大家好，我是刘艳，腾讯微服务平台TSF产品经理，目前主要负责TSF高可用能力建设和演进规划。对架构的理解和TSF构建高可用能力的最佳实践，将和大家一起探讨如何构建高可用的微服务架构。微服务架构挑战软件架构的演进首先我们来看软件架构的演进：单体架构：没有复杂的逻辑分层，前后台代码耦合，单个应用可能关联多个数据库适用于：迭代频率低，对于并发量小、业务逻辑简单的应用场景，单体架构在政府、金融、工业等领域的应用依然广泛。SOA架构：按照业务逻辑进行服务拆分，通过服务总线进行服务管理和服务之间的流量转发。主要问题是服务总线成为系统新的瓶颈，难以满足业务不断发展线性扩展的要求。微服务架构：服务架构通过服务注册中心实现服务注册和发现。当服务启动时，服务实例被注册到注册中心。呼叫者在发起呼叫时使用注册中心对服务进行寻址，并直接与提供者通信。理论上，服务可以随着业务的发展线性扩展，不同的服务可以独立迭代，实现敏捷开发。服务网格：随着版本云原生k8s和容器技术的发展，服务网格技术已经趋于成熟。与传统微服务架构相比，服务网格采用sidercar模式进行流量代理和服务注册发现，不需要业务感知，容易实现跨语言服务治理，帮助业务快速迁移，让业务应用更专注于自己自己的业务逻辑实现。每个软件架构都没有严格的好坏之分，用户需要根据自己的业务特点来选择架构。微服务应用常见问题微服务架构在满足高并发和敏捷迭代的同时，业务模块数量呈几何级数增长，对应用运维提出严峻挑战。与传统的单体架构相比，微服务架构具有流量高峰增长快、模块依赖复杂、故障定位难、故障恢复耗时等特点。流量激增：单体应用拆分成微服务应用后，原来单一的请求逻辑拆分成多个微服务应用的组合业务逻辑，接口调用量呈1:N增长。电话激增。复杂的模块依赖：原来的单体应用只有业务逻辑在单个进程中的组合，而微服务应用被拆分成多个进程。连锁反应，导致服务雪崩。故障定位难：针对单个请求异常，需要根据各个模块的依赖关系分析整个调用链路，定位故障原因。由于跨多个微服务应用进程的业务逻辑不同，故障定位的难度急剧增加。故障恢复时间长：由于各个微服务模块的依赖关系复杂，需要根据调用链准确定位故障问题的根源，并进行分步恢复。从故障中恢复和验证恢复后的评估结果需要很长时间。如何衡量系统可用性指标管理大师彼得·德鲁克曾说过“IfyouCan'tmeasureit,youcan'tmanageit”（“Ityoucan’tmeasureit,youcan'tmanageit”）。要有效管理，很难绕过衡量问题。那么如何衡量分布式系统的可用性指标，这里有一个简单的公式，可用性=平均无故障时间/平均无故障时间与平均故障恢复时间之和。所谓平均无故障时间是指相邻两次故障之间的平均工作时间，又称平均无故障时间。平均修复时间是故障和修复之间的时间。较短的MTTR表示更好的可恢复性。MTBF：MeanTimeBetweenFailures，英文全称“MeanTimeBetweenFailure”。是衡量一个产品（尤其是电器产品）可靠性的指标。单位是“小时”。MTTR：全称是MeanTimeToRepair，即平均修复时间。指可修复产品的平均修复时间，即从故障到修复的时间。较短的MTTR表示更好的可恢复性。如何设计高可用的微服务架构？下面我将从道、法、技三个层面来谈谈微服务高可用架构设计的基本原则、架构设计原则以及高可用架构的常用解决方案。Dao:FromCAPtoBASECAP理论：在分布式系统中，一致性（C：Consistency），可用性（A：Availability）和分区容错性（P：PartitionTolerance）只能同时满足其中两个。其中，分区容忍度（P：PartitionTolerance）是复杂网络环境中必不可少的要素，因此分布式系统的架构设计需要在一致性和可用性之间进行权衡。Paxos算法、Raft算法、强一致性共识算法、2阶段提交、3阶段提交最终共识算法等共识算法诞生。BASE理论：BASE是CAP中一致性和可用性平衡的结果。其理论的核心思想是：即使无法实现强一致性，各个应用也可以根据自己的业务特点，采用合适的方法来制作系统。实现最终一致性。方法：微服务高可用架构设计原则结合本人对微服务高可用架构的理解，总结出以下6条高可用架构设计原则，分别是服务无状态、异步解耦、分区容错、故障隔离、快速恢复,最终一致性：无状态服务：服务应用的无状态设计，通过缓存和数据库集中存储服务应用的状态数据，通过nginx或网关进行负载均衡，实现横向扩展。异步解耦：各服务模块通过发布-订阅和事件驱动方式异步解耦，通过异步回调方式快速响应单个请求调用，将通知事件与处理结果分离，避免异常雪崩。分区容错：根据指定的业务规则实现业务分流路由，将流量分发到多个可用区，通过不同可用区的数据同步和多重备份机制保证数据的一致性。故障隔离：单个进程、单个接口、单个服务通过熔断和降级机制实现故障隔离，避免系统相关异常造成雪崩效应。快速恢复：通过流量切分、版本管理、应用回滚机制，快速将应用回滚到健康版本，快速恢复应用。最终一致性：通过多数据源双写、数据审计、数据修复，实现跨可用区数据的最终一致性。技术：高可用常用手段分区容错：异地容灾是高可用架构的典型应用场景。通过在不同区域的数据中心建设多套应用服务，当单个区域服务宕机时，可以通过流量保护快速切换到灾备中心，业务持续稳定。异地容灾根据保障等级的不同分为五个等级：多可用区、同城冷备、同城双活、异地冷备、两地三中心，其保障等级、应用成本，恢复延迟均呈现增加趋势。异步解耦：在微服务应用中，消息中间件的引入将上游复合服务的同步调用异步解耦到下游多个微服务，消息可靠的传递能力可以快速响应用户请求，可以大大提高服务的并发访问性能和用户体验，通过数据补偿保证数据的最终一致性。服务限流：由于API接口无法控制调用者的行为，当遇到请求突然激增时，会导致该接口过多占用服务器资源，降低其他请求的响应速度或超时，严重的会造成服务器停机。服务限流主要是为了保护服务节点或数据节点，防止服务和数据因瞬时流量过大而崩溃，导致服务不可用。局部限流：基于简单的计数、令牌桶、漏斗算法，在单个节点限流，可以只限制进入本节点的请求，不引入中间件，通过局部限流达到全局限流的目的，同时避免Instance级单接口访问激增问题全局限流：基于简单的计数和令牌桶算法，通过引入redis等中间件，全局控制整个集群的流量。服务断路器：服务断路器是处理服务异常、实现服务容错、避免服务雪崩的有效手段。从下图可以看出，当网关ingress服务请求多个下游服务接口时，当服务C接口异常时，会导致ingress服务流量不可用，服务A和服务E请求就白占了。从下图可以看出，当网关入口的服务向下游请求单个服务接口时，当服务B接口异常时，入口请求会被阻塞，占用网关请求资源，导致整体业务不正常。针对以上两种异常场景，通过在调用服务时配置熔断策略，可以快速失效，直接反馈上游业务的异常结果，避免请求线程崩溃和服务雪崩。降级容错：服务降级是在服务器压力急剧增加的情况下，根据当前业务情况，利用有限的资源，关闭某些服务接口或页面，以释放服务器资源，保证核心服务的正常运行。TSF高可用最佳实践TSF微服务平台针对业务流量激增、服务异常等问题，提供架构容灾、灰度发布、服务容错、实例优雅启停、应用性能管理等一体化高可用服务架构容错。突出立体化、自动化、可视化优势，提供端到端的应用性能监控，运营监控数据聚合分析多维度可视化，实现故障业务的自动检测、自动处理、快速恢复，保障系统稳定高效运行。单元化架构部署单元化架构是一种先进的高可用性架构设计模式。通过对核心业务数据的分片，应用服务的无状态设计，将同一领域内的业务服务划分为单独的部署单元，整体业务在单元内闭环。单元化部署架构，有效满足弹性伸缩、故障隔离、异地容灾等高可用建设需求。另外，在单元化部署的基础上，可以构建基于部署单元的灵活发布策略。单元化架构产品能力：网关业务单元路由标签支持跨单元水平调用单元服务，容错，弹性伸缩。通过配置动态伸缩规则，TSF中控服务可以根据代理上报的监控数据实现实时统计，应对流量激增。自动扩容或流量低峰自动缩容能力，有效保障服务高效稳定，提高资源利用率。全链路灰度发布灰度发布是将具有一定特征或比例的流量分配给需要验证的版本，以观察新验证版本的上线运行情况。与全量发布相比，灰度发布是一种更为谨慎的发布形式。当在线调用环节复杂时，全链路灰度发布可以将每一个在线服务隔离成一个单独的运行环境。全链路灰度产品能力：基于业务级别的全链路灰度发布能力支持按服务级别请求参数分配流量通道间流量隔离优雅启停在应用的滚动发布过程中，可以进行滚动发布通过调整部署组更新策略实现离线优雅服务，减少发布过程中业务中断的影响。这里简单介绍一下优雅下线的简单流程。离线实例在注册中心注销，注销该实例的注册信息。注册中心节点的订阅更新周期为15s。调用者感知到注册中心实例的变化后，更新本地缓存服务地址。流量不再路由到离线实例，保证期间业务不中断；离线实例在执行实际离线操作之前等待30秒（2个心跳周期）；优雅启停产品能力：支持容器和虚拟机部署实例注销离线事件详情实例启动就绪检测服务限流TSF限流是基于监控服务流量的QPS指标。当达到指定的阈值时，进行流量控制，避免被瞬时峰值流量淹没，从而保证服务的高可用性。支持在网关配置全局限流策略，保证入口业务流量稳定支持为单个服务配置本地限流策略，保证当前业务流量稳定，同时提供限流规则的灵活配置和动态验证，提供可视化限流运行及监控数据显示。服务熔断TSF服务熔断能力支持服务、实例、API多维度熔断隔离级别，提供控制台可视化配置和熔断事件展示，满足熔断热效配置需求。熔断器状态转换：熔断器一开始处于关闭状态，一旦检测到错误（或响应慢）达到一定阈值，就会转为打开状态，此时不会调用下游目标服务。一段时间后，会转为半开状态，并尝试向下游服务释放一些请求。一旦检测到响应成功，则返回关闭状态，即恢复服务；否则返回打开状态。健康检查与登记中心联动流程健康检查分为生存检查和就绪检查；生存检查的主要作用是判断进程的生存状态，判断是否重启实例。就绪检查的主要作用是判断服务实例是否可以支持对外服务，并将健康检查结果与注册中心状态挂钩，避免流量访问异常节点。健康检查与注册中心联动流程1.就绪检查，检查实例状态是否就绪2.如果就绪检查就绪，更新实例注册状态为passing，否则检查状态为circical3.监控注册服务商实例状态变化4.存在状态缓存和本地文件变化更新5.发起服务调用健康检查产品能力：生存检查就绪检查多种检测方式：http、tcp、执行命令支持虚拟机&容器部署应用性能管理能力最后，我们将从一个故障处理流程来展示全局展示tsf应用性能管理能力：用户接收监控平台发送的告警信息，判断基本异常信息。通过服务依赖拓扑确定异常服务的上下游依赖关系，并进行全局视图分析。接下来可以根据服务接口调用情况判断是全局接口异常还是单个接口异常。如果是全局接口异常，说明服务提供者的服务实例存在异常问题。通过日志检索或JVM监控分析，找到对应的异常实例并排查具体问题；如果是单个接口异常，说明provider接口逻辑处理不当，可以通过日志检索来排查具体问题。.当然，在全局视图分析之后，还可以分析直接服务的调用链，查看单个请求的调用链接，通过调用链和日志的联动查看具体的异常。
