第二篇：使用API网关

写在前面的话，这些文章是在NGINX的官方博客中发现的。是关于微服务的一系列的文章，本着好东西共享一下，同时也丰富一下自己，把这些翻译成中文，但是后来发现国内已经有很多人翻译了，我只能说我的品位还不差，和各位大牛步调还算一致，虽然已经有人翻译了，但是本着“一千个读者就有一千个哈姆雷特”的想法继续了下去。

本文出自Using an API Gateway，作者 Chris Richardson， 写于2015年5月19日

---

第一篇文章介绍了如何设计、构建和部署微服务。其中讨论了使用微服务的优点和缺点，即使由于微服务的复杂性，对于复杂的应用来说，它们通常情况下也是理想的选择。这篇文章，也是本系列文章的第二篇，将会讨论使用API网关构建微服务。

当你选择将你的应用构建成一系列的微服务的时候，你就需要考虑你的应用客户端如何与微服务进行交互。对于一个单体应用来说，只要有一系列的endpoint即可，然后可以通过负载均衡将流量分布到完全相同的应用中即可。但是在微服务架构中，每个服务都会有很多细粒度的endpoint。本文将要讨论的就是这种情况如何影响客户端与应用的通信，并且提出使用API网关的方法。

一、介绍

假如你正在开发一个购物的移动应用客户端，很可能要实现一个产品详细信息的页面，它会展示一个产品的详细信息。例如图2-1显示了在Amazon的Android客户端浏览产品信息时看到的页面：

​ 图2-1 购物应用

虽然这是一个智能手机应用，但是产品信息页面仍然要展现很多的信息。例如，基本的产品信息，比如名称、描述、价格，该页也会展示：

1. 购物车中的产品数量；
2. 历史订单；
3. 顾客评论；
4. 低库存预警；
5. 运送选项；
6. 各种推荐，包括与此产品时同时购买的其他产品，购买该产品的顾客也购买的产品，购买该产品的顾客浏览的产品；
7. 可替代的购买选项；

当使用单体应用架构时，移动客户端通过给应用发送一个REST请求来获取数据，比如：

GET api.company.com/productdetails/productId

负载均衡器路由这个请求到几个相同应用实例其中的一个。单体应用接着查询多个数据库表并返回响应给客户端。

比较而言ÿ