4、微服务架构：从单体应用到灵活架构的转变

微服务架构：从单体应用到灵活架构的转变

1. 单体应用架构的问题

在传统的单体应用架构中，存在着诸多问题，这些问题限制了应用的可扩展性、灵活性和对新技术的适应性。

1.1 单体应用模块间依赖

单体应用架构中，应用内的模块紧密耦合。模块之间通过本地调用协议或合适的远程协议进行通信，且大多数调用是同步的，即每个请求事务都期望得到响应或异常反馈。
- 当所有模块打包部署在同一进程中时，本地方法调用是最佳通信方式。但这种部署方式下，要么整个应用正常运行，要么只要某个模块的任何部分出现问题，整个应用就会崩溃。
- 若将部分模块分离部署到不同进程，分离模块所在进程的健康状况不会影响其他依赖进程。然而，从整体来看，如果分离模块因任何原因停止运行，依赖模块仍会受到影响。因为模块间通信是直接的同步方法调用依赖，若被调用模块无响应或不存在，调用模块会受到影响，可能无限阻塞或等待一段时间后报错。

1.2 可扩展性困境

现代应用架构应具备水平可扩展性，即同一功能的多个实例可部署到不同进程，客户端对同一功能的请求可由具有相同功能的任何服务器进程处理，这种拓扑结构称为服务器群。
以电子商务应用为例，用户与应用的交互步骤通常如下：
1. 访问电子商务应用的主页。
2. 浏览产品类别。
3. 选择感兴趣的商品并浏览所选产品的详细信息。
4. 若感兴趣，将所选商品添加到购物车。
5. 创建用户资料或登录已有账户。
6. 付款并结算商品，确认订单。

通常，许多已登录和未登录的用户会浏览大量产品类别和产品详情页面，因此处理这些请求的产品模块比订单模块承受的压力更大。为了灵活应对