大家好，欢迎来到万猫学社，跟我一起学，你也能成为微服务专家。
微服务看起来很美，但其实是需要一个技术体系或平台体系来支撑并且落地的。微服务架构建设分为两种思路：
- 框架模式
- 服务网格（Service Mesh）模式
接下来我们对上面的两个思路进行详细的介绍和对比。
框架
框架模式的典型代表是 Spring Cloud，Spring Cloud 是基于 Spring Boot 的一整套微服务开发框架，专注于为典型用例提供良好的开箱即用体验，并提供覆盖其他用例的扩展机制。
框架模式的底层运行平台可以是物理实体机或 PaaS 平台，也可以是 Kuberneters 平台或 Docker 容器。
框架模式的优势
面向应用和开发人员，定制化、协议支持灵活，适合完全自治的服务状态，方便线下调试，对操作系统平台无依赖。
框架模式的不足
对业务是侵入性的，应用需引入额外的框架或SDK包；需要构建微服务基础设施做业务能力支撑。
服务网格（Service Mesh）
Istio 是服务网格（Service Mesh）模式的典型代表。Istio 扩展了 Kubernetes ，使用强大的 Envoy 服务代理建立可编程的、感知应用程序的网络，为复杂的部署带来了标准的、通用的流量管理、遥测和安全性。
虽然在Istio的官方文档上写着可以同时支持 Kubernetes 和传统工作负载，但实际上 Istio 更适合在 Kubernetes 上运行，在物理实体机或 PaaS 平台上有一些局限性。
ServiceMesh 模式的优势和不足与 SDK 模式正好相反。
服务网格的优势
不需要额外引入框架或 SDK 包，对应用无侵入，且对 Kubernetes 天然友好支持；对流量的管控有着非常大的优势。
服务网格的不足
部署比较复杂，对底层系统有一定的依赖；通讯协议类型支持受限，对 Mesh 平台的依赖度高；对于分布式场景下的复杂度问题没有很好的解决手段。
总结
基于框架模式的微服务建设方案已经非常成熟，国内最知名的就是 Spring Cloud 、 Spring Cloud Alibaba 、 Dubbo等等，而基于服务网格（Service Mesh）的建设方案目前各个大厂也都有尝试和落地，但是要求也更高。
最后，感谢你这么帅，还给我点赞。
