Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederrsshub.app
美团技术团队
Get the latest updates from 美团技术团队 directly as they happen.
Follow now 97 followers
Latest posts
Last updated over 1 year ago
一次「找回」TraceId的问题分析与过程思考
about 2 years ago
1. 问题背景和思考1.1 问题背景在一次排查线上告警的过程中，突然发现一个链路信息有点不同寻常（这里仅展示测试复现的内容）：在机器中可以清楚的发现“2022-08-02 19:26:34.952 DXMsgRemoteService ”这一行日志信息并没有携带TraceId，导致调用链路信息戛然而止，无法追踪当时的调用情况。1.2 问题复现和思考在处理完线上告警后，我们开始分析“丢失”的TraceId到底去了哪里？首先在代码中定位TraceId没有追踪到的部分，发现问题出现在一个@Async注解下的方法，删除无关的业务信息代码，并增加MTrace埋点方法后的复现代码如下：@SpringBootTest @RunWith(SpringRunner.class) @EnableAsync public class DemoServiceTest...
人机语音交互场景中的低延迟流式语音识别技术
about 2 years ago
1. 前言1.1 语音识别技术简介人机交互一直都是人工智能大背景下的“热门话题”，语音交互作为人机交互的一个重要分支，具有广泛的应用价值，也被应用到美团的多个业务场景中，如智能客服、电话营销和电话满意度反馈等。而流式语音识别技术是整个交互链条的入口，对交互体验影响巨大。常见的语音识别大多都是非流式语音识别技术，它是指模型在用户说完一句话或一段话之后再进行识别。这意味着模型需要等待用户停顿或结束说话才能开始识别，并且只能在用户停顿或结束说话后才能输出完整的识别结果。这样做的缺点是会导致较长的延迟和不连贯的交互。例如，在会议场景中，如果使用非流式语音识别技术，就可能出现会议参与者说了很长时间的话才显示出他们所说的内容，而且可能因为网络延迟或其他原因导致内容显示不全或错误。这样就会影响会议参与者之间的沟通和理解，并且降低会议效率和质量。而与之对应的是流式语音识别技术，它是指可以在处理音频流的过程中，支持实时返回识别结果的一类语音识别模型。这意味着模型不需要等待用户说完整句或整段话就可以开始识别，并且可以随着用户说话的进度逐渐输出识别结果。这样做的好处是能够大大减少人机交互过程中语音识别的处理时间，提高用户体验和交互效率。例如，在智能客服场景中，使用流式语音识别技术，就可以实现用户说一句话很快就能获得机器人响应，而不是等到用户说完一段话才给出回答。这样就可以让用户更快地得到满意的解决方案，并且减少用户的等待时间和不满情绪，提升用户满意度。在美团内部的众多业务场景中广泛使用了流式语音识别技术。本文将详细阐述团队在语音交互场景中的低延迟流式语音识别方案，目前以该方案形成的技术论文《Peak-First CTC: Reducing the Peak Latency of CTC Models by...
基于AI+数据驱动的慢查询索引推荐
about 2 years ago
1 背景随着美团业务量的不断增长，慢查询的数量也日益增多。目前，日均慢查询数量已经超过上亿条，如果仅依靠DBA和开发人员手动地对这些慢查询进行分析并建立合适的索引，显然是不太现实的。为了解决这一难题，美团内部DAS（数据库自治服务）平台已经集成了基于代价的慢查询优化建议来自动地为慢查询推荐索引。然而，仍然存在一些问题：基于代价的慢查询优化建议是借助于优化器的代价估计，来推荐出对于查询代价改善最大的索引，但优化器的代价估计并不是完全准确[1]，因此可能存在着漏选或者错选推荐索引的问题。基于代价的慢查询优化建议需要计算查询在不同索引下查询代价的改善程度，因此需要进行大量的增删索引操作，但真实增删索引的代价是非常大的，需要借助于假索引[2]技术，假索引技术并不创建真实的物理索引文件，只是通过模拟索引存在时的查询计划来估算索引对于查询的收益。目前，美团大部分业务都是运行在MySQL实例上的，不同于商业数据库SQL Server和开源数据库PostgreSQL，MySQL内部并没有集成假索引技术，因此需要自己构建支持假索引的存储引擎，其开发成本较高，这也是目前DAS平台基于代价的慢查询优化建议所采用的方案。为了解决上述两个问题，美团数据库研发中心与华东师范大学数据科学与工程学院展开了《基于数据驱动的索引推荐》的科研合作，双方通过在DAS平台上集成基于AI+数据驱动的索引推荐，来与基于代价的方法并行地为慢查询推荐索引，以提升推荐效果。首先，基于代价的方法每天会为慢查询推荐索引，并在采样库上评估推荐的索引是否真正地改善了查询的执行时间，这为AI方法积累了大量可信的训练数据，根据此数据训练的AI模型，可以在一定程度上弥补基于代价的方法漏选或错选索引的问题。其次，基于AI的方法将针对慢查询的索引推荐看作是二分类问题，通过分类模型直接判别在某一列或某些列上建立索引是否能够改善查询的执行性能，并不借助于查询优化器和假索引技术，这使得AI方法更加通用，且开发成本更低。2 索引推荐介绍索引推荐可以划分为两个级别：Workload级别和Query级别：在Workload级别，索引推荐是在限制的索引存储空间或索引个数下，推荐出一组最优的索引集合来使得整个Workload的代价最低。Query级别的索引推荐可以被视为Workload级别索引推荐的简化版本，在Query级别，索引推荐是为单个慢查询推荐缺失的索引，以改善其性能。2.1 基于代价的索引推荐基于代价的索引推荐[3]大多聚焦于Workload级别的索引推荐，出现在查询中每一列或者列的组合都可以看作是一个能够改善Workload代价的候选索引，所有的候选索引构成了一个巨大的搜索空间（候选索引集合）。基于代价的索引推荐的目标，是在候选索引集合中搜索出一组最优索引集合，以最大程度地改善Workload代价。如果候选索引的个数$N$，限制的最大推荐索引个数是$M$，那么最优索引集合的搜索空间是：$$ C_{N}^{M}=\frac{N *(N-1) \ldots(N-M+1)}{M !} $$这是一个属于NP-hard范畴的搜索问题[4]。目前，基于代价的索引推荐方法大多会采用“贪心策略”来简化搜索过程，但这可能会导致最后推荐出的索引是次优解[5]。2.2 基于AI+数据驱动的索引推荐基于AI+数据驱动的索引推荐聚焦于Query级别的索引推荐，出发点是在某个数据库中因为缺失索引导致的慢查询，在其它数据库中可能有相似的索引创建案例：这些查询语句相似，因此在相似位置上的列创建索引也可能带来类似的收益。例如下图中，查询$q_s$和$q_t$在语句结构和列类型上非常相似。因此，我们可以通过学习查询$q_s$的索引创建模式来为查询 $q_t$推荐缺失的索引。对于不同列数的索引推荐，我们会分别训练基于XGBoost的二分类模型。例如，我们目前最高支持三列的索引推荐，因此会分别训练一个单列索引推荐模型、一个两列索引推荐模型和一个三列索引推荐模型。对于给定的一个单列候选索引和它对应的慢查询，我们使用单列索引推荐模型来判断该单列候选索引是否能够改善该慢查询的性能。同样的，对于给定的一个两列（三列）候选索引和它对应的慢查询，我们使用两列（三列）索引推荐模型来判断这个两列（三列）候选索引是否能够改善该慢查询的性能。如果一条慢查询中包含的候选索引个数为$N$，那么则需要$N$次模型预测来完成对这条慢查询的索引推荐。3...
ICDE 2023 | 多场景多任务学习在美团到店餐饮推荐的实践
about 2 years ago
随着推荐算法技术的不断发展，跨场景学习已经受到了越来越多的研究人员的关注。美团到餐算法团队受到业界相关技术的启发，不断探索到店餐饮多场景推荐的优化问题，在多场景多任务学习的推荐领域中积累了较多的应用经验。团队使用到店餐饮全域推荐场景数据训练统一的多场景多任务学习模型，减少了重复性开发，并在多个到店餐饮推荐场景进行落地，取得了较为显著的效果。本文详细阐述了美团到店餐饮业务中多场景多任务学习的解决方案，基于该方案形成的学术论文《HiNet: Novel Multi-Scenario & Multi-Task Learning with Hierarchical Information Extraction》已经被国际数据工程会议ICDE 2023收录。1. 背景随着网络信息和服务的爆炸式增长，推荐系统已经成为为用户提供高质量个性化决策建议和体验的关键组件。传统的推荐系统，模型服务通常需要为特定场景单独进行定制化的开发，以适配不同场景下数据分布和特征空间的差异。然而在美团等工业互联网平台中通常存在多种多样的推荐场景（例如首页信息流、垂类子频道等）作用于用户访问的决策链路，同时基于每个场景的个性化推荐模型再对展示项目进行排序最终呈现给用户。在美团到店餐饮（以下简称到餐）平台中，伴随业务精细化的发展趋势，越来越多的场景需要对推荐系统进行定制化的建设，以满足用户到店就餐的个性化需求。如下图1所示，现实中用户往往会在多个不同场景之间进行浏览、点击，并最终成交。但随着推荐场景数量的增加，传统地针对单个场景独立开发推荐模型，往往会导致如下问题：仅根据单场景自身的数据进行建模，无法利用到用户在跨场景中丰富的行为信息，忽视了场景共性信息，特别是考虑到多种场景中可能会存在重复展示的商品（在上图1中，红色矩形框圈中的其实是相同的商品）。一些长尾的业务场景由于流量较小且用户行为较为稀疏，数据量不足以让模型有效地进行建模。由于每个场景的特征挖掘、模型训练和上线部署是独立开发且相互隔离的，这会大大增加计算成本和维护负担。总的来讲，推荐算法对各场景单独建模存在诸多的局限性。然而，简单地将多个场景数据集进行合并训练一个排序模型来提供服务，并不能有效地捕获到每个场景的特有信息。此外，除了多场景推荐问题，每个场景中的用户满意度和参与度等通常都存在不同的衡量指标需要共同优化，例如点击率（CTR）和点击转化率（CTCVR）。因此需要开发一个有效和统一的框架，来解决这种在多个场景中优化各种指标复???性的问题（即多场景多任务优化问题）。在最近的一些研究中，相关方法往往是将多场景推荐做为一个多任务学习（Multi-Task...
MRCP在美团语音交互中的实践和应用
about 2 years ago
一、背景智能语音对话作为人工智能领域最先落地的分支之一，可以实现与人进行自然语言多轮对话，其核心技术在近年来不断地发展成熟，包括语音识别、自然语言理解、对话管理等。伴随着技术的成熟，越来越多的电话机器人开始走进我们的生活，这些电话机器人在客户服务、智能销售、通知触达等场景发挥着重要的作用。当你和智能语音机器人对话交互时，你是否好奇电话背后的机器人如何“听懂”你的意思，又如何像人一样“回答”你的问题？经典的技术实现路径是：机器人首先通过“语音识别（ASR）”将用户输入语音识别成文字，再通过“自然语言理解（NLU）”识别意图，之后根据意图、系统信号等输入结合对话管理技术得到相应的回复，最后通过“语音合成（TTS）”生成语音播报给电话对端的用户。但要将 ASR、TTS 这些技术应用到电话系统上，还需要一些额外的工作和技术支撑，其中比较重要的技术之一也就是本文将要介绍的 MRCP。备注：本文涉及较多的专业名词，我们特别在文末附上了名词解释，以帮助大家进行阅读。1.1 MRCP 是什么MRCP（Media Resource Control Protocol, MRCP）是一种通讯协议，中文定义是：媒体资源控制协议，用于语音服务器向客户端提供各种语音服务（如语音识别和语音合成）。该协议定义了控制媒体处理资源所必需的请求（Request）、应答（Response）和事件（Event）等消息，它需要借助 RTP（Real-Time Transport...
SOTA！目标检测开源框架YOLOv6 3.0版本来啦
about 2 years ago
1. 概述1 月 6 日，美团视觉智能部发布了 YOLOv6 3.0 版本，再一次将目标检测的综合性能推向新高。本次更新除了对 YOLOv6-N/S/M/L 模型进行全系列升级之外，还推出了大分辨率 P6 模型。其中，YOLOv6-L6...
大规模食品图像识别：T-PAMI 2023论文解读
about 2 years ago
1 引言视觉智能部与中科院计算所于2020-2021年度展开了《细粒度菜品图像识别和检索》科研课题合作，本文系双方联合在IEEE T-PAMI2023发布论文《Large Scale Visual Food Recognition》 (Weiqing Min, Zhiling Wang, Yuxin...
交互式推荐在外卖场景的探索与应用
about 2 years ago
1. 背景1.1 什么是交互式推荐？交互式推荐是一种互动式实时推荐产品模块，主要通过理解用户需求、以互动的方式进行推荐。交互式推荐由Youtube在2018年提出[1]，主要用于解决推荐系统的延迟[2]和与用户互动偏弱的问题。从2021年下半年开始，美团外卖推荐技术团队在外卖首页Feed上持续进行探索，2022上半年完成全量。具体流程如视频1所示：用户从首页Feed进入商家详情页并退出之后，动态地插入新的推荐内容到用户推荐列表中。其主要优势是根据用户的实时需求动态插入卡片进行反馈，进而增强用户的使用体验。视频1 外卖首页Feed中的交互式推荐形态1.2 为什么需要交互式推荐？我们发现，外卖首页Feed在用户即时兴趣的捕捉和反馈上存在痛点，“对比型”用户的选购效率和体验不佳。外卖首页Feed作为泛意图用户主要选购场景之一，用户在浏览到成单过程中通常需要进行一番对比、才能逐步收敛意图，然后做出最终决策。但受限于长列表的翻页模式，首页Feed根据用户需求实时调整推荐结果的能力不足。具体表现在，一部分用户的浏览深度不足一页，推荐系统没有额外的机会根据用户兴趣调整推荐结果。另一部分用户虽然有较深的浏览深度，但需要等到翻页时推荐系统才能重新理解用户意图，实时性不足。业界优化这类问题的主要产品形态有交互式推荐、动态翻页、端上重排这三种。交互式推荐由于是在用户可视范围内插入，用户感知较强；后两种的主流形态是在用户不可见区域更新推荐，用户感知相对较弱。其实，这三种形态在美团外卖均有尝试，本文重点聚焦于交互式推荐的介绍。2. 问题与挑战我们在外卖场景搭建交互式推荐时，主要面临以下难点和挑战：不同于传统的推荐系统，交互式推荐是由用户触发的推荐，外卖场景下，如何更好的匹配用户实时需求，搭建出一套适用于外卖的、基于端智能框架的推荐系统是我们首要解决的问题。作为首页Feed内部的个性化模块，交互式推荐只做单一模块的优化是不够的，还要考虑首页Feed整体的访购效率。那么，如何选择优化目标，以及如何衡量效果和收益，是摆在我们面前的第二个问题。主流的Feed形态是双列商品瀑布流，但外卖首页Feed是以商家为主的单列列表，如何避免交互在用户的选择路径上带来的“干扰感”，在合适的时机触发交互式推荐，是我们面临的???三个问题。交互式推荐具有动态插入效果，用户对于推荐结果好与坏的感受会更加明显。如何更好理解用户即时意图，如何利用首页Feed列表推荐结果优化交互式推荐的单商家卡片，是我们面临的第四个问题。本文将从以上四个方面，详细介绍外卖首页Feed交互式推荐从0到1搭建的全过程，以及针对以上问题的解决思路。3. 主要工作3.1 交互式推荐框架3.1.1 整体链路上文提到，要实现交互式推荐，搭建出一套适用于外卖的、基于端智能框架的推荐系统非常重要。搭建思路可以用“4W1H”来总结：Where/How：交互式推荐卡片展示在哪？交互式推荐卡片的展现形式是什么？涉及产品形态。Who/When：交互式推荐需要对什么样的用户触发？在什么时机下触发？涉及用户意图理解。What：交互式推荐卡片需要展示什么？涉及推荐策略。基于对上述问题的思考和多方探讨，我们最终和产品、端智能、客户端、应用服务和推荐工程等多个相关团队一起，搭建了这套适用于外卖首页Feed的交互式推荐链路。上图1展示了从“用户点击首页Feed商家卡片”开始，到交互式推荐卡片展现”的全流程。用户进入点菜页后，由客户端调用端智能的意图理解引擎；满足交互式推荐的触发条件后，进行特征处理、计算和存储，并将计算好的将特征传递给客户端组装推荐请求；推荐请求由应用服务层透传给混排服务，再由混排调用商家推荐模块，经过召回、排序、机制、透出阶段，最终返回结果到客户端进行展示。3.1.2 产品形态文章开头部分的视频1是我们线上的最终形态（在用户点击商家下方插入单个商家卡片），但在此之前，我们对交互式推荐的卡片形态和交互逻辑进行了多轮尝试。在卡片形态上，我们先后探索、上线了搜索词卡片、多商家聚合卡片（如视频2所示）、单商家卡片（如视频所示）等多种形态，测试不同卡片类型对用户选购的影响。在交互逻辑上，为了避免插入动画对用户选购的“干扰感”，也对比了“在点击卡片上覆盖”和“在点击卡片下方插入”两种交互，测试对于用户选购的影响。视频2 交互式推荐双商家卡片展示样式在观测不同产品形态的效果差异时，我们重点关注插入的交互式卡片对于首页Feed的千人成交额的影响，实验数据见下表：其中，UV_CXR =...
美团视觉GPU推理服务部署架构优化实践
about 2 years ago
0. 导读美团视觉面向本地生活服务，在众多场景上落地应用了文字识别、图像质量评价、视频理解等视觉AI技术。此前，在线推理服务使用的GPU资源不断增加，但服务GPU利用率普遍较低，浪费大量计算资源，增加了视觉AI应用成本，这是美团也是很多企业亟需解决的问题。美团视觉智能部通过实验分析发现，造成视觉推理服务GPU利用率低下的一个重要原因是模型结构问题：模型中预处理或者后处理部分CPU运算速度慢，导致推理主干网络无法充分发挥GPU运算性能。基于此，视觉研发团队通过模型结构拆分和微服务化，提出一种通用高效的部署架构，解决这种常见的性能瓶颈问题。目前，该解决方案已经在多个核心服务上成功应用。以“图像检测+分类”服务为例，优化后的服务压测性能指标GPU利用率由40%提升至100%，QPS提升超过3倍。本文将会重点介绍推理服务部署架构优化的工程实践，希望对从事相关工作的同学们有所帮助或启发。1. 背景随着越来越多的AI应用进入生产应用阶段，推理服务所需要的GPU资源也在迅速增加。调研数据表明，国内AI相关行业推理服务的资源使用量占比已经超过55%，且比例未来还会持续升高。但很多公司面临的实际问题是，线上推理服务GPU利用率普遍较低，还具备很大的提升空间。而造成服务GPU利用率低的重要原因之一是：推理服务本身存在性能瓶颈，在极限压力情况下也无法充分利用GPU资源。在这种背景下，“优化推理服务性能、提高GPU资源使用效率、降低资源使用成本”具有非常重要的意义。本文主要介绍如何通过架构部署优化，在保证准确率、推理时延等指标的前提下，提升推理服务的性能和GPU利用率。2. 视觉模型服务的特点与挑战近年来，深度学习方法在计算机视觉任务上取得显著进展，已经成为主流方法。视觉模型在结构上具有一些特殊性，如果使用现有推理框架部署，服务在性能和GPU利用率方面可能无法满足要求。2.1 模型优化工具与部署框架深度学习模型部署前通常会使用优化工具进行优化，常见的优化工具包括TensorRT、TF-TRT、TVM和OpenVINO等。这些工具通过算子融合、动态显存分配和精度校准等方法提高模型运行速度。模型部署是生产应用的最后一环，它将深度学习模型推理过程封装成服务，内部实现模型加载、模型版本管理、批处理以及服务接口封装等功能，对外提供RPC/HTTP接口。业界主流的部署框架有以下几种：TensorFlow Serving：TensorFlow Serving（简称TF-Serving）是Google发布用于机器学习模型部署的高性能开源框架，内部集成了TF-TRT优化工具，但是对非TensorFlow格式的模型支持不够友好。Torch Serve：TorchServe是AWS和Facebook联合推出的Pytorch模型部署推理框架，具有部署简单、高性能、轻量化等优点。Triton：Triton是Nvidia发布的高性能推理服务框架，支持TensorFlow、TensorRT、PyTorch和ONNX等多种框架模型，适用于多模型联合推理场景。在实际部署中，无论选择哪种框架，需要同时考虑模型格式、优化工具、框架功能特点等多种因素。2.2 视觉模型特点与传统方法不同， 深度学习是一种端到端的方法，不需要单独设计特征提取、分类器等模块，用单个模型取代传统方法多模块任务。深度学习模型在分类、检测、分割、识别等视觉任务上呈现出巨大优势，做到了传统方法无法达到的精度。常用的视觉分类模型（如ResNet、GoogleNet等）和检测模型（如YOLO、R-FCN等）具有如下特点：网络层数多（适合用GPU运算）：以ResNet-50为例，网络包含49个卷积层和1个全连接层，参数量高达2千5百万，计算量达到38亿FLOPs（浮点运算数）。模型推理包含大量矩阵计算，适合用GPU并行加速。输入图像尺寸固定（需要预处理）：同样以ResNet-50为例，网络的输入是图像浮点类型矩阵，尺寸大小固定为224x224。因此二进制编码图片在送入网络前，需要做解码、缩放、裁切等预处理操作。2.3 视觉推理服务面临的问题与挑战由于视觉模型存在的上述特点，导致模型在部署和优化上存在2个问题：模型优化不彻底：TensorRT、TF-TRT等工具主要针对主干网络优化，但忽略了预处理部分，因此整个模型优化并不充分或者无法优化。例如分类模型中ResNet-50所有网络层都可以被优化，但预处理中的图像解码（通常是CPU运算）操作”tf.image.decode”会被TF-TRT忽略跳过。多模型部署困难：视觉服务经常存在组合串接多个模型实现功能的情况。例如在文字识别服务中，先通过检测模型定位文字位置，然后裁切文字所在位置的局部图片，最后送入识别模型得到文字识别结果。服务中多个模型可能采用不同训练框架，TF-Serving或Troch Serve推理框架只支持单一模型格式，无法满足部署需求。Triton支持多种模型格式，模型之间的组合逻辑可以通过自定义模块（Backend）和集成调度（Ensemble）方式搭建，但实现起来较为复杂，并且整体性能可能存在问题。这两点常见的模型部署问题，导致视觉推理服务存在性能瓶颈、GPU利用率低，即便Triton这种高性能部署框架也难以解决。通用部署框架重点关注的是“通信方式、批处理、多实例”等服务托管方面的性能问题，但如果模型本身中间某个部分（如图像预处理或后处理）存在瓶颈，优化工具也无法优化，就会出现“木桶效应”，导致整个推理过程性能变差。因此，如何优化推理服务中的模型性能瓶颈，仍然是一件重要且具有挑战性的工作。3...
Code：美团代码托管平台的演进与实践
over 2 years ago
1. 引言Code是美团自研的代码托管平台，其中包括了代码版本管理、分支管理及代码评审等功能，协同众多研发流程工具平台，支撑内部所有工程师的日常研发工作。经过近3年的建设，目前Code托管了数以万计的仓库，日常处理千万级的Git相关请求，稳定支撑着美团研发流程规范的持续落地。本文主要介绍美团在建设代码托管平台过程中面临的一些挑战和实践经验。2. 美团代码托管平台建设之路2.1 代码托管平台的发展史回顾美团代码托管平台的发展史，整个历程可以划分为三个阶段：单机部署、多机部署以及自研分布式代码托管平台。第一阶段：单机部署美团最初的代码托管平台，和绝大多数Web系统一样，单机部署即可运行，所有用户的请求均通过Web应用进行响应。由于Git使用基于文件组织形式的存储模式，无论是通过页面访问还是执行Git命令操作，最终都会表现为磁盘的文件读写，高IO磁盘尤为重要。整体架构如下图1所示：第二阶段：多机部署在访问规模不大的情况下，第一阶段这种单机架构可以满足日常的开发需求。但随着研发团队业务需求的不断增长，测试自动化流程的逐步完善，扩展性瓶颈也愈发明显，主要表现为以下2个方面：存储：由于公司资源限制和地域分配不均等因素，代码托管平台部署机器已配置最大容量的可用SSD磁盘，使用率仍高达80%，可用空间严重不足。负载：随着研发人员的不断增多，在访问高峰期，CPU和IO负载高达95%以上，页面出现严重的卡顿，仅能通过限流保障系统的持续服务。因而，单机部署无法再承载高峰期的访问量，系统扩容刻不容缓。于是，我们开始设计了一套能够通过多机负载同一仓库IO的读写分离架构方案，以解决较为严重的IO负载问题。在读写分离架构中，最重要的是要保证用户视角的数据一致性（用户随时可以读取提交的最新代码），这里采取了以下措施：写操作仅发生在主节点。采用懒汉同步模式，在读取数据时触发从节点同步数据，若失败，则路由到主节点。采用独主兜底模式，遇遇到突发情况时可以迅速禁用从节点，保障数据安全。如图2所示，我们将仓库访问形式按照应用层协议区分为HTTP和SSH，分别由对应的解析代理模块进行读写分发操作后再下发到主从节点???此处采用了Round-Bobin的算法分发读请求），使得读吞吐量整体扩大了2倍。对于从节点，我们部署了Agent，在用户发起读请求时会触发同步仓库数据的Fetch操作，以保证数据的一致性。第三阶段：自研分布式代码托管平台在第二阶段，虽然通过多机负载IO的读写分离架构短暂性地解决了扩展性瓶颈问题，但仓库数据仍在持续不断地指数增长。同时，除扩展性问题之外，可用性瓶颈也凸显出来，主要表现在以下2个方面：运维：无论是日常迭代更新版本还是热修复紧急Bug，都需要停服才能部署系统，停服期间用户无法使用代码托管平台。备份：系统采用冷备份的方式多副本存储Git数据，无法保证核心数据的实时恢复，异常情况下存在数据丢失风险。因此，搭建具备高可用性和水平扩展性的分布式架构迫在眉睫。我们调研了业界主流代码托管平台的分布式方案，并结合公司内部的业务特性，最终选择了基于应用层分片的分布式架构，该架构满足了以下2个特性：高可用：采用三副本多活模式，规避代码丢失风险，且系统版本更新无需停服，单机断电、宕机均可正常提供服务。水平扩展：可通过扩容分片集群的方式进行存储和负载扩展，实现广义下的“无限”容量。综上所述，Code基于GitLab生态开源组件二次开发，并采用了应用层分片多活模式的分布式架构方案，简介如下：底层存储服务基于GitLab生态开源组件二次开发，有良好的生态和丰富的功能支持。各服务间均通过gRPC进行交互通信，主要考虑点是Git大多数为二进制数据通信，gRPC基于HTTP 2.0，有良好的传输性能和流式支持。通过路由模块实现逻辑层与存储层有效隔离，逻辑层对物理分片无感知，存储层如同一个整体提供服务。采用了多活复制模式的数据保障架构，提高读写吞吐量，满足日均千万级的请求量需求。针对于应用层分片的劣势，在架构设计时也做了相应的针对性优化，具体如下：热点库：提供了自动化的分片迁移能力，在发现仓库出现热点时，可进行分片迁移达到分片均衡。跨分片数据交互：通过业务层的Git事务包装，我们使用共享Object的模式并确保相互关联的仓库均落在同一分片上，既避免了跨分片通信的问题，也减少了磁盘空间占用和访问时延。3. 美团代码托管平台架构演进的落地和挑战代码托管平台在架构演进过程中，最终完成了以下两个目标：高可用：缩短停机时间，提高可用性，系统稳定可靠。高扩展：针对计算和存储资源，可以实现水平扩展。接下来，针对于每个目标，本文分别从技术挑战、方案选型、设计及解决方案等方面详细介绍我们的实践经验。3.1 扩展性目标3.1.1 技术挑战在进行水平扩展改造时，主要面临了以下两类挑战：规模性：在研发流程自动化等背景下，美团代码托管平台需要具备千万级吞吐、低延迟及高可用的系统性能，以提高研发效率。兼容性：技术改造涉及的场景比较多，主要有两方面的考量：（1）用户低感知，新老系统保证现有通信方式及平台使用方式不变；（2）兼顾过渡时期底层存储介质多样性、运维体系兼容等问题，并保障上下游系统的正常运行。3.1.2 方案选型经过对主流代码托管平台（GitHub、GitLab、Bitbucket等）的调研分析，我们发现各大平台主要采用了以下两种架构解决扩展性问题。通过上述对比可以发现，如果直接接入共享存储，暂时无法满足代码托管平台的稳定性和性能要求（若Git机制进行并行优化，且使用更高读写性能的分布式存储系统，或许是一个不错的选择）。在共享存储优化改造成本较高的前提下，我们最终采用了应用层分片的分布式架构，它既满足扩展性的要求，也更加成熟和稳定，并表现出不错的性能。3.1.3 方案设计我们通过代理模块实现了请求分发，通过路由模块实现了仓库分片，通过应用模块的无状态改造实现了弹性伸缩，从而达成了水平扩展的架构目标。下面将对这些模块进行详细的介绍。代理模块SSH Proxy：提供Git-SSH操作代理，提供Git-SSH请求代理，通过路由模块获取路由信息，到目标机器执行SSH操作。SSH Proxy组件基于go-crypto库开发，实现了公钥识别用户，流量控制，长连接超时处理，SSH转gRPC等功能。后续计划引入signature校验，以应对不同的使用场景。HTTP...
美团技术年货来了！1300+页的电子书，涵盖前端、后端、算法、数据、运维、安全
over 2 years ago
新春将至，一年一度的美团技术年货也如约到来。时间煮雨，岁月缝花，花开无声，花谢无语。2022这一年，我们一起经历了无数的悲喜，也留下了满满的回忆。也许生活就是这样，只有历尽波澜，才能欣赏茫茫大海的辽阔和无边，才能感受到漫天星辰的光芒和温暖。在2023年春节到来之际，我们从去年美团技术团队公众号上精选了60多篇技术文章，整理制作成一本1300多页的电子书，作为新年礼物赠送给大家。这本电子书内容覆盖算法、前端、后端、数据、运维/安全等多个技术领域，希望能对同学们的工作和学习有所帮助。也欢迎大家转给更多有相同兴趣、爱好学习的同事和朋友们，一起切磋，共同成长。祝愿2023年，大家诸事顺遂，健康平安。如何获取？回复关键字【2022算法】，下载20022年算法系列（共430页，约34M）回复关键字【2022前端】，下载2022年前端系列（共198页，约16M）回复关键字【2022后端】，下载2022年后端系列（共575页，约24M）回复关键字【2022综合】，下载2022年数据·运维·安全系列（共160页，约6M）温馨提示：美团技术年货合集大小约为48M，下载需要一些时间；打开电子书目录后，可直接点击感兴趣的标题进行阅读；部分文章中的动态图片无法在电子书中进行完全的展示，大家可以移步美团技术团队官方博客 tech.meituan.com ，或在美团技术团队公众号历史文章中进行阅读，感谢理解。往期技术年货下载关注「美团技术团队」微信公众号。回复【2021年货】、【2020年货】、【2019年货】、 【2018年货】、【2017年货】，即可获取往期年货下载链接。感谢我们相信坚持和积累的力量，9年多的时间，3000多个日夜，500多篇技术文章，美团技术团队博客/公众号，感谢大家的一路相伴！
美团开放平台SDK自动生成技术与实践
over 2 years ago
1. 引言美团开放平台developer.meituan.com对外提供了外卖、团购、配送等20余个业务场景的OpenAPI，供第三方开发者搭建应用时使用，是美团系统与外部系统通讯的最重要平台。本文主要讲述开放平台如何通过技术手段自动生成支持接口参数富模型和多种编程语言的SDK，以提高开发者对接开放平台API的效率。1.1 背景美团开放平台将美团各类业务提供的扩展服务封装成一系列应用程序编程接口（API）对外开放，供第三方开发者使用。开发者可通过调用开放平台提供的OpenAPI获取数据和能力，以实现自身系统与美团系统协同工作的业务逻辑。以外卖业务场景为例，开发者可以在自己为外卖商户开发的应用中通过调用美团开放平台提供的API，提供外卖订单查询、接单、订单管理等一系列功能。如下图所示：开放平台为开发者提供的OpenAPI以HTTP接口的形式提供。以平台提供的订单查询接口为例，对应的HTTP请求如下所示：POST https://api-open-cater.meituan.com/api/order/queryById Content-Type: application/x-www-form-urlencoded;charset=utf-8 appAuthToken=eeee860a3d2a8b73cfb6604b136d6734283510c4e92282& charset=utf-8& developerId=106158& sign=4656285a4c2493e279d929b8b9f4e29310da8b2b& timestamp=1618543567& biz={"orderId":...