数据API 案例 开发者 关于
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道

从单体应用走向微服务:一次API Gateway升级的启示

HelloFresh 的规模每一天都在不断增长,产品在持续改进,新的想法不断涌现,供应链也已经完全实现自动化,所有这一切都让我们惊讶。另外一方面业务的持续增长也给我们带来了许多技术挑战。

今天给大家介绍基础架构中的一次 API Gateway 升级过程,这次改造的目的是给微服务铺路,使得我们将来可以更快、更灵活和更安全的方式快速迭代。

技术的挑战

我们最近完成开发了一个新的 API Gateway(网关) [1],因此面临着将老的主  API 单体应用迁移到其下层的复杂挑战,理想情况下当然是升级过程中没有停机,迁移后可以使我们能够开发更多的微服务,并容易地将它们连接到我们的基础设施中,而无需额外的代价。

HelloFresh 的架构

我们的 API 网关位于基础设施的上层,它每天接收大量的请求,我们在开发它时选择 Go 语言,因为它的性能、简单性和优雅的高并发解决方案。借助我们其他已有的系统或组件,使得这种改造变得简单:

服务发现和客户端负载均衡

我们使用 Consul 作为我们的服务注册发现工具。连同 HAProxy 一起,使我们能够解决进微服务架构的两个主要问题:服务注册发现和客户端负载均衡。


自动化

对于我们的基础设施,最有用的工具是我们的自动化工具。 在云环境中我们使用 Ansible 进行配置服务,从单个机器到处理网络、DNS、CI 服务等。 重要的是,我们团队达成了一个约定:当开发一个新的服务,工程师的第一件事是为这个服务创建 Ansible 脚本。

日志和监控

在我们的基础设施中的任何系统、组件、数据都应该被监控。我们有一些关于如何正确记录日志和监控应用程序的最佳实践:

  • 对于任何给定时间点,仪表板(dashboard)都能够显示系统的状态;

  • 对于记录日志,我们使用 ELK,借助它我们可以快速分析服务的详细行为;

  • 对于监控,我们喜欢 Statsd + Grafana 的组合。 它非常简单易用并且足够强大;

691-640.jpg.jpg


理解老的架构

即使借助这些工具,我们依然面临一个难题:了解老的架构,并且尽可能平滑的升级它。在这个阶段,我们花了一些时间和精力来重构我们的老系统,以支持我们的新 API 网关和身份验证服务,这也是本文将要介绍的(后续内容请继续关注此系列)。


我们遇到的一些问题:

  • 虽然我们可以更改我们的移动客户端,但没法保证用户会很快更新。因此我们不得不保持向后兼容性,比如通过 DNS 来确保旧版本依然可以正常使用;

  • 我们必须分析公开和私有 API 中的所有可访问地址,并自动在网关中注册它们;

  • 我们必须禁用原有 API 中的身份验证,并将此职责交给新的身份验证服务;

  • 我们必须确保 API 网关和微服务之间的通信安全、可靠;

为了解决导入问题,我们使用 Go 语言写了一个脚本先来读取我们的 OpenAPI 规范(Swagger 生成的 API DOC),再为我们 原有 API 的每个资源(Restful 中的 resource)创建一个代理,同时需要包含正确的规则(如限速,配额,CORS等)。为了测试服务之间的通信,我们在一个 staging 环境中搭建了一整套基础设施,并开始执行我们的自动化测试集。我们维护了一套大型自动化功能测试集,帮助我们保障原 API 到移动客户端和 Web 客户端的服务质量。在我们确信上述事情在 staging 环境中正确工作后,我们开始考虑如何将其应用到生产环境。


初次升级尝试

必须承认第一次尝试(生产环境)完全是个灾难,即使我们有一个相当不错的计划:

  • 将最新版本的 API 网关部署到 staging 环境

  • 将最新版本的主 API 部署到 staging 环境

  • 在 staging 环境执行自动化功能测试集合

  • 在 staging 环境针对移动客户端和 Web 客户端执行手工测试

  • 部署 API 网关到生产环境

  • 部署主 API 到生产环境

  • 执行自动化功能测试

  • 针对移动客户端和 Web 客户端执行手工测试

  • 啤酒 

    原文来自:高可用架构

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道
从单体应用走向微服务:一次API Gateway升级的启示
发布:2017-03-03

