微服务本地开发指南

Question

我正在寻找一些关于本地开发微服务的方法的指导。我意识到会有很多不同的方法，但我只是在寻找一些例子，然后我可以决定哪种方法可能适合我的情况。

我目前正在考虑将一个单片系统转移到微服务系统。我正在使用Docker和Docker Compose来‘容器化’每个服务(通过Visual Studio2019)，我已经将每个服务放入了他们自己的解决方案(.sln)和他们自己的Git存储库(Azure Repos)。我预测会有很多次我需要同时处理两个或多个服务(例如，我需要服务A将事件发布到服务B，并且我需要更新服务B来处理这个新事件)。

我的问题是，有没有人用什么方法来处理这样的情况...您需要同时使用服务A和服务B，但可能还需要运行服务C和服务D？我可以/应该使用多个Docker组合文件来处理这种情况吗？在这种情况下，使用本地Kubernetes (通过Docker Desktop)会更好吗？我是否应该只运行一个脚本，下载并运行我所有的服务镜像，然后处理有问题的服务？

如果有人能够分享他们的经验，或者向我推荐一些关于这方面的文档，我将非常感激。

Answer 1

也许最好的解决方案是帮助你以最快的方式得到你需要的东西。有时最好的解决方案是你已经知道的。

基本上，您需要运行服务。当我只需要几个服务时，我所做的就是手动启动和配置它们(团队中的每个开发人员都使用自己的设置)。这有时是一个恼人的过程，但它需要完成。使用docker-compose不会有真正的帮助，因为事情会随着时间的推移而变化。当然，您可以为每个可能的配置创建一个docker-compose文件，只要您能够跟踪它们。

我使用的另一件事是将整个应用程序部署在一个dev/alpha环境中，然后从本地连接到我需要的服务。这减少了本地系统上使用的内存，您只需通过URL指向所有其他服务即可访问这些服务。当您需要启动5个以上的服务时，此方法可能会很有帮助。

我将这两种方法混合在一起，以获得更快的结果。

你的方法在我看来很好。也许你可以做一些调整来改进它，但这真的取决于你在本地有什么。

当dev/alpha环境不在我的控制范围内时，我经常做的另一件事是将所有服务部署到单独机器上的本地Kubernetes单节点集群中(比如笔记本电脑或树莓派，有时两者都有)。这可以帮助您避免在云中拥有自己的集群的成本，并且应用程序配置始终在手边(例如，您不需要身份验证)。我在这里谈论的是数十种服务。

在某种程度上，如果你最终要使用那么多的服务，那么你将需要转移到云中的开发环境，因为你的本地内存将是不够的。

Answer 2

确保所有可以引用主机名的内容都可以配置为环境变量。如果一个服务调用另一个服务，则其主机名或URL是环境变量；如果某个服务使用数据库，则数据库位置是环境变量；依此类推。这些环境变量通常缺省为在开发人员设置中有用的内容，您可以在部署时覆盖它们。

如果这样做，则可以在开发环境中启动少量服务

# Starts a, b, c, d on ports 8001, 8002, 8003, 8004
docker-compose up -d
# C_URL defaults to http://localhost:8003, etc.
PORT=7001 B_URL=http://localhost:7002 ./service_a.sh
PORT=7002 ./service_b.sh
curl -XPOST http://localhost:7001/invoke-b

一定要确保你有可靠的单元测试，这实际上是单元测试。服务A的测试不应该依赖于数据库、服务B或其他任何东西。通过这种方式测试系统显然只能做到这一点，而且还需要集成测试，但是如果您可以运行

./a_tests.sh

如果不启动其他任何东西并覆盖80%的代码，您的测试将运行，您的业务逻辑将得到测试；如果运行测试需要有效的端到端设置，它们将无法运行，并且在CI环境中将失败。

我需要服务A将事件发布到服务B...

使用专用的消息代理可以帮助解决这种情况。作为一种开源选择，我对RabbitMQ很熟悉，但还有其他选择。这打破了依赖链:A需要消息代理，以便它可以将消息发送到那里，但并不特别依赖于B的运行；B需要消息代理及其输入消息，但不一定是生产者。如果大多数服务间通信仅通过消息代理发生，则服务只需要自身和代理运行。

docker-compose up -d rabbitmq
# https://github.com/jandelgado/rabtap
export RABTAP_AMQPURI=amqp://guest:guest@localhost:5672/
rabtap pub service.a.exchange < a-input.txt
./service_a.sh
rabtap sub service.b.queue

在这种情况下使用本地Kubernetes (通过Docker Desktop)会更好吗？我是否应该只运行一个脚本，下载并运行我所有的服务镜像，然后处理有问题的服务？

拥有一些自动化来启动所有东西，或者至少是一个必要的服务核心，对开发人员来说真的很有用。查看12个存储库并运行12个略有不同的启动脚本是不会扩展的。有一种观点认为这应该与您的部署脚本相同，如果您还在生产中使用Kubernetes，则建议使用本地Kubernetes (Docker Desktop、minikube、kind)或共享开发集群。Docker编写设置很简单，也可能是“启动一切”shell脚本，但在添加服务时，这些脚本需要保持最新。

如果您无论如何都在使用Kubernetes，像Telepresence或Skaffold这样的工具可以简化这一特定的工作流程，旨在帮助您在本地运行一个服务，并在集群中运行环境的其余部分。如果您只有三到四个服务，并且它们可以安装在一台主机上(即使是在生产环境中，也可能不包括数据库)，并且对拥有所有权限的管理员感到满意，那么Kubernetes将成为比您需要的更多的集群软件。