基于nacos的分布式服务治理

微服务是什么

微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成

微服务架构特点

1.通过服务实现组件化
开发者不再需要协调其它服务部署对本服务的影响。

2.按业务能力来划分服务和开发团队
开发者可以自由选择开发技术，提供 API 服务

3.去中心化
每个微服务有自己私有的数据库持久化业务数据,每个微服务只能访问自己的数据库，而不能访问其它服务的数据库,某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

4.基础设施自动化（devops、自动化部署）
的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。

微服务的组成

1、注册中心
注册中心主要是用来登记服务信息的存储中心，主要用来注册和发现已注册登记的服务，并维护它们间的通信关系。
目前主流选用Eureka、Consul、Zookeepr及nacos作为注册中心，它们都有各自的特点和适用场景，
具体在后续注册中心专题文章进行介绍。那么，登记的服务信息到底是什么？
实际上，登记的服务程序信息一般为能够找到服务的信息，比如：IP地址、端口号、服务名及通信协议等能够唯一标志服务的数据，
不论选用上面介绍的哪种技术实现，都离不开这些信息，不同的主要在选用的实现技术在集群选举和故障恢复上的异同。

2、API网关
之所以称为“API网关”，主要是因为在微服务架构体系中，服务间的通信大多选用Rest API或RPC来实现，
而往往它们的实现形式也就是API，只不过所遵循的通信协议和极限性能不同罢了。那么，微服务架构中的API网关能够做什么事昵？其实，它可以作很多事，比如：控制不论是对外还是对内的服务间的统一入口和路由转发，并能方便地监控服务间的调度、限流及容错回退等功能。可以选用Netflix系列中的Zuul，也可以选用Web服务器，如：Nginx作为代理路由服务器。

3、服务提供者
服务提供者，承载着对外提供的业务服务单元，一般仅对服务消费者开放，而实现方式没有特殊的要求，只要能够合理的实现业务功能即可，比如：可选用传统的MVC架构，或仅仅是一个实现主类。

4、服务消费者
服务消费者，负责对接和消费服务提供者所提供的服务单元，它的实现方式也没有特殊的要求，与提供者类似，但不同的是其负责与前端交互，负责将从提供者获取的数据和行为，赋予给与用户打交道的前端交互，比如：我们熟知的浏览器等。

5、配置中心
配置中心，一个负责统一配置全局参数的地方，做到不需要重新打包、发布版本才能更新数据，而仅仅通过改变统一配置文件，服务就可以动态更新最新的属性数据，大大提高程序服务的灵活性，避免繁琐的运维部署工作。而实现配置中心的方式也有很多种，以前推荐用Cloud Bus，它一般会与消息中间件，如：RabbitMQ、ActiveMQ、RocketMQ、Kfka等结合使用，通过集成消息中间件，来实现负载群发配置变更信息给相关的服务同步数据，同时它也负责与版本存储连接，如：Git/Svn等，通过监听它们的变更，来及时通知消息消息广播消息。目前的话有nacos-config功能

6、消息总线
消息总线，在上面已经介绍，主要工作是能够负载均衡地群发事件消息数据给所有相关的服务，使它们及时更新最新属性，其一般选型均为消息队列系统实现，当然，这并非是固定的标准，选用如Redis亦可。

7、服务跟踪
微服务架构中，跟踪服务调用运转的情况很重要，因为通过分析服务调用的频次和时间作为参考，有助于我们预知服务的使用度和延迟问题所发生的时机。细心的读者，会发现服务跟踪与日志跟踪有些类似，没错，传统的架构中，我们为了定位问题，通常借助ELK技术栈来跟踪和记录感兴趣的日志信息，虽然，它们类似，但日志跟踪的数据分析较困难，所记录的数据大多无规律，而服务跟踪，则从服务粒度出发，从功能整体来记录和分析程序问题，使问题定位更加清晰和高效，实际上，服务跟踪也是一种日志跟踪。如果读者选用Spring Cloud栈搭建微服务架构，则可选用Cloud Sleuth，它往往与Zipkin等集成，来实现可视化的跟踪分析；如果采用的是非Spring Cloud，如基于dubbo搭建微服务的化，因其本身并未提供类似Cloud Sleuth的开源栈，所以需要读者自行实现，可选用高效的，且支持持久化的中间件实现，如：Redis或MongoDB等。  目前使用sentinel

8、服务容错
服务容错，或称之为服务降级。我们知道，在微服务环境中，服务往往存在与不同的服务器节点，甚至是不同的网络环境，那么服务间的交互，势必会经常发生错误，如：网络抖动、服务bugs等。那么，如何实现当某个服务故障时，关联的服务程序也能正常对外提供服务昵？答案是，引入一个提高用户体验或与故障服务类似的服务作为降级服务后的服务，这就是服务降级或容错。这里以Spring Cloud方式搭建架构，那么可选用Cloud Hystrix，利用其提供的容错断路器来实现降级，并且往往它需要与API路由集成（实际上，Zuul已经集成了它），因为后者是几乎所有服务的访问控制的入口。  目前使用sentinel

技术间的对比

1.nacos 与 eureka

CAP定律
1.CP和AP不可能同时满足

