前言
咱们常常会说互联网“三高”，那什么是三高呢？咱们常说的三高，高并发、高可用、高性能，这些技术是构建古代互联网应用程序所必须的。对于京东 618 备战来说，所有的中台零碎服务，无疑都是围绕着三高来开展的。对于一个程序员，或多或少都能说出一些跟三高零碎无关的技术点，而我本篇文章的目标，就是帮大家零碎的梳理一下三高零碎中的第一高：高可用性。
首先来说，互联网的业务特点决定了他必须保障“三高”，同时，高并发，高可用，高性能，这三高之间并不是孤立的，而是强相干。一个高可用的零碎，肯定也须要应答高并发场景对系统带来的冲击，保证系统在高流量拜访状况下，零碎的服务的失常运行。同时，一个可能撑持高并发的零碎也肯定要满足高性能，否则也无奈实现高流量的承载。
回到咱们本文的宗旨，咱们这里所说的高可用性是指，零碎在遇到任何艰难的状况下仍能失常运行的能力。
在京东 618 备战期间，零碎的高可用对咱们来说至关重要，因为零碎的解体，不止带来间接经济上的损失，还会导致用户信赖的失落。接下来我通过一张思维导图开展我的分享，帮大家梳理一下一个高可用零碎所须要思考的技术点。
开发时
1. 首先技术架构计划选型很重要, 切记防止适度设计。
比方咱们常说的单体利用架构和微服务架构，两种架构单纯来比照，单体利用架构的可用率要比微服务架构高的。因为多服务之间的依赖肯定会升高零碎的可用率，比方一个依赖 10 个微服务的对外接口，假如每个服务的可用率是 99%，那么这个接口对外提供服务的整体可用率就间接降到了 90.4%，这两头还要思考到服务之间的网络提早，数据一致性的问题。
还有例子就是中间件抉择，比方一个缓存业务场景，我能够用内存缓存，也能够应用 redis 分布式缓存，那么应用哪个呢？应用内存缓存零碎可用率会高，因为如果引来 redis，零碎的可用率又得乘以一个 redis 的可用率。当然如果咱们的业务场景必须应用 redis，那么也是齐全能够的，但这里切记零碎的适度设计，也是设计简单的零碎，也须要更多的高可用相干的保障，所付出的资源代价和运维代价也是几何增长。
2. 其次就是代码品质。
其实这个可能是很多人疏忽的一点，因为很多人更喜爱高谈阔论分布式，集群，压测，故障演练等等，但在我看来，一个代码开发品质的好坏，或者说一个程序员对代码的掌控力，对系统可用性起到至关重要的作用。以下举几个代码维度的例子。
第一个就是异样解决。一个代码品质的好坏，要看他对异样解决能力，一个本科生的课程设计代码，可能都是主业务逻辑，一条路写到黑，不思考任何异常情况，而一个毕业几年的程序员，经验过线上业务的拷打，可能会用在代码里找到很多的 try-catch，用于捕获各种不确定逻辑，而一个资深程序员，反而他的代码里你看不到任何 try-catch, 因为他全副用 AOP 的形式实现了异样的捕获。这就是代码维度的考量，一个优良的代码，肯定是进攻式编程，同时还会配合单元测试等。
第二个讲述一个什么是对代码的掌控力。在大厂里，你更多场景是接手他人的老代码。想必所有程序员都深有体会，接手他人的老代码是一件极其苦楚的经验，尤其是他人写了一半的代码。老话前人种树后人乘凉，但在程序员圈，前人种树，前人只能凉凉了 ….. 调侃归调侃，但有些事件须要面对，后期你须要对业务场景和代码逻辑进行抽丝剥茧的梳理，这个很重要。如果你无奈对老代码进行充沛相熟，那么你就不敢去改写和重构它，如果在不相熟的前提下贸然批改代码或者配置，而后上线，那么很大几率会带来线上零碎问题，影响零碎可用率。换一个角度来说，咱们写的代码将来也可能交接给他人，如何不让他人苦楚，也是咱们的责任。所以正当应用设计模式，遵循代码标准，书写代码架构和设计文档，这些也是很重要的一点，他的重要可能会关乎零碎将来的可用率。
对于代码开发这块，京东技术平台也积淀了一些本人的教训。外部有本人的 java 代码开发标准阐明文档，也在京英学习平台上能够进行考试。而京东的 coding 平台，能够在你代码提交时，配置代码开发标准扫描和代码安全性扫描，同时，能够配置代码评审人，这些都能够用来晋升咱们代码品质。
部署时
1. 冗余性和备份
在部署维度，咱们首先思考的是冗余性和备份设计，这个可能是大家曾经很相熟的状况了，咱们能够通过集群的形式，多个服务器、磁盘或者网络接口来缩小故障点的数量。说到集群，依据实现形式和目标不同，我帮大家梳理一下集中集群类型：
（1）高可用集群。
有多个独立服务器组成的零碎，旨在进步零碎可用性，当主节点呈现故障时，通过失败转移（Failover）让备用节点主动接管服务。这个咱们常见的有 zookeeper 集群，etcd 集群等等，这类集群是基于共识算法实现的，通过选举的形式，来保障当主节点故障时，能够有主动备份节点主动接管。
（2）负载平衡集群。
在负载平衡零碎中，流量被扩散到多个服务器中，每个服务器都独立地解决申请。当一个服务器负载过高或呈现故障时，申请会主动被转移到其余可用的服务器上，从而保证系统的可用性和性能。负载平衡能够在多个层面上实现，包含应用层、传输层和网络层。在应用层负载平衡中，负载均衡器通常通过 HTTP 代理来散发申请，并依据申请的特定属性（例如 URL 或 Cookie）进行路由。在传输层负载平衡中，负载均衡器通常在传输层（例如 TCP 或 UDP）上运行，并依据端口号或其余特定协定进行路由。在网络层负载平衡中，负载均衡器通常是一个独立的网络设备，用于在不同的服务器之间散发网络流量。
（3）数据库集群。
这里的数据库能够了解为狭义数据库，就是数据的存储媒介。对于数据库的的集群实现形式，分为如下几个：主从复制，复制集，分区。
对于这几种实现计划，这里能够 elasticsearch 举例说明。ES 有分片和正本的概念，所谓的分片，就是将数据程度划分到多个节点，每个节点存储局部数据，当查问数据时，须要在多个节点上进行查问，最初将后果合并。分区能够实现数据的高可用性和可扩展性，但须要思考数据一致性问题。
同时 ES 的每个分片都能够配置多个正本，正本跟主从复制相似，或者说更像一个集群内的高可用子集，容许多个正本实例同时存在，并反对主动故障转移和成员选举，保障了数据的高可用性和负载平衡。
此外，对于集群计划来说，还要额定思考多机房部署问题，异地多活。换句话说，我所有服务实例，不能放在一个篮子里，因为网络的抖动和不稳定性，对系统可用性来说是很大的威逼。
2. 公布检测
在部署维度，第二个关键点是公布检测。有统计数据表明，咱们大部分的稳定性问题来源于零碎变更，也就是零碎的公布上线。那么如何保障一个安稳的零碎上线呢？
首先，要欠缺自动化测试和单元测试，每次发版前，必回归测试，当然这块如果交给人工来做，费时费力，不肯定能起到他的成果，所有说，欠缺的自动化测试流程，对于零碎稳定性部署来说，至关重要。
其次就是做好公布的自动化，在发版过程中，缩小人为参加，这样也就缩小了出错的可能性。京东的行云部署自身就反对部署编排，利用部署编排，能够稳固且高效的实线滚动发版。同时也能够在行云上的流水线中配置 CI/CD 流程，实现持续集成和继续部署的串联。
最初就是要实现发版的可观测，可灰度，可回滚。发版前要有 checklist，发版时采纳灰度公布验证的形式，能够升高因为发版引起的线上故障。最初如果发版发现失败，能够实现疾速的回滚操作。这个就要在发版前的 checkList 里，做好回滚流程的备案。
运维时
在运维时，咱们的指标是可能疾速止损线上问题，做到问题早发现，快定位，速解决。
1. 零碎全链路观测和监控
在互联网零碎中，从用户申请开始，通过所有的零碎组件或服务，直到响应返回给用户，对整个零碎的性能、稳定性和可用性进行全面观测和监控的过程。这包含了对硬件、网络、存储、软件等方面的观测，监控。
在京东 618 备战期间，所有利用零碎都必须实现自建，欠缺 UMP 监控埋点，对外围接口办法的可用率，TP99，调用量进行实时监控，同时，也对须要对云主机，中间件等资源维度，包含 CPU，内存，资源占有率进行实时监控。
此外，针对监控，要做好日志监控做好采集工作，因为日志记录了零碎中各个组件或服务的运行状态，能够提供丰盛的信息用于问题排查和剖析。
在京东外部采纳 logbook 进行日志采集，对于外围业务须要审计留存的，能够独自搭建 ELK，将历史日志存入 ES 中。
2. 值班与报警。
针对 618 备战期间，须要额定安顿固定人员进行每日值班，做到对线上问题能够及时反馈。
针对报警机制，有一点须要切记，要把握好报警的阈值问题，如果阈值偏低，会导致研发人员频繁收到报警，导致警惕性升高。而如果阈值偏高，会错过一些线上问题，导致问题没有及时发现，以致故障扩大化。
3. 故障演练及应急机制。
京东外部有两大利器，一个是 ForceBot，一个是 Chaos Monkey。
前者是做全链路军演压测用的，个别 618 大促前要进行三次军演压测，通过这些军演，让各个利用零碎发现零碎中的薄弱点，并针对性解决。forcebot 是通过部署在全国各地的 CDN 节点，模仿实在用户发动的大规模拜访流量，这种靠近实战的压测，能够让咱们做到防患于未然，同时，通过压测，能够针对性的优化服务资源，可能更针对性的进行扩容。
第二个咱们有时候会叫猴子捣鬼测试，也会叫混沌测试。它可能通过模仿包含网络，中间件，流量等在内的各种故障，通过故障的随机注入，来演练咱们对系统故障的反馈能力。
这里就该提到所谓的应急机制。该机制就像一本相似医院给发的急救指南手册，须要在日常做到对各种不确定的故障进行反馈能力。比方遇到突发高流量，零碎呈现了熔断，如何疾速扩容云主机和各类中间件资源；比方网络忽然产生提早，接口申请超时状况下，如何做好降级计划等等。
总结
本文写于京东 618 备战开门红前夜值班之时。
以上的所有对于零碎高可用的总结，都源于一次次的前人的实际经验总结进去的。每次备策略细节有不同，但大的方向准则是不变的。
祝：京东 618 大麦。
作者：京东物流 赵勇萍
起源：京东云开发者社区