kubernetes实践之六十五：Service Mesh

一：什么是Service Mesh

1.可以将Service Mesh比作是程序或者微服务间的TCP/IP，负责服务之间的网络调用，限流，熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

2.Service Mesh有如下几个特点：
a. 应用程序间通信的中间层
b.轻量级的网络代理
c.应用程序无感知
d.解耦应用程序的重试，超时，监控，追踪和服务发现

3.Service Mesh的架构

Service mesh 作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 serivce mesh 中实现。

二：为何使用 Service Mesh

1.Service mesh 并没有给我们带来新功能，它是用于解决其他工具已经解决过的问题，只不过这次是在 Cloud Native 的 kubernetes 环境下的实现。

2.在传统的 MVC 三层 Web 应用程序架构下，服务之间的通讯并不复杂，在应用程序内部自己管理即可，但是在现今的复杂的大型网站情况下，单体应用被分解为众多的微服务，服务之间的依赖和通讯十分复杂。

3.在 Cloud Native 架构下，容器的使用给予了异构应用程序的更多可行性，kubernetes 增强的应用的横向扩容能力，用户可以快速的编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发，赋予开发者更多的创造性。

三： Service Mesh如何工作

 Linkerd 为例讲解 service mesh 如何工作：

1.Linkerd 将服务请求路由到目的地址，根据其中的参数判断是到生产环境还是测试环境，是路由到本地环境还是公有云环境？所有的这些路由信息可以动态配置，可以是全局配置也可以为某些服务单独配置。

2.当 Linkerd 确认了目的地址后，将流量发送到相应服务发现端点(在 kubernetes 中是 service)，然后 service 会将服务转发给后端的实例(Pod)。

3.Linkerd 根据它观测到最近请求的延迟时间，选择出所有应用程序的实例中响应最快的实例。

4.Linkerd 将请求发送给该实例，同时记录响应类型和延迟数据。

5.如果该实例挂了、不响应了或者进程不工作了，Linkerd 将把请求发送到其他实例上重试。

6.如果该实例持续返回 error，Linkerd 会将该实例从负载均衡池中移除，稍后再周期性得重试。

7.如果请求的截止时间已过，Linkerd 主动失败该请求，而不是再次尝试添加负载。

8.Linkerd 以 metric 和分布式追踪的形式捕获上述行为的各个方面，这些追踪信息将发送到集中 metric 系统。

四：Istio 与 Linkerd

当前的Service Mesh实现主要有两大阵营，Linkerd和Istio。

Feature	Istio	Linkerd
部署架构	Envoy/Sidecar	DaemonSets
易用性	复杂	简单
支持平台	kuberentes	kubernetes/mesos/Istio/local
当前版本	0.3.0	1.3.3
是否已有生产部署	否	是

下图是Istio和Linkerd架构的不同，Istio是使用Sidecar模式，将Envoy植入到Pod中，而Linkerd则是在每台node上都以DaemonSet的方式运行。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28624388/viewspace-2156654/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28624388/viewspace-2156654/