首页
关于
Search
1
给你10个市场数据调研报告的免费下载网站!以后竞品数据就从这里找!
141 阅读
2
php接口优化 使用curl_multi_init批量请求
131 阅读
3
2024年备考系统架构设计师
102 阅读
4
《从菜鸟到大师之路 ElasticSearch 篇》
102 阅读
5
PHP 文件I/O
89 阅读
php
thinkphp
laravel
工具
开源
mysql
数据结构
总结
思维逻辑
令人感动的创富故事
读书笔记
前端
vue
js
css
书籍
开源之旅
架构
消息队列
docker
教程
代码片段
redis
服务器
nginx
linux
科普
java
c
ElasticSearch
测试
php进阶
php基础
登录
Search
标签搜索
php函数
php语法
性能优化
安全
错误和异常处理
问题
vue
Composer
Session
缓存
框架
Swoole
api
并发
异步
正则表达式
php-fpm
mysql 索引
开发规范
协程
dafenqi
累计撰写
785
篇文章
累计收到
8
条评论
首页
栏目
php
thinkphp
laravel
工具
开源
mysql
数据结构
总结
思维逻辑
令人感动的创富故事
读书笔记
前端
vue
js
css
书籍
开源之旅
架构
消息队列
docker
教程
代码片段
副业
redis
服务器
nginx
linux
科普
java
c
ElasticSearch
测试
php进阶
php基础
页面
关于
搜索到
785
篇与
的结果
2023-09-01
集成平台的高可用-双机冷备和热备
集成平台的高可用-双机冷备和热备随着电子病历和互联互通成熟度等级评测的快速推广、集成平台所集成的系统越来越多,作为集成平台基础核心组件的集成引擎的容灾功能越发重要, 宕机而产生的连带后果不容小觑 。其实早在2011年,原卫生部就已经强调落实国家信息安全等级保护制度,三级甲等医院的核心业务信息系统安全保护等级不得低于三级, 保证系统的高可用性。医院集成平台高可用性(HA)的解决方案:双机冷备两个服务器,一台运行,一台不运行做为备份。这样一旦运行的服务器宕机,就把备份的服务器运行起来。 冷备的方案比较容易实现,但 冷备的缺点是主机出现故障时备机不会自动接管,需手动启动硬件和服务。宕机可能无法及时被发现,经常是在数据不到位时才发现服务已经停止,然后手动启动 ,而很多情况下都是直接重启主机来解决,备机有时形同虚设。 冷备容灾部署示意图有些医院在冷备的基础上增加了操作系统层级的热备或使用硬件实现热备, 但这些“热备”都只是在整个服务器宕机的情况下才能触发,而实际经常发生的情况通常是集成平台的服务停止了,但服务器还在运行,这样就不会自动切换到备机,仍然需要手动重启来解决。 因此,集成引擎应用/服务级别的热备就显得非常重要,在主机的服务出现问题时快速自动切换到备机,确保医院的业务继续平稳运行。双机热备双机热备即是通常所说的 active/standby 方式, 服务器数据包括数据库数据同时往两台或多台服务器写。当active服务器出现故障的时候,通过软件诊测(一般是通过心跳诊断)将standby机器激活,保证应用在短时间内完全恢复正常使用。当一台服务器宕机后,自动切换到另一台备用机使用,不需要工作人员手动去切换。 双负载均衡热备容灾部署示意图关于Odin多功能引擎Odin多功能引擎具有双机热备功能 ,符合国家三级等保要求。Odin的高可用性通过消除单点故障,进行主节点和从节点之间的实时数据复制提供了额外的数据保护,并能自动或一键式进行故障切换和故障恢复,为医院信息平台安全稳定运行保驾护航。Odin多功能引擎还具有以下优势:Odin引擎从根本上解决了引擎重启慢的问题:有些品牌引擎重启, 有时需要5、6小时, 用户只得手动删日志等信息, 使重启加快,效率低。Odin先检查核心模块, 启动后再做全面检查、恢复,重启动时间从质上缩短。解决了数据库点重新联接时必须手动启动的问题: Odin已经实现全自动重新连接,无需手动干预。解决了数据量大时引发的各种不稳定问题:Odin多功能引擎大量采用新技术,可以轻松应对每日10,000门诊量。系统的容错性:Odin 引擎可以隔离失败的子系统功能, 防止可能导致整个系统崩溃的故障连锁效应的发生。
2023年09月01日
27 阅读
0 评论
0 点赞
2023-09-01
高并发(水平扩展,垂直扩展)
高并发(水平扩展,垂直扩展)一、什么是高并发高并发(High Concurrency) 是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指, 通过设计保证系统能够同时并行处理很多请求。 高并发相关常用的一些指标有 响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数 等。响应时间:系统对请求做出响应的时间。 例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间。吞吐量:单位时间内处理的请求数量。 QPS:每秒响应请求数。 在互联网领域,这个指标和吞吐量区分的没有这么明显。并发用户数:同时承载正常使用系统功能的用户数量。 例如一个即时通讯系统,同时在线量一定程度上代表了系统的并发用户数。二、如何提升系统的并发能力互联网分布式架构设计, 提高系统并发能力的方式,方法论上主要有两种:垂直扩展(Scale Up)与水平扩展(Scale Out)。垂直扩展垂直扩展:提升单机处理能力 。垂直扩展的方式又有两种:(1)增强单机硬件性能例如:增加CPU核数如32核,升级更好的网卡如万兆,升级更好的硬盘如SSD,扩充硬盘容量如2T,扩充系统内存如128G;(2)提升单机架构性能例如:使用Cache来减少IO次数,使用异步来增加单服务吞吐量,使用无锁数据结构来减少响应时间;在互联网业务发展非常迅猛的早期,如果预算不是问题,强烈建议使用“增强单机硬件性能”的方式提升系统并发能力,因为这个阶段,公司的战略往往是发展业务抢时间,而“增强单机硬件性能”往往是最快的方法。不管是提升单机硬件性能,还是提升单机架构性能,都有一个致命的不足: 单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。水平扩展水平扩展:只要增加服务器数量,就能线性扩充系统性能。 水平扩展对系统架构设计是有要求的,如何在架构各层进行可水平扩展的设计,以及互联网公司架构各层常见的水平扩展实践,是本文重点讨论的内容。三、常见的互联网分层架构常见互联网分布式架构 如上,分为:(1)客户端层:典型调用方是浏览器browser或者手机应用APP(2)反向代理层:系统入口,反向代理(3)站点应用层:实现核心应用逻辑,返回html或者json(4)服务层:如果实现了服务化,就有这一层(5)数据-缓存层:缓存加速访问存储(6)数据-数据库层:数据库固化数据存储整个系统各层次的水平扩展,又分别是如何实施的呢?四、分层水平扩展架构实践反向代理层的水平扩展反向代理层的水平扩展,是 通过“DNS轮询”实现的 :dns-server对于一个域名配置了多个解析ip,每次DNS解析请求来访问dns-server,会轮询返回这些ip。当nginx成为瓶颈的时候,只要增加服务器数量,新增nginx服务的部署,增加一个外网ip,就能扩展反向代理层的性能,做到理论上的无限高并发。站点层的水平扩展站点层的水平扩展,是 通过“nginx”实现的 。通过修改nginx.conf,可以设置多个web后端。当web后端成为瓶颈的时候,只要增加服务器数量,新增web服务的部署,在nginx配置中配置上新的web后端,就能扩展站点层的性能,做到理论上的无限高并发。服务层的水平扩展服务层的水平扩展,是 通过“服务连接池”实现的 。站点层通过RPC-client调用下游的服务层RPC-server时,RPC-client中的连接池会建立与下游服务多个连接,当服务成为瓶颈的时候,只要增加服务器数量,新增服务部署,在RPC-client处建立新的下游服务连接,就能扩展服务层性能,做到理论上的无限高并发。如果需要优雅的进行服务层自动扩容,这里可能需要配置中心里服务自动发现功能的支持。数据层的水平扩展在数据量很大的情况下,数据层(缓存,数据库)涉及数据的水平扩展,将原本存储在一台服务器上的数据(缓存,数据库)水平拆分到不同服务器上去,以达到扩充系统性能的目的。互联网数据层常见的水平拆分方式有这么几种,以数据库为例:按照范围水平拆分每一个数据服务,存储一定范围的数据,上图为例:user0库,存储uid范围1-1kwuser1库,存储uid范围1kw-2kw这个方案的 好处 是:(1)规则简单,service只需判断一下uid范围就能路由到对应的存储服务;(2)数据均衡性较好;(3)比较容易扩展,可以随时加一个uid[2kw,3kw]的数据服务;不足 是:(1)请求的负载不一定均衡,一般来说,新注册的用户会比老用户更活跃,大range的服务请求压力会更大;按照哈希水平拆分每一个数据库,存储某个key值hash后的部分数据,上图为例:user0库,存储偶数uid数据user1库,存储奇数uid数据这个方案的 好处 是:(1)规则简单,service只需对uid进行hash能路由到对应的存储服务;(2)数据均衡性较好;(3)请求均匀性较好;不足 是:(1)不容易扩展,扩展一个数据服务,hash方法改变时候,可能需要进行数据迁移;这里需要注意的是,通过水平拆分来扩充系统性能,与主从同步读写分离来扩充数据库性能的方式有本质的不同。通过水平拆分扩展数据库性能:(1)每个服务器上存储的数据量是总量的1/n,所以单机的性能也会有提升;(2)n个服务器上的数据没有交集,那个服务器上数据的并集是数据的全集;(3)数据水平拆分到了n个服务器上,理论上读性能扩充了n倍,写性能也扩充了n倍(其实远不止n倍,因为单机的数据量变为了原来的1/n);通过主从同步读写分离扩展数据库性能:(1)每个服务器上存储的数据量是和总量相同;(2)n个服务器上的数据都一样,都是全集;(3)理论上读性能扩充了n倍,写仍然是单点,写性能不变;缓存层的水平拆分和数据库层的水平拆分类似,也是以范围拆分和哈希拆分的方式居多,就不再展开。五、总结高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。 提高系统并发能力的方式,方法论上主要有 两种:垂直扩展(Scale Up)与水平扩展(Scale Out) 。前者 垂直扩展可以通过提升单机硬件性能 ,或者提升单机架构性能,来提高并发性,但 单机性能总是有极限的 ,互联网分布式架构设计 高并发终极解决方 案还是后者: 水平扩展 。互联网分层架构中,各层次水平扩展的实践又有所不同:(1)反向代理层可以通过“DNS轮询”的方式来进行水平扩展;(2)站点层可以通过nginx来进行水平扩展;(3)服务层可以通过服务连接池来进行水平扩展;(4)数据库可以按照数据范围,或者数据哈希的方式来进行水平扩展;各层实施水平扩展后,能够通过增加服务器数量的方式来提升系统的性能,做到理论上的性能无限。
2023年09月01日
67 阅读
0 评论
0 点赞
2023-09-01
程序世界里的不信任原则
程序世界里的不信任原则导语人与人之间最重要的是信任,但 程序的世界里,可能信任越少越好;我越发觉得越是高性能高可用的系统里,不信任原则会体现得更加淋漓尽致 。 为了少走弯路,写下这篇文章留给自己参考,其中一些是自己踩过的一些坑;一些是接手他人系统时触过的雷;还有一些是从别人分享的经验学习得来;能力有限,先记下自己的一些体会,错误的地方再慢慢改正。一、编程的世界里十面埋伏编程,是一件容易的事,也是一件不容易的事。说它容易,是因为掌握一些基本的数据类型和条件语句,就可以实现复杂的逻辑;说它不容易,是因为高性能高可用的代码,需要了解的知识有很多很多; 编程的世界,也跟扫雷游戏的世界一样,充满雷区,十面埋伏,一不小心,随时都可能踩雷,随时都可能Game Over。 而玩过扫雷的人都知道,避免踩雷的最好方法,就是提前识别雷区并做标记(设防)避免踩踏。鉴于此, 编程的世界里,从输入到输出同样需要处处设防,步步为营。1、对输入的不信任(1)对空指针的检查不只是输入,只有是使用到指针的地方,都应该先判断指针是否为NULL,而内存释放后,应当将指针设置为NULL。【真实案例】:注册系统某段逻辑,正常使用情况下,都有对指针做检查,在某个错误分支,打印日志时,没检查就使用了该字符串;结果可正常运行,但当访问某个依赖模块超时走到改分支,触发bug,导致 coredump 。(2)对数据长度的检查使用字符串或某段buf,特别是memcpy/strcpy时,需要尽量对数据长度做下检查和截断。【真实案例】:接手oauth系统后运行数月表现良好,突然有一天,发生了coredump,经查,是某个业务不按规定请求包中填写了超长长度,导致memcpy时发生段错误,根本原因,还是没有做好长度检查。(3)对数据内容的检查某些场景下,没有对数据内容做检查就直接使用,可能导致意想不到的结果。【案例】: sql注入和xss攻击都是利用了服务端没有对数据内容做检查的漏洞。2、对输出(变更)的不信任变更的影响一般体现在输出,有时候输出的结果并不能简单的判断是否正常,如输出是加密信息,或者输出的内容过于复杂。所以,对于每次变更(1)修改代码时,采用不信任编码,正确的不一定是“对”的,再小的修改也应确认其对后续逻辑的影响,有些修正可能改变原来错误时的输出,而输出的改变,就会影响到依赖该改变字段的业务。(2)发布前,应该对涉及到的场景进行测试和验证,测试可以有效的发现潜在的问题,这是众所周知的。(3)发布过程,应该采用灰度发布策略,因为测试并非总是能发现问题,灰度发布,可以减少事故影响的范围。常见灰度发布的策略有机器灰度、IP灰度、用户灰度、按比例灰度等,各有优缺点,需要根据具体场景选择,甚至可以同时采用多种的组合。(4)发布后,全面监控是有效发现问题的一种方法。因为测试环境和正式环境可能存在不一致的地方,也可能测试不够完整,导致上线后有问题,所以需采取措施补救A:如使用Monitor监控请求量、成功量、失败量、关键节点等B:使用DLP告警监控成功率C:发布完,在正式环境测试一遍【案例】oauth系统某次修改后编译时,发现有个修改不相关的局部变量未初始化的告警,出于习惯对变量进行了初始化(初始化值和编译器默认赋值不一样),而包头某个字段采用了该未初始化的变量,但在测试用例中未能体现,监控也没细化到每个字段的值,导致测试正常,监控正常;但前端业务齐齐互动使用了该包头字段,导致发布后影响该业务。二、服务程序的世界里防不胜防一般的系统,都会有 上下游 的存在,正如下图所示而上下游的整个链路中,每个点都是不能保证绝对可靠的,任何一个点都可能随时发生故障,让你措手不及。因此, 不能信任整个链路中的任何一个点,需进行设防。1、对服务本身的不信任主要措施如下:(1)服务监控前面所述的请求量、成功量、失败量、关键节点、成功率的监控,都是对服务环节的单点监控。在此基础上,可以加上自动化测试,自动化测试可以模拟应用场景,实现对于流程的监控。(2)进程秒起人可能在程序世界里是不可靠的因素(大牛除外),前面的措施,多是依赖人来保证的;所以,coredump还是有可能发生的,这时,进程秒起的实现,就可以有效减少coredump的影响,继续对外提供服务。2、对依赖系统的不信任可采用柔性可用策略,对于根据模块的不可或缺性,区分关键路径和非关键路径,并采取不同的策略(1)对于非关键路径,采用柔性放过策略当访问非关键路径超时时,简单的可采取有限制(一定数量、一定比重)的重试,结果超时则跳过该逻辑,进行下一步;复杂一点的统计一下超时的比例,当比例过高时,则跳过该逻辑,进行下一步(2)对于关键路径,提供弱化服务的柔性策略关键路径是不可或缺的服务,不能跳过;某些场景,可以根据目的,在关键路径严重不可用时,提供弱化版的服务。举例如派票系统访问票据存储信息严重不可用时,可提供不依赖于存储的纯算法票据,为弥补安全性的确实,可采取缩短票据有效期等措施。3、对请求的不信任(1)对请求来源的不信任有利可图的地方,就会有黑产时刻盯着,伪造各种请求,对此,可采取如下措施A:权限控制如 ip鉴权、模块鉴权、白名单、用户登录态校验 等B:安全审计权限控制仅能打击一下非正常流程的请求,但坏人经常能够成功模拟用户正常使用的场景;所以,对于一些重要场景,需要加入安全策略,打击如IP、号码等信息聚集,频率过快等机器行为,请求重放、劫持等请求)(2)对请求量的不信任前端的请求,不总是平稳的;有活动时,会暴涨;前端业务故障恢复后,也可能暴涨;前端遭到恶意攻击时,也可能暴涨; 一旦请求量超过系统负载,将会发生雪崩,最终导致整个服务不可用,对此种种突发情况,后端服务需要有应对措施A:频率限制,控制各个业务的最大请求量(业务根据正常请求峰值的2-3倍申请,该值可修改),避免因一个业务暴涨影响所有业务的情况发生。B:过载保护,虽然有频率限制,但业务过多时,依然有可能某个时间点,所有的请求超过了系统负载,或者到某个IDC,某台机器的请求超过负载,为避免这种情况下发生雪崩,将超过一定时间的请求丢弃,仅处理部分有效的请求,使得系统对外表现为部分可用,而非完全不可用。三、运营的世界里不可预测1、对机器的不信任机器故障时有发生,如果服务存在单点问题,故障时,则服务将完全不可用,而依赖人工的恢复是不可预期的,对此,可通过以下措施解决(1)容灾部署即至少有两台以上的机器可以随时对外提供服务。(2)心跳探测用于监控机器是否可用,当机器不可用时,若涉及到主备机器的,应做好主备机器的自动切换;若不涉及到主备的,禁用故障机器对外提供服务即可。2、对机房的不信任现实生活中,整个机房不可用也是有发生过的,如2015年的天津滨海新区爆炸事故,导致腾讯在天津的多个机房不能对外提供正常服务,对此采取的措施有:(1)异地部署不同IDC、不同城市、不同国家等部署,可用避免整个机房不可用时,有其他机房的机器可以对外提供服务(2)容量冗余对于类似QQ登陆这种入口型的系统,必须保持两倍以上的冗余;如此,可以保证当有一个机房故障时,所有请求迁移到其他机房不会引发系统过载。3、对电力的不信任虽然我们越来越离不开电力,但电力却不能保证一直在为我们提供服务。断电时,其影响和机器故障、机房故障类似,机器会关机,数据会丢失,所以,需要对数据进行备份。(1)磁盘备份来电后,机器重启,可以从磁盘中恢复数据,但可能会有部分数据丢失。(2)远程备份机器磁盘坏了,磁盘的数据会丢失,使用对于重要系统,相关数据应当考虑采用远程备份。4、对网络的不信任(1)不同地方,网络时延不一样一般来说,本地就近的机器,时延要好于异地的机器, 所以,比较简单的做法就是近寻址,如CMLB。也有部分情况,是异地服务的时延要好于本地服务的时延,所以,如果要做到较好的最优路径寻址,就需要先做网络探测,如Q调(2)常有网络有波动或不可用情况和机器故障一样处理,应当做到自动禁用;但网络故障和机器故障又不一样,经常存在某台机器不可用,但别的机器可以访问的情况,这时就不能在服务端禁用机器了,而应当采用本地回包统计策略,自动禁用服务差机器;同时需配合定时探测禁用机器策略,自动恢复可正常提供服务机器。5、对人的不信任人的因素在运营的世界里其实是不稳定的因素(大牛除外),所以,不能对人的操作有过多的信任。(1)操作备份每一步操作都有记录,便于发生问题时的回溯,重要的操作需要 review ,避免个人考虑不周导致事故。(2)效果确认实际环境往往和测试环境是存在一些差异,所有在正式环境做变更后,应通过视图review和验证来确认是否符合预期。(3)变更可回滚操作前需对旧程序、旧配置等做好备份,以便发生故障时,及时恢复服务。(4)自动化部署机器的部署,可能有一堆复杂的流程,如各种权限申请,各种客户端安装等,仅靠文档流程操作加上测试验证时不够的,可能某次部署漏了某个步骤而测试又没测到,上线后就可能发生事故若能所有流程实现自动化,则可有效避免这类问题。(5)一致性检查现网的发布可能因某个节点没同步导致漏发,也就是不同的机器服务不一样;对此,有版本号的,可通过版本号监控发现;没版本号的,则需借助进程、配置等的一致性检查来发现问题。四、小结备注:以上提到的不信任策略,有的不能简单的单条使用,需要结合其他的措施一起使用的。好了,先写这么多。最重要的还是那句话,程序的世界里,应该坚持不信任原则,处处设防。
2023年09月01日
45 阅读
0 评论
0 点赞
2023-08-31
并发和并行的区别
并发和并行的区别区别并发(concurrency)和并行(parallellism)是:解释一:并行是指两个或者多个事件在同一时刻发生;而并发是指两个或多个事件在同一时间间隔发生。解释二:并行是在不同实体上的多个事件,并发是在同一实体上的多个事件。解释三:并行是在多台处理器上同时处理多个任务。如 hadoop 分布式集群,并发是在一台处理器上“同时”处理多个任务。所以 并发编程的目标是充分的利用处理器的每一个核,以达到最高的处理性能。并行(parallel)并行(parallel):指在同一时刻,有多条指令在多个处理器上同时执行。所以无论从微观还是从宏观来看,二者都是一起执行的。并发(concurrency)并发(concurrency):指在同一时刻只能有一条指令执行,但多个进程指令被快速的轮换执行,使得在宏观上具有多个进程同时执行的效果,但在微观上并不是同时执行的,只是把时间分成若干段,使多个进程快速交替的执行。并行在多处理器系统中存在,而并发可以在单处理器和多处理器系统中都存在,并发能够在单处理器系统中存在是因为并发是并行的假象,并行要求程序能够同时执行多个操作,而并发只是要求程序假装同时执行多个操作(每个小时间片执行一个操作,多个操作快速切换执行)。当有多个线程在操作时,如果系统只有一个 CPU,则它根本不可能真正同时进行一个以上的线程,它只能把 CPU 运行时间划分成若干个时间段,再将时间段分配给各个线程执行,在一个时间段的线程代码运行时,其它线程处于挂起状态.这种方式我们称之为并发(Concurrent)。当系统有一个以上 CPU 时,则线程的操作有可能非并发。当一个 CPU 执行一个线程时,另一个 CPU 可以执行另一个线程,两个线程互不抢占 CPU 资源,可以同时进行,这种方式我们称之为并行(Parallel)。
2023年08月31日
42 阅读
0 评论
0 点赞
2023-08-31
什么是高可用
什么是高可用一、什么是高可用高可用HA(High 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自动故障转移
2023年08月31日
36 阅读
0 评论
0 点赞
1
...
60
61
62
...
157