京东业务如何整体上云

标签:云计算京东OpenStack京东云

访客:42284  发表于:2015-12-07 10:44:06

大家下午好。我是京东云平台的何小峰,今天跟大家分享的主题是京东的业务如何迁移到云上面去的。

迁移到云之前我们有很多的痛点,这是领导层的痛点。京东业务发展非常快,每年服务器增长规模都会上万台,如果按照一台机器成本算几万块钱的话,这个硬件成本每年都几个亿,包括数据中心盈维这些成本加起来,这是非常大的一笔开销。我们每周会有两次上线,每次上线都几千个在等着上线,效率不是很高。我们现在系统有这些痛点,大家一直在反思,以后未来IT基础设施怎么建构的问题?这是我们的领导层特别关心的一些问题。下面的研发团队沟通的时候他们关注问题点又是不一样的。他们很关注的问题是你这个系统稳不稳定?你给我的IT基础设施必须是稳定的,你的IT基础设施带来的性能,跟我的系统有什么影响?如果我的应用迁移到新的基础设施里面,我的性能下降了,这肯定是不行的。所有这些团队已经习惯了某种方式,比如说登录这个机器上分析问题,解决问题,或者怎么部署这个应用,怎么垂心培养这个用户新的习惯了和新的工具?经过我们分析这些问题以后,我们差不多在2013年就开始云的迁移的准备了。

京东业务如何整体上云

                           京东集团高级架构师何小峰

2013年的时候我们最新使用KVM,现在整个KVM外界已经运行了一段时间,我们也运行了一年作用,有一个反馈感觉不是很快。用户专注的是性能的问题,用户反馈不是很好。正好dockar的容器发展比较快,经过我们评估我们觉得dockar特别适合我们这一块的。我们建的是私有云的,跟公有云相比安全性能方面比较好。另外一块Dockar竞相流程非常快,每周上线的发布,我们应用程序迭代的更新,可以做多快速的更新。2014年就拿着京东的图片系统,大家上京东的话其实首先看到的就是这些图象。我一般看这个图片好看再进去选。这个图片很重要,先把这个系统试别。第一它很重要,还有一个跟重要的是这个图片系统是我们能够掌控的。正好是我们这些团队符合比较重要的一个系统。我们拿他们系统试点,试点的结果感觉到这个非常好。原来物理器上搬到容器上整个性能没有什么损失,整个京东用户反馈没有受到任何的影响,根据我们这个流量做一个弹性的伸缩。特别是晚上的时候会发现它这个用户的访问少了,它这个机器的数量会下去。当你摆摊的时候,这个量不会上来,因为用户访问比较多了,它的压力大了。经过我们这个试点以后2014年缩减一个平台,整个京东运用迁上去。2014年初,我们就把我们的弹性这个平台建起来了。建起来了以后,我们也是一个逐步相对的过程。首先迁的时候,我们已经知道这个存储系统已经上线了,我们找了一个单体页,这是一个非常的重要的页面。为什么找这个页面试点我们这个容器?这个页面也否非常地重要。而且它是系统的客户。这个单频页是其他研发团队建的,我们不能自己说自己系统的好。其他客户说我们好可以给我们形成一个良好的口碑。这样单频试点以后给我们一个非常好的报告,他们性能各个稳定性都非常好。在我们京东每年有两个大数,一个618一个是双十一,618把一些大规模的应用往下迁了,大概618的时候有一万的容器支持我们整个京东业务跑,一些单频,包括风控的系统还有整个618的大频的暂时已经迁过去了。618期间非常稳定,没有出任何的问题,这个更坚定了领导层的决心,他们非常大力地支持我们的推广。在双十一的之前我们全部使用我们这个弹性,建设我们新的数据中心。所有的应用系统都迁移到这个数据中心都是落在我们这个弹性上面。在整个双十一的时候,截止到双十一,我们在线的容器已经达到了6万多,应该是在国内的话,这个数字也是很领先的。

