PhpDev.App
fucongcong/GroupCo

fucongcong/GroupCo

Stars: 480

Forks: 68

Pull Requests: 29

Issues: 14

Watchers: 37

Last Updated: 2020-07-28 02:20:22

#async #swoole #soa #coroutines #generator #pool #redis #mysql #bff

PHP的服务化框架。适用于Api、Http Server、Rpc Server；帮助原生PHP项目转向微服务化。出色的性能与支持高并发的协程相结合

License:

Languages: PHP, CSS, HTML, Dockerfile

Group-Co

Build Status Code Climate

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语言是内置协程。

OPEN ISSUES

See all

RELEASES

See all