从零学架构-基础部分

我就是我 2023-10-04 21:21 16阅读 0赞

## 一、架构的基础 ##

将学习的架构设计知识总结出来，分享给大家。

![7e6900c0ab1c2be2d19ee469f4a175de.png][]

### 1.1什么是架构 ###

*  架构和框架是什么关系？有什么区别?

*  Linux有架构，MySQL有架构，JVM也有架构，应该关注哪个架构？

*  金融有架构，支付有架构，反洗钱也有架构，到底什么是架构？

先熟悉几个概念：系统和子系统，模块和组件，框架和架构。

*  概念1

系统：泛指一群有关联的个体组成，根据某种规则，能完成某类工作的群体。

子系统：也是由一群有关联的个体组成，是更大系统中的一部分。

例如：支付系统---交易子系统、账户子系统、结算子系统、网关子系统。

*  概念2

模块：是一套一致且互相有紧密关联的软件组织，包含程序和数据结构两部分。

组件：自包含的、可编程的、可重用的、与语言无关的软件单元，可以被容易的组装应用程序，例如COM组件，JavaBean组件。

区别：模块是从逻辑的角度上来拆分系统的，目的是职责分离，例如登录模块、注册、交易监测模块；组件是从物理角度上拆分系统的，例如安全加密组件、审核组件，目的是单元复用。

*  概念3

框架：实现了某种软件规范的、能提供基础功能的产品，例如Spring MVC，MyBatis。

架构：软件架构是指软件系统的顶层结构。架构需要明确系统包含哪些“个体”，架构需要明确个体运作和协作规则，架构要能区分系统和子系统间的层次关系。

### 1.2架构设计的目的 ###

架构设计的主要目的是为了解决复杂度带来的问题。

随着软件规模的增加，当系统有很多部分组成的时候，整个系统的组织协调会导致一系列新的设计问题的产生。

例如：

*  系统规模庞大，内部耦合严重，开发效率低。

*  系统耦合严重，牵一发而动全身，后续修改和扩展困难。

*  系统逻辑复杂，容易出问题，问题难排查。

### 1.3复杂度来源 ###

*  高性能单机复杂度--多进程，多线程，多任务。集群复杂度--任务分配、任务分解

*  高可用

计算高可用、存储高可用--主备、主从、主主、集群等物理结构的设计保证可用，存在一致性如何解决的问题。

系统高可用方案五花八门，但万变不离其宗，本质上都是通过“冗余”来实现高可用。

*  可扩展正确预测变化，完美封装变化，但是要做到这两点很困难。

*  低成本

往往只有“创新”才能达成低成本目标，“创新”包括引进新技术或者创造新技术。

*  安全

功能安全---XSS攻击，CSRF攻击，SQL注入，Windows漏洞，密码破解。

架构安全---DDoS攻击，目前有效手段是多层防火墙，但是功能强大、性能一般，不太适合互联网系统，在互联网系统的架构安全目前没有太好的设计手段。

*  规模功能越多，导致系统的复杂度指数级上升，最糟糕的现象是多个功能节点之间形成网状依赖。数据越多，系统的复杂度会发生质变，主要表现在大数据成了一门独立的技术领域。

## 二、架构设计三原则 ##

### 2.1合适原则 ###

合适优于业界领先

三个负面因素：

1.  没那么多人，却想干那么多活；

1.  没那么多积累，却想一步登天；

1.  没那么多卓越的业务场景，却幻想灵光一闪成为天才。

所以，优秀的架构都是在企业当前人力、条件、业务等各种因素的约束下设计出来的，能够合理整合资源，发挥最大功效，并且能快速落地。

### 2.2简单原则 ###

简单优于复杂

软件领域的复杂性体现在结构复杂性和逻辑复杂性两方面。

结构复杂性，会导致系统的组件越来越多，系统内部关系越来越复杂，在升级修改、排查问题的时候会增大难度。

