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

2018-05-19 李运华

《从 0 开始学架构》

课程介绍



讲述：黄洲君

时长:大小4.95M



从今天开始，我将分 4 期，结合复杂度来源和架构设计原则，通过一个模拟的设计场景“前浪微博”，和你一起看看在实践中究竟如何进行架构设计。今天先来看架构设计流程第 1 步：识别复杂度。
架构设计第 1 步：识别复杂度我在前面讲过，架构设计的本质目的是为了解决软件系统的复杂性，所以在我们设计架构时，首先就要分析系统的复杂性。只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向；否则，如果对系统的复杂性判断错误，即使后续的架构设计方案再完美再先进，都是南辕北辙，做的越好，错的越多、越离谱。
例如，如果一个系统的复杂度本来是业务逻辑太复杂，功能耦合严重，架构师却设计了一个 TPS 达到 50000/ 秒的高性能架构，即使这个架构最终的性能再优秀也没有任何意义，因为架构没有解决正确的复杂性问题。
架构的复杂度主要来源于“高性能”“高可用”“可扩展”等几个方面，但架构师在具体判断复杂性的时候，不能生搬硬套，认为任何时候架构都必须同时满足这三方面的要求。实际上大部分场...



展开全文

精选留言

pk
2018-05-21
文中有一句话：TPS 1780 并不高。这个结论怎么来的？作者经验丰富，见过很高的TPS。但作为新手，如何衡量这个性能要求高还是不高呢？
作者回复: 对于架构师来说，常见系统的性能量级需要烂熟于心，例如nginx负载均衡性能是3万左右，mc的读取性能5万左右，kafka号称百万级，zookeeper写入读取2万以上，http请求访问大概在2万左右。
具体的数值和机器配置以及测试案例有关，但大概的量级不会变化很大。

如果是业务系统，由于业务复杂度差异很大，有的每秒500请求可能就是高性能了，因此需要针对业务进行性能测试，确立性能基线，方便后续架构设计做比较。
共 9 条评论
295
公号-技术夜未眠
2018-05-19
识别复杂度心得

架构设计由需求所驱动，本质目的是为了解决软件系统的复杂性；为此，我们在进行架构设计时，需要以理解需求为前提，首要进行系统复杂性的分析。具体做法是：

（1）构建复杂度的来源清单——高性能、可用性、扩展性、安全、低成本、规模等。

（2）结合需求、技术、团队、资源等对上述复杂度逐一分析是否需要？是否关键？

“高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。

“可用性”主要从服务不中断等质量属性，符合行业政策、国家法规等方面去考虑。

“扩展性”则主要从功能需求的未来变更幅度等方面去考虑。

（3）按照上述的分析结论，得到复杂度按照优先级的排序清单，越是排在前面的复杂度，就越关键，就越优先解决。

