2、微服务架构：从单体应用到高效开发的转变

微服务架构：从单体应用到高效开发的转变

1. 何时选择何种架构

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

而微服务则更适合软件即服务（SaaS）和互联网规模的应用。这些应用以功能为先，每个功能专注于单一业务能力，变更迅速，并且可以根据业务能力按需部分扩展。由于存在多个服务，与作为单个应用实现的单体应用相比，此类应用中的事务和一致性更难实现。

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

团队生产力可能会在以下情况开始下降：
- 对单体应用的更改开始影响多个组件。这些更改可能是由于向应用添加新功能、升级数据库技术或重构现有组件引起的。对应用所做的任何更改都必须使整个团队保持同步，特别是部署团队，如果部署过程需要更改的话。在大型团队中沟通此类更改通常会导致协调困难、多个变更请求，进而降低处理该应用的团队的整体生产力。
- 生产力还取决于最初对技术栈的选择及其实现的灵活性。例如，如果新功能需要使用不同技术栈或编程语言中现成的库，由于它不符合应用组件现有的技术栈，采用起来就会很有挑战性。在这种情况下，团队最终会为当前技术栈从头开始实现相同的功能集，这反过来又会降低生产力并进一步增加技术债务。

在开始使用微服务之前，首先要在团队成员之间建立最佳设计原则。接下来，尝试评估现有单体应用的组件及其交互。如果重构