对服务治理的演进理解

发展的进程

在长期的演变过程中，人们从程序这个概念演变出了服务的概念。我们不需要追求程序的演变，程序的服务化是伴随着程序提供的socket能力开始的。这个socket能力就是连接别人和被别人连接的能力。

连接别人的能力被称作客户端，被别人连接的能力被称为服务端。天然的，服务端的处理能力要求比客户端强很多，稳定性要求也比客户端大很多。后面一切的故事，都是因为性能和稳定性两个方面的要求。还有一个逐渐增大的需要，就是安全性，也就是访问控制。

围绕三个核心点：性能，稳定性，访问控制，服务这个概念开始逐渐的迭代。

listen的程序被叫做服务，是整个浪潮的第一步。这个时代，一个服务器对所有的客户端提供服务。

DNS的出现是这个浪潮的一步奠基性的推动。目标直指稳定性。稳定性为了提供服务的持续可用（SPOF问题），DNS的出现目标明确，但是同时开创了两个影响深远的概念：负载均衡和服务治理。

负载均衡是一种专门用于均衡流量的技术，是一个纯性能领域的服务架构演进方案。一台服务器承担不了对应的性能，多台服务器同时来一起分割承担。

所有的服务器对外暴露统一的IP地址，叫做VIP。可以很清楚的发现就是VIP的出现，让所有的客户端只看到一个IP地址，像最原始的那样通过一个IP:port去使用服务。也就是负载均衡技术的出现，让人们回到原点，重新思考DNS技术出现的必要性。

这个由DNS带出来的概念，进一步侵蚀DNS的地位。从解决的问题角度出发，负载均衡和DNS能解决同样的问题。但是社会层面，IP地址可能不会固定的被一个机构持有，但是DNS可以，其实IP也可以。

但是人们就逐渐的产生了一种观念，DNS是持久的，IP是相对临时的，于是VIP也跟随IP一起，背上了一个临时性的大锅。VIP至今没有作为互联网的服务标称，还有一个重要的原因是域名的可读性。DNS在这场左手与右手的较量中，活下来并且找到自己的活法的法宝竟然是可读性，是一个非技术的因素。

于是诞生自DNS的负载均衡技术逐渐脱离DNS单独的提供负载均衡服务。在并不需要服务命名可读性，而是更需要技术层面的均衡的领域，独霸天下。

但是，整个互联网界，思考优雅管理的永远比技术人员的声音大，基于DNS的可读性概念与服务的概念成功的绑定，在另一条路开始独立演进。

服务的名字就此采用了DNS开创的可读性命名方式。于是，现在当我们说一个服务的时候，说的是他的可读性名字，而不是他的VIP（技术人员表示不服气，anycast+VIP我怕过谁？4个8这个DNS服务挺好的，没毛病！）。服务的命名方式确定了，随着服务数量的增多，人们又开始思考起来。

人们思考出了两个问题，同一个服务被很多人重复搭建，是不是有点浪费了？

于是SaaS的概念诞生了。另外一个问题是，这么多服务，我怎么管？这个问题的回答，就诞生了很多概念：服务治理，服务发现是两个最重要的回答。

此外，围绕服务相关的概念，逐渐产生了服务授权，服务编排，服务容量，服务质量等等。

负载均衡VS服务治理

这些所有的概念合起来，就是我们现代化的系统目标。任何闭门造车的人都是在试图靠一人之力战胜整个社会的成果，痴人说梦。

你要有所突破你起码要先把论文看完吧。你要做系统起码要先把已有的成熟的系统怎么做了解透彻吧。否则？你做的是什么东西？用基础数学工具花一辈子去研究费玛大定理吗？你很努力，但是如果能出成果，互相学习靠群体智慧前进的数学大师们可以反省了。

我们说过，负载均衡与整个服务概念是并行的解决问题的方法。但是随着时间的发展，负载均衡在逐渐吸收服务领域的研究成果，服务领域的发展也逐渐的发现，最后我还是离不开负载均衡。

两者融合的大浪潮势不可挡。但是怎么融合，两者各有观点。

负载均衡认为，现代网络服务，性能和稳定性为王，应当从这个角度出发去覆盖服务的概念。对应的典型产品就是Nginx。

从服务的角度出发，业务第一，早期的时候大家业务非常多，性能问题和稳定性问题够用就可以，服务的周边概念梳理才是最重要的。

这种概念诞生在快速发展急速扩张的大型互联网公司。已经有了很多的业务，急需梳理大量服务的架构关系和管理方式。所以这种公司就一定会从服务的角度出发。但是发展到后面发现性能和稳定性上又出现了问题，于是向纯粹的负载均衡技术求救。

