《究竟啥才是互联网架构“高可用”》由会员分享，可在线阅读，更多相关《究竟啥才是互联网架构“高可用”（9页珍藏版）》请在金锄头文库上搜索。
1、究竟啥才是互联架构“可”、什么是可可HA（High Availability）是分布式系统架构设计中必须考虑的因素之，它通 常是指，通过设计减少系统不能提供服务的时间。假设系统直能够提供服务，我们说系统的可性是100%。如果系统每运100个时间单位，会有1个时间单位法提供服务，我们说系统的可性是99%。很多公司的可标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个时。百度的搜索页，是业内公认可保障常出的系统，甚们会通过 能不能访问来判断“络的连通性”，百度可的服务让留下啦“络通畅，百度就能访问”，“百度打不开，应该是络连不上”的印象，这其实是对百度HA最的褒奖。、如何保障
2、系统的可我们都知道，单点是系统可的敌，单点往往是系统可最的风险和敌， 应该尽量在系统设计的过程中避免单点。法论上，可保证的原则是“集群化”， 或者叫“冗余”：只有个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他 backup能够顶上。保证系统可，架构设计的核准则是：冗余。有了冗余之后，还不够，每次出现故障需要介恢复势必会增加系统的不可服务实践。所以，又往往是通过“动故障转移”来实现系统的可。接下来我们看下典型互联架构中，如何通过冗余+动故障转移来保证系统的可特性。三、常见的互联分层架构常见互联分布式架构如上，分为：（1）客户端层：典型调是浏览器browser或者机应APP（2）反向代理层
3、：系统，反向代理（3）站点应层：实现核应逻辑，返回html或者json（4）服务层：如果实现了服务化，就有这层（5）数据-缓存层：缓存加速访问存储（6）数据-数据库层：数据库固化数据存储整个系统的可，又是通过每层的冗余+动故障转移来综合实现的。四、分层可架构实践【客户端层-反向代理层】的可【客户端层】到【反向代理层】的可，是通过反向代理层的冗余来实现的。以 nginx为例：有两台nginx，台对线上提供服务，另台冗余以保证可，常见的 实践是keepalived存活探测，相同virtual IP提供服务。动故障转移：当nginx挂了的时候，keepalived能够探测到，会动的进故障转 移，将流
4、量动迁移到shadow-nginx，由于使的是相同的virtual IP，这个切换过程 对调是透明的。【反向代理层-站点层】的可【反向代理层】到【站点层】的可，是通过站点层的冗余来实现的。假设反向代 理层是nginx，nginx.conf能够配置多个web后端，并且nginx能够探测到多个后端的 存活性。动故障转移：当web-server挂了的时候，nginx能够探测到，会动的进故障转 移，将流量动迁移到其他的web-server，整个过程由nginx动完成，对调是透 明的。【站点层-服务层】的可【站点层】到【服务层】的可，是通过服务层的冗余来实现的。“服务连接池”会 建与下游服务多个连接，每
5、次请求会“随机”选取连接来访问下游服务。动故障转移：当service挂了的时候，service-connection-pool能够探测到，会动的 进故障转移，将流量动迁移到其他的service，整个过程由连接池动完成，对调 是透明的（所以说RPC-client中的服务连接池是很重要的基础组件）。【服务层缓存层】的可【服务层】到【缓存层】的可，是通过缓存数据的冗余来实现的。缓存层的数据冗余又有种式：第种是利客户端的封装，service对cache进双 读或者双写。缓存层也可以通过持主从同步的缓存集群来解决缓存层的可问题。以redis为例，redis天然持主从同步，redis官也有sentinel
6、哨兵机制，来做redis的存 活性检测。动故障转移：当redis主挂了的时候，sentinel能够探测到，会通知调访问新的 redis，整个过程由sentinel和redis集群配合完成，对调是透明的。说完缓存的可，这要多说句，业务对缓存并不定有“可”要求，更多的 对缓存的使场景，是来“加速数据访问”：把部分数据放到缓存，如果缓存挂 了或者缓存没有命中，是可以去后端的数据库中再取数据的。这类允许“cache miss”的业务场景，缓存架构的建议是：将kv缓存封装成服务集群，上游设置个代理（代理可以集群冗余的式保证可 ），代理的后端根据缓存访问的key平切分成若个实例，每个实例的访问并不 做可。
7、缓存实例挂了屏蔽：当有平切分的实例挂掉时，代理层直接返回cache miss，此时缓 存挂掉对调也是透明的。key平切分实例减少，不建议做re-hash，这样容易引 发缓存数据的不致。【服务层数据库层】的可部分互联技术，数据库层都了“主从同步，读写分离”架构，所以数据库层的 可，又分为“读库可”与“写库可”两类。【服务层数据库层“读”】的可【服务层】到【数据库读】的可，是通过读库的冗余来实现的。既然冗余了读库，般来说就少有2个从库，“数据库连接池”会建与读库多个连 接，每次请求会路由到这些读库。动故障转移：当读库挂了的时候，db-connection-pool能够探测到，会动的进故 障转移，将
8、流量动迁移到其他的读库，整个过程由连接池动完成，对调是透 明的（所以说DAO中的数据库连接池是很重要的基础组件）。【服务层数据库层“写”】的可【服务层】到【数据库写】的可，是通过写库的冗余来实现的。以mysql为例，可以设置两个mysql双主同步，台对线上提供服务，另台冗余以保 证可，常见的实践是keepalived存活探测，相同virtual IP提供服务。动故障转移：当写库挂了的时候，keepalived能够探测到，会动的进故障转移， 将流量动迁移到shadow-db-master，由于使的是相同的virtual IP，这个切换过程对 调是透明的。五、总结可HA（High Availabi
9、lity）是分布式系统架构设计中必须考虑的因素之，它通 常是指，通过设计减少系统不能提供服务的时间。法论上，可是通过冗余+动故障转移来实现的。整个互联分层系统架构的可，又是通过每层的冗余+动故障转移来综合实现的，具体的：（1）【客户端层】到【反向代理层】的可，是通过反向代理层的冗余实现的，常见实践是keepalived + virtual IP动故障转移（2）【反向代理层】到【站点层】的可，是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与动故障转移（3）【站点层】到【服务层】的可，是通过服务层的冗余实现的，常见实践是通过service-connection
10、-pool来保证动故障转移（4）【服务层】到【缓存层】的可，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利缓存集群的主从数据同步与sentinel保活与动故障转移；更多的业务场景，对缓存没有可要求，可以使缓存服务化来对调屏蔽底层复杂性（5）【服务层】到【数据库“读”】的可，是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证动故障转移（6）【服务层】到【数据库“写”】的可，是通过写库的冗余实现的，常见实践是keepalived + virtual IP动故障转移欢迎加我的社群或关注公众号“架构师之路”进讨论。W3Cschool（）最的技术知识分享与学习平台此篇内容来于站户上传并发布。
