架构设计的基石

设计架构的目的：

为了解决软件系统复杂度带来的问题。切记，不能为了炫耀自己的技术而去设计。不能贪大求全。

 

复杂度的6个来源：

 

1. 高性能

1.1.任务分配：不同的任务分配到不同的机器上执行。

1.2任务分解：把复杂的业务系统拆分成小而简单的组成部分。但拆分过细会已指数级别增加系统间的调用 ，反而会让系统性能下降。

 

2.高可用

2.1.本质上都是用冗余来实现高可用。

2.2计算高可用

2.3存储高可用

2.4高可用状态决策：判断系统当前的状态是否正常，选举主节点。

 

3.可扩展性

3.1.利设计模式，代码封装易变的，系统分层，抽象。

3.2对未来的需求有预测

 

4.低成本

5.安全

6规模

 

 

架构设计三原则：

1.合适原则：合适优于业界领先。

1.1没那么多人，却想干那么多活，是失败原因。

1.2没有过我的积累，想一步登天，是失败原因。

1.3.没有那么卓越的业务场景，却幻想录光一闪为天才。

 

2.简单原则：简单优于复杂

2.1结构复杂，组成系统的组件过多，组件多就越有可能出现组件故障。定位问题比较难

2.2逻辑的复杂性，就是业务本身复杂。

 

3.演化原则：演化优于一步到位

3.1，windows也不是一开始设计就是win10系统。要根据情况不断迭代演进。

 

 

 

软件设计流程：

1.识别复杂度：正确分析出了复杂性，后续的架构设计方案才不会偏离方向。架构的复杂度主要来源于“高性能”“高可用”“可扩展”“业务复杂性”等几个方面，要将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂问题。

 

2.设计备选方案

2.1备选方案的数量3~5个。

2.2备选方案的差异要比较明显

2.3备选方案的技术 不要只局限已经熟悉是技术。

2.4备选方案不易过细，太浪费时间和精力。

 

3.评估和选择备选方案

3.1列出我们需要关注 的质量属性点，分别从这些质量属性的维度去评估每个广寒 。现选择最优方案

常见的方案质量属性点有：性能，可用性，硬件成本，项目投入，复杂度，安全性，可扩展性等，结合“合适原则”和“简单原则”。

3.2，评估未来业务发展的规模时，一种简单的方式是将当前的业务规模乘以2~4.比如现在的tps是200则按照tps800来设计。

 

4.详细方案设计：

4.1将最终确定的备选方案进行细化，使得备选方案变成一个可落地的设计方案。

4.2详细方案就是将方案涉及的关键技术细节给确定下来。比如用mysql分库分表，那么就需要确定哪些表要分库分表，按什么维度来分。

4.3，可通过详细方案来发现细节点是否太多，导致方案非常庞大，会让整个项目可能开开发很长时间。则说明备选方案不可行。

4.4.架构量不但要进行备选方案设计和选型，还要对备选方案的关键细节有较深的理解。