关于高可用:618备战巡礼三高之第一高如何打造高可用系统-京东云技术团队

111次阅读

共计 4054 个字符,预计需要花费 11 分钟才能阅读完成。

前言

咱们常常会说互联网“三高”,那什么是三高呢?咱们常说的三高,高并发、高可用、高性能,这些技术是构建古代互联网应用程序所必须的。对于京东 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 大麦。

作者:京东物流 赵勇萍

起源:京东云开发者社区

正文完
 0