BT

您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

一个创业公司的API网关落地实践

| 作者 Ítalo Lelis ,译者 薛命灯 发布于 2017年3月6日. 估计阅读时间: 不到一分钟 |

HelloFresh是一家食品电商初创公司,用户根据选定的菜谱下单,HelloFresh把菜谱所需要的食材送至用户家中。来自HelloFresh的技术负责人Ítalo Lelis在博客上分享了HelloFresh的API网关落地实践,本文为该博文的译文,并已获得原网站的翻译授权。

HelloFresh的规模一直保持着增长的态势:我们的产品在持续改进,新的想法不断涌现出来,我们拥有完全自动化的供应链。持续的增长给我们带来了惊喜,同时也带来了技术方面的挑战。

在这篇文章里,我将会和大家分享我们的基础设施所经历的一次重大迁移,这次迁移保证了以后的路我们可以走得更快、更灵活,也更安全。

挑战

我们最近开发了一个API网关,所以接下来需要在不停机的情况下对网关后面的主API(单体系统)进行迁移改造。升级之后,我们希望能够开发更多的微服务系统,并且无缝对接到目前我们的基础架构中。

架构

API网关处在基础设施的最外层,它每天需要接收大量的请求,所以我们选择了Go语言来构建网关,因为Go性能好、简单易用,而且提供了优雅的并发解决方案。

我们手头已经有很多现成的工具,它们可以简化我们的迁移工作。

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

我们使用Consul作为服务发现工具,它和HAProxy配合起来使用可以帮我们解决微服务架构的两个主要问题:服务发现(新服务上线时会自动注册)和客户端负载均衡(把请求均衡地分发到各个服务器上)。

自动化

我们的工具箱里最有用的工具或许要数基础设施的自动化。我们使用Ansible在云端管理资源,包括单机、网络、DNS、运行持续集成工具的主机,等等。按照我们的惯例,开发一个新服务时,我们工程师的第一件事情就是为这个服务创建Ansible脚本。

日志和监控

从某种程度上说,我们应该监控基础设施里的所有东西。在日志和监控应用方面,我们有一些最佳实践。

  • 办公室里有仪表盘(就是国内公司里的大电视屏,显示系统状态),我们在任何时候都可以查看系统的运行情况。
  • 我们使用ELK技术栈来收集日志,从而可以快速地分析服务的运行情况。
  • 我们使用StatsdGrafana作为监控工具,这些工具总会给我们带来惊喜。

Grafana的仪表盘为性能度量指标提供了非常完美的视角。

理解当前的架构

尽管有了这些工具,我们仍然有一个棘手的问题需要解决:理清当前的架构,然后想清楚如何顺利地进行迁移。我们花了一些时间对遗留系统进行了重构,让它们支持新的网关,同时我们也加入了认证服务。在这个过程中,我们遇到了一些问题。

  • 虽然我们可以对移动应用进行更新,但也要考虑到有些用户可能不愿意升级,所以我们要保持向后兼容,比如DNS,我们要确保旧版本也能正常工作。
  • 我们需要整理出所有公开和私有的API端点,并让它们自动地注册到网关上。
  • 我们需要把认证工作从主API迁移到新的认证服务上。
  • 确保网关和微服务之间通信的安全性。

为了解决这些问题,我们写了一个Go脚本,这个脚本会读取OpenAPI规范(Swagger)文件并为API资源创建规则(比如速率限定、配额、CORS等)代理。

我们在staging环境搭建了整个基础设施,并在上面运行自动化测试,对服务间的通信进行了测试。不得不说,自动化staging测试在整个迁移过程中起到了很大的作用。我们有很多功能测试用例,这些用例保证了主API的功能是完好的。

在确保了staging环境一切正常之后,我们开始考虑如何将它们推到生产环境。

第一次尝试

可以告诉大家的是,我们的第一次尝试简直是灾难性的。尽管我们已经做足了计划,不过仍然不足以把它们推向生产环境。先来看看我们的初始计划。

  • 把最新的API网关部署到staging环境
  • 把主API的变更部署到staging环境
  • 在staging环境运行自动化功能测试
  • 通过网站和移动端进行staging环境的手动测试
  • 把最新的API网关部署到生产环境
  • 把主API的变更部署到生产环境
  • 在生产环境运行自动化功能测试
  • 通过网站和移动端进行生产环境的手动测试
  • 庆祝胜利

在staging环境一切进展得都很顺利,当我们准备进入生产环境时,问题出现了。

  1. 认证服务的数据库过载:我们低估了请求的流量,造成数据库拒绝连接
  2. 错误的CORS配置:部分端点的CORS规则配置错误,造成请求无法获得资源

数据库被冲垮,我们不得不马上回滚。幸运的是,我们的监控系统捕获到了从认证服务获取令牌的问题。

第二次尝试

从第一次失败中吸取了教训,我们知道我们还没有为进入生产环境做好准备,于是在回滚之后,立即对问题展开诊断。在再次尝试之前,我们做了一些改进。

  • 准备蓝绿(blue-green)部署过程。我们为生产环境创建了一个副本,包括已经部署好的网关,通过一些简单的配置变更就能让整个集群运行起来,如果需要回滚,也只需做一些简单的配置变更。
  • 从当前的系统收集更多的度量指标,这样可以帮助我们决定该使用多少机器来处理负载。我们利用第一次尝试时所使用的数据作为探针,并使用Gatling来运行负载测试,确保我们可以应付预期的流量。
  • 再次进入生产环境之前,我们对认证服务的已知问题进行了修复,包括一个大小写问题、一个JWT签名的性能问题,并添加了更多的日志和监控。

我们花费了一个礼拜来完成上述的工作,之后的部署进展得很顺利,中间没有停机。不过尽管部署进展得很顺利,我们仍然发现了一些在自动化测试中没有发现的个别问题,不过这些问题最终得到修复,并没有对系统造成太大影响。

结果

最终的架构如下图所示。

主API

  • 10多个主API部署在装配了高端CPU的主机上
  • 主从MySQL(3个副本)

认证服务

  • 4个应用服务器
  • 主从PostgreSQL(2个副本)
  • RabbitMQ用于异步地处理用户的更新操作

API网关

  • 4个应用服务器
  • 主从MongoDB(4个副本)

其它

  • 使用Ansible批量管理远程服务器
  • 使用Amazon CloudFront作为CDN/WAF
  • 使用Consul和HAProxy作为服务发现和客户端负载均衡工具
  • 使用Stasd和Grafana收集系统度量指标并触发告警
  • 使用ELK技术栈从不同的服务收集日志
  • 使用Concourse CI作为持续集成工具

查看英文原文:Scaling @ HelloFresh: API Gateway


感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT