内容简介：最近在使用公司的网关，发现一些不好用的地方，加上之前自己有做一个熔断器，其原理其实都差不多， 总结一些我心目中的网关应有的特性：当然只是YY，并没有实际去实现一个。YY基于之前做的熔断器和公司的网关的使用体验。所以如果要我在guard上改，我大概会做这些事情，因为guard总体上还是比较符合我的预期的（当然我不会改了， 因为这是一篇YY文）：
最近在使用公司的网关，发现一些不好用的地方，加上之前自己有做一个熔断器，其原理其实都差不多， 总结一些我心目中的网关应有的特性：
当然只是YY，并没有实际去实现一个。YY基于之前做的熔断器和公司的网关的使用体验。
- 不更改URL Path，这样子就不会影响一些第三方封装的SDK
- 路由注册应当支持多级泛匹配，这样就可以容忍网关后面是一个通用代理
- 理论上完美的网关应当做成Nginx一样，是一个纯粹的代理，这样所有的SDK就无需更改代码即可使用， 同时网关可以完成熔断，统计的功能。但是这样的缺点在于，不能识别流量来源，如果要做到这个功能， 就需要增加一些头部，例如用一个token来标志是什么应用在请求，不过个人以为作用不大，因为HTTP请求 是可以模拟的，攻击者可以伪造。
- 同时支持HTTP/1.0以上和HTTP/2，最好还能支持websocket，如果要做到这三个，估计RFC要熟读了。
- 确实应当提供一个地方去注册路由，并且由管理员来审核，这样在大规模团队的时候，可以提高安全度。
所以如果要我在guard上改，我大概会做这些事情，因为guard总体上还是比较符合我的预期的（当然我不会改了， 因为这是一篇YY文）：
- 自己重写fasthttp，支持HTTP/1.0以上，HTTP/2和websocket，但是要充分借鉴fasthttp的思想，以提供高性能 代理
- 把由后端App自主注册更改成web界面注册，管理员审核
- 增加统计功能，可以是日志统计，这样对网关性能没有影响，但是展示效果会差一些因为数据肯定会有滞后性；也可以是 即时统计，但是这样有缺点就是对性能会有比较大的影响，我会采取前者。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。