加载中…
个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:4,062,426
  • 关注人气:5,899
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

再谈API服务网关(4.26)

(2019-04-26 08:39:19)
标签:

soa

网关

分类: IT咨询
再谈API服务网关(4.26)

这两天看Kong网关发的一些技术资料,结合我们原来基于自研ESB总线产品,感觉里面最大的一个问题还不是对Rest API接口本身的支持能力较弱问题,而是本身平台产品的扩展性和开放性问题。即Kong网关里面的插件功能,这个本身在开源的ESB总线产品中也经常会采用类似的设计,类似ESB总线本身也是基于OSGI组件化和可插拔的方式实现的,但是我们在进行定制的时候并没有对管控治理功能做到足够的插件化和灵活性。

我们回头再看来下一个API网关,里面的关键对象注意包括了接入系统(微服务),消费系统,注册接入的API接口,发布的Proxy API接口,在代理和原始服务间有一个路由对象。只要有这些最基本的对象就可以实现最简单场景下的服务接入。而其它所有的扩展可以看到都应该基于插件式方式的扩展,这些插件包括了安全认证类插件,流量控制类插件,日志监控类插件,转换类插件。

任何一个API接口和插件之间是一种多对多的关系。即一个API接口可以被作用多个插件,同时一个插件本身又可以应用在多个API接口上。插件本身就类似于AOP横切。对服务请求消息的输入和输出进行拦截,在拦截到信息后进行相关的安全或其他管控处理。当然插件本身一定会损耗性能,在实现的时候需要考虑对服务运行数据,运行统计数据的缓存,特别是对于流控的实时计算过程。

微服务模块本身可以基于容器化资源池提供的能力进行动态扩展,因此这个地方本身又有两层负载均衡,一个是kubernates提供的集群能力,一个是多个API网关本身提供的集群能力。当然API网关本身也具备负载均衡功能,可以和Kubernate进行衔接。插件我们可以先定义好基础的标准插件,同时提供足够的开放性,则用户可以自定义和扩展所需要的插件,插件的扩展具备足够的灵活性,只要符合插件开发接入规范即可进行插件的开发和注册。而可以看到我们实际提供给插件的输入和输出无碍乎就是消费系统和IP,时间,消息输入和输出等报文信息。

在API接口服务被应用了诸多插件后,必须要有配套的灵活查询方式,比如可以很方便从某个系统,某个服务,某个消费方等多个维度来检索究竟应用了哪些插件。特别是对于单个服务,可以快速的检索到这个服务究竟被应用了哪些插件。这些插件里面有全局的插件,也有个性化的插件。我们完全可以考虑在进行单个服务检索的时候,将应用的插件信息可以更加图形化和可视化的呈现。

业务系统有对应的IP地址信息,而实际的API接口路径中本身也有IP地址信息,因此我们需要维护一种业务系统在各个环境的IP地址配置表信息,这样在我们维护API地址的时候完全可以维护相对地址信息,那么我们在做接口服务的发布和环境迁移的时候就更加方便。如果是在Docker容器资源池,容器本身动态扩展,IP是可变的,这块更需要注意任何进行IP的维护和映射。

对于API网关的实现,我们仍然不推荐在业务系统侧需要前置任何SDK包的做法,这本身又加强了业务系统和API网关之间的耦合性。虽然这种做法更加容易在后续实现去中心化的架构模式,但是这样做最大的弊端就是后续SDK包的更新和版本管理问题。

日志是我们关心的另外一个关键内容,正式由于插件开发的灵活性,我们可以灵活的配置将获取到的日志信息最终写入到哪里?比如写入到本地服务器日志文件,还是数据库,还是JMS,还是说写到类似Solr库中以方便后续日志的全文检索。这些都是可以选择的方式。

0

阅读 收藏 转载 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有