3、微服务架构：从挑战到解决方案

微服务架构：从挑战到解决方案

1. 平台组件扩展与挑战

在平台开发中，借助定义良好的 API，每个组件都能独立扩展到多个服务器，以满足高可用性需求或处理更高的请求量。例如在特定项目里，通过在运行 Java EE 网络容器的多个服务器前手动设置负载均衡器来实现扩展。

然而，将平台分解为多个组件也带来了新挑战：
- 手动配置繁琐易错 ：为组件添加新实例时，需要手动配置负载均衡器和设置新节点，既耗时又容易出错。
- 系统交互易出错 ：平台易受与之通信的其他系统影响。若对方系统未能及时响应请求，平台会迅速耗尽关键资源，如操作系统线程，尤其在大量并发请求时，可能导致组件挂起甚至崩溃，进而引发级联故障。
- 配置管理困难 ：保持所有组件实例的配置一致且最新是个难题，会产生大量手动且重复的工作，还可能引发质量问题。
- 状态监控复杂 ：监控平台的延迟问题和硬件使用情况（如 CPU、内存、磁盘和网络的使用）比监控单体应用的单个实例更为复杂。
- 日志收集关联难 ：从多个分布式组件收集日志文件并关联相关日志事件虽可行，但也有难度。

2. 微服务的引入

2014 年了解到基于微服务的架构后，发现其他项目也面临类似挑战。许多微服务先驱最初开发的单体应用在业务上取得成功，但随着时间推移，维护和演进变得困难，垂直扩展也达到极限。于是，他们开始将单体应用拆分为更小的组件，通过水平扩展部署在多个较小的服务器上，并在前面放置负载均衡器。在云端，扩展能力