跨境物流链路怎么做?菜鸟工程师打造了全球通关“神器”

阿里妹导读:2018天猫双11物流订单量创新高,突破10亿件,这是一次史无前例的物流洪峰。天猫双11十年来,见证了物流业从手写地址、人工分拣,到电子面单、机器人分拣。无论是物流园区、干线运输,还是秒级通关、末端配送,都通过技术高效连接,智能物流骨干网正在加快实现行业数字化、智能化升级。因此,阿里技术推出《菜鸟智慧新物流》专题,邀请菜鸟技术人,为你揭秘物流核心技术。今天第一期,让我们一起走近神秘的“神鲸网络全球通关平台”,全方位了解新技术时代下的跨境智能关务。前言“跨境”,这是在当今行业一个非常 fashion的名词。从2014年起,海关总署陆续颁发多项跨境贸易政策,给跨境进出口业务带来了诸多红利。2014年也被很多业内人士称为跨境进口电商元年。也许你会听到这样一段对话:A:Hey,兄dei,你是做什么的?B:哦,我搞跨境物流的。A:是嘛,跨境这几年很火啊!政府在大力扶持这一块,我看很多公司都在做一块,有前途!B:哪有?道路坎坷,很艰辛的,不过累并快乐着,我也挺看好这块的!在整个跨境物流链路中,会涉及到多个角色:仓、干线、关务、快递等。关务是跨境物流链路最核心的环节,需要协同海关,国检等政府部门完成整个进出口国的通关操作。这块不仅业务复杂,而且存在诸多不确定性。为此,我们搭建了“神鲸网络全球通关平台”。旨在对接海关,协同CP(cainiao partner),从线下到线上,以全球化、数据化、智能化为方向,以快速、轻量、多态为核心目标,为跨境电商客户提供全球一体化的通关解决方案!痛点和挑战如下是整个通关全链路业务流程,包含资质备案、风控、出入区、跨境通关、税汇等核心领域。整个链路交互节点繁多,不同国家,甚至不同监管区在申报模式,交互方式,通关能力上都存在很大差别,另外由于申报链路冗长,任何一个节点出现抖动都有可能导致整个通关发生异常,进而导致申报时效拖长,为保障用户能够正常通关,我们往往需要投入更多的成本去解决申报链路过程发生的种种问题。所以,如何有效使用海关通关能力,给到跨境商户稳定的、高效的、统一的一站式通关解决方案?这是我们需要攻克的核心难题。应对策略通关异常繁多,申报时效冗长,大促成本飙高是大部分跨境通关企业碰到的问题。如何去异常,打时效,降成本,保障通关丝般顺滑?基于此,在神鲸网络通关平台中,我们做了诸多举措,有一体化监控的星宫大盘,阳关道批量申报,政企协同全链路摸高压测以及守护神智能辅助系统等等。今年的双十一大促上,因为有这些强有力的后盾,加上海关通关能力再创新高,大家在喝茶+聊天中度过了一个轻松愉快的双十一。今天,我们重点来交流下星宫大盘、批量申报和智能辅助系统。星宫大盘,一体化监控整个通关链路长,依赖系统多,如果有一个全链路的监控系统进行护卫,不仅可以实时窥视整个链路流转情况,还可以做到异常的实时跟踪处理。为此,我们搭建了关务数据中心,承载关务所有数据,并依托它构建了整个星宫大盘产品,将业务监控,指标监控,系统监控一体化,真正实现360度无死角主动监控。如下图(注:下图中数据非真实数据,仅做示例):数据中心数据中心涵盖了整个关务生态的数据,通过实时+离线两种方式,很好的支撑了实时业务监控和指标监控等核心业务。如下是整个数据中心核心架构,包含消息接入,指标计算,数据存储等核心模块。作为一个数据产品,最基本的的诉求就是能保证数据实时性、准确性,那怎么在大促情况下能够做到99.99%数据准确性?这是数据中心面临的最大的一个挑战。实时性(秒级生效)业务系统通过消息埋点的方式记录各个链路节点数据,通过阿里消息中间件消息异步推送给数据中心。数据中心拥有一个支持水平扩展的庞大的服务器集群,具有强大的消息处理能力,保证消息的实时消费。通过缓存+异步存储的方式提升整体消息处理能力; 存储之前先往缓存存一份,后面热点查询优先从缓存获取数据,提高查询效率,数据插入如果超时或者失败立即创建调度任务进行异步重试插入。准确性(99.99%)由于关务业务特殊性,星宫需要保证监控数据的准确性,传统的方案一般是通过流计算的方式把数据统计出来,这种方案统计和详情数据是分开的,可能会导致数据统计和真实数据存在误差的情况,这对于星宫来说是不可接受的。为此,项目组另辟蹊径采用实时详情数据聚合的方案,这里,我们引入了ES中间件,阿里中间件团队针对ES做了非常多的优化,具有高性能的聚合能力,支持海量级数据的实时聚合。另外我们在数据结构存储上面做了多层优化,比如:热点查询条件用int来逻辑映射,字段存储底层采用列存储。为了加快检索,存储树形结构把目录加载到缓存,犹如数据字典一样。另外为了保证数据消费不丢失,在客户端启动了多层重试机制,保证数据的最终一致性。今年大促上,数据中心表现出色,双11当天QPS达到40000+ 平均耗时11ms,正是这种强大的数据消费能力保证了星宫数据实时性,另外亿级别数据多维度聚合统计基本上都是秒级返回,真正做到了100%可用。批量申报,独木桥变阳关道由于海关各个节点大多采用MQ+FTP的技术架构,文件数的个数会影响整体通道消费能力。另外总署的56号公告要求四单申报进行加签操作,随之带来的将是验签成本的增加。为减轻总署通道压力,并提升验签能力,我们采用了批量申报的策略,简而言之就是将多个订单聚合到一起进行申报,一次加签操作,一次申报动作。如下:批量申报调度模块自研了一个轻量的批量调度框架实现,通过一个任务池汇总所有任务,按照不同业务规则聚合同类型的任务然后进行消费。如下:记得当时该项目刚上线时,还有一个小插曲,压测下来发现整体性能远远达不到要求,这可急坏了整个项目组。任务消费过程大体分为:分页捞取任务-》锁定任务-》消费任务。其中捞取任务和锁定任务过程是通过抢占分布式锁的方式来防止并发,避免同一个任务被多个线程捞取并消费。正式由于这个分布式锁的限制以及单库单表的DB瓶颈,导致整体性能一直上不去。经过讨论,最终我们采用了分布式锁池+DB散列方案。即既然单个分布式锁无法满足要求,那么设计成锁池好了;既然单库单表存在瓶颈,那按照业务关键字进行散列。分布式锁池我们使用的是redis的Set数据结构+spop和sadd命令实现的,应用启动时初始化指定个数的锁放到Set数据结构中,然后通过spop随机获取一个模值捞取任务,任务锁定后再通过sadd返还锁,插入任务时也是通过锁个数进行随机散列到多个库多个表中。通过该机制改造后,整体性能大大提升,数据库压力也降低了好几倍。这次微小的调整,却带来了巨大的性能提升,在今年双十一大促上,批量申报也是大放异彩,整个通关审单时效大大降低,申报能力相比往年也有质的提升。如下是17年和18年双十一某一属地海关的平均审单时效对比,相比17年,今年的平均审单时效非常稳定,基本保持在20分钟以内,海关上行和下行通道毫无压力。如下是某海关30分钟内审单完成率情况,相比往年,今年审单能力有巨大的飞跃,基本上是零堆积,申报速度跟审单速度几乎持平。智能辅助系统,关务守护神今年是关务的智能化元年,在正向申报链路上,我们推出了智能限流与智能hold单产品,自适应保护自身与海关系统。在人工成本降低的同时,保证了海关系统的最大吞吐能力。在异常处理上,我们基于规则引擎上线了异常智能处理系统,通过不断丰富异常处理规则,系统变得越来越聪明,基本上可以自动处理大部分海关异常。同时,作为关务智能大脑,还为关务数据中心提供数据分析服务。智能系统包含产品如下:智能限流整个智能限流的设计不仅支持集群环境下任意接口秒级与分钟级精准限流,还能根据接口的RT与失败率等指标对接口流量进行动态调节。1.技术架构:智能限流分三个主要模块:资源监控(对资源的请求量精准统计)、限流策略(请求量达到阈值后的操作)、智能调控(依据一定的规则与算法调节)。智能限流整体采用了pipeline的设计模式,目前实现了单机限流、集群限流和自适应限流三个阀门,只有全部通过阀门,请求才能被放行,否则就会被拦截。这种设计便于维护以及后期限流策略的扩展,例如在双十一之前紧急增加的集群分钟级限流(开发测试仅半个人日)。单机限流和集群限流都是固定限流,即人为提前设定好接口的限流值,如果请求量超过这个值,便会被流控。人工限流的关键是对请求量的精准统计。动态限流则会依赖一些指标进行实时计算和分析,系统按照一定规则自行判断是否需要限流,这个限流是将接口能力分为档位进行调整,既会下调,也会自动上调恢复接口的能力。2.资源监控资源监控是指统计某个接口的各种指标,包含请求量/失败量/限流量等,这些指标基本上是在单台机器上的统计。但是在限流场景,单机限流仅仅能保护机器本身,对于下游的保护,还是需要集群限流功能,因此还需要对集群环境下的资源访问统计。单机指标统计单机指标主要是基于滑动窗口的原理进行统计,比如QPS(每秒的请求数)的统计是将1秒分为5个时间窗口,每个窗口统计200ms内的请求,最后做累加。单机指标监控主要是做单机限流,单机限流的最大好处是能够保障单台机器不会被上游压垮。而对下游而言,单机限流可用性较低,对集群数据来说准确性不能保障。集群指标统计我们不仅仅要保护自己,还要保护下游系统,因此需要保证集群环境下给到下游的量是精确可控制的。集群指标统计需要借助分布式缓存实现,通过使用incr原子累加功能,实现在分布式环境下对请求量的统计。针对QPS的统计,缓存的key由接口名称+秒级时间戳(yyyyMMddmmSS)组成,例如:xxxx_20181118012012。集群统计的准确性依赖两个点:一个是分布式缓存的性能,另一个是分布式环境下每台机器的时间一致性(NTP网络可以保证)。智能限流的缓存使用的是阿里集团的tair(MDB),单次读写平均在5ms以内,对于并发量不是特别大的业务系统来说误差完全可以接受。3.限流策略通过对资源的准确监控,人工固定限流比较容易实现,只要比较下当前的实际qps值和设定的qps值大小即可,达到设定的限流值该请求就会被终止(目前通过抛出指定类型的异常)。无论是秒级还是分钟级限流,只是监控的粒度不同,即统计的key的时间戳的区别,对于限流的逻辑完全一致。在限流时,我们还会进行主动通知,便于人工干预。异常智能处理异常智能处理主要是在日常和大促后的扫尾阶段发挥重要作用。它以关务知识大脑为核心,协同CP、小二、系统共同高效解决业务异常。处理的异常越多,沉淀的就越多,系统也会越来越智能。关务异常存在繁、杂、多、变等特点,如果靠人工去处理每一个异常订单,需要投入巨大的成本,时效也无法得到保障,在大促期间,异常订单量更是以百倍级别增长。技术是第一生产力,我们需要机器代替人工处理这些异常,系统自动处理也就应运而生。然而,经过不断的实践证明,短期单纯依赖系统自动处理所有的异常是不现实的,有部分还是需要人工介入(比如备案问题),然后再利用系统进行重新申报。因此,异常智能处理系统的目标是:搭建人机交互闭环机制,沉淀底层知识大脑,快速提高异常处理的智能化程度。在底层实现上,我们搭建了一套规则库用于知识沉淀,上层实时监听海关异常回执,实现大部分异常秒级处理;同时,启动定时异常处理任务,每天定点捞取遗漏订单进行处理;最后,为小二和CP推送需要人工介入的异常订单,处理完后再推送到系统,由系统接着处理后续流程。展望未来在全球化的道路上,我们任重而道远,AI智能,大数据协同是未来的方向,基于人工智能方式实现全球通关的丝般顺滑,让全球通关更简单!这是我们的宗旨和目标,我们会一步一个脚印一直走下去!未来的路还很长,我们迫切需要有更多的能人异士加入,一起谱写旷世不灭的传奇。如果你足够优秀,如果你不甘平庸,来吧,让我们一起风骚前行!本文作者:啸鹏阅读原文本文来自云栖社区合作伙伴“阿里技术”,如需转载请联系原作者。

