从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开始学架构
登录|注册

架构专栏特别放送 | “华仔,放学别走!” 第2期

何潇 & 李运华 2018-06-01
各位同学,晚上好,我是架构专栏的编辑 Shawn。今天又到周五啦,没错,我又出来送福利了 [捂脸]。
“华仔,放学别走”第 1 期不知道你看了没有,华仔回答了关于知识分享、理论与实践、专栏学习方法、推荐的参考书等几个问题,希望你从中能够有所收获。今天是“华仔,放学别走”第 2 期,继续回答你所关注的问题,然后展示出 08 ~ 13 期被选中的精选留言,并给留言被选中的同学送出价值 68 元的专栏阅码。话不多说,开始今天的问答环节。
Shawn:有做公司架构 / 网站架构 /App 架构的同学,这个专栏能帮助到他们吗?
华仔:有的同学在学习了一段时间后跟我留言交流,说感觉专栏的内容好像比较适合做互联网后台架构,不太适合企业应用、客户端这类系统。其实这是一个误解,我之所以在前面花费很大篇幅来讲架构设计的目的、架构设计原则、架构设计流程等看起来比较偏理论的内容,而没有一上来就讲异地多活、高性能架构之类的怎么做,原因就在于这是一套完整的架构设计理论体系,不管是企业应用,还是客户端应用,都可以按照这个设计理论体系去操作。我以手机 App 为例,首先,我们分析一下 App 的复杂度主要来源是什么?通常情况下,App 的主要复杂度就是可扩展,因为要不断地开发新的需求;高性能和高可用也涉及,高性能主要和用户体验有关;高可用主要是减少崩溃。其次,再看 App 的架构需要遵循架构设计原则么?答案是肯定需要。刚开始为了业务快速开发,可能用“原生 +H5”混合架构;后来业务发展,功能更复杂了,H5 可能难以满足体验,架构又需要演进到“纯原生”;如果业务再发展,规模太庞大,则架构又可能需要演进到“组件化、容器化”。以上通过手机 App 的为例说明这套架构设计理论是通用的,有兴趣的同学可以按照这种方式分析一下企业应用,会发现这套理论也是适应的。
Shawn:讲讲你总结“架构设计三原则”的过程吧?
华仔:“架构设计三原则”是综合各方面的信息和思考得来的。首先是我自己的经验,包括成功的经验和失败的教训;其次是分析了很多业界的架构演讲和技术发展历史;第三是看了一些关于技术本质的书籍而受到的启发,例如《技术的本质》《系统之美》等。其实最初整理的架构设计原则有 10 多条,但我觉得 10 多条太多了,不聚焦也不利于理解,因此去芜存菁,最终得到了“架构设计三原则”,这三个原则是最重要也是最核心的。
如下是我原来整理的设计原则:可以看到一共有 14 条:
Shawn:“PPT 架构师”的口头禅是“细节不讨论”,一个优秀的架构师,需要对细节有多少考虑呢?
华仔:这是一个非常好的问题,也是很多同学困惑的问题,我分享一下我的做法,以我学习 Elasticsearch 为例,具体的做法是:
搭建一个单机伪集群,搭建完成后看看安装路径下的文件和目录,看看配置文件有哪些配置项,不同的配置项会有什么样的影响。
执行常用的操作,例如创建索引,插入、删除、查询文档,查看一下各种输出。
研究其基本原理,例如索引、分片、副本等,研究的时候要多思考,例如索引应该如何建,分片数量和副本数量对系统有什么影响等。
和其他类似系统对比,例如 Solr、Sphinx,研究其优点、缺点、适用场景
模拟一个案例看看怎么应用。例如,假设我用 Elasticsearch 来存储淘宝的商品信息,我应该如何设计索引和分片。
查看业界使用的案例,思考一下别人为何这么用;看看别人测试的结果,大概了解性能范围。
如果某部分特别有兴趣或者很关键,可能去看源码,例如 Elasticsearch 的选举算法(我目前还没看 ^_^)。
如果确定要引入,会进行性能和可用性测试。
这样一套组合拳下来,基本上能够满足在架构设计时进行选型判断,而且花费的时间也不多。我并不建议拿到一个系统一开始就去读源码,效率太低,而且效果也不好。
Shawn:谈谈架构师沟通能力的重要性吧?
华仔:架构师是业务和技术之间的桥梁,同时通常情况下还会确定整体项目的步骤。因此,架构师的沟通能力非常重要,既要说得动老板,让老板支持自己的设计决定;又要镇得住技术人员,让技术人员信服自己的设计选择;同时还要能够理解业务,结合业务不同发展阶段设计合适的架构,所以也要参与产品和项目决策。由于架构设计过程中存在很多判断和选择,而且不一定都有明确量化的标准,因此不同的人有不同的看法是普遍情况。这种情况下架构师既需要专业能力过硬,又需要具备良好的沟通技巧,才能促使业务、项目、技术三方达成一致。
当然,架构师的核心能力还是技术能力,过硬的技术才是良好沟通的基础,否则单纯靠沟通技巧甚至花言巧语,一次两次可能奏效,但后面被打脸打多了,也就没人信任了。
Shawn:有同学留言说,给企业做项目,甲方会不顾业务需要,只要是业界流行的技术就要求在项目中采用,这种情况下怎样才能符合“架构设计三原则”?
华仔:首先,业务第一,先把订单签下来,才有后面的架构设计,如果硬要说甲方的要求不合理,不满足“架构设计三原则”,结果订单都拿不到,那是没有意义的。其次,这种情况我把它归为“架构约束”,即这不是架构师能够选择的,而是架构师必须遵守的,因此这里不需要使用“架构设计三原则”来判断。第三,这种情况下,架构师还是可以应用“架构设计三原则”来指导架构设计,比如说客户要求采用 Docker,Docker 的网络模式有 5 种,host 模式使用起来比 bridge 模式简单,那我们就用 host 模式;如果客户再要求需要对 Docker 进行统一管理,那我们是自己研发 Docker 管理平台,还是直接用 Kubernetes 呢?按照简单原则来说,肯定用 Kubernetes 了。
通过这个示例也可以看出,“架构设计三原则”主要是指架构师在选择和判断时采取的指导原则;但如果是架构的基本需求或者约束必须被满足时,架构师此时的选择是采取什么样的方案能够更好的满足这些需求和约束。

