5

在玩了一点 Azure Service Fabric 并观看了 BUILD 的流之后，我有点好奇是否有围绕工具为更复杂的服务编排环境的管道。

假设我构建了一个服务“Service1”，它调用“Service2”和“Service3”中的演员和服务；任何检查“Service1”存储库以执行更改的开发人员还必须不仅检查“Service2”和“Service3”，还必须构建它们并将它们部署到 Service Fabric，然后才能正确测试他/她在“Service1”中的更改”。将此与例如Compose for Docker进行比较（我知道 Azure Service Fabric 本身并不是容器式基础结构，而只是作为示例），您可以在其中创建描述您的服务及其依赖项的清单。然后，您可以轻松引导运行和测试服务所需的整个环境。

这对于自动化测试甚至 QA 服务也很有用，您可以在其中启动一个新集群并部署您的服务 - 及其依赖项 - 并在开始生产部署之前对您的更改运行实际的实时测试。

这可能是一个更适合作为产品反馈的问题或建议，但在将其形成建议之前对此有更多的投入会很有趣。我对用作示例的 Compose 并不十分熟悉，对 Azure Service Fabric 也不是很熟悉，因此可能有更好的解决方案来解决这个问题。

4

4 回答 4

3

只要您有一个类似于 Compose 对 Docker Hub 所做的应用程序包的中央存储库，下拉应用程序包并将它们部署到您的集群（无论是本地、测试、产品等）实际上是一件相当简单的事情。换句话说，功能是存在的，但我们还没有像 Docker Hub 这样的集中位置来存储应用程序包——而且你必须编写一些脚本来自己把东西拉下来。所以现在是的，您需要检查具有您的依赖项并构建（或注入模拟以进行本地测试）的存储库。

请注意，请将此建议发布到我们的产品反馈中！

于 2015-05-02T19:38:14.463 回答
1

我们处理各种服务和参与者包之间关系的方式是进行完整部署。通过完整部署，用户在其本地 git 分支中提交的任何更改都将通过完整的应用程序部署（所有服务和参与者）进行测试。我们已经使用自定义 ps 脚本在本地环境中部署相同的脚本。

部署应用程序后，开发人员运行我们完整的 specflow 测试套件，该测试使用模拟数据并测试我们的服务结构应用程序的所有部分以及所做的任何新更改。目前部署是由开发人员执行的手动步骤。开发人员需要将 specflow 测试运行结果与提交/合并一起附加。

来自 Microsoft BizTalk 世界，其中应用程序/编排的行为类似于 SF 中的服务和参与者，我们了解到，与部分部署相比，在同一环境中管理应用程序之间的依赖关系时，完全部署是更清洁的方法。

我们的应用程序包含 3 个服务

1. Stateless router service
2. State full cache service
3. Domain specific Actor micro services ( we have multiple services in same actor project)

Service 1 and 3 are dependent on service 2. Any change in 'Router' or 'Actor' service need to be tested along with 'Cache' service as they all work together. 

Any changes to 'Actor' ( this one changes most of the time due to business logic ) generally require our team to deploy all 3 service and execute our spec flow test suite to test complete functionality. This make sure that all the functionality is working as expected.

作为替代方案，您可以为不同的参与者创建多个项目，而不是将它们全部放在同一个项目中。我们也在 v2 实施中研究这种方法。这将有助于我们只部署基于参与者的微服务，其中发生了变化以及任何所需的服务。

我同意我们目前将所有参与者组合在一个项目中的设计并不是最好的，但这有助于我们以更快的速度构建应用程序。一旦您根据需要了解了哪些有效，哪些无效，重构总是很重要的。

于 2018-02-21T04:04:57.293 回答
0

不确定我是否看到了这个问题。假设 TFS（或其他），团队可能有一个包含所有服务项目的根项目。您将在本地框（您可以构建和部署）上已经有一个本地的 ServiceB 工作集。您构建并部署 ServiceB（如果您以前没有）到您的本地开发结构。它会一直保留在那里，直到您将其删除或在其上部署。现在您签出编辑 ServiceA，进行更改，在 ServiceA 解决方案上按 f5，您的 ServiceA 找到已经在开发结构中的 ServiceB。如果稍后有人更改 ServiceB，您将获得新的信息并再次部署该应用程序，以便在您的开发结构中更新它，直到它再次更改。
在 Azure 结构情况下（发布时）似乎大致相同。ServiceB 已经在运行。您更改 ServiceA 并部署您的更改。

于 2015-09-13T03:15:27.153 回答
-1

一旦您在微服务之间定义了明确的合同，您就可以升级它们并独立测试它们。各种微服务可以打包在单个应用程序包中，也可以是不同应用程序包的一部分。您可以在单个应用程序或不同的应用程序中创建所需的微服务实例。

假设微服务服务 A 是应用程序包 A 的一部分。它依赖于应用程序包 B 中的其他微服务服务 B。您已将应用程序包 B 安装并实例化为“fabric:/AppB”，并且创建了一个微服务“fabric:/AppB/ServiceB”。您可以将应用程序 A 和服务 A 部署和实例化为配置为与“fabric:/AppB/ServiceB”通信的“fabric:/AppA/ServiceA”。您还可以在运行时查找特定类型的服务，并根据服务端点或命名属性存储中的已发布元数据，您可以动态连接到所需的服务。

于 2015-05-02T04:19:55.817 回答