---------------------------------------------------------------------------------
單體架構到位服務
軟件生命周期與架構演化
微服務立方體
最好的架構是演化過來
微服務拆分示例——典型電商系統的架構演化
微服務橫向擴展划分——共享核心功能模式
微服務數據分區
---------------------------------------------------------------------------------------
如何設計一個為服務系統
微服務系統的優缺點
| 優點 |
缺點 |
| 更為敏捷 |
整個系統更加復雜 |
| 更小，更專注的團隊 |
開發和測試面臨更多挑戰 |
| 更小的codebase |
分布式帶來管控難題 |
| 自由選擇不同的技術棧 |
網絡瓶頸和延遲 |
| 問題隔離 |
數據一致性 |
| 擴展性/擴容容易 |
管理文化挑戰 |
| 數據隔離 |
多服務版本對齊控制 |
|
|
技術能力要求高 |
微服務設計示例：Boat House無人機送餐系統
S1-領域模型Domain Model設計
S3 單一領域結構分析(Shipping Domain)
s4——單一領域流程f分析(Shipping Domain)
S5——應用服務邊界和條用關系設計
S7應用服務部署設計
S8服務見通訊機制設計
S9.CI/CD流水線設計
--------------------------------------------------------------------------------------
12要素法制（Software as a Service設計准則/Cloud Native應用設計准則）
基准代碼：一份基准代碼，多分部署（快速交付：合理划分邊界，良好的軟件生命周期管理）
依賴：顯式聲明依賴關系（提升開發效率：標准化，排除意外風險）
配置：在環境存儲配置(軟件發布管理：將配置轉為環境變量)
后端服務：吧后端服務當作附加資源(彈性/敏捷：使用斷路器，松散綁定)
構建、發布、運行：嚴格分離構建和運行(軟件發布管理：通過流水線實現CI/CD自動化)
進程：以一個火多個無狀態進程運行應用(雲兼容性:將狀態管理交給后端服務)
端口綁定：通過端口綁定提供服務(運營效率：應用服務只需要知道url地址與對應端口)
並發：通過進程模型進行擴展(自動彈性伸縮：轉為雲台設計，使用PCF的功)
易處理：快速啟動和優雅終止可最大化健壯性(自動彈性伸縮：將緩慢的進程轉變為后端服務)
開發環境與線上環境等價：盡可能的保持開發、預發布，線上環境相同(可靠性：憑借雲平台，獲得等價性)
日志：把日志當作事件流(實時系統指標：日志管理系統)
管理進程：后台管理任務當作一次性進程運行(可靠性：轉變為后端服務，並暴露為REST接口)