December 4, 2018 · 1 min · jiezi

云数据库POLARDB优势解读之①——10分钟了解

什么是POLARDBPOLARDB 是阿里云自研的下一代关系型分布式数据库,100%兼容MySQL,之前使用MySQL的应用程序不需要修改一行代码,即可使用POLARDB。POLARDB在运行形态上是一个多节点集群,集群中有一个Writer节点(主节点)和多个Reader节点,他们之间节点间通过分布式文件系统(PolarFileSystem)共享底层的同一份存储(PolarStore)。POLARDB通过内部的代理层(Proxy)对外提供服务,也就是说所有的应用程序都先经过这层代理,然后才访问到具体的数据库节点。Proxy不仅可以做安全认证(Authorization)和保护(Protection),还可以解析SQL,把写操作(比如事务、Update、Insert、Delete、DDL等)发送到Writer节点,把读操作(比如Select)均衡地分发到多个Reader节点,这个也叫读写分离。POLARDB对外默认提供了两个数据库地址,一个是集群地址(Cluster),一个是主地址(Primary),推荐使用集群地址,因为它具备读写分离功能可以把所有节点的资源整合到一起对外提供服务。主地址是永远指向主节点,访问主地址的SQL都被发送到主节点,当发生主备切换(Failover)时,主地址也会在30秒内自动漂移到新的主节点上,确保应用程序永远连接的都是可写可读的主节点。如上图,底层一套存储,节省成本,是『合』;中间多个节点,提高扩展性,是『分』;上层一套代理层,统一入口,使用简单,也是『合』。如此『合-分-合』的架构,在扩展性和使用便捷性之间保持了平衡,使得对于上层应用程序来说,就像使用一个单点的MySQL数据库一样简单。如何使用POLARDB部署在云端,创建时先选择使用的地域可用区和具体的VPC网络,然后指定节点的数量(从 2个 到 16 个)和配置(从 2核 到 88核)即可,存储空间不用提前配置,也不需要关心容量大小,系统会根据实际的使用量自动收取费用。创建过程可能持续5-10分钟,然后配置好白名单、创建完高权限账号就可以使用了。逻辑DB和账号User,可以在控制台创建,也可以通过高权限账号登录到数据库执行SQL创建,二者效果完全一样,没有区别。如果您需要迁移老的数据库到POLARDB,推荐使用DTS。不管源库是在RDS,还是在ECS自建MySQL,甚至是在云下有公网地址可访问的MySQL,都可以通过DTS做在线平滑迁移,停机时间5-10分钟。特点除了可以像使用MySQL一样使用POLARDB,这里还有一些传统MySQL数据库不具备的优势。容量大最高100T,不再因为单机容量的天花板而去购买多个MySQL实例做Sharding,甚至也不需要考虑分库分表,简化应用开发,降低运维负担。高性价比多个节点只收取一份存储的钱,也就是说只读实例越多越划算。分钟级弹性存储与计算分离的架构,再加上共享存储,使得快速升级成为现实。读一致性集群的读写分离地址,利用LSN(Log Sequence Number)确保读取数据时的全局一致性,避免因为主备延迟引起的不一致问题。毫秒级延迟——物理复制利用基于Redo的物理复制代替基于Binlog的逻辑复制,提升主备复制的效率和稳定性。即使是加索引、加字段的大表DDL操作,也不会对数据库造成延迟。无锁备份利用存储层的快照,可以在60秒内完成2T数据量大小的数据库的备份。并且这个备份过程不需要对数据库加锁,对应用程序几乎无影响,全天24小时均可进行备份。复杂SQL查询加速内置并行查询引擎,对执行时长超过1分钟的复杂分析类SQL加速效果明显。该功能需要额外连接地址。本文作者:乙休阅读原文本文为云栖社区原创内容,未经允许不得转载。

