Awesome
Group-Co
V2.0的几个重要改动
- 不在支持php5.6以下版本。php>=7.0
- 基础服务之间的依赖与通信松耦合(写业务时要考虑到事务的处理)
- 数据传输通过protobuf编码，所以基础服务层编码规范要严格定义数据类型
- 将基础服务拆分了，单独分离了接口(API interface)与ServiceImpl。
V1.X版本
框架结构
框架其实分为两大板块, 协程客户端(BFF —— Backend For Frontend)与提供基础服务的服务端。
客户端（BFF）
- 利用协程特性以同步方式来编写异步代码，增强可读性。
- 将swoole的异步特性与传统框架的MVC相结合。
- 和nodejs类似，BFF端应该是胶水层(类似传统MVC的控制层)，API提供者
服务端
- 利用swoole的多进程模式创建，当前版本仅支持RPC调用。
服务化
- 目前实现了以Zookeeper、Redis、Mysql为注册中心的服务化治理.
- 支持了Apollo的配置中心化
- 服务发现，客户端缓存、心跳检测、服务监听
如何使用协程客户端，与传统框架的区别？
- 框架基本使用与传统框架基本一致，路由，控制器，调用基础服务
- 在异步调用的地方需要以yield关键词来触发协程切换
为什么服务端不采用swoole的4.X版本协程？
- 业务码迁移方便。不使用协程，在原项目或者新项目微服务化时，可以无脑迁移，完全不用担心协程化导致的连接释放、全局变量问题等等诸多限制。
- 多进程模式可以将单连接请求速度优化，利用task机制
- 稳定性、已得到线上验证
生产环境使用
- GroupCo框架目前已经全线用于我们团队，日均处理请求百万次。响应时间平均在0.1ms-10ms左右(视业务而定)
- 大型项目，服务发现不建议使用redis/mysql。也可以自己集成etcd/consul等其他服务发现工具（框架后面会更新支持）
特性
- 全异步协程调度，支持高并发
- 服务发现，客户端缓存、心跳检测、服务监听
- 统一配置中心
- 异步TCP，HTTP客户端
- 异步日志
- 异步文件读写
- 异步Mysql
- 异步Mysql事务处理
- 异步Redis
- 支持Tcp、Mysql、Redis、WebSocket连接池
- SOA服务化调用，内部封装完整的RPC通信，服务端采用异步Task处理后合并数据并返回。
- 异步TCP客户端支持并行、串行调用
- Twig、Doctrine支持视图、服务数据层
- 单元测试覆盖
文档总览
案例Demo与最佳实践
BUG反馈
如果你在使用过程中遇到安全或者框架层面使用bug，请提issue。
架构模型
与Go的协程的区别
基于Swoole的异步与php的Generator实现的异步协程，而go语言是内置协程。