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支持视图、服务数据层
• 单元测试覆盖

文档总览

• 快速开始
  • 环境依赖
  • 启动项目
  • Docker容器启动
• 客户端
  • 异步Tcp客户端
  • 异步WebSocket客户端
  • 异步Http客户端
  • 异步Redis客户端
  • 异步Mysql客户端
  • 异步Log日志
  • 异步文件读写
  • 异常Exception
• 服务端(用于基础服务开发)
  • Service
  • Dao
  • Cache
  • Log日志类
  • FileCache文件缓存类
• 服务中心
  • 服务治理流程
  • 注册中心
  • 服务调用
  • 使用TCP连接池
  • 服务调用监控
  • 服务调用失败事件
  • 调试模式
• 配置中心
  • 配置中心的使用
• 框架基础类
  • Config配置类
  • StaticCache静态缓存类
  • Route路由类
  • Controller控制器类
  • View视图类
  • Request请求类
  • Response响应类
  • Event事件类
  • Listener监听类
  • Subscriber多事件监听
  • EventDispatcher事件调度
• 单元测试
• 控制台

案例Demo与最佳实践

• WebSocket简单示例,聊聊集群时的消息转发
• 实现服务异常邮件通知
• 秒杀系统,与GO切磋
• 日志分析服务
• Api服务

BUG反馈

如果你在使用过程中遇到安全或者框架层面使用bug，请提issue。

架构模型

• 架构模型

与Go的协程的区别

基于Swoole的异步与php的Generator实现的异步协程，而go语言是内置协程。