针对京东应用开发平台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可以对某一分区下指定的用户或用户组进行磁盘限额。限额不是针对用户主目录，而是针对这个分区下的用户

以上就是关于针对京东应用开发平台jae的一些核心技术进行分析的相关介绍，更多针对京东应用开发平台jae的一些核心技术进行分析相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对针对京东应用开发平台jae的一些核心技术进行分析有更深的了解和认识。