一、背景
网络管理层是各上层业务都要用到的层级，为提供更高效率、更高质量的服务，需对网络服务层进行重构。
二、重构目标
1、提供连接管理
在App整个运行过程中，始终向上层业务提供两条有效的长连接（云端连接和路由器连接），并支持在网络断开、心跳失败后的重连机制.
2、自动登陆(已实现)
在长连接重建后, 自动登陆服务器.
3、自动同步(已实现)
在长连接重建后、并自动登陆服务器后, 自动同步本地信息到云平台/路由器.
4、网络服务代理层RemoteProxy
RemoteProxy作为对上层业务的唯一网络接口, 向上层业务提供获取业务数据的网络访问接口, 使上层业务无需关心网络访问的细节, 其内部实现了连接管理等功能.
5、独立出同步功能
将同步功能从ControlPad和logincenter中抽取出来，作为独立的公共库hdsync。
三、重构方案
3.1
网络整体框架构思
图1为《智能家居APP架构说明》中描述的网络整体框架构思图，本方案基于此架构构思进行设计。
图1网络整体框架
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
3.2 网络框架工作流程
图2描述了网络库重构方案的原理主流程。
本次网络库重构，重点在于网络连接管理，网络连接管理主要处理两种场景：网络发生变化和心跳包异常。
在网络状态监听器发现网络发生变化时，如果网络断开，此时网络库会重置同云平台和路由器长连接的状态；如果网络恢复连接，则网络库会尝试重新与云平台和路由器建立新的长连接，在同云平台和路由器建立新的长连接后，网络库将调用logincenter库的登陆逻辑，以自动登陆云平台和路由器，待登陆成功后，便将本地信息同步到云平台和路由器。
h2 { direction: inherit; text-align: center }
h2.western { font-family: "Liberation Sans", sans-serif; font-size: 16pt }
h2.cjk { font-size: 16pt }
h2.ctl { font-size: 16pt }
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
h1 { margin-bottom: 0.21cm; direction: inherit; text-align: center }
h1.western { font-family: "Liberation Sans", sans-serif; font-size: 18pt }
h1.cjk { font-family: "宋体"; font-size: 18pt }
h1.ctl { font-family: "Noto Sans CJK SC Regular"; font-size: 18pt }
h2 { direction: inherit; text-align: center }
h2.western { font-family: "Liberation Sans", sans-serif; font-size: 16pt }
h2.cjk { font-size: 16pt }
h2.ctl { font-size: 16pt }
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
a:link { }
图2 网络库重构方案主流程
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图3描述了心跳检测机制，网络库每隔60s发送一次心跳检测包，然后将heartBeatFlag减1, heartBeatFlag初值为3, 当收到云平台/路由器的心跳响应时，网络库将 heartBeatFlag重新设置为3。如果网络库连发三个心跳包都没有收到云平台/路由器的心跳响应，那么网络库在准备发第四个心跳检测包前，会重置云平台/路由器的长连接状态（断开连接并发出长连接断开通知）。
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图3心跳检测机制
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
3.3 网络库框架
图3描述了网络库框架的架构设计。
图3中粉色背景部分为本次网络库重构的新增（修改）部分，构建RemoteProxy（远程服务代理）类，
RemoteProxy类的功能如下：
- 作为网络库与上层业务唯一的通信接口；管理TCP连接的建立、连接、维护、关闭；
- 自动接入Sec、LB、Biz服务器；
- 可自动路由业务TCP命令走云平台或路由器；
- 监听网络状态；
- 维持有效的同云平台、路由器的长连接。
图3中黄色背景部分为工程代码间的相互移动部分，HdNetworkService原来位于主工程ControlPad中，由于其功能逻辑与网络库（心跳发送）密切相关，故本次重构会将其移动至网络库hdnetworklib中。
h2 { direction: inherit; text-align: center }
h2.western { font-family: "Liberation Sans", sans-serif; font-size: 16pt }
h2.cjk { font-size: 16pt }
h2.ctl { font-size: 16pt }
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图3网络库框架
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图4描述了网络库框架同其他库的关系。
图4中的粉色部分为本次重构新增的部分，除前面介绍的网络库新增、修改、移动的代码部分，还包括将原网络库中DeviceManager、FamilyManager、RoomManager、UpgradeManager等与具体业务强相关的管理类移到ControlPad主工程。
此外，将信息同步的代码逻辑从logincenter中抽取出来，形成独立的信息同步模块hdsync。
从图4中可看出，重构后的网络库，可面向除XXXHome外不同的App。
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图4网络库框架同其他库的关系
图5描述了重构前的网络库类结构及与其他库的关系。
图5中用红色标示的类为归类存放不合理的类，在本次重构时需要调整其存放位置，以SyncTaskService和LoginStatusReceiver为例子，其原来的设计目的是为了监听用户登陆成功的消息后，便通知同步任务服务去做同步信息相关的事情，但现在SyncTaskService和LoginStatusReceiver存放在主工程ControlPad中，考虑到同步功能应独立出来作为一个模块，也便于今后对同步模块的需求做进一步扩展，故本次需对分散在ControlPad和hdlogincenter同步代码进行抽取，然后归集在hdsync模块。
图5 重构前网络库类结构及与其他库的关系
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图6 描述了重构后的网络库类结构及与其他库的关系。
图6 黄色背景标识的类为本次重构新增的类，RemoteProxy为网络访问的唯一入口，RouteStrategy为选择云平台还是路由器通道的路由功能类，CloudRemote维护了一条云平台长连接和经由该长连接与云平台通信的逻辑、RouteRemote维护了一条路由器长连接和经由该长连接与路由器通信的逻辑。
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图6重构后网络库类结构及与其他库的关系
图7为图6的详细类图，描述了重构后网络库详细类图及与其他库的关系。
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图7重构后网络库详细类图及与其他库的关系
图8描述了在网络良好情况下，重构后的网络库发送Tcp请求的时序图。
图9描述了在网络不好情况下，重构后的网络库发送Tcp请求的时序图。
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图8重构后发送Tcp请求的时序图（网络良好）
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
图9重构后发送Tcp请求的时序图（网络不好）
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
3.4 后台服务接入流程改造（建议）
h2 { direction: inherit; text-align: center }
h2.western { font-family: "Liberation Sans", sans-serif; font-size: 16pt }
h2.cjk { font-size: 16pt }
h2.ctl { font-size: 16pt }
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
目前网络库连接Sec、LB、BIZ服务器需要建立3次TCP连接，有以下缺点：
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
- 不安全
将Sec服务器、LB服务器地址暴露在网络上，易遭到黑客攻击。
- 降低效率
- 影响用户体验
使用户的等待时间加长，并产生更多的流量。
- 不利于后期运营维护
Sec服务器、LB服务器域名发生变更，App必须重新发包。
建议和云服务沟通，将模式修改为建立一个代理服务器，由代理服务器完成与Sec、LB服务器的通信，App只需访问代理服务器以获取BIZ地址并建立与BIZ的长连接，参见图10后台服务接入模式新旧方案对比。
图10 后台服务接入模式新旧方案对比
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
四、总结
h1 { margin-bottom: 0.21cm; direction: inherit; text-align: center }
h1.western { font-family: "Liberation Sans", sans-serif; font-size: 18pt }
h1.cjk { font-family: "宋体"; font-size: 18pt }
h1.ctl { font-family: "Noto Sans CJK SC Regular"; font-size: 18pt }
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
p { margin-bottom: 0.25cm; direction: inherit; line-height: 120%; text-align: center }
--
--> { }
原文地址：https://www.cnblogs.com/tgltt/p/9542709.html