成为一名架构师是每个程序员的梦想,但这并不意味着如果您做得好,就能成为一名架构师。 好的程序员和架构师之间存在的差距是非常明显的,这个差距是“不确定性”。对于编程,基本上没有不确定性。而就架构设计而言,它本质是不确定的,对于同一个系统,公司A和公司B制作的体系结构可能会非常不同,但最终它们都可以正常工作。 对于相同的解决方案,设计者A认为应该这样做,设计师B认为应该做到这一点,这似乎是有道理的。与编程相比,架构设计没有像编程语言那样的语法来约束,更多的时候是面对多种可能性时进行选择。
在充分了解众多的互联网公司架构设计后,会发现有几个共性的原则隐含其中,这就是:合适原则、简单原则、演化原则,架构设计时遵循这几个原则,有助于做出最好的选择。
合适原则
合适原则宣言:“合适优于业界领先”。
优秀的技术人员都有很强的技术情结,当他们做方案或者架构时,总想不断地挑战自己,想达到甚至优于业界领先水平是其中一个典型表现,因为这样才能够展现自己的优秀,才能在年终KPI绩效总结里面骄傲地写上“设计了XX方案,达到了和Google相同的技术水平”“XX方案的性能测试结果大大优于阿里集团的YY方案”。
但现实是,大部分这样想和这样做的架构,最后可能都以失败告终!我在互联网行业见过“亿级用户平台”的失败案例,2011年的时候,某个几个人规模的业务团队,雄心勃勃的提出要做一个和腾讯QQ(那时候微信还没起来)一拼高下的“亿级用户平台”,最后结果当然是不出所料的失败了。
简单原则
简单原则宣言:“简单优于复杂”。
软件架构设计是一门技术活。所谓技术活,从历史上看,无论是瑞士的钟表,还是瓦特的蒸汽机;无论是莱特兄弟发明的飞机,还是摩托罗拉发明的手机,无一不是越来越精细、越来越复杂。因此当我们进行架构设计时,会自然而然地想把架构做精美、做复杂,这样才能体现我们的技术实力,也才能够将架构做成一件艺术品。
由于软件架构和建筑架构表面上的相似性,我们也会潜意识地将对建筑的审美观点移植到软件架构上面。我们惊叹于长城的宏伟、泰姬陵的精美、悉尼歌剧院的艺术感、迪拜帆船酒店的豪华感,因此,对于我们自己亲手打造的软件架构,我们也希望它宏伟、精美、艺术、豪华……总之就是不能寒酸、不能简单。
团队的压力有时也会有意无意地促进我们走向复杂的方向,因为大部分人在评价一个方案水平高低的时候,复杂性是其中一个重要的参考指标。例如设计一个主备方案,如果你用心跳来实现,可能大家都认为这太简单了。但如果你引入ZooKeeper来做主备决策,可能很多人会认为这个方案更加“高大上”一些,毕竟ZooKeeper使用的是ZAB协议,而ZAB协议本身就很复杂。其实,真正理解ZAB协议的人很少(我也不懂),但并不妨碍我们都知道ZAB协议很优秀。
演化原则
演化原则宣言:“演化优于一步到位”。
软件架构从字面意思理解和建筑结构非常类似,事实上“架构”这个词就是建筑领域的专业名词,维基百科对“软件架构”的定义中有一段话描述了这种相似性:从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。例如,软件架构描述的是一个软件系统的结构,包括各个模块,以及这些模块的关系;建筑架构描述的是一幢建筑的结构,包括各个部件,以及这些部件如何有机地组成成一幢完美的建筑。然而,字面意思上的相似性却掩盖了一个本质上的差异:建筑一旦完成(甚至一旦开建)就不可再变,而软件却需要根据业务的发展不断地变化。
通过上述关于架构设计三原则的介绍,相信您对架构设计有了进一步的理解吧,想了解更多关于架构设计的信息,请继续关注中培伟业。