Apollo服务端设计原理剖析

Posted 2023-04-16

参考技术A

本文摘自于 《Spring Cloud微服务 入门 实战与进阶》 一书。

配置中心最重要的一个特性就是实时推送了，正因为有这个特性，我们可以依赖配置中心做很多事情。在我自己开发的Smconf这个配置中心，Smconf是依赖于Zookeeper的Watch机制来实现实时推送。

上图简要描述了配置发布的大致过程：

ReleaseMessage消息是通过mysql实现了一个简单的消息队列。之所有没有采用消息中间件，是为了让Apollo在部署的时候尽量简单，尽可能减少外部依赖。

上图简要描述了发送ReleaseMessage的大致过程：

通知是采用基于Http长连接实现，主要分为下面几个步骤：

Apollo推送这块代码比较多，就不在本书中详细分析了，我把推送这块的代码稍微简化了下，给大家进行讲解，这样理解起来会更容易。当然我这边会比较简单，很多细节就不做考虑了，只是为了能够让大家明白Apollo推送的核心原理。

发送ReleaseMessage的逻辑我们就写一个简单的接口，用队列存储，测试的时候就调用这个接口模拟配置有更新，发送ReleaseMessage消息。

消息发送之后，前面我们有讲过Config Service会启动一个线程定时扫描ReleaseMessage表，去查看是否有新的消息记录，然后取通知客户端，这边我们也启动一个线程去扫描：

循环去读取NotificationControllerV2中的队列，如果有消息的话就构造一个ReleaseMessage的对象，然后调用NotificationControllerV2中的handleMessage()方法进行消息的处理。

ReleaseMessage就一个字段，模拟消息内容：

接下来，我们看handleMessage做了什么样的工作

NotificationControllerV2实现了ReleaseMessageListener接口，ReleaseMessageListener中定义了handleMessage()方法。

handleMessage就是当配置发生变化的时候，通知的消息监听器，消息监听器得到配置发布的信息后，则会通知对应的客户端：

Apollo的实时推送是基于Spring DeferredResult实现的，在handleMessage()方法中可以看到是通过deferredResults获取DeferredResult，deferredResults就是第一行的Multimap，Key其实就是消息内容，Value就是DeferredResult的业务包装类DeferredResultWrapper，我们来看下DeferredResultWrapper的代码：

通过setResult()方法设置返回结果给客户端，以上就是当配置发生变化，然后通过消息监听器通知客户端的原理，那么客户端是在什么时候接入的呢？

NotificationControllerV2中提供了一个/getConfig的接口，客户端在启动的时候会调用这个接口，这个时候会执行getApolloConfigNotifications()方法去获取有没有配置的变更信息，如果有的话证明配置修改过，直接就通过deferredResultWrapper.setResult(newNotifications);返回结果给客户端了，客户端收到结果后重新拉取配置的信息进行覆盖本地的配置。

如果getApolloConfigNotifications()方法没有返回配置修改的信息，证明配置没有发生修改，就将DeferredResultWrapper对象添加到deferredResults中，等待后续配置发生变化时消息监听器进行通知。

同时这个请求就会挂起，不会立即返回，挂起是通过DeferredResultWrapper中的下面的代码实现的：

在创建DeferredResult对象的时候指定了超时的时间和超时后返回的响应码，如果60秒内没有消息监听器进行通知，那么这个请求就会超时，超时后客户端就收到的响应码就是304。

整个Config Service的流程就走完了，接下来我们看客户端是怎么实现的，我们简单的写个测试类模拟客户端注册：

首先启动/getConfig接口所在的服务，然后启动客户端，客户端就会发起注册请求，如果有修改直接获取到结果，进行配置的更新操作。如果无修改，请求会挂起，这边客户端设置的读取超时时间是90秒，大于服务端的60秒超时时间。

每次收到结果后，无论是有修改还是没修改，都必须重新进行注册，通过这样的方式就可以达到配置实时推送的效果。

我们可以调用之前写的/addMsg接口来模拟配置发生变化，调用之后客户端就能马上得到返回结果。

本文摘自于 《Spring Cloud微服务 入门 实战与进阶》 一书。

去年出版的 《Spring Cloud微服务:全栈技术与案例解析》 一书，得到了大家的支持以及反馈，基于大家的反馈，重新进行了更正和改进。

基于比较稳定的 Spring Cloud Finchley.SR2 版本和 Spring Boot 2.0.6.RELEASE 版本编写。

同时将示列代码进行标准的归档，之前的都在一起，不方便读者参考和运行。

同时还增加了像Apollo，Spring Cloud Gateway，生产实践经验等新的内容。

https://github.com/yinjihuan/spring-cloud

C++服务器设计：聊天系统服务端实现

　　在之前的章节中，我们对服务端系统的设计实现原理进行了剖析，在这一章中，我们将对服务端框架进行实际运用，实现一款运行于内网环境的聊天系统。该聊天系统由客户端与服务器两部分组成，同时服务端通过数据库维护用户的账号信息。本章将重点介绍如何运用该服务端框架进行服务器业务逻辑开发。

