作者:杨奕 华为云技术规划专家
在以往的文章《云原生微服务治理技术朝无代理架构的演进之路》中,我们介绍了几种微服务架构模式,如下图所示。
注:图片来源 https://twitter.com/bibryam/status/1026429379587567616
今天主要是介绍,第一种SOA/ESB架构,在Java语言场景下,如何朝第三种 云原生ServiceMesh架构 的演进的问题。
首先我们来看看 SOA/ESB 架构模式 在目前公有云上的典型参考架构。
如下图所示,以华为云为例,以该模式部署应用时,其使用到的典型云服务为 弹性负载均衡 (ELB) + 弹性伸缩(AS,包含ECS)。在这种场景下,
值得注意的是,以上的模式可能存在几种变种。
以上架构虽然在隔离性、安全性上存在一定优点,但是短板也非常明显。
对于如何改造 SOA/ESB 架构,朝微服务架构或云原生架构演进,业界也有很多方法。主要是以下两类。
综上所述,两种方案都存在比较明显的短板。接下来分析下采用Sermant方式进行架构改造,如何弥补上述两种方案的短板。
采用Sermant (https://sermant.io/zh/) 对SOA/ESB架构升级,本质上的最后的架构终态是Service-Mesh。但是因为采用的方法稍有不同,从而导致方案在性能和运维问题上都不存在短板。主要是以下两点:
Sermant方案架构如下图所示。
在核心技术点上,Sermant改造方案的功能主要有以下几个方面:
以上便是Sermant改造方案的主要功能点。另外,在实操中如何针对现有环境进行升级还是需要一定方法,避免对现有环境进行太大冲击。以下详细叙述。
应用改造在具体局点上不可能一蹴而就,因此在具体上实施上肯定是一个慢慢灰度的过程。以Kubernetes容器场景为例,介绍下在上百个微服务应用上千实例的情况下,如何采用Sermant对SOA/ESB基于灰度进行安全可控的云原生架构升级。
以下为准备工作:
以下介绍详细实施过程。假设初始架构如下。一共三个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社区交流群
|