gateway处理gzcompress/lz4compress问题

今天这篇文章,主要是吐槽

gateway项目是处于接入方和backend之间的中间件服务,将backend中共同的feature提出到gateway中,算是重构。今天遇到一个问题,当接入方传入compress_type这个参数时,提示decode response失败,进一步看代码才发现,原来gateway在开发中忽略了对compress的处理,导致的这个问题。

backend主要由php编写,允许接入方通过参数选择具体的compress(压缩)方式,当前主要有gzcompress和lz4compress,压缩方法的好坏不在这里讨论。

作为gateway,用什么样的方式处理compress逻辑更合适,我就说说这个问题。

第一个想到的方法很直观,gateway基本做的是透传的工作,现在问题是php返回的response gateway解析不了,那么我就想办法解析好了,解析的原因是:后续迁移一些feature进来的时候需要用到response中的内容。遇到的问题主要有以下几个:

终于可以uncompress php的response了,以为大工搞成,可以细想以下,发现php backend做encode,gateway decode,然后再encode,到client再decode,这简直就是性能噩梦,所以静下心想了一下。发现其实,直接把compress提到gateway中处理是更妙的办法,encode/decode方面的性能和接入方直接访问php一样,没有增加。整个策略对php和接入方都是透明的。

还没完,build一个binary以后,deploy到测试环境提示glibc 2.14找不到,第二天大家讨论下,才想到cloudflare使用了他们自己封装的c library,经验判断,选择了go-lz4,虽然是个人开发者搞的,单没有依赖hell。

所以设计技术方案时一定要,多想一些,不要一头扎进技术细节中。搞的整体方案不好看。还得返工。

gateway处理gzcompress/lz4compress问题
Share this