分布式消息追踪
先推荐个文章,云栖的https://yq.aliyun.com/articles/91435,介绍了分布式调用链的一些场景和阿里的分布式调用链组件eagle,记得原来云栖有个视频介绍这个的,没找到。
随着分布式架构的发展,系统调用日趋复杂,一个业务场景可能涉及底层n多的服务调用,服务调用又涉及不同的组件:
1. 服务框架;
2. mq;
3. 缓存;
4. 数据库组件;
5. 大数据……
这时候就需要分布式消息跟踪系统。
业务场景分析
- 故障的快速定位,调用关系:A-B-C…..,如果没有消息跟踪,A调用出问题了,就只能通过日志分析,找B,B再找C,一级一级找下去,估计累死;
- 调用路径分析,分析调用路径关系,找出服务热点,易发故障点,评估风险,性能统计等;
- 调用来源和去向分析,分析依赖关系,各种kpi性能统计分析。
系统设计
每次业务请求生成全局唯一traceId,通过埋点将调用链各节点的日志串联,形成完整的日志调用关系链,日志的实时采集,汇总,分析,portal展示分析结果。
系统架构
- 调用链埋点日志生成;
- 分布式采集和存储埋点日志;
- 在线、离线计算,调用链数据分析和汇总;
- portal展示;
埋点日志
埋点的分类:
- 客户端埋点,调用时生成调用上下文,包括traceID,调用ip,调用方接口或业务名称,时间,被调用的服务名、方法名、ip地址和端口等信息;
- 服务端埋点,当前节点生成的上下文,包括被调用的服务,处理结果,时间等等信息;
埋点日志的实现,通常包含:
- 埋点规范,用于业务二次开发和第三方中间件/系统对接;
- 埋点日志类库,生成埋点上下文,打印埋点日志等;
- 中间件预置埋点功能,隔离业务代码,无需业务方代码侵入,也可以通过埋点日志类库,将业务字段带入调用链上下文;
日志生成规则:
埋点日志上下文包含:
- traceID, rpcID,调用开始时间,调用类型,协议类型,调用方ip端口,被调用方ip和端口,请求方接口,请求的服务等信息;
- 调用的耗时,结果,异常信息,报文信息等;
- 扩展信息;
traceID,全局唯一,除了uuid生成外,通常使用一些业务信息组装traceid,包含信息:
- ip地址和端口:调用发起方和被调用方ip,端口;
- 时间戳:埋点上下文的生成时间;
- 顺序号:标识链路传递序列的rpcID;
- 进程号;
- 随机数,一般会有递增的Atomic序列;
rpcID标识了日志埋点的顺序和嵌套关系:
埋点日志技术挑战:
- 异步调用,业务调用mq或其他组件,发生线程切换,通过上下文传递的埋点信息丢失,mq客户端认为自己是首节点,重新生成traceID,导致调用链串接不起来;
- 性能影响:频繁写日志,占用系统资源,导致正常的业务无法运行;
采样率
每次调用不一定需要全采样,支持动态设置采样率;采集和存储埋点日志
计算和展示,支持多维度的汇总分析;
调用链扩展,埋点日志支持扩展,主要是应用的相关信息组装到调用链中;
分布式消息跟踪,这东西可以做的很复杂,想想阿里单独做一个调用链组件就能明白这玩意可以做的多复杂,主要是涉及的系统,组件太多,加入埋点日志,还要做到不影响业务应用,设计起来细节太多。
可靠性设计
服务化后,分布式调用面临的故障风险更高:
1. 网络类故障:链路闪断,读写超时等;
2. 序列化反序列失败;
3. 畸形码流;
4. 流控和调用失败;
5. 其他异常….
服务状态监测
服务提供者不可用,如果没有发现,消费端继续路由到该机器,调用发生失败。为了保证路由的正确性,服务提供者不可用时,即使从本地缓存中清除,直到提供者恢复。
基于服务注册中心状态检测
链路有效性状态检测机制
通常消费端和提供者采用长连接,通过心跳保证链路的可靠性。存在一种场景,消费者和提供者与注册中心网络可达,但提供者和消费者之间不可达,所以就需要通过二者之间的心跳来维持链路可达。
服务健康度检测
集群环境,由于硬件和网络等原因,导致提供者的负载是不均衡的。利用健康度检测,可以对所有服务实例进行检查,评分,然后调整路由权重,平衡压力。
健康度检测需要采集性能kpi指标:
1. 调用时延;
2. QPS;
3. 成功率;
4. 基础资源的使用情况,cpu,内存等;
健康度评分通常由独立的监控节点负责,消费端和提供者将kpi数据上报监控节点,监控中心汇总分析后打分,然后下发消费端,由消费端做路由的权重调整。
服务故障隔离
进程级故障隔离
进程级隔离,在服务发生内存泄漏异常,导致整个进程不可用。VM级故障隔离
一台物理机部署几个虚机,虚机部署服务服务,物理机挂了服务还是不可用。物理机故障隔离
分布式集群部署,服务实例部署不同物理机。机房挂了,服务不可用。机房故障隔离
- 本地机房优先;
- 注册中心,服务订阅发布同步;
其他可靠性
服务注册中心
考虑zk的使用。监控中心
宕机,只影响采用数据和日志汇总,不影响服务调用。服务提供者
容错策略的配置,路由切换,本地调用或mock,服务放行。
微服务架构
这章题目太大,讲的不是很清楚,别看了,改天找资料再学习下,好像有个微服务框架实践的书,没看过,不知道怎么样。面试阿里的时候被问过微服务,当时有点懵逼,不知道从哪里下手回答。转载个文章,云栖肥侠的微服务(Microservice)那点事,https://yq.aliyun.com/articles/2764,当时看完留言咨询过微服务与rpc的区别,回复说是没区别,不知道是不是忽悠我,个人理解他说的没区别应该是说技术实现上区分不大,但是在服务的管理和运维等地方还是有区分的。不谈技术实现,微服务这个理念现在还是很流行的,出去聊天,不说2句微服务,都感觉你落伍了,艹。
- 微服务的“微”,强调的是专注于细,你的服务划分粒度要足够的小,达到微自治,自我管理;
- 技术实现通常基于http,rest方式开放;
- 容器的发展绝对大大促进了MSA的发展;
- 因为服务的粒度足够小,所以Devops
知乎的文章,回答的不错:SOA和微服务架构的区别 https://www.zhihu.com/question/37808426;
服务化最佳实践
性能和时延问题
- io调度模型的选择:阻塞还是非阻塞;
- 序列化框架的选择;
- 线程模型;
- io调度模型的选择:阻塞还是非阻塞;
分布式事务:这里写了些,不细,云栖搜沈询的视频看吧,讲的不错,深入浅出,容易理解;
团队协作:
- 共用注册中心:一般不会,肯定开发测试用不同的环境,容许屏蔽注册中心,直连服务提供者;
- 服务降级和mock测试:开发测试环境,提供者还未提供服务,可以做本地mock测试;
- 服务接口的兼容性:其实这里应该包含2部分,一个是框架本身对服务的支持,还有服务接口的不同版本间兼容性。
总结
- 这本书不错,值得多看几遍;
- 一定要找rpc的源码研究下,空谈误国,实干兴邦。