3、深入理解微服务：架构、挑战与设计模式

深入理解微服务：架构、挑战与设计模式

1. 平台组件扩展与自主软件组件挑战

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

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

2. 微服务的兴起与相关技术

2014 年，微服务架构逐渐进入视野，许多项目都在应对类似挑战。一些微服务先驱最初开发的单体应用在业务上取得成功，但随着时间推移，维护和演进变得困难，垂直扩展也达到瓶颈。于是，他们开始将单体应用拆分为更小的组件，实现独立发布和扩展，即水平扩展。

同年，一些新的