我正在考虑将应用程序迁移到在Azure上运行的Service Fabric.这是一个使用SignalR的实时聊天式应用程序.我想让一个服务实例运行,为用户正在进行通信的每个“关联组”自我托管一个SignalR集线器(通过OWIN).这样我就可以避免使用背板扩展SignalR.我希望能够在用户组进入和离开我的应用程序时上下旋转这些服务.我希望我可以为每个VM托管数十个这样的服务,每个组的典型负载为数百个用户.

我的想法是,我有一个服务定位器,客户端最初连接到该服务定位器以发现哪个服务(端口)正在托管其组.我还有一个服务,当该组的第一个请求进入时,它会启动聊天服务的实例.

我将如何在Azure上的Service Fabric中构建此框架,以便a)每个服务/演员都可以通过Internet上的SignalR客户端访问？和b)我只运行尽可能多的服务来服务n个小组中的m个活跃组？对这个应用程序的需求是非常短暂和尖锐的,所以我希望利用这样一个事实,即服务只是流程,并且可以在几秒钟内配置,而不是我当前的情况,我必须启动整个云服务并等待数十分钟来处理尖峰(此时为时已晚)

最佳答案 你会做一些事情：

>有一个“服务管理器服务”拦截初始加入请求并在运行时创建新的Service Fabric服务(如果它们尚不存在)或者它们是否已存在解析服务的当前位置然后将该地址返回给客户端

>或者他们可以只传回内部服务名称(如果您可以公开该信息),客户端可以进行解析然后连接.在某种程度上,这将取决于您希望向客户端公开多少信息,无论您是否可以将其修改为“了解”Service Fabric等.

>然后,客户端将直接连接到实际的支持服务
>您必须为实际的聊天服务提供某种机制才能知道没有人离开,要么自行删除,要么通过管理员返回.
>您可能最好将聊天服务建模为可靠服务而不是演员,因为可靠服务堆栈允许更灵活地围绕通信协议/堆栈.