01 | 架构设计流程（一）：识别复杂度

李运华 2019-09-06

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

取消

完成

0/1000字

划线

笔记

复制

该试读文章来自付费专栏《架构设计流程详解》，如需阅读全部文章，
请订阅文章所属专栏。

立即订阅

登录后留言

精选留言(6)

spdia

作为架构师，深入了解业务需求，非常重要。只有深入了解需求，结合团队人员能力，才能识别复杂度并进行排序，最终得出适合业务和团队的架构方案。

2019-09-10



 6
科春

希望案例能够把业务架构讲清楚，再讲技术架构。

2019-09-11



 4
k_k

划分纬度，分析各个维度的重要性，从高到低来满足。

2019-09-09



 2
stg609

文中的识别复杂度实战中所采用的排查法似乎只适用对已有系统架构的改造，因为可以基于当前系统的数据(TPS, QPS)进行识别，但是对于一个全新的系统(没有既往的数据可供参考)该如何去分析呢？

2019-10-06

 1

 1
Geek_steven_wang

做为企业业务系统类的系统架构师，对于企业业务的了解非常重要，这类系统主要是扩展性，其次是可用性，最后才是高性能。扩展性强依赖于业务发展的了解及业务本身的深入了解。

2019-11-30




东之沫沫

一般情况下，系统的业务也是不断扩展的，架构正常情况下只能满足到近期可想到的业务，团队的情况真的很重要，我们的新系统最初的设计思想被开发的技术能力打破了😂

2019-09-14





收起评论

6









下载
客户端

返回
顶部