《从0开始学架构》-第1部分-架构基础

目录

01架构到底是指什么?

02架构设计的历史背景

03架构设计的目的

04复杂度来源:高性能

单台计算机内部为了高性能带来的复杂度

多台计算机集群为了高性能带来的复杂度

05复杂度来源:高可用

高可用方案的本质

冗余”带来的复杂性

一、计算高可用

二、存储高可用

高可用状态决策

1)独裁式

2)协商式

3)民主式

思考题:高性能和高可用哪个更难?

06复杂度来源:可扩展性

07复杂度来源:低成本、安全、规模

08架构设计三原则

合适原则

简单原则

演化原则

09架构设计原则案例

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

11架构设计流程:设计备选方案

12架构设计流程:评估和选择备选方案

13架构设计流程:详细方案设计

01架构到底是指什么?

“架构”到底指什么?

涉及到的关键概念分析:

 
区别与联系


系统与子系统


系统

系统泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。

关键点:关联、规则、能力

子系统


模块与组件

  • 模块和组件都是系统的组成部分,只是从不同角度拆拆分系统而已
  • 从逻辑角度拆分,得到的单元叫模块。划分模块的主要目的是职责分离。
  • 从物理角度拆分,得到的单元叫组件。划分组件的主要目的是单元复用。

举例:学生信息管理系统。从逻辑角度拆分,分为“登录注册模块”、“个人信息模块”、“个人成绩模块”。从物理角度拆分,可分为Nginx、WebServer、MySQL


框架与架构

  • 框架(FrameWork)关注的是规范。
  • 架构(Architecture)关注的是结构。

重新定义架构:

架构:软件架构指软件系统的顶层架构。

02架构设计的历史背景

20 世纪 60 年代第一次软件危机引出了“结构化编程”,创造了“模块”概念;20 世纪 80 年代第二次软件危机引出了“面向对象编程”,创造了“对象”概念;到了 20 世纪 90年代“软件架构”开始流行,创造了“组件”概念。我们可以看到,“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分,差别只是在于随着软件的复杂度不断增加,拆分的粒度越来越粗,拆分的层次越来越高。

03架构设计的目的

架构设计的目的:架构设计的主要目的是为了解决软件系统复杂度带来的问题

04复杂度来源:高性能

单台计算机内部为了高性能带来的复杂度

  • 单机如何高性能?多进程、多线程、进程间通信、多线程并发
  • 如何选择?Nginx可以多进程也可多线程、Redis采用单进程、Memchache采用多线程,都实现了高性能

多台计算机集群为了高性能带来的复杂度

多台机器配合达到高性能的方式有

任务分配:(业务比较简单的情况)每台机器都可以处理完整的业务,不同任务分配到不同机器上执行

任务分解:(业务很复杂)将复杂的业务系统,拆分为多个简单但需要配合的业务系统

05复杂度来源:高可用

高可用方案的本质

高可用方案本质都是通过“冗余”实现高可用

  • 一台不够两台
  • 一个机房可能断点,那就两个机房
  • 一台通道可能故障,那就两条,两条不够就三条(移动、联通、电信)

高性能与高可用的区别

高可用的“冗余”解决方案,单纯从形式上来看,和之前讲的高性能是一样的,都是通过增加更多机器来达到目的,但其实本质上是有根本区别的:高性能增加机器目的在于“扩展”处理性能;高可用增加机器目的在于“冗余”处理单元。

冗余”带来的复杂性

一、计算高可用

特点:无论从哪台机器上进行计算,同样的算法和输入,产出都是一样的。

复杂度分析举例:双机架构

1)任务分配器的选择,性能、成本、可维护性、可用性等因素

2)任务分配器和计算服务器交互。什么连接方式、如何进行连接管理(连接建立、连接检测、连接中断处理)

3)任务分配器的分配算法。双机算法:主备(冷备、温备、热备)、主主。

二、存储高可用

存储与计算相比的本质区别:将数据从一台机器搬到另一台机器,需要经过线路进行传输。

传输带来的问题:数据的不一致

  • 1)传输时延:同机房几毫秒、不同地方的机房几十甚至上百毫秒(广州到北京)
  • 2)传输链路可用性:传输中断、阻塞、丢包、错包,光缆被挖断

存储高可用的难点:如何减少或规避数据不一致对业务的影响

高可用状态决策

