前言
《改变自己》的一篇文章《规模化思考》,讲述了对于一件事情,能否从十倍或者百倍的角度,思考其规模,从而帮助我们尽早考虑,在相当长的时间周期内识别风险,并将价值最大化。
最近,看到了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