如果我全部进行重新建,这个不太可能短期内把它做出来。这是比较成熟的技术,我们可以完全使用了。为什么上面自建的平台?更多是跟我们京东现有的系统整合系统,保持用户的习惯。现在京东有非常多的基础设施,包括监控,部署,原代码的管理。这些系统整合起来,保持应用系统。要用openstack是非常困难,这样可以对我们的应用进行部署和监控,包括弹性的伸缩。

openstack我们是延用的这一套,首先它是开元的,他也非常成熟了。也有很多的主件。另外一个很重要的一点,我们要把公有云和私有云的价格完全统一起来。未来京东的公有云,它会和我们私有云的架构完全一样。我们可以保持一套价格。另外openstack我们也提了很长的经验,2013年我们在做一个云的时候也是请openstack来做的,这样我们经验还是积累比较丰富的。

我们怎么样整合这个openstack容器怎么整合起来,就是把openstack当做我们docker Vift的方式。它可以利用openstack的组建。

网络上稍微提一下,这边要提的是我们每一个容器都有一个独立的IP,这个的目的也是为了保持这个用户的习惯。因为公司所有基础IT设施,基本上都是用这个IT标识这种资源。就是一些物理性原来是用IT标识,我们所有应用系统,如果要监控,去管理这些都需要IP。我们现在把所有的这个网络上,我们采用是OS来做的,然后使用vLan的模式,但是我们每一个IP都是独立的。

存储这个用户也非常关心,存储我们采用xfs的文件系统,还有文思有一个jfs的快文件系统,还有这个数据卷。很多系统有很多日志,这些日志是不能丢失的,方便以后查询。

京东每周可能会有上千个应用在发布,每个应用如果是一个镜像的话,一个应用可能会有迭代几千个的镜像,如果是你一个镜像都不剩的话,你这个网络的流量开销是非常大的我们需要尽量把这个镜像做的足够小。这样做了一个大概分成,是这种OS层,技术层和应用层。这样的目标,应用层是只有真正应用,它变化的时候我们才需要把那个镜像,只需要拉那个应用的时候这个变化最小的,下面这个基础层和S层都会比较复杂,所以这些容器上面的,物理机里面。当需要应用上线的时候只需要把上层的应用层的代码拉过去就行了。

这是为我们这个京东的研发系统所构建一个镜像中心。我们为什么这样做,一个程序编的以后,只需要在线下编译一次就可以发布到我的线上去。还有一个地方是需要做处理的,就是我在线下编译的应用,是怎么样发多线上的时候,其实有一些配制是需要改的。比如说数据库,一些认证,这些东西可能都会不一样。这些东西我们是做了一个撇之中心来做的动态的修改,然后可以在我发布到线上的时候,会把这些配制做了替换。所有这些镜像文件只需要编译一次。

这里面提到这个配制中心。现在所有的应用都依赖于这个配制中心,这个配制中心会分不同的环境,我有测试环境,还有我这个应用可能面向不同的,AB测试配制不一样,有不同的分组区分这样一个应用,这样的话每一个应用分组在不同的环境下有不同的配制,这样的话它在线上的时候这些配制都会进行动态的替换。大概我可以讲讲我们这个上层的应用平台的简单的价格。这个价格看起来划的比较多,其中就是中间那一块。其他基础设施都是京东现有的基础设施。右边一个,左边一个,都是现有的。我们中间做了一个分布式流动调度,就是把京东所有基础设施全部集成起来,集成到我们这个平台。然后把我们这个弹性也是建立了这个基础设施之上。

还有一个用户很关心的事情,就是监控。为什么要监控?用户在这个前面也提到了,第一个要求是稳定,怎么知道系统稳定,就是监控的指标知道这个系统是否稳定。我们现在对整个云的监控,跟以前物理机所有的监控都是一样,所有这些指标都是有的。比如说连接数,CPO,内存,网络,以及系统是否是存活,我们保留原来的物理机这样一个系统是完全一致了。

