项目设计-服务可靠性建设

软件工程有两个显著特点，一是具备规模化快速复制扩散的能力，二是在竣工之后依然可以被改造并保持高速进化。这也就导致了软件工程一点点的不足也可能被快速扩散、无限放大造成大规模损失，进化中既有的稳定性结构可能会被不断打破，可能导致大量的救火投入，疲于奔命，极大地消耗有效而宝贵研发资源，阻碍软件的进行甚至带来灾难性后果。‘

所以，我们在项目设计时需要考虑到服务的可靠性建设，

稳定性保障围绕的核心

在业务团队进行服务设计的时候，稳定性保障涉及应用架构代码质量、流量与封网管控、故障复盘、监控等，是一项非常系统化的工程。比如技术架构选型，服务稳定性，基础设施建设，开发规范，业务恢复能力等。

系统实现核心环节与稳定性关系如下图所示：

这几个核心点并不是所有都是业务团队需要关系的，所以，下面只会描述下业务团队主要关心的事情。

开发规范

服务稳定性

代码通用模块稳定性

结合自身系统特点，理清楚变与不变。把可以反复使用的部分、易出错的部分以及系统核心引擎抽象出来，做为系统不变的部分。把伴随着业务的变化或者新业务方接入而不断调整的部分提取出来，做为系统中可变的部分。

对于不变的部分，运用设计模式及常用套路将其固化下来形成公共模块，降低类似功能重复编写带来的风险，提高增量业务迭代效率。这部分代码投入核心精力让它像工具类一样稳定可靠，之后反复运行。这部分的抽象决定了系统的核心代码层次，保障大楼的上相似的模块统一稳定，有统一的管控手段。

对于变的部分，提供扩展点。这部分是会随着业务的变化而不断迭代，同时要考虑让变化的部分具备隔离性。即当改动一个子业务需求时，尽可能从从架构上限定住它的影响范围。

追求高内聚，低耦合，满足开闭原则易扩展易维护的代码层次结构。

统一对外服务层异常兜底

标准是当service层抛异常，我们需要自己处理掉异常，以Result结果中的结果码的形式与外界通信，而不是直接抛运行时异常给业务方。那么我们可以抽象出中间件层，对Service层的异常统一捕获，返回兜底错误码给上游。

统一抽象摘要日志模块

日志记录什么

• 记录有帮助的信息
• 找到已发生事件的任何信息 When What Where How Who
• 理清简洁的上下文相关信息
• 分析各种可能性
• 人工、半自动、自动
• 远程可下载的日志文件
• 导致系统缓慢的蛛丝马迹
• 认证/授权信息

什么时候记录日志

操作日志

• 出现影响单个用户的错误时
• 出现影响所有用户的关键条件时
• 系统/应用程序的启动、停止、重启时
• 运行中活动导致的属性改变
• 新组件、插件的安装
• 配置发生变更
• 代码/缓存变更
• 开始备份
• 日志访问审计
• 安全相关日志
• etc. 业务相关日志

记录的一行日志，就像讲述一个故事，when, what, who, and why

统一下游依赖模块

正确的做法是我们对于同一个下游入口，包装出唯一的接口，唯一的方法，统一维护、监控，反复使用。这里的下游不仅仅指业务系统，同时包括对于一些中间件的依赖，比如：针对 redis、mysql、es 访问封装。

资源池使用

单个应用对异步线程的管理，应该有统一的接口收口，使用者只需要业务函数及所需要的变量即可。

这样通过统一的监控配置一目了然就能看到整个应用对资源池的使用管理情况，快速诊断出是哪里的线程池使用不合理导致的系统线程数飙高报警，也便于后续的交接维护

服务监控设计

抽象来看系统层面发现能力建设主要有三个方向：异常处理、监控设计、错误码，日志。

异常处理

当service层抛异常，我们需要自己处理掉异常，以错误码的方式返回给调用方

错误码

需要建立错误码标准，分外部错误码、内部错误码，建立错误码统一维护策略。
参考 新浪开放平台 Error code 的设计

错误代码说明

• 服务级错误（1为系统级错误） 服务模块代码 具体错误代码
• 服务级别错误：1 为系统级错误；2 为普通错误，通常是由用户非法操作引起的
• 服务模块为两位数：一个大型系统的服务模块通常不超过两位数，如果超过，说明这个系统该拆分了
• 错误码为两位数：防止一个模块定制过多的错误码，后期不好维护
• code = 0 说明是正确返回，code > 0 说明是错误返回
• 错误通常包括系统级错误码和服务级错误码
• 建议代码中按服务模块将错误分类
• 错误码均为 >= 0 的数

日志

记录的一行日志，就像讲述一个故事，when, what, who, and why

监控设计

监控是手段和目标，需要在错误码、异常、日志三个要素的基础之上基于业务特点细化到每一段核心代码逻辑，能够及时发现预期之外的运行逻辑，报警精准程度则直接决定了线上运维成本。根据适用场景可以把分为通知型与大盘型，通知型是指直接通过某种通讯工具报警触达至接收者

通知型监控告警层

比如依赖方返回时间超过500ms、错误码环比大涨、异常量大涨、出现未知异常。这类异常应该由统一解决方案，无需按照业务模块重复建设。

特定业务场景告警层

结合系统所承载的业务本身，对关键链路做特定监控。

业务恢复能力

当通过监控发现问题后，进一步面临的是如何恢复的问题。一般有如下几种手段：

业务降级

当发现服务接口超时，定位到是某一个下游依赖所致。且判断该依赖并非产品核心流程，此时需要一键关闭掉对该服务的调用，进而保障主流程能够正常工作。要求我们在编码的时候能够梳理强弱依赖，对弱依赖增加必要的降级开关，并形成预案。

重试补偿与人工介入

重试补偿分自动重试补偿和人工补偿两种情形。

自动重试如消息重试，线程内循环重试，一般是因为机器进程中断，网络延时等原因导致的差错场景，这类场景经过系统自动重试机制是可以完成的。

而人工补偿主要面对人为引起的脏数据，或者依赖外部机构带来的不可控因素。

极限兜底保护稳定性

无论什么时候，要保障你的系统是活着的，