Reddit之训 – 关于的网站建设和架构好译文

Reddit之训: 月浏览量从100万到10亿的陷阱

  • 一篇很好的网站建设和架构的翻译文章。

 

Reddit网站 网站运营 社交网站运营 网站盈利

Jeremy Edberg,reddit正式聘用的第一位员工,在RAMP大会上做了一个极其精彩的演讲《Scaling Reddit from 1 Million to 1 Billion–Pitfalls and Lessons》,传授了许多如何创建一个成功社交网站的经验。

jeremy借用了褒贬参杂的方式来总结经验教训,他分享了在推广Reddit过程中所犯的比比错误,但也让我们看到他们做出的正确抉择。不过有点令人吃惊的是,jeremy现在是Netflix的可靠性架构师。所以从他的演讲中也可感受Netflix的一些观点。

令我印象深刻的几个教训是:

SSD看做是便宜的内存(RAM),而不是昂贵的硬盘。

reddit因为数据库的缘故从机械型硬盘升级到固态硬盘(SSD)后,其服务器数量从12台降为1台,且还有极大的空间富余。SSD虽比机械式硬盘贵了四倍,但是你会得到16倍的性能提升,真是物有所值。

给用户一点点权力,看看他们怎么做,然后把其中的好点子变为网站的功能。

reddit从用户那里所学极为丰富,且其网站的流畅运作很大程度上倚赖其用户,这是我获得的最大收获。用户会告诉你很多你不知道的事情,reddit gold就是个很好的例子,刚开始它只是社区里大家开的玩笑,reddit将其兑现为产品,并深得用户喜爱。

项目开始时就建设一个可扩展性架构是不必要的。

开始时你并不会知道网站将来的功能集,所以你也不会知道你有哪些扩展方面的问题。等到你的网站开始壮大时,你自然就可以了解网站会在哪些方面有扩展问题。

把未登录用户当作二等公民。

通过总是给未登录用户返回缓存内容的做法,reddit将包袱扔给了Akamai而自身的流量畅通,这种做法使其网站性能大大提升。

Jeremy的分享远不止于此。从reddit扩展初期的错误中我们能学到的经验教训良多,这里是我对Jeremy演讲的一些释读:

统计数据

访问流量大约每15个月翻一番。

上个月,来自177个不同国家的 67,328,706名独立访客浏览了reddit网站上 4,692,494,641个页面。这个演讲是在reddit的第10亿页面浏览节点完成时进行的,其目前架构与之前架构的差异无法确认。

28名雇员。

每名雇员应对大约240万独立访客。(链接)

数以千计的志愿者版主。

在2012年时,他们用240台服务器来支撑每月20亿的页面浏览量和Postgres里的2TB数据。所有高访问率数据都从EBS转移到本地临时磁盘(以保证网站运行流畅)。

公司源起

Reddit始于2005年。创始人首先带着“通过短信点餐”的点子去寻求Y Combinator的资金支持但被拒绝,他们回头和Paul Graham(Y Combinator的创始人,美国著名程序员、风险投资家、博客和技术作家)讨论并产生了开发互联网网页建设的点子,即reddit。那时他们并不知道掘客(Digg)的存在。

从数据中心开始,随后逐渐将功能转移至亚马逊弹性计算云(EC2)。

2006年,开始通过EC2使用S3提供存储和服务标志。

2007年,开始使用S3支持缩略图服务。

2008年,以vpn通道连接数据中心的方式在EC2上进行批处理。

2009年,整站使用EC2服务。网站停运整整一天,将数据全部迁移到EC2。这是《数据引力》的重大案例,随后还会谈到。

EC2

迁移到EC2的原因

不断堆叠机柜并不有趣。不想租用更多的机柜,买更多的服务器。

建立数据中心,早期数据的增长是无法预测的。

对于一个4人小组而言,成本相对降低了。亚马逊的EC2比他们在San Francisco的数据中心价格便宜了29%。

EC2不是万能的。如果你受够了高网络延迟和邻居发出的噪音,考虑下迁移到EC2上。一个好处是网站可以自由的壮大。

熟悉EC2上的资源限制

所有的资源对每个帐号都有限制。

亚马逊也不清楚其中的一些限制是什么。

跟踪限制,在你需要的时候扩大限制范围。

捕获异常以发现何时临界条件被触发。

架构

Reddit的架构是很直观的。**用户连接到一个可以与应用纽带直接通话的网络纽带。这个应用纽带又与memcache, Cassandra, 还有 Postgres通话,Postgres使用的是一个主从关系网络。这是一个使用Cassandra 和 Postgres的批处理系统。

相比较而言,Netfli使用的是一个服务型的架构,各部分通过REST API相互之间通话。

优点:方便自适应规模,因为只有服务器需要调整规模;更容易规划容量;错误更容易找出,因为他们在REST框架里是独立的;变化效果十分精确;本地缓存更加高效。

缺点:需要多个Dev或者Dev团队在多个服务器上工作,所以人工成本增加;需要一个公共开发平台避免重复工作;对于一个小团队来说,管理成本很大。

Postgres是一个非常优秀的数据库**他可以创造出十分优秀,快速键值储存的数据库。

邮件系统是一个大问题** 信息传送很难弄好,开始的时候可以用他们自带的邮件系统,但是现在可能要用专门邮件系统提供商的服务了。

