rest - 从传统架构向微服务架构的转变

Question

我想讨论一下从胖数据库到微服务架构的转变。

一些历史:因此，我们有一个遗留贷款申请系统，它将客户详细信息捕获到包含 1000 多个表的 FAT 数据库中。该应用程序所做的不仅仅是捕获贷款，还构建了 100 多个超出贷款捕获范围的屏幕/流程。如管理、报告、配置等。

当前状态:整个表示层、逻辑层、DB 层、ORM 层都是一个项目的一部分。

当前手头的任务:该应用程序是在 Win Forms 中构建的，我的工作是将其转换为现代 UI，因为我们需要现代功能。

方法:我采取的方法是在当前的数据库结构上构建一些微服务。使用相同的DB将允许当前应用程序按原样运行，并且我们可以在一些微服务中编写新的DB层、逻辑层。然后我们可以编写将使用这些服务的现代用户界面(Angular/React)。第二步将停止使用旧应用程序的捕获操作。

第三步是将特定数据库表从旧数据库移至它们自己的数据库。

这种方法似乎最好保持当前操作按原样运行。此外，这种方法允许我们在生产环境上并行运行两个应用程序。

困惑:我的问题是关于详细设计。我正在努力理解微服务中的上下文分割。第一次迭代范围内的信息为:- 一些资格问题- 联系方式- 应用程序要求- 银行明细- 收入详情- 费用明细- 以前的贷款信息

我想要的微服务是 - 申请服务 - 质量问题 - 应用程序要求 - 以前的贷款信息 - 收入/支出详情 - 人口统计信息 - 银行明细 - 联系方式

问题:- 从遗留系统到微服务，这种方法听起来正确吗？- 微服务 split 。有人可以建议这是否正确吗？

提前非常感谢。问候高拉夫·夏尔马

Answer 1

你说过:

built some Micro Services on current DB Structure

我认为这从根本上来说是错误的做法，我敦促您考虑替代方案。这种方法的问题是，它将导致与现在相同级别的耦合和相互依赖。您只是在 SQL 层之上引入一个额外的 HTTP 层，然后可能会将逻辑推送到 UI 中。

如果您希望具有长期的可维护性，则必须最大限度地减少微服务之间的相互依赖性。基本上，微服务需要能够独立于其他微服务来完成其工作。

看看Self-Contained Systems .

诚然，通过 HTTP 镜像 SQL 接口(interface) (CRUD) 更容易做到，如果您愿意，有一些框架可以为您做到这一点，但它最终不会使架构变得更好。