从程序员到架构师，需要跨域一个鸿沟“不确定性”。在开发中，写出来的代码执行结果是确定的，但是对于架构来说，本质就是不确定的。同样的系统，A公司和B公司架构差异很大，但是都能运行。同一个方法，A方案也能做，B方案也能做，但是各有各的道理。相比编程，架构设计并没有向编程语言那样的语法来进行约束，更多的是面临多种可能性的选择。
业务千变万化，技术层出不穷，设计理念也是百花齐放，没有什么一套通用的规范适合所有的业务场景。所以，在进行架构设计中，一定要遵循几个原则，分别是：合适原则，简单原则，演化原则
合适原则
合适优于业界领先
优秀的人总想做点牛逼的东西，总会挑战自己。一上来就搞什么亿级流量大并发什么的，这样想和做这样做的架构，绝大部分都是失败了。好的架构都是适合当前公司的业务，需要一步步的实现。这里的一步步主要体现在以下几个方面
- 没有那么多人，却想做那么多活，这是失败的原因之一。
- 大公司分工很细，一个系统就是一个小组负责。大部分公司研发团队就只有100多人，甚至都没有。却想把系统做的更好，更完美。也不是不可能，但是难度是可想而知的。
- 没有那么多的积累，却想一步登天，这是失败的原因之一。
- 架构设计并不是靠灵机一动就出来的，单纯的靠头脑风暴，是不可能和实战中遇到的困难同日而语的。
- 没有大的业务场景，却幻想成为天才，这是失败的原因之一。
- 更多的时候，优秀的架构都是被逼出来的。业务发展到一定程度，量变导致了质变。先有的方式已经无法解决新的问题，才需要一种新的方案来解决，通过创新和尝试，才有了先进的方案。
简单原则
简单优于复杂
软件领域的复杂性只要在两个方便，结构复杂和逻辑复杂。
- 结构复杂，业务发展越多，组件越多。就越有可能其中几个组件出现故障，导致相同故障。如果需要改动一个组件，有可能还会影响到其他组件。定位一个故障的组件需要花费更多的时间，精力。
- 逻辑复杂，业务发展也就伴随着逻辑的复杂性越来越大。可能会引用一些复杂的算法，进而导致整个系统难以理解，难以修改。
无论是结构复杂还是逻辑复杂，都会存在着一些问题。所以架构设计时如果简单的方案和复杂的方案都能解决问题，一定要选择简单的方案。
演化原则
演化优于一步到位
对比建筑学，建筑一旦完成，甚至设计图一旦定稿，就不会改变，而软件需要根据业务的发展不停的变化。对于建筑学来说，永恒时主题；对于软件来说，变化时主题。软件架构设计需要根据业务不断变化发展，需要一个变化的过程
- 首先设计出来的架构要满足当时的业务需要。
- 架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使架构不断的完善。
- 当业务发生变化时，架构需要扩展、重构、甚至重写。代码也可能会重写，但是有价值的经验，教训，逻辑。设计却在新的架构中延续。
结语
架构师在进行架构设计的时候，需要记住这三条原则，时刻提醒自己不要贪大求全，或者盲目的抄大公司的做法。应该理清当前的业务特点，明确要面临的问题，设计合理的架构，满足当前业务的需要，然后在运行过程中不断的完善架构，不断随着业务演化架构。
#架构
