通过“分布式系统的8大谬误”反思APP的设计

作为移动端和网站开发者，有大量现成的网络开发代码可以使用在开发中直接使用。可惜的是没有一套代码可以代替我们全面考虑到网络的不可靠性，尤其是在移动端设备上。同时，幸运的是有些著名的结论以及一些著名的模式可以帮助我们思考如何优雅的处理现实世界中的现实问题。接下来让我们一起思考著名的“分布式系统的8大谬误”，以及我们该如何避免这些问题。

以下是著名的“分布式系统的8大谬误”
1， 网络是可靠的；
2， 网络不存在时延；
3， 网络带宽是无限的；
4， 网络是安全的；
5， 网络拓扑结构是不会变化的；
6， 只有一个管理员；
7， 网络传输是不需要任何代价；
8， 网络是同构的。

谬误1：网络是可靠的；
然而事实是：
1， 你的网络忽然在某个时间段无法工作了；
2， 设备可以连上网络，但就是请求不到数据；
3， 由于请求没有应答，设备不断发送重复数据；因此你的服务器会收到重复请求；
4， 设备或服务器收到脏数据或者部分数据；
5， 主机不可以用；

我们该如何处理？

－ 你的应用要将请求保存在队列中，并能自动重试发送请求。
通过使用Apple的Reachability类（或直接使用底层SCNetworkReachability接口），不断的异步获取设备的网络可用性；但也需要了解调用这个API的短处。首先，断掉的主机也许真的不可连接了，不需要多次尝试；另一方面，可连接的主机也可能连接失败，不在收到或应答请求。此外，设备需要一段时间才能建立起网络链接，以致你需要花费一段时间才能判断出网络连接是否可用。
我发现非常有必要将网络请求保存在队列中。当网络不可到达时，我可以将先将请求填充到队列中。或者在连接失败的时候，重新尝试连接。最后，当这些请求不再有效，或者看起来请求不会再有成功的可能性时，将这些请求从队列中删除。当然，管理这个队列的策略依赖app的业务需求以及请求的性质。比方说，如果某个请求的目的是为了同步数据的话，就不值得多次尝试。而一个保存用户数据到服务端的请求，就必须保证操作成功，甚至如果重启APP的话要重新创建该请求。

－服务器端能断开请求，并能考虑重复请求。
我的绝大多数应用的网络请求都建立在http或者类似http协议的基础至少，所以服务器必须考虑不可靠网络带来的问题。
当手机在不同的基站间切换，或人们带着手机穿过隧道，并且考虑手机周围都是高楼大厦的话，手机其实在不停的失去移动网络，然后尝试重新连接移动网络。Web Kit和NSURL工具类可以轻松搞定这些异常情况，只是服务器端就会面临，建立了很多长链接，只能等待超时机制断开这些链接。如果，其中的某些请求的链接巧合是占有重要的系统资源，那么服务器就无法在处理更多请求，即使带宽非常宽裕。
同时，APP端会自动重新发送这些没有成功回复的请求。其实有的时候服务器确确实实发送了回应，只是由于某种原因没有到达手机端，这个时候服务器会收到多个一摸一样的请求。如果服务器无法分辨这个是一个重新尝试的请求，还是某个用户确实进行了多次请求，那么会给我们系统带来大麻烦。解决的方法可以这样，在请求上加上序列号，时间戳或者某种标示。
当UIWebView在加载内容的时候，我会考虑在资源不可加载的情况下，先展示内容。我是该先加载内容，再加载图片或其他资源？还是说先显示进度条，直到页面全部加载完毕？

－优雅的处理时断时续的网络或断开链接的情况。
最后，在开发app时需要考虑在网络异常情况下如何展示页面。我断然不会每次网络出问题是就弹出一个对话框。而且我也绝对不会在一连串网络错误发生的时候弹出一连串的提示框。我会尽量告知用户APP正在处理请求，一旦发生问题，用户还能继续操作，直到请求完成。
实际操作中，手机不能简单获取或推送请求，而是要同步网络情况；当某个发送请求的视图被关闭了的情况下，还要能记录请求以及回应。当请求还在传输过程中时，不能阻碍用户的继续操作。

－测试：如何创建一个非可靠网络
开发和调试时，开发环境中的网络看起来一直都很可靠，当然现实不是如此。在进行手动测试或者进行bug复现时，我会使用Charles在本地wifi网络中模拟一个糟糕的网络环境。在代理中下断点，可以有选择的中断请求，随时中断网络连接。

英文原文在这里，明天继续翻译下一章节：http://blog.carbonfive.com/2010/11/17/fallacy-1-the-network-is-reliabl/