企业官网建设流程全解析

莱芜市城乡建设局网站,铁岭网站建设网络优化,wordpress 更换语言包,东莞网站制作模板可观测性作为系统高可用的重要保障#xff0c;已经成为系统建设中不可或缺的一环。然而随着业务逻辑的日益复杂#xff0c;传统的ELK方案在日志搜集、筛选和分析等方面愈加耗时耗力#xff0c;而分布式会话跟踪方案虽然基于追踪能力完善了日志的串联#xff0c;但更聚焦于调…可观测性作为系统高可用的重要保障已经成为系统建设中不可或缺的一环。然而随着业务逻辑的日益复杂传统的ELK方案在日志搜集、筛选和分析等方面愈加耗时耗力而分布式会话跟踪方案虽然基于追踪能力完善了日志的串联但更聚焦于调用链路也难以直接应用于高效的业务追踪。本文介绍了可视化全链路日志追踪的新方案它以业务链路为载体通过有效组织业务每次执行的日志实现了执行现场的可视化还原支持问题的高效定位。1. 背景1.1 业务系统日益复杂1.2 业务追踪面临挑战2. 可视化全链路日志追踪2.1 设计思路2.2 通用方案3. 大众点评内容平台实践3.1 业务特点与挑战3.2 实践与成果4. 总结与展望1. 背景1.1 业务系统日益复杂随着互联网产品的快速发展不断变化的商业环境和用户诉求带来了纷繁复杂的业务需求。业务系统需要支撑的业务场景越来越广、涵盖的业务逻辑越来越多系统的复杂度也跟着快速提升。与此同时由于微服务架构的演进业务逻辑的实现往往需要依赖多个服务间的共同协作。总而言之业务系统的日益复杂已经成为一种常态。1.2 业务追踪面临挑战业务系统往往面临着多样的日常客诉和突发问题“业务追踪”就成为了关键的应对手段。业务追踪可以看做一次业务执行的现场还原过程通过执行中的各种记录还原出原始现场可用于业务逻辑执行情况的分析和问题的定位是整个系统建设中重要的一环。目前在分布式场景下业务追踪的主流实现方式包括两类一类是基于日志的ELK方案一类是基于单次请求调用的会话跟踪方案。然而随着业务逻辑的日益复杂上述方案越来越不适用于当下的业务系统。1.2.1 传统的ELK方案日志作为业务系统的必备能力职责就是记录程序运行期间发生的离散事件并且在事后阶段用于程序的行为分析比如曾经调用过什么方法、操作过哪些数据等等。在分布式系统中ELK技术栈已经成为日志收集和分析的通用解决方案。如下图1所示伴随着业务逻辑的执行业务日志会被打印统一收集并存储至Elasticsearch下称ES[2]。图1 业务系统ELK案例传统的ELK方案需要开发者在编写代码时尽可能全地打印日志再通过关键字段从ES中搜集筛选出与业务逻辑相关的日志数据进而拼凑出业务执行的现场信息。然而该方案存在如下的痛点日志搜集繁琐虽然ES提供了日志检索的能力但是日志数据往往是缺乏结构性的文本段很难快速完整地搜集到全部相关的日志。日志筛选困难不同业务场景、业务逻辑之间存在重叠重叠逻辑打印的业务日志可能相互干扰难以从中筛选出正确的关联日志。日志分析耗时搜集到的日志只是一条条离散的数据只能阅读代码再结合逻辑由人工对日志进行串联分析尽可能地还原出现场。综上所述随着业务逻辑和系统复杂度的攀升传统的ELK方案在日志搜集、日志筛选和日志分析方面愈加的耗时耗力很难快速实现对业务的追踪。1.2.2 分布式会话跟踪方案在分布式系统尤其是微服务系统中业务场景的某次请求往往需要经过多个服务、多个中间件、多台机器的复杂链路处理才能完成。为了解决复杂链路排查困难的问题“分布式会话跟踪方案”诞生。该方案的理论知识由Google在2010年《Dapper》论文[3]中发表随后Twitter开发出了一个开源版本Zipkin[4]。市面上的同类型框架几乎都是以Google Dapper论文为基础进行实现整体大同小异都是通过一个分布式全局唯一的id即traceId将分布在各个服务节点上的同一次请求串联起来还原调用关系、追踪系统问题、分析调用数据、统计系统指标。分布式会话跟踪是一种会话级别的追踪能力如下图2所示单个分布式请求被还原成一条调用链路从客户端发起请求抵达系统的边界开始记录请求流经的每一个服务直到向客户端返回响应为止。图2 一次典型的请求全过程摘自《Dapper》分布式会话跟踪的主要作用是分析分布式系统的调用行为并不能很好地应用于业务逻辑的追踪。下图3是一个审核业务场景的追踪案例业务系统对外提供审核能力待审对象的审核需要经过“初审”和“复审”两个环节两个环节关联相同的taskId因此整个审核环节的执行调用了两次审核接口。如图左侧所示完整的审核场景涉及众多“业务逻辑”的执行而分布式会话跟踪只是根据两次RPC调用生成了右侧的两条调用链路并没有办法准确地描述审核场景业务逻辑的执行问题主要体现在以下几个方面图3 分布式会话跟踪案例(1) 无法同时追踪多条调用链路分布式会话跟踪仅支持单个请求的调用追踪当业务场景包含了多个调用时将生成多条调用链路由于调用链路通过traceId串联不同链路之间相互独立因此给完整的业务追踪增加了难度。例如当排查审核场景的业务问题时由于初审和复审是不同的RPC请求所以无法直接同时获取到2条调用链路通常需要额外存储2个traceId的映射关系。(2) 无法准确描述业务逻辑的全景分布式会话跟踪生成的调用链路只包含单次请求的实际调用情况部分未执行的调用以及本地逻辑无法体现在链路中导致无法准确描述业务逻辑的全景。例如同样是审核接口初审链路1包含了服务b的调用而复审链路2却并没有包含这是因为审核场景中存在“判断逻辑”而该逻辑无法体现在调用链路中还是需要人工结合代码进行分析。(3) 无法聚焦于当前业务系统的逻辑执行分布式会话跟踪覆盖了单个请求流经的所有服务、组件、机器等等不仅包含当前业务系统还涉及了众多的下游服务当接口内部逻辑复杂时调用链路的深度和复杂度都会明显增加而业务追踪其实仅需要聚焦于当前业务系统的逻辑执行情况。例如审核场景生成的调用链路就涉及了众多下游服务的内部调用情况反而给当前业务系统的问题排查增加了复杂度。1.2.3 总结传统的ELK方案是一种滞后的业务追踪需要事后从大量离散的日志中搜集和筛选出需要的日志并人工进行日志的串联分析其过程必然耗时耗力。而分布式会话跟踪方案则是在调用执行的同时实时地完成了链路的动态串联但由于是会话级别且仅关注于调用关系等问题导致其无法很好地应用于业务追踪。因此无论是传统的ELK方案还是分布式会话跟踪方案都难以满足日益复杂的业务追踪需求。本文希望能够实现聚焦于业务逻辑追踪的高效解决方案将业务执行的日志以业务链路为载体进行高效组织和串联并支持业务执行现场的还原和可视化查看从而提升定位问题的效率即可视化全链路日志追踪。下文将介绍可视化全链路日志追踪的设计思路和通用方案同时介绍新方案在大众点评内容平台的落地情况旨在帮助有类似需求的业务系统开发需求的同学提供一些思路。2. 可视化全链路日志追踪2.1 设计思路可视化全链路日志追踪考虑在前置阶段即业务执行的同时实现业务日志的高效组织和动态串联如下图4所示此时离散的日志数据将会根据业务逻辑进行组织绘制出执行现场从而可以实现高效的业务追踪。图4 业务系统日志追踪案例新方案需要回答两个关键问题如何高效组织业务日志以及如何动态串联业务日志。下文将逐一进行回答。问题1如何高效组织业务日志为了实现高效的业务追踪首先需要准确完整地描述出业务逻辑形成业务逻辑的全景图而业务追踪其实就是通过执行时的日志数据在全景图中还原出业务执行的现场。新方案对业务逻辑进行了抽象定义出业务逻辑链路下面还是以“审核业务场景”为例来说明业务逻辑链路的抽象过程逻辑节点业务系统的众多逻辑可以按照业务功能进行拆分形成一个个相互独立的业务逻辑单元即逻辑节点可以是本地方法如下图5的“判断逻辑”节点也可以是RPC等远程调用方法如下图5的“逻辑A”节点。逻辑链路业务系统对外支撑着众多的业务场景每个业务场景对应一个完整的业务流程可以抽象为由逻辑节点组合而成的逻辑链路如下图5中的逻辑链路就准确完整地描述了“审核业务场景”。一次业务追踪就是逻辑链路的某一次执行情况的还原逻辑链路完整准确地描述了业务逻辑全景同时作为载体可以实现业务日志的高效组织。图5 业务逻辑链路案例问题2如何动态串联业务日志业务逻辑执行时的日志数据原本是离散存储的而此时需要实现的是随着业务逻辑的执行动态串联各个逻辑节点的日志进而还原出完整的业务逻辑执行现场。由于逻辑节点之间、逻辑节点内部往往通过MQ或者RPC等进行交互新方案可以采用分布式会话跟踪提供的分布式参数透传能力[5]实现业务日志的动态串联通过在执行线程和网络通信中持续地透传参数实现在业务逻辑执行的同时不中断地传递链路和节点的标识实现离散日志的染色。基于标识染色的离散日志会被动态串联至正在执行的节点逐渐汇聚出完整的逻辑链路最终实现业务执行现场的高效组织和可视化展示。与分布式会话跟踪方案不同的是当同时串联多次分布式调用时新方案需要结合业务逻辑选取一个公共id作为标识例如图5的审核场景涉及2次RPC调用为了保证2次执行被串联至同一条逻辑链路此时结合审核业务场景选择初审和复审相同的“任务id”作为标识完整地实现审核场景的逻辑链路串联和执行现场还原。2.2 通用方案明确日志的高效组织和动态串联这两个基本问题后本文选取图4业务系统中的“逻辑链路1”进行通用方案的详细说明方案可以拆解为以下步骤图6 通用方案拆解2.2.1 链路定义“链路定义”的含义为使用特定语言静态描述完整的逻辑链路链路通常由多个逻辑节点按照一定的业务规则组合而成业务规则即各个逻辑节点之间存在的执行关系包括串行、并行、条件分支。DSLDomain Specific Language是为了解决某一类任务而专门设计的计算机语言可以通过JSON或XML定义出一系列节点逻辑节点的组合关系业务规则。因此本方案选择使用DSL描述逻辑链路实现逻辑链路从抽象定义到具体实现。图7 链路的抽象定义和具体实现 逻辑链路1-DSL[{nodeName: A,nodeType: rpc},{nodeName: Fork,nodeType: fork,forkNodes: [[{nodeName: B,nodeType: rpc}],[{nodeName: C,nodeType: local}]]},{nodeName: Join,nodeType: join,joinOnList: [B,C]},{nodeName: D,nodeType: decision,decisionCases: {true: [{nodeName: E,nodeType: rpc}]},defaultCase: [{nodeName: F,nodeType: rpc}]}]2.2.2 链路染色“链路染色”的含义为在链路执行过程中通过透传串联标识明确具体是哪条链路在执行执行到了哪个节点。链路染色包括两个步骤步骤一确定串联标识当逻辑链路开启时确定唯一标识能够明确后续待执行的链路和节点。链路唯一标识 业务标识 场景标识 执行标识 三个标识共同决定“某个业务场景下的某次执行”业务标识赋予链路业务含义例如“用户id”、“活动id”等等。场景标识赋予链路场景含义例如当前场景是“逻辑链路1”。执行标识赋予链路执行含义例如只涉及单次调用时可以直接选择“traceId”涉及多次调用时则根据业务逻辑选取多次调用相同的“公共id”。节点唯一标识 链路唯一标识 节点名称 两个标识共同决定“某个业务场景下的某次执行中的某个逻辑节点”节点名称DSL中预设的节点唯一名称如“A”。步骤二传递串联标识当逻辑链路执行时在分布式的完整链路中透传串联标识动态串联链路中已执行的节点实现链路的染色。例如在“逻辑链路1”中当“A”节点触发执行则开始在后续链路和节点中传递串联标识随着业务流程的执行逐步完成整个链路的染色。当标识传递至“E”节点时则表示“D”条件分支的判断结果是“true”同时动态地将“E”节点串联至已执行的链路中。2.2.3 链路上报“链路上报”的含义为在链路执行过程中将日志以链路的组织形式进行上报实现业务现场的准确保存。图8 链路上报图示如上图8所示上报的日志数据包括节点日志和业务日志。其中节点日志的作用是绘制链路中的已执行节点记录了节点的开始、结束、输入、输出业务日志的作用是展示链路节点具体业务逻辑的执行情况记录了任何对业务逻辑起到解释作用的数据包括与上下游交互的入参出参、复杂逻辑的中间变量、逻辑执行抛出的异常。2.2.4 链路存储“链路存储”的含义为将链路执行中上报的日志落地存储并用于后续的“现场还原”。上报日志可以拆分为链路日志、节点日志和业务日志三类链路日志链路单次执行中从开始节点和结束节点的日志中提取的链路基本信息包含链路类型、链路元信息、链路开始/结束时间等。节点日志链路单次执行中已执行节点的基本信息包含节点名称、节点状态、节点开始/结束时间等。业务日志链路单次执行中已执行节点中的业务日志信息包含日志级别、日志时间、日志数据等。下图就是链路存储的存储模型包含了链路日志节点日志业务日志、链路元数据配置数据并且是如下图9所示的树状结构其中业务标识作为根节点用于后续的链路查询。图9 链路的树状存储结构3. 大众点评内容平台实践3.1 业务特点与挑战互联网时代内容为王。内容型平台的核心打法就是搭建内容流水线保障内容可持续、健康且有价值地流转到内容消费者并最终形成内容“生产→治理→消费→生产”的良性循环。大众点评和美团App拥有丰富多样的内容站内外业务方、合作方有着众多的消费场景。对于内容流水线中的三方分别有如下需求内容的生产方希望生产的内容能在更多的渠道分发收获更多的流量被消费者所喜爱。内容的治理方希望作为“防火墙”过滤出合法合规的内容同时整合机器和人工能力丰富内容属性。内容的消费方希望获得满足其个性化需求的内容能够吸引其种草或辅助其做出消费决策。生产方的内容模型各异、所需处理手段各不相同消费方对于内容也有着个性化的要求。如果由各个生产方和消费方单独对接内容模型异构、处理流程和输出门槛各异的问题将带来对接的高成本和低效率。在此背景下点评内容平台应运而生作为内容流水线的“治理方”承上启下实现了内容的统一接入、统一处理和统一输出图10 点评内容平台业务形态统一接入统一内容数据模型对接不同的内容生产方将异构的内容转化为内容平台通用的数据模型。统一处理统一处理能力建设积累并完善通用的机器处理和人工运营能力保证内容合法合规属性丰富。统一输出统一输出门槛建设对接不同的内容消费方为下游提供规范且满足其个性化需求的内容数据。如下图11所示是点评内容平台的核心业务流程每一条内容都会经过这个流程最终决定在各个渠道下是否分发。图11 点评内容平台业务流程内容是否及时、准确经过内容平台的处理是内容生产方和消费方的核心关注也是日常值班的主要客诉类型。而内容平台的业务追踪建设主要面临以下的困难与复杂性业务场景多业务流程涉及多个不同的业务场景且逻辑各异例如实时接入、人工运营、分发重算等图中列出的部分场景。逻辑节点多业务场景涉及众多的逻辑节点且不同内容类型节点各异例如同样是实时接入场景笔记内容和直播内容在执行的逻辑节点上存在较大差异。触发执行多业务场景会被多次触发执行且由于来源不同逻辑也会存在差异例如笔记内容被作者编辑、被系统审核等等后都会触发实时接入场景的重新执行。点评内容平台日均处理百万条内容涉及百万次业务场景的执行、高达亿级的逻辑节点的执行而业务日志分散在不同的应用中并且不同内容不同场景不同节点以及多次执行的日志混杂在一起无论是日志的搜集还是现场的还原都相当繁琐耗时传统的业务追踪方案越来越不适用于内容平台。点评内容平台亟需新的解决方案实现高效的业务追踪因此我们进行了可视化全链路日志追踪的建设下面本文将介绍一下相关的实践和成果。3.2 实践与成果3.2.1 实践点评内容平台是一个复杂的业务系统对外支撑着众多的业务场景通过对于业务场景的梳理和抽象可以定义出实时接入、人工运营、任务导入、分发重算等多个业务逻辑链路。由于点评内容平台涉及众多的内部服务和下游依赖服务每天支撑着大量的内容处理业务伴随着业务的执行将生成大量的日志数据与此同时链路上报还需要对众多的服务进行改造。因此在通用的全链路日志追踪方案的基础上点评内容平台进行了如下的具体实践。(1) 支持大数据量日志的上报和存储点评内容平台实现了图12所示的日志上报架构支持众多服务统一的日志收集、处理和存储能够很好地支撑大数据量下的日志追踪建设。图12 点评内容平台日志上报架构日志收集各应用服务通过机器上部署的log_agent收集异步上报的日志数据并统一传输至Kafka通道中此外针对少量不支持log_agent的服务搭建了如图所示的中转应用。日志解析收集的日志通过Kafka接入到Flink中统一进行解析和处理根据日志类型对日志进行分类和聚合解析为链路日志、节点日志和业务日志。日志存储完成日志解析后日志会按照树状的存储模型进行落地存储结合存储的需求分析以及各个存储选项的特点点评内容平台最终选择HBase作为存储选型。整体而言log_agent Kafka Flink HBase的日志上报和存储架构能够很好地支持复杂的业务系统天然支持分布式场景下众多应用的日志上报同时适用于高流量的数据写入。(2) 实现众多后端服务的低成本改造点评内容平台实现了“自定义日志工具包”即下图13的TraceLogger工具包屏蔽链路追踪中的上报细节实现众多服务改造的成本最小化。TraceLogger工具包的功能包括模仿slf4j-api工具包的实现在slf4j框架之上并模仿slf4j-api对外提供相同的API因此使用方无学习成本。屏蔽内部细节内部封装一系列的链路日志上报逻辑屏蔽染色等细节降低使用方的开发成本。上报判断判断链路标识无标识时进行兜底的日志上报防止日志丢失。判断上报方式有标识时支持日志和RPC中转两种上报方式。日志组装实现参数占位、异常堆栈输出等功能并将相关数据组装为Trace对象便于进行统一的收集和处理。异常上报通过ErrorAPI主动上报异常兼容原日志上报中ErrorAppender。日志上报适配Log4j2日志框架实现最终的日志上报。图13 TraceLogger日志工具包下面是TraceLogger工具包分别进行业务日志和节点日志上报的使用案例整体的改造成本较低。业务日志上报无学习成本基本无改造成本。案例业务日志上报// 替换前原日志上报LOGGER.error(update struct failed, param:{}, GsonUtils.toJson(structRequest), e);// 替换后全链路日志上报TraceLogger.error(update struct failed, param:{}, GsonUtils.toJson(structRequest), e);节点日志上报支持API、AOP两种上报方式灵活且成本低。案例节点日志上报public Response realTimeInputLink(long contentId) {// 链路开始传递串联标识业务标识 场景标识 执行标识TraceUtils.passLinkMark(contentId_type_uuid);// ...// 本地调用(API上报节点日志)TraceUtils.reportNode(contentStore, contentId, StatusEnums.RUNNING)contentStore(contentId);TraceUtils.reportNode(contentStore, structResp, StatusEnums.COMPLETED)// ...// 远程调用Response processResp picProcess(contentId);// ...}// AOP上报节点日志TraceNode(nodeNamepicProcess)public Response picProcess(long contentId) {// 图片处理业务逻辑// 业务日志数据上报TraceLogger.warn(picProcess failed, contentId:{}, contentId);}3.2.2 成果基于上述实践点评内容平台实现了可视化全链路日志追踪能够一键追踪任意一条内容所有业务场景的执行并通过可视化的链路进行执行现场的还原追踪效果如下图所示【链路查询功能】根据内容id实时查询该内容所有的逻辑链路执行覆盖所有的业务场景。图14 链路查询【链路展示功能】通过链路图可视化展示业务逻辑的全景同时展示各个节点的执行情况。图15 链路展示【节点详情查询功能】支持展示任意已执行节点的详情包括节点输入、输出以及节点执行过程中的关键业务日志。图16 节点详情目前可视化全链路日志追踪系统已经成为点评内容平台的“问题排查工具”我们可以将问题排查耗时从小时级降低到5分钟内同时也是“测试辅助工具”利用可视化的日志串联和展示明显提升了RD自测、QA测试的效率。最后总结一下可视化全链路日志追踪的优点接入成本低DSL配置配合简单的日志上报改造即可快速接入。追踪范围广任意一条内容的所有逻辑链路均可被追踪。使用效率高管理后台支持链路和日志的可视化查询展示简单快捷。4. 总结与展望随着分布式业务系统的日益复杂可观测性对于业务系统的稳定运行也愈发重要[6]。作为大众点评内容流水线中的复杂业务系统为了保障内容流转的稳定可靠点评内容平台落地了全链路的可观测建设在日志Logging、指标Metrics和追踪Tracing的三个具体方向上都进行了一定的探索和建设。其中之一就是本文的“可视化全链路日志追踪”结合日志Logging与追踪Tracing我们提出了一套新的业务追踪通用方案通过在业务执行阶段结合完整的业务逻辑动态完成日志的组织串联替代了传统方案低效且滞后的人工日志串联最终可以实现业务全流程的高效追踪以及业务问题的高效定位。此外在指标Metrics方向上点评内容平台实践落地了“可视化全链路指标监控”支持实时、多维度地展示业务系统的关键业务和技术指标同时支持相应的告警和异常归因能力实现了对业务系统整体运行状况的有效把控。未来点评内容平台会持续深耕实现覆盖告警、概况、排错和剖析等功能的可观测体系[7]持续沉淀和输出相关的通用方案希望可以为业务系统特别是复杂的业务系统提供一些可观测性建设的借鉴和启发。5. 参考文献[1] Metrics, tracing, and logging[2] ELK Stack: Elasticsearch, Logstash, Kibana | Elastic[3] Dapper, a Large-Scale Distributed Systems Tracing Infrastructure[4] OpenZipkin · A distributed tracing system[5] 分布式会话跟踪系统架构设计与实践[6] 凤凰架构-可观测性[7] 万字破解云原生可观测性