世界上没有更好的案例比中国的几大互联网巨头更适合这个场景了。阿里的Dubbo，腾讯的Tars，新浪的Motan都是这个思路的典型代表。阿里的Dubbo和腾讯的Tars在内部应用了之后，进而开源，试图在整个产业链通过社会力量定义技术方向。

针对这种局面，有两个人不同意，一个是纯粹的负载均衡厂商，一个是什么都没做过的，后来居上的大玩家谷歌。谷歌看到了你们的服务治理体系过于看重服务，直接把数据通道给完全忽略了。也看到了Nginx你们过于重视数据通道，控制通道你们是有重视，但是你们出个Nginx Pro才有控制通道出来卖钱是几个意思？你家的Pro谁买得起？

于是谷歌发怒了，这时候正好有个小公司提出了一个新颖的概念，叫微服务。

谷歌一看，这个微服务是什么鬼？换汤不换药的一些东西，根本没有新东西啊。但是它好像就是我想要的，是一个数据和控制两个层面均衡的一个思路。

整个微服务里面，没有什么新概念，但是有一个很有意思的架构，就是数据通道和控制通道的分离。于是Istio诞生了。

这是业内第一个开源的数据通道和控制通道分离的技术。数据通道可以用Nginx，可以用Linerd，可以用Envoy，你们随意，你Nginx不是控制通道不开源，只有数据通道开源吗？你的数据通道就正好就加入我的体系吧。你Dubbo这些不是控制通道做的很好吗？我就吸收借鉴学习一下（其实到底不向你们学习谷歌自己好像也能把控制相关的事情撸明白，控制这个事情似乎谷歌才是大哥）。

抛开现象看本质，Istio是对目前格局的一个整合产品，概念上并没有新东西，但是架构上是全新。所以Istio的最大价值在于架构，然后就是它兼容并包的大而全的服务思想和数据思想。

我们逐个来看这些所有的数据和服务思想个体的发展路线和技术方案。先来个列表：

负载均衡角度：负载均衡算法，健康检测，RS动态手动添加删除，RS的自动根据响应质量来上下线。然后最关键的就是技术层面怎么服务于业务，也就是如何对外暴露服务，Nginx和Ha等开源版本采用的是配置server，就是在配置文件里面写listen（通过配置文件描述服务）。

服务的CURD都是通过配置文件的重新加载实现的。由于配置文件是描述式的，也就是意味着当前业内的负载均衡产品对服务的定义是一个描述性的服务架构。

描述性强大的地方在于任何情况我都可以万变不离其宗的描述。反正是一次性的描述，对于服务，只需要提供一个完备的描述性服务的解析操作即可。所有的服务变动都是通过重新启动整个解析流程，一切从头开始。所以你看到的现象就是reload。这是开源的Nginx目前给出的服务管理方案。

从服务本身概念的角度出发，这个就很大了。服务授权，服务编排，服务容量，服务质量，服务治理，服务发现这些我们要一个一个说（Nginx说你们搞什么球一个配置文件都进去了）。

先说概念。服务治理：诞生自服务出现的早期，一旦服务多了就会有人开始思考，主要目的是解决开发带来的运维问题。

概念可大可小，大到你可以把所有的服务相关的概念都说成是服务治理的子集。系统架构的一个原则，高内聚，低耦合，这六字真言就是当前服务治理的描述。

整个服务治理过程就是在考虑如何把各个服务之间的关系变成高内聚，低耦合的状态。它解决的服务之间的问题。比如开发了一大堆的服务，a服务通过b服务的一个内部结构访问了b的数据，b通过c的一个内部结构访问了c的数据，依赖或者延展或者成环，最差的情况一个服务崩塌，整体所有业务不可用。

所谓的服务治理最简单的实现就是中台系统之间互相解耦，统一对外接口，禁止直接访问内部数据。核心要解决的问题是服务之间的依赖，描述，申请开通分配访问（其实是服务授权了），级联故障，接口描述与沟通成本的降低。

最后这个点诞生了很多的技术，比如SOAP就是这个思想的放大体现，Restfull也是一种方式，RPC也是一种手段，但是RPC可能承载的概念不仅仅限于此。

服务发现：诞生自DNS。所谓的发现不要太高大上的神话了，根本技术就是负载均衡用的很熟练的技术RS的手动和根据质量的自动动态上下线支持。

大部分情况到这里就可以了，这个概念之所最近特别重要，是因为容器让这个功能显得特别重要。因为容器的伸缩性，就注定了IP:PORT的强烈不固定。那就需要灵活的RS上下线的方式。

