前言监控系统是整个业务系统中至关重要的一环，它就像眼睛一样，时刻监测机房、网络、服务器、应用等运行情况，并且在出现问题时能够及时做出相应处理。美团点评刚开始使用的是Zabbix监控系统，几经优化，在当时能够达到2W+机器，450W+监控项的量。随着各业务线的发展，监控项越来越多，Zabbix的问题也越来越突出，当时针对Zabbix的吐槽问题有：不支持扩展，本身是一个单点，当机器规模超过万台的时候会出现很明显的性能问题。改造难度比较大，不支持定制化功能。配置比较复杂，学习成本较高。对外提供的API不够丰富，很难与其他业务系统集成。这个时候我们急于寻找一个替代的解决方案，经过筛选后，最终选择引进最初由小米开源的Open-Falcon监控系统（文档）。下面本文将为大家详细介绍Mt-Falcon在原来Open-Falcon的基础上做出的一些改进。Open-Falcon架构图图片转载自Open-Falcon官网Mt-Falcon的架构图Mt-Falcon相对Open-Falcon改造后，比较大的功能点有：报警禁用、报警ACK、报警升级、报警任务分布式消费、支持OpenTSDB存储、字符串监控、多条件监控、索引信息存储改造、过期索引信息自动删除且重新上报后会再次重建等。改进列表一、Agent改造1. 提升Agent数据转发的性能异步化处理。之前是每调一次Agent的上报接口就会往Transfe ...继续阅读 (103)

背景随着外卖业务的快速发展，业务复杂度不断增加，线上系统环境有任何细小波动，对整个外卖业务都可能产生巨大的影响，甚至形成灾难性的雪崩效应，造成巨大的经济损失。每一次客诉、系统抖动等都是对技术人员的重大考验，我们必须立即响应，快速解决问题。如何提高排查问题的效率呢？最有效的方式是通过分析系统日志。如果系统日志全面，会为我们排查解决线上问题带来绝大的帮助，但是要想保证系统日志全面，就必须打印出所有的系统或业务日志。这样就会带来另一个问题，那就是日志量的暴涨，过多的日志除了能够帮助我们解决问题外，同时会直接造成系统性能下降，极端情况下，甚至导致系统宕机。在这种背景下，为了兼顾性能和快速响应线上问题，我们设计开发了日志级别动态调整组件。通过使用该组件，可以在需要解决线上问题时，实时调整线上日志输出级别，获取全面的Debug日志，帮助工程师提高定位问题的效率。简介使用场景场景一业务依赖复杂。某一时刻，依赖的下游服务故障，导致请求大量超时，尤其是像外卖这种集中性特别明显的业务，平均每秒QPS在8000以上，1分钟的故障就会集中产生大量的错误日志，导致磁盘IO急剧提高，耗费大量CPU，进而导致整个服务瘫痪。如果该业务不能立即降级，怎么办？从代码级别解决问题到发版上线，暂且不说流程长、操作麻烦，同时还存在引入其它故障的高风险。如果系统恰好使用Log4j版本，在极短时间内打印出了海量错误日志，会快速 ...继续阅读 (91)

美团外卖经过3年的飞速发展，品类已经从单一的外卖扩展到了美食、夜宵、鲜花、商超等多个品类。用户群体也从早期的学生为主扩展到学生、白领、社区以及商旅，甚至包括在KTV等娱乐场所消费的人群。随着供给和消费人群的多样化，如何在供给和用户之间做一个对接，就是用户画像的一个基础工作。所谓千人千面，画像需要刻画不同人群的消费习惯和消费偏好。外卖O2O和传统的电商存在一些差异。可以简单总结为如下几点：1）新事物，快速发展：这意味很多用户对外卖的认知较少，对平台上的新品类缺乏了解，对自身的需求也没有充分意识。平台需要去发现用户的消费意愿，以便对用户的消费进行引导。2）高频：外卖是个典型的高频O2O应用。一方面消费频次高，用户生命周期相对好判定；另一方面消费单价较低，用户决策时间短、随意性大。3）场景驱动：场景是特定的时间、地点和人物的组合下的特定的消费意图。不同的时间、地点，不同类型的用户的消费意图会有差异。例如白领在写字楼中午的订单一般是工作餐，通常在营养、品质上有一定的要求，且单价不能太高；而到了周末晚上的订单大多是夜宵，追求口味且价格弹性较大。场景辨识越细致，越能了解用户的消费意图，运营效果就越好。4）用户消费的地理位置相对固定，结合地理位置判断用户的消费意图是外卖的一个特点。外卖产品运营对画像技术的要求如下图所示，我们大致可以把一个产品的运营分为用户获取和用户拓展两个阶段。在用户获取阶段， ...继续阅读 (103)

