<p>杨成伟：大家好，我是来自爱奇艺的杨成伟，现在在爱奇艺公司内部负责弹性计算云方面的建设，之前我是做移动操作系统的，之前在因特尔做MeeGo和Python，有几年的经验，主要是在操作系统的核心层，但是是在UserSpace这一块，所以对于像Systemd DBUS比较了解，然后也是一个DBUS的 Upstream Commiter。但是现在来到爱奇艺之后主要是从事云计算这一块的工作。</p>    <h2>内容提要</h2>    <p>今天我主要给大家介绍一下爱奇艺 App Engine设计与实现： ## 大标题</p>    <h3>1、背景、出发点、目标</h3>    <p>第一部分是一些背景、出发点以及目标，因为爱奇艺在Iaas起步比较早，我们公司大部分的业务都已经从物理机实现到虚机的迁移，也就是第一步的这种Iaas基础架构已经有了，包括公司非常多的像DB、MQ中间件之类的几乎都已经实现了云化。为什么要从虚机到基于Docker的这种转变的话，我们从最早的时候是13年底开始接触Mesos，我们有非常强的mesos的背景，我们首先考虑的是从资源效率的方面考虑的，所以最早的时候想要实现一个App Engine，主要是借助Docker的灵活性然后实现业务的横向扩展以及对资源的节约。</p>    <h3>2、iQIYI App Engine 设计与实现</h3>    <p>第二部分我们会详细的分析一下App Engine的设计与实现</p>    <h3>3、一些经验（坑）</h3>    <p>第三部分因为这个App Engine现在长成这样，之前也不是这样的，我们也积累了一些经验，包括踩了一些坑</p>    <h3>4、现状与展望</h3>    <p>最后一部分是App Engine在我们公司的现状包括业务的现状以及开发状态，最后是一点展望。</p>    <h3>5、Q & A</h3>    <h2>背景、出发点、目标</h2>    <h3>背景 — 业务上</h3>    <p><img src="https://simg.open-open.com/show/3dec5c5e9367b7053348151fdde2cd2e.png"></p>    <p>因为业务很大部分已经迁移到虚机，而虚机我们其实提供了各种类型的业务，最常见的就是后台服务，而且非常大的一部分是基于java+Tomcat这种后台的业务，还有一些非常常见的worker业务，它们会接受一些MQ里面的任务然后自己处理，再把处理结果入库或者上云之类的，其他占大部分的就是一些中间件或者是DB Cache，因为不太适合Docker这种应用场景，所以我们首先会着力改造将适合Docker的设计理念的一些业务首先迁移到Docker上，之后我们才会考虑说从满足各种更丰富的应用场景。</p>    <h3>背景 — 技术上</h3>    <p><img src="https://simg.open-open.com/show/9c743ebadcc117a53bf1c58aaf3cc32c.png"></p>    <p>这是我们的技术背景，我们在13年底的时候是接触Mesos，然后14年上半年我们把公司的大约30%左右的转码（图片、视频）任务都已经跑在了容器里面，当时我们上线的Docker版本是1.0，当然我们在调研的时候是从0.8开始调研，所以那个时候Mesos对于Docker的支持实际上还没有，因为从0.16开始它是只有自己builtin容器环境，当然Docker出现之后就有开源的项目，就是让Mesos来支持Docker，所以我们在上线了基于时间批处理业务之后我们就有精力来考虑另外一种业务类型，也就是Long—Running的业务类型，这个业务类型当时官方提供的是基于mesos的Marathon框架，这个框架主要是为了Mesos设计的，现在也经不能运行在其他的框架上。当时还有一个是推ter 框架，但是那个框架比较原始，而且使用起来非常复杂，所以我们就很自然选择了基于Mesos的Marathon框架来搭建我们的App Engine，所以App Engine主要是面向这种Long—Running service来服务的，一个方面是因为作为一个执行调度层的话，它是内建了一些对Long—Running service支持的，比如说像之前大家都说到的，要它保持几个容器的话，它会通过健康检查来发现死掉的容器，然后确保在任意时刻是有指定数量的容器在运行。还有一些内建的服务发现机制。</p>    <h3>出发点</h3>    <p><img src="https://simg.open-open.com/show/f98b35f51ef6526c6f958478dd4a664f.png"></p>    <p>出发点其实很简单，Mesos的设计原理就是说把静态分区的一些数据中心把它整合在一起运行，有一些业务：比如spark可能是非常耗内存的，比如mapreduce可能在CPU计算或者磁盘IO上面会比较高，但是如果你都把单独搭集群的话，它的综合利用率不会高，因为有一些资源可能是闲置的，有一些资源可能就会非常的忙。所以从Mesos设计理念出发的，最早做App Engine出发点是考虑到要省资源，相应的也就是要省钱、要省人。</p>    <p>但是目标当时是非常模糊的，因为我们对于这种具体的业务能够省多少资源是没有精确的这种测量过的，因为业务也在时时的变化，但是我们相信基于Docker这种弹性计算的话，它和虚机相比有一个非常大的好处，也就是它的横向扩容能力非常强。因为基于虚机模式的话，实际上是说你在上线业务之前实际上你要预估你这个业务的量，但是因为虚机部署和上线以及扩容就是太麻烦，往往肯定是会留很大的buffer，至少是留一倍的buffer出来，应对你在紧急的时候能够支撑上你的业务，但是一旦上了这种Docker弹性云的话，这种buffer显然是不需要的，因为它能够时时的扩容。所以我们知道后面可以节省的资源实际上是非常多的。</p>    <p><img src="https://simg.open-open.com/show/6314a1e2b442695b904365bf422da4e8.png"></p>    <p>目标会变的，随着我们慢慢的深入，就是有业务去接入，我们会发现其实让用户从一个基于虚机的开发环境迁移到一个基于容器的这种开发模式下，实际上改变是非常大的，我们也主要在用户的学习成本上以及应用性还有用户受益方面做了一些工作，比如说像学习成本方面的话，一个是文档，一个是开发。因为最早Docker还没有像Docker include这个功能，我们在内部实现了这个功能，所以就可以实现Dockerfile的重用，减少用户写Dockerfile的难度。</p>    <h3>用户受益</h3>    <p>用户受益主要是这几方面：</p>    <p>• 资源到位快</p>    <p>因为我们底层是有多个DC的Mesos的弹性资源池，这个资源池会按一定的规律去建设的，所以对于业务来说的话，这个资源池里面总是可以够单个业务使用的，而不是需要业务临时的去申请，我们再加物理机再往里面扩资源池，所以和虚机相比的话这个资源就到位非常快</p>    <p>• 部署快（上线、升级）</p>    <p>部署快的话主要是在上线升级还有持续集成发布这方面，因为如果是基于虚机方式的话，很多开发者需要管理它一套的这种部署环境，因为一个Long—Running它肯定会用很多的虚拟机，然后管理这几十台虚拟机的环境一致性，其实就是一个非常大的问题。我们这边也遇到过一些情况，就是非常多的用户对于Linux 操作系统这一块并不是非常熟练，特别是对于一些performance tuning之类的。用户说：我的环境全部是一致的。但是这一致的话是它口头上说的------就是我部署都是一致的，但是你具体一不一致的话，这个是很难去排查的，因为对于外面的人来说，等你操作完之后，实际上就是一个黑盒子，但是有docker的话，这种环境的一致性就会非常的方便。</p>    <p>• 扩容快</p>    <p>扩容快和资源到位快是差不多，但是分为两个时段，一个就是业务上线之前它的资源到位，一个是在业务上线之后扩容快，这里对于用户来说是对于他们业务的扩容快，但是对于我们这个基础平台的话，Mesos这个资源层本身的扩容是非常快的。</p>    <p>• 自动故障转移，免运维</p>    <p>自动故障转移、免运维。Mesos本身就实现了这种结算节点的故障转移，所以一旦有上面的task因为底层的计算节点失败的话，它会转移到其他的节点去，所以这个对于和虚机相比的话，虚机故障了以后，是不去处理线上故障，一旦从第一个业务迁移到我们平台之后，实际上就不用晚上起来运维了。</p>    <p>• 完善的监控预警</p>    <p>完善的监控预警，这个相当于是我们在监控预警方面会对业务做一些内置的监控预警，所以这样子每个开发者也就是我们的用户不用自己去部署这些系统层面的监控、预警以及它的业务层面方面的监控预警，因为毕竟非常多的后台应用的开发者对于Linux 系统层面的这种监控、调优实际上不是非常熟练的。</p>    <h2>iQIYI App Engine 设计与实现</h2>    <p><img src="https://simg.open-open.com/show/97aa0a65a8e6c12bab92a6ef12ac6ae1.png"></p>    <p>这一部分主要介绍一下App Engine的设计与实现。这是一个功能框图（如图），我们最下面 是有Marathon和Mesos的弹性资源池，当然这个资源池是多DC的一个集群，对于每一个DC，比如说一套Mesos上面可能会跑多套的Marathon，如果业务有需求的话可能会进行一些物理节点方面的隔离。然后再上面是爱奇艺的App Engine，所以App Engine从设计上是可以跨DC部署你的应用的，主要包含的功能模块一个是自动扩展，然后是任务的管理。主要是因为要从业务的APP逻辑转化为Marathon的task去调度，包括一些生存期的管理。对于CI和CD，现在我们是正在prototype，还没有正式上线。事件总线，对于这种Long—Running来说，另外一个必须的功能实际上还有服务发现，所以服务发现和事件总线，实际上是可以完美的结合起来：基于事件总线来实现这种服务的发现。监控就分为三层，一层是对于底层Mesos弹性计算集群平台的监控，实际上这一层对于用户来说是不用感知的，因为这一层是我们集群运维的工作。预警系统，公司内部的一个预警系统支持多种方式的预警。日志就是对于传统的基于虚机的开发者来说，日志尽量不要改，不要为了去迎合Docker导致只能把日志打成Stdout或者是Stderr。所以日志这一块也是需要提供额外的功能。当然最上面就是API和webUI。然后接下来我们会分模块探讨一下这几大模块的实现。</p>    <h3>QAE — 监控和预警</h3>    <p><img src="https://simg.open-open.com/show/409e0dd0050a04361134e8d4d8fd8e2c.png"></p>    <p>首先介绍一下监控和预警，因为监控非常重要，因为它对于用户来说必须要知道他这个业务迁移到一个陌生的环境、一个陌生的平台，必须要知道它的运营状态，Docker的最佳实践是不推荐用户在容器里面跑 多个进程，包括像SSHD之类的，但是在我们的实际经验中其实很多用户依然会装SSHD进去，即使它有这些监控数据，我们会在每一个计算节点上有一个容器的监控engine叫dAdviser，（后面会介绍）。这个dAdviser它会负责监控所有的QAE启动的这种容器，并且采集包括像CPU、内存、磁盘、网络、数据，当然还有可能是其他数据，这一块其他数据我们后面应该会再继续做，目前还没有做，其他数据可能包括进程里面的数据，可能更详细一些，包括像对比较common的业务，比如像tomcat这种业务包括服务器、内部的监控，这样的话就可以更方便用户去排障、debug以及监视，这些数据全部都会打到一个Time Series DB，然后我们这一块是采用的Graphite，后面我们会介绍为什么采用这个东西。</p>    <p>那除了容器这一层做监控，另外就有业务层的监控，因为一个业务的话肯定是由多个容器组成的，即使是一个容器的话，其实它也是有一些业务数据的，包括对于QAE Core里面能够看到的比如说你处于各种状态的容器数量，这个可以给用户一个相当于一个提醒，就是说有没有容器，现在处于说是一种不健康的状态，所以一旦有了这种支持负载均衡的template，它可以在控制迁入的量，可以在nginx节点上把需要迁移的流量部署上去。实际上它是支持一个template概念，在template我们只会替换说需要替换的地方，也就是说它实际上是支持虚机和Docker混布的，所以即使是在一台Nginx 上，你也是可以同时把流量分发到后面的虚机或者分发到我们的Docker，所以这对于业务的推广还有用户的接入是比较方便的，而不是说一次性就让把用户都迁过来，因为他们的担忧确实是比较大。</p>    <h3>QAE — 日志</h3>    <p><img src="https://simg.open-open.com/show/2ac9f7435cabbd883da8488854837e23.png"></p>    <p>QAE日志，日志我们现在采用的方案也是经过几轮的变化的，因为上线之后用户会有反馈，我们这种架构在QAE Core在启动容器的时候，会注入一个日志卷，注入到容器里的日志卷在主机上有一个唯一的目录。因为根据我们对公司内部业务开发者，这些收集的反馈就是一个日志目录，是能够满足他们的需求的。但是如果你让所有的用户都把日志打到Stdout、Stderr的这个是他们不能接受的，比如像开发代码也好，或者是tomcat也好，他们都需要改代码或者是改配置，所以这个的工程量是非常大的，因此我们就支持这种日志卷的注入，相当于把日志打到这个目录，然后会在每一个计算节点上会有一个log—agent，然后这个agent主要是做两部分的工作，一部分是要负责对日志的采集，然后将日志备份，采集的方案我们现在会有flume，venus是一个公司内部基于flume然后打造的一个相当于服务平台，所以会采用这个方案去把日志上云，上云之后用户可以在这个云平台上面进行一些加工，比如说写一些spark的job，然后来计算它的日志，还可以接入像ELK之类的然后做一些日志统计分析、报表呈现。另外一块就是非常重要的一块，就是时时日志，因为非常多的用户对于日志来说他们很多情况下，如果发现这个业务有一点问题，或者是说失败率过高或者是有一些异常，或者是它依赖的后端服务有异常，就需要时时去看这个容器的日志输出，所以对于上云的那种日志的话它的有一定的延时的，可能在分钟级别，所以对于时时日志的话这个Log—agent会实现一个相当于 websockie 的 server，所以我们的QAE Core会知道说每一个容器它的日志是放在哪一台机器上的，这个Log—agent服务地址会呈现给用户，让用户有一个时时的链接可以点击，当它点击这个链接之后就会和Log—agent建立websockie 的这种实时流的通信机制，所以用户就能在浏览器里面看到实时的日志这种输出和docker logs -f比较类似。当然这个对于那种日志量非常非常大的可能不太适用，因为他们根本就看不过来，但是这个功能对于很多用户来说就是非常需要的。</p>    <h3>QAE — CI/CD</h3>    <p><img src="https://simg.open-open.com/show/fba3df33d5e3e0fc3295114b9ca737df.png"></p>    <p>最后是CI和CD，我们这里选用的是GitLab，而非就是传统的像Gerrit和Jenkins，Gerrit是用的非常早，当然最早规模化是谷歌在用，当然后来因特尔内部也是用这个，但是Gerrit对于用户入门的门槛非常高，它的项目配制和用户权限的管理，包括每一个branche需要的权限，配制的话几乎是需要专门的管理人员才能搞得定，另外一个是看起来比较不美观。CI的话实际上也是采用了GitLab内制的CI，因为CI在它一款软件里面集成的比较好，比较类似像Github和CherryS这种CI的集成，然后没有选用Jenkins的话，也是因为Jenkins对于用户的要求也是比较高的，因为它是从底到上所有都需要用户来配制的，如果我们想要提供一种像CI as a service 实际上是不需要用户来关心下层的这种CI的worker的，也就是你worker在哪跑，你需要给用户隐藏的，当然像GitLab的话实际上就能够把这一部分剥离，这一部分挪到了相当于管理员的任务，然后用户只需要关心他的job，而不需要关心底层的配制，所以GItLab总的来说就是和Gerrit和Jenkins相比的话就是它的用户门槛会低一些，而且它工作方式会比较现代，和Github是比较类似的。所以从Code Hosting/Review到CI ，（GitLab），以及一些开发的工作，Gitlab它的 api和hook机制是非常完备的，支持像json数据格式。所以我们的开发主要就集中在对于像built docker镜像以及像传输到Docker Registry 。另外可以提供自动上线的功能，当用户选择自动上线的话，就可以在QAE里面自动启动你新的镜像。这一块我们现在还在prototype当中，一个原因也是因为GitLab的话它的开发非常活跃，我们在去年年终调研的时候，他们是对于Docker是不支持的，但现在是支持的，所以这一块工作我们会尽快的启动。所以对于QAE平台来说，也就是它不仅会解决业务上线到业务运维这一个纬度，还会解决开发这一个纬度，开发者从他的代码开发一直到生成镜像，就是开发打包和built ceph这一条路的话也会cover。</p>    <h2>一些经验（坑）</h2>    <p>第三部分是一些经验，前面讲的设计实际上QAE现在长成的一个状态，一些经验的会介绍一下我们从开始到现在走过的一些弯路。</p>    <h3>容器监控 — Zabbix</h3>    <p>• 优势</p>    <p>• 已有 Zabbix 基础服务</p>    <p>• Auto Discovery 能发现容器启动/消失事件</p>    <p>• 劣势</p>    <p>• 需要在容器内部安装 zabbix, overhead 太大</p>    <p>• 不是很稳定</p>    <p>• 数据统计比较复杂</p>    <p>首先在容器监控方面，因为虚机已经规模非常大，在虚机监控以及物理机监控方面都是采用的Zabbix，因为Zabbix也是开源的，所以这一块对于我们的优势就是能够沿用已有的基础服务，并且zabbix有Auto Discovery 这种机制，所以它能够发现你在主机上如果有容器启动或者消失事件，它是能够发现的，它能实现自动的去感知，并且自动的去监控，所以当时看来也是能够直接采用的。但是后来Zabbix的问题也是比较明显的，一个是在镜像安装Zabbix这个overhead比较大，因为你在一个计算节点上很可能会跑非常多的容器，那么在每一个容器内部如果你都运行一个Zabbix的话，overhead很大。另一个也是不符合Docker这种最佳实践。还有一个问题是-----不是很稳定，因为一旦量很大之后，到Zabbix proxy 还有一些地方都会导致它不是非常的稳定。数据统计比较复杂。因为我们做一个App Engine实际上是以APP为中心的，而不是像以前虚机那样子，虚机比较重，所以会以虚机为中心，但是Zabbix它没有内置的数据的统计，就是将多个容器的数据整合成一个APP的数据，从容器的纬度转换成APP的纬度，所以这个是需要自己开发的，而且Zabbix的API实际上真的写的是不怎么样，所以用起来会非常麻烦，后来我们就完全抛弃了用Zabbix来监控容器。</p>    <h3>容器监控 — cAdvisor</h3>    <p>• 优势</p>    <p>• 背靠 Google 且开源</p>    <p>• 监控数据详尽</p>    <p>• 劣势</p>    <p>• 集群化开发成本较高，Kubernetes heapster 实现</p>    <p>• influxDB 而非 graphite（当时有基础服务）</p>    <p>在14年谷歌开放了，因为我们在Kubernetes之前就做这个东西，所以我们后来决定放弃Zabbix之后也调研了谷歌的cAdvisor，一个是背靠谷歌且开源，跟一些小项目来比的话，它的持续开发和社区的质量是能够保证的。另外一个就是它的监控数据是非常详尽的，包括我们general想要的，像一些CPU memory的统计，它还会有更详细的，比如说每一个核的统计，包括每一个核的IDL或者是User time and Sys time之类的都会有统计。劣势，就是cAdvisor它是一个单机版的监控，集群化开发成本较高，Kubernetes heapster实现的，所以对于像不采用Kubernetes你需要自己去实现这个集群化的工作。另外一个就是cAdvisor它的backend的存储只有两种可选，一种就是In-Memory，In-Memory显然是不适合的，而且它的memory是有限制的，所以你只能看到最近10分钟的数据，显然用户不可能只看最近10分钟的数据。另外一种持久化的存储采用的是influxDB，influxDB 也是一个非常新兴的一个time series DB。而当时我们对于像内部有这种现成的graphite服务，而且对于graphite使用起来也比较熟练，所以我们也没有同时去上cAdvisor。</p>    <h3>容器监控 — dAdvisor</h3>    <p>• Docker Advisor</p>    <p>• 采集：CPU, 内存，磁盘，网络</p>    <p>• 集成现有 Graphite</p>    <p>• 统计数据方便（Graphite 内置一些操作符）</p>    <p>• 呈现方便（Graphite Render URL API）</p>    <p>• 开发量不大</p>    <p>最后我们考虑到简单我们就自己写了一个容器监控，我们也就follow谷歌的这种 cAdvisor命名方式，因为C的话是代表contianer，所以我们就直接叫了一个Docker的dAdvisor。它的功能实际上就非常简单的，主要就采集这几个方面的数据，CPU、内存、磁盘、网络，这些数据实际上都可以从kernel cgroup直接就能拿到。另一方面和现有的 Graphite 集成，开发量也不大，所以容器监控这一块就可以非常快速的满足现有的需求。</p>    <h3>Time Series Database — Graphite</h3>    <p>• 优势</p>    <p>• 老牌（Since 1999），已有服务，经过验证</p>    <p>• 简单、内置 aggregator，Render URL API</p>    <p>• 劣势</p>    <p>• 项目及社区已经几乎停滞</p>    <p>• 集群化配置复杂，需要详细规划</p>    <p>• 缺乏多用户认证，授权机制，黑白名单太单薄</p>    <p>• 数据删除缺少 API</p>    <p>Time Series Database 现在用的Graphite，一个是因为它非常老牌，已经有10多年历史了，用的地方非常多，在公司内部也是非常多的地方在用，所以我们也就相对于是现有的这种background 直接就用 Graphite。另外粗看起来Graphite好处就是比较简单，包括它有一些内置的aggregator的进程，类似于proxy的东西，所以这个 aggregator，它可以实现一些数据简单的算法（sum ，average等算法），所以对我们来说非常的好用，比如我可以将所有的计算节点上的同一个服务的容器监控，然后经过像这种求average后，我们能够拿到这个服务的平均值，所以这些内置的功能的话相比Zabbix来说就会非常方便。除了像aggregator这一方面的话，还有就是它的呈现非常方便，也就是它的输出，它的Render URL API 是非常简单好用的，包括能够进行一些简单的算法，包括对于多种数据类型的输出，像一些图片或者是json或者是一些裸数据的输出。这样子在业务层面上实际上是能够快速的就把这些数据以多种方式展现给用户，当然最常见的就是一些监控图片展现给用户。或者我们可以拿一些json数据，就是用一些JS的画图工具自己重绘，这个也是非常方便的。</p>    <p>当然它的劣势也经过一段时间使用的话也比较明显，一个是项目和社区几乎已经停了，如果你发现现在有不太满足你的功能的话，在短时间内的话你几乎是可以预计这些功能是肯定不会有人再需开发的。如果要自己去弥补这些功能的话，对于像可能只有公司规模更大可能会投入一些资源去自研或者是弥补它的功能缺陷。另外一个就是集群化的配制非常复杂，Graphite是有三个进程，你要实现数据的shading和数据的replication，这个是需要详细规划的，否则的话你后面要实现数据的迁移，这些几乎都是一些运维的成本。我们如果作为一个平台的话，实际上它会缺乏很多的API，包括像数据删除，还有多用户认证、授权，这些机制实际上都没有的，所以对于数据安全这一块的话是非常弱的，也就是它仅有的安全机制就在于黑白名单，黑白名单的话显然是不太可用的，因为你即使限制了数据的这种合法值，但是你没有认证授权的机制的话，实际上每个人都可以去写的，这样的话数据可能保证不了安全。</p>    <h3>服务发现（Service Discovery）</h3>    <p>• 负载均衡/反向代理方案</p>    <p>• HAProxy：Marathon 支持，用户少</p>    <p>• Nginx：大量用户</p>    <p>• 服务发现</p>    <p>• Flask 推送，SSH，不可靠，不安全</p>    <p>• Ansible 推送，SSH，不可靠，不安全</p>    <p>• event bus + guardro-template</p>    <p>服务发现，在Marathon upstream原生是支持这种 HAProxy来作为服务发现机制的，但是 HAProxy在公司内部大部分业务都是采用的Nginx， HAProxy用户非常少，所以我们也没有支持HAProxy，所以选用的是Nginx。服务发现，我们实际上有三个过程，因为我们的项目是用python写的，所以最早是用Flask，有关我们的Marathon整个集群是用的Ansible，对于Ansible这块也比较熟悉，后来换到Ansible，都会发现SSH都不是非常可靠，因为对于有一些主机来说，它的SSH状态可能是不太稳定的，或者是说你要配制一些Key之类的，就是对于这种要服务发现来说都显得比较重，所以我们后面就实现了基于event bus+ guardro-template的方式来实现服务发现。所以前面两种方式都没有用了，都全部采用后面这种方式，而且工作的也非常好。</p>    <h3>日志</h3>    <p>• ELK (Elasticsearch + Logstash + Kibana)</p>    <p>• 延时较高（分钟级）</p>    <p>• 只支持格式化后的日志（for machine）</p>    <p>• 用户诉求</p>    <p>• 低延时（秒级），准实时</p>    <p>• 裸日志（for real person）</p>    <p>• 备份日志（Apache Flume）</p>    <p>日志，我们最早采用的是ELK，也是考虑到也是有限额的服务，但是采用之后用户对于真正使用ELK去排障去做呈现、做报表做一些搜索、检索之类的，在我们看来几乎没有，因为很多用户都不习惯这种使用方式。另外一个就是延时也比较高，支持格式化后的日志的话，所以它对于要仍可读的话理解上会比较困难，因为即使是你把所有的裸日志都采出来的话，因为它每一条日志都切片，都打了一些tag所以看起来也非常头疼。用户最终的需求目前来看就是低延时，我需要一些准实时的日志，另外就是要裸日志，裸日志好处就是我仍可以读，我一旦有了裸日志实际上就对这种裸日志进行任何的处理，包括像上云做一些计算，然后再包括到ELK之类的都是可以的。</p>    <h2>现状与展望</h2>    <h3>现状</h3>    <p>• 处于活跃开发状态</p>    <p>• 接入了几十个业务</p>    <p>• 主要业务类型：服务型，RPC，Worker</p>    <p>• 服务型业务 QPS 大于 10 万</p>    <p>• 4 个数据中心</p>    <p>关于现状：我们项目已经开发了挺久了，从2014年到现在超过一年了，现在还处于一个活跃开发状态，因为我们的人手确实也不太够，因为弹性计算平台包括像底层的建设还有整个公司所有的这种转码业务实际上都接到我们的平台，包括短任务这种量是非常大的，我们的容器每周会达到200多万的量级。现在开发这个业务的人手远远不够，目前也接入了一些业务，但主要在这几种类型，一个就是服务型的，就是Long-running service，另外像RPC，因为很多RPC的发现实际上都不需要我们做的，因为他们自己会基于JK或者是基于其他机制来实现RPC的服务发现，所以RPC和这种Worker类型的话，实际上对于我们来说它需要的服务的要求是最低的，这三种业务实际上现在是主要接入的业务类型。目前在线的业务QPS我们已经超过10万了。</p>    <h3>展望</h3>    <p>• 支持短任务</p>    <p>• Quota 和计费</p>    <p>• Web Console</p>    <p>• 内置典型服务（如：Tomcat）数据统计</p>    <p>• Docker 持久化卷和跨主机通信</p>    <p>• 支持更多类型服务：Cache, DB, MQ 等</p>    <p>最后是一些展望，第一个是Web Console ，Web Console 也是为了迎合用户对于虚机使用习惯，你虽然提供了一些容器给我，但是对于他是一个黑盒子来说，总是会有强烈的需求我想进去看一下到底是什么样的，所以Web Console 我们希望能够改变用户在里面装SSHD这种服务的习惯，然后通过也是类似于像Web VNC或者这种WebSocket（39：52英文）的这种类似，让用户在浏览器上获得一个交互的Console，能够对于每一个容器能够进行交互式的操作。内置典型服务的数据统计，这个也是我们根据接的业务来看的话，实际上有非常多的是基于Tomcat这种java的这种后台服务，所以这一方面我们可以针对这种服务做一些builtin的数据统计、监控，然后就是给用户一些额外的监控数据。第三个Quota 和计费，其实Quota 和计费在私有云来说对于公司内部来说，基本上相当于优先级非常低的一个功能，如果业务需要的话，需要这么多资源，实际上你都得给他。Docker 持久化卷和跨主机通信，实际上我们现在因为接入的这些数据类型对于持久化卷和跨主机通信这一方面的要求实际上都不高，因为服务的话都是通过服务发现来接入的。因为我们内部的云平台实际上对非常多的中间件服务还有DB cache、MQ就是各种公共的服务实际上都有专门的团队，都已经把它云化了，所以各种后台写业务逻辑的开发者的话，实际上大部分都是用的公司的私有云服务，所以对于持有化卷的需求的话也是比较少的。支持更多类型的服务，也就是我们在支持像long-running 的web service ，worker，RPC这些业务之后，也就是随着Docker的这种开发对于持久化卷和跨主机通信方面的进展，我们也会在业务类型上进行一些横向扩展，比如说支持一些Cache、DB、MQ之类的业务类型。最后还有可能会支持短任务，因为对于短任务来说实际上API是最方便的，很少有人会通过WebUI去提交一些短任务，那样子的话效率太低了，所以我们现在的短任务是跑在一个cronnos平台上面，那个任务量是非常大的，我们后面也考虑会把那个任务接入到QAE平台上，可以进行一些数据统计之类的工作。我的分享就结束了，谢谢。</p>    <p> </p>    <p><a href="/misc/goto?guid=4959675513414368066">阅读原文</a></p>    <p> </p>