网络架构设计

引言

一般情况下，我们设计的网络架构面向过程设计，那么设计的方案大多数会出现下面的现象：

• 1.耦合，主要包括缓存、网络状态监听、请求头设置、请求设置、参数处理、请求结果模型解析、成功和失败的回调处理等；
• 2.糅合了业务，比如登录状态，cookie设置、参数业务处理；
• 3.灵活性低，更改初始化设置非常麻烦；
• 4.批量处理或者同步处理存在另外设计；
• 5.扩展性不强，比如希望在请求接口上做缓存或者签名，也杂糅在设计的网络架构里面；

那么具体该怎么设计呢，这里是个人见解，不喜勿喷：

1.划分层次，自顶向下，应该是业务处理并发起请求-->场景请求方式处理(批量请求或者同步控制或者不同方式请求等)-->调用底层发起请求-->底层请求结果传递-->场景请求结果处理(动态模型封装或异常error传递)-->业务类获取请求结果对应业务操作，一般大体是这样的流程。

2.划分设计的层次结构，根据上述情况，业务类应该是最外层，属于不可公用部分，应该由不同的项目自身去扩展设计，只需要里面调用同样组件处理即可，这里我们需要考虑的一个是场景设计类，一个底层调用类，后续的组件也主要是以底层设计为主，场景为扩展区间。
底层设计属于可替换组件，只做网络请求，具体做哪方面的请求，这里并不需要知道，优点是我们可以更换不同的网络库，而不影响本身业务实现(这里考虑的是网络库的更新换代)。
场景设计只是对请求的进一步扩展，增添更多的功能来适应我们业务的需要，但是注意，它不关注具体业务是什么，只做对业务需求的兼容性，就如同网络请求提供了了get/post/put/head/delete等场景，但是具体调用哪一种，是业务本身来决定。

3.设计方式，从项目来看，整个网络请求设计了3层，现在要做的是如何设计这3层之间的数据传递，数据传递要做到解耦，那么我们去考虑的必然是面向对象设计，即在网络请求流向里流转的必然是一个对象。
这里又存在一个问题：这个对象应该包含哪些东西？
根据我的理解，该对象应该实现问题1里面的各个特性，包括：是否需要缓存、是否做网络监听处理、请求头和参数怎么设置、结果模型是什么样的、超时时间等，成功和失败可以用于参数传递，这里可以不参与对象构造。
下面又有一个问题：不同的项目去构造该对象模型怎么知道需要哪些东西？或者扩展了对象范围如何不影响原有结构？
这里就需要用到协议，除了必须的URL、参数等必须的外，加入的扩展协议方法都是可选，并且需要一直提供一个extra另外参数用于扩展
同理，返回的响应模型也是一个对象，也有对应的协议。
好处是：

• 1.项目根据自己的业务需要去实现对应的协议，构造对象；
• 2.提供扩展和维护，用于升级；
• 3.对象可以携带更多的信息。

4.场景设计这里忽略，底层设计里面，要将问所说的缓存、网络状态监听等独立出来，可以通过观察订阅模式或者中介者模式来获取对应信息，通过流转的对象项目配置信息来处理，我们需要在底层将可能出现的情况预先设计埋点。