CN106506703A - 基于共享内存的服务发现方法、装置及系统、服务器 - Google Patents

Abstract

本发明公开了一种基于共享内存的服务发现方法、装置及系统、服务器，涉及计算机网络技术领域。其中方法包括：监听并获取消息队列中记录的服务名称；其中，所述服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到所述服务的服务提供者信息而写入到消息队列中；根据所述服务名称，从服务注册组件处获取所述服务的服务提供者信息；将所述服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取所述服务的服务提供者信息并返回给应用层。利用本方案，达到了应用层在获取服务列表配置信息时和获取本地内存读写一样的性能，减少了网络延迟，提升了读取速度。

Description

基于共享内存的服务发现方法、装置及系统、服务器

技术领域

本发明涉及计算机网络技术领域，具体涉及一种基于共享内存的服务发现方法、装置及系统、服务器。

背景技术

服务发现组件记录了(大规模)分布式系统中所有服务的信息，人们或者其它服务可以据此找到这些服务。DNS就是一个简单的例子。当然，复杂系统的服务发现组件要提供更多的功能，例如，服务元数据存储、健康监控、多种查询和实时更新等。服务发现给当前互联网架构的网络公司带来的好处就是零配置，不需要硬编码网络地址到应用中，只需有服务的名字即可找到该服务的后端服务列表和网络拓扑信息。

目前业界提供了多种服务发现的解决方案，但是目前公开的各种服务发现解决方案都没有完美的解决所有问题。举例来说，DNS，在小规模系统可以先使用DNS作为服务发现手段。一旦服务节点的启动和销毁变得更加动态，DNS就会出现问题，因为DNS记录传播的速度可能跟不上服务节点变化的速度。常见的服务发现相关的解决方案还有类似dubbo这种基于某个编程语言的，但是这种基于特定语言的服务发现问题也是显而易见的，因为大多数互联网公司内部使用的编程语言都不止一种，限定到语言级别则会将服务发现的能力大大降低。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的基于共享内存的服务发现方法、装置及系统、服务器。

根据本发明的一个方面，提供了一种基于共享内存的服务发现方法，包括：

监听并获取消息队列中记录的服务名称；其中，所述服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到所述服务的服务提供者信息而写入到消息队列中；

根据所述服务名称，从服务注册组件处获取所述服务的服务提供者信息；

将所述服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取所述服务的服务提供者信息并返回给应用层。

根据本发明的另一方面，提供了一种基于共享内存的服务发现装置，包括：

监听模块，适于监听并获取消息队列中记录的服务名称；其中，所述服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到所述服务的服务提供者信息而写入到消息队列中；

获取模块，适于根据所述服务名称，从服务注册组件处获取所述服务的服务提供者信息；

写入模块，适于将所述服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取所述服务的服务提供者信息并返回给应用层。

根据本发明的另一方面，提供了一种基于共享内存的服务发现系统，包括：上述基于共享内存的服务发现装置、共享内存、客户端以及服务注册组件；

所述客户端适于：在接收到应用层访问服务的请求之后，在共享内存中查询到所述服务的服务提供者信息，若未查询到，则将服务名称写入到消息队列中；若查询到，则从共享内存中读取所述服务的服务提供者信息并返回给应用层。

根据本发明的又一方面，提供了一种服务器，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行上述基于共享内存的服务发现方法对应的操作。

根据本发明的再一方面，提供了一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使所述处理器执行如上述基于共享内存的服务发现方法对应的操作。

根据本发明提供的基于共享内存的服务发现方法、装置及系统、服务器，在客户端接收到应用层访问服务的请求之后，首先在共享内存中查询服务的服务提供者信息，若查询到，则直接在共享内存中读取服务提供者信息；若未查询到，则通过网络去服务注册组件中获取服务提供者信息。利用本方案，达到了应用层在获取服务列表配置信息时和获取本地内存读写一样的性能，减少了网络延迟，提升了读取速度，这种与后端分布式集群通信产生共享内存并提供客户端供应用使用的方式，避免了客户端和分布式集群之间用长连接方式进行对接而导致的资源占用过多、服务注册组件处理效率低下的问题。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的基于共享内存的服务发现方法的流程图；

图2示出了本发明一个实施例中服务发现数据结构存储模型的示意图；

图3示出了根据本发明另一个实施例的基于共享内存的服务发现方法的流程图；

图4示出了实现本发明一个实施例的基于共享内存的服务发现方法的系统架构示意图；

图5示出了本发明一个实施例中agent内部线程模型的示意图；

图6示出了本发明一个实施例中各个语言接入共享内存进行通信的示意图；

图7示出了根据本发明一个实施例的服务发现协议的分层模型示意图；

图8示出了根据本发明一个实施例的服务注册集群中服务健康检查的架构示意图；

图9示出了根据本发明一个实施例的基于共享内存的服务发现装置的功能框图；

图10示出了根据本发明一个实施例的基于共享内存的服务发现系统的功能框图；

图11示出了根据本发明实施例六的一种服务器的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

在对本发明的技术方案进行介绍之前，首先对本发明实施例中所涉及的技术术语进行简单介绍：

服务发现：当某个服务添加的服务集群中时，该服务所暴露的调用地址能够被其使用方自动感知到并进行调用。

