【架构师从入门到进阶】第一章：架构设计基础——第二节：架构设计原则

本篇文章我们来学习架构设计的原则，有这么三个原则，第一个是合适原则，第二个是简单原则，第三个是演化原则。

许多同学心中或多或少有成为架构师的想法，可是并不是说你把代码写好，就能成为一个架构师，优秀的程序员和架构师之间，还有一个明显的鸿沟需要跨越，这个鸿沟就是不确定性。对编程来说，它是不存在不确定性的，对于同样的一行代码，不管是谁写的，不管什么时候执行，执行的结果总是确定的，这里的确定呢，它不一定是正确性，也就是说哪怕这个程序运行的有bug，那它也是确定的。

但是。架构设计却不一样，架构设计的本质上，它就是不确定的。举一个例子，同样的一个系统。a公司和b公司做出来的架构，可能差异很大，但是最后它都能上线，都能正常的运行。还有同样需要存储，用MySQL也可以，用MongoDB也可以。

所以说架构设计没有像编程语言那样，通过语法进行约束，更多的时候，是面对多种可能性进行选择。选择也就意味着要做放弃，这才是考验架构师的地方。是选择业界最先进的技术呢，还是选择团队最熟悉的技术，这里面就会涉及到一些选择和放弃了，如果选择最先进的技术，那么后面出了问题该怎么办呢？没人会解决，如果选择最熟悉的技术，那后续的技术升级迭代该怎么办呢？是选择更强大、功能更完善的技术方案呢，还是选择更灵活的技术方案呢？这里面也就意味着选择和放弃。

其实关键在于架构设计领域并没有一套通用的方案来指导架构师进行架构设计，更多的是依赖架构师的经验和直觉。因此，架构设计也会被看成一项比较神秘的工作业务，千变万化，技术层出不穷，设计理念也是百花齐放，看起来似乎很难有一套通用的规范适合所有的架构设计场景。

但是呢，在研究了多个公司的架构设计的发展历史之后，从务虚的角度来说，他们都有这么这么几个共同的原则：合适，简单，演化。我们一一来说先说。

合适原则

第一个合适原则。

合适原则简单说就是“合适的就是最好的”。做技术的人总会有一个想法，总是想着做的特别的完美，这样不仅能够展示自己的优秀，还能达到一个好的绩效。梦想总是很美好的，但是也得考虑其他的方面，我们的成本，我们的时间，还有很多因素要考虑。

比如说要做一个系统，没有那么多人，没有那么多时间，却想干那么多的活。很多公司有着资源的限制，包括资金、时间、人员等等。如果说我们设计的太完美，太复杂，那么总会不如人意。人不够，时间不够，所以说总要有一些取舍的。

罗马不是一天建成的。很多大公司的方案，也不是在某一个时间点灵光一闪就设计出来了，它也是经过很长时间的沉淀、总结、甚至是失败才形成的。

还有一个点就是，冰山下面的才是最关键的，这是什么意思呢？大家想一下，我此时所说的冰山，就是你们看到人家优秀的架构方案，比如说淘宝优秀的架构方案。但是如果说只有十个人的公司在做，这个系统服务的用户只有1000个人，你想让这家公司设计出能扛得住双11流量的系统，那么估计是不可能的，就算他嘴上说他能设计出来，但是也没有办法经过实际的测试，最终能不能成谁也不知道。所以说不要只看到架构技术的厉害，还要看到它这么厉害的架构背后，它是如何被逼到那个份上的。淘宝最开始的时候也不是直接要达到双11流量，也是随着业务的发展一层一层累积起来被业务倒逼，然后技术促进业务，业务倒逼技术等等，是一个相辅相成的不停迭代的过程。所以说我们不仅要看到作为一个冰山露出水面的那一点点优秀的架构，还要看到它冰山下面，它有很多不为人知的地方。

总结一下。