至于服务发现概念推崇的注册查询机制，都是建立在没有负载均衡技术的场景之下的服务概念单独演进的场景的。

A服务要与B服务通信，使用的是域名或者VIP（古老的战争），依赖纯粹的负载均衡技术，A根本不需要指导B的RS情况，因为负载均衡本身保证了RS的可用性和灵活性。

Docker不是飘吗？飘的时候利用负载均衡的技术改一下RS的配置不就行了？这就是服务发现的一个实现方式了。非常接地气，非常有效。

另外一个方式以Dubbo和Tars这两个推广的最狠的服务角度出发的实现为例，我一个服务（假设接口是个DNS域名）上线了，客户端怎么知道我上线了呢？我通过Dubbo做服务注册（Dubbo本身就是SOA时代的产物），让docker一上线就把自己的访问地址在Dubbo上注册，这样使用方就能得到通知。“哇，你上线了一个新的RS。但是你有很多个RS呀。那我选哪个？”这就是负载均衡的概念了，但是必须要严肃注意的是，这个负载均衡是客户端的负载均衡，是客户端使用负载均衡算法，选择使用哪一个RS，然后直接由客户端把请求输送到后端的RS。

所以服务的演进，最高境界就是完全在数据通道甩锅，通过SDK来做到客户端负载均衡。

Dubbo专注于广义的服务治理。这样做的好处也是很大的，就是流量不需要经过一个负载均衡节点，少了一个逻辑跳，并且还能实现负载均衡技术所达到的RS上下线和健康检测的目的。

事情似乎很美好。事实上客户端负载均衡说的有些绝对，一个比较流行的做法是在请求之前RPC到Dubbo让Dubbo来做这个负载均衡的决策，然后客户端去直连RS。这些方案都是大同小异的，核心就是不存在数据通道。

上面说的服务发现的两种思路，一种从负载均衡技术栈出发的解决方案，一种从服务治理的角度出发的管理方案。相当于是一个从数据面想办法解决，另外一个从控制面想办法解决。

Istio的Sidecar模型是一个控制面联动数据面的模型。这个模型是Istio区别于这两种方案的最大因素。服务发现这个技术本身并没有什么神圣，两种传统方案都是支持的。业务比较重的时候Dubbo可能好一些（忽略Dubbo的java向，只是举个SOA思想的例子），数据比较重的时候Nginx可能就好一些。Nginx架构是横在用户和自己的服务器之间，Dubbo架构是横在自己的服务器之间，两者架构和目的不同，但是都在悄悄的实现着同样的服务理念。

融合，在所难免。

不过服务发现还有一个很重要的是服务目录和服务查询，Nginx那种配置模式，可以洗洗睡了。想知道现在的VIP后面有哪些RS？你猜。或者你自己在用我之前自己记录一下？不好意思我不提供接口给你查询。喔，我有，收费。你也可以用consul+confd呀，没毛病。只是要reload一下，你忍一忍。

服务授权：这个概念很容易理解，服务授权包含鉴权和授权两部分。

在这个领域Dubbo为代表的服务化思想有自己的一套（然后Dubbo真的有服务授权的实现吗？Dubbo好像压根没怎么理这个）。

既然是服务，就有接口，接口这个概念被逐渐的抽象化，API这个词语不知道什么时候被网络接口窃取，成了接口的同义词。

网络API逐渐的被各个大公司认识到，一系列各种服务对外都要暴露API，这也是低耦合高内聚六字真言的实践方式。

但是API谁可以访问，一天允许你访问几次，怎么识别访问的人是我认可的人，这些问题就是服务授权要解决的。

在这个领域，负载均衡技术栈完胜，因为Nginx产生了Kong，OpenResty产生了Orange（OpenResty也是Nginx的孩子），还有很多API Gateway的实现，例如Zuul。

但是市场份额最大的恐怕就是Nginx系列的API Gateway了。API Gateway的发展势如破竹，因为每个公司内部都有一大堆乱七八糟的API等待管理。从乱七八糟的API到有组织的管理，似乎走API Gateway的方式比走SOA的完全架构重构的方式更友好。

所以API Gateway的思想从服务授权的角度出发，进一步跟传统的SOA进行交融。本来服务授权是一个典型的控制面的事情，应该由Dubbo等平台做好，但是世界发展就是如此巧妙，它阴差阳错的由Nginx做好了。一个很大的原因是Nginx这种负载均衡的思路是直接在数据通道的，做这些事情非常直接，纯粹的控制通道的置身事外的做法，想要控制数据层面的东西，确实是有难度，进一步加重SDK。两者的优劣逐渐的根据不同的发展阶段而此起彼伏。

