从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

05 | 复杂度来源:高可用

李运华 2018-05-08
今天,我们聊聊复杂度的第二个来源高可用
参考维基百科,先来看看高可用的定义。
系统无中断地执行其功能的能力,代表系统的可用性程度,是进行系统设计时的准则之一。
这个定义的关键在于“无中断”,但恰好难点也在“无中断”上面,因为无论是单个硬件还是单个软件,都不可能做到无中断,硬件会出故障,软件会有 bug;硬件会逐渐老化,软件会越来越复杂和庞大……
除了硬件和软件本质上无法做到“无中断”,外部环境导致的不可用更加不可避免、不受控制。例如,断电、水灾、地震,这些事故或者灾难也会导致系统不可用,而且影响程度更加严重,更加难以预测和规避。
所以,系统的高可用方案五花八门,但万变不离其宗,本质上都是通过“冗余”来实现高可用。通俗点来讲,就是一台机器不够就两台,两台不够就四台;一个机房可能断电,那就部署两个机房;一条通道可能故障,那就用两条,两条不够那就用三条(移动、电信、联通一起上)。高可用的“冗余”解决方案,单纯从形式上来看,和之前讲的高性能是一样的,都是通过增加更多机器来达到目的,但其实本质上是有根本区别的:高性能增加机器目的在于“扩展”处理性能;高可用增加机器目的在于“冗余”处理单元
通过冗余增强了可用性,但同时也带来了复杂性,我会根据不同的应用场景逐一分析。

计算高可用

