架构学习之旅-架构设计三大原则

架构设计的三大原则是简单、合适、演化

架构设计领域并没有一套通用的规范来指导架构师进行架构设计，更多是依赖架构师的经验和直觉，因此架构设计有时候也会被看作一项比较神秘的工作。

一、简单原则

前面的文章我们有说到，架构设计的目的是解决软件系统复杂度带来的问题，因此我们应当尽量的避免由于架构设计导致的复杂度增加的问题，这里之所以说是尽量避免，是因为在部份场景下，一些系统的设计需要满足某些特性时，系统设计不由得的变得更加复杂，例如微信的架构设计、12306的架构设计都远比普通项目更加复杂。

但是我们在设计过程中，要遵循“简单优于复杂“的原则。比如有两套架构方案都能解决目前问题。那么我们应当优先选择简单方案。

而软件领域的复杂性通常体现在两个方面，架构复杂性和逻辑复杂性，在权衡简单方案时，我们可以从这两个方面进行评估。

1、结构复杂性

其表现在组件数量更多，组件之间的关系更加复杂。

我们可以用公司来进行比较。小公司的人员少，部门组织架构少，因此人员关系更加简单易于维护。而大公司的人员多，组织架构部门多，部门之间的关联，远比小公司更加复杂，需要投入更多的工具和人员进行维护。


其复杂性问题在于：

• 组件越多，越有可能其中某个组件出现故障
• 某个组件改动，会影响关联的所有组件
• 定位一个复杂系统中的问题总是比简单系统更加困难

以微服务系统举例，微服务越多，服务出现问题的概率就会增加，某个服务出现问题，可能会影响很多其他服务，微服务越多，链路越长，定位某个问题可能涉及的服务变多，从而导致排查难度增加

2、逻辑复杂性

主要体现在逻辑复杂和功能复杂两个方面，通常逻辑复杂的组件，一个比较典型的特征就是这个组件承担了太多的职责，比如PHP的大单体服务，通常其项目复杂性相对较高

而功能复杂的组件，另外一个典型特征就是采用了复杂的算法。复杂算法导致的问题主要是难以理解，进而导致难以实现、难以修改，并且出了问题难以快速解决。

复杂的架构通常可以承担更大的职责，但是复杂架构会带来很多的问题，这是因为需求是不断产生的，因此需要我们不断的对系统进行修改，所以复杂性系统的维护成本通常会更高

二、合适原则

好的不一定合适，正确的也不一定合适，这段话放在架构设计中也是适用的。在架构设计中，我们应当遵循“合适优先业界领先”原则

进行系统设计时，需要脚踏实地的根据实际情况进行，考虑几个因素：

是否有充足的资源？

是否有足够的积累？

是否符合业务场景？

优秀的程序员总有一个技术执念，想设计出很“牛逼”的东西。

当你只有几个人的资源时，想做几十个人团队的事情，难度非常大，所以在设计过程中，必须考虑你目前的资源情况，避免“饼”画大了，吃不下了。

而当你知识储备、团队能力不足时，不要妄想一步登天，罗马从来不是一天建成的，一个优秀的技术架构，必然是经历了长期的发展而演化而来的，业界很多领先的方案，也是前辈一个个坑踩出来的，好处就是我们可以借鉴这些已有的经验，在以前网络没那么发达的时代，前辈们只能翻外国书籍，或者自己探索。【实战+借鉴】 是很好的学习捷径。

如果没有卓越的业务场景，却幻想做出非常牛逼的架构，也是不大可能的。
比如一家做IM的小公司，想设计一个亿级用户平台，基本上只能以失败告终。

所以真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。

三、演化原则

谈恋爱都需要磨合期，架构设计也很难一步到位，在系统设计过程中，要遵照“演化优于一步到位”的原则。

和很多东西不同的是，一个架构是要承担很多年的摧残的。我们以房屋建造举例。一旦房子的架构确定下来了。后面基本上要改就得重建（或者是小部份重建），其成本是非常高的，这也是为什么架构设计是一件非常严肃的事情（因为定下来了就不好改了）

但是不一样的是，对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。

因此我们不要期望一步到位设计一个软件架构，可以一直支撑不断变化的业务。

所以架构师在做架构设计的时候，应当认真分析当前业务的痛点，明确业务主要面临的问题，来设计出合理的架构，快速落地，然后在业务发展过程中，去不断的完善和演化，不管多牛的人，也不大可能完美预测所有的业务发展路径。

生物的演化规则过程是：

• 先适应当前环境
• 不断繁殖，剔除不利基因，传递有效基因
• 生物环境变化后，快速改变适应，适者生存

而架构有着类似的过程：

• 先设计满足当时需要的架构
• 在实际应用过程中不断的迭代，保留优秀设计，剔除无效设计，完善架构
• 当业务发生变化时，进行拓展、重构、重写，延续优良设计

所以要一步一步来，不可贪大求全，盲目从众。做什么事都一样的。
（因此这篇就到这了，🤣）