前言近年来，深度学习在语音、图像、自然语言处理等领域取得非常突出的成果，成了最引人注目的技术热点之一。美团点评这两年在深度学习方面也进行了一些探索，其中在自然语言处理领域，我们将深度学习技术应用于文本分析、语义匹配、搜索引擎的排序模型等；在计算机视觉领域，我们将其应用于文字识别、目标检测、图像分类、图像质量排序等。下面我们就以语义匹配、图像质量排序及文字识别这三个应用场景为例，来详细介绍美团点评在深度学习技术及应用方面的经验和方法论。基于深度学习的语义匹配语义匹配技术，在信息检索、搜索引擎中有着重要的地位，在结果召回、精准排序等环节发挥着重要作用。传统意义上讲的语义匹配技术，更加注重文字层面的语义吻合程度，我们暂且称之为语言层的语义匹配；而在美团点评这样典型的O2O应用场景下，我们的结果呈现除了和用户表达的语言层语义强相关之外，还和用户意图、用户状态强相关。用户意图即用户是来干什么的？比如用户在百度上搜索“关内关外”，他的意图可能是想知道关内和关外代表的地理区域范围，“关内”和“关外”被作为两个词进行检索，而在美团上搜索“关内关外”，用户想找的就是“关内关外”这家饭店，“关内关外”被作为一个词来对待。再说用户状态，一个在北京和另一个在武汉的用户，在百度或淘宝上搜索任何一个词条，可能得到的结果不会差太多；但是在美团这样与地理位置强相关的场景下就会完全不一样。比如我在武汉搜“黄鹤楼”， ...继续阅读 (97)

本文是郑坤根据第14期美团点评技术沙龙“你不知道的美团云”演讲内容整理而成，已发表在《程序员》杂志2017年1月刊。美团点评容器平台简介本文介绍美团点评的Docker容器集群管理平台（以下简称“容器平台”）。该平台始于2015年，是基于美团云的基础架构和组件而开发的Docker容器集群管理平台。目前该平台为美团点评的外卖、酒店、到店、猫眼等十几个事业部提供容器计算服务，承载线上业务数百个，日均线上请求超过45亿次，业务类型涵盖Web、数据库、缓存、消息队列等。为什么要开发容器管理平台作为国内大型的O2O互联网公司，美团点评业务发展极为迅速，每天线上发生海量的搜索、推广和在线交易。在容器平台实施之前，美团点评的所有业务都是运行在美团私有云提供的虚拟机之上。随着业务的扩张，除了对线上业务提供极高的稳定性之外，私有云还需要有很高的弹性能力，能够在某个业务高峰时快速创建大量的虚拟机，在业务低峰期将资源回收，分配给其他的业务使用。美团点评大部分的线上业务都是面向消费者和商家的，业务类型多样，弹性的时间、频度也不尽相同，这些都对弹性服务提出了很高的要求。在这一点上，虚拟机已经难以满足需求，主要体现以下两点。第一，虚拟机弹性能力较弱。使用虚拟机部署业务，在弹性扩容时，需要经过申请虚拟机、创建和部署虚拟机、配置业务环境、启动业务实例这几个步骤。前面的几个步骤属于私有云平台，后面的步骤属于业务工程师 ...继续阅读 (90)

本文首发在“美团点评技术团队”微信公众号，内容已覆盖截止至2017年1月23日最新的技术文章。1955年3月15日，爱因斯坦给刚去世的密友Michele Besso家人的信中说：“像我们这样信仰物理学的人都知道，过去、现在和未来之间的分别只不过是持久而顽固的幻觉。”然而，临近岁末，我们这些普通人还是难以免俗地做一番回顾与展望。算起来，“美团点评技术团队”这个公众号始自2014年9月，已经运营两年多了。公众号对应的美团点评技术博客开始得更早，是2013年的12月。那时候，美团创立不到4年，千团大战还在如火如荼，美团酒旅和美团外卖都刚刚开始不久。而现在，美团外卖今天刚刚宣布日订单突破900万，离美团酒旅按间夜数也已成为业界第一。在美团点评，我们信仰耐心和坚持的力量，愿意持续去做一些正确、有积累、可能表面看上去不那么重要实则非常关键的事情。正如美团联合创始人穆荣均在今年一次Hackathon上说的： “这个世界不缺乏有勇气的人，很多人都会想做各种惊天动地的事业。而最缺乏的，是耐心和坚持。”技术博客和技术公众号正是耐心与坚持的结果。从2013年的4篇文章开始，我们多年来一直坚持把团队在一线实践中获得的经验和思考写成文章，对外发布。2016年，我们发表了55篇技术文章，终于实现了最初公司老大给我们提出的每周一篇的目标（耶！）。让我们一起来倒数美团点评技术博客/公众号的年度Top 10（基于微 ...继续阅读 (92)