留言精选

华仔:有个懂技术的好老大是一件多么幸福的事情:)
华仔:有钱也不能任性,微软 95 年也不可能开发出 Windows 10 操作系统;业务量大了重构甚至重写那是自然而然的,不会浪费也不会导致错失产品机会,Windows、Android、淘宝、QQ 都是这么过来的。
华仔:终于明白了我一开始就提架构设计的核心目的的良苦用心了吧 :)
华仔:实现起来细节较多,但没有想象的那么复杂,一般的公司如果有人力的话,做一个简单够用的消息队列不难,用 MySQL 做存储的话,不到 1 万行代码就可以搞定。
华仔:如有雷同,实属巧合,确认过眼神,我不是你们公司的人 ^_^
华仔:架构师确实需要在技术广度和技术深度两方面都要兼顾,但如何把握技术深度这个“度”,不同架构师有不同的理解,但千万不能说“细节不讨论”“你上网搜”,这样会没有技术公信力。
最后,再次恭喜@Tony@Michael@空档滑行@bluefantasy@东@ant,也感谢写下留言的每位同学。欢迎你在这期“华仔,放学别走”留下你的问题,业务、职场、职业规划等不限主题,可以和华仔一起聊聊专栏以外的话题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 爱吃技术的🐱
    企业高速发展过程中,技术总是短期内被高估,长期被低估,一位15年IT老兵的切身感受!

    作者回复: 我理解是短期被牺牲,长期被低估😂😂

    2018-06-02
    12
  • Sic Pavis
    老师好,我想咨询一个职业规划的问题。
    先简单介绍下:
    刚毕业的时候找的工作岗位比较闲,一两年下来没做多少事情。自己也不是个很自觉的人,有些荒废。现在一转眼毕业五年了,技术水平还是不高。

    现在比较急于找到方向去努力,但是悟性有限。和团队里的资深人士交流后还是抓不住重点。现在做事情知道思考知道简单总结,但是不知道如何将这些量变积累成质变。希望老师有空指惑,谢谢!

    作者回复: 大部分人还不到拼悟性的时候,你觉得自己抓不住重点,主要还是积累不够,清点一下自己看过的书,做个的项目,研究过的系统,看看到底有多少。

    另外可能是你的学习不系统,只知道点,不知道面和体,别人稍微扩散一下就把你卡住了

    2018-08-22
    1
    8
  • 张国胜
    之前在公司遇到的问题是,拿演化当挡箭牌,导致根本没有架构就直接开干。演化优于过度设计,我的理解是,演化要站在上帝视角,能看到一定程度的将来,然后从多种设计方案中选择最基本的那一种,就像有了最小子集,这是后续演化的基石,最好不要推到重来,如果要重来也要尽早。而不能无设计作为起点。

    作者回复: 是的,演化优于过度设计不是说不要设计,而是不要过度设计

    2018-06-29
    2
  • Panda
    目前公司的项目并发量不大,项目比较复杂,逻辑复杂度高,多个项目耦合强,请老师分享一下这种情况下的架构 应该怎么做

    作者回复: 可扩展章节有讨论

    2018-06-04
    2
  • 忽然发现上了热门,有种被翻牌子的感觉!
    2018-06-04
    1
  • godtrue
    嗯,我勤奋有毅力,因为无知错过一些,现在我反应过来了,我相信自己会越来越好。

    作者回复: 加油

    2019-09-04
  • 飘然
    1.看得书多,加上实践,技术能力是不是就能不断提升。如果看了书过一段就忘了,或者看了一些书,技术能力还是感觉没有提升,这种情况怎么办,还是看书少的原因?
    2.技术人员,除了提升技术还需要提升哪些方面?
    3.对于工作8-9年,技术有些薄弱,未来3-5年,对于晋升和提升自己有什么常见的策略?

    作者回复: 多总结多实践

    2019-04-07
  • 胡文峰
    短期被压榨,长期被低估,又被kill掉
    2019-03-29
收起评论
8
返回
顶部