课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
服务网格与微服务架构开发都是目前许多软件开发程序员都在使用的软件开发方式,下面我们就通过案例分析来了解一下,传统微服务架构都有哪些缺陷。
先理解下什么是传统微服务架构,就是微服务治理能力如服务注册、发现、熔断、限流等与业务逻辑解耦,单独以SDK的形式提供给开发者,但服务治理和业务逻辑还是跑在一个进程中的。再看下这种传统微服务架构带来了哪些痛点:
SDK升级维护成本高,由于SDK耦合在业务进程中,那每次SDK升级必然需要绑定业务一起升级,这对于拥有成千上万的业务系统是很难接受的,而且涉及到SDK大版本的变更可能还会有兼容性问题;
多语言框架SDK维护成本高,SDK意味着和语言绑定,那不同语言都要维护不同的SDK版本,所以很少有多语言的传统微服务框架,能流行起来的也就是某个语言的框架如JAVA系的SpringCloud、Dubbo,go系的go-micro等;
没有统一微服务策略控制,各种治理能力控制比较分散,配置方式也比较随意;
额外组件的引入特别是注册中心带来的运维成本。
而ServiveMesh之所以越来越受欢迎,在提供更丰富的服务治理、安全性、可观测性等核心能力外,其从架构设计从解决了以上几个痛点,服务治理能力以Sidecar的模式下沉到数据面,解决了SDK升级及多语言的问题,由于没有SDK的依赖,开发人员可以选择任何开发语言,只需专注于业务逻辑的开发,无需关注服务治理,Sidecar作为基础设施层,也可以独立升级。对于像负载均衡、熔断、限流等策略配置,由控制面统一管理和配置,并下发到数据面生效。同时,Kubernetes已被认为是云原生时代的操作系统,越来越多的应用基于Kubernetes进行编排,而主流的ServiceMesh方案像Isitio、Linkerd都是承载在Kubernetes上,那微服务的核心之一服务注册发现,就完全不需要额外引入外部注册中心,编排在Kubernetes上的应用会自动在Mesh体系中被感知。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。