服务编排。服务编排在API Gateway出现之前，是一件非常痛苦的事情。

服务编排是指众多的服务的调用链如何的组织。这个概念以前不火的，容器刚出现的时候也不火，但是等容器开始逐渐承载越来越多的服务的时候，跟随微服务的概念一起火起来了。

毕竟服务不多的时候，你编排什么？编排说白了是一个复杂性管理的工作。

API Gateway一个核心目的是权限，但是好像更核心的任务逐渐的变成了服务编排，两者密不可分。

最原始的服务编排方式是有一个服务控制中心，每一步到哪了该去哪都要是服务中心去指示。或者是同步的或者是异步的，不过这种叫做编制更加合适。

这种思路发展下来相当于把所有的API当成一个个函数，向本级的函数库一样的去调用，也是最直白的，也是大部分业务不约而同的自然演进的方向。因为顺序的逻辑，写起来还是很舒服了，你有API了，我不就是应该在我的程序里直接调用你的API吗？有什么问题吗？服务领域，粒度越小，组合的可能越大，组合的程度越高，对组合这个事情本身的要求就越高，也就是编排的要求越高。那么银弹是什么？谷歌给出了一个答案：链路追踪。

链路追踪是指在负载的调用链上追踪调用链的整个环节，有一个专门的调用链中心来查看这个调用链的结果和每个环节的问题，及时的发现每个环节的瓶颈问题。这是解决问题吗？不是，这是在当前众多API实在不知道怎么组合的时候出的，你怎么组合你看着办，但是我有个方案，可以让你组合的更舒服，让你的组合能更快的发现问题。

那服务编排的前沿是什么？如果谷歌的应用不算前沿，那国内大量趋之若鹜跟着上链路追踪的大厂就更不算前沿了？还是老大哥的方案是产业界的前沿。也就是说服务编排现在没有答案，但是大家都是通过链路追踪来解决海量API复杂调用关系的问题。业务内部直接调用API没问题，你继续调用，业务你自己就是一个你用到的API的协调中心。但是仍然还会有一个整体的协调中心，这个中心就是API Gateway。

恰好了，由于所有API都经过API Gateway，那么服务编排的链路追踪的标准做法（谷歌的做法）就是在请求中插入ID，API Gateway又莫名其妙的成为了承担服务编排的几乎唯一入口。Nginx又躺着赢了一局。

至于服务容量服务质量这些，是很容易的，无论从负载均衡的角度还是从控制面的角度，都是很容易实现的。负载均衡角度叫做健康检测，一个很low的名字，但是服务治理层面就会叫的比较高大上（服务角度出发的演进本身就是个在概念上逐渐高大上的过程），最后你不还是个健康检测？

归一时代

大家也看到了，工业界的痛点大都是谷歌，同时大哥还提出了解决方案（那是解决了？）。这次老大哥是真的想要彻底的解决这个问题了。你们别吵了，一个创业公司的思路很好，Sidebar了解一下。控制面跟数据面怎么就不能结合？Nginx的思路能做的事情你Dubbo能做吗？API Gateway领域纯服务的思路走不通了哥哥们，早点悔改吧。但是Nginx你觉得自己的负载均衡技术很厉害吗？能改数据通道就是王道吗？问题是你能做到Dubbo那种程度的服务治理吗？服务治理怎么跟数据通道进行联动呢？Dubbo技术上不可能支持sidebar，Nginx不支持控制面纯粹是公司问题，你不是不支持，你是支持的部分要收费，还那么贵，这我能忍？

Istio出现了。包含了Dubbo完整的服务治理思想（说Dubbo可能不恰当，应当是谷歌内部的服务治理思想，有个参照比较好讲），同时把数据通道跟控制通道紧密结合。这个思路也不是新思路了，K8S为什么取得了巨大的成功？OpenVswitch为什么取得了巨大成功？杀手锏就在这里，用过Openflow的人就再也离不开它了。那种坐在一台烂服务器里，运筹帷幄，远程管理这海量的高性能节点的实时策略，真的是非常的爽。Istio的秘籍就是复制这个成功经验，运用到服务治理领域。

好了，话说到这里。那么微服务架构该怎么设计就很清楚了。

