成为一名架构师是每个程序员的梦想，但这并不意味着如果您做得好，就能成为一名架构师。 好的程序员和架构师之间存在的差距是非常明显的，这个差距是“不确定性”。对于编程，基本上没有不确定性。而就架构设计而言，它本质是不确定的，对于同一个系统，公司A和公司B制作的体系结构可能会非常不同，但最终它们都可以正常工作。 对于相同的解决方案，设计者A认为应该这样做，设计师B认为应该做到这一点，这似乎是有道理的。与编程相比，架构设计没有像编程语言那样的语法来约束，更多的时候是面对多种可能性时进行选择。

在充分了解众多的互联网公司架构设计后，会发现有几个共性的原则隐含其中，这就是：合适原则、简单原则、演化原则，架构设计时遵循这几个原则，有助于做出最好的选择。

 合适原则

 合适原则宣言：“合适优于业界领先”。

优秀的技术人员都有很强的技术情结，当他们做方案或者架构时，总想不断地挑战自己，想达到甚至优于业界领先水平是其中一个典型表现，因为这样才能够展现自己的优秀，才能在年终KPI绩效总结里面骄傲地写上“设计了XX方案，达到了和Google相同的技术水平”“XX方案的性能测试结果大大优于阿里集团的YY方案”。

但现实是，大部分这样想和这样做的架构，最后可能都以失败告终!我在互联网行业见过“亿级用户平台”的失败案例，2011年的时候，某个几个人规模的业务团队，雄心勃勃的提出要做一个和腾讯QQ(那时候微信还没起来)一拼高下的“亿级用户平台”，最后结果当然是不出所料的失败了。

 简单原则

 简单原则宣言：“简单优于复杂”。

软件架构设计是一门技术活。所谓技术活，从历史上看，无论是瑞士的钟表，还是瓦特的蒸汽机;无论是莱特兄弟发明的飞机，还是摩托罗拉发明的手机，无一不是越来越精细、越来越复杂。因此当我们进行架构设计时，会自然而然地想把架构做精美、做复杂，这样才能体现我们的技术实力，也才能够将架构做成一件艺术品。

由于软件架构和建筑架构表面上的相似性，我们也会潜意识地将对建筑的审美观点移植到软件架构上面。我们惊叹于长城的宏伟、泰姬陵的精美、悉尼歌剧院的艺术感、迪拜帆船酒店的豪华感，因此，对于我们自己亲手打造的软件架构，我们也希望它宏伟、精美、艺术、豪华……总之就是不能寒酸、不能简单。

团队的压力有时也会有意无意地促进我们走向复杂的方向，因为大部分人在评价一个方案水平高低的时候，复杂性是其中一个重要的参考指标。例如设计一个主备方案，如果你用心跳来实现，可能大家都认为这太简单了。但如果你引入ZooKeeper来做主备决策，可能很多人会认为这个方案更加“高大上”一些，毕竟ZooKeeper使用的是ZAB协议，而ZAB协议本身就很复杂。其实，真正理解ZAB协议的人很少(我也不懂)，但并不妨碍我们都知道ZAB协议很优秀。

 演化原则

 演化原则宣言：“演化优于一步到位”。

软件架构从字面意思理解和建筑结构非常类似，事实上“架构”这个词就是建筑领域的专业名词，维基百科对“软件架构”的定义中有一段话描述了这种相似性：从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。例如，软件架构描述的是一个软件系统的结构，包括各个模块，以及这些模块的关系;建筑架构描述的是一幢建筑的结构，包括各个部件，以及这些部件如何有机地组成成一幢完美的建筑。然而，字面意思上的相似性却掩盖了一个本质上的差异：建筑一旦完成(甚至一旦开建)就不可再变，而软件却需要根据业务的发展不断地变化。

通过上述关于架构设计三原则的介绍，相信您对架构设计有了进一步的理解吧，想了解更多关于架构设计的信息，请继续关注。