我正在尝试将我们当前的整体 Web 应用程序重新架构为更加模块化(微服务)风格的设计。
我对边界有一个很好的了解,并制定了如何构建它的计划......
应用程序的每个部分都有自己的域包、后备 API 和用于管理数据的 Web 前端。加上其他东西,如单元测试和可能的连接帮助程序库等。
为了便于论证,假设我的整体应用程序有 3 个主要组件(模块):
- 用于创建和管理用户的帐户模块
- 用于管理和管理产品的产品模块 目录
- 用于创建、查看和修改订单的订单模块。
在单体应用程序中,这些都是同一应用程序(以及 VS 解决方案和项目)的一部分,并且通常具有使用 MVC/WebApi 等配置的不同 Controller :
// 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 规模集,例如仅针对产品 api 的 VM 规模集,以及另一个针对订单 Web UI 的 VM 规模集等?
另请注意,我们的系统很大,因此有很多组件,因此需要拆分整体样式,因此我需要一个一致的结构来实现这一切。
我们存在严重的可扩展性问题,并且(手动)虚拟服务器配置速度非常慢。加上一个单一的整体 SQl Server 数据库。我想要的 SF 功能是模块化设计、轻松配置和部署以及系统响应时间和吞吐量的大幅增加。当然还有良好的故障转移。
最终,我希望客户看到一致的 URL 结构,但在幕后,我希望能够将其全部分开并在多个节点上协同工作。
提前致谢。
非常感谢任何有关如何配置此功能的帮助。
G.
最佳答案
网关
我建议在这里使用网关模式。 (more info)
通过应用此模式,您将可以完全控制传入的 http 请求的路由方式(基于版本控制、租户、运行状况等)。
vmss
将服务放在特定的 VMS 上将限制 SF 平衡其负载的选项。一个应用程序可能使用更多的内存资源,另一个应用程序可能使用更多的CPU。这些可以组合在一个节点上以优化资源使用。
使用节点集来优化成本,因此需要较少资源的服务可以放置在更便宜的节点上。 (使用 placement constraints ) (订阅费较低的租户也是如此)
关于deployment - Service Fabric 嵌套应用程序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38480000/