24、利用微服务迁移到云原生架构

利用微服务迁移到云原生架构

1 迁移前的架构

在开始迁移之前，系统架构主要包含以下部分：
- ContentServices ：包含目标 SDK 执行模型对象的 CRUD 操作所需的服务。
- DeveloperWebsite ：一个用 HTML 和 JQuery 编写的应用程序，作为开发者的仪表盘，借助 DeveloperServices 组件实现功能。

2 迁移至微服务架构的原因

促使我们迁移到微服务架构的是“聊天即服务”需求带来的问题。为实现该需求，我们选择了 ejabberd，因其具备内置的可扩展性且能在集群上运行。我们编写了 Python 脚本，使 ejabberd 能使用我们的系统进行身份验证。但服务的按需能力成为大问题，以下是选择微服务架构的具体原因：

2.1 可重用性需求

为解决上述问题，我们开始自动化聊天服务的设置过程，其中包括为每个用户设置数据库。我们期望这也是创建可重用的关系型数据库管理系统（RDBMS）项目的一步。然而，现有的 RDBMS 服务创建过程无法满足新需求。当前设计只是为满足 RDBMS 服务需求，与 Oracle 服务器紧密耦合，而我们需要 MySQL 数据库来支持 ejabberd。因此，我们需要一个数据库预留系统，更广泛地说，需要一个后端资源预留系统，这是创建可被系统其他部分重用的内聚服务的第一步。

2.2 去中心化数据治理需求

每次有人想添加不同服务的元数据时，都会将其添加到 DeveloperData 中，这使其成为服务间的集成点。但服务是独立单元，仅