## 微服发展趋势  ## 服务网格与传统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等）停止开发。|