网络框架重构设计

Posted 2021-01-01 tgltt

一、背景

         网络管理层是各上层业务都要用到的层级，为提供更高效率、更高质量的服务，需对网络服务层进行重构。

二、重构目标

1、提供连接管理

        在App整个运行过程中，始终向上层业务提供两条有效的长连接（云端连接和路由器连接），并支持在网络断开、心跳失败后的重连机制.

2、自动登陆(已实现)

        在长连接重建后, 自动登陆服务器.

3、自动同步(已实现)

        在长连接重建后、并自动登陆服务器后, 自动同步本地信息到云平台/路由器.

4、网络服务代理层RemoteProxy

        RemoteProxy作为对上层业务的唯一网络接口, 向上层业务提供获取业务数据的网络访问接口, 使上层业务无需关心网络访问的细节, 其内部实现了连接管理等功能.

5、独立出同步功能

        将同步功能从ControlPad和logincenter中抽取出来，作为独立的公共库hdsync。

三、重构方案

3.1 网络整体框架构思

         图1为《智能家居APP架构说明》中描述的网络整体框架构思图，本方案基于此架构构思进行设计。

 

图1网络整体框架

 

3.2 网络框架工作流程

        图2描述了网络库重构方案的原理主流程。

       本次网络库重构，重点在于网络连接管理，网络连接管理主要处理两种场景：网络发生变化和心跳包异常。

       在网络状态监听器发现网络发生变化时，如果网络断开，此时网络库会重置同云平台和路由器长连接的状态；如果网络恢复连接，则网络库会尝试重新与云平台和路由器建立新的长连接，在同云平台和路由器建立新的长连接后，网络库将调用logincenter库的登陆逻辑，以自动登陆云平台和路由器，待登陆成功后，便将本地信息同步到云平台和路由器。

 

图2 网络库重构方案主流程

 

       图3描述了心跳检测机制，网络库每隔60s发送一次心跳检测包，然后将heartBeatFlag减1, heartBeatFlag初值为3, 当收到云平台/路由器的心跳响应时，网络库将 heartBeatFlag重新设置为3。如果网络库连发三个心跳包都没有收到云平台/路由器的心跳响应，那么网络库在准备发第四个心跳检测包前，会重置云平台/路由器的长连接状态（断开连接并发出长连接断开通知）。

图3心跳检测机制

3.3 网络库框架

   图3描述了网络库框架的架构设计。

   图3中粉色背景部分为本次网络库重构的新增（修改）部分，构建RemoteProxy（远程服务代理）类，

   RemoteProxy类的功能如下：

• 作为网络库与上层业务唯一的通信接口；管理TCP连接的建立、连接、维护、关闭；
• 自动接入Sec、LB、Biz服务器；
• 可自动路由业务TCP命令走云平台或路由器；
• 监听网络状态；
• 维持有效的同云平台、路由器的长连接。

   图3中黄色背景部分为工程代码间的相互移动部分，HdNetworkService原来位于主工程ControlPad中，由于其功能逻辑与网络库（心跳发送）密切相关，故本次重构会将其移动至网络库hdnetworklib中。

图3网络库框架

图4描述了网络库框架同其他库的关系。

   图4中的粉色部分为本次重构新增的部分，除前面介绍的网络库新增、修改、移动的代码部分，还包括将原网络库中DeviceManager、FamilyManager、RoomManager、UpgradeManager等与具体业务强相关的管理类移到ControlPad主工程。

   此外，将信息同步的代码逻辑从logincenter中抽取出来，形成独立的信息同步模块hdsync。

   从图4中可看出，重构后的网络库，可面向除XXXHome外不同的App。

 图4网络库框架同其他库的关系

 

   图5描述了重构前的网络库类结构及与其他库的关系。

   图5中用红色标示的类为归类存放不合理的类，在本次重构时需要调整其存放位置，以SyncTaskService和LoginStatusReceiver为例子，其原来的设计目的是为了监听用户登陆成功的消息后，便通知同步任务服务去做同步信息相关的事情，但现在SyncTaskService和LoginStatusReceiver存放在主工程ControlPad中，考虑到同步功能应独立出来作为一个模块，也便于今后对同步模块的需求做进一步扩展，故本次需对分散在ControlPad和hdlogincenter同步代码进行抽取，然后归集在hdsync模块。

图5 重构前网络库类结构及与其他库的关系

   图6 描述了重构后的网络库类结构及与其他库的关系。

   图6 黄色背景标识的类为本次重构新增的类，RemoteProxy为网络访问的唯一入口，RouteStrategy为选择云平台还是路由器通道的路由功能类，CloudRemote维护了一条云平台长连接和经由该长连接与云平台通信的逻辑、RouteRemote维护了一条路由器长连接和经由该长连接与路由器通信的逻辑。

图6重构后网络库类结构及与其他库的关系

   图7为图6的详细类图，描述了重构后网络库详细类图及与其他库的关系。

图7重构后网络库详细类图及与其他库的关系

   图8描述了在网络良好情况下，重构后的网络库发送Tcp请求的时序图。

   图9描述了在网络不好情况下，重构后的网络库发送Tcp请求的时序图。

 

 

图8重构后发送Tcp请求的时序图（网络良好）

图9重构后发送Tcp请求的时序图（网络不好）

 

3.4 后台服务接入流程改造（建议）

 

   目前网络库连接Sec、LB、BIZ服务器需要建立3次TCP连接，有以下缺点：

• 不安全

          将Sec服务器、LB服务器地址暴露在网络上，易遭到黑客攻击。

• 降低效率
• 影响用户体验

          使用户的等待时间加长，并产生更多的流量。

• 不利于后期运营维护

          Sec服务器、LB服务器域名发生变更，App必须重新发包。

   建议和云服务沟通，将模式修改为建立一个代理服务器，由代理服务器完成与Sec、LB服务器的通信，App只需访问代理服务器以获取BIZ地址并建立与BIZ的长连接，参见图10后台服务接入模式新旧方案对比。

图10 后台服务接入模式新旧方案对比

 

四、总结