从零学架构-基础部分

一、架构的基础

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

从零学架构-基础部分_第1张图片

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有的放矢-识别复杂度

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

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



序号

要素

说明

评分规则

加权因子

1

子系统/功能点数量

一般来说,一个系统越复杂,其按照功能域划分的子系统越多,其最终分解出来的具体功能点越多。子系统和功能点的增加与工作量的增加不是简单的线性增长关系,从只包含一个子系统到包含多个子系统,随着人员投入数量增多和组织的细分,其复杂度会因为组织间沟通和分工协作的难度而大大增加。在这一点来说,可以认为子系统的数量是划分简单项目和复杂项目的一个重要维度。

0-低、5-中、10-高。技术复杂度因素较难量化,只能根据技术要求定性分为低、中、高。

2

2

外围接口数量

一般的IT系统都不是系统孤岛,是和外围系统紧密相连的。与外围系统的接口数量越多,代表着进行系统间集成的复杂度越高,难度越大。这里的复杂度影响主要来自于几个方面:一个是不同系统架构间形成统一接口协议的复杂度,这需要弥合系统间差异,体现系统间关系的工作;另一个是在完全无关的两个项目组织间协调实施的复杂度,包括设计开发、联调测试等协同工作,这是比项目组内部不同子系统间的协调更为复杂的协同工作。

0-需求稳定成熟 ,5-需求较新,但相对稳定,10-需求变动频繁

1.5

3

承载的业务数量

在当前的IT系统架构中,往往一套体系架构上,运转着多种业务和产品。因此,一套IT系统中承载的业务和产品数量,将直接影响系统开发、配置、测试、联调工作的复杂度。

0--简单(1-5个业务),5—中等复杂(6-10个业务),10—复杂(>10个业务)

1

4

业务数据量

大型企业的IT系统中,很多关键系统是伴随着大量的业务数据存在着的。IT系统处理数据量的大小,直接影响到IT系统的架构设计模式。一个业务处理数据量大的系统,不仅要求从硬件规模和部署上进行复杂深入的考虑,而且在应用架构设计上要充分考虑系统的并行处理、负载均衡等要求。很多在小数据量系统中可以通过人工进行的操作,在大数据量系统中则需要通过开发系统功能来实现,如数据的审核、出错回退、数据同步等。从IT系统的特点来说,可以采用最终用户数(Subscriber)来衡量业务数据量的大小。

0--小型(<1000000的用户),5--中型(1000000至5000000个用户),10—大型(>5000000个用户)

1

5

技术复杂度

技术复杂度来自于系统建设中对功能上的复杂技术要求,典型的场景包括最新技术架构、较高的安全要求、套装软件的集成等。目前各种IT系统建设已经从原来的烟囱式的一种业务一套处理程序,向生产线式的多种业务一套处理程序的架构转变。这种模式更多地需要搭建系统架构时,建立统一的数据模型,对业务进行充分的抽象,通过构建基础架构公共组件实现多种业务的支撑。

0-低、5-中、10-高。技术复杂度因素较难量化,只能根据技术要求定性分为低、中、高。

1

6

需求的成熟度

需求的成熟度是影响IT系统建设成本的重要因素。如省BOSS的高复杂度系统,因为需求比较成熟,有完善的规范来指导设计和开发,因此,其实施成本可以通过多省实施来实现架构复制,实现了成本摊平。

而很多新的业务领域,存在着业务模式频繁变化,需求不断变动的特点,此类IT系统建设,不仅要求开发商具有丰富的系统实施经验,还要具有深入的咨询能力,对人员素质要求和系统的灵活性及扩展性都有较高的要求。

0-需求稳定成熟 ,5-需求较新,但相对稳定,10-需求变动频繁

1

7

系统的关键程度

系统的关键程度实际上体现的是对系统的质量要求。这种质量要求体现在系统高可用性要求(如联机交易要求7*24小时的高可用性)、系统处理正确性要求(如计费帐务的正确性处理要求)、系统处理的及时性要求(如实时计费处理的时效性要求)等。系统的关键程度越高,越要在架构设计中考虑冗余处理、正确性验证、并发处理等各种手段,确保系统运行的稳定、准确、高效。

0-非关键系统、5-中等关键系统、10-重要关键系统。

1.5

8

数据迁移的复杂程度

IT系统的建设过程中,除了设计开发之外,更为艰巨的工作是测试和迁移。很多IT系统需要把原有系统中的数据完整地迁移到新系统中,尤其对于数据量大的系统,数据迁移需要开发很多程序和脚本,并通过充分的测试和模拟,才能实现正确和及时的数据迁移。很多原有系统还存在较多的错误数据,这些数据的清理也是一个很大的工作。

0-简单少量迁移,5-中等复杂迁移,10-高度复杂迁移

1

0-40分:小型项目;41—70分:中型项目;71—100分:大型项目

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

序号

问题

分类

优先级

解决办法



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

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

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

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

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

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

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



从零学架构-基础部分_第2张图片



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



从零学架构-基础部分_第3张图片



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



质量属性

分值

方案A

方案B

方案C

评分

性能

5、3、1

A-3,B-5,C-1

可用性

7、5、3

硬件成本

项目投入

复杂度

安全性

可扩展性



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

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

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

从零学架构-基础部分_第4张图片





你可能感兴趣的:(笔记,架构)