Service Fabric 嵌套应用程序
Service Fabric Nested Applications
我正在尝试将我们当前的整体式 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 规模集，或者每个组件也有一个 VM 规模集，例如仅产品的 VM 规模集 api 和订单 web 的另一个规模集 UI，等等？
另请注意，我们的系统很大，因此有很多组件，因此需要拆分整体样式，所以我需要一个一致的结构来启用所有这些。
我们有严重的可扩展性问题和非常慢的（手动）虚拟服务器配置。加上一个单一的 SQl 服务器数据库。我想要的 SF 的特性是模块化设计、易于配置和部署以及我们系统的响应时间和吞吐量的急剧增加。当然还有良好的故障转移。
归根结底，我希望客户看到一致的 url 结构，但在幕后，我希望能够将其全部分开并在多个节点上协同工作。
提前致谢。
非常感谢任何有关如何配置它的帮助。
G.
网关
我建议在这里使用网关模式。 ()
通过应用此模式，您将完全控制传入的 HTTP 请求的路由方式（基于版本控制、租户、运行状况等）。
vmss
将服务放在特定的 VMS 上将限制 SF 必须在其上平衡负载的选项。一个应用程序可能使用更多内存资源，另一个应用程序可能使用更多 CPU。这些可以组合在一个节点上以优化资源使用。
使用节点集来优化成本，因此可以将需要较少资源的服务放在更便宜的节点上。 （使用 placement constraints）
（同样适用于订阅量较低的租户）
我正在尝试将我们当前的整体式 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 规模集，或者每个组件也有一个 VM 规模集，例如仅产品的 VM 规模集 api 和订单 web 的另一个规模集 UI，等等？
另请注意，我们的系统很大，因此有很多组件，因此需要拆分整体样式，所以我需要一个一致的结构来启用所有这些。
我们有严重的可扩展性问题和非常慢的（手动）虚拟服务器配置。加上一个单一的 SQl 服务器数据库。我想要的 SF 的特性是模块化设计、易于配置和部署以及我们系统的响应时间和吞吐量的急剧增加。当然还有良好的故障转移。
归根结底，我希望客户看到一致的 url 结构，但在幕后，我希望能够将其全部分开并在多个节点上协同工作。
提前致谢。
非常感谢任何有关如何配置它的帮助。
G.
网关
我建议在这里使用网关模式。 (
通过应用此模式，您将完全控制传入的 HTTP 请求的路由方式（基于版本控制、租户、运行状况等）。
vmss
将服务放在特定的 VMS 上将限制 SF 必须在其上平衡负载的选项。一个应用程序可能使用更多内存资源，另一个应用程序可能使用更多 CPU。这些可以组合在一个节点上以优化资源使用。
使用节点集来优化成本，因此可以将需要较少资源的服务放在更便宜的节点上。 （使用 placement constraints） （同样适用于订阅量较低的租户）