赵 鑫 李铭轩

1 北京邮电大学 北京 100876

2 中国联通研究院 北京 100048

引言

在传统代码架构中，随着新功能的增加，代码库会越变越大。尽管代码被分成各个模块，但随着时间推移，这些界限将变得模糊。代码之间功能类似的模块将越来越多，维护将变得越来越困难[1]。相对于传统软件，微服务是一种新型架构方式。它提倡将单一应用程序划分成一组小的服务，每个服务独立完成一个很小的功能。服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制(通常是基于HTTP的Restful API)相互沟通[2]。但微服务架构下软件稳定性不够强，故障率相对较高，且故障原因复杂，微服务的故障治理一直是一个很大的挑战。

容器是一种虚拟化技术，相比于VM，具有更好的性能，更轻量和更好的扩展性[3]。每个容器上运行一个进程，容器内打包这个进程所需要的所有依赖环境，拥有良好的移植性。容器之间彼此独立运行，负责单一的功能。容器间也可以相互配合，相互调用，完成更大的功能。容器技术的特点使它与微服务架构完美适配。这里也使用容器技术实现微服务架构。

服务网格是用于处理服务与服务之间通信的专用基础设施层。其主要思路是为每个微服务实例(往往以容器形式)都设置反向代理组件，即Sidecar。所有进出微服务的流量会被Sidecar劫持，通过该组件进行处理和转发[4]。服务网格在不侵入业务代码的情况下可以完成对微服务集群的监控，为微服务故障治理提供了新的解决思路。……