共享内存(SHM)：在多处理器的计算机系统中，可以被不同中央处理器(CPU)访问的大容量内存。

进程间通信(IPC)：一组编程接口，让程序员能够协调不同的进程，使之能在一个操作系统里同时运行，并相互传递、交换信息。

负载均衡(LB)：建立在网络结构之上，能够将请求分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。常见的负载均衡软件有HAPROXY，nginx，LVS等。

服务注册组件：一个通用的分布式组件，该组件通常通过的分布式算法进行实现，主要用于保障分布式复杂网络环境，多个服务器针对某个服务的事务性，一致性，可靠性。这种服务注册组件常见的开源实现有zookeeper，etcd，consul等。

本发明的发明人在研究现有技术的过程中，发现现有技术提供的服务发现解决方案存在以下未解决的难题，并对这些难题未解决的原因进行了具体分析。

难题一，应用层在获取服务列表配置信息时不能保证和获取本地内存读写一样的性能，之所以说保持内存读写级别的性能是个难题，主要有以下几个原因导致：

(1)当客户端获取在服务注册组件所注册的服务时，如果每个客户端都走长连接，由于应用数量和应用进程数不可控，会导致长连接过多致使服务注册组件处理效率低下，资源占用过多；

(2)当客户端获取在服务注册组件所注册的服务时，如果每个客户端走短连接，那么获取服务注册组件的服务本身就需要有个网络层1到5ms的开销，使得服务性能低下；

(3)常见的分布式组件应用设计上大多考虑更多的是分布式一致性和可靠性问题，对分布式服务本身提供的高性能方面有先天性不足。举例来说，当分布式组件集群中有一个或者多个节点宕机时，这时分布式组件集群为了保证可靠性和重新选举策略，一般都会有相当大的开销，这时该分布式组件的写入和读取性能有较大的损失。

难题二，跨语言的通用性服务发现实现困难，其难以实现的主要原因由以下几个方面：

(1)不是所有的编程语言都支持长连接的方式进行实时通信；

(2)不是所有的语言对分布式组件比如zookeeper，etcd等都有完善的API支持；

(3)实现某个特定语言的客户端对分布式组件(比如：zookeeper)的使用已经非常困难，要实现各个语言保持一致的使用方式的使用更是难上加难。

难题三，基于统一模型的服务发现技术需要兼容服务端的服务发现机制和客户端的服务发现机制。

传统的服务发现的架构模式要么是服务端服务发现，要么是客户端服务发现，两个方案各有优缺点，在实际生产环境的应用上，往往需要兼容服务端的服务发现和客户端的服务发现。常见的服务端服务发现的架构模式一般都是将服务动态注册到一个LB(loadbalancer，负载均衡)上，然后客户端的调用从LB获取服务。常见的客户端服务发现的架构模式是在客户端绑定一个负载均衡逻辑块，该负载均衡逻辑块负责和服务注册中心通讯获取服务列表然后通过负载均衡算法进行返回。

为了克服以上至少一个难题，本发明提供了一种基于共享内存的服务发现方法。下面通过几个具体的实施例对本发明的具体实现方案进行详细介绍。

实施例一

图1示出了根据本发明一个实施例的基于共享内存的服务发现方法的流程图。如图1所示，该方法包括如下步骤：

步骤S101，监听并获取消息队列中记录的服务名称；其中，服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到服务的服务提供者信息而写入到消息队列中。

步骤S102，根据服务名称，从服务注册组件处获取服务的服务提供者信息。

步骤S103，将服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取服务的服务提供者信息并返回给应用层。

本发明实施例中，服务注册组件用来存储服务节点相关的元数据。在服务注册系统中，存在监听单元，负责监听新加入的服务提供者，将服务提供者进行抽象为服务注册节点，并获取服务注册节点的元数据(包含主机端口，名称等)，调用接口将服务注册节点的元数据写入到服务注册组件中。常见的服务注册节点的数据存储模型都是树形结构，针对该种类型的数据结构设计的服务发现存储模型如图2所示。

namespace：名字空间(即服务名称)，每个服务都会有一个namespace与之对应。每个namespace又会有两个子节点providers和consumers；

providers：服务提供者，用于通过名字空间获取；服务提供者信息包含提供服务的各个主机的主机端口；

consumers：服务消费者，用于记录使用该服务的节点信息，服务消费者信息包含使用服务的各个主机的主机端口。

为了保障应用层在获取服务列表配置信息时能和获取本地内存读写一样的性能，并且在服务注册组件中服务列表变更时能够同步实时的感知到服务的变更信息，本发明的解决方案提供一个共享内存和agent，该agent负责和服务注册组件进行通信并保证服务注册组件内的变更能够实时通知到该agent，然后该agent产生共享内存供其他应用使用。

在上述步骤S101中，客户端接收到应用层访问服务的请求之后，在共享内存中查询服务的服务提供者(providers)信息，若未查询到，则将服务名称(namespace)写入agent的消息队列中。agent实时监听和获取消息队列中记录的服务名称。

在上述步骤S102中，若agent监听到消息队列中存在服务名称，则从中提取出服务名称，从服务注册组件处获取服务的服务提供者信息。