无论计算高可用还是存储高可用,基础都是“状态决策”,即系统需要能够判断当前的状态是正常还是异常,出现了异常就要采取行动保证高可用。

矛盾点:通过冗余实现的高可用,状态决策本质上都不可能完美,都会有问题点。

常见决策方式

1)独裁式

一个“决策者”,其他为“上报者”。“决策者”收集信息进行决策,“上报者”将状态信息发送给决策者。

问题点:因为只有一个决策者,当决策者异常,整个系统无法进行决策

2)协商式

两个个体进行交流,进行决策。常用协商式决策是主备决策。两台机器,一个主机,一个备机。

问题点:两个机器信息交换出现问题(如主备之间连接中断),如何做决策?主备之间连接中断。备机认为主机故障了,升级为主机,导致出现了两个主机;备机认为主机没故障,但主机确实故障了,导致没有主机了。

3)民主式

多个个体投票进行决策。常见的Zookeeper集群选举Leader。

问题点:脑裂

  • 一般通过“投票数必须超过总结点数一半”解决脑裂问题。据CAP理论,但会降低系统可用性。

思考题:高性能和高可用哪个更难?

课后思考题:高性能和高可用是很多系统的核心复杂度,你认为哪个更复杂一些?理由是什么?

精彩评论1:

高可用

  • 为什么会出现不可用?

    • 硬件故障。如服务器宕机。
    • 软件故障。如软件bug。
    • 不可抗力。如地震、洪水、战争。
  • 高可用的复杂度体现
    • 状态监控、服务切换、服务恢复
  • 如何做到高可用?
    • 硬件故障引起的不可用解决方法:

      • (1)应用服务器:多台机器,负载均衡检测服务器不可用时,将其从集群中摘除。前提(无状态设计):服务需要设计为无状态的,即不保存业务的上下文信息,而仅根据每次请求提交的数据进行业务逻辑的响应。
      • (2)数据服务器:数据冗余备份
    • 软件故障引起的不可用解决方法:通过软件开发过程进行质量保证。如测试、灰度发布

精彩评论2:

高性能非必须做。不管通过什么方式,或多或少,性能总能提高。高可用必须做。系统宕机或数据丢失,谈高性能没有意义。

精彩评论3:

高可用的解决方法不是解决,而是减少或者规避,而规避某个问题的时候,一般都会引发另一个问题,只是这个问题比之前的小,高可用的设计过程其实也是一个取舍的过程。这也就是为什么系统可用性永远只是说几个九,永远缺少那个一。而高性能,这个基本上就是定义计算能力,可以通过架构的优化,算法的改进,硬件的升级都可以得到很好的解决,从而达到我们心里对性能的预期…

精彩评论4:

高性能虽然复杂,但是只要通过合理的集群方案还是可以解决业务的性能需求,但是高可用也只能做到相对高可用,绝对高可用是不存在的,总会有诸多突发外界因素进行干扰,高性能的实现是受人为控制的,只要是在人的控制范围内,那问题都不是问题,但是要做到高可用,很多事情都不是人能控制的,比如天灾人祸

精彩评论5:

古人有言:先解决有无,再解决优化。所以可用更难,性能次之

06复杂度来源:可扩展性

设计具备良好可扩展性的系统,有两个基本条件:正确预测变化、完美封装变化

1)预测变化的复杂性

  • 不是每个设计点都考虑可扩展性
  • 不能完全不考虑可扩展性
  • 所有的预测都存在出错的可能性

2)应对变化

常见方案1:将“变化”封装在“变化层”,将不变的部分封装在“稳定层”。

复杂性

    • 1)需要拆分出变化层和稳定层,但是对于哪些属于变化层、哪些属于稳定层,并不好分辨
    • 2)需要设计变化层和稳定层之间的接口

常见方案2:提炼出一个“抽象层”和一个“实现层”。

  • 典型案例:设计模式、规则引擎。

07复杂度来源:低成本、安全、规模

规模:典型案例就是关系型数据库存储数据,需要进行分库分表。

软件架构图如何画?4+1视图。http://hongyitong.github.io/2017/02/17/4+1%E8%A7%86%E5%9B%BE%E5%88%86%E6%9E%90/

08架构设计三原则

合适原则

合适原则:“合适优于业界领先”

简单原则

简单原则:“简单优于复杂”(KISS原则:Keep it simple,stupid!)

  • 简单的方案和复杂的方案都能满足要求,最好选择简单的方案。

演化原则

