使用Azure Service Fabric协调本地开发或测试环境

Question

使用Azure Service Fabric协调本地开发或测试环境

5

在尝试使用Azure Service Fabric并观看来自BUILD的直播后，我有些好奇是否有任何关于编排更复杂服务环境工具的管道。

比如说我构建了一个名为“Service1”的服务，它调用了“Service2”和“Service3”中的演员和服务；任何想要检出“Service1”仓库进行更改的开发人员也必须不仅检出“Service2”和“Service3”，而且还要在正确测试其对“Service1”的更改之前将它们构建并部署到Service Fabric上。与Compose for Docker（我知道Azure Service Fabric并不是这样的容器式基础架构，但这只是一个例子）相比，你可以创建一个描述你的服务及其依赖项的清单。然后，你可以轻松地引导运行和测试你的服务所需的整个环境。

这对于自动化测试甚至服务质量保证也很有用，你可以启动一个新集群并部署你的服务 - 以及它的依赖项 - 并在开始生产部署之前实际运行测试。

这可能更适合作为产品反馈的问题或建议，但在将其制定为建议之前，有了更多的输入将会很有趣。我不是很熟悉Compose，我只是用它作为一个例子 - 也不熟悉Azure Service Fabric，所以可能有更好的解决方案。

- Trond Nordheim

4个回答

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实现中采用这种方法。这将有助于我们仅部署基于演员的微服务，并提供任何所需的服务，以及发生变化的地方。

我同意我们当前将所有演员合并到单个项目中的设计不是最好的，但这帮助我们更快地构建应用程序。一旦您了解了适合您需求的工作原理和不适合的内容，重构始终很重要。

- Satya Tanwar

没有示例，我很难理解如何实现你所提到的内容。 - Alex Gordon

0

我还不确定问题在哪里。假设使用TFS（或其他），团队可能有一个包含所有服务项目的根项目。您已经在本地计算机上拥有ServiceB的本地WorkingSet（可以构建和部署）。您构建并部署ServiceB（如果之前没有），将其部署到本地开发环境中。它会一直保留在那里，直到您删除它或覆盖它。现在，您要为编辑ServiceA进行签出，进行更改，对ServiceA解决方案进行f5操作，然后您的ServiceA会找到已经在开发环境中的ServiceB。如果稍后有人更改了ServiceB，则会获取新的位，并再次部署该应用程序，以便在您的开发环境中更新，直到再次更改。
在Azure环境（发布时）中，情况似乎大致相同。ServiceB已经在运行。您更改ServiceA并部署更改。

- staceyw

-1

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

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

- VipulM-MSFT

2

这并没有真正回答问题；如果我是一个开发人员，需要对AppA中的ServiceA进行一些更改。我检出代码，实现我的更改，并启动它；服务执行针对fabric:/AppB/ServiceB的调用，由于我没有在本地运行此服务，因此将失败。同样的情况也适用于我在Azure中的测试套件中旋转资源组并部署ServiceA；它将失败，因为没有ServiceB，这意味着测试套件必须知道这一点，并在部署ServiceA之前构建+部署此服务-这将是一个难以维护的混乱。 - Trond Nordheim

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Vaclav Turecek · Accepted Answer

拉取应用程序包并将其部署到您的集群（无论是本地、测试、生产等）实际上是一件相当简单的事情，只要您有一个类似于Compose和Docker Hub一样的应用程序包中心仓库。换句话说，这种能力已经存在，但我们还没有像Docker Hub那样的集中存储应用程序包的地方，您需要自己编写一些脚本来拉取内容。因此，现在您需要检查具有依赖项的存储库并构建它们（或注入模拟数据进行本地测试）。

顺便提一下，请将此建议发布到我们的产品反馈页面！