从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152572 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

09 | 架构设计原则案例

演化原则
简单原则
合适原则
重新设计架构
重构架构
架构改造
简单架构
去IOE化
自研技术
加入缓存、CDN、开源的JBoss
放弃EJB,引入Spring
数据分库
选择Java的原因
切换到Java
买NAS和Oracle RAC
买更高配置的Oracle
买一个轻量级系统
快速上线
探讨案例中体现的架构设计原则
分析其他互联网大厂的架构发展案例
架构设计原则
亿级IM
千万级IM
百万级IM
十万级IM
Java时代3.0和分布式时代
Java时代2.0
Java时代1.0
Oracle/支付宝/旺旺
个人网站
下一步
总结
手机QQ
淘宝
架构设计原则的案例

该思维导图由 AI 生成,仅供参考

周二,我给你介绍了架构设计的三条核心原则,先复习一下:合适原则、简单原则和演化原则。我们在架构设计实践中,应该时刻谨记这三条设计原则,指导我们设计出合适的架构,即使是代表中国互联网技术最顶尖水平的 BAT,其架构的发展历程也同样遵循这三条原则。
今天我就以大家耳熟能详的淘宝和手机 QQ 作为案例,来简单分析一下。

淘宝

注:以下部分内容摘自《淘宝技术发展》。
淘宝技术发展主要经历了“个人网站”→“Oracle/ 支付宝 / 旺旺”→“Java 时代 1.0”→“Java 时代 2.0”→“Java 时代 3.0”→“分布式时代”。我们看看每个阶段的主要驱动力是什么。
1. 个人网站
2003 年 4 月 7 日马云提出成立淘宝,2003 年 5 月 10 日淘宝就上线了,中间只有 1 个月,怎么办?淘宝的答案就是:买一个。
估计大部分人很难想象如今技术牛气冲天的阿里最初的淘宝竟然是买来的,我们看看当初决策的依据:
当时对整个项目组来说压力最大的就是时间,怎么在最短的时间内把一个从来就没有的网站从零开始建立起来?了解淘宝历史的人知道淘宝是在 2003 年 5 月 10 日上线的,这之间只有一个月。要是你在这个团队里,你怎么做?我们的答案就是:买一个来。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

