一、微服務架構特點
1、服務服務力度：粒度是圍繞業務進行拆分的。
2、獨立進程：任何一個微服務從它的開發，測試，上線，以及運維等過程都可以獨立的進行，不依賴以其他的微服務。
3、圍繞業務建模：微服務架構是圍繞業務建模的
4、輕量級通信：通信模式是輕量級的，兩個模塊之間的通信沒有語言關系，沒有平台關系。
5、去中心化管理：微服務具體用的語言，平台都沒有強行的規定，以平台，語言沒有依賴關系。
二、微服務架構設計
微服務網關：作為客戶端服務器，它會維護海量的鏈接，對用戶身份的校驗，session的管理，請求的轉發。不做業務處理。對外提供HTTP接口。
微服務聚合層：根據用戶的請求，拆分為多個微服務原子層，向微服務原子層發送請求，發送回來之后在微服務聚合層把請求的結果匯集起來，提供給微服務網關層，把結果返回給客戶端。提供RPC接口。
微服務原子層：提供這些微服務的增刪改查的修改。提供RPC接口。
微服務數據層：對每一個微服務的數據單獨存在一個數據庫中。
去中心化管理：采用相同的語言開發。
備注：
網關層：http/https接口協議，安全
聚合層：服務器內部同過rpc接口協議，傳輸更快，通信效率更高
需要兩個中心：微服務注冊中心、微服務配置中心
將聚合層再按業務功能拆分成多個聚合層
三、通信協議和服務的注冊、發現
通信協議-輕量級通信協議
1、REST：基於HTTP，與語言、平台無關
2、HAL：基於REST協議做的一個提升，國內用的暫時比較少
3、RPC：遠程過程調用，國內開源RPC框架用得比較多，如：Apache、Thrift、gRpc、dubbo
4、消息隊列：兩個微服務通過消息隊列通信，可以把同步的調用變成異步的調用
RPC相較HTTP的優勢：
1、省去了HTTP頭信息，傳輸包更輕量
2、基於TCP長連接，效率比較高
3、安全方面高於HTTP
四、柔性可用和服務治理
1、為什么需要柔性可用？
流量高峰期，短時請求量大的情況下：服務能力有限、性能下降、服務宕機、系統雪崩
2、柔性設計如何做？
目標：保證核心服務可用；非核心服務弱可用，甚至不可用
方式：系統降級、數據層降級、柔性可用策略
（1）系統降級：拒絕部分請求、關閉部分服務（業務緊密）
（2）數據層降級
更新請求：持久到消息隊列，只更新緩存，暫不更新數據庫
讀請求：讀取緩存
數據補齊：后續需將消息隊列中的數據寫入數據庫中
（3）柔性可用策略
自動打開柔性可用策略，不依賴人員手動開啟
測試環境時需演練，確保線上生效
3、服務治理
（1）服務需要監控：監控進程狀態，及時發現問題，掌握主動權
（2）主要監控：機器資源、進程狀態
（3）監控手段：
（4）微服務實時監控
例如：請求平均耗時、請求異常條數等，對比最近幾天的數據情況發現問題
（5）微服務監控框架：open-falcon、定制開發