晓致API接口能接入哪些什么是计算机接入网络的接口设备语言？

点击联系发帖人 时间：2017-08-07 05:48

什么是计算机接入网络的接口设备

阿里巴巴集团拥有超大的数据库實例规模在快速发展的过程中我们在运维管理方面也在不断的面临变化，从物理器到容器、从独占到混布、从本地盘到存储计算分离、從集团内到大促云资源从开源的MySQL到自研分布式数据库，运维管控进行了自我革新与进化

作者——谭宇（花名：茂七），阿里巴巴高级技术专家2009年加入阿里，对分布式系统和数据库领域有很大的兴趣目前负责阿里巴巴集团数据库中台建设，支撑了集团数据库在容器化、存储计算分离、在离线混部、大规模迁移建站以及智能运维等技术探索与落地

本文梳理了阿里巴巴数据库运维发展历程以及对未来数據库自治时代的看法，期待与诸位一起讨论

我在阿里快十年了，前五年做一些分布式系统开发相关的工作参与的系统包括TFS/Tair/OceanBase，后五年聚焦在数据库运维平台及服务的建设从搭建数据库集群、数据采集等底层运维到外部客户服务、POC支持等都有所经历，好的想法历来稀少外加个人天资愚钝，不敢说有什么独创的想法都是实践过程中的一些感悟，且与大家分享也是对过去一段时间的总结。

关于阿里的数據库大家可能已经听说过很多，阿里巴巴数据库技术的发展与整个集团的技术发展类似从商业到开源再到自主研发。早在09年以前阿裏巴巴数据库或DBA团队已经在业界非常知名，拥有多名Oracle ACE / ACE Director外加自发性的与业界的交流、分享以及著作，构建了非常强的影响力很多人因此吸引而加入，这是一段荣耀时光当时很多知名人物现在有的在创业、有的仍在集团不同的领域奋斗，江湖中仍然可以搜索到他们的传说

后来就是轰轰烈烈的去IOE运动了，刚入职时经常在内部BBS上看到各种成功去除Oracle的帖子基本套路就是DBA和业务开发一起配合，通过各种脚本把數据迁移到MySQL上在这个过程中，遇到过很多问题也在积极寻求各种新的技术，比如为了突破磁盘性能问题在当时主流的还是机械硬盘嘚时候，使用了Fusion-IO等也在MySQL内核上开始各种改进，形成了AliSQL

关于去IOE、各自数据库内核技术、支撑的业务这些方面，讲的很多大家可以搜到各自技术相关的文章，但很少有人讲过这背后有一个什么样的平台来支持这些业务变化以及技术迭代过去的5年里，我和我的团队一直在莋数据库运维或者是服务方面的事情很难，我相信各位如果有做过这方面经验会感同身受

一方面，这是运维类或服务类系统的“原罪”这类系统形成初期，它只是一个工具或一个平台使命是支撑好业务，自己并不实际产生价值所有的技术要在这里落地，等落完地恏像和你又没什么关系价值感比较弱。今天K8S等系统的出现说明这个也可以做得很好但相对来说这是一个更难做好的领域。

另一方面業务的复杂性、技术栈的多样性以及所依赖的组件决定了这个系统在实现层面很难，你需要把各个组件一层一层的串联起来从业务访问箌数据库内核再到底层的网络、存储、OS、硬件等，任何一个层面出了问题都会集中反应到你的系统中实现人员面临着从上到下各个层面問题的理解、异常的处理，对团队及个人能力要求极高

一个很具体的例子，我们的运维系统涉及了前端、大数据处理、算法、数据库、底层软硬件等各个技术领域在最初期团队不可能有各个领域的专家，需要每个同学了解并解决不同的领域的问题

我想就这些方面，系統性地跟大家介绍一下我们所做的一些工作主要包括三个方面：第一，我们整个系统的发展历程所谓从历史看未来，不知道过去无法推断出未来我们的样子。第二现阶段的技术和产品，比如我们如何支撑我们现有的工作双11大促等。第三从过去和现在出发，我们未来一段时间要到达的样子

阿里巴巴数据库运维发展的历程，主要有这几个阶段09年以前，以商业数据库为主去IOE也才开始。之前没有整体运维规划、运维平台使用了各类脚本、工具。

在09年以后由于规模迅速膨胀，这个时候自然产生了一些工具团队把各类脚本拼在┅起，弄个界面形成了最初的产品。

接着随着复杂度进一步增加，以及云计算的推动交付方面有了更高的要求，形成了服务化比洳DBaaS等。

近年来随着大数据、机器学习等技术的发展，AIOPS催生智能化在智能化的基础之上，对各类服务平台的服务质量的进一步要求也僦是自治。

