## 微服發展趨勢  ## 服務網格與傳統SDK框架比較 | 比較項 | service mesh (istio) |Dubbo|Spring cloud| | --- | --- | ---| --- | | 容器+虛機混合部署 | 支持 |支持| 支持| |流量管理| 框架與語言無關 <br> 支持服務治理（熔斷，限流，降級）<br>應用級的流量監控<br>| 目前僅支持java <br>僅支持訪問權重配置| 目前僅支持java <br>服務治理需要配合Spring Cloud其他組件在客戶端實現| | 灰度發布| 非侵入方式提供分流能力、提供服務粒度、服務分組的灰度發布。流量切換非常便利。| 高版本SDK內置根據請求標簽的分流能力| 需要在SDK中配合其他組件支持，侵入業務代碼 | 監控| 支持無入侵全鏈路跟蹤、應用拓撲、訪問日志 支持無入侵全鏈路跟蹤、應用拓撲、訪問日志 | SDK內埋點，或者業務自己實現| SDK內埋點，或者業務自己實現| |性能（服務調用時延）| 經過Proxy會有1毫秒左右的延時| 業務經過進程內處理治理鏈路會產生適當耗時| 業務經過進程內處理治理鏈路會產生適當耗| | 可靠性（故障處理）| 數據面Proxy和業務進程隔離，Proxy故障不會直接影響業務進程。Proxy有獨立的健康檢查。| 治理邏輯和用戶業務共進程，治理邏輯故障會影響業務。| 治理邏輯和用戶業務共進程，治理邏輯故障會影響業務。| | 維護性| 框架維護：服務框架屬于平臺底座，由平臺專家團隊提供維護； <br>框架擴展升級：框架管理面及數據面Proxy升級用戶無感知；| 框架維護：服務框架基于SDK，服務穩定性由各個服務開發人員保障； <br>框架擴展升級：用戶需要升級已部署業務服務SDK，引入新的工作量和潛在風險；| 框架維護：服務框架基于SDK，服務穩定性由各個服務開發人員保障； <br>框架擴展升級：用戶需要升級已部署業務服務SDK，引入新的工作量和潛在風險；| | 落地難度| 無侵入式架構，傳統業務無需做服務化改造，即插即用；開放標準化接口，無遷移代價| 侵入式架構，需要引入SDK，業務代碼需要修改，引入多個SDK包依賴| 侵入式架構，需要引入SDK，業務代碼需要修改，引入多個SDK包依賴| | 社區活躍度| 【每1小時】都有代碼提交（新功能開發）；| 中斷維護幾年后，近2年開始重新維護；| Netflix提供的Spring Cloud核心組件（Eureka、Hystrix等）停止開發。|