HelloFresh 的规模每一天都在不断增长,产品在持续改进,新的想法不断涌现,供应链也已经完全实现自动化,所有这一切都让我们惊讶。另外一方面业务的持续增长也给我们带来了许多技术挑战。

今天给大家介绍基础架构中的一次 API Gateway 升级过程,这次改造的目的是给微服务铺路,使得我们将来可以更快、更灵活和更安全的方式快速迭代。

技术的挑战

我们最近完成开发了一个新的 API Gateway(网关) [1],因此面临着将老的主  API 单体应用迁移到其下层的复杂挑战,理想情况下当然是升级过程中没有停机,迁移后可以使我们能够开发更多的微服务,并容易地将它们连接到我们的基础设施中,而无需额外的代价。

HelloFresh 的架构

我们的 API 网关位于基础设施的上层,它每天接收大量的请求,我们在开发它时选择 Go 语言,因为它的性能、简单性和优雅的高并发解决方案。借助我们其他已有的系统或组件,使得这种改造变得简单:

服务发现和客户端负载均衡

我们使用 Consul 作为我们的服务注册发现工具。连同 HAProxy 一起,使我们能够解决进微服务架构的两个主要问题:服务注册发现和客户端负载均衡。


自动化

对于我们的基础设施,最有用的工具是我们的自动化工具。 在云环境中我们使用 Ansible 进行配置服务,从单个机器到处理网络、DNS、CI 服务等。 重要的是,我们团队达成了一个约定:当开发一个新的服务,工程师的第一件事是为这个服务创建 Ansible 脚本。

日志和监控

在我们的基础设施中的任何系统、组件、数据都应该被监控。我们有一些关于如何正确记录日志和监控应用程序的最佳实践:

  • 对于任何给定时间点,仪表板(dashboard)都能够显示系统的状态;

  • 对于记录日志,我们使用 ELK,借助它我们可以快速分析服务的详细行为;

  • 对于监控,我们喜欢 Statsd + Grafana 的组合。 它非常简单易用并且足够强大;

691-640.jpg.jpg


理解老的架构

即使借助这些工具,我们依然面临一个难题:了解老的架构,并且尽可能平滑的升级它。在这个阶段,我们花了一些时间和精力来重构我们的老系统,以支持我们的新 API 网关和身份验证服务,这也是本文将要介绍的(后续内容请继续关注此系列)。


我们遇到的一些问题:

  • 虽然我们可以更改我们的移动客户端,但没法保证用户会很快更新。因此我们不得不保持向后兼容性,比如通过 DNS 来确保旧版本依然可以正常使用;

  • 我们必须分析公开和私有 API 中的所有可访问地址,并自动在网关中注册它们;

  • 我们必须禁用原有 API 中的身份验证,并将此职责交给新的身份验证服务;

  • 我们必须确保 API 网关和微服务之间的通信安全、可靠;

为了解决导入问题,我们使用 Go 语言写了一个脚本先来读取我们的 OpenAPI 规范(Swagger 生成的 API DOC),再为我们 原有 API 的每个资源(Restful 中的 resource)创建一个代理,同时需要包含正确的规则(如限速,配额,CORS等)。为了测试服务之间的通信,我们在一个 staging 环境中搭建了一整套基础设施,并开始执行我们的自动化测试集。我们维护了一套大型自动化功能测试集,帮助我们保障原 API 到移动客户端和 Web 客户端的服务质量。在我们确信上述事情在 staging 环境中正确工作后,我们开始考虑如何将其应用到生产环境。


初次升级尝试

必须承认第一次尝试(生产环境)完全是个灾难,即使我们有一个相当不错的计划:

  • 将最新版本的 API 网关部署到 staging 环境

  • 将最新版本的主 API 部署到 staging 环境

  • 在 staging 环境执行自动化功能测试集合

  • 在 staging 环境针对移动客户端和 Web 客户端执行手工测试

  • 部署 API 网关到生产环境

  • 部署主 API 到生产环境

  • 执行自动化功能测试

  • 针对移动客户端和 Web 客户端执行手工测试

  • 啤酒 

    原文来自:高可用架构

电话 0512-88869195