这是我参加「第三届青训营-后端场」笔记创作活动的第5篇笔记
听完课程对于一些名词不太理解，因此阅读了相关文档进行补充，学习资料传送门
Service mesh：可以概括为微服务时代的TCP/IP协议
微服务：一种「软件架构风格」，专注于单一责任和功能的小型功能区块为基础，利用「模块化」的方式组合出复杂的大型程序，各功能区块的使用与语言无关的API集相互通信。
个人理解：微服务的设计风格可以让我们把一个大型项目拆解为彼此之间松耦合的小型部分，更加方便对任务进行划分实现和测试。同时，语言无关的特性，使其可以应用于多个场景。
技术演进历史
-
最纯朴简单的服务间通信方式（非常抽象的方式，未考虑任何细节）
-
原始通信时代：开始考虑一系列细节实现和控制问题，除了业务逻辑还包含网络传输逻辑。
-
TCP时代：「分层划分」，为了避免每个服务都需要自己实现一套相似的网络传输处理逻辑，将技术栈下移，
从图里可以看到原始通信时代到TCP时代的变化
- 第一代微服务：需要解决分布式系统引入的问题，分布式特有的通信语义包含熔断策略、负载均衡、服务发现、认证授权等，于是服务根据业务需求来实现一部分所需的通信语义。
- 第二代微服务：为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，出现了一些面向微服务架构的开发架构，能够在一定程度上屏蔽这些通信细节。
-
第一代service mesh
第二代微服务模式存在的问题：
-
开发者需要花费时间掌握和管理复杂的框架
-
开发框架只支持一种or几种语言（与微服务语言无关的特性相悖
-
框架以lib库形式和服务联编，复杂项目会面临复杂的依赖问题
因此出现了一Linkerd为代表的代理模式「边车模式」应运而生
分布式服务通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样上边所说的三个问题也迎刃而解。
从全局视角看，也可以称为服务网格
-
-
第二代service mesh：第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。
服务网格是一个
基础设施层
，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证
请求在这些拓扑中可靠地穿梭
。在实际应用当中，服务网格通常是由一系列轻量级的
网络代理
组成的，它们与应用程序部署在一起，但
对应用程序透明
。
Service mesh总的来说，有四个关键词
-
基础设施层
请求在这些拓扑中可靠穿梭
-
网络代理：实现形态
-
对应用透明：关键特点，能够解决spring cloud为代表的第二代微服务框架所面临的三个本质问题
