外部API的设计难题
让客户端直接调用服务，可行且实现简单。但存在弊端：
- 效率低，用户体验差。服务API往往颗粒度比较细，客户端需要调用多次API才能检索到需要的数据
- 封装不足，紧耦合。客户端需要了解每个服务，服务端API接口的改变，会要求客户端一同修改。
- 客户端使用不便。可能存在防火墙
API Gateway模式
API Gateway服务是外部API客户端进入基于微服务应用程序的入口点，负责请求路由、API组合、协议转换（隐藏微服务应用程序内部多种协议细节）和边缘功能（身份验证、流量监控、速率限制、缓存、指标手机、请求日志等功能）。
边缘功能的实现可以放在三个位置：
- 后端服务
- API Gateway
- API Gateway上游的边缘服务。使用边缘服务，也可以进一步的分割问题。例如身份验证，可以建立Auth服务。
好处是，封装了应用程序的内部结构。
弊端是，1.可能成为开发的瓶颈，2.只有在更新API Gateway之后，才能提供服务的API。
API Gateway的设计难题
在设计API Gateway的时候，需要考虑以下几个问题：
- 性能和可扩展性。同步I/O可能会存在线程数量和并发连接数量的上限。异步I/O，更具扩展性，但是更复杂，代码更难编写、理解和调试。
- 使用响应式编程。在API组合的时候，需要考虑到调用服务的依赖性。
- 处理局部故障。一种方法是，负载均衡器后面运行多个API Gateway服实例，另一种方式是，使用断路器。
不同客户端需要不同的数据
解决这个挑战，可以
- 让客户端指定所需要的数据，如利用expand参数，或者基于图形的API框架GraphQL
- 后端前置模式，为每个客户端，实现单独的接口。
基于图形的API框架的关键思想是，服务器的API由基于图形的模式组成，。该模式定义了一组节点（类型），他们具有属性（字段）和其他节点的关系。客户端通过，查询图的节点和与其他节点的关系，检索数据。
这种基于图形的API框架的好处是：
- 是客户端能够控制返回的数据
- API更灵活，可以显著减少开发的工作量。
两种最流行的基于图形的API技术是：GraphQL和Netflix Falcor
