详解 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 网格进行开发，将服务发现，服务治理留给基础设施，可以将开发人员从复杂的服务中解脱出来，专注于业务开发，是当前来说比较好的解决方案。

视频地址：https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXI055+Self-paced/courseware/511f6f06d97d4aaf9b90445dca5800d1/c08eb6fa0dd14a34bd617c6beb63a923/

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