聊天系统功能分析

　　本聊天系统只作为服务端框架的运用展示，因此仅限于最基本的局域网聊天工具，数据传输均采用为明文形式，并不在安全性上进行深入探讨。具体功能需求分析如下：

• l  用户注册：提供新用户账号注册功能，注册内容包括新用户的账号名和密码。服务器需要检测注册信息的有效性，并将注册用户的信息保存在数据库中。
• l  用户登录：用户根据账号密码进行登录操作，若未进行登录操作将无权限请求聊天相关消息。服务器查询数据库验证用户账号信息，同时判断该用户是否已经登陆。用户账号不允许重复登录。
• l  在线好友更新：已登录用户可以主动向服务器查询当前在线的好友信息。服务器同样应该及时向所有登录用户推送好友上线及下线信息。
• l  好友聊天：已登录用户可以向在线状态的任意好友发送聊天消息，同时也能接收到来自其他在线状态的好友发送过来的消息。
• l  群体聊天：已登录用户可以同时向所有在线状态的好友发送群体聊天消息。同时也能接收到来自其他在线状态的好友发送的群体聊天消息。

聊天系统服务端实现

数据库实现

　　聊天系统需要维护用户的账号信息，记录注册的新账号，并对每次登录的用户信息进行校验。我们选用轻量级的Mysql作为数据库管理系统，并选择Mysql++作为Mysql的API操作库。

　　整个聊天系统只建立了一个名为UserInfo表结构，如表5-1所示。同时根据Mysql++封装了两个操作接口，分别添加新用户账号信息，以及根据账号名和密码查询该用户是否存在。

表5-1 用户账号信息表UserInfo

字段名	数据类型	关键字	约束	含义
id	int(20)	Y	unique	唯一标识符
username	varchar(20)	N	unique,not null	账号名
Password	varchar(20)	N	not null	密码

　　由于数据库操作涉及网络传输及磁盘处理，因此属于耗时操作。而在服务端框架Reactor反应池中的所有处理必须在非阻塞环境下进行，如果进行耗时操作将会阻塞当前线程，导致其它消息事件得不到及时处理。因此在Reactor中进行数据库操作应该以异步的方式进行，可以通过创建工作线程池的方式处理数据库等耗时操作。但是在本聊天系统中，只有在注册新用户和用户登录两个场景中才涉及数据库操作。为了简化开发模型，我们在此直接调用数据库相关的操作。

　　数据库部分并非本文论述重点，因此不再做进一步介绍。

聊天设备类型及消息事件实现

　　通过分析功能需求，可以得知客户端连接主要存在两种状态下的消息请求，分别为临时状态和登录状态。在临时状态下需要能够请求注册新用户和登录操作，在登录状态下需要能够请求当前在线用户信息，向某个用户发送消息类型和广播消息类型。并且由于服务器存在登录超时的机制，客户端连接不管在临时状态还是登录状态，均需定时向服务器发送心跳消息。

　　客户端的两种状态正好对应于服务端框架制定的两种设备类型，即临时设备类型和登录设备类型。如图5-1所示。我们为临时设备添加新的注册账号消息事件，用于向所有与服务端建立了连接的客户进行注册操作。同时我们创建一个新的设备类型，名为ChatType设备类型，并且继承于登录设备类型，用于专门处理登录后和聊天相关的消息事件。

 

图5-1 聊天设备类型及消息事件

　　临时设备类型新添加的消息事件介绍如下：

• l  registerUsr：注册新的用户账号。客户端在请求该消息事件时需同时传入期待注册的账号名和密码。服务器接收到该消息事件后，将校验账号名和密码是否合法，然后调用数据库新账户注册接口，进行账户注册。最后根据数据库实际插入结果向客户端发送注册结果信息。由于该消息事件无需请求权限，任何连接该服务器的客户均可进行注册操作。为了防止存在某些客户进行恶意注册现象，在实际实现中添加了邀请码信息。服务端将会验证客户端传来的邀请码是否正确，如果邀请码正确才会实际进行注册操作。
• l  heartMsg：心跳消息。客户端将会定期发送心跳消息。服务器接收到该消息事件后，将会在超时队列更新该连接的超时信息。在事件回调实现中，并不会对该消息进行进一步业务处理，而是直接返回。

 

　　ChatType为新创建的继承于默认登录设备的设备类型，具体实现的消息事件介绍如下：

• l  askFriends：请求当前在线的用户信息。客户端会在登录成功后，向服务器请求该消息事件。服务器收到该消息事件后，将会查询除请求者外，当前其他所有在线的ChatType类型的用户信息，并整理发送给客户端。该数据用于客户端对在线用户列表的初始化工作。
• l  chatSend：向一个指定在线用户发送聊天消息。客户端将会把聊天消息的内容，自己的信息，及期望接收该聊天消息的用户信息发送给服务器。服务端接收到该消息事件后，将会尝试找寻该接收用户，并将聊天消息和发送者消息转发给该接收用户，并向发送用户返回发送成功消息事件。如果该接收用户并不在线，将只会向发送用户返回发送失败的消息事件。
• l  groupSend：向全体在线用户发送聊天消息。客户端将会把聊天消息及自身信息发送给服务器。服务器接收到该消息后，将会遍历除请求者外，当前其他所有在线的ChatType类型的用户，并将该聊天消息和发送者信息转发给所有遍历的用户，并向发送用户返回发送成功的消息。
• l  heartMsg：心跳消息。同临时设备新添加的heartMsg的心跳消息。

