`

架构设计经验:高可用与可伸缩

 
阅读更多
1. 分布式架构要解决的主要问题

1)高可用:举个单机房高可用的例子,你肯定不希望因为一个磁盘损坏,或一个机器损坏,或者一个交换机损坏,就导致整个系统的服务不可用了。

2)在系统容量增长的情况下,如何实现可伸缩。

3)偏管理的方面:如果能够让7--10人的小组的工作是独立的服务单元,各个小组之间的工作有比较清晰的边界,这样他们合作起来会方便很多。

4)服务质量:有南北方机房,让北方的用户访问北方的机房,南方的用户访问南方的机房,如果你有合适的机制能够让这些用户的所有的操作都能够整合起来,当做一个网站来用,这就是用多机房来提高服务质量。

5)更高的需求:如果机房突然毁掉怎么办?如果你的业务是关键业务,你肯定希望做到能跨机房可用。

今天主要讲前两点,单机房的高可用和可伸缩的问题,对常规服务我们怎样解决。


2. 什么是高可用和可伸缩

1)高可用:狭义来讲,单台机器宕机后,用户全无感知。从延伸来讲,不仅有机器的概念,还有各种设备,包括主机、网卡、交换机、网线这些都要做到用户无感知。还有,你可能部署了一大堆服务,可能某一个单个服务也会产生异常,比如打开的连接数过多,也许机器的CUP突然升高导致服务劣化。

2)可伸缩:当业务量增涨的时候,如果能做到业务量增涨的时候只需要买了机器放上去,软件一部署,系统容量就增长了,这就是可伸缩。

今天,我简单把系统分成四个层次,分别将他们的高可用和可扩展方案。
1)入口处,也就是Nginx这个层, Ngx, apache这种层面的东西
2)业务层
3)缓存层
4)数据库层

3. 高可用问题的解决方案
1) 入口层:
入口层的高可用性,用的就是心跳,Keepalived就提供这个功能。
注:Keepalived: Keepalived的作用是检测web服务器的状态,如果有一台web服务器死机,或工作出现故障,Keepalived将检测到,并将有故障的web服务器从系统中剔除,当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中,这些工作全部自动完成,不需要人工干涉,需要人工做的只是修复故障的web服务器。
Keepavlied工作原理:ping, 监听端口,监控用户设定的服务器程序运行是否正常
Layer3,4&7工作在IP/TCP协议栈的IP层,TCP层,及应用层,原理分别如下:
Layer3:Keepalived使用Layer3的方式工作式时,Keepalived会定期向服务器群中的服务器发送一个ICMP的数据包(既我们平时用的Ping程序),如果发现某台服务的IP地址没有激活,Keepalived便报告这台服务器失效,并将它从服务器群中剔除,这种情况的典型例子是某台服务器被非法关机。Layer3的方式是以服务器的IP地址是否有效作为服务器工作正常与否的标准。
Layer4:如果您理解了Layer3的方式,Layer4就容易了。Layer4主要以TCP端口的状态来决定服务器工作正常与否。如web server的服务端口一般是80,如果Keepalived检测到80端口没有启动,则Keepalived将把这台服务器从服务器群中剔除。
Layer7:Layer7就是工作在具体的应用层了,比Layer3,Layer4要复杂一点,在网络上占用的带宽也要大一些。Keepalived将根据用户的设定检查服务器程序的运行是否正常,如果与用户的设定不相符,则Keepalived将把服务器从服务器群中剔除。

比如说简单的做法,我们用两台机器做互备,一台机器的IP是1234, 一台是1235,那么我们再申请一个IP1236, 我们称之为心跳IP. 这个心跳IP平时绑在机器A上,如果A宕机了,机器B就主动把这个IP抢过去,那么就达到了A宕机了B补上去,B宕机了A补上去,这只需要做一个简单的事情,把DNS直接绑到1236上面,用户根据域名访问你的服务,你的服务只想一个心跳的IP,不管你哪台机器宕机了,这个心跳IP都是活着的,这样至少在入口层我们不用担心机器司机造成的可用性问题。

Keepalived有什么使用限制呢?
第一,两台机器必须在同一个网段,由于路由的原因,跨网段不能抢这个IP, 路由不到。
第二,是服务监听,无法通过监听单个IP来绑定多个IP, 因为IP的监听必须是对称的。最简单的做法是,你就全部监听所有的IP.
第三,服务器的利用率会下降,因为是主备模式,本来一个机器可以1000M,你可能觉得两个机器可以抗住2000M流量,可实际上2台机器还是只能1000M。

2)业务层:推荐采用无状态,即不适用进程内缓存。-- 貌似扯淡,不用缓存怎样保证高性能。
业务层不要有状态,状态要分散到缓存层和数据库层。当我们用Java的时候,把很多技术线或者其他东西扔到内存里面,这样会导致整个业务的状态会嵌在业务层里面,那么如果这台服务器死机了,里面的数据就丢掉了(在融云,通过redis/ssdb保证缓存的数据在宕机后不丢失)。第二,如果你没有状态,签名是一个接入层,nginx,后面是多台业务服务器,那么一台业务服务器只会通过反向代理,把剩下的流量达到剩余的服务器上面去,如果这台服务器宕机了对用户来讲是完全无感知的。

3)缓存层:
缓存层做高可用直接做成本很高。最常见的做法是,把缓存层分得足够细。比如我们只有两台机器当缓存,其中一台宕机了,我们就会有50%的请求直接压到数据库,数据库可能就直接宕机了。如果我们把缓存的规模分的比较细,我有10台机器,每台只有1/10的容量,那么宕机一台,数据库的请求量比总量要增加10%,增加10%对数据库来讲就更容易承受。我比较推荐把业务层和缓存层混合部署,即业务层部署10台机器,缓存层也部署10台机器。就是说,缓存天生是没有高可用问题可言的,唯一要担心的是,一旦缓存宕机,会不会把数据库压垮。
对于某种特殊情况,即时缓存分散,也是无法容忍的,最简单的办法是缓存启用主从两台,主服务器活着的时候,从主服务器读,主从服务器都写。主服务器宕机的话,从服务器升级为主服务器,主服务器恢复之后变成新的从服务器。这样可以保存缓存的数据依然有效,这种模式的变种比较多,大多数需要两倍的服务器。
我也见过1.5倍服务器的情况,A服务器做一部分缓存,B服务器做一部分缓存,C作为A和B的异或。A宕机了,B和C也可以用。

4)数据库:
数据库的高可用性来讲,在业界的产品层面都解决得差不多了,SQL这一些列的,例如MySQL,有主从模式,有主主模式,都可以满足需求。


4. 可伸缩问题的解决方案
1)入口层:
最简单的,直接加机器,机器放多一点,DNS加上IP, 访问的时候自然都某个IP上去了。
简单加机器不能说不行,但有一个问题,域名解析这个阶段是不保证的,一个域名解析到10个IP,那是均匀的,但绝大部分域名解析服务器根本无法做到这一点,你会发现大部分请求只会使用前面几个IP,然后这个优化效果就很不稳定。所以如果你真的流量大到你的入口都扛不住了,最简单的就是你的入口用一些比较大的服务器(比如融云的CMP),比如说以前你有千兆网,那上万兆,现在也不贵,上万兆不行再上40GB, 百GB的服务器现在也是比较成熟的技术了。业务服务器就隐藏在内网,隐藏在内网之后,这是一种方式,如果你是基于HTTP的话。如果非HTTP,经常有一些客户端,比如游戏客户端,那么在客户端做一个调度,客户端访问之前先去一个小的服务器问有哪些IP可用,你拿到入口之后,再随机挑一个,这样也能做到比较均匀的调用。

2)业务层:业务层的可伸缩,只要保证无状态就好了。

3)缓存层:
缓存层的伸缩性,redis3.0解决了这个问题。如果想自己搭,最简单的解决方式是,如果低峰期间,比如半夜2,3点,数据库能抗住,那么直接把缓存下线掉,再上一个新的缓存系统。扛不住的话,比如是个国际站点,整天都没有低峰时段,或者说确实数据库不是设计了能抗住无缓存压力的话,我们把缓存分成三种类型,第一种是强一致性缓存,也就是说,我们无法接受从缓存里面拿到错误的数据,比如缓存用户余额。第二种是弱一致性缓存,只要达到最终一致性就可以了,能够在接受一段时间内从缓存拿到错误数据,比如微博的转发数。第三种是不变型的缓存,也就是说缓存这个key对应的值不会变更,比如我们要做解密工具,从SHA1反推密码,这样的结果不会变,或者其他复杂公式计算结果。
这三种缓存的处理方式不同。
若一致性缓存和不变型缓存扩容比较方便,用一致性hash就可以,强一致性情况会稍微复杂。比如,我们的业务服务器回去缓存系统取数据,至于这个缓存系统的配置是9台还是10台,是有一份配置文件保存在业务服务器里面的,如果你要更新缓存服务器配置的时候,你要通知业务服务器去修改这个配置,这时会有个微小的时间差,导致拿到的是过期的数据。第二种情况,你有可能扩容,扩容之后你再删除节点,比如你发现缓存出问题了或者有其他问题,这时候会拿到脏数据,比如A的key之前在机器1, 扩容后再机器2,数据更新,删除机器2后Key回到机器1,这时候会有脏数据的问题,这样比如用特殊处理把这个问题解决掉。
最简单的办法是只增不减,这当然意味着我们要引入一些高可用的技术避免单个节点坏掉。第二种方式,要么节点调整时间大于数据的有效时间,这样可以规避掉这一问题。

4)数据库
我们常用的几种办法,
办法1. 水平拆分,比如用户量比较大,预先根据用户的ID拆分成100个表,临时往一台机器上面装,未来可以扩展到100台机器上去。
办法2. 垂直拆分,典型的案例是一个电子商务网站,每个商品有一些最基础的信息,最后还有一个非常详细的信息页面,如果把信息页面和之前的信息存放在同一个数据库,那么取这种简单的基础信息的时候,也会把详细信息带出来,带出来的话,整个取的效率就很低。那么你把详细信息分到单独的表里面去,签名的索引,数据库大小都可以缩,相当于你的性能提高了。
办法3. 你可以做一些定期滚动,比如交易记录,要看之前记录的话需要做查询。这样对应的交易日志可以把三个月之前的就滚动到一个更大的数据库里面去了

总结:
把业务系统分成几个层,入口层、业务层、缓存层、数据库层。在这几个层里面有不同的技术去解决高可用和可伸缩的问题。比如入口层,用心跳解决高可用,用平行部署解决可伸缩。业务层很简单,千万记住,不要有状态,至少没有状态的时候,这两个问题解决很简单。缓存层,第一是减小粒度,避免对数据库的冲击。要么用redis3.0, 要么用一致性hash, 把伸缩带来的冲击降到最低。数据库,一个是主从模式,一个是水平或垂直拆分与定期滚动。

最后讲一下,我们不一定要到一定规模的时候采取考虑高可用和可伸缩的事情,因为高可用和可伸缩,对于大部分架构师来讲,这个东西成本并不高。比如一个简单的这种模型的业务服务,简单的一个前端业务和数据库模型,我们简单的用两台机器就可以达到所有的高可用和可伸缩的配置。最开始两台机器完全一样的部署,前面一个Nginx,两个配心跳,中间是业务,最后是数据库,一个主一个从。当业务量逐步增加的时候,第一步把数据库分出去,第二步把业务和前端做一个分离,第三部业务层做水平伸缩,第四部加缓存层。不要认为业务量小的时候就随便搭,真出了篓子就不太好了。比如某app在大访问量的时候没有抗住,这时候客户就流失掉了,再要把客户找回来就不容易了。作为一个负责任的架构师,你先把这个东西搞定掉,既然成本不高,干嘛不先搞定?
分享到:
评论

相关推荐

    开发者最佳实践日-高可用和可伸缩架构

    ### 开发者最佳实践日——高可用和可伸缩架构详解 #### 一、高可用的概念与实现 ##### 1.1 高可用定义 在IT领域,“高可用”(High Availability, HA)通常指的是系统在面对单点故障时能够维持正常运行的能力。...

    高并发高可用的可伸缩的架构设计的原则

    综上所述,高并发高可用的可伸缩架构设计涉及到多个层面的技术和策略,包括数据与计算的分离、多维度的可用性设计、合理的资源管理和优化、以及灵活的伸缩拆分等。通过综合运用这些技术和策略,可以构建出稳定可靠且...

    可伸缩服务架构:框架与中间件 第一部分

    《可伸缩服务架构:框架与中间件》以高可用服务架构为主题,侧重于讲解高可用架构设计的核心要点:可伸缩和可扩展,从应用层、数据库、缓存、消息队列、大数据查询系统、分布式定时任务调度系统、微服务等层面详细...

    可伸缩服务架构:框架与中间件 第二部分

    《可伸缩服务架构:框架与中间件》以高可用服务架构为主题,侧重于讲解高可用架构设计的核心要点:可伸缩和可扩展,从应用层、数据库、缓存、消息队列、大数据查询系统、分布式定时任务调度系统、微服务等层面详细...

    高可用架构 第1卷高可用架构 第1卷-高可用架构社区

    《高可用架构 第1卷》是高可用架构社区推出的一部深入探讨系统高可用性设计与实践的专业书籍。高可用架构是指通过设计和构建能够容忍硬件、软件甚至网络故障的系统,来确保服务的持续性和稳定性。在互联网行业中,高...

    《可伸缩服务架构框架与中间件》源码.zip

    本书以高可用服务架构为主题,侧重于讲解高可用架构设计的核心要点: 可伸缩和可扩展,从应用层、数据库、缓存、消息队列、大数据查询系统、分布式定时任务调度系统、微服务等层面详细讲解如何设计可伸缩、可扩展的...

    可扩展、高可用、负载均衡网站架构设计方案

    可扩展、高可用、负载均衡网站架构设计方案 本文将详细介绍一个可扩展、高可用、负载均衡网站架构设计方案,该方案旨在解决高访问量网站的性能和可靠性问题。该方案包括以下几个方面: 一、基本需求 1. 高可用性...

    可伸缩服务架构:框架与中间件-1

    《可伸缩服务架构:框架与中间件》,涵盖了架构师一半以上的技术。

    高可用网站架构设计与实现.rar

    网站架构设计是构建互联网应用的核心环节,其主要目标是确保服务的高可用性、可伸缩性和性能优化。高可用(High Availability, HA)架构设计通常涉及以下几个关键知识点: 1. **负载均衡**:通过分配网络流量到多个...

    读书笔记:一套高可用、易伸缩、高并发的IM群聊、单聊架构聊天系统。.zip

    读书笔记:一套高可用、易伸缩、高并发的IM群聊、单聊架构聊天系统。

    大型分布式网站架构设计与实践 PDF(带目录清晰完整版)

    《大型分布式网站架构设计与实践》这本书深入浅出地介绍了分布式系统的基础知识、设计模式以及实践经验。对于想要深入了解分布式系统架构的设计者和开发者来说,这是一本非常有价值的参考书。通过学习本书,不仅可以...

    高可用架构讲座PPT

    根据提供的信息,“高可用架构讲座PPT”这一标题与描述明确指出了该文档的主要内容是关于高可用架构的讲座资料。接下来,我们将基于这个主题展开详细的解析与介绍,旨在为读者提供一个全面、深入的理解。 ### 一、...

    源码-可伸缩服务架构-框架与中间件.zip

    "源码-可伸缩服务架构-框架与中间件.zip"这个压缩包显然包含了关于实现这种架构的相关代码、框架和中间件的资料,这对于开发者和架构师来说是一份宝贵的资源。下面,我们将深入探讨这些关键知识点。 首先,可伸缩...

    如何构建大型网站的高性能、高并发、高可用架构设计指南

    内容概要:本文全面解析了如何设计高性能、高并发、高可用的大型网站系统。首先介绍了大型网站的特性及其架构目标(高性能、高可用、可伸缩、扩展性和安全性),并详细讲述了常见的架构模式,如分层、分割、分布式...

    into100沙龙第17期:高可用高并发网站解决之道-张立刚-20160319.pdf

    张立刚-***.pdf》和描述《高可用高并发电商核心交易系统应用架构演进及实践》表明本篇文档是一场沙龙的演讲稿或演讲材料,由张立刚主讲,主题聚焦于构建和优化高可用性(HA)和高并发性的网站架构,特别是在电商核心...

    数据库架构——PaxosStore:微信高可用、强一致存储系统 共29页.pdf

    ### 数据库架构——PaxosStore:微信高可用、强一致存储系统 #### 1. 项目背景与概述 在互联网行业中,随着用户数量的急剧增长以及数据处理需求的不断加大,构建一套既能够保障数据安全性又能够实现高效稳定运行的...

    Sina架构师:基于MySQL可扩展架构设计 pdf

    《Sina架构师:基于MySQL可扩展架构设计》是一本深入探讨如何利用MySQL构建高可用、高性能、可扩展的数据库架构的专业书籍。该书主要针对的是互联网行业中的大型网站和应用,尤其是那些需要处理海量数据并确保服务...

Global site tag (gtag.js) - Google Analytics