November 29, 2018 · 1 min · jiezi

Kubernetes 弹性伸缩全场景解析 (一)- 概念延伸与组件布局

传统弹性伸缩的困境弹性伸缩是Kubernetes中被大家关注的一大亮点,在讨论相关的组件和实现方案之前。首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实际负载的矛盾。如上图所示,蓝色的水位线表示集群的容量随着负载的提高不断的增长,红色的曲线表示集群的实际的负载真实的变化。而弹性伸缩要解决的就是当实际负载出现激增,而容量规划没有来得及反应的场景。常规的弹性伸缩是基于阈值的,通过设置一个资源缓冲水位来保障资源的充盈,通常15%-30%左右的资源预留是比较常见的选择。换言之就是通过一个具备缓冲能力的资源池用资源的冗余换取集群的可用。这种方式表面上看是没有什么问题的,确实在很多的解决方案或者开源组件中也是按照这种方式进行实现的,但是当我们深入的思考这种实现方案的时候会发现,这种方式存在如下三个经典问题。1. 百分比碎片难题在一个Kubernetes集群中,通常不只包含一种规格的机器,针对不同的场景、不同的需求,机器的配置、容量可能会有非常大的差异,那么集群伸缩时的百分比就具备非常大的迷惑性。假设我们的集群中存在4C8G的机器与16C32G的机器两种不同规格,对于10%的资源预留,这两种规格是所代表的意义是完全不同的。特别是在缩容的场景下,通常为了保证缩容后的集群不处在震荡状态,我们会一个节点一个节点或者二分法来缩容节点,那么如何根据百分比来判断当前节点是处在缩容状态就尤为重要,此时如果大规格机器有较低的利用率被判断缩容,那么很有可能会造成节点缩容后,容器重新调度后的争抢饥饿。如果添加判断条件,优先缩容小配置的节点,则有可能造成缩容后资源的大量冗余,最终集群中可能会只剩下所有的巨石节点。2. 容量的规划炸弹还记得在没有使用容器前,是如何做容量规划的吗?一般会按照应用来进行机器的分配,例如,应用A需要2台4C8G的机器,应用B需要4台8C16G的机器,应用A的机器与应用B的机器是独立的,相互不干扰。到了容器的场景中,大部分的开发者无需关心底层的资源了,那么这个时候容量规划哪里去了呢?在Kubernetes中是通过Request和Limit的方式进行设置,Request表示资源的申请值,Limit表示资源的限制值。既然Request和Limit才是容量规划的对等概念,那么这就代表着资源的实际计算规则要根据Request和Limit才更加准确。而对于每个节点预留资源阈值而言,很有可能会造成小节点的预留无法满足调度,大节点的预留又调度不完的场景。3. 资源利用率困境集群的资源利用率是否可以真的代表当前的集群状态呢?当一个Pod的资源利用率很低的时候,不代表就可以侵占他所申请的资源。在大部分的生产集群中,资源利用率都不会保持在一个非常高的水位,但从调度来讲,资源的调度水位应该保持在一个比较高的水位。这样才能既保证集群的稳定可用,又不过于浪费资源。如果没有设置Request与Limit,而集群的整体资源利用率很高这意味着什么?这表示所有的Pod都在被以真实负载为单元进行调度,相互之间存在非常严重的争抢,而且简单的加入节点也丝毫无法解决问题,因为对于一个已调度的Pod而言,除了手动调度与驱逐没有任何方式可以将这个Pod从高负载的节点中移走。那如果我们设置了Request与Limit而节点的资源利用率又非常高的时候说明了什么呢?很可惜这在大部分的场景下都是不可能的,因为不同的应用不同的负载在不同的时刻资源的利用率也会有所差异,大概率的情况是集群还没有触发设置的阈值就已经无法调度Pod了。弹性伸缩概念的延伸既然基于资源利用率的弹性伸缩有上述已知的三个问题,有什么办法可以来解决呢?随着应用类型的多样性发展,不同类型的应用的资源要求也存在越来越大的差异。弹性伸缩的概念和意义也在变化,传统理解上弹性伸缩是为了解决容量规划和在线负载的矛盾,而现在是资源成本与可用性之间的博弈。如果将常见的应用进行规约分类,可以分为如下四种不同类型:在线任务类型比较常见的是网站、API服务、微服务等常见的互联网业务型应用,这种应用的特点是对常规资源消耗较高,比如CPU、内存、网络IO、磁盘IO等,对于业务中断容忍性差。离线任务类型例如大数据离线计算、边缘计算等,这种应用的特点是对可靠性的要求较低,也没有明确的时效性要求,更多的关注点是成本如何降低。定时任务类型定时运行一些批量计算任务是这种应用的比较常见形态,成本节约与调度能力是重点关注的部分。特殊任务类型例如闲时计算的场景、IOT类业务、网格计算、超算等,这类场景对于资源利用率都有比较高的要求。单纯的基于资源利用率的弹性伸缩大部分是用来解决第一种类型的应用而产生的,对于其他三种类型的应用并不是很合适,那么Kubernetes是如何解决这个问题的呢?kubernetes的弹性伸缩布局Kubernetes将弹性伸缩的本质进行了抽象,如果抛开实现的方式,对于不同应用的弹性伸缩而言,该如何统一模型呢?Kubernetes的设计思路是将弹性伸缩划分为保障应用负载处在容量规划之内与保障资源池大小满足整体容量规划两个层面。简单理解,当需要弹性伸缩时,优先变化的应该是负载的容量规划,当集群的资源池无法满足负载的容量规划时,再调整资源池的水位保证可用性。而两者相结合的方式是无法调度的Pod来实现的,这样开发者就可以在集群资源水位较低的时候使用HPA、VPA等处理容量规划的组件实现实时极致的弹性,资源不足的时候通过Cluster-Autoscaler进行集群资源水位的调整,重新调度,实现伸缩的补偿。两者相互解耦又相互结合,实现极致的弹性。在Kubernetes的生态中,在多个维度、多个层次提供了不同的组件来满足不同的伸缩场景。如果我们从伸缩对象与伸缩方向两个方面来解读Kubernetes的弹性伸缩的话,可以得到如下的弹性伸缩矩阵。cluster-autoscaler:kubernetes社区中负责节点水平伸缩的组件,目前处在GA阶段(General Availability,即正式发布的版本)。HPA:kubernetes社区中负责Pod水平伸缩的组件,是所有伸缩组件中历史最悠久的,目前支持autoscaling/v1、autoscaling/v2beta1与autoscaling/v2beta2,其中autoscaling/v1只支持CPU一种伸缩指标,在autoscaling/v2beta1中增加支持custom metrics,在autoscaling/v2beta2中增加支持external metrics。cluster-proportional-autoscaler:根据集群的节点数目,水平调整Pod数目的组件,目前处在GA阶段。vetical-pod-autoscaler:根据Pod的资源利用率、历史数据、异常事件,来动态调整负载的Request值的组件,主要关注在有状态服务、单体应用的资源伸缩场景,目前处在beta阶段。addon-resizer:根据集群中节点的数目,纵向调整负载的Request的组件,目前处在beta阶段。在这五个组件中,cluster-autoscaler、HPA、cluster-proportional-autoscaler是目前比较稳定的组件,建议有相关需求的开发者进行选用。对于百分之八十以上的场景,我们建议客户通过HPA结合cluster-autoscaler的方式进行集群的弹性伸缩管理,HPA负责负载的容量规划管理而cluster-autoscaler负责资源池的扩容与缩容。最后在本文中,和大家主要讨论的是在云原生时代下弹性伸缩概念的延伸,以及Kubernetes社区是如何通过解耦的方式通过多个转职的组件实现了两个维度的弹性伸缩,在本系列后面的文章中会为一一解析每个弹性伸缩组件的相关原理与用法。本文作者:莫源阅读原文本文为云栖社区原创内容,未经允许不得转载。

