首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件架构设计 >

怎么才是一个好的架构

2012-06-27 
怎样才是一个好的架构?关于软件设计的抽象思想?曾经被阿里的某CTO问过一个问题:什么是好的架构?? ? 听到这

怎样才是一个好的架构?

关于软件设计的抽象思想

?曾经被阿里的某CTO问过一个问题:什么是好的架构?

? ? 听到这种最著名的开放式问题,我心里“咯噔”一下,心想:“又来了”。

一个老生常谈,莫衷一是的话题,得与失只在一念之间。

贤哲们的思想,犹如星辰遗落的闪光碎片,美丽零散;正如人生哲理,再著名的编程思想也是一样的细碎不成体系,在现实的复杂性面前会被毫不留情的击得粉碎。但是他山之石可以攻玉,如果不了解那些名词,想必设计思维还会有所欠缺。

下面尝试整理一下我所思考过的那些问题。

架构的原罪:变与不变

软件之所以称为“software”,根本性的原因就在于它是可变的。要修改一个硬件,必须用物理化学手段如高温、高压、强酸、化合等等原子分子级别的操作,而且往往是不可逆的。在计算机发明以前,人类文明几万年的历史,主要是硬件史。更快更简单的造出或掠夺更好的硬件,就是生产力。计算机发明以后,另一个位面:虚拟世界诞生了。在这个位面里,改变衣服的颜色不是先漂白再用着色剂染色,而是修改一个RGB数字;发射子弹不是通过机簧的张力而是一个函数调用;核爆炸试验不需要原子反应而是CPU计算。通过二进制将模拟世界转变换成数字世界,世界的一小部分能通过电磁现象得以模拟,最直接的也是最大的红利就是:相比物质时代,改变的代价变得前所未有的小,促使生产力的爆发性增长。

软件变动的代价再怎么小,我们也仍然觉得麻烦。市场经济下,人类对生产力的追求是无止境的。所以,软件设计的核心追求是:尽可能不变!由于这个潜在的原动力,虚拟位面的造物主开始借鉴现实世界的一切智慧结晶。西方建筑学的计模式(或者我国宋代逆天的《营造法式》?),机械制造的标准件,音乐的结构、曲式、旋律等乐理,社会组织制度,生物,化学,工艺流程,甚至简单到积木和钩子,无一不是造物主们灵感的源泉。(题外话:好程序员应该是博学的,只有精通现实世界才能更好的构造虚拟世界嘛)

为了救赎“变”这个原罪,造物主有个很直觉的思路:

“将变与不变相隔离!”

这句话在软件设计史上的地位相当于原始海洋中细胞膜的诞生,毫不起眼,但是意义无远弗届。统治当代编程思想的面向对象由此发轫。数据和方法一朝碰头,有趣的概念就自然而然的诞生了:类,对象,消息,接口,抽象,继承,多态,封装,复用,多么像一群单细胞生物啊!

造物主当然不会止步于此。类和类可以通过各种设计模式(factory、abstract factory、builder、bridge,command,decorator,flyweight,iterator,mediator,observer,proxy,facade,singleton,chain of responsibility,vistor,state,strategy,template)组成类库或模块,他们遵循的原则包括:“单一职责”,“开闭”,“liskov替换”,“依赖倒置”,“接口隔离”,“重用发布等价”,“共同封闭重用”,“无环稳定依赖”,“稳定抽象”等,到此为止,多细胞生物诞生了!模块一般表现为一个包,为了解决依赖性封装为OSGI、maven、jigsaw或者js的AMD,nodejs的npm,ruby的gem,debian的apt等。

???????? “将变与不变相隔离”,说得fashion一点就是“解耦”,通俗一点就是“把会变的逻辑用设计技巧从稳定的逻辑中抽取出来,使软件设计不用修改就能适应需求的变化”。一个合格的架构师要具备厘清问题领域中哪些是变,哪些是不变,哪些是可能变的洞察力,需要对各种设计技巧和优劣心知肚明,然后才能开始着手设计。这种洞察力在基础软件领域有一些成熟的经验,譬如管道、请求响应、MVC、IOC、代理等等,由于基础应用的需求稳定,所以这种架构的着眼点更关注灵活性、扩展性、性能等方面,学习参考Spring、Jetty、Netty、Nginx。在应用软件领域,这个洞察力就不太靠谱了,因为软件的用户变成了人,逻辑像野草一样不可控起来。费尽心力设计一个优雅的系统,客户的一句话就得改头换面。架构师很痛苦,尤其在web方面,很少见到在逻辑层用上什么设计模式,如果用上了,基本也是吃力不讨好的后果。“变”与“不变”,是架构师需要学习的第一堂课,是指导我们行动的准则。一个逻辑,如果无法判断其稳定性,就不要花费精力设计,否则迟早掉入“过度设计”的坑里。

