左耳听风_056_55_管理设计篇之服务网格
你好，我是陈浩网名左耳朵house.那今天这节课呢我们来谈一谈服务网格。
在前面呢我们讨论了赛decar编车模式啊，这是一个非常不错的分布式架构的设计模式。
因为这个模式啊可以有效的分离系统控制和业务逻辑，并且呢可以让整个系统架构在控制面上可以集中管理，可以显著的提高分布式系统的整体控制和管理效率。
并且呢可以让业务开发更为快速。
那么呢我们不妨在上面这个模式下分个b位一下。
假如呢我们在一个分布式系统中已经把一些标准的sid car给部署好了。
比如前面说的熔断啊、限流啊，还有城市密等路由，还有监视等这些东西。
我们呢在每个计算节点上都部署好了这些东西。
那么真实的业务服务呢，只需要往这个集群中一放啊，就可以和本地的sidecar去通信。
然后呢由side car去委托代理与其他系统的交互和控制。
那这样一来呢，我们的业务开发和运维岂不是非常简单了呢？是啊试想一下，如果某一个云服务的提供商提供了一个带着前面我们说过的那些各式各样的分布式设计模式的sidecard集群。
那么我们的用户呢啊真的就只用写业务逻辑相关的service了。
写好一个呢就往这个集群中部署，那开发和运维的工作量都会得到巨大的降低和减少。
那这个呢就是CNCF啊，也就是云原生计算基金会目前在主力推动的新一代微服务架构叫service mesh服务网格。
我在文中呢放了一篇文章的链接，它解释了什么是service mesh啊，你有兴趣呢可以打开看一看service mesh这个服务网格啊，专注于处理服务和服务间的通讯。
它呢主要负责构造一个稳定可靠的服务通讯的基础设施，并让整个架构呢更为先进和cloud native.那在工程中呢，service match基本上来说啊，就是一组轻量级的服务代理和应用逻辑的服务在一起，并且呢对应用服务是透明的那说白了就是这么几个特点。
那第一呢service mesh是一个基础设施。
那第二呢它是一个轻量的服务通讯的网络代理。
那第三呢，它对应用服务来说啊是透明无侵入的那第四呢它是用于解耦和分离分布式系统架构中控制层面上的东西。
那说起来呢sarce matsh啊，就像是网络七层模型中的第四层TCP协议。
他把底层的那些非常难以控制的网络通信方面的控制面上的东西啊都管了。
而更为上面的应用层的协议呢，只需要关心自己业务应用层上的事儿了啊，比如HTP的HTML协议。
在parattern service match这篇文章里呢，也详细解释了service match的出现并不是一个偶然，而是一个必然。
那其中的演化路径呢是这样的那一开始呢是最原始的两台主机件的进程直接通信。
然后呢我分离出网络层来服务线的远程通信呢，通过底层的网络模型来完成。
那再后来呢，因为两边的服务在接收的速度上不一致，所以呢就需要在应用层中啊执行流控。
后来呢我发现流控模块基本上也可以交给网络层来实现。
于是呢TCPIP就成了世界上最成功的网络协议。
那再往后面呢，我们知道了分布式系统中的八个谬论，意识到我们需要在分布式系统中啊需要有弹力设计。
于是呢我们在更上层中啊加入了像限流、熔断，还有服务，发现还有监控等等功能。
然后呢，我们发现这些弹力设计的模式呢都是可以标准化的，将这些模式写成SDK、 lib和framework.那这样呢就可以在开发层面上很容易的集成到我们的应用服务中。
那接下来呢我们又发现SDK the framework不能跨编程语言，有什么改动之后呢，需要重新编译重新发布服务啊，太不方便了，应该有一个专门的层啊来干这个事儿。
于是呢就出现了sid car.那再然后呢sidecard集群啊就成了service match.你来看文中，我展示的这幅图图中的绿色模块呢是真实的业务应用服务。
那蓝色模块呢就是sid卡，它组成了一个网格，而我们的应用服务啊完全独立自包含，只需要和本机的sidecard去依赖。
那剩下的事啊就全交给set car了。
于是呢sidecar就组成了一个平台，一个clounative的服务，流量调度的平台。
你是否还记得我在分布式系统的本质？那一系列文章中所说的关键技术中的流量调度和应用监控，那他们呢都可以通过service mansh这个平台来完成。
那加上对整个集群的管理，控制面板呢，就成了我们整个的service match架构。
那这里呢我在文中啊引用了几幅partion service mash篇文章里的图片，希望你能打开文章看一看，方便你理解。
那目前比较流行的service mansh开源软件呢是istto和lincold,那它们呢都可以在corpornetice中集成。
那当然呢还有一个新成员conduate,它是由林克尔的作者出来，自己搞的，由rust和go写成的rust负责数据层面，go呢负责控制面。
他号称吸取了很多linkor的scale的教训，比的更快、更轻，还更简单。
我自己呢虽然不是语言的偏好者，但是呢不可否认rust和go在性能方面呢比scala要好的多得多，尤其是呢是要做成一个和网络通讯相关的基础设施，那性能是比较重要的。
对此呢我还是推荐啊大家使用rust和go语言实现的e ste和conduate.那后者呢比前者要轻的多，你可以根据你的具体需求来挑选，或者呢自己实现。
嗯，e steq呢是目前最主流的解决方案，它的架构啊并不复杂。
它的核心sidecar呢叫做mmory,用来协调服务网格中所有服务的出入站流量，并提供服务，发现负载均衡还有限流、熔断等能力，还可以收集大量的与流量相关的性能指标。
在service match控制面上呢，有一个叫mixer的收集器，用来从arvy中收集相关的被监控到的流量特征和性能指标。
然后呢通过拍到t控制器，将相关的规则发送到area中，让area啊应用新的规则。
那最后呢还有一个为安全设计的STUO ss身份认证组件，用来做服务间的访问安全控制。
我在文中呢给你展示了整个SQ的架构图。
那最后呢我们来谈一谈service matsh的设计重点。
那service mesh作为sed car的一个集群应用呢，sid car所需要的微观层面上的那些设计要点，我在这里呢就不再复述了，欢迎大家看我之前的文章。
那在这里呢我更多的说一下service mesh在整体架构上的一些设计要点。
我们知道像cooper onnetice和docker是分布式系统管理面上的技术解决方案，他们一样对应用程序来说是透明的。
最重要的是啊cuper nettice和docker对于应用服务的干扰是比较少的。
也就是说呢，cuper natives和docker的服务进程的失败，它不会导致应用服务的异常运行。
但是呢service matsh却不是这样，因为它调度了流量。
所以呢如果service matsh有bug,或者呢set card组件不可用，就会导致整个架构啊出现致命的问题。
所以呢在设计service match的时候，我们需要小心的考虑。
如果service matsh所管理的side car出了问题，那应该怎么办呢？所以呢service match这个网格啊一定需要是高可靠的，或者是出现了故障之后会有work wrong的方式。
那一种比较好的方式呢，就是除了在本机有赛d car,我们还可以部署一下稍微集中一点的set car.比如为某个服务集群啊，部署一个集中式的set car.那一旦本机的有问题呢，就可以走集中的那这样一来呢，sidecar本来就是用来调度流量的，而且它的力度呢既可以细到每个服务的实力，也可以粗到一组服务，还可以促到整体接入。
那这个看来看去啊都像是一个gateway的事儿，所以呢我相信使用gateway来干这个事儿应该是最合适不过的了。
那这样呢我们的service matsh的想象空间啊一下子就大多了。
Service match它不不siset car需要和service一起打包一起部署，service mesh呢可以完全独立部署。
那这样一来呢，service mesh啊就成了一个基础设施，就像一个pass平台。
所以呢serarce ash能不和和verrentice密切结合，就成为了非常关键的因素。
好了，我们来总结一下今天分享的主要内容。
首先呢冰车模式进化的下一个阶段，就是它的功能标准化成一个集群。
那结果呢就是服务网格。
它在分布式系统中的地位呢，类似于七层网络模型中的传输层协议。
而服务本身呢它只需要关心业务逻辑。
因此呢类似于应用层协议，然后呢我介绍了几个实现了服务网格的开源软件。
在最后呢我介绍了服务网格的几个设计重点。
在下节课呢我们会讲述网关模式，希望能对你有帮助，也欢迎你来分享一下你接触到的分布式系统有没有用到服务网格呢？具体啊用的是哪个开源呢？或者闭源的框架呢？我在文末呢给出了分布式系统模式系列文章的目录，希望你能在这个列表里啊找到自己感兴趣的内容。