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

10 | 架构设计流程:识别复杂度

可扩展性:不需要特别的可扩展性
高可用性:保证消息写入、存储、读取的高可用性
高性能读取:TPS 1380,QPS 13800
高可用消息读取
高可用消息存储
高可用消息写入
高性能消息读取
子系统强耦合导致开发效率低下
系统间协作效率低下
设计目标
分析复杂度
前浪微博的业务问题
复杂度的判断需要根据具体情况进行排序和优先级设定
架构的复杂度来源于高性能、高可用、可扩展等方面
正确分析系统的复杂性是架构设计的关键
架构设计的本质目的是解决软件系统的复杂性
识别复杂度需要综合考虑业务、技术和团队等因素
在实际应用中,不同系统可能有不同的复杂度分析
通过分析复杂度来确定设计目标和方案
架构设计流程的第一步是识别复杂度
识别复杂度实战
架构设计第1步:识别复杂度
总结
架构设计流程第一步:识别复杂度

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

从今天开始,我将分 4 期,结合复杂度来源和架构设计原则,通过一个模拟的设计场景“前浪微博”,和你一起看看在实践中究竟如何进行架构设计。今天先来看架构设计流程第 1 步:识别复杂度。

架构设计第 1 步:识别复杂度

我在前面讲过,架构设计的本质目的是为了解决软件系统的复杂性,所以在我们设计架构时,首先就要分析系统的复杂性。只有正确分析出了系统的复杂性,后续的架构设计方案才不会偏离方向;否则,如果对系统的复杂性判断错误,即使后续的架构设计方案再完美再先进,都是南辕北辙,做的越好,错的越多、越离谱。
例如,如果一个系统的复杂度本来是业务逻辑太复杂,功能耦合严重,架构师却设计了一个 TPS 达到 50000/ 秒的高性能架构,即使这个架构最终的性能再优秀也没有任何意义,因为架构没有解决正确的复杂性问题。
架构的复杂度主要来源于“高性能”“高可用”“可扩展”等几个方面,但架构师在具体判断复杂性的时候,不能生搬硬套,认为任何时候架构都必须同时满足这三方面的要求。实际上大部分场景下,复杂度只是其中的某一个,少数情况下包含其中两个,如果真的出现同时需要解决三个或者三个以上的复杂度,要么说明这个系统之前设计的有问题,要么可能就是架构师的判断出现了失误,即使真的认为要同时满足这三方面的要求,也必须要进行优先级排序。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

架构设计的第一步是识别复杂度。在进行架构设计时,首先需要分析系统的复杂性,以便后续的设计方案不偏离方向。复杂度主要来源于高性能、高可用、可扩展等方面,但并非所有系统都需要同时满足这三个要求。在实际情况下,需要根据综合情况进行排序,优先解决当前面临的最主要的复杂度问题。对于按照复杂度优先级解决的方式,可能会出现解决了优先级排在前面的复杂度后,解决后续复杂度的方案需要将已经落地的方案推倒重来。然而,软件系统的可塑性和易变性使得总是可以挑出综合来看性价比最高的方案。识别复杂度对架构师来说是一项挑战,需要在理解需求的基础上进行分析。有经验的架构师可能一看需求就知道复杂度大概在哪里;如果经验不足,那只能采取“排查法”,从不同的角度逐一进行分析。因此,正确的做法是将主要的复杂度问题列出来,然后根据业务、技术、团队等综合情况进行排序,优先解决当前面临的最主要的复杂度问题。 在实战案例中,以“前浪微博”为例,通过排查法分析了消息队列系统的复杂度。首先,对系统的高性能、高可用性和可扩展性进行了详细分析,以确定设计目标和需求。针对消息队列系统的复杂性,主要体现在高性能消息读取、高可用消息写入、高可用消息存储和高可用消息读取等方面。通过这一案例,读者可以了解到如何通过排查法分析系统的复杂度,并根据需求和情况进行设计方案的优先级排序。 总的来说,本文通过实际案例向读者介绍了架构设计流程的第一个步骤“识别复杂度”,并详细讲解了排查法的具体分析方式。这对于读者在实际工作中进行架构设计时,能够提供一定的指导和帮助。通过深度思考和实践,读者可以更好地理解系统复杂度的分析方法,从而为架构设计提供更加合理和有效的方案。

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