逻辑复杂性，假设支付系统的所有功能都集中到一个系统中，上百人在维护几十万行代码，会不停的出现各种冲突。

所以，架构设计时如果简单方案和复杂方案都能满足需求，优先选择简单方案。

### 2.3演化原则 ###

演化优于一步到位

软件架构需要根据业务的发展不断变化。

误区：试图一步到位的设计一个软件架构，期望不管业务怎么变化，架构都是稳定的。

变化是永恒的，架构也是随着业务的变化不断演变，不断完善的。

所以，架构的设计首先是满足当前的业务需要，然后是在不断的实际应用过程中迭代。

## 三、架构设计流程 ##

架构设计也是有套路的，按照套路去做，也能做出基本可行的架构。

### 3.1有的放矢-识别复杂度 ###

架构设计的目的是解决系统的复杂性，只有正确的分析出了系统的复杂性，架构设计才能不会偏离方向。

评估一个项目的复杂度可以从八大要素来衡量

<table style=""> 
 <tbody> 
 <tr> 
 <td style="width:60px;vertical-align:top;height:52px;">序号</td> 
 <td style="width:132px;vertical-align:top;height:52px;">要素</td> 
 <td style="width:507px;vertical-align:top;height:52px;">说明</td> 
 <td style="width:243px;vertical-align:top;height:52px;">评分规则</td> 
 <td style="width:68px;vertical-align:top;height:52px;">加权因子</td> 
 </tr> 
 <tr> 
 <td style="width:60px;vertical-align:top;height:52px;">1</td> 
 <td style="width:132px;vertical-align:top;height:52px;">子系统/功能点数量</td> 
 <td style="width:507px;vertical-align:top;height:52px;">一般来说，一个系统越复杂，其按照功能域划分的子系统越多，其最终分解出来的具体功能点越多。子系统和功能点的增加与工作量的增加不是简单的线性增长关系，从只包含一个子系统到包含多个子系统，随着人员投入数量增多和组织的细分，其复杂度会因为组织间沟通和分工协作的难度而大大增加。在这一点来说，可以认为子系统的数量是划分简单项目和复杂项目的一个重要维度。</td> 
 <td style="width:243px;vertical-align:top;height:52px;">0-低、5-中、10-高。技术复杂度因素较难量化，只能根据技术要求定性分为低、中、高。</td> 
 <td style="width:68px;vertical-align:top;height:52px;">2</td> 
 </tr> 
 <tr> 
 <td style="width:60px;vertical-align:top;height:52px;">2</td> 
 <td style="width:132px;vertical-align:top;height:52px;">外围接口数量</td> 
 <td style="width:507px;vertical-align:top;height:52px;">一般的IT系统都不是系统孤岛，是和外围系统紧密相连的。与外围系统的接口数量越多，代表着进行系统间集成的复杂度越高，难度越大。这里的复杂度影响主要来自于几个方面：一个是不同系统架构间形成统一接口协议的复杂度，这需要弥合系统间差异，体现系统间关系的工作；另一个是在完全无关的两个项目组织间协调实施的复杂度，包括设计开发、联调测试等协同工作，这是比项目组内部不同子系统间的协调更为复杂的协同工作。</td> 
 <td style="width:243px;vertical-align:top;height:52px;">0-需求稳定成熟 ，5-需求较新，但相对稳定，10-需求变动频繁</td> 
 <td style="width:68px;vertical-align:top;height:52px;">1.5</td> 
 </tr> 
 <tr> 
 <td style="width:60px;vertical-align:top;height:52px;">3</td> 
 <td style="width:132px;vertical-align:top;height:52px;">承载的业务数量</td> 
 <td style="width:507px;vertical-align:top;height:52px;">在当前的IT系统架构中，往往一套体系架构上，运转着多种业务和产品。因此，一套IT系统中承载的业务和产品数量，将直接影响系统开发、配置、测试、联调工作的复杂度。</td> 
 <td style="width:243px;vertical-align:top;height:52px;">0--简单（1-5个业务），5—中等复杂（6-10个业务），10—复杂（&gt;10个业务）</td> 
 <td style="width:68px;vertical-align:top;height:52px;">1</td> 
 </tr> 
 <tr> 
 <td style="width:60px;vertical-align:top;height:52px;">4</td> 
 <td style="width:132px;vertical-align:top;height:52px;">业务数据量</td> 
 <td style="width:507px;vertical-align:top;height:52px;">大型企业的IT系统中，很多关键系统是伴随着大量的业务数据存在着的。IT系统处理数据量的大小，直接影响到IT系统的架构设计模式。一个业务处理数据量大的系统，不仅要求从硬件规模和部署上进行复杂深入的考虑，而且在应用架构设计上要充分考虑系统的并行处理、负载均衡等要求。很多在小数据量系统中可以通过人工进行的操作，在大数据量系统中则需要通过开发系统功能来实现，如数据的审核、出错回退、数据同步等。从IT系统的特点来说，可以采用最终用户数（Subscriber）来衡量业务数据量的大小。</td> 
 <td style="width:243px;vertical-align:top;height:52px;">0--小型（&lt;1000000的用户），5--中型（1000000至5000000个用户），10—大型（&gt;5000000个用户）</td> 
 <td style="width:68px;vertical-align:top;height:52px;">1</td> 
 </tr> 
 <tr> 
 <td style="width:60px;vertical-align:top;height:52px;">5</td> 
 <td style="width:132px;vertical-align:top;height:52px;">技术复杂度</td> 
 <td style="width:507px;vertical-align:top;height:52px;">技术复杂度来自于系统建设中对功能上的复杂技术要求，典型的场景包括最新技术架构、较高的安全要求、套装软件的集成等。目前各种IT系统建设已经从原来的烟囱式的一种业务一套处理程序，向生产线式的多种业务一套处理程序的架构转变。这种模式更多地需要搭建系统架构时，建立统一的数据模型，对业务进行充分的抽象，通过构建基础架构公共组件实现多种业务的支撑。</td> 
 <td style="width:243px;vertical-align:top;height:52px;">0-低、5-中、10-高。技术复杂度因素较难量化，只能根据技术要求定性分为低、中、高。</td> 
 <td style="width:68px;vertical-align:top;height:52px;">1</td> 
 </tr> 
 <tr> 
 <td style="width:60px;vertical-align:top;height:52px;">6</td> 
 <td style="width:132px;vertical-align:top;height:52px;">需求的成熟度</td> 
 <td style="width:507px;vertical-align:top;height:52px;">需求的成熟度是影响IT系统建设成本的重要因素。如省BOSS的高复杂度系统，因为需求比较成熟，有完善的规范来指导设计和开发，因此，其实施成本可以通过多省实施来实现架构复制，实现了成本摊平。而很多新的业务领域，存在着业务模式频繁变化，需求不断变动的特点，此类IT系统建设，不仅要求开发商具有丰富的系统实施经验，还要具有深入的咨询能力，对人员素质要求和系统的灵活性及扩展性都有较高的要求。</td> 
 <td style="width:243px;vertical-align:top;height:52px;">0-需求稳定成熟 ，5-需求较新，但相对稳定，10-需求变动频繁</td> 
 <td style="width:68px;vertical-align:top;height:52px;">1</td> 
 </tr> 
 <tr> 
 <td style="width:60px;vertical-align:top;height:52px;">7</td> 
 <td style="width:132px;vertical-align:top;height:52px;">系统的关键程度</td> 
 <td style="width:507px;vertical-align:top;height:52px;">系统的关键程度实际上体现的是对系统的质量要求。这种质量要求体现在系统高可用性要求（如联机交易要求7*24小时的高可用性）、系统处理正确性要求（如计费帐务的正确性处理要求）、系统处理的及时性要求（如实时计费处理的时效性要求）等。系统的关键程度越高，越要在架构设计中考虑冗余处理、正确性验证、并发处理等各种手段，确保系统运行的稳定、准确、高效。</td> 
 <td style="width:243px;vertical-align:top;height:52px;">0-非关键系统、5-中等关键系统、10-重要关键系统。</td> 
 <td style="width:68px;vertical-align:top;height:52px;">1.5</td> 
 </tr> 
 <tr> 
 <td style="width:60px;vertical-align:top;height:52px;">8</td> 
 <td style="width:132px;vertical-align:top;height:52px;">数据迁移的复杂程度</td> 
 <td style="width:507px;vertical-align:top;height:52px;">IT系统的建设过程中，除了设计开发之外，更为艰巨的工作是测试和迁移。很多IT系统需要把原有系统中的数据完整地迁移到新系统中，尤其对于数据量大的系统，数据迁移需要开发很多程序和脚本，并通过充分的测试和模拟，才能实现正确和及时的数据迁移。很多原有系统还存在较多的错误数据，这些数据的清理也是一个很大的工作。</td> 
 <td style="width:243px;vertical-align:top;height:52px;">0-简单少量迁移，5-中等复杂迁移，10-高度复杂迁移</td> 
 <td style="width:68px;vertical-align:top;height:52px;">1</td> 
 </tr> 
 </tbody> 
