一文了解“Service Mesh（服务网格）”的历史与如今

对于大多数人来讲，“Service Mesh（服务网格）”仍然是一个新概念，所以，谈论它的“历史”可能看起来有点滑稽。但事实上，早在2010年初，在一些大网络规模的公司中，服务网格的概念就隐约开始逐步造成了。所以，服务网格确实有一段历史值得去探索、去理解。

在深刻历史脉络以前，让咱们先聊聊“如今”。什么是服务网格？为何它忽然成为了云原生领域的热门话题？

服务网格是用于控制和监视微服务应用程序中的内部服务到服务流量的软件基础结构层。它一般采用与应用程序代码一块儿部署的网络代理的“数据平面”的形式，以及用于与这些代理交互的“控制平面”。在这个模型中，开发人员（“服务全部者”）能够很是幸福地彻底意识不到服务网格的存在，而运营商（“平台工程师”）则被授予一套新的工具来确保可靠性、安全性和可见性。

服务网格为何会忽然流行？简而言之，是由于对于许多公司来讲，像Docker和Kubernetes这样的工具已经“解决了部署的问题”——至少是差很少解决了。但Docker和Kubernetes没能解决运行时的问题。而这就是服务网格的用武之地。

“解决部署问题”是什么意思？使用Docker和Kubernetes之类的技术能够为企业大大减小部署大量应用或服务时的操做负担。使用Docker和Kubernetes，部署100个应用程序或服务的工做量，再也不是部署单个应用程序的100倍。这是历史性的向前迈出的一大步，对于许多公司来讲，它能够极大下降采用微服务的成本。这可能不只仅是由于Docker和Kubernetes在全部正确的级别提供了强大的抽象，更是由于它们标准化了整个组织的打包和部署模式。

可是，一旦应用程序运行以后呢？毕竟，部署不是生产的最后一步; 部署完以后，应用程序还必须运行。如此一来问题就变成了：像使用Docker和Kubernete进行标准化部署时同样，咱们还能以一样的方式来将应用程序的运行时操做也标准化吗？

为了解决这个问题，服务网格应运而生。从本质上讲，服务网络提供统一的全局方式来控制和测量应用程序或服务之间的全部请求流量（在数据中心的说法中，即“东西向”流量）。对于采用微服务的公司而言，此请求流量在运行时行为中起着相当重要的做用。因为服务经过响应传入请求和发出传出请求来工做，所以请求流成为应用程序在运行时的行为方式的关键决定因素。所以，将流量管理标准化，则成为将应用程序运行时标准化的工具。

经过提供API来分析和操做此流量，服务网络为整个组织的运行时操做提供了标准化机制——包括确保可靠性、安全性和可见性的方法。和任何优秀的基础设施层同样，服务网格（在理想状况下）的工做方式与服务的构建方式无关。

服务网格是如何造成的？

那么服务网格从何而来？作了一些软件考古以后，咱们发现服务网格提供的核心功能——请求级负载均衡、断路、重试、仪器等——基本上并非新功能。其实，服务网格最终是功能的从新包装，真正发生转变的是“地方”，而不是“什么”。

服务网格的起源始于大约2010年三层应用程序架构模型的兴起——这是一种简单的架构，一度为网络上的绝大多数应用程序提供动力。在这个模型中，请求流量发挥着重要做用（有两个跃点！）。应用程序流量首先由“Web层”处理，“web层”又与“app层”对话，后者又与“数据库层”对话。Web层中的Web服务器旨在处理大量传入请求，须要很是迅速地将它们当心地交给相对较慢的应用服务器。（Apache、NGINX和其余流行的Web服务器都有很是复杂的逻辑来处理这种状况。）一样，应用层使用数据库库与后备存储进行通讯。这些库一般负责以针对此用例优化的方式处理缓存、负载均衡、路由、流控制。

可是，这种三层应用程序架构模型，在过载的状况下会开始崩溃——特别是在app层，随着时间的推移它的负载会变得很是大。像谷歌、Facebook、Netflix、Twitter这样的大公司学会了将单体架构拆分红许多独立运行的块，从而催生了微服务的兴起。在引入微服务的那一刻，还引入了东西向流量。在这个世界上，通讯再也不是专注的，而是在每一项服务之间。通讯若出错，整个网站都会出现故障。

所以，这些公司都以相似的方式作出了回应：他们编写了“胖客户端”库来处理请求流量。这些库——例如谷歌的Stubby、Netflix的Hysterix、Twitter的Finagle——为全部服务提供了统一的运行时操做方式。开发人员或服务全部者使用这些库向其余服务发出请求，而在这个框架下，这些库将负责负载均衡、路由、断路、遥测。经过在应用程序中的每一个服务之间提供统一的行为、可见性和控制点，这些库造成了表面上最初的服务网格——没有花哨的名称。

Proxy的兴起

快进到现代的云原生世界。固然，这些库仍然存在。可是，鉴于进程外代理提供的操做便利性，库的吸引力显著下降了——尤为是当容器和编排框架的出现使得部署复杂性大幅降低时。

代理避免了库的许多缺点。例如，当一个库发生变化时，必须在每一个服务中部署这些变化，这个过程每每须要复杂的组织层面的协调工做。相比之下，代理能够在不从新编译和从新部署每一个应用程序的状况下进行升级。一样，代理支持多语言系统，在多语言系统中由服务组成的应用程序是用不一样语言编写的——而这种方法对于库而言过于昂贵。

也许最重要的是，对于大型组织而言，在代理而不是库中实现服务网络，会将提供必要功能的责任，从服务全部者手上，转移到最终使用该服务的终端用户（即平台工程团队）手上。服务提供者和使用者的这种一致性，将会让这些团队把握本身的命运，消除开发和运维之间复杂的依赖关系。

这些因素都有助于服务网格的兴起。经过部署代理的分布式“网格”（它能够做为底层基础架构的一部分而不是应用程序自己来进行维护），并经过提供集中式API来分析和操做此流量，服务网格为跨越整个组织的运行时操做提供了标准化机制，包括确保可靠性、安全性和可见性的方法。

企业级服务网格应用

Service Mesh极大地简化了用户体验，并将大中型企业的Kubernetes落地引领进下一个全新阶段，被业界广泛认为是新一代的微服务架构的最佳技术设计。日前，国内外企业及技术领域对Service Mesh技术的应用和探索开展的如火如荼，对大多数使用容器的企业而言，Service Mesh仿佛是容器部署中亟待补齐的最后一块拼图。

由CNCF举办的KubeCon + CloudNativeCon，做为世界范围的Kubernetes与容器技术领域的顶级技术盛会，将于今年11月14日-15日登录上海，这是KubeCon首次来华举办。Rancher Labs携手华为，将于11月13日和CNCF联合举办KubeCon同场会议，同中国区众多企业客户一块儿，推出2018云原生服务网格（Istio）企业峰会。

届时，来自华为、上汽集团、Rancher Labs、云宏、兴业银行、飞贷金融、金风科技、树维信息等著名企业的科技负责人和微服务架构师，将分享各自在新一代微服务架构建设和Service Mesh应用方面的经验和心得。

日期：11月13日，星期二

时间：上午9:00至下午6:00

地点：上海新发展亚太JW万豪酒店，长风大宴会厅

报名：http://t.cn/RFG85AW 大会详情+在线注册

诚邀您届时莅临峰会，共话容器、微服务、Kubernetes等新技术的落地应用。

英文原文连接：

https://thenewstack.io/history-service-mesh/