这里的“计算”指的是业务的逻辑处理。计算有一个特点就是无论在哪台机器上进行计算,同样的算法和输入数据,产出的结果都是一样的,所以将计算从一台机器迁移到另外一台机器,对业务并没有什么影响。既然如此,计算高可用的复杂度体现在哪里呢?我以最简单的单机变双机为例进行分析。先来看一个单机变双机的简单架构示意图。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(109)

  • 公号-代码荣耀
    今日心得

    需求驱动驱动;而高可用与高性能,是架构设计中两个非常重要的决策因素。因此,面对不同业务系统的不同需求,对高可用与高性能也会有不同的决策结论,其实现的复杂度也各不相同。支付宝业务,对于可用性和性能就会有很高的要求,在可用性方面希望能提供7*24不间断服务,在高性能方面则希望能实时收付款;而对于一个学生管理系统,在可用性与性能方面就不一定要有多高的要求,比如晚上可关机,几秒内能查询到信息也可接受。为此,高可用性与高性能的复杂度讨论需要结合业务需求。

    1 WHAT - 什么是可用性?
    定义可用性,可以先定义什么是不可用。需要经历若干环节,网站的页面才能呈现在最终的用户面前;而其中的任何一个环节出现了故障,都可能会导致网站的页面不可访问,也就是出现了网站不可用的情况。昨夜iOS版本QQ出现大面积闪退就是一个系统不可用的典型案例。

    我们可以利用百分比来对网站可用性进行度量:
    网站不可用时间=完成故障修复的时间点 - 故障发现的时间点
    网站年度可用时间=年度总时间 - 网站不可用时间
    网站年度可用性=(网站年度可用时间/年度总时间) x 100%

    举例:一些知名大型网站的可用性可达到99.99%(俗称4个9),我们可以算一下一年下来留给处理故障的时间有多少?
    年度总时间=365*24*60=525600分钟
    网站不可用时间=525600*(1-99.99%)=52.56分钟
    也就是,如果网站要达到4个9的可用性,一年下来网站不可用时间最多53分钟(也就是不足1个小时)。

    可见,高可用性就是技术实力的象征,高可用性就是竞争力。

    2 WHY - 为什么会出现不可用?
    硬件故障。网站多运行在普通的商用服务器,而这些服务器本身就不具备高可用性,再加之网站系统背后有数量众多服务器,那么一定时间内服务器宕机是大概率事件,直接导致部署在该服务器上的服务受影响。

    软件BUG或网站更新升级发布。BUG不能消灭,只能减少;上线后的系统在运行过程中,难免会出现故障,而这些故障同样直接导致某些网站服务不可用;此外,网站更新升级发布也会引起相对较频繁的服务器宕机。

    不可抗拒力。如地震、水灾、战争等。

    3 HOW - 如何做到高可用
    核心思想:网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上;数据存储在多台服务器上互相备份。通过上述技术手段,当任何一台服务器宕机或出现各种不可预期的问题时,就将相应的服务切换到其他可用的服务器上,不影响系统的整体可用性,也不会导致数据丢失。

    从架构角度看可用性:当前网站系统多采用经典的分层模型,从上到下为:应用层、服务层与数据层。应用层主要实现业务逻辑处理;服务层提供可复用的服务;数据层负责数据读写;在部署架构上常采用应用和数据分离部署,应用会部署到不同服务器上,这些服务器被称为应用层的服务器;这些可复用的服务也会各自部署在不同服务器上,称为服务层的服务器;而各类数据库系统、文件柜等数据则部署在数据层的服务器。

    硬件故障方面引起不可用的技术解决措施:(1)应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务(前提是这些服务需要设计为无状态,即应用服务器不保存业务的上下文信息,而仅根据每次请求提交的数据进行业务逻辑的操作响应),当均衡设备通过心跳检测手段检测到应用服务器不可用时,则将其从集群中移除,并将请求切换到其他可用的应用服务上。(2)服务层服务器。这些服务器被应用层通过分布式服务框架(如Dubbo)访问,分布式服务框架可在应用层客户端程序中实现软件负载均衡,并通过服务注册中心提供服务的服务器进行心跳检测,当发现有服务器不可用时,立即通知客户端程序修改服务列表,同时移除响应的服务器。(3)数据服务器。需要在数据写入时进行数据同步复制,将数据写入多台服务器上,实现数据冗余备份;当数据服务器宕机时,应用程序将访问切换到有备份数据的服务器上。

    软件方面引起不可用的技术解决措施:通过软件开发过程进行质量保证。通过预发布验证、严格测试、灰度发布等手段,尽量减少上线服务的故障。
    2018-05-08
    200
  • 彡工鸟
    这么多回复里,没有人提到高可用和高性能的量化指标,没有这个指标前提下,无法断定哪个更复杂吧。打个比方,高可用两条99就行了,你觉得会复杂,会难么?高性能要求你在并发百万,千万级调用十几个服务前提下,仍能保持10多毫秒,你觉得简单?复杂与否还是要指标。另外,很多人都关注应用节点和硬件节点高可用,却忽略了业务高可用这个视角,系统全挂了,你人工接入业务,在后台帮用户开通,办理,对业务来说也是高可用吧。以上个人看法

    作者回复: 你说的有道理,没有绝对的结论,我的问题只是想引起大家思考,通过思考来更深入理解复杂度。

    通常情况下,高可用要复杂一些,因为需要考虑的情景很多,而且没有完美的方案,只能做取舍。

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

    作者回复: 有道理,没有完美的高可用方案

    2018-05-25
    19
  • YMF_WX1981
    高可用相对复杂。

    高性能,不管通过什么方式,或多或少,性能总获提高,行为上非必须做;高可用必须做,因为系统宕机或数据丢失时,谈高性能也无意义。

    高可用涉及分布式存储和分布式计算,这两课题本身就复杂。

    高可用涉及的非技术因素,如自然,政治。

    So...

    2018-05-08
    13
  • 夜行观星
    就我一个人注意到ZK的选举算法不是Paxos吗?虽然不是本文重点😂

    作者回复: 感谢指正,ZK的协议是ZAB,官方文档也解释了ZAB不是Paxos算法,因为两者的设计目标不同,我没有深入研究两者协议,但大部分研究过的人认为ZAB是在Paxos算法上进行了改良和优化,有兴趣的可以深入研究一下。

    2018-05-13
    9
  • 罗烽
    高性能,高可用,哪个复杂度更高?
    我认为高可用更复杂。性能方面,我们可已通过增加机器,拆分服务来提高性能。但是高可用这个不是通过单纯花钱(增加机器)能解决的,但还是必须要花钱😂😂,相比较而言,它更需要一个良好的设计,这个就很复杂了。
    关于高可用,我有些自己的想法
    1,还是要做小的服务,小的服务稳定性会更高。
    2,高可用的监控十分的重要,只有能先发现问题,才能接下来处理问题。
    3, 存储高可用(减少和规避数据不一致),这个太复杂的不清楚,我们的业务现在没有那么复杂,数据库用的就是阿里云的主备rds,相比较而言,使用阿里云的服务会让我们的服务保障性更高些,这个只能想到这些
    2018-05-08
    8
  • 晓晨同学
    核心思想:网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上;数据存储在多台服务器上互相备份。通过上述技术手段,当任何一台服务器宕机或出现各种不可预期的问题时,就将相应的服务切换到其他可用的服务器上,不影响系统的整体可用性,也不会导致数据丢失。

    从架构角度看可用性:当前网站系统多采用经典的分层模型,从上到下为:应用层、服务层与数据层。应用层主要实现业务逻辑处理;服务层提供可复用的服务;数据层负责数据读写;在部署架构上常采用应用和数据分离部署,应用会部署到不同服务器上,这些服务器被称为应用层的服务器;这些可复用的服务也会各自部署在不同服务器上,称为服务层的服务器;而各类数据库系统、文件柜等数据则部署在数据层的服务器。

    硬件故障方面引起不可用的技术解决措施:(1)应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务(前提是这些服务需要设计为无状态,即应用服务器不保存业务的上下文信息,而仅根据每次请求提交的数据进行业务逻辑的操作响应),当均衡设备通过心跳检测手段检测到应用服务器不可用时,则将其从集群中移除,并将请求切换到其他可用的应用服务上。(2)服务层服务器。这些服务器被应用层通过分布式服务框架(如Dubbo)访问,分布式服务框架可在应用层客户端程序中实现软件负载均衡,并通过服务注册中心提供服务的服务器进行心跳检测,当发现有服务器不可用时,立即通知客户端程序修改服务列表,同时移除响应的服务器。(3)数据服务器。需要在数据写入时进行数据同步复制,将数据写入多台服务器上,实现数据冗余备份;当数据服务器宕机时,应用程序将访问切换到有备份数据的服务器上。

    作者回复: 为你点赞👍👍👍

    2019-02-19
    7
  • 李志伟
    个人觉得根据场景而定,如果一个系统部署结构复杂,组件众多,数据量也很大。那么高可用性的代价就会比较高。因为高可用意味着冗余,
    冗余也就意味着要有额外的策略来管理这些冗余的组件。另外大数据量数据服务冗余异地多活也是很有挑战性的。 于此相对如果一个系统他的业务复杂度很高,涉及到很多的复杂计算,但是本身部署结构不复杂,那么这时候高性能的复杂度就会比较大
    2018-05-08
    7
  • 歪脖贰点零
    为保证高可用,有时候会引入其他组件,比如keepalive等等,此时keepalive也易容易产生单点问题,于是做主从或其他方案。若其他方案同样存在单点问题,如此往复下去。悲观的看,似乎无止境,更多的时候是个取舍。
    2018-05-08
    5
  • 性能
    老师,银行账务类强一致性业务,适用最终一致性方案吗?我们通常要求既要实时看到账务操作结果,又要提供高性能,最终只能用依赖于数据库实现一致性,但性能压力很大

    作者回复: 强一致性目前没有太好的方式,目前一般采取用户分区的做法,即:将用户分散在多个数据分区中,每个数据分区中的用户用单点数据库保证强一致性

    2018-05-29
    3
  • 孙振超
    相对而言还是高可用更难些,按照作者说的高性能其实就是容量,在负载均衡系统高可用的情况下加机器就可以了,而想做到各个环节的高可用不是靠加机器就能搞定的,通常需要复杂的算法、引入更多的中间件、牺牲一定的性能才能实现,这其中还要进行各种权衡取舍裁剪才可以

    作者回复: 确实如此

    2018-05-26
    3
  • 高歌在羊城
    大神,希望后面多一些落地的案例分析,章节篇幅可以长一点,一次讲一个要点都行😁

    作者回复: 别急,后面很多案例和模式分析

    2018-05-08
    3
  • Ivan
    高可用一般会考虑的更多一些,简单点说一个不可以的服务也就不存在性能一说,冗余是高可用的主要手段,高可用的主要复杂度体现在状态监控,服务切换或服务恢复上,为了降低其复杂度,又有无状态设计,熔断设计等等,这里面其实又牵扯到高性能,一个高性能的服务往往是快的小的独立的,相应的其高可用也就较容易实现。感觉最终的落地点还是在业务复杂度上,登录偏向高性能,支付偏向高可用
    2018-05-08
    3
  • 幸福时光
    架构的问题谈复杂性不如谈重要性来得直接,这个依赖于架构所要解决的业务场景的复杂度是对高性能有更高要求,还是对高可用有更高要求。如果对高性能的要求取舍大于高可用,自然高性能的架构考虑势必会复杂一些。大多数情况下,鱼和熊掌不可兼得,最终架构选择还是要依赖业务场景做出平衡。
    2018-05-08
    3
  • 高性能虽然复杂,但是只要通过合理的集群方案还是可以解决业务的性能需求,但是高可用也只能做到相对高可用,绝对高可用是不存在的,总会有诸多突发外界因素进行干扰,高性能的实现是受人为控制的,只要是在人的控制范围内,那问题都不是问题,但是要做到高可用,很多事情都不是人能控制的,比如天灾人祸

    作者回复: 很正确👍

    2018-10-27
    2
  • 小超在努力
    古人有言:先解决有无,再解决优化。所以可用更难,性能次之,找对象同理。

    作者回复: 你已参透天机😄

    2018-08-16
    2
  • Joker
    高性能是为了达到一个量化的目标,通常我们会有各种不同的办法去实现,抛开消耗来说,方法有很多种,就像上篇讲到的,粗暴加机器,优雅划分等;但是高可用是为了规避一个非量化的抽象bug场景集合,这些不都是能提前预测到的,所以高可用一般来说都会比高性能复杂!

    作者回复: 是的,通俗来讲,高性能是土豪,有钱可以任性;高可用是文豪,需要日积月累修炼😃

    2018-05-25
    2
  • 云学
    有些人把高可用与高可靠混淆了,高可用是不要中断服务,高可靠是数据不丢失。

    作者回复: 有区别,但实践中一般很难清晰的区分,否则每次都要解释半天,我们一般都是混用,大家都明白是什么意思。

    严格来说,高可用是指正常提供服务的概率,主要和故障恢复时间有关;高可靠是指出问题的概率,主要和故障次数有关。大部分情况下其实我们都是说可用性,因为保证系统能够正常提供服务才是我们的首要目标。

    2018-05-15
    2
  • Geek_d8f635
    区块链技术如果越来越成熟,是不是对高性能有很大帮助?

    作者回复: 据我目前对区块链的理解来看,区块链恰恰是性能低下的实现方案,不但没有帮助,还会存在明显的性能问题

    2018-05-09
    2
  • itperson
    高可用更复杂一些,因为需要考虑很多的异常处理方式。
    2018-05-08
    2
收起评论
99+
返回
顶部