2、微服务架构：从单体应用到微服务的转型指南

微服务架构：从单体应用到微服务的转型指南

1. 何时选择何种架构

在软件行业中，单体分层架构是最为常见的架构之一。它非常适合面向事务的企业应用，这类应用通常具有明确的功能特性、变更频率较低，并且拥有复杂的业务模型。对于此类应用，事务和一致性至关重要，因此需要采用具备内置 ACID 属性支持的数据库技术来存储事务。

而微服务则更适用于软件即服务（SaaS）以及互联网规模的应用。这些应用以功能特性为首要考量，每个功能专注于单一的业务能力。它们的变更速度极快，并且可以根据业务需求对单个业务能力进行局部扩展。不过，由于存在多个服务，与作为单一应用实现的单体应用相比，这类应用中的事务和一致性更难以实现。

建议从设计精良、模块化的单体应用开始，无论领域复杂度或事务性质如何。通常，所有应用最初都是以单体应用的形式启动的，这样可以作为单个工件快速部署。当应用的复杂性开始超过团队的生产力时，再将其拆分为微服务。

团队生产力可能会在对单体应用的更改开始影响多个组件时下降。这些更改可能是由于向应用添加新功能、升级数据库技术或重构现有组件引起的。对应用所做的任何更改都必须使整个团队保持同步，特别是部署团队（如果部署过程需要进行更改）。在大型团队中沟通此类更改通常会导致协调困难、产生多个变更请求，进而降低处理该应用的团队的整体生产力。

生产力还取决于最初对技术栈的选择及其实现的灵活性。例如，如果新功能需要一个在不同技术栈或编程语言中容易获取的库，那么采用该库就会变得具有挑战性，因为它不符合应用组件现有的技术栈。在这种情况下，团队最终可能需要为当前技术栈从头开始实现相同的功能集，这不仅会降低生产力，还会增加技术债务。

在开始采用微服务之前，首先要在