November 23, 2018 · 1 min · jiezi

阿里如何做到百万量级硬件故障自愈?

随着阿里大数据产品业务的增长,服务器数量不断增多,IT运维压力也成比例增大。各种软、硬件故障而造成的业务中断,成为稳定性影响的重要因素之一。本文详细解读阿里如何实现硬件故障预测、服务器自动下线、服务自愈以及集群的自平衡重建,真正在影响业务之前实现硬件故障自动闭环策略,对于常见的硬件故障无需人工干预即可自动闭环解决。1.背景1.1.面临挑战对于承载阿里巴巴集团95%数据存储及计算的离线计算平台MaxCompute,随着业务增长,服务器规模已达到数十万台,而离线作业的特性导致硬件故障不容易在软件层面被发现,同时集团统一的硬件报障阈值常常会遗漏一些对应用有影响的硬件故障,对于每一起漏报,都对集群的稳定性构成极大的挑战。针对挑战,我们面对两个问题:硬件故障的及时发现与故障机的业务迁移。下面我们会围绕这两个问题进行分析,并详细介绍落地的自动化硬件自愈平台——DAM。在介绍之前我们先了解下飞天操作系统的应用管理体系——天基(Tianji)。1.2.天基应用管理MaxCompute是构建在阿里数据中心操作系统——飞天(Apsara)之上,飞天的所有应用均由天基管理。天基是一套自动化数据中心管理系统,管理数据中心中的硬件生命周期与各类静态资源(程序、配置、操作系统镜像、数据等)。而我们的硬件自愈体系正是与天基紧密结合,利用天基的Healing机制构建面向复杂业务的硬件故障发现、自愈维修闭环体系。透过天基,我们可以将各种物理机的指令(重启、重装、维修)下发,天基会将其翻译给这台物理机上每个应用,由应用根据自身业务特性及自愈场景决策如何响应指令。2.硬件故障发现2.1.如何发现我们所关注的硬件问题主要包含:硬盘、内存、CPU、网卡电源等,下面列举对于常见硬件问题发现的一些手段和主要工具:在所有硬件故障中,硬盘故障占比50%以上,下面分析一下最常见的一类故障:硬盘媒介故障。通常这个问题表象就是文件读写失败/卡住/慢。但读写问题却不一定是媒介故障产生,所以我们有必要说明一下媒介故障的在各层的表象。a. 系统日志报错是指在/var/log/messages中能够找到类似下面这样的报错Sep 3 13:43:22 host1.a1 kernel: : [14809594.557970] sd 6:0:11:0: [sdl] Sense Key : Medium Error [current]Sep 3 20:39:56 host1.a1 kernel: : [61959097.553029] Buffer I/O error on device sdi1, logical block 796203507b. tsar io指标变化是指rs/ws/await/svctm/util等这些指标的变化或突变,由于报错期间会引起读写的停顿,所以通常会体现在iostat上,继而被采集到tsar中。在tsar io指标中,存在这样一条规则让我们区分硬盘工作是否正常 qps=ws+rs<100 & util>90,假如没有大规模的kernel问题,这种情况一般都是硬盘故障引起的。c. 系统指标变化通常也由于io变化引起,比如D住引起load升高等。d. smart值跳变具体是指197(Current_Pending_Sector)/5(Reallocated_Sector_Ct)的跳变。这两个值和读写异常的关系是:媒介读写异常后,在smart上能观察到197(pending) +1,表明有一个扇区待确认。随后在硬盘空闲的时候,他会对这个197(pending)中攒的各种待确认扇区做确认,如果读写通过了,则197(pending) -1,如果读写不通过则 197(pending)-1 且 5(reallocate)+1。总结下来,在整条报错链路中,只观察一个阶段是不够的,需要多个阶段综合分析来证明硬件问题。由于我们可以严格证明媒介故障,我们也可以反向推导,当存在未知问题的时候能迅速地区分出是软件还是硬件问题。上述的工具是结合运维经验和故障场景沉淀出来,同时我们也深知单纯的一个发现源是远远不够的,因此我们也引入了其他的硬件故障发现源,将多种检查手段结合到一起来最终确诊硬件故障。2.2.如何收敛上一章节提到的很多工具和路径用来发现硬件故障,但并不是每次发现都一定报故障,我们进行硬件问题收敛的时候,保持了下面几个原则:指标尽可能与应用/业务无关:有些应用指标和硬件故障相关性大,但只上监控,不作为硬件问题的发现来源。 举一个例子,当io util大于90%的时候硬盘特别繁忙,但不代表硬盘就存在问题,可能只是存在读写热点。我们只认为io util>90且iops<30 超过10分钟的硬盘可能存在硬件问题。采集敏感,收敛谨慎:对于可能的硬件故障特征都进行采集,但最终自动收敛分析的时候,大多数采集项只做参考,不作为报修依据。 还是上一个硬盘io util的例子,如果单纯出现io util>90且iops<30的情况,我们不会自动报修硬盘,因为kernel问题也可能会出现这个情况。只有当 smartctl超时/故障扇区 等明确故障项出现后,两者关联才确诊硬盘故障,否则只是隔离观察,不报修。2.3.覆盖率以某生产集群,在20xx年x月的IDC工单为例,硬件故障及工单统计如下:去除带外故障的问题,我们的硬件故障发现占比为97.6%。3.硬件故障自愈3.1 自愈流程针对每台机器的硬件问题,我们会开一个自动轮转工单来跟进,当前存在两套自愈流程:【带应用维修流程】和【无应用维修流程】,前者针对的是可热拔插的硬盘故障,后者是针对余下所有的整机维修硬件故障。在我们的自动化流程中,有几个比较巧妙的设计:a. 无盘诊断对于宕机的机器而言,无法进无盘(ramos)才开【无故宕机】维修工单,这样能够大量地减少误报,减少服务台同学负担。无盘中的压测可以完全消除当前版本的kernel或软件的影响,真实地判断出硬件是否存在性能问题。b. 影响面判断/影响升级对于带应用的维修,我们也会进行进程是否D住的判断。如果存在进程D住时间超过10分钟,我们认为这个硬盘故障的影响面已扩大到了整机,需要进行重启消除影响。在重启的时候如果出现了无法启动的情况,也无需进行人工干预,直接进行影响升级,【带应用维修流程】直接升级成【无应用维修流程】。c. 未知问题自动化兜底在运行过程中,会出现一些机器宕机后可以进无盘,但压测也无法发现任何硬件问题,这个时候就只能让机器再进行一次装机,有小部分的机器确实在装机过程中,发现了硬件问题继而被修复了。d. 宕机分析整个流程巧妙的设计,使得我们在处理硬件故障的时候,同时具备了宕机分析的能力。不过整机流程还以解决问题为主导向,宕机分析只是副产品。同时,我们也自动引入了集团的宕机诊断结果进行分析,达到了1+1>2的效果。3.2.流程统计分析如果是同样的硬件问题反复触发自愈,那么在流程工单的统计,能够发现问题。例如联想RD640的虚拟串口问题,在还未定位出根因前,我们就通过统计发现了:同个机型的机器存在反复宕机自愈的情况,即使机器重装之后,问题也还是会出现。接下来我们就隔离了这批机器,保障集群稳定的同时,为调查争取时间。3.3.业务关联误区事实上,有了上面这套完整的自愈体系之后,某些业务上/kernel上/软件上需要处理的问题,也可以进入这个自愈体系,然后走未知问题这个分支。其实硬件自愈解决业务问题,有点饮鸩止渴,容易使越来越多还没想清楚的问题,尝试通过这种方式来解决兜底。当前我们逐步地移除对于非硬件问题的处理,回归面向硬件自愈的场景(面向软件的通用自愈也有系统在承载,这类场景与业务的耦合性较大,无法面向集团通用化),这样也更利于软硬件问题分类和未知问题发现。4.架构演进4.1.云化最初版本的自愈架构是在每个集群的控制机上实现,因为一开始时候运维同学也是在控制机上处理各种问题。但随着自动化地不断深入,发现这样的架构严重阻碍了数据的开放。于是我们采用中心化架构进行了一次重构,但中心化架构又会遇到海量数据的处理问题,单纯几个服务端根本处理不过来。因此我们对系统进一步进行分布式服务化的重构,以支撑海量业务场景,将架构中的各个模块进行拆解,引入了 阿里云日志服务(sls)/阿里云流计算(blink)/阿里云分析数据库(ads) 三大神器,将各个采集分析任务由云产品分担,服务端只留最核心的硬件故障分析和决策功能。下面是DAM1与DAM3的架构对比4.2.数据化随着自愈体系的不断深入,各阶段的数据也有了稳定的产出,针对这些数据的更高维分析,能让我们发现更多有价值且明确的信息。同时,我们也将高维的分析结果进行降维,采用健康分给每台机器打标。通过健康分,运维的同学可以快速知晓单台机器、某个机柜、某个集群的硬件情况。4.3.服务化基于对全链路数据的掌控,我们将整个故障自愈体系,作为一个硬件全生命周期标准化服务,提供给不同的产品线。基于对决策的充分抽象,自愈体系提供各类感知阈值,支持不同产品线的定制,形成适合个性化的全生命周期服务。5.故障自愈闭环体系在AIOps的感知、决策、执行闭环体系中,软件/硬件的故障自愈是最常见的应用场景,行业中大家也都选择故障自愈作为首个AIOps落地点。在我们看来,提供一套通用的故障自愈闭环体系是实现AIOps、乃至NoOps(无人值守运维)的基石,应对海量系统运维,智能自愈闭环体系尤为重要。5.1.必要性在一个复杂的分布式系统中,各种架构间不可避免地会出现运行上的冲突,而这些冲突的本质就在于信息不对称。而信息不对称的原因是,每种分布式软件架构在设计都是内敛闭环的。现在,通过各种机制各种运维工具,可以抹平这些冲突,然而这种方式就像是在打补丁,伴随着架构的不断升级,补丁似乎一直都打不完,而且越打越多。因此,我们有必要将这个行为抽象成自愈这样一个行为,在架构层面显式地声明这个行为,让各软件参与到自愈的整个流程中,将原本的冲突通过这种方式转化为协同。当前我们围绕运维场景中最大的冲突点:硬件与软件冲突,进行架构和产品设计,通过自愈的方式提升复杂的分布式系统的整体鲁棒性。5.2.普适性透过大量机器的硬件自愈轮转,我们发现:被纳入自愈体系的运维工具的副作用逐渐降低(由于大量地使用运维工具,运维工具中的操作逐渐趋于精细化)。被纳入自愈体系的人工运维行为也逐渐变成了自动化。每种运维动作都有了稳定的SLA承诺时间,不再是随时可能运行报错的运维脚本。因此,自愈实际上是在复杂的分布式系统上,将运维自动化进行充分抽象后,再构筑一层闭环的架构,使得架构生态形成更大的协调统一。本文作者:钟炯恩阅读原文本文来自云栖社区合作伙伴“阿里技术”,如需转载请联系原作者。

