作为独立软件开发商,我们有一个企业解决方案,可为我们的大客户扩展我们现有的软件,他们必须在本地或甚至Azure中安装和配置Azure SF群集。我们的软件主要用于无状态服务,只有一些状态很好。它也是多租户的,所以我们可以在云环境中运行自己的软件。单台机器上的Azure服务Fabric群集
但是我们也有第三种使用方式:我们需要将我们的软件运送给有我们其他软件的非企业客户。这是一个问题,因为Service Fabric需要多台小型客户没有且当然不想拥有的机器。有时他们是软件的单个用户,并将其全部运行在一台笔记本电脑上。
我看到几个解决方案c.q.选项:
1.重写软件。
以某种方式维护相同的代码库,主机作为Windows服务或其他东西。与顶部,这是相对容易主办基于OWIN/Katana的程序。
优点
- 没有服务织物集群
- 安装更方便,例如windows服务
缺点
- 没有有状态的服务 个
- 多的Visual Studio解决方案
- 开发者必须考虑托管和服务织物是用或不
- 单节点集群上没有的可靠性和可扩展性
2.主机的方式
在生产环境中将群集安装为机器上的单个节点。明知可靠性和可扩展性丢失,但thatis也与选择1
优点
- 一个Visual Studio解决方案
- 只有一个代码库,无需修改代码,这是很容易的开发商
缺点
- 不通过Azure的服务织物生产
- 没有可靠性和可扩展性
3支持。在一个码头集装箱内运送一个集群
我对docker的了解不多,但也许很容易发布预先配置的服务结构集群?
你们(和女孩)有什么想法?我会喜欢选项二或三,但我们的一些开发人员甚至想到选项1是我怀疑的更好的选项。
一些相关的链接,我发现:
选项2:Azure Service Fabric Single Virtual Machine
方案3:https://github.com/Azure/service-fabric-issues/issues/409
你有什么理由让所有的应用程序在SF? – Mardoxx
首先考虑使用云进行编码,解决方案中的所有应用程序都在一个清单中,对于具有本地或订阅集群的客户进行简单安装。 – rfcdejong
但它是一台机器上的一个安装?相反,击败使用Serboce织物的目的不是吗?听起来像你想使用SF,因为它是“酷”,而不是正确的工具!大量不必要的复杂层次和不可维护的内容。 – Mardoxx