微服务

维基百科的定义

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关(Language-Independent/Language agnostic) 的 API 集相互通信。

目前与微服务有关的平台/框架：Spring Cloud， Service Fabric，Linkerd，Envoy，Istio …

分布式系统与微服务

1、分布式系统定义

应用开发后随着业务量变大，单机计算存储不能满足要求后，部署时会像分布式架构转变
分布式系统是若干独立计算机的集合，这计算机对用户来说就像单个相关系统

2、设计原则

CAP 原则

• 一致性（consistency）：保持所有节点在同一个时刻具有相同的、逻辑一致的数据。
• 可用性（availability）：保证每个请求不管成功还是失败都有响应。
• 分区容忍性（partition tolerance）：系统中任何的信息丢失或者失败都不会影响系统的继续运作。

BASE 理论

即使分布式系统无法做到强一致性，也可以采用适当的方法达到最终一致性。

• BA（Basically Available，基本可用）：在分布式系统中，最重要的需求是保证基本可用，有响应结果返回。比如典型的降级服务。
• S（Soft State，软状态）：其意义在于允许系统存在中间状态。一般来说，系统之间的数据通信都会存有副本，而这些副本都会存在一定的延迟。这时推荐使用弱一致性代替强一致性。这样的好处在于，提高系统的可用和性能。
• E（Eventual Consistency，最终一致性）：是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，以保证数据的正确性。

3、分布式系统对通信的要求

熔断策略、负载均衡、服务发现、认证和授权、quota限制、trace和监控等等

4、分布式系统与微服务区别

• 微服务：是一种架构风格，聚焦在系统设计层面，解决的是系统复杂度问题（一般是应用的业务问题），即在一个系统中承担职责太多了，需要从逻辑上进行拆分，便于理解和维护，进而提升系统的开发效率和运行效率
• 分布式：系统部署层面，解决的是系统性能问题，即解决系统部署上单点的问题，尽量让组成系统的子系统分散在不同的机器上进而提高系统的吞吐能力

微服务的发展

1、初代微服务

利用框架实现分布式系统通信需要的各种通用语义功能，如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节。例如：spring cloud/dubbo

但是微服务框架存在一些问题
其一，虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事；
其二，开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到；
其三，框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级；

2、第一代服务网格Service Mesh

sidecar（边车模式），例如Linkerd，Envoy，NginxMesh
将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信

3、第二代服务网格Service Mesh

提供了统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh

服务网格Service Mesh

维基百科的定义

在软件架构中，服务网格是一个专用的基础设施层，用于使用代理促进服务或微服务之间的服务到服务通信。专用通信层可以提供许多好处，例如提供对通信的可观察性，提供安全连接，或自动重试和回退失败的请求。
服务网格由与应用程序中的每个服务配对的网络代理和一组任务管理流程组成。代理称为数据平面，管理进程称为控制平面。数据平面拦截不同服务之间的调用并“处理”它们；控制平面是网格的大脑，负责协调代理的行为，并为运维人员提供 API 来操作和观察整个网络

服务网格是仅针对“微服务”可用吗？
不是的，有服务就可以使用，适用于容器化业务后的服务治理

服务网格的特点

• 基础设施：处理服务间通信的基础设施
• 云原生：适用于云原生场景下的服务间的通信
• 网络代理：轻量级的网络代理来执行治理逻辑
• 对应用透明：应用程序网络代理部署在一起，但应用感知不到代理的存在

服务网格作用——服务治理

治理内容包括：连接、安全、策略执行和可观察性

• 连接：通过配置的流量规则控制服务间的流量和调用，实现负载均衡，熔断，故障注入，重试，重定向等服务治理
• 安全：提供认证机制、通道加密、服务访问授权等，增强服务访问的安全性
• 策略执行：通过可动态插拔，可扩展的策略，实现访问控制，速率限制，配额管理，服务计费等能力
• 可观察性：动态获取服务运行数据和输出，提供强大的调用链，监控，和调用日志收集与输出的能力。

服务网格与微服务的区别

• 微服务：是一种架构风格，是一种方法论
• 服务网格：是服务治理组件持续下沉的具体实践，为了解决业务服务的非业务功能部分复杂度，衍生出来的通信方式，解决的是分布式系统的痛点

技术栈

1、控制面

控制面有很多软件，Istio胜出

2、数据面

数据面有很多软件，Envoy胜出

3、基于Istio与Envoy的服务网格

在控制平面上，Istio由三个组件（ Pilot、Citadel、Galley ）整合成了一个单进程、多模块的istiod

• Pilot：控制面最重要的组件，提供服务发现、流量路由及服务治理（超时，重试，熔断等）功能
• Citadel：与安全相关的组件，主要负责密钥和证书的管理，可以实现强大的授权和认证等功能
• Galley：配置管理的组件，从底层平台获取配置，验证配置信息的格式和内容的正确性，并将这些配置信息提供给Pilot使用

数据面上，pod启动后内部组成如下
实际会创建3个容器

• istio-init容器：在istio-proxy容器和微服务容器启动前运行，进行一些初始化操作后退出，所以在pod创建成功后，只能看到istio-proxy容器和微服务容器
• istio-proxy代理容器：容器中运行着两个进程：pilot-agent和envoy

1、pilot-agent：pilot-agent是istio-proxy的入口进程，负责envoy进程的生命周期管理。pilot-agent会生成启动envoy进程需要加载的静态配置文件，启动envoy进程，监控和管理envoy进程的状态，如envoy出错时重启envoy，或envoy配置变更后reload envoy
2、envoy启动时读取pilot-agent提供的静态配置文件：etc/istio/proxy/envoy-rev0.json，获得控制面Pilot地址，通过访问Pilot提供的接口，获取动态配置信息（如Cluster信息、Endpoint信息、Route信息等），根据配置信息进行服务间通信及服务管理

• 微服务容器：具体的业务容器

参考文档

https://philcalcado.com/2017/08/03/pattern_service_mesh.html
https://blog.csdn.net/h2604396739/article/details/115869669
https://www.itdaan.com/tw/7e0a437fc6e5511166589e35f2856aec
https://zhuanlan.zhihu.com/p/499341027
https://zhuanlan.zhihu.com/p/504313570
https://zhuanlan.zhihu.com/p/61901608