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

11 | 架构设计流程:设计备选方案

在备选方案2的基础上,将MySQL存储替换为自研实现存储方案
利用MySQL的主备复制实现高可用存储和高可用读取
集群方式满足高可用写入和高性能读取
集群方式满足高性能消息读取
单服务器高性能备选方案
备选方案的技术不要只局限于已经熟悉的技术
备选方案的差异要比较明显
备选方案的数量以3 ~ 5个为最佳
评审效果差
忽略整体的技术设计
耗费大量时间和精力
单一方案设计会出现过度辩护的情况
架构师的经验知识和技能有局限
心里评估过于简单,可能没有想得全面
避免浪费资源开发无用的系统或无法实现的情况
设计合适自己业务、团队、技术能力的方案才是好方案
技术的组合和递归特征改变了对技术本质的认识
技术都是在现有技术的基础上发展起来的
可扩展的分层、插件化等技术
高性能的负载均衡、多路复用
高可用的主备方案、集群方案
对组合后的方案进行修改和调整
挑选合适的架构模式进行组合
对已经经过验证的架构模式烂熟于心
对已经存在的技术非常熟悉
设计多个备选方案是合理的做法
给出了备选方案的设计样例
架构设计流程的第二个步骤:设计备选方案
备选方案的设计样例
备选方案3:集群 + 自研存储方案
备选方案2:集群 + MySQL存储
备选方案1:采用开源的Kafka
设计多个备选方案的最佳做法
备选方案过于详细的错误
只做一个方案的错误
设计最优秀的方案的错误
技术的组合和递归特征
成熟的技术
架构师的工作
小结
设计备选方案实战
架构设计第2步:设计备选方案
架构设计流程第二步:设计备选方案

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

上一期我讲了架构设计流程第 1 步识别复杂度,确定了系统面临的主要复杂度问题后,方案设计就有了明确的目标,我们就可以开始真正进行架构方案设计了。今天我来讲讲架构设计流程第 2 步:设计备选方案,同样还会结合上期“前浪微博”的场景,谈谈消息队列设计备选方案的实战。

架构设计第 2 步:设计备选方案

架构师的工作并不神秘,成熟的架构师需要对已经存在的技术非常熟悉,对已经经过验证的架构模式烂熟于心,然后根据自己对业务的理解,挑选合适的架构模式进行组合,再对组合后的方案进行修改和调整。
虽然软件技术经过几十年的发展,新技术层出不穷,但是经过时间考验,已经被各种场景验证过的成熟技术其实更多。例如,高可用的主备方案、集群方案,高性能的负载均衡、多路复用,可扩展的分层、插件化等技术,绝大部分时候我们有了明确的目标后,按图索骥就能够找到可选的解决方案。
只有当这种方式完全无法满足需求的时候,才会考虑进行方案的创新,而事实上方案的创新绝大部分情况下也都是基于已有的成熟技术。
NoSQL:Key-Value 的存储和数据库的索引其实是类似的,Memcache 只是把数据库的索引独立出来做成了一个缓存系统。
Hadoop 大文件存储方案,基础其实是集群方案 + 数据复制方案。
Docker 虚拟化,基础是 LXC(Linux Containers)。
LevelDB 的文件存储结构是 Skip List。
在《技术的本质》一书中,对技术的组合有清晰的阐述:
新技术都是在现有技术的基础上发展起来的,现有技术又来源于先前的技术。将技术进行功能性分组,可以大大简化设计过程,这是技术“模块化”的首要原因。技术的“组合”和“递归”特征,将彻底改变我们对技术本质的认识。
虽说基于已有的技术或者架构模式进行组合,然后调整,大部分情况下就能够得到我们需要的方案,但并不意味着架构设计是一件很简单的事情。因为可选的模式有很多,组合的方案更多,往往一个问题的解决方案有很多个;如果再在组合的方案上进行一些创新,解决方案会更多。因此,如何设计最终的方案,并不是一件容易的事情,这个阶段也是很多架构师容易犯错的地方。
第一种常见的错误:设计最优秀的方案。
很多架构师在设计架构方案时,心里会默认有一种技术情结:我要设计一个优秀的架构,才能体现我的技术能力!例如,高可用的方案中,集群方案明显比主备方案要优秀和强大;高性能的方案中,淘宝的 XX 方案是业界领先的方案……
根据架构设计原则中“合适原则”和“简单原则“的要求,挑选合适自己业务、团队、技术能力的方案才是好方案;否则要么浪费大量资源开发了无用的系统(例如,之前提过的“亿级用户平台”的案例,设计了 TPS 50000 的系统,实际 TPS 只有 500),要么根本无法实现(例如,10 个人的团队要开发现在的整个淘宝系统)。
第二种常见的错误:只做一个方案。
很多架构师在做方案设计时,可能心里会简单地对几个方案进行初步的设想,再简单地判断哪个最好,然后就基于这个判断开始进行详细的架构设计了。
这样做有很多弊端:
心里评估过于简单,可能没有想得全面,只是因为某一个缺点就把某个方案给否决了,而实际上没有哪个方案是完美的,某个地方有缺点的方案可能是综合来看最好的方案。
架构师再怎么牛,经验知识和技能也有局限,有可能某个评估的标准或者经验是不正确的,或者是老的经验不适合新的情况,甚至有的评估标准是架构师自己原来就理解错了。
单一方案设计会出现过度辩护的情况,即架构评审时,针对方案存在的问题和疑问,架构师会竭尽全力去为自己的设计进行辩护,经验不足的设计人员可能会强词夺理。
因此,架构师需要设计多个备选方案,但方案的数量可以说是无穷无尽的,架构师也不可能穷举所有方案,那合理的做法应该是什么样的呢?
备选方案的数量以 3 ~ 5 个为最佳少于 3 个方案可能是因为思维狭隘,考虑不周全;多于 5 个则需要耗费大量的精力和时间,并且方案之间的差别可能不明显。
备选方案的差异要比较明显例如,主备方案和集群方案差异就很明显,或者同样是主备方案,用 ZooKeeper 做主备决策和用 Keepalived 做主备决策的差异也很明显。但是都用 ZooKeeper 做主备决策,一个检测周期是 1 分钟,一个检测周期是 5 分钟,这就不是架构上的差异,而是细节上的差异了,不适合做成两个方案。
备选方案的技术不要只局限于已经熟悉的技术设计架构时,架构师需要将视野放宽,考虑更多可能性。很多架构师或者设计师积累了一些成功的经验,出于快速完成任务和降低风险的目的,可能自觉或者不自觉地倾向于使用自己已经熟悉的技术,对于新的技术有一种不放心的感觉。就像那句俗语说的:“如果你手里有一把锤子,所有的问题在你看来都是钉子”。例如,架构师对 MySQL 很熟悉,因此不管什么存储都基于 MySQL 去设计方案,系统性能不够了,首先考虑的就是 MySQL 分库分表,而事实上也许引入一个 Memcache 缓存就能够解决问题。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