??????? 架构的抉择:选择合适的技术而不是最好的技术

??????? 多细胞生物怎么协作呢?模块通过各种纤尘、线程或进程运行,与进程内或进程外甚至远程的其他模块以各种稀奇古怪的方式通信,包括函数调用、共享内存、文件、管道、消息、信号量、socket,这些通信方式有的还涉及到序列化和反序列化,譬如RMI、hessian、xml、json、thrift、protobuf、phprpc、amf、avro等。模块接着整合为应用,在OS或虚拟机上运行,抢夺CPU指令流水,占领内存,处理IO的IN/OUT,把虚拟世界运转起来。应用可以扩张成集群,不管是水平扩展还是垂直扩展,通过代理服务器、负载均衡路由、LVS等方式,IO、Memory和CPU的负载可以得到分流,从而架构出大规模计算集群;反之汇总集群计算结果的方式有map/reduce、集中式存储等。基本从家庭发展到了部落。已经有了生物聚集性,离蚁群的群体智慧还有一步之遥。现在方兴未艾的云平台和开放平台浪潮,则进一步将各个部落开放出来,各个平台通过互联网也具备了整体协作的简单能力。

??????? 我们处在这样一个空前复杂的虚拟生态系统之中,能选择的实在太多了。作为架构师,这是一个整合的时代!

选择合适的机房,合适的硬件,合适的平台,合适的语言,合适的框架,合适的数据存储,合适的分布式,合适的协议,

到处都是选择题。怎么选?

??????? 如果你头脑惯于发热,或者极度追求高端技术,甚至是为了技术而技术却忘了产品的成功才是你应该追求的目标,你往往会做出一些漂亮的架构,能为简历增光添彩,但却对团队伤害至深。要选择最合适的技术,而不是最好的技术。就像算法的本质是空间与时间的博弈,架构的本质是开发效率和产品目标的平衡。开发快,运行快,可扩展,能重用,好测试,容易部署,便于运维,学习成本低,好招人,甚至公司的中远期规划,这些责任是架构师必须铭记在心。架构师要慎重抉择每一项技术,有针对性的做性能测试,压力测试,代码实现,周边工具调查等实际的劳务。你应该对各种性能参数了如指掌。JVM一次普通方法调用,一次反射方法调用,一个事务插入,索引查询,一次http通讯,一个memcache set操作的耗时这些细枝末节往往是决定架构成败的关键。

??????? 在我决定离职的那段时间里,我一直在反思两年中公司所犯下的错误。除了产品的问题,技术架构也是一个决定性的败因。由于未知的历史原因,公司形成了C++,Flash,Java三个技术团队,互不统属,用网络游戏的架构加上千万PV的web架构开发两套互联的产品,技术很复杂,迭代很迟钝。作为java架构师,我也是很缓慢的才觉察到大局的失误。大错已成!到我管理整个技术部时有心杀贼无力回天。这段创业失败的经历教会我很多,其中之一就是:合适的目标加上合适的技术才是王道,不要好高骛远,不要追高求新,在创业初始阶段开发效率和用户体验是第一位的。

?

相关架构参考:

一个架构已经存在并良好运作了,还有什么要做的?要防止它腐化!与时俱进。这又是个大课题,幸亏有人写得比我好多了:http://www.infoq.com/cn/articles/cjz-architecture-corruption?作者是前yahoo工程师陈金洲,应该还有人记得他写的buffalo框架吧,我很喜欢用。


携程网的架构演化:http://www.infoq.com/cn/presentations/ly-ctrip-on-soa

? ? ?讲的比较实在和翔实,现实的世界里不只是漂亮的图表,而是要把繁杂的遗留系统优化成井井有条的理想世界。SOA架构,简单的分布式事务,ESB服务,服务治理,携程基本上是一个处于初级阶段的大型系统。

?

?

?

?

热点排行