素材网站下载,专做智能化施工的网站,手机网站怎么制作内容,分享到wordpress背景 随着酒店业务的高速发展#xff0c;我们为用户、商家提供的服务越来越精细#xff0c;系统服务化程度、复杂度也逐渐上升。微服务化虽然能够很好地解决问题#xff0c;但也有副作用#xff0c;比如#xff0c;问题定位。 每次问题定位都需要从源头开始找同事帮我人肉… 背景 随着酒店业务的高速发展我们为用户、商家提供的服务越来越精细系统服务化程度、复杂度也逐渐上升。微服务化虽然能够很好地解决问题但也有副作用比如问题定位。 每次问题定位都需要从源头开始找同事帮我人肉查日志举一个简单的例子 “这个详情页的价格是怎么算出来的?” 一次用户酒店可订空房页POI详情页访问流量最多需要经过73个服务节点。查问题的时候需要先后找4~5个关键节点的同学帮我们登录十多个不同节点的机器查询具体的日志沟通成本极大效率很低。 为了解决这个问题基础架构的同学提供了MTrace详情可以参考技术博客《分布式会话跟踪系统架构设计与实践》协助业务方排查长链路问题。 但是与此同时还有许多不确定性因素使问题排查过程更加艰难甚至无果而终 各服务化节点存储日志的时间长度不一致有的服务节点因为QPS过高只能不打或者随机打印日志会导致最终查问题的时候线索因为没日志断掉有的服务节点使用了异步逻辑线程池、Hystrix、异步RPC等导致日志中缺失Trace ID无法关联在一起各服务节点的采样率不一样链路数据的上报率也是随机性的线索容易断掉MTrace上只有链路信息没有关联各服务节点的日志信息动态扩容节点上的日志缩容后无法找到。总结起来如图所示 目标 我们的核心诉求有两个 根据用户行为快速定位到具体的Trace ID继而查询到这次服务调用链路上所有节点的日志查询的实时性要能做到准实时秒级输出相关链路日志要在独立外部存储系统中保存半年以上。然后我们对诉求做了进一步的拆分 全量打日志不现实需要选择性打打价值最高部分的日志链路数据需要全服务节点都上传避免因为异步化等原因造成链路数据中断不上传接入方式尽量简单避免所有服务节点都需要修改具体业务代码来接入。最好是能通过日志拦截的方式其它保持透明日志格式化该有的字段AppKey、hostname、IP、timestamp等不需要业务RD反复输入自动补齐在不阻塞原有业务操作的情况下做到准实时展示链路、日志链路数据和日志数据存储不依赖各服务节点需要在独立的存储系统上存储半年以上。系统 搞清了核心诉求后我们针对性地做了许多调研最终定了一个系统的整体设计方案这就是目前已经上线并实践已久的美团点评酒店「卫星系统」。 下面我们就来对系统做详细介绍包括一些核心细节点。 架构 如下图所示卫星系统从横向分为链路和日志两个部分。 链路部分是以MTrace为基础用支持超时fallback下Trace信息传递的Hystrix-Trace插件来覆盖全部场景保证链路被完整采集。 日志部分在接入端有三大核心步骤首先是依托于日志拦截组件实现对业务代码零侵入的情况下收集系统中所有日志内容然后根据统一日志规范对日志进行格式化处理最后通过基于logcenter日志传输机制实现日志到Kafka的传输。 从纵向又分为 业务接入层根据策略采集Trace与业务日志数据处理层通过storm流式处理日志信息数据存储层用于支持实时查询的Squirrel美团点评Redis集群与持久存储的ESElasticSearch以及面向用户的展示层。日志采样方案 接入端是所有数据之源所以方案设计极为关键。要解决的问题有采集策略、链路完整性保障、日志拦截、日志格式化、日志传输。 有的业务单台机器每天日志总量就有百G以上更有不少业务因为QPS过高而选择平时不打印日志只在排查问题时通过动态日志级别调整来临时输出。所以我们在最初收集日志时必须做出取舍。经过分析发现在排查问题的时候绝大多数情况下发起人都是自己人RD、PM、运营如果我们只将这些人发起的链路日志记下来那么目标日志量将会极大减少由日志量过大而造成的存储时间短、查询时效性差等问题自然得到解决。 所以我们制定了这样的采集策略 通过在链路入口服务判断发起人是否满足特定人群住宿事业部员工来决定是否进行日志采集将采集标志通过MTrace进行全链路传递。这样就能保证链路上所有节点都能行为一致地去选择是否进行日志上报保证链路上日志的完整性。 日志拦截 作为核心要素的日志如何进行收集是一个比较棘手的问题。让业务方强制使用我们的接口进行日志输出会带来许多麻烦一方面会影响业务方原有的日志输出策略另一方面系统原有的日志输出点众多涉及的业务也五花八门改动一个点很简单但是全面进行改动难保不会出现未知影响。所以需要尽可能降低对接入方代码的侵入。 由于目前酒店核心业务已全面接入log4j2通过研究发现我们可以注册全局Filter来遍历系统所有日志这一发现使我们实现了代码零改动的情况下收集到系统所有日志。 日志格式化 业务系统输出的日志格式不一比如有的没有打印TraceID信息有的没有打印日志位置信息从而很难进行定位。这主要带来两方面的问题一方面不利于由人主导的排查分析工作另一方面也不利于后续的系统优化升级比如对日志的自动化分析报警等等。 针对这些问题我们设计了统一日志规范并由框架完成缺失内容的填充同时给业务方提供了标准化的日志接口业务方可以通过该接口定义日志的元数据为后续支持自动化分析打下基础。 由框架填充统一日志信息这一过程利用到了log4j2的Plugins机制通过Properties、Lookups、ContextMap实现业务无感知的操作。 日志处理 我们在最终的日志传输环节利用了日志中心的传输机制使用日志中心的ScribeAppender实现日志传输至本地agent然后上报到远端Kafka这样设计有几点好处 依赖公司成熟的基础服务相对而言更可靠、更稳定同时也省去了自己搭建服务、保证服务安全这一过程可以将日志直接转存至日志中心ES做持久化存储同时支持快速灵活的数据检索可以通过Storm对日志进行流式处理支持灵活的系统扩展比如实时检索、基于日志的实时业务检查、报警等等为后续系统扩展升级打下基础。我们的数据处理逻辑全部在Storm进行处理主要包含日志存储Squirrel美团点评内部基于Redis Cluster研发的纯内存存储、实时检索与Trace同步。 目前日志中心ES能保证分钟级别实时性但是对于RD排查问题还是不够必须支持秒级别实时性。所以我们选择将特定目标用户的日志直接存入Squirrel失效时间只有半小时查询日志时结合ES与Squirrel这样既满足了秒级别实时性又保证了日志量不会太大对Squirrel的压力可以忽略不计。 我们的系统核心数据有链路与日志链路信息的获取是通过MTrace服务获得但是MTrace服务对链路数据的保存时间有限无法满足我们的需求。所以我们通过延时队列从MTrace获取近期的链路信息进行落地存储这样就实现了数据的闭环保证了数据完整性。 链路完整性保障 MTrace组件的Trace传递功能基于ThreadLocal而酒店业务大量使用异步化逻辑线程池、Hystrix这样会造成传递信息的损失破坏链路完整性。 一方面通过Sonar检查和梳理关键链路来确保业务方使用类似transmittable-thread-local中的ExecutorServiceTtlWrapper.java、ExecutorTtlWrapper.java的封装来将ThreadLocal里的Trace信息也传递到异步线程中前文提到的MTrace也提供这样的封装。 另一方面Hystrix的线程池模式会造成线程变量丢失。为了解决这个问题MTrace提供了Mtrace Hystrix Support Plugin插件实现跨线程调用时的线程变量传递但是由于Hystrix有专门的timer线程池来进行超时fallback调用使得在超时情况下进入fallback逻辑以后的链路信息丢失。 针对这个问题我们深入研究了Hystrix机制最终结合Hystrix Command Execution Hook、Hystrix ConcurrencyStrategy、Hystrix Request Context实现了覆盖全场景的Hystrix-Trace插件保障了链路的完整性。 HystrixPlugins.getInstance().registerCommandExecutionHook(new HystrixCommandExecutionHook() {Overridepublic T void onStart(HystrixInvokableT commandInstance) {// 执行command之前将trace信息保存至hystrix上下文实现超时子线程的trace传递if (!HystrixRequestContext.isCurrentThreadInitialized()) {HystrixRequestContext.initializeContext();}spanVariable.set(Tracer.getServerSpan());}Overridepublic T Exception onError(HystrixInvokableT commandInstance, HystrixRuntimeException.FailureType failureType, Exception e) {// 执行结束后清空hystrix上下文信息HystrixRequestContext context HystrixRequestContext.getContextForCurrentThread();if (context ! null) {context.shutdown();}return e;}Overridepublic T void onSuccess(HystrixInvokableT commandInstance) {// 执行结束后清空hystrix上下文信息HystrixRequestContext context HystrixRequestContext.getContextForCurrentThread();if (context ! null) {context.shutdown();}} });HystrixPlugins.getInstance().registerConcurrencyStrategy(new HystrixConcurrencyStrategy() {Overridepublic T CallableT wrapCallable(CallableT callable) {// 通过自定义callable保存trace信息return WithTraceCallable.get(callable);} });效果展示 比如以排查一次用户点击某POI详情页的TraceID为例子 我们可以看到他在MTrace中的调用链路是这样的 在卫星系统中展示为如下效果 可见在保留了链路数据的基础上系统还将全链路节点日志聚合到了一起提升了排查效率。 后续规划 目前系统还处于初级阶段主要用来解决RD在排查问题时的两大痛点日志信息的不完整与太分散现在已经满足了这一需求。但是全链路日志系统能做的不止这些后续的主要规划有如下几方面 支持多链路日志关联搜索比如一次列表页刷新与后续的详情页展示虽然链路是多个但是实际处在一个关联的场景中。支持关联搜索就可以可以将日志排查目标从单个动作维度扩展到多动作组成的场景维度。支持业务方自定义策略规则进行基于日志的自动化业务正确性检查如果检查出问题可以直接将详细信息通知相关人员实现实时监测日志、实时发现问题、实时通知到位免去人工费时费力的低效劳动。作者简介 亚辉2015年加入美团点评就职于美团点评酒旅事业群技术研发部酒店后台研发组。曾鋆2013年加入美团点评就职于美团点评酒旅事业群技术研发部酒店后台研发组。招聘信息 最后发个广告美团点评酒旅事业群技术研发部酒店后台研发组长期招聘Java后台、架构方面的人才有兴趣的同学可以发送简历到xuguanfei#meituan.com。