总体来讲有两次比较大的革新。

第一次是从产品化到服务化最初，我们的产品形成非常简单没有什么平台，没有什么系統大家一边干活一边沉淀一些脚本，到处分发随着规模的增长，原来的那套脚本需要管理起来了我相信很多团队最开始都会设立一個工具组，专门来干这个事情这就会演变成一个团队做工具，另一个团队来使用慢慢的两者之间的GAP就出现了。工具团队有工具团队的KPI业务团队有业务团队的KPI，分歧会逐渐增大

另外一个问题则是大家都在攒工具，攒平台结果这些平台之间是相互不能通信的。比如一個应用开发需要数据库、搜索、分布式存储等各个系统，开发人员需要去逐个申请效率不高。

服务化的变革就是在这种情况下发生的我们不提供工具、平台，而提供服务这些服务之间相互打通，并且我们对提供的服务有相关SLA保证这次革新可以说是云计算的基础，雲计算的本质是IT资源交付技术的进步这是云计算带给我们的最大价值。

第二次革新是自治我们目前正处于这次革新中。

对SLA或者服务质量的追求是没有止境的现在很火的Cloud Native、Serverless本质上都是对更高服务质量的一种追求。要提升服务水平关键点有两个，一是规模规模大了才能做更多事情，比如混合部署、智能调度、机器学习都要求一定的规模和大量的数据。这也符合当前提供基础服务的云计算趋于集中的趨势

规模也是问题的根源，管理一千个实例和十万个实例所需的技术完全不一样所以另一个关键点是技术水平，有了规模还必须有相應的技术比如容器化、机器学习、存储计算分离、RDMA网络等技术的提升。

当然技术的积累是一个长期的过程积累到一定程度就会引起质變。我们这些年在系统建设、技术积累方面所做了许多工作先来看一组数据，这是刚刚过去的双十一数据库相关的一些情况

大家可能看过一些数据，比如成交额交易峰值。对于背后的数据库而言每秒有超过5000万次的访问。特别是在高峰期读写比是和平时不一样的。通常一般系统读写比大约是9：1或者7：1但在双11高峰时，数据库的读写比可能是2：1在写入比例极高的情况下，要求数据库不能出现任何抖動或者延迟我们对任何一种新技术的引入都非常严格。

另外阿里巴巴大促场景非常复杂，包括线上线下以及海内外多种场景基础设施分布在全球多地，数十个机房同时支撑系统复杂性非常高。

总结来看我们的业务场景大致有以下几个特点：

业务多样性。作为数据庫中台数据库团队要支撑集团所有业务。包括核心电商、线下新零售场景以及各个独立子公司各种场景对数据库的要求也不一样，比洳线上场景就要求高并发低延时故障快速恢复。线下场景则要求绝对可用而且接入及使用数据库的方式都不受控制。而新加入阿里体系的收购公司有原来的运维体系，要求他们做改变也不太现实总之需求的多样性对数据库的要求非常高。
基础设施多样化数据中心汾布在全球，有的用公有云、有的有自建机房有的用物理机，有的用Docker、用弹性计算等整个集团就是一个超级大的混合云。
双11超级大热點除了成本和性能方面，双11在弹性方面有很高的要求我们也不可能为双11买这么多机器，那太浪费了早期，会在不同的业务线之间进荇拆借比如借云的机器或者借离线的机器，大促后归还全靠人肉搬机器。整个大促周期非常长人力成本和机器成本都很高。

针对以仩情况我们形成了如下架构。主要思路是向下层屏蔽差异向上层提供多样化服务能力，中间围绕着弹性、稳定性、智能化进行建设

早期的运维系统因为各种原因，没有设计好的架构导致难以扩展最后越来越臃肿，推翻重构的事情并不少见现今，我们设计了服务化嘚运维系统整体架构：

一来可以清晰地理顺系统各个模块之间的交互方式并标准化彻底解决原来工具时代遗留下来的各自为政，各个功能散落在不同地方的问题整个系统的发展不再背负历史包袱；
二来可以解决技术栈太多的问题，从前端到底层采集、算法分析我们不鈳能统一成一个框架、一种语言。让这些模块能互不影响、互相交互是整个系统能做强的基础；
三来可以将整个系统的数据集中起来，為后续智能化所需要的统一数据、统一算法提供基本要素；四来可以向外提供统一形式、功能多样化的服务要想做好做强一个服务类的系统，服务化是第一步

在底层，我们做了统一的资源调度层用来屏蔽底层计算、存储、网络资源的差异，向上交付标准的容器

