第34章
作者:林锐 更新:2021-12-03 17:33
如果13亿中国人民每个人都要用特别的方式构造奇异的房子,那么960万平方公里的土地将会变得千疮百孔,终日不得安宁。
(2)体系结构在一定的时间内保持稳定。只有在稳定的环境下,人们才能干点事情,社会才能发展。科学告诉我们,宇宙间万物无时无刻不在运动、飞行。由于我们的生活环境在地球上保持相对稳定,以致于我们可以无忧无虑地吃饭和睡觉,压根就意识不到自己是活生生的导弹。软件开发最怕的就是需求变化,但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时,最好只对软件做些皮皮毛毛的修改,可千万别改动软件的体系结构。就如人们对住宿的需求也会变动,你可以经常改变房间的装璜和摆设,但不会在每次变动时都要去折墙、拆柱、挖地基。如果当需求发生变化时,程序员不得不去修改软件的体系结构,那么这个软件的系统设计是失败的。
良好的体系结构意味着普适、高效和稳定。本节将论述两种非常通用的软件体系结构:层次结构和客户机/服务器(Client/Server)结构。
5.1.1 层次结构
层次结构表达了这么一种常识:有些事情比较复杂,我们没法一口气干完,就把事情分为好几层,一层一层地去做。高层的工作总是建立在低层的工作之上。层次关系主要有两种:上下级关系和顺序相邻关系。
一、上下级关系的层次结构
我们从小学一直读到博士研究生毕业,要读20多年,可以分为五个层次。而范进的知识结构只有两层:“私塾”和“秀才”,但读了五十多年,如图5.1所示。一般地处于较高层次的学生应该懂得所有低层次的知识,而处于低层次学生无法懂得所有高层次的知识。图5.1的层次结构存在上下级关系,如同在军队中,上级可以命令下级,而下级不能命令上级。如果把图5.1的层次结构当成是一个软件系统的结构,那么上层子系统可以使用下层子系统的功能,而下层子系统不能够使用上层子系统的功能。
二、顺序相邻关系的层次结构
顺序相邻关系的层次结构表明通讯只能在相邻两层之间发生,信息只能被一层一层地顺序传递。这种层次结构的经典之作是计算机网络的OSI参考模型,如图5.2所示。为了减少设计的复杂性,大多数网络都按层(Layer)或级(Level)的方式组织。每一层的目的都是向它的上一层提供一定的服务,而把如何实现这一服务的细节对上一层加以屏蔽。一台机器上的第n层与另一台机器上的第n层进行对话。通话的规则就是第n层的协议。数据不是从一台机器的第n层直接传送到另一台机器的第n层。发送方把数据和控制信息逐层向下传递。最低层是物理介质,它进行实际的通讯。接收方则将数据和控制信息逐层向上传递。
每一对相邻层之间都有接口。接口定义了下层提供的原语操作和服务。当网络设计者在决定一个网络应包含多少层,每一层应当做什么的时候,其中很重要的工作是在相邻层之间定义清晰的接口。接口可以使得同一层能轻易地用某一种实现(Implementation)来替换另一种完全不同的实现(如用卫星信道来代替所有的电话线),只要新的实现能向上层提供同一组服务就可以了。[Tanenbaum 1998]
考上“举人”时已五十多岁了
复习报考“举人”用了几十年
图5.1(a)从小学读到博士存在的五个学习阶段 图5.1(b)范进的知识结构
图5.2 计算机网络的OSI参考模型
三、其它的层次结构
目前在大型商业应用软件系统中还流行一种包含中间件(Middleware)的层次结构,如图5.3所示[Jacobson 1997]。中间件支持与平台无关的分布式计算,可以用DCOM和CORBA对象来实现。
图5.3 包含中间件的层次结构
5.1.2 客户机/服务器结构
让我们先回顾一下早期的电话系统。贝尔(Alexander Graham Bell)于1876年申请了电话专利。那时期的电话必须一对一对地卖,用户自己在两个电话之间拉一根线。如果一个电话用户想和其它几个电话用户通话,他必须拉n根单独的线到每个人的房子里。于是在很短的时间内,城市里到处都是穿过房屋和树木的混乱的电话线。很明显,企图把所有的电话完全互联(如图5.4(a)所示)是行不通的。
贝尔电话公司在1878年开办了第一个交换局。公司为每个客户架设一条线。打电话时,客户摇动电话的曲柄使电话公司办公室的铃响起来,操作员听到铃声以后根据要求将呼叫方和被呼叫方用跳线手工连接起来。这种集中交换式的模型如图5.4(b)所示。很快地,贝尔系统的交换局就出现在各地。人们又要求能打城市间的长途电话,就出现了二级交换局,以后进一步发展为多个二级交换局。[Tanenbaum 1998]
5.4(a)完全互联的电话系统 5.4(b)集中交换式的电话系统
如果将图5.4(b)中的电话看成是客户程序,将中心的交换局看成是服务程序,那么图5.4(b)就是典型的客户机/服务器结构。注意这里客户机和服务器都是指软件而不是指硬件(一台计算机可以放多个客户机和服务器软件)。
客户机/服务器结构存在两个显然的优点:
(1)以集中的方式高效率地管理通讯。前面讲电话系统的故事就是要说明这一点。
(2)可以共享资源。比如在信息管理系统中,服务器将信息集中起来,任何客户机都可以通过访问服务器而获得所需的信息。
客户机和服务器之间的通讯以“请求——响应”的方式进行。客户机先向服务器发起“请求”(Request),服务器再响应(Response)这个请求,如图5.5所示。
请求
响应
图5.5 Client和Server之间的通讯以“请求——响应”的方式进行
采用“请求——响应”这种通讯方式的基本动机是为了解决“聚集”(Rendezvous)问题。为了理解这一个问题,设想一个人试图在分离的机器上启动两个程序并让它们进行通讯。还需记住,计算机的运行速度要比人的操作速度高出许多数量级。在他启动第一个程序后,该程序开始执行并向对等程序发送消息。在几个微秒内,它便发现对等程序还不存在,于是就发出一条错误消息,然后退出。此后,他启动了第二个程序。不幸的是,当第二个程序开始执行时,它也找不到第一个程序(早已退出)。即使这两个程序连续地重新试着通讯,但由于它们的执行速度那么高,以致于它们在同一瞬间联系上的概率非常低。在客户机/服务器结构中,服务器在启动后必须(无限期地)等待客户机的“请求”,因此就形成了“请求——响应”的通讯方式。
在Internet/Intranet领域,目前“浏览器—Web 服务器—数据库服务器” 结构是一种非常流行的客户机/服务器结构,如图5.6所示。这种结构最大的优点是:客户机统一采用浏览器,这不仅让用户使用方便,而且使得客户机端不存在维护的问题。当然,软件开发布和维护的工作不是自动消失了,而是转移到了Web 服务器端。在Web 服务器端,程序员要用脚本语言编写响应页面。例如用Microsoft的ASP语言查询数据库服务器,将结果保存在Web 页面中,再由浏览器显示出来。
HTTP 请求
查询
HTTP 响应
图5.6 “浏览器—Web 服务器—数据库服务器”结构
5.2 模 块 设 计
在设计好软件的体系结构后,就已经在宏观上明确了各个模块应具有什么功能,应放在体系结构的哪个位置。我们习惯地从功能上划分模块,保持“功能独立”是模块化设计的基本原则。因为,“功能独立”的模块可以降低开发、测试、维护等阶段的代价。但是“功能独立”并不意味着模块之间保持绝对的孤立。一个系统要完成某项任务,需要各个模块相互配合才能实现,此时模块之间就要进行信息交流。
(2)体系结构在一定的时间内保持稳定。只有在稳定的环境下,人们才能干点事情,社会才能发展。科学告诉我们,宇宙间万物无时无刻不在运动、飞行。由于我们的生活环境在地球上保持相对稳定,以致于我们可以无忧无虑地吃饭和睡觉,压根就意识不到自己是活生生的导弹。软件开发最怕的就是需求变化,但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时,最好只对软件做些皮皮毛毛的修改,可千万别改动软件的体系结构。就如人们对住宿的需求也会变动,你可以经常改变房间的装璜和摆设,但不会在每次变动时都要去折墙、拆柱、挖地基。如果当需求发生变化时,程序员不得不去修改软件的体系结构,那么这个软件的系统设计是失败的。
良好的体系结构意味着普适、高效和稳定。本节将论述两种非常通用的软件体系结构:层次结构和客户机/服务器(Client/Server)结构。
5.1.1 层次结构
层次结构表达了这么一种常识:有些事情比较复杂,我们没法一口气干完,就把事情分为好几层,一层一层地去做。高层的工作总是建立在低层的工作之上。层次关系主要有两种:上下级关系和顺序相邻关系。
一、上下级关系的层次结构
我们从小学一直读到博士研究生毕业,要读20多年,可以分为五个层次。而范进的知识结构只有两层:“私塾”和“秀才”,但读了五十多年,如图5.1所示。一般地处于较高层次的学生应该懂得所有低层次的知识,而处于低层次学生无法懂得所有高层次的知识。图5.1的层次结构存在上下级关系,如同在军队中,上级可以命令下级,而下级不能命令上级。如果把图5.1的层次结构当成是一个软件系统的结构,那么上层子系统可以使用下层子系统的功能,而下层子系统不能够使用上层子系统的功能。
二、顺序相邻关系的层次结构
顺序相邻关系的层次结构表明通讯只能在相邻两层之间发生,信息只能被一层一层地顺序传递。这种层次结构的经典之作是计算机网络的OSI参考模型,如图5.2所示。为了减少设计的复杂性,大多数网络都按层(Layer)或级(Level)的方式组织。每一层的目的都是向它的上一层提供一定的服务,而把如何实现这一服务的细节对上一层加以屏蔽。一台机器上的第n层与另一台机器上的第n层进行对话。通话的规则就是第n层的协议。数据不是从一台机器的第n层直接传送到另一台机器的第n层。发送方把数据和控制信息逐层向下传递。最低层是物理介质,它进行实际的通讯。接收方则将数据和控制信息逐层向上传递。
每一对相邻层之间都有接口。接口定义了下层提供的原语操作和服务。当网络设计者在决定一个网络应包含多少层,每一层应当做什么的时候,其中很重要的工作是在相邻层之间定义清晰的接口。接口可以使得同一层能轻易地用某一种实现(Implementation)来替换另一种完全不同的实现(如用卫星信道来代替所有的电话线),只要新的实现能向上层提供同一组服务就可以了。[Tanenbaum 1998]
考上“举人”时已五十多岁了
复习报考“举人”用了几十年
图5.1(a)从小学读到博士存在的五个学习阶段 图5.1(b)范进的知识结构
图5.2 计算机网络的OSI参考模型
三、其它的层次结构
目前在大型商业应用软件系统中还流行一种包含中间件(Middleware)的层次结构,如图5.3所示[Jacobson 1997]。中间件支持与平台无关的分布式计算,可以用DCOM和CORBA对象来实现。
图5.3 包含中间件的层次结构
5.1.2 客户机/服务器结构
让我们先回顾一下早期的电话系统。贝尔(Alexander Graham Bell)于1876年申请了电话专利。那时期的电话必须一对一对地卖,用户自己在两个电话之间拉一根线。如果一个电话用户想和其它几个电话用户通话,他必须拉n根单独的线到每个人的房子里。于是在很短的时间内,城市里到处都是穿过房屋和树木的混乱的电话线。很明显,企图把所有的电话完全互联(如图5.4(a)所示)是行不通的。
贝尔电话公司在1878年开办了第一个交换局。公司为每个客户架设一条线。打电话时,客户摇动电话的曲柄使电话公司办公室的铃响起来,操作员听到铃声以后根据要求将呼叫方和被呼叫方用跳线手工连接起来。这种集中交换式的模型如图5.4(b)所示。很快地,贝尔系统的交换局就出现在各地。人们又要求能打城市间的长途电话,就出现了二级交换局,以后进一步发展为多个二级交换局。[Tanenbaum 1998]
5.4(a)完全互联的电话系统 5.4(b)集中交换式的电话系统
如果将图5.4(b)中的电话看成是客户程序,将中心的交换局看成是服务程序,那么图5.4(b)就是典型的客户机/服务器结构。注意这里客户机和服务器都是指软件而不是指硬件(一台计算机可以放多个客户机和服务器软件)。
客户机/服务器结构存在两个显然的优点:
(1)以集中的方式高效率地管理通讯。前面讲电话系统的故事就是要说明这一点。
(2)可以共享资源。比如在信息管理系统中,服务器将信息集中起来,任何客户机都可以通过访问服务器而获得所需的信息。
客户机和服务器之间的通讯以“请求——响应”的方式进行。客户机先向服务器发起“请求”(Request),服务器再响应(Response)这个请求,如图5.5所示。
请求
响应
图5.5 Client和Server之间的通讯以“请求——响应”的方式进行
采用“请求——响应”这种通讯方式的基本动机是为了解决“聚集”(Rendezvous)问题。为了理解这一个问题,设想一个人试图在分离的机器上启动两个程序并让它们进行通讯。还需记住,计算机的运行速度要比人的操作速度高出许多数量级。在他启动第一个程序后,该程序开始执行并向对等程序发送消息。在几个微秒内,它便发现对等程序还不存在,于是就发出一条错误消息,然后退出。此后,他启动了第二个程序。不幸的是,当第二个程序开始执行时,它也找不到第一个程序(早已退出)。即使这两个程序连续地重新试着通讯,但由于它们的执行速度那么高,以致于它们在同一瞬间联系上的概率非常低。在客户机/服务器结构中,服务器在启动后必须(无限期地)等待客户机的“请求”,因此就形成了“请求——响应”的通讯方式。
在Internet/Intranet领域,目前“浏览器—Web 服务器—数据库服务器” 结构是一种非常流行的客户机/服务器结构,如图5.6所示。这种结构最大的优点是:客户机统一采用浏览器,这不仅让用户使用方便,而且使得客户机端不存在维护的问题。当然,软件开发布和维护的工作不是自动消失了,而是转移到了Web 服务器端。在Web 服务器端,程序员要用脚本语言编写响应页面。例如用Microsoft的ASP语言查询数据库服务器,将结果保存在Web 页面中,再由浏览器显示出来。
HTTP 请求
查询
HTTP 响应
图5.6 “浏览器—Web 服务器—数据库服务器”结构
5.2 模 块 设 计
在设计好软件的体系结构后,就已经在宏观上明确了各个模块应具有什么功能,应放在体系结构的哪个位置。我们习惯地从功能上划分模块,保持“功能独立”是模块化设计的基本原则。因为,“功能独立”的模块可以降低开发、测试、维护等阶段的代价。但是“功能独立”并不意味着模块之间保持绝对的孤立。一个系统要完成某项任务,需要各个模块相互配合才能实现,此时模块之间就要进行信息交流。
作品本身仅代表作者本人的观点,与本站立场无关。如因而由此导致任何法律问题或后果,本站均不负任何责任。