摘要
一個完整的電商項目微服務的實踐過程，從選型、業務設計、架構設計到開發過程管理、以及上線運維的完整過程總結與剖析。
講師介紹
產品需求介紹
- 純線上商城
- 線上線下一體化
- 跨行業
- 跨商業模式
從0開始，我們應該采用微服務嗎？
不適合采用微服務架構：
- 應用程序規模小
- 領域不明確
- 組織不能做出改變
- 缺乏理解
- 團隊不成熟
微服務的成本（從單體轉入微服務）
- 協作問題
- 引發分布式事務問題
- 增加大量的重復代碼
- 服務監控
- 日志的搜集與展示
針對微服務所帶來的成本可用通過 K8S 解決
K8S 的成本
- 統一的配置問題
- 增加大量的部署時間
- 服務注冊與發現
- 負載均衡
- 服務器成本增加
K8S 的優勢
- 無狀態服務高可用
- 有狀態數據高可用
- 快速擴容
- 按量付費
- 基於 GitLab 和 helm 的 CI/CD
- 統一配置
- 服務注冊與發現
- 日志搜集
領域划分
微服務架構
微服務實踐
- 共享核心庫：核心庫部署到私有 nuget server，並通過 CI 自動化
- 共享代碼：基於 GitLab CI 發布業務組件到 nuget server
- 服務模板：grpc server
- 同步通信：本地調用與 RPC 調用單體部署與分布式部署
- 異步通信：基於 masstransit 庫的 saga
- 統一認證授權：Ocelot
- 協作：API 管理，Postman
- 持續集成：基於 GitLab CI 和 helm CICD 部署到 K8S
- 未來：分布式事務，Service Mesh 服務網格
微服務的價值
- 微服務架構解放小團隊生產力，提高市場響應力
- 微服務是顆子彈，需要 PaaS 作槍，瞄准的是快速變化的目標
視頻鏈接
本作品采用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可。
歡迎轉載、使用、重新發布，但務必保留文章署名 鄭子銘 （包含鏈接： http://www.cnblogs.com/MingsonZheng/ ），不得用於商業目的，基於本文修改后的作品務必以相同的許可發布。
如有任何疑問，請與我聯系 (MingsonZheng@outlook.com) 。