業務準備
一個傳統web系統，使用者模組永遠是不可或缺的一環，也作為一個系統的基石。下列的教程中將使用go-micro來編寫一個使用者服務，以此作為開發的基礎。下面是一個使用者服務中暴露的api以及內部呼叫rpc方法規劃。
api
| url | method | 簡介 |
|---|---|---|
| /user | POST | 註冊 |
| /user | GET | 獲取使用者資訊 |
| /user/token | POST | 認證獲取token |
| /user/token | PUT | 驗證token |
| /user/password | POST | 發起密碼重置 |
| /user/password | PUT | 重置密碼 |
rpc
| 方法名 | 簡介 |
|---|---|
| Get | 根據ID獲取使用者資訊 |
| Pagination | 獲取分頁資料 |
| Create | 建立使用者 |
| Update | 更新使用者 |
| Delete | 刪除使用者 |
| Auth | 認證獲取token |
| Validate | 驗證token |
| CreatePasswordReset | 建立密碼重置記錄 |
| ResetPassword | 密碼重置 |
架構設計
技術選型
- 註冊中心：etcd
- api閘道器：micro-api v2
- api服務：gin
- 微服務：go-micro v2
- 資料庫：mysql
- 服務追蹤：opentracing/jaeger
- 服務監控：prometheus + grafana
- 訊息佇列：rabbit-mq
- 快取系統：redis
- 搜尋服務：elasticsearch
- 日誌系統：ELK
上述中所有描述的元件，在單機階段我們都使用docker-compose來進行實踐。後續我完成編碼以及單機部署後再基於k8s進行部署
總結一下上圖中使用者請求到響應的整個流程，使用者在前端發起請求，請求到達伺服器後透過nginx或其他的負載均衡器中，透過反向代理把請求轉發到micro-api統一閘道器。關於micro-api閘道器，你同樣可以把他理解為一個分發路由，micro-api啟動後會透過服務發現找到所有已經註冊的api服務，然後解析路由規則將請求分發到到我們指定的api服務。而api服務會透過grpc向service請求，實際中api服務並不參與過多的密集計算或IO處理，最終處理壓力交由service來承擔。service處理完成將響應返回給api服務，api再返回響應給到接入層（nginx）,從而完成整個請求響應的閉環。至於上圖中出現的服務治理，服務監控，鏈路追蹤等細節，我們後續在執行到相關知識時再詳細瞭解。
本作品採用《CC 協議》，轉載必須註明作者和本文連結