b站崩了那一晚上我想该写点什么了

几个读者群都很热闹，点开几乎都在讨论B站崩了的事情，你们还不断在给B站作压测，访问从没中止过。

写段子、调侃B站的文章已经太多了，做为技术人，正好借此次机会说说互联网公司是怎么作高可用的。

通常互联网公司，通过了这十几二十年的增加，技术的一轮一轮迭代，中型以上互联网公司基本都有一套本身的高可用的架构，经历了一个阶段：

• 单机房
• 同城多机房
• 异地多活（二地三中心）

大多数互联网公司都是走了这样一个架构升级历程，可是真正在容灾方面作的怎么样？估计只有他们本身最清楚。

国内互联网公司的SRE不少都是参考Google 来作的，方法论是Google在2015年发表的一篇论文《High-Availability at Massive Scale: Building Google’s Data Infrastructure for Ads》，为此Google还写了一本书（书图片放下面了），相信不少人都看过。不过即便是强如Google，也有服务宕机的状况。

美国东部时间 12 月 14 日，大量用户反馈 Google 公司服务中断， YouTube、Gmail、Google 云端硬盘、Google Search 等服务没法正常使用。此外，很多热门手机游戏也受到了波及，由于须要用谷歌帐户登陆。长达 50 分钟的宕机，导致全球多个国家及地区用户受到严重影响。

缘由：Google Cloud Platform 和 Google Workspace 经历了一次全球中断，影响了全部须要 Google 帐户认证的服务，持续时间为 50 分钟。根本缘由是咱们的自动配额管理系统出现了问题，下降了谷歌中央身份管理系统的容量，致使其在全球范围内返回错误。所以，咱们没法验证用户请求是否通过认证，并向用户提供错误。

简单来讲，是因为内部存储配额的问题使 Google 身份验证系统中断，致使宕机了 50 分钟。

其实就算是作了异地多活，也不能彻底保证系统服务彻底不宕机，没有银弹，这是软件系统自己的复杂性决定的，一方面互联网技术在不断迭代，从最开始的单机，到双机HA、虚拟化、分布式、容器、再到上云、云原生、Service Mesh等。另外一方面业务需求也愈来愈复杂，从原来的注重用户和业务的野蛮增加，到用户的精细化运营，从增量市场到存量博弈，业务的复杂度愈来愈高，随之也加剧了技术的复杂度。

下面说一说互联网公司基础架构的演进。

单机房

通常对于不少服务连续性要求不高，可用性要求没那么高的，好比公司内部的系统，不少就是单机房部署，有的甚至是单机部署。

安琪拉之前大学给老师搞的软件，那时候用的C#写的，本地部署，说简单点就是直接在实验室老师的电脑上部署好，整台电脑（软件带硬件）一块儿卖给人家的，由于只是工具软件，数据都是保持在本地的，软件卡了直接关机重启，????。架构图以下：

通常虽然是单机房，可是不少都是分布式部署的，因此若是机房出现故障，就只能死等。

同城双机房

单个机房在出现不可抗拒的问题（如断电、断网等因素）时，会致使没法正常提供服务，会对业务形成潜在的损失。因此在金融级的高可用设计上，为了不用户损失，须要一种能够基于同城或异地的多个不一样机房之间的多活机制，在保障数据一致性的同时，可以最大程度下降因为机房的单点可用所致使的潜在高可用问题。同城双活就是其中的一种机制。

由于同城双机房实际就是在一个城市，创建了二个机房，从物理位置上能够离的足够近，因此能够在二个机房之间拉根专线，机房之间部署的系统能够相互调用，接口层的DNS、四层设备、反向代理、网关/Web层能够随机路由。

有一个机房出现故障时，可在基本不丢失数据的状况下进行应急切换，保持业务连续。逻辑架构图以下：

若是从设计上，按服务维度拆分应用，应用之间用rpc服务调用连通，平台层面设计服务治理的策略，服务可作水平扩展，弹性扩缩容，机房以前近似与同机房部署，内部服务路由策略能够自由选择，例如：轮询、一致性哈希、同机房优先、sticky session、自定义路由规则等。

将业务系统拆分为模块化、标准化、松耦合、可插拔、可扩展的微服务架构。

