Service Mesh 和 Spring Cloud

Spring Cloud 相信大家经过这几年微服务文化的熏陶已经非常了解熟悉了，这个框架的最大有点可以说是非常容易上手，因为spring 快速集成的关系导致使用Cloud全家桶内的东西非常方便，但是缺点也是比较明显的：

1. 不能跨语言，只支持java应用
2. 需要进行最简单的相关配置
3. 每一个接入的应用都要重复相关配置
4. 框架选型被完全限制了，因为要最简单的上手微服务，只能被迫选择spring cloud

带着上述这些问题，在18年的时候不少社区论坛出现了Service Mesh 网格服务的话题讨论，Service Mesh作为下一代微服务技术的代名词，初出茅庐却深得人心一鸣惊人，大有一统微服务时代的趋势。

Service Mesh 网格服务首先改变的是服务间的通信方式

•        传统Spring cloud微服务之间的通信方式如下图：

为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等，这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统

• Service Mesh 通信交互方式如下图：

粗看貌似并不是网格状，但是当你的服务达到一定数量之后就会变成这样了

Service Mesh会接管整个网络，在服务之间转发所有的请求。在这种情况下，业务服务不再负责处理请求的具体逻辑，只负责完成业务处理。服务间通讯的环节就从服务里面剥离出来，呈现出一个抽象的基础设施层。对应的服务间通讯相关的治理功能，如流量路由（根据权重或参数分流、负载均衡、黑白名单）、流量治理（熔断、限流、容错）、请求认证鉴权、调用拓扑等均在下沉的Service Mesh层实现，微服务研发者专注于业务研发本身即可

 

Service mesh 对比 Spring Cloud 的优势在哪里呢？

• 微服务基础设施下沉 —— 微服务架构支撑、网络通信、治理等相关能力下沉到基础设施层，业务部门无需投入专人开发与维护，可以有效降低微服务架构下研发与维护成本；
• 降低升级成本 —— Sidecar支持热升级，降低中间件和技术框架客户端、SDK升级成本；
• 语言无关 —— 提供多语言服务治理能力；
• 降低复杂测试、演练成本 —— 降低全链路压测、故障演练成本和业务侵入性。

从功能上讲，以Google、IBM主推的Istio框架为例，其对Service Mesh核心功能表述如下所示：

• 连接 —— 智能控制服务之间的流量和API调用，进行一系列测试，并通过红/黑部署逐步升级。
• 保护 —— 通过托管身份验证、授权和服务之间通信加密自动保护服务。
• 控制 —— 应用策略并确保其执行使得资源在消费者之间公平分配。
• 观测 —— 通过丰富的自动追踪、监控和记录所有服务，了解正在发生的情况。

 

Service mesh 缺点是什么呢？

• 最好使用在云环境中，一个SideCar 对应一个应用，这样排除的单点问题，如果在VM环境中使用，一个SideCar 对应多个应用部署，那么就会出现单点问题
• 没有跨语言需求或者应用不是也别多的公司没必要去Spring Cloud转型Service Mesh
• 性能损失，因为网络通过一层SideCar 转发必然会有性能损失，早起版本性能损失严重达到40%左右，现在新版本性能损失估计在10%
• 架构复杂，相较于Cloud体系整体架构复杂很多，需要有一个很强的运维团队支撑

 

Envoy+Istio（网格服务基础支持）

• Istio由Google，IBM和Lyft联合开发，Go语言实现。2017年5月24日0.1 release发布，目前已经有1.3.x release版本发布。其与Kubernetes一脉相承，提供了完整的Service Mesh解决方案。核心组件包括数据面Envoy（https://www.envoyproxy.io/，CNCF第三个毕业项目，云原生数据面事实标准组件，具备高性能和丰富的数据面功能） ，控制面Pilot、Mixer、Citadel、Galley等。
• 数据面以Envoy Proxy作为代理组件。通过Outbound流量拦截或显示指向Envoy Proxy地址的方式代理发起请求流量，经过Envoy Proxy的服务发现、负载均衡、路由等数据面逻辑后，选择目标服务实例地址进行流量转发；在Inbound流量接收端进行流量拦截（可配置是否拦截），对Inbound流量进行处理后转发至目标服务实例。
• 控制面以Pilot为核心组件。通过建立与Envoy Proxy双向GRPC连接，实现服务注册信息、服务治理策略的实时下发与同步。其他控制面组件Mixer（策略检查、监控、日志审计等）、Citadel（认证与授权）、Galley（配置检查）可在实际场景中配置关闭。
• 平台开放与扩展主要通过Kubernetes CRD与Mesh Configuration Protocol（简称为MCP，一套标准GRPC协议）。平台默认支持Kubernetes基于ETCD的注册中心机制，可通过MCP机制对接更多诸如Consul、Eureka、ZooKeeper等多注册中心；对服务治理策略的配置可通过定义Kubernetes CRD或实现MCP GRPC服务对接实现。
• 高可用设计主要基于Kubernetes及Istio机制实现。数据面Envoy Proxy以Init-Container方式与业务Container同时启动，Istio提供了Pilot-agent组件实现对Envoy Proxy生命周期、升级的支持，保证Envoy Proxy的高可用。控制面所有Istio组件均由Kubernetes多副本探针机制保证高可用性。

 

容器化与Service Mesh

在基于Envoy+Istio方案中，容器化是Service Mesh高效落地的基础。容器化+Kubernetes编排不仅为微服务本身带来灵活部署调度、扩缩容、高可用等诸多能力，对Service Mesh架构下Sidecar注入、生命周期管理、流量拦截、安全管理等也提供了十分重要的特性。简而言之，容器化与Service Mesh具备天生的亲和性。

Service Mesh架构本身并未限定业务微服务本身必须容器化，Istio社区也从未将支持非容器这扇“门”堵死（早期的版本Istio仅对Kubernetes进行了支持），轻舟Service Mesh方案中也提供了对非容器的支持。但从微服务业务长期规划、Service Mesh核心价值最大化、压缩迁移成本等方面考虑，容器化+Service Mesh一定是微服务业务演进的重要方向。集团内严选、传媒均已选择了上云+容器化+Service Mesh同步进行的演进规划，轻舟团队也为这两大业务提供了演进接入Service Mesh方案。

 

Service Mesh 亮点功能

• 灰度引流

在业务完成容器化+Service Mesh改造与迁移后，已经可以在容器化服务范围内互相发现、调用、治理策略分发与生效了。但对于大部分线上环境在跑的微服务业务而言，需要逐步将原有流量灰度引流到Service Mesh体系内服务。以轻舟团队为严选提供的云内/云外互访方案为例，如下图所示：

• 熔断
• 链路跟踪
• 快速A/B测试