针对京东应用开发平台jae的一些核心技术进行分析

JD.COMPaaS平台的主要服务对象是两类人，一类是个人开发者，二类是JD.COMISV。在数据开放平台日益成熟的背景下，他们都希望以最低的成本方便地部署自己的应用程序，提高生产力。而且京东Paas平台是为了满足开发者和ISV的这一需求而开发的。JAEEEAS平台的核心是JAE（JingdongAppEngine），以CloudFoundry为核心，之所以选择CloudFoundry，是因为CloudFoundry是社区中最早开源、最成熟、最活跃的基础PaaS平台。为了为开发人员提供更方便的服务，JAE云化基本服务，访问高可用MySQL服务、Redis缓存集群服务、消息队列等各种应用组件服务；此外，它还结合应用开发工具，为开发人员提供github代码托管服务、云测试、Java工程云编译和资源统计信息，使开发人员更加关注自己的代码业务。此外，JAE对平台上托管的应用程序进行健康监控，支持查看应用程序日志，并提供其他安全服务。让开发者只关心自己的应用代码，JAE为其提供其他一切，大大提高了开发者的效率，降低了开发成本。下图描述了JAE与PaaS平台用户及其他相关服务的关系。JAE还根据JD.COMPaaS平台的需求进行了许多有针对性的功能扩展。本文主要讨论JAE的核心技术点。JAE的其他基本服务将参考其官方网站：智能路由（LoadBalance）众所周知，CloudFoundry支持设置应用的实例数。但是，当并发量增加时，请求（Request）能否均匀分配给后端的例子？对于多实例的应用，Cloudfoundry采用随机策略响应客户端的要求，不能公平有效地利用实例资源。当并发量达到峰值时，有可能发生雪崩。为了解决这个潜在的问题，JAE借鉴了nginx的路由策略，采用了权重（weight）算法中，负载越小，响应请求的机会就越大。那么，我们需要进一步解决的问题是：如何计算实例的负载，以及在收到请求后如何分流？下图是JAE的模块关系图:所有请求首先到达router模块，router保存所有实例的路由信息(即实例的ip和port)，并决定哪个实例来响应请求。每个实例的ip和port信息都是dea模块通过nats消息总线转发给router的。实现原理是dea将服务器上的所有实例信息发送给nats，router订阅消息，收到后保存在路由表中，通过过期失效机制定期获取最新实例信息。为了让router获得每个例子的负载信息。我们对dea模块进行了改造，每次向nats发送消息时，我们都会“携带”此时此刻的负载信息。dea模块收集dea服务器本身及所有实例的CPU利用率、内存利用率、I/O等原始信息一起发送给router。router决定如何从这些原始数据中计算负载值。至于用什么算法来计算负载，这是router自己的职责范围。我们采用了以下算法:实例真实负载=(vm负载*30% *70%实例负载*100%vm负载=CPU已使用%*30% Mem已经使用了%*30%的实例负载=CPU已经使用了%*30% Mem在上述算法中使用了%*30%，在计算实例的负载值时，我们考虑了dea的因素，因为dea实际上是服务器(虚拟机)，而实例运行在dea上的每个过程中。如果一个dea的负载很高，而其上一个例子的负载很低，那么router可能不会将请求交给这个例子。如果一个dea的负载非常高，而其上一个示例的负载非常低，那么router可能不会将请求交给这个示例。所有算法都应该考虑dea的感觉。计算每个应用实例的负载值后，JAE提供了以下平衡策略：从以下代码可以看出，Router采用了weight策略。有状态的（stateful）未经智能路由处理请求。例如，当session存在时，在第一个请求之后，服务器将响应请求的实例信息回写到客户端的cookie中。当router收到客户端的下一个请求时，它将转发给同一个例子。有人可能会问，这是否会影响请求的响应时间？答案是肯定的，但影响很小，因为算法是纯数值计算，效率很高。目前算法只考虑了几个常用的因素，还有优化的空间，比如增加负载的因素，比如I/O，例带宽的使用等。弹性伸缩（Auto-scaling）在最后一个话题中，当并发量继续增加时，所有实例的负载都可以通过智能路由平衡，但如何应对实例负载的持续增加，并面临应用程序随时不可用的情况？只需添加例子！虽然我们可以通过JAE控制界面轻松地增加或减少应用程序的实例数（只要资源满足）。然而，这种纯手动方法显然是不可取的。JAE采用弹性伸缩机制自动化这一过程。常用的方法是定义扩展规则。以下是JAE管理页面的规则设置：规则是用户层面的全球定义。每个用户可以创建多个规则，并在具体应用绑定规则后生效。该规则的正确执行取决于“过去几分钟平均申请次数”的指标。我们通过实时统计获得这个指标。实现流程图如下图所示:所有router服务器均安装agent、flume集群实时收集routernginx访问日志，保存在redis中，定期清理，同时将分析结果保存在同一redis集群中，规则引擎从redis中获取数据，与应用程序的规则进行比较，判断是否触发规则。然后调用cloudcontrolerestfulapi来扩展或减少实例数。向云日志和云监控模块发送原始日志和分析结果，为应用程序提供相应的功能。将原始日志和分析结果传输给云日志和云监控模块，为应用程序提供相应的功能。例如，查看和搜索dashboard管理页面上的应用程序日志；应用PV、UV监控趋势图等。智能启动（Auto-loading）如果80%的应用程序不活跃，但总是占用资源，就会造成巨大的浪费。智能启动的意思是，当某个应用程序在一段时间内未收到请求时，应用程序将暂时休眠，并在下一个请求到达时立即启动。长时间不要求的应用，再次访问时，会有秒级加载延迟。如图所示，访问日志的计算结果也用于智能启动，计算统计周期中每个应用程序的访问次数，并保存在Redis集群中。智能启动模块从CDB过滤获取待处理的应用列表，依次获取Redis周期内应用程序的总访问次数。如果发现为零，首先调用Ccrestfulapi停止应用程序，然后将CCDB中的应用程序识别为Sleep状态，并通知Router更新路由表信息，使路由表中有所有正在运行的应用程序实例信息，还有sleep状态的应用信息。当Router收到下一次访问时，首先从路由表中找到相应的实例信息，发现该应用程序处于sleep状态，将激活该应用程序，并立即返回给客户端一个加载页面。当Router收到下一个访问时，首先从路由表中找到相应的实例信息，发现该应用程序处于sleep状态，将激活该应用程序，并立即返回给客户端一个正在加载的页面。通过刷新页面，您可以正常访问应用程序。下表从natsmessage解释了模块之间的交互:资源隔离和访问控制资源隔离是cloudfoundry的精髓。除了各种功能便于JAE开发外，最重要的是“安全感”。资源隔离意味着应用程序之间的资源相互隔离不受干扰。访问控制意味着在JAE内部，应用程序不能以任何方式相互访问或操作其他应用程序。但其他应用程序可以通过HTTP访问。JAE在整个过程中也做了一些尝试，在这里分享。JAE在整个过程中也做了一些尝试，在这里分享。Cloudfoundry使用warden实现资源隔离和访问控制，但JAE的第一版资源隔离策略使用vcapdev，当时没有warden。在当时的背景下，cloudfoundry官网还没有迁移到v2版，业内成功应用也相对较少。JAE采用稳中求进的方案，即在vcapdev的基础上，借鉴warden的思路，实现资源隔离和访问控制。接下来，我们将详细介绍JAE第一版的资源隔离实现方法。部署所需资源灵活，不仅支持单机部署，还支持多机部署，对个人开发者有很好的参考。如上图所示，实现JAE第一版资源隔离和访问控制的方法是vcapsafemode cgroup quota ACL。首先，vcapsafemode提供了访问控制功能，安全模式为dea服务器创建了n个用户，默认为32个用户，vap-user-11至vap-user-32.它属于vcap-dea用户组。启动应用程序实例分配用户，并将代码目录的所有者设置为此用户。如果实例停止，则回收用户。这可以简单地保证应用程序之间的访问控制，不同的应用程序（不同的用户）不能相互访问。vcapsafemode只设置了应用程序目录的权限，限制了目录间的访问，但大多数系统命令和系统文件，如ls，仍然可以看到或操作mkdir,/usr/bin，/etc/init.d/，这很危险。JAE通过LinuxACL（accesscontrollist）禁止大部分系统命令，有点杀敌1000自损800的味道。许多应用程序需要调用系统命令。ACL的具体做法是限制用户组vcap-dea对绝大多数系统命令的查看和操作权限：JAE使用safemode ACL在某种意义上实现了访问控制。为什么说是某种意义上的？在特定的Namespace中，虽然它提供了一些功能，但没有Namespace的概念，PID、IPC、Network是全球性的，每个Namesapce中的资源对其他Namesapce都是透明的，而safemode是透明的 ACL是一种共享方案。后来JAE升级的主要原因是Namespace问题。其次，说到资源隔离，应用的系统资源可能有内存，CPU、磁盘和带宽等。JAE借鉴warden方案，利用linux内核自带的cgroup和quota来解决内存，CPU、磁盘隔离问题。下面，借此机会介绍warden的实现细节。cgrouppwarden实现原理（ControlGroup）它是Linux核心的功能。简单地说，它是对过程进行分组，然后对资源进行调试和分配。其结构为树形结构。每个root都管理下面的所有分支，分支共享root资源。这些群体由每个子系统控制和监控。cgroup的子系统有：CPU、CPUset、CPUacct、memory、devices、blkio、net-cls、freezer，不同的linux内核版本提供不同的子功能。cgroup的系统目录位于/sys/fs/cgroup，JAE宿主机为ubuntu12.04LTS，默认有以下子系统：CPU、CPUacct、devices、freezer、当dea启动时，memory将重新初始化cgroup和mount子系统。安装cgroup系统/tmp/container在cgroup下，mount了四个子系统。当部署应用程序时，/tmp/container/cgroup/memory目录生成此应用程序的进程节点，命名为#{instance_name}-#{instance_index}-#{instance_id}，即“应用名-应用实例号-实例id”，将应用的内存配额写入memory.limit_in_bytes，memory.memsw.limit_in_bytes。限制可用的最大内存和swap值。限制了可用的最大内存和swap值。然后将实例的过程ID写入每个子系统的tasks文件中，注意到每个子模块的notify_on_release设置为1，告诉cgroup，如果应用程序消耗的资源超过限制，kill就会下降。Warden写了一个OomNotifier服务来监控内存的消耗，然后进行具体操作。就我个人而言，Oomnotifier可能有更“温和”的处理方法或更逻辑的处理方法。但目前OomNotifier只做了kill操作。JAE为什么不设置CPU子系统来设置内存配额？由于在JAE环境中，应用程序主要是内存消耗，如果CPU想设置配额，只能设置占用时间的比例，逻辑上不能更直观地为应用程序分配CPU资源，因此采用了“平均分配”的原则。如果虚拟机上只有一个应用程序示例，则此应用程序示例可以“独家”，因此CPU资源。如果有两个应用程序示例，则每个应用程序最多只能使用50%，以此类推。CPU的利用率是过去一段时间使用实例所占用的CPU时间/总时间。接下来说到磁盘配额，JAE使用了linux内核的Quota。Quota可以对某一分区下指定的用户或用户组进行磁盘限额。限额不是针对用户主目录，而是针对这个分区下的用户