大家经常遇到加载一个页面，结果向服务器发送两个或以上的请求情况（一个点击查询操作也可能触发向服务器多次请求），让服务器合并成一个请求，服务开发说他属于不同的业务等推词，总之不想给你合并成一个请求。首先咱们先了解他的弊端，再说他的解决方案。
客户端做多请求的弊端：
1.数据安全：服务器和客户端的网络是不稳定的网络，建立tcp通道慢，网络信号差时容易请求失败，udp消息可能丢失（微信，qq的消息就是udp消息）。而服务器和数据库服务或具体业务服务器之间是局域网，socket通道建立很快，基本上不会以为网络问题而请求失败（当然你的数据库表有问题导致操作超时和网络无关），udp消息不会丢失（概率极小，可以忽略）。
2.时间：服务器和客户端的网络是不稳定的网络，建立tcp通道慢，而服务器和数据库服务或具体业务服务器之间是局域网，socket通道建立很快，而且一个处理多次请求，网络不好时需要多次建立tcp通道（大家都知道http的大部分时间都花费在建立http通道上，其次才是服务器查询数据库表的时间），显然一个处理的时间成倍增长。而由于服务（网关）和数据库服务器，业务服务器之间是局域网络，根据服务化的要求，他们都有长连接存在，所以就剩去了建立多次tcp通道的时间。现在知道了app向服务器连续发送多个请求和app向服务器发送一个请求而服务向各个业务服务器发送同等数量的请求所用的时间相差好几倍。
3.流量：http会带消息头，每次发送请求都带消息头，这是费流量的。通常各个请求都有可能带无用字段（当然就是服务器合并了请求没有优化服务器返回的字段也是有多余字段返回。以前我们的一个订单达到1450字节，根据http报文协议，肯定分两组报文发送，可见冗余字段占有多大的流量）。
4.耗电量：以前我统计影响过手机的各种因素，频繁发送http是极耗电的。
5.bug:app发送多次请求很容易出现各种异常，一部分成功，一部分失败很正常，情况很复杂，很容易产生bug。当然通过信号压缩zipWith能减少这些bug，但是前面4方面的影响是避免不了的。
解决方案有以下几种：
1.服务器给你把一个处理的多个请求合并成一个请求（业务无关），你向服务器发送一个请求，服务器向不同业务服务器发送请求，等所有的业务请求都回来后，服务器合并成一个请求给你。通常原来的分请求在其他地方也有使用，所以通常也保留各个分请求，就是服务给你提供一个合并后的接口。必定这样的处理是少数的。
2.若服务器过于复杂，不只对你一个app服务，还为多个网页服务，多个app服务，服务器开发人员不想给你合并请求。可以通过服务器人员开发出来一个聚合层网关，多所有的请求进行编号，每次发送合并请求是发送请求编号和对应参数，请求编号可以为多个。服务器通过请求编号，解析对应的参数，向业务服务器发送请求。
3.服务器不配合，不给你合并请求接口，也没有聚合层，那么app只能通过app自己处理了。可以通过RACSignal的zipWith压缩信号来达到多个请求都成功合并成一个消息后出发组合消息。当然这种方法，前四个缺点都存在。（当然你没有引入ReactiveCocoa这个第三方库也没有办法使用）。
发送信号 交互顺序，元组内元素的顺序不会变，跟发送的顺序无关，而是跟压缩的顺序有关[signalA zipWith:signalB]—先是A后是B。具体参照文章：http://blog.csdn.net/jia12216/article/details/55520151。
4.定义几个变量，每一个消息成功把它返回的数据都先存起来，设置成功标志，判断是不是所有的消息都设置了成功标志。这种方法，所有缺点都存在。