从零构建亿级流量API网关

这不是一个讲概念的专栏，而且我也不擅长讲概念，每一篇文章都是一个故事，我希望你可以通过这些故事了解我当时在实际工作中遇到问题和背后的思考，架构设计是种经验，我有幸参与到多个亿级系统的架构设计中，有所收获的同时也希望把这些收获分享与大家。

承接上篇，统一了接口之后并没有彻底改变被客户端碾着走的局面，因为还有一个根本的点没有被解决，就是网关对上游服务的适配问题，说白了就是每当上游有一个新的 API 要发布，网关都需要进行开发适配，我们曾经出过一个 API 标准接入的解决方案去推动上游去改造，不过遇到了很大的阻力。这个痛点直到网关实现了 API 的服务泛化调用之后才有所突破，功能一经上线，API 发布在网关就不需要再适配一行代码，完全解耦了网关与平台的业务逻辑，使网关的效能得到释放。不过，内部协议直接被转化成外部协议使得 API 在定义和格式上变得晦涩难懂和似乎不受控制，而且上游 API 的变更让网关很难处理兼容性问题，这就是所谓的有得必有失吧。再后来随着开放平台、共建生态迎来了大潮，这时已经是2015年了，我们又反客为主迅速推动上游进行 API 标准化的接入和改造，这只能说之前网关更关注 API 接入的效率，后来更关注 API 接入的质量。

1。泛化调用

泛化调用在当时起到了非常重要的作用，虽然现在已经很少在网关直接粗暴的提供泛化调用的 API，但是泛化调用在其它地方有了更广泛的应用，比如 API 测试等等。

下面我们就结合着泛化调用来说下网关服务调用的那点事，回顾上文我画的一张 API 网关的架构示意图。首先，泛化调用是网关服务调用组件提供的一种服务调用方式，而整个服务调用概括的讲主要有路由寻址、协议转换、分发调度三个步骤。