需要特别注意的是：随着所处的业务阶段不同、外部的技术条件和环境的不同，得到的复杂度问题的优先级排序就会有所不同。一切皆变化。
展开
共 5 条评论
78
XP
2018-05-19
感觉这个专栏定位是扫盲，留言的读者都是老司机
作者回复: 应该是兄台水平高，所以觉得定位是扫盲，实际上很多人不知道这些内容，上网搜索也搜不到的
共 6 条评论
71
云辉
2018-05-20
复杂度问题，还有是方案简单，但是沟通协调成本高，跨部门了，请问华仔，你们是自己推动，还是技术PMO推动。
作者回复: 架构师推动是主要的，架构师需要五项全能：技术，沟通，推动，管理，撕逼😃😃😃
共 8 条评论
66
空档滑行
2018-05-20
说下之前改造的一个系统，当时是这个系统从其他系统同步数据，经过一整套流程后将数据拆解到本地库的各个业务表中。
原来的系统是一个单机多线程程序，到了大促的时候延时非常厉害，因为马上又要大促了，首先想到的是扩展性的问题，于是就做了无状态服务拆分，可以横向扩展。在这过程成因为要控制单个同步实体任务的并发在处理幂等性上也花很大的功夫。做完这个后，又对非关键流程做了消息解耦，提高主流程的处理速度。
系统上线后运行稳定，但是到了大促当日发现速度提升很有限，将机器扩展到10台速度只提升了2-3倍，而且数据库和应用压力都很小。
后来分析下来瓶颈竟然是在数据库中间件上。其他系统大量的慢sql导致中间件处排队严重。
现在想起来，其实还是改造前优先级没搞清楚，根据之前的经验就把问题归结到扩展性上，投入了大部分精力在扩展性和可用性上，而没有对原来单机系统的性能做完整的测试和评估。其实当时做一个单机程序的压测大概就可以判断出问题所在(改造过程中也发现老的程序确实有bug)。还有就是高性能的优先级远大于扩展性和可用性，因为这个系统重启的影响非常小。改造的时候过于理想化的，想做一个各个方面均衡完善的架构
展开
作者回复: 所以系统复杂度识别是非常重要的，也没那么容易
共 3 条评论
33
三月沙@wecatch
2018-05-29
专栏本身的牛逼之处在于系统化，相似概念其实在日常架构中已经多有涉及，但是专栏用自己独有的方法论浅显易懂的论述了这些概念以及它们的关系，值得在缺乏经验的团队广而告之
26
herome
2018-05-19
最近在做一个平台化的crm系统，也就是公司各个业务线都可以接入，或者外面的业务线也能接入。但是我们在开发过程中，比如查看商家等级列表这个接口，以前所有的接入方，都是查看就是查看，但是有个主要对接方提出了个需求是，查看后如果不存在就插入一个默认等级。，但是其他对接方没有这样的需求，也就说原接口不能变，如果没有其他接入方我直接修改原来的接口即可，根本不考虑兼容。类似的问题数不胜数，我们每次要么是if else这种代码走不同的逻辑，要么是新写个接口，现在我们的代码的维护已经很混乱了，一个简单的逻辑，如查看等级列表，我就要维护好几套接口，好几套逻辑。有想过变成可配置化的，但是没有好的思路。华哥对这方面有好的建议吗？😂
作者回复: 试试设计模式的策略模式或者职责链模式
共 2 条评论
22
黑客悟理
2018-05-26
留言全是干货……
18
梅子黄时雨
2018-05-21
微服务架构，是解决了什么复杂性问题呢
作者回复: 可扩展
共 3 条评论
18
huayu00
2018-06-23
“http请求访问大概在2万左右”
请问这个是指什么，数字怎么得来的？
共 1 条评论
10
Sir Peng
2018-05-24
华仔，架构师要具备的五项全能中，"撕逼"能在哪种情况中得已体现？
作者回复: 说服别人重构，选择方案等很多时候要撕逼😂😂
共 2 条评论
10
renwotao
2018-06-13
公司架构日志占了百分之二十的cpu，有什么好的解决方案吗
作者回复: 日志压缩，采样，隔离
共 2 条评论
10
joyafa
2018-05-31
我现在做的是交易转发网关，性能瓶颈很大一部分也受上级券商网关影响，系统无状态，无数据库操作，因为涉及到交易，对可用性要求很高，需要能快速处理客户端的请求，经过多次压测，也没有排查出自身系统问题出在哪里，对系统压测，以及测试得到的数据该怎么分析，怎么找出问题所在？
作者回复: 网关的性能可以参考nginx的性能，如果你们的测试数据和nginx做网关差异很大，那可能是并发模型甚至记日志这些不起眼的操作给拖慢了，如果差不多，那基本就是性能极限了
9
彡工鸟
2018-05-20
个人看法，在顶层上看一个系统，确实会有高可用，高性能，可扩展等等多个复杂度的要求，而且可能还真的无法分出个优先级。这样就落到都要抓，都要硬，最终无法分出个主次，导致设计四不像的系统出来。针对这种情况，是否就应该动用子系统一说，将系统拆分到一定的粒度，可以聚焦到一个，或者至多两个复杂度上？而子系统自然有子系统的架构设计，技术选型来针对性地解决其复杂度问题
作者回复: 这是一种思路，比较适合业务系统，中间件系统就不太适合这种方式
8
allen.huang
2018-12-12
识别复杂度方面比较难，如果判断错误，容易误入歧途。像我们公司是属于创业型公司，业务迭代很快，前面两三年都在堆业务，并且所有的业务都在一个系统上，web服务器一台，数据库RDS一台，那个时候流量并不大，公司高层没有重视，不考虑优化，还是以发展业务为主。

