华为FusionStage PaaS平台技术探秘之微服务运行与治理框架

一、哪些应用适合用在微服务上？

 

没有太标准的说法，主要看应用的实际情况。

 

1、应用希望使用在云场景下。

 

首先这个应用是想用在云的场景上的。这个是前提。在云场景上应用会更灵活、更快上线。云上有它自身的特点，比如云上系统运行环境是容器或虚机，并不像传统场景下是物理服务器。这些要求导致应用是不是要用微服务。

 

2、应用本身很重很复杂，可以考虑使用微服务。

 

对于应用本身来说，如果特别简单，也很灵活，在容器或者虚机场景下就很快使用，那就不需要使用微服务了，如果说容器本身就很重很复杂，有至少几十个节点，曾经在一个服务器搭建出来，可以考虑下用微服务。

 

微服务帮用户实现故障机制：熔断、容错、隔离。达到故障迅速恢复。

 

微服务上过云环境，在云环境体系下就是放在容器下跟另一个容器中你的另一个组件去交互，你会发现不知道这个虚机或者这个容器的地址在哪里，这样就需要自己去实现访问机制，但你在原来传统的应用服务器的场景下是固定的IP，在云上容器IP会根据实际的情况变化。就比如你的节点或者虚机出现故障，它会挂掉，有自己的保护机制能够拉起来，但是IP就会变。如果IP变掉，你的业务怎么样才能不出问题，这样还是要结合具体的云场景说。

 

在云上用了微服务会碰到在云上才会发生的故障，比如云上的容器出了问题，这种场景下我们在传统应用服务器上出现的故障情况不同，比如有的时候是网络故障，有的时候是容器迁移了等其他原因。不否认云上出故障的频率比传统物理机上要高，这里就必须要有个故障保护机制，这个故障机制就需要这个应用自己去做，如果没有用微服务的话。用了微服务，就会帮你实现故障机制：容错、熔断、隔离。微服务帮你做了你需要做的事情，不需要你再考虑，统一帮你解决这些问题。

 

在云上可能会面临如何去运维和定位问题这样的一个场景。有的应用可能做了很强大的运维手段和系统，有的应用并没有这么强大，也有可能做了运维系统，但是在云上有些不符合的东西。比如说在物理机环境下运维系统基于每个IP是固定，然后再构建你的运维系统，但在云场景下这个场景就不成立了，你的系统就不成立或者不适合。这就涉及到在云上是如何运维，其中一种手段就是calling tracker业务调用链跟踪，还有很多微服务的运维手段。Calling tracker 会记录你的每一个组件，用了微服务之后，你的消息都是经过微服务发的，能做到消息跟踪，并不需要你关注，只要你需要的时候打开。它能帮你跟踪每个应用的消息链，帮你绘制拓扑图：比如你组件相互的关系，帮你描绘每个相互关系的时间，比如XX毫秒在这个模块发出，进入这个模块，到另一个模块出来耗时多久，这些信息都可以用Calling tracker绘制。经过这个拓扑关系绘制之后，你会发现你原来发现不了的问题，比如这个模块消费的时间最大，可能就是你性能消耗点在这里；还有就是故障发生的时候，原来能走到的一个过程，现在走不到了，比如这条链，因为在访问关系中这条链路的调用关系中断了，这个就可以从微服务运维的界面上清晰地看到业务的交互过程，这个就是微服务里面帮应用解决的一些问题。

 

二、微服务的管理和技术是如何实现的？

 

第二个问题就是我们是怎么实现这个微服务的管理，实现微服务这个技术？里面涉及到几个主要的服务/架构。

 

稍微深入一点，在微服务架构里面是有个服务器的。这个服务器相当于是担任整个微服务所有信息的管理，我们可以叫它service center。service center里面有很多主要的功能点，首先就是一个服务注册管理：首先要解决的就是把一个应用拆散之后，需要让各个部件各个小模块之间能够发现对方，然后能够通过一个统一的机制找到对方的地址，然后发送请求，所以这里面服务中心这边提供注册发现的功能，我们这边就叫service register。

 

