前言
《改变自己》的一篇文章《规模化思考》，讲述了对于一件事情，能否从十倍或者百倍的角度，思考其规模，从而帮助我们尽早考虑，在相当长的时间周期内识别风险，并将价值最大化。
最近，看到了Susan Fowler的演讲视频《Microservice Standardisation》，分享了她在Uber作为SRE，经历从800+ 服务到接近2000+服务的运维心得，并提出了一些有代表性的规模化观点。
而这也正是我目前的思考，(目前工作在大型传统企业，服务的规模化会成为下一个阶段所面临的挑战)。
微服务经历了过去几年的快速发展，帮助很多组织解决了复杂系统的伸缩性、灵活性、以及快速响应的问题后，那下一个阶段的挑战在哪里？
规模化引发的思考？
如果从规模化的角度考虑，对于一些大型组织（尤其是传统行业），拥有成千上万的微服务后，会面临哪些挑战? 是个体能力的提升，组织的差异化还是流程的动态演进？
服务规模化
我们常说，天下大势，分久必合，合久必分，在经历了松散的细粒度架构演进，未来是否还需要标准化？
如果标准化，是否从某种程度违背了微服务的初衷？微服务概念的诞生，不是为了提升复杂系统的交付效率，才基于分而治之的思想并差异化演进吗？
如果需要标准化，从架构、实践和组织三个维度展开，是权宜之计还是一劳永逸？
规模化带来的挑战
参考Susan的演讲，我总结了服务规模化后可能面临的挑战。
1. 组织的孤岛效应
根据康威定律以及康威逆定律，组织的沟通结构与其设计的系统架构是对等的。
如果存在1000个服务，那么得到的将有可能是与其对应的1000个小团队。在充分享受团队自组织带来优势的同时，也要辩证的看待团队间的差异性。不同团队的服务实践如何？他们是如何测试、部署、监控的？
作为开发成员，如果换去另一个团队，在框架、工具百花齐放、层出不穷的今天，是否大大增加了上手的成本。当服务数量激增后，需要专业的QA/Ops/SRE，组织内是否能找到足够多的这样资深的专业人员？
所以，这其实是速度与成本的博弈。
2. 处理失败的成本增加
根据墨非定律，“凡是可能出错的情况，必定会出错”。
随着服务的数量增加，系统失败的几率会大幅增加。
每一个服务的失败都有可能导致故障。虽然我们的目标是期望每个服务都能够互不依赖，自适应，高度容错，但是必须找到有效的方式来确保服务可用。
因此，处理失败的成本大幅增加。
3. 优势资源的竞争
微服务系统就像是自然界的生态系统，对资源的使用，关系复杂且微妙。
当有成千上万的服务时，资源如何分配？从业务角度分析，哪个服务的优先级高？哪个团队应该优先获得更优秀的资源？包括但不限于优秀的工程师、资金、软件、硬件等等。
任何时候，资源都不是免费的。
当只有几个微服务时，这些问题都不会是问题，但随着服务数量的增加，这种协作与竞争的关系会愈发明显。
4. 独立性、技术债与成本
自由选择编程语言，自由选择数据库......听起来激动人心，但如何长期维护并保证可持续发展，是一个值得研究的话题。
随着微服务的大热，组织中许多人员对微服务过度追捧。
很多人认为微服务对应着松散的组织结构，只要能独立交付，团队可以做任何他们想做的。从技术角度而言，技术日新月异的变化，会产生各种大大小小的技术债，而随着采用微服务化在技术上的多样性，将变得难以维护。
微服务确实意味着自由与独立。但在大规模的组织中，过度的独立性必然带来高昂的管理与维护成本。从工程角度而言，当拥有成千上万的服务时，集中式的管控平台并不像我们认为的那样糟糕，确保大部分团队能使用相同的方式、相同的标准，能够低成本运作。
5. 团队的信任危机
作为服务的交付团队的负责人，你和我一样 :)， 积极上进且有必胜的信念。
充满豪情壮志，愿意带领团队遵循各种最佳实践、完美的实现所负责的服务。
但是，我们永远无法保证，依赖的所有上下游团队，也能按照同样的标准实现服务。这是现实。
而且，随着服务关系越复杂，依赖越多，出问题的几率越大，信任危机愈发明显。
总结
微服务经历了过去几年的快速发展，帮助很多组织解决了复杂系统的伸缩性、灵活性、以及快速响应的问题后，那下一个阶段的挑战在哪里？
是个体能力的提升，组织的差异化运作还是流程的自适应演进？
参考
https://www.infoq.com/news/2017/01/production-ready-microservices
http://www.oreilly.com/programming/free/microservices-in-production.csp
https://static1.squarespace.com/static/57a6de391b631b6aa4789ebf/t/582c2afe1b631bf8805848cf/1479289601725/Susan+Fowler%27s+SACON+2016+SF+Slides.pdf
网友评论