聊天设备的生命周期实现

　　虽然我们已经为聊天客户端的连接制定了具体的设备类型和消息事件，但是一些和连接状态相关的业务逻辑仍然需要我们设计。比如如何制定与聊天客户端相关的具体登录过程？当某个聊天客户端已经成功登录后，怎样第一时间通知其他客户端该账号已上线？当某个聊天客户端退出时，又如何通知其他客户端该账号已下线？这些与客户端状态相关的操作都依赖上一章节制定的连接生命周期机制来进行管理。

 

图5-2 聊天设备的生命周期

　　具体的聊天设备的连接生命周期实现如图所示。我们只需对具体业务相关的生命周期接口的实现进行重写即可，因此无需进行更改的生命周期接口并未被列出。需要被重写的接口实现介绍如下：

• l  onLoginCheckMsg()：当客户端执行登录操作，且选择登录类型为ChatType设备类型时，将会执行该接口。此时系统将会检查客户端传来的账号名和密码是否合法，如果合法将会调用数据库的账号密码查询接口，判断该账户是否存在。如果该账户存在，则返回True，并将控制权交还给系统进行进一步的登录操作；如果该账户不存在，则向该客户端发送不存在该账号信息，此次登录失败的消息，并直接返回False退出整个登录操作。
• l  onLoginSuccessMsg()：当登录类型为ChatType的客户端进行登录操作，执行onLoginCheckMsg()返回True，且系统整个登录过程成功时，将会执行该接口。此时系统将会进行两件工作：首先向该客户端发送登录成功的消息；其次将会遍历除该用户本身外的其他已登录的ChatType类型的用户，并向这些用户发送通知消息表明该新用户已上线。这样每个登录用户只需在第一次登录的时候向服务器请求当前所有在线用户信息，而新的用户上线或老用户下线等信息将由服务器主动推送，而无需客户端定期请求维护。
• l  onLoginFailureMsg()：当登录类型为ChatType的客户端进行登录操作，执行onLoginCheckMsg()返回True，但整个登录过程失败时，将会执行该接口。一般该接口被执行将表明此用户账号已经被登录，服务器无法对相同账号进行重复登录操作。此时服务器将会向客户端发送重复登录，此次登录失败的消息，并退出整个登录操作。
• l  onLogoutMsg()：当登录类型为ChatType的客户端进行注销操作时，将会执行该接口。服务器将向该客户端返回注销成功的消息，并对该连接进行进一步的注销操作。
• l  releaseConnNode()：当登录类型为ChatType的客户端进行注销成功，或者连接由于超时或者其它异常原因被迫退出时，将会执行该接口。此时服务器将会遍历除该用户本身外的其他已登录的ChatType类型的用户，并向这些用户发送通知消息表明该用户已经下线。同时系统将会把该用户连接所申请的相关资源进行释放工作。
• l  onOverTime()：当服务器一段时间内未收到该客户端有效消息或心跳消息，将会被判超时，并执行该接口。一般执行该接口时表明该客户端已经由于异常而停止工作，但是并未主动断开连接。此时服务器将尝试向该客户端发送一条该连接已经超时的消息。由于客户端已经处于异常状态，并不能保证该条消息能够被客户端接收。然后服务器将会执行releaseConnNode()接口，并强制断开该客户端连接。

聊天系统展示

　　该聊天系统部署于局域网内，并可通过C#实现的客户端进行相关操作。运行场景截图如下：

图5-3 登录及注册窗口

　　如图5-3为客户端的登录窗口与注册窗口。注册窗口通过登录窗口的注册按键打开，并可进行新账号的注册操作。同时登录窗口可以进行账号的登录操作，如果登录失败将会显示具体失败原因；如果登录成功，将会进入客户端主界面。

 

图5-4 主界面及好友聊天窗口

　　如图5-4为客户端的主界面及聊天窗口。在主界面中显示了当前登录的用户名及当前在线的用户名列及数量。可以单击具体用户名进入与该用户的聊天窗口。在聊天窗口中，可以在输入栏输入消息，并点击发送键或按下回车键发送该消息。如果收到其他用户的聊天消息，客户端也会主动弹出该用户的聊天窗口，并显示接收的的聊天信息。在主界面的下方还存在群聊按键，点击可以进入群聊窗口。

 

图5-5 群聊窗口

　　如图5-5为群聊窗口。在群聊窗口中可以接收到打开了该窗口的其他用户发送的聊天信息。同时自己也能输入相关聊天消息并发送给所有该窗口下的其他用户。