TickNet-ApiGateway的一些思考

前言

随着工作室的产品、项目越来越多，运维、开发成本极速增加，也冒出了许许多多的问题。

运维上，我们的项目，都是统一从portal机器调用，通过nginx转发到后端应用服务器。

开发上，我们需要做用户权限认证、流量监控……我们目前的方案是每个APP自己写权限认证，自己写监控……所以每一位加入工作室的同学，都需要完整的开发一次从用户鉴权到数据返回全链路调试过程。现在细细一品，有好处的地方是，按这种模式开发出项目的同学，都会学到很多东西，但是坏处显然易见，门槛高，尤其是当鉴权涉及到微信授权登录时，这导致我们招核心同学很艰难。同学们会开心的进来，但很快被难搞的技术吓跑，我觉得这一方面，我难辞其咎，因为技术团队在我手里，可用的人数太少，导致我们团队校园产品毫无产出，而我当时很多精力却是花在维护学长们留下的老项目的深渊里，当然，维护项目的接锅人目前培养好，抽出身的我，遂希望能通过对一些系统基础建设进行改革，以帮助团队能扩大自己规模，让更多人加入我们团队学到东西。

综上，我们需要实现一个技术，方便我们提高运维开发效率，API网关就是其中需要调研的一部分。通过接入Api网关服务层，可以释放出Api层的开发与维护工作，减少每个业务的重复开发工作，可以更专注与业务/服务逻辑实现。

考虑过两种方案，网关服务and中台服务。

网关服务，api调用，第一入口，统一调用、流量拦截入口。

中台服务，内部调用平台，可通过调用该平台的接口，实现用户权限获取等等接口，流量入