ServiceMesh企业应用分析

服务网格+云原生的核心价值

从业务开发团队，运维团队，基础设施团队的接耦，接耦后提高了各团队的工作效率和质量。

耦合情况举例：

1. 业务团队内部耦合：

   • 对于巨大的单体应用，业务团队内部不同的人和子团队之间在开发和部署上存在相互依赖。通过微服务化，接耦。

2. 业务团队和运维团队的耦合:

   • 业务扩容，需由运维团队提供数据，业务团队设计方案（每个服务扩容多少，数据层怎么扩容，缓存层）。扩容的方案，
     要借助服务发现机制或修改配置文件，由运维团队执行。
   • 服务治理相关的内容，因为属于服务化SDK的配置，SDK配置每个语言都不同，通常需要由业务团队给出方案，运维团队部署执行。
   • 灰度方案，同上，业务团队设计灰度方案，运维团队检验并执行。然后再由业务团队验证。
   • 故障注入，需要业务团队在代码级别注入故障，在演练结束后还需要再撤销。由运维团队注入的故障，往往只有kill 服务进程等非常简单。而且需要搭建额外的测试环境，
     很难利用线上环境使用灰度的方式演练。

   最理想的情况是：业务团队只用专心在业务上，而所有其他工作可由运维团队和基础设施团队地理完成。

3. 业务团队和基础设施团队的耦合：

   • 基础设施团队为服务化SDK添加了新的功能，一个是需要对所有的语言的SDK添加并测试，第2个需要和业务代码一起上线。需要研发上线的窗口和所有语言的业务应用对齐。效率低下。
   • 对监控，策略执行的新的功能的添加，或者对接，更换新的后端应用，也有同上问题。
   • 基础设施团队，希望通过对应用和中间件之间的流量进行治理，缺乏通用工具。要依赖和业务团队合作，分别在中间件和应用SDK上做修改，并部署上线。

4. 基础设施团队和运维团队的耦合：

   • 基础设施中间件的性能通常需要随着业务性能扩展而扩展，因此和业务团队一样，需要更加接耦的伸缩机制。
   • 对中间件和应用之间的流量进行治理，即使基础能力在，需要由基础设施团队设计配置变更（缺乏通用配置），运维团队执行。

5. 3个团队的耦合：

   • 对于异常检测，需要由基础设施团队，业务团队设计相应的预案，运维团队执行相应的动作。
   • 对于上线新的指标的监控，需要业务人员开发或至少测试新的探针，基础设施团队对监控中间件修改相应的配置，运维团队执行变更。
   • 对于安全，需要业务团队设计验证安全方案，基础设施团队检验相关的安全设计，提供相应的安全中间件（证书管理），运维团队要负责网络层面的安全，并实际部署。
   • 对于流控等实时策略，需要业务人员完成业务端的开发或验证，基础设施团队提供相应的中间件功能。（redis的桶等），运维人员要实际部署，并做检验。

企业微服务化架构的演变

1. 微服务+VM时代
   • 业务团队内部的接耦。极大的提高新业务开发和发布的效率。
2. 微服务+云原生时代
   • 通过容器化技术让应用和运行平台接耦，K8S又为运维团队提供了强大的资源编排工具。实现了业务团队+基础设施团队和运维团队的解耦。极大的提高了运维和业务发布的效率，提升了业务伸缩性，可用性和发布的安全性。
3. 微服务+云原生+ServiceMesh时代
   • 在2的基础上，把服务治理，策略，监控，安全等能力基础设施化，实现了业务团队与基础设施团队的解耦。极大的提高了基础设施团队的工作效率。而基础设施能力的提升，又会极大的促进整个公司业务能力的提升。

在企业已经部分应用微服务+云原生的条件下，ServiceMesh应对的痛点场景

Istio-主流ServiceMesh方案

主要优势:

