【问题标题】:MicroService with DCOS带有 DCOS 的微服务
【发布时间】:2018-02-18 04:41:21
【问题描述】:

我决定迁移到微服务架构,将一个项目分成多个服务并在 DCOS 上运行这些服务。它确实为项目部署和维护提供了一个很好的故事。但它使开发过程变得复杂。

对于开发者来说,在执行过程中本地运行应用程序很容易。现在项目分为多个服务,运行在需要良好配置的DCOS上。因此,在执行过程中测试应用程序对于开发人员来说变成了一场噩梦。

伙计们,有人在使用带有微服务的 DCOS,您能否建议您在内部开发中遵循的流程。

【问题讨论】:

    标签: microservices dcos


    【解决方案1】:

    DCOS 只是您的部署工具,因此为了提供更好的答案,您必须在问题中分享更多有关您的技术堆栈的信息。但这里有一些一般性的想法:有不同类型/级别的测试,每种都有不同的考虑因素。

    1. 在单元级别 - 这取决于您用于实现服务的技术,这也是 Go 等语言在服务器开发中越来越受欢迎的原因。例如,如果您使用go,您可以轻松地在开发机器上运行您当前正在本地(非容器化)开发的任何服务。您可以轻松运行附加的单元测试。您可以在本地运行相关服务或模拟它们(可能取决于努力)。您可能还希望要求每个服务团队提供模拟服务作为其定期交付的一部分。 并且您将需要针对本地环境进行特殊的环境设置和服务配置。所以总结一下,这种方法将要求您具备在本地运行服务的方法,并且根据您使用的实施技术,它会更容易或更难。

    2. 在部署/集成级别 - 在 dev's local machine 上设置最小集群和/或使用专用的测试和暂存集群。这使您可以测试包括容器化在内的服务,并在具有依赖关系的更最终的部署环境中进行测试。您可能会为这种类型的测试编写特殊的测试客户端。而且这种方法还需要您为不同的环境提供单独的环境设置、配置文件等。像Jaeger 这样的工具变得越来越流行,通过这里的多个服务来帮助调试错误。

    3. Canary 测试。顾名思义 - 您将最新的服务版本部署到生产集群的一小部分,以便在将其推广到大众之前先在有限数量的用户上对其进行测试。在这个阶段你可以运行用户级别的测试,实际上你的用户成为了测试人员,所以要谨慎使用。一些组织更喜欢拥有只能访问这些环境的特殊 beta 类型用户。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2021-07-31
      • 1970-01-01
      • 2020-07-01
      • 2016-01-14
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-04-22
      相关资源
      最近更新 更多