分布式政企应用如何快速实现云原生的微服务架构改造
作者:杨奕 华为云技术规划专家
在以往的文章《云原生微服务治理技术朝无代理架构的演进之路》中,我们介绍了几种微服务架构模式,如下图所示。
注:图片来源 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 解决。
准备步骤二:在 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 社区交流群
版权声明: 本文为 InfoQ 作者【华为云开源】的原创文章。
原文链接:【http://xie.infoq.cn/article/0f1fbac959017fe01a155c27c】。文章转载请联系作者。
评论