百度商业托管页系统高可用建设方法和实践 [复制链接]

导读：在互联网公司中，业务迭代快，系统变更频繁，初期都是刀耕火种。但随着系统复杂度不断增加，系统稳定性问题会凸显出来，当稳定性问题成为业务发展的掣肘的时候，重新推倒重来所需要的代价可想而知，因此我们的系统架构需要持续优化和演进不断提升稳定性，既要解决当务之急，又要防患未然。本文结合具体实践，对系统高可用建设的方法进行思考和总结。

全文字，预计阅读时间19分钟。

01一、背景介绍

百度商业托管：是百度为了实现营销新生态的建设，以高效连接和投放优化为目标，为商业客户提供一站式的的运营阵地，连接服务和消费者，是百度从流量运营到用户运营的重要转变。代表的产品有基木鱼、度小店等建站和电商平台。

随着托管页的业务不断发展，系统的规模和业务复杂度不断增加，系统的可用性面临巨大挑战，本文从可用性建设的方法到实践，深入分析稳定性建设的思路，从规范、监控、冗余、降级、预案等多方面实现系统的高可用。

「可用性指标定义:」对于系统而言，最理想的情况是系统能提供24小时不间断的提供服务、但由于软件系统的复杂度高，尤其在分布式系统环境中经常会由于系统BUG、软硬件异常、容量不足等导致系统无法提供%的可用性，因此通常采用N个9来评估系统可用性，此指标也作为一些基础服务的SLA的标准。

02二、可用性整体建设思路

2.1故障发现早

系统的高可用建设是一件庞大的工程、需要从不同维度去综合考虑，整体建设思路可以围绕系统故障发生的时间、范围、频率，处理速度等方面来综合考虑。从故障的发生时间来看，在用户或客户反馈问题之前，研发人员能够第一时间发现问题是非常重要的，每一次故障发生之后我们都会深入思考一个问题，能不能更早的发现问题,我们有哪些常用的手段和方法，下面就逐一介绍下。

2.1.1故障发现早-规范化：

「日志规范化」：

规范化的核心思想是通过一定约束来保证整体系统能够协调统一,托管内部的服务是基于统一的微服务框架构建，但由于各个系统和模块的日志千差万别，在开发、测试和运维阶段带来较高的成本。日志规范主要是针对开发过程中关键业务信息的记录，高效的定位问题；在QA测试阶段进行问题排查；在数据统计分析提供有效指导手册。

「全局通用规范」：

全局上下文采用统一的MDC实现，用中括号和空格分割。所有的logger均需设置addtivity=false，禁止重复打印。msg信息需要简明、易懂。相关日志禁止重复打印到console.log中。打印日志使用slf4j门面。

「日志分级」/p>

「TRACE」　　调试详细信息，线上禁止开启。

「DEBUG」　　开发调试日志，线上禁止开启。

「WARN」　　警告日志日志常用来表示系统模块发生问题，但并不影响系统运行。

「INFO」　　信息记录日志级别主要用于记录系统运行状态等关联信息。

「ERROR」　　错误信息输出此信息输出后，主体系统核心模块正常工作，需要修复才能正常工作。

「日志文件」：

「logPattern」

propertyname="ENCODER_PATTERN"value="%d{yyyy-MM-ddHHss.fff}[%thread][%X{reqid}][%X{ip}][%X{baiduid}][%X{cuid}]%-5level%logger{5}:%msg%n"/

「关键日志的格式要求」此处涉及的细则规范较多，不一一列举，主要涉及到贯穿日志的核心上下文，需要包含来源ip,请求路径,状态码,耗时等。

「报警规范化」报警规范化主要针对错误日志的报警监控，做到报警的分级监控、定义了分级监控的监控项目名称的定义。针对不同级别的报警，采用不同的采集任务和监控策略，并定义配套的跟进流程。

通用服务的性能监控报警。强依赖的性能监控报警。服务异常状态码监控报警。第三方服务耗时监控报警。

「值班规范化」：针对值班同学的通报、止损、定位、解决等核心规范和流程，保证线上的问题能够第一时间处理和解决。

2.1.2故障发现早-系统监控

系统监控主要是从问题感知到问题定位的全面能力的建设。前面提到的日志规范化整改是实现自动化问题感知的前提，当系统日志规范完成之后，我们就可以通过一些自动化的方式来建设统一的监控。在问题感知层面主要包含业务指标、业务功能、系统稳定性、数据的正确性、时效性等。

「问题感知:」业务指标是指系统