我读到过，在构建微服务时必须考虑到下面-
- 基于业务领域而非DAO等技术层拆分微服务
- 所有的服务必须是自包含的——我认为它不应该有很多外部依赖。例如，如果服务需要与外部DB交互并使用10个查询，那么所有这些都应该在应用程序的DAO层内，而不应该是由多个微服务共享的外部库。
我有一个现有的遗留应用程序，我计划转换成一个微服务。遗留应用程序与Couchbase DB交互。我们有连接到现有遗留应用程序中包含的couchbase db的库项目。在目前的设置中，我们使用weblogic，该应用程序部署在大约16个weblogic农场。每个应用程序创建自己到DB的连接，这导致打开到CB服务器的连接数量。
应用程序足够小&只包含一个业务域。所以我计划将整个应用程序转换为微服务。我将把它部署到关键的云代工平台上。当将应用程序部署到PCF时，我将创建应用程序的多个实例，我想我会遇到与遗留应用程序相同的问题。作为设计的一部分，我正在评估的一个选项是将DAO层暴露为另一个微服务，以便我可以限制连接到couchbase DB的数量。然而，基于我上面列出的几点，我认为这不是一个好的实践。如果我的理解有误，请告诉我。
我正在评估的另一个选项是在PCF中使用用户提供的服务来建立到couchbase服务器的连接。然而，我不确定这是否创建了一个可以被所有部署的应用程序使用的连接池。
请让我知道你对上述方法的看法，以及是否有任何其他推荐的方法。谢谢你。
您描述的计划将把一个遗留应用程序转换为一个"微服务"，该服务将与许多实例一起运行(在最后16处)。正如你所说，这给你留下了和以前一样的问题。
主要的问题似乎是数据库。所有实例只有一个数据库，这就是瓶颈。但是您有了couchbase，因此您可以使用集群并获得可伸缩性。
如果您真的想使用微服务，您需要将遗留应用程序拆分为更小的部分，每个部分只处理业务域的一部分。
在许多微服务之间共享一个数据库是一种已知的反模式，正如您在案例中看到的那样。
每个微服务只负责域的一部分，每个微服务只需要访问数据库的一个子集。理想情况下，每个微服务都有自己的数据库，允许自由选择持久化技术、缓存和其他优化。
这就是你可以从微服务中获得的好处。这不是免费的，它需要一些努力来做好。
关于共享外部库我不认为共享技术库是一个问题。无论如何你都要这样做，例如spring boot。
如果您共享与业务领域相关的库，则确实会出现问题。这意味着，许多微服务都关注同一件事。这与"关注点分离"是相反的，而"关注点分离"是微服务的主要目标之一。services.