上篇文章開始，我們透過一個系列文章跟大家詳細展示一個 go-zero 微服務示例，整個系列分十篇文章，目錄結構如下：
- 環境搭建
- 服務拆分（本文）
- 使用者服務
- 產品服務
- 訂單服務
- 支付服務
- RPC 服務 Auth 驗證
- 服務監控
- 鏈路追蹤
- 分散式事務
期望透過本系列帶你在本機利用 Docker 環境利用 go-zero 快速開發一個商城系統，讓你快速上手微服務。
完整示例程式碼：github.com/nivin-studio/go-zero-ma...
服務拆分
一個商城專案可拆分使用者服務（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一些思考（From 萬俊峰Kevin）
微服務拆分並沒有統一的標準，相同的業務在不同的公司很可能拆分方式會有所區別，使用者規模、團隊大小、組員能力等都會是考慮因素。但我們還是有一些基本原則可以遵循：
- 由粗到細，避免過度拆分，遵循漸進式演進的原則
- 不同服務之間應該是正交的，不要你中有我我中有你
- 避免環形依賴，服務依賴關係應該是有向無環圖
- 避免不同服務之間共享同一個資料庫
go-zero 也是一個漸進式微服務框架，你可以在業務早期使用單體來快速滿足業務，當業務增長並有需要的時候，做最小的改動即可做到漸進式的服務拆分。
此類話題也可以在 go-zero 社群群裡一起討論。
專案地址
歡迎使用 go-zero 並 star 支援我們！
微信交流群
關注『微服務實踐』公眾號並點選 交流群 獲取社群群二維碼。
本作品採用《CC 協議》，轉載必須註明作者和本文連結