在上述步骤S103中，agent将服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取服务的服务提供者信息并返回给应用层。

由于linux跨进程通信中基于共享内存的方式具有高性能，可靠性的特点因此本方案通过将与服务注册组件进行网络通信的模块移交到agent中，然后让agent产生共享内存供其他客户端使用，利用这种方式，避免了客户端本身和服务注册组件进行通信的网络开销，也使得客户端本身几乎没有额外的性能开销。

实施例二

图3示出了根据本发明另一个实施例的基于共享内存的服务发现方法的流程图，图4示出了实现本发明一个实施例的基于共享内存的服务发现方法的系统架构示意图，图5示出了本发明一个实施例中agent内部线程模型的示意图。下面结合图3、图4和图5对本发明实施例二的详细步骤进行介绍。

如图3所示，该方法包括如下步骤：

步骤S200，服务注册步骤。

服务注册一般都会有服务注册组件用来存储服务节点相关的元数据。如图2所示，常见的服务注册节点的数据存储模型都是树形结构。从使用方角度来讲服务自身的注册逻辑应当尽可能的简单，最好简单到一步即可完成，但是又考虑到服务注册本身并不是任何应用均可以随意注册，其自身还需要有权限管理和授权机制，因此本发明实施例抽象出一个API层专门用于服务注册到服务注册组件上，该API层实现的API主要基于以上树形结构的服务注册组件元信息进行开发，API概要如下：

1，获取namespace列表接口

GET/zkapi/v1/namespace

2，创建namespace接口

POST/zkapi/v1/{namespace}

data＝{"name":"namespace"}逻辑上会创建namespace节点以及其子节点providers和consumers

3，删除namespace接口

DEL/zkapi/v1/{namespace}

4，获取某个namespace下提供的服务列表和服务策略

GET/zkapi/v1/{namespace}/providers

5，添加或更新一个服务提供者到某个namespace

POST/zkapi/v1/{namespace}/providers/{service_name}

data＝{"host":"192.168.56.32","port":"4455"}

6，删除某个namespace下的一个服务提供者

DEL/zkapi/v1/{namespace}/providers/{service_name}

7，获取某个namespace下消费者的列表

GET/zkapi/v1/{namespace}/consumers

8，删除某个namespace下的消费者

DEL/zkapi/v1/{namespace}/consumers/{consumer_name}

9，添加消费者到某个namespace下

POST/zkapi/v1/{namespace}/consumers/{service_name}

data＝{"service_value":"ip:port"}

10，修改某个namespace下providers节点值属性

POST/zkapi/v1/{namespace}/providers

data＝{"load_banlance":"RR","on_faile":"url"}

步骤S201，生成动态链接库向利用不同编程语言实现的客户端提供统一的共享内存查询接口。

为了解决跨语言的通用性服务发现实现困难的难题，本实施例提供的解决方案是不再在各个语言内部进行服务注册组件的实现，而是使用统一的编程语言，如C++编程语言对服务注册组件API进行调用和服务发现逻辑的封装，用C++生成动态链接库的方式来对外提供统一的服务发现的API。图6示出了本发明一个实施例中各个语言接入共享内存进行通信的示意图。如图6所示，服务发现策略实现的各个语言接入主要支持：Java，Python，php，C/C++，lua等，还可支持shell，go等语言。各个语言接入共享内存主要通过动态链接库(.so文件)来和共享内存进行通信，各个语言通过封装动态链接库和服务发现逻辑提供的服务发现的接口只有一个即：get_service，接口参数为namespace和algorithm，该函数根据algorithm参数对namespace下的providers进行筛选从而返回一个provider出来给应用层使用。

步骤S202，客户端接收到应用层访问服务的请求之后，在共享内存中查询该服务的服务提供者信息，若查询到，则执行步骤S207；若未查询到，则执行步骤S203。

客户端在接收到应用层访问服务的请求之后，首先在共享内存中查询该服务的providers信息，若共享内存中预先存储有该服务的providers信息，则可直接读取。若共享内存中没有存储该服务的providers信息，继续执行步骤S203。

本实施例主要是利用服务注册集群中的节点变更通知特性监听节点事件的发生，从而进行共享内存中节点的增删改查，尽量保证共享内存中节点信息与服务注册组件中的节点信息一致。具体地，监听服务注册组件中的内容变更，将这些变更情况同步到共享内存中。

步骤S203，将该服务的服务名称写入到消息队列中。

步骤S204，代理agent监听并获取消息队列中记录的服务名称。

步骤S205，根据服务名称，从服务注册组件处获取该服务的服务提供者信息。

步骤S206，将该服务的服务提供者信息写入共享内存中。

代理agent内部主要使用4个线程保证服务稳定可靠，如图5所示，主线程启动后，从消息队列中获取待查询的服务名称，然后从服务注册组件处获取该服务的服务提供者信息，并更新到共享内存中。如果更新共享内存成功，主线程还会将查询到的数据发送到另一队列中用于一些额外的操作。