演化原则:“演化优于一步到位”

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

09架构设计原则案例

分析了淘宝和手机QQ的发展历程

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

将主要的复杂度问题列出来,优先解决当前面临的最主要的复杂度问题

举例:是否需要高性能、是否需要高可用、是否需要高可扩展性。按优先级排序,前面的优先解决。

需注意的是:业务阶段不同,复杂度问题的优先级可能不同。

11架构设计流程:设计备选方案

注意事项

  • 备选方案的数据以3-5个为最佳。
  • 备选方案之间的差异要比较明显。
    • 主备方案VS集群方案,zookeeper做主备决策VS用keepalived做主备决策。
  • 备选方案的技术不要只局限于已经熟悉的技术。
  • 备选方案不要过于详细。备选阶段关注的是技术选型,而不是技术细节。

几种常见的设计误区。

1)设计最优秀的方案(技术人的技术情结,方案中的技术越牛逼越好)。而是要根据“合适”、“简单”、“演进”的架构设计原则,决策出与需求、团队、技术能力相匹配的合适方案。

2)只做一个方案。一个方案容易陷入思考问题片面、自我坚持的认知陷阱。

12架构设计流程:评估和选择备选方案

几种流派

  • 最简派。挑选最简单的方案。
  • 最牛派。挑选最牛逼的方案。
  • 最熟派。挑选最熟悉的方案。

对上面几种流派的看法:

并无绝对正确和错误,关键是不同场景采取不同方式。即有时最简,有时最牛,有时最熟。

如何选出最终方案?

  • 1)列出需要关注的质量属性点,然后分别从这些质量属性的维度去评估每个方案。常见的质量属性点:性能、可用性、扩展性、安全性、硬件成本、项目投入(时间、人力)、复杂度、可维护性、运维难度
  • 2)根据当前业务发展情况、团队规模和技能、业务发展预测等因素,将质量属性按优先级排序,首先挑选满足高优先级的。

实战案例

13架构设计流程:详细方案设计

就是将方案设计到的关键技术细节给确定下来

  • 如确定使用MySQL分库分表,那就需要确定哪些表要分库分表、按什么维度分库分表、分库分表后联合查询怎么处理。

可能遇到的问题是在详细设计阶段发现备选方案不可行,一般原因是备选方案设计时遗漏了关键技术点或关键质量属性。

架构师不但要进行备选方案设计和选型,还需要对备选方案的关键细节有较深入理解。

原文地址:https://www.cnblogs.com/yeyang/p/12578624.html

时间: 03-27

《从0开始学架构》-第1部分-架构基础的相关文章

【从0开始学Java】1.面向对象的特征有哪些方面

+Q325957484可以领取学习视频 1.面向对象的特征有哪些方面 1.Java基础培训,从0开始学Java:抽象 抽象就是忽略一个主题中与当前目标无关的那些方面,以便更充分地注意与当前目标有关的方面.抽象并不打算了解全部问题,而只是选择其中的一部分,暂时不用部分细节.抽象包括两个方面,一是过程抽象,二是数据抽象. 2.Java基础培训,从0开始学Java:继承 继承是一种联结类的层次模型,并且允许和鼓励类的重用,它提供了一种明确表述共性的方法.对象的一个新类可以从现有的类中派生,这个过程称为

Android Camera API2.0下全新的Camera FW/HAL架构简述

本文均属自己阅读源码的点滴总结,转账请注明出处谢谢. 欢迎和大家交流.qq:1037701636 email:gzzaigcn2[email protected] Software:系统源码Android5.1 前沿: 前面博文大多少总结的是Camera HAL1到HAL3的系统架构,但这些架构对于Camera APP开发来说依旧还是处于Camera API1.0的标准.而随着Camera3.HAL3.0等的不断更新,Google先是在Framework中更改了整个架构从而去匹配Camera A

如何从 0 开始学 ruby on rails (漫步版)

如何从 0 开始学 ruby on rails (漫步版) ruby 是一门编程语言,ruby on rails 是 ruby 的一个 web 框架,简称 rails. 有很多人对  rails 感兴趣,但又不知道从何下手.学习路线是什么,因为在多个场合下回答过类似问题,所以决定整理成文章供大家参观. 有很多人选择直接学习 rails,在学习使用 rails 的过程中学习 ruby.但我觉得这有些本末倒置,我更推崇先学 ruby 再学 rails,在对 ruby 有了一定的了解后再学 rails

