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