留意架构图里的空白区域
2015-08-24 11:06
169 查看
作者:迈克尔·尼加德(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格式的文件,又该怎么处理?
万一会话双方中的一方暂时没有响应,该怎么处理?
只有想清楚了,才能顺利地解决空白区域里的问题。
软件系统由相互依赖的程序组成,我们把装配这些程序的方法及程序之间的关系称为架构。绘制架构图时,一般用简单的矩形表示这些程序,用箭头表示程序之间的关系。
假设某个箭头代表了“使用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格式的文件,又该怎么处理?
万一会话双方中的一方暂时没有响应,该怎么处理?
只有想清楚了,才能顺利地解决空白区域里的问题。
相关文章推荐
- 理解RESTful架构
- openstack cinder+drbd+nfs实现高可用存储【kilo版】
- 大型网站技术架构学习笔记
- 牛人网站汇总
- 60个国外免费3D模型下载网站
- 大型网站架构提速关键技术
- iOS项目架构
- js实现适用于素材网站的黑色多级菜单导航条效果
- 如何屏蔽防止别的网站嵌入框架代码
- 收藏的网站
- 一个IIS网站的异常配置的安全解决方案
- 如何屏蔽防止别的网站嵌入框架代码
- js实现适用于素材网站的黑色多级菜单导航条效果
- jQuery实现的类似淘宝网站搜索框样式代码分享
- perl如何使用lwp-rget对网站做镜像
- 电子工程师必上的十大专业网站
- 一个网站有很大的访问量,有什么办法来解决?
- 六种微服务架构的设计模式
- 我的架构师梦想日记
- 手机网站宽度自动适应手机屏幕