单体应用、微服务和无服务器

本文说明在决定单体、微服务和无服务器架构时权衡的简化思维模型。目标是突出每种风格的固有优势和差距，同时为何时选择哪种建筑风格提供指导。

单体
小型团队或项目的理想入门架构。它启动起来很简单，并且通常可以提供很多里程，直到您需要扩展到单个团队之外。

在构建单体应用时，必须从模块化开始，即使看起来似乎添加了样板代码。这意味着构建组件并遵守层之间严格的逻辑分离（请参阅清洁架构了解更多内容）。

• 通信层——服务的外部接口
• 封装——业务逻辑或用例的干净接口
• 领域实体 - 仅供内部使用的业务对象的数据表示
• 模式隔离——避免实体之间的跨域连接

• 易于开发——所有代码都在一起。
• 易于部署——所有代码一起部署。
• 网络效率——所有计算都发生在进程内。
• 成本分摊效率 — CPU 和内存是每台服务器的一个大型共享池。

• 限制组织规模——开发、部署和代码紧密耦合带来的协调开销。
• 技术债务风险——易于走捷径和构建紧密耦合的代码。

随着开发复杂性的增加存在质量下降的高风险，从而导致生产力下降。它会产生一种矛盾的效果，即你雇佣的人越多，你的交付就越慢且更不可预测，需要转向微服务

微服务
当您的业务需求开始增长并且您的团队分成多个团队时，这是理想的扩展架构。这个里程碑自然地与将您的整体分解为自然的、上下文的边界相结合，以允许您的团队更加独立地扩展。

强烈建议遵循逆康威 策略来打破你的沟通模式，否则促进你的整体的熟悉模式将继续像胶水一样将团队粘合在一起。

优势

• 独立交付——减少依赖。
• 澄清所有权——实现强大的所有权模型。
• 组织规模——促进跨团队工作相对独立的并行化。
• 独立扩展——计算隔离允许平台的各个部分单独扩展。

• 协调标准——标准的变化可能会渗透到架构中，从而降低一致性和整体可维护性。
• 网络延迟惩罚——曾经共同位于单个服务中的进程现在正在进行网络调用，这会导致端到端计算的延迟。
• 减少资源共享——曾经共享相同 CPU、内存和磁盘要求的进程现在部署有自己的专用资源。
• 成本增加——与单体应用相比，每项服务的额外网络 I/O 和资源的成本会进一步增加。

无服务器
对于不需要实时保证的某些类型的工作负载来说是理想的架构风格。异步、分布式处理，不需要代码始终处于热状态并立即可用。

截至撰写本文时，该行业正在转向更加“绿色”地编写构建系统，这些系统在减少计算的碳足迹方面更加经济。我认为这种架构风格是对生态系统的有力补充，但并不能完全取代其前身的必要性。

优势

• 精益扩展——仅扩展所需的无服务器功能。
• 成本效益 — 仅在需要时以最少的资源部署资源。（警告：仅当计算是间歇性的时。当计算需要热时，请参阅下面的权衡）

• 资源效率惩罚——曾经共享相同 CPU、内存和磁盘要求的进程都有自己的最低要求。
• 成本效益差——仅在部署有持续需求、使每个功能像热服务器一样运行的情况下。
• 网络惩罚——与单体和微服务相比，每个函数调用现在都是一个网络跃点，而不是作为进程内计算并置。
• 随着时间的推移而演变

结束语
“天上掉馅饼”架构想法通常会让人产生一种高耸的摩天大楼的形象，其理想标准并不真正代表现实。这种差异使得弥合理想主义与实用主义的挑战留给读者自己解决。