服务器又崩了？深度解析高可用架构的挑战和实践

微服务架构挑战

 软件架构的演进历程

首先我们先来看下软件架构的演进历程：

单体架构：没有复杂逻辑分层，前后代码耦合，单个应用可能与多个数据库关联

适用于：迭代频率低，并发量小，业务逻辑简单的应用场景，目前单体架构在政府、金融、工业领域仍有广泛应用。

SOA架构：按业务逻辑进行服务拆分，服务间通过服务总线进行服务管理及流量转发

其主要问题在于：服务总线成为系统新的瓶颈，难以伴随业务的不断发展满足线性扩容的要求。

微服务架构：服务架构通过服务注册中心实现服务注册发现，服务启动时将服务实例注册到注册中心，调用方在发起调用时通过注册中心进行服务寻址，直接与提供方进行通信。理论上服务可以伴随业务发展实现线性扩展，不同服务之间可单独迭代，实现敏捷开发。

服务网格：版本云原生k8s及容器技术发展，服务网格技术已趋于成熟，相较于传统的微服务架构，服务网格通过sidercar模式进行流量代理和服务注册发现，无需业务感知，轻松实现跨语言服务治理，帮助业务快速迁移，使业务应用更加专注自身业务逻辑实现。

每种软件架构没有严格意义上的好坏之分，用户需要根据自身的业务特点进行架构选型。

微服务应用常见问题

微服务架构在满足高并发、敏捷迭代的同时，业务模块数量成几何数增长，给应用运维带来了严峻挑战，微服务架构相较于传统单体架构，具有流量洪峰激增、模块依赖复杂、故障定位难度大、故障恢复耗时长的特点。

• 流量激增：单体应用拆分为微服务应用后，原有的单一请求逻辑拆分为多个微服务应用的组合业务逻辑，接口调用量成1:N的增长关系，面对流量洪峰，接口调用量激增。

  
  

• 模块依赖复杂：原有的单体应用仅存在单一进程内的业务逻辑组合，微服务应用拆分为多个进程，各模块间的服务上下游依赖关系复杂，单个微服务或单个接口异常通常引发链式反应，造成服务雪崩。

  
  

• 故障定位难度大：单次请求异常需要依据各模块的依赖关系分析整个调用链路定位故障原因，由于横跨多个微服务应用进程的不同业务逻辑，故障定位难度陡增。

  
  

• 故障恢复耗时长：由于各微服务模块依赖关系复杂，需要根据调用链准确定位故障问题根源并进行逐级恢复，故障恢复及恢复后验证评价结果耗时长。

如何度量系统可用性指标

管理学大师彼得德鲁克曾说“你如果无法度量它，就无法管理它”(“It you can’t measure it, you can’t manage it”)。要想有效管理，就难以绕开度量的问题。

那如何度量分布式系统的可用性指标呢，这里有一个简单公式，可用性=平均故障间隔时间/平均故障间隔时间与平均故障恢复时间之和。

所谓平均故障间隔时间是指相邻两次故障之间的平均工作时间，也称为平均故障间隔。平均修复时间是从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。

MTBF：即平均故障间隔时间，英文全称是“Mean Time Between Failure”。是衡量一个产品（尤其是电器产品）的可靠性指标。单位为“小时”。

MTTR：全称是 Mean Time To Repair，即平均修复时间。是指可修复产品的平均修复时间，就是从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。

高可用架构设计的道、法、术

那如何设计高可用的微服务架构呢？接下来我将分别从道、法、术三个层面讲高可用微服务架构设计的基本原理、架构设计原则、以及高可用架构常用的解决方法。

道：从CAP到BASE

CAP 理论：在一个分布式系统中， 一致性（C：Consistency）、可用性（A：Availability） 和 分区容忍性（P：Partition Tolerance），最多只能同时满足其中两项。其中分区容忍性（P：Partition Tolerance）是复杂网络环境下的必须要素，因此分布式系统的架构设计需要在一致性和可用性之间进行取舍。就诞生了诸如：Paxos 算法 和 Raft 算法强一致性共识算法，以及2阶段提交，3阶段提交的最终一致性算法。

