高可用架构_高可用架构设计 - CSDN
精华内容
参与话题
  • 高可用架构设计思路

    2018-11-14 10:23:35
    高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。 如何保障高可用 减少单点,服务器集群化 服务分层,并且每层都是集群,当集群中一个...

    什么是高可用

    高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

    如何保障高可用

    减少单点,服务器集群化

    服务分层,并且每层都是集群,当集群中一个节点发生故障时,要自动将请求转移到可用节点上,此转移过程要对调用方透明

    常见的服务分层思路

    架构图

    1. 客户端层:典型调用方是浏览器browser或者手机应用APP
    2. 反向代理层:系统入口,反向代理
    3. 站点应用层:实现核心应用逻辑,返回html或者json
    4. 服务层:如果实现了服务化,就有这一层
    5. 数据-缓存层:缓存加速访问存储
    6. 数据-数据库层:数据库固化数据存储

    整个系统的高可用,又是通过每一层的冗余+自动故障转移来综合实现的。

    总结

    高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

    方法论上,高可用是通过冗余+自动故障转移来实现的。

    整个互联网分层系统架构的高可用,又是通过每一层的冗余+自动故障转移来综合实现的,具体的:

    1. 【客户端层】到【反向代理层】的高可用,是通过反向代理层的冗余实现的,常见实践是keepalived + virtual IP自动故障转移

    2. 【反向代理层】到【站点层】的高可用,是通过站点层的冗余实现的,常见实践是nginx与web-server之间的存活性探测与自动故障转移

    3. 【站点层】到【服务层】的高可用,是通过服务层的冗余实现的,常见实践是通过service-connection-pool来保证自动故障转移

    4. 【服务层】到【缓存层】的高可用,是通过缓存数据的冗余实现的,常见实践是缓存客户端双读双写,或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移;更多的业务场景,对缓存没有高可用要求,可以使用缓存服务化来对调用方屏蔽底层复杂性

    5. 【服务层】到【数据库“读”】的高可用,是通过读库的冗余实现的,常见实践是通过db-connection-pool来保证自动故障转移

    6. 【服务层】到【数据库“写”】的高可用,是通过写库的冗余实现的,常见实践是keepalived + virtual IP自动故障转移

    参考

    展开全文
  • 架构设计(8)—高可用架构设计

    千次阅读 2020-07-18 19:05:24
    高可用架构设计总结: 前言:海恩法则和墨菲定律 海恩法则 · 事故的发生是量的积累的结果。 · 再好的技术、再完美的规章 , 在实际操作层面也无法取代人自身的素质和责任心 。 墨菲定律 · 任何事情都没有...

    架构设计学习思维导图: 架构设计系列主要的ADM(架构开发方法)主要基于TOGAF9或者TOGAF9.1来论述。这是个人学习实践和总结笔记,专注并不断积累和更新,努力精进自己。个人拙见,仅供参考。
    1、 架构概述:了解架构基础知识:架构定义、分类、级别、应用架构演进、架构是否合理、架构误区等。
         《谈谈架构》
    2、 原则模式:了解架构模式和设计原则。
         《架构设计原则》
          《架构模式》
    3、 瀑布模式:根据瀑布开发模式,从前期的架构愿景->到架构需求分析->架构设计
          《架构愿景分析》
          《架构需求分析》
          《如何设计一个架构》
    4、 架构三高:架构战术设计主要关注点:高可用、高性能、高效服务治理或者高并发
         《高可用架构设计》
         《高性能设计》
         《分布式服务治理》
    5、 具体知识点:架构实施知识点,框架、组件、限流、容错等知识。
         《分布式链路跟踪》
         《分布式链路跟踪:Zipkin实践》
         《分布式链路跟踪:skywalking实践》
         《我们自研log2跟踪组件》

    前言:海恩法则和墨菲定律


    海恩法则

    · 事故的发生是量的积累的结果。
    · 再好的技术、再完美的规章 , 在实际操作层面也无法取代人自身的素质和责任心 。

    墨菲定律

    · 任何事情都没有表面看起来那么简单 。
    · 所有事情的发展都会比你预计的时间长 。
    · 会出错的事总会出错。
    · 如果你担心某种情况发生,那么它更有可能发生 。

    警示我们,在互联网公司里,对生产环境发生的任何怪异现象和问题 都不要轻易忽视,对于其背后的原因一定要彻查。同样,海恩法则也强调任何严重事故的背后 都是多次小问题的积累,积累到一定的量级后会导致质变,严重的问题就会浮出水面 。 那么,我们需要对线上服务产生的任何征兆,哪怕是一个小问题,也要刨根问底: 这就需要我们有技术攻关的能力,对任何现象都要秉着以下原则: 为什么发生? 发生了怎么应对? 怎么恢复? 怎么避免? 对问题要彻查,不能因为问题的现象不明显而忽略 。

    1、可用性


    1.1业务可用性指标:

    所谓业务可用性(availability)也即系统正常运行时间的百分比,架构组最主要的 KPI (Key Performance Indicators ,关键业绩指标)。对于我们提供的服务(web,api)来说,现在业界更倾向用 N 个9 来量化可用性, 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。


    故障时间=故障修复时间点-故障发现(报告)时间点
    服务年度可用时间%=(1-故障时间/年度时间)× 100%。

     

    1.2 故障的度量与考核

    对管理者而言:可用性是产品的整体考核指标。 每个工程师而言:使用故障分来考核:

    类别 描述 权重
    高危S级事故故障 一旦出现故障,可能会导致服务整体不可用 100
    严重A级故障 客户明显感知服务异常:错误的回答 20
    中级B级故障 客户能够感知服务异常:响应比较慢 5
    一般C级故障 服务出现短时间内抖动 1

    考核指标:故障分=故障时间分钟* 故障级别权重。

     

    1.3 服务分级:

    如果是一个分布式架构设计,系统由很多微服务组成,所有的服务可用性不可能都是统一的标准。

    为了提高我们服务可用性,我们需要对服务进行分类管理并明确每个服务级别的可用性要求。

    类别 服务 可用性要求 描述
    一级核心服务 核心产品或者服务 99.99%(全年53分钟不可用) 系统引擎部分:一旦出现故障,整个系统瘫痪
    二级重要服务 重要的产品功能 99.95%(全年260分钟不可用) 类比汽车轮子:该服务出现问题,该重要功能不可用。
    三级一般服务 一般功能 99.9%(全年8.8小时不可用) 类比汽车倒车影像:该部分出现问题,稍微影响用户体验
    四级工具服务 工具类是服务 99% 非业务功能:比如爬虫、管理后台、运维工具

     

    2、架构分层


    为了降低应用服务管理的复杂性,我们把整个系统划分成若干个层次,每一层专注解决某个领域的问题,并向上提供服务。

    典型架构分层设计如下:按照功能处理顺序划分应用,这是面向业务深度的划分。同时禁止逆向调用。

    每个公司的架构分层可能不一样,但是目的都是为了统一架构术语,方便团队内部沟通。

    接入层:主要流量入口,经过简单

    应用层:直接对外提供产品功能,例如网站、API接口等。应用层不包含复杂的业务逻辑,只做呈现和转换。

    服务层:根据业务领域每个子域单独一个服务,分而治之。

    数据层:数据库和NoSQL,文件存储等。

    我们先列出目前我们系统有哪些环节,每个环节是否薄弱. 客户端访问服务器端,经过很多环节,任何环节出问题,都不能访问:

    接入层:

    • 1、dns被劫持:域名是否使用https。
    • 2、黑客攻击:是否有弱密,服务器权限,数据库权限
    • 3、ddos攻击:是否有必要使用高防IP接入流量。
    • 4、CC攻击:免费和收费版域名分开,网关是否有限流和防刷措施。

    应用层:

    • 1、应用服务器宕机。
    • 2、应用服务bug。
    • 3、第三方服务不可用。

    服务层:

    • 1、服务不可用或者出现bug
    • 2、第三方服务不可用。

    数据层:

    • 1、数据库服务器磁盘损坏导致数据库不可用等

     

    3、接入层高可用设计


    在接入层,这里主要是架构运维的高可用要求的事项:

    1、 域名规范解析和规范化管理,应该制定《域名规范管理说明》,例如根据产品重要等级,制定使用高防ip的策略。
    2、 规范API管理。
    3、 明确各个API限流和防刷策略。

    因此我们设计接入层架构:

    目前我们对外的接口繁多,同时不同的项目不同的接口,没有一个统一管理的系统,也不方便监控和
    跟踪 api 的健康状况。因此搭建我们 api 网关,方便 api 日常管理,包括控版本管理,升级,回滚。同时提供调试工具,方便开发人员, qa 调试和测试。 更重要的是 api 网关起到限流防刷(CC攻击)作用,保护后端服务。
     

    4、应用层高可用设计


    4.1、应用层设计主要原则:

    1、可以水平扩展:通过接入层的负载均衡,实现故障自动转移。

    2、无状态设计:无状态的系统更利于水平扩展,更利于做负载均衡。

          状态是系统的吞吐量、易用性、可用性、性能和可扩展性的大敌,要尽最大可能避免。

    3、回滚设计 :确保系统可以向后兼容,如果应用服务上线后出现bug,可以紧急回滚。

    4、灰度发布:结合接入层设计A/B 功能,实现灰度发布,比如按ip,请求参数等分发流量。

    5、幂等设计:系统中的多次操作,不管多少次,都应该产生一样的效果,或返回一样的效果。

    6、调用设置超时:调用服务一旦超时,通信框架应该返回异常,调用方根据调度策略选择重试或者请求转移。

    4.2、服务主要异常情况

    1、服务内部出错、异常;

    2、服务响应超时;

    3、服务负载过高;

    4、网络链路延迟或中断;

    5、服务依赖链中部分依赖SLA不达标,造成整体服务不可用;

    6、服务链条过长,造成SLA整体不可控;

    4.3 提高服务可用性机制

    解决的思路:服务隔离、自我保护、失效转移或恢复、服务降级。

    1、服务隔离措施:依据服务重要性分级或流量特点、用户画像等,从物理上隔离服 务。将服务使用的资源(CPU、线程、IO等)隔离,主要使用舱壁模式;比如核心服务单独部署,三级服务可以混合部署。

    2、自我保护措施:快速失败(failfast)、限流、调用超时、熔断(Resilience4j);

    3、失效转移机制:失效检测、失效重试、失效转移(failover)、失效恢复(failback);

    4、服务降级措施:依据依赖服务的重要性或依赖程度(强、弱),同步变异步,降级开关、拒绝部分服务等。

     

    4.4、具体容错机制说明

    1、failover:失效转移
    Fail-Over失效转移是一种备份操作模式,当主要组件异常时,其功能转移到备份组件。其要点在于有主有备,主故障时系统能够自动地切换到备用服务上,  保证服务继续运行。比如内部调用nginx代理,不能是单点提供服务,需要有主备模式,通过keep-alive机制自动切换到备用服务上。核心和重要服务都需要按N+1原则部署。

    2、failfast:快速失败
    fail-fast 是“快速失败”,尽可能的发现系统中的错误,使系统能够按照事先设定好的错误的流程执行,对应的方式是“fault-tolerant(错误容忍)”。以JAVA集合(Collection)的快速失败为例,当多个线程对同一个集合的内容进行操作时,就可能会产生fail-fast事件。例如:当某一个线程A通过iterator去遍历某集合的过程中,若该集合的内容被其他线程所改变了;那么线程A访问集合时,就会抛出ConcurrentModificationException异常(发现错误执行设定好的错误的流程),产生fail-fast事件。

    3、failback:故障自动恢复
    Fail-over之后的自动恢复,在簇网络系统(有两台或多台服务器互联的网络)中,由于要某台服务器进行维修,需要网络资源和服务暂时重定向到备用系统。在此之后将网络资源和服务器恢复为由原始主机提供的过程,称为自动恢复。

    4、failsafe:失效安全
    Fail-Safe的含义为“失效安全”,即使在故障的情况下也不会造成伤害或者尽量减少伤害。维基百科上一个形象的例子是红绿灯的“冲突监测模块”当监测到错误或者冲突的信号时会将十字路口的红绿灯变为闪烁错误模式,而不是全部显示为绿灯。
     

     

    5、服务分级治理


    服务层设计最主要原则:服务分级管理

    线上有很多服务,每个服务的可用性要求不一样,我们需要先这些服务做分级。
    1、各级服务的部署原则:核心服务:独立服务器且N+1部署。三级和四级服务可以共享服务器部署。
    2、各级服务上线发布原则:核心和重要服务:晚上12点上线。,三级和四级随时可上线
    3、各级服务监控原则
     

    一级核心服务:

    定义
    可用性:99.99%,极高可用性,全年53分钟不可用。
    条件
    1、服务自身可用性:99.99%。
    2、依赖数据资源服务可用性要求:(应用服务研发方自定义)。
    3、依赖第三方服务可用性要求:(应用服务研发方自定义)。
    4、需要部署的服务器数:N台。

    服务设计满足以下原则
    1、冗余N+1部署:故障自动转移到多部署一个节点,避免单点问题。
    2、可监控:服务流量预警、端口存活、进程占用的资源、服务接口功能逻辑是否正常,应用FGC等情况。
    3、可回滚、灰度:灰度部署服务,部署的服务出现问题可快速回滚。
    4、可独立部署:可以直接在运维平台打包部署,而不需要依赖其他服务部署完成后才能部署运行。
    5、可独立测试:可以单独测试。
    6、水平扩展:流量激增可快速扩容。
    7、异步设计:服务需要通知第三方服务,必须通过消息队列进行异步方式完成。
    8、幂等设计:服务可以重复调用,不影响结果。
    7、可容错:自身有容错和修复能力:
          1)、隔离手段:服务使用的资源(CPU、线程、IO等)隔离,使用舱壁模式;
          2)、自我保护手段:快速失败(failfast)、流控、超时、熔断;
          3)、失效转移或恢复手段:失效检测、重试、转移(failover)、回退恢复(failback);
          4)、降级手段:依据依赖服务的重要性或依赖程度(强、弱),同步变异步,降级开关、拒绝部分服务等。
     

     

    二级重要服务:

    定义
    可用性99.95%(故障具备自动恢复的能力,全年260分钟不可用)。
    条件
    1、服务自身可用性:99.95%。
    2、依赖数据资源服务可用性要求:(应用服务研发方自定义)。
    3、依赖第三方服务可用性要求:(应用服务研发方自定义)。
    4、需要部署的服务器数:N台。

    服务设计满足以下原则
    1、冗余N+1部署:故障自动转移到多部署一个节点,避免单点问题
    2、可监控:监控进程、端口存活、进程占用的资源,应用FGC等。
    3、可回滚、灰度:灰度部署服务,部署的服务出现问题可快速回滚。
    4、故障隔离:服务器只部署唯一该应用服务,该应用服务出现问题,只影响自身服务问题。
    5、可独立部署:可以直接在运维平台打包部署,而不需要依赖其他服务部署完成后才能部署运行。
    6、可独立测试:可以单独测试。
    7、水平扩展:流量激增可快速扩容。
    8、可容错:自身有容错和修复能力。

    三级一般服务:

    定义
    可用性99.9%(全年8.8小时分钟不可用)。
    条件
    1、服务自身可用性:99.95%。
    2、依赖数据资源服务可用性要求:(应用服务研发方自定义)。
    3、依赖第三方服务可用性要求:(应用服务研发方自定义)。
    4、需要部署的服务器数:N台。
    服务设计满足以下原则
    1、冗余N+1部署:可以单点部署。
    2、可监控:可监控服务进程、端口存活是否正常。
    3、可回滚、灰度:灰度部署服务,部署的服务出现问题可快速回滚。
    4、故障隔离:一个服务器上可以部署多个应用,但保证服务器资源充足。
    5、可独立部署:需要独立部署。
    6、可独立测试:可以单独测试。
    7、水平扩展:流量激增可快速扩容。
    8、可容错:需要具备一般的容错能力。

    四级工具服务:

    定义
    可用性99.9%(全年8.8小时分钟不可用)。
    条件
    1、服务自身可用性:99.9%。
    2、依赖数据资源服务可用性要求:(应用服务研发方自定义)。
    3、依赖第三方服务可用性要求:(应用服务研发方自定义)。
    4、需要部署的服务器数:N台。

    服务设计满足以下原则

    1、冗余N+1部署:可以单点部署,进程存活就可以。
    2、可监控:不需要监控。
    3、可回滚、灰度:只要部署成功就可以。
    4、故障隔离:哪个服务器有资源就可以部署。
    5、可独立部署:不用考虑。
    6、可独立测试:不用考虑。 
    7、水平扩展:不用考虑。
    8、可容错:不用考虑。

     

    6、高可用的数据库架构


    1、数据架构设计原则

    2、CAP:

    在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),最多只能同时三个特性中的两个,三者不可兼得。

    C一致性(Consistency):说的是每一个更新成功后,分布式系统中的所有节点,都能读到最新的信息。即所有节点相当于访问同一份内容,这样的系统就被认为是强一致性的。

    A可用性(Availability):是每一个请求,都能得到响应。请求只需要在一定时间内返回即可,结果可以是成功或者失败,也不需要确保返回的是最新版本的信息。

    P分区容错性(Partition tolerance):是说在网络中断,消息丢失的情况下,系统照样能够工作。这里的网络分区是指由于某种原因,网络被分成若干个孤立的区域,而区域之间互不相通。
    在非金融的互联网分布式应用里面,主机多,数据大,部署分散。所以节点故障,网络故障是常态。一般是为了保证服务可用性而舍弃一致性C. 即保证AP.

    3、完善的数据备份和恢复机制

           

    4、故障转移机制

     

     

    7、高质量的服务管理


    • 1、规范服务管理:CMDB对项目、服务、服务器进行统一管理。 
    • 2、自动化发布:发布不影响用户,完善发布流程,自动化发布,可以及时回滚  。
    • 3、自动化测试: 上线完成后进行全面自动化测试。
    • 4、性能压测:通过对服务压测,了解服务可以承载并发能力,以致可以让运维通过预警进行服务器扩容 。
    • 5、代码控制:测试环境使用测试分支,beta环境发布tag,线上使用该tag发布。
    • 6、发布流程:规范上线发布流程。
    • 7、灰度发布:灰度发布服务 。
    • 8、应急处理机制 。
    •  

    8、完善的监控告警机制 


    在高可用服务设计章节提到,核心服务可以监控:服务流量预警、端口存活、进程占用的资源、服务接口功能逻辑是否正常,应用FGC等情况,需要一个完善监控告警机制,并在告警后,通过一定的策略进行处理,以致服务可以快速恢复。例如,监控FGC,如果在一分钟内存出现10次FGC,自动重启服务。

    • 1、网络流量监控 。
    • 2、系统监控服务器资源和网络相关监控(CPU、内存等) 
    • 3、日志监控统一日志收集(各个服务)监控,跟踪(log2) 。
    • 4、应用监控端口存活、进程占用的资源,应用FGC等情况
    • 5、业务监控 服务接口功能逻辑是否正常
    • 6、立体监控 监控数据采集后,除了用作系统性能评估、集群规模伸缩性预测等, 最终目标是还可以根据实时监控数据进行风险预警,并对服务器进行失效转移,自动负载调整,最大化利用集群所有机器的资源。

     

    9、容灾


    • 1、备份:数据备份(热备,冷备(冗余),异地)
    • 2、过载保护:
    • 3、同城多活-》异地多活
    • 4、流量切换
    • 5、重试,防雪崩(概率很小,成本很高)

    10、职责


    海恩法则提到:再好的技术、再完美的规章 , 在实际操作层面也无法取代人自身的素质和责任心 。

    因此要做到高可用的架构设计,职责也要清晰明确,要不然出现问题,相互推诿,问题解决进度很慢,会直接影响业务服务可用性。

    1、架构师职责:

    • 1、高可用架构设计:包括业务流程,模块划分组合,框架设计,流程纰漏,最后架构设计,技术实现步骤。 系统性的思考,权衡利弊,综合各种因素,设计出具有前瞻性的架构。
    • 2、和运维协调沟通,提出高效的服务治理解决方案,把控服务质量管理。
    • 3、协调沟通:开发之间沟通,产品之间沟通,市场沟通,运维沟通、沟通后产出图形化文档及设计。
    • 4、规范和统筹:保证系统秩序,统一,规范,稳定,高效运行。

    2、运维职责:

    • 1)、熟悉系统技术架构,和架构师制定各种规范化要求。
    • 2)、和架构师共同协调沟通,对系统架构提出可靠性,伸缩,扩展,数据库切分,缓存应用等解决方案。
    • 3)、提供监控系统,自动化发布系统,代码管理,文档平台,自动运维平台等基础设施
    • 4)、制定运维规范。
    • 5)、建立运维安全体系。
    • 5)、建立容灾备份体系。

    3、研发职责:

    • 1)、参与架构师的架构师设计,并根据设计实现具体细节。
    • 2)、针对开发功能进行自测,压测。
    • 3)、开发代码,使用工具或组件符合架构师制定规范。 包括代码规范、文档规范。
    • 4)、代码部署符合运维部署规范要求。

     

    参考《《大型网站技术架构+核心原理与案例分析》》

    展开全文
  • 高可用架构

    千次阅读 2018-08-23 13:48:11
    高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务,我们说系统的可用性是100%。 如果系统每运行100个时间...

     一、什么是高可用

    高可用HAHigh Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

    假设系统一直能够提供服务,我们说系统的可用性是100%。

    如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%。

    很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时。

    百度的搜索首页,是业内公认高可用保障非常出色的系统,甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”,百度高可用的服务让人留下啦“网络通畅,百度就能访问”,“百度打不开,应该是网络连不上”的印象,这其实是对百度HA最高的褒奖。

     

    二、如何保障系统的高可用

    我们都知道,单点是系统高可用的大敌,单点往往是系统高可用最大的风险和敌人,应该尽量在系统设计的过程中避免单点。方法论上,高可用保证的原则是“集群化”,或者叫“冗余”:只有一个单点,挂了服务会受影响;如果有冗余备份,挂了还有其他backup能够顶上。

    保证系统高可用,架构设计的核心准则是:冗余。

    有了冗余之后,还不够,每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以,又往往是通过“自动故障转移”来实现系统的高可用。

    接下来我们看下典型互联网架构中,如何通过冗余+自动故障转移来保证系统的高可用特性。

     

    三、常见的互联网分层架构


    常见互联网分布式架构如上,分为:

    (1)客户端层:典型调用方是浏览器browser或者手机应用APP

    (2)反向代理层:系统入口,反向代理

    (3)站点应用层:实现核心应用逻辑,返回html或者json

    (4)服务层:如果实现了服务化,就有这一层

    (5)数据-缓存层:缓存加速访问存储

    (6)数据-数据库层:数据库固化数据存储

    整个系统的高可用,又是通过每一层的冗余+自动故障转移来综合实现的。

     

    四、分层高可用架构实践

    【客户端层->反向代理层】的高可用


    【客户端层】到【反向代理层】的高可用,是通过反向代理层的冗余来实现的。以nginx为例:有两台nginx,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。

     


    自动故障转移:当nginx挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-nginx,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

     

    【反向代理层->站点层】的高可用


    【反向代理层】到【站点层】的高可用,是通过站点层的冗余来实现的。假设反向代理层是nginx,nginx.conf里能够配置多个web后端,并且nginx能够探测到多个后端的存活性。

     


    自动故障转移:当web-server挂了的时候,nginx能够探测到,会自动的进行故障转移,将流量自动迁移到其他的web-server,整个过程由nginx自动完成,对调用方是透明的。

     

    【站点层->服务层】的高可用


    【站点层】到【服务层】的高可用,是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接,每次请求会“随机”选取连接来访问下游服务。

     


    自动故障转移:当service挂了的时候,service-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的service,整个过程由连接池自动完成,对调用方是透明的(所以说RPC-client中的服务连接池是很重要的基础组件)。

     

    【服务层>缓存层】的高可用


    【服务层】到【缓存层】的高可用,是通过缓存数据的冗余来实现的。

    缓存层的数据冗余又有几种方式:第一种是利用客户端的封装,service对cache进行双读或者双写。

     


    缓存层也可以通过支持主从同步的缓存集群来解决缓存层的高可用问题。

    以redis为例,redis天然支持主从同步,redis官方也有sentinel哨兵机制,来做redis的存活性检测。

     


    自动故障转移:当redis主挂了的时候,sentinel能够探测到,会通知调用方访问新的redis,整个过程由sentinel和redis集群配合完成,对调用方是透明的。

     

    说完缓存的高可用,这里要多说一句,业务对缓存并不一定有“高可用”要求,更多的对缓存的使用场景,是用来“加速数据访问”:把一部分数据放到缓存里,如果缓存挂了或者缓存没有命中,是可以去后端的数据库中再取数据的。

    这类允许“cache miss”的业务场景,缓存架构的建议是:


    将kv缓存封装成服务集群,上游设置一个代理(代理可以用集群冗余的方式保证高可用),代理的后端根据缓存访问的key水平切分成若干个实例,每个实例的访问并不做高可用。

     


    缓存实例挂了屏蔽:当有水平切分的实例挂掉时,代理层直接返回cache miss,此时缓存挂掉对调用方也是透明的。key水平切分实例减少,不建议做re-hash,这样容易引发缓存数据的不一致。

     

    【服务层>数据库层】的高可用

    大部分互联网技术,数据库层都用了“主从同步,读写分离”架构,所以数据库层的高可用,又分为“读库高可用”与“写库高可用”两类。

     

    【服务层>数据库层“读”】的高可用


    【服务层】到【数据库读】的高可用,是通过读库的冗余来实现的。

    既然冗余了读库,一般来说就至少有2个从库,“数据库连接池”会建立与读库多个连接,每次请求会路由到这些读库。

     


    自动故障转移:当读库挂了的时候,db-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的读库,整个过程由连接池自动完成,对调用方是透明的(所以说DAO中的数据库连接池是很重要的基础组件)。

     

    【服务层>数据库层“写”】的高可用


    【服务层】到【数据库写】的高可用,是通过写库的冗余来实现的。

    以mysql为例,可以设置两个mysql双主同步,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。

     


    自动故障转移:当写库挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-db-master,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

     

    五、总结

    高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

    方法论上,高可用是通过冗余+自动故障转移来实现的。

    整个互联网分层系统架构的高可用,又是通过每一层的冗余+自动故障转移来综合实现的,具体的:

    (1)【客户端层】到【反向代理层】的高可用,是通过反向代理层的冗余实现的,常见实践是keepalived + virtual IP自动故障转移

    (2)【反向代理层】到【站点层】的高可用,是通过站点层的冗余实现的,常见实践是nginx与web-server之间的存活性探测与自动故障转移

    (3)【站点层】到【服务层】的高可用,是通过服务层的冗余实现的,常见实践是通过service-connection-pool来保证自动故障转移

    (4)【服务层】到【缓存层】的高可用,是通过缓存数据的冗余实现的,常见实践是缓存客户端双读双写,或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移;更多的业务场景,对缓存没有高可用要求,可以使用缓存服务化来对调用方屏蔽底层复杂性

    (5)【服务层】到【数据库“读”】的高可用,是通过读库的冗余实现的,常见实践是通过db-connection-pool来保证自动故障转移

    (6)【服务层】到【数据库“写”】的高可用,是通过写库的冗余实现的,常见实践是keepalived + virtual IP自动故障转移

    展开全文
  • 如何做高可用架构设计

    千次阅读 2018-03-28 16:41:55
    如何做高可用架构设计 本篇的题目其实比较大,所以在写的时候,我其实是有些“惶恐”的,怕这篇完成后有标题档的嫌疑。不过为了将自己过去多年的经历和最近1年改造架构的想法,做一个阶段性总结,还是有必要...

    https://juejin.im/post/59365121570c35005b6816af


    谢东升Forest
    2017 年 06 月 06 日

    如何做高可用的架构设计

    本篇的题目其实比较大,所以在写的时候,我其实是有些“惶恐”的,怕这篇完成后有标题档的嫌疑。不过为了将自己过去多年的经历和最近1年改造架构的想法,做一个阶段性总结,还是有必要好好写一写的,所以如果写得不好,大家多包涵,欢迎大家补充。


    定义目标

    既然我们的目标是做到高可用,那么我们就有必要先明确清楚高可用的含义,并通过拆解目标,让目标可以被量化。按照我的理解,可以将目标按照以下三条进行拆解:


    1. 保持业务高稳定性

    系统稳定性是高可用的根本目的,通俗的说,系统能持续可用,不会无故宕机,在高压下仍然能正常工作。

    2. 支持快速定位故障

    从实际工程的角度看,不出故障的服务是不存在的,所以出了故障要能够快速发现和定位,在外部用户发现前,通过报警机制,能准确定位故障原因,帮助工程师尽快处理问题,防止进一步影响业务。 

    3. 支持快速恢复业务

    这一点需要多说两句,有关“恢复业务”和“解决问题”之间的区别,这两个词也正好说明了线上出现故障后,我们解决问题的两种不同思路。简单的说,“恢复业务”的意思是线上故障是什么原因可以先暂时放在一边,我们先找到快速的临时方案,让业务跑起来。很多同学在处理生产故障的时候有一个思维惯性:先努力找到问题的起因,然后改代码解决问题,测试,发布上线,最后业务功能才能正常工作。实际上,一个流程走下来,时间成本是很高的,业务因为本次故障受到较大的影响。比如说某台机器上的服务响应很慢,导致请求超时,可能的原因有:网络带宽出现问题、机器磁盘有问题、机器的CPU或者Memory不够用了、应用程序有死循环、jvm垃圾回收时间变长......要在短短几分钟内排查这么多可能的原因是很难的,但我们不知道真正的原因也可以恢复业务,比如说最简单的方法就是直接把这台机器立刻下线,让流量分配到其它的机器或者新添加的机器上。

    现在我们有了这三条分拆后的目标,那么接下来的架构方案就会围绕着这三个目标来执行。


    服务分级 + 服务降级


    服务分级:根据业务的需求,将服务进行分类,划分核心服务和普通服务,核心服务与普通服务不会相互影响,服务背后的资源,缓存,数据库,MQ相互分离。服务分级,对应于我们的子目标1。

    这里有两个关键点:

    1. 抽取核心服务,例如我们互金业务中,用户,订单,支付这三个服务是核心业务,消息推送、营销券积分等是普通服务,核心服务的稳定与否也关乎业务的KPI。核心服务是客户必须要使用的,核心服务一旦有问题,客户就不能购买产品了;而普通服务即使有问题,暂时也不会对交易产生影响。从另外一个角度看,普通服务的代码在我们日常的工作中反而变动频繁。因此,优先保证核心服务正常使用,是我们首要目标。

    2. 不同级别的服务资源分离,包括服务器, 缓存,MQ, DB等建议都分离出来,因为只要不同服务共享资源,就有可能因为普通服务影响核心服务。举个最简单的例子,如果服务间共用一套redis,那么如果大量的消息请求占用了redis的连接数,那么核心服务的质量就会因此受到很大的影响。



    服务降级:当出现故障的时候,可以将普通服务直接降级,保护核心服务不受影响。服务降级,对应于我们的子目标3。

    拆分为核心服务和普通服务后,在很多业务场景下,服务间是相互调用的,这就存在服务之间可能是相互影响的。例如,我们在推送消息(普通服务)之前,需要查询用户的信息(核心服务),大量消息下发,就会给核心业务系统产生较大的压力。这种情况下我们可以通过将非核心服务停掉,以保证核心服务不受影响。

    另外,在做服务降级的时候,最佳的方式,是通过修改动态配置来执行。而不是靠手工到线上修改静态配置或者发布新版本的方式来完成,因为容易出错,而且效率还不高。所以,这里我比较推荐类似阿里diamond的服务, 接入diamond后,通过diamond后台,修改配置后,groovy脚本直接就将最新的配置同步到服务中,甚至都不要重启服务就完成了降级操作。


    建立分层监控


    建立监控分层的目的对应于我们的子目标2,就是将故障分析和定位时涉及的所有的相关信息都要监控起来,共分为5层,具体各层和含义如下:


    网络层

    分析网络出入的情况,比方说有大量的外部请求,导致外网网卡的带宽被占满,需要立刻分析是否是正常流量,如果是活动带来高频访问,那么需要做带宽升级,如果是外部攻击,那么需要考虑做流量清洗等防护操作。


    接口层

    收集对外暴露的接口的访问情况,包括接口执行时间、返回状态码、调用次数等,我们需要时刻关注我们访问次数最多的API接口,根据接口的访问情况,决定了是否需要服务扩容,并判断是否有外部的不正常访问,机刷等。如果存在某些接口有大量的错误码返回,我们需要第一时间查明这些接口访问失败的原因。


    业务层

    收集和分析核心业务和普通服务的运行情况和相互调用情况,比方说,如果某个服务产生了大量的Exceptions或者dubbo服务调用超时。


    中间件层

    中间件层指服务依赖的各类中间件,例如容器、缓存、消息队列。不同的中间件关注不一样的信息,例如数据库Redis监控指标包括连接数、请求数, rdb&aof的执行情况, IO的频率等,缓存命中率等。


    系统层

    系统层指操作系统状态、收集的信息包括cpu使用率、内存使用率、网卡流量、连接数等。 


    总结

    将实现高可用架构拆分为3个子目标,针对这3个子目标提出了三个优化思路:服务分级 + 服务降级+分层监控。围绕这三块优化的方向,层层推进,最终让系统的技术架构得到质的提升。未来,我会针对里面的每一点,进一步展开讨论一下里面的细节,除此之外,还会讨论一些本文还未涉及到的内容,例如DNS的优化,异地多活等等,欢迎大家一起讨论。


    展开全文
  • Redis 高可用架构最佳实践

    千次阅读 2017-08-13 21:33:16
    一、前言 2017 年 5 月 13 日,应用性能管理大讲堂广州站圆满落幕,其中来自三七互娱的 DBA 温国兵在会场与各位进行了精彩的 Redis 技术分享。...Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于...
  • 高可用性能平台架构演变史

    千次阅读 2018-05-04 10:20:42
    开篇概述 在如今移动互联网、互联网+、大数据的时代,各类的互联网网站、平台异常突起,如同雨后春笋,有种“忽如一夜春风来,千树万树梨花开”感觉。 对于移动互联网时代的平台来说,用户的体验感是否良好?...
  • 高可用架构

    2020-08-15 18:46:50
    CAP理论:在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个,另外一个必须...
  • 高可用的系统架构

    2018-04-16 14:07:46
    一、什么是高可用高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务,我们说系统的可用性是100%。如果系统每...
  • 高可用基本架构

    千次阅读 2019-02-11 22:45:06
    一、什么是高可用集群 高可用集群(High Availability Cluster,简称HA Cluster),是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务,把因软件、硬件、人为造成的...
  • 高可用架构(转)

    千次阅读 2018-06-22 17:51:49
    一、可用性度量与考核 首先,不得不说:要保证一个网站永远完全可用几乎是一件...例如QQ可用性达到了4个9:99.99% ①2个9=基本可用 ②3个9=较高可用 ③4个9=具有自动恢复能力的高可用 ④5个9=极高可用->...
  • 什么是高可用架构

    2019-11-17 14:10:58
    我们经常听到有人会提到高可用,那么什么是高可用呢,我们先来看百度百科中对高可用的定义,高可用是通过尽量缩短 应用日常操作,和突发的系统奔溃,所导致的停机时间,以提高系统的可用性,所以说,所谓的高可用,实际上,是...
  • 高可用+并发+负载均衡架构设计

    万次阅读 2017-09-06 19:36:42
    高可用+并发+负载均衡架构设计 原创 2017-09-05
  • 《互联网业务研发架构指南(2019)》

    万次阅读 多人点赞 2020-08-06 13:03:12
    互联网业务研发架构体系指南(草稿V0.0.1) 大纲 业务技术 稳定性 【稳定性day0】稳定性治理的三种思想—亚马逊、Netflix与蚂蚁金服 【稳定性day1】从DBA到运维架构总监之路 - 专注的力量 【稳定性day2...
  • 同步架构与异步架构 背景 把智能系统比喻成KFC营业厅,处理器是窗口和窗口后面的服务员(把一个窗口当作一个核心),指令集是后面排队的人,窗口是数据吞吐量。 当中午就餐人多的时候,一个窗口肯定忙不过来, 这...
  • 9种性能高可用高并发的技术架构

    万次阅读 多人点赞 2017-11-22 21:24:10
     所谓网站架构模式即为了解决大型网站面临的并发访问、海量数据、可靠运行灯一系列问题与挑战。为此,在实践中提出了许多解决方案,以实现网站性能、可靠性、易伸缩、可扩展、安全等各种技术架构目标。 1...
  • 现在的架构很多,各种各样的,如并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等,还有和这些架构相关的管理型的技术方法,如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE ...
  • 大型分布式网站架构技术总结

    万次阅读 2018-03-08 18:09:35
    本次分享大纲如下大型网站的特点大型网站架构目标大型网站架构模式高性能架构高可用架构可伸缩架构可扩展架构安全架构敏捷架构大型架构举例一、大型网站的特点用户多,分布广泛大流量,高并发海量数据,服务...
  • 什么是架构分隔 单体 单体:是把系统部署到一台服务器上,所有的请求业务都由这台服务器处理 优点:适合小型系统,节省资源 缺点:安全性低,一旦有突发压力, 整个系统都会面临崩溃 分层—隔离效果 分层:分层架构...
  • 8张图学习大型网站技术架构(转)

    万次阅读 2019-01-16 16:46:31
    1 大型网站架构演化 2 大型架构模式 3 大型网站核心架构要素 ...5 万无一失:网站的高可用架构 6 永无止境:网站的伸缩性架构 7 随机应变:网站的可扩展性架构 8 固若金汤:网站的安全机构 ...
  • 互联网架构为什么要做服务化?

    万次阅读 2017-08-20 21:26:52
    一、互联网高可用架构,为什么要服务化? 【服务化之前高可用架构】 在服务化之前,互联网的高可用架构大致是这样一个架构: (1)用户端是浏览器browser,APP客户端 (2)后端入口是可用的nginx集群,用于...
1 2 3 4 5 ... 20
收藏数 411,910
精华内容 164,764
关键字:

高可用架构