全部留言(97)

  • 最新
  • 精选
  • pk
    文中有一句话:TPS 1780 并不高。这个结论怎么来的?作者经验丰富,见过很高的TPS。 但作为新手,如何衡量这个性能要求高还是不高呢?

    作者回复: 对于架构师来说,常见系统的性能量级需要烂熟于心,例如nginx负载均衡性能是3万左右,mc的读取性能5万左右,kafka号称百万级,zookeeper写入读取2万以上,http请求访问大概在2万左右。 具体的数值和机器配置以及测试案例有关,但大概的量级不会变化很大。 如果是业务系统,由于业务复杂度差异很大,有的每秒500请求可能就是高性能了,因此需要针对业务进行性能测试,确立性能基线,方便后续架构设计做比较。

    2018-05-21
    21
    378
  • XP
    感觉这个专栏定位是扫盲,留言的读者都是老司机

    作者回复: 应该是兄台水平高,所以觉得定位是扫盲,实际上很多人不知道这些内容,上网搜索也搜不到的

    2018-05-19
    12
    88
  • 云辉
    复杂度问题,还有是方案简单,但是沟通协调成本高,跨部门了,请问华仔,你们是自己推动,还是技术PMO推动。

    作者回复: 架构师推动是主要的,架构师需要五项全能:技术,沟通,推动,管理,撕逼😃😃😃

    2018-05-20
    12
    83
  • 空档滑行
    说下之前改造的一个系统,当时是这个系统从其他系统同步数据,经过一整套流程后将数据拆解到本地库的各个业务表中。 原来的系统是一个单机多线程程序,到了大促的时候延时非常厉害,因为马上又要大促了,首先想到的是扩展性的问题,于是就做了无状态服务拆分,可以横向扩展。在这过程成因为要控制单个同步实体任务的并发在处理幂等性上也花很大的功夫。做完这个后,又对非关键流程做了消息解耦,提高主流程的处理速度。 系统上线后运行稳定,但是到了大促当日发现速度提升很有限,将机器扩展到10台速度只提升了2-3倍,而且数据库和应用压力都很小。 后来分析下来瓶颈竟然是在数据库中间件上。其他系统大量的慢sql导致中间件处排队严重。 现在想起来,其实还是改造前优先级没搞清楚,根据之前的经验就把问题归结到扩展性上,投入了大部分精力在扩展性和可用性上,而没有对原来单机系统的性能做完整的测试和评估。其实当时做一个单机程序的压测大概就可以判断出问题所在(改造过程中也发现老的程序确实有bug)。还有就是高性能的优先级远大于扩展性和可用性,因为这个系统重启的影响非常小。改造的时候过于理想化的,想做一个各个方面均衡完善的架构

    作者回复: 所以系统复杂度识别是非常重要的,也没那么容易

    2018-05-20
    3
    43
  • herome
    最近在做一个平台化的crm系统,也就是公司各个业务线都可以接入 ,或者外面的业务线也能接入。但是我们在开发过程中,比如查看商家等级列表这个接口,以前所有的接入方,都是查看就是查看,但是有个主要对接方提出了个需求是,查看后如果不存在 就插入一个默认等级。,但是其他对接方没有这样的需求,也就说原接口不能变,如果没有其他接入方我直接修改原来的接口即可,根本不考虑兼容。类似的问题数不胜数, 我们每次要么是if else这种代码走不同的逻辑,要么是 新写个接口,现在我们的代码的维护已经很混乱了,一个简单的逻辑,如查看等级列表,我就要维护好几套接口,好几套逻辑。 有想过变成可配置化的,但是没有好的思路。华哥对这方面有好的建议吗?😂

    作者回复: 试试设计模式的策略模式或者职责链模式

    2018-05-19
    3
    28
  • 梅子黄时雨
    微服务架构,是解决了什么复杂性问题呢

    作者回复: 可扩展

    2018-05-21
    4
    26
  • renwotao
    公司架构日志占了百分之二十的cpu,有什么好的解决方案吗

    作者回复: 日志压缩,采样,隔离

    2018-06-13
    3
    17
  • joyafa
    我现在做的是交易转发网关,性能瓶颈很大一部分也受上级券商网关影响,系统无状态,无数据库操作,因为涉及到交易,对可用性要求很高,需要能快速处理客户端的请求,经过多次压测,也没有排查出自身系统问题出在哪里,对系统压测,以及测试得到的数据该怎么分析,怎么找出问题所在?

    作者回复: 网关的性能可以参考nginx的性能,如果你们的测试数据和nginx做网关差异很大,那可能是并发模型甚至记日志这些不起眼的操作给拖慢了,如果差不多,那基本就是性能极限了

    2018-05-31
    2
    17
  • allen.huang
    识别复杂度方面比较难,如果判断错误,容易误入歧途。像我们公司是属于创业型公司,业务迭代很快,前面两三年都在堆业务,并且所有的业务都在一个系统上,web服务器一台,数据库RDS一台,那个时候流量并不大,公司高层没有重视,不考虑优化,还是以发展业务为主。 今年业务量起来了之后才重视,流量会对现有系统有所影响。于是讨论出最终方案,重新起一套框架,来重构,原来的老系统继续使用。结果实施发现周期重新起一套开发时间上,公司等不及,开发了3个月都没有出来就胎死腹中了。 但那个时候开始老系统经常频繁出问题了,有时是web请求量比较大WEB服务器CPU 100%,WEB服务器都登录不进去。有时是数据库操作比较频繁,数据库100%。只能重启web服务器来临时应对,有一次业务高峰更尴尬,连服务器重启都没有用,一重启流量一进来又100%。 这个时候通过分析web请求日志,慢查询日志来进行分析,然后来制定出优化方案,在原有的老系统上来进行优化。 但推进这个优化的过程中,也是比较费劲,研发人员比较害怕在老的系统上来进行优化了,怕优化后用不了,这好比是在给飞行中的飞机加油。后面通过领导的支持下达,通过分析报告的结果,把老系统的服务由简单到难逐步拆分: 1. 先拆分的是静态资源放到OSS上并做成CDN化。 2. 将慢查询进行优化,能利用缓存的,用缓存,大表的联表查询,拆分成单表查询。 3. 将轮询在调用接口的迁移到其他服务器,将一些轮询的计划任务服务也迁移到其他服务器。 这样子系统算是稳定下来,但要走的路还很长。 我写了这些事故的经历,就是在互联网公司成长过程中都会经历,对于技术复杂度的判断很重要,要是一开始我们就打算先从老系统来进行优化,就会避免一些事故的发生,还有就是技术上的推动,还是需要由公司领导的大力支持,首先要说服领导,说服老板,上通下达才行。

    作者回复: 架构师必须能说得动老板

    2018-12-12
    3
    16
  • prader26
    做了一个很小的系统,就给几个领导看,所以写代码的时候,没注意加锁,和并发。所有的功能都在一个系统里,只求速度。。。

    作者回复: 这种算demo系统,能跑起来就可以了,关键是要把界面做的漂亮😂

    2021-01-21
    15
收起评论
显示
设置
留言
97
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部