企业应用架构演化探讨：从微服务到Service Mesh

导读

当下微服务的实践方案中，Spring Cloud，Dubbo做为主流的落地方案，在企业应用架构中发挥愈来愈重要的做用。本文探讨企业应用架构如何从微服务架构向Service Mesh架构演化，并造成落地方案。须要特别说明：本文讨论的架构目前适用于普通的企业级应用，其余行业（例如互联网）须要进一步扩展。

在讨论以前，咱们须要明确一个事实：企业应用必定是围绕业务进行的。不管采用什么的架构落地，都是为了更好的为应用业务进行服务。从企业应用的特性考虑，主要包括：稳定性，安全性，扩展性，容错性。

围绕着企业应用的这些特色，咱们来看一个典型的微服务企业架构模型，如图所示：

• 服务接入层：企业暴露到外部访问的入口，通常经过防火墙等。
• 网关层：服务网关是介于客户端和服务端的中间层，全部的外部请求会先通过服务网关，为企业应用提供统一的访问控制入口。服务网关是微服务架构下的服务拆分，聚合，路由，认证以及流控综合体现。
• 支撑服务层：为企业应用提供运行所需的支撑环境，包括注册发现，集中配置，容错限流，认证受权，日志聚合，监测告警，消息服务等
• 业务服务层：业务服务是企业应用的核心所在，为企业领域应用的具体实现，通常进一步拆分为基础服务（基础功能）和聚合服务（综合场景）。
• 平台服务层：为企业应用提供运行所需的软件资源，包括应用服务器，应用发布管理，应用镜像包管理，服务治理。
• 基础设施层：为企业应用提供运行所需的硬件资源，包括计算资源，网络资源，存储资源，基本的安全策略控制等。

从这个典型的服务架构体系中，可以清晰的代表层级架构以及各层涵盖的职责说明。咱们暂不考虑基础设施层和平台服务两层，重点关注网关服务，业务服务，支撑服务，突出其中的一些基础支撑功能组件，这也是咱们本篇探讨的重点内容。以下图所示：

根据图中红色标识，咱们会发现这样一个事实：在微服务架构下，不管是哪一种落地实现方式，都集中在网关服务、支撑服务两个层面。不管是Spring Cloud“套装组件”，Dubbo“套件”仍是其余开源组件，都为支撑服务的实现提供了数量众多的选择。功能完整、选择性多这是业内喜闻乐见的事情，可是也无形中增长了开发，测试，运维人员的压力。你们须要掌握愈来愈多的“使用工具”以更“方便”、“快捷”地应对业务服务。有时候，可能为了实现单一功能，而必须引入一堆组件，这时候咱们但愿可以有一个完整的平台来为应用业务提供一体化的支撑服务，而不是一系列“套装组件”与业务的集成。

那么如何基于一个平台来实现这些企业应用须要的能力呢？通过必定阶段的技术调研，咱们认为Service Mesh可以帮助咱们初步达到这个目标。

咱们都知道Service Mesh以解决“服务通讯”的问题做为其设计初衷，聚焦基础设施“网络层”，并以此作技术基础，解决业务通讯场景面临的问题。那么如何把它应用在企业应用架构中来取代“微服务套装组件”呢？那接下来让咱们针对网关服务，业务服务，支撑服务分别来看一下，如何从原来的微服务“套装组件”中抽离出来，实现Service Mesh方向的转变。

网关服务

前面提到过：服务网关是介于客户端和服务端的中间层。从功能上不难理解，对内屏蔽内部细节，对外提供统一服务接口。从场景聚焦角度考虑，网关根据不一样的场景承载不一样的职责，包括认证，受权，路由，流控，负载等。（以前咱们也聊过网关组件的对比及具体实现，感兴趣的同窗可点击微服务五种开源API网关实现组件对比）。

因而可知，服务网关是企业应用架构下一些列功能的综合体现。那么在Service Mesh状况下如何处理网关服务呢？在展开以前首先须要说明一个前提：目前为止Service Mesh跟真正企业网关相比还存在必定的不足之处，例如“协议转化”，“安全策略”，“性能要求”等方面。在这里咱们也是探讨这样的可能性。下面以Istio为例，咱们来看一下，如何提供网关层面的服务。

Istio在网关层面提供两种类型的网关服务：Ingress Gateway，Egress。

