这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天，记录一下对微服务和服务网格的学习。
微服务架构
优势
现代大型复杂应用往往由多个微服务组成。每个微服务可以被独立部署，专注于完成一件任务，微服务之间是松耦合的。微服务架构相比于传统单体应用架构具有复杂度可控、易于容错、易于扩展、技术选型灵活等优势。
不足
以 Spring Cloud 和 Dubbo 为代表的传统微服务开发框架在企业内部得到了广泛的应用，但这其中也存在一定的问题：
- 侵入性强：要想集成 SDK 的能力，除了要添加相关依赖，往往还需要在业务代码中添加一部分代码、注解或者配置，导致业务层代码与服务治理层代码耦合。
- 组件多、门槛高：以 Spring Cloud 为例，包含大大小小几十个组件，内容很多，需要很长时间去熟悉其中的关键组件。如果要想使用 Spring Cloud 作为完整的治理框架，则需要深入了解其中的原理与实现。
服务网格（Service Mesh）
定义
服务网格是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。
特点
服务网格由一堆紧挨着各个服务的用户代理和一组任务管理流程组成。代理在服务网格中被称为数据层或数据平面（data plane），管理流程被称为控制层或控制平面（control plane）。
在服务网格中，代理作为一个 sidecar 被注入到每个服务部署中。服务不直接通过网络调用服务，而是调用它们本地的 sidecar 代理，而 sidecar 代理又代表服务管理请求，从而封装了服务间通信的复杂性。相互连接的 sidecar 代理集构成了数据平面。
控制平面的作用主要有代理配置、服务发现、指标收集等。
优势
相比于传统微服务架构，服务网格实现了微服务治理与业务逻辑的解耦。服务网格把 SDK 中的大部分能力从应用中剥离出来，拆解为独立的进程，以 sidecar 的模式进行部署；服务网格通过将服务通信及相关管控功能从业务程序中分离并下沉到基础设施层，使其和业务系统完全解耦，使开发人员更加专注于业务本身。
