服务路由、容错、监控、跟踪与安全的核心功能与实现要点

[[服务发现的两种实现方式：自理式与代理式的风险取舍]]解决了”知道有哪些可用节点”，服务路由解决的是”这次调用具体挑哪个节点”——路由和发现关系紧密，通常不会独立成一个系统，而是内嵌在发现系统里实现：自理式下路由逻辑在微服务内部实现，代理式下路由逻辑在负载均衡系统里实现；不管放在哪里，核心都是路由算法，常见的有随机路由、轮询路由、最小压力路由、最小连接数路由。服务容错针对的是微服务架构特有的”故障扩散”问题：拆成微服务后单个节点故障的概率变小、影响范围也变小，但节点总数大大增加，从整体看某个微服务出故障的概率反而变大，如果不及时处理，故障会沿调用链扩散、看起来像很多服务同时出了问题；靠人工逐个处理既投入大又速度慢，处理速度一慢故障扩散得更快，所以必须要有自动容错能力，常见手段包括请求重试、流控、服务隔离，通常也是集成在服务发现和服务路由系统里实现。服务监控解决的是”节点数量暴增后，靠人力监控和排障已经不现实”这个问题——需要监控的机器、网络、进程、接口调用数量都随节点数暴增，用户投诉后如果靠人工去几十个节点上翻日志，光是打开这些日志就要十几分钟；服务监控系统要做的是实时采集分析信息（避免故障后才临时分析、缩短处理时间）并在此基础上做预警（在问题萌芽阶段就发现，缩小影响范围和时长）；因为需要采集处理大量数据，建议做成独立系统，不要塞进服务发现、API网关这类系统里。服务跟踪和服务监控的区别是宏观和微观：监控记录的是聚合统计信息（比如A服务请求B服务10次，B返回JSON，监控记录的是请求次数、平均/最高响应时间、错误码分布这类汇总数据），跟踪记录的是单次请求的完整链路细节（某一次请求的发起时间、响应时间、错误码、请求参数、返回内容等），目前业界绝大多数分布式跟踪和微服务跟踪的实现都基于Google的Dapper论文。服务安全解决的是”微服务之间技术上互联互通，但业务上敏感数据/操作只该部分服务能访问”这个矛盾，主要分接入安全、数据安全、传输安全三部分；通常集成在配置中心里实现——配置中心统一配置各微服务的接入安全策略和数据安全策略，微服务节点从配置中心拉取这些策略、处理具体调用请求时按策略执行，由于策略逻辑是通用的，一般也会封装成公共库供各微服务调用。

结构图：

flowchart TB
  A["服务路由/容错/监控/跟踪/安全"]
  A --> B["服务路由：挑选具体节点<br/>常与服务发现同处实现<br/>算法：随机/轮询/最小压力/最小连接数"]
  A --> C["服务容错：应对故障扩散<br/>请求重试/流控/服务隔离<br/>常集成在发现+路由系统中"]
  A --> D["服务监控：宏观聚合统计<br/>实时采集+预警，建议独立系统"]
  A --> E["服务跟踪：微观单次请求全链路<br/>基于Google Dapper论文技术路线"]
  A --> F["服务安全：接入/数据/传输三部分<br/>通常集成到配置中心统一下发策略"]