• Ingress Gateway

Ingress Gateway用于接收传入的HTTP/TCP链接，它配置暴露端口，协议供外部统一接入，可是自身不提供任何的路由配置，而是彻底依赖 Istio 的控制规则来进行流量路由。从而与内部服务请求统一到同一个控制层面上。

• Egress

在企业应用与外部应用之间，有时候为了业务须要会出现内部服务调用外部服务的状况，此时通常会从企业内部接入第三方网关来获取服务数据。在 Isito 中你一样能够基于Egress来达到目的。Isito中提供两种方式：一种基于ServiceEntry + VirtualService的配置，实现第三方服务的访问，一种扩大sidecar的访问地址列表。（参考文档：https://preliminary.istio.io/...）。

基于上述两种场景，咱们能够看出，在 Service Mesh 的体系下，网关层面变成一个能够动态生成和销毁的组件，可以经过控制层面实现统一规则管理，而且实时生效。

基于Service Mesh的网关服务以下图所示：

从实现原理上分析，传统的网关实现基于 Servlet 的 filter 的模式，实现服务请求转移过程当中的层层过滤和处理。区别在于采用同步或者异步处理机制，用来解决网关的性能瓶颈。而Service Mesh的网关彻底是基于网络代理的请求转发与控制，本质上做用在服务的 Iptables 上，经过对 Iptables 的规则控制达到一样的效果。

业务服务

业务是企业应用的“重中之重”，不管哪一种企业架构，最终都是为了更好地为业务提供服务，那么咱们如何在Service Mesh的体系下，重构业务服务呢？咱们以两个简化的服务调用来讲明整个架构的转变过程。

假如要实现服务A，服务B的相互调用，最原始的方式是服务A基于协议层直接调用服务B（这里暂时忽略高可用，多副本，负载均衡的方式），如图所示：

由图可见，服务A基于某种协议完成对服务B的请求，相对比较简单。可是咱们知道这样虽然可以快速完成业务关联，可是没法确保业务正常稳定的运行，所以咱们须要引入更多的服务来保证业务的稳定，可靠，可控。此时咱们最容易想到的是引入微服务的支撑组件来达到目标。

以Spring Cloud方案为例，咱们来讲明当前微服务架构的实现方式。为了知足企业应用对服务A，服务B的管理控制，须要额外引入“注册中心”，“网关”，“配置中心”，“服务监测”，“事件消息”，“链路跟踪”，“日志服务”等众多与直接业务无关的“旁路保障服务”，简化一下，以下图所示：

从图中能够看出，每一个服务都引入了大量与业务无关的“保障服务”，这些“旁路保障服务”消耗的资源，与比业务自己消耗的资源成“倍数关系”。随着服务数目的增多，业务服务自己占用的资源比会愈来愈少，此时开发人员会把大量的精力花费在维护这些“旁路保障服务”上，而忽略业务自己。这对于企业应用而言，有些本末倒置的意思。

咱们再来看一下 Service Mesh 体系下，咱们如何解决上述问题。Service Mesh为了解决企业应用的“通讯问题”重点作了四个方面的工做，以 Istio 为表明，提供了包括流量管理，安全配置，策略控制以及外围组件支撑的遥测功能（须要的朋友，能够参考官方文档：https://preliminary.istio.io/...），在Service Mesh的架构下，服务A调用服务B的架构会变成下图所示：

经过上图咱们能够发现，与Spring Cloud的实现方式相比，彷佛简单了不少，咱们再也不须要在业务服务中引入众多的“旁路保障服务”，而是保障了业务服务自己的简单化。那么Service Mesh是如何处理的呢？

第一，引入了Sidecar代理模型，做为服务流量控制的入口和出口，保证可以对网络层面数据作实时监控和调整；

第二，控制器根据具体业务状况，分发控制状态和控制指令，Sidecar获取控制信息后，及时更新缓存信息，保证策略有效性。

第三，Sidecar因为可以拦截全部请求的流量信息，按期把收集的数据向控制层进行上报，从而完成服务状态和应用链路的监测。

第四，全部的这些都是在应用部署阶段完成，在开发层面不须要花费大量的精力。

基于以上四点咱们能够发现，Service Mesh 仅仅经过方式转变就达到了一样的效果，还极大的解放了开发人员。

