在本地测试微服务架构很困难。 在 Nylas，我们使用 Minikube 和 Tilt 创建了一个本地开发环境。 让我们来看看我们如何在 Nylas 中启用微服务的本地测试。

本地测试微服务架构面临的问题

微服务架构是一种很好的设计实践，但在本地测试它非常困难。 让我们来看看面临哪些问题。
一个简单的微服务架构如下所示：

您可以在该架构中看到相关组件：
●处理来自客户端的 API 请求的 API 服务。
●充当消息代理的消息队列。
●一些异步执行任务的异步服务。
●一些存储应用程序数据的数据层。
然而，现实中的微服务架构要复杂得多。 这是一个更贴近现实的版本：

首先，现实世界中的服务比我们上面看到的简单架构要多得多。 每个业务领域都有自己的微服务生态系统。 每个产品都可以有自己的 API 服务、消息队列、异步服务和数据库。 一旦公司采用微服务架构，服务的数量就会呈指数级增长。
其次，业务领域经常跨越边界。 产品 A 中的服务有时会从为产品 B 定义的数据库中读取。这不一定是一个糟糕的设计，因为业务领域总是相互关联的。 例如，当您进行 Google 网络搜索时，搜索 API 将不可避免地同时调用 Google 地图和 YouTube。 在产品之间建立清晰的、服务无法逾越的边界非常困难。
第三，并非所有服务都属于一种产品。 一些服务被构建为“平台服务”或“共享服务”。 例如：
●处理用户登录的身份验证服务。 大多数产品服务都依赖于此来进行用户身份验证/授权。
●为 DevOps 和支持团队构建的管理服务。 工程师可以使用管理服务删除数据库中损坏的数据，或删除过期的工作流程。
●API 网关（或“边缘服务”）：一种将客户端请求路由到不同 API 服务的服务。 API 网关还处理限流、日志记录、DDoS 保护等。

拥有数百个后端服务的中型公司很常见。 在笔记本电脑环境中本地启动每一项服务变得根本不可能。
因此，微服务架构给开发者带来了如下挑战：
●如何在本地测试我的更改？
●我如何确保我的更改不会意外破坏整个系统？
为了解决这些问题，我们为 Nylas 工程师创建了一个本地开发环境。

微服务按“域”划分

开发环境的基础单元是一个“域”。 域是密切相关的服务的集合。 域内的服务耦合比跨域的服务更紧密。
域通常通过产品定义。 例如，Nylas Streams 域由 Nylas Stream 产品 (https://www.nylas.com/capabilities/nylas-streams) 定义。 该域中，有一个 Streams API 服务、Streams 异步服务、Streams 数据库和 Streams 消息队列。
通过这种方式，我们可以将微服务分组到域中。
在划分“域”之前的架构如下：

在分组到域之后：

在 Nylas，代码存储库不是根据服务定义的，而是根据域。 紧密协作的服务存储在同一个代码库中。
因此，我们的开发人员环境是建立在逐个域的基础上的。 每次我们的开发人员想要在本地运行和测试服务时，他们都必须启动整个域的开发人员环境。
让我们看一个示例开发人员环境：

在上面的示例中，我们有 API 服务、异步服务 A 和异步服务 B。它们是我们要测试的服务。
不要忘记：域内服务会依赖域外服务。 一些依赖是第三方提供的：消息队列（Kafka/RabbitMQ/SQS）、数据库（Mongo/Dynamo/Spanner）、缓存（Redis）等。 其他依赖项在其他域中； 例如，电子邮件服务可能需要调用电子邮件域之外的身份验证服务。
开发人员环境由域中定义的所有服务组成。 也包含域外的第三方依赖项和服务的模拟器。
至此，我们已经定义了开发环境的范围，但我们如何在本地运行它呢？
答案是 Minikube 和 Tilt。