济南企业网站推广方法,长葛网站制作,南京经济经济技术开发总公司,郑州做定制网站的公司目录
Rpc远程调用的思想
项目框架设计
服务端模块划分
网络通信模块 Network
应用层通信协议模块 Protocol
消息分发处理模块 Dispatcher
远程调用路由功能模块 RpcRouter
编辑
发布订阅功能模块 Publish-Subscribe
服务注册/发现/上线/下线功能模块 Registry-Disc…目录
Rpc远程调用的思想
项目框架设计
服务端模块划分
网络通信模块 Network
应用层通信协议模块 Protocol
消息分发处理模块 Dispatcher
远程调用路由功能模块 RpcRouter
编辑
发布订阅功能模块 Publish-Subscribe
服务注册/发现/上线/下线功能模块 Registry-Discovery
服务端模块 Server
客户端模块划分
网络通信模块 Network
应用层通信协议模块 Protocol
消息分发处理模块 Dispatcher
请求管理模块 Requestor
远程调用功能模块 RpcCaller
发布订阅功能模块 Publish-Subscribe
服务注册/发现/上线/下线功能模块 Registry-Discovery
框架设计
抽象层
具象层
业务层 Rpc远程调用的思想 节省本地计算机的算力通过远程调用服务器方法来实现但是这种多对一的方法如下图存在一个健壮性问题当远程服务器出现故障所有客户端将无法正常调用方法。 因此我们需要引入分布式架构的rpc我们因该将客户端和服务器之间的关系改为多对多的关系以此来提高健壮性和稳定性。
如下引入一个中转中心进行服务发现和服务注册 当然客户端与这个中转中心服务器也形成了多对一的关系但是我们可以通过升级某个rpc服务器使其当作备用中转中心服务器这样系统的健壮性和稳定性便有了保障。 所谓的服务发布订阅也就是一个客户端提供某种服务便在服务器上注册一个也就是服务注册服务器按功能划分主题当一个客户端需要某个功能就订阅哪个某个功能对应的主题如下图 那么客户端如何知道服务端有哪些功能主题呢这里就需要引入服务发现客户端先通过服务发现来发现服务器上有哪些功能主题然后按需订阅。
这个项目的三个主要功能
rpc调用服务注册与发现以及服务的下线/上线通知消息的发布订阅
项目框架设计
服务端模块划分
服务端的功能需求 基于网络通信接收客户端的请求提供rpc服务。基于网络通信接收客户端的请求提供服务注册与发现服务上线与下线通知。基于网络通信接收客户端的请求提供主题操作创建/删除/订阅/取消订阅消息发布。 我们按服务端的功能需求将服务端的功能划分为以下几个模块 Network网络通信模块Protocol应用层通信协议模块Dispatcher消息分发处理模块RpcRouter远程调用路由功能模块Publish-Subscribe发布订阅功能模块Registry-Discovery服务注册/发现/上线/下线功能模块Server基于以上模块整合而出的服务端模块 网络通信模块 Network 该模块为网络通信模块实现底层的网络通信功能使用Muduo库来进行搭建。
应用层通信协议模块 Protocol 应用层通信协议模块存在的意义解析数据解决通信中可能存在的粘包的问题能够获取一条完整的消息。 该模块就是网络通信模块的设计在网络通信中我们是基于Tcp协议的可能会存在粘包问题因此我们必须设计一个应用层的网络通信协议解决粘包问题又三种方式特殊字符间隔要处理转义问题、定长本项目中的消息有长也有短不适合、LV格式。这里我们使用LV格式来定义应用层的通信协议格式如下
首先是定长的长度Length变长的主体主体又分为两大部分 消息的类型MType本项目使用数字来表示消息的类型因此只需要4字节描述消息ID部分IDLength、MID、Body 消息的ID每一条消息都有对应的ID具有唯一性客户端接收到返回的服务响应消息ID要与请求的消息ID对应以此区分不同的服务响应 因为消息的ID需要具有唯一性因此我们这里ID使用字符串进行表示因此需要三个部分表示为了方便扩展这里ID使用变长的使用IDLength描述MID的长度而MID是描述消息的ID的长度。 消息分发处理模块 Dispatcher 消息分发处理模块存在的意义区分消息类型根据不同的类型调用不同的业务处理函数进行消息处理。发出对应的rpc请求 该模块主要是一个表描述消息的类型和对应的回调函数将这两者之间进行映射。 Protocol模块的onMessage接口是对接收原生的数据进行应用层协议的处理并将获取的完整的消息内容交给Dispatcher模块Dispatcher模块的onMessage接口来区分是什么消息类型和对应的业务处理函数也就是查看map然后再调用muduo库中的onMessageCallback接口。 而Dispatcher模块中通过registerHandler()接口来注册消息类型和回调函数之间的映射关系。 消息的类型 rpc请求和响应服务注册/发现/上线/下线请求和响应主题创建/删除/订阅/取消订阅请求和响应消息发布的请求和响应 远程调用路由功能模块 RpcRouter RpcRouter模块存在的意义提供rpc请求的处理回调函数内部所要实现的功能分辨出客户端请求的服务进行处理得到结果进行响应。 rpc请求中最关键的两个点 请求方法名称请求对应要处理的参数信息 在一个rpc请求中一定会有对应字段描述消息所请求的方法名称和相应的参数这个模块主要是根据请求中的方法去调用对应的远程方法。 Dispatcher模块只是区分消息类型比如服务注册..根据消息类型发送相应的rpc请求RpcRouter模块则需要根据Dispatcher模块发来的请求中根据方法名调用对应的远程方法也就是说RpcRouter模块也会有一张表表示方法与远程方法的映射关系如下 再因为可能客户端发来请求中的参数不一定是正确的所以RpcRouter模块还需要有一个方法描述描述方法类型和参数字段名称和类型再接收到客户端的rpc请求后根据方法描述进行校验没有问题则取出指定字段进行处理并返回结果。 不管是客户端要传递给服务端的服务名称以及参数信息或者是服务端返回的结果都是在上边Protocol中定义的Body字段中因此Body字段就存在了一个正文的序列化/反序列化过程。 序列化的方法有很多种这里我们使用json序列化来进行所定义格式如下
//RPC-request
{method : Add,parameters : {num1 : 11,num2 : 22}
}
//RPC-response
{rcode : OK,result: 33
}
{rcode : ERROR_INVALID_PARAMETERS
} 根据上面所述再实现该模块时必须具备以下几个部分 该模块必须具备一个rpc路由管理其中包含对于每个服务的参数校验功能该模块必须具备一个方法名称和方法业务回调的映射。该模块必须向外提供rpc请求的业务处理函数。 发布订阅功能模块 Publish-Subscribe Publish-Subscribe模块存在的意义针对发布订阅请求进行处理提供一个回调函数设置给Dispatcher模块。 该模块主要给客户端提供服务进行主题的相关操作和消息发布。
发布订阅所包含的请求操作 主题的创建主题的删除主题的订阅主题的取消订阅主题消息的发布 相应的请求和响应格式如下
//Topic-request
{key : music, //主题名称// 主题操作类型optype : TOPIC_CRAETE/TOPIC_REMOVE/TOPIC_SUBSCRIBE/TOPIC_CANCEL/TOPIC_PUBLISH,//TOPIC_PUBLISH请求才会包含有message字段message : Hello World
}
//Topic-response
{rcode : OK
}
{rcode : ERROR_INVALID_PARAMETERS
}
1、该模块必须具备一个主题管理且主题中需要保存订阅了该主题的客户端连接。
主题收到一条消息需要将这条消息推送给订阅了该主题的所有客户端。
2、该模块必须具备一个订阅者管理且每个订阅者描述中必须保存自己所订阅的主题名称。
目的是为了当一个订阅客户端断开连接时能够找到订阅信息的关联关系在主题管理中进行删除。
3、该模块必须向外提供 主题创建/销毁主题订阅/取消订阅消息发布处理的业务处理函数。 服务注册/发现/上线/下线功能模块 Registry-Discovery 该模块主要给服务端提供服务进行服务注册与发现。 Registry-Discovery模块存在的意义就是针对服务注册与发现请求的处理。
服务注册/发现类型请求中的详细划分 服务注册服务provider告诉中转中心自己能提供哪些服务服务发现服务caller询问中转中心谁能提供指定服务服务上线在一个provider上线了指定的服务后通知发现过该服务的客户端有个provider可以提供该服务服务下线在一个provider断开连接通知发现过该服务的caller谁下线了哪个服务 //RD--request
{//SERVICE_REGISTRY-Rpc-provider进⾏服务注册//SERVICE_DISCOVERY - Rpc-caller进⾏服务发现//SERVICE_ONLINE/SERVICE_OFFLINE 在provider下线后对caller进⾏服务上下线通知optype : SERVICE_REGISTRY/SERVICE_DISCOVERY/SERVICE_ONLINE/SERVICE_OFFLINE,method : Add,//服务注册/上线/下线有host字段发现则⽆host字段host : {ip : 127.0.0.1,port : 9090}
}
//Registry/Online/Offline-response
{rcode : OK,
}
//error-response
{rcode : ERROR_INVALID_PARAMETERS,
}
//Discovery-response
{method : Add,host : [{ip : 127.0.0.1,port : 9090},{ip : 127.0.0.2,port : 8080}]
}
该模块的设计如下
1、必须具备一个服务发现者管理
方法与发现者当一个客户端进行服务发现的时候进行记录谁发现过该服务当有新的提供者上线的时候可以通知该发现者。连接与发现者当一个发现者断开连接了删除上面方法与发现者的关联关系往后就不再通知了。
2、必须具备一个服务提供者管理
连接与服务提供者当一个服务提供者断开连接的时候能够通知该提供者提供的服务可能有多个服务对应的发现者该提供者提供的某某服务下线了。方法与服务提供者能够知道谁的哪些方法下线了然后通知发现过该方法的客户端。 服务端模块 Server 该模块即能搭建一个服务注册中心也能搭建一个服务提供者的服务器。
客户端模块划分
我们将客户端划分为以下几个功能模块 Network网络通信模块Protocol应用层通信协议模块Dispatcher消息分发处理模块Requestor请求管理模块RpcCaller远程调用功能模块Publish-Subscribe发布订阅功能模块Registry-Discovery服务注册/发现/上线/下线功能模块Server基于以上模块整合而出的服务端模块 网络通信模块 Network
网络通信基于muduo库实现网络通信客户端。
应用层通信协议模块 Protocol
应用层通信协议处理与服务端保持一致。
消息分发处理模块 Dispatcher
IO数据分发处理逻辑与服务端一致与服务端的区别在于主要针对响应分发进行处理。
请求管理模块 Requestor Requestor模块存在的意义针对客户端的每一条请求进行管理以便于对请求对应的响应做出合适的操作。 为什么客户端需要增加这个模块呢 第一点对于客户端来说更多时候客户端是请求方是主动发起请求服务的一方在多线程的网络通信中针对多个请求进行响应就可能会存在时序的问题这种情况下我们无法保证一个线程发送一个请求后接下来接收到的响应就是针对自己这条请求的响应。 第二点因为本项目是基于muduo库这种异步IO网络通信库的通常IO都是异步操作即发送数据就是把数据放入缓冲区但是什么时候发送由底层的网络库来进行协调并且也不会提供recv接口而是在连续触发可读事件后IO读取数据完成后调用处理回调进行数据处理因此也无法直接在发送请求后去等待该条请求的响应。 针对以上两个问题我们就需要创建当前的请求管理模块 Requestor就是给每个请求都设定一个请求ID服务器进行响应的时候标识响应针对的是哪个请求也就是响应信息中会包含请求ID因此客户端这边我们不管收到哪条请求的响应将数据存储入一个hash_map中以请求ID作为映射并向外提供获取指定请求ID响应的阻塞接口这样只要在发送请求的时候知道自己的请求ID那么就能获取到自己想要的响应而不会出现张冠李戴的情况。 针对这个解决方法我们再进一步可以将每个请求进一步封装描述添加入异步的future控制或者设置回调函数的方式这样不仅可以阻塞获取响应也可以实现异步获取响应以及回调处理响应。 远程调用功能模块 RpcCaller RpcCaller模块存在的意义向用户提供进行rpc调用的模块。 该模块相对简单只需要向外提供几个rpc调用的接口内部实现向服务端发送请求等待获取结果即可稍微麻烦的一点是rpc调用我们需要提供多种不同方式的调用 同步调用发送调用后等收到响应结果后返回。异步调用发起调用后立即返回在想获取结果的时候进行获取。回调调用发起调用的同时设置结果的处理回调收到响应后自动对结果进行回调处理。 请求是通过Requestor模块进行发送Requestor模块可以对收到的响应进行处理根据请求描述区分同步/异步/回调请求进行设置相应的内容。 发布订阅功能模块 Publish-Subscribe Publish-Subscribe模块存在的意义向用户提供发布订阅所需的接口针对推送过来的消息进行处理。 发布订阅稍微复杂一点在发布订阅中客户端可能是消息的发布者也可能是消息的订阅者。而且不管是哪个角色都是对主题进行操作因此也包含了主题的相关操作比如要发布一条消息需要先创建一个主题。 一个订阅者可能会订阅多个主题每个主题的消息可能有不同的处理方式因此需要有订阅者主题回调的管理。 主题创建/销毁/订阅/取消订阅都是客户端的主动请求但是消息发布到服务器后对于客户端A是一个主动请求但是对于订阅了该主题的客户端B是一个被动请求。 因此当一个客户端订阅主题的时候就必须设置一个主题消息的处理回调。同样的客户端也必须针对消息发布请求做出Dispatcher模块的处理分发。 Dispatcher模块中主动的请求都是通过requestor接口进行发送的和接收处理响应的如果是收到一个消息发布的请求则是通过onPublish接口。 服务注册/发现/上线/下线功能模块 Registry-Discovery
每个服务提供端都包含一个RpcProvider服务端和RegisteryClient客户端。每一个客户端都包含一个发现客户端和rpccaller客户端。 作为服务操作的客户端 向外提供服务注册的功能接口连接注册中心发送服务注册请求等待响应判断是否注册成功。向外提供服务发现的功能接口连接注册中心发送服务发现请求等待响应获取到提供服务的主机信息。 也就是说要实现的客户端既能用于provider进行服务注册也能用于caller进行服务发现。 对于服务发现来说注册中心只能将当前注册了该服务的主机地址返回如果后续又有了其他的主机注册了该服务之前进行了服务发现的主机是得不到这个主机信息的因此还得有服务上线/下线通知。 框架设计
在本项目的实现中我们将整个项目的实现划分为三层来进行实现 抽象层将底层的网络通信以及应用层通信协议以及请求响应进行抽象使项目更具扩展性和灵活性。具象层针对抽象的功能进行具体的实现。业务层基于抽象的框架在上层实现项目所需功能。 抽象层
在项目实现中
网络通信部分采用了第三方库Muduo库通信协议使用了LV格式的通信心意来解决粘包问题数据正文采用了Json格式进行序列化和反序列化 而这几个方面我们后续可能会存在优化的的问题甚至在序列化部分不一定非要采用Json因此在设计项目框架的时候我们对底层通信部分相关功能先进行抽象形成一层抽象层而上层业务部分根据抽象层来完成功能这样的好处是在具体的底层功能实现部分我们可以实现插拔式模块化替换以此来提高项目的灵活性和扩展性。
具象层 具象层就是针对抽象的具体实现。 而具体的实现也比较简单从抽象类派生出具体功能的派生类然后在内部实现各个接口功能即可。 基于Muduo库实现网络通信部分抽象基于LV通信协议实现Protocol部分抽象 这一层比较特殊的是需要针对不同的请求从BaseMessage中派生出不同的请求和响应类型以便于在针对指定消息处理时能够轻松的获取或设置请求及响应中的各项数据元素。
业务层 业务层就是基于底层的通信框架针对项目中具体的业务功能的实现了比如Rpc请求的处理发布订阅请求的处理以及服务注册与发现的处理等等。
