【发布时间】：2016-11-23 14:46:48
【问题描述】：
我正在尝试将我们当前的单体 Web 应用程序重新架构为更加模块化（微服务）风格的设计。
我对边界和如何构建它的计划有一个很好的想法......
应用程序的每个部分都有自己的域包、一个后备的 api 和一个用于管理数据的 Web 前端。加上其他东西，比如单元测试和可能的连接帮助库等。
为了论证，假设我的单体应用有 3 个主要组件（模块）：
- 用于创建和管理用户的帐户模块
- 用于管理和管理产品的产品模块 目录
- 一个订单模块，用于创建、查看和修改订单。
在单体应用程序中，这些都是同一个应用程序（以及 VS 解决方案和项目）的一部分，并且通常具有使用 MVC / WebApi 等配置的不同控制器：
// MyApp.Web Project (base url ~/)
myapp.com/...
myapp.com/accounts/...
myapp.com/products/...
myapp.com/orders/...
// MyApp.Api Project (base url ~/api)
myapp.com/api/...
myapp.com/api/accounts/...
myapp.com/api/products/...
myapp.com/api/orders/...
目前我们使用嵌套应用程序和虚拟文件夹在 IIS 中托管它，但我想使用服务结构集群复制这种想法或结构。但是每个孤立的区域（帐户、产品、订单）都将相互独立地开发和部署。
如何配置 Service Fabric 集群以启用这种情况？
例如，如果我有一个由 50 个节点组成的集群，并且在这 50 个节点上，我的实例分布在每个服务和服务的 api 之外。怎么说呢：
v2.myapp.com/accounts --> any available accounts web UI instance?
v2.myapp.com/products --> any available products web UI instance?
v2.myapp.com/api/products --> any available products api instance?
我应该为 web 和 api 提供一个 VM Scale Sets，还是为每个组件提供一个 VM Scale Sets，例如仅用于产品 api 的 VM Scale Sets 和另一个用于订单 Web UI 等的 VM Scale Sets？
另外请注意，我们的系统很大，所以有很多组件，因此拆分单体样式的原因，所以我需要一个一致的结构来实现这一切。
我们存在主要的可扩展性问题和非常缓慢的（手动）虚拟服务器配置。加上一个单一的整体 SQl Server 数据库。我想要的 SF 的特点是模块化设计、易于配置和部署，以及我们系统的响应时间和吞吐量的大幅增加。当然还有很好的故障转移。
归根结底，我希望客户看到一致的 url 结构，但在幕后，我希望能够将它们全部分开并在多个节点上协同工作。
提前致谢。
非常感谢任何有关如何配置它的帮助。
G.
【问题讨论】：
-
是否有任何理由不将当前解决方案拆分为具有多个项目的多个解决方案？据我了解，SF 的优势在于平衡工作负载和处理故障转移。如果你现有的应用程序中没有这样的问题，只是想解耦模块，也许不使用 SF 会更好？换句话说，您想使用 Service Fabric 的哪个功能？
-
@cassandrad 我们存在重大的可扩展性问题和非常缓慢的（手动）虚拟服务器配置。加上一个单一的整体 SQl Server 数据库。我想要的 SF 的特点是模块化设计、易于配置和部署，以及我们系统的响应时间和吞吐量的大幅增加。当然，正如您所说的良好的故障转移。归根结底，我希望客户看到一致的 url 结构，但在幕后，我希望能够将它们全部分开并在许多节点上协同工作。有意义吗？
-
也许这一切都是通过负载均衡器完成的？
-
@GaryDoublé，是的，这是有道理的。我认为重写您当前的应用程序并制作您提到的所有内容的努力将非常非常巨大并且可能需要很多时间，尤其是当您说您有一个大应用程序时。现在我看到您需要更多新功能而不仅仅是模块化，因此在这种情况下使用 SF 是合适的。您可以将您在评论中提到的内容添加到帖子中吗？
标签： deployment configuration microservices azure-service-fabric