服务在拆分成微服务之后，最显著的特征就是服务的数量增多了。由此导致原本只需要调用一个接口就能完成的任务现在需要调用多个接口了。拿电商的商品详情界面为例。在商品详情界面一般会显示：商品详情、购买数量、剩余数量、评价和相关推荐等。在单应用的情况下，只调用一个产品详情的接口就能够获取全部的信息。在拆分成多个微服务之后，服务的数量增多，商品详情、购买数量、剩余数量、评价和相关推荐等可能会被拆分成独立的微服务。这个时候为了能够完成商品详情的展示，需要调用5个接口。无形增加了客户端的复杂度。
调用事例
另外，这样会导致客户端与各个服务的耦合。如果后续发生服务的合并或者拆分都需要客户端的修改。一般情况下，微服务都是多实例的，如果客户端需要感知这些IP，那么在服务重启或者升级的时候，客户端都需要更新这些连接信息。
为了解决上面的问题，API网关就出现了。API网关只需要提供一个粗粒度的接口就可以了。在查询商品详情的时候，客户端直接向API网关发送查询商品详情的接口，由API网关进一步调用其他的微服务并汇聚响应。
API网关
API网关的出现，解耦了客户端与各个微服务之间耦合关系。作为API网关，需要具备如下的特点：
1.高性能。API网关封装了对后面微服务的调用，所以API网关不能成为性能瓶颈。
2.易用。微服务是需要注册到API网关的，多个团队都需要对其更改，如果修改难度大，会导致开发效率下降。
3.具备服务发现的能力。因为后台微服务多实例的原因，API网关需要服务发现的能力。
4.具备容错的能力。一个请求在API网关被拆分成多个请求，API网关需要有能力处理某个或者某几个请求失败的情况。比如，某个关键调用失败，这个时候，API网关需要返回错误。对于一些次要的服务，在调用失败的时候，可以选择服务降级的处理。推荐服务失败的情况下，可以返回一个默认的推荐列表。还有一些服务的失败可能需要支持重试。另外，服务的熔断器也需要实现在API网关。在服务故障时，触发熔断，对这个服务的调用，API网关直接返回失败，避免浪费资源。
5.服务的编排。对于一些请求，是没有依赖关系的，可以并发处理。对于另外一些请求，存在依赖关系，API网关在调用后台服务的时候，需要按依赖顺序进行调用。
6.协议转换。一般情况，微服务的协议比较单一，rest+rpc的模式，是不需要协议转换的。在存在协议不一致的情况下，API网关需要具备协议转换的能力。但是要注意，尽量让微服务的协议保持清爽。
现在有很多的开源的API网关。在开发资源资源有些的情况下，可以使用开源软件。为了学习，也可以进行源码的阅读。
閱讀更多 java技術小碼農 的文章