消息线程负责从消息队列里取服务名称。因为系统的消息队列大小有限制，若队列内的数据未及时取走，则可能因为客户端在短时间内大量写入服务名称而将队列填满，之后的服务名称将无法再写入，造成错误。而agent获得服务名称后，需要通过网络去服务注册组件上取得服务提供者信息，相对较慢(10ms左右)，因此很可能发生队列的积压填满。为了避免出现这种问题，agent监听消息队列中记录的服务名称，将消息队列中记录的服务名称读到内存中，并及时清除消息队列中记录的服务名称，防止填满队列。主线程从内存里获得需要读取的服务名称，再去服务注册组件上取值。

辅助线程负责每隔预定时间扫描共享内存中的服务提供者信息；将共享内存中的服务提供者信息与服务注册组件中的服务提供者信息进行比对；若比对不一致，则根据服务注册组件中的服务提供者信息更新共享内存中的服务提供者信息。

因为服务注册组件的watcher机制不能设置为持久监视，而是一次性的，也就是说，一个事件被触发一次后，该watcher就被自动销毁，如果要继续监视下次事件，只能重新注册watcher。所以本发明采取的策略是事件发生后，第一时间先重新注册watcher，再执行具体的处理逻辑，尽量减少上个watcher销毁与下个watcher注册的时间间隔。尽管如此，这二者仍然不是事务性操作，因此仍有极小概率会丢失事件。为了防止这种情况发生，本发明会每隔30-60分钟扫描共享内存里的所有节点，并与服务注册组件上的最新值比较，若有差异则更新到最新值，并为可能遗漏监视的节点重新注册watcher。

触发线程实际上是一个多功能线程，主要是数据在共享内存更新完成后需要执行的额外操作，当前主要操作有备份(dump)，执行脚本以及信息反馈。

步骤S207，客户端从共享内存中读取该服务的服务提供者信息。

从图4所示的系统架构图上可以看出，agent与客户端并没有直接的通讯，二者的交互的一个渠道是共享内存。共享内存的作用在于，客户端可能会多次读取相同的配置项(其值可能并不会每次都改变)，如果没有在本机存储这些配置项，那么就必然需要每次通过网络去服务注册组件服务端读取(相同的值)，一是存在网络延迟，二是服务注册组件本身性能并不高，不适合大量的频繁读操作。之所以选用共享内存这种存储方式，是看中了其性能优势，节点信息在共享内存里以哈希表的形式存储，因此查询时间是常数级，实际测试一次读取耗时在16us左右，完全可以满足用户对低延迟的要求。

agent与客户端交互的另一个渠道是消息队列。客户端接收到应用层访问服务的请求之后，先去共享内存里检索，若找到则直接返回，若未找到，则将该服务的名称写入消息队列。而agent时刻监视消息队列中是否有数据，一旦有数据被写入，agent即读出数据(服务名)，再根据服务名去服务注册组件把服务提供者信息读取回来，并写入共享内存。客户端会等待直到共享内存里出现所要读取的服务提供者信息，然后读出服务提供者信息并返回。

步骤S208，根据读取的服务的服务提供者信息计算MD5值，将计算得到的MD5值与共享内存中存储的MD5值进行比对是否一致，若是，则执行步骤S209；否则，执行步骤S207。

由于涉及到多个进程(agent和客户端进程)对共享内存的同时读写，所以需要避免冲突。共享内存里同时存储服务提供者信息与其MD5值，客户端会把二者一次全读出，然后根据读取的服务提供者信息计算MD5值，校验MD5值是否正确，若不正确则会重新读取，这就避免了agent尚未写入完整的服务提供者信息被客户端读走，也消除了锁争用，进一步提升性能。

步骤S209，客户端将该服务的服务提供者信息返回给应用层。

另外，针对基于统一模型的服务发现技术需要兼容服务端的服务发现机制和客户端的服务发现机制的问题，该问题主要集中在一套服务发现协议如何保证服务端的服务发现和客户端的服务发现拥有相同的特性。常见的服务发现组件有Nginx，Haproxy，LVS等，其中Nginx工作在网络协议的第七层(应用层)，Haproxy既可以工作在4层又可以工作在七层，LVS只能工作在4层。从高性能、可靠性、易用性、可扩展性上，经对比发现Nginx在实现负载均衡的策略上较其他几个有更好的应用场景。

图7示出了根据本发明一个实施例的服务发现协议的分层模型示意图，如图7所示，本发明基于Nginx开发了一个LB扩展模块，使得nginx层可以通过该LB扩展模块来动态获取上游(upstream)的配置，从而解决了服务端的服务发现问题。本发明使用nginx做反向代理来提供服务，nginx代理的服务需要能够自动注册到nginx中，避免了因修改nginx的配置文件而重启nginx。

客户端的解决方案相对服务端来说没有依赖某个特定LB的场景，其实现也就比较简单，因为几乎所有的语言都支持linux环境下跨进程通信(IPC)机制，因此只要帮助各个语言实现一个从共享内存中获取服务信息的API的客户端即可，又由于本发明基于C++开发和服务注册组件通信时生成了动态链接库，因此只要该编程语言支持动态语言的接口即能快速实现其客户端读取服务的列表。

