09 | 架构设计原则案例

精选留言(50)

• 

  公号-代码荣耀

  今日心得
  
  通过文中对淘宝和手机 QQ 两个典型互联网业务的架构发展历程的详细拆解，可以看出，大型互联网架构发展的最重要甚至唯一的驱动力就是"情非得已"，伴随业务的高速发展，用户、数据、流量、业务复杂度都在呈指数级增长，总会突破现有商业、开源条件能够提供的解决方案的有效范围，企业发展到一定程度最终还是要立足自力更生，去摸索、去创新适合自己需求、符合自己业务体系的系统架构。
  
  为此，从更宏观的视角来看，不断演化是其架构发展的主旋律，而满足适合、追求简单是架构决策的重要依据。需求驱动技术的创新演化；技术反哺业务的发展升级。

  2018-05-17

  

   37
• 

  小小笑儿

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

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

  2018-05-18

  

   20
• 

  何国平

  所以有些公司要求两三年就重构一次

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

  2018-05-18

  

   17
• 

  米斯特.杜

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

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

  2018-05-17

  

   9
• 

  李彦余

  架构这种话题不好讲，原则适用性更不好把控，概念性的东西太多，简单原则相对最好把控，至于合适原则与演绎，这个主要就看架构师的理解和实际能力了。
  特别说到有些行业追求的是概念，新兴公司追求实用，更是不好取舍，最终又变成了怎么把控真正的需求，这个才是核心。
  唯一可量化的就是复杂度了，所以非功能性的普适性更高。

  2018-05-21

  

   6
• 

  xinsz08

  能不能讲下关于并发和pv，日活，在线人数的计算方式和关系

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

  2018-05-18

   1

   4
• 

  独步舞者

  也是受那个时代技术的影响决定的，05年有分布式，阿里也会选择使用

  作者回复: 分布式一直都有的，不是05年后才出现的

  2018-05-17

  

   4
• 

  如风

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

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

  2018-05-22

  

   3
• 

  黄金的太阳

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

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

  2018-05-17

  

   3
• 

  孙振超

  各个公司的架构都是逐渐演进成当前的样子，在达到同样目的的过程中实现手段确并不完全相同，蚂蚁和阿里都进行了多地多中心部署的架构改造，但二者在诸如配置中心、跨ldc访问管控等方面都不尽相同，即使在蚂蚁内部也出现了后续实现推翻原始规划的情况。在多地多中心部署架构改造完成后，为进一步降低成本，避免大促活动中机器的浪费，又开始了弹性部署的改造，希望能够在大促高峰来临的前几个小时再临时增加服务器，等活动结束服务器就立即回收。等这个搞定，又开始在线离线混布的改造，进一步降低整体成本。
  这些改造只所以一个接一个的能够实现，也在于使用的主要中间件和框架都是自研的，知根知底，可以快速迭代修改，如果是使用第三方的或者购买的，一方面可能非常贵，另一方面可能根本不支持，要重新设计改造部署所需的时间要远远大于自研的成本。

  作者回复: 是的，有钱有人业务又复杂，可以自己弄

  2018-06-04

  

   2
• 

  one day

  在简单，演化，合适三原则之下我们也要考虑当时的技术水平，淘宝开始的技术是没有目前分布式成熟系统的，我们在架构设计时并不一定开始就搭建一个只是简单的系统，因为我们占在时代前进的道路上，原来是复杂的现在反而是简单，原来需要演化许多年的，现在也可能只需几天。根据业务，根据技术，根据人员，根据时间，根据可看到的未来。架构不确定，多思，就让设计的架构多撑几年

  作者回复: 时代不同，同样的原则，做法不同，2004年简单就是买Oracle，2018年就是买阿里云

  2018-05-28

  

   2
• 

  bigticket

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

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

  2018-05-26

  

   2
• 

  MichaelJY

  感觉所有的互联网产品都要遵循上面的原则。
  首先要合适，然后简单，最后演进。
  互联网时代机会稍纵即逝，所以要快速出一个基础产品，要快，要活下来先！然后随着业务的发展，逐步演进架构，当然这里面也涉及到一些技术架构的决策。
  
  感觉上面的三原则和敏捷开发宗旨差不多，快速地持续地交付有价值的产品！
  
  

  作者回复: 传统行业的系统很多都是买的，客户不希望买了后不到1年就又要改，因此当然希望希望买一套设备顶10年，但后果就是买了大量没用的功能和特性，记得某位专家说过电信设备85%的功能都是浪费的

  2018-05-21

  

   2
• 

  SHLOMA

  李老师，您好，简单和合适原则是否是贯穿所有架构设计，而演化原则，则是指在当前架构无法通过优化手段适应当前业务量，重新设计架构?

  作者回复: 演化原则也要在每次架构设计的时候遵守，避免过度设计

  2018-05-20

  

   2
• 

  辉辉

  适合互联网:快，短，频。是不是一定适合传统IT行业?传统IT行业，现在打标拼的技术部分不再是合适，简单，演化。是各种高大尚的方案。

  作者回复: 确实如此，很多朋友也都反馈这种情况，我的建议是把这些当做合规要求，在此基础上应用架构设计三个原则

  2018-05-18

  

   2
• 

  Bob

  要是当年淘宝买了商用的PHP连接池，世界将会怎样？PHP会真的成为宇宙第一语言吗😂

  作者回复: 很有可能，PHP是世界上最好的语言😂
  如果当时不是能够请到sun和oracle的专家，估计就是php了

  2018-05-17

  

   2
• 

  追寻云的痕迹

  从0到1时牢记KISS原则，做大业务，等你有钱了自然请得起人了😂

  作者回复: 有钱也不要浪费哦，好钢花在刀刃上😃

  2018-05-17

  

   2
• 

  赤城

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

  作者回复: 分析到位👍

  2019-07-12

   1

   1
• 

  Dong Zhang

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

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

  2018-09-08

  

   1
• 

  syhasia

  请问老师，多租户（大于1k）场景下，用户读次数远大于写，数据库需要分库分表吗？还是一个库多个schema（一个schema代表一个用户）就够了？

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

  2018-09-05

  

   1