《企业级容器云架构开发指南》—2.3　微服务的高级进阶

2.3　微服务的高级进阶

所谓高级进阶，其实是微服务设计模式的总结，而所谓的设计模式简单来说就是前人留下的一些设计经验。

2.3.1　得API者得天下

亚马逊的缔造者杰夫·贝佐斯2002年在给内部员工的一封信里提到了4条内容，就是利用这简单的4条规定，经过13年的发展，贝佐斯除了做了一个网上商城之外，还把他的云、API管理做成了一个价值50亿美元的生意。

第一，无论是外部使用者还是内部使用者，我们企业内部所有的数据和功能只能通过API提供给使用者；第二，提供的API不仅要考虑与现在系统、其他的微服务、其他系统之间的协作，也要考虑便于公司外部调用；第三，除API之外，不允许有第二种方式连接部门间的系统；第四，以上规定如果不遵守，那么就要被开除。

从这个故事能看出前瞻性对于企业发展的重要性，如今可以不夸张地说“得API者得天下”。现在我们做的是企业内部和外部的交换，未来还会涉及行业的交换，即行业内会有标准的接口，其会以行业的标准提供给我们现在能提供的能力。

1.为什么需要API Gateway

随着无线技术的发展和各种智能设备的兴起，互联网应用已经从单一的Web浏览器时代演进到以API驱动的无线优先（mobile first）和面向全渠道体验（omni-channel experience oriented）的时代，如图2-19所示。

PC端的程序需要关注浏览器和分辨率；移动端的程序需要关注带宽和手机电量，甚至是地区的发展水平（也许使用短信登录更符合当地的实际）；在平板电脑上，我们很难使用右键操作。不同终端的操作特性带来了不同的要求，适配成为一个问题，我们可以通过将服务功能进行不同的组合，为Web、移动端、可穿戴设备提供不同的体验。但如果组织一个移动端的页面，需要调用20个服务，这对于移动设备来说会有些吃力，这时我们可以使用API Gateway来缓解这一问题，这种模式下多个底层的调用会被聚合成一个调用。

使用API Gateway解决了两个问题：一个问题是如何让外部诸多请求直接找到我们提供的API；另外一个问题是API之间的调用关系由谁来完成。由于互联网是全渠道的，因此除了外部直接访问这个问题需要解决，还要解决不同终端的适配。用户的接入形式多样，包括无线（手机、iPad）、Web、互联网电视、第三方合作应用等，各种用户设备的屏幕大小、操控体验方式不同。所以关于API Gateway定位做了两件比较重大的工作：一个是针对外部访问的健全、路由、控制；另一个是针对不同访问端页面的适配。简单来说，采用API Gateway需要：

封装内部系统的架构，并且为各个客户端提供API。

理想情况下针对每种用户体验类型需要一个API Gateway。

图2-19　全渠道体验时代

还可能将授权、监控、负载均衡、缓存等功能封装到独立网关层。

但是任何事情都有两面性，有优势就有劣势。

优势：封装应用内部结构，减少和简化客户和服务器端的通信。

劣势：作为一个高可用的组件，必须需要开发、部署和管理，且可能成为开发瓶颈。

这也就是说使用Gateway的优势是解决了所有外部访问的问题，但劣势是一旦Gateway做的事情较多，就需要考虑它的性能要求，对资源的依赖度，出现单点问题如何解决等。

2.如何实现一个API Gateway

（1）性能和可扩展性

API Gateway的性能和可扩展性非常重要。因此，创建一个支持同步、非阻塞I/O的API Gateway很有意义。目前已经有各类不同技术可以实现一个可扩展的API Gateway。在JVM上，采用基于NIO技术的框架，如Netty、Vertx、Spring Reactor、JBoss Undertow。一个可选的方案是NGINX Plus，NGINX Plus提供一个成熟的、可扩展的、高性能的Web服务器和反向代理，容易部署、配置和进行二次开发。NGINX Plus可以管理授权、权限控制、负载均衡、缓存，并提供应用健康检查和监控。

（2）采用反应性编程模型

对于有些请求，API Gateway可以通过直接路由请求到对应的后端服务上的方式来处理。对于另外一些请求，API Gateway需要调用多个后端服务并合并结果来处理。对于诸如产品最终页面的请求，发给后端服务的请求是相互独立的，为了最小化响应时间，API Gateway应该并发地处理相互独立的请求，但有时请求之间是有依赖的，API Gateway可能需要先通过授权服务来验证请求，然后再路由到后端服务。利用传统的同步回调方法来实现API合并的代码会有回调函数麻烦，代码难以维护，反应性编程模式是很好的解决方案。

（3）服务调用

基于微服务的应用是分布式系统，并且必须采用线程间通信的机制。线程间的通信方法有两种：一种是采用同步机制，是基于消息的方法，这类实现方法有JMS和AMQP，另外诸如Zeromq属于服务间的直接通信；还有一种线程间的通信采用异步机制，如Thrift和HTTP。事实上一个系统会同时采用同步和异步两种机制。由于它的实现方式有很多种，因此API Gateway就需要支持多种通信方式。

（4）服务发现

API Gateway需要知道每一个微服务的IP和端口，在传统应用中可能会硬编码这些地址，但在目前云基础的微服务应用中，这是一个非常简单的问题。基础服务通常会采用静态地址，可以采用操作系统环境变量来指定，但探测应用服务的地址就没那么容易了，应用服务通常动态分配地址和端口。同样地，由于扩展或者升级，服务的实例也会动态地改变。因此，API Gateway采用系统的服务发现机制，要么服务端发现，要么客户端发现。

（5）处理部分失败

在实现API Gateway的过程中，另外一个需要考虑的问题就是部分失败。这个问题发生在分布式系统中当一个服务调用另外一个服务超时或者不可用的情况下。API Gateway不应该被阻断并处于无限期等待下游服务的状态，但如何处理这种依赖于特定的场景和具体服务的失败？例如，如果产品详情页的推荐服务模块无响应，那么API Gateway应该返回剩下的其他信息给用户，因为这些信息也是有用的，推荐部分可以返回空，也可以返回固定的顶部10个给用户。但是，如果是产品信息服务无响应，那么API Gateway就应该给客户端返回一个错误。

在缓存有效的时候，API Gateway应该能够返回缓存。例如，由于产品价格变化并不频繁，API Gateway在价格服务不可用时应该返回缓存中的数值。这类数据可以由API Gateway自身来缓存，也可以由Redis或Memcached这类外部缓存实现。API Gateway通过返回缓存数据或者默认数据，来确保系统错误不影响用户体验。