详解4种微服务框架接入Istio方案
Posted 华为云开发者社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了详解4种微服务框架接入Istio方案相关的知识，希望对你有一定的参考价值。
本文分享自华为云社区《传统微服务框架接入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网格进行开发，将服务发现，服务治理留给基础设施，可以将开发人员从复杂的服务中解脱出来，专注于业务开发，是当前来说比较好的解决方案。
以上是关于详解4种微服务框架接入Istio方案的主要内容，如果未能解决你的问题，请参考以下文章
Spring Cloud vs Istio微服务治理框架对比