</table>

0-40分：小型项目；41—70分：中型项目；71—100分：大型项目

架构的复杂性主要来源于“高性能”“高可用”“可扩展”等几个方面，可以从这几个方向上将复杂的问题列出来，排除优先级，依次解决。当问题间有冲突的时候要选择一定的妥协。

软件系统的可塑性和易变性是很强的，方案可以有多个，总能挑出性价比比较高的方案。

引进新技术是解决复杂度的一个好方法。

### 3.2按图索骥-设计备选方案 ###

架构师需要设计多个备选方案，备选方案设计时考虑一下几个方面：

![fe4c81d4a9e69587fdcc57900594af16.png][]

备选阶段关注的是技术选型，不是技术细节，技术选型的差异要明显，经过评审选定最终方案，后续再进行细化。

### 3.3深思熟虑-评估和选择方案 ###

选择方案还是比较有挑战的，主要体现在一下几个方面：

![3102030fdc93063d671472cac4951b01.png][]

在实际操作中也会碰到一些习惯性的做法：

![c9cbbab046e6ef3822eaa146c3c79ffd.png][]

如何较客观的选择方案呢？答案：360评，根据方案质量属性点综合度环挑选适合当时情况的最有方案。

根据项目对高性能、高可用、可扩展方面的要求，可以有所侧重，质量属性也可以增减。

### 3.4精雕细琢-详细方案设计 ###

备选方案是不关注技术细节的，备选方案确定后，需要把方案中涉及到的关键技术的细节确定下来，例如ES副本的数量，MySQL分库分表的方案，是用dubbo还是用thrift，负载均衡策略是什么等。

![2b2d059fcf56814162202421bee0b46c.png][]

[7e6900c0ab1c2be2d19ee469f4a175de.png]: https://img-blog.csdnimg.cn/img_convert/7e6900c0ab1c2be2d19ee469f4a175de.png
[fe4c81d4a9e69587fdcc57900594af16.png]: https://img-blog.csdnimg.cn/img_convert/fe4c81d4a9e69587fdcc57900594af16.png
[3102030fdc93063d671472cac4951b01.png]: https://img-blog.csdnimg.cn/img_convert/3102030fdc93063d671472cac4951b01.png
[c9cbbab046e6ef3822eaa146c3c79ffd.png]: https://img-blog.csdnimg.cn/img_convert/c9cbbab046e6ef3822eaa146c3c79ffd.png
[2b2d059fcf56814162202421bee0b46c.png]: https://img-blog.csdnimg.cn/img_convert/2b2d059fcf56814162202421bee0b46c.png