08 | 架构设计三原则
2018-05-15 李运华
《从 0 开始学架构》
课程介绍
讲述：黄洲君
时长:大小8.05M
前面几期专栏，我跟你系统的聊了架构设计的主要目的是为了解决软件系统复杂度带来的问题，并分析了复杂度的来源。从今天开始，我会分两期讲讲架构设计的 3 个原则，以及架构设计原则的案例。
成为架构师是每个程序员的梦想，但并不意味着把编程做好就能够自然而然地成为一个架构师，优秀程序员和架构师之间还有一个明显的鸿沟需要跨越，这个鸿沟就是“不确定性”。
对于编程来说，本质上是不能存在不确定的，对于同样一段代码，不管是谁写的，不管什么时候执行，执行的结果应该都是确定的（注意：“确定的”并不等于“正确的”，有 bug 也是确定的）。而对于架构设计来说，本质上是不确定的，同样的一个系统，A 公司和 B 公司做出来的架构可能差异很大，但最后都能正常运转；同样一个方案，A 设计师认为应该这样做，B 设计师认为应该那样做，看起来好像都有道理……相比编程来说，架构设计并没有像编程语言那样的语法来进行约束，更多的时候是面对多种可能性时进行选择。
可是一旦涉及“选择”，就很容易让架构师陷入两难的...
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
精选留言
公号-技术夜未眠2018-05-15今日得到
架构即决策。架构需要面向业务需求，并在各种资源（人、财、物、时、事）约束条件下去做权衡、取舍。而决策就会存在不确定性。采用一些高屋建瓴的设计原则有助于去消除不确定，去逼近解决问题的最优解。
1 合适原则
架构无优劣，但存合适性。“汝之蜜糖，吾之砒霜”；架构一定要匹配企业所在的业务阶段；不要面向简历去设计架构，高大上的架构不等于适用；削足适履与打肿充胖都不符合合适原则；所谓合适，一定要匹配业务所处阶段，能够合理地将资源整合在一起并发挥出最大功效，并能够快速落地。
2 简单原则
"我没有时间写一封短信，所以只好写一封长信"。其实，简单比复杂更加困难。面对系统结构、业务逻辑和复杂性，我们可以编写出复杂的系统，但在软件领域，复杂代表的是“问题”。架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案。但是，事实上，当软件系统变得太复杂后，就会有人换一个思路进行重构、升级，将它重新变得简单，这也是软件开发的大趋势。 简单原则是一个朴素且伟大的原则，Google的MapReduce系统就采用了分而治之的思想，而背后就是将复杂问题转化为简单问题的典型案例。
3 演化原则
大到人类社会、自然生物，小到一个细胞，似乎都遵循这一普世原则，软件架构也不例外。业务在发展、技术在创新、外部环境在变化，这一切都是在告诫架构师不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。怀胎需要十月，早一月或晚一月都很危险。展开共 5 条评论229
@漆~心endless2018-05-17架构设计三原则；
合适原则最适合；
简单原则不简单；
演化原则需推进；
如若脱离三原则；
老板生气你苦逼。展开作者回复: 确认过眼神，你是油菜花的人！！😂😂😂
共 2 条评论62
石同享2018-05-15合适原则是不是可理解为：确定了一定的系统复杂度之后，能承受其包括性能，可用性，可拓展性，成本，安全方面的最小代价解(简单原则)，而演化原则是对上述系统的迭代优化。这样和之前的内容都可以联系起来了。作者回复: 是的，我的思路就是这样的，三个原则是一体的，三个原则与架构设计的目的也是一脉相承的
34
桌小洛2018-08-11总结的很好，架构设计原则:
合适原则: 有多大的脚（复杂度），穿多大码的鞋。BAT或者业界领先的架构对很多团队和公司来说都是大码的鞋而已，穿上不合适的鞋，团队必定步履蹒跚，很难走的很远，还有可能摔倒（项目失败）。
但是如果能根据自己的业务需求，对BAT或者业界领先的架构进行仔细调研，进行删减，重新取其一部分组合成适合自己的架构，也是非常好的方法。
简单原则: 我感觉改成简洁原则更合适，简单+整洁。360行皆是艺术，架构也是一门艺术。一个复杂的系统，如果能用一个简洁的架构来实现，完全相当于一个艺术品。 相反，如果一个普通的系统，反而被设计成了一个错综复杂的复杂架构，相当于做了一个糟粕品。
演化原则: 通过 简化设计 + 重构 来保证架构的与时俱进。不要前期就对架构进行过度设计，毕竟无论你前期怎么设计，总会有你意想不到的变化产生，唯一不变的就是变化。等你的脚长大了，再去穿大码的鞋。展开作者回复: 你的解读很形象👍👍
22
narry2018-05-15个人感觉合适原则是最重要的，它决定了对简单原则和演化原则的判断，没有以合适为基础，很难判断简单是否能满足业务的需求，演化的起点在哪里19
何磊2018-05-15三大原则：合适原则，简单原则，演进原则。
最重要的莫过于合适原则，如果不合适，无意欲削足适履，团队感觉难受，业务不稳定等，因此架构设计的第一原则一定是合适，合适当前的业务，合适当前的团队，合适当前的成本（时间与资本）
其二简单原则，这是一个相对原则，是在合适的基础上进行选择最简单方案，绝不能孤立，并且简单是自己业务的对比，比如：当前淘宝的架构每次迭代，他们选择一个简单方案，但他们的简单不意味着我们的简单。
关于演进原则，系统一定变化的、生长的，但是他们的起跑点肯定不同，比如大公司造的系统都是富二代，他会从微服务开始演进，十个人的小团队会从单体应用演进。
对于上面三个原则，演进原则其实我觉得考不考虑，他都存在，只要你的业务继续，不过好的架构有助于可扩展性，让后续演进更丝滑般流畅，不好的架构到了某个阶段只能重来。展开作者回复: 恰恰“演进原则”很多人不知道，总想一步到位，过度设计
共 2 条评论15
Loy2018-05-18发现这三个选择放在爱情上，也完全没毛病作者回复: 爱情怎么演化？😂😂
共 4 条评论13
SHLOMA2018-05-21题外话，如何说服领导，合适大于先进😂作者回复: 人手不够，工期太长，成本太高，没有合适的人才……😃
共 3 条评论12
查理2018-05-17演进很重要，很多人都喜欢过度设计，简单的东西搞复杂。其实以后系统怎样变化很多过度的预测都不准，还不如让系统在一开始保持精简一点，根据需求慢慢演进作者回复: 赞同，预测太长没有意义，也预测不准
共 3 条评论9
Forrest Li2018-07-04面对不确定性，架构师始终要做出一个选择，而三个原则遵循着解决问题的思路，提供了选择的依据。首先是合适，能够解决问题，其次是从合适中挑选简单的、能hold住的方案，最后，不要指望一个方案能解决所有问题，总会有弊端、不足，在碰到未来无法预料的情况时再做调整就是。变是永远不变的。作者回复: 仅此一家，别无分店的三原则😄
5
钰湚—付晓岩2018-05-17我们之前花了多年时间进行了一次全范围的架构升级，几乎重做了所有主力系统，这个过程中，我的体会其实跟三原则非常接近，尤其是演化原则，大公司的复杂系统永远不可能一步到位，甚至较长的工期本就会导致原有设计在最终实现时就已经落后，复杂系统的架构只能是演化迭代的，这其中即有技术因素也有业务因素，有工艺的复杂也有人的复杂；简单原则，实际上是对单一职责的追求，但是对大型系统而言，单一职责也会带来通讯的复杂，调用的复杂，大型系统清晰的逻辑分层并不容易实现，如果涉及多方协同施工，单一职责更难贯彻，尽管大家都认可，但是实现起来并不容易；合适原则非常正确，不过可惜的是，它经常不是甲方的原则。这三原则对于架构设计而言非常重要，但是保证它发挥作用的是架构师能够获得充分的保障履行职责。作者回复: 架构师再牛气，首先得要有领导的信任😃
5- Geek_5420ac2021-01-11深有体会，刚来公司发现现有的项目写的跟shi一样，一直跟组长提出重构，虽然拖了大半年但还是重构了，到了自己负责重构的搭建时，又发现其实之前框架的很多逻辑其实是优于我设计的，最后设计出来的发现其实也不是自己想象中的那么完美，因为设计的同时既要保证原有功能不能丢失，而且还有考虑到后续的拓展，这两者在我看来一般是矛盾的，很难在两者中间取舍，说到底还是自己接触的太少了，加油干饭人！
作者回复: 你刚来就觉得项目要重构，有点操之过急了，很多时候看起来不合理其实很可能是你不熟悉而已😄
4 
十里坡剑神2021-01-03非互联网行业的程序猿路过。架构设计得是否复杂，是否高大上，关系到能申请到多少项目预算甚至能否立项作者回复: 哈哈，之前有朋友也说过，如果是做外包项目，架构设计无法遵守三原则，必须要高大上；如果在某些事业单位做项目，架构设计的越复杂越好，拿到的经费多。
共 2 条评论4
木木2018-05-15合适优先级最高吧，反正一切脱离业务需求的架构设计都是耍流氓4
t7ink2019-02-28我的理解是：
在合适原则的基础上保持可演化的最简单的架构。3
lufeng2018-06-06我们既要仰望星空（演进），又要脚踏实地（合适，简单），so 演进是一种sense，这个要求对业务有深入的理解和对技术趋势有独到的见解，合适和简单是两个维度，就是功能和质量要求达标的情况下尽量简单，因为越简单的东西越稳定、性能，可用性和可扩展性相当于复杂系统要好.作者回复: 油菜花😃😃先脚踏实地，再仰望星空
3
美国的华莱士2020-05-27早期业务单一的时候如果把事情想得太全会带来很多内耗,直接的结果就是吃的是奶挤的是草......很多老板线下落地能力非常强,到了互联网这一块恨不得你一个打十个,张口闭口就是直逼阿里京东携程(我真的遇到过),有的时候,复杂的架构更多是由老板想得太美丽造成的,造出来的东西没几个人用,还不如弄个简单的功能把钱花在推广上~所以说,那些不重要的功能,能不要就别要~作者回复: 合适最重要
2- 牺牲2020-05-17合适最重要，不合适等于白费力气，做完也得重做。
简单复杂根据情况来，预算、时间和人力允许的情况下随意发挥，紧巴巴的时候就去繁从简吧。
演化是逐步解决问题的过程，跟随系统复杂度变化。变化无法一步到位，架构又怎么一步到位呢。作者回复: 到位👍
2 
易燃易爆炸2018-06-26 作者回复 架构师再牛气，首先得要有领导的信任😃 201...
极客时间版权所有: https://time.geekbang.org/column/article/7071?device=geekTime.ios
哈哈哈，看到作者这句话，深感这才是第一重要的。个人感觉合适最重要，本着实事求是的态度，解决问题为导向，不求高大上，但是最各种体系都要熟悉，知道优缺点，了解具体试用场景，可能这是最好的状态吧。展开作者回复: 不能说第一重要，但确实挺重要，第一重要的是架构师要真懂技术😄
2
Tony2018-05-30第一次了解架构三原则
初出茅庐时候有次和老大1-1面谈
直接甩给老大几个问题：为什么不用spring?为啥不用ibatis？为啥还在用SP?
看完这篇，现在回头想想老大给我的回复，姜还是老的辣……
当时也是拍脑袋想到为何不用业界流行的框架重构我们的系统，其实没有最好的框架，只有合适的框架，只要能够简单的解决系统面临的业务复杂度，架构组优先会选择公司现有的框架
另外提到架构演绎，我的看法应该是偿还技术债务，公司目前推行的是敏捷开发，敏捷开发的价值就是快速可靠的持续交付，往往team实践时候优先考虑如何在现有框架基础上快速实现业务需求
长期以往一个组件的功能就非常复杂了，功能上容易牵一发而动全身，所以这时候不得不让team停顿下，解决现有的技术债务，从而让复杂的组件从功能上解耦展开2
