【云驻共创】华为云云原生钻石课程15:传统微服务框架接入Istio方案详解
微服务的概念和原理
微服务带来的问题
微服务带来的好处:
解耦了业务,解耦了代码和架构,业务更紧凑,逻辑更单一简单。
微服务带来的问题:
在早期的时候,使用单体架构,所有的业务都在一个服务内,没有跨进程和网络上的一些复杂度。
微服务化之后引入的问题包括如何做服务发现,怎么做负载均衡,包括服务间的访问保护,例如熔断,故障定位等等问题。
在故障定位时,在原来单体服务下只需要看下日志,但是微服务化之后需要借助分布式调用链工具,这无形中带来了开发和定位问题的复杂度。
微服务和lstio网格架构对比
微服务框架我们了解比较多的Spring cloud 或者国内用的比较多的Dubbo,框架本身就不多介绍了,我想大家都有所了解。
原理就是提供了开发的SDK或者说叫框架,这些框架都是内置了一些解决微服务问题的方案,比如服务发现,负载均衡,服务的熔断和降级,以及调用链路的埋点,动态路由这些事情。
下图是一个典型的用法,也是应用非常广泛的用法
基于网格的治理是近些年应用比较多的,从上图可以看出,虽然基于网格的治理提供的能力和上图的基于sdk的能力一样,但是两者的设计原理,使用场景,设计理念是不同的。
详细介绍
服务发现和负载均衡
上图是传统的微服务框架的原理
一般的流程是:
• 服务启动的时候向服务中心进行注册
• 调用的时候先从服务中心获取后端服务的地址
• 选择一个实例发送请求,等待回复
服务网格的工作原理:
服务网格一般和k8s结合使用,因为k8s 本身做了服务的endpoint 维护,所以lstio不需要做服务注册,只需要做服务发现。
看下详细的区别
服务熔断
服务熔断的机制:
如果一个服务在配置的一段时间内一直不可用,可以通过熔断机制,把服务隔离开,接触不到流量,进入到半熔断状态,
如果在一定的考察时间段能够恢复正常,熔断状态就会关闭,如果还是不能正常,会继续进入到熔断状态。
传统微服务框架的问题和基于服务网格的解决方案
问题1:微服务SDK的多语言问题
上面这张图示意了微服务的之间的关系,一些大的客户拥护大的系统,系统由多个服务组成,服务可能由多种语言开发。
比如系统中可能有go服务,C++服务,python服务以及spring cloud 服务等等,这是一种比较常见的情况。
在这些服务中想做一个通用的服务发现时,但是Spring cloud或者Dubbo开发的服务,有一套自己的服务发现机制,但是不同语言开发的服务之间发现框架是不同的,比如go服务开发的服务不可能去spring cloud的服务中心注册,这个问题没办法解决。
比较粗暴的解决办法是对其他语言的项目用Java重构,在项目不复杂的情况下是可以接受的,但是在系统业务比较复杂,需要修改的项目比较多的情况下是无法接受的,不仅需要大量的人力,还要花费大量的时间,服务的稳定性没法保证。
服务网格的解决方案下,服务发现是业务解耦的,不管是什么语言开发的服务,因为proxy不需要参与编译,网格之间只需要开放端口,并且保持可以访问,在这种方案下,不需要修改原来代码,减少了开发量,是企业可以接受的。
问题2:基于sdk的服务在k8s下出现延迟和数据不一致
在上图这种情况下,Consumer服务原来在pod1 上,后来由于调度问题,导致Consumer服务迁移到pod2 上,正常情况下pod1 需要注销,pod2 进行重新注册,但是如果pod 迁移比较频繁,导致Producer 在访问Consumer服务的时候仍然拿到老的注册地址,就会出现延迟和数据不一致的情况。
问题3:基于SDK逻辑开发的服务升级必须重新编译
基于SDK开发的逻辑代码进行升级的时候,必须重新编译所有基于SDK开发的服务,这个升级会带来大量的工作量,SDK的升级过程必须要和业务团队一起升级,非常耗时。产生的需求就是如果业务代码没有改变的情况下不需要重新编译。
使用网格的解决方案下,如果业务没有修改是不需要进行编译和修改的,对开发人员和运维来说是非常友好的,同时降低了运维的风险,毕竟任何改动都是风险。
问题4:基于SDK开发,统一发现和治理能力,需要全部改造
如果对一个单体应用进行微服务化,一般是渐进微服务化,比如上图,一般先对svc1进行微服务化,然后再对svc2 进行微服务化,在开发的过程中需要仍然访问互通,但是使用SDK的微服务有时需要使用同一框架,同一版本才能进行通信交互,这就是痛点。
在使用网格的情况下,第一步先对svc1进行微服务化,svc2不改动,在开发的期间仍然不影响原来的访问。
传统微服务框架在服务网格中集成的实践详情
总体思路
卸载SDK的服务发现和服务治理的功能,将这些功能迁移到基础设施上,让用户从这些中解脱出来,只专注于自己的业务代码。
解决方案
传统微服务的发现是注册到注册中心
在使用网格之后,平台同一服务发现,使用kube-proxy进行服务发现和负载均衡,Kube-proxy 直接返回服务的ip和端口,这样的话就消除容器环境下服务发现数据不及时的问题。
在使用k8s做服务发现,再使用网格的能力,服务完全无需修改适配
Spring cloud项目的改造
在原来的配置中,取消对注册中心的注册,改为直接使用服务名:端口进行访问,直连的这种方式会被k8s 进行转发,对业务代码无需修改,减少了工作量。
注意:要和访问的服务保持协议一致。
移除spring cloud 的项目依赖
微服务网关的改进
情况1:微服务网关有业务逻辑
写了很多自定义的逻辑,比如filter的过滤等等,这种情况下网关可以作为普通的微服务部署在网格内。
情况2:微服务只有通用逻辑能力
直接用Ingress进行替换,进行地址映射,路径映射等基础能力,移除原来的网关。
集成微服务注册中心到网格
由于有些项目开发架构自成体系,不太适合直接排除原来的基础能力,在这种情况下想使用网格的能力,需要把原来的注册中心导入。Istio从微服务的注册中心导入注册数据,并且转换格式存储,在这种情况下依然可以配置相同的治理规则。
总结
使用k8s和lstio网格进行开发,将服务发现,服务治理留给基础设施,可以将开发人员从复杂的服务中解脱出来,专注于业务开发,是当前来说比较好的解决方案。
视频地址:https://education.huaweicloud.cn/courses/course-v1:HuaweiX+CBUCNXI055+Self-paced/courseware/511f6f06d97d4aaf9b90445dca5800d1/c08eb6fa0dd14a34bd617c6beb63a923/
本文整理自华为云社区【内容共创】活动第14期。
https://bbs.huaweicloud.cn/blogs/336904
任务25.华为云云原生钻石课程15:传统微服务框架接入Istio方案详解
- 点赞
- 收藏
- 关注作者
评论(0)