经过业务服务调用方式的实现转变，咱们发现这样一个事实：Service Mesh在保证业务简化有效的同时，进一步屏蔽了多种开发语言带来的障碍。它彻底基于网络层面和协议层面做为出发点，达到“以不变应万变”的效果。

支撑服务

从企业业务的价值角度考虑，其实支撑服务更多属于“资源消耗”品，虽然如此，它倒是企业应用架构不可或缺的一部分。从单一的业务调用--->微服务体系业务调用--->Service Mesh 体系业务调用的转变方式中，能够看出支撑服务处于一个层级不断降低的过程。而依赖于ServiceMesh的定位，最终一些支撑服务会做为基础设施的形态呈现出来，这也是将来发展的趋势所在。支撑服务在企业架构的形态转变如图所示：

• 传统架构：传统架构下，支撑服务，业务服务基本上没有明确的边界区分，实现方式上都经过代码杂糅在一块儿。
• 微服务架构：微服务架构下，支撑服务，业务服务可以初步分离，可是须要保证代码框架的统一性和依赖性，跨语言受限比较严重。
• Service Mesh架构：Service Mesh架构下，支撑服务，业务服务可以完全分离，不收语言限制，惟一须要考虑的是不一样协议的支持状况。

经过支撑服务的转变形态能够看出，支撑服务与业务服务分离是必然趋势，而最终的受限取决于多元化的网络协议的处理分析能力。固然咱们须要明确一个事实：就Service Mesh目前的发展趋势和定位而言，并不可以彻底取代全部的支撑服务，例如事件消息，配置管理等。咱们更多指望它可以帮助解决应用服务在网络层面须要面对的场景和问题。这也是它发挥价值的地方所在。

经过对网关服务，业务服务，支撑服务在不一样体系架构下的转变，咱们清晰的认识到Service Mesh可以帮助咱们重点解决微服务体系下繁琐的“旁路支撑”服务，保证业务服务的简单有效性。经过演化分析，最终基于Service Mesh的企业应用架构以下图：

从图中能够看到 Service Mesh 架构下重点作了三件事情：

• 网关层的接入工做，不管是外部请求接入，仍是内部服务请求转发，均可以基于 Service Mesh 提供的不一样类型的 gateway 实现，同时还能够保证策略的统一控制和管理。省略了独立的网关管理控制台。
• 针对业务服务，增长了 Sidecar 的代理模型，用来处理全部的入站和出站流量，而且配合支撑服务的控制策略，实现业务服务的旁路控制功能。
• 统一面向网络的支撑服务，基于控制与数据分离的思想，根据业务的运行状况，提升企业应用运行过程当中的动态控制能力。

一样咱们也意识到，利用 Service Mesh 处理服务通讯的能力，替换须要不一样组件支撑的“注册发现”，“容错限流”“认证受权”“日志搜集”，“监控告警”“流量控制”等功能。在减小组件代码开销的同时，将企业应用的支撑服务进一步下移。不管是开发人员，仍是领域专家，能够集中精力用来处理应用业务，而不用在维护第三方的不一样的功能组件上“浪费时间”。而业务运维人员，经过 Service Mesh 的控制平台，可以实时监测企业服务的运行状态，而不须要向以前那样花费精力维护不一样的工具和组件。

最后让咱们一块儿讨论一下，Service Mesh是如何作到这些的。Service Mesh 本质上并无采用任何技术上的创新，更可能是思想层面的变革。咱们认为有几个转变是须要提出来的：

• 层级转变：Service Mesh在设计思路上，把本身再也不定位成企业应用组件，而是把本身下沉到基础设施层，成为基础设施的一部分，这样层级的转变就与企业业务自己划清楚界限。
• 方式转变：Service Mesh在实现思路上，高度抽象，聚焦于通讯链路自己，而不是聚焦于组件功能上，从网络层入手，抓住了服务通讯交互的本质。
• 控制转变：Service Mesh将控制和实现分离，提供统一，灵活的控制入口，可以快速方便的针对业务场景进行自定义处理。

最后的最后须要说明 Service Mesh 还不完善，还有不少问题须要在实际的企业应用过程当中逐步去解决，让咱们一块儿拭目以待吧。

本文由博云研究院原创发表，转载请注明出处。