• 环境总会有限制，不可能考虑的特别完美；
• 还有架构需要通过长时间的去累积，并不一定说现在就要把它做成怎么着；
• 不要看到别人的架构那么完美，我们就要盲目跟随，岂不知别人可能是业务倒逼，或者是大数据量把它催生的，为了解决当时的那个问题，就得设计一个好的架构。

真正优秀的架构，是在企业当前的人力条件，业务等各种约束下设计出来的。能够合理的将资源整合在一起，让他们发挥最大的功效，并且能够快速的落地。其实这也是很多BAT出来的架构师到了一些创业公司，反而做不出成绩的一个原因。因为他原来在公司有平台有资源，有他的积累，他把他在大厂的那一套的做法，生搬硬套到一个创业公司，大概率都是失败的。

简单原则

简单原则就是说能简单的把事情做好了，就不要去做复杂。每个人都喜欢简单的东西，越简单越好，工具的发展，包括我们编程语言其实也在发展，越来越往简单易用的方向去走。

很多公司在做架构方案设计的时候，有的架构师说：“我这个方案做的太简单了吧？都不好意思拿出去给别人讲，怕被人笑话，设计了半天，设计了这么简单的一个东西”。这是从人的这种虚荣或者说是要面子这一层来考虑的，一些初出茅庐的架构师可能会不自觉的追求架构的复杂性，看着花里胡哨一些，看着图上的各种流程多一些。

能简单解决问题就简单解决，复杂的设计不一定是有必要的。如果说你的业务没那么复杂，但是你架构设计的很复杂，那么你上线后出问题了，你要排查，你的排查就很复杂。所以说，能简单解决业务问题的，那就简单去解决，以后业务变复杂了，我们再升级再迭代。这个就是我们下面所说的演化原则，先简单设计，以后再慢慢的演化。

演化原则

我们进入下一个演化原则。这个演化原则，要把握一点，就是避免一步到位，要给事物的发展提供一个过程，要容忍它有这么一个过程。

架构这个词从哪来的呢？从建筑领域来的，在建筑领域中，建好一栋大楼之后几乎不会去动。比如上海中心，摩天大厦，或者东方明珠塔，或者说北京奥林匹克公园的大钉子，鸟巢水立方，建好之后几乎不会改了，不会再升级，不会再改外观，调个形状。

对建筑物来说，永恒是主题，但是对我们的软件系统来说呢，变化才是主题。软件架构需要根据业务的发展而不断变化。我们想一下，最开始设计WINDOWS的人，不可能一下子就设计出了现在的win11，因为那时候连平板电脑都没有，它怎么能设计一个适应平板电脑的操作系统呢。

我们不要想着一步到位，设计一个软件架构，期望不管业务如何变化，架构都稳如磐石，不要有这种期望，要有一定的容忍度，给它一个发展演进的空间。我们要把握一点，就是我们要牢记软件架构需要根据业务的发展不断的变化。建筑行业是做静态的建筑，是一个静态的过程，我们的软件行业更像是一个动态的生物。

首先，生物要适应环境，同样的类比过来就是我们的软件要解决当前的业务需要，这是第一点。第二个，生物要不停的繁殖将基因传递下去，优胜劣汰。同样的软件也要根据业务和使用场景的变化，不断的迭代修复缺陷，完善代码。最后当环境发生变化时，生物要适应环境，否则只能在大自然的选择下被淘汰。同样的，我们的软件也一样，当业务发生变化时，架构要扩展，要重构，要重写，这样才能伴随着软件一起成长。很多大公司都是这样过来的，很多大公司现在用的这种架构跟最开始根本就是完全两个样子，可以说必然是两个不同的样子。淘宝最开始和现在能一样吗？肯定是不一样的，完全是天翻地覆的变化。

所以说架构师在设计时呢，要牢记这个原则，时刻提醒自己不要贪大求全，不要盲目照搬大公司的做法，而是应该认真分析自己当前业务的特点，明确业务需要注意的问题。设计合理的架构快速落地，满足当前业务的需要，然后在运行过程中不断完善，不断成长，不断的演化。