根据本发明上述实施例提供的基于共享内存的服务发现方法，在客户端接收到应用层访问服务的请求之后，首先在共享内存中查询服务的服务提供者信息，若查询到，则直接在共享内存中读取服务提供者信息；若未查询到，则通过网络去服务注册组件中获取服务提供者信息。利用本方法，达到了应用层在获取服务列表配置信息时和获取本地内存读写一样的性能，减少了网络延迟，提升了读取速度，这种与后端分布式集群通信产生共享内存并提供client供应用使用的方式，避免了客户端和分布式集群之间用长连接方式进行对接而导致的资源占用过多、服务注册组件处理效率低下的问题。另外，本方法通过生成动态链接库向利用不同编程语言实现的客户端提供统一的共享内存查询接口，解决了跨语言的通用性服务发现实现困难的问题。本发明基于Nginx开发了一个扩展模块，使得nginx层可以通过该扩展模块来动态获取upstream的配置，从而解决了服务端的服务发现问题，又由于本发明基于C++开发和服务注册组件通信时生成了动态链接库，因此只要该编程语言支持动态语言的接口即能快速实现其客户端读取服务的列表，因而最终实现了兼容服务端的服务发现机制和客户端的服务发现机制。

本发明实施例还提供了一种服务注册集群中服务健康检查的方法，其中服务健康检查的作用主要是针对不健康的服务节点(服务提供者和/或服务消费者)进行动态的摘除，以提升服务注册集群的稳定性和可靠性。该方法中，分布式健康检查策略设计为主从(master-slave)架构。

图8示出了根据本发明一个实施例的服务注册集群中服务健康检查的架构示意图。如图8所示，以服务注册集群利用zookeeper技术实现为例，master选举靠zookeeper来维系，主要涉及如下内容：

1.所有健康检查服务启动后都将自己做为临时节点注册到zookeeper中；

2.所有的节点都监听zookeeper路径/arch_group/healthcheck/election，当有变更时表示需要重新选举master；

3.master节点负责任务分配和健康检查，具体分配方式是添加一个任务给自己，并将其他无关任务移除；

4.master的任务负责按照周期轮询所有的providers，然后将这些providers的健康检查分配给其他的健康检查节点；

5.分配给其他节点的策略是发送一个HTTP请求让slave节点添加一个健康检查的任务。

slave节点需要执行健康检查任务，主要涉及如下内容：

1.slave节点除了监听master选举外默认启动后什么都不做；

2.slave节点当收到master节点发过来的添加任务的请求后开始执行健康检查任务。

有节点挂掉后策略：

1.由于所有的节点都监听了zookeeper的master选举节点，当有节点变更时集群所有节点都有感知；

2.当感知到master节点挂掉后，重新选举master，然后执行master的任务；

3.当感知到slave节点挂掉后，master节点不再分配任务给该挂掉的slave节点。

实施例三

图9示出了根据本发明一个实施例的基于共享内存的服务发现装置的功能框图。如图9所示，该装置包括：监听模块301，获取模块302，写入模块303。

监听模块301，适于监听并获取消息队列中记录的服务名称；其中，服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到所述服务的服务提供者信息而写入到消息队列中。

获取模块302，适于根据所述服务名称，从服务注册组件处获取所述服务的服务提供者信息；

写入模块303，适于将所述服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取所述服务的服务提供者信息并返回给应用层。

监听模块301进一步适于：监听消息队列中记录的服务名称；将消息队列中记录的服务名称读到内存中，并及时清除消息队列中记录的服务名称；从内存中获取所述服务名称。

监听模块301负责从消息队列里取服务名称。因为系统的消息队列大小有限制，若队列内的数据未及时取走，则可能因为客户端在短时间内大量写入服务名称而将队列填满，之后的服务名称将无法再写入，造成错误。而本装置获得服务名称后，需要通过网络去服务注册组件上取得服务提供者信息，相对较慢(10ms左右)，因此很可能发生队列的积压填满。为了避免出现这种问题，监听模块301监听消息队列中记录的服务名称，将消息队列中记录的服务名称读到内存中，并及时清除消息队列中记录的服务名称，防止填满队列。获取模块302从内存里获得需要读取的服务名称，再去服务注册组件上取值。

进一步的，该装置还可包括：扫描模块304，比对模块305，更新模块306。

扫描模块304，适于每隔预定时间扫描共享内存中的服务提供者信息；

比对模块305，适于将共享内存中的服务提供者信息与服务注册组件中的服务提供者信息进行比对；

更新模块306，适于若比对不一致，则根据服务注册组件中的服务提供者信息更新共享内存中的服务提供者信息。

因为服务注册组件的watcher机制不能设置为持久监视，而是一次性的，也就是说，一个事件被触发一次后，该watcher就被自动销毁，如果要继续监视下次事件，只能重新注册watcher。所以本发明采取的策略是事件发生后，第一时间先重新注册watcher，再执行具体的处理逻辑，尽量减少上个watcher销毁与下个watcher注册的时间间隔。尽管如此，这二者仍然不是事务性操作，因此仍有极小概率会丢失事件。为了防止这种情况发生，扫描模块304会每隔30-60分钟扫描共享内存里的所有节点，比对模块305将其与服务注册组件上的最新值比较，若有差异则由更新模块306更新到最新值，并为可能遗漏监视的节点重新注册watcher。

进一步的，该装置还可包括：生成模块307，适于生成动态链接库向利用不同编程语言实现的客户端提供统一的共享内存查询接口。

