我有一个支持订购的现有Web服务，它有多个操作（大约20个）。这是一个支持订购功能的单一Web服务。它与多个其他服务交互以提供订购功能。
由于这个应用程序中有很多业务功能，并且它由10个成员团队支持，我相信它是一个整体（虽然我认为没有硬性和快速的规则来定义整体是什么）。
我们计划在云代工厂环境中部署应用程序，我们计划将应用程序拆分为2-3个微服务，主要是为了使它们能够独立扩展。
能够搜索产品的前几个api通常具有更多的命中数，而支持实际订单提交的api获得的命中率低于5％。因此，与订单提交api相比，产品搜索API应具有更多的实例数。
虽然我不确定我们是否可以拆分是基于子域（我已经读过的应该是基础），但我们正在考虑根据前面解释的调用序列来拆分它们。
我还读到微服务应该编排而不是精心策划。然而，为了确保我们现有的消费者不受影响，我相信我们应该公开一个api层，它将协调对这些微服务的调用。提供api网关，遵循的常规方法是确保消费者不会最终调用多个微服务并提供一层抽象？
这似乎比编排更多的是编排 - 尽管我并没有在理论方面陷入困境，但我想了解在企业界中为这个问题陈述所采用的不同解决方案。
答案 0 :(得分：5)
我建议根据域拆分您的服务。这是一种合乎逻辑且有效的方法，使其成为一个简单的起点。您的整体包结构可能已经以这种方式组织，这进一步简化了重构。
典型的Spring Cloud方法是在网络边缘使用Zuul Proxy，它接收来自客户端（Web，移动设备等）的请求，并将它们路由到防火墙后面的微服务。客户端只与单个域接口，它可以开箱即用地处理CORS。
资源：