BASE 理论：BASE是对 CAP 中一致性和可用性权衡的结果，它的理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

法：微服务高可用架构设计原则

结合我对微服务高可用架构的理解，总结出以下6点高可用架构设计的原则，分别是服务无状态、异步解耦、分区容错、故障隔离、快速恢复、最终一致性：

服务无状态：服务应用进行无状态设计，将服务应用的状态数据通过缓存、数据库进行集中存储，通过nginx或网关进行负载均衡实现水平扩展。

异步解耦：各服务模块通过发布订阅、事件驱动方式进行异步解耦，单次请求调用通过异步回调方式快速响应，将通知事件与处理结果分离，避免异常雪崩。

分区容错：基于指定的业务规则实现业务分流路由，将流量分发至多个可用区，不同可用区通过数据同步、多备份机制保障数据一致性。

故障隔离：单一进程、单一接口、单一服务通过熔断、降级机制实现故障隔离，避免系统关联异常，引发雪崩效应。

快速恢复：通过流量切分，版本管理、应用回滚机制实现应用快速回退至健康版本，快速恢复应用。

最终一致性：通过多数据源双写、数据稽核、数据修复实现数据跨可用区数据最终一致性。

术：高可用常用手段

分区容错：

异地容灾是高可用架构典型的应用场景，通过将不同地域的数据中心构建多套应用服务，当单一地域服务宕机时可快速通过流量切换灾备中心保障业务持续、稳定。异地容灾按保障级别不同分为，多可用区、同城冷备、同城双活、异地冷备、两地三中心五个级别，其保障级别、应用成本、恢复延迟都呈递增趋势。

异步解耦：

在微服务应用中通过引入消息中间件将上游组合服务对下游多个微服务的同步调用进行异步解耦，基于消息的可靠投递能力快速响应用户请求，能够大幅提升服务并发访问性能及用户体验，并通过数据补偿手段保障数据最终一致性。

服务限流：

由于 API 接口无法控制调用方的行为，因此当遇到瞬时请求量激增时，会导致接口占用过多服务器资源，使得其他请求响应速度降低或是超时，严重导致服务器宕机。服务限流主要是保护服务节点或者数据节点，防止瞬时流量过大造成服务和数据崩溃，导致服务不可用。

• 局部限流：基于简单计数、令牌桶、漏斗算法在单个节点内的限流，仅能限制传入此节点的请求，无需引入中间件，通过局部限流达到全局限流的目的，同时避免实例级别单一接口访问量激增问题

• 全局限流：基于简单计数、令牌桶算法，通过引入中间件如redis，针对整个集群流量进行全局控制。

从下图中可以看出，当网关入口服务请求下游多个服务接口，当服务C接口异常将导致入口服务流量的不可用，服务A、服务E请求则白白占用。

从下图中可以看出，当网关入口的服务请求下游的单一服务接口，当服务B接口异常将导致入口请求夯住，占用网关请求资源，导致整体业务异常。

针对以上两种异常场景，通过在服务调用时配置熔断策略能够快速失败，直接反馈上游业务异常结果，避免请求线程夯死及服务雪崩。

TSF高可用最佳实践

TSF微服务平台针对业务流量激增、服务异常容错等问题提供架构容灾、灰度发布、服务容错兜底、实例优雅启停、应用性能管理的一体化高可用服务架构。突出立体化、自动化、可视化的优势，提供端到端的应用性能监控，多维度可视化的运行监控数据聚合分析，实现故障自动感知，自动处理，快速恢复故障业务，保障系统的稳定高效运行。

单元化架构部署

单元化架构是一种高级的高可用架构设计模式，通过对核心业务数据分片，应用服务无状态设计将相同领域的业务服务划分为一个个独立的部署单元，单元内整体业务闭环。通过单元化部署架构能够有效满足弹性伸缩，故障隔离，异地容灾等高可用建设要求。此外基于单元化部署可以实现以部署单元为基准，构建灵活的发布策略。

