Jin-microservices是基於 php 語言 + hyperf 微服務 框架的完整微服務demo。
github:github.com/Double-Jin/jin-microser...
gitee: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呼叫
- JWT認證
- 統一異常處理
- 服務註冊與服務發現
- 訊息佇列
- 連結追蹤
- 配置中心
- 服務限流
- 服務降級
- 分散式日誌
- 分散式事務
微服務是把單體應用進行分拆後的架構,分拆後帶來的問題透過引用第三方元件來解決,安裝部署這些元件的時候你將會遇到很多奇奇怪怪的問題。為減低難度,本專案大部分元件採用docker來安裝,整體流程我已在不同的電腦上驗證數遍,即便如此還是會存在如composer、github、http/tcp訪問、埠、記憶體、docker版本等問題,同樣的操作換了臺電腦就可能出問題,這需要你跟據報錯內容查詢相關資料自行解決。
- 8核16G電腦
- 熟悉docker
- 瞭解網路協議
- 基本的運維能力
目錄結構
|-- api-gateway //閘道器服務專案程式碼 |-- order-srv //訂單服務專案程式碼 |-- user-srv // 使用者服務專案程式碼 |-- task-srv // 定時任務、佇列消費服務專案程式碼 |-- README.md //說明文件
完整微服務架構
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
通訊多個服務
JWT認證
GET http://127.0.0.1:9501/Auth/Login
使用者登入GET http://127.0.0.1:9501/Auth/Logout Authorization : Bearer {{token}}
使用者退出登入
統一異常處理
- 封裝AppServiceExceptionHandler.php 統一處理http請求異常
- 封裝RateLimitExceptionHandler.php 統一處理限流異常
- 封裝JsonRpcExceptionHandler.php 統一處理JsonPrc通訊異常
- 封裝DtmExceptionHandler.php 統一處理DTM事務中介軟體異常
服務註冊與服務發現
訊息佇列
GET http://127.0.0.1:9501/User/UserRabbitMQ
呼叫投遞使用者訊息佇列介面GET http://127.0.0.1:9501/Order/OrderRabbitMQ
呼叫投遞訂單訊息佇列介面
連結追蹤
配置中心
服務限流
GET http://127.0.0.1:9501/RateLimit/Test
服務降級
GET http://127.0.0.1:9501/CircuitBreaker/Test
分散式日誌
當系統變為叢集后,應用日誌在數十臺甚至是上百臺不同的伺服器上,能實現日誌的統一查詢、分析和歸檔等功能便可稱為分散式日誌系統。
生產上方案會有很多,如將日誌直接輸出來Elasticsearch,如使用雲服務商提供的日誌收集。本案例採用的是透過filebeat將日誌同步到ELK中。
分散式事務
資料庫事務可以確保該事務範圍內的所有操作都可以全部成功或者全部失敗。但對分散式系統來說,資料的操作來自多個不同的資料庫,單個資料庫事務的成功或失敗不代表整個系統的資料一致性是對的,只能夠透過分散式事務來解決。
分散式事務就是指事務的發起者、資源及資源管理器和事務協調者分別位於分散式系統的不同節點之上。行業上常用的有二階段提交、SAGA、TCC等方案,當了解原理後,你自行用http/tcp也能實現二階段提交、SAGA、TCC。
下面的介面透過DTM排程實現在一個SAGA案例。
POST http://127.0.0.1:9501/Order/CreateOrder
分散式事務
- 不支援gRpc的服務註冊與服務發現
- 配置中心元件只支援config呼叫,無法做到env的動態寫入與框架重啟,但可透過k8s實現
- hyperf:hyperf.wiki/2.2/#/README
- dtm:en.dtm.pub/
- nacos:nacos.io/zh-cn/docs/what-is-nacos....
- elk:www.elastic.co/cn/what-is/elk-stac...
本作品採用《CC 協議》,轉載必須註明作者和本文連結