微服务大规模化，面临的挑战？

前言

曾经看过《改变自己》的一篇文章《规模化思考》，讲述了对于某件事情，我们能否从十倍或者百倍的角度，思考其规模，从而在一个相当长的周期内，考虑价值的投入产出比。

最近，看到了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个方面探讨了服务规模化面临的挑战。

来源：中生代技术

原文链接