如何发一条可靠的CGI请求

客户端业务搬砖狗的自我修养……

在日常开发中，和后台交互必不可少，比如Feeds流里的消息，需要更新、预加载等等，都需要找后台拉取信息。

那么，向后台发包，请求数据，并处理返回的数据。就是一次CGI请求。当然不同公司和团队，对此定义也不一样，不必纠结。

漫谈CGI请求的那些事

让一条CGI更加可靠，需要考虑的点很多。比如逻辑要放到合适的线程/进程中执行、并发访问兼容、多线程访问兼容、考虑监控耗时、考虑使用合适的存储、考虑用户操作、考虑请求限频、考虑节假日请求量激增问题，考虑在极端场景下，比如后台返回了错误的数据，对客户端的影响要降到最低。简言之，考虑的越周全越好。

作为业务狗，学会归纳与抽象化，对个人能力的提高极为重要，举个最简单的例子，工作一年，可能要写几十条CGI，但是，这些CGI的主流程基本都是一样的，只有归纳整理成通用流程以及方法论，才能轻松应对工作中各式各样的需求，才能切实提高自己的业务水平。

CGI请求常见考虑点

细化一下CGI流程中常见的考虑点。

1. 定义生命周期

一条CGI，或者是某个Action，总会有对应的生命周期。什么时候开始，什么时候结束，什么时候会被中断。想清楚这些，才能更好的管理请求。

2. 发起请求

1. 首先确定要在哪个线程/进程发起，比如子线程发起的话，就可以做一些比较耗时的操作。

2. 限定调用方线程/进程，或者要兼容调用方存在多线程调用的可能。

3. 发请求一定要做好限频，比如两次请求之间，要间隔多少分钟，在请求发起时判断是否满足限频条件，在请求发出后更新最新请求时间。

4. 通常，相同请求，要做好互斥，即上一条请求结束之前，不要发起新的请求。

5. 每一条异常return分支，要打印log方便后续查问题。

6. 发请求之前，根据业务场景增加判断当前网络的逻辑，比如无网络时不发起请求。

3. 请求回包。

1. 确认当前线程/进程，这决定着后续逻辑能否操作UI，能否执行耗时操作。

2. 检查对应的Request是不是自己发起的，只处理自己期望的回包。

3. 检查Response是否正常，错误码、返回数据是否完整。

4. 解析数据，注意空指针，注意后台异常数据，比如用户年龄，肯定不是负数。要做到和后台互不信任，互相检查，保证在后台返回了错误数据的情况下，客户端受到的影响尽量小。

5. 有时候后台会返回下一次请求的间隔时间，记得更新到本地。

6. 更新数据，要考虑耗时，灵活使用子线程。

7. 写DB要处理更新失败的回退、考虑是否需要使用事务。

8. 先更新DB，后更新UI，更新UI要切到主线程。

9. 处理好各种失败的逻辑，比如请求失败、更新DB失败。

10. 请求间隔、数据存储等等，要考虑影响范围，比如影响单个用户、所有用户等等。

11. 考虑在读写DB时，用户也在同时操作UI的情况，比如某个要更新的数据，可能在本次CGI回来之前，用户已经删除了。

统一的原则

根据不同业务，不同场景，需要考虑的问题也有一定的差别，当然，规划与思考是最重要的。考虑的越全面，越不容易被祭天。

当然，从另一个角度上说，这也是属于归纳与抽象化思维的一点应用。