从微服务转回单体:服务个数从21下降到2,版本类运维量降为0
# 关注并星标腾讯云开发者
# 每周3 | 谈谈我在腾讯的架构设计经验
# 第9期 | 如何优雅兼容公有云和私有化?
大家好,我是 anson。做过 To B 项目的开发者朋友都知道,传统行业为了满足安全合规等问题,大多会要求采购的软件需要在本地化环境部署运行。
在这种场景下,传统的私有化部署依赖客户的 IDC 资源,若资源需求量太重,对客户来讲直接增加了大量成本,那么 To B 产品优雅地进行架构设计就非常重要了。
基于此,微搭低代码是如何设计的,使最终资源需求量下降90%、版本类运维量降为0,让这款服务海量企业的低代码产品实现“轻装上阵”的呢?
容我先简单介绍「微搭低代码」、「混合云」、「微搭混合云」几个概念。
微搭低代码作为腾讯云自研、为开发者打造的高效低代码平台,可通过可视化拖拉拽的方式轻松搭建微信小程序和企业生产管理系统。
混合云是一种混合计算环境,其中结合使用不同环境(公有云和私有云,包括本地数据中心或“边缘”位置)中的计算、存储空间和服务来运行应用。
微搭混合云这里指的是应用的开发在公有云上,开发完后的应用产物运行部署在客户 IDC 内。
1.1 微搭为什么要做混合云
传统的私有化是将所有的计算+存储私有化,但是微搭低代码平台作为开发+运行平台,不仅承担了开发工具的职责,也承担了运行部署平台。在传统行业渗透数字化的过程中,除了特定金融等行业,大部分行业需要的只是产物私有化(也即开发后的应用包部署和运行在私有化环境),如果开发工具能够继续使用公有云的平台,这样开发效率还可以随着公有云迭代随时享受最新的便利性。基于此,重点来了,微搭推出混合云模式,也就是将开发工具公有云,应用部署私有化。
1.2 混合云的开发模式
微搭是集应用页面设计和后台运行环境一体化低代码应用构建平台,默认方式支持公有云模式;同时微搭也支持私有化方式支持数据不能存在公网的情况,是微搭应用私有化部署方式,为混合云模式。
混合云的开发模式,包含两大核心模板:公有云设计开发和私有化应用运行。从应用的开发中,两个场景覆盖的应用生命周期如下:
2.1 混合云形态
微搭低代码整体上分为两部分:设计态和运行态。
设计态:应用工作区,用来开发应用 ,把开发好的应用构建发布成物料; 运行态:应用运行环境底座,基于设计态开发好的物料,做部署安装。
2.2 混合云架构
基础服务负责前端和后端 api 的接入,通过 DNS 、 LB 将用户请求分发到不同区域的控制台; 网关服务负责对后端和前端流量分别进行处理; 服务控制包含了所有微搭所有的服务组件(微服务粒度20+),包含权限控制,数据模型,流程,消息中心,应用管理,企业工作台管理等; 支撑组件,包含 Mysql 、 MongoDB 、 Redis 、 Kafka 、 S3 对象存储等。
3.1 概念
微服务 是「可分」; 单体架构 是「可合」。
3.2 架构演进
3.3 方案实现
3.3.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})})@SpringBootApplicationpublic class AllInOneApplication {public static void main(String[] args) {SpringApplication.run(AllInOneApplication.class, args);}}
3.3.2 具体改造
# 私有化环境<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.4 合流 + 自动化测试保障单体架构
3.5 可合的服务如何与可分微服务对应
4.1 概念
4.2 方案实现
4.2.1 提出方案
那我们这块的思路是:「应用更新的时候来进行底座 pod 的更新」,相当于我们在安装应用的时候,会从镜像仓库中拉取公有云运行态对应的底座镜像版本来进行部署;
4.2.2 方案设计
因此这种需要通过建立长连接保持网络互通。
这样的话,我们也抽象出来了「混合云管理流」和「混合云数据流」的概念。「混合云管理流」:也叫混合云设计态,管理底座集群信息上报、运维、部署、升级等功能
混合云 agent 与公有云服务,建立 websocket 长链接,用于集群信息上报 ; 事件引擎用户路由 agent 下发的指令操作 ; 运行态底座服务用于支撑的应用的运行态相关功能的 operator 来 watch 底座的任务部署、升级、回滚底座等功能
5.1 架构维度
我们进行架构改造实践落地后,从之前的微服务架构变成了单体架构,微服务数量从 21 个变成 1 个(运行态:21 -> 1,设计态:0->1 ) 。
5.2 部署方向
从运行态来看:可分-微服务有 21个,可合-单体 1 个;
从设计态来看:可合单体架构下多了 1 个 pod 。
5.3 运维角度
我们进行架构改造实践落地后,解决了混合云底座运维管理事项功能,公有云上可看到混合云底座运行的状态,也可以在公有云一键来管理混合云。
5.4 资源维度
「可分」架构下 21 个服务,每个进程 4c8g ,共用 84C168G 。
「可合」架构下 2 个服务,每个进程 4c8g ,共用 8C16G 。
5.5 交付客户
同时,客户表示大大减轻了各个业务模块研发人员投入排查【底座镜像版本过低,功能报错问题】的时间。
第一时间看鹅厂架构设计经验