随着数字化时代的快速发展,企业和组织正面临着如何在保持敏捷和灵活的同时,提高业务运营效率和降低成本的巨大挑战。为了应对这些挑战,许多企业开始采用面向服务的架构(SOA)和企业服务总线(ESB)来构建和集成复杂的应用系统。然而,随着云计算和微服务等新威廉希尔官方网站 的出现,SOA/ESB架构也面临着一些问题和挑战。本文将对SOA/ESB架构,在Java语言场景下,如何朝云原生ServiceMesh架构演进的问题进行探讨。
SOA/ESB架构简介和问题概览
SOA(Service-Oriented Architecture,面向服务的架构)是一种软件架构设计方法,它将应用程序的功能模块化为一组可重用的服务,这些服务可以通过网络进行调用和组合,以支持业务流程的执行。ESB(Enterprise Service Bus,企业服务总线)是SOA架构中的关键组件,它提供了一种用于连接和集成各种服务的中间件平台。
SOA/ESB架构模式在目前公有云上的典型参考架构,以华为云为例,其使用到的典型云服务为弹性负载均衡(ELB)和弹性伸缩(AS,包含ECS)。在这种场景下,需要发起调用的客户端程序,通过配置好的域名或地址,直接调用到ELB上,通过ELB去调用到后端的ECS服务器。ELB上需要配置后端服务器的多个IP地址。当然,一般这类操作可以简化为添加某类弹性伸缩组。这样,当ECS发生弹性伸缩时管理员无需处理ELB配置,ELB即可自动刷新ECS的IP列表的变化。
SOA/ESB架构虽然在隔离性、安全性上存在一定优点,但是短板也非常明显。主要包括性能和资源开销以及运维成本。相对微服务架构,SOA/ESB架构上网络增加了额外一跳,而且ELB的引入也会导致资源的额外消耗增多。此外,额外引入了一个ELB的组件,因此在微服务之间调用时,瓶颈在哪里,ELB是否需要扩缩容,都是问题。
微服务和云原生架构改造方法和问题
对于如何改造SOA/ESB架构,朝微服务架构或云原生架构演进,业界也有很多方法。主要是以下两类:
1. 通过修改代码,将应用改造为微服务架构。例如直接在代码中引入比如SpringCloud的服务注册发现和负载均衡等组件。当然,这种改造往往也并不简单,主要取决于现有应用已采用的开发框架等。比如应用本身没有采用spring来进行开发,那么直接采用SpringCloud可能会为应用带来海量的改造成本。
2. 采用istio方案,通过有限改造应用,将架构升级为ServiceMesh架构。之所以该方案说是有限改造,而不是无改造,也是因为在服务调用方式上,istio方案对应用并不是完全无限制。其至少需要在客户端将调用的http调用地址改造成为k8s原生的服务地址,调用的服务治理才能被envoy有效接管。当然,改造完毕后,用户在接下来在面向边车的性能衰减,更复杂的调用运维问题上,恐怕一个也不会少。
综上所述,两种方案都存在比较明显的短板。接下来分析下采用Sermant方式进行架构改造,如何弥补上述两种方案的短板。
Sermant对SOA/ESB架构升级的思路
采用Sermant对SOA/ESB架构升级,本质上的最后的架构终态是Service-Mesh。但是因为采用的方法稍有不同,从而导致方案在性能和运维问题上都不存在短板。主要是以下两点:
1. 首先,Sermant采用Java Agent来动态注入增强的服务逻辑治理,因此应用侧理论可以做到完全不用改代码。
2. 其次,由于Sermant的核心逻辑是以AOP (面向切面编程) 方式,Java Agent和业务属于同一进程,因此在性能方面不存在sidecar形态的特别大的损耗。
在核心威廉希尔官方网站 点上,Sermant改造方案的功能主要有以下几个方面:
1. 内置的服务注册发现机制。插件本身会带服务注册功能,在Provider应用启动的时候自动到注册中心进行服务注册。在Consumer应用进行URL服务调用的时候,通过微服务服务发现+负载均衡机制替代原先的服务直调。
2. 域名到服务名(有时也称应用名)的转换。服务发现时,由于原先的调用采用URL直调,并不包含应用信息。这就需要一个调用关系到应用名的映射。对于这块内容,未来我们计划做成了一个动态配置,存储到配置中心里。这样当有应用需要发起调用时,Sermant直接将URL转换成应用名,就可以在注册中心获取响应的应用IP列表。
3. 增强的客户端侧负载均衡、重试、隔离、降级机制。通过URL获取Provider应用名后,由于在改造过程中,不用Provider应用并不是同批次发布携带Sermant Java Agent,因此还需要有个白名单机制,来配合灰度发布。
4. 对于一些必要的东西向流量的治理能力,如服务间的3A认证等,也需要进一步在Sermant端补齐。
采用Sermant对SOA/ESB架构升级的方案实操
应用改造在具体局点上不可能一蹴而就,因此在具体上实施上肯定是一个慢慢灰度的过程。以Kubernetes容器场景为例,介绍下在上百个微服务应用上千实例的情况下,如何采用Sermant对SOA/ESB基于灰度进行安全可控的云原生架构升级。
以下为准备工作:
1. 准备步骤一:自身应用是否支持。当前Sermant支持的微服务升级的Java框架可以在该文档中查询。如未支持,可以考虑给社区提Issue解决。
2. 准备步骤二:在Kubernetes中安装Injector,方便以非侵入方式让Java应用携带Sermant Java Agent。具体安装方法可以参考Sermant官方文档。
接下来,详细介绍实施过程:
1. 在Kubernetes中对新版本的App进行发布。新版本的App需要携带Sermant Java Agent,可以通过在Kubernetes的Deployment或者StatefulSet中添加annotations来实现。例如:
```
annotations:
sermant.injector.io/inject: "true"
```
2. 在配置中心,将App加入到白名单中。这样,当Consumer应用发起调用时,只有在白名单中的Provider应用才会被调用。这样可以确保在灰度发布过程中,不会出现因为部分应用未升级导致的问题。
3. 验证成功后,可以逐步将其他App升级为携带Sermant Java Agent的版本,并将其加入到白名单中。最后,删除App的旧版本。
Sermant作为专注于服务治理领域的字节码增强框架,致力于提供高性能、可扩展、易接入、功能丰富的服务治理体验。通过采用Sermant对SOA/ESB架构进行升级,企业和组织可以更快速地实现云原生的微服务架构改造,从而提高业务运营效率和降低成本。
本文主要介绍了SOA/ESB架构的简介和问题,以及如何使用Sermant对SOA/ESB架构进行升级。文章认为Sermant采用Java Agent来动态注入增强的服务逻辑治理,并且其核心逻辑是以AOP (面向切面编程) 方式,因此在性能方面不存在sidecar形态的特别大的损耗。同时,Sermant方案在实际操作中也可以实现灰度发布,确保应用升级过程的安全可控。因此,对于分布式政企应用如何快速实现云原生的微服务架构改造,Sermant方案值得关注和尝试。
当前Sermant已在华为云云服务CSE中被集成,用户可以在华为云CSE云服务中使用相关功能。
审核编辑黄宇
-
SOA
+关注
关注
1文章
287浏览量
27466 -
ESB
+关注
关注
0文章
9浏览量
8860 -
云原生
+关注
关注
0文章
248浏览量
7949
发布评论请先 登录
相关推荐
评论