从0开始学架构
李运华
资深技术专家
立即订阅
38735 人已学习
课程目录
已完结 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开始学架构
登录|注册

02 | 架构设计的历史背景

李运华 2018-05-01
理解了架构的有关概念和定义之后,今天,我会给你讲讲架构设计的历史背景。我认为,如果想要深入理解一个事物的本质,最好的方式就是去追寻这个事物出现的历史背景和推动因素。我们先来简单梳理一下软件开发进化的历史,探索一下软件架构出现的历史背景。

机器语言(1940 年之前)

最早的软件开发使用的是“机器语言”,直接使用二进制码 0 和 1 来表示机器可以识别的指令和数据。例如,在 8086 机器上完成“s=768+12288-1280”的数学运算,机器码如下:
101100000000000000000011
000001010000000000110000
001011010000000000000101
不用多说,不管是当时的程序员,还是现在的程序员,第一眼看到这样一串东西时,肯定是一头雾水,因为这实在是太难看懂了,这还只是一行运算,如果要输出一个“hello world”,面对几十上百行这样的 0/1 串,眼睛都要花了!
看都没法看,更何况去写这样的程序,如果不小心哪个地方敲错了,将 1 敲成了 0,例如:
101100000000000000000011
000001010000000000110000
001011000000000000000101
如果要找出这个程序中的错误,程序员的心里阴影面积有多大?
归纳一下,机器语言的主要问题是三难:太难写、太难读、太难改

汇编语言(20 世纪 40 年代)

为了解决机器语言编写、阅读、修改复杂的问题,汇编语言应运而生。汇编语言又叫“符号语言”,用助记符代替机器指令的操作码,用地址符号(Symbol)或标号(Label)代替指令或操作数的地址。
例如,为了完成“将寄存器 BX 的内容送到 AX 中”的简单操作,汇编语言和机器语言分别如下。
机器语言:1000100111011000
汇编语言:mov ax,bx
相比机器语言来说,汇编语言就清晰得多了。mov 是操作,ax 和 bx 是寄存器代号,mov ax,bx 语句基本上就是“将寄存器 BX 的内容送到 AX”的简化版的翻译,即使不懂汇编,单纯看到这样一串语言,至少也能明白大概意思。
汇编语言虽然解决了机器语言读写复杂的问题,但本质上还是面向机器的,因为写汇编语言需要我们精确了解计算机底层的知识。例如,CPU 指令、寄存器、段地址等底层的细节。这对于程序员来说同样很复杂,因为程序员需要将现实世界中的问题和需求按照机器的逻辑进行翻译。例如,对于程序员来说,在现实世界中面对的问题是 4 + 6 = ?。而要用汇编语言实现一个简单的加法运算,代码如下:
.section .data
a: .int 10
b: .int 20
format: .asciz "%d\n"
.section .text
.global _start
_start:
movl a, %edx  
addl b, %edx  
pushl %edx
pushl $format
call printf
movl $0, (%esp)
call exit
这还只是实现一个简单的加法运算所需要的汇编程序,可以想象一下,实现一个四则运算的程序会更加复杂,更不用说用汇编写一个操作系统了!
除了编写本身复杂,还有另外一个复杂的地方在于:不同 CPU 的汇编指令和结构是不同的。例如,Intel 的 CPU 和 Motorola 的 CPU 指令不同,同样一个程序,为 Intel 的 CPU 写一次,还要为 Motorola 的 CPU 再写一次,而且指令完全不同。

高级语言(20 世纪 50 年代)

