开发者社区> 颜淡慕潇> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

【微服务系列】微服务总结(二)

简介: 注册中心:简单说就是记录部署服务机器地址的一个服务 在分布式系统里,就有一个类似的概念,不过它的名字可不是叫什么地图,而是叫注 册中心。但原理和地图其实差不多,就是将部 署服务的机器地址记录到注册中心,服务消费 者在有需求的时候,只需要查询注册中心,输入提供的服务名,就可以得到地址,从 而发起 调用。 注册中心原理: 在微服务架构下,主要有三种角色,服务提供者(R...
+关注继续查看

 注册中心:简单说就是记录部署服务机器地址的一个服务

在分布式系统里,就有一个类似的概念,不过它的名字可不是叫什么地图,而是叫注 册中心。但原理和地图其实差不多,就是将部

署服务的机器地址记录到注册中心,服务消费 者在有需求的时候,只需要查询注册中心,输入提供的服务名,就可以得到地址,从

而发起 调用。

注册中心原理:

在微服务架构下,主要有三种角色,服务提供者(RPC Server),服务消费者(RPC client)和服务注册中心(Registry),三者的交互关系如下

RPC Server 提供服务,在启动时,根据服务发布文件server.xml中的配置的信息,向Registry 注册自身服务,并向Registry定期发送心跳汇报存货状态。

RPC Client 调用服务(服务消费者),在启动时,根据服务引用文件client.xml 中的配置信息,向Registry 订阅服务,把Registry 返回的服务节点列表缓存在本地内存中,并与RPC Server 建立连接。

当 RPC Server 节点发生变更时,Registry 会同步变更,RPC Client 感知后会刷新本地 内存中缓存的服务节点列表。 RPC Client 从本地缓存的服务节点列表中,基于负载均衡算法选择一台 RPC Sever 发起 调用

imageimage.gif编辑

注册中心实现方式

注册中心的实现主要涉及几个问题:注册中心需要提供哪些接口,该如何部署;如何存储服 务信息;如何监控服务提供者节点的存活;如果服务提供者节点有变化如何通知服务消费 者,以及如何控制注册中心的访问权限。

1. 注册中心 API

根据注册中心原理的描述,注册中心必须提供以下最基本的 API,例如:

服务注册接口:服务提供者通过调用服务注册接口来完成服务注册。

服务反注册接口:服务提供者通过调用服务反注册接口来完成服务注销。

心跳汇报接口:服务提供者通过调用心跳汇报接口完成节点存活状态上报。

服务订阅接口:服务消费者通过调用服务订阅接口完成服务订阅,获取可用的服务提供者 节点列表。

服务变更查询接口:服务消费者通过调用服务变更查询接口,获取最新的可用服务节点列 表。

除此之外,为了便于管理,注册中心还必须提供一些后台管理的 API,例如:

服务查询接口:查询注册中心当前注册了哪些服务信息。

服务修改接口:修改注册中心中某一服务的信息。

2. 集群部署

注册中心作为服务提供者和服务消费者之间沟通的桥梁,它的重要性不言而喻。所以注册中心一般都是采用集群部署来保证高可

用性,并通过分布式一致性协议来确保集群中不同节点 之间的数据保持一致

分布式一致性协议

一致性协议描述了特定一致性模型的实际实现。一致性模型就像是接口,而一致性协议就像是接口的具体实现。一致性模型提供了分布式系统中数据复制时保持一致性的约束,为了实现一致性模型的约束,需要通过一致性协议来保证

单主协议(不允许数据分歧):整个分布式系统就像一个单体系统,所有写操作都由主节点处理并且同步给其他副本。例如主备同步、2PC、Paxos 都属于这类协议。

多主协议(允许数据分歧):所有写操作可以由不同节点发起,并且同步给其他副本。例如 Gossip、POW。

可以发现,它们的核心区别在于是否允许多个节点发起写操作,单主协议只允许由主节点发起写操作,因此它可以保证操作有序性,一致性更强。而多主协议允许多个节点发起写操作,因此它不能保证操作的有序性,只能做到弱一致性。

单主协议

单主协议的共同点在于都会用一个主节点来负责写操作,这样能够保证全局写的顺序一致性,它有另一个名字叫定序器,非常的形象。

主备复制

主备复制可以说是最常用的数据复制方法,也是最基础的方法,很多其他协议都是基于它的变种。 主备复制要求所有的写操作都在主节点上进行,然后将操作的日志发送给其他副本。可以发现由于主备复制是有延迟的,所以它实现的是最终一致性。

主备复制的实现方式:主节点处理完写操作之后立即返回结果给客户端,写操作的日志异步同步给其他副本。这样的好处是性能高,客户端不需要等待数据同步,缺点是如果主节点同步数据给副本之前数据缺失了,那么这些数据就永久丢失了。MySQL 的主备同步就是典型的异步复制。

两阶段提交

两阶段提交(2PC)是关系型数据库常用的保持分布式事务一致性的协议,它也属于同步复制协议,即数据都同步完成之后才返回客户端结果。可以发现 2PC 保证所有节点数据一致之后才返回给客户端,实现了顺序一致性。

2PC 把数据复制分为两步:

表决阶段:主节点将数据发送给所有副本,每个副本都要响应提交或者回滚,如果副本投票提交,那么它会将数据放到暂存区域,等待最终提交。

提交阶段:主节点收到其他副本的响应,如果副本都认为可以提交,那么就发送确认提交给所有副本让它们提交更新,数据就会从暂存区域移到永久区域。只要有一个副本返回回滚就整体回滚。可以发现 2PC 是典型的 CA 系统,为了保证一致性和可用性,2PC 一旦出现网络分区或者节点不可用就会被拒绝写操作,把系统变成只读的。由于 2PC 容易出现节点宕机导致一直阻塞的情况,所以在数据复制的场景中不常用,一般多用于分布式事务中(注:实际应用过程中会有很多优化)。

有点忙,现在接着学习吧---嘿嘿

3,目录存储

还是以 ZooKeeper 为例,注册中心存储服务信息一般采用层次化的目录结构: 每个目录在 ZooKeeper 中叫作 znode,并且其有一个唯一的路径标识。 znode 可以包含数据和子 znode。 znode 中的数据可以有多个版本,比如某一个 znode 下存有多个数据版本,那么查询这 个路径下的数据需带上版本信息。

imageimage.gif编辑

4. 服务健康状态检测

注册中心除了要支持最基本的服务注册和服务订阅功能以外,还必须具备对服务提供者节点 的健康状态检测功能,这样才能保证注册中心里保存的服务节点都是可用的。

还是以 ZooKeeper 为例,它是基于 ZooKeeper 客户端和服务端的长连接和会话超时控制 机制,来实现服务健康状态检测的。

在 ZooKeeper 中,客户端和服务端建立连接后,会话也随之建立,并生成一个全局唯一的 Session ID。服务端和客户端维持的是一个长连接,在 SESSION_TIMEOUT 周期内,服务 端会检测与客户端的链路是否正常,具体方式是通过客户端定时向服务端发送心跳消息 (ping 消息),服务器重置下次 SESSION_TIMEOUT 时间。如果超过 SESSION_TIMEOUT 后服务端都没有收到客户端的心跳消息,则服务端认为这个 Session就已经结束了,ZooKeeper 就会认为这个服务节点已经不可用,将会从注册中心中删除其 信息。

ZooKeeper

它是一个分布式服务框架,是Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。zookeeper=文件系统+监听通知机制。

1、 文件系统

Zookeeper维护一个类似文件系统的数据结构

每个子目录项如 NameService 都被称作为 znode(目录节点),和文件系统一样,我们能够自由的增加、删除znode,在一个znode下增加、删除子znode,唯一的不同在于znode是可以存储数据的。

有四种类型的znode:

    • PERSISTENT-持久化目录节点
      客户端与zookeeper断开连接后,该节点依旧存在
    • PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
      客户端与zookeeper断开连接后,该节点依旧存在,只是Zookeeper给该节点名称进行顺序编号
    • EPHEMERAL-临时目录节点
      客户端与zookeeper断开连接后,该节点被删除
    • EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
      客户端与zookeeper断开连接后,该节点被删除,只是Zookeeper给该节点名称进行顺序编号

    2、 监听通知机制

    客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、被删除、子目录节点增加删除)时,zookeeper会通知客户端。

    5. 服务状态变更通知

    当注册中心探测到服务提供者节点有新加入或者删除的信息,会立刻通知其消费者(订阅者)作出相应的改变,订阅者则会刷新本地缓存的服务节点信息 ,从而确保请求的可用性。

    Zookeeper 为例,基于Zookeeper Watcher 机制,实现服务状态变更通知给服务消费者,服务消费者在调用ZooKeeper的GetDate


    版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

    相关文章
    通俗地理解面向服务的架构(SOA)以及微服务之间的关系
    通俗地理解面向服务的架构(SOA)以及微服务之间的关系
    36 0
    【杂谈】关于常见架构的整理,单应用、微服务、SOA、分布式和集群
    【杂谈】关于常见架构的整理,单应用、微服务、SOA、分布式和集群
    10 0
    微服务架构(java环境&tomcat)
    微服务架构(java环境&tomcat)
    12 0
    Github标星67.9k的微服务架构以及架构设计模式笔记我粉了
    微服务架构是什么? 我们都知道微服务架构是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的 类上应用很多SOLID原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。
    56 0
    微服务是开发架构对三高场景的妥协吗?
    #架构 #运维 #云平台 #职责 #微服务架构 #单体架构 #编码
    53 0
    微服务2:微服务全景架构
    微服务2:微服务全景架构
    56 0
    《JAVA生态圈技术总结》之 微服务架构蓝图总览(下)
    《JAVA生态圈技术总结》之 微服务架构蓝图总览(下)
    19 0
    《JAVA生态圈技术总结》之 微服务架构蓝图总览(上)
    《JAVA生态圈技术总结》之 微服务架构蓝图总览(上)
    42 0
    专为云原生、微服务架构而设计的链路追踪工具 【SkyWalking介绍及搭建】(下)
    专为云原生、微服务架构而设计的链路追踪工具 【SkyWalking介绍及搭建】(下)
    22 0
    专为云原生、微服务架构而设计的链路追踪工具 【SkyWalking介绍及搭建】(上)
    专为云原生、微服务架构而设计的链路追踪工具 【SkyWalking介绍及搭建】(上)
    54 0
    +关注
    颜淡慕潇
    欢颜如炼 悲苦如戟;浓尽必枯 淡者屡深
    文章
    问答
    文章排行榜
    最热
    最新
    相关电子书
    更多
    基于 OpenResty 和 Node.js 的个推微服务实践
    立即下载
    腾讯云多Kubernetes集群高可用运维实践
    立即下载
    花呗-亿级金融业务架构演进
    立即下载