专栏名称: 京东成都研究院
京东商城成都研究院信息平台
目录
相关文章推荐
51好读  ›  专栏  ›  京东成都研究院

CDRD TALK|系统稳定性建设

京东成都研究院  · 公众号  · 成都  · 2017-09-30 17:12

正文

稳定性概述

去年的年会上刘总强调了京东未来12年只有三样东西:技术!技术!技术!这说明了技术在京东未来12年的发展过程中起的关键作用,也从侧面对我们技术人员提出了更高的要求。系统稳定性是京东技术必须做好的事情,对于京东这样体量的公司,系统稳定性影响的不只是用户的体验,甚至是许多行业、企业正常运转甚至赖以生存的基础。这里的稳定性是个笼统的概念,总的意思是必须持续地、正确地,在预期时间内提供服务,也就是大家经常提到的可靠性、稳定性、可用性等一堆概念。这些概念之间很多时候没有清晰的界线,往往互相关联互相影响,只是描述的侧重点不同。稳定性侧重描述不同环境下系统的效率波动是否在合理范围内,可靠性侧重描述规定条件下完成规定功能的能力,可用性侧重描述系统处在可工作状态时间的比例。比如一个系统平常对用户的请求响应时间是100ms,高峰期响应时间是3s,变得很慢,这个时候系统处理结果没有出错,我们可以说系统是可靠的但不稳定。因此接下来的描述我们不严格区分这些概念,统称系统稳定性。

稳定性指标

要做系统稳定性建设首先要确定稳定性的目标,不同的业务对稳定性的定义和要求可能有些不同,但本质上可以用如下的一些指标来衡量:

  • 吞吐量 :单位时间内系统处理的请求数。

  • 并发数 :单位时间内系统能同时服务的用户数。

  • 故障规模 :每次发生故障的影响面。

  • 故障频率 :规定时间内发生故障的次数。

  • 平均无故障时间 :系统平均能够正常运行多长时间才发生一次故障,可靠性越高平均无故障时间越长。

  • 平均响应时间 :系统为用户返回请求结果所化的平均时间。

要实现屈指可数的这几个指标并非易事,需要做大量的工作。从平常的工作中可以了解到一些常用的稳定性保障措施,比如监控、测试等。而对于大规模复杂系统的稳定性建设是个系统工程,靠零散的几个措施并不能很好的实现稳定性目标,它贯穿与软件整个生命周期中,并且也不是一个系统自身的问题,而是涉及到一个系统交互网络。我把系统稳定性建设分为一纵、一横两条路径。

稳定性建设

纵向路径

所谓纵向路径就是用户请求所经过的系统节点。现在公司内部,大多数业务系统开发人员只要负责建设和维护自己的应用服务器就可以让业务安全稳定地跑起来,实际上应用服务器只是请求链路中的一个小节点。整条纵向链路节点可以划分的很细,每个节点都要做足稳定性的相关工作,具体划分多细取决于自身的工作范围,但是作为应用系统分析设计人员,我们至少要关注以下几个重要节点。

负载均衡 :负载均衡有F5这样的硬件设备,也有LVS/HAPROXY这样的系统级软件,还有NGINX这样的反向代理。负载均衡器的稳定性保障通常依靠一主一从热备,通过心跳检测和IP漂移来做切换,复杂点的是把负载均衡做成集群。这一层需要对网络知识有更多的了解,往往需要专业的工程师来做稳定性保障优化。

应用集群 :集群不是一个应用的集群,而是多个互相依赖的应用集群,我们主要关注关键链路上应用系统间的稳定性保障。

存储缓存 :存储缓存这一块涉及非常丰富的内容,站在业务开发人员的角度,我们主要关注数据切分,数据一致性,可用性。常用到的技术包括应用缓存管理,分库分表策略,数据一致性保障,部署方式等。

网络 :网络是连接所有节点的纽带,起着至关重要的作用。网络往往是复杂多变的,作为业务开发人员,我们一般需要了解TCP/IP,HTTP等基本协议,对Nagle/三次握手/半连接队列/全连接队列等概念要有所了解并能处理相应问题。

横向路径

纵向请求链路上的每一个节点都可能是一个或者多个复杂的软件系统,纵向的关注重点在于节点之间的稳定性,而节点自身的稳定性保障需要更深入更广泛的领域知识。把节点展开就是接下来从横向角度来介绍如何开展稳定性保障的工作。从横向来看,稳定性保障工作贯穿与整个软件生命周期,主要分为四个阶段:

  • 架构设计阶段

  • 开发实现阶段

  • 测试阶段

  • 运行阶段

各个阶段的侧重点有所不同。

架构设计

技术人员之间经常争论好的系统是设计出来的还是进化出来的,在我看来,世界不是非黑即白的,在这个问题上也是,系统设计方向不对,基础建设不牢,今后很难进化发展为一个完善的系统,甚至需要推倒重来。而前期的架构设计再好,后面没有好好维护、共同遵守约定,最终也会摇摇欲坠的。在架构设计阶段,我们需要重点关注以下几点:

系统划分: 系统划分不是按照一些概念随意划分,而是应该在充分了解业务需求和未来业务发展大致方向的基础上进行的。大的原则上来说,我们会按照业务域进行垂直划分,在业务域中,视业务模块的规模和重要程度来决定是否独立建立系统,同时对于一些公共的交叉业务,我们还会从横向的角度来建立平台系统。

关键约束 :关键约束是系统持续健康发展的基础,是大家共同遵守的规约。没有约束就很难保证系统朝着正确的、稳定的方向演进。通常,我们可以重点关注以下约束。

  • 建立良好的系统分层模型,确保层次清晰、职责分别,各层之间无循环依赖。

  • 避免过度设计和系统单点。

  • 共同遵守一套编码规范和日志规范。

  • 核心系统弱依赖非核心系统或者不依赖非核心系统

  • 高内聚,低耦合

开发实现

开发阶段除了完成基本功能性需求的开发外,还需要列出可能会影响稳定性的风险点,有针对性的来制定策略解决这些风险点。

远程调用风险

我们所有的业务系统在开发的时候基本都会涉及到远程调用,比如JSF调用,DB调用等。对于远程调用我们要时刻保持警惕,因为远程调用跨进程、强依赖网络的原因导致远程调用不是百分百可靠的。发生失败的原因可能很多,比如网路抖动、系统重启、发布、系统负载过高、BUG等。大多数情况我们只需要处理好远程调用的返回值就好了,针对上述这些异常情况,我们有一些措施去避免这些风险。







请到「今天看啥」查看全文