Service Mesh的演进过程

微服务

在过去的几年里，微服务一直是题。在微服务之前，项目大多是单机运行的。项目中有很多业务逻辑，导致项目臃肿，可扩展性低，让程序员头疼。微服务的出现大大提高了项目的可扩展性、可升级性、易维护性、资源隔离性等，大大提高了产品的研发效率。同时，使产品的持续集成和发布更加方便。

容器技术

微服务也带来了一些严重的问题，比如产品业务逻辑比较复杂，挑战了运维管理上千个应用。对于这些问题，容器技术逐渐演变，比如目前最流行的docker等等。我们可以单独为微服务创建容器，并以容器的形式部署。它不仅可以实现物理机器上的资源隔离，而且比启动虚拟机更快、更低。

容器编排

如何管理多个容器，提高容器的可用性，自动生成容器、扩容、缩容、负载平衡等诸多问题，kurbernets提出了解决方案。kurbernetes它是目前最流行的容器布置工具，可以实现容器的自动创建、扩容、缩容、负载平衡、服务发现、跨主机调度，可以大大提高运维效率，缩短问题处理时间，改变基础设施模式。

Service Mesh

容器布置工具(kubernetes)它主要倾向于容器管理和调度问题，对指标收集、分布式链路跟踪、熔断、流量迁移、限速和日志收集没有很好的解决方案。针对这些问题，Netflix公司推出了一系列工具，如ribbon、feign、zuul、hystrix、trace等等，形成spring cloud生态。但这些工具并不能解决多语言问题，这些工具只针对java。同时，多语言也给中间件带来了挑战。中间件不仅需要多种语言SDK，而且中间件的升级也有很多困难。能给出一个无关语言的中间件解决方案吗？Service Mesh它可以解决类似的问题，目前很流行service mesh解决方案主要是Envoy和Linkerd。他们能做到sidecar运行在每个pod形成抽象的应用网络。所有业务应用程序的流量通过service mesh流动网格。以下功能可以通过流量劫持实现，业务应用和中间件可以真正解耦，中间件可以快速升级，语言无关。例如Envoy它可以提供许多方便的功能：

Istio

Istio和Envoy区别在于，Envoy数据平面只实现，Istio基于Envoy实现数据平面，增加控制平面，丰富功能，控制一切sidecar，控制所有流量，为开发人员带来集中的控制体验，支持插件自定义配置。

Service Mesh缺点

从上面我们可以看到service mesh它能带来很多便利，但也能带来一些值得关注的问题。

Service Mesh缺点

2. 运维复杂度增加。操作人员必须熟练掌握Docker、Kurbernetes、Envoy、Isito等相关知识。

3. 缺乏可靠的生产实践经验，目前应用公司不多。在中国广泛使用Dubbo协议支持不够。对于这个问题，Dubbo团队也在努力适应Service Mesh，在可预计的dubbo3.初步支持0版本Service Mesh。

Istio架构

从上图看，Istio由Proxy、Mixer、Pilot、Galley、Citadel等组件组成。以下是重点讲解Proxy、Mixer、Pilot这三种组件功能。

Proxy组件作为sidecar与应用程序一起部署，可以处理应用程序的访问请求。Proxy由Pilot-agent和Envoy两部分组成。- Pilot-agent启动时会去Pilot-server生成静态资源和动态资源Envoy启动启动所需的静态资源，Envoy同时启动Pod正确的生命周期Envoy管理和监控。其核心功能为从Pilot-server获取动态配置资源，将配置信息转换为Envoy配置规则可以使用。

