微服务架构下的服务治理
Posted weixin_47215856
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务架构下的服务治理相关的知识，希望对你有一定的参考价值。
目录
三、Apache Dubbo集成zookeeper实现服务注册
一、如何理解Apache Dubbo
Apache Dubbo是一个分布式框架，主要是实现多个系统的高性能，透明化调用吗，简单来说就是rpc框架，但不同的是，它提供了服务发现、注册、监控、路由、容错等
二、ZooKeeper
ZooKeeper是高性能的分布式协调中间介，需要强调的是zookeeper本身不是注册中心，只是基于他本身的特性可以实现注册中心的这个场景而已
zookeeper的数据结构
zookeeper树中的每个节点称之为Znode,每个节点的数据是允许读和写的
zookeeper的特性
zookeeper的Znode被创建的时候，需要指定节点类型，节点类型主要包含
1.持久化节点，节点数据会被持久化到磁盘
2.临时节点，节点的生命周期与创建该节点的客户端的生命周期一致，也就是说一旦该客户端的会话生命周期结束，那么该节点也会被自动删除。（基于节点的这个特性，可以实现服务注册于发现）
3.有序节点，持久化节点和临时节点都是可以是有序的节点。
3.5.3版本后，又增加了两个节点
1.ttl节点，针对持久化节点，可以设置它的过期时间
2.容器节点，当容器中的最后一个子节点被删除之后，容器也会被删除
需要注意：同一层级目录下，节点名称必须唯一
Watcher机制
Watcher 监听机制是 Zookeeper 中非常重要的特性，我们基于 zookeeper 上创建的节点，可以对这些节点绑定监听事件，比如可以监听节点数据变更、节点删除、子节点状态变更等事件，通过这个事件机制，可以基于 zookeeper实现分布式锁，发布订阅（多个订阅者同时监听某一个主题对象，当这个主题对象自身状态发生变化时，会通知所有订阅者）等功能。
Watcher 分为以下三个过程：客户端向ZK服务端注册 Watcher、服务端事件发生触发 Watcher、客户端回调 Watcher 得到触发事件情况.
触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。
Watcher是一次性的. 一旦被触发将会失效. 如果需要反复进行监听就需要反复进行注册.
（原理不做展开 可参考文章：Zookeeper原理之数据模型, 选举机制, 监听机制, 数据一致性处理, 分布式锁应用_啊策策的博客-CSDN博客）
注册 watcher 有 3 种方式，getData、exists、getChildren；
- 监听节点数据的变化get path [watch]
- 监听节点状态的变化 stat path [watch]
- 监听子节点增减的变化 ls path [watch]
常见应用场景分析
基于zookeeper的节点特性，可以针对很多场景提供解决方案。
分布式锁
分布式锁使用的是Zookeeper的临时有序节点
需求: 在分布式系统中, 很容出现多台主机操作同一资源的情况, 比如两台主机同时往一个文件中追加写入文本, 如果不去做任何的控制, 很有可能出现一个写入操作被另一个写入操作覆盖掉的状况.
方案: 此时我们可以来一把锁, 哪个主机获取到了这把锁, 就执行写入, 另一台主机等待; 直到写入操作执行完毕，另一台主机再去获得锁，然后写入.
这把锁就称为分布式锁, 也就是说:分布式锁是控制分布式系统之间同步访问共享资源的一种方式
实现:
使用Zookeeper的临时有序节点可以轻松实现这一需求.
所有需要执行操作的主机都去Zookeeper上创建一个临时有序节点.
然后获取到Zookeeper上创建出来的这些节点进行一个从小到大的排序.
判断自己创建的节点是不是最小的, 如果是, 自己就获取到了锁; 如果不是, 则对最小的节点注册一个监听.
如果自己获取到了锁, 就去执行相应的操作. 当执行完毕之后, 连接断开, 节点消失, 锁就被释放了.
如果自己没有获取到锁, 就等待, 一直监听节点是否消失，锁被释放后, 再重新执行抢夺锁的操作.
集群选主
集群选主使用的是zookeeper的临时节点.
需求: 在集群中, 很多情况下是要区分主从节点的, 一般情况下主节点负责数据写入, 从节点负责数据读取, 那么问题来了, 怎么确定哪一个节点是主节点的, 当一个主节点宕机的时候, 其他从节点怎么再来选出一个主节点呢？
实现：
使用Zookeeper的临时节点可以轻松实现这一需求
我们把上面描述的这个过程称为集群选主的过程, 首先所有的节点都认为是从节点, 都有机会称为主节点, 然后开始选主, 步骤比较简单
- 所有参与选主的主机都去Zookeeper上创建同一个临时节点，那么最终一定只有一个客户端请求能够 创建成功（因为zookeeper的特性，同一层级目录下，节点的唯一性）。
- 成功创建节点的客户端所在的机器就成为了Master，其他没有成功创建该节点的客户端，成为从节点
- 所有的从节点都会在主节点上注册一个子节点变更的Watcher，用于监控当前主节点是否存活，一旦 发现当前的主节点挂了，那么其他客户端将会重新进行选主。
统一命名服务
统一命名服务使用的是ZK的node节点全局唯一的这个特点.
- 在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。例如：IP不容易记住，而域名容易记住。创建一个节点后, 节点的路径就是全局唯一的, 可以作为全局名称使用.
-
统一配置管理
统一配置管理, 使用的是Zookeeper的watch机制
需求: 分布式环境下, 要求所有节点的配置信息是一致的, 比如Kafka集群. 对配置文件修改后, 希望能够快速同步到各个节点上.
方案: 可以把所有的配置都放在一个配置中心, 然后各个服务分别去监听配置中心, 一旦发现里面的内容发生变化, 立即获取变化的内容, 然后更新本地配置即可.
实现: 配置管理可交由Zookeeper实现
- 可将配置信息写入Zookeeper上的一个Znode.
- 各个客户端服务器监听这个Znode.
- 一旦Znode中的数据被修改, Zookeeper将通知各个客户端服务器.
统一集群管理
统一集群管理使用的是Zookeeper的watch机制
需求: 分布式环境中, 实时掌握每个节点的状态是必要的, 可以根据节点实时状态做出一些调整.
方案: Zookeeper可以实现实时监控节点状态变化
-
- 可将节点信息写入Zookeeper上的一个Znode.
- 监听这个Znode可获取它的实时状态变化.
三、Apache Dubbo集成zookeeper实现服务注册
在远程rpc通信过程中，有两个比较尖锐的问题
服务动态上下线的感知
负载均衡
实现步骤
1.引入zookeeper相关依赖
2.修改配置文件，注册地址为zookeeper服务器地址即可
实现原理
处理url是临时节点（好处是当注册该节点的服务器下线了，那么这个url就会被zookeeper从服务器上移除），其他都是持久化节点。providers表示服务的提供者，consumers表示服务的消费者。
当Dubbo服务消费启动时，会对providers节点下的子节点注册watcher监听，便于感知服务提供方节点上下线的变化，从而防止请求发送到已下线的服务发生失败。同时也会在/consumers下写消费者的url。这样做的好处有：
1.可以在监控平台看到dubbo服务正在被哪些服务调用
2.最重要的是消费者如果要调用服务，那么它回去/providers中通过负载均衡策略选择出提供方的url
整体来看都是运用到了zookeeper的临时节点、watcher等。除此之外Dubbo还可以针对不同情况实现一下功能
1.基于临时节点特性，服务提供者下线之后，注册中心回自动删除提供者的信息
2.注册中心重启后，Dubbo能自动恢复注册与请求
3.为了确保节点安全，zookeeper提供了acl权限控制
四、Apache Dubbo的高级应用
集群容错
1、Failover Cluster(默认)
失败自动切换，当出现失败，重试其它服务器。
通常用于读操作，但重试会带来更长延迟。
2、Failfast Cluster
快速失败，只发起一次调用，失败立即报错。
通常用于非幂等性的写操作，比如新增记录。
3、Failsafe Cluster
失败安全，出现异常时，直接忽略。
通常用于写入审计日志等操作。
4、Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。
通常用于消息通知操作。
5、Forking Cluster
并行调用多个服务器，只要一个成功即返回。
通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
配置方式
负载均衡
- Random LoadBalance（随机，按照权重的设置随机概率 ）默认
- RoundRobinLoadBalance（轮询，按照权重设置轮询比率）
- LeastActive LoadBalance（最少活跃数，响应快的提供者接受越多请求，响应慢的接受越少请求）
- ConsistentHashLoadBalance（一致性Hash，相同参数的请求总是发到同一个服务提供者（相同参数默认是指请求的第一个参数）根据服务提供者ip设置hash环，携带相同的参数总是发送的同一个服务提供者，若服务挂了，则会基于虚拟节点平摊到其他提供者上
配置方式
服务降级
Dubbo提供了mock机制来实现服务的降级，也就是说当服务的提供方发生异常时，客户端不抛出异常，而是执行兜底的逻辑
配置方式
主机绑定规则
主机绑定指的是dubbo服务对外暴露的Ip地址
第一步：查找环境变量DOUBBO_IP_TO_BIND属性配置的ip地址
第二步：从配置文件中获取host，检验host是否合理，如果合理，则直接返回。反之，进行下一步的获取。
第三步：获取本地ip地址，检验是否合理，如果合理，则直接返回。反之，进行下一步的获取。
第四步：利用注册中心去获取，首先判断注册中心地址是不是不为空，如果不为空，循环每个注册中心（dubbo支持多注册中心），通过socket去连接对应的注册中心地址，连接成功后，再通过socket获取本地ip地址。检验是否合理，如果合理，则直接返回。反之，进行下一步的获取。
第五步（最后一步）：遍历本地网卡，返回第一个合理的ip地址。
在etc/host中配置机器名对应的ip地址映射
在环境变量中添加DOUBBO_IP_TO_BIND或者DOUBBO_IP_TO_REGISTRY,value为绑定的主机名
通过dubbo.protocol.host设置主机地址
针对不同协议提供了不同的端口号
Dubbo默认协议端口号：20880
Webservice协议端口号：80
用友云服务治理平台 助力企业微服务架构落地
本文主要阐述使用微服务架构时，治理框架或者平台需要解决的主要问题，微服务落地实施过程中所遇到的关键问题和对应解决方案。同时，文章也介绍用友云旗下的微服务治理平台的核心功能和技术架构，以及微服务治理平台在用友云一些产品下的实践，下一步的发展计划和趋势。
用友云微服务治理平台由来
伴随互联网、云计算、大数据等技术的快速发展，越来越多的企业在信息化之后，将企业上云和数字化提上日程。软件架构的微服务方式重构、应用的自动化运维、容器化等需求强烈，催生出了众多的PaaS平台。同时，针对微服务，也涌现除了许多RPC框架和微服务治理平台，各个框架和平台都有各自的优势和自身独特的适应场景。
相比于单体应用和SOA架构，微服务的小团队开发运维、复杂度可控制、独立扩缩、可灵活组合等等优势也逐渐凸显，被广大架构师和技术人员引入和推崇。但同时也引出了配置繁杂、事务不可控等诸多问题，如何恰当的解决微服务中暴露出的各种问题，成为各微服务治理平台的重点和难点。
软件架构在微服务之前，各个服务通过RestFul接口或者RPC进行互联和调用，进行功能的服务化和解耦，诸多成熟的RPC框架被引入，例如：
RPC调用是微服务治理的基础，但单单RPC不能称为微服务，微服务的核心功能还应该包含服务注册、发现，动态和可视化配置，限流熔断，链路追踪、分析，异步调用，数据一致性处理，API网关等等。
上文中所介绍的不同厂商的框架和产品，都围绕着以上核心功能，进行了实现和融合。各个产品都有不同的复杂度和局限性，并和自身厂商的其它产品联系密切。
用友云主要面向企业级应用，在TOB领域有独特的技术特色和要求，且用友云下的微服务治理需要和自身的DevOps平台、容器云平台及数据平台进行协同和能力聚合。在借鉴和吸收其他产品的优势的同时，用友云微服务治理平台团队针对自身产品需要做了完善和适配，充分的和用友云开发者中心、数据平台、租户中心、用户中心等结合，推出了更适合自身的用友云微服务治理平台，平台具有以下鲜明的特色：
用友微服务治理平台从2015年立项以来，经过团队的不断打磨，已经发展了几个版本，推出了较为成熟的多个版本，例如2.3.1-RELEASE、3.0.1-RELEASE，并在3.5后进行了类隔离机制和插件机制的增强，推出3.5.2-RELEASE、5.0.0-RELEASE. 并在资金云、人力云、财务云、协同云等多个产品，中建、中广核、DIWORK等大型项目中得到了验证。
平台的主要功能和技术架构
（1）功能架构：
服务治理平台提供RPC调用框架、异步调用框架、服务注册发现、配置中心、元数据、一致性框架等基础中间件，并预留了插件机制的扩展，方便开发者使用和集成；也从中间件容器层面提供类隔离和组件加载机制，尽量避免和业务应用引用的三方组件版本冲突；提供统一的门户入口，可视化的管理和查看远程服务的接口信息、调用链路日志、统计信息、评价信息，动态的控制具体接口和方法的权限和流量限制；提供限流、链路追踪等组件保证服务的稳定和可用性。
同时，在外围还支持和服务网关API Link的对接，支持使用IDE进行微服务的编排和一键发布。
（2）技术架构
服务治理平的几大核心技术模块包含注册中心，元数据、控制台、配置中心、基础SDK、链路计算、限流熔断、异步调用和一致性适配组件，IUAP和DUBBOX适配组件等，大致可以分为两类：微服务SDK（middleware）和后端支撑服务。
微服务SDK：
SDK主要可分为启动和加载（helix），基础的RPC调用（iris），配置中心sdk（proteus）、限流（sentinel）、链路（yyeye）、监控（ms-monitor）、异步调用和可靠消息（eos-spring-support）、数据最终一致性（cctrans-springsupport）、IUAP上下文支持（iuap-support）、dubbox适配（dubbox-support）等。
各个组件通过核心的插件机制和类加载机制整合在一起，形成整体对外提供服务，具有两大鲜明特性：
1：支持SPI方式扩展的插件机制，灵活组合，易于扩展；
2：基于ClassLoder的类隔离机制，组件分离，避免冲突；
通过服务治理平台的SDK，业务方可以简单快速的集成微服务的能力到业务工程，达到技术架构的微服务化的目的。
后端支撑：
后端支撑较为核心的包括注册中心、元数据、控制台和链路计算、监控、配置中心、权限管控等。
·注册中心源于springcloud体系下的eureka，在其基础上增加了多租户和权限校验机制，和用友云的租户机制和验证机制有机结合；
·元数据服务记录了业务服务中暴露出的远程RPC接口和方法，为可视化的管控及数据分析打好基础；
·统一控制台提供服务治理平台的UI交互的对接，支持用户可视化的管控接口、权限、链路，查看统计信息和监控信息；
·链路计算通过队列接收调用信息，使用数据平台的存储和分析机制统一计算和管理；
·监控服务收集各个应用和实例的基础配置、权限限流配置、端口和域名信息、接入和输出列表、调用基本统计等并统一展示；
·配置中心统一存储各个应用的各种配置信息，动态管理和下发全局配置、权限配置、限流配置等；
EDAS是阿里云平台推出的分布式服务调用和管控平台，其依赖其自身云平台的配置中心、调度中心、基础资源管理、核心容器、监控中心、权限中心等服务，构建整体服务对外提供服务，功能强大但相对复杂，整体技术栈对阿里云体系的其他产品强依赖，不易专属化的实施落地。
用友云平台的微服务治理团队也对其架构进行分析和对比，借鉴其优势的同时，结合自身特点，对各个模块进行拆分，并在异步调用、多套环境支持、去容器依赖等方面进行了针对性的适配；同时在支持与开发者中心、用户中心、权限中心等服务结合方面做了扩展，支持轻量化的独立部署，为平台的专属化减轻了负担。
关键问题点和解决方案
服务治理平台的几大核心功能包含基础的RPC框架、注册中心元数据、配置中心、链路追踪、异步和一致性、限流熔断等；
服务治理平台在实现和落地微服务的几个核心功能的过程中，也遇到一些难点，这也是众多厂家和平台共同的难点。针对这些关键点，服务治理平台提出了适合自身场景的多种合理的解决方案并实现，较为关键的几点简单说明如下：
（1）类隔离机制和插件机制：
JAVA 版的SDK，在和各种业务应用整合的同时，会遇到很多三方组件版本冲突的问题，给业务整合方带来了困扰。服务治理平台自3.5 版本开始对其进行了优化，引入了类隔离机制，推出了冰山（iceberg）思想，内部自身加载其依赖的三方组件，不对外部的业务三方引用造成冲突，大大简化了集成的难度。
同时，服务治理平台各个组件使用插件（plugin）机制进行组合，为后续的扩展和能力增强打好基础。
（2）动态配置：
业务应用的微服务化拆分，使得业务工程的配置文件更加繁多和分离，微服务的权限和流量的实时控制，也需要动态的管理各项配置。所以配置中心的后端服务和前端SDK体现出更重要的作用。
服务治理平台的SDK为每个使用的客户端，内置了配置中心的SDK，其使用长轮询的方式，近实时的感知远程配置文件的变化，从而及时的响应变化。云端的操作提供RestFul接口和可视化界面，操作简单实用。
（3）异步调用数据最终一致性：
异步调用框架提供可靠消息组件，完善了队列的权限认证体系，简化了异步调用的开发方式，业务开发只需要简单配置和注解，即可完成异步操作。同时，异步事务控制台可以在云端可视化的下发命令，提供错误事务的重试机制。
服务治理平台的SDK，将eos、cc等适配组件有机结合，一体化对外提供服务：
上述几个关键点只是服务治理平台的部分问题的解决方案，还有更多的技术点，本文在这里不做更深层次的阐述。通过云平台和支持和服务治理平台团队的共同努力，我们攻克了许多难题并给出了比较合理的解决方案且落地实现，为云平台及其他产品的微服务化铺平了道路。
服务治理平台在用友云的实践和落地
微服务治理平台自推出以来，经历了多个版本的迭代和多次升级完善，目前已经相对稳定。线上支持的应用数量已达到900多个，API数量已经接近三万个。
目前，使用服务治理平台的云产品和组织包括资金云、财务云、人力云、协同云、用友审计、用友能源等，支持的大型项目包括中建、中广核、DIWORK等。感谢各个平台和产品的支持，也希望微服务治理平台在对各产品和项目的微服务拆分及落地提供更多更有效的服务。
下图为线上监控系统分析出的各个产品和模块的调用依赖图，随着各个产品和服务的接入，用友云服务间的调用层级、依赖关系会越来越清晰，我们也能从中提炼出更多的价值。
微服务治理发展趋势和展望
服务治理平台经过长时间的发展和磨练，已经在分布式服务调用、运维管控和服务治理、生命周期管理和统一控制台、数字化监控和运营、开发支持扩展和兼容等等大方面有沉淀和输出。我们也和其他成熟的产品及框架进行对比，吸收和优化，构建和完善自身的微服务能力体系。
随着产品的发展，服务治理平台也总结了自身的几个重要阶段，我们从基础的调用框架走来，加强了权限和安全的管控，加入了服务稳定性保证，这些功能已经能覆盖大部分的业务需求。
但同时，我们要把握好技术的发展趋势，站在发展的前沿。服务治理平台下一步的发展规划，包括支持服务搜索和集市、对服务编排和网关更有效的组合、服务网格、服务监控等。
各个产品和服务间的调用数据已经收集，如何更好的更充分的利用这些数据，挖掘出有价值的信息，是服务治理平台的一个重要课题，我们可以借鉴京东云的思路，从这些数据中发掘出类似知识搜索、服务评价、调用图谱等，不仅从技术上，也从业务和流程上给出有价值的分析结果。
同时，线上应用变得更多，调用关系变的更复杂后，微服务监控的重要性就更加凸显。有效和及时的监控到各个服务和实例的参数、指标，能更有针对性的进行问题问题的排查和解决。下一阶段，微服务监控也是我们需要重点、大力投入的。
我们希望构建一个统一的可视化微服务监控体系，可以从中直观的获取到各类监控信息，譬如运行时环境、全局配置、异步调用配置、一致性组件的配置等，链接、端口、域名、跃点等，还有服务接口的调入、调出列表和统计信息，调用出错的链路和堆栈信息等等。有效的服务监控必将在开发和运维的不同阶段体现出更大的作用。
能力聚合、生态链、协同发展
服务治理平台的发展并非原生和独立的，其成功推出也伴随着其他产品和技术的支撑，云平台的DevOps、容器云的发展和微服务的发展相辅相成，有机组合，数据平台的大数据存储和分析为链路追踪和分析提供了可能。
微服务治理平台、DevOps平台、容器云平台合力，成为各个云产品和服务成功上云的三把尖刀，为其底层的技术支撑提供了强有力的保障。相信三把尖刀也会在技术中台中体现出越来越重要的价值。
对内有机整合，对外需要扩展和延伸，服务治理平台和API Link、服务编排等在微服务外围合理组合，使得微服务的利用率更高、可组合性更强。
但是，我们清楚，服务治理平台的各个技术架构和数据分析机制，依赖于各个业务平台的数据，只有各个业务线的数据不断完善，整体的用友云调用链路不断完整，服务治理才更加能突出治理和协调的作用，服务的分析和评价才更能落地。
各个业务的云化和微服务化需要技术中台的有力支撑，技术平台的发展也需要各个业务的有力配合，希望服务治理平台和开发者中心能够构建出越来越稳定和完善的服务，更多的云产品和项目接入进来，构建更为完整的用友云生态。
服务治理平台，作为用友云平台下 3+2战略 （技术中台、业务中台、数据中台 + 混合云、生态链）下的技术中台核心产品，也必将展示出更强的战斗力。
以上是关于微服务架构下的服务治理的主要内容，如果未能解决你的问题，请参考以下文章