从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

08 | 架构设计三原则

李运华 2018-05-15
前面几期专栏,我跟你系统的聊了架构设计的主要目的是为了解决软件系统复杂度带来的问题,并分析了复杂度的来源。从今天开始,我会分两期讲讲架构设计的 3 个原则,以及架构设计原则的案例。
成为架构师是每个程序员的梦想,但并不意味着把编程做好就能够自然而然地成为一个架构师,优秀程序员和架构师之间还有一个明显的鸿沟需要跨越,这个鸿沟就是“不确定性”。
对于编程来说,本质上是不能存在不确定的,对于同样一段代码,不管是谁写的,不管什么时候执行,执行的结果应该都是确定的(注意:“确定的”并不等于“正确的”,有 bug 也是确定的)。而对于架构设计来说,本质上是不确定的,同样的一个系统,A 公司和 B 公司做出来的架构可能差异很大,但最后都能正常运转;同样一个方案,A 设计师认为应该这样做,B 设计师认为应该那样做,看起来好像都有道理……相比编程来说,架构设计并没有像编程语言那样的语法来进行约束,更多的时候是面对多种可能性时进行选择。
可是一旦涉及“选择”,就很容易让架构师陷入两难的境地,例如:
是要选择业界最先进的技术,还是选择团队目前最熟悉的技术?如果选了最先进的技术后出了问题怎么办?如果选了目前最熟悉的技术,后续技术演进怎么办?
是要选择 Google 的 Angular 的方案来做,还是选择 Facebook 的 React 来做?Angular 看起来更强大,但 React 看起来更灵活?
是要选 MySQL 还是 MongoDB?团队对 MySQL 很熟悉,但是 MongoDB 更加适合业务场景?
淘宝的电商网站架构很完善,我们新做一个电商网站,是否简单地照搬淘宝就可以了?
还有很多类似的问题和困惑,关键原因在于架构设计领域并没有一套通用的规范来指导架构师进行架构设计,更多是依赖架构师的经验和直觉,因此架构设计有时候也会被看作一项比较神秘的工作。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(98)

  • 公号-代码荣耀
    今日得到

    架构即决策。架构需要面向业务需求,并在各种资源(人、财、物、时、事)约束条件下去做权衡、取舍。而决策就会存在不确定性。采用一些高屋建瓴的设计原则有助于去消除不确定,去逼近解决问题的最优解。

    1 合适原则

    架构无优劣,但存合适性。“汝之蜜糖,吾之砒霜”;架构一定要匹配企业所在的业务阶段;不要面向简历去设计架构,高大上的架构不等于适用;削足适履与打肿充胖都不符合合适原则;所谓合适,一定要匹配业务所处阶段,能够合理地将资源整合在一起并发挥出最大功效,并能够快速落地。

    2 简单原则

    "我没有时间写一封短信,所以只好写一封长信"。其实,简单比复杂更加困难。面对系统结构、业务逻辑和复杂性,我们可以编写出复杂的系统,但在软件领域,复杂代表的是“问题”。架构设计时如果简单的方案和复杂的方案都可以满足需求,最好选择简单的方案。但是,事实上,当软件系统变得太复杂后,就会有人换一个思路进行重构、升级,将它重新变得简单,这也是软件开发的大趋势。 简单原则是一个朴素且伟大的原则,Google的MapReduce系统就采用了分而治之的思想,而背后就是将复杂问题转化为简单问题的典型案例。

    3 演化原则

    大到人类社会、自然生物,小到一个细胞,似乎都遵循这一普世原则,软件架构也不例外。业务在发展、技术在创新、外部环境在变化,这一切都是在告诫架构师不要贪大求全,或者盲目照搬大公司的做法。应该认真分析当前业务的特点,明确业务面临的主要问题,设计合理的架构,快速落地以满足业务需要,然后在运行过程中不断完善架构,不断随着业务演化架构。怀胎需要十月,早一月或晚一月都很危险。
    2018-05-15
    133
  • oddrock
    合适优于先进>演化优于一步到位>简单优于复杂

    合适也就是适应当前需要是首位的,连当前需求都满足不了谈不到其他。
    架构整体发展是要不断演进的,在这个大前提下,尽量追求简单,但也有该复杂的时候,就要复杂,比如生物从单细胞一直演化到如今,复杂是避免不了的,

    作者回复: 标准答案👍👍

    2018-05-15
    114
  • @漆~心endless
    架构设计三原则;
    合适原则最适合;
    简单原则不简单;
    演化原则需推进;
    如若脱离三原则;
    老板生气你苦逼。

    作者回复: 确认过眼神,你是油菜花的人!!😂😂😂

    2018-05-17
    25
  • 石同享
    合适原则是不是可理解为:确定了一定的系统复杂度之后,能承受其包括性能,可用性,可拓展性,成本,安全方面的最小代价解(简单原则),而演化原则是对上述系统的迭代优化。这样和之前的内容都可以联系起来了。

    作者回复: 是的,我的思路就是这样的,三个原则是一体的,三个原则与架构设计的目的也是一脉相承的

    2018-05-15
    20
  • narry
    个人感觉合适原则是最重要的,它决定了对简单原则和演化原则的判断,没有以合适为基础,很难判断简单是否能满足业务的需求,演化的起点在哪里
    2018-05-15
    14
  • 何磊
    三大原则:合适原则,简单原则,演进原则。
    最重要的莫过于合适原则,如果不合适,无意欲削足适履,团队感觉难受,业务不稳定等,因此架构设计的第一原则一定是合适,合适当前的业务,合适当前的团队,合适当前的成本(时间与资本)
    其二简单原则,这是一个相对原则,是在合适的基础上进行选择最简单方案,绝不能孤立,并且简单是自己业务的对比,比如:当前淘宝的架构每次迭代,他们选择一个简单方案,但他们的简单不意味着我们的简单。
    关于演进原则,系统一定变化的、生长的,但是他们的起跑点肯定不同,比如大公司造的系统都是富二代,他会从微服务开始演进,十个人的小团队会从单体应用演进。
    对于上面三个原则,演进原则其实我觉得考不考虑,他都存在,只要你的业务继续,不过好的架构有助于可扩展性,让后续演进更丝滑般流畅,不好的架构到了某个阶段只能重来。

    作者回复: 恰恰“演进原则”很多人不知道,总想一步到位,过度设计

    2018-05-15
    9
  • 桌小洛
    总结的很好,架构设计原则:

    合适原则: 有多大的脚(复杂度),穿多大码的鞋。BAT或者业界领先的架构对很多团队和公司来说都是大码的鞋而已,穿上不合适的鞋,团队必定步履蹒跚,很难走的很远,还有可能摔倒(项目失败)。
    但是如果能根据自己的业务需求,对BAT或者业界领先的架构进行仔细调研,进行删减,重新取其一部分组合成适合自己的架构,也是非常好的方法。

    简单原则: 我感觉改成简洁原则更合适,简单+整洁。360行皆是艺术,架构也是一门艺术。一个复杂的系统,如果能用一个简洁的架构来实现,完全相当于一个艺术品。 相反,如果一个普通的系统,反而被设计成了一个错综复杂的复杂架构,相当于做了一个糟粕品。

    演化原则: 通过 简化设计 + 重构 来保证架构的与时俱进。不要前期就对架构进行过度设计,毕竟无论你前期怎么设计,总会有你意想不到的变化产生,唯一不变的就是变化。等你的脚长大了,再去穿大码的鞋。

    作者回复: 你的解读很形象👍👍

    2018-08-11
    6
  • Loy
    发现这三个选择放在爱情上,也完全没毛病

    作者回复: 爱情怎么演化?😂😂

    2018-05-18
    6
  • 查理
    演进很重要,很多人都喜欢过度设计,简单的东西搞复杂。其实以后系统怎样变化很多过度的预测都不准,还不如让系统在一开始保持精简一点,根据需求慢慢演进

    作者回复: 赞同,预测太长没有意义,也预测不准

    2018-05-17
    4
  • 木木
    合适优先级最高吧,反正一切脱离业务需求的架构设计都是耍流氓
    2018-05-15
    4
  • Forrest Li
    面对不确定性,架构师始终要做出一个选择,而三个原则遵循着解决问题的思路,提供了选择的依据。首先是合适,能够解决问题,其次是从合适中挑选简单的、能hold住的方案,最后,不要指望一个方案能解决所有问题,总会有弊端、不足,在碰到未来无法预料的情况时再做调整就是。变是永远不变的。

    作者回复: 仅此一家,别无分店的三原则😄

    2018-07-04
    3
  • SHLOMA
    题外话,如何说服领导,合适大于先进😂

    作者回复: 人手不够,工期太长,成本太高,没有合适的人才……😃

    2018-05-21
    3
  • 易燃易爆炸
     作者回复 架构师再牛气,首先得要有领导的信任😃 201...
    极客时间版权所有: https://time.geekbang.org/column/article/7071?device=geekTime.ios


    哈哈哈,看到作者这句话,深感这才是第一重要的。个人感觉合适最重要,本着实事求是的态度,解决问题为导向,不求高大上,但是最各种体系都要熟悉,知道优缺点,了解具体试用场景,可能这是最好的状态吧。

    作者回复: 不能说第一重要,但确实挺重要,第一重要的是架构师要真懂技术😄

    2018-06-26
    2
  • lufeng
    我们既要仰望星空(演进),又要脚踏实地(合适,简单),so 演进是一种sense,这个要求对业务有深入的理解和对技术趋势有独到的见解,合适和简单是两个维度,就是功能和质量要求达标的情况下尽量简单,因为越简单的东西越稳定、性能,可用性和可扩展性相当于复杂系统要好.

    作者回复: 油菜花😃😃先脚踏实地,再仰望星空

    2018-06-06
    2
  • Tony
    第一次了解架构三原则
    初出茅庐时候有次和老大1-1面谈
    直接甩给老大几个问题:为什么不用spring?为啥不用ibatis?为啥还在用SP?
    看完这篇,现在回头想想老大给我的回复,姜还是老的辣……
    当时也是拍脑袋想到为何不用业界流行的框架重构我们的系统,其实没有最好的框架,只有合适的框架,只要能够简单的解决系统面临的业务复杂度,架构组优先会选择公司现有的框架
    另外提到架构演绎,我的看法应该是偿还技术债务,公司目前推行的是敏捷开发,敏捷开发的价值就是快速可靠的持续交付,往往team实践时候优先考虑如何在现有框架基础上快速实现业务需求
    长期以往一个组件的功能就非常复杂了,功能上容易牵一发而动全身,所以这时候不得不让team停顿下,解决现有的技术债务,从而让复杂的组件从功能上解耦
    2018-05-30
    2
  • 苏本东
    目前在做一个某行业的国际站,还未上线。其中多语言文案需要其他同事翻译,于是做了一个excel表格,在微信群里飞来飞去。然后领导说同行业某某公司有自己的管理后台,说我们的做法low了,可我认为这是目前最快也是最合适的方法。后续做大了再演进呀。

    作者回复: 看优先级,如果还有其他事情更优先就可以先用简单的方式

    2018-05-19
    2
  • 钰湚
    我们之前花了多年时间进行了一次全范围的架构升级,几乎重做了所有主力系统,这个过程中,我的体会其实跟三原则非常接近,尤其是演化原则,大公司的复杂系统永远不可能一步到位,甚至较长的工期本就会导致原有设计在最终实现时就已经落后,复杂系统的架构只能是演化迭代的,这其中即有技术因素也有业务因素,有工艺的复杂也有人的复杂;简单原则,实际上是对单一职责的追求,但是对大型系统而言,单一职责也会带来通讯的复杂,调用的复杂,大型系统清晰的逻辑分层并不容易实现,如果涉及多方协同施工,单一职责更难贯彻,尽管大家都认可,但是实现起来并不容易;合适原则非常正确,不过可惜的是,它经常不是甲方的原则。这三原则对于架构设计而言非常重要,但是保证它发挥作用的是架构师能够获得充分的保障履行职责。

    作者回复: 架构师再牛气,首先得要有领导的信任😃

    2018-05-17
    2
  • 幸福时光
    软件系统唯一的不变就是变化,架构设计终极目标就是把适应未来变化的架构演进成本最小化。不过度设计,也不能没有设计。在适配当前业务场景的前提下,参考业界先进技术,找出系统设计的最优解。适应业务优先级第一,简单的架构方案不能理解为简单的系统设计,深入业务理解和技术剖析,才能输出适配的简单架构。大道至简,厚积才能薄发!
    2018-05-16
    2
  • ZYCHD(子玉)
    合适原则,简单原则和演化原则是一体的,在合适的基础上简单,简单有利于后续系统因业务变化而产生的演化。很难说哪个原则最重要,三者都很重要。没有一尘不变的业务也就没有一尘不变的系统。

    作者回复: 是一体的,并且这里的简单原则是指多个方案比较后挑选简单一些的,不是说方案本身一定要简单

    2018-05-15
    2
  • t7ink
    我的理解是:
    在合适原则的基础上保持可演化的最简单的架构。
    2019-02-28
    1
收起评论
98
返回
顶部