如何优雅兼容公有云和私有化？腾讯低代码混合云「可分可合」架构值得借鉴

腾讯技术工程官方号

发布于 2023-11-01 14:59:56

4490

发布于 2023-11-01 14:59:56

文章被收录于专栏：腾讯技术工程官方号的专栏腾讯技术工程官方号的专栏

作者 / 腾讯高级后台开发工程师 anson

喇叭 / 涨技术知识，关注“腾讯低代码”公众号

👉导读

「架构设计」没有放之四海而皆准的方法。“软件架构不像桥梁和房屋的架构。桥梁建成后就很难改变，但软件不一样。软件一旦运行起来，我们就可以更深入地了解我们的工作负载，然后再选择一个可演进的架构，在不影响客户体验的情况下进行更改。并且我们没有强制要求特定的架构风格。我想重申，没有一种架构模式可以满足所有的情况，单体没有消亡（恰恰相反），可演进的架构也在不断变化的技术格局中扮演着越来越重要的角色。

本文是由微搭高级后台开发工程师 anson，从技术角度与大家一起探讨微搭低代码作为腾讯推出的服务海量企业的 To B 产品，在满足传统行业的安全合规性以及开发体验便利性上，「混合云」版本的架构设计是如何思考的。

👉目录

1、微搭混合云概述：为什么要做混合云

2、微搭在混合云的落地实践

3、挑战1：如何同时支持微服务和单体架构，满足可分&可合

4、挑战2：私有化底座如何保持与公有云同步

5、从微服务转单体架构的架构升级成果

6、总结

前言

大家好，我是 anson。做过 To B 项目的开发者朋友都知道，传统行业为了满足安全合规等问题，大多会要求采购的软件需要在本地化环境部署运行。

在这种场景下，传统的私有化部署依赖客户的 IDC 资源，若资源需求量太重，对客户来讲直接增加了大量成本，那么To B 产品优雅地进行架构设计就非常重要了。

基于此，微搭低代码是如何设计的，使最终资源需求量下降90%、版本类运维量降为0，让这款服务海量企业的低代码产品实现“轻装上阵”的呢？

本文重点介绍如何通过技术手段解决其中的2个痛点。一个是用户 IDC 内的资源很少，如何通过技术将微服务支持可分可合。另外一个痛点是如何解决公有云服务组件升级了，混合云（产物运行底座）没有及时升级导致的功能不支持。

微搭混合云概述

容我先简单介绍「微搭低代码」、「混合云」、「微搭混合云」几个概念。

微搭低代码作为腾讯云自研、为开发者打造的高效低代码平台，可通过可视化拖拉拽的方式轻松搭建微信小程序和企业生产管理系统。

混合云是一种混合计算环境，其中结合使用不同环境（公有云和私有云，包括本地数据中心或“边缘”位置）中的计算、存储空间和服务来运行应用。

微搭混合云这里指的是应用的开发在公有云上，开发完后的应用产物运行部署在客户 IDC 内。

1.1 微搭为什么要做混合云

传统的私有化是将所有的计算+存储私有化，但是微搭低代码平台作为开发+运行平台，不仅承担了开发工具的职责，也承担了运行部署平台。在传统行业渗透数字化的过程中，除了特定金融等行业，大部分行业需要的只是产物私有化（也即开发后的应用包部署和运行在私有化环境），如果开发工具能够继续使用公有云的平台，这样开发效率还可以随着公有云迭代随时享受最新的便利性。基于此，重点来了，微搭推出混合云模式，也就是将开发工具公有云，应用部署私有化。

1.2 混合云的开发模式

微搭是集应用页面设计和后台运行环境一体化低代码应用构建平台，默认方式支持公有云模式；同时微搭也支持私有化方式支持数据不能存在公网的情况，是微搭应用私有化部署方式，为混合云模式。

混合云的开发模式，包含两大核心模板：公有云设计开发和私有化应用运行。从应用的开发中，两个场景覆盖的应用生命周期如下：

微搭在混合云的落地实践

2.1 混合云形态

微搭低代码整体上分为两部分：设计态和运行态。

设计态在公有云，运行态在私有云的特性，称为混合云。

设计态：应用工作区，用来开发应用，把开发好的应用构建发布成物料；
运行态：应用运行环境底座，基于设计态开发好的物料，做部署安装。

2.2 混合云架构

基于这种业务形态，结合我们公有云本身就是微服务的架构体系。我们快速落地了混合云（运行态）的架构（1.0版本），微搭低代码混合云的整体架构，包含基础服务、网关服务、服务控制、容器平台以及支撑组件。

基础服务负责前端和后端 api 的接入，通过 DNS 、 LB 将用户请求分发到不同区域的控制台；
网关服务负责对后端和前端流量分别进行处理；
服务控制包含了所有微搭所有的服务组件（微服务粒度20+），包含权限控制，数据模型，流程，消息中心，应用管理，企业工作台管理等；
支撑组件，包含 Mysql 、 MongoDB 、 Redis 、 Kafka 、 S3 对象存储等。

