分布式政企应用如何快速实现云原生的微服务架构改造-德赢Vwin官网网

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

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

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

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

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

·需要发起调用的客户端程序，通过配置好的域名或地址，直接调用到ELB上，通过ELB去调用到后端的ECS服务器。

·ELB上需要配置后端服务器的多个IP地址。当然，一般这类操作可以简化为添加某类弹性伸缩组。这样，当ECS发生弹性伸缩时管理员无需处理ELB配置，ELB即可自动刷新ECS的IP列表的变化。

(配置操作可参见：

值得注意的是，以上的模式可能存在几种变种。

·对于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，因此还需要有个白名单机制，来配合灰度发布。

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

- 此外，对于一些必要的东西向流量的治理能力，如服务间的3A认证等，也需要进一步在Sermant端补齐。

以上便是Sermant改造方案的主要功能点。另外，在实操中如何针对现有环境进行升级还是需要一定方法，避免对现有环境进行太大冲击。以下详细叙述。

采用Sermant对SOA/ESB架构升级的方案实操

应用改造在具体局点上不可能一蹴而就，因此在具体上实施上肯定是一个慢慢灰度的过程。以Kubernetes容器场景为例，介绍下在上百个微服务应用上千实例的情况下，如何采用Sermant对SOA/ESB基于灰度进行安全可控的云原生架构升级。

以下为准备工作：

准备步骤一：

自身应用是否支持。当前Sermant支持的微服务升级的Java框架可以在该文档中查询。如未支持，可以考虑给社区提Issue解决。

准备步骤二：

在Kubernetes中安装Injector，方便以非侵入方式让Java应用自动挂载Sermant Java Agent.

（本步骤可选。如跳过，则需要手动改变应用部署脚本加载Sermant Java Agent。）

以下介绍详细实施过程。假设初始架构如下。一共三个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已在华为云云服务CSE中被集成，用户可以在华为云CSE云服务中使用相关功能。

审核编辑：汤梓红

声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表德赢Vwin官网网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。举报投诉

服务器

服务器

+关注

关注
12

文章
9123

浏览量
85318
SOA

SOA

+关注

关注
1

文章
287

浏览量
27461
微服务

微服务

+关注

关注
0

文章
137

浏览量
7337
华为云

华为云

+关注

关注
3

文章
2445

浏览量
17404
云原生

云原生

+关注

关注
0

文章
248

浏览量
7947

云原生技术概述云原生火爆成为升职加薪核心必备

云原生微服务可通过分布式部署，大幅提升团队和日常的工作效率，K8s+Docker+Ceph+Envoy+Istio+Prometheus架构，目前是各大主流互联网首选的技术方向，掌握

发表于 07-27 10:23 •1302次阅读

微服务架构下分布式事务解决方案 —— 阿里GTS

一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高。4 GTS--分布式事务解决方案GTS是一款分布式事务中间件，由阿里巴巴中间件部门研发，可以为微服务

发表于 03-16 11:14

一行代码，保障分布式事务一致性—GTS:微服务架构下分布式事务解决方案

故障问题。单体应用拆分所导致的数据库架构的拆分。应用更新多个业务记录非常常见，单体应用实现也比较简单。然而在微服务架构下，应用不得不调用多个微服务

发表于 06-05 19:14

性能提升1倍，成本直降50%！基于龙蜥指令加速的下一代云原生网关

；业务网关提供独立业务域级别的、与后端业务紧耦合策略配置，随着应用架构模式从单体演进到现在的分布式微服务，业务网关也有了新的叫法 - 微服务网关。（图 6/传统网关）MSE 云原生网关

发表于 08-31 10:46

微服务，容器和云原生架构的中间件世界的现状

令人不可思议的速度快速向这些技术靠拢！在2016年6月的今天，许多企业已经采用容器和原生云架构或正在采用它们。这个话题也越来越和中间件供应商相关。因此，我们需要做一个有关微服务，

发表于 10-10 11:25 •0次下载

微服务和分布式的区别

本文全面概述了微服务和分布式的区别。分布式和微服的架构很相似，只是部署的方式不一样而已。分布式：

发表于 02-09 10:52 •8.1w次阅读

云原生技术将是企业落地微服务的优秀伴侣

随着技术的发展，我们云托管时代逐步的向云原生演进了。所谓云原生，就是将微服务、DevOps的架构理念与云所提供的容器、Serverless无服务

发表于 10-08 14:37 •1937次阅读

什么是微服务和分布式 微服务和分布式之间区别

独立的小团队开发，测试，部署，上线，负责它的整个生命周期。 分布式又是啥？ 分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负

发表于 07-30 18:21 •3w次阅读

什么是分布式系统 分布式架构有哪些

什么是分布式系统？ 1.分布式系统一定是由多个节点组成的系统。 2.这些连通的节点上部署了我们的节点，并且相互的操作会有协同。随着应用架构演进， 分布式

发表于 07-31 09:54 •7525次阅读

什么是分布式云原生

体验，让客户在使用云原生应用时，感受不到地域、跨云、流量的限制，把云原生的能力带入到企业的每一个业务场景，加速千行百业拥抱云原生。 分布式云原生

发表于 07-27 15:52 •1568次阅读

华为云左少夫：面向分布式云原生构筑无处不在的云原生基础设施

2022年全球分布式云大会近日于深圳南山举办，会上华为云云原生产品总监做了题为“面向分布式云原生，构筑无处不在的云原生基础设施”的主题演讲。

发表于 12-26 21:52 •771次阅读

分布式政企应用如何快速实现云原生的微服务架构改造

和集成复杂的应用系统。然而，随着云计算和微服务等新技术的出现，SOA/ESB架构也面临着一些问题和挑战。本文将对SOA/ESB架构，在Java语言场景下，如何朝云原生ServiceMe

发表于 04-17 15:17 •540次阅读

如何迅速将分布式政企应用转型为云原生微服务架构

）来构建和集成复杂的应用系统。然而，随着云计算和微服务等新技术的出现，SOA/ESB架构也面临着一些问题和挑战。本文将对SOA/ESB架构进行简要介绍，并探讨将其转换为微服务和

发表于 04-17 15:18 •517次阅读

技术速递 | 分布式政企应用如何快速实现云原生的微服务架构改造

作者：杨奕华为云技术规划专家在以往的文章《云原生微服务治理技术朝无代理架构的演进之路》中，我们介绍了几种微服务架构模式，如下图所示。

发表于 04-19 00:45 •559次阅读

k8s微服务架构就是云原生吗？两者是什么关系

k8s微服务架构就是云原生吗？K8s微服务架构并不等同于云原生，但两者之间存在密切的联系。Kub

发表于 11-25 09:39 •136次阅读