产品思考(10.4)

今天是假期第四天，早上6点起床发现还在下小雨，因此一直等到差不多11点雨基本停后才出门跑步，气温也降低到了7-10度左右，但是下雨后空气质量和能见度明显好了很多，虽然温度低了点但是奥森公园的空气清晰，很适合跑步，但是由于刚下完雨再加上接近中午整个公园跑步的人很少。

这几天放假也有时间重新思考下我们的产品研发，在前面自己也提到了基于Kong来重新定制API网关管理平台，其中包括了研发平台，管理平台，监控平台，更包括了上层的能力开放和运营平台以形成一个完整的面向微服务架构体系的企业应用集成整体解决方案。

整个思路本身没有问题，但是最近一直在思考软件国产化的问题，由于我们底层使用Kong网关，那么实际上整个软件就不是完全自主研发的国产化软件。对于最初的自研ESB服务总线产品我们本身也有两个分支产品，一个是完全从头到尾自主研发的总线产品，一个是基于ServiceMix和Camel进行定制的新版本产品。当然基于开源产品进一步定制确实减少了我们很多底层研发的工作量，但是却很难真正说其是一个完全自主研发的国产化软件。类似当前国内很多企业一样，都基于国外的很多开发软件定制，然后重新换下界面就变成了一个自主国产化软件，但是实际后续问题还是很多。

为了避免后续问题，在我们新解决方案宣传里面，也不再回避Kong网关，而是直接给出我们是基于开源Kong网关进行定制管理平台，然后再进行实施的完整解决方案和产品。当初选型Kong作为API网关的底层引擎也是花了不少的时间，最主要还是其强大的插件定义机制和高性能表现。

那如果要完全自主研发，需要思考以下几个关键问题

是否自带应用中间件，还是说需要安装部署在类似tomcat等应用中间件或Web平台上层。实际上可以看到最好是做到完全自带应用中间件，那么在这里就存在应用中间件或Web平台本身也是开源的，类似选择OpenResty作为应用中间件Web平台。

完全从底层研发，实际上涉及到底层关键的几个开源组件，其中就包括了消息中间件，缓存组件等，而这几个组件本身是否继续使用开源组件，还是说需要进行自主研发，个人理解是这些底层的技术中间件可以使用开源组件，但是需要符合标准的协议标准，如果需要后期也可以随时进行替换。

对于开发语言的选择，由于考虑到大并发下的性能问题，最好还是不选择类似java这种解释性语言，而选择Lua或go语言来开发底层的API网关引擎。比如Kong网关本身就是基于Nginix+Lua作为底层的，可以获得更好的高并发下的性能。

整个API网关的扩展性问题，其中最主要的就是需要借鉴类似Kong网关当前已有的插件式开发机制，即对于安全，日志，限流熔断，路由，代理等能力都可以通过灵活可热插拔的插件方式进行定制和开发。对于每个接入的服务接口都可以灵活的配置全局插件和可定制插件。这个是整个网关研发的一个重点。

我们可以看下网上一个开源的悟空API网关GoKu API Gateway的介绍。

悟空API网关，是国内首个开源go语言API网关，帮助企业进行API服务治理与API性能安全维护，为企业数字化赋能。帮助企业管理、保护以及拓展API，提供微服务架构、Open API以及API服务治理的解决方案。网关支持OpenAPI与微服务管理，支持私有云部署，实现API转发、请求参数转换、数据校验等功能，提供图形化界面管理，能够快速管理多个API网关，提高API业务安全性。

多种鉴权方式：支持Basic 认证、API Key授权、IP认证、无认证等方式。

支持Open API：不同账户拥有独立的访问密钥。

权限管理：可针对不同策略组设置流量控制策略，包括访问QPS、访问总次数、访问IP、访问时间段等

请求转发：默认支持http rest路由。

IP黑白名单：支持用户的IP白名单、黑名单机制。

数据整形：支持参数的转换与绑定。

动态数据更新：API、插件等都支持在管理平台进行配置，服务器不用重启就可直接生效。

快速部署，支持手动部署与Docker部署。

上面只列举了一些关键内容，可以看到要自主研发实现上面这些基础的网关引擎内容并不困难，而真正困难的还是整个网关平台的基于插件方式的灵活可扩展性。

最后一点要考虑的就是在整体架构设计阶段就需要考虑API网关引擎和管理平台之间要做到彻底的解耦，即网关引擎本身就提供开放的API接口能力供管理平台对API接口进行全生命周期管理和API运行监控。这点和Kong网关的机制很类似，Kong引擎本身就提供完整的API管理接口，这也看到第三方团队很容易基于Kong网关来定制各类拦截插件和上层的管理平台，也让Kong网关具备了足够的开放性。