今年业务量起来了之后才重视，流量会对现有系统有所影响。于是讨论出最终方案，重新起一套框架，来重构，原来的老系统继续使用。结果实施发现周期重新起一套开发时间上，公司等不及，开发了3个月都没有出来就胎死腹中了。

但那个时候开始老系统经常频繁出问题了，有时是web请求量比较大WEB服务器CPU 100%，WEB服务器都登录不进去。有时是数据库操作比较频繁，数据库100%。只能重启web服务器来临时应对，有一次业务高峰更尴尬，连服务器重启都没有用，一重启流量一进来又100%。

这个时候通过分析web请求日志，慢查询日志来进行分析，然后来制定出优化方案，在原有的老系统上来进行优化。

但推进这个优化的过程中，也是比较费劲，研发人员比较害怕在老的系统上来进行优化了，怕优化后用不了，这好比是在给飞行中的飞机加油。后面通过领导的支持下达，通过分析报告的结果，把老系统的服务由简单到难逐步拆分：
1. 先拆分的是静态资源放到OSS上并做成CDN化。
2. 将慢查询进行优化，能利用缓存的，用缓存，大表的联表查询，拆分成单表查询。
3. 将轮询在调用接口的迁移到其他服务器，将一些轮询的计划任务服务也迁移到其他服务器。
这样子系统算是稳定下来，但要走的路还很长。

我写了这些事故的经历，就是在互联网公司成长过程中都会经历，对于技术复杂度的判断很重要，要是一开始我们就打算先从老系统来进行优化，就会避免一些事故的发生，还有就是技术上的推动，还是需要由公司领导的大力支持，首先要说服领导，说服老板，上通下达才行。
展开
作者回复: 架构师必须能说得动老板
共 2 条评论
5
MichaelJY
2018-05-21
现在遇到这样的系统:
1.前后端没有分离，因为业务情况需要多窗口显示，然后是通过div分隔的，在多窗口的使用下会出现id冲突或者在a窗口的操作影响到b窗口的数据
2.系统分为三个子系统，业务子系统处理具体业务，公共子系统处理类似登录，权限，审批等，定时任务负责调度，三者之间通过http交互，没有集群，现在业务子系统耦合比较严重。业务子系统大概可以分为接入层，业务处理层，结算层，现在是一整个系统，经常发现结算层的逻辑变更，会导致接入层和业务层不可用
3.因为历史原因，对于数据校验方面做的比较差，经常出现数据格式问题，当然新增代码已经处理了这些，但是历史债务比较严重，且业务迭代很快
4.整个系统是单点，所有发版升级都会停服

我觉得最急的是4 >2 >1 >3，不知道对不对
展开
作者回复: 优先级需要根据业务和团队综合判断，不是单纯技术角度判断。
例如，如果停服影响不大的话，那2可能优于4；
如果历史债务导致投入很大，那3可能优于2
5
prader26
2021-01-21
做了一个很小的系统，就给几个领导看，所以写代码的时候，没注意加锁，和并发。所有的功能都在一个系统里，只求速度。。。
作者回复: 这种算demo系统，能跑起来就可以了，关键是要把界面做的漂亮😂
5
xiaoya
2018-08-02
我是个新手，听一遍就忘了。记住的不多😭不开心。是我接触的太少不太重视这些吧，这些很关键?这么多理论的东西，嗨，我心性太差了。一口老想都吃掉，结果都不好。认识自己驾驭自己，一点点
作者回复: 我也是从新手过来的，坚持就有收获，不要求一次就全部听懂了，
共 3 条评论
4
秋天
2018-05-21
有没有系统提升架构思维的资料推荐，感觉还没有打破那个灵感，请大神指教？
作者回复: 我的专栏就是呢，架构设计目的，架构设计原则，架构设计流程……都是架构设计系统化的技能点
4
慎独明强
2020-07-25
如何去分析自己系统的复杂度，那么项目中的痛点应该就是自己项目复杂度所在。我之前负责订单履约系统，由于订单是交易平台通过mq推送给我们，高并发不是我们系统的复杂度所在。订单拆单与发货都是自己内部系统，高性能也不是我们系统复杂度。但是我们的高可用影响到订单发货和客服满意度，订单系统是供应链的源头，与很多部门都有交互。响应业务快速性，业务复杂度和高可用是我们系统复杂度所在。按这样排序，业务复杂度，高可用，高性能。
作者回复: 非常好的分析👍
4