存储层以MySQL数据库为例，主从复制，主节点故障时候能够手工或者自动切换从为主，可是这种方案只是解决可用性问题，对于数据一致性是有损的，觉得这种架构设计一个时间点只有一个Master节点，目前更合理的设计是采用分布式数据库，利用Paxos、Raft分布式多数派原则，好比存在5个Master节点，写时须要3个节点都写成功才算成功，这样经过一致性协议保证数据强一致。

二地三中心（异地主备）

由于出现某个城市出现洪涝、地震等天然灾害，会出现城市级机房不可用的状况，因此跨城机房就是避免这种状况出现而产生，可是不少公司由于成本和服务可用性要求没这么高，没有作异地主备。

这种架构模式是在同一个城市，弄二个机房，在另外一个城市弄一个备用机房，叫作同城双活+异地灾备，也是不少CTO经常提的两地三中心。

通常跨城调用是有必定延迟的，上海杭州大概是30ms左右，通常异地主备主要仍是一个作主，另外一个主要起到数据备份，服务backup的功能，若是主机房服务出现可靠性问题，例如访问成功率断崖式下跌，能够当即让异地的备份机房当即切主，等到主机房故障恢复，再切回主机房。

备机房有点相似于主机房的镜像，因此访问层、服务层和存储层都是独立部署的。备机房访问层和服务层一直会有health check，以及仿真流量，保证备机房服务随时启用的时候都是可用状态，否则主机房挂了，启用备用机房的时候发现备用机房也是不可用的，那就完蛋了。

同城双活+异地灾备虽然对可用性有帮助，对于可用性要求不高的不须要作这种架构。这种同城双活+异地灾备架构也有一些弊端：

1. 异地灾备没有业务流量，可是备份了二个主机房的全部业务数据，异地机房的机器容量、配置要求也不低，日常大部分状况机器都是空跑的，利用率比较低，因此成本仍是比较高的。
2. 跨城同步仍是有必定延迟，若是平时没有常常演练，即便主机房出故障，也不敢贸然切异地灾备机房；每一年蚂蚁5月份都有机房演练，好比直接把一个机房断电，断网，还有红蓝对抗，人为故障注入。
3. 故障灾备策略每每不是自动化的，不能一有业务异常就切备，因此决策仍是比较复杂的，通常也不会作出自动化的，须要测试演练，因此维护的成本、切换的风险也很高；
4. 由于主备资源系统的类似性，因此伸缩性很差，扩容困难，由于主备确定要一块儿扩一块儿缩容，服务和容量都要对应。

由于这些弊端的存在，就衍生了异地多活。

异地多活

异地多活指的是否是只有同城的二个机房提供服务，物理地址不一样的机房同时提供服务。

架构设计图以下：

异地多活下，能够按照就近原则，用户访问更快，如上图，华东用户就访问上海机房，华南用户就走深圳机房，时效性更好，若是机房出故障，路由层把流量切到异地机房。业务流量能够自定义配置，不均等的分配到各个地域机房里面。与异地单机房相比，

• 具有更快的恢复能力。流量动态分配，一个区域挂掉，流量能够自由的在地域间调度、切换。

• 不用备份全站，成本更低。

• 数据异地backup，同机房也有数据备份，数据流量支持自定义，机房维度扩缩容更灵活，好比我能够99%流量给到其中一个机房，把某个机房流量调到只剩1%，在云环境中，可扩展性更好。

固然并非全部业务都须要作异地多活，对可用性有极致要求，核心应用，数据规模大的才优先作，不然整个技术复杂度也会比较复杂。

逻辑架构以下：

 

LDC 单元化

LDC 单元化架构是能够实现异地多活和高并发场景的架构体系，LDC（Logic Data Center）逻辑数据中心是相对于传统的 IDC（Internet Data Center）提出的。逻辑数据中心所表达的中心思想是不管物理结构如何的分布，整个数据中心在逻辑上是协同和统一的。主要适用于大型互联网公司在线交易系统支持，好比淘宝、支付宝、携程等。

关于LDC架构，由于技术敏感方面缘由，我隐去一些信息，周末整理之后再发出来，这个是目前阿里云和蚂蚁采用的部署架构。