November 20, 2018 · 1 min · jiezi

阿里云梁楹:这样的青春,别样的精彩

人的青春应该怎样度过?相信一千个人心中,有一千个答案。我是郭嘉梁,花名梁楹,在不少人眼中,我是一个来自北方的大男孩,一个自带“古典气质的少年”,其实我是一个喜欢晋级打怪,热爱挑战自我的阿里云工程师。1024程序员节之际,分享我的成长经历,且看别样的“青春修炼手册”。学生时代:热爱、执著、前进早在读书的时候,我就一直很喜欢接触一些新的技术。本科毕业后,我被保送到中科院计算所读研,机缘巧合,我接触到了很有前瞻性的光网络互连技术。当时,在国内做光网络研究的人还是很少的。在导师的指导下,我专注于根据高性能数据中心流量模型,利用光交换机对数据中心的网络拓扑进行快速重构。通过 RYU 控制器完成了控制层的拓扑发现,路由计算等工作。在模拟系统中,实现并验证了 HyperX、Torus、DragonFly 等高性能网络常见拓扑结构 的重构算法 FHTR(fast and hitless data center topology reconfiguration)。在基于 AWGR 的光网络中利用该算法达到了微秒级的拓扑重构,并在小规模拓扑的评测中比之前的最新研究成果降低了 50%的丢包率。终于在2017年投中了欧洲光通信领域顶会ECOC的文章。虽然实验室内接触的技术大多偏重计算机硬件,但当时实验室的同学也喜欢利用业余时间探讨一些互联网的相关技术。研二时,我看到了阿里云正在举办中间件性能挑战赛,我和实验室的小伙伴一拍即合,决定以赛代练,多接触接触工业界的先进技术。当时的赛题是需要实现自定制数据库,满足双十一脱敏数据的高并发写入和查询需求。于是在两个多月的时间里,我们几乎从0开始调研数据库的索引机制,整个暑假的时间都泡在实验室里。最终,在索引阶段,我们通过 TeraSort 的排序算法对 4 亿订单进行聚集索引,并采用多线程同步的方式控制磁盘 I/O。 在查询阶段,通过多线程完成 Join 操作,充分利用了 CPU 资源。同时,利用 AVRO 实现了数据的压缩,将原始数据压 缩到了 46%。使用 LRU 算法完成了基于块的缓存机制,查询的命中率达到 83%。日常学习的沉淀积累、平时练就的细致全面的解题思路、敢打硬仗的勇气,终于帮助我们克服了重重困难,翻越高山和大海,我们拿到了决赛冠军的好成绩!从此,我也结下了与阿里巴巴的缘分。阿里体验:我挑战,我能行2017年,我参加了阿里巴巴的校园招聘,了解到当时正在打算开辟新的业务,也是国内第一个和Elasticsearch官方合作的项目。当时内心就十分向往,虽然对全文搜索技术了解不多,但我依然觉得这是一个不错的挑战机遇。心里有个声音告诉我,如果刚工作的时候,能把一件未知的事情干好,以后职场上没有什么事情是做不好的!十分幸运,我加入阿里就赶上了Elasticsearch项目的启动,以及长达三个月的封闭开发。“一个新人+ 一个新项目”,挑战模式全面升级,而这正是我加入阿里所期待的。还记得刚入职的时候,很多问题搞不清楚,阿里的“老员工”濒湖同学,就像高年级的学长一样,耐心与我共同探讨问题、结对开发,极大的缩短了我融入团队的时间。但毕竟是新项目,压力和焦虑感也随之而来,漫长的封闭开发期,需要我用最快的速度了解阿里云的相关业务,以及适应阿里的开发节奏,这种“折磨”感让我无论是在技术方面还是对公司文化的理解方面,感觉都是经历了一场脱胎换骨式的洗礼。记忆里,几乎所有的场景都是与时间赛跑的拼搏画面,项目也终于在进入封闭开发室两个月后,进入了公测阶段。阿里的工程师每个人都肩负着重要的开发任务,以及相应的责任。主管万喜对我说的一句话,至今记忆犹新,“阿里云上的业务很重要,对待每一行代码都要非常认真,这是客户沉甸甸的信任。”每一次开发新功能时,每一次版本迭代时,我都心怀敬畏。如今,我参与开发的产品和相关技术在国内同行业中已经处于领先位置,获得行业认可和用户的好评。马老师说过,阿里人要有家国情怀。阿里云的业务涉及到的中小型企业非常多,因此我们每一天要做的,就是要完成好这一份重托,这份嘱托,支撑我迎接挑战、面对困难、赢得胜利!不忘初心,迎接未来来到阿里已经一年多了,在这个欢乐的大家庭,我收获很多,不但认识了新的同事,开发了新的产品,身份也从一名学生,正是转变成了工程师,我的“青春”再升级。对于工程师的身份,我感到十分骄傲。目前,我参与的阿里云Elasticsearch产品,提供基于开源Elasticsearch及商业版X-Pack插件,致力于数据分析、数据搜索等场景服务。在开源Elasticsearch基础上提供企业级权限管控、安全监控告警、自动报表生成等功能。Elasticsearch公有云,目前已经部署了4个国内区域以及6个国际区域,在线的弹性调度,配置管理,词典更新,集群监控,集群诊断,集群网络管理等功能均已提供服务。如果有志同道合的小伙伴,欢迎加入我们的团队。从学生时代到阿里巴巴,所有获得的成绩,都来源于对未知的好奇心。所有事情都是这样,做了不一定有机会,但不做一定没机会。未来,我感到身上的责任更重了,我会认真写好每一行代码,做好每一个云产品。认真生活,快乐工作!点击了解阿里云Elasticsearchhttps://data.aliyun.com/product/elasticsearch本文作者:山哥在这里阅读原文本文为云栖社区原创内容,未经允许不得转载。

November 16, 2018 · 1 min · jiezi