留意架构图里的空白区域

作者：迈克尔·尼加德（MichaelNygard）

软件系统由相互依赖的程序组成，我们把装配这些程序的方法及程序之间的关系称为架构。绘制架构图时，一般用简单的矩形表示这些程序，用箭头表示程序之间的关系。

假设某个箭头代表了“使用HTTP协议，发送SOAP-XML格式的同步请求/响应消息”（Syncchronous request/reply using SOAP/XML over HTTP）。由于架构图的空间有限，写不下这么多内容，所以通常用简单的注释来表示。从技术角度出发，可以简写成“XML over HTTP”，如果从业务角度出发，有可能写成“查询库单无”（SKU Lookup）。

不同的程序看拟通过箭头直接联系，其实不然。矩形之间的空白区域“充满”了各种软件和“硬件”，比如：

• 网卡
• 网络交换机
• 防火墙
• 网络入侵检测系统（IDS）和入侵防御系统（IPS）
• 消息队列或消息中介
• XML转换引擎
• FTP服务器
• “临时上传区”分配表
• 域域同步光纤环路
• 多协议标记交换（MPLS）网关
• 网络干线（Trunklines）
• 海洋
• 可能破坏海底光缆的拖网捕鱼船

通常A程序和B程序之间至少隔着4～5台主机。这些主机上运行着各种软件，包括分组交换、流量分析、路由计算、威胁分析，等等。这些“隐藏在空白区域中的因素”是设计架构时必须考虑的。

我见过一个箭头的注释是“提供满意的服务（Fullfillment）”。箭头一端是客户公司的服务器，另一端是一台远程服务器。这个箭头代表的不是一个简单的接口，它承担着为客户提供满意服务的重任。它由一系列复杂的事件组成，包括将消息代理（message broker）接收到的消息转换成文件，周期性地通过FTP协议传输等，超过20个步骤。

应该理解每个箭头包含的静态信息和动态信息。除了“SOAP-XML over HTTP”这种的注释，还应该知道箭头包含的动态信息：“利用单个HTTP请求发送查询，利用单个HTTP响应接收回复。每秒钟最多发送100次请求。响应时间控制在250毫秒以内，成功率应该达到99.999%”。

除此以外，还有更多的细节考虑：

• 如果会话发起方的请求频率太高怎么处理？接收方可以忽略请求吗？还是应该“礼貌地”拒绝，或者尽可能地响应？
• 如果响应时间超过了250毫秒，会话发起方该怎么处理？是重新发送请求、继续等待，还是默认接收方出现了故障，跳过这个请求执行后续步骤？
• 如果会话发起方发送请求用的是1.0版的协议，收到的回复却是1.1版的，该怎么处理？如果收到的不是XML格式的文件，而是HTML格式的文件，甚至是MP3格式的文件，又该怎么处理？
• 万一会话双方中的一方暂时没有响应，该怎么处理？

只有想清楚了，才能顺利地解决空白区域里的问题。