2.P:代表分区容错, 在整个分布式系统中某个节点服务挂掉了,并不影响整个系统的运作和使用，因为他可以在稍后或者通过切换可用节点立即恢复使用
 
3.C:一致性,写操作之后的读操作，必须返回该值。注册中心集群中: leader的作用, 所有的写操作都依赖于leader来完成,为了保证数据的一致性,leader只有一个.假如: 没有leader,首先加入我们新加入一台数据处理服务,就会像注册中心1进行注册,注册中心1写入数据处理服务的ip等等基本信息,并且准备同步给其他注册中心节点, 结果这个在还没发生同步的过程中,注册中心1挂掉了,然后客户端准备调用数据中心写入,这个时候就因为注册中心1挂掉了,就直接切到了注册中心2,但是注册中心2没有收到数据处理服务的添加请求,所有没有这个服务,这个时候就对客户端显示不可用了.

4.A:可用性,没有leader,可以很容易的切换到可用的注册中心,对于客户端的调用总是及时反应, 在上述C操作的例子中,对于像服务注册,获取服务注册的基本信息,比如ip来说,基本不会存在,因为像Eureka来说,我们的服务可以像所有的注册中心节点发起注册请求,这样就不会存在注册中心节点服务列表不一致的情况

eureka + springCloudConfig
eureka:默认支持AP,使用节点间的相互复制,和服务端同时注册到所有注册中心节点上来保证一致性springCloudConfig:单独服务,使用git仓库拉取配置信息,然后服务器拉取config服务器里的配置缓存到本地仓库.需要结合bus等才能使用,保证数据的一致性

nacos: 默认单机支持AP 集群支持CP 同时作为注册中心和配置中心,使用推送模式来传输配置(原理:服务器使用监听器监听nacos的配置变化.如果发生变化就变更)

eureka目前停止更新 nacos处于起步阶段.新功能及bug反馈速度快.

2.Sentinel 与 Hystrix

https://www.jianshu.com/p/d1f22a555065

1.侧重点:
    (1)Hystrix: 在于以隔离和熔断为主的容错机制
    (2)Sentinel: 多样化的流量控制,熔断降级,系统负载保护,实时监控和控制台

nacos

https://nacos.io/zh-cn/docs/what-is-nacos.html

服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理：Kubernetes Service , gRPC & Dubbo RPC Service , Spring Cloud RESTful Service

Nacos 的关键特性包括:
服务发现和服务健康监测
1.Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。
2.Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。

动态配置服务
动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。

动态 DNS 服务
动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。Nacos 提供了一些简单的 DNS APIs TODO 帮助您管理服务的关联域名和可用的 IP:PORT 列表.

服务及其元数据管理
Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。

nacosMap

nacos生态图

nacos基本架构

服务 (Service)
服务是指一个或一组软件功能（例如特定信息的检索或一组操作的执行），其目的是不同的客户端可以为不同的目的重用（例如通过跨进程的网络调用）。Nacos 支持主流的服务生态，如 Kubernetes Service、gRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service.

服务注册中心 (Service Registry)
服务注册中心，它是服务，其实例及元数据的数据库。服务实例在启动时注册到服务注册表，并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。

服务元数据 (Service Metadata)
服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据

服务提供方 (Service Provider)
是指提供可复用和可调用服务的应用方

服务消费方 (Service Consumer)
是指会发起对某个服务调用的应用方

配置 (Configuration)
在系统开发过程中通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成这个步骤。配置变更是调整系统运行时的行为的有效手段之一。

配置管理 (Configuration Management)
在数据中心中，系统中所有配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动统称为配置管理。

名字服务 (Naming Service)
提供分布式系统中所有对象(Object)、实体(Entity)的“名字”到关联的元数据之间的映射管理服务，例如 ServiceName -> Endpoints Info, Distributed Lock Name -> Lock Owner/Status Info, DNS Domain Name -> IP List, 服务发现和 DNS 就是名字服务的2大场景。

配置服务 (Configuration Service)
在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。

nacos逻辑架构

服务管理：实现服务CRUD，域名CRUD，服务健康状态检查，服务权重管理等功能
配置管理：实现配置管CRUD，版本管理，灰度管理，监听管理，推送轨迹，聚合数据等功能
元数据管理：提供元数据CURD 和打标能力
插件机制：实现三个模块可分可合能力，实现扩展点SPI机制
事件机制：实现异步化事件通知，sdk数据变化异步通知等逻辑
日志模块：管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮助文档
回调机制：sdk通知数据，通过统一的模式回调用户处理。接口和数据结构需要具备可扩展性
寻址模式：解决ip，域名，nameserver、广播等多种寻址模式，需要可扩展
推送通道：解决server与存储、server间、server与sdk间推送性能问题
容量管理：管理每个租户，分组下的容量，防止存储被写爆，影响服务可用性
流量管理：按照租户，分组等多个维度对请求频率，长链接个数，报文大小，请求流控进行控制
缓存机制：容灾目录，本地缓存，server缓存机制。容灾目录使用需要工具
启动模式：按照单机模式，配置模式，服务模式，dns模式，或者all模式，启动不同的程序+UI