共计 2048 个字符,预计需要花费 6 分钟才能阅读完成。
上篇文章开始,咱们通过一个系列文章跟大家具体展现一个 go-zero 微服务示例,整个系列分十篇文章,目录构造如下:
- 环境搭建
- 服务拆分(本文)
- 用户服务
- 产品服务
- 订单服务
- 领取服务
- RPC 服务 Auth 验证
- 服务监控
- 链路追踪
- 分布式事务
冀望通过本系列带你在本机利用 Docker 环境利用 go-zero 疾速开发一个商城零碎,让你疾速上手微服务。
残缺示例代码:https://github.com/nivin-studio/go-zero-mall
服务拆分
一个商城我的项目可拆分用户服务(user)、订单服务(order)、产品服务(product)、领取服务(pay)、售后服务(afterSale)…
每个服务都能够再分为 api
服务和 rpc
服务。api
服务对外,可提供给 app
调用。rpc
服务是对内的,可提供给外部 api
服务或者其余 rpc
服务调用。整个我的项目服务依赖流程图大抵如下:
1 用户服务(user)
api 服务 |
端口:8000 | rpc 服务 |
端口:9000 |
---|---|---|---|
login | 用户登录接口 | login | 用户登录接口 |
register | 用户注册接口 | register | 用户注册接口 |
userinfo | 用户信息接口 | userinfo | 用户信息接口 |
… | … | … | … |
2 产品服务(product)
api 服务 |
端口:8001 | rpc 服务 |
端口:9001 |
---|---|---|---|
create | 产品创立接口 | create | 产品创立接口 |
update | 产品批改接口 | update | 产品批改接口 |
remove | 产品删除接口 | remove | 产品删除接口 |
detail | 产品详情接口 | detail | 产品详情接口 |
… | … | … | … |
3 订单服务(order)
api 服务 |
端口:8002 | rpc 服务 |
端口:9002 |
---|---|---|---|
create | 订单创立接口 | create | 订单创立接口 |
update | 订单批改接口 | update | 订单批改接口 |
remove | 订单删除接口 | remove | 订单删除接口 |
detail | 订单详情接口 | detail | 订单详情接口 |
list | 订单列表接口 | list | 订单列表接口 |
paid | 订单领取接口 | ||
… | … | … | … |
4 领取服务(pay)
api 服务 |
端口:8003 | rpc 服务 |
端口:9003 |
---|---|---|---|
create | 领取创立接口 | create | 领取创立接口 |
detail | 领取详情接口 | detail | 领取详情接口 |
callback | 领取回调接口 | callback | 领取回调接口 |
… | … | … | … |
5 创立我的项目目录
- 创立
mall
工程
$ mkdir mall && cd mall
$ go mod init mall
- 创立
common
目录
$ mkdir common
- 创立
service
目录
$ mkdir service && cd service
- 创立
user api
,user rpc
,user model
目录
$ mkdir -p user/api
$ mkdir -p user/rpc
$ mkdir -p user/model
- 创立
product api
,product rpc
,product model
目录
$ mkdir -p product/api
$ mkdir -p product/rpc
$ mkdir -p product/model
- 创立
order api
,order rpc
,order model
目录
$ mkdir -p order/api
$ mkdir -p order/rpc
$ mkdir -p order/model
- 创立
pay api
,pay rpc
,pay model
目录
$ mkdir -p pay/api
$ mkdir -p pay/rpc
$ mkdir -p pay/model
- 最终我的项目目录
├── common # 通用库
├── service # 服务
│ ├── order
│ │ ├── api # order api 服务
│ │ ├── model # order 数据模型
│ │ └── rpc # order rpc 服务
│ ├── pay
│ │ ├── api # pay api 服务
│ │ ├── model # pay 数据模型
│ │ └── rpc # pay rpc 服务
│ ├── product
│ │ ├── api # product api 服务
│ │ ├── model # product 数据模型
│ │ └── rpc # product rpc 服务
│ └── user
│ ├── api # user api 服务
│ ├── model # user 数据模型
│ └── rpc # user rpc 服务
└── go.mod
一些思考
微服务拆分并没有对立的规范,雷同的业务在不同的公司很可能拆分形式会有所区别,用户规模、团队大小、组员能力等都会是思考因素。但咱们还是有一些根本准则能够遵循:
- 由粗到细,防止适度拆分,遵循渐进式演进的准则
- 不同服务之间应该是正交的,不要你中有我我中有你
- 防止环形依赖,服务依赖关系应该是有向无环图
- 防止不同服务之间共享同一个数据库
go-zero 也是一个渐进式微服务框架,你能够在业务晚期应用单体来疾速满足业务,当业务增长并有须要的时候,做最小的改变即可做到渐进式的服务拆分。
此类话题也能够在 go-zero 社区群里一起探讨。
我的项目地址
https://github.com/zeromicro/go-zero
欢送应用 go-zero
并 star 反对咱们!
微信交换群
关注『微服务实际 』公众号并点击 交换群 获取社区群二维码。
正文完