之前本来规划先写服务注册和服务的开发，但是需要依赖代理才能进行访问。 那就先开发接口代理吧
前言
之前和一个大佬交流的时候，他说项目还得再考虑一下，细化一下，感觉不是很清晰。我认真思考了几天和参考其他项目，整理了下思路。
- 首先还是坚持简单原则，一个复杂庞大的框架和体系，目前一个人很难撸下去。所以组件还是用开源的，只撸业务代码
- 只做2件事，接口代理到后端服务， 后端服务直接可以方便的使用rpc进行内部接口调用。 大致结构如下图
至于更复杂的场景和应用市面上已经有足够多的框架和体系可用。
代理设计
此次版本的代理完成以下功能：
- 接口注册，后端服务可以将对外暴露的api注册到代理中心。
- 代理层可以存储接口。然后根据访问地址进行转发。
- 有新接口注册进来，需要自动重载配置和代理服务。
- 提供接口状态检测机制，接口不可用，自动剔除
开发
- 目前的版本设计先支持http代理，所以增加了proxy driver,方便以后扩展其他协议代理。
- 使用swoole的多端口监听，创建2个监听端口，一个用于对外，一个用于后端服务注册api
- swoole start后，用swoole timer增加定时器，定时检查api是否可用。
- 后端注册api接口也通过http协议， 主要是为了后面开发可视化界面用，方便管理接口和查看接口状态
- 后端服务全部使用swoole的tcp协议， 代理和后端接口创建长连接, 提供连接池，设置最大链接数量，动态增长和剔除
- 注册服务后，同swoole_process::kill 重载服务，更新代理配置，达到实时注册，实时更新代理
- 本来刚开始设计的时候，代理可以设置多级目录，压测的时候发现很影响效率，所以先改为只代理一级目录，例如 /user、 /orders
后续：
既然这里整了接口注册，那为何不再把rpc接口一起上报了？然后通知其他服务更新即可？额，好像有道理，先这样做吧，实践出真知。
后端服务的rpc调用，经过采访不同的开发者，他们更接受 $rpc->user->getList(参数) 的方式， 先按大众的审美做吧。。
示例：
- 启动代理中心
- 启动user和orders服务，分别监听8081和8082端口
- 访问接口看看是否正确
如图，user和order通过代理端口8080可以访问了，老铁双击6666吧， 你还可以直接停止user和orders服务，看看接口是否剔除，然后再启动，看是否正常重新注册。
ab一波：