架构设计流程的第二步是设计备选方案。在这一步骤中,架构师需要关注技术选型而不是技术细节,避免过于详细的设计,并选择适合业务、团队和技术能力的方案。备选方案的数量以3~5个为最佳,且差异要比较明显。文章通过模拟“前浪微博”消息系统,给出了三个备选方案的设计样例,包括采用开源的Kafka、集群+MySQL存储、以及集群+自研存储方案。备选方案设计的关键在于选择合适的技术和模式进行组合,并对组合后的方案进行修改和调整。架构师的技术储备越丰富、经验越多,备选方案也会更多,从而才能更好地设计备选方案。整体而言,本文通过实例展示了架构设计备选方案的流程和注意事项,为读者提供了一定的指导和思考方向。

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

全部留言(85)

  • 最新
  • 精选
  • 公号-技术夜未眠
    设计备选方案心得 经过架构设计流程第 1 步——识别复杂度,确定了系统面临的主要复杂度问题,进而明确了设计方案的目标,就可以开展架构设计流程第 2 步——设计备选方案。架构设计备选方案的工作更多的是从需求、团队、技术、资源等综合情况出发,对主流、成熟的架构模式进行选择、组合、调整、创新。 1. 几种常见的架构设计误区 (1)设计最优秀的方案。不要面向“简历”进行架构设计,而是要根据“合适”、“简单”、“演进”的架构设计原则,决策出与需求、团队、技术能力相匹配的合适方案。 (2)只做一个方案。一个方案容易陷入思考问题片面、自我坚持的认知陷阱。 2. 备选方案设计的注意事项 (1)备选方案不要过于详细。备选阶段解决的是技术选型问题,而不是技术细节。 (2)备选方案的数量以 3~5个为最佳。 (3)备选方案的技术差异要明显。 (4)备选方案不要只局限于已经熟悉的技术。 3. 问题思考 由于文中已经从开源、自研的角度提出了架构设计方案;为此,从架构设计三原则出发,也可考虑第四个备选方案:上云方案,该方案是直接采用商业解决方案,就好比阿里前期采用IOE类似。 如果是创业公司的业务早、中期阶段,可直接考虑采用阿里云/腾讯云,性能、HA、伸缩性都有保证。 此外,在文中备选方案1 - 开源方案中,如果从提供另外一种视角看问题的角度出发,个人会更加倾向于RabbitMQ。首先,RabbitMQ与Kafka都同样具备高可用、稳定性和高性能,但是,通过一些业界测试比较,RabbitMQ比Kafka更成熟、更可靠;其次,在高性能指标方面,Kafka胜出,kafka设计的初衷是处理日志,更适合IO高吞吐的处理。但是,对于“前浪微博”系统的QPS要求,RabbitMQ同样可以驾驭。为此,综合来看,会更加倾向于RabiitMQ。 最后,通过本文再结合自己做技术最大的感悟是:做事情永远都要有B方案。

    作者回复: 最好是“三方案”,又叫“第三选择”,可以防止思维狭隘,目光短浅,思维盲区等决策陷阱

    2018-05-23
    2
    96
  • 陈华英
    文中的方案写得很清晰,有理有据。只是在主备切换的时候显得略了一点,上文中提到用zookeeper或者keepalived,可以分为两个备选方案。keepalived比较简单,主要是实现虚IP的漂移,这个对客户端是透明的。如果是zookeeper的话,客户端还需要从ZK上读下主节点

    作者回复: 赞,被你发现了,限于篇幅无法细化,主备切换这部分可以有几个备选,zk是一种方式,还有不用zk的也可以。

    2018-05-22
    57
  • 星火燎原
    高可用消息存储和读取可以采用mongo和redis 这么高的gps很难保证消息不丢 那么可以采用有消息确认机制和消息回溯的MQ 或者自研rpc的时候考虑消息发送失败的时候重新选择节点然后落盘

    作者回复: 点赞,这是可行方案

    2018-05-22
    3
    36
  • 王磊
    原文这句话理解有点困难 '高性能消息读取属于“计算高可用”的范畴'

    作者回复: 写错了,属于“计算高性能”范畴

    2018-05-23
    2
    14
  • 王磊
    方案二的架构图有些question (不是problem), 这个可以理解为分库后的主备方案吗,还是所有数据库是全量,我理解是前者,因为文中说分组间不同步,那么这里缺少一个根据消息路由的模块,对吧

    作者回复: 赞,你可以思考一下怎么做😃

    2018-05-23
    3
    10
  • narry
    个人觉得方案2,3根据架构设计的3个原则已经是一个优秀的架构设计了,我只是感觉到微博的应用有个比较有特点的特征就是有热点的出现,如果热点出现,按方案2,3会出现消息都集中在一个分片中,从而导致分片所在主机处于饱和的状态,甚至崩溃掉,如果能像业务服务器中放一个sidecar(或者内嵌到程序中),来负责根据规则的消息路由,并且规则是可以调整的,这样就可以应对热点问题

    作者回复: 微博有热点,异步消息没有热点哦,消息随便发给任何一台服务器都可以,可以采取轮询或者随机算法

    2018-05-22
    9
  • gary
    李老师,我们最近帮银行做系统,发现现在银行业仍然有很多公司使用weblogic / websphere 这样的容器,就目前形势来看weblogic较一些开源方案好像确实更加稳定和安全。 目前来看老师现在给的一些技术思路都是偏互联网方向,不知道老师是否有过一些厂商产品方面经验,比如weblogic 的mq性能水平是什么样的,和开源技术比较有哪些优劣势,好像网上这方面资料也不多,所以想请教李老师。另外不知道李老师眼中如何看待这些类似oracle 大厂商产品和未来我们的互联网开源产品在市场上的发展趋势

    作者回复: 我的经验主要在互联网,总体技术趋势是云计算,不管是开源还是闭源。 Oracle这类企业,要么自己开始提供云计算云存储,要么就是为云厂商生产设备。

    2018-06-07
    6
  • SHLOMA
    李老师专栏讲解模式很好,菜鸟都能跟着进来,看到此处感觉需要学习好多技术,望老师有机会可以出个架构相关技术学习的专栏

    作者回复: 太多了,还是期望你掌握了整体架构设计理论,然后按照这套理论的指导去自己学习

    2018-06-01
    6
  • XB.Chan
    备选方案2中,采用集群+MySQL的方式开发,满足QPS13800的需求,但是MySQL按照性能来说800/秒的插入速度算是比较快了,那这样平均算下来13800/800约等于18台服务器??

    作者回复: MySQL的读写简单表结构(例如k-v)远远超过800的QPS和TPS,我们测试k-v都是上万的

    2018-06-05
    5
  • J.Smile
    当面对一个即将解决的问题时,我们前期会通过调研进行技术选型,这个过程我理解是必须要了解下细节的,避免因为选择一个看似ok的方案,最终却发现根本无法实现。

    作者回复: 要了解细节,但是这里的细节仅限于影响方案决策的细节,而不是API的某个参数这种细节。以Netty为例,理解Netty的Reactor模式,多线程模式是需要在架构设计阶段关注的细节;但是设置tcp_nodelay就不是架构阶段需要关注的细节。

    2020-12-09
    4
收起评论
显示
设置
留言
85
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部