微服务，只有年收入 20 亿美元的公司才需要。

这是个肯定句，是经过多层的数据研究，公司到达此规模，才有充分的理由采用微服务架构。

之前是什么状态？

单体式架构演化为基于服务的模块化单体式架构，然后才演化为宏服务、迷你服务与微服务。

这是为什么？

付出最少努力的解决方案，是提供适应和发展业务能力的首选解决方案。

什么是微服务架构？

微服务架构就像沙漠中的一粒沙子，虽然很小，但聚集在一起，就会变得非常庞大。

微服务的关键特征包括：

• 小而集中

• 执行非常细微的功能

• 只操作需要的数据

• 服务层上进行协作

• 通常按反应方执行

• 数据按比例解耦

如果微服务做得好，它们将拥有完全自动化的配置流程，这是纯正的云原生，在各个层都会有很好的解耦。

但它们存在一些问题，需要做以下权衡：

• 业务流程更难以映射

• 服务协作很困难

• 数据状态难以协调

• 集成要复杂得多

• 自动化成本更高

• 复杂性更难控制

• 可观察性是一个挑战

减少这些权衡需要一种渐进的方法，来让事情变得更小，同时处理分发的额外复杂性。对于我们大多数人来说，当公司的年收入不到 20 亿美元时，并不需要微服务特性。

架构如何帮助业务？

许多组织考虑转向微服务架构，希望很快赶上最新趋势的潮流。

独立于技术架构，企业希望在速度兼具质量的范例中实现增长：

1. 为用户传递价值

2. 快速测试新的想法

3. 可在短时间内适应

4. 保持可控性

5. 支持增加流量

6. 有利可图
   
   

从该列表中，下一阶段是确定技术如何成为业务限制的因素，以明确区分问题与可能的解决方案。

所有解决方案通常都需要关键功能的高可用性、更多的模块化，以更好地适应更多的变化以及在小范围内测试想法的能力。

不同的是限制因素，这取决于上下文：

• 哪个范围必须改变很多？

• 是否有关键区域不稳定或存在风险？

• 哪些部分累积了更多的复杂性？

• 哪里达到协作限制？

• 哪些资源可以更改？

这些问题是定义从初始架构所需的最小架构演变的起点，可能并不用改变那么多。

架构与业务一起成长

软件行业发展到社会技术生态系统的概念，认识到人、流程、组织、文化和技术之间的联系。

这种相互依赖性需要每个领域保持一致，使其朝着正确的方向发展，以最小的努力发展业务。

基于该模型，应避免的问题实例是：

• 只有3 名软件工程师的微服务架构；

• 拥有 500 名开发人员的模块 ，但缺少共享支持

• 每个软件团队在没有共享支持的情况下完成 50% 的运行任务

该列表还在继续。

我们对 50 多家公司的研究揭示了以下的宏观模型：

1. 单体：收入为 0-200 万美元，10 个 FTE （全职员工）

2. 单体模块化：2-2000 万美元的收入，最多 50 个 FTE

3. 基于服务：20-2 亿美元的收入，最多 500 个 FTE

4. 从宏服务到迷你服务：2 亿美元至 20 亿美元的收入，最高 5000 FTE

5. 迷你服务到微服务：超过 5000 个 FTE ，收入 > $20亿美元。

请看如下图片：

分析还显示，声称要实施微服务的公司实际上是在实施基于服务或宏服务的架构。

例如，数字电子商务上下文中的“购物车”服务是宏服务而不是微服务，因为它是模块化的，具有与其它应用程序的显式接口，但仍在相同的功能和技术范围内执行多种业务功能。

关键的技术差异在于服务的粒度更高，服务之间共享数据而不是外部解耦。

以最小的努力调整生态系统

在业务发展的不同阶段，不同的架构需要不同的社会技术生态系统。

目标与技术无关——它与支持业务适应和快速增长的最小一致性有关。

在日常工作中可能没有那么花哨的流行语，但更高的效率和软件交付将有所作为。

因此，首先要为自己的业务做出正确的选择，同时“单体模块化”和“最小架构”再次成为主流。

它们均是质量工程的一部分。如果本篇文章对你有用，请点赞 👏

作者：大雄