我们1.0的架构推进过程中，也遇到了一些问题挑战：

1、微服务粒度20+ ，针对私有化场景下客户机器数量有限。有没有一种方案可实现可以同时支持微服务和单体架构？

2、客户在公有云设计态开发的应用（公有云底座产品能力实时迭代），应用发布到混合云上，由于混合云底座是部署时的老版本，导致开发的应用发布到混合云功能会出现因为功能不支持导致的报错。

下面我们来看下，微搭在这两个挑战上是如何解决的？

挑战1：可分&可合

3.1 概念

有没有一种方案可实现同时支持微服务和单体架构？

微服务是「可分」
单体架构是「可合」

我们要支持公有云的架构是「可分」，私有化的架构是「可合」，并且原则是：以公有云的微服务架构为基准。

3.2 架构演进

那这块我们的思路是：「可分」单个微服务可以编译成单个进程，「可合」也可以编译成子模块集成到大进程中这样相当于把N个进程从架构上演变成了1个进程。

3.3 方案实现

3.1 方案设计

原则是：以公有云的微服务架构为基准，通过搭建一个单体应用的 Spring 启动框架，通过 dependency 将微服务的 jar 引入进来，通过 @ComponentScan 来排除掉各个子进程的启动类只启动单体应用的进程，进而达到N个进程合并成1个进程的效果。

单体架构应用：没有任何逻辑，只有启动类和一个配置文件。

单体应用启动类伪代码如下：

@EnableFeignClients
@ComponentScan(basePackages = {"com.xxx"},
        excludeFilters = {@ComponentScan.Filter(
        type = FilterType.ASSIGNABLE_TYPE,
        classes = {
                com.xxx.AApplication.class,
                com.xxx.BApplication.class,
                com.xxx.CApplication.class,
                com.xxx.DApplication.class,
                com.xxx.EApplication.class,
                com.xxx.FApplication.class,
                省略xxxxxxx.class 
        }
)}
)
@SpringBootApplication
public class AllInOneApplication {

    public static void main(String[] args) {
        SpringApplication.run(AllInOneApplication.class, args);
    }
}

3.2 具体改造

3.2.1 每个微服务的数据库合成一个数据库

针对微服务使用不同的 database ，这块混合云统一合成一个 database ，由统一的 datainit 服务来完成数据库的创建和初始化。

3.2.2 每个微服务yaml合并一个yaml

所有微服务的 yaml 针对存量的key 统一做合并，新增的 key 统一加下微服务前缀标识来区分，确保每个微服务的 key 各不相同。

3.2.3 bean 冲突改造

如果各个业务中存在同名的 bean ，在 Spring 启动的时候，会基于 name 加载到Spring 容器中，造成 Spring 启动失败，为了避免 Bean 冲突。

有以下处理策略：

1、每个微服务修改包名，基于「领域」修改包路径。例如：权限加 auth 、流程加 flow 等。

2、如果业务中存在通过之前 name 来注入 Bean 的。比如 @Bean(name="") 、@Resource(name="")、@Autowired(name="")、@Service(name="")、@Qualifier(name="")等，建议加上业务「领域」属性，避免冲突。

3.2.4 pom.xml 改造

原来公有云 pom.xml 有 dev 、 test 、 pre 和 prod 的对应的 profile ，增加一个私有化所对应的 profile 节点 private ，这样对公有云构建和编译也不受任何影响。

在单体流水线构建出包的时候，各个微服务的 SPRING_PROFILE = private

mvn clean install-DskipTests-P$SPRING_PROFILE-s../settings.xml

另外需要注意的地方，需要在 private 节点中移除 spring-boot-maven-plugin 的maven plugin 和排除掉微服务中的 resources 配置文件。

（因为配置文件已经统一合并成一个了，在单体项目中引入即可）

# 私有化环境
<profile>
    <id>private</id>
    <build>
         <resources>
                    <resource>
                        <directory>src/main/resources</directory>
                        <filtering>true</filtering>
                        <excludes>
                        <exclude>application.properties</exclude>
                            <exclude>bootstrap.yaml</exclude>
                            <exclude>bootstrap.yml</exclude>
                            <exclude>application.yaml</exclude>
                            <exclude>application-*.yaml</exclude>
                            <exclude>application.yml</exclude>
                            <exclude>application-*.yml</exclude>
                        </excludes>
                    </resource>
                </resources>
    </build>
<profile>

3.3 合流 + 自动化测试保障单体架构

为了保证单体应用功能的正确性，我们在公有云合流阶段做了流水线，当公有云微服务代码合并主干分支时触发「单体应用」构建&部署。如果部署成功，会执行自动化测试用例来提前发现私有化功能上的一些问题（通过技术手段来保证：用来检测每个微服务 yaml、Bean 要互斥，不能出现同名的 key 和同名的 Bean ）。