详解4种微服务框架接入Istio方案

作者: 小麦

更新时间:2022-03-26 14:34:51

575 阅读

摘要:使用k8s和lstio网格进行开发,将服务发现、服务治理留给基础设施,可以将开发人员从复杂的服务中解脱出来,专注于业务开发,是当前来说比较好的解决方案。

本文分享自华为云社区《传统微服务框架接入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.com/courses/course-v1:HuaweiX+CBUCNXI055+Self-paced/courseware/511f6f06d97d4aaf9b90445dca5800d1/c08eb6fa0dd14a34bd617c6beb63a923/

 

点击关注,第一时间了解华为云新鲜技术~

版权声明:本文著作权归作者【小麦 】所有,不代表本网站立场。

侵权请联系:root_email@163.com

相关推荐