如何使用Nylas在本地测试微服务(上)

2023-03-06   出处: Nylas  作/译者:Zhi Qu/王练

在本地测试微服务架构很困难。 在 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。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
195° /1958 人阅读/0 条评论 发表评论

登录 后发表评论