我想讨论从胖DB到微服务架构的转换。
有点历史： 因此，我们有一个传统的贷款申请系统，它将客户详细信息捕获到一个包含1000多个表的FAT数据库中。该应用程序不仅仅是捕获超过贷款捕获的100多个屏幕/流程的贷款。像管理，报告，配置等。
当前状态： 整个表示层，逻辑层，DB层，ORM层是一个项目的一部分。
当前的任务： 该应用程序是在Win Forms中构建的，我的工作是将其转换为Modern UI，因为我们需要现代功能。
方法 我采取的方法是在当前的数据库结构上构建一些微服务。使用相同的DB将允许当前应用程序按原样运行，并且我们可以在某些微服务中编写新的DB层，逻辑层。然后我们可以编写将使用这些服务的现代用户界面（角度/反应）。 然后，第二步将停止使用遗留应用程序中的捕获操作。
第三步是将特定数据库表从旧数据库中移出到自己的数据库中。
通过保持当前操作按原样运行，这种方法似乎是最好的。此外，这种方法允许我们在生产环境中并行运行两个应用程序。
混乱： 我的问题是详细设计。我正在努力理解微服务中的上下文分裂。第一次迭代范围内的信息是： - 一些资格问题 - 联系方式 - 应用程序要求 - 银行明细 - 收入详情 - 费用详情 - 以前的贷款信息
我想要的微服务是 - 申请服务 - 质量问题 - 应用程序要求 - 以前的贷款信息 - 收入/支出详情 - 人口统计信息 - 银行明细 - 联系方式
问题： - 从遗留到微服务，这种方法听起来是否正确？ - 微服务分裂。有人可以建议这是对的吗？
提前多多感谢。 问候 Gaurav Sharma
答案 0 :(得分：2)
你说过：
在当前数据库结构上构建了一些微服务
我认为从根本上说这是错误的做法，我会敦促你考虑替代方案。这种方法的问题是，它将导致您现在拥有的相同级别的耦合和相互依赖性。您只是在SQL之上引入了一个额外的HTTP层，并且可能正在将逻辑推送到UI中。
如果您希望具有长期可维护性，则必须尽量减少微服务之间的相互依赖性。基本上微服务需要能够独立于其他微服务完成工作。
不可否认，通过HTTP镜像SQL接口（CRUD）更容易，如果需要，还有一些框架可以帮助您，但最终不会使架构更好。
答案 1 :(得分：0)
微服务的巨大优势在于您可以采用渐进式方式采用迁移项目，因此我会尝试确定可以迁移的各个功能，并允许您快速获得，避免大-ban方法。
您面临的最大挑战可能是了解您的第一个微服务的适当粒度。它必须有多大或多小。
一个很好的参考点是微服务应该尝试遵循principle of single responsibility，并且通常所有SOLID principles也适用。
如果你的DB很胖，你可能会有许多外出钥匙，你必须仔细计划如何面对database per service pattern
这篇文章也可能有所帮助'How Small Should Microservices Be?'