OpenResty 在物流网关中的应用

来这里找志同道合的小伙伴！

为什么选择OpenResty

物流网关在建设之初就重点关注 性能 、 稳定性 、 扩展性 以及 可持续性 。

在技术选型阶段重点关注三个方面：

• 在网络 I/O 模型方面，出于性能的考虑，需要非阻塞的 I/O 模型；

• 由于物流网关对外提供的是 Http/s 协议，所以需要成熟的支持 Http/s 协议的技术；

• 这个世界变化很快，只有拥抱好的生态才能促进持续发展。

综合这三方面的需求，发现 OpenResty 是一个很好地选择。

首先，OpenResty 利用协程实现了同步非阻塞的 cosocket，利用 cosocket 既可以享受同步编程的简单，又可以享受非阻塞IO的性能优势。

其次，Nginx 处理 Http/s 请求，目前在业界无人能出其右，性能和稳定性有目共睹。

同时，期望利用插件机制扩展功能。这方面 Kong 这个网关项目（这个项目基于 OpenResty）给出了优秀的参考方案。

插件化扩展方法

物流网关的功能纷繁复杂，核心的组件有安防、认证、限流、协议转换、日志，网关的这些核心功能最好都是插件化的，这些插件能够根据不同的商家动态加载和卸载，这样才能满足不同商家的需求。

物流网关的插件机制依赖于 Nginx 处理请求的生命周期模型，安防、认证、限流这三个插件在 Rewrite / Access 阶段动态加载执行，协议转换、负载均衡在 Content 阶段动态加载执行，而日志在 Log 阶段异步处理。

每一个请求都需要根据业务配置动态加载，这些配置存储在 MySQL 数据库中，在高并发场景下，如果每次请求都要访问 MySQL 数据库，那 MySQL 数据库一定会成为瓶颈直至宕机，因此引入多级缓存。

缓存的设计

物流网关采用了多级缓存，首先是利用 ngx.shared.DICT 实现的本地缓存，集中式缓存使用的是 Redis，物流网关并不直接访问数据库，而是通过调用 RPC 服务来访问数据库。

Redis 中的缓存是长期有效的，Redis 和 MySQL 之间的数据同步依赖双写机制，本地缓存和 Redis 的同步同时采用了两种方法，一种是利用Redis实现了一个简单MQ，网关集群节点订阅元数据变更的消息，当有变更时，清空相关的本地缓存；为了容错，本地缓存设置了失效期，这样能够保证数据总是有机会同步到本地缓存。

负载均衡器的设计

物流网关自研了支持 RPC 协议的 Lua 客户端，功能与 Java 版的客户端类似，值得一提的是负载均衡器的设计更加智能，在压测阶段发现，同样规格的 Docker，性能差异非常大，这个差异很可能和宿主机的网络、CPU 负载、内存使用率有关，这个影响因素是动态变化的，因此静态的负载均衡配置（例如轮训、随机、权重等负载均衡策略）难以满足需求，理想的负载均衡器应该能够根据 RPC 服务负载来动态调整流量分发。

物流网关的调度算法选用的是最小连接数调度算法，类似于大家去超市排队结账，总是选取长度最少的 队伍 。连接数的计算是这样的：发送请求的时候连接数+1，响应返回或者异常的时候连接数-1。

Json 跨语言的坑

Json 作为一种成熟的序列化方案，已经存在很久了，但是在跨语言方面  Json  并不成熟，A == json.decode(A).encode 在跨语言的时候并不是总能成立。例如对于二进制的序列化，在 Java 里都是将它转换成 base64 的字符串，例如 0X3F 会被序列化成”/”，OpenResty 自带的 cjson 会把“/”反序列化成字符串“/”，至此都没有问题，但是 cjson 序列化字符串“/”时，得到的却是“\/”，因为按照 json 规范“/”是需要被转义的。最终结果就是网关的输入是“/”输出却是“\/”。

所以物流网关自研了无损的 json 序列化组件，完全在字符串基本上操作 json，这样就避免了类型转换带来的问题。下图是一个 json 字符的解析过程。

性能优化

OpenResty 提供了优秀的性能分析工具，可以在运行时对系统采样，并生成火焰图，通过火焰图可以快速定位性能瓶颈出现在哪行代码。物流网关在单机全链路压测中 TPS 能够到达10万，将硬件性能发挥到了极致。

总结

目前，物流网关作为京东物流开放技术平台的核心服务，支撑了所有 Http/s 协议的开放业务，已经平稳度过2018年的618全球年中购物节以及11.11全球好物节。借助 Lua 优秀的表达能力，以及插件化机制，物流网关近一年实现了功能的快速演进，真正做到了快速响应业务发展。

RECOMMEND