#### mesh服务网格 及Istio框架 ####

转自 https://www.infoq.cn/article/YTdb55y6P1b9gVp0w0wx

仅做个人备份，浏览请看原文

基于 SDK/服务框架的微服务治理体系

从传统单体应用到微服务架构转变去落地时，基于 SDK 和服务框架这种微服务治理体系，这种传统的服务治理能力完全是由 SDK 以及服务框架来实现的。这其中，包含了很多服务治理、服务发现、服务路由、服务重试、熔断限流等微服务相关的一些能力。业务程序重度依赖 SDK 及其服务框架，并和语言、业务绑定在一起。

基于这样一个服务框架的服务治理体系，在由传统的单体到微服务的转变之后，将面临着很多种挑战：

具体来说，在语言绑定层面，传统的微服务治理体系可能要跟具体的语言绑定，因为它跟具体的业务逻辑是要绑定在一起的。

从整体来看，在多语言层面很难做到一个统一的技术，因为语言本身有各自的特性，还有各个语言的能力，都有不太一样的情况。

此外，采用传统的 SDK，在向前去演进的时候，很难去推动业务去做升级，SDK 和业务严重绑定了，这样会造成演进困难。

基于透明代理的服务治理体系

基于这些问题，我们将非业务逻辑相关的微服务治理，放在另外一个透明代理，即一个轻量级的网格代理，我们称它为 sidecar。在 sidecar 层面，我们做了很多的服务发现、负载均衡、服务路由等等。

这样服务的概念更加纯粹，不同的服务和微服务进来，只需要关心自己的业务逻辑实现就可以了，完全把这种非业务的实现逻辑，放在 sidecar 层面去做。

这种典型场景具备四个特点：它本身和业务无关，真正做到了从业务中剥离出来；由于它和业务在两个独立的进程里，所以不存在语言绑定的情况；它和业务逻辑没有强烈的耦合，独立演进，包括独立的升级和维护；透明升级的，就是我们基于 sidecar 这样一个能力的升级是不再依托于业务的升级，因为本身没有绑定，这是我们基于透明代理的服务治理体系。

Istio 架构

这种基于透明代理的服务治理体系，可以简单称它为服务网格。我们先看一下其典型代表 Istio，Istio 是一个在服务网格领域深受大家喜爱，也深受开发者追捧的框架架构。

我们来看一下它的典型架构。

Service A 和 Service B 是我们的两个业务应用，Envoy Proxy 就是一个透明代理，它本身对业务是透明的。我们可以看到，有一个控制平面 Istio control plane，控制平面可以简单理解为，它会向着我们所有的 sidecar 去推送整体的一些配置、数据等等。通过这样一个典型的 Istio 架构，来引出我们这个服务网格的概念。

从整体视角上来看，所有的 sidecar 都是在一个网状结构里进行透明的流量转发和治理，组成了一个扁平的网状，这种由透明代理组成的一个网状结构，我们可以称它为服务网格，服务网格本身是基于透明代理去实现的。