微服务的概念和原理

微服务带来的问题

微服务带来的好处：

  解耦了业务，解耦了代码和架构，业务更紧凑，逻辑更单一简单。

微服务带来的问题：

  在早期的时候，使用单体架构，所有的业务都在一个服务内，没有跨进程和网络上的一些复杂度。

微服务化之后引入的问题包括如何做服务发现，怎么做负载均衡，包括服务间的访问保护，例如熔断，故障定位等等问题。

在故障定位时，在原来单体服务下只需要看下日志，但是微服务化之后需要借助分布式调用链工具，这无形中带来了开发和定位问题的复杂度。

微服务和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/

本文整理自华为云社区【内容共创】活动第14期。
https://bbs.huaweicloud.com/blogs/336904
任务25.华为云云原生钻石课程15：传统微服务框架接入Istio方案详解