summer项目开发七:接口代理

之前本来规划先写服务注册和服务的开发,但是需要依赖代理才能进行访问。 那就先开发接口代理吧

前言

之前和一个大佬交流的时候,他说项目还得再考虑一下,细化一下,感觉不是很清晰。我认真思考了几天和参考其他项目,整理了下思路。

  1. 首先还是坚持简单原则,一个复杂庞大的框架和体系,目前一个人很难撸下去。所以组件还是用开源的,只撸业务代码
  2. 只做2件事,接口代理到后端服务, 后端服务直接可以方便的使用rpc进行内部接口调用。 大致结构如下图

绘图2.png

至于更复杂的场景和应用市面上已经有足够多的框架和体系可用。

代理设计

此次版本的代理完成以下功能:

  1. 接口注册,后端服务可以将对外暴露的api注册到代理中心。
  2. 代理层可以存储接口。然后根据访问地址进行转发。
  3. 有新接口注册进来,需要自动重载配置和代理服务。
  4. 提供接口状态检测机制,接口不可用,自动剔除

开发

  1. 目前的版本设计先支持http代理,所以增加了proxy driver,方便以后扩展其他协议代理。
  2. 使用swoole的多端口监听,创建2个监听端口,一个用于对外,一个用于后端服务注册api
  3. swoole start后,用swoole timer增加定时器,定时检查api是否可用。
  4. 后端注册api接口也通过http协议, 主要是为了后面开发可视化界面用,方便管理接口和查看接口状态
  5. 后端服务全部使用swoole的tcp协议, 代理和后端接口创建长连接, 提供连接池,设置最大链接数量,动态增长和剔除
  6. 注册服务后,同swoole_process::kill 重载服务,更新代理配置,达到实时注册,实时更新代理
  7. 本来刚开始设计的时候,代理可以设置多级目录,压测的时候发现很影响效率,所以先改为只代理一级目录,例如 /user、 /orders

后续:
既然这里整了接口注册,那为何不再把rpc接口一起上报了?然后通知其他服务更新即可?额,好像有道理,先这样做吧,实践出真知。
后端服务的rpc调用,经过采访不同的开发者,他们更接受 $rpc->user->getList(参数) 的方式, 先按大众的审美做吧。。

示例:

  1. 启动代理中心

1.jpg

  1. 启动user和orders服务,分别监听8081和8082端口

2.jpg
3.jpg

  1. 访问接口看看是否正确

4.jpg
5.jpg

如图,user和order通过代理端口8080可以访问了,老铁双击6666吧, 你还可以直接停止user和orders服务,看看接口是否剔除,然后再启动,看是否正常重新注册。

ab一波:
6.jpg

标签: 无

发表评论: