Jin-microservices是基于 php 语言 + hyperf 微服务 框架的完整微服务demo。
github:https://github.com/Double-Jin/jin-microservices
gitee:https://gitee.com/ljj96/jin-microservices
作为php、go双修的开发者, go 语言的微服务体系已经基本掌握,go 语言相关的微服务的文章、开源项目在网上搜索一搜一大堆,这让会 go 语言的开发者能容易地上手并实现微服务,毕竟go语言是除java外最合适做微服务的语言这一。
php语言的优势在于web生态,开发的应用绝大多数为单体应用架构。近年来随着基于 swoole 扩展的 hyperf框架的出现,让php也能开发微服务架构,这里要感谢开源工作者。但用 "php + 微服务 "作为关键词时,搜索出来的文章、开源项目都是一些简单的案例,开发者并不能通过这些简单的案例来了解微服务,这让我有了想写本项目的原始动力。
JM 是一款基于 php 语言 + hyperf 微服务 框架编写的完整微服务demo,与网上能找到的单一功能点简单实现的文章不同,JM从实际项目需求出发,力求做到git clone 项目下来后对着文件就能帮你构建微服务完整的知识体系,让你实际用hyperf开发微服务项目时能粘贴复制本项目的代码。
微服务架构并不是比单体架构先进的架构,只是在项目体量、项目开发者人数达到一定量级后的一种选择。切勿盲目鼓吹微服务,在团队开发、运维能力不足的情况下强行推进微服务架构恐怕会适得其反。
下面提到的组件并不是微服务架构才能使用,如elk、nacos、dtm这些,在单体应用里面也有合适的场景用到,取其精华来满足业务上的需要。如在生产上用到这些组件最好选择编译安装或购买云服务
- 完整微服务架构
- JsonRpc调用
- 统一异常处理
- 服务注册与服务发现
- 链接追踪
- 配置中心
- 服务限流
- 服务降级
- 分布式日志
- 分布式事务
微服务是把单体应用进行分拆后的架构,分拆后带来的问题通过引用第三方组件来解决,安装部署这些组件的时候你将会遇到很多奇奇怪怪的问题。为减低难度,本项目大部分组件采用docker来安装,整体流程我已在不同的电脑上验证数遍,即便如此还是会存在如composer、github、http/tcp访问、端口、内存、docker版本等问题,同样的操作换了台电脑就可能出问题,这需要你跟据报错内容查找相关资料自行解决。
- 8核16G电脑
- 熟悉docker
- 了解网络协议
- 基本的运维能力
-
JsonRpc调用
GET http://127.0.0.1:9501/User/UserInfo
通讯单一服务GET http://127.0.0.1:9501/User/UserBonusList
通讯单一服务GET http://127.0.0.1:9501/User/UserStoredList
通讯单一服务GET http://127.0.0.1:9501/Order/OrderList
通讯多个服务
-
统一异常处理
- 封装AppServiceExceptionHandler.php 统一处理http请求异常
- 封装RateLimitExceptionHandler.php 统一处理限流异常
- 封装JsonRpcExceptionHandler.php 统一处理JsonPrc通讯异常
- 封装DtmExceptionHandler.php 统一处理DTM事务中间件异常
-
分布式事务
数据库事务可以确保该事务范围内的所有操作都可以全部成功或者全部失败。但对分布式系统来说,数据的操作来自多个不同的数据库,单个数据库事务的成功或失败不代表整个系统的数据一致性是对的,只能够通过分布式事务来解决。
分布式事务就是指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。行业上常用的有二阶段提交、SAGA、TCC等方案,当了解原理后,你自行用http/tcp也能实现二阶段提交、SAGA、TCC。
下面的接口通过DTM调度实现在一个SAGA案例。
POST http://127.0.0.1:9501/Order/CreateOrder
分布式事务
- 不支持gRpc的服务注册与服务发现
- 配置中心组件只支持config调用,无法做到env的动态写入与框架重启,但可通过k8s实现