在上一篇重学swoole文章后，为了进一步更深入的进行实战，我还是决定从造轮子开始，写个基于swoole的小框架，毕竟其他实战情况工作中遇到需要的场景还比较少。既然有那么多轮子为啥还要造？买的或捡东西和自己做的能一样么，收获的是造轮子的过程和解决造轮子过程中遇到的问题所带来的快感和提升。
既然要造轮子，那么就需要了解目前框架的情况，所以拜读了下用得比较多的swoft和easyswoole的源码，总体来说满足不同需求情况。这就带来思考了，我是要造什么样的轮子？是要满足什么需求和场景？
需求和场景分析：
- 简单易用
- 性能好
- 开发快速
- 只支持api，暂不考虑web
额。。。这不是废话么，简单易用，功能就单一，重型武器比然就复杂。看来不能掉入这个坑，得先约定下，避免后期陷入纠结的死循环。 以简单和快速开发为基础，复杂功能底层隐藏，实在过于复杂的，寻找第三方解决方案或者尝试开发辅助扩展解决。 一句话，撸码要少，速度要快。 需要重型武器的，可以直接转java用spring了， 我设计保持简单足够，没有某些功能就没有吧。
经过一系列思考和知识整理，目前列出一些思考点和设计想法。
- server和manage
用swoole不止由于他的高性能，还有就是现在流行的微服务化，现在是spring全家桶系列大行其道的时代，php应该也可以做进一步的尝试，微服务我个人认为是以后的主流开发方向，所以从设计上就应该是从这方面起步。
manage,我设计manage作为服务的简单管理，本来想集成第三方，例如consul等，但是最终我还是觉得尝试自己开发个简单的服务管理，主要完成以下功能：
manage。
目前整理的需要开发的功能大致如下：- server的端口范围设置 (manage端分配，如果注册server带了端口检查是否占用)
- server注册 (统一管理server和负载，并给出状态报告)
- server状态检测和监控 (完成热插拔)
- config全局配置 (热更新)
- 请求转发 (http+websocket)
- auth统一授权 (统一授权，下放登录信息，server可直接获取登录信息)
- 日志收集 (自动收集日志，看是否用es进行管理日志或者其他方案)
- 降级限流 (这个没想好怎么做，难道每个server的降级写着manage端还是有单个server自己控制流量)
- 集中式的事件注册和分发 (基于异步事件，server统一上报，通过注册server监听，分发到监听的server上)
- 集中式锁（初步设想是注册服务的时候，带上lock关键词，分发的时候，在manage端基于swoole内存操作级别的锁，或者单个server的基于redis的锁）
- 通用服务插件 (提供一些通用服务，比如短信，邮件等)
- 支持集群和docker化
- 中间件
之所以设计这些，是为了让server开发简单，隐藏细节，让业务开发更回归业务本身。
server
- server创建，compser create '**' server1,通过命令行一键创建。
- 修改配置manage地址和端口，填写注册名称
- 启动服务
- 开始开发
- 脚手架
提供全局对象，管理router,requset,action,service,dao,entity,listener,event,log。自动注册路由和服务器，热重载配置及服务列表。简单对外暴露rpc服务，单请求唯一id标识
- 开发周期
预计2019年10月1日出个雏形版本。本人太懒，给个时间强制约束下自己 - 命名
要取一个响亮的名字，呃。。。。spring春天，这个想法诞生于夏天，那么就叫他summer吧。足够霸气，如夏花之绚烂
