从传统架构到微服务架构的转变答案

【问题标题】：Transformation from Legacy to Microservices architecture从传统架构到微服务架构的转变
【发布时间】：2018-03-01 03:46:27
【问题描述】：

我想讨论从胖 DB 到微服务架构的转变。

一点历史： 所以我们有一个遗留的贷款申请系统，它将客户详细信息捕获到一个包含大约 1000 多个表的 FAT 数据库中。该应用程序所做的不仅仅是通过构建超过贷款捕获的 100 多个屏幕/流程来捕获贷款。比如管理、报告、配置等。

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

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

方法： 我正在采取的方法是在当前的数据库结构上构建一些微服务。使用同一个 DB 可以让当前应用按原样运行，我们可以在一些微服务中编写一个新的 DB 层，逻辑层。然后我们可以编写将使用这些服务的现代用户界面（角度/反应）。然后第二步将停止使用旧版应用程序的捕获操作。

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

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

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

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

问题： - 从遗留到微服务的方法听起来正确吗？ - 微服务拆分。有人可以建议这是否正确？

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

【问题讨论】：

【解决方案1】：

微服务的最大优势在于您可以采用增量方向的迁移项目，因此我会尝试确定可以迁移的各个功能，并允许您开发一个速赢，避免大- 禁止方法。

也许您面临的最大挑战是了解您的第一个微服务的适当粒度。它必须有多大或多小。

一个很好的参考点是微服务应该尝试遵循principle of single responsibility，并且通常所有SOLID principles 也适用。

如果你的DB很胖，你可能会有很多外键，你必须仔细计划如何面对database per service pattern

【讨论】：

谢谢伙计。我现在将介绍服务模式。你是绝对正确的，我正在为每个服务的数据库而苦苦挣扎。我不能只创建一个新的数据库。在我们的 UI 设计获得批准之前，不能更改现有系统。 [当你在公司工作时]

【解决方案2】：

你说过：

在当前数据库结构上构建了一些微服务

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

如果您想获得长期的可维护性，则必须尽量减少微服务之间的相互依赖关系。基本上，微服务需要能够独立于其他微服务来完成它们的工作。

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

【讨论】：

您好罗伯特，感谢您的回答。我同意原则上我所做的与微服务的定义不符。不过，摆在我面前的挑战是“在飞机飞行时更换引擎”。我不确定如何让这 2 个系统运行，更具体地说，如果我只是创建一个新数据库，那么运行一个 100 多人的大型数据仓库。我的方法完全基于为我们的 UI 获得一个独立的数据库，但仅限于迭代模式
@GauravSharma 我同意罗伯特的观点。 SOA 不仅仅是创建一堆服务。有整个 SOA 治理部分，它是 SOA 的一部分，所以你必须面对它。您不能通过重构代码来引入 SOA，但是您可以通过重构使其现代化。像您提议的那样对架构进行更改是可以的，让我们回到绘图板方法，您可能想向业务部门提及一些事情。我建议您权衡您的选择，提出一些建议，包括详细的时间表和成本。然后让业务决定。
@Namphibian 我同意你们。昨天完成了我关于领域驱动设计和微服务的书。我相信我正在做的方法是急于进入微服务架构，因为企业不愿意给时间。但这行不通。所以我现在要回到绘图板了
@GauravSharma 它是所有项目中最令人愤怒的四个：时间、金钱、范围、人力，他们需要一个非常好的 PM 来正确平衡并由业务驱动。不幸的副作用是商业有时会毁掉非常好的技术创意。