比如说我的利用率很高了,99%我们可能做一个报警,根据这个指标触发我们一个弹性的伸缩。我的连接数量很快高了,我们可以立马在一个另外一个事例把整个数降下来。

当我们怎么检测这些容器的存活,因为这个也是很重要的,就是有时候我们这个容器因为有很多原因,不管是物理机也有可能出现问题,怎么探测出这些出了问题的容器,我们会定时的去拼这些容器。如果三个机房里面会说这个容器出了问题,我们会说这个容器出了问题。如果只从一个机房拼的话是有可能反馈到不是很准确,因为有部分是网络出问题,机房出了问题,检测另外一个机房容器有可能访问不通,但是这个容器是存活的。因为访问不通,不会认为他是出了问题。我们是从三个机房同时检测的。

物理机的探测,我们也会实时采集物理机的情况。如果物理机出了故障,可以把这个通知运维做一个下行的处理。这是所有监控的页面,这一块儿跟我们数据的监控中心,他们会集成24小时看我们的产品的情况。这上面有哪些容器出了问题,还有整体的复杂的流量情况是怎么样的。目前整个京东弹性还是走到页面比较领先的地位。我们涵盖了整个的研发的流程,包括了我们的上线、下线还有一些一弹性的伸缩,故障的一些迁移,包括日常的部委。

简单介绍一下我们这个扩容的流程:我们京东这么大的压力了,在双十一的时候或者618的时候它的流量非常大,比日常有几十倍的流量增长。日常十台服务器就支撑了,但是618可能上百台的机器支撑,怎么快速进行一个扩容?我们会有一个弹性调度的程序。它会不断的检测这些指标,我们上传的这些指标,发现整个应用拓展比较高,比如说我的连接数太高了,会通过一定预测算算出来,会触发整个流程。包括这个创建容器,对这些数据库授权,然后注册部署,整个流程全部齐起来了。我们所有这些流程其实跟大家手动上线差不多。我们这个系统自动化的工具做起来了,让大家比较熟悉这样一个流程。

还有一个问题,就是经常会甬道这种物理机故障,因为京东服务器非常高了。每天都有这种物理机损害的情况。我们怎么样检测这样一个问题?做一个快速的迁移。发现一台机器有问题以后,把一台容器快速吸引到另外一个服务器上面。

核心所有应用都已经迁到这些弹性上面,还有一些金融的,一些O2O的,所有的这些基本上已经迁到我们弹性运营上。我们接触的类型里面会有哪些,这个应用方面。比如说会有一些程序,还有一些缓存的,还有一些微服务的架构的程序,都已经迁移到整个弹性上面。

领导很关心的问题我们资源使用率怎么样,为什么买这么多方面的服务器,就是通过这个弹性以后可以得出所有的弹性以上的应用的资源情况,包括每个容器的资源使用率。还有这个也用资源使用率怎么样,是高还是低,为什么跟你扩容?以及部门情况使用率怎么样,部门这些资源使用不是很合理?通过这些我们可以对这个京东的资源可以做内部的调度让它做的更合理。为我们未来精细化的运营做了一个很好的铺垫。如果我们把这个京东的资源利用率提升一倍定这个财务报表也可以做的非常好看。

另外我们会对这个京东所有应用做定期的巡检,是因为我们在整个京东的建设过程中,它所有的路径都是一批一批来的,所有机房不是一下自动化全部已经到位了。在整个建设的过程中难免会存在着某些机房部署过多的情况。定期做一些巡检,根据这个巡检报告做一些部署机的调整。

实践经验,对一些磁盘要求如果不高的应用很适合部署在我们这个弹性里面,做一个弹性的伸缩。一些微服务的架构,本身注册和发现非常部署到我们弹性上面。整个弹性的建设过程中,推荐使用万兆的交换机跟网络。网络这一块儿如果大家竞争的话,会形成一个瓶颈。还有比较稳定的操作系统的版本,物理机这些配置要求尽量高一点。如果物理机的配置比较低,可能比较浪费资源。

我今天介绍的内容就是这些,谢谢大家!


评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");