服务设计模式-请求/确认模式

在上一篇文章中我们了解请求/响应模式的概念和适用场景：http://blog.csdn.net/lohocc/article/details/42743693

这一篇文章我们来对服务设计模式的请求/确认模式来做一个了解

Web服务如何保护系统，使其免受请求负载中峰值的影响；当底层系统不可用时，如何保证请求能够得到处理？

在设计web服务时，客户端与服务端的时间耦合度是一个关键的因素，当接收到请求就必须立马处理，这样的时间耦合度相对较高，这包括所有的应用程序必须正常运行（数据库，原有的web程序等等）。高时间耦合度还会造成系统因为峰值负载所带来的过度的资源消耗的系统级错误。

我们使用请求/确认模式来代替请求/响应模式,在这种模式下，服务端会执行以下几步操作：

1.接收请求

2.验证客户端证书（非必须）

3.授权客户端可以执行的请求操作（非必须）

4.校验请求（非必须）

5.生成请求标识符/URI

6.存储并转发消息

7.返回应答消息

我们来了解以下5-7的一个流程：客户端通过所有的校验后，服务会生成一个请求标识符或URI，这个是具有唯一性的键值，它可以供参与回话的各方在未来的交互中引用请求，创建后它（请求标识符/URI）就被附加到请求中，再议队列或数据表的方式转发到一个后台异步的进程，请求处理器会处理客户端的每一个请求，并把它转发到相应的队列中（等待进程去处理），在转发完成后（此时放到队列中的请求可能尚未处理），给客户端返回一个状态码/文档消息，文档消息在消息体某个地方包含了请求标识符。

请求/确认的实现方式：

（1）轮询：请求/确认/轮询作为请求/确认的一个变种，这种模式下要求客户端定期轮询另一个web服务，以获取更新信息或处理结果，但是这种情况客户端必须先从确认消息中取回一些轮询的先决信息（如请求标识符），如果客户端崩溃/断网等等，只要在这些情况发生前已经从确认的消息中提取出了轮询所需要的信息，并保存好，那么在重新启动/联网后，也能取回服务端处理的最终结果。

请求/确认/轮询的频率如果不够高，则会导致客户端数据更新不够及时，如果过高，又会导致服务端产生过度的负担，产生大量的网络流量。

（2）回调和转发：与轮询模式类似，只是这里不会让客户端进行轮询来获取处理结果，而是请求处理器将结果信息推送回客户端或转发给其他参与者，后面这种属于转发模式，在进行回调时，服务端与客户端角色互换，即原来发送请求的客户端必须提供一个回调服务来接受服务端的回调。

回调模式下如果单一请求会产生多个更新，一个请求要发送给多个回调服务，如果请求结果需要多种格式化，那么需要的系统资源将会高出原先的很多。

（3）发布/订阅模式：发布/订阅是一种经典的设计模式，在这种模式下，一个消息发送者（发布者）先将消息传输给一个中介，对消息感兴趣的各方（订阅者）可以从这个中介接收消息，同时有保证他们会彼此独立，不会感知到其他各方的存在。

请求/确认/轮询和请求/确认/转发是两种实现这种模式的方法。前面这种方法中，服务只负责接收消息，由服务来把处理的结果持久化（存入数据库或文件系统中），订阅者通过另一个服务把处理的结果取回来。后一种服务负责接收消息的发布者，再将消息推送到订阅者。