欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

怎样才是一个好的架构? 博客分类: 编程思想技术  

程序员文章站 2024-02-12 14:26:58
...

关于软件设计的抽象思想

 曾经被阿里的某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服务,服务治理,携程基本上是一个处于初级阶段的大型系统。