《企业IT架构转型之道》读书笔记（部分3）

7 服务治理：通过鹰眼平台跟踪服务调用链

业务服务化带来的问题：

分布式服务体系建设后，整个淘宝平台变成了一个复杂无比的服务交互链路网。这会带来很多问题，比如：

• 如何对每天发生的几千亿次服务调用出现报错时快速定位问题。
• 如何实时监控到服务的运行状态是否正常。
• 如何给运营团队关注的业务指标提供实施呈现以便他们进行实时的精准营销。

解决之道：

• 对于分布式服务调用跟踪方面的需要，阿里打造了针对分布式服务调用链的跟踪平台 - 鹰眼。它通过一套分布式日志平台实现对服务调用链路的跟踪，基于阿里巴巴海量日志分布式处理平台 TLog。
• 它是JStorm 流式计算引擎，对应用集群接收到的日志进行内容的解析拆分，按照不同业务场景的需求将拆分后的数据保存到不同的存储系统中。
• 其原理是通过服务调用链各服务处理节点生成相应的日志信息，通过同一请求中生成的日志具有同一个ID将不同系统或服务孤立的日志串在一起，重组还原出更多有价值的信息。

价值：

• 服务实时监控。通过在应用的不同层次进行埋点日志的打印，鹰眼平台可以实现从应用入口、服务层、服务方法层的精细管控。结合监控报警能力，鹰眼可以实现异常报警。
• 服务调用链跟踪：鹰眼可以帮助运维人员在Web界面上清晰还原出每一次业务请求所产生的服务链调用情况。该功能着重于对业务链路数据的实时监控。这既能帮助快速定位问题，还能对应用的优化分析带来帮助。正是有了调用链跟踪功能，阿里巴巴的服务化平台从一个无服务管控状态变成为一个具备真正可管可控的状态，形成了完善的服务化管控体系。
• 服务调用链分析。这是针对业务架构诉求的服务调用链分析功能，让业务架构师对于自己设计的业务链路在实际生产中的运行状况有一个直观的了解。该功能着重于对服务调用数据按照不同维度进行离线的统计和分析。利用分析出的数据，可以更针对性地优化业务链路流程，或提升某些服务的服务质量，给用户提供更好的用户体验。
• 业务全息排查：这本质上是将服务链路信息与业务事件进行了集成，将业务事件通过服务调用链的 traceID&rcpID 进行双向关联。
• 业务实时监控：将发生的业务指标变化在秒级就体现在业务大屏上。有了这样的业务实时大屏，给市场运营人员提供有价值的参考数据，真正对企业的运营提供了精准有效的数据支持。

8 服务治理：通过多种措施保证平台稳定性

1. 限流与降级：

• 阿里巴巴的 Sentinel 平台提供了限流和降级功能。它为整个服务化体系的稳定运行行使着警戒任务，是对资源调用的控制平台，主要涵盖了授权、限流、降级、调用统计监控四大功能模块。
• 限流：其作用在当过载的时候掐掉一些流量，让系统有能力集中资源以较快的速度处理平台处理范围内的业务请求。
• 首先需要采用压力测试的方法对系统进行压测。阿里巴巴开发了线上压测巩固，来获取该服务所能提供的最大处理能力。
• 然后对服务资源的使用情况进行监控。在实际中，都会通过服务的QPS作为限流的关键判断指标。
• 将资源监控的指标与之前获得的服务处理上线进行比较，如果超过服务处理上限，则启动限流。
• 阿里巴巴是通过在 Nginx 上实现的扩展组件 TMD 实现了接入层限流。
• 降级：判断依赖的资源的响应情况，当依赖的资源响应时间过长时进行自动降级，并在指定的时间后自动恢复调用。
• 监控：提供了全面的运行状态监控，实时监控资源的调用情况，包括QPS，响应时间，限流降级等信息。

流量调度：