淘宝和手机QQ的架构设计原则实践 本文以淘宝和手机QQ为案例,展示了架构设计原则在实践中的应用。文章介绍了架构设计的三条核心原则:合适原则、简单原则和演化原则,并指出即使是代表中国互联网技术最顶尖水平的BAT,其架构的发展历程也同样遵循这三条原则。通过淘宝和手机QQ的案例分析,读者可以了解到这些顶尖互联网技术公司是如何在架构设计中贯彻这些原则的。这样的案例分析有助于读者更好地理解架构设计原则的实际运用,为他们在实践中设计合适、简单且易于演化的架构提供了有益的参考。 淘宝的技术发展历程经历了从个人网站到分布式时代的演变,每个阶段都体现了不同的架构设计原则的应用。在初创阶段,淘宝以“快”为主要业务要求,因此架构设计和选择主要遵循的是“合适原则”和“简单原则”。随着业务的迅速发展,淘宝采取了“买”的方式来快速解决问题,体现了“合适原则”和“简单原则”的应用。随着技术问题影响业务发展,淘宝进行了重构,体现了“演化原则”的应用。在Java时代2.0,淘宝进行了多项优化工作,围绕着提高容量、性能、节约成本来做,体现了架构设计遵循了“合适原则”和“简单原则”。最终,淘宝技术从商用转为“自研”,进入分布式时代,体现了技术的修炼成功,自研技术已经自成一派,除了支撑本身的海量业务。这些阶段的演变展示了架构设计原则在实践中的应用,为读者提供了宝贵的经验和启示。 手机QQ的发展历程也展现了架构设计原则的应用。从十万级IM到亿级IM,不同阶段的用户规模推动了架构的演化,体现了“合适原则”、“简单原则”和“演化原则”的应用。随着用户规模的增长,架构不断升级和重构,以适应业务的发展和挑战。 通过本文的阐述,读者可以深入了解淘宝和手机QQ在架构设计中的实践经验,以及这些顶尖互联网技术公司是如何贯彻合适、简单和易于演化的架构设计原则。这对于技术领域的从业者来说,将是一次宝贵的学习和启发。文章通过具体案例,生动展示了架构设计原则在实践中的应用,为读者提供了有益的参考和启示。 总之,本文通过深入分析淘宝和手机QQ的架构设计实践,生动展示了合适、简单和易于演化的架构设计原则在顶尖互联网技术公司中的应用。这对于读者来说是一次宝贵的学习和启发,也为他们在实践中设计合适、简单且易于演化的架构提供了有益的参考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(65)

  • 最新
  • 精选
  • 小小笑儿
    适合原则,简单原则,演化原则这三个点归纳得很精辟,本次课程也通过实例来讲解了各个原则的使用。但是我还有个小小的疑问,就是在对这些成功项目进行复盘的时候我们可以很清楚的辨别什么时候采用什么原则优先,而如果把我们回到之前选择的时间点上,如何更准确的判断应该采用什么原则呢?

    作者回复: 合适原则第一考虑,优先满足业务需求; 简单原则第二考虑,挑选简单方案快速落地验证; 演进原则第三考虑,适当预测业务发展,感觉预测不准就不预测,等真的出现问题的时候演进即可

    2018-05-18
    76
  • 米斯特.杜
    探讨个问题,希望可以得到回答。之前看过云栖社区对faceu的cto的采访,他说当时他们上第一版后台系统时就直接选型了阿里云的drds,他自己也不知道用户量会不会上来。他还说如果当时他没选drds方案,到后来用户井喷式增长时系统再做调整估计等不到改好用户就跑光了。所以我的问题是,对于像这种近两年创业的公司可能做出爆款产品时,系统架构方面是否需要向前多考虑一些?

    作者回复: 站在巨人的肩膀上,其实他们也是选了简单的方案,同样遵循合适原则和简单原则。2004年时遵循简单原则是买oracle,2016年遵循简单规则是买阿里云,一个道理

    2018-05-17
    2
    42
  • 何国平
    所以有些公司要求两三年就重构一次

    作者回复: 至少说明这个公司重视技术

    2018-05-18
    3
    39
  • 考休
    技术的架构有很大一方面也是由于互联网产品的特殊演化导致的,互联网产品讲究小步快跑、快速迭代,尤其是在产品初期,需要依据初始用户的反馈快速优化产品,所以技术上来说产品初期对可扩展性的要求比较高,而到了中后期,由于产品的核心功能开始稳定,但是用户量又达到了一定的量级,这个时候又对系统的高性能、高可用提出来较高的要求。

    作者回复: 分析到位👍

    2019-07-12
    4
    29
  • 沐风
    能不能讲下关于并发和pv,日活,在线人数的计算方式和关系

    作者回复: 跟业务有关,不存在恒等式呢 一般来说: pv=日活*人均点击次数 并发均值=pv/86400 并发峰值=并发均值*N

    2018-05-18
    4
    28
  • bigticket
    今天看到一条微博,收集了七年前appstore里微信的用户评价,骂声一片,很多是说连不上数据库的问题,而现在用微信已经很少出现bug,感觉非常能体现架构演进的原则,早期用户量少,架构设计主要考虑合适、简单两个原则,当用户量变大引起复杂度提高,从而导致无法正常运行时,倒逼架构进行演进优化。现在能支持的高峰大并发的方案很多,应该算比较成熟了,那下一个能打破现有架构设计的业务需求可能是什么?感觉又回到了要不要预测问题,过度设计的循环中…

    作者回复: 如果是微信,现有架构基本不会演进了,因为促使微信架构演进的推动力已经没有了,一个是用户量(除非微信能全球普及,目前来看不太可能),一个是业务复杂度,这两个已经基本到头了,即使微信做新的业务,其实只是用了微信的账号和流量,不需要改变微信已有的架构,新业务自己搭建新架构即可

    2018-05-26
    24
  • syhasia
    请问老师,多租户(大于1k)场景下,用户读次数远大于写,数据库需要分库分表吗?还是一个库多个schema(一个schema代表一个用户)就够了?

    作者回复: 分库分表主要是写请求扛不住,读请求扛不住用读写分离加缓存就够了

    2018-09-05
    18
  • Dong Zhang
    我是做infra的,企业部分打交道多,主要做设计实施,售前设计接触过一点。前期拼方案的时候,演进原则不好说,简单和适用还是要的吧,为了降低竞标成本。当然最重要的是和客户感情上关系上生意上都谈拢,很多时候标书都可能是抄某个牌子来的。设计实施的时候简单适用还是很重要,演进还真不是特别快,一般能用未来3~5年就好。我在infra看,构架师和客户的沟通、说服、取信非常重要,特别不同部门不同级别;集成商将各种厂商粘合到一起很难,需要的知识很广;构架师对于项目和行业具体情况的经验积累也是很重要。总体来说我觉得构架师的双商都要高,既能搞定人,也要有技术广度和一定深度,还要有丰富的领域和临场经验。

    作者回复: 你说的这种角色类似在菊花厂叫“系统分析师”,对业务理解和行业理解要求很高,系统分析师和架构师都要求双商

    2018-09-08
    12
  • 如风
    很多跟我们公司类似,公司从创业再到上市,从无到有,再到每天几千万笔的流量都经历过了,开始也是追求快,所有业务公用一个数据库,一出现问题,引发全部拖死,不断优化演进,业务及架构不断分离,很多东西也是买,买云服务,架构不只是简单的一个框架,涉及的东西太广了,从网络服务器,再到应用软件,数据存储等等,需要建立一套可行的运维监控体系...

    作者回复: 以前大部分这样,现在不一定要这样做,买云服务也是可以的,同样符合简单原则和合适原则

    2018-05-22
    9
  • 黄金的太阳
    一直追剧追到现在,感觉受益匪浅,也是第一次留言,因本人能力有限,这篇文章中关于架构演进过程中各个环节希望能有更进一步关于架构图的配套说明,例如 1.本次演进改进的点在哪里 2.为什么这样设计就能解决当时的问题 而不是直接一张图,没有任何说明,也许对于架构师大神们是很小白的问题,但咱们的课程是不是要考虑到从0开始学架构的兄弟们呢?一点小建议

    作者回复: 这些都是腾讯和手淘的公开资料,里面也提炼了演进和选型的原因,至于更多的细节,有兴趣可以直接买他们的书来看,书名《淘宝技术这十年》

    2018-05-17
    2
    8
收起评论
显示
设置
留言
65
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部