云原生架构优化——架构改造迁移

xuyijing0103

已于 2023-10-20 11:21:13 修改

阅读量253

点赞数

分类专栏：云原生K8S系统架构优化文章标签：云原生架构微服务 spring cloud dubbo

于 2023-10-17 15:31:28 首次发布

本文链接：https://blog.csdn.net/weixin_53439529/article/details/133880413

版权

云原生K8S系统架构优化专栏收录该内容

6 篇文章 0 订阅

订阅专栏

【摘要】

微服务Apache Dubbo架构改造Spring Cloud架构，并迁移上HW云。

【背景】

最近辅导某系统建设，方案要求用云原生架构，系统开发完全基于云原生架构，目前在做微服务改造和迁移，计划拆分为对内和对外两个子系统，对外系统采用微服务SpringCloud 架构，内部系统采用微服务Dubbo架构。用政务云上的CCE和CSE（微服务管理平台）建设，当然还有其他云服务，不做赘述。

【问题】

1、内部系统用微服务Apache Dubbo架构，对应的政务云厂商CSE是ServiceComb框架，支持SpringCloud 框架，但不支持Dubbo，需做架构改造。

2、改造完成后如何做迁移？

【过程及解决方案】

【初步解决思路】

1、是否有不做框架改造的方式，比如采用某种中间件或Agent；

2、评估Dubbo 框架改SpringCloud 框架的难度及工作量，改造方案；

3、改造后迁移的方案。

【微服务框架】

（来源《阿里云原生架构白皮书》）：
过去传统软件开发框架基本都是牵一发而动全身的大单体架构，为了解决由单体应用模型衍生的过度集中式项目迭代流程，微服务模式应运而生。微服务从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。进入云原生时代，容器化和K8S容器引擎得以充分利用云资源的高可用和安全体系，让应用获得更有保障的弹性、可用性与安全性。应用构建在云所提供的基础设施与基础服务之上，充分利用云服务所带来的便捷性、稳定性，降低应用架构的复杂度。云原生的微服务体系也将帮助应用架构全面升级，让应用天然具有更好的可观测性、可控制性、可容错性等特性。
云原生时代微服务架构的演化也经历了多个阶段，由此产生了多种多样的微服务框架。目前主流的是SpringCloud框架，但是SpringCloud也是经历了时间的积累才有今天的使用度，而当它称为最流行的开发框架的时候，某种程度上也面临了前辈们的局面：新的框架又开始准备替代它了。

典型的架构模式按出现的先后顺序大致分为四代：
第一代：微服务架构中，应用除了需要实现业务逻辑之外，还需要自行解决上下游寻址、通讯，以及容错等问题。随着微服务规模扩大，服务寻址逻辑的处理变得越来越复杂，哪怕是同一编程语言的另一个应用，上述微服务的基础能力都需要重新实现一遍。
第二代：微服务架构中，引入了旁路服务注册中心作为协调者来完成服务的自动注册和发现。服务之间的通讯以及容错机制开始模块化，形成独立服务框架。但是随着服务框架内功能日益增多，用不同语言的基础功能复用显得十分困难，这也就意味着微服务的开发者被迫被绑定在某种特定语言上，从而违背了微服务的敏捷迭代原则。
第三代：服务网格。原来被模块化到服务框架里的微服务基础能力，被进一步的从一个SDK 演进成为一个独立进程 - Sidecar。这个变化使得第二代架构中多语言支持问题得以彻底解决，微服务基础能力演进和业务逻辑迭代彻底解耦。这个架构就是在云原生时代的微服务架构 - Cloud Native Microservices，边车（Sidecar）进程开始接管微服务应用之间的流量，承载第二代中服务框架的功能，包括服务发现、调用容错，到丰富的服务治理功能，例如：权重路由、灰度路由、流量重放、服务伪装等等。
第四代：近两年开始使用的Serverless架构。在这个架构中，微服务进一步由一个应用简化为微逻辑（Micrologic），从而对边车模式提出了更高诉求，更多可复用的分布式能力从应用中剥离，被下沉到边车中，例如：状态管理、资源绑定、链路追踪、事务管理、安全等等。同时，在开发侧开始提倡面向 localhost 编程的理念，提供标准 API 屏蔽掉底层资源、服务、基础设施的差异，进一步降低微服务开发难度。这个也就是目前业界提出的多运行时微服务架构（Muti-Runtime Microservices）。
明显能看出来，微服务的整体演进方向就是把越来越多的可复用能力从应用中剥离出来，让应用尽量实现业务该实现的功能，而涉及到底层资源、配置、服务发现、服务治理和运维特性这些与业务无关但是却影响业务正常使用的关键特征，通过更高维度的抽象沉淀到下层去。也就是业务的归业务，运维的归运维。

在这些年微服务演进的过程中，形成了多种微服务框架，带有明显的代际差异：

1. Apache Dubbo：是源自阿里巴巴的一款开源高性能 RPC 框架，自带智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。面世较早，已是国内使用最广泛的微服务框架之一，而且构建了强大的生态体系并开源了： Spring Cloud-Alibaba( 分布式应用框架 )、Nacos( 注册中心 & 配置中心 )、Sentinel( 流控防护 )、Seata( 分布式事务 )、Chaosblade( 故障注入 )。不得不说阿里确实有两把刷子，目前Dubbo 也在发展 Service Mesh。

