作者：杨奕 华为云技术布局专家
在以往的文章《云原生微服务治理技术朝无代理架构的演进之路》中，咱们介绍了几种微服务架构模式，如下图所示。
注：图片起源 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 社区交换群