然后在客户端这边有个发现的模块，这个模块就是现在微服务框架里面提供一个微服务的功能，在客户端是通过SDK，相当于是一个包，就java里面的包类，然后引用一下，就可以在自己代码里面使用微服务功能，使用起来比较简单，如果是java语言的话，10-20行之内的代码就能用起来。主要引用它的jar包这样一个SDK。这个逻辑在用户这里是看不到，是根据你给的信息到服务注册中心去发现你的服务，这个是调用者，也就是我们说的消费者：它说我要去访问某个服务，就去服务中心拿到服务信息，这边就实现它的发现；这边还有个提供服务的角色，就是provider，这个provider同样在SDK里面有个注册的过程，注册的过程就是注册到注册中心，注册中心会发布这个服务。所以所有的发布者在注册中心注册服务，所有的消费者在注册中心发现服务，然后实现一个注册发现。这个是最基本的能力。

 

第二个就是还会有一些对服务的管理，比如说对服务版本的管理，我们叫service manager，主要是一些信息的管理，然后让外部能够查询到，就是这边有一个维护人员，或者是一个管理者看这个中心的有哪些注册信息，还有相关的一些服务的管理人员。

 

第三个就是配置管理。这个对于微服务框架来说也是比较重要的，因为一个应用可能会根据自己的业务调整自己的配置，所以它需要一些配置管理，所以我们需要提供一个配置中心，然后把它的配置同步到所有配置节点上，然后我们不需要逐个节点地管理自己的配置，这个是微服务里面自然而然提供的一个功能。这个配置中心对微服务系统来说比较重要。

 

还有就是在因为我们主要的功能点在SDK上。在SDK里面包含很多特性：比如说我们发现它，然后再解决两个节点之间简单地建立连接然后创建请求，这个都是在微服务SDK里面提供的能力；还有就是解决微服务的监控和运维，因为我们把一个应用拆散之后，他们互相之间的调用关系、调用情况都需要给用户一个可视化的体现；另外需要解决服务治理，比如调用过程中异常，如何解决异常。

 

1服务治理；2、服务注册发现；3、服务运维这几个特性都会在SDK里面体现。

 

服务治理的模块在这里叫Business keeper，主要做的就是故障的容错熔断，还有就是资源隔离的特性；还有就是IPC(RESTFULL +RPC)，就是我们常说的消息转发的过程，通过它来把消息发送给远端，再往下就是我们的calling tracker，就是用来做消息跟踪的。

 

逐个讲一下关键特性在SDK里面做了什么事情：

 

Business keeper主要做的就是服务治理，首先是容错。容错就是向provider请求消息，如果出错了，可以有些策略，我们可以重发这个请求，或者说是找下一个节点，可能你当前访问的节点是不正常的，不代表整个后端的所有节点都是不正常的，所以可以尝试查找下一个节点实现容错，还有就是可以实现自己定制，就是根据自己的业务情况定制容错处理。

 

第二就是熔断，熔断这部分更可以理解为一个解决依赖的问题。假如说一个后端服务不正常，可能一个消息发出去，这个消息内容可能要等到超时才能等到结果，熔断就是为了解决这方面的问题，根据请求历史状态，提前判断服务后端正不正常，通过这样的中间控制保证不会因为后端服务不正常导致消费者大量无效的等待，以及等待造成的影响。这个也有自己的检测机制能够从熔断状态恢复过来。

 

第三个就是隔离，隔离就是消费者会可能会访问不同的服务提供者，不同的服务提供者有不同的业务，隔离主要解决的问题就是当它访问A 这个provider占用资源和它访问B服务访问资源的时候能够把资源隔离开，不会因为大量访问B的业务不会导致consumer这边的资源被耗尽，导致A这边的业务无法运行，这是隔离这边做的特性。

 

IPC就是消息的构造和发送，这部分的逻辑主要解决了把应用拆散后，相当于让所有的功能组件之间有了网络的交互，这里提供了这样的模块就是让你很方便建立组件与组件之间的通道，而不需要自己去构建消息交互过程，这个模块主要是简化在拆分微服务之后消息的处理，就不需要每个开发者自己构建消息通道，而是由微服务帮你维护和创建消息通道。在这个消息发送过程中有个calling tracker也就是消息跟踪的处理，这个处理主要就是去跟踪你一个业务请求消息的过程，这个特性也是微服务里面的一个特点，这种处理方式直观上让你知道前后调度的关系，让你知道你的业务在每个节点上消耗的时间，还有走过的模块，这个比传统应用上更直观让你了解业务的运行状态，让你了解业务消耗时间，定位你的问题。

 

这几块主要都是微服务的特性和功能点，回答如何把应用换成小模块以及之后如何解决消息的互相访问，和被拆散之后请求过程中出错的处理方式，保障业务的正常运行。