2. Spring Cloud：是主要微服务选择之一，集成了配置管理、服务发现、断路器等能力和开发工具。尤其是 Java 作为主流的开发语言，Spring Cloud提供了java微服务开发的基础编程模型，同时也能够丝滑接入Service Mesh 架构。

3. TAF：是腾讯将其内部使用的微服务框架 TAF开源的项目，自带服务治理和多语言支持等。

4. ServiceComb：来源于华为微服务引擎（CSE），2017年开源。

5. Dapr（Distributed Application Runtime ，分布式应用运行时）是微软新推出的，一种可移植的serverless框架。

本项目中采用的华为云CSE是用于微服务应用的云中间件，兼容Spring Cloud、ServiceComb，如果是ServiceComb应用，可以零代码修改接入；如果是Spring Cloud应用，做少量修改也可以接入；如果是Dubbo框架，就不能直接接入了。

【过程】

1. Sermant Agent

官网给了一个Sermant Agent 的说明，是一种基于JavaAgent的无代理服务网格技术。自带通过Sermant Agent注册到ServiceComb引擎中的功能，叫做标签路由。通过匹配dubbo attachment中的信息，把符合规则的流量转发到对应的标签应用中，从而实现标签路由的功能。

但是该方案仅支持的版本为Dubbo 2.6.x - 2.7.x，而且只在公有云的个别AZ开放了这个功能。项目中使用的Dubbo框架为2.0版本，框架升级不现实。

2. Dubbo框架改造为Spring Cloud框架并接入ServiceComb引擎。

一个框架改造为另外一个框架的工作量可以从两个维度进行评估：改造前的业务代码依赖于原来框架/运行时的程度，以及目标框架本身对于业务代码采用的技术的支持程度。
根据大佬发布的各个框架切换CSE的难度对比，Dubbo切CSE为中(4)。

应用系统迁移华为云评估-云社区-华为云 (huaweicloud.com)

将 Dubbo 迁移 Spring Cloud，主要需要解决如下几个问题：

将 RPC 接口定义修改为 REST 接口定义；
将 RPC 接口调用修改为 Feign 接口调用；
修改依赖关系和配置文件；

其他常见问题修改，包括启动类修改、解决三方软件冲突等。

https://github.com/huaweicse/migrator/wiki/dubbo-2-cse

其实单纯从技术角度来说可能工作量并不大，对于多数项目，可以通过migrator一键式完成改造。但是这个改造很考验团队原代码标准度和对新框架的熟悉度，比如：
ModifyDubboAction包含如下操作，分别完成不同的改造任务：

ModifyDubboServiceAction

ModifyDubboServiceAction的主要功能是扫描目录下面的所有JAVA文件，识别文件是否包含 @DubboService 标签，如果存在，将其替换为 @RestController。

ModifyDubboReferenceAction

ModifyDubboReferenceAction的主要功能是扫描目录下面的所有JAVA文件，识识别文件是否包含 @DubboReference 标签，如果存在，将其替换为 @FeignClient。

ModifyDubboInterface2RestAction

ModifyDubboInterface2RestAction的主要功能是扫描目录下面的所有JAVA文件，首先扫描出包含 @DubboService 标签的文件，并从中解析出需要处理的 JAVA interface文件，
然后将 interface 文件修改为 REST 风格。

ModifyDubboAddBootstrapYamlAction

ModifyDubboAddBootstrapYamlAction的主要功能是在项目的 src/main/resources 目录下添加 bootstrap.yml 文件。会在根目录，以及根目录的第一级子目录查找 src/main/resources 目录。

ModifyDubboMainClassAction

ModifyDubboMainClassAction的主要功能是扫描目录下面的所有JAVA文件，识别文件是否包含main函数，并将相关 @EnableDubbo 逻辑改为 Spring Boot。

ModifyDubboPomAction

ModifyDubboPomAction的主要功能是扫描目录下面的所有POM文件，删除Dubbo相关的依赖、插件，增加Spring Cloud相关的依赖、插件。
可以看出来很多modify严重依赖于原来项目里面的标签等，原来的代码标准和质量就非常关键了，由项目自行评估能否改造及工作量。

3. 改造后接入CSE

如果已经是Spring Cloud 应用，无需修改代码，使用 spring cloud-huawei 可接入CSE 。是构建在Spring Cloud应用之上，基于Spring Cloud现有能力构建的，Spring Cloud huawei提供的一系列新的组件。

A、引入依赖包。

<dependency>
<groupId>com.huaweicloud</groupId>
<artifactId>spring-cloud-starter-huawei-service-engine</artifactId>
</dependency>

<dependency>
<groupId>com.huaweicloud</groupId>
<artifactId>spring-cloud-starter-huawei-service-engine-gateway</artifactId>
</dependency>

B、接入服务注册发现中心

spring:
application:
name: basic-provider
cloud:
servicecomb:
discovery:
enabled: true
address: http://127.0.0.1:30100
appName: basic-application
serviceName: ${spring.application.name}
version: 0.0.1
healthCheckInterval: 30
config:
serverAddr: http://127.0.0.1:30113
watch:
delay: 10000

C、配置微服务信息和CSE引擎信息

# Configure AK/SK credentials if needed. Default not enabled.
credentials:
enabled: true
accessKey: your AK
secretKey: your SK
akskCustomCipher: default
project: cn-north-4