前言
在这篇文章中，我将演示在决定使用单体架构、微服务架构和无服务器架构时的权衡的简化心智模型。目标是突显每种风格的固有优势和缺陷，并提供关于何时选择哪种架构风格的指导。
单体架构
对于小团队或项目来说是理想的入门架构。它简单易上手，通常在需要超过一个团队的规模之前能够提供很多收益。
在构建单体架构时，务必从模块化开始，即使可能会增加样板代码。这意味着构建组件并在层之间保持严格的逻辑分离（更多详见Clean Architecture）。
•通信层 — 服务的外部接口•封装 — 业务逻辑或用例的清晰接口•领域实体 — 业务对象的数据表示，仅供内部使用•架构隔离 — 避免实体之间的跨领域连接
优势
•开发便利性 — 所有代码都在一起。•部署便利性 — 所有代码一起部署。•网络效率 — 所有计算发生在进程内。•成本共享效率 — 每台服务器上有大型共享的 CPU 和内存池。
权衡
•组织规模的限制 — 由于开发、部署和代码的紧密耦合，需要协调的开销增加。•技术债务的风险 — 容易采取捷径，构建紧密耦合的代码。
当您的团队看起来像上面的插图时，这表明您应该考虑演进您的架构到微服务。开发中的复杂性增加会高风险地降低质量，从而导致生产力减缓。这产生了一个矛盾的效果，即您雇佣的人越多，交付就变得越慢和不可预测。
微服务
对于业务需求开始增长并且团队分成多个团队时，这是理想的架构。这个里程碑自然地与将单体架构拆分成自然的、上下文边界的微服务相配合，以便团队可以更独立地扩展。
设计你想要的组织，架构会追随着，踌躇着走来
我强烈建议采用Inverse Conway Maneuver策略，打破您的通信模式，否则促使单体的熟悉模式将继续像胶水一样将团队粘在一起。
优势
•独立交付 — 减少依赖关系。•明确所有权 — 实现强大的所有权模型。•组织规模 — 促进团队间相对独立的并行努力。•独立扩展 — 计算隔离允许平台的各部分独立扩展。
权衡
•协调标准 — 标准的变化可能泄漏到架构中，降低一致性和整体可维护性。•网络延迟惩罚 — 曾经在单个服务中共同存在的进程现在正在进行引入端到端计算的网络调用，引入了延迟。•资源共享减少 — 曾经共享相同 CPU、内存和磁盘需求的进程现在部署有自己的专用资源。•成本增加 — 与单体相比，每个服务的额外网络 I/O 和资源会导致额外的成本。
无服务器
对于不需要实时保证的某些工作负载来说，这是理想
的架构风格。异步、分布式处理，不要求代码始终保持热和立即可用。
截至撰写本文时，该行业正在朝着编写更经济的系统的“绿色”方向发展，以减少我们计算的碳足迹。我认为这种架构风格是生态系统的一个强大补充，但并不能完全取代它的前辈的必要性。
优势
•精益扩展 — 仅扩展所需的无服务器函数。•成本效益 — 仅在需要时使用最少的资源部署资源。（警告：仅当计算是间歇性的时候。在计算需要保持热时，请查看下面的权衡。）
权衡
•资源效率惩罚 — 曾经共享相同 CPU、内存和磁盘需求的进程现在每个都有自己的最小要求。•成本效益差 — 只有在部署时有恒定需求，使每个函数运行像热服务器时。•网络惩罚 — 与单体和微服务相比，每个函数调用现在都是一个网络跳跃，而不是作为进程内计算共同存在。
随着时间的推移演进
那么，当您的业务或产品的需求不断增长时，您的架构演进可能是什么样子呢？