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

38 | 架构师应该如何判断技术演进的方向?

李运华 2018-07-24
互联网的出现不但改变了普通人的生活方式,同时也促进了技术圈的快速发展和开放。在开源和分享两股力量的推动下,最近 10 多年的技术发展可以说是目不暇接,你方唱罢我登场,大的方面有大数据、云计算、人工智能等,细分的领域有 NoSQL、Node.js、Docker 容器化等。各个大公司也乐于将自己的技术分享出来,以此来提升自己的技术影响力,打造圈内技术口碑,从而形成强大的人才吸引力,典型的有,Google 的大数据论文、淘宝的全链路压测、微信的红包高并发技术等。
对于技术人员来说,技术的快速发展当然是一件大好事,毕竟这意味着技术百宝箱中又多了更多的可选工具,同时也可以通过学习业界先进的技术来提升自己的技术实力。但对于架构师来说,除了这些好处,却也多了“甜蜜的烦恼”:面对层出不穷的新技术,我们应该采取什么样的策略?
架构师可能经常会面临下面这些诱惑或者挑战:
现在 Docker 虚拟化技术很流行,我们要不要引进,引入 Docker 后可以每年节省几十万元的硬件成本呢?
竞争对手用了阿里的云计算技术,听说因为上了云,业务增长了好几倍呢,我们是否也应该尽快上云啊?
我们的技术和业界顶尖公司(例如,淘宝、微信)差距很大,应该投入人力和时间追上去,不然招聘的时候没有技术影响力!
公司的技术发展现在已经比较成熟了,程序员都觉得在公司学不到东西,我们可以尝试引入 Golang 来给大家一个学习新技术的机会。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(33)

  • 无问。
    成熟的架构演进和案例当然是可以借鉴的,相信有不少架构师都读过淘宝技术十年。但是如果说参照他人的架构演进,将自己的架构一步设计到位我觉得这本身就是个伪命题。

    为什么?

    1.首先淘宝自己的架构是在持续的演进中的,可能技术的变革、业务的创新、硬件性能的提升等都会迫使架构产生变化,没有所谓最优解。

    2.技术和架构是不能脱离业务来谈的,否则我们怎么去衡量它们的价值和收益呢。世界上没有两片相同的叶子,淘宝的业务在结构、体量和形态上往往和很多企业有很大的差异。

    3.针对于架构实践,另一个不能避免问题就是,管理和成本。不同的架构设计解决问题的广度和深度不同,相应的带来的管理复杂度和人力物力的成本也不同。


    那具体该怎么做呢?我的理解是

    1.结合激进、保守、跟风,作为架构的实践者,必须及时跟进新的技术体系,同时需要慎重考虑引入新的内容,要想清楚它的必要性、能在短期带来的什么收益、能解决什么问题,同时还需要以观察者的角度来看业界大厂的实践,同时思考他们为什么要这么做,对于我们以后改进设计很有帮助

    2.对于架构演进来说是有成本的,在准备改变之前还要想明白的一个事就是这么做的成本是什么,会给我们带来什么样的收益,当前的团队规模是否能稳定驾驭

    作者回复: 赞同👍

    2018-07-24
    47
  • 铃兰Neko
    我感觉要分情况讨论,但是本质上还是要符合 "合适" "简单" "演进" 原则的.
    假设淘宝目前的架构是 100 分.
    A : 假设是一个量级也是很大的电商 (比如苏宁,京东) :
    初始的阶段和要求就很高 ,可能一上线就有大量用户 , 建议参考淘宝的架构 , 至少达到60分.
    不用一步到位, 但是要有大部分基础功能 (比如肯定要有缓存, 要服务化, 肯定要上docker , 肯定要有基础的微服务组件,
    订单系统 , 用户系统至少先做的能够支持一段时间的用户增长 ;
    但是可以不用自研, 先使用开源 )
    B : 假设是一个量级较小的小网站.
    这个就不建议一步到位, 没人没钱搞这个; 能达到淘宝的20分 可能都够用.
    可以根据人力,时间,机器等资源 . 解决当前的最大矛盾: 可能就是先上一版初版, 效果好后续慢慢演进 .
    效果不好没有用户, 那以后人都没有了也就不用演进了. 😂

    作者回复: 分析到位,大公司和创业公司做法不同,例如传统的苏宁国美沃尔玛要从线下转线上,第一版电商网站确实可以参考淘宝当前架构,但也不是完全照搬,你说的60分非常到位👍👍

    2018-07-24
    16
  • 三木子
    最近遇到一个现实的架构设计,本来一个业务不多系统却要上微服务架构,项目经理解释说不弄点流行技术,公司就少投钱。这就是现实啊😄

    作者回复: 理解,面向升职的架构设计😂

    2018-07-28
    1
    10
  • zhngbin
    请问下画架构图用什么软件的?

    作者回复: libre office draw

    2018-07-24
    5
  • narry
    觉得还是应该按演进的思想来,先根据业务发展阶段选择合适的架构,业界的案例可以作为演进的方向

    作者回复: 演进的原则没错,不要一步到位,但要考虑是从20分开始演进还是从60分开始演进,大公司例如苏宁国美可以从60分演进,小公司可以从20分演进

    2018-07-24
    5
  • Michael
    像浏览器这样的产品,使用规模还是会影响用户选择的,假如我有一个更好的浏览器ud浏览器
    但如果周边的人都用uc,网上也推荐用uc,那可能用户就选择uc了,这个还是“规模”作用啊

    还有打车软件,比如我自己不但提供软件可以打车,而且自己也提供车,用户会因为我提供的车更专业选择我的,也会因为这个软件的“规模”选择我的
    也就是说该如何严格确定,一个东西到底是产品,还是服务呢?

    作者回复: 服务就是别人用你才能用,例如微信,我用米聊就没法和我的朋友聊天了,除非他们都切换米聊
    产品就是工具,我不管别人用不用我都可以用,我用opera浏览器不影响我上网

    2018-07-25
    3
  • 今夕是何年
    选择什么样的架构和看病一样要对症下药。
    首先要预估业务规模和系统1.0上线后,系统的并发量,以略高于预估的并发量来设计,否则,系统一上线,用户来访问,分分钟挂掉,对业务是莫大的损失,又丢用户又丢技术人员的脸。
    系统上线后,关注系统的压力,并探讨用户数到下一个量级,架构和技术要如何支撑为课题,综合技术团队的技术水平和技术团队规模能驾驭的架构来做选择。
    涉及到新技术的,要尽早去学习试错,以期用时能淡定从容应对。

    作者回复: 正解👍

    2018-07-25
    2
  • 张立春
    一个企业的技术架构是随着业务发展逐渐演化生长出来的 绝不可能照抄别人就可以。就像每个人都是独一无二的,拥有不一样的经历和人生。

    作者回复: 细节独一无二的,大方向还是可以参考的,例如我们都是程序员,发展路径可以借鉴

    2018-07-24
    2
  • 问题究竟系边度
    有成熟的架构参考。在一定程度上,可以预知以后系统变大后,可能要做一些什么,还有大体的逻辑结构会怎么样,因为这是通过检验的。但是业务上并不完全一致的情况下和体量不一样的情况下,详细的设计还是需要结合实际去做的。

    作者回复: 赞同👍

    2018-07-24
    2
  • monalisali
    请教作者,一般的企业级开发的项目应该属于产品类还是服务类呢? 我觉得应该属于产品类,因为这种系统虽然不像360这种直接到个人的产品,但是实际使用的还是单个企业内的员工。如果从企业角度来看的话,应该是属于产品比较合适吧

    作者回复: 属于产品类,因为是帮助企业解决特定问题的

    2019-01-21
    1
  • Alan
    老师后面还有新的专栏吗

    作者回复: 暂时没有,写专栏很辛苦的😄

    2018-07-25
    1
  • Fisher
    总结起来还是运华老师那几句话,按照企业当前的业务发展阶段衡量当前复杂度,逐步推演,设计合适的架构。
    如果有对手系统可以参考,企业自身业务能够达到一个高度,老板给时间,就预见性的设计,为后续升级留出通路。

    作者回复: 要碰到好老板才行😁

    2018-07-25
    1
  • 小龙
    老师,架构师只需要做技术选型,不需要做需求分析、概要设计、详细设计是吗?

    作者回复: 需求分析要做,概要设计要把关,防止偏离架构,详细设计真不需要,再说了,做好架构设计其实很费时间的😄

    2018-07-24
    1
  • 凡凡
    首先,参考和借鉴业内最好的实践经验,架构案例,对于将来的判断和技术准备都有很大的益处,也可以少踩一些坑,也能让后续的演进顺利和省心很多,淘宝技术十年再来一打。

    另外,需要综合考虑,看业务发展,看资源,看团队情况。

    如果团队很小,资源需要一步一步积累,自然要逐步演进。对于特别有经验和有未来野心的团队,可以直接上手高级阶段,尤其是对于公司基础设施比较完备的大型公司,很多资源已经云化了,实现起来比较容易。

    之前创业的时候,研究过网易的网易美学,自打上线就是拆分完备的系统了,如何呢?团队实力,老板支持力,妥妥的没有压力

    作者回复: 是的,小公司从20分开始演进,大公司可以从60分开始演进

    2018-07-24
    1
  • feifei
    如果业界已经有了一个明显的参照对象(例如电商企业可以参考淘宝),那架构师是否还需要按照步骤逐步演进,还是直接将架构一步到位设计好?

    这个肯定是逐步的演进,比如新上线的一个小电商网站,主要服务对象是某地区的用户,业界的淘宝已经有现有的架构,能按照淘宝的模式照搬吗?答案是肯定不行
    1,业务的规模达不到淘宝的规模,照搬只会浪费大量的人力投入,而且过亿级别的系统开发所需的开发,非普通的开发能够完成,人力成本非常高。
    2,淘宝的服务用户数已达到亿级别,刚成立的小电商肯定没有这么大的用户数,照搬只会造成资源的大量投入,硬件成本非常高
    3,初创时期是快速业务上线,照搬会造成业务上线时间长。

    以上就是我的理解,欢迎指正,谢谢

    作者回复: 小公司可以这样做,大公司可以直接参考,例如国美苏宁沃尔玛做自己的电商网站

    2018-07-24
    1
  • 小名叫大明
    我是一个架构小白,根据之前的学习,架构不是设计出来的,是一步一步演进出来的,哪有一步到位的架构。

    作者回复: 不一定一步到位,前面有位同学说的很好,淘宝100分,苏宁国美沃尔玛做电商网站可以做到60分,小公司可能做到20分就可以了

    2018-07-24
    1
  • godtrue
    课后思考及问题
    1:这节不费脑,架构师如何判断技术演进的方向?
    老师讲的很对市场、业务、管理,但我觉得应该上升到国家层面,至少咱们国家是这样的。国家政策的推动,使技术飞速的发展,比如:任何地方几乎都能上网,有了这些基础设施的建设,手机才能有更多的市场,有了市场才有钱转,这样又促进了技术得发展。技术的又帮助企业开拓更加广阔的市场,技术创新和业务发展就像一个太极图,在市场的大盘子里相互的推进和影响。
    2:如果业界已经有了一个明显的参照对象(例如电商企业可以参考淘宝),那架构师是否还需要按照步骤逐步演进,还是直接将架构一步到位设计好?
    这个我觉得不是不想而是不能,这是人、才、物的限制,另外,即使让现在的淘宝团队再造一个淘宝,想一模一样也不可能,虽然还没加入阿里,但我猜想以他们规模,代码复杂度极其庞杂,单单维护就会花费不菲的代价,做出一个一模一样的淘宝市场也是不会认可的,花了银子没有收益自然没法做呀!
    所以,根据自身及所在企业的具体情况,一步步演进架构是少不了的。

    作者回复: 分析不错

    2019-09-03
  • 赤城
    软件架构与其他系统有很大的不同就是有的时候解决问题的办法并不是唯一的,有时候依靠合理的系统架构,优秀的软件工程师来实现需求,有时候仅需要简单的堆砌硬件即可,有时候可以购买第三方服务实现,有时候又可以通过自家开发团队来实现,这些决策都需要架构师有更高的认识,不仅仅停留在技术层面。

    作者回复: 没有什么系统解决方案是唯一的

    2019-08-29
  • (╯‵□′)╯︵┻━┻
    业务是变化的,架构是跟着业务变化的。所以解决眼下问题可以先参考业务的应用场景相似度,实现之后,还要继续深入了解对方通过架构衍化解决问题的思路,使自己具备回归到业务的能力。
    2019-08-11
  • 刘楠
    技术和架构是不能脱离业务来谈的,天天被伪需求烦死了,业务明明没那么大,不需要那么多微服务,非要做那么复杂的系统,做出来又是一堆问题

    作者回复: 焦油坑😂

    2019-04-25
收起评论
33
返回
顶部