• 目标：针对分布式服务系统的流量调度平台，用于屏蔽所有机器的软硬件差异，根据机器的实时服务能力来分配机器的实时流量。
• 原理：通过秒级获取服务器系统运行指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线等操作，以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影响。

业务开关：

• Switch 是一个轻量级的开关集成框架，用来集中管理集群各应用的开关，统一业务操作业务开关的方式和API，方便进行集中化管理。

  

容量压测及评估规划：

• 需求：要知道一个平台的处理能力是否能支持大促活动的访问量，最常见的方式是对平台进行性能测试。
• 容量压测：将线上真实的流量引流到压测目标服务器上，来获取单机QPS能力。
• 容量规划：利用服务的单机QPS数据，结合对各种服务器机型处理能力的差异化分析，对到底需要部署多少线上服务器资源才能满足大促活动有更准确的预测。

全链路压测：

• 这是阿里全系统每个环境都参与的双11实战演习，主要对零点峰值流量进行评估，以及网站承压能力进行测试。 业务一致性平台：
  • 平台还是偶尔会出现业务与数据不一致的问题。
  • 阿里巴巴利用BCP 平台来解决该问题。

  

9 服务治理：治理平台 - 共享服务平台

服务化野蛮发展带来的问题：

• 服务的数量和业务覆盖范围越来越大。
• 应用和业务架构越分越细，服务越来越专业化，跨领理解的成本越来越高。
• 服务安全控制层缺乏。
• 开发体验很不友好，产品在接入流程，开发使用手册建设非常之差。
• 整体服务体系缺乏一个统一的服务治理层。

上面这些问题，可归结为一个问题，服务治理。针对这些问题，集团的共享服务平台 SPAS 应运而生，其目标是对阿里巴巴集团的服务更好地进行治理和共享。

主要功能：

• 服务的描述元数据
• 服务注册与发现机制
• 服务的访问控制与安全策略
• 应用服务 portal
• 服务依赖与运维管理
• 服务SLA协议
• 服务消费者的管理与支持
• 服务化辅助工具支持
• 服务调用分析与报表
• 服务成本核算与服务能力变现
• 文档与开发工具支持

SPAS 也是一个协作的平台，是以服务为对象建立的一个在线市场。其中有三个角色：服务共享平台、服务提供者、服务消费者：

三个角色之间的协作方式：

示例：业务中台与前端应用协作：

• 业务中台对前端核心业务的紧密沟通机制。各个服务中心的核心架构师和运营人员会定期参与前端业务方的业务会议或重大项目的研讨会。这样，让业务中台对于前端重要应用的业务发展动向有一个准确及时的了解，从而为业务中台如何更好地支撑这些业务做好准备和服务能力的提升。
• 建立分歧升级机制：因为两方所处岗位和诉求的差别，有时难免对于讲一个业务功能的实现放到业务中台还是在前端应用中实现存在分歧。此时，一般按照业务负责的层级关系依次升级。
• 岗位轮动推动真正换位思考：将业务中台某服务中心的负责人与对口业务的负责人进行岗位对调，让双方在实际工作中更真切地感知到出于不同岗位时对业务的理解和出发点。
• 业务持续沉淀及共建模式：业务中台是一个不断沉淀，不断完善的过程。在进行业务沉淀到中台的过程中，又会出现两种情况：
  • 一种是业务中台现有的人员对于要沉淀的业务功能自身就有较强的业务能力，能够很好地完成将业务功能沉淀和融入到业务中台的能力，这是一种业务沉淀的典型方式。
  • 另一种则是对于要沉淀到业务中台的业务，业务中台现有人员没有足够的业务理解和能力，此时，就会采取共建的模式，业务中台和前端应用方各自派出人员共同组建一个团队，一起负责该业务功能的实现，以及到中台的能力沉淀。

业务中台的考核机制：

• 服务稳定是重中之重。40%。
• 业务创新推动业务发展。25%。
• 服务接入量是衡量服务价值的重要考核。20%。
• 客户满意度促动服务的提升。15%。