单元化架构产品能力：

• 网关业务单元路由标签 

• 支持跨单元横向调用 

• 单元内服务容错兜底

通过配置动态伸缩规则，TSF中控服务基于agent上报的监控数据实现实时统计，满足流量激增自动扩容或流量低峰自动缩容能力，有效保障服务高效稳定及资源利用率提升。

全链路灰度发布

灰度发布是将具有一定特征或者比例的流量分配到需要被验证的版本中，用来观察新的验证版本的线上运行状态。相比全量上线，灰度发布是更加谨慎的发布形式。当线上调用链路较为复杂时，全链路灰度发布可以将线上的各个服务隔离出一个单独的运行环境。

优雅启停

在应用滚动发布过程中，可以通过调整部署组滚动发布更新策略达到服务优雅下线，降低发布过程中业务中断影响。

这里简单介绍优雅下线的简单流程

1. 下线实例在注册中心进行反注册，注销该实例注册信息；

2. 注册中心节点订阅更新周期为15s，调用方在感知注册中心实例变更后，更新本地缓存服务地址，不再将流量路由到下线实例，期间保障业务无中断；

3. 下线实例等待30s（2个心跳周期）后进行实际下线操作；

优雅启停产品能力：

• 支持容器、虚机部署方式

• 实例反注册下线事件详情 

• 实例启动就绪检测

服务限流

TSF 限流基于监控服务流量的 QPS 指标，当达到指定的阈值时进行流量控制，避免被瞬时高峰流量冲垮，从而确保服务的高可用。支持在网关配置全局限流策略保障入口服务流量稳定支持针对单一服务配置局部限流策略保障当前服务流量稳定，同时提供灵活的限流规则配置及动态生效，提供可视化的限流操作及监控数据展示。

服务熔断

TSF服务熔断能力支持服务、实例、API多维度的熔断隔离级别，提供控制台可视化配置及熔断事件展示，满足熔断配置热生效需求。

熔断器状态转换：

• 熔断器开始处于closed状态，一旦检测到错误（或慢响应）达到一定阈值，便转为open状态，此时不再调用下游目标服务。

•  一段时间后转化为half open状态，尝试放行一部分请求到下游服务。 

• 一旦检测到响应成功，回归到closed状态，也即恢复服务；否则回到open状态。

健康检查与注册中心联动流程

健康检查分为存活检查及就绪检查；存活检查主要作用是确定进程存活状态，判断是否需要进行实例重启。就绪检查主要作用是确定服务实例能否支持对外服务，将健康检查结果与注册中心状态联动避免流量接入异常节点。

健康检查产品能力：

• 存活检查

• 就绪检查

• 多种探测方式：http，tcp，执行命令

• 支持虚机&容器部署

应用性能管理能力

最后我们从一个问题排查流程全局展示tsf应用性能管理能力：

1. 用户收到监控平台发送的告警信息，确定异常基本信息。

2. 通过服务依赖拓扑确定异常服务的上下游依赖关系，进行全局视图分析。

3. 接下来可以服务接口调用情况确定是全局接口异常或是单一接口异常。

4. 如果是全局接口异常说明服务提供方服务实例存在异常问题，找到对应的异常实例通过日志检索或JVM监控分析排查具体问题；如果是单一接口异常说明提供方接口逻辑处理，通过日志检索可排查具体问题。

5. 当然也可以在全局视图分析后通过对直接服务进行调用链分析排查单笔请求的调用链路，通过调用链与日志联动排查具体异常。

以上是本次TSF高可用结构设计及核心技术原理的全部分享。

— 本文结束 —

● 漫谈设计模式在 Spring 框架中的良好实践

● 颠覆微服务认知：深入思考微服务的七个主流观点

● 人人都是 API 设计者

● 一文讲透微服务下如何保证事务的一致性

● 要黑盒测试微服务内部服务间调用，我该如何实现？

在看点这里