作者：杨奕  华为云技术布局专家

在以往的文章《云原生微服务治理技术朝无代理架构的演进之路》中，咱们介绍了几种微服务架构模式，如下图所示。

注：图片起源 https://twitter.com/bibryam/status/1026429379587567616

明天次要是介绍，第一种SOA/ESB架构，在Java语言场景下，如何朝第三种 云原生ServiceMesh架构 的演进的问题。

SOA/ESB架构简介和问题概览

首先咱们来看看 SOA/ESB 架构模式 在目前私有云上的典型参考架构。

如下图所示，以华为云为例，以该模式部署利用时，其应用到的典型云服务为 弹性负载平衡 (ELB) + 弹性伸缩(AS，蕴含ECS)。在这种场景下，

  • 须要发动调用的客户端程序，通过配置好的域名或地址，间接调用到ELB上，通过ELB去调用到后端的ECS服务器。
  • ELB上须要配置后端服务器的多个IP地址。当然，个别这类操作能够简化为增加某类弹性伸缩组。这样，当ECS产生弹性伸缩时管理员无需解决ELB配置，ELB即可主动刷新ECS的IP列表的变动。 (配置操作可参见：https://support.huaweicloud.com/usermanual-as/as_01_0102.html)

    值得注意的是，以上的模式可能存在几种变种。
  • 对于ELB，可能会采纳API网关代替，或者用户自建的KONG, APISIX,Envoy等，具体取决各个企业的本身业务场景。例如，某些互联网公司偏向于采纳企业自建的KONG，其次要起因是除了根本的服务发现和负载平衡能力以外，网关还须要解决面向外部跨域调用的一些鉴权状况解决。
  • 对于弹性伸缩，可能也会间接采纳Kubernetes的Deployment + HorizontalPodAutoscaler代替。这当然取决于企业外部的基础架构采纳状况，看是更偏向于应用虚拟机架构还是容器架构。
    以上架构尽管在隔离性、安全性上存在肯定长处，然而短板也非常明显。
  • 性能和资源开销。这个比拟好了解，绝对微服务架构，SOA/ESB架构上网络减少了额定一跳，而且ELB的引入也会导致资源的额定耗费增多。
  • 运维老本。毕竟额定引入了一个ELB的组件，因而在微服务之间调用时，瓶颈在哪里，ELB是否须要扩缩容，都是问题。

微服务和云原生架构革新的一些办法和问题

对于如何革新 SOA/ESB 架构，朝微服务架构或云原生架构演进，业界也有很多办法。次要是以下两类。

  • 通过批改代码，将利用革新为微服务架构。例如间接在代码中引入比方SpringCloud的服务注册发现和负载平衡等组件。当然，这种革新往往也并不简略，次要取决于现有利用已采纳的开发框架，等。比方利用自身没有采纳spring来进行开发，那么间接采纳SpringCloud可能会为利用带来海量的革新老本。
  • 采纳istio计划，通过无限革新利用，将架构降级为ServiceMesh架构。之所以该计划说是无限革新，而不是无革新，也是因为在服务调用形式上，istio计划对利用并不是齐全无限度。其至多须要在客户端将调用的http调用地址革新成为k8s原生的服务地址，调用的服务治理能力被envoy无效接管。当然，革新结束后，用户在接下来在面向边车的性能衰减，更简单的调用运维问题上，恐怕一个也不会少。
    综上所述，两种计划都存在比拟显著的短板。接下来剖析下采纳Sermant形式进行架构革新，如何补救上述两种计划的短板。

Sermant对SOA/ESB架构降级的一些思路

采纳Sermant (https://sermant.io/zh/) 对SOA/ESB架构降级，实质上的最初的架构终态是Service-Mesh。然而因为采纳的办法稍有不同，从而导致计划在性能和运维问题上都不存在短板。次要是以下两点：

  • 首先，Sermant采纳Java Agent来动静注入加强的服务逻辑治理，因而利用侧实践能够做到齐全不必改代码。
  • 其次，因为Sermant的外围逻辑是以AOP (面向切面编程) 形式，Java Agent和业务属于同一过程，因而在性能方面不存在sidecar状态的特地大的损耗。
    Sermant计划架构如下图所示。

在核心技术点上，Sermant革新计划的性能次要有以下几个方面：

* 内置的服务注册发现机制。(上图中的第一点和第三点) 

插件自身会带服务注册性能，在Provider利用启动的时候主动到注册核心进行服务注册。在Consumer利用进行URL服务调用的时候，通过微服务服务发现+负载平衡机制代替原先的服务直调。

* 域名到服务名(有时也称利用名)的转换。(上图中的第二点)

服务发现时，因为原先的调用采纳URL直调，并不蕴含利用信息。这就须要一个调用关系到利用名的映射。对于这块内容，将来咱们打算做成了一个动静配置，存储到配置中心里。这样当有利用须要发动调用时，Sermant间接将URL转换成利用名，就能够在注册核心获取响应的利用IP列表。通过URL获取Provider利用名后，因为在革新过程中，不必Provider利用并不是同批次公布携带Sermant Java Agent，因而还须要有个白名单机制，来配合灰度公布。

* 加强的客户端侧负载平衡、重试、隔离、降级机制。(上图中的第四点)

联合上一步，残缺的商用计划，Consumer调用Provider除了须要满足根本的负载平衡性能以外，还须要更进一步进行重试、容错隔离、以及对上游的限流降级解决。此外，对于一些必要的东西向流量的治理能力，如服务间的3A认证，等，也须要进一步在Sermant端补齐。

以上便是Sermant革新计划的次要性能点。另外，在实操中如何针对现有环境进行降级还是须要肯定办法，防止对现有环境进行太大冲击。以下具体叙述。

采纳Sermant对SOA/ESB架构降级的计划实操

利用革新在具体局点上不可能欲速不达，因而在具体上施行上必定是一个缓缓灰度的过程。以Kubernetes容器场景为例，介绍下在上百个微服务利用上千实例的状况下，如何采纳Sermant对SOA/ESB基于灰度进行平安可控的云原生架构降级。

以下为筹备工作：

  • 筹备步骤一：本身利用是否反对。以后Sermant反对的微服务降级的Java框架能够在该文档中查问。如未反对，能够思考给社区提Issue解决。

    参考链接：https://sermant.io/zh/document/plugin/springboot-registry.htm...

  • 筹备步骤二：在Kubernetes中装置Injector，不便以非侵入形式让Java利用主动挂载Sermant Java Agent.
    本步骤可选。如跳过，则须要手动扭转利用部署脚本加载Sermant Java Agent。

    参考链接：https://sermant.io/zh/document/user-guide/injector.html 

以下介绍具体施行过程。假如初始架构如下。一共三个App，其中App1通过ELB连贯到App2和App3。为简化表述，图中为利用均为单实例，理论生产中的实例可能会有多个。

接下来，在Kubernetes中对新版本的App1, App2进行公布(图中为V2版本)，并在公布时携带Sermant Java Agent，以及激活SpringBoot注册插件。然而此时能够先不配置Provider白名单规定，因而公布后，利用流量应该还是走ELB，未产生任何变动。

接着在配置核心，将App2退出到白名单中。此时，对辨认到App2的利用，挂有Sermant Java Agent的App1实例 (图中的V2实例) 会对App2的实例以负载平衡形式间接发动调用。与此同时，App1拜访App3的流量没有变动。

验证胜利后，删除App1、 App2的V1版本，App1到App2的流量通过注册核心的注册发现，齐全实现直连。同时，App1拜访App3的流量维持不变。

至此，应用Sermant对App1、App2的云原生架构降级完结。后续其余App利用，能够依照相似计划，进行灰度降级，直至所有利用全副挂载上Sermant，实现微服务直连革新。

结束语

Sermant 作为专一于服务治理畛域的字节码加强框架，致力于提供高性能、可扩大、易接入、功能丰富的服务治理体验，并会在每个版本中做好性能、性能、体验的看护，宽泛欢送大家的退出。

Sermant官网：https://sermant.io
GitHub仓库地址：https://github.com/huaweicloud/Sermant
增加Sermant小二（微信号：sermant-support）退出社区交换群
或扫码退出Sermant社区交换群