使用DCOS的MicroService

Question

我决定转向MicroService架构，将一个项目划分为多个服务，并在DCOS.It上运行这些服务，这为项目部署和维护提供了一个很好的故事。但这会使开发过程变得复杂。

对于开发人员来说，当项目在progress.Now中实现时，很容易在本地运行应用程序。项目被划分为多个服务，并在需要良好配置的DCOS上运行。因此，在实现过程中为开发人员测试应用程序成了一场噩梦。

各位，如果有人正在使用DCOS和Microservice，你们能建议一下你们内部开发的流程吗？

Answer 1

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

单元级的

1. --这取决于你使用什么技术来实现你的服务，也是像go这样的语言在服务器开发中变得越来越流行的原因。例如，如果您使用go，则可以轻松地在开发机器上运行当前正在本地(非容器化)开发的任何服务。而且您可以轻松地运行附加的单元测试。您可以在本地运行依赖服务，也可以模拟它们(可能取决于工作)。您可能更喜欢让每个服务团队提供模拟服务，作为其常规交付的一部分。您将需要为汇总的本地environment.So设置特殊的环境设置和服务配置此方法将要求您具有在本地运行服务的方法，并且根据您使用的实施技术，它将变得容易或困难。
2. on deployment/integration level -在dev's local machine上设置最小群集和/或使用专用测试-以及暂存群集。这允许您测试服务，包括容器化，并在具有依赖性的更最终的部署环境中进行测试。您可能会为这种类型的测试编写特殊的测试客户端。这种方法还要求您针对不同的环境有单独的环境设置、配置文件等。在通过多个服务here.
3. Canary测试来帮助调试错误方面，像Jaeger这样的工具变得越来越流行。顾名思义，您将最新的服务版本部署到生产集群的一小部分，以便首先在有限数量的用户上进行测试，然后再将其向大众推出。在此阶段，您可以运行用户级别的测试，实际上您的用户将成为测试人员，因此需要谨慎使用。一些组织更喜欢有特殊的测试版用户，他们只能访问这些environments.