为了解决跨语言的通用性服务发现实现困难的难题，本装置提供的解决方案是不再在各个语言内部进行服务注册组件的实现，而是使用统一的编程语言，如C++编程语言对服务注册组件API进行调用和服务发现逻辑的封装，用C++生成动态链接库的方式来对外提供统一的服务发现的API。如图6所示，服务发现策略实现的各个语言接入主要支持：Java，Python，php，C/C++，lua等，还可支持shell，go等语言。各个语言接入共享内存主要通过动态链接库来和共享内存进行通信，各个语言通过封装动态链接库和服务发现逻辑提供的服务发现的接口只有一个即：get_service，接口参数为namespace和algorithm，该函数根据algorithm参数对namespace下的providers进行筛选从而返回一个provider出来给应用层使用。

实施例四

图10示出了根据本发明一个实施例的基于共享内存的服务发现系统的功能框图。如图10所示，该系统包括：上述实施例描述的基于共享内存的服务发现装置401、共享内存402、客户端403以及服务注册组件404。

客户端403适于：在接收到应用层访问服务的请求之后，在共享内存中查询到所述服务的服务提供者信息，若未查询到，则将服务名称写入到消息队列中；若查询到，则从共享内存中读取所述服务的服务提供者信息并返回给应用层。

客户端404还适于：根据读取的所述服务的服务提供者信息计算MD5值，将计算得到的MD5值与共享内存中存储的MD5值进行比对，若比对不一致，则重新从共享内存中读取所述服务的服务提供者信息。

从图4所示的系统架构图上可以看出，装置401与客户端403并没有直接的通讯，二者的交互的一个渠道是共享内存402。共享内存402的作用在于，客户端403可能会多次读取相同的配置项(其值可能并不会每次都改变)，如果没有在本机存储这些配置项，那么就必然需要每次通过网络去服务注册组件404服务端读取(相同的值)，一是存在网络延迟，二是服务注册组件404本身性能并不高，不适合大量的频繁读操作。之所以选用共享内存402这种存储方式，是看中了其性能优势，节点信息在共享内存402里以哈希表的形式存储，因此查询时间是常数级，实际测试一次读取耗时在16us左右，完全可以满足用户对低延迟的要求。

装置401与客户端403交互的另一个渠道是消息队列。客户端403接收到应用层访问服务的请求之后，先去共享内存402里检索，若找到则直接返回，若未找到，则将该服务的名称写入消息队列。而装置401时刻监视消息队列中是否有数据，一旦有数据被写入，装置401即读出数据(服务名)，再根据服务名去服务注册组件404把服务提供者信息读取回来，并写入共享内存402。客户端403会等待直到共享内存402里出现所要读取的服务提供者信息，然后读出服务提供者信息并返回。

由于涉及到多个进程(装置和客户端进程)对共享内存402的同时读写，所以需要避免冲突。共享内存402里同时存储服务提供者信息与其MD5值，客户端403会把二者一次全读出，然后根据读取的服务提供者信息计算MD5值，校验MD5值是否正确，若不正确则会重新读取，这就避免了装置401尚未写入完整的服务提供者信息被客户端403读走，也消除了锁争用，进一步提升性能。

进一步的，如图7所示，本系统基于Nginx开发了一个LB扩展模块，与客户端和共享内存通信连接，使客户端通过LB扩展模块与共享内存进行通信。具体地，使得nginx层可以通过该LB扩展模块来动态获取上游(upstream)的配置，从而解决了服务端的服务发现问题。

客户端的解决方案相对服务端来说没有依赖某个特定LB的场景，其实现也就比较简单，因为几乎所有的语言都支持linux环境下跨进程通信(IPC)机制，因此只要帮助各个语言实现一个从共享内存中获取服务信息的API的客户端即可，又由于本发明基于C++开发和服务注册组件通信时生成了动态链接库，因此只要该编程语言支持动态语言的接口即能快速实现其客户端读取服务的列表。

根据本发明上述实施例提供的基于共享内存的服务发现装置及系统，在客户端接收到应用层访问服务的请求之后，首先在共享内存中查询服务的服务提供者信息，若查询到，则直接在共享内存中读取服务提供者信息；若未查询到，则通过网络去服务注册组件中获取服务提供者信息。利用本装置及系统，达到了应用层在获取服务列表配置信息时和获取本地内存读写一样的性能，减少了网络延迟，提升了读取速度，这种与后端分布式集群通信产生共享内存并提供client供应用使用的方式，避免了客户端和分布式集群之间用长连接方式进行对接而导致的资源占用过多、服务注册组件处理效率低下的问题。另外，本装置及系统通过生成动态链接库向利用不同编程语言实现的客户端提供统一的共享内存查询接口，解决了跨语言的通用性服务发现实现困难的问题。本系统基于Nginx开发了一个扩展模块，使得nginx层可以通过该扩展模块来动态获取upstream的配置，从而解决了服务端的服务发现问题，又由于本发明基于C++开发和服务注册组件通信时生成了动态链接库，因此只要该编程语言支持动态语言的接口即能快速实现其客户端读取服务的列表，因而最终实现了兼容服务端的服务发现机制和客户端的服务发现机制。

