微服务-技术栈
常见注册中心组件，对比分析
1、基础概念
在分布式架构的系统中注册中心这个概念就已经被提出了，最经典的就是Zookeeper中间件。
微服务架构中，注册中心是最核心的基础服务之一，注册中心可以看做是微服务架构中的通信中心，当一个服务去请求另一个服务时，通过注册中心可以获取该服务的状态，地址等核心信息。
服务注册主要关系到三大角色：服务提供者、服务消费者、注册中心。
2、流程和原理
基础流程
- 服务启动时，将自身的网络地址等信息注册到注册中心，注册中心记录服务注册数据。
- 服务消费者从注册中心获取服务提供者的地址，并通过地址和基于特定的方式调用服务提供者的接口。
- 各个服务与注册中心使用一定机制通信。如果注册中心与服务长时间无法通信，就会注销该实例，这也称为服务下线，当服务重新连接之后，会基于一定的策略在线上线。
- 服务地址相关信息发生变化时，会重新注册到注册中心。这样，服务消费者就无需手工维护提供者的相关配置。
核心功能
通过上面的基本流程，不难发现一个注册中心需要具备哪些核心功能：
- 服务发现
服务发现是指服务在启动后，注册到注册中心，服务方提供自身的元数据，比如IP地址、端口、运行状况指标的Uri 、主页地址等信息。
- 服务记录
记录注册中心的服务的信息，例如服务名称、IP地址、端口等。服务消费方基于查询获取可用的服务实例列表。
- 动态管理服务
注册中心基于特定的机制定时测试已注册的服务，例如：默认的情况下会每隔30秒发送一次心跳来进行服务续约。通过服务续约来告知Server该Client仍然可用。正常情况下，如果Server在90 秒内没有收到Client 的心跳，Server会将Client 实例从注册列表中删除。
二、基础组件对比
1、Zookeeper组件
1.1基础描述
ZooKeeper是非常经典的服务注册中心中间件，在国内环境下，由于受到Dubbo框架的影响，大部分情况下认为Zookeeper是RPC服务框架下注册中心最好选择，随着Dubbo框架的不断开发优化，和各种注册中心组件的诞生，即使是RPC框架，现在的注册中心也逐步放弃了ZooKeeper。在常用的开发集群环境中，ZooKeeper依然起到十分重要的作用，Java体系中，大部分的集群环境都是依赖ZooKeeper管理服务的各个节点。
1.2组件特点
从Zookeeper的数据结构特点看，并不是基于服务注册而设计的，ZooKeeper提供的命名空间与文件系统的名称空间非常相似，在数据结构上高度抽象为K-V格式，十分通用，说到这里不得不提一下Redis，也可以作为注册中心使用，只是用的不多。
ZooKeeper组件支持节点短暂存在，只要创建znode的会话处于活动状态，这些znode就会存在，会话结束时，将删除znode。Dubbo框架正是基于这个特点，服务启动往Zookeeper注册的就是临时节点，需要定时发心跳到Zookeeper来续约节点，并允许服务下线时，将Zookeeper上相应的节点删除，同时Zookeeper使用ZAB协议虽然保证了数据的强一致性。
2、Eureka组件
2.1基础描述
SpringCloud框架生态中最原生的深度结合组件，Eureka是Netflix开发的服务发现框架，基于REST的服务，主要用于服务注册，管理，负载均衡和服务故障转移。但是官方声明在Eureka2.0版本停止维护，不建议使用。
2.2组件特点
Eureka包含两个组件：EurekaServer和EurekaClient。
EurekaServer提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。Eureka允许在注册服务的时候，自定义实现检查自身状态的是否健康的方法，这在服务实例能够保持心跳上报的场景下，是一种比较好的体验。
EurekaClient是一个java客户端，用于简化与EurekaServer的交互，客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。
3、Consul组件
3.1基础描述
Consul是用于服务发现和配置的工具。Consul是分布式的，高度可用的，并且具有极高的可伸缩性，而且开发使用都很简便。它提供了一个功能齐全的控制面板，主要特点是：服务发现、健康检查、键值存储、安全服务通信、多数据中心、ServiceMesh。Consul在设计上把很多分布式服务治理上要用到的功能都包含在内了。
3.2组件特点
Consul提供多个数据中心的支持，基于Fabio做负载均衡，每个数据中心内，都有客户端和服务端的混合构成。预计有三到五台服务端。可以在失败和性能的可用性之间取得良好的平衡。数据中心中的所有节点都参与八卦协议。这意味着有一个八卦池，其中包含给定数据中心的所有节点。这有几个目的：首先，不需要为客户端配置服务器的地址;发现是自动完成的。其次，检测节点故障的工作不是放在服务器上，而是分布式的。这使得故障检测比天真的心跳方案更具可扩展性。第三，它被用作消息传递层，用于在诸如领导者选举等重要事件发生时进行通知。
4、Nacos组件
4.1基础描述
Nacos致力于发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。Nacos更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。Nacos支持作为RPC注册中心，例如：支持Dubbo框架；也具备微服务注册中心的能力，例如：SpringCloud框架。
4.2组件特点
Nacos在经过多年生产经验后提炼出的数据模型，则是一种服务-集群-实例的三层模型。如上文所说，这样基本可以满足服务在所有场景下的数据存储和管理,数据模型虽然相对复杂，但是并不强制使用数据结构的风格，大多数应用场景下，和Eureka数据模型是类似的。
Nacos提供数据逻辑隔离模型，用户账号可以新建多个命名空间，每个命名空间对应一个客户端实例，这个命名空间对应的注册中心物理集群是可以根据规则进行路由的，这样可以让注册中心内部的升级和迁移对用户是无感知的。
三、组件选择
如下注册中心对比图。
综合上述几种注册中心对比，再从现在SpringCloud框架流行趋势看，个人推荐后续微服务架构体系选择Nacos组件，大致原因如下，社区活跃，经过大规模业务验证，不但可以作为微服务注册中心，也支持作RPC框架Dubbo的注册中心，且有完善的中文文档，总结下来就一句话：通用中间件，省时；文档详细，省心。
====================================================================================
流量整形算法，服务熔断与降级
1、基本概念
流量控制的核心作用是限制流出某一网络的某一连接的流量与突发，使这类报文以比较均匀的速度流动发送，达到保护系统相对稳定的目的。通常是将请求放入缓冲区或队列内，然后基于特定策略处理请求，匀速或者批量处理，该过程也称流量整形。
流量控制的核心算法有以下两种：漏桶算法和令牌桶算法。
2、漏桶算法
基础描述
漏桶算法是流量整形或速率限制时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。
漏桶算法基本思路：请求（水流）先进入到容器（漏桶）里，漏桶以一定的速度出水，这里就是指流量流出的策略，当流量流入速度过大容器无法承接就会直接溢出，通过该过程限制数据的传输速率。
核心要素
通过上述流程，不难发现漏桶算法涉及下面几个要素：
容器容量
容器的大小直接决定能承接流量的多少，容器一但接近饱和，要么溢出，要么加快流速；
流出速度
流量流出的速度取决于服务的请求处理能力，接口支撑的并发越高，流速就可以越大；
时间控制
基于时间记录，判断流量流出速度，控制匀速模式，
注意：需要一个基本的判定策略，漏桶算法在系统能承接当前并发流量时，不需要启用。
3、令牌桶算法
基础描述
令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满。后面再产生的令牌就会从桶中溢出。
令牌桶算法虽然根本目的也是控制流量速度，但是当令牌桶内的令牌足够多时，则允许流量阶段性的并发。传送到令牌桶的数据包需要消耗令牌。不同大小的数据包，消耗的令牌数量不一样。
核心要素
令牌桶
存放按照特定的速率生成的令牌，以此控制流量速度。
匹配规则
这里的匹配规则更多是服务于分布式系统，例如服务A是系统的核心交易，当出现并发时，基于令牌桶最匹配规则，只允许交易请求通过，例如：常见双十一期间，各大电商平台提示，为保证核心交易，边缘服务的数据延迟或暂停等。
注意：令牌桶算法和漏桶算法的目的虽然相同，但是实现策略是相反的，不过都存在一个问题，为保证大部分请求流量成功，会牺牲小部分请求。
二、限流组件
1、Nginx代理组件
Nginx反向代理实际运行方式是指以代理服务器来接收客户端连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给客户端，此时代理服务器对外就表现为一个服务器。
流量限制是Nginx作为代理服务中一个非常实用的功能，通过配置方式来限制用户在给定时间内HTTP请求的数量，两个主要的配置指令limit_req_zone和limit_req，以此保护高并发下系统的稳定。
2、CDN边缘节点
CDN边缘节点，准确的说并不是用来处理流量限制的，而是存放静态页面。内容缓存为CDN网络节点，位于用户接入点，是面向最终用户的内容提供设备，可缓存静态Web内容和流媒体内容，实现内容的边缘传播和存储，以便用户的就近访问，这样避免用户大量刷新数据服务器，节省骨干网带宽，减少带宽需求量。
在高并发场景下，尤其是倒计时抢购类似业务，在活动开始前后用户会产生大量刷新页面的操作，基于CDN节点，这些请求不会下沉到数据的服务接口上。也可以基于页面做一些请求拦截，比如点击页面单位时间内只放行一定量的请求，以此也可以实现一个限流控制。
三、熔断器组件
所谓熔断器机制，即类似电流的保险器，当然电压过高会自动跳闸，从而保护电路系统。微服务架构中服务保护也是这个策略，当服务被判断异常，会从服务列表断开，等待恢复在重新连接。服务熔断降级的策略实现有如下几个常用的组件。
1、Hystrix组件
基础简介
Hystrix当前处于维护模式，即不再更新，作为SpringCloud微服务组件中，最原生的一个熔断组件，很多思路还是有必要了解一下。例如：服务熔断，阻止故障的连锁反应，快速失败并迅速恢复，服务降级等。
某个微服务发生故障时，要快速切断服务，提示用户，后续请求，不调用该服务，直接返回，释放资源，这就是服务熔断。
熔断器策略
服务器高并发下，压力剧增的时候,根据当业务情况以及流量，对一些服务和页面有策略的降级(可以理解为关闭不必要的服务)，以此缓解服务器资源的压力以保障核心任务的正常运行。熔断生效后，会在指定的时间后调用请求来测试依赖是否恢复，依赖的应用恢复后关闭熔断。
基本流程：
首先判断服务熔断器开关状态，服务如果未熔断则放行请求；如果服务处于熔断中则直接返回。
每次调用都执行两个函数markSuccess(duration)和markFailure(duration) 来统计在一定的时间段内的调用是成功和失败次数。
基于上述的成功和失败次数的计算策略，来判断是否应该打开熔断器，如果错误率高于一定的阈值，就会触发熔断机制。
熔断器有一个生命周期，周期过后熔断器器进入半开状态，允许放行一个试探请求；否则，不允许放行。
2、Sentinel组件
基础简介
基于微服务的模式，服务和服务之间的稳定性变得越来越重要。Sentinel以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel可以针对不同的调用关系，以不同的运行指标（如QPS、并发调用数、系统负载等）为基准，收集资源的路径，并将这些资源的调用路径以树状结构存储起来，用于根据调用路径对资源进行流量控制。
流量整形策略
直接拒绝模式是默认的流量控制方式，即请求超出任意规则的阈值后，新的请求就会被立即拒绝。
启动预热模式：当流量激增的时候，控制流量通过的速率，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。
匀速排队方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。
熔断策略
Sentinel本质上是基于熔断器模式，支持基于异常比率的熔断降级，在调用达到一定量级并且失败比率达到设定的阈值时自动进行熔断，此时所有对该资源的调用都会被阻塞，直到过了指定的时间窗口后才启发性地恢复。
================================================================================
微服务技术栈：API网关中心，落地实现方案
一、服务网关简介
1、外观模式
客户端与各个业务子系统的通信必须通过一个统一的外观对象进行，外观模式提供一个高层次的接口，使得子系统更易于使用：
简单说一下外观模式，网关和这个模式很像，但是比外观模式复杂，模式，结构，原则这些都是通用的，在各种架构或组件中使用。
2、网关简介
微服务网关从感觉上，很像是：拦截器+路由+过滤器，拦截请求，系列基础处理，路由转发到指定服务。
服务网关在整个架构体系上也是一个服务器，作为请求的唯一入口，与外观模式十分类似，在网关层处理所有的非业务功能，为客户端提供定制的API，在网关层通常会执行如下操作：如权限校验、监控、负载均衡、缓存、日志、限流、等等。
二、网关模式
1、模式对比
这里对比常用的请求服务管理模式，和网关模式，如图：
常规模式
在没有网关的情况下，微服务架构会在业务层服务上提供一个API服务，用来接收参数，例如Client-API，通常会根据系统模块划分多个API，例如，运营系统，用户系统等。
- 请求统一进入Client-API服务 ；
- Client-API经过鉴权，限流，路由等操作；
- 如果请求通过，会转发到相应业务服务上；
- 如果请求被拦截，会直接返回给客户端；
- Client-API集成所有业务服务的开放接口；
该模式下的缺点非常明显，每个Client-API都需要实现一套非业务服务，代码冗余，当系统膨胀之后，维护成本极高，适用于轻量级系统架构。
网关模式
在业务服务层上，添加一层网关控制，在服务网关中可以完成一系列的横切非业务功能：
- 客户端请求在网关层做统一拦截；
- 网关上执行：路由/鉴权/限流/降级等操作；
- 网关判断是转发请求还是直接响应客户端；
网关服务层要执行很多非业务流程，作为系统的服务端唯一入口，承受所有服务的路由转发，安全，限流，缓存，日志，监控，熔断降级等功能，网关服务不仅要做到高可用，还要避免出现性能瓶颈。
2、多重网关
在大型复杂的系统中，通常会对网关做分层管理，把一类业务规划到一个网关下，避免网关过于臃肿，方便维护和管理：
总网关：通用常用来做路由转发功能；
模块网关：分类的业务服务聚合网关，对这类服务的做非业务性操作，最后请求转发到具体服务上，在数据类平台上，通常对数据通道(流入流出)做一层独立的服务网关；对数据分析类服务做一层独立网关；基本是根据服务的使用情况来划分，这样避免单层服务网关过于复杂的情况。
三、核心功能
1、配置层面
服务发现
网关应该有服务发现功能，通过统一注册中心，获取服务列表，这样才能执行统一代理服务和路由转发功能。
路由请求
植入网关层服务之后，客户端不知道自己请求的是哪个具体的服务，只需要把请求转发给网关，网关放行之后会把请求路由到指定业务服务上。
负载均衡
网关连接的服务实例可能是集群模式存在，所以网关还可以对各个服务实例上执行负载均衡策略，常见的策略就是服务轮询或者按权重路由。
2、定制开发
定制开发例如：权限校验，日志集成，接口限流，等相关功能，需要和数据库交互，可以做成独立服务，在服务中实现具体的处理逻辑，网关层直接调用即可。
四、网关组件
1、Netflix-Zuul
Zuul网关主要提供动态路由，监控，弹性，安全管控等功能。在分布式的微服务系统中，系统被拆为了多个微服务模块，通过zuul网关对用户的请求进行路由，转发到具体的后微服务模块中，Netflix开源的一个基于JVM路由和服务端的负载均衡器。
2、Tyk组件
Tyk是一个开源的、轻量级的、快速可伸缩的API网关，支持配额和速度限制，支持认证和数据分析，支持多用户多组织。基于go语言编写，在Java架构系统中使用很少。
3、Kong组件
Kong是一款基于Nginx+Lua编写的高可用，可扩展的开源网关项目，由Mashape公司开放。核心是实现数据库抽象，路由和插件管理，插件可以存在于单独的代码库中，并且可以在几行代码中注入到请求生命周期的任何位置。提供易于使用的RESTfulAPI来操作和配置API管理，并且可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对高并发的网络请求。