clean code，顾名思义就是整洁的代码，或者说清晰、漂亮的代码，相信大多数工程师都希望自己能写出这样的代码。也许这是个千人千面的话题，每个工程师都有自己的理解。比如我，从一个天天被骂代码写得烂的人，逐渐学习成长，到现在也能写的出“人模人样”的代码来了。这期间算是积累了一点经验心得，想和大家分享，抛砖引玉。本文主要针对面向对象编程的clean code来阐述，面向过程代码的思路会比较不同，不在本文的讨论范畴。代码整洁的大前提代码大部分时候是用来维护的，而不是用来实现功能的这个原则适用于大部分的工程。我们的代码，一方面是编译好让机器执行，完成功能需求；另一方面，是写给身边的队友和自己看的，需要长期维护，而且大部分项目都不是朝生夕死的短命鬼。大部分情况下，如果不能写出清晰好看的代码，可能自己一时爽快，后续维护付出的代价和成本将远高于你的想象。对清晰好看代码的追求精神，比所有的技巧都要重要。优秀的代码大部分是可以自描述的，好于文档和注释当你翻看很多开源代码时，会发现注释甚至比我们自己写的项目都少，但是却能看的很舒服。当读完源码时，很多功能设计就都清晰明了了。通过仔细斟酌的方法命名、清晰的流程控制，代码本身就可以拿出来当作文档使用，而且它永远不会过期。相反，注释不能让写的烂的代码变的更好。如果别人只能依靠注释读懂你的代码的时候，你一定要反思代码出现了什么问题（当然，这里不是说大家不要写 ...继续阅读 (94)

在手机客户端尤其是Android应用的开发过程中，我们经常会接触到“硬件加速”这个词。由于操作系统对底层软硬件封装非常完善，上层软件开发者往往对硬件加速的底层原理了解很少，也不清楚了解底层原理的意义，因此常会有一些误解，如硬件加速是不是通过特殊算法实现页面渲染加速，或是通过硬件提高CPU/GPU运算速率实现渲染加速。本文尝试从底层硬件原理，一直到上层代码实现，对硬件加速技术进行简单介绍，其中上层实现基于Android 6.0。了解硬件加速对App开发的意义对于App开发者，简单了解硬件加速原理及上层API实现，开发时就可以充分利用硬件加速提高页面的性能。以Android举例，实现一个圆角矩形按钮通常有两种方案：使用PNG图片；使用代码（XML/Java）实现。简单对比两种方案如下。方案原理特点使用PNG图片（BitmapDrawable）解码PNG图片生成Bitmap，传到底层，由GPU渲染图片解码消耗CPU运算资源，Bitmap占用内存大，绘制慢使用XML或Java代码实现（ShapeDrawable）直接将Shape信息传到底层，由GPU渲染消耗CPU资源少，占用内存小，绘制快页面渲染背景知识页面渲染时，被绘制的元素最终要转换成矩阵像素点（即多维数组形式，类似安卓中的Bitmap），才能被显示器显示。页面由各种基本元素组成，例如圆形、圆角矩形、线段、文字、矢量图（常用贝塞尔曲线 ...继续阅读 (96)

本文根据“第八届中国系统架构师大会”演讲内容整理而成。背景美团最初以团购的形式出现，到现在有了很大的业务形态转变。尤其是经过与大众点评的业务融合，从单一业务发展成了覆盖到店餐饮、到店综合、猫眼、外卖、酒店、旅游等多个垂直领域的综合性电商，并且在各个领域都处于行业领先的地位。在这背后，美团点评不仅面临激烈的行业竞争，还有黑色产业（以下简称“黑产”）带来的各种风险，因为我们的业务有这样一些特点：品类多、覆盖面广：包括几乎所有吃喝玩乐服务，其中不乏容易被销赃的品类。用户多、商户多：美团点评拥有6亿以上用户，400万以上合作商家，覆盖了很大部分国内网民和商户。交易高频：每日订单峰值突破千万。美团点评对黑产有着巨大的吸引力，归纳起来在这些方面尤其突出：用户作弊：大家常说的“薅羊毛”，用户为了骗取促销优惠的作弊行为。商家刷单：常见的有刷排名、刷销量、刷好评等违反商家平台协议的行为。账户和支付安全：公民信息盗用形势已经十分严峻，黑产从业者会在电商平台上盗取用户的余额，或使用他人支付信息来消费。这些行为严重侵害平台用户和商户的利益、扰乱正常交易秩序，处理结果的好坏将决定整个业务的成败。所以美团点评需要一套灵活高效的风险控制系统和工作机制来防控这些风险。归纳一下，风控系统面临的挑战有：业务多、风险点多：上面提到的风险涉及到各个业务的购买流程、用户操作、商家操作等多个场景。变化快：黑产的攻击手段升级， ...继续阅读 (69)

