我们有一个带有巨大 oracle 数据库的大型单体应用程序。我们希望将应用程序迁移到使用容器的微服务架构，而无需在数据库级别做太多事情。稍后我们将更改数据库。
隔离服务的最佳方法是什么？我们应该做些什么来减少下一阶段更改数据库时的痛苦？
当您有多个进程（每个服务一个）时，在数据库级别不会有问题吗？
【问题讨论】：
标签： architecture containers microservices
重构应用程序的处理方面而不重构应用程序使用的数据可能会导致问题，其中之一是技术债务负担不断增加。由于您在大型 RDBMS 中“免费”获得了很多一致性，您是否还计划推迟所有基于事件的异步通知和更新的实现，您需要添加以支持每个服务？如果这些端点甚至还没有被识别出来，那么在微服务初始完成之后，您似乎需要重构的不仅仅是数据库。除了独立于数据库结构的核心业务逻辑之外，一旦您分解了数据库，就可以期待这些微服务的另一次迭代开发。
是的，当您有多个进程时，您可能会在“数据库级别”遇到问题。问题是，现在在您的单体应用中，您的事务可能跨越属于（或服务于）多个业务域的表——这些域可能注定要驻留在不同的微服务中。
我建议采用更全面的方法，将数据库和单体架构一起逐步重构为微服务。选择一个易于隔离的单体应用程序并从它开始。它可以包含几个 REST 端点的小型 API，并将其数据分离到自己的表中。对于 REST GETS，使用您喜欢的任何方法将数据从单体数据库移动到这些表以保持它们同步。对于持久性方法，使用事件队列和简单服务来更新微服务数据存储中的整体数据。然后继续下一个服务。随着您的继续，您可以开始停用服务以及用于维护微服务模式和整体数据库模式之间的数据一致性的任何其他机制。在没有积累未知数量的技术债务的情况下，甚至可以在实施前几个用户故事后更好地预测项目结果！
【讨论】：
Oracle 数据库是在 PCF 基础中注入的。您可以按以下方式执行此操作..
一旦将 db 注入 pcf，您就可以创建服务实例并将其绑定到您的应用程序。
更改将针对您的应用。您将不得不对其进行重构，以从云环境中获取数据库详细信息。其余的交互可以保持不变。
关于将您的单体应用程序转换为微服务，有不同的方法。何时使用取决于具体情况以及组织接受变化的能力和意愿。
一种常见的称为“绞杀模式”。这种方法允许您逐步将单体应用迁移到微服务。在这种方法中，您提取高价值特征，并将它们转换为微服务。然后，旧的单体应用要么忽略这些特性，要么重构为调用这些微服务。
还有其他一些必须解决的问题。它们包括会话处理、记录到文件等。
希望这会有所帮助！
【讨论】：