如何从 0 开始学 Ruby on Rails

如何从 0 开始学 Ruby on Rails (漫步版)Ruby 是一门编程语言,Ruby on Rails 是 Ruby 的一个 web 框架,简称 Rails. 有很多人对 Rails 感兴趣,但又不知道从何下手.学习路线是什么,因为在多个场合下回答过类似问题,所以决定整理成文章供大家参观. 有很多人选择直接学习 Rails,在学习使用 Rails 的过程中学习 Ruby.但我觉得这有些本末倒置,我更推崇先学 Ruby 再学 Rails,在对 Ruby 有了一定的了解后再学 Rails 有

面向服务的体系架构(SOA)—架构篇

面向服务的体系架构(SOA)-架构篇 1.面向服务的体系架构(SOA) 面向服务的架构(service-oriented architecture)是Gartner于2O世纪9O年代中期提出的面向服务架构的概念.2002年的l2月,Gartner提出"面向服务的架构(SOA)"是"现代应用开发领域最重要的课题"之后.国内外计算机专家.学者掀起了对SOA的积极研究与探索. 在分布式的环境中,将各种功能都以服务的形式提供给最终用户或者其他服务.如今,企业级应用的开发都采

“微服务” 的架构终将成为产品架构上的主流

在敏捷开发中, 我们确实找到了一个框架,能使领域专家,架构师可共同的协作,设计出一可适应变化的 ROA 架构. 但,我想应该从另一个角度来思考-- 团队中即使领域专家,架构师可共同协作,但毕竟领域专家,架构师都还是人,不是神.所以,到底能从当前的版本中,预测到多少未来需求的变化? 这实在是个无法答复的问题.所以,在实务上,架构到底能承受多少的变化,同样也变成个无法答复的问题. "假如,不走预测变化这条路做架构设计.那架构设计的思维又是什么?" 很简单-- "既然不能有效预测变

单体架构还是微服务架构,这是个问题?

(此文章同时发表在本人微信公众号"dotNET每日精华文章",欢迎右边二维码来关注.) 微服务架构现在越来越流行,那么是不是就意味着单体架构不再成为我们的选择了呢?个人认为这个要依情况而定. 现在谈及微服务架构的文章.演讲随处可见,似乎所有系统的架构都开始尽情拥抱微服务架构,包括笔者前久为一个异构电商平台系统设计的架构也选用了这种风格.然而,我们在选择微服务架构之前,一定要问一句"你现在面对的系统,微服务架构是一个好的选择吗?".当然,这个问题也是我这几天在思考的.

向架构师进军--->系统架构设计基础知识

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 在讲解系统架构设计之前,有必要补充一下架构相关的概念,因此本博文主要讲述架构.架构师和架构设计等相关的概念以及关系.这是系统架构设计的基础,只有具备了此方面的知识之后,我们才能进一步了解架构师在软件开发过程中扮演的角色,架构师如何编写架构文档来满足不同利益相关者的需求等相关内容. 现在我们通过定义的概念来了解架构设计中的一些相关术语. 架构:架构是体现在它的组件中的一个系统的基本组织.它们彼

Android架构师之路-架构师的决策

android架构师之路-架构师的决策 内涵+造型:可能大部分人对这个内涵和造型不是很理解,在这里我可以给大家举个生动的例子:相信很多人都有自己的汽车, 我们总结汽车有哪些属性和功能,这些都是内涵,大自然中的每个对象都有自己的内涵(人有手有脚,还可以跑),然后我们 将这些内涵放入指定的造型中,类似模版,比如java语言如果定义一个class的时候,必须在作用域(大括号内部)指定属性和 函数,这个class的定义规范就是一个造型,然后我们将汽车这个内涵按照class的规范定义一个汽车class,那

4、传统三层架构与DDD分层架构

4.传统三层架构与DDD分层架构 模型是抽象的 现实是形象的 技巧是重要的 思想是永恒的 从传统三层架构与DDD分层架构的编程演变其实是思想的演变. 传统三层架构,即用户界面层UI.业务逻辑层BAL.数据访问层DAL.一般同时还有建立一个Model实体类的工程项目.DDD分层架构,即表现层UI.应用层Application.领域驱动层Doman.基础设施层Infrastructure. 传统三层架构,我一直使用.结构单一.逻辑也清晰,三层各处理各自的事务,上层向下层引用接口与方法,下层向上层提供