- Envoy承担流量控制、负载平衡、熔断等一系列重要功能。Istio主要由流量控制Envoy实现。从下图来看，Envoy提供取动态资源提供了一组接口XDS，可分别获得CDS(Cluster Discovery Service)、EDS(Endpoint Discovery Service)、SDS(Service Discovery Service)、RDS(Route Discovery Service)、LDS(Listener Discovery Service)。Envoy可以有多个listener，每个Listener可以有多个Filter组成Chains。Envoy可以有多个listener，每个Listener可以有多个Filter组成Chains。Listener(监听器)可监控下游客户端连接的网络请求Filter匹配，让Filter处理元数据。同时listener可以通过LDS动态获取。Listener filter(监控过滤器)处理符合匹配要求的要求，如监控指标收集、限速等。Http Route Table：HTTP 请求域名等路由规则，Path 符合哪些规则，转发给哪些规则？ Cluster。Health checking：健康检查会和SDS配合使用服务发现。但而，即使使用其他服务发现方法，也需要进行主动健康检查。

Pilot分为Pilot-agent和Pilot-server两部分，Pilot-agent位于数据平面，Pilot-server位于控制平面。Pilot-agent在Proxy有些解释后不会重复。Pilot-server对应图中的Discovery Service,主要功能是Kubernetes的Controller中注册Event事件，对Service、Pod、Endpoint、Node监控信息变更。若这些内容发生变化，Pilot-server将通知所有人Pilot-agent。Pilot-agent会去更新Envoy配置规则。

Istio实施授权策略，并为网格中的服务收集遥测数据提供灵活的模型。Istio提供统一抽象Istio它可以与一组开放式基础设施的后端交互，可以改变层之间的边界，降低系统的复杂性，消除业务代码中的收集逻辑。而Mixer负责提供战略控制和遥测收集Istio组件。如上图所示，Proxy请求转发时，请求Mixer进行Check And Report。Check检查要求是否符合先决条件，Report报告遥测请求。我们可以发现，每个请求都需要调用Mixer，它不仅增加了两请求的耗时，而且受到集中化的限制Mixer，将带来严重的性能问题。官方虽然在Document中描述Envoy sidecar具有本地缓存功能，可在缓存中进行相对较大比例的前提条件检查，但我们仍对该设计持怀疑态度。在SOFA Mesh本文还提到了这方面的性能问题，在下一章中我们将讨论如何改进这一点。

https://istio.io/zh/docs/reference/config/policy-and-telemetry/adapters/。

https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide

通过以上分析，相信大家对Service Mesh和Istio对什么有一定的了解。进一步总结，Service Mesh翻译成中文称为服务网格。进一步总结，Service Mesh翻译成中文称为服务网格。服务网格的含义是将应用网格化，而不是相互调用，而是作为sidecar的proxy互相请求。剥离应用程序之间的网络呼叫、流量限制、熔断和监控，确保要求的可靠传输，使应用程序之间的传输没有感知，使业务应用程序更加关注业务逻辑。相比于Spring Cloud我们不再需要增加生态Euraka作为注册中心，Hystrix作为熔断、Trace作为分布式链路跟踪，Zuul依赖网关等列。Istio将这些功能作为云原生基础设施抽离，使开发更加方便。 Istio是实现Service Mesh解决方案。

1. 执行 kubectl get po -n default,可以获取namespace为default下的pod信息 NAME READY STATUS RESTARTS AGE curl-6bf6db5c4f-rgqzp 1/1 Running 1 25d details-v1-6f4c4dfb85-pzznh 2/2 Running 0 14d hello-build-pod-d3a958 0/1 Completed 0 10d productpage-v1-bb79f5cc5-fn76j 2/2 Running 0 14d ratings-v1-69757fc969-z89wc 2/2 Running 0 14d reviews-v1-6f9c998689-gfc4d 2/2 Running 0 14d reviews-v2-9c869845c-hwvwv 2/2 Running 0 14d reviews-v3-74b8d986c6-l2wx9 2/2 Running 0 14d test-git-branch-pod-3ba297 0/1 Completed 0 10d2. 执行 kubectl describe pod details-v1-6f4c4dfb85-pzznh，获取details详细信息。 Init Containers: istio-init: Container ID: docker://7c8b7773e0eb0cc6e3263328bf480eec2a472775e1da92b58ac645b41df 2a