在Android 7.0（Nougat）推出了新的应用签名方案APK Signature Scheme v2后，之前快速生成渠道包的方式（美团Android自动化之旅—生成渠道包）已经行不通了，在此应用签名方案下如何快速生成渠道包呢？本文会对新的应用签名方案APK Signature Scheme v2以及新一代渠道生成工具进行详细深入的介绍。新的应用签名方案APK Signature Scheme v2Android 7.0（Nougat）引入一项新的应用签名方案APK Signature Scheme v2，它是一个对全文件进行签名的方案，能提供更快的应用安装时间、对未授权APK文件的更改提供更多保护，在默认情况下，Android Gradle 2.2.0插件会使用APK Signature Scheme v2和传统签名方案来签署你的应用。下面以新的应用签名方案来指APK Signature Scheme v2。目前该方案不是强制性的，在build.gradle添加v2SigningEnabled false，就能使用传统签名方案来签署我们的应用（见下面的代码片段）。android { ... defaultConfig { ... } signingConfigs { release { storeFile file("my ...继续阅读 (90)

介绍随着数据量的不断增大，传统的直连数据库对数据进行访问的方式已经无法满足一般公司的需求。通过数据库中间件，可以对数据库进行水平扩展，由原来单台数据库扩展到多台数据库，数据库中间件通过路由规则将数据的访问请求路由到其中一台数据库上，从而大大降低了数据访问的瓶颈和单台数据库的压力。通过数据库中间件还可以将DBA和研发进行解耦，提升DBA运维效率。奇虎360公司开源的Atlas是优秀的数据库中间件，美团点评DBA团队针对公司内部需求，在其上做了很多改进工作，形成了新的高可靠、高可用企业级数据库中间件DBProxy，已在公司内部生产环境广泛使用，较为成熟、稳定。相关工作的详细介绍可以参考之前的博客文章《美团点评的DBProxy实践》。现在，我们非常高兴地将DBProxy开源，希望与业内有类似需求的团队，一起打造一款优秀的企业级数据库中间件产品。项目的Github地址是https://github.com/Meituan-Dianping/DBProxy。DBProxy的优点支持多语言MySQL客户端读写分离负载均衡Slave故障感知与摘除（Master需要MHA等其他联动）后端连接池自定义SQL拦截与过滤流量分组与控制丰富的监控状态支持分表（分库版本正在内测中）Client IP限制DBProxy对Atlas的改进新增功能点从库流量配置指定查询发送到某个从库参数动态设置(完善show p ...继续阅读 (74)

什么是前端工程化？根据具体的业务特点，将前端的开发流程、技术、工具、经验等规范化、标准化就是前端工程化。它的目的是让前端开发能够“自成体系”，最大程度地提高前端工程师的开发效率，降低技术选型、前后端联调等带来的协调沟通成本。美团点评厦门智能住宿前端研发团队通过多个前端项目开发的探索和实践，基于“约定优于配置”（Convention Over Configuration）的原则制定了一套前端工程化开发方案app-proto。本文将简要介绍其中的一些设计细节和约定。面临的业务特点智能住宿前端团队承担的前端业务主要面向B端项目，用户主要是商家、销售、运营、产品经理以及研发人员。诸如工单管理、信息管理、门锁运营、PMS（Property management system）、CRM（Customer relationship management）及AMS（Asset management system）等项目都是单页面工具类应用，特点是功能交互繁多、复杂表单，非展示类、无SEO（Search engine optimization）需求。如果这些项目脱离浏览器这个“外壳”，与传统的原生桌面GUI软件无异。换言之，这些项目就是一种运行于浏览器的工具软件。实际上，部分项目我们也确实利用CEF（Chromium Embedded Framework）等技术给其套个“外壳”，当作传统的桌面GUI ...继续阅读 (79)

本文整理自美团点评技术沙龙第14期：美团背后的故事－你不知道的美团云。美团点评技术沙龙由美团点评技术团队主办，每月一期。每期沙龙邀请美团点评及其他互联网公司的技术专家分享来自一线的实践经验，覆盖各主要技术领域。目前沙龙会分别在北京、上海和厦门等地举行，要参加下一次最新沙龙活动？赶快关注微信公众号“美团点评技术团队”。本期沙龙包括三场讲座：美团云Docker平台、美团云对象存储系统、美团四层负载均衡网关MGW。其他几场讲座的图文实录会陆续发表，请继续关注。前言在高速发展的移动互联网时代，负载均衡有着举足轻重的地位，它是应用流量的入口，对应用的可靠性和性能起着决定性的作用，因此负载均衡需要满足高性能、高可靠两个特点。MGW是美团点评自研的一款四层负载均衡，主要用于替代原有环境的四层负载均衡LVS，目前处理着美团点评数十 Gbps的流量、上千万的并发连接。本文主要介绍MGW是如何实现高性能、高可靠的。什么是负载均衡？互联网早期，业务流量比较小并且业务逻辑比较简单，单台服务器便可以满足基本的需求；但随着互联网的发展，业务流量越来越大并且业务逻辑也越来越复杂，单台机器的性能问题以及单点问题凸显了出来，因此需要多台机器来进行性能的水平扩展以及避免单点故障。但是要如何将不同的用户的流量分发到不同的服务器上面呢？早期的方法是使用DNS做负载，通过给客户端解析不同的IP地址，让客户端的流量直接到达各 ...继续阅读 (86)

团购订单系统简介美团团购订单系统主要作用是支撑美团的团购业务，为上亿美团用户购买、消费提供服务保障。2015年初时，日订单量约400万~500万，同年七夕订单量达到800万。目标作为线上S级服务，稳定性的提升是我们不断的追求。尤其像七夕这类节日，高流量，高并发请求不断挑战着我们的系统。发现系统瓶颈，并有效地解决，使其能够稳定高效运行，为业务增长提供可靠保障是我们的目标。优化思路2015年初的订单系统，和团购其它系统如商品信息、促销活动、商家结算等强耦合在一起，约50多个研发同时在同一个代码库上开发，按不同业务结点全量部署，代码可以互相修改，有冲突在所难免。同时，对于订单系统而言，有很多问题，架构方面不够合理清晰，存储方面问题不少，单点较多，数据库连接使用不合理，连接打满频发等等。针对这些问题，我们按紧迫性，由易到难，分步骤地从存储、传输、架构方面对订单系统进行了优化。具体步骤1. 存储优化订单存储系统之前的同事已进行了部分优化，但不够彻底，且缺乏长远规划。具体表现在有分库分表行为，但没有解决单点问题，分库后数据存储不均匀。此次优化主要从水平、垂直两个方面进行了拆分。垂直方面，按业务进行了分库，将非订单相关表迁出订单库；水平方面，解决了单点问题后进行了均匀拆库。这里主要介绍一下ID分配单点问题：系统使用一张表的自增来得到订单号，所有的订单生成必须先在这里insert一条数据，得到订单 ...继续阅读 (91)

前言美团酒店直连项目自2013年末开始，通过业务上的不断完善和技术上的不断改进，至今已经接入200多家供应商，其中在线酒店3万以上，在线SPU30万以上。经过两年的成长，美团酒店直连平台终于在2015年末发展为国内最大的酒店直连业务平台，其接入的业务类型也从最初的经济连锁，拓展到高星渠道、小连锁集团、非标准住宿等，获得了业界一致好评。随着美团点评的日益壮大，客户的需求和系统体量的不断增加，直连平台的技术架构和数据应用面临着诸多挑战。为了保障美团点评的用户体验度，对技术方面会提出更高的要求。如何在合作方接口极不稳定的情况下保持高可用效果？如何在不影响系统稳定性的前提下提升接口响应时间？如何解决庞大数据带来的一致性问题的同时降低系统运营风险？这些是直连平台每天都在思考的问题。技术平台和数据应用的改进完善并非一蹴而就。考虑到数据是业务运营的核心，这里先以产品数据一致性问题的解决方案作为切入点与大家分享，也希望借此抛砖引玉，欢迎更多的同学一起探讨，共同进步。为了使数据一致性完善方案更直观易懂，这里引用美团酒店直连项目中直连平台与供应商酒店产品数据一致性方案作为分析案例，通过面临问题、总体思路、解决方案和总结思考四个方面进行论述。面临问题酒店直连系统的主要工作是将供应商的酒店产品（房型），通过系统对接的方式，转化为美大点评平台可以售卖的产品（房型）。酒店产品购买是一个可预订日期跨度比较长的业 ...继续阅读 (85)

背景2016年Q3季度初，在美团外卖上单2.0项目上线后，商家和商品数量急速增长，预估商品库的容量和写峰值QPS会很快遇到巨大压力。随之而来也会影响线上服务的查询性能、DB（数据库，以下统一称DB）主从延迟、表变更困难等一系列问题。要解决上面所说的问题，通常有两种方案。第一种方案是直接对现有的商品库进行垂直拆分，可以缓解目前写峰值QPS过大、DB主从延迟的问题。第二种方案是对现有的商品库大表进行分库分表，从根本上解决现有问题。方案一实施起来周期较短，但只能解决一时之痛，由此可见，分库分表是必然的。在确定分库分表的方案之后，我们调研了外卖订单、结算以及主站等业务的分库分表实现方案，也调研了业界很多分库分表中间件。在综合考虑性能、稳定性及实现成本的前提下，最终决定自主研发客户端分库分表中间件MTDDL来支撑外卖商品分库分表项目，这也就是MTDDL的由来。当然，在MTDDL的设计研发过程中，我们充分考虑了MTDDL的通用性、可扩展性、功能的全面性和接入的便利性。到目前为止一共开发了四期，实现了MySQL动态数据源、读写分离、分布式唯一主键生成器、分库分表、连接池及SQL监控、动态化配置等一系列功能，支持分库分表算法、分布式唯一主键生成算法的高可扩展性，而且支持全注解的方式接入，业务方不需要引入任何配置文件。下面就部分业界方案及MTDDL的设计目标详细展开下，然后从源码的角度来剖析下MTD ...继续阅读 (100)

性能问题是造成App用户流失的罪魁祸首之一。App的性能问题包括崩溃、网络请求错误或超时、响应速度慢、列表滚动卡顿、流量大、耗电等等。而导致App性能低下的原因有很多，除去设备硬件和软件的外部因素，其中大部分是开发者错误地使用线程、锁、系统函数、编程范式、数据结构等导致的。即便是最有经验的程序员，也很难在开发时就能避免所有导致性能低下的“坑”，因此解决性能问题的关键是在于能不能尽早地发现和定位这些“坑”。美团外卖在实践中通过总结常见性能问题，并在学习了业内微信、360等性能监控技术原理后，开发了一套移动端性能监控解决方案——Hertz（赫兹）。Hertz的目标是实现这三个功能：开发时期，检查性能异常点并通知给开发者；测试时期，和现有测试工具结合产生性能测试报告；上线时期，通过监控平台上报性能数据，实现线上问题定位和追查。要实现这三个功能，首先要采集到可衡量、有价值的性能数据，因此性能数据的采集是我们关注的最核心的问题之一。数据采集虽然用户可以感知到的性能问题多种多样，我们仍然可以将其抽象成具体的监控指标。在Hertz中这些监控指标包括：FPS、CPU使用率、内存占用、卡顿、页面加载时间、网络请求流量等。这其中有的性能指标比较容易获取，例如FPS、CPU使用率、内存占用等，有的性能指标不易获取，例如卡顿、页面加载时间、网络请求流量等。例如在iOS中我们可以这样获取FPS：- (voi ...继续阅读 (88)

背景图1 外卖排序系统框架外卖的排序策略是由机器学习模型驱动的，模型迭代效率制约着策略优化效果。如上图所示，在排序系统里，特征是最为基础的部分：有了特征之后，我们离线训练出模型，然后将特征和模型一起推送给线上排序服务使用。特征生产Pipeline对于策略迭代的效率起着至关重要的作用。经过实践中的积累和提炼，我们整理出一套通用的特征生产框架，大大节省开发量，提高策略迭代效率。外卖排序系统使用GBDT（Gradient Boosting Decision Tree）树模型，比较复杂。受限于计算能力，除了上下文特征（如时间、地域、终端类型、距离等）之外，目前使用的主要是一些宽泛的统计特征，比如商家销量、商家单均价、用户的品类偏好等。这些特征的生产流程包括：离线的统计、离线到在线的同步、在线的加载等。图2 特征生产流程如上图，目前外卖排序的特征生产流程主要有：特征统计：基于基础数据表（如曝光表、点击表、订单表等），统计若干时段内特定维度的总量、分布等，如商家月均销量、用户不同品类下单占比。统计结果存储于Hive表。这部分工作，简单的可基于ETL，复杂的可基于Spark。产出的特征可供离线训练和线上预测，本文主要围绕线上展开。特征推送：Hive表里的数据需要存入KV，以便线上实时使用。这一步，首先要将Hive表里的记录映射成POJO类（称为Domain类），然后将其序列化，最后将序列化串存入 ...继续阅读 (81)

前言《HDFS NameNode内存全景》中，我们从NameNode内部数据结构的视角，对它的内存全景及几个关键数据结构进行了简单解读，并结合实际场景介绍了NameNode可能遇到的问题，还有业界进行横向扩展方面的多种可借鉴解决方案。事实上，对NameNode实施横向扩展前，会面临常驻内存随数据规模持续增长的情况，为此需要经历不断调整NameNode内存的堆空间大小的过程，期间会遇到几个问题：当前内存空间预期能够支撑多长时间。何时调整堆空间以应对数据规模增长。增加多大堆空间。另一方面NameNode堆空间又不能无止境增加，到达阈值后（与机型、JVM版本、GC策略等相关）同样会存在潜在问题：重启时间变长。潜在的FGC风险。由此可见，对NameNode内存使用情况的细粒度掌控，可以为优化内存使用或调整内存大小提供更好的决策支持。本文在前篇《HDFS NameNode内存全景》文章的基础上，针对前面的几个问题，进一步对NameNode核心数据结构的内存使用情况进行详细定量分析，并给出可供参考的内存预估模型。根据分析结果可有针对的优化集群存储资源使用模式，同时利用内存预估模型，可以提前对内存资源进行合理规划，为HDFS的发展提供数据参考依据。内存分析NetworkTopologyNameNode通过NetworkTopology维护整个集群的树状拓扑结构，当集群启动过程中，通过机架感知（通 ...继续阅读 (87)

本文要感谢我职级评定过程中的一位评委，他建议把之前所做的各种性能优化的案例和方案加以提炼、总结，以文档的形式沉淀下来，并在内部进行分享。力求达到如下效果：1. 形成可实践、可借鉴、可参考的各种性能优化的方案以及选型考虑点，同时配合具体的真实案例，其他人遇到相似问题时，不用从零开始。2. 有助于开阔视野，除了性能优化之外，也能提供通用的常见思路以及方案选型的考虑点，帮助大家培养在方案选型时的意识、思维以及做各种权衡的能力。文章在内部分享后，引起强烈分享，得到了不少同事和朋友的认可和好评，觉得对日常的工作有很好的指导作用。考虑到这些经验可能对业界同行也有帮助，所以在美团点评技术团队博客公开。常见性能优化策略分类代码之所以把代码放到第一位，是因为这一点最容易引起技术人员的忽视。很多技术人员拿到一个性能优化的需求以后，言必称缓存、异步、JVM等。实际上，第一步就应该是分析相关的代码，找出相应的瓶颈，再来考虑具体的优化策略。有一些性能问题，完全是由于代码写的不合理，通过直接修改一下代码就能解决问题的，比如for循环次数过多、作了很多无谓的条件判断、相同逻辑重复多次等。数据库数据库的调优，总的来说分为以下三部分：SQL调优这是最常用、每一个技术人员都应该掌握基本的SQL调优手段（包括方法、工具、辅助系统等）。这里以MySQL为例，最常见的方式是，由自带的慢查询日志或者开源的慢查询系统定位到具体 ...继续阅读 (69)

红黑树是平衡二叉查找树的一种。为了深入理解红黑树，我们需要从二叉查找树开始讲起。BST二叉查找树（Binary Search Tree，简称BST）是一棵二叉树，它的左子节点的值比父节点的值要小，右节点的值要比父节点的值大。它的高度决定了它的查找效率。在理想的情况下，二叉查找树增删查改的时间复杂度为O(logN)（其中N为节点数），最坏的情况下为O(N)。当它的高度为logN+1时，我们就说二叉查找树是平衡的。BST的查找操作T key = a search key Node root = point to the root of a BST while(true){ if(root==null){ break; } if(root.value.equals(key)){ return root; } else if(key.compareTo(root.value)<0){ root = root.left; } else{ root = root.right; } } return null;从程序中可以看出，当BST查找的时候，先与当前节点进行比较：如果相等的话就返回当前节点；如果少于当前节点则继续查找当前节点的左节点；如果大于当前节点则继续查找 ...继续阅读 (74)

介绍客户关系管理系统（CRM系统）是管理公司当前以及未来潜在客户的系统，其主要目的是通过优化客户关系实现公司销售业绩的长期增长，它是企业信息系统的核心之一。目前，移动互联网、大数据以及人工智能技术发展日新月异，正在加速改变世界。但是在CRM等企业系统的构建和优化方法论上，却缺乏革命性的创新。本文作者在构建和优化CRM系统的过程中总结出一些新方法论，与当下的一些先进理念不谋而合。每个具体的理念虽然并非原创，应用在CRM系统构建中还算新颖，并且所有的理念一起构成一个完整的体系。希望这些对负责CRM系统开发的管理者、工程师、产品人员有所帮助。CRM系统的构建和优化本质上是一个工程学问题。解决好一个工程学问题需要把控好四个主要环节：明确该工程的主要目标。理清实现该目标的方法论。构建快速支撑方法论实施的架构和系统。打造一个优秀的团队。本文基于这条线进行阐述。第一部分主要讨论CRM系统的目标以及方法论。第二部分通过具体案例详细阐述方法论实施。本文第三部分是关于如何设计灵活可扩展系统架构。最后一部分总结了在团队管理方面的一些心得。CRM系统目标和方法论搭建优秀的CRM系统的前提是清晰的目标，然后寻找实现系统目标的系统性的方法论。在方法论和目标之间建立关联是一个复杂的分析过程。我们采用严谨的数学方法，从CRM系统目标中推导出独特的方法论。确定了方法论之后，我们将深度阐述其具体内涵以及层次。本小节的 ...继续阅读 (77)

自动化测试是研发人员进行质量保障的重要一环，良好的自动化测试机制能够让开发者及早发现编码中的逻辑缺陷，将风险前置。日常研发中，由于快速迭代的原因，我们经常需要在各个业务线上进行主流程回归测试，目前这种测试大部分由人工进行，费时费力，重复劳动多。如果能将UI自动化测试与主流程回归结合到一起，一方面保证了代码质量，另一方面大大节约人力成本，可谓一举两得。为什么需要UI自动化测试原因主要是以下三点：保证质量——及早发现代码缺陷，风险前置。减少重复劳动，节约人力——快速迭代中经常需要进行主流程回归，测试完整个主流程，需要耗费相当大的人力成本。统一标准——每个人对测试用例以及业务理解程度不同，标准可能存在不一致。进行UI自动化测试面临的问题工具选择。降低对后端的依赖，避免因为测试环境后端不稳定导致的测试失败。整合测试用例，增加复用，降低用例维护成本。自动化测试工具对比业界UI测试工具发展迅速，目前有Robotium、Appium、Espresso、UIAutomator、Calabash等等，其中在Android中应用最广泛的当属UIAutomator、Robotium、Appium。下面列表比较说明：UIAutomatorRobotiumAppium支持平台AndroidAndroid，H5Android，iOS，H5脚本语言JavaJavaAlmost any是否支持无源码测试YesYe ...继续阅读 (80)

背景原大众点评的订单单表早就已经突破两百G，由于查询维度较多，即使加了两个从库，优化索引，仍然存在很多查询不理想的情况。去年大量抢购活动的开展，使数据库达到瓶颈，应用只能通过限速、异步队列等对其进行保护；业务需求层出不穷，原有的订单模型很难满足业务需求，但是基于原订单表的DDL又非常吃力，无法达到业务要求。随着这些问题越来越突出，订单数据库的切分就愈发急迫了。这次切分，我们的目标是未来十年内不需要担心订单容量的问题。垂直切分先对订单库进行垂直切分，将原有的订单库分为基础订单库、订单流程库等，本文就不展开讲了。水平切分垂直切分缓解了原来单集群的压力，但是在抢购时依然捉襟见肘。原有的订单模型已经无法满足业务需求，于是我们设计了一套新的统一订单模型，为同时满足C端用户、B端商户、客服、运营等的需求，我们分别通过用户ID和商户ID进行切分，并通过PUMA（我们内部开发的MySQL binlog实时解析服务）同步到一个运营库。切分策略1. 查询切分将ID和库的Mapping关系记录在一个单独的库中。优点：ID和库的Mapping算法可以随意更改。缺点：引入额外的单点。2. 范围切分比如按照时间区间或ID区间来切分。优点：单表大小可控，天然水平扩展。缺点：无法解决集中写入瓶颈的问题。3. Hash切分一般采用Mod来切分，下面着重讲一下Mod的策略。数据水平切分后我们希望是一劳永逸或者是易于水 ...继续阅读 (80)

概述作为一个android开发者，在开发应用时，随着业务规模发展到一定程度，不断地加入新功能、添加新的类库，代码在急剧的膨胀，相应的apk包的大小也急剧增加， 那么终有一天，你会不幸遇到这个错误：生成的apk在android 2.3或之前的机器上无法安装，提示INSTALL_FAILED_DEXOPT方法数量过多，编译时出错，提示：Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536而问题产生的具体原因如下：无法安装（Android 2.3 INSTALL_FAILED_DEXOPT）问题，是由dexopt的LinearAlloc限制引起的，在Android版本不同分别经历了4M/5M/8M/16M限制，目前主流4.2.x系统上可能都已到16M， 在Gingerbread或者以下系统LinearAllocHdr分配空间只有5M大小的， 高于Gingerbread的系统提升到了8M。Dalvik linearAlloc是一个固定大小的缓冲区。在应用的安装过程中，系统会运行一个名为dexopt的程序为该应用在当前机型中运行做准备。dexopt使用LinearAlloc来存储应用的方法信息。Android 2.2和2.3的缓冲区只有5MB，Android ...继续阅读 (111)