队列是救世主** 在组件至今传递任务的时候,放入一个队列里。你将会得到一个短小精悍的缓冲器。(Reddit用的是[RabbitMQ](http://www.rabbitmq.com/))

混用HAProxy和Nginx** 有些阻塞是相互的。对于负载均衡尝试Nginx无效之后可以试试HAProxy(在负载均衡崩溃的时候)。他对于L7负载均衡很有用,Nginx仍然可以用来终止SSL和服务静态内容。

代码

框架。 使用Pylons (Django太慢了),它就是一个基于Python的框架。从一开始,它就很容易上手。由于不匹配你的用例,最终它们总会出问题。Pylon最终做出了很多改变,(原来)它升级到新版本是很困难的(现在已经修复这个问题)。(现在)可以使用Pyramid (Pylons的新名字)。

基于线程的事件? 基于线程可以提前依大小排列,但是排列可能是错误的。基于事件可以处理更多的连接而不必在遇到瓶颈时继续陷在瓶颈中。你希望花更多的时间去规划线程池的尺寸或处理突然遭遇到的瓶颈吗?

开源有益。 Reddit是在开源代码上构建的。 不需要付费的软件不错,尤其是在开始的时候。

数据

数据将是你的公司最重要的资产Facebook, Google和Flickr这样的公司的根本就是数据。

沉重的数据。当你把数据放在一个地方,你就需要在这个地方放置你的应用。所有的应用都是围绕数据进行的。数据形成了一个引力中心,其他东西都要向它靠近,因为数据最难移动,而且数据量越大越难移动。目前,把数据移出EC2非常的贵。这就是 EC2 存储数据免费,迁移数据收费的原因。他们想要你把所有的数据都存放在云服务器上。

关系型 VS 非关系型。reddit 的大部分数据都是键值对,存储在Postgres数据库中。所有涉及到金钱的数据存储在关系型的数据库中,因为可以使用事务和简便地分析。

Postgres 是防弹的。它像岩石一样坚硬,它自己从未出过问题。即使有问题,也是其他它周边系统的问题,比如使用Python编写的复制系统。很难找到熟悉Postgres的专家(因为它不需要专家解决奇怪的问题)。

键值存储选择了Postgres而不是Cassandra是因为Cassandra当时并不存在,而且Postgres速度非常快,还已经原生支持键值。

分库分表。写操作被拆分到四个主数据库中:连接、帐户、子自动、评论、投票、其它。

每一个主数据库都有从数据库。投票数据库只有一个主库和一个从库。评论数据库有一个主库和十二个从库。

如果可以,尽量避免直接从主库读取数据,从从库读取数据以使主库专用于写入数据。

客户端代码负责从库间负载均衡。如果一个从库响应较慢,访问另一个从库。

实现了一个数据访问层,名称为thing。

这种方法已经使用了很长时间。混合使用数据库分库分表,主从读写分离,跟踪数据读取性能保持负载均衡。

Cassandra

快速写入,快速负查询,简单高可扩展性,无单点故障问题

在 Netflix(美国一家视频网站),数据分散地存储在三个不同的区域。每一个区域都有全部区域的数据。即使一个区域的数据丢失了,网站仍然可以正常运行。

把投票数据转换后存入Cassandra 是 reddit 一次巨大的进步。Cassandra 的 bloom 过滤器显著地提高了负查询的效率。比如它可以很快查询出你没有投票过的意见,因此负查询的结果显示很快。

社会

在2008年,reddit开源了

用户可以阅读代码,从而知道没有人破坏投票结果

用户可以增加他们早就想增加的功能,reddit会提供运行平台。开起来,用户并不是不想写代码。

招聘。别人会了解代码,所以更容易招聘。推销自己的想法来更好地合作

蠕虫事故。 有人指出了如何在一个网页中注入多余的javascript代码来写一个蠕虫的方法。这个方法并没有打算被泄露出去,但是最终还是泄露了。在那一天,创始人之一正在结婚,整个团队都在从婚礼返回的飞机上。但是,一个用户已经快速响应,提交了一个阻止蠕虫传播的补丁。开源可以使得在危机时刻社区可以提供帮助。

reddit怎么赚钱?

侧边条广告,自助广告,推销,reddit币,市场。

注意,reddit还没有实现盈利。这带来一个问题,像reddit这样的云端站点能否实现盈利?

另外,reddit现在不再属于Condé Nast,它是独立的 。

错误

没有考虑迁移到EC2之后增加的延迟。 在数据中心,机器之间的访问时间都是亚毫秒级,所以加载一页可以调用1000次memcache。但是在EC2,情况发生了变化, Memcache的访问时间增加了十倍,导致原来的方法行不通了。解决方案是批量调用memcache,这样一次请求可以得到大量的结果。

过于相信承诺。 Amazon并不总是按照承诺交付,所以有时要圆滑一些处理。设计的时候就要考虑错误,而不是试图修复错误。(这里没有参考文献,也许EBS是个例子?)

在生产环境中使用最新的产品。当Cassandra还处于开发周期的早期的时候,我们就开始使用它了。它现在很棒,但是当时有很多问题。

早就应该把更多的工作量迁移到client端。 服务器端做了很多页面渲染的工作,但是这些工作应该被推到客户端。Facebook是这方面的大师。你会得到一个矩形,和很多空的div,然后通过API调用来填满这些div。这就是他们早就希望reddit可以做的事情。这可以让我们的规模更快地增长。而且这也对调试有好处,因为我们很容易知道哪个API出了问题。

没有足够的监控,而且用了一个可视化效果不太好的监控系统。 最开始我们使用Ganglia,它可以展示非常漂亮的图表,但是它比较难用,而且变化太快,尤其是在一个实例进进出出的虚拟机环境中。

没有让数据过期。 在reddit你能看到从最初开始的评论。后来他们开始增加一些限制,使得你不能对旧的评论投票,也不能回复旧的帖子。这会造成数据量越来越大,越来越难把热数据放在数据库里面。

没有使用一致性哈希算法。Not using consistent hashing. 当往cache中hash数据的时候,可能会出现这样的问题,当你增加更多的cache的时候,你的数据还会被hash到原来的cache中,不管你有多少chache。这样增加cache的时候,你无法保证负载均衡。一致性hash是解决问题的办法。我们迁移到Cassandra来解决这个问题。

教训总结

最关键的是在用户遇到问题之前就找到系统的瓶颈。

使用代理服务器不再是拓展的良方。过去可以根据用户访问的URL来分流。Reddit曾经也有过一个系统用于监控每个URL上系统服务的时间。用户请求会根据访问的URL的不同,进入到不同的响应通道。但是整个系统的响应速度总是此起彼伏。根据平均响应时间来分流以达到系统的巨大提升,已经完成成为过去时了。

让一切自动化。 如果你能对你的基础架构像对待你的代码周全,可以扩展的。那么所有事情都应该是其他的所有工作也应该是可以自动化配置的。

项目开始时就建设一个可扩展性架构是不必要的. 在项目开始的时候你不知道它会有什么特性,那么你只是想知道拓展会有什么问题。但是等到你的站点扩大后,你就能看到拓展的具体问题在什么地方。

不要一开始就使用面向服务的架构。记住,面向服务对一个中大型网站来说是很好的。但如果是起步期的站点就有点太超前了。

不要追求潮流。 只有一小部分的流行技术是可行的,比如,node.js这样的。

对所有的功能设限。 对所有会不断重复发生的事件设限制,必要的时候放宽或降低限制标准。如果添加限制,会排斥出一部分用户,但是保护了系统。举个子版块上传文件的例子。有用户指出他们上传的文件数多到可以损坏系统。也不要允许上传巨型文本。 其他人会教你怎么让你接受5GB的文本文件。

多手准备. 当在设计阶段的时候就假定以后系统要不断扩展的时候,那么开始的时候就不要只准备一台应用服务器,一台数据库和一个缓存了。那么以后做横向拓展的时候会容易的多。

用C语言重新Python代码。 随着reddit的不断拓展,大多数重复的功能都用C语言重写了原来的Python代码,且获得了很大的速度提升。特别是过滤器、markdown标签的渲染及memcache的调用。用C重写Python代码的优势是简单高效。

保证数据库设计尽可能的无模式。 这样会使得在添加新特性的时候变得简单。你所做的只是添加一些新的属性而不用修改表结构。

过期数据。 停用那些老旧的线程,创建好一个完整的页面并添加到缓存中。这就是处理那些可能导致你数据库奔溃的老旧数据的方式。同样的,不要允许对很久以前的评论点赞或者加平路,用户几乎不会注意到的。

SSD看做是便宜的内存,而不是昂贵的硬盘。 当reddit把数据库的存储设备从机械型硬盘升级到固态硬盘(SSD)后,服务器数量从12台降为1台,且响应还更快。SSD虽比机械式硬盘贵了四倍,但是你会得到16倍的性能提升,真是物有所值。Netflix板块中的一些最大Cassandra节点都是采用的SSD存储,性能得到了巨大的提升。

每个工具都有不同的适用场景。 Memcache中的数据是不做持久化的,但是非常快,那么投票数据存在它里面可以是页面的渲染以最快速度完成。Cassandra是持久化的,而且快,布隆过滤器的使用也是它可以找出没有命中的查询,所以使得它很适合存储没有在memcache中存储的投票数据的副本。Postgres是非常可靠的关系型数据库,可以用来存放Cassandra中投票数据的备份(Cassandra中的所有数据在必要的情况下可以从Postgre中获取),在做批量操作的时候,有时也需要依赖关系数据库的功能。

把未登录用户当作二等公民。 过去80%的请求来自未登入的用户,现在是接近50%。通过总是给未登录用户返回缓存内容的做法,reddit将包袱扔给了Akamai而自身的流量畅通,这种做法使其网站性能大大提升。附带的好处是,如果reddit当机了,你没登入的话你也许就察觉不到。

使用队列。 投票、评论、缩略图、预查询、垃圾评论处理及纠错等等都放在队列中处理。通过监控队列的长度就能让你发现问题。附带好处是,使用队列后有些问题对用户会变得透明,像投票请求,即使系统没有即时响应,用户也不会察觉。

将数据放在多个可访问的域中。

避免在一个实例中保存状态。

频繁对EBS硬盘做数据快照。

不要在实例中保存秘钥。

按安全策略组分拆功能。

提供API。开发人员可以在你的平台上开发应用。像reddit手机应用,就是由公司外的开发人员通过调用API开发的。

在你自己的社区做一个积极分子。

让用户为你工作。 网上用户的输入总是充满欺骗性、无用的、伪造的,但是对于reddit,处理这些垃圾信息的大部分工作都由志愿者完成了。这就是reddit能保持小团队却能把工作完成的出奇的好的原因。

给用户一点点权力,看看他们怎么做,然后把其中的好点子变为网站的功能。比如,当子版块可以定制CSS的时候,他们看到用户在干吗,以及为其他所有用户提供的一些功能。这也使用户在reddit做一些事感到兴奋,因为他们喜欢控制的感觉。还有很多这样的例子。

倾听用户的声音。用户会告诉你许多你可能想知道但是又不知道的事情。比如,reddit币最开始就是社区里面的一句玩笑话。现在他们做成了产品,而且用户很喜欢。

Team Foundation Server(TFS) 源代码管理服务器 更换IP地址或端口

源码管理服务器 Team Foundation Server(TFS) 的ip地址发生改变后, 解决方案连不上了.

解决方法是:

  • 1  打开”团队” -> “连接到 Team Foundation Server”, 移除原服务器地址

20140804104552

  • 2  编辑 项目解决方案.sln文件, 修改里面的 “SccTeamFoundationServer” 后面的TFS地址为新地址

  20140804105319

  • 3  打开 “C:\Users\Administrator\AppData\Local\Microsoft\Team Foundation\3.0\Cache”  版本不同, 文件夹可能是4.0.

修改 LocationServerMap.xml 文件, 删除其中的 “location” = 原地址的条目.

 20140804104744

  • 4  重新打来项目连接到TFS

 20140804104621

程序员的持续学习之道

原文出处: ShareCore (@Justin_Programer)

 

我其实是一个悲观主义者,从开始成为一名程序员的那一天开始,我就对自己的职业充满着担忧。早期,我担忧的是我刚进入这一行,落后身边从事这一行多年的人太多,跟他们比,我一开始就处于“不公平“的起跑线上;二是当我稍微深入这行后,发现技术的道路充满了歧路和死胡同,稍不留神,就将落入再也跟不上技术进步的节奏,身边也充斥着类似的示例。

好在在这条路上,我找到了一个克服担忧的良方:学习,坚持不懈的学习!

人类最大的恐惧莫过于对未知的恐惧,而学习,是克服未知的一个最有效途径。那作为一个程序员,该如何才能做到坚持不懈的学习呢?我想主要有以下几点:

1. 不抗拒变化,跟踪变化

这里说的变化,更多指的是技术的变化。新技术永远层出不穷,如果你抗拒变化,或惧怕变化,在心里优势上就落后了一大截。很多程序员的技术道路越走越窄,当一门新技术来临时,他们从不去了解或研究,他们要么认为这是”换汤不换药“的”技术幌子“,不值得去研究,要么等着别人去研究,自己被动的接受别人的结论与成果。诚然,等待别人的研究结果也可行,但是,当身边没有人去研究呢?当研究的人不愿意提供给你他的研究结果呢?当别人的结论和结果是错误的呢?

当然,业界的新技术层出不穷,要去跟踪每一项新技术的变化也是不可能的,我的建议是尽量掌握基础的技术,越是基础的技术越是恒定。如计算机的体系架构,TCP,HTTP,各类编程范式,OOP,MVC架构等,都是好多年来没有发生过变化的技术了。许多新技术也是建立在他们上面,当你了解了这些基础的技术,建立在他们之上的新技术也就能很快掌握了,并能迅速而准确地对这些新技术作出“价值判断”。

技术的变化,其实也并不全是指业界的新技术来临,更多指的是,超出自己当前技术能力外,主动研究和选择的“新技术” ,主动丢弃老的套路和技术,不固步自封。见过很多的程序员,他们写了很多年的代码了,技术能力还停留在数据库层写一个Sql(存储过程)+前端调用上。为什么如此呢?因为自开始写代码起,这样简单粗暴的方式就可以解决他们面对的问题了。所以,当碰到新的问题,他们就继续沿用着这种方式,而从不去看看业界是不是有更合适的方案来解决。长此以往,他们的技术能力也就不会有任何的变化,工作十年,只是将第一年所学的技术重复十年而已

2. 书宜杂读,业宜精钻

建筑学家梁思成赴美留学,其父梁启超告诫说:你该挤出一部分时间学些常识性东西,特别是文学或人文科学,稍稍多用点工夫就能有大的收获。我深怕你因所学太专一,把多彩的生活弄得平平淡淡,生活过于单调,则生厌倦心理,厌倦一生即成苦恼之事……书宜杂读,业宜精钻。

学习本身应该是一件很快乐的事情,但如果只是一味地沉浸于专业学习之中,难免会将本来快乐的事情弄成平淡和单调,更可怕的是,由此产生厌倦心理,放弃学习。

所以,可以尽量跟随自己的兴趣,去更广泛地读书。历史,文学,心理学,哲学等等各方面的书都可以尝试去读,它们不仅丰富你的知识,更能让你在阅读中受到感动、教育和启迪。书读的更多更广泛,知道的事也就多,思路更加开阔,解决问题的能力也就能高于常人,从而反过来帮助到你专业能力的提升。

3. 投资团队,积极打造学习型团队

现代社会,难免的一点就是个人必须置身于群体之中,程序员更是如此。从群体心理学的角度来看,在群体里,个人的才智被削弱,异质性被同质性所吞没。由此,如果一个团队不爱学习,那么,其中的成员也很难坚持学习(个性和意志力特别强的人除外)。

如果你爱学习,请想办法让你的团队也变得爱学习,这样,你对学习的坚持将变得更加容易。或许你认为建立学习氛围,是团队领导的事情,跟自己无关。领导当然可以来做也需要来做这样的事情,但要明白的一点,学习这事,如果变成从上向下,就难免“政治化”了,容易失去它本身的意义。而从下往上,更能建立轻松和谐的学习环境。

一些软件设计原则

出自:http://blog.jobbole.com/685/

导读:酷壳网的陈皓给大家介绍了软件设计的一些原则,作者认为一个好的程序员通常由其操作技能、知识水平,经验层力和能力四个方面组成。软件设计的这些原则,每一个程序员都应该了解。相信大家从中能够从中学了解到一些设计原理方面的知识。
文章内容如下:

以前本站向大家介绍过一些软件开发的原则,比如优质代码的十诫和Unix传奇(下篇)中所以说的UNIX的设计原则。相信大家从中能够从中学了解到 一些设计原理方面的知识,正如我在《再谈“我是怎么招聘程序员”》中所说的,一个好的程序员通常由其操作技能、知识水平,经验层力和能力四个方面组成。在这 里想和大家说说设计中的一些原则,我认为这些东西属于长期经验总结出来的知识。这些原则,每一个程序员都应该了解。但是请不要教条主义,在使用的时候还是 要多多考虑实际情况。

下面这些原则,不单单只是软件开发,可以推广到其它生产活动中,甚至我们的生活中

Don’t Repeat Yourself(DRY)

DRY是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易 的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码 让他们以一些合适的参数调用这个新的方法。

参考http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Keep It Simple, Stupid (KISS)

KISS原则在设计上可能最被推崇的,在家装设计,界面设计,操作设计上,复杂的东西越来越被众人所BS了,而简单的东西越来越被人所认可,比如这些UI的设计和我们中国网页(尤其是新浪的网页) 者是负面的例子。“宜家”(IKEA)简约、效率的家居设计、生产思路;“微软”(Microsoft)“所见即所得”的理念;“谷歌”(Google) 简约、直接的商业风格,无一例外的遵循了“kiss”原则,也正是“kiss”原则,成就了这些看似神奇的商业经典。而苹果公司的iPhone/iPad 将这个原则实践到了极至。

把一个事情搞复杂是一件简单的事,但要把一个复杂的事变简单,这是一件复杂的事。

参考http://en.wikipedia.org/wiki/KISS_principle

Program to an interface, not an implementation

这是设计模式中最根本的哲学,注重接口,而不是实现,依赖接口,而不是实现。接口是抽象是稳定的,实现则是多种多样的。以后面我们会面向对象的SOLID原则中会提到我们的依赖倒置原则,就是这个原则的的另一种样子。还有一条原则叫Composition over inheritance(喜欢组合而不是继承),这两条是那23个经典设计模式中的设计原则。

Command-Query Separation (CQS)–命令-查询分离原则

查询:当一个方法返回一个值来回应一个问题的时候,它就具有查询的性质;
命令:当一个方法要改变对象的状态的时候,它就具有命令的性质;

通常,一个方法可能是纯的Command模式或者是纯的Query模式,或者是两者的混合体。在设计接口时,如果可能,应该尽量使接口单一化,保证 方法的行为严格的是命令或者是查询,这样查询方法不会改变对象的状态,没有副作用,而会改变对象的状态的方法不可能有返回值。也就是说:如果我们要问一个 问题,那么就不应该影响到它的答案。实际应用,要视具体情况而定,语义的清晰性和使用的简单性之间需要权衡。将Command和Query功能合并入一个 方法,方便了客户的使用,但是,降低了清晰性,而且,可能不便于基于断言的程序设计并且需要一个变量来保存查询结果。

在系统设计中,很多系统也是以这样原则设计的,查询的功能和命令功能的系统分离,这样有则于系统性能,也有利于系统的安全性。

参考http://en.wikipedia.org/wiki/Command-query_separation

You Ain’t Gonna Need It(YAGNI)

这个原则简而言之为——只考虑和设计必须的功能,避免过度设计。只实现目前需要的功能,在以后您需要更多功能时,可以再进行添加。
如无必要,勿增复杂性。

软件开发先是一场沟通博弈。

以前本站有一篇关于过度重构的文章,这个示例就是这个原则的反例。而,WebSphere的设计者就表示过他过度设计了这个产品。我们的程序员或是架构师在设计系统的时候,会考虑很多扩展性的东西,导致在架构与设计方面使用了大量折衷,最后导致项目失败。这是个令人感到讽刺的教训,因为本来希望尽可能延长项目的生命周期,结果反而缩短了生命周期。

参考http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

Law of Demeter–迪米特法则

迪米特法则(Law of Demeter),又称“最少知识原则”(Principle of Least Knowledge),其来源于1987年荷兰大学的一个叫做Demeter的项目。Craig Larman把Law of Demeter又称作“不要和陌生人说话”。在《程序员修炼之道》中讲LoD的那一章叫作“解耦合与迪米特法则”。关于迪米特法则有一些很形象的比喻:

如果你想让你的狗跑的话,你会对狗狗说还是对四条狗腿说?

如果你去店里买东西,你会把钱交给店员,还是会把钱包交给店员让他自己拿?

和狗的四肢说话?让店员自己从钱包里拿钱?这听起来有点荒唐,不过在我们的代码里这几乎是见怪不怪的事情了。

对于LoD,正式的表述如下:
对于对象‘O’中一个方法‘M’,M应该只能够访问以下对象中的方法:

  • 1.对象O;
  • 2.与O直接相关的Component Object;
  • 3.由方法M创建或者实例化的对象;
  • 4.作为方法M的参数的对象。

在《Clean Code(代码整洁之道)》一书中,有一段Apache framework中的一段违反了LoD的代码:

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

这么长的一串对其它对象的细节,以及细节的细节,细节的细节的细节……的调用,增加了耦合,使得代码结构复杂、僵化,难以扩展和维护。

在《重构》一书中的代码的环味道中有一种叫做“Feature Envy”(依恋情结),形象的描述了一种违反了LoC的情况。Feature Envy就是说一个对象对其它对象的内容更有兴趣,也就是说老是羡慕别的对象的成员、结构或者功能,大老远的调用人家的东西。这样的结构显然是不合理的。 我们的程序应该写得比较“害羞”。不能像前面例子中的那个不把自己当外人的店员一样,拿过客人的钱包自己把钱拿出来。“害羞”的程序只和自己最近的朋友交 谈。这种情况下应该调整程序的结构,让那个对象自己拥有它羡慕的feature,或者使用合理的设计模式(例如Facade和Mediator)。

参考http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge

面向对象的S.O.L.I.D原则

一般来说这是面向对象的五大设计原则,但是,我觉得这些原则可适用于所有的软件开发。

Single Responsibility Principle (SRP)–职责单一原则

关于单一职责原则,其核心的思想是:一个类,只做一件事,并把这件事做好,其只有一个引起它变化的原因。单一职 责原则可以看作是低耦合、高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因。职责过多,可能引起它变化的原 因就越多,这将导致职责依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合度。单一职责,通常意味着单一的功能,因此不要为一个模块实现过多的功能 点,以保证实体只有一个引起它变化的原因。

Unix/Linux是这一原则的完美体现者。各个程序都独立负责一个单一的事。

Windows是这一原则的反面示例。几乎所有的程序都交织耦合在一起。

Open/Closed Principle (OCP)–开闭原则

关于开发封闭原则,其核心的思想是:模块是可扩展的,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的

对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。

对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对类进行任何修改。

对于面向对象来说,需要你依赖抽象,而不是实现,23个经典设计模式中的“策略模式”就是这个实现。对于非面向对象编程,一些API需要你传入一个 你可以扩展的函数,比如我们的C语言的qsort()允许你提供一个“比较器”,STL中的容器类的内存分配,ACE中的多线程的各种锁。对于软件方面, 浏览器的各种插件属于这个原则的实践。

Liskov substitution principle (LSP)–里氏代换原则

软件工程大师Robert C. Martin把里氏代换原则最终简化为一句话:“Subtypes must be substitutable for their base types”。也就是,子类必须能够替换成它们的基类。即:子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作。另外,不应该 在代码中出现if/else之类对子类类型进行判断的条件。里氏替换原则LSP是使代码符合开闭原则的一个重要保证。正是由于子类型的可替换性才使得父类 型的模块在无需修改的情况下就可以扩展。

这么说来,似乎有点教条化,我非常建议大家看看这个原则个两个最经典的案例——“正方形不是长方形”和“鸵鸟不是鸟”。通过这两个案例,你会明白 《墨子小取》中说的——“娣,美人也,爱娣,非爱美人也….盗,人也;恶盗,非恶人也。”——妹妹虽然是美人,但喜欢妹妹并不代表喜欢美人。盗贼是人,但 讨厌盗贼也并不代表就讨厌人类。这个原则让你考虑的不是语义上对象的间的关系,而是实际需求的环境

在很多情况下,在设计初期我们类之间的关系不是很明确,LSP则给了我们一个判断和设计类之间关系的基准:需不需要继承,以及怎样设计继承关系。

Interface Segregation Principle (ISP)–接口隔离原则

接口隔离原则意思是把功能实现在接口中,而不是类中,使用多个专门的接口比使用单一的总接口要好。

举个例子,我们对电脑有不同的使用方式,比如:写作,通讯,看电影,打游戏,上网,编程,计算,数据等,如果我们把这些功能都声明在电脑的抽类里 面,那么,我们的上网本,PC机,服务器,笔记本的实现类都要实现所有的这些接口,这就显得太复杂了。所以,我们可以把其这些功能接口隔离开来,比如:工 作学习接口,编程开发接口,上网娱乐接口,计算和数据服务接口,这样,我们的不同功能的电脑就可以有所选择地继承这些接口。

这个原则可以提升我们“搭积木式”的软件开发。对于设计来说,Java中的各种Event Listener和Adapter,对于软件开发来说,不同的用户权限有不同的功能,不同的版本有不同的功能,都是这个原则的应用。

Dependency Inversion Principle(DIP)–依赖倒置原则

高层模块不应该依赖于低层模块的实现,而是依赖于高层抽象。

举个例子,墙面的开关不应该依赖于电灯的开关实现,而是应该依赖于一个抽象的开关的标准接口,这样,当我们扩展程序的时候,我们的开关同样可以控制 其它不同的灯,甚至不同的电器。也就是说,电灯和其它电器继承并实现我们的标准开关接口,而我们的开关产商就可不需要关于其要控制什么样的设备,只需要关 心那个标准的开关标准。这就是依赖倒置原则。

这就好像浏览器并不依赖于后面的web服务器,其只依赖于HTTP协议。这个原则实在是太重要了,社会的分工化,标准化都是这个设计原则的体现。

参考http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

Common Closure Principle(CCP)–共同封闭原则

一个包中所有的类应该对同一种类型的变化关闭。一个变化影响一个包,便影响了包中所有的类。一个更简短的说法是:一起修改的类,应该组合在一起(同 一个包里)。如果必须修改应用程序里的代码,我们希望所有的修改都发生在一个包里(修改关闭),而不是遍布在很多包里。CCP原则就是把因为某个同样的原 因而需要修改的所有类组合进一个包里。如果2个类从物理上或者从概念上联系得非常紧密,它们通常一起发生改变,那么它们应该属于同一个包。

CCP延伸了开闭原则(OCP)的“关闭”概念,当因为某个原因需要修改时,把需要修改的范围限制在一个最小范围内的包里。

参考http://c2.com/cgi/wiki?CommonClosurePrinciple

Common Reuse Principle (CRP)–共同重用原则

包的所有类被一起重用。如果你重用了其中的一个类,就重用全部。换个说法是,没有被一起重用的类不应该被组合在一起。CRP原则帮助我们决定哪些类 应该被放到同一个包里。依赖一个包就是依赖这个包所包含的一切。当一个包发生了改变,并发布新的版本,使用这个包的所有用户都必须在新的包环境下验证他们 的工作,即使被他们使用的部分没有发生任何改变。因为如果包中包含有未被使用的类,即使用户不关心该类是否改变,但用户还是不得不升级该包并对原来的功能 加以重新测试。

CCP则让系统的维护者受益。CCP让包尽可能大(CCP原则加入功能相关的类),CRP则让包尽可能小(CRP原则剔除不使用的类)。它们的出发点不一样,但不相互冲突。

参考http://c2.com/cgi/wiki?CommonReusePrinciple

Hollywood Principle–好莱坞原则

好莱坞原则就是一句话——“don’t call us,we’ll call you.”。意思是,好莱坞的经纪人们不希望你去联系他们,而是他们会在需要的时候来联系你。也就是说,所有的组件都是被动的,所有的组件初始化和调用都 由容器负责。组件处在一个容器当中,由容器负责管理。

简单的来讲,就是由容器控制程序之间的关系,而非传统实现中,由程序代码直接操控。这也就是所谓“控制反转”的概念所在:

  • 1.不创建对象,而是描述创建对象的方式。
  • 2.在代码中,对象与服务没有直接联系,而是容器负责将这些联系在一起。

控制权由应用代码中转到了外部容器,控制权的转移,是所谓反转。

好莱坞原则就是IoC(Inversion of Control)或DI(Dependency Injection)的基础原则。这个原则很像依赖倒置原则,依赖接口,而不是实例,但是这个原则要解决的是怎么把这个实例传入调用类中?你可能把其声明 成成员,你可以通过构造函数,你可以通过函数参数。但是IoC可以让你通过配置文件,一个由Service Container 读取的配置文件来产生实际配置的类。但是程序也有可能变得不易读了,程序的性能也有可能还会下降。

参考
http://en.wikipedia.org/wiki/Hollywood_Principle
http://en.wikipedia.org/wiki/Inversion_of_Control

High Cohesion & Low/Loose coupling & –高内聚,低耦合

这个原则是UNIX操作系统设计的经典原则,把模块间的耦合降到最低,而努力让一个模块做到精益求精。

  • 内聚:一个模块内各个元素彼此结合的紧密程度
  • 耦合:一个软件结构内不同模块之间互连程度的度量

内聚意味着重用和独立,耦合意味着多米诺效应牵一发动全身。

参考
http://en.wikipedia.org/wiki/Coupling_(computer_science)
http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Convention over Configuration(CoC)–惯例优于配置原则

简单点说,就是将一些公认的配置方式和信息作为内部缺省的规则来使用。例如,Hibernate的映射文件,如果约定字段名和类属性一致的话,基本 上就可以不要这个配置文件了。你的应用只需要指定不convention的信息即可,从而减少了大量convention而又不得不花时间和精力啰里啰嗦 的东东。配置文件很多时候相当的影响开发效率。

Rails中很少有配置文件(但不是没有,数据库连接就是一个配置文件),Rails的fans号称期开发效率是java开发的10倍,估计就是这 个原因。Maven也使用了CoC原则,当你执行mvn -compile命令的时候,不需要指源文件放在什么地方,而编译以后的class文件放置在什么地方也没有指定,这就是CoC原则。

参考http://en.wikipedia.org/wiki/Convention_over_Configuration

Separation of Concerns (SoC)–关注点分离

SoC是计算机科学中最重要的努力目标之一。这个原则,就是在软件开发中,通过各种手段,将问题的各个关注点分开。如果一个问题能分解为独立且较小 的问题,就是相对较易解决的。问题太过于复杂,要解决问题需要关注的点太多,而程序员的能力是有限的,不能同时关注于问题的各个方面。正如程序员的记忆力 相对于计算机知识来说那么有限一样,程序员解决问题的能力相对于要解决的问题的复杂性也是一样的非常有限。在我们分析问题的时候,如果我们把所有的东西混 在一起讨论,那么就只会有一个结果——乱。

我记得在上一家公司有一个项目,讨论就讨论了1年多,项目本来不复杂,但是没有使用SoC,全部的东西混为一谈,再加上一堆程序员注入了各种不同的观点和想法,整个项目一下子就失控了。最后,本来一个1年的项目做了3年。

实现关注点分离的方法主要有两种,一种是标准化,另一种是抽象与包装。标准化就是制定一套标准,让使用者都遵守它,将人们的行为统一起来,这样使用 标准的人就不用担心别人会有很多种不同的实现,使自己的程序不能和别人的配合。Java EE就是一个标准的大集合。每个开发者只需要关注于标准本身和他所在做的事情就行了。就像是开发镙丝钉的人只专注于开发镙丝钉就行了,而不用关注镙帽是怎 么生产的,反正镙帽和镙丝钉按标来就一定能合得上。不断地把程序的某些部分抽像差包装起来,也是实现关注点分离的好方法。一旦一个函数被抽像出来并实现 了,那么使用函数的人就不用关心这个函数是如何实现的,同样的,一旦一个类被抽像并实现了,类的使用者也不用再关注于这个类的内部是如何实现的。诸如组 件,分层,面向服务,等等这些概念都是在不同的层次上做抽像和包装,以使得使用者不用关心它的内部实现细节。
说白了还是“高内聚,低耦合”。

参考http://sulong.me/archives/99

Design by Contract (DbC)–契约式设计

DbC的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。例如:
供应商必须提供某种产品(责任),并且他有权期望客户已经付款(权利)。
客户必须付款(责任),并且有权得到产品(权利)。

契约双方必须履行那些对所有契约都有效的责任,如法律和规定等。

同样的,如果在程序设计中一个模块提供了某种功能,那么它要:
期望所有调用它的客户模块都保证一定的进入条件:这就是模块的先验条件(客户的义务和供应商的权利,这样它就不用去处理不满足先验条件的情况)。

保证退出时给出特定的属性:这就是模块的后验条件——(供应商的义务,显然也是客户的权利)。

在进入时假定,并在退出时保持一些特定的属性:不变式。

契约就是这些权利和义务的正式形式。我们可以用“三个问题”来总结DbC,并且作为设计者要经常问:

  • 它期望的是什么?
  • 它要保证的是什么?
  • 它要保持的是什么?

根据Bertrand Meyer氏提出的DBC概念的描述,对于类的一个方法,都有一个前提条件以及一个后续条件,前提条件说明方法接受什么样的参数数据等,只有前提条件得到 满足时,这个方法才能被调用;同时后续条件用来说明这个方法完成时的状态,如果一个方法的执行会导致这个方法的后续条件不成立,那么这个方法也不应该正常 返回。

现在把前提条件以及后续条件应用到继承子类中,子类方法应该满足:

  • 1.前提条件不强于基类.
  • 2.后续条件不弱于基类.

换句话说,通过基类的接口调用一个对象时,用户只知道基类前提条件以及后续条件。因此继承类不得要求用户提供比基类方法要求的更强的前提条件,亦 即,继承类方法必须接受任何基类方法能接受的任何条件(参数)。同样,继承类必须顺从基类的所有后续条件,亦即,继承类方法的行为和输出不得违反由基类建 立起来的任何约束,不能让用户对继承类方法的输出感到困惑。

这样,我们就有了基于契约的LSP,基于契约的LSP是LSP的一种强化。

参考http://en.wikipedia.org/wiki/Design_by_contract

Acyclic Dependencies Principle (ADP)–无环依赖原则

包之间的依赖结构必须是一个直接的无环图形,也就是说,在依赖结构中不允许出现环(循环依赖)。如果包的依赖形成了环状结构,怎么样打破这种循环依 赖呢?有2种方法可以打破这种循环依赖关系:第一种方法是创建新的包,如果A、B、C形成环路依赖,那么把这些共同类抽出来放在一个新的包D里。这样就把 C依赖A变成了C依赖D以及A依赖D,从而打破了循环依赖关系。第二种方法是使用DIP(依赖倒置原则)和ISP(接口分隔原则)设计原则。

无环依赖原则(ADP)为我们解决包之间的关系耦合问题。在设计模块时,不能有循环依赖。

参考http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple

上面这些原则可能有些学院派,也可能太为理论,我在这里说的也比较模糊和简单,这里只是给大家一个概貌,如果想要了解更多的东西,大家可以多google一下。

不过这些原则看上去都不难,但是要用好却并不那么容易。要能把这些原则用得好用得精,而不教条,我的经验如下:(我以为这是一个理论到应用的过程)

  • 1.你可以先粗浅或是表面地知道这些原则。
  • 2.但不要急着马上就使用。
  • 3.在工作学习中观察和总结别人或自己的设计。
  • 4.再回过头来了回顾一下这些原则,相信你会有一些自己的心得。
  • 5.有适度地去实践一下。
  • 6.Goto第 3步。

好的程序设计原则

好的编程原则跟好的系统设计原则和技术实施原则有着密切的联系。下面的这些编程原则在过去的这些年里让我成为了一名优秀的程序员,我相信,这些原则对任何一个开发人员来说,都能让他的编程能力大幅度的提高,能让他开发出可维护性更强、缺陷更少的程序。

我不要自我重复 — 这也许是在编程开发这最最基本的一个信条,就是要告诉你不要出现重复的代码。我们很多的编程结构之所以存在,就是为了帮助我们消除重复(例如,循环语句,函数,类,等等)。一旦程序里开始有重复现象的出现(例如很长的表达式、一大堆的语句,但都是为了表达相同的概念),你就需要对代码进行一次新的提炼,抽象。
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

提炼原则 — 跟“不要自我重复原则”相关,这一原则是说“程序中任何一段具有功能性的代码在源代码文件中应该唯一的存在。”
http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

保持简单 — 简单化(避免复杂)永远都应该是你的头等目标。简单的程序让你写起来容易,产生的bug更少,更容易维护修改。
http://en.wikipedia.org/wiki/KISS_principle

不要开发你目前用不到的功能 — 除非你真正需要用到它,否则不要轻易加上那些乱七八糟用不到的功能。
http://en.wikipedia.org/wiki/YAGNI

用最简单的方法让程序跑起来 — 在开发时有个非常好的问题你需要问问自己,“怎样才能最简单的让程序跑起来?”这能帮助我们在设计时让程序保持简单。
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

不要让我动脑子 — 这实际上是Steve Krug 关于web界面操作的一本书的书名,但也适用于编程。主旨是,程序代码应该让人们花最小的努力就能读懂和理解。如果一段程序对于阅读者来说需要花费太多的努力才能理解,那它很可能需要进一步简化。
http://www.sensible.com/dmmt.html

开放/封闭原则 — 程序里的实体项(类,模块,函数等)应该对扩展行为开放,对修改行为关闭。换句话说,不要写允许别人修改的类,应该写能让人们扩展的类。
http://en.wikipedia.org/wiki/Open_Closed_Principle

为维护者写程序 — 任何值得你编写的程序在将来都是值得你去维护的,也许由你维护,也许由他人。在将来,当你不得不维护这些程序时,你对这些代码的记忆会基本上跟一个陌生人一样,所以,你最好还是当成一直在给别人写程序。一个有助于你记住这个原则的办法是“写程序时时刻记着,这个将来要维护你写的程序的人是一个有严重暴力倾向,并且知道你住在哪里的精神变态者”。
http://c2.com/cgi/wiki?CodeForTheMaintainer

最少意外原则 — 最少意外原则通常是使用在用户界面设计上,但这个原则同样适用于编写程序。程序代码应尽可能的不要让阅读者感到意外。也就是说应该遵循编码规范和常见习惯,按照公认的习惯方式进行组织和命名,不符常规的编程动作应该尽可能的避免。
http://en.wikipedia.org/wiki/Principle_of_least_astonishment

单一职责原则 — 一个代码组件(例如类或函数)应该只执行单一的预设的任务。
http://en.wikipedia.org/wiki/Single_responsibility_principle

最小化耦合关系 — 一个代码片段(代码块,函数,类等)应该最小化它对其它代码的依赖。这个目标通过尽可能少的使用共享变量来实现。“低耦合是一个计算机系统结构合理、设计优秀的标志,把它与高聚合特征联合起来,会对可读性和可维护性等重要目标的实现具有重要的意义。”
http://en.wikipedia.org/wiki/Coupling_(computer_programming)

最大化内聚性 — 具有相似功能的代码应该放在同一个代码组件里。
http://en.wikipedia.org/wiki/Cohesion_(computer_science)

隐藏实现细节 — 隐藏实现细节能最小化你在修改程序组件时产生的对那些使用这个组件的其它程序模块的影响。
http://en.wikipedia.org/wiki/Information_Hiding

笛米特法则(Law of Demeter) — 程序组件应该只跟它的直系亲属有关系(例如继承类,内包含的对象,通过参数入口传入的对象等。)
http://en.wikipedia.org/wiki/Law_of_Demeter

避免过早优化 — 只有当你的程序没有其它问题,只是比你预期的要慢时,你才能去考虑优化工作。只有当其它工作都做完后,你才能考虑优化问题,而且你只应该依据经验做法来优化。“对于小幅度的性能改进都不该考虑,要优化就应该是97%的性能提升:过早优化是一切罪恶的根源”—Donald Knuth。
http://en.wikipedia.org/wiki/Program_optimization

代码复用 — 这不是非常核心的原则,但它跟其它原则一样非常有价值。代码复用能提高程序的可靠性,节省你的开发时间。
http://en.wikipedia.org/wiki/Code_reuse

职责分离 — 不同领域的功能应该由完全不同的代码模块来管理,尽量减少这样的模块之间的重叠。 http://en.wikipedia.org/wiki/Separation_of_concerns

拥抱变化 — 这是Kent Beck的一本书的副标题,它也是极限编程和敏捷开发方法的基本信条之一。很多的其它原则都基于此观念:面对变化,欢迎变化。事实上,一些经典的软件工程原则,例如最小化耦合,就是为了让程序更容易面对变化。不论你是否采用了极限编程方法,这个原则对你的程序开发都有重要意义。http://www.amazon.com/gp/product/0321278658

[英文原文:The Principles of Good Programming ]
这和《代码大全》上的总结基本一致

C# 中的 Json

一直是做的winform多一些, 可最近做的活儿都是常用JSON。

项目的服务交互是 jquery easyui , Handler.ashx做的, 后台是工具配置的数据.

 

fastJSON -> fastJSON.dll

Json.NET -> Newtonsoft.Json.dll

DataContractJsonSerializer -> System.Runtime.Serialization.Json

速度上对比:
fastJSON  > Json.NET > Windows.Data.Json 
参考:
http://james.newtonking.com/json/help/html/JsonNetVsDotNetSerializers.htm
http://james.newtonking.com/json/help/html/JsonNetVsWindowsDataJson.htm

GIT与SVN的优缺点比较

git_logosf-logo

GIT与SVN的优缺点比较

Subversion
1.SVN优缺点
优点:
1、 管理方便,逻辑明确,符合一般人思维习惯。
2、 易于管理,集中式服务器更能保证安全性。
3、 代码一致性非常高。
4、 适合开发人数不多的项目开发。
缺点:
1、 服务器压力太大,数据库容量暴增。
2、 如果不能连接到服务器上,基本上不可以工作,看上面第二步,如果服务器不能连接上,就不能提交,还原,对比等等。
3、 不适合开源开发(开发人数非常非常多,但是Google app engine就是用svn的)。但是一般集中式管理的有非常明确的权限管理机制(例如分支访问限制),可以实现分层管理,从而很好的解决开发人数众多的问题。

 

 

logo@2x
2.Git优缺点
优点:
1、适合分布式开发,强调个体。
2、公共服务器压力和数据量都不会太大。
3、速度快、灵活。
4、任意两个开发者之间可以很容易的解决冲突。
5、离线工作。
缺点:
1、学习周期相对而言比较长。
2、不符合常规思维。
3、代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

多种常见软件系统缩写

BPM(Business Process Management):业务流程管理

也称做商业流程管理。一套达成企业各种业务环节整合的全面管理模式。其中的Business并不局限于商业,它泛指各种组织中的活动:从商业企业到政府机构、非营利团体等等,因此,普遍共识是对应于更加中性的“业务”一词,例如:业务流程管理(Business Process Management, BPM)、业务流程再造(Business Process Reengineering, BPR)等。Business Process Modeling,即业务流程建模,是对业务流程进行表述的方式,它是过程分析与重组的重要基础。

 

CRM(Customer Relationship Management):客户关系管理

是一个不断加强与顾客交流,不断了解顾客需求,并不断对产品及服务进行改进和提高以满足顾客的需求的连续的过程。其内含是企业利用信息技(IT)术和互联网技术实现对客户的整合营销,是以客户为核心的企业营销的技术实现和管理实现。客户关系管理注重的是与客户的交流,企业的经营是以客户为中心,而不是传统的以产品或以市场为中心。为方便与客户的沟通,客户关系管理可以为客户提供多种交流的渠道。

 

CMS(Content Management System):内容管理系统

它具有许多基于模板的优秀设计,可以加快网站开发的速度和减少开发的成本。CMS的功能并不只限于文本处理,它也可以处理图片、Flash动画、声像流、图像甚至电子邮件档案。

 

EIP(Enterprise Information Portal): 企业信息门户

是指在Internet的环境下,把各种应用系统、数据资源和互联网资源统一集成到企业信息门户之下,根据每个用户使用特点和角色的不同,形成个性化的应用界面,并通过对事件和消息的处理、传输把用户有机地联系在一起。

 

ERP(Enterprise Resource Planning):企业资源计划系统

又译企业资源规划,简单地说,ERP是“一个大型模块化、集成性的流程导向系统,集成企业内部财务会计、制造、进销存等信息流,快速提供决策信息,提升企业的营运绩效与快速反应能力。”它是e化企业的后台心脏与骨干。任何前台的应用系统包括EC、CRM、SCM等都以它为基础。
一般ERP软件强调如下之系统集成。
ERP主要的模块有:
生产管理:工程、材料清单(Bill Of Material)、调度、产能、工作流管理、质量控制、成本管理、生产过程、生产工程、生产流程、生产配置
进销存货管理:库存、订单输入、采购、供应商调度、货物检查、付款请求处理、佣金计算
财务管理及会计项目:总帐、现金管理、应付帐款管理、应收帐款管理、票据资金管理、固定资产管理
成本管理:账单、时间和支出、活动管理
人力资源管理:人力资源、薪金名册、培训管理、员工班别和出勤管理、津贴、劳健保、绩效考核
供应链管理:和客户、供应商、员工之间的各种自服务接口

 

GIS(Geographic Information System):地理信息系统

又称为“地学信息系统”。它是一种特定的十分重要的空间信息系统。它是在计算机硬、软件系统支持下,对整个或部分地球表层(包括大气层)空间中的有关地理分布数据进行采集、储存、管理、运算、分析、显示和描述的技术系统。

 

MIS(Management Information System):管理信息系统

是一个由人、计算机及其他外围设备等组成的能进行信息的收集、传递、存贮、加工、维护和使用的系统。利用现代计算机及网络通讯技术加强企业的信息管理,通过对企业拥有的人力、物力、财力、设备、技术等资源的调查了解,建立正确的数据,加工处理并编制成各种信息资料及时提供给管理人员,以便进行正确的决策,不断提高企业的管理水平和经济效益。

 

OA(Office Automation):办公自动化

是现代利用电脑进行全自动的办公,目的是提高效率。

 

SCM(Supply Chain Management):供应链管理

把公司的制造过程、库存系统和供应商产生的数据合并在一起,从一个统一的视角展示产品建造过程的各种影响因素。对整个供应链(从供货商,制造商,分销商到消费者)的各个环节进行综合管理,例如从采购、物料管理、生产、配送、营销到消费者的整个供应链的货物流、信息流和资金流,把物流与库存成本降到最小。供应链是企业赖以生存的商业循环系统,是企业电子商务管理中最重要的课题。

 

WfMS(Workflow Management System):工作流管理系统

工作流(Workflow),是对工作流程及其各操作步骤之间业务规则的抽象、概括、描述。工作流建模,即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。工作流要解决的主要问题是:为实现某个业务目标,在多个参与者之间,利用计算机,按某种预定规则自动传递文档、信息或者任务。工作流管理系统(Workflow Management System, WfMS)的主要功能是通过计算机技术的支持去定义、执行和管理工作流,协调工作流执行过程中工作之间以及群体成员之间的信息交互。工作流需要依靠工作流管理系统来实现。

 

WMS(Warehouse Management System):仓储管理系统

对物料存放空间进行管理的软件,区别于库存管理。其功能主要有两方面,一为通过在系统中设定一定的仓库仓位结构对物料具体空间位置的定位,二为通过在系统中设定一些策略对物料入库\出库\库内等作业流程进行指导。有利于仓库资源使用。

 

Windows 驱动程序入门

驱动程序入门

从这里开始学习有关驱动程序的基本概念。

你应熟悉 C 编程语言,并且应了解函数指针、回调函数以及事件处理程序的理念。若要基于用户模式驱动程序框架 1.x 编写驱动程序,则应熟悉 C++ 和 COM。

什么是驱动程序?

 

为术语“驱动程序”给出单一的准确定义比较困难。就最基本的意义而言,驱动程序是一个软件组件,可让操作系统和设备彼此通信。例如,假设应用程序需要从设备中读取某些数据。应用程序会调用由操作系统实现的函数,操作系统会调用由驱动程序实现的函数。驱动程序(由设计和制造该设备的同一公司编写)了解如何与设备硬件通信以获取数据。当驱动程序从设备获取数据后,它会将数据返回到操作系统,操作系统将数据返回至应用程序。

图:显示应用程序、操作系统以及驱动程序

 

扩大定义

到目前为止,我们的说明采用以下几种方式进行简单化:

  • 并非所有驱动程序都必须由设计该设备的公司编写。在多种情形下,设备根据已发布的硬件标准来设计。这表示驱动程序可以由 Microsoft 编写,设备设计者无须提供驱动程序。
  • 并非所有驱动程序都直接与设备通信。对于给定的 I/O 请求(如从设备读取数据),通常有一些驱动程序(在堆栈中进行分层)参与该请求。可视化堆栈的传统方式是将第一个参与对象放在顶部,将最后一个参与对象放在底部,如此图所示。堆栈中的某些驱动程序可能通过将请求从一种格式转换至另一种格式来参与。这些驱动程序不会与设备直接通信;它们只操纵请求并将请求传递至堆栈下方的驱动程序。图:显示应用程序、操作系统、3 个驱动程序以及设备
  • 堆栈中直接与设备通信的一个驱动程序称为“函数驱动程序”;执行辅助处理的驱动程序称为“筛选器驱动程序”
  • 某些筛选器驱动程序遵守并记录有关 I/O 请求的信息,但不会主动参与这些请求。例如,某些筛选器驱动程序充当验证程序以确保堆栈中的其他驱动程序正确处理 I/O 请求。

我们可以扩大“驱动程序”的定义,方法是表示驱动程序为遵守或参与操作系统与设备之间通信的任一软件组件。

软件驱动程序

我们的扩大定义相当准确,但仍不完整,原因是某些驱动程序与任何硬件设备根本不关联。 例如,假设你需要编写可以访问核心操作系统数据结构的工具,这些结构仅可以由内核模式下运行的代码进行访问。可以通过将工具拆分成两个组件来执行该操作。第一个组件在用户模式下运行且提供用户界面。第二个组件在内核模式下运行且可以访问核心操作系统数据。在用户模式下运行的组件称为应用程序,在内核模式下运行的组件称为“软件驱动程序”。软件驱动程序与硬件设备不关联。有关处理器模式的详细信息,请参阅用户模式和内核模式

此图说明了与内核模式软件驱动程序通信的用户模式应用程序。

图:显示应用程序和软件驱动程序

其他说明

软件驱动程序始终在内核模式下运行。编写软件驱动程序的主要原因是获取对仅在内核模式下可用的受保护数据的访问权限。但是设备驱动程序不会始终需要访问内核模式数据和资源。因此某些设备驱动程序在用户模式下运行。

有一系列的驱动程序我们尚未提及,“总线驱动程序”。若要了解总线驱动程序,你需要了解设备节点和设备树。有关设备树、设备节点以及总线驱动程序的信息,请参阅设备节点和设备堆栈

到目前为止,我们的说明过度简化了“函数驱动程序”的定义。我们表示设备的函数驱动程序为堆栈中直接与设备通信的一个驱动程序。对于直接连接到外围组件互连 (PCI) 总线的设备而言,以上为真。PCI 设备的函数驱动程序获取映射到设备上端口和内存资源的地址。函数驱动程序通过写入这些地址直接与设备通信。但是在多种情形下,设备未直接连接到 PCI 总线。相反设备连接到的主机总线适配器连接到 PCI 总线。例如,USB toaster 连接到主机总线适配器(称为 USB 主控制器),该适配器连接到 PCI 总线。USB toaster 具有函数驱动程序,USB 主控制器也具有函数驱动程序。toaster 的函数驱动程序与 toaster 间接通信,方法是将请求发送至 USB 主控制器的函数驱动程序。然后,USB 主控制器的函数驱动程序与 USB 主控制器硬件直接通信,该硬件与 toaster 通信。

图:显示 USB toaster 驱动程序和 USB 主控制器驱动程序

 

选择驱动程序模型

Microsoft Windows 提供了多种驱动程序模型,你可以使用这些模型编写驱动程序。最佳驱动程序模型的选择策略取决于你计划编写的驱动程序类型。下文介绍了这些选项:

  • 设备函数驱动程序
  • 设备筛选器驱动程序
  • 软件驱动程序
  • 文件系统筛选器驱动程序
  • 文件系统驱动程序

有关各种类型驱动程序之间差异的介绍,请参阅什么是驱动程序?设备节点和设备堆栈。以下部分说明了如何为每种类型的驱动程序选择模型。

为设备函数驱动程序选择驱动程序模型

当你设计一个硬件设备时,首先要考虑的事项之一就是你是否需要编写函数驱动程序。提出下列问题:

是否可以完全避免编写驱动程序?
如果必须编写函数驱动程序,则最好使用哪个驱动程序模型?

若要回答这些问题,请确定设备的何处可以容纳设备和驱动程序技术中介绍的技术列表。参阅该特定技术的文档,以确定是否需要编写函数驱动程序以及了解哪些驱动程序模型可供设备使用。

某些个别技术具有微型驱动程序模型。在微型驱动程序模型中,设备驱动程序由两个部分组成:一个部分处理常规任务,另一部分处理设备特定的任务。通常,Microsoft 编写通用部分,设备制造商编写设备特定的部分。设备特定的部分具有多种名称,其中大部分名称都共享前缀“微型”。以下是微型驱动程序模型中使用的一些名称:

  • 显示器微型端口驱动程序
  • 音频微型端口驱动程序
  • 电池微型类驱动程序
  • 蓝牙协议驱动程序
  • HID 微型驱动程序
  • WIA 微型驱动程序
  • NDIS 微型端口驱动程序
  • 存储器微型端口驱动程序
  • 流微型驱动程序

有关微型驱动程序模型的概述,请参阅微型驱动程序和驱动程序对

并非设备和驱动程序技术中列出的每项技术都有专用的微型驱动程序模型。特定技术的文档可能会建议你使用内核模式驱动程序框架 (KMDF);其他技术的文档可能会建议你使用用户模式驱动程序框架 (UMDF)。关键点是你应从研究特定设备技术的文档开始。如果你的设备技术具有微型驱动程序模型,则必须使用微型驱动程序模型。否则就遵循技术特定的文档中有关是使用 UMDF、KMDF 还是 Windows 驱动程序模型 (WDM) 的建议。

为设备筛选器驱动程序选择驱动程序模型

一些驱动程序频繁参与单个 I/O 请求(如从设备读取数据)。驱动程序在堆栈中进行分层,并且可视化堆栈的常规方法是将第一个驱动程序放在顶部,将最后一个驱动程序放在底部。堆栈具有一个函数驱动程序并且还可以具有筛选器驱动程序。有关函数驱动程序和筛选器驱动程序的介绍,请参阅什么是驱动程序?设备节点和设备堆栈

如果你准备为设备编写筛选器驱动程序,则确定设备的何处可以容纳设备和驱动程序技术中介绍的技术列表。查看特定设备技术的文档是否有关于选择筛选器驱动程序模型的任何指南。如果设备技术的文档未提供此指南,则首先考虑使用 UMDF 作为驱动程序模型。如果筛选器驱动程序需要访问的数据结构无法通过 UMDF 获取,则考虑使用 KMDF 作为驱动程序模型。在极端少见的情形中,驱动程序需要访问的数据结构无法通过 KMDF 获取,则使用 WDM 作为驱动程序模型。

为软件驱动程序选择驱动程序模型

未与设备关联的驱动程序称为“软件驱动程序”。有关软件驱动程序的介绍,请参阅什么是驱动程序?主题。软件驱动程序很有用,原因是这些驱动程序可以在内核模式下运行,这样为其提供了受保护操作系统数据的访问权限。有关处理器模式的信息,请参阅用户模式和内核模式

有关软件驱动程序,你的两个选项为 KMDF 和旧的 Windows NT 驱动程序模型。使用 KMDF 和旧的 Windows NT 模型,你可以在编写驱动程序时无须考虑即插即用 (PnP) 和电源管理。你可以改为专心于驱动程序的首要任务上。使用 KMDF,你不必考虑 PnP 和电源,因为框架会为你处理 PnP 和电源。使用旧的 Windows NT 模型,你不必考虑 PnP 和电源,原因是旧的驱动程序在与 PnP 和电源管理完全无关的环境中运行。

我们的建议是使用 KMDF,尤其是当你已熟悉 KMDF 时。如果你希望驱动程序与 PnP 和电源管理完全无关,则使用旧的 Windows NT 模型。如果你需要编写注意到电源转换或 PnP 事件的软件,则不能使用旧的 Windows NT 模型;必须使用 KMDF。

Note  在极少情形中,你需要编写注意到 PnP 或电源事件的软件驱动程序,并且驱动程序需要访问无法通过 KMDF 获取的数据,则必须使用 WDM。

为文件系统筛选器驱动程序选择驱动程序模型

有关为文件系统筛选器驱动程序选择模型的帮助,请参阅“文件系统微过滤驱动程序”和文件系统筛选器驱动程序

为文件系统驱动程序选择驱动程序模型

有关为文件系统驱动程序选择模型的帮助,请参阅文件系统微过滤驱动程序。+

 

编写第一个驱动程序

提供了三个练习,指导你完成编写和构建小型驱动程序的整个过程。第一个练习基于用户模式驱动程序框架 (UMDF),其他两个练习基于内核模式驱动程序框架 (KMDF)。

尽管因为稳定性和可靠性的缘故 UMDF 为首选模型,但 KMDF 提供了一个有吸引力的机会,可以编写非常小的 Hello World 驱动程序。使用 KMDF,你可以编写非常简短的驱动程序,仅实现两个函数。

这些练习之间彼此独立,因此你可以采用任何顺序选择仅做其中一个练习或所有练习。 要点是获取一些有关驱动程序代码编写和构建的早期实例体验。

 

架构蓝图–软件架构 “4+1” 视图模型

架构蓝图–软件架构 “4+1” 视图模型

 

Philippe Kruchten, 高级技术专员

 

简介: 本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。使用多重视图允许独立地处理各”风险承担人”:最终用户、开发人员、系统工程师、项目经理等所关注的问题,并且能够独立地处理功能性和非功能性需求。本文分别对五种视图进行了描述,并同时给出了捕获每种视图的表示方法。这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。

引言

我们已经看到在许多文章和书籍中,作者欲使用单张视图来捕捉所有的系统架构要点。通过仔细地观察这些图例中的方框和箭头,不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。方框是代表运行的程序吗?或者是代表源代码的程序块吗?或是物理计算机吗?或仅仅是逻辑功能的分组吗?箭头是表示编译时的依赖关系吗?或者是控制流吗?或是数据流吗?通常它代表了许多事物。是否架构只需要单个的架构样式?有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面:数据工程、运行效率、开发策略和团队组织等。有时架构并不能解决所有”客户”(或者说”风险承担人”,USC 的命名)所关注的问题。许多作者都提及了这个问题:Garlan & Shaw        1、CMU 的 Abowd & Allen、SEI 的 Clements。作为补充,我们建议使用多个并发的视图来组织软件架构的描述,每个视图仅用来描述一个特定的所关注的方面的集合。


回页首
架构模型

软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配,从而满足系统主要功能和性能需求,并满足其他非功能性需求,如可靠性、可伸缩性、可移植性和可用性。Perry 和 Wolfe 使用一个精确的公式来表达,该公式由 Boehm 做了进一步修改:

软件架构 = {元素,形式,关系/约束}

软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构,该模型包含五个主要的视图(请对照图 1):

  • 逻辑视图(Logical View),设计的对象模型(使用面向对象的设计方法时)。
  • 过程视图(Process View),捕捉设计的并发和同步特征。
  • 物理视图(Physical View),描述了软件到硬件的映射,反映了分布式特性。
  • 开发视图(Development View),描述了在开发环境中软件的静态组织结构。

架构的描述,即所做的各种决定,可以围绕着这四个视图来组织,然后由一些用例 (use cases)或场景(scenarios)来说明,从而形成了第五个视图。正如将看到的,实际上软件架构部分从这些场景演进而来,将在下文中讨论。

图 1 - “4+1″视图模型 图 1 - "4+1"视图模型

我们在每个视图上均独立地应用 Perry & Wolf 的公式,即定义一个所使用的元素集合(组件、容器、连接符),捕获工作形式和模式,并且捕获关系及约束,将架构与某些需求连接起来。每种视图使用自身所特有的表示法-蓝图(blueprint)来描述,并且架构师可以对每种视图选用特定的架构风格(architectural style),从而允许系统中多种风格并存。

我们将轮流的观察这五种视图,展现各个视图的目标:即视图的所关注的问题,相应的架构蓝图的标记方式,描述和管理蓝图的工具。并以非常简单的形式从 PABX 的设计中,从我们在Alcatel 商业系统(Alcatel Business System)上所做的工作中,以及从航空运输控制系统(Air Traffic Control system)中引出一些例子―旨在描述一下视图的特定及其标记的方式,而不是定义这些系统的架构。

“4+1″视图模型具有相当的”普遍性”,因此可以使用其他的标注方法和工具,也可以采用其他的设计方法,特别是对于逻辑和过程的分解。但文中指出的这些方法都已经成功的在实践中运用过。

逻辑结构

面向对象的分解

逻辑架构主要支持功能性需求――即在为用户提供服务方面系统所应该提供的功能。系统分解为一系列的关键抽象,(大多数)来自于问题域,表现为对象或对象类的形式。它们采用抽象、封装和继承的原理。分解并不仅仅是为了功能分析,而且用来识别遍布系统各个部分的通用机制和设计元素。我们使用 Rational/Booch 方法来表示逻辑架构,借助于类图和类模板的手段        4。类图用来显示一个类的集合和它们的逻辑关系:关联、使用、组合、继承等等。相似的类可以划分成类集合。类模板关注于单个类,它们强调主要的类操作,并且识别关键的对象特征。如果需要定义对象的内部行为,则使用状态转换图或状态图来完成。公共机制或服务可以在类功能 (class utilities)中定义。对于数据驱动程度高的应用程序,可以使用其他形式的逻辑视图,例如 E-R 图,来代替面向对象的方法(OO approach)。

逻辑视图的表示法

逻辑视图的标记方法来自 Booch 标记法4。当仅考虑具有架构意义的条目时,这种表示法相当简单。特别是在这种设计级别上,大量的修饰作用不大。我们使用 Rational Rose? 来支持逻辑架构的设计。

图 2 - 逻辑蓝图的表示法 图 2 - 逻辑蓝图的表示法

逻辑视图的风格

逻辑视图的风格采用面向对象的风格,其主要的设计准则是试图在整个系统中保持单一的、一致的对象模型,避免就每个场合或过程产生草率的类和机制的技术说明。

逻辑结构蓝图的样例

图 3  显示了 Télic PABX 架构中主要的类。

图 3 - a. Télic PABX 的逻辑蓝图 b.空中交通系统的蓝图 图 3 - a. Télic PABX 的逻辑蓝图 b.空中交通系统的蓝图

PABX 建立终端间的通信连接。终端可以是电话设备、中继线(例如,连接到中央办公室)、连接线(PABX 专线到 PABX 线)、电话专线、数据线、ISDN 等等。不同的线路由不同的接口卡提供支持。线路 controller 对象的职责是在接口卡上对所有的信号进行解码和注入,在特定于接口卡的信号与一致性的小型事件集合之间进行相互转换:开始、停止、数字化等。controller 对象同时承载所有的实时约束。该类派生出许多子类以满足不同的接口类型。terminal 对象的责任是维持终端的状态,代表线路协调各项服务。例如,它使用 numbering plan 服务来解释拨号。conversation 代表了会话中的一系列终端 。conversation 使用了Translation Service(目录、逻辑物理映射、路由),以及建立终端之间语音路径的Connection Service 。

对于一个包含了大量的具有架构重要意义的类的、更大的系统来说,图 3 b 描述了空中交通管理系统的顶层类图,包含 8 个类的种类(例如,类的分组)。

进程架构

过程分解

进程架构考虑一些非功能性的需求,如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题,以及逻辑视图的主要抽象如何与进程结构相配合在一起-即在哪个控制线程上,对象的操作被实际执行。

进程架构可以在几种层次的抽象上进行描述,每个层次针对不同的问题。在最高的层次上,进程架构可以视为一组独立执行的通信程序(叫作”processes”)的逻辑网络,它们分布在整个一组硬件资源上,这些资源通过 LAN 或者 WAN 连接起来。多个逻辑网络可能同时并存,共享相同的物理资源。例如,独立的逻辑网络可能用于支持离线系统与在线系统的分离,或者支持软件的模拟版本和测试版本的共存。

进程是构成可执行单元任务的分组。进程代表了可以进行策略控制过程架构的层次(即:开始、恢复、重新配置及关闭)。另外,进程可以就处理负载的分布式增强或可用性的提高而不断地被重复。

软件被划分为一系列单独的任务。任务是独立的控制线程,可以在处理节点上单独地被调度。

接着,我们可以区别主要任务、次要任务。主要任务是可以唯一处理的架构元素;次要任务是由于实施原因而引入的局部附加任务(周期性活动、缓冲、暂停等等)。它们可以作为 Ada Task 或轻量线程来实施。 主要任务的通讯途径是良好定义的交互任务通信机制:基于消息的同步或异步通信服务、远程过程调用、事件广播等。次要任务则以会见或共享内存来通信。在同一过程或处理节点上,主要任务不应对它们的分配做出任何假定。

消息流、过程负载可以基于过程蓝图来进行评估,同样可以使用哑负载来实现”中空”的进程架构,并测量在目标系统上的性能。正如 Filarey et al. 在他的 Eurocontrol 实验中描述的那样。

进程视图的表示法

我们所使用的进程视图的表示方法是从Booch最初为 Ada 任务推荐的表示方法扩展而来。同样,用来所使用的表示法关注在架构上具有重要意义的元素。(图 4)

图 4 - 过程蓝图表示法 图 4 - 过程蓝图表示法

我们曾使用来自 TRW 的 Universal Network Architechure Services(UNAS0) 产品来构建并实施过程和任务集合(包扩它们的冗余),使它们融入过程的网络中。UNAS 包含 Software Architect Lifecycle Environment(SALE)工具,它支持上述表示方法。SALE 允许以图形的形式来描述进程架构,包括对可能的交互任务通信路径的规格说明,正是从这些路径中自动生成对应的 Ada 或 C++ 源代码。使用该方法来指定和实施进程架构的优点是易于进行修改而不会对应用软件造成太多的影响。

进程视图的风格

许多风格可以适用于进程视图。例如采用 Garlan 和 Shaw 的分类法1,我们可以得到管道和过滤器(Pipes and filters),或客户端/服务器,以及各种多个客户端/单个服务器和多个客户端/多个服务器的变体。对于更加复杂的系统,可以采用类似于 K.Birman 所描述的ISIS系统中进程组方法以及其它的标注方法和工具。

进程蓝图的例子

图 5 - Télic PABX 的过程蓝图(部分) 图 5 - Télic PABX 的过程蓝图(部分)

所有的终端由单个的 Termal process 处理,其中 Termal process 由输入队列中的消息进行驱动。Controller 对象在组成控制过程三个任务之中的一项任务上执行:Low cycle rate task 扫描所有的非活动终端(200 ms),将 High cycle rate task(10 ms)扫描清单中的终端激活,其中 High cycle rate task 检测任何重要的状态变化,将它们传递给 Main controller task,由它来对状态的变更进行解释,并通过向对应的终端发送消息来通信。这里 Controller 过程中的通信通过共享内存来实现。

开发架构

子系统分解

开发架构关注软件开发环境下实际模块的组织。软件打包成小的程序块(程序库或子系统),它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构,每个层为上一层提供良好定义的接口。

系统的开发架构用模块和子系统图来表达,显示了”输出”和”输入”关系。完整的开发架构只有当所有软件元素被识别后才能加以描述。但是,可以列出控制开发架构的规则:分块、分组和可见性。

大部分情况下,开发架构考虑的内部需求与以下几项因素有关:开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制。开发架构视图是各种活动的基础,如:需求分配、团队工作的分配(或团队机构)、成本评估和计划、项目进度的监控、软件重用性、移植性和安全性。它是建立产品线的基础。

开发蓝图的表示方法

同样,使用 Booch 方法的变形,仅考虑具有架构意义的项。

图 5 - 开发蓝图表示方法 图 5 - 开发蓝图表示方法

来自 Rational 的 Apex 开发环境支持开发架构的定义和实现、和前文描述的分层策略,以及设计规则的实施。Rational Rose 可以在模块和子系统层次上绘制开发蓝图,并支持开发源代码(Ada、C++)进程的正向和反向工程。

开发视图的风格

我们推荐使用分层(layered)的风格,定义 4 到 6 个子系统层。每层均具有良好定义的职责。设计规则是某层子系统依赖同一层或低一层的子系统,从而最大程度地减少了具有复杂模块依赖关系的网络的开发量,得到层次式的简单策略。

图 6 - Hughes 空中交通系统(HATS)的 5 个层 图 6 - Hughes 空中交通系统(HATS)的 5 个层

开发架构的例子

图 6 代表了加拿大的 Hughes Aircraft 开发的空中交通控制系统(Air Traffic Control system)产品线的 5 个分层开发组织结构。这是和图 3 b 描述的逻辑架构相对应的开发架构。

第一层 和第二层组成了独立于域的覆盖整个产品线的分布式基础设施,并保护其免受不同硬件平台、操作系统或市售产品(如数据库管理系统)的影响。第三层为该基础设施增加了 ATC 框架,形成一个特定领域的软件架构(domain-specific software architecture)。使用该框架,可以在第四层上构建一个功能选择板。层次 5 则非常依赖于客户和产品,包含了大多数用户接口和外部系统接口。72 个子系统分布于 5 个层次上,每层包含了 10 至 50 个模块,并可以在其他蓝图上表示。

物理架构

软件至硬件的映射

物理架构主要关注系统非功能性的需求,如可用性、可靠性(容错性),性能(吞吐量)和可伸缩性。软件在计算机网络或处理节点上运行,被识别的各种元素(网络、过程、任务和对象),需要被映射至不同的节点;我们希望使用不同的物理配置:一些用于开发和测试,另外一些则用于不同地点和不同客户的部署。因此软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。

物理蓝图的表示法

大型系统中的物理蓝图会变得非常混乱,所以它们可以采用多种形式,有或者没有来自进程视图的映射均可。

图 7 - 物理蓝图的表示法 图 7 - 物理蓝图的表示法

TRW 的 UNAS 提供了数据驱动方法将过程架构映射至物理架构,该方法允许大量的映射 的变更而无需修改源代码。

物理蓝图的示例

图 8 - PABX 的物理蓝图 图 8 - PABX 的物理蓝图

图 8 显示了大型 PABX 可能的硬件配置,而图 9 和图 10 显示了两种不同物理架构上的进程映射,分别对应一个小型和一个大型 PABX。C、F 和 K 是三种不同容量的计算机,支持三种不同的运行要求。

图 9 - 带有过程分配的小型 PABX 物理架构 图 9 - 带有过程分配的小型 PABX 物理架构
图10-显示了过程分配的大型PABX物理蓝图 图10-显示了过程分配的大型PABX物理蓝图

场景

综合所有的视图

四种视图的元素通过数量比较少的一组重要场景(更常见的是用例)进行无缝协同工作,我们为场景描述相应的脚本(对象之间和过程之间的交互序列)。正如 Rubin 和 Goldberg 所描述的那样6。

在某种意义上场景是最重要的需求抽象,它们的设计使用对象场景图和对象交互图来表示4。

该视图是其他视图的冗余(因此”+1″),但它起到了两个作用:

  • 作为一项驱动因素来发现架构设计过程中的架构元素,这一点将在下文中讨论。
  • 作为架构设计结束后的一项验证和说明功能,既以视图的角度来说明又作为架构原型测试的出发点。

场景的表示法

场景表示法与组件逻辑视图非常相似(请对照图 2),但它使用过程视图的连接符来表示对象之间的交互(请对照图 4),注意对象实例使用实线来表达。至于逻辑蓝图,我们使用 Rational Rose 来捕获并管理对象场景。

场景的例子

图 11 显示了小型 PABX 的场景片段。相应的脚本是:

1. Joe的电话控制器检测和校验摘机状态的变换,并发送消息唤醒相应的终端对象。

2. 终端分配一些资源,并要求控制器发出拨号音。

3. 控制器接受拨号并传递给终端。

4. 终端使用拨号方案来分析数字流。

5. 有效的数字序列被键入,终端开始会话。

图 11 - 本地呼叫的初期场景――阶段选择 图 11 - 本地呼叫的初期场景――阶段选择

视图之间的对应性

各种视图并不是完全是正交的或独立的。视图的元素根据某种设计规则和启发式方法与其他视图中的元素相关联。

从逻辑视图到过程视图

我们发现逻辑视架构有几项重要特性:

  • 自主性:对象是主动的、被动的还是被保护的?
    • 主动对象享有调用其他对象或其自身操作的主动权,并且当其他对象对其进行调用时,具有对其自身操作的完全控制权。
    • 被动对象不能主动调用任何操作,对其他对象调用自身的操作没有控制。
    • 被保护对象不能主动调用任何操作。但对自身的操作有一定的控制功能。
  • 持久化:对象是暂时的还是持久化的?它们是否会导致过程或处理器的终止?
  • 依赖性:对象的存在或持久化是否依赖于另一个对象?
  • 分布性:对象的状态或操作是否能被物理架构中的许多节点所访问?或是被进程架构中的几个进程所访问?

在逻辑视图中,我们认为每个对象均是主动的,具有潜在的”并发性”,即与其他对象具有”平行的”行为,我们并不考虑所要达到的确切并发程度。因此,逻辑结构所考虑的仅是需求的功能性方面。

然而,当我们定义进程架构时,由于巨大的开销,为每个对象实施各自的控制线程(例如,Unix 进程或 Ada 任务),在目前的技术状况下是不现实的。此外,如果对象是并发的,那么必须以某种抽象形式来调用它们的操作。

另一方面,由于以下几种原因需要多个控制线程。

  • 为了快速响应某类外部触发,包括与时间相关的事件。
  • 为了在一个节点中利用多个 CPU,或者在一个分布式系统中利用多个节点。
  • 为了提高 CPU 的利用率,在某些控制线程被挂起,等待其他活动结束的时候(例如,访问外部对象其他活动对象时),为其他的活动分配 CPU。
  • 为了划分活动的优先级(提高潜在的响应能力)。
  • 为了支持系统的可伸缩性(借助于共享负载的其他过程)。
  • 为了在软件的不同领域分离关注点。
  • 为了提高系统的可用性(通过 Backup 过程)。

我们同时使用两种策略来决定并发的程度和定义所需的过程集合。考虑一系列潜在的物理目标架构。以下两种形式我们可以任选其一:

  • 从内至外:
    由逻辑架构开始:定义代理任务,该任务将控制一个类的多个活动对象的单个线程进行多元化处理;同一代理任务还执行持久化处理那些依赖于一个主动对象的对象;需要相互进行操作的几个类或仅需要少量处理的类共享单个代理。这种聚合会一直进行,直到我们将过程减少到合理的较少数量,而仍允许分布性和对物理资源的使用。
  • 由外至内:
    从物理结构开始:识别系统的外部触发;定义处理触发的客户过程和仅提供服务(而非初始化它们)的服务器进程;使用数据完整性和问题的串行化(serialization)约束来定义正确的服务器设置,并且为客户机与服务器代理分配对象;识别出必须分布哪些对象。

其结果是将类(和它们的对象)映射至一个任务集合和进程架构中的进程。通常,活动类具有代理任务,也存在一些变形:对于给定的类,使用多个代理以提高吞吐量,或者多个类映射至单个代理,因为它们的操作并不是频繁地被调用,或者是为了保证执行序列。

注意这并不是产生最佳过程架构的线性的、决定性的进程;它需要若干个迭代来得到可接受的折衷。还存在许多其他方法,例如 Birman 等人5 或 Witt 等人7提出的方法。 确切的实施映射的方法不在本文的讨论范围,但我们以一个小的例子来说明一下。

图 12 显示了一个小的类集合如何从假想的空中交通控制系统映射至进程。

flight 类映射至一个 flight 代理集合:有许多航班等待处理,外部触发的频率很高,响应时间很关键,负载必须分布于多个 CPU。并且,航班处理的持久化和分布性方面都取决于 flight server,为了满足可用性,还是使用 flight server 的一台备份服务器。

航班的 profile 和 clearance 总是从属于某个航班,尽管它们是复杂的类,但它们共享 flight 类的进程。航班分布于若干其他进程,特别是对于显示和外部接口。

sectorization 类,为 controller 的权限分配建立了空域划分。由于完整性约束,仅能被一个代理处理,但可以与 flight 类共享服务器过程:更新得并不频繁。

location 和 arispace 及其他的静态航空信息是受到保护的对象,在几个类中共享,很少被更新;它们被映射至各自的服务器,分布于其他过程。

图 12 - 从逻辑视图到过程视图的映射 图 12 - 从逻辑视图到过程视图的映射

从逻辑视图到开发视图

类通常作为一个模块来实现,例如 Ada 包中可视部分的一个类型。密切相关的类(类的种类)的集合组合到子系统中。子系统的定义必须考虑额外的约束,如团队组织、期望的代码规模(通常每个子系统为 5 K 或 20 K SLOC)、可重用性和通用性的程度以及严格的分层依据(可视性问题),发布策略和配置管理。所以,通常最后得到的不是与逻辑视图逐一对应的视图。

逻辑视图和开发视图非常接近,但具有不同的关注点。我们发现项目规模越大,视图间的差距也越大。例如,如果比较图 3 b 和图 6,则会发现并不存在逐一对应的类的不同种类到层的映射。而如果我们考虑类的种类的”外部接口”-网关种类时,它的实现遍布若干层:通讯协议在第 1 层或以下的层,通用网关机制在第 2 层,而特定的网关在第 5 层子系统。

从进程视图到物理视图

进程和进程组以不同的测试和部署配置映射至可用的物理硬件。Birman 在 ISIS 项目中描述了详细的映射模式5。

场景主要以所使用类的形式与逻辑视图相关联;而与进程视图的关联则是考虑了一个或多个控制线程的、对象间的交互形式。

模型的剪裁

并不是所有的软件架构都需要”4+1″视图。无用的视图可以从架构描述中省略,比如: 只有一个处理器,则可以省略物理视图;而如果仅有一个进程或程序,则可以省略过程视图。  对于非常小型的系统,甚至可能逻辑视图与开发视图非常相似,而不需要分开的描述。场景对于所有的情况均适用。

迭代过程

Witt 等人为设计和架构指出了 4 个阶段:勾画草图、组织、具体化和优化,分成了 12 个 步骤7。他们还指出需要某种程度的反向工程。而我们认为对于大型的项目,该方法太”线性 化”了。在 4 个阶段的末尾,可用于验证架构的内容太少。我们提倡一种更具有迭代性质的方法,即架构先被原形化、测试、估量、分析,然后在一系列的迭代过程中被细化。该方法除了减少与架构相关的风险之外,对于项目而言还有其他优点:团队合作、培训,加深对架构的理解,深入程序和工具等等(此处提及的是演进的原形,逐渐发展成为系统,而不是一次性的试验性的原形)。这种迭代方法还能够使需求被细化、成熟化并能够被更好地理解。

场景驱动(scenario-driven)的方法

系统大多数关键的功能以场景(或 use cases)的形式被捕获。关键意味着:最重要的功能,系统存在的理由,或使用频率最高的功能,或体现了必须减轻的一些重要的技术风险。

开始阶段:

  • 基于风险和重要性为某次迭代选择一些场景。场景可能被归纳为对若干用户需求的抽象。
  • 形成”稻草人式的架构”。然后对场景进行”描述”,以识别主要的抽象(类、机制、过程、子系统),如 Rubin 与 Goldberg6 所指出的 ―― 分解成为序列对(对象、操作)。
  • 所发现的架构元素被分布到 4 个蓝图中:逻辑蓝图、进程蓝图、开发蓝图和物理蓝图。
  • 然后实施、测试、度量该架构,这项分析可能检测到一些缺点或潜在的增强要求。
  • 捕获经验教训。

循环阶段:

下一个迭代过程开始进行:

  • 重新评估风险,
  • 扩展考虑的场景选择板。
  • 选择能减轻风险或提高结构覆盖的额外的少量场景,

然后:

  • 试着在原先的架构中描述这些场景。
  • 发现额外的架构元素,或有时还需要找出适应这些场景所需的重要架构变更。
  • 更新4个主要视图:逻辑视图、进程视图、开发视图和物理视图。
  • 根据变更修订现有的场景。
  • 升级实现工具(架构原型)来支持新的、扩展了的场景集合。
  • 测试。如果可能的话,在实际的目标环境和负载下进行测试。
  • 然后评审这五个视图来检测简洁性、可重用性和通用性的潜在问题。
  • 更新设计准则和基本原理。
  • 捕获经验教训。

终止循环

为了实际的系统,初始的架构原型需要进行演进 。较好的情况是在经过 2 次或 3 次迭代之后,结构变得稳定:主要的抽象都已被找到。子系统和过程都已经完成,以及所有的接口都已经实现。接下来则是软件设计的范畴,这个阶段可能也会用到相似的方法和过程。

这些迭代过程的持续时间参差不齐,原因在于:所实施项目的规模,参与项目人员的数量、他们对本领域和方法的熟悉程度,以及该系统和开发组织的熟悉程度等等。因而较小的项目迭代过程可能持续 2-3 周(例如,10 K SLOC),而大型的项目可能为 6-9 个月(例如,700 K SLOC)。

架构的文档化

架构设计中产生的文档可以归结为两种:

  • 软件架构文档,其结构遵循”4+1″视图(请对照图 13,一个典型的提纲)
  • 软件设计准则,捕获了最重要的设计决策。这些决策必须被遵守,以保持系统架构的完整性。                                      图 13 - 软件架构文档提纲 图 13 - 软件架构文档提纲

回页首

结束语

无论是否经过一次本地定制的和技术上的调整,”4+1″视图都能在许多大型项目中成功运用。事实上,它允许不同的”风险承担人”找出他们就软件架构所关心的问题。系统工程师首先接触物理视图,然后转向进程视图;最终用户、顾客、数据分析专家从逻辑视图入手;项目经理、软件配置人员则从开发视图来看待”4+1″视图。 在 Rational 和其他地方,提出并讨论了其他系列视图,例如 Meszaros(BNR)、Hofmeister。Nord 和 Soni(Siemenms)、Emery 和 Hilliard(Mitre),但我们发现其他视图通常可以归入我们所描述的 4 个视图中的一个。例如 Cost&Schedule 视图可以归入开发视图,将一个数据视图归入一个逻辑视图,以及将一个执行视图归入进程视图和物理视图的组合。

表 1 - “4+1″视图模型一览表 表 1 - "4+1"视图模型一览表


回页首

致谢

“4+1” 视图的诞生要归功于在Rational、加拿大的 Hughes Aircraft、Alcatel 以及其他地方工作的同事。笔者特别感谢下面这些人的贡献: Ch. Thompson、A. Bell、M.Devlin、G. Booch、W. Royce、J. Marasco、R. Reitman、V. Ohnjec、E. Schonberg。

参考资料

  1. D. Garlan & M. Shaw, “An Introduction to Software Architecture,” Advances in Software Engineering and Knowledge Engineering, Vol. 1, World Scientific Publishing Co. (1993).
  2. D. E. Perry & A. L. Wolf, “Foundations for the Study of Software Architecture,” ACM Software Engineering Notes, 17, 4, October 1992, 40-52.
  3. Ph. Kruchten & Ch. Thompson, “An Object-Oriented, Distributed Architecture for Large Scale Ada Systems,” Proceedings of the TRI-Ada ’94 Conference, Baltimore, November 6-11, 1994, ACM,p.262-271.
  4. G. Booch: Object-Oriented Analysis and Design with Applications, 2nd. edition, Benjamin-Cummings Pub. Co., Redwood City, California, 1993, 589p.
  5. K. P. Birman, and R. Van Renesse, Reliable Distributed Computing with the Isis Toolkit, IEEE Computer Society Press, Los Alamitos CA, 1994.
  6. K. Rubin & A. Goldberg, “Object Behavior Analysis,” CACM, 35, 9 (Sept. 1992) 48-62
  7. B. I. Witt, F. T. Baker and E. W. Merritt, Software Architecture and Design-Principles, Models, and Methods, Van Nostrand Reinhold, New-York (1994) 324p.
  8. D. Garlan (ed.), Proceedings of the First Internal Workshop on Architectures for Software Systems, CMU-CS-TR-95-151, CMU, Pittsburgh, 1995.

 

原文出处 :

架构蓝图–软件架构 “4+1” 视图模型 : http://www.ibm.com/developerworks/cn/rational/r-4p1-view/