我已经读过，在构建下面的微服务时必须考虑到这一点 -
我有一个现有的遗留应用程序，我打算将其转换为微服务。遗留应用程序与Couchbase DB交互。我们有一个库项目，它连接到现有遗留应用程序中包含的couchbase数据库。在当前设置中，我们使用weblogic，该应用程序部署在大约16个weblogic服务器场中。每个应用程序都会创建自己与DB的连接，这会导致向CB服务器打开连接数。
该应用程序足够小＆amp;仅包含一个业务域。所以我打算将整个应用程序转换为微服务。我将把它部署到关键的云代工平台上。在将应用程序部署到PCF时，我将创建应用程序的多个实例，我想我将遇到与旧应用程序相同的问题。作为设计的一部分，我正在评估的一个选项是将DAO层暴露为另一个微服务，以便我可以限制与couchbase数据库的连接数。但是根据我上面列出的要点，我认为这不是一个好习惯。如果我的理解不正确，请告诉我。
我正在评估的另一个选项是在PCF中使用用户提供的服务来建立与couchbase服务器的连接。但是我不确定这是否会创建一个可供所有已部署应用程序使用的连接池。
请告诉我您对上述方法的看法，以及是否有其他推荐方法。谢谢。
答案 0 :(得分：1)
您所描述的计划会将一个遗留应用程序转换为一个“微服务”，该服务将在许多实例中运行（再次在结束时16）。正如你所说，这会给你留下与以前一样的问题。
主要问题似乎是数据库。所有实例只有一个数据库，这就是瓶颈。但是你有沙发基础，所以你可以使用集群并获得可扩展性。
如果您真的想使用微服务，则需要将旧版应用程序拆分为较小的部分，每个部分仅处理业务域的一部分。
在许多微服务中共享一个数据库是一种已知的反模式，如您所见。
每个微服务只负责域的一部分，每个只需要访问数据库的一个子集。理想情况下，每个微服务都有自己的数据库，允许自由选择持久性技术，缓存和其他优化。
这是您可以从微服务中获得的好处。这不是免费的，它需要一些努力才能做到正确。
关于共享外部库 我不认为共享技术库是一个问题。无论如何你都是这样做的，例如春季靴子。
如果您共享与业务域相关的库，确实会出现问题。这意味着许多微服务都关注同一件事。这与“关注点分离”相反，微观服务是服务的主要目标之一。