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

⾼可⽤和可伸缩架构 李道兵
 七⽜云存储 2015-03 啥叫⾼可⽤？ • 狭义：单台机器当机后⽤户⽆感知 • 延伸: 单台设备(主机，⺴卡，交换机，⺴线)失效后 ⽤户⽆感知、单个服务异常时⽤户⽆感知 啥叫可伸缩？ 当业务量增⻓时，可以简单通过加机器布服务来解 决，那么这个服务就是可伸缩的 你想讲啥？ 想填⼀下这张表 ⾼可⽤ 可伸缩 ⼊⼝层 业务层 缓存层 数据库 ⼊⼝层如何做⾼可⽤？ • 使⽤⼼跳技术: Keepalived 就提供这个功能 • ⽐如机器A IP是 ，机器 B 的 IP 是 , 那 么再申请⼀个 IP (我们称之为⼼跳IP), 平时绑 定在机器A上⾯，如果 A 当机，那么 IP 会⾃动绑定 在机器 B 上边. • DNS层⾯绑定到⼼跳IP即可 keepalived 有什么使⽤限制么？ • 两台机器必须在同⼀个⺴段 • 服务监听必须监听所有IP ，如果仅仅监听⼼跳IP ，那 么从机上的服务（即不持有⼼跳IP的机器）会启动失 败 • 服务器利⽤率下降（混合部署可以改善这⼀点） 两台机器，两个公⺴IP ，DNS上把域名同时定位到 两个IP ，这样算⾼可⽤么？ 不算，如果⼀台机器当机，那么就有⼀半左右的⽤ 户⽆法访问 业务层如何做⾼可⽤？ 业务层不要有状态，状态分散到缓存层和数据库。 只要没有状态，业务层的服务死掉后，前⾯的nginx 会⾃动把流量打到剩下的服务。 友情提醒：不要因为想让服务端⽆状态就直接⽤ cookie session, ⾥边的坑有点⼤，考察清楚后再⽤ ⽐较好。 缓存层如何做⾼可⽤？ 缓存层分得细⼀点，保证单台缓存当机后数据库还 能撑得住即可。 中⼩规模下缓存层和业务层可以混合部署，这样可 以节省机器。 你这也叫⾼可⽤，明明是祸⽔东引嘛 也有办法，缓存机启⽤主从两台。 主服务活着的时候，主服务读，主从服务都写。 主服务当机后，从服务升级为主服务。主服务恢复后，变成新的从服务。 这个模式也有不少变种，但⼤部分都需要两倍的服务器，⽽且性能下降。 数据库层有什么⾼可⽤⼿段么？ MySQL 有主从模式，还有主主模式都能满⾜你的需 求。 MongoDB 也有 ReplicaSet 的概念，基本都能满⾜ ⼤家的需求。 ⼩结 ⾼可⽤ 可伸缩 ⼊⼝层 ⼼跳 业务层 服务⽆状态 缓存层 减⼩粒度 数据库 主从模式 可伸缩 ⼊⼝层如何提供伸缩性？这个我知道，直接铺机器， 然后 DNS 加 IP 就可以了吧？ 可以，但也有需要注意的地⽅： 尽管⼀个域名解析到⼏⼗个IP没有问题，但是很多浏览器客 户端只会使⽤前⾯⼏个IP ，部分域名供应商对此有优化（⽐ 如每次返回的IP顺序随机），但这个优化效果不稳定。 推荐的做法是使⽤少量的 nginx 机器作为⼊⼝，业务服务器 隐藏在内⺴（HTTP类型的业务这种⽅式居多）。另外，也 可以在客户端做⼀些调度（特别是⾮ HTTP 型的业务，⽐如 直播）。 业务层伸缩性如何？ 跟应付⾼可⽤⼀样，保证⽆状态是很好的⼿段。加 机器继续⽔平部署即可。 缓存层伸缩性如何？ 如果低峰期间数据库能抗住，那么直接下线缓存然 后上新缓存就是最简单有效的办法。 如果扛不住呢？ 取决于缓存类型了，可以把缓存分为三类： 1. 强⼀致性缓存：⽆法接受从缓存拿到错误的数据 (⽐如 ⽤户余额，或者会被下游继续缓存这种情形) 2. 弱⼀致性缓存: 能接受在⼀段时间内从缓存拿到错误的 数据 （⽐如微博的转发数) 3. 不变型缓存: 缓存key对应的value不会变更 (⽐如从 SHA1 推出来