中间昰数据库层。因为业务的多样性数据库类型多种多样，运行在不同的环境我们通过统一的命令通道和采集通道的抽象来屏蔽这些差异。

再往上是传统的数据库运维层包括常见的数据库的生命周期管理，我们称之为Lego希望OPS这样的基础功能能像乐高一样百变组合，迅速搭建我们想要的功能还包括数据采集、处理存储的模块Kepler，我们希望把所有的运行数据实时采集到然后通过大数据处理、机器学习等手段發掘出深层价值，采集的数据包括OS、网络、存储数据库的SQL流水、性能指标等等，整个处理的数据量非常大并且所有指标都要求是秒级嘚。每秒都要处理超过100G的原始报文

再往上是智能决策层，这一层完成自动修复与优化的工作比如预期内的故障，异常处理也通过采集到的数据，做一些分析和决策

我们把整个系统的功能以服务的形式提供出来，大家可以在这个基础之上定制想要的功能过去几年，峩们在架构实现方面一直坚持“一个平台、一套架构集团孵化、云上输出”的策略，集团内部数据库管控平台提供服务所有模块在一套架构下实现，产品在集团检验后开始在云上输出不同的时期有不同的坚持，在智能化时代我们对这个架构及策略也有所调整，这个茬后面会提及

解决架构问题后，我们过去两年主要围绕几个能力进行建设一是容器化与存储计算分离，二是快速弹性与混部的能力彡是规模化交付与智能运维，这几项工作都是今天能够发展成为集团数据库中台以及支撑双十一的关键能力

第一，容器化是技术的量变箌质变容器并没有很多开创性的技术，各种技术合在一起开辟了新的思路所以在把数据库放到容器里首先要突破我们的运维思路，坚萣可以把数据库放到容器里的这个想法当然这个过程中也遇到过稳定性和性能问题，比如网络在使用bridge模式的时候会有些CPU的增加。

最终茬网络团队不断优化后基本可以做到与物理机持平。容器化一方面解决了很多环境问题另一方面也为数据库的调度提供了可能，我们從16年开始做数据库容器化到今年，绝大部份的数据库都跑在了容器里

第二，存储计算分离其实数据库最开始就是存储计算分离架构嘚。在互联网时代这个架构在最初遇到了瓶颈，因为互联网时代的容量扩张非常快然后出现了分布式系统，把计算搬到数据所在的地方但是随着技术的发展，特别是云的交付方式存储计算分离的交付则更为便捷。交付多少计算能力交付多少存储，一目了然

另外，存储和计算的发展也不太均衡比如双11的时候，我要求的是计算能力其实存储并没有增加多少。所以随着技术的发展我们这一圈基夲上又转了回来。当然存储计算分离要不要上我们也是经过了很长时间的讨论，今天来看上存储计算分离这个决定是对的。在这个过程中也遇到很多问题主要是延迟的问题，毕竟经过一层网络IO时间是有增加的。

我们最开始上了左边这个架构将远程存储挂载到本地，这个延迟要较本地盘大很多核心业务难以接受，在这个基础之上我们大规模引入RDMA网络，通过DBFS　bypass掉kernel延时基本能和本地盘相当，所以紟年所有的核心业务就跑在了这个架构上

有了容器化和存储计算分离的基础，就可以比较好的解决弹性问题了之前我们的弹性主要靠搬数据加搬机器，现在数据可以不用搬了我们大促所用的机器主要来自两个地方，一个是离线资源另外一个是云资源，我们用完之后雲可以继续对外售卖

大家知道，双11的高峰期主要在零点时段所以我们在高峰期来的时候弹性扩容，高峰期结束立即缩容还机器给别囚用。我们结合集团的调度做了一套混部调度系统，可以做到数据库快上快下今年我们的核心集群10分钟就可以完成弹性扩缩，而我们朂终的目标是在1分钟内完成

第三，交付和诊断我们说云计算是IT资源交付能力的进步。我们基本完成了向用户交付数据库资源开发人員可以通过系统自助完成数据库资源的申请与使用。如果只是把交付理解为用户自助获取数据库资源的话我们已经完成得很好了。

但集團有更严苛和复杂的交付任务比如下面两个例子：大促时需要在上十万个数据库实例里扩容数千甚至上万个实例，大促完成后还需要缩嫆回来每年有固定的或临时的建站、迁站等操作，例如今年的一路向北和上海、张北多次建站可能会涉及到数万数据库实例及数十PB数據，这些都非常考验我们交付的能力

之前的常规做法是让人来评估，确定好操作的数据库范围算好需要多少机器资源，如何摆放等洅通过我们提供的迁移操作来完成。人需要来控制其中的每一个步骤这是一个相当繁琐的工作。每年都要做那么几次在我们今天要求赽上快下的时候就显得特别力不从心。

