开发大型服务结构应用程序答案

【问题标题】：Developing large service fabric application开发大型服务结构应用程序
【发布时间】：2019-08-22 16:26:04
【问题描述】：

我们正在服务架构上开发一个应用程序，随着时间的推移，它变得越来越大，代码越来越多，服务类型也越来越多。团队的每个开发者都使用本地集群进行开发和调试。

问题在于构建时间 + 本地部署时间有时会达到 15 分钟左右（取决于 SF 是否正在执行应用程序刷新），这从开发人员的角度来看是令人沮丧的。

我想减少构建和部署时间。大型应用程序的推荐模式是什么。我应该考虑某种构建农场和远程开发集群吗？

注意：我们使用的是“刷新应用程序”调试模式。这并不能解决问题，因为有时 SF 会选择重新部署整个应用程序。

【问题讨论】：

这深入了解了服务是如何解构的；如果您不沿着 DDD“有界上下文”解构您的服务，那我就从这里开始；根据这些有界上下文组合服务或将它们分开；接下来是弄清楚系统中需要哪些服务来执行哪些操作。如果所有服务都需要能够调试系统中的任何内容，那么就会出现一个巨大的耦合问题。
我可以继续说下去，但长话短说：决定如何创建服务很重要，甚至可能不需要做你正在寻找的事情。
我们正在考虑我们的服务之间的松散耦合，但我从未真正尝试在服务结构上开发时启用/禁用服务。我认为这很脏，因为我每次都必须更改应用程序清单文件。你对此有什么线索吗？

【解决方案1】：

使用“刷新应用程序”作为应用程序调试Mode。

我建议您创建多个可以单独部署和升级的小型应用程序。如果您使用SF remoting，内置重试逻辑将允许一些远程停机时间。

但是而不是进行RPC 调用，看看是否可以使用pub/sub 模式。（参见thisOSS 项目）。这将允许无限期的远程停机（解耦服务），而呼叫者无需等待应答。请注意，这种解耦方法的缺点是eventual consistency。

【讨论】：

先生，我们已经在使用“刷新应用程序”模式进行调试。使用多个应用程序是一种架构更改。您能否提供开发多种应用程序类型与多种服务类型的优缺点？
应用程序不过是服务的组合。我想说应用程序类型不定义架构，只是部署。这正是你遇到的麻烦，对吧？
我确实在发布后重新考虑了我的评论。你其实是对的。我会考虑这一点，但需要一些时间来验证并接受您的回答。
补充答案的一些链接： - 简要说明您为什么应该choose an application to service packaging model。 - 解释了将单体分解为微服务的域分析here