实施例五

本申请实施例五提供了一种非易失性计算机存储介质，所述计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的基于共享内存的服务发现方法。

实施例六

图11示出了根据本发明实施例六的一种服务器的结构示意图，本发明具体实施例并不对服务器的具体实现做限定。

如图11所示，该服务器可以包括：处理器(processor)602、通信接口(Communications Interface)604、存储器(memory)606、以及通信总线608。

其中：

处理器602、通信接口604、以及存储器606通过通信总线608完成相互间的通信。

通信接口604，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器602，用于执行程序610，具体可以执行上述基于共享内存的服务发现方法实施例中的相关步骤。

具体地，程序610可以包括程序代码，该程序代码包括计算机操作指令。

处理器602可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。服务器包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器606，用于存放程序610。存储器606可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序610具体可以用于使得处理器602执行以下操作：监听并获取消息队列中记录的服务名称；其中，所述服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到所述服务的服务提供者信息而写入到消息队列中；根据所述服务名称，从服务注册组件处获取所述服务的服务提供者信息；将所述服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取所述服务的服务提供者信息并返回给应用层。

在一种可选的实施方式中，客户端接收到应用层访问服务的请求之后，在共享内存中查询到所述服务的服务提供者信息，从共享内存中读取所述服务的服务提供者信息并返回给应用层。

在一种可选的实施方式中，程序610用于使得处理器602监听消息队列中记录的服务名称；将消息队列中记录的服务名称读到内存中，并及时清除消息队列中记录的服务名称；从内存中获取所述服务名称。

在一种可选的实施方式中，程序610用于使得处理器602每隔预定时间扫描共享内存中的服务提供者信息；将共享内存中的服务提供者信息与服务注册组件中的服务提供者信息进行比对；若比对不一致，则根据服务注册组件中的服务提供者信息更新共享内存中的服务提供者信息。

在一种可选的实施方式中，所述共享内存中存储有服务提供者信息及其MD5值；程序610用于使得处理器602根据读取的所述服务的服务提供者信息计算MD5值，将计算得到的MD5值与共享内存中存储的MD5值进行比对，若比对不一致，则重新从共享内存中读取所述服务的服务提供者信息。

在一种可选的实施方式中，程序610用于使得处理器602生成动态链接库向利用不同编程语言实现的客户端提供统一的共享内存查询接口。

综上，本发明实施例提供的上述解决方案达到了如下技术效果：

1.以客户端最小侵入性的方式实现客户端层服务发现；

2.获取服务列表实现了超高的性能和原生读取内存几乎无差异；

3.客户端层服务发现和服务端层LB都实现了使用统一接口的服务发现方式；

4.服务端层LB的服务发现使得后端服务动态扩容/缩容更独立，无需通知依赖方服务变更，配置维护成本更低；

5.客户端层服务发现使得客户端有了自主负载均衡策略，客户端对后端服务的选择有了更大的自主空间，当后端服务出现阻塞卡顿时，客户端可以根据自己的重试策略来解决；

6.独立的分布式服务健康检查方案来实现服务节点的摘除策略；

7.与后端分布式集群通信产生共享内存并提供client供应用使用的方式，避免了客户端和分布式集群之间用长连接方式进行对接而导致的资源占用过多、服务注册组件处理效率低下的问题；

8.统一通过REST(Representational State Transfer，表述性状态传递)风格的API提供对后端分布式集群进行修改和删除操作，使得节点变更前后能够得到统一的控制。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明公开了：A1、一种基于共享内存的服务发现方法，包括：

监听并获取消息队列中记录的服务名称；其中，所述服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到所述服务的服务提供者信息而写入到消息队列中；

根据所述服务名称，从服务注册组件处获取所述服务的服务提供者信息；

将所述服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取所述服务的服务提供者信息并返回给应用层。

A2、根据A1所述的方法，其中，所述方法还包括：客户端接收到应用层访问服务的请求之后，在共享内存中查询到所述服务的服务提供者信息，从共享内存中读取所述服务的服务提供者信息并返回给应用层。

A3、根据A1所述的方法，其中，所述监听并获取消息队列中记录的服务名称进一步包括：

监听消息队列中记录的服务名称；

将消息队列中记录的服务名称读到内存中，并及时清除消息队列中记录的服务名称；

从内存中获取所述服务名称。

A4、根据A1所述的方法，其中，所述方法还包括：

每隔预定时间扫描共享内存中的服务提供者信息；

将共享内存中的服务提供者信息与服务注册组件中的服务提供者信息进行比对；

若比对不一致，则根据服务注册组件中的服务提供者信息更新共享内存中的服务提供者信息。

A5、根据A1或A2所述的方法，其中，所述共享内存中存储有服务提供者信息及其MD5值；

在客户端从共享内存中读取所述服务的服务提供者信息之后，所述方法还包括：根据读取的所述服务的服务提供者信息计算MD5值，将计算得到的MD5值与共享内存中存储的MD5值进行比对，若比对不一致，则重新从共享内存中读取所述服务的服务提供者信息。

A6、根据A1所述的方法，其中，所述方法还包括：生成动态链接库向利用不同编程语言实现的客户端提供统一的共享内存查询接口。

