引言
大家知道最近两年随着AlphaGo的兴起，人工智能和机器学习成为各个互联网公司，如阿里巴巴、腾讯等重金投入的场景。实时计算作为机器学习的重要基础设施，开始大规模应用起来，它在搜索、推荐、广告、监控等场景下，对数据、模型等产生实时的反馈，对算法效果的提升有非常大的帮助。
在去年双十一时，阿里的实时计算平台服务了20多个BU、有1K多的 Job、近万台机器，其计算峰值达到了4.72亿QPS，大家在双十一当天看到的阿里巴巴对外提供不断滚动的大屏，其计算峰值达到1.8亿QPS。
随着实时计算的大规模上线，在平台运维方面也面临着很多与在线服务和离线计算都不太一样的挑战。
01实时计算平台的运维挑战
关于实时计算、离线计算和
在线服务的差异
- 离线计算对 SLA 的要求不高，分钟甚至小时的延时都是可以接受的；
- 实时计算就要求必须达到秒级，不得出现一分钟卡顿的情况；
- 大家比较熟悉的在线服务必须是毫秒级或者微秒级的要求。
- 针对不同的情况，容灾方式也不一样
- 在线服务需要有异地双备或者多地单元化部署，保证能随时互切；
- 对于实时计算，它只会针对个别核心业务做双备，大部分业务只有一个运行实例；
- 离线计算几乎没有双备。针对这种容灾方式造成资源利用率的不同。在线服务要保障随时互切，资源利用率，比如CPU不能超过40%。
- 实时计算和离线计算对资源利用率有更高的要求，必须达到70%-80%以上，甚至达到90%以上。
当前实时计算面临的挑战
集群异构情况。我们的机器每年在更新换代，今年的机器和去年的机器相比，CPU和内存的提升，会导致集群机型的异构；
热点的情况。在离线计算的挑战不大，可以接受一个小时或者至少几分钟的延时。但对于实时计算来说，必须要保证秒级延时，一旦出现热点，必须能够马上进行实时自动化处理，否则会影响整个服务的时效性；
软硬件故障导致服务的可用性 ；
资源利用率的提升对于稳定性的挑战非常大。实时计算和离线计算对于资源利用率的要求几乎一致，要达到80-90%的利用率，但实时计算对sla要求却更高，是十倍级以上的提升。
2统一的运维自动化平台
阿里巴巴实时计算平台和运维架构：
1.最底层是运行环境的管理，主要通过阿里自研的IDC系统以及阿里大数据运维平台自己的系统，做物理机和Docker的硬件管理，包括硬件的运行时管理；
2.往上一层对应存储层、调度层、引擎，存储主要有HDFS、HBase、Pangu。在调度层主要是Yarn和阿里自研的Fuxi。在引擎层是阿里巴巴基于开源的Blink打造的引擎。
3.对应运行层的服务，主要通过 Aquila 做了管理。Aquila 是我们基于社区开源做的企业版服务。之所以叫Aquila，因为类似像Hadoop、HBase等，是以动物的形象展现给大家，而Aquila是非洲野生动物园的名字，我们希望通过Aquila 把类似Hadoop、Blink 的生态系统全部管理起来。
4.最项层是实时计算支撑的整个阿里的业务，包括搜索、推荐、广告、大屏。整个的开发和应用层是通过阿里计算平台事业部开发的 大数据智能运维平台星云（Nebula）系统做业务的管理和运营。
5.阿里巴巴的实时计算平台目前主要是StreamCompute 和 Porsche。StreamCompute已经在阿里云公开对外输出，如果大家对实时计算感兴趣，可以到阿里云的官网做试用或者采购。
DAM-硬件运维运营利器
DAM 主要做的包括四部分工作：
1.硬件检查。检测设备中出现的硬件故障
2.故障预测。利用硬件和系统日志，通过算法的分析，对硬件故障进行预测，依赖很多底层算法及大数据相关的技术。
3.故障修复。机器自动化故障处理，自动化的提交报修单，囊括提报修单、现场维修、重新交付等整个维修过程。
4.硬件运营。对于底层硬件运营情况的展示，包括资源利用率、机器上线情况，同时另一部分的工作是做多种机型故障率、维修时长等运营工作，可以帮助我们发现每种机型或者同机型不同厂商之间的硬件故障率，对我们后续硬件的采购产生影响。
Aquila-从工具到产品升级
把Aquila从工具到产品的升级，提供对运维自动化有帮助的能力，包括以下几点：
- 运维操作白屏化；
- 服务统一的运维规范和模式；
- 运维系统和运维操作的可持续集成能力；
- 对自动化操作的支持能力。它能提供完整的API供外部接口做调用，支持自动化的操作。
2.1Aquila-概念和功能需求
Aquila：概念和功能需求的划分为以下几点：
1.Stack管理。一组特定版本的服务集合，它本身有版本的概念，比如1.0-1.1中间的差异可以是其中某一个 Service 版本的变化或者多个Service版本的变化，通过Stack管理来做整个集群的升级管理。
2.配置管理。我们面对的是集群管理异构的情况，所以它必须支持机器配置分组管理。配置代码化，通过Git管理，有版本概念，支持Review和回滚。
3.自动化方案。一是要支持完善的API，能够做自动化的扩容，机器从故障预测、下线、机器修复和重新上线的自动化流程；二是支持服务的自动拉起和维持，现在集群会出现一些异常，它要保证随时把停掉的进程拉起来。
4.是通用接口
2.2Aquila设计和实现
- 底层依赖DB，Server层包括几部分，一是Heartbeat Handler，它负责和Agent通信；FSM是状态机的管理。在Aquila里，各种服务的管理是通过状态机进行的。
- Action Manager、Coordinator、Stage Pianner 负责从请求到生成对应的操作流程。 Agent和Server通信方式是由Agent主动发起，Server 端的命令下发、监控是通过 Heartbeat respond 方式完成，包括 Agent 监控的信息、动作执行情况，全部以主动向Server汇报的方式进行。
2.3相比开源社区优势
相比于开源社区，Aquila提供以下优势：
服务更稳定
- 支持Server的HA架构，保障server的高可用。开源社区中ambari是单点服务，包括DB、Server。我们在此之上做了一个改造，就是HA的架构。保证我在一个Server挂掉的情况下，不影响整个集群的操作。
- DB采用阿里云数据库rds，能够保证数据的安全性。
- 增加配置Review流程。该流程可以保证我们的配置经过对应的开发、QA，做Review后的配置，才能分发到整个集群里。
- bugfix达到100+。
- 后台基于RDS，可以在出现故障的情况下做无缝迁移。在Server端，我们支持两个Server，这两个 Server 通过Zookeeper 保证一致性，保证只有一台 Server 在运行状态，另一台准备状态。
- Agent的通信类似Hadoop的工作方式，当它向其中一台Server发起通信受阻情况下，它会主动去另一台做重试。通过这样的方式来保障Aquila的高可用。
- 改造后的配置管理情况。通过Aquila WebUI或Json IDE发起配置变更，配置保存在Git上。不管你是通过Aquila WebUI还是Json IDE，都会生成Review Borad。
- 这个Review是通过Facebook提供的开源工具来做，它已经集成到阿里的系统上。生成Review后，可以通过对应的开发和QA Review后，才可能进到Git。
- 只有进入Git才有可能被Aquila Server接受，下发到计算平台的集群里。大家看到的不是特别大或者特别复杂的改造，这对于生产环境来说，是一个非常重要，而且是必须要做的事情。
管理更高效
- Stack的管理：
Stack依赖管理重新设计，整体更加简洁。举例说明原来的管理模式1.0有一个基础，1.1某一个服务做了改动，其他的都会改为对1.0的依赖。这对于整个服务管理非常复杂，我们要对其中一个服务做操作上的改动，所有的Stack1.0、1.1要重新升级。改造后，Stack1.1-1.0的依赖类似拷贝的过程，从1.0-1.1做升级，对应做版本变更、操作变更，使整个依赖变得更加简洁，操作更加友好。
- 多集群管理：
支持多集群管理功能。Aquila Server的部署是一个比较复杂的过程，包括它的依赖情况。多集群管理功能可以实现一台Aquila可以管理整个生产的多个集群。
增加配置导入导出的流程，方便新集群部署，所有已Review好的配置可以从GitLab上直接导入集群，做配置的复用，直接配置新集群。
支持机器自动注册和服务自动部署，支持Docker服务自动部署。阿里在做统一调度系统，所有业务都要进容器。支持服务扩容，需向一层调度申请一部分资源。它反馈给我们的是Docker容器。我们做自动注册服务，Docker只要把Aquila拉起来，我可以通过Server中的配置自动把服务拉起。
流程优化达到30+，包括部署向导、Batch升级、Rack信息导入等。
服务接入更开放
- Stack 和 Server 做打包分离，加快 Stack的迭代，让服务接入更方便。
- 对 Service 的 Meta 文件进行拆分，将版本信息、操作信息、依赖信息分离，Stack升级更加灵活。若要对服务做操作方面的改造或者升级，无需专门做Stack的升级便能完成。
- 支持更灵活的安装方式和源，如Rpm、Tar、Git、Oss等。
性能更高
目前从 Aquila 社区看到，单集群支持2500+机器。通过对数据库表结构的优化及Host管理优化，单集群可以支持 5000+ 机器和单 Server 支持 50+ 集群。其他性能优化 20+，包括锁优化、事件管理优化及前端框架的优化。从整个平台看来，有了 Aquila后，我们可以依赖这个产品做很多自动化的工作
2.4统一的大数据运营平台
基于业务运营层面统一的大数据运营平台，包括业务中心、平台运营和工具服务。
运维运营平台提供分站开发框架、资源整合相关管理、运维数据化的支撑、智能分析工具，它的功能涵盖业务中心、服务管控、平台运营、工具服务、运营中心和运筹优化。
从运维/运营业务场景来看，它提供故障处理场景、监控分析场景、变更保障场景和值班、大促的场景。Tesla 面向的客户包括业务开发、一线运维、IDC、财务，它涵盖资源账单情况。
3主动出击，消除隐患
对于实时计算平台来说，机器出现故障影响业务后再进行处理有比较大的风险。
3.1硬件故障自愈
通过引入DAM做硬件预测，在预测到故障时，主动通过 Aquila 完成服务的下线，把机器交还给 DAM，做硬件自愈，自愈完成后重新加入到集群中，形成一个完整的闭环。现在在运营工作中，不再需要主动做硬件故障管理的工作。
3.2资源自动扩容
实时探测资源水位，在水位紧张的情况下启动向 Sigma 的资源申请。通过容器做自动注册，完成服务部署，最后加入集群，进行调度作业。
4智能化运维应用
在实时计算运维架构的迭代演进，通过工具和系统的开发已实现完成了运维标准化及自动化的建设，我们开始进一步探索运维场景的智能化应用，例如在集群异构情况下通过聚类分析，识别发现配置错误导致的资源问题并进行报警处理。通过 Metrics 数据采集密度聚类，实现对机器热点的全面分析，后续系列篇我们将为大家带来具体应用实践案例，敬请期待。
