只有 1% 的人需要微服务
导读：只有 1% 的人需要微服务。而当今有一些技术团队为了微服务而微服务，平添很多重复杂性，成本大于效能多倍。 本文言简意赅，发人深省，告诉我们如何调整。
微服务，只有年收入 20 亿美元的公司才需要。
这是个肯定句，是经过多层的数据研究，公司到达此规模，才有充分的理由采用微服务架构。
之前是什么状态？
单体式架构演化为基于服务的模块化单体式架构，然后才演化为宏服务、迷你服务与微服务。
这是为什么？
付出最少努力的解决方案，是提供适应和发展业务能力的首选解决方案。
什么是微服务架构？
微服务架构就像沙漠中的一粒沙子，虽然很小，但聚集在一起，就会变得非常庞大。
微服务的关键特征包括：
小而集中
执行非常细微的功能
只操作需要的数据
服务层上进行协作
通常按反应方执行
数据按比例解耦
如果微服务做得好，它们将拥有完全自动化的配置流程，这是纯正的云原生，在各个层都会有很好的解耦。
但它们存在一些问题，需要做以下权衡：
业务流程更难以映射
服务协作很困难
数据状态难以协调
集成要复杂得多
自动化成本更高
复杂性更难控制
可观察性是一个挑战
减少这些权衡需要一种渐进的方法，来让事情变得更小，同时处理分发的额外复杂性。对于我们大多数人来说，当公司的年收入不到 20 亿美元时，并不需要微服务特性。
架构如何帮助业务？
许多组织考虑转向微服务架构，希望很快赶上最新趋势的潮流。
独立于技术架构，企业希望在速度兼具质量的范例中实现增长：
为用户传递价值
快速测试新的想法
可在短时间内适应
保持可控性
支持增加流量
有利可图
从该列表中，下一阶段是确定技术如何成为业务限制的因素，以明确区分问题与可能的解决方案。
所有解决方案通常都需要关键功能的高可用性、更多的模块化，以更好地适应更多的变化以及在小范围内测试想法的能力。
不同的是限制因素，这取决于上下文：
哪个范围必须改变很多？
是否有关键区域不稳定或存在风险？
哪些部分累积了更多的复杂性？
哪里达到协作限制？
哪些资源可以更改？
这些问题是定义从初始架构所需的最小架构演变的起点，可能并不用改变那么多。
架构与业务一起成长
软件行业发展到社会技术生态系统的概念，认识到人、流程、组织、文化和技术之间的联系。
这种相互依赖性需要每个领域保持一致，使其朝着正确的方向发展，以最小的努力发展业务。
基于该模型，应避免的问题实例是：
只有3 名软件工程师的微服务架构；
拥有 500 名开发人员的模块 ，但缺少共享支持
每个软件团队在没有共享支持的情况下完成 50% 的运行任务
该列表还在继续。
我们对 50 多家公司的研究揭示了以下的宏观模型：
单体：收入为 0-200 万美元，10 个 FTE （全职员工）
单体模块化：2-2000 万美元的收入，最多 50 个 FTE
基于服务：20-2 亿美元的收入，最多 500 个 FTE
从宏服务到迷你服务：2 亿美元至 20 亿美元的收入，最高 5000 FTE
迷你服务到微服务：超过 5000 个 FTE ，收入 > $20亿美元。
请看如下图片：
分析还显示，声称要实施微服务的公司实际上是在实施基于服务或宏服务的架构。
例如，数字电子商务上下文中的“购物车”服务是宏服务而不是微服务，因为它是模块化的，具有与其它应用程序的显式接口，但仍在相同的功能和技术范围内执行多种业务功能。
关键的技术差异在于服务的粒度更高，服务之间共享数据而不是外部解耦。
以最小的努力调整生态系统
在业务发展的不同阶段，不同的架构需要不同的社会技术生态系统。
目标与技术无关——它与支持业务适应和快速增长的最小一致性有关。
在日常工作中可能没有那么花哨的流行语，但更高的效率和软件交付将有所作为。
因此，首先要为自己的业务做出正确的选择，同时“单体模块化”和“最小架构”再次成为主流。
它们均是质量工程的一部分。如果本篇文章对你有用，请点赞 👏
作者：大雄
相关阅读：