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

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

泛化调用

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

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

路由寻址

一个 API 请求在调用上游服务之前，首先要通过请求方法名进行上游服务的路由寻址，寻址包括上游服务端的接口名、方法以及分组。具体来讲，网关会通过请求方法名在内存路由表中去寻找对应的服务实例地址，如果没有找到，就会去 API 元数据库中读取配置并完成服务的实例化。这是因为网关的泛化调用是一种基于配置的实现方式，所有 API 的方法和参数都以配置的方式存储在元数据库中。所以，这类 API 服务在网关是一种动态实例化的方式，它不是在服务端启动时就初始化好的服务，而是一种懒加载的方式。

在 API 服务初始化的时候我曾有过这样的设计考量，API 服务是否可以改成配置发布加载的方式？之所以没有这么做，主要因为 API 实在是太多了，有很多 API 都没有被调用过，另外就是1～2次调用 API 只会被初始化在少量的 API 网关上，对整体而言也不会有太多的资源占用。

协议转换

在获取到对应的服务地址之后，就需要对请求参数进行协议的转换和解析。当时在没有泛化调用之前，网关依赖上游提供二方包，并需要依据二方包的接口定义，才能完成请求参数的解析与协议的转换。而在有了泛化调用之后，网关可以不依赖于上游服务提供的二方包，就可以进行协议转换了，这是因为泛化调度在实现上采用了反射和动态代理的方式。

分发调度