为了解决汇编语言的问题,计算机前辈们从 20 世纪 50 年代开始又设计了多个高级语言,最初的高级语言有下面几个,并且这些语言至今还在特定的领域继续使用。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(161)

  • 公号-代码荣耀
    2018年5月1日心得

    在古代的狼人传说中,只有用银质子弹(银弹)才能制服这些异常凶残的怪兽。在软件开发活动中,“银弹”特指人们渴望找到用于制服软件项目这头难缠的“怪兽”的“万能钥匙”。

    软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。从IT技术的发展历程来看,先辈们在上述不同的环节中提出过很多在当时看来很先进的方法与理念。但是,这些方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点:我们可以通过诸多方式去接近“银弹”,但很遗憾,软件活动中没有“银弹”。

    布鲁克斯发表《人月神话》三十年后,又写了《设计原本》。他认为一个成功的软件项目的最重要因素就是设计,架构师、设计师需要在业务需求和IT技术中寻找到一个平衡点。个人觉得,对这个平衡点的把握,就是架构设计中的取舍问题。而这种决策大部分是靠技术,但是一定程度上也依赖于架构师的“艺术”,技术可以依靠新工具、方法论、管理模式去提升,但是“艺术”无法量化 ,是一种权衡。

    软件设计过程中,模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论,软件架构是一种对软件的“组织”方法论。一分一合,其目的是为了软件研发过程中的成本、进度、质量得到有效控制。但是,一个成功的软件设计是要适应并满足业务需求,同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”,这就决定了这是一个动态活动,出现新问题,解决新问题,没有所谓的“一招鲜”。

    以上只是针对设计领域的银弹讨论,放眼到软件全生命周期,银弹问题会更加突出。

    小到一个软件开发团队,大到一个行业,没有银弹,但是“行业最佳实践”可以作为指路明灯,这个可以有。

    作者回复: 赞,666,你已经提前帮我做了后面相关内容的预热了👍👍

    2018-05-01
    2
    421
  • narry
    软件开发最本质的挑战有两个:复杂和变更,而软件的价值是保证业务的响应力,而与之相对的是开发资源的有限,而各种的软件开发方法论,也都是在研究有限的资源下,如何应对着两个挑战,寻找平衡点,实现业务目标,因为是在寻找平衡点,就说明是有取舍的,所以就没有所谓的银弹的存在

    作者回复: 回答的很好,作者也受到了启发,谢谢👍👍

    2018-05-02
    118
  • cruise
    从哲学角度来说,是不存在银弹的。任何技术或方法都不是独立来看的,要综合其它各种相关因素来考虑的。因此对别人来说可能是银弹的,对你来说可能是个炸弹了。架构设计也是一样的,不能脱离业务、公司实际情况、人员配置、经费预算、时间投入等等与技术本身无关的因素,但却又是影响,甚至决定架构设计方向的因素。因此说没有最好,只有更合适。
    2018-05-01
    75
  • felix
    变化才是唯一的不变,所以银弹不会存在

    作者回复: 言简意赅,抓住了核心本质,“银弹”产生于一定的历史背景和大环境,而历史和环境总是会变化的

    2018-05-02
    39
  • 合民
    作者这个问题是否在考验,读者认真看了这篇文章没有?我认为文章的软件发展历史正是答案,软件工程归根结底是为各行各业的需求服务的,而随着需求的复杂度越来越高,用户的要求越来越高,软件也越复杂,形态也在不断变化,所以没有一种方法论能称得上是银弹,只能说某一种方法论适合某一种需求。这也正是架构师存在的意义,去选择合适的技术,如果有银弹,还要架构师干嘛!以上只是个人见解!

    作者回复: 你已经看穿一切👍👍
    确实是想通过介绍历史来启发大家思考

    2018-05-01
    35
  • 李志博
    软件开发的结果在于人,而不在于方法论,面向对象,设计模式,架构,这些概念的推出距离现在,好几十年了吧,可真正理解透彻的能有多少呢,就算有像作者这样理解透彻的,还在一线开发的能有多少……阿里的p9难道还在一线写代码嘛……最终写代码的人还是理解不到位的我们,技术强的,写的项目能多撑两年,但是复杂到一定程度,没有良好关系架构指导,都是坑

    作者回复: 其实不一定要P9才要理解到位呢,我2014年就写了《面向对象葵花宝典》,那时我还在写代码的哦,其实我现在也写代码,不写代码很多技术没法确切理解,我现在写demo代码比较多,例如用golang写个简单的区块链,用java写个reactor等

    2018-05-01
    20
  • Alspadger
    因为设计者都是站在当时的业务瓶颈下考虑问题的,因为你不可预测当业务发展的一定程度后,又会遇到怎么样的技术瓶颈。也就是所谓的技术支撑业务发展,业务推动技术发展。
    2018-05-01
    16
  • xuan
    “No Silver Bullet”的原文是:“没有任何技术或管理上的进展,能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。”之所以这样说,是因为软件的根本困难(Essence,包括复杂度、一致性、可变性、不可见性)
    复杂度:规模上, 软件实体可能比任何由人类创造的其他实体更复杂, 因为没有任何两个软 件部分是相同的
    一致性:软件的变化必须遵循一系列接口标准规范,有些情况下它的变化就是要兼容;
    可变性:一般有如下几种情况:
      1.当客户喜欢用某个功能或者某个功能能解决他的某些问题时,他会针对这方面提出很多优化该功能的需求点
      2.硬件或者其他配件的升级变化 必须升级现有软件平台
    不可见性:软件不存在一种空间形态 可以通过一张图
    或者其他载体来可视化展示 ,不能通过地图 电路设计图等来全面展示.
    由于这几个点的变化,导致系统越来越臃肿,从而导致管理成本上升,沟通困难,可靠性逐年下降等等;而结构化 面向对象等主要是来提高生产率 可靠性和简洁性

    作者回复: 没有看过《人月神话》的程序员不能成为好的架构师😃😃👍👍

    2018-05-02
    15
  • Mark Yao
    软件本身的复杂度难以度量,随时间和规模发展,原有的解决方案很快难适应,人们就不断总结经验模式和设计解决新困难的办法,但是不管什么样的架构设计都是在尽量满足适应我们可能遇到的问题的解决方案,不是解决问题方案。生活中我们的应用从单体到主备再到集群、分布式、微服务最后到最新的Service Mesh,这些其实都是解决和改善、完善、优化我们在软件开发遇到的问题。There is no silver bullet.

    作者回复: 回答正确👍

    2018-05-02
    13
  • crazyone
    感觉像是看大佬们在华山论剑般,评论相当精彩
    2018-05-06
    10
  • 淡云天
    解空间是建立在问题空间之上的,问题空间的扩展速度远超解空间时,就会架空解空间。而这时就需要新的、适应问题空间扩展速度的解空间来担当这个阶段的银弹。这一点类似于宏观物理学和量子物理学,只不过物理学几百年的进化之路,计算机只用了二十年就走完了。。。
    2018-05-02
    10
  • yoummg
    作者的用心令人敬佩。
    为什么现在我们在谈“架构”,他不是平白无故产生的,他是在一定的背景下产生的。更好地理解他产生的原因,会在具体解决问题的时候做到有的放矢。
    直到现在才看明白,what,why,how。这真是一个认清事物最本质的三步。👍👍👍

    作者回复: 你已经洞悉天机👍👍😄整个专栏思路就是这样的

    2018-07-08
    8
  • 带刺的温柔
    软件架构是为了解决大规模开发时遇到的效率、复杂及扩展性问题。听老师所说让我对架构认知又更加清晰落地。但是对拆分粒度越来越粗,层次越来越高理解的还是不够,其实与我的一些开发习惯是相悖的,一般我会尽可能拆分细来保证后期的扩展性。不知道老师我是哪里理解偏差了
    2018-05-01
    7
  • 阿罗
    超赞👍🏻,
    饱含认识论和系统论的理论知识与软件实践知识。太难得了,非大集成者无以为之。我买过最值的课程!
    2018-05-01
    6
  • 候鸟归来的季节
    技术在不断发展,新的业务需求催生新的技术,没有银弹
    2018-05-01
    6
  • KingPoker
    推荐一本书「伟大的计算原理」,把计算机的本质问题描述的很透彻,也给我有一些全新的认知。
    2018-05-01
    5
  • 闭嘴
    感觉作者对整个软件行业有比较深入的了解。就是内容太少。还没看就没了。希望后面的文章多来一点干货。让我这种小白能够学习到一点实质的东西。能够解决项目问题的一些东西。希望大神能够把自己的功力展现60%就行。

    作者回复: 这是提炼出来的,为了写这一篇,我写了2~3周,如果觉得意犹未尽,可以在这个基础上继续去探索

    2018-05-02
    4
  • 老甘
    所有的解决方案都是为了解决某一类问题,既然是某一类问题势必是术业有专攻,从辩证的角度也很好理解,事物都有两面性,不存在某种方案可以解决所有问题而没有任何弊端,有弊端自然会出现针对某个场景更好的解决方案。而且,世界在变化,针对现实世界解决问题的软件业务逻辑也势必不断变化,所以只有针对多数场景暂时的银弹,而没有永久的。未来还有更好的
    2018-05-01
    4
  • Welton
    技术在不断发展和更新,没有一劳永逸的事物能够代替不断变化的大千世界需求!
    2018-05-01
    4
  • 猴哥
    为什么软件架构还不是银弹,因为还有更加高级的等着我们去开发挖掘。究其原因,我个人认为主要是人在进步,当下看可能是最好的方法,过十年人类经验的积累,可能会发现更好的理论,这可能是个死循环,所以没有银弹。

    作者回复: 唯一不变的是变化本身

    2018-05-01
    3
收起评论
99+
返回
顶部