大家好,欢迎来到万猫学社,跟我一起学,你也能成为微服务专家。
微服务看起来很美,但其实是需要一个技术体系或平台体系来支撑并且落地的。微服务架构建设分为两种思路:
- 框架模式
- 服务网格(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)的建设方案目前各个大厂也都有尝试和落地,但是要求也更高。
最后,感谢你这么帅,还给我点赞。