1. 生态兼容性好，很容易和其他（如监控，分布式跟踪，策略）开源产品一起组成完整的企业后端解决方案方案。
2. 由IBM, google发起，项目架构优异，可扩展性好。功能强大。
3. 社区活跃度最高，github 2018年贡献者发展最快的top 5项目。
4. 和容器化编排的事实标准K8S深度融合，复用大量K8S的概念和基础能力，与K8S的能力整合得最好，在使用K8S的基础上，学习和应用复杂度相对较低。
5. 对应用可实现零侵入。
6. 跨云统一治理能力好。
7. 通过ServiceEntry来实现云原生内外互通，和部分统一治理能力。

Istio的能力和架构概述

功能概述：

1. 流量治理：包括服务发现，负载均衡，路由控制，限流，熔断，容错，故障注入，灰度发布，流量镜像等。
2. 可观测性：包括监控，日志聚合，计量，分布式跟踪
3. 实时规则（策略）
4. 安全：加密通信，认证，授权。
5. 服务访问接口：南北向通信
6. 跨云融合

可以看到其功能丰富，对与大部分企业来说在功能上能满足。并且能构成企业后端的完整解决方案和统一的技术栈

架构概述：

1. Proxy即为数据面，负责规则的执行。使用功能强大，扩展性好，性能优异的Envoy
2. Mixer复杂把监控信息，和实时规则（策略）信息转发给对应的后端，支持多种不同的后端
3. Citadel负责维护分发安全证书，可实现透明的，可插拔的双向认证TLS通信，保障服务间通信安全。也能执行RBAC。
4. Pilot负责所有的配置的下发。
5. Galley 代理屏蔽不同的运行时实现，和Istio其他组件通信。验效配置。

Istio的现阶段的不足-可发展的潜力

1. 所有的公司现有的非ServiceMesh的服务基础设施，因其做为业务的底座，和业务高度绑定，更新的成本很大。考虑到业务的连续性和稳定性，也几乎不可能将其同时的迁移至Istio,所以需要更高效的模型，工具，帮助客户实现第1代SDK微服务，和第2代Service Mesh微服务Istio的互通调用和统一治理。
2. 可以考虑把SDK变成独立进程并下沉至基础设施这一想法继续深化，不限于服务治理，监控的范畴，比如把Envoy扩展为包含对分布式redis访问的SDK，这样当需要升级redis的SDK实现时，业务代码不用变化，同时也让分布式redis的水平伸缩变得更加容易。同样的考虑也适用MQ，数据库。从另一个观点来看，就是让Envoy支持更多特殊协议。
3. 安全模块的功能，架构还在高速变化，还未到达生产可用。
4. 因Istio重架构，暂时在性能优化方面分配较少精力。所以在大规模ServiceMesh场景下会遇到性能瓶颈，主要集中在Mixer和Pilot, 可以做进一步优化。

初步设计方案A:

1. 注册中心ServiceCenter要添加服务治理的配置储存功能
2. ServiceCenter要支持MCP协议
3. 改造Java-chassis支持xDS协议
4. 改造Mesher支持xDS协议
5. 控制面Pilot改造，提高其性能，后期可以考虑添加服务注册透传功能
6. Sidecar可以发展Mesher,也可以folk envoy，为其添加ServiceCenter服务注册能力。
7. Mixer复用Istio的。对于非云原生业务，要另外实现相关功能。

初步设计方案B:

1. Edge-Sidecar既是所有跨云和非云的流量的代理，也是作为非云原生应用的边车的集群，要能部署多个实例，能执行xDs协议，实现和Istio的更多功能的统一治理。
2. 扩展Scb已有组件Syncer实现和Istio的服务同步，和互相发现。
3. ServiceCenter作为所有非云原生的注册中心。
4. 对于所有的SDK微服务（包括Spring cloud，Dubbo)的存量应用，通过让其支持ServiceCenter来实现与Istio的融合。
5. 对于没有SDK的服务，可以通过Mesher实现无侵入接入Mesh。