分布式系统服务治理
分布式系统架构特别是进入微服务架构后，服务治理的重要性愈发变得不可缺少而且处于重要地位。缺乏服务治理的的分布式系统架构，很难正式投入生产。那么服务治理包括哪些方面呢？主要包括服务发现，负载均衡，限流，熔断，超时，重试，服务跟踪等。下面展开讲。
侵入式服务治理
1.服务发现
服务发现是指使用一个注册中心来记录分布式系统中全部服务的信息，以便让其他服务能够快速找到这些已注册的服务。服务发现需要服务注册，服务查找，服务健康检查及服务变更通知等关键功能。
最早的服务发现应用就是DNS，通过使用域名，让访问者不必关心服务在哪里。其实DNS的服务发现应用，在原来公司做大型嵌入式软件时，虽然是单体系统，但是是一个分时的多进程系统，由于系统非常庞大，不同的进程间通信采用的是IPC进程间通信。为了便于不同的进程间通信，我们当时设计在IPC模块内部提供了一个小型的服务发现功能，所有需要通过IPC通信的系统，在模块启动时都需要调用IPC提供的服务注册功能，这样当模块间通信时，就不用关注这个IPC通信是设备的板间通信还是板内通信。这里简单解下，因为设备形态存在控制板（主要负责协议计算和路由）和接口板（主要负责数据报文转发，可能多个接口板），因此当我们在考虑IPC时提供了类似的设计。
可以看到关于服务发现，关键是要有一个服务注册中心。具体的服务发现机制
1.服务提供者启动时需要注册。
2.注册中心与服务提供者无法保持心跳时需要剔除服务
3.服务消费者可以从注册中心获取服务提供者的最新信息，可以采取定期拉和事件通知的两种方式
可以看到服务注册中心在分布式服务架构中的关键位置，因此需要具备高可用。基于CAP定理的，服务注册中心的最佳选择是一个AP的系统。但实际中我们常用的注册中心有zooKeeper,Eureka,etcd,consul，还有阿里的Nacos。
- zooKeeper我们知道它本质其实是一个CP模型，基于其自己的Zab协议（基于Paxos裁剪）来保证注册中心多个节点之间的数据一致性。
Zab协议规定，消息传递要遵循可靠传递，完全有序，因果有序的特性.
在zooKeeper中，主节点故障下，Zab协议通过主节点快速选举，初始化，同步从节点、广播几个阶段来保证数据一致性和主节点选举的高效。
zooKeeper 的核心概念
集群角色： 主节点,从节点，观察者节点。主节点负责数据写入服务，从节点提供读数据。观察者同样提供读但是不参与选举投票。在集群中，服务器数量是奇数被认为是一个最佳实践。集群对外工作的必要条件是超过半数的服务器可以对外正常工作。
另外有个集群宕机容忍度的衡量，2台服务器的容忍度为0，3台，4台容忍度都是1
会话：在zooKeeper,客户端和服务端之间是有TCP长连接的。基于长连接发送心跳。会话超时时间徐阿哟根据生产环境的网络状况合理设定。
数据节点：数据节点称zNode,通过/分割父节点和子节点。zNode分为持久节点和临时节点 服务注册就是注册在临时节点上。
PERSISTENT
PERSISTENT_SEQUENTIAL（持久序列/test0000000019 ）
EPHEMERAL
EPHEMERAL_SEQUENTIAL
监听： 即watcher,客户端可以在感兴趣的zNode上进行监听，当zNode状态变化时，服务端会通知客户端。
zooKpeer 原生提供了命令行客户端及Java，c的客户端。原生客户端开发效率低，且存在一些不足（不支持递归，需要重复注册监听器，需要自行解决会话超时，对常用的分布式锁，选举，分布式计数等都需要二次开发）。
zkClient和Curator是两个常见的三方库。
zkClient提供递归删除创建节点，会话超时处理，监听器反复等，简化了原生API的使用。
Curator是Netflix开源的，已经被Apache基金会收录。除了支持zkClient的功能，还支持选举，分布式锁等场景
zooKeeper是最广为广泛的分布式协调组件，由于存在当主节点因为网络与其他节点失去联系导致整个系统重新选举时，集群是不可用的（这也是它作为CP模型，不能应用于大规模分布式系统注册中心的考虑。），因此已经不是服务发现的最好选择了，其主要优势在选举和分布式锁。Curator提供的缓存能力，能够让zooKeeper可用性增强，同时由于缓存使得其从CP发生向AP的转化
- Eureka
Eureka采用了去中心化的设计，整个集群由对等节点组成，不存在zk（zooKpeer以下简称zk）的选举问题。服务端之间相互注册彼此同步信息来实现高可用性。客户端可以连接任一服务端进行注册。但这样会存在数据的一致性问题，也就是客户端查询的信息不一定是最新的。
Eureka也是Netflix的开源项目，可以和SpringCloud很好的整合。Eureka是一个 war包，需要部署到一个web服务器中。另外Eureka提提供一个保护机制，就是当超过85%的节点在15分钟内没有心跳时，就会启动，此时
1.不再从注册列表删除长时间没有心跳的服务
2.不会接受新的户注册及同步数据
3.网络恢复稳定后再接受新注册及同步信息
Eureka提供了java,Python, Node.js, .net的客户端，对于没有客户端的语言可以通过Restful API交互。
-
Etcd
Etcd和zk具有类似的架构，采用 Raft算法代替了 zab，从CAP来分析，也是一个CP系统，通过TTL来实现类似zk临时节点的功能 -
Consul
Consul是一个商业产品(Raft)，有一个开源版本。除了服务发现，还通过内存，磁盘使用的细粒度状态检测及服务配置的键值存储功能。 -
Nacos
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
nacos_map
Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务.它同时支持AP和CP模式，可以通过配置切换。
作者：技术与健康
链接：https://www.jianshu.com/p/ef615bc40d79
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