本发明还公开了：B7、一种基于共享内存的服务发现装置，包括：

监听模块，适于监听并获取消息队列中记录的服务名称；其中，所述服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到所述服务的服务提供者信息而写入到消息队列中；

获取模块，适于根据所述服务名称，从服务注册组件处获取所述服务的服务提供者信息；

写入模块，适于将所述服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取所述服务的服务提供者信息并返回给应用层。

B8、根据B7所述的装置，其中，所述监听模块进一步适于：

监听消息队列中记录的服务名称；

将消息队列中记录的服务名称读到内存中，并及时清除消息队列中记录的服务名称；

从内存中获取所述服务名称。

B9、根据B7所述的装置，其中，所述装置还包括：

扫描模块，适于每隔预定时间扫描共享内存中的服务提供者信息；

比对模块，适于将共享内存中的服务提供者信息与服务注册组件中的服务提供者信息进行比对；

更新模块，适于若比对不一致，则根据服务注册组件中的服务提供者信息更新共享内存中的服务提供者信息。

B10、根据B7所述的装置，其中，所述装置还包括：生成模块，适于生成动态链接库向利用不同编程语言实现的客户端提供统一的共享内存查询接口。

本发明还公开了：C11、一种基于共享内存的服务发现系统，包括：B7-B10任一项所述的基于共享内存的服务发现装置、共享内存、客户端以及服务注册组件；

所述客户端适于：在接收到应用层访问服务的请求之后，在共享内存中查询到所述服务的服务提供者信息，若未查询到，则将服务名称写入到消息队列中；若查询到，则从共享内存中读取所述服务的服务提供者信息并返回给应用层。

C12、根据C11所述的系统，其中，所述客户端还适于：根据读取的所述服务的服务提供者信息计算MD5值，将计算得到的MD5值与共享内存中存储的MD5值进行比对，若比对不一致，则重新从共享内存中读取所述服务的服务提供者信息。

C13、根据C11所述的系统，其中，还包括：LB扩展模块，与客户端和共享内存通信连接，使客户端通过LB扩展模块与共享内存进行通信。

本发明还公开了：D14、一种服务器，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如A1-A6中任一项所述的基于共享内存的服务发现方法对应的操作。

本发明还公开了：E15、一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使所述处理器执行如A1-A6中任一项所述的基于共享内存的服务发现方法对应的操作。

Claims (10)

1.一种基于共享内存的服务发现方法，包括：

监听并获取消息队列中记录的服务名称；其中，所述服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到所述服务的服务提供者信息而写入到消息队列中；

根据所述服务名称，从服务注册组件处获取所述服务的服务提供者信息；

将所述服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取所述服务的服务提供者信息并返回给应用层。

2.根据权利要求1所述的方法，其中，所述方法还包括：客户端接收到应用层访问服务的请求之后，在共享内存中查询到所述服务的服务提供者信息，从共享内存中读取所述服务的服务提供者信息并返回给应用层。

3.根据权利要求1所述的方法，其中，所述监听并获取消息队列中记录的服务名称进一步包括：

监听消息队列中记录的服务名称；

将消息队列中记录的服务名称读到内存中，并及时清除消息队列中记录的服务名称；

从内存中获取所述服务名称。

4.根据权利要求1所述的方法，其中，所述方法还包括：

每隔预定时间扫描共享内存中的服务提供者信息；

将共享内存中的服务提供者信息与服务注册组件中的服务提供者信息进行比对；

若比对不一致，则根据服务注册组件中的服务提供者信息更新共享内存中的服务提供者信息。

5.根据权利要求1或2所述的方法，其中，所述共享内存中存储有服务提供者信息及其MD5值；

在客户端从共享内存中读取所述服务的服务提供者信息之后，所述方法还包括：根据读取的所述服务的服务提供者信息计算MD5值，将计算得到的MD5值与共享内存中存储的MD5值进行比对，若比对不一致，则重新从共享内存中读取所述服务的服务提供者信息。

6.根据权利要求1所述的方法，其中，所述方法还包括：生成动态链接库向利用不同编程语言实现的客户端提供统一的共享内存查询接口。

7.一种基于共享内存的服务发现装置，包括：

监听模块，适于监听并获取消息队列中记录的服务名称；其中，所述服务名称是客户端接收到应用层访问服务的请求之后，在共享内存中未查询到所述服务的服务提供者信息而写入到消息队列中；

获取模块，适于根据所述服务名称，从服务注册组件处获取所述服务的服务提供者信息；

写入模块，适于将所述服务的服务提供者信息写入共享内存中，以供客户端从共享内存中读取所述服务的服务提供者信息并返回给应用层。

8.一种基于共享内存的服务发现系统，包括：权利要求7所述的基于共享内存的服务发现装置、共享内存、客户端以及服务注册组件；

所述客户端适于：在接收到应用层访问服务的请求之后，在共享内存中查询到所述服务的服务提供者信息，若未查询到，则将服务名称写入到消息队列中；若查询到，则从共享内存中读取所述服务的服务提供者信息并返回给应用层。

9.一种服务器，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-6中任一项所述的基于共享内存的服务发现方法对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-6中任一项所述的基于共享内存的服务发现方法对应的操作。