所以我们提出软件定义部署的概念类似常说的编排。主要做两个事情一是把我们的这些操作都精确定义和记载下来，线上的运行环境也能用代码精确定义出来二是把中间的腾挪步骤交给系统，人只需要描述最终的状态在我们预測准确到一定程度后，这个最终描述状态也可以由系统来完成真正的完成大促自动化交付。

可以看到我们的链路其实很长，中间的各個组件出了问题诊断是一件很难的事情Gartner有一个名词叫AIOPS，相信大家都听说过其实Gartner提出AIOPS很早，最开始指的是基于算法的OPS随着AI技术的发展呢，他顺势把这个词的写法给改了但本质上没有变，仍然是依托大数据、算法来改变OPS

应该说这也是个朴素的概念，我们在差不多时刻吔提出了这个想法最开始叫做数据驱动，后来改名为运行数据与数据运营也是通过各种算法，比如基线、异常检测、关联分析、趋势預测等等来自动决策或辅助我们决策

这便是CloudDBA的初衷，先把各种采集到的数据汇聚统一、预处理再加上领域知识和算法打通从用户到DB，從DB到底层硬件这两个链路在双11的时候也能实时的诊断访问链路。当然这里待挖掘的还非常多现在我们可以说只应用了非常小的一部份。

最后我把之前讲的这些都融进了一个产品。Gartner有一份报告指出到2020年的时候，有85％的企业会使用混合云的架构这和我们的判断是一致嘚。之前提到过阿里巴巴集团就是一个超大的混合云，所以我们推出了HDM帮助企业把混合云数据库架构打通。

HDM主要提供两大功能一是統一管理，不管是云上的还是云下还是其他云的数据库都可以进行统一管理与诊断。二是弹性扩展一键把数据库上云也不再是梦想。茬数据库层消除本地IDC和云的区别

在提出HDM后一段时间里，我一度认为这基本上就是数据库服务的未来了但这些年，不管是数据库领域還是运维领域，都在飞速的向前发展我们似乎又到了一个技术集中爆发的时间点。一方面是新的软硬件技术比如容器、高速网络，机器学习另外一个是云计算的发展，都在不断的推动我们向前提供更好的交付及服务。

在数据库领域有自治数据库、智能数据库，在運维领域有AIOPS等等。这对数据库运维来说到底意味着什么我们结合过去和现在的情况，提出了自治数据库平台这个定义是很多人一起討论了很久才定出来的。

首先是平台的能力和目标我们希望能做到自动驾驶，简单的说就是不需要人的参与要做到这个，就要具备自感知、自决策、自恢复、自优化四大能力其次是平台能为数据库赋能，今天的现状是我们用了很多种数据库不能对每个数据库有很高嘚要求才能自治，我们可以进行能力分级

我们也有非常明确的业务目标，这是阿里数据库事业部掌门人公开的目标：在2020财年结束的时候阿里集团85％的数据库实例要能做到自动驾驶。我为此定了两个评估指标一是没有人接收这些数据库的报警，另一个是稳定性要达到99.995%

目标有了，具体怎么实现首先，自治是一个技术的量变到质变的过程在过去的一段时间里，我们应用了大量的新技术包括存储计算汾离，大数据处理与机器学习等等掌握好这些技术是自治的基础。

有了这些技术还需要革新我们的思路，就像今天的电动汽车或自动駕驶由传统厂商来制造，都显得差强人意这一方面是思维定势，另一方面则是有它的历史包袱

我们需要破除这些，比如我们之前的數据、运维、资源都是分割开来的所谓自动处理都是先接收一个报警，然后根据报警的内容做自动化这明显没办法形成一个统一的整體。今天我们需要先去构建整个骨架然后让数据、算法去丰富、去润滑整个系统。

另外还需要专业知识数据库是高度专业的系统，之湔可能由DBA、内核开发人员去调校靠数据，靠试错靠经验。这些知识如何精确化、数字化下来让系统也具备这些能力，是我们要去努仂的事情

最后，重要的一点是要持续提升原有的基础能力不是说我们今天智能化、自治化就是数据和算法，其他基础能力同等重要仳如OPS，我们提出了一个ad-hoc执行：假如决策模块作出了一个决策是全网内存水位高于95％的数据库实例做一个action你要能够很快执行下去。

我们目湔正在向这个方向前进预计很快我们就会对一部份数据库实例实施自治，欢迎有兴趣的同学加入一起建设共同迎接自治时代的到来。

夲文为云栖社区原创内容未经允许不得转载。

}