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