微服务基本架构以及注册中心、配置中心等的使用

浏览量：909

微服务定义：

  1. 一种架构风格，将单体应用划分成一组小的服务，服务之间相互协作，实现业务功能
  2. 每个服务运行在独立的进程中，服务间采⽤轻量级的通信机制协作（通常是HTTP/
    JSON）
  3. 每个服务围绕业务能力进行构建，并且能够通过自动化机制独立地部署
  4. 很少有集中式的服务管理，每个服务可以使用不同的语言开发，使用不同的存储技术
  5. 更多参考 – https://www.martinfowler.com/articles/microservices.html

一个比较成型的微服务架构体系：

其中：

  1. 网关层：流量首先进入网关层，负责反向路由、限流熔断、安全等功能
  2. 业务层有可能同时包含松散的单个服务，和某多项服务的聚合服务

  3. 支撑服务层中，服务的注册和发现解决了微服务架构最关键的问题：如何精准的定位需要调用的服务ip以及端口。无论使用哪种方式来提供服务发现功能，大致上都包含以下三点：

    1. Register, 服务启动时候进行注册
    2. Query, 查询已注册服务信息

    3. Healthy Check,确认服务状态是否健康

      整个过程大致就是在服务启动的时候，先去进行注册，并且定时反馈本身功能是否正常。由服务发现机制统一负责维护一份正确或者可用的服务清单。因此，服务本身需要能随时接受查下，反馈调用方服务所要的信息。

    主要包括三个部分：

    1. 服务提供者：服务启动时将服务信息注册到注册中心，服务退出时将注册中心的服务信息删除掉。
    2. 服务消费者：从服务注册表获取服务提供者的最新网络位置等服务信息，维护与服务提供者之间的通信。

    3. 注册中心：服务提供者和服务消费者之间的一个桥梁

      服务发现机制的关键部分是注册中心。注册中心提供管理和查询服务注册信息的API。当服务提供者的实例发生变更时（新增/删除服务），服务注册表更新最新的状态列表，并将其最新列表以适当的方式通知给服务消费者。

注册中心使用的两种主要的服务发现模式：

使用API Gateway模式，可以与微服务注册中心相连接，实现微服务无感知的动态扩容。

以下介绍客户端发现模式，和服务端发现模式。二者主要的区别在于，客户端是否保存了服务列表的信息。

  1. 客户端发现模式：

    客户端模式下，如果进行微服务调用，首先客户端要到服务注册中心获取服务列表，然后再调用本地端的负载均衡策略，进行服务调用。

    在上图中，客户端提供了负载均衡的功能，其首先从注册中心获取服务提供者的列表，然后通过自身负载均衡算法，选择一个最合理的服务提供者进行调用:

    1. 服务提供者向注册中心进行注册，提交自己的相关信息
    2. 服务消费者定期从注册中心获取服务提供者列表
    3. 服务消费者通过自身的负载均衡算法，在服务提供者列表里面选择一个合适的服务提供者，进行访问

    客户端发现模式的优点：客户端可以定制化负载均衡部分的逻辑。

    客户端发现模式的缺点：负载均衡部分逻辑如果有更新，很难同一时间全部更新。与注册中心耦合度太高。

  2. 服务端发现模式：

    在服务端模式下，调用方直接向服务注册中心进行请求，服务注册中心再通过自身负载均衡策略，对微服务进行调用。这个模式下，调用方不需要在自身节点维护服务发现逻辑以及服务注册信息。

    在服务端模式下：

    1. 服务提供者向注册中心进行服务注册
    2. 注册中心提供负载均衡功能
    3. 服务消费者去请求注册中心，由注册中心根据服务提供列表的健康情况，选择合适的服务提供者供服务消费者调用

服务端发现模式的优点：

  1. 服务消费者不需要关心服务提供者的列表，以及其采取何种负载均衡策略

  2. 负载均衡策略的改变，只需要注册中心修改就行，不会出现新老算法同时存在的现象

  3. 服务提供者上下线，对于服务消费者来说无感知

    服务端发现模式的缺点：

  4. 注册中心成为瓶颈，所有的请求都要经过注册中心，如果注册服务过多，服务消费者流量过大，可能会导致注册中心不可用

  5. 如果路由器或者负载均衡器无法提供服务，那么将导致整个系统瘫痪。

注册中心实现方案：

比较成熟的注册中心的方案：**zookeeper，etcd，consul，nacos，eureka

注册中心的对比和选型，可参考：

《注册中心对比和选型：Zookeeper、Eureka、Nacos、Consul和ETCD》

《主流微服务注册中心浅析和对比》

集中式配置中心的作用和技术选型：

配置中心，顾名思义就是用来统一管理项目中所有配置的系统。为什么要使用配置中心，传统的项目配置一般有以下几个特点：

  1. 静态化配置，大多数是单独写一个配置文件，类似”config.conf“等，如果需要修改则不灵活，甚至需要重启服务
  2. 配置文件过于分散
  3. 修改的配置无法追溯

微服务里面，配置中心的思路就是把项目中各种配置、各种参数、各种开关，全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。当各个服务需要获取配置的时候，就来配置中心的接口拉取。当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。

核心功能：

  1. 实现配置的记录
  2. 实现配置的读取、更新、取消
  3. 实现配置的查看

几个热门的配置中心技术选型：

  1. Apollo(携程开源) – https://www.apolloconfig.com/#/
  2. disconf(百度开源) – https://disconf.readthedocs.io/zh_CN/latest/

上面提过的注册中心nacos也提供了一些配置中心的功能，这三者的对比可以参考：《深度对比三种主流微服务配置中心》

案例，Netflix的微服务路由发现体系架构：

  1. 服务注册中心使用Eureka, 网关使用zuul。这两个核心组件支撑了整个netflix的服务注册路由发现体系
  2. 内部微服务，分为了基础服务，以及聚合服务，一共两层。内部服务之间发现，通过服务注册中心Eureka，基础服务启动时候会注册到Eureka，聚合服务调取后面基础服务前，先通过注册中心调取已经注册的基础服务，拉取路由表，缓存在客户端，等待随后的调用。
  3. 客户端如果需要调取后台服务，需要先经过网关层，网关层也需要同步服务中心Eureka的路由表，然后请求根据路由表，找到后台对应的服务进行调用。
  4. 服务中心同样提供服务治理功能，规定服务的调取要求等等

留下评论