核心在于服务治理领域的OpenFlow协议！仅此而已！至于你从服务的角度出发还是从负载均衡的角度出发已经不重要了。Istio已经告诉了世界，两个角度已经正式融合，你们之间就缺一个OpenFlow。还有一件事情，Dubbo你洗洗睡吧，数据通道是必要的，你就是不能支持，你也没价值了。Nginx你还是开源你的控制平面吧，你pro的设计挺好的，已经包括了控制与数据的联动，只是不够彻底，不够绝对，不够开放。总之你有点搓。Istio更多是的SOA的进一步发展，也就是说是从服务角度出发的一个大招，这一回不是要碾压你，而是要包括你。负载均衡的旗手Nginx，会怎么做呢？

我们看Nginx在Istio出现之后的表现就知道了。Nginx快速推出了Nginmesh，直接把自己的开源部分作为了Istio的Sidecar。

谷歌说：“老铁你够绝啊！直接卖啊！”

Nginx说：“我还是不想开源我的控制面，开源了我赚谁的钱去啊”。

谷歌说：“你不开源是吧？我Istio的控制面继续开源投入，而且版本还迭代，你跟不跟呢？”

Nginx说：“不跟了。”于是Nginmesh直接停了……永久性的停止在Istio的0.7版本的管理协议上。

谷歌说：“你确实跟不起。”

Nginx说：“我就不信你的管理协议不RFC？你能抵挡创造一个服务治理领域的OpenFlow的诱惑？”

谷歌说：“你猜。”

Nginx：“.……”

Nginx陷入沉思，开始更加的在自己的控制面发力。谷歌声势浩大，拉拢了IBM进行造势。众多中调厂商唯谷歌是从，谷歌只要不大错就没大问题。其实本质上，两者在做的事情一模一样，但是一个是开源，一个仍然是闭源的。业内的选择就不用说了，大量的倒向Istio。但是Istio的Envoy在数据层面真的可以跟Ng竞争？差很远的。API Gateway你Istio那么容易撼动的？谷歌或许可以，但也不是现在。

一个Nginx的开源公司内部环境，如果主动选择向Istio哲学靠拢，需要做哪些工作呢？API Gateway完成编排和服务授权，Nginx内部实现Zk实现完整的服务发现原语（国内已经有不少厂商这么做了，当然并不是为了向Istio哲学靠拢，纯粹是发展需要），然后就是各家都有自己实现的健康检测（本来是Nginx Pro内容）来实现的服务质量和服务容量概念。

数据通道上Envoy在功能支持上实在是给力，HTTP、gRPC、WebSocket 和 TCP等都支持，Nginx可能需要支持gRPC才行。但是那取决于到底整个公司是否是gRPC架构的服务组织方式。前面说过如果服务的高层次治理没有经过SOA时代的公司，至今应当仍然是Restfull的，反而没有了rpc的问题和需求。这个问题和需求被直接压在了API Gateway上。

Istio在服务发现这里做了很多事情，这也是开源的Nginx的最大软肋。所以他们可以做到A/B 测试、金丝雀部署等弹性（超时、重试、熔断器等），这是Istio的Pilot组件的功能，这也是Ng集团的缺失部分。但是这部分，真的难吗?要知道控制面是建立期的核心，稳定运行期的核心永远在数据面！

Citadel和Mixer是Istio对Nginx阵营的API发起的强力挑战。功能直接与API Gateway重叠（虽然很多API Gateway没有链路追踪，我是指全面的API Gateway），但是短期内应该是看不到取代的可能。

剩下一个最关键的问题就是容器化和标准化。对容器的天然友好是Istio的杀手锏，也是他被称为微服务架构的原因。虽然Nginx与Istio功能上相互替代的程度很大，但是微服务这个词天然属于容器，属于虚拟化，荣誉属于Istio。但是Nginx前面也说过，回调API的方式没毛病，反而完全独立，更好的满足低内聚的要求。至于能不能标准化，任何人都知道谷歌比Nginx有更高的标准化的话语权，并且Istio的Envoy API本身就自有标准化的实现的，是已经做了的，只是没有RFC，还在演进。而Nginx？没有。

趋势非常明显，Istio会逐步成为事实的标准，但是Nginx的成功恰好就是因为他的数据面极其强大。Nginx的彻底落败，应该发生在Ha宣布完全支持Istio为止。

Ha在纯粹的反向代理的简单应用领域，是几乎完胜Nginx的。除了reload和一些小细节各有千秋，也很难评价优劣。Nginx在反代领域的胜出很大程度得益于Nginx的模块设计和Nginx的不止止是反代的能力。影响力上，Nginx是比Ha好很多的。但是如果一方面是Nginx告别Istio，一方面是Ha靠拢Istio的话，格局并不好说。但是这也都是还没有出现的事情。Ha发展至今，证明了它的技术性的性格。

原文链接： 对服务治理的演进理解