独立出来的美团云业务部目前有十几位工程师。虽然部门独立，但工作中仍然跟系统运维组有紧密的配合。美团系统运维组原本就有三分之二的开发工程师，而运维工程师也全部具备编写代码的能力，因此开发与运维工程师能够进行紧密的配合。相关厂商内容美团云的最初版本起步于2012年7月，一开始是作为私有云计算平台来构建。第一版开发了大约2个月的时间，之后用了大概10个月的时间将美团的所有业务迁移到云平台上。现在除了Hadoop、数据库仍跑在物理机上之外，美团网的所有业务都已经运行在美团云上，内部的研发、测试平台也运行在美团内部的办公云平台上。2013年5月，美团云开始对外提供公有云服务，截止到目前仅对外提供云主机产品。对象存储、Redis、MySQL、负载均衡、监控、VPC等服务也在研发，部分产品已经在内部以及部分测试客户使用，未来会根据产品的成熟度和客户的需求程度逐步对外开放。稳定是公有云服务的核心价值。自从公有云服务开放以来，美团云主要的工作都放在提升云主机的稳定性，完善云主机模板、备份、监控、安全等工作上。预计在2014年9月，美团云将发布其第三个版本的更新，继续打磨其产品细节。技术架构美团云最初选型的时候对OpenStack、CloudStack、Eucalyptus都做过调研，调研的结果是架构设计使用OpenStack的框架，网络架构参考CloudStack，主要组件由自己开发，部分组件在OpenStack原生组件上进行了二次开发。核心的云主机管理系统是自己研发，没有使用Nova。采用Region-Zone-Cluster三层架构，支持跨地域、多数据中心的大规模集群部署。采用了基于KVM的主机虚拟化和基于OpenVSwitch+OpenFlow的网络虚拟化技术。镜像管理用了Glance。有一定修改，例如，多数据中心分布式支持，以及镜像替换。身份管理用了Keystone。有一定修改，例如，高并发性能改进，与美团帐户系统的集成。对象存储用了Swift，但Swift在写延迟方面存在性能问题，同时在OAM方面的功能比较薄弱，所以也做了一些修改和研发。Swift现在已经在为美团网内部存储量几十TB量级的业务提供服务。之所以没有整个引入OpenStack，是因为当时调研时，感觉OpenStack的设计比较脱离美团的实际情况。例如，网络架构需要有较大的调整，同时需要有共享存储的支持。当时对美团来说，现有业务的基础设施已经基本固化，为适应OpenStack而做这样的调整基本不可接受。另外，OpenStack在很多细节方面达不到需要的级别。比如，OpenStack对跨机房多Zones的设计，它假设你机房之间的网络是完备的，这也不太符合我们的网络现状。因此，我们基于美团现有的主机使用模式和网络架构，重新设计了网络、存储和主机管理模型，自主研发了虚拟化管理平台。同时，我们在从单机房做到多机房的时候，在Zones之间做了解耦，比如在每个机房里都放置Glance服务节点，减少对跨机房网络的依赖。正是由于这些研发工作，使得我们经过不到一年时间的磨练，就实现了美团整个基础设施完全运行在私有云上的目标。当然，由于我们不使用Nova，就意味着OpenStack社区的很多依赖Nova的组件和功能我们基本无法直接使用。不过，相对于OpenStack大而全/兼容并包的架构，我们坚持在每一方面都集中精力用好一种技术，如主机虚拟化使用KVM，网络虚拟化使用OpenVSwitch+OpenFlow，使得整个系统的开发和维护成本相对较低，同时能深挖这些技术方案的功能特性，最大限度地压榨硬件性能。同时，由于我们掌握了基础系统的代码，使得我们可以较高的效率添加一些新的业务功能(例如，对虚拟IP，USBKEY的支持等)，以及实现系统架构的升级改造(例如，对多机房架构支持等)。另外，我们对使用的OpenStack组件做的一些修改，比如对Swift的优化，目前技术委员会也在提议如何回馈给上游社区。当然了，这个还需要看社区对我们的patch接受与否，而我们也还是以满足业务需求优先。其他方面，块存储落在本地的SAS盘上并在本地做RAID。目前我们对美团网自己的业务做RAID5，对公有云用户做RAID10。这是考虑到美团网自己的业务在应用层已经做了较完备的高可用设计的，即使掉了单个节点也不会影响到业务;但对于公有云用户而言，他们用的那一台云主机就是一个单点，所以要对他们的云主机做更好的保护。使用RAID10当然成本会比较高。我们也在考虑共享存储，当然前提是先解决了上面的稳定性和性能问题。以后会使用SSD，使块存储的性能有更大的提升。网络方面做了分布式设计，主机上用了OpenFlow，通过OpenFlow修改二层协议，让每个用户拥有一个独立的扁平网络，跟其他用户的网络隔离。通过DNS虚拟化技术，使得不同的用户可以在各自的私有网络上使用相同的主机名字，并在每个宿主机上部署分布式DNS和DHCP以实现基础网络服务的去中心化。运维美团云的运维思路跟整个美团的运维思路是一致的。下面介绍的运维思路既适用于美团云，也适用于整个美团网。运维框架可以概括为五横三纵。从横向来看，自底向上分为五个层次：物理层，包括机房网络、硬件设施。我们已在开展多机房和城域网建设，从最底层保证基础设施的稳定性。为了应对大规模机房建设带来的运维成本，我们实现了Baremetal自动安装部署的Web化管理，从服务器上架之后，其他工作均由自动化完成，并可以和虚拟机一样管理物理机。系统层，包括操作系统、虚拟化。我们在虚拟化基础之上采用了模板化(镜像)的方式进行管理，也对Linux内核做了一部分定制开发，例如针对OVS的兼容性做了优化。服务层，包括Webserver、缓存、数据库等基础服务。我们基于Puppet工具做了统一配置管理，有自己的软件仓库，并对一部分软件包做了定制。统一配置管理的好处，一方面是避免不一致的修改，保证集群的稳定性，另一方面是提高运维效率。逻辑层，包括业务逻辑、数据流。这一层的主要工作是发布和变更。在很多其他公司，业务的发布上线、数据库的变更管理都是由运维来做，我们认为这样对开发、运维的协作成本较高，所以一直往开发人员自助的方向做，通过代码发布平台、数据库变更平台实现开发和运维工作的轻耦合。在发布平台中，每个应用对应独立的集群，有一位开发作为应用owner有最高权限，有多位开发作为应用的成员可以自助发布代码。数据库变更平台也有类似的权限控制机制，并在任务执行层面有特殊的稳定性考虑，例如将大的变更任务自动调度到夜间执行，对删除数据表的任务在后台先做备份。应用层，包括用户可见部分。除了跟逻辑层有类似的发布和变更之外，我们有统一前端平台，实现访问流量的进出分离、行为监测和访问控制，这对于整体的安全性有很大的好处。从纵向来看，有三部分工作，对上述五个层次是通用的：监控。从物理层到服务层的监控和报警都是运维来跟进、响应的。对于逻辑层和应用层，也是开发人员自助的思路，运维提供监控API的规范，开发可以自己创建监控项、设定报警规则、进行增删改查。监控报警之后的处理，现在有些做到了自动化，有些还没有。尤其是有些基础架构和业务之间的纵向链条还没有打通，包括建立业务容量模型，某种特定的业务形态在多少用户的情况下最高负载多少，不同负载等级下的SLA应该是多少，等等，这些模型都建立起来之后就能够进行自动化的处理。安全。我们很早就部署了统一的安全接入平台，所有线上的人工操作都需要登陆relay跳板机，每个人有独立的登陆帐号，所有线上操作都有审计日志。更多的安全工作由专门的信息安全组负责。流程。早期基于Jira做了一些简单的流程，但仍需要改进。现在正在针对比较集中的需求，开发相应的流程控制系统，方向也是自动化、自助化。从业务部门申请VM资源，到业务扩容的整个流程，我们正在进行上下游的打通，未来可以在Web界面上通过很简单的操作实现，也提供服务化的API，方便其他业务平台进行集成。虚拟化覆盖全业务线之后，这些事情做起来都变得很方便。总之，美团网整体的运维思路就是：保证业务稳定运行，同时推动全面自动化、自助化。涉及开发、运维沟通协作的部分，尽可能通过自动化平台的方式，由开发人员自助完成。运维人员除了基础环境、平台建设之外，帮助业务进行高可用架构的梳理，提高代码的可运维性，以及定位和解决业务中的各类问题。改进与演变美团云从对内服务开始到现在两年以来，最大的一次改进就是从单机房到多机房的建设，这是跟美团网的城域网建设同步开展的。单机房的时候，美团网业务早期曾遇到过运营商网络中断几小时的情况，期间业务不可用，非常痛苦。多机房冗余做到最理想的情况下是，即使一个机房整个断电了，业务也不受影响，当然这就意味着需要100%的冗余量，成本是比较高的。不过对于美团网来说，冗余的成本是很愿意承担的，因为业务不可用造成的损失要大于做这些冗余的成本，所以我们现在物理资源都留有50%的冗余，带宽一般会预留30%的冗余。因为美团网的发展速度很快，去年我们一度遇到资源不够用的情况，在这上面踩了很多坑之后，开始做一些长远规划。现在美团网业务的双机房冗余已经实施了一部分，美团云也有两个机房，如果公有云客户的业务支持横向扩展，那么也可以做跨机房部署。这种机房级高可用做好了，对稳定性又是一个很大的提升，大大减少网络抖动对业务的影响，可用性SLA可以从现在的4个9做到更高。有些规模比较大的客户对服务质量会有比较高的需求，所以美团的城域网、以及未来的广域网，也会共享给我们的公有云客户。另外上面说到我们数据库跑在物理机上，这一块现在用的是SSD，读写性能顶得上早期的三台15000转SAS，瓶颈在千兆网卡上，所以我们现在也在做万兆网络的升级改造。数据库服务以后也会开放给公有云用户使用，基础设施跟美团自身业务一致。未来的计划由于使用本地存储，所以现在虚拟机迁移需要在夜间进行，以减少对用户服务的影响。为了提高服务的可用性，在确保稳定性和性能的前提下，共享存储是一个不错的选择，所以我们正在测试万兆网络下的共享存储方案。另外，我们底层虚拟化机制用的KVM，本身是没有热插拔的功能，这也是我们计划要做的一件事。现在很多客户问我们，什么时候出Redis，什么时候出云数据库，一些客户对Redis和MongoDB会有需求，Web服务想要MySQL。我们的计划是由DBA团队提供一些模板，相当于是一些专门针对Redis/MySQL做好优化的系统镜像，让客户可以直接拿来用。这可能会在下一个版本release的时候推出。我们还会提供一些基础架构的咨询服务，这个咨询服务一方面是工程师提供的人工服务，另一方面是以工具+文档的形式，以互联网的方式将我们的最佳实践共享出去。美团网做到现在的几百亿规模，内部有很多经验积累，如果能把这些积累传递给我们的客户，能够帮助客户少走很多弯路。美团云的架构美团云的前端后台使用的框架是Django，主要处理Web业务相关的逻辑，Django的社区支持比较丰富，文档健全，本身功能也比较强大。然而有些特性似乎比较多余，比如说Django的很多“黑魔法”是用数据库外键实现的，但是美团内部有自己的一个DBA团队，负责审核所有项目的数据库设计，他们则要求不允许用外键，据说是因为最佳实践得出的经验。后端整个云平台的框架也是用Python实现的，在底层包括虚拟化计算、网络、存储三大功能体系，上层则分为资源管理、任务调度、日志、监控、用户管理、通知报警、API、用量计费等模块，同时在垂直方向上，又包括关系型数据库服务、缓存服务、对象存储服务、负载均衡服务、模板和快照服务、虚拟专用网络服务等。尽管后端的业务不尽相同，但架构师们抽象出了一套处理工作流的逻辑，并且用Python实现了一个框架。比如，在消息通信机制的选择上，美团云没有采用类似OpenStack的采用消息队列Rabbitmq的方案，而是采用了Webserver，主要原因是考虑到Webserver在更加久经考验，业界对HTTP协议有着更加成熟的方案。美团云团队深度定制了Tornado，将它由单线程、异步回调的机制修改为同时支持多线程和同步查询的机制。这主要是考虑到在关系型数据库的查询上(比如MySQL)，没有较成熟的异步查询方案，而单线程的阻塞查询则会影响Tornado的主线程。通过精巧的代码整合，将Tornado与SQLAlchemy这样的数据库ORM集成在一起，成功地解决了数据库的问题。同时针对SQLAlchemy的特性进行了一些设置，比如关闭Auto-Commit，这样能够使得ORM不会在每次查询的时候都会发出网络连接，而是在一个线程的业务逻辑里将所有的修改操作hold住，只允许查，在线程结束的时候手动commit，关闭session，提交所有的修改。通过这种方式，实现了一个线程级别的数据库事务锁和对象锁，使得程序员们能在一个线程的逻辑里面同时查询和修改多个数据库表，同时保证业务的原子性。陈博说“通过这些框架，程序员们在开发上层业务的时候也感觉到更加便捷了。”听众对演讲反应热烈，表示受益匪浅，也对美团产生的敬佩之情。美团能发展到今天这般规模，其技术能力不容小觑。”当然，这些只是美团云整个技术的冰山一角。美团是中国第一大的O2O电商，网络流量500T/天，月活跃用户数超过1.3亿。支持这一庞大业务规模的正是美团云。今年3月，美团云获得IDC牌照，8月对外开放首个高品质的自建机房。同时，美团云通过第四批可信云认证，并将“电商云”奖项收入囊中。2015年第四季度，美团云也将推出数据产品及行业解决方案。所有的这些都意味着，美团云致力于为千万用户提供稳定的公有云服务这一愿景，正在成为现实。
电商不仅仅是大数据驱动的，京东用大数据为用户、商品等带来运营效率的提升。同时，从在线的数据访问来讲，电商业务需要非常快速的数据访问。大家可以看到，京东随便打开京东首页或类似的电商首页，图片是京东的资产，是商品形象的描述，可以用CDN加速。除了图片之外，其他几乎都是动态内容，量很大，且是频繁被改写的，它们需要非常快速的访问，比如说商品的详情、价格、品类下推荐的结果等许多内容，打开个商品详情页面或列表页，后台逻辑是很复杂的，需要非常多的数据去展现。这个过程中，一个是快速的数据访问对终端用户的体验有非常关键的影响。另外，从京东产品工程师开发的产品角度出发，另一个诉求就是关注业务逻辑，而不应该花时间优化后台在线存储的性能。JimGray是数据库领域的泰斗级人物，他其中一句话我记得很清楚，即“Memoryisthenewdisk（内存是新的磁盘）”。07、08年时京东买的内存大小标准配置是4G左右，很快4G、8G、16G一路下来，很多公司都会采购158、265G内存，估计明年都会用1T内存。京东都用265G内存加万兆网卡来做，单机内存在快速变大，整体很多在线的小结构和半结构化数据存放在内存里，这个问题是不大的，也是非常合理的。而且用内存做在线存储确实有弊端，就是成本在一个时间段内有些偏高，但是除此之外却带来很多性能、管理等各方面的便捷性，两相权衡下，在一定程度上，成本的升高对有一定规模和业务比较重要的公司可以接受，而且京东可以用技术手段降低这个成本。JIMDB的全称为TheJingdongIn-MemoryDatabase，这个系统的名字是大概2014年初起的，它并不是严格的关系型数据库，而是一种新型的，以内存为中心的全部托管、全管理服务化的数据库。它是以内存为中心的数据存储，主要针对在线的结构或半结构化的数据，过去两年一直在持续建设。从目前的业务价值角度，它支撑了京东几乎所有的在线业务。除图片之外，几乎所有的动态内容都被它所服务，或者严格来说，图片的有些信息也用它来存储。越来越呈现一个趋势，就是京东更多地用它来做主存储，MySQL或者DataBase会进行归档。接下来从技术角度做个简单介绍。JIMDB基于redis，redis是一个非常优秀的开源软件，它做对了两个事情。第一，它是基于内存的，简单且高性能；第二，也是基于内存，它提供了非常丰富的数据类型和数据结构。对许多互联网公司来说非常方便，比如商品的详情、属性等，非常便捷。两年前，京东为了解决它的痛点，因为之前的监控系统已不能满足京东的业务需求，便不断演进，一路做下来。它是相对分散的分布式系统，有许多分支、模块，不同模块做不同的事情。从用户（业务的开发人员）的角度，给他们提供Java、Cdriver，其他小众语言是给他们提供代理，完全兼容但是不限于RAMservers。对于任何一个业务都给它集群，所有集群都在京东的物理资源池上。京东这个团队的核心任务是做一套复杂的平台，一套健壮的分布式系统，管理目前大概四五千台大内存机器，为众多业务提供可靠的、性能稳定的、数据有持久性保证的高可用服务。这个系统从部署结构来讲，是单个物理服务器、多实力的结构，任何大内存物理servers上都会部署多个内存，好处是便于流量监控等，但是给业务和监控带来很多复杂性。对行业来说目前还是比较合理，故障的检测与切换，扩容的管理、升级、监控等都是独立的模块。存储的servers是复用原来redis网络编程的框架，但是复制的协议、存储的引擎等各方面都是自己来开发。在此列举几个技术点。第一，怎么做故障切换？分布式系统要解决的第一个问题是怎么处理故障。故障是个很严肃的事情，并不能简单说有一个进程有一个servers不通了就是故障，会发生网络不稳定等等，各个方面都有可能。在一个或多个数据中心有若干个故障检测器，当多数人认为它故障并且没有人认为它健康时，才能定位确实故障。发给故障的控制器做下一步事情，重新触发新的配置，改变集群的拓扑。所以故障的检测和自动的Failover是2014年做的第一个事情，把故障自动化，这个事情说起来简单，其实是最基础和最重要的，因为整个过程分很多步骤，前一段时间还出现过Bug。第二个关键问题是任何一个逻辑的集群、业务数据量会增长、变化，所以必须支持在线、动态、重新的分片，或者说重新的Sharding，这个Sharding核心思想不是简单把集群分片，中间要加一个抽象，才能进行动态的重新分片。对于这个策略来说，中间加一个bucket的抽象，然后来进行管理。迁移的过程是通过复制来做的，学术界或工程界喜欢管它叫“Partialreplication”。举例来说，原来是3个分片，现在怎么变成4个分片？通过调度算法，决策把哪些分片中的bucket迁移到这里，迁移是通过复制来做的，建一个复制关系，但是这个复制关系并不是复制它原来所有的数据，所以要求复制协议的实现是要做特殊的事情，只要这一个区间的复制，复制全部完成之后更改拓扑，最后生效，这可以做并行的Partialreplication做迁移。从数据的可靠性保证比较高，技术也比较简单和传统。过去两年从底层技术研发分三个方面一步步演进做了些事情，从存储引擎的角度，用的最多的是这个，第二个存储引擎是LSM，京东用RAM+SSD做混合的两级存储，这三种不是取代的关系，而是互为补充。第二种更多应用的场景，是有些东西比较大，京东可以把这个放在SSD上，把K依然放在RAM里，这样可以适当的节省成本，目前第二类线上已经有百分之十几的用量，但是数据量要乘四五倍，因为每台机器单机容量更大。第三类是B+TREE，可以排序，可以支持按范围查找和便利，这个线上用得不是特别多，京东只支持有需要按范围、需要便利查询的场景。复制协议更加关键，因为对于存储来说最核心的是复制，除了异步复制就是同步复制，京东上半年做了状态机的复制。分片策略京东用哈希最多，因为哈希最简单，业务更多时候需要单K去查询，有些业务需要按范围，京东支持Range。这三个方面技术可以做合理的按业务场景组合，满足不同的业务需求，比如业务更多是用Dict+异步复制+哈希分片策略，比较大的是RAM+SSD两级存储，然后配合其他的策略。从业务使用场景角度，京东是分而治之，不同的软件、不同的集群，根据业务的需要，可以分成这么两大类。不少业务是做纯缓存，后台还有数据库和其他存储，京东更多是用异步复制或者不复制，哈希的分片，可以做LUR的淘汰。但是线上也有将近一半左右的集群，他们不仅仅用这个东西做缓存，他们做持久存储，京东有更高的可靠性保证，一般用来开启同步或者状态机的复制，然后用范围或哈希分片，而且对它的快照做定时备份，备份到内部对象存储上去。对任何一个系统来说，底层的基础技术研发仅仅是它的一个环节，当系统达到一定规模之后，更多工作会放在监控和运维体系的建设方面。整个平台京东有比较完善的监控体系，这更多是数据驱动的，从各个方面，连接树、网络入出流量等等，产生很多时间序列进行分析、预警，并且驱动各种控制器做决策。比如有的分片存的数据因为是个华为的手机，它太热了，京东就可以把它做分列，很多时候做扩容做分列并不是因为容量，而是因为数据的热度。数据监控也存在这个系统里做快速的展现。基于容器的自动化运维，因为我刚才说过，整个系统规模比较大，有几千台机器，而且每台机器上部署很多的存储节点，所以运维的复杂性比较高。在整个2013年更多是依靠手工的运维，怎么样选机器，怎么样部署，运维工作量极大，在2014年下半年和2015年上半年，京东花了很长时间做全自动化运维的平台，它是基于Docker，简单来说是大的Linux大内存服务器上上面有很多Docker，每个进程是Docker实例，用Docker软件管理版本，智能做机器的选择，做定期的软件升级，各个方面很多工作。这个平台通过容器技术也在这里面有所发挥。说一说规模吧，因为对于任何一个底层系统建设来说，它核心的价值只有一定规模、真实驱动业务才能有收获力。线上京东有多个数据中心，有几千台大内存机器，都需要跨数据中心的复制，有的基于容灾的考虑，比如不同的机房有不同的规则，有可能跨机房做异步复制，有可能同步，预计明年有512G内存或者1T内存机器的采购。线上支持了1000多个线上的业务，每个应用相当于一个逻辑的集群。从运维角度来说，这么多台机器里面有大概3万多Docker的实例。内存存储带来什么？花了很多内存片、内存条，带来了极佳的性能、非常稳定的性能，这是京东线上某一个比较重要的集群，在双十一期间可以看到它整体的QPS超过200多万，是非常稳定的，99%的请求都在2毫秒之内返回，这个让用户体验更好，让京东的业务开发起来更加简单，让公司运维团队更加省心、更加轻松。内存存储考虑的一个主要因素是，内存可以花钱买，但是不能因为软件因素再去浪费内存，内存存储是分出来的，线上很多集群比较夸张、比较大，可能因为它使用场景比较特殊，才产生了碎片。但是整个分布来说，京东也做一些优化的工作，从内存分布器选择来看，主要的集群内存碎片率基本在1.1-1.3左右。我个人工程上的经验来说，这是非常好的内存分配器，内存分配器自行开发意义很小。正在做的事情比较多，优先级比较高的是让它更稳定更好的运维，除此之外进一步提升性能，通过软件硬件协同创新，引入更大、更便宜的内存、更快的网卡，考虑重新实现用户的网络协议加速小包的处理性能。Linux网络协议站不是为数据中心高速的网络、高速的在线应用而设计，每一次包都要中断，对于大包是合理的，对于小包是不划算的，这样的存储性能更多的是小包处理，京东在考虑重写用户协议，来加速小包处理的性能。在功能方面京东也在做个事情，这更多是工作量的事情，考虑从NoSQL支持SQL接口，因为底层有了横向扩张、灵活复制的内存里的数据结构的存储。通过JAVA等等提供，这是工作量的问题而已。另外，希望在某种程度上降低成本，因为平台化第一步是求规模稳定，让它有很好的性能和效率的保证，第二是从整体来说能降低成本，比大家分散、自由去用更省钱。基本的想法是这样的，目前是专署集群，京东希望从专署集群过渡到聚合各个IDC的RAM资源，比如说京东私有云机器去分容器、去分虚拟机，很多时候CPU是瓶颈，分完了内存有剩余，非结构化机器磁盘是瓶颈，磁盘或SSD被分完了但内存有空余，京东聚合整个RAM资源，让数据动态流动、去降低成本。云数据库服务是一项基础性的云服务，解决用户自己搭建数据库时需要考虑的各种问题，让用户在使用时可以按需申请数据库资源，保证整个数据库服务的稳定性及数据的可靠性，同时提供弹性伸缩等的支持，尽可能的降低用户在使用云数据库时的成本。本主题主要是分享京东私有云分布式数据库集群的实现，包括如何支撑上亿级数据量的业务，如何保证数据高可靠、服务高可用以及在线集群扩容等机制。另外还会分享京东公有云数据库的架构与设计，如何实现一个稳定、可靠、可弹性伸缩的公有云数据库服务，涉及到备份、恢复、监控、迁移、高可用切换等一整套方案。京东内部有大量业务的数据是存放在Oracle中的，为了完成京东内部去O的过程，京东为此打造了一套私有云分布式数据库集群，这套私有云分布式数据库集群目前支撑着京东大量拥有上百亿级数据量的业务，本主题中会重点介绍去O过程中遇到的难点同时详细介绍在内部数据库云化以及在支撑大规模业务过程中积累的经验，包括如何打造一套高性能的私有云分布式数据库集群服务，如何在支撑京东上百亿级别数据量业务正常服务的情况下做到在线无缝集群扩容，分享来自京东生产一线的经验。云服务最重要的是要做到可弹性伸缩可按需获取资源，让用户可以尽可能的花最少的代价满足业务的需求。用户使用云数据库时面临当业务量增长时申请的资源不够，需要做到快速的扩张现有资源，当业务量降低时需要快速缩小现有资源。当数据库实例甚至整个机房发生故障时，要做到用户在云数据库中的数据是安全的可靠的，可以第一时间恢复云数据库服务，包括跨机房恢复等，保证云上的用户业务是不受影响的，这些都是云服务尤其是云数据库服务需要解决的事情，本主题也会介绍京东公有云数据库是怎么解决这些问题的以及在解决这些问题时积累的经验。京东云数据库主要包括公有云数据库服务和私有云数据库服务两部分。公有云数据库主要是面向外部用户，定位是中小型公司；私有云数据库主要针对公司内部业务，有时候甚至会特殊业务特殊对待，会针对业务的特点来具体问题具体分析，数据量较大的业务京东会建议业务使用京东私有云分布式数据库集群，将数据进行拆分等。这两项服务在京东都是由同一个团队来提供支持，京东云数据库的总体做法是将私有云数据库中积累的经验逐步的输出到公有云数据库上。云数据库集群服务主要是指分布式数据库集群，用户在使用这个集群的时候可以像使用单台数据库一样去使用，在业务层面不用关心集群中的数据是如何分布的，对用户来说后端的数据库实例是不可见的或者不需要关心的，在使用层面来说心智负担会大大降低。N个数据库同时提供服务一般是指N个数据库服务多个不同的业务，或者是某个业务同时使用了N个数据库，但是业务对这些数据库是有感知的，换句话说这N个数据库对业务都是可见的。云数据库服务其实也可以理解为将传统的数据库服务搬到云上，但是云数据库服务尤其是公有云数据库和传统的数据库确实是有区别的，最大的挑战在于不仅仅要提供数据库服务，还需要与用户的私有网络及云主机甚至包括云存储等各项云服务相互配合提供高可用的服务、保证数据的高可靠，是一整套云服务中的一项。传统的数据库技术更多关注的是数据库本身的，网络及主机等问题一般会比较简单。京东公有云数据库的架构都是基于私有云数据库的实践经验所得，在实际输出的时候考虑到安全及弹性伸缩等的考虑，公有云上采用基于虚机部署的方式，结合云主机云存储以及云数据库系统自身相配套的信息采集系统再整合公司的监控系统等各项服务，对外提供可伸缩高可用及高可靠的公有云数据库服务。私有云中的分布式数据库集群架构主要是采用引入中间件的方式来支撑业务，中间件本身完全兼容mysql协议，在内部业务使用的时候可以像使用原生数据库一样简单。公司内部有一套完整的统一的监控系统，云数据库自身还有一套信息采集系统，采集系统会采集数据库实例上的相关信息包括慢查询以及机器负载等信息，这些采集的信息经分析处理以后如果如果发现有异常比如有慢查询或者机器负载较高，会通过统一的监控系统触发报警，做到及时发现问题及时处理问题。在私有云分布式数据库集群中的性能监控主要是两部分构成，一部分是分布式数据库中间件会对查询做一些统计信息，这些统计信息中有超过某些阈值的情况就会触发报警，另外一部分是数据库本身的完善的监控系统。京东公有云数据库目前是部署在虚拟机里的，基于虚拟机的快速创建京东可以做到公有云数据库实例的较快的创建。私有云数据库目前有很大一部分已经将数据库实例放到容器里，在创建部署方面将更加的便捷，当内部验证以后后续京东也会考虑输出到公有云上。京东的业务发展非常的迅猛，所以在很大程度上来说京东的技术都在被业务驱动着往前跑，很多业务早期数据可能是放在Oracle或者Sqlserver中的，等到业务量比较庞大的时候再着手将数据从原来的数据库迁移到mysql里的时候就会比较痛苦，一般都需要业务方和数据库团队紧密配合才能真正的完整的迁移出来，但是也正是因为有这些实际的业务需求驱使着京东的技术不断的提升。
当网站建设完成之后，首先要做的是前期的运营推广，花大量的时间精力去提升网站流量以及引导用户，当自己的网站有了一定的流量时，我们就应该考虑网站的转化率，因为网站转化率是一个网站是否能赢得更多利益的核心。首先我们来讲讲什么是网站的转化率，网站的转化率是指访问某一网站，转化的访客占全部访客的比例。简单通俗的理解就是从单纯的网站访客转变成参与您网站活动的访客，或者是访问您的网站之后，有实质性的咨询或者下单的访客。如果您的网站有一定的流量，转化率却很低，那么重点应该放在如何提高网站的转化率。以下是提高网站转化率的几个重要方法，如果有需要的朋友可以参考一下。一、采集并分析数据首先采集网站的相关数据，然后通过分析数据找准问题所在，如何分析数据呢?我们可以通过百度统计，站长统计等工具，这些工具都有着详细的访客信息，比如：用户的访问时间、访问者的IP、用户通过什么方式访问的、用户访问过网站的哪些页面、停留了多长时间等等。通过分析相关的数据，得出用户所想，这样我们就可以根据分析的结果把网站调整成适合用户需求的网站，从而获得更高的转化率。二、降低网站的加载时间网站的加载时间直接影响到转化率，如果网站的加载时间太长，用户不会浪费时间等待你的网站加载完成，所以千万别让访问者等待。三、减少让用户分心的元素网站应该要保持专注力，所以应该去除页面上那些会让用户分心的信息，并加强会影响转化率的关键信息的展示。应该以最容易被注意到的方式展现引导用户进行下一步操作的元素，以便用户能够找到并完成他们的操作任务。很多企业网站转化率低的原因是还停留在表面的分析上，如果想提高网站的转化率，必须要了解用户内心的真正需求，一切的工作从用户角度出发，这样网站的转化率就水到渠成了。
现在的自助建站排版技术主要分为四种，绝对定位布局排版系统、Table布局排版系统、流式布局排版系统、综合布局排版系统，这四种排版技术都是现在自助建站使用频率比较高的，那这四种排版技术究竟有什么优缺点呢?所以今天小编就为大家分析这四种自助建站排版技术，一起来看看吧!绝对定位布局排版系统优点：其排版操作具有直观性，而且比较易用，这种排版技术在国外的建站系统比较常见，例如wix。(注：中国大陆不能访问wix做出来的网站，如果有需要可以使用中国的中国的wix起飞页自助建站系统)缺点：缺少页面的逻辑结构，与传统方案相比，差距是比较大的，而且搜索引擎对于这样的网页友好度比较低。Table布局排版系统优点：相对于绝对定位布局排版系统来说比较好一点，但搜索引擎对于网页的表格布局的友好度还是比较低。缺点：使用web1.0的布局方式，对于现在的手工建站比较少使用，而且用户的友好度比较差。流式布局排版系统优点：和手工建站有着很高的相似度，而且搜索引擎以及用户的好友度都比较好。缺点：有相当一部分的功能比较难使用。综合布局排版系统优点：融合了绝对定位布局排版系统和流式排版布局系统的优点，搜索引擎的友好度比较高，而且灵活性非常好。缺点：相对于其他的自助建站布局系统，其排版已经非常接近手工建站的方式。以上就是四种排版技术的优劣，大家应该按照实际情况来对网站的整体布局进行选择，合适的才是最好的，当然网站的类型排版的选择哦。
当当网自成立以来，内部技术体系的发展已经有15年左右的历史了。系统架构也经历了从高度集成的软件向分布式、低耦合、SOA化系统的演进过程，形成全面支持网上零售业各种业态模式的系统架构，每天支撑着千万级的PV访问，承载了超过100亿元人民币的年营业额，2013年双11峰值流量达到日常的10倍。作为一个典型的自营与开放平台相结合的网上零售电子商务平台，当当网网上购物流程由多达上百个大小系统共同实现。当当网最终服务于消费者，良好的用户体验、钱物准确是立足的根本，因此对系统稳定性、可靠性、准确性有非常严格的要求。任何时候都能保证线上系统的稳定运行，是我们工作的第一优先级。电商系统的运行峰值通常出现在各类促销、营销活动期间，以及大量集中收订的订单带来很大的生产和配送压力时。除了参加每年的双11和双12大促、每年的10月店庆、业内重要的庆典、两次开学季图书大促、换季服装大促、常规的新品和尾品大促以外，当当网每个月至少会有一次公司级别大促，而各种中小型大促常年不断。各种促销活动均可以闪购、秒杀、大量SKU促销等模式实现。网站流量的来源除了新老用户的直接登录以外，还包括多种站外引流方式如网址导航、联盟、搜索引擎、各种线上线下媒介、短信、邮件、微信等通道。因流量来源的不同，相应用户的浏览、购物模式也大有不同。如很多促销落地页是当当网的“馆”，或者专题页，那么我们可以在活动之前做非常有针对性的准备；有时用户已提前准备好了购物清单，如双11这样的促销中，订单转化率会比平时高，体现在订单收订和卖场流量不会成比例上涨——如订单收订上涨6倍，卖场流量可能只会涨3~4倍；而一些外部引流方式会带来大量无效、垃圾流量，所以订单转化率会比正常流量低。有的活动流量会对首页有较大影响；有的活动会对购物车有较大影响，如闪购类的限时购买或复杂的促销逻辑；有的活动会对当当网的仓储、配送系统有较大影响，如当当网配送的订单；有的活动会对开放平台有较大影响，如商家订单。因此，摸清业务模式和活动特点，是设计和运维高峰值电商系统，即高伸缩性系统的重中之重。但从另一个角度来说，在没有动态弹性部署的前提下，过度的设计和服务器部署是一种浪费，特别是硬件非常有限的寿命会带来每年巨大的成本摊销。当当网根据业务发展速度和业务运营规律，结合多年的经验，制定的系统伸缩性的设计原则和硬件常备策略使各流程能够直接应对日常5倍业务量的上涨。通过增加服务器的方式，能够应对10倍业务量上涨。而如果要应对10倍以上的上涨，则需要提前做有针对性的系统优化。但无论当前承受的业务量是否超过了设计范围，都不能影响设计范围内业务量的正常处理。设计和部署大流量、高并发系统的技术方案选择比较多，业内有很多成功经验和案例。但根据我们的经验，设计高峰值的网上零售业电商应用系统通常要面对以下几大难点。应用架构复杂，业务发展快，迭代速度快，各系统之间盘根错节，历史包袱重。不仅有牵一发而动全身的风险，更有边缘case出错影响主流程处理、耗尽过多资源的隐患。从前台到后台的业务流程长，用例多。在能承受的最大峰值上，存在短板效应。设计实现时要面面俱到。通常促销活动的持续时间短而集中，前期推广活动已经启动，在活动期间，短暂的系统不可用，也会带来惨重的销售损失与负面影响，没有亡羊补牢的机会。要确保系统的稳定性，平时的工作就要做足。针对这几大难点，有以下几大应对策略。基于SOA架构理念，降低系统耦合性，接口定义清晰明确，保证独立子系统的健壮性高，降低故障跨系统扩散风险，从而将伸缩性的困难逐步分解到各个系统。对系统进行分级，集中力量，突出重点系统。当当网从卖场到交易流程均属于一级系统，这部分系统直接关乎用户体验和订单量。在系统稳定性和可靠性等指标上，设计标准高于后台系统。优先考虑用异步处理代替同步处理，做好系统异常的降级方案，保证有限的合格服务。在描述电商平台峰值系统的设计之前，通过下图可简单了解当当网电商平台的几大组成系统：卖场系统，促销、会员系统，商品管理系统，交易系统，订单管理系统，仓储与调拨系统，物流与配送系统，客服与退换货系统等。系统分级对于电商网站，用户体验是第一位的，系统稳定运行是保证用户良好体验的基础。在资源有限的条件下，采取对系统进行级别划分的方式，对高级别系统保持重点关注，在设计、部署、监控等方面确保高级别系统具备良好的伸缩性、健壮性和敏感度，能够应对电商业务中不确定的极限峰值冲击。当当网基于可能对用户产生影响的程度与敏感度，将所有应用系统分为三级，简单描述如表。依此标准，当当网的一级系统主要包括卖场系统、商品详情、价格系统、库存系统、促销系统、购物车、交易系统、支付系统、会员系统等。二级系统则包括商品信息系统、订单系统、ERP、仓储系统、物流与干线运输系统等。三级系统主要是结算系统、报表系统，以及运营、活动管理类系统。其中一级系统基本可分为两类，第一类为面向用户访问的前端页面，第二类为购买流程所涉及的系统。一级系统的关键指标是可用性，在设计和部署时都要高标准严要求，要求具备完善的容错降级机制，日常保持较低的系统运行负载，配置高级别的监控告警流程，出现问题在要求的SLA标准内修复与解决。这两类系统的核心业务功能定位不同，采用的技术也不同，前端页面系统主要使用PHP语言，购买流程则主要由Java语言实现。前端页面系统是电商业务的流量入口，需解决的核心问题是保证大流量高并发情况下的快速展示可用，这方面业界已有较为成熟的解决方案，如CDN、缓存、静态化、异步加载、与依赖的数据源解耦、同机部署、数据库读写分离等。通过这样的设计使前端无状态页面应用可以水平扩展，增加Web服务器即可提升系统能力。为充分发挥系统资源潜力、提高性能，我们引入HHVM对PHP代码进行优化加速，经过性能测试验证，取得了显著效果，性能提升超过100%。现在当当网前端页面系统具备支撑10倍流量冲击的能力，面对超出极限的流量峰值，我们也有预案，主要采取延长缓存时效、本地静态化方式，屏蔽峰值流量对后端系统的冲击，并具备容错机制，在后端非关键服务失效时优雅展示等。卖场系统作为生成各种活动专题页面的工厂，支持通过配置将页面组件静态化，以满足更高访问量的要求。购买流程是电商业务流程中至关重要的环节，一旦出现问题，将使前面的引流、促销、搜索、推荐等营销成果付诸东流，因此购物车、交易系统和支付系统必须确保用户购买结算过程的高效稳定，并保证数据持久化的准确性和一致性。购物车与交易系统逻辑复杂，依赖服务众多，其中交易流程的实现依赖超过100个服务。我们梳理出核心业务流程，再根据与核心业务流程的关系，区分出对服务的依赖性强弱。弱依赖服务如积分、礼券、收藏夹等，通过较好的容错和降级机制，在业务量达到峰值时，可通过服务降级维持核心业务流程的稳定运行。对于强依赖服务中数据变化较少的配置查询类服务，则通过缓存数据来降低服务依赖关系，牺牲部分数据的及时性换取系统的健壮性。交易型系统的业务，成功率是关键指标，可能因为分布式服务集群中部分实例异常或网络问题导致调用强依赖的服务失败，需要发起重试，为兼顾用户体验和减少对系统资源的占用，采用设置较短超时时间及重试其他服务节点方式更为合理。经过优化，购买流程的系统可用性指标达到了99.99%。二级系统多数为后台订单与履约系统。在流量漏斗模型下，在一级系统内形成订单后，订单流转到二级系统，二级系统面对的峰值压力要小得多。二级系统多采用异步方式进行系统交互，对于超出处理能力的业务数据，异步机制削峰填谷，使系统得以在可控的压力下运行。系统资源占用维持在较高水位，既能充分利用系统资源，又可以保证较高的处理效能。当然，异步机制带来的延迟问题也必须控制在合理范围之内，在业务量骤增时可以容忍一定程度延迟。如果平时就经常出现延迟，则需要进行优化，或者重新进行容量规划，提高系统整体的吞吐能力。2014年为应对双11及未来业务发展，当当网对订单系统数据库进行了扩容，规模达到之前的5倍，其他部分系统也进一步分库分表，使之具备承载更高业务峰值的能力。系统分级是根据不同系统的特点，结合公司业务战略关注点进行的差异化处理。电商业务链贯穿多个系统，每一个环节都不容忽视。一级系统固然是核心优化的重点，二三级别系统的技术指标要求也同样严格。我们对每个系统的可用性都有严格要求，并将监控系统列为一级系统，时刻关注木桶理论中最短的那块板子，我们的目标是打造一套性能均衡，没有明显短板，日常能够应对5倍业务峰值压力的电商系统平台。解耦与SOA实践经过多年实践，当当网逐步完成系统架构的SOA化改造，并通过SOA化，实现了服务解耦与高内聚，简化了架构复杂度，这是主流零售型电商平台通常选择的道路。基于分布式的服务使系统具备更强的伸缩性和扩展性，系统瓶颈更易定位和优化，满足业务快速增长的需要。SOA即面向服务的架构，在业界并没有统一的标准，但有一些公认的设计原则：标准合约、松散耦合、服务抽象、可复用性、服务自治、无状态性、可发现性、可组合性。在实际应用过程中，根据系统情况以其中部分原则为侧重点，不求全责备，简单实用为上。2012年起，当当网启动一系列重点项目，首先对开放平台进行重构，使开放平台成为搭建在PIM、库存、价格、促销、订单、TMS等主业务系统之上一套具备更灵活的扩展性的业务平台。这次重构是当当网近年的重大架构调整之一，之后各主业务系统陆续实现业务平台化，支持多商家甚至是平台级跨商家的业务模式。开放平台将原有独立管理的商家商品信息、订单流程迁移至PIM系统和订单系统进行统一管理，充分发挥服务的可复用性，减少重复逻辑的多点实现带来的开发和维护成本。商品信息是电商业务系统中的核心主数据，是促销、价格、库存、礼券、搜索等系统的基础数据来源。PIM系统作为商品主数据系统，承担着管理商品基础数据、关系、品牌、类目和状态等信息的职能，商品数据量在千万级别。PIM系统的SOA建设经过了两个阶段。第一阶段主要是实现服务化，因服务设计粒度过细，发布的服务达到数百个，其他系统要完成一个业务功能可能需要调用多个PIM服务，增加了服务使用方的逻辑复杂度，也带来了更多的网络交互开销，不能称为SOA的最佳实践。为此，又进行了第二阶段改造，将第一阶段实现的服务定义为基础服务，根据业务需要将其组合，提供粗粒度的对外服务，解决了之前的问题。粗粒度服务能够提供独立的业务功能，可能同时依赖于多个系统的基础服务，当服务使用方因业务需要调用多个粗粒度服务时，可能会对同一个基础服务发起多次访问，产生叠加的系统压力。我们经过分析认为，底层服务资源的消耗能够简化上层应用逻辑，对于系统架构层次的合理性更为有益，只要提高底层基础服务的性能，上层服务能力将更具弹性。遵循SOA的系统解耦有时会增加系统资源开销，甚至降低部分服务性能指标，但可使系统架构更为清晰，增加服务复用性，具备更强的业务扩展性，提高开发测试效率，降低开发运维的人力成本，及时响应业务创新，使IT系统重现活力。通过上述系统架构治理，当当网以很少的临时性系统准备顺利度过2013年双11大促。海量动态信息流的快速发布当当网打造综合品类电商平台，开放商家入驻，随之而来的是商品数据量迅速突破千万。商品信息是电商业务流程前端的重要数据，是进行营销活动、生成订单的基础。商品信息在前台有多种展示页面，大规模营销活动期间运营人员需要进行大量操作设置，价格、库存等也会更为频繁地更新。目前库存日更新量峰值超过1500万SKU的变化；价格日更新数据量达500万以上SKU，极限峰值超过1000万，每秒可能超过1万。数据同步及时性、一致性指标关乎用户体验和营销活动执行效率，如此大量的数据，在各业务系统之间高效稳定传输，对系统架构提出了很大的挑战。当当网的商品数据有多个来源，自营实物商品来源于ERP系统，电子书来源于数字业务系统，商家商品来源于开放平台，最终这些商品的数据都由主业务系统中的PIM、库存系统、价格系统集中统一管理，再发布到搜索系统、推荐系统、前端页面展示等系统。为了对商品信息中的关键数据同步时效进行监控，当当网建立了啄木鸟监控系统，覆盖了近20个信息流路径数百个节点，对超出同步时限的环节自动报警，以便及时处理，避免发生严重的延迟。商品的关键数据包括商品基本信息、库存和价格，库存和价格都依赖于商品基本信息，对于不同类型的数据，根据应用场景区别对待。平台化之后，每个商品都归属于一个商家，以商家ID为维度进行散列，将商品基本信息保存在数据库中，支持水平扩展，可以满足商品数据不断增长的需要。对于历史版本的商品信息，则迁移至历史版本库，作为订单交易快照供用户查询。库存数据在前端展示只关注是否有货，并不需要将每一次库存变化同步，在库存变为0或从0变为正整数时触发状态同步，交易下单时实时查询当前库存即可，此种变数量为状态的方式极大地减少了同步数据量，提高了数据一致性。价格属于高度敏感的数据，对于手机专享价等类型，业务运营有设置生效时间、失效时间的要求，为保证前端按照时间动态展示，我们将生效时间段数据也发布到前端系统，由使用方判断当前有效价格。图2中给出了主要信息流。即便已经对不同类型的商品信息数据流进行了差异化处理，仍然不能排除短时间内会发生大量数据造成系统同步阻塞，影响正常业务运营操作的及时发布。极端情况下，超出系统处理能力还可能导致系统崩溃。为解决此类问题，我们采用批量、异步、分流、限流等手段进行处理。批量、批次操作限制API调用频次的同时，我们提供批量API供商家对商品信息进行更新，批量更新方式减少了各环节交互次数，提高了系统吞吐量，更好地贴合营销活动中批量处理的需求。在系统内部，批量方式能够有效降低系统资源开销，并能对频繁更新的商品数据进行合并处理，提高处理速度，使数据更新及时准确。增加异步处理，减少同步处理信息流同步经过多个系统，每个系统处理逻辑和吞吐能力不同，采用同步机制可能导致上游系统将下游系统拖垮，因此采用异步机制最为稳妥。异步方式有两点好处：一方面起到缓冲的作用，下游系统依据自身能力控制处理数据量，避免遭受超负荷的冲击，保证系统稳定运行；另一方面实现系统隔离解耦，一旦下游系统出现异常，上游系统仍然能正常处理数据，不至于引发连锁反应。分流不同的信息对处理时效的要求也不同，库存、价格、商品上下架状态同步及时性要求很高，而商品基本信息，如名称、副标题、详情则相对较低。拆分不同的同步路径，对及时性要求高的数据配置更多的系统资源，既保障了敏感数据的及时性，又避免了数据积压相互干扰。同理，针对三种不同的数据来源渠道（ERP、数字业务系统、开放平台），也可通过分流方式保证自营实物、电子书和商家商品信息的及时同步。限流多数的商品数据来源于商家，商家会通过一些第三方系统与当当网开放平台对接，调用API进行数据同步。一些不合理的同步机制设置会频繁发起大量的数据同步请求，而多数请求属于无效数据，这类数据难以识别，会浪费大量的系统资源，干扰有效数据的处理。我们在开放平台对每个商家调用API的频次进行限制，根据商家商品数量合理分配，有效地抑制了无效数据的泛滥。随着多年双11和集中促销模式的考验，电商系统的峰值设计理念和实践已经慢慢趋于成熟，但仍然是所有电商类公司技术团队的最重要任务之一。当当网技术团队经过多年的沉淀，积累了大量处理电商业务峰值的经验。通过深入分析应用场景，对系统进行分级，SOA化完成系统解耦，并采用多种技术手段实现海量数据的高效处理发布，不断提升系统吞吐能力，确保为用户提供稳定友好的购物服务体验，充分体现技术力量在产业中的重要作用。促销系统重构如今大规模促销已经成为大大小小的电商平台及入驻商家运营的常态。随着业务的复杂化、运营的精细化，以及品类、平台、渠道的不断丰富，各种新的促销形式也层出不穷，贯穿从商品展示、搜索、购买、支付等整个流程，电商对于精细化、精准化促销运营的需求也越来越强烈。一次促销活动几十万商品，一天之内几十个、上百个促销活动已是家常便饭，至于入驻商家的常态促销更是不胜枚举。双十一期间，电商平台和商家更是会使出浑身解数，火力全开，无品不促销。促销规则支持分时段设置，多个活动能够叠加，促销系统中的数据量甚至会超过商品信息系统，而且促销内容会根据执行效果快速调整，这些都对促销系统提出了更高的要求，促销系统越强大，促销活动才能玩得越疯狂。我们在重构前面临的状况，是促销模型比较陈旧、扩展性差，促销系统成熟度低、与其他系统耦合严重，新增一个促销类型可能牵动从单品展示、搜索、推荐、购物车、交易、订单、退换货、库存、价格、促销自身等一系列产品线的变更。因此，促销系统的重构势在必行，数据模型与运营的贴合度决定的扩展性、灵活性，系统解耦和更强大的数据处理能力，是核心改进点。最基本的促销模型很简单，如下图：在当当，有一些“类促销”业务，从广义上可以归入促销范畴，但业务与数据均不属于促销系统，在设计中，我们考虑将这类业务逐渐回收；另外，促销系统能不能承担一些营销的功能？带着这两点考虑，在促销基础上进一步抽象出活动模型。什么是活动？我们认为任何一个有时间范围的事件/动作均可称为活动，活动则抽象为三要素组成：基础信息、维度（条件）、工具（动作）例如，在11月1日10:00-12:00在第一会议室开双十一准备会，讨论双十一各系统需要准备的事项，需要各系统负责人参加；那么这个活动的基础信息包括时间（11月1日10:00-12:00）、主题（双十一准备会），维度包括地点（第一会议室）、与会人员（各系统负责人），工具（动作）包括议题以及讨论本身。那么推而广之，理论上，只要有相应的工具对接，可以用这个极简的活动模型，去管理任何一类活动，这样模型就变为了两层：实际业务中我们遇到过的一些关于促销计算单元的头疼问题。买了一堆商品，到底哪几个应该作为一组计算条件和优惠，在促销叠加的场景这一点显得更为复杂。所以我们引入作用域来定义这个计算单元的范围。例如常规的限时抢促销，每个SKU有自己的价格，那么SKU就是这个促销的计算单元，也就是促销的作用域；例如第二件5折，可能会按SPU来做，你买一个红的一个蓝的，还是能享受促销，那么SPU成为了这个促销的计算单元；诸如此类，现有及未来可扩展的还有店铺、品类、品牌等等。简言之，这个作用域成为促销计算引擎进行计算单元分组的依据。于是模型又变成了这样：举个例子，我们要在11月11日11:00-12:00针对IT技术类图书进行满200元减100元促销，购买过此类图书的客户每本书每人限购一册。那么这个活动的基础信息包括时间（11月11日11:00-12:00）、主题（程序猿光棍节福利）；维度包括商品品类（IT技术）、用户范围（购买过此类图书的客户）；工具是满额减促销、以金额满200元为条件、减100元为优惠，此外还有限购策略为限购1本，作用域为参与活动的所有商品；可能这里会引发困扰，基础信息的时间为何不能算做时间维度？维度也定义了一些限制条件，那和促销工具模型里的条件有什么区别？时间之所以不归入维度，是基于前面对活动的定义，时间范围是必须的，而维度是可选的；促销模型中的条件只对于促销工具有效和有意义，而维度则有更广泛的普适性，例如平台、渠道、地区、用户、商品等，与工具是什么并无关系。基础模型定型之后，我们开始着手解耦方面的设计：首先是系统交互解耦，将直读DB和存储冗余促销数据的系统修改为调用服务及监听MQ；然后是逻辑回收，包括将促销校验与促销计算提取为交易服务，将原先由购物车、交易系统自行处理的促销逻辑回收；从业务上，将促销工具的属性进行提取，诸如类型枚举、促销标签、限购策略、库存策略等，以期外围系统尽量少的关注促销类型，通过促销ID拿到所需信息直接使用；未来则关注于业务层面的梳理与整合，逐步回收适用于活动模型的其他“类促销”业务。系统解耦后，促销系统需要提供各系统所需要的服务，必须具备更强大的数据处理能力和更好的性能表现。应用架构实现上，从前端页面到后端逻辑，尽量避免有逻辑与促销类型直接绑定，全部以插件化方式与促销模型对接，完全根据促销类型的配置进行组装。针对不同维度、条件、优惠、促销属性，定制页面模板及业务逻辑，使得新增一种促销类型（在已有维度、条件、优惠下）仅需配置即可完成。促销系统的查询服务需要同时为多个系统提供数据，对TPS要求很高，同时促销的时效性又要求很高的实时性。我们采用的方式是在数据库前加Redis缓存，提高响应速度，同时监听MQ，根据事件清理相应的缓存数据。这种设计方案也有一些可能的坑，例如Redis缓存虽然减轻了DB压力，但对于计算密集型应用并未减轻应用服务器压力，IO没有节省还增加了序列化的开销；事件驱动清理缓存在读写分离场景下，有可能比主从同步更快，造成缓存数据错误。这也是具体应用中需要注意的地方。促销系统重构上线后，使多渠道（终端）、多区域化营销成为简单易行的配置操作，显著提高了当当运营能力，当当双十一呈现出更多的想象空间。交易系统重构交易系统是客户购物流程中最重要的环节，主要任务是完成购物车中商品信息获取、拆单、促销计算、配货计算、运费计算、非现金支付的使用以及生成订单等操作，聚合各方面业务逻辑，计算非常复杂，而且响应速度影响购买转化率，一旦出现故障，直接影响营业收入，可谓电商最为敏感的核心系统，决定对其进行重构需要极大的魄力。当当原有交易系统采用.NET技术框架，运行多年，很好的支撑了购买流程，但是弊端逐渐显露。首先是技术体系属于微软系，每年要花费大量成本购买服务；其次是随着业务需求的不断叠加，其结构及可维护性逐年下降，尤其是众多小版本结算的存在，使得功能扩展异常艰难。基于以上因素，交易系统团队在2014年底启动重构项目，2015年10月底新老版本完成切换。此次重构耗费约1500人天，重构代码17万行，全部切换至Java开源技术架构，为公司节约大量成本，并进行了架构优化，整体性能平均提升25%。交易系统业务主流程图如下：交易系统重构引入了许多业界成熟的技术实现方案，主要有以下几点：1.集中化配置集中化配置方式，一点配置，所有实例可见，更易于管理，而且配置修改后，通过热加载方式，立刻生效，快速便捷。而原有交易系统修改配置后，必须重启系统才能生效。2.页面缓存技术用户请求一次交易结算页面，会调用各种后端服务，而由于逻辑的复杂性，每次服务调用都会调用订单计算大流程，导致页面刷新缓慢。新交易系统将大流程计算结果进行缓存，在一次页面请求范围内，后续调用直接用缓存结果，极大提高了页面的刷新速度。3.小版本合并由于历史原因，交易系统存在很多版本的结算逻辑。最常用的是统一结算，还有一些特殊类型的结算，如秒杀、一键下单、补发货等等，逻辑与统一结算稍有不同，统称为小版本结算。因小版本结算与统一结算大部分逻辑相同，因此新交易系统将二者合到了一起，共享基础逻辑，而不同的逻辑则单独处理，极大提高了可维护性。4.灰度发布、无缝切换借助了Nginx在运行状态下可以reload配置，而基本不影响对外提供服务的能力。每个Nginx负载两台应用服务器，灰度发布时，将Nginx配置更改为只负载一台应用服务器，即可对另一台进行部署。用户请求不会导向正在部署中的服务器，从而不影响用户下单。5.并行比对交易系统重构后，尽管进行了大量的测试，仍不能放心部署上线。因为交易系统的计算都和金钱有关，必须慎之又慎，我们提出了线上并行比对方案，根据老交易系统比对新交易，保证其逻辑正确。原理如下：1）用户请求到达老交易系统2）根据条件将部分请求数据复制，发送至调用mock服务的新交易系统3）新老交易同时计算，结果存入各自的数据库，但只有老交易结果对用户公开4）对新老计算结果进行比对这样，既实现了比对目的，又不会影响线上环境。6.分流比对之后，新交易系统也不能立即全面上线，那样可能有巨大风险。我们开发了分流功能，按照用户id来分流，正式分流前，先使用测试白名单中的用户进行预验证。预验证通过后，再按比例由低至高逐步切换。7.Web服务器按需伸缩基于前面所讲的灰度发布技术，新交易系统很容易做到按需伸缩。正常情况下，每个Nginx负载两台应用服务器。双十一需要扩容时，将待扩服务器ip地址加入Nginx配置，重新reload，该Nginx就可负载更多台应用服务器了。交易系统上线后为备战双十一，确保万无一失，利用老交易系统还未下线的条件进行了线上压测。为达到最准确的测试效果，且不影响正常系统运行，进行了以下的准备：1.测试环境、数据与生产环境一致在准备测试环境方面，为了保证测试结果更接近真实结果，本次测试使用线上环境，通过大量测试账号对线上的真实促销商品进行测试，这样也对新交易系统所依赖的各系统服务做了检验。2.线上业务运行保障测试阶段线上的请求切到老交易系统，压测请求发送到新交易系统，使测试和生产业务进行分离，保证了各自服务器资源的独立性。在应用服务器层面使测试过程不会影响到线上正常交易。3.拦截订单回收库存由于使用线上环境测试，需要对测试订单进行拦截，避免进入生产流程，并回收占用的库存，使商品不会耗尽库存，采用的方法是在自动审单系统中将测试账户加入黑名单，测试订单提交后会被拦截，然后取消订单释放库存。为防止测试过程占用了商品的全部库存而影响线上销售，测试商品池基数很大，并且过滤掉了库存数量较少的商品，在执行测试过程中控制每个商品的使用次数，保证可销售库存占用在安全范围内。4.恶意用户策略控制因为在交易下单过程中包含恶意用户判定的策略，会对用户进行隔离，禁止连续大量下单，线上压测时根据实际情况短时间内调整了安全级别，保证订单成功率。经过多轮线上压测，新交易系统的高可用性得到验证，得到了实际性能指标，并根据双十一流量估算进行了扩容部署，将以崭新的面貌为广大客户提供稳定可靠便捷的网购服务。
打造内部应用框架当当技术部现在是按照产品线划分的，一个产品线的产品、开发、测试都在一个部门，但像项目管理、运维、架构这些技术体系中公用的部分是独立的部门。架构部里主要分成三部分，一个是架构与规范，一个是性能测试，一个是基础应用系统研发。我们花了比较多的精力在技术架构上，去年我们在Dubbo上做了二次开发，做了DubboX并且对外开源，业界反馈还不错，包括很多来面试的人都知道。我们的技术体系、核心业务系统明确的方向是Java，去年年底，我们开始做一个基于Java的应用开发框架，DDFrame，用它去对接一些核心组件，包括SOA、作业调度、缓存、消息队列、数据库、配置中心等，现在已经发布了2.0版本。虽然受限于资源，进度比较缓慢，但我们一直在做这件事，未来也会慢慢完善这个框架，使其成为技术体系的核心。开源Dubbox，扩展Dubbo服务框架支持REST风格远程调用当当网近日开源了Dubbox项目，可为Dubbo服务框架提供多项扩展功能，包括REST风格远程调用、Kryo/FST序列化等等。当当网架构部和技术委员会架构师沈理向InfoQ中文站介绍了Dubbox项目，开发背景和主要特点描述如下：Dubbo是一个被国内很多互联网公司广泛使用的开源分布式服务框架，即使从国际视野来看应该也是一个非常全面的SOA基础框架。作为一个重要的技术研究课题，在当当网我们根据自身的需求，为Dubbo实现了一些新的功能，并将其命名为Dubbox（即DubboeXtensions）。主要的新功能包括：支持REST风格远程调用（HTTP+JSON/XML)：基于非常成熟的JBossRestEasy框架，在dubbo中实现了REST风格（HTTP+JSON/XML）的远程调用，以显著简化企业内部的跨语言交互，同时显著简化企业对外的OpenAPI、无线API甚至AJAX服务端等等的开发。事实上，这个REST调用也使得Dubbo可以对当今特别流行的“微服务”架构提供基础性支持。另外，REST调用也达到了比较高的性能，在基准测试下，HTTP+JSON与Dubbo2.x默认的RPC协议（即TCP+Hessian2二进制序列化）之间只有1.5倍左右的差距，详见下文的基准测试报告。支持基于Kryo和FST的Java高效序列化实现：基于当今比较知名的Kryo和FST高性能序列化库，为Dubbo默认的RPC协议添加新的序列化实现，并优化调整了其序列化体系，比较显著的提高了DubboRPC的性能，详见下图。支持基于嵌入式Tomcat的HTTPremoting体系：基于嵌入式tomcat实现dubbo的HTTPremoting体系（即dubbo-remoting-http），用以逐步取代Dubbo中旧版本的嵌入式Jetty，可以显著的提高REST等的远程调用性能，并将ServletAPI的支持从2.5升级到3.1。（注：除了REST，dubbo中的WebServices、Hessian、HTTPInvoker等协议都基于这个HTTPremoting体系）。升级Spring：将dubbo中Spring由2.x升级到目前最常用的3.x版本，减少项目中版本冲突带来的麻烦。升级ZooKeeper客户端：将dubbo中的zookeeper客户端升级到最新的版本，以修正老版本中包含的bug。上面很多功能已在当当网内部稳定的使用，现在开源出来，供大家参考和指正。也希望感兴趣的朋友也来为Dubbo贡献更多的改进。注：dubbox和dubbo2.x是兼容的，没有改变dubbo的任何已有的功能和配置方式（除了升级了Spring之类的版本）。另外，dubbox也严格遵循了Apache2.0许可证的要求。分布式作业调度框架elastic-job的开源elastic-job原本是当当java应用框架ddframe的一部分，本名dd-job。ddframe包括编码规范，开发框架，技术规范，监控以及分布式组件。ddframe规划分为4个演进阶段，目前处于第2阶段。3、4阶段涉及的技术组件不代表当当没有使用，只是ddframe还未统一规划。ddframe由各种模块组成，均已dd-开头，如dd-container、dd-soa、dd-rdb、dd-job等。当当希望将ddframe的各个模块与公司环境解耦并开源以反馈社区。之前开源的Dubbo扩展版本DubboX即是dd-soa的核心模块。而本次介绍的elastic-job则是dd-job的开源部分，其中监控（但开源了监控方法）和ddframe核心接入等部分并未开源。elastic-job主要的设计理念是无中心化的分布式定时调度框架，思路来源于Quartz的基于数据库的高可用方案。但数据库毕竟没有分布式协调功能，所以在高可用方案的基础上增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。团队目前由3个部分组成，第一部分是开发团队，由架构部的架构师曹昊、高洪涛和我组成，主要负责设计和编码；第二部分是来自于各个研发团队的应用架构师、开发工程师和架构部总监史海峰，他们负责推广落地，整理需求并贡献当当已经存在的最佳实践代码；第三部分由架构部性能测试团队组成，负责框架的性能和稳定性测试。elastic-job的主要分为注册中心、数据分片、分布式协调，定时任务处理和多作业模式等模块。注册中心模块目前直接使用Zookeeper，用于记录作业的配置，服务器信息以及作业运行状态。Zookeeper虽然很成熟，但原理复杂，使用较难，在海量数据支持的情况下也会有性能和网络问题。目前elastic-job已经抽象出注册中心的接口，下一步将会考虑支持多注册中心，如etcd，或由用户自行实现注册中心。无临时节点和监听机制的注册中心需要自行实现定时心跳监测等功能。数据分片是elastic-job中实现分布式的重要概念，将真实数据和逻辑分片对应，用于解耦作业框架和数据的关系。作业框架只负责将分片合理的分配给相关的作业服务器，而作业服务器需要根据所分配的分片匹配数据进行处理。服务器分片目前都存储在注册中心中，各个服务器根据自己的IP地址拉取分片。分布式协调模块用于处理作业服务器的动态扩容缩容。一旦集群中有服务器发生变化，分布式协调将自动监测并将变化结果通知给各个仍存活的作业服务器。协调时将会涉及主节点选举，重分片等操作。目前使用的Zookeeper的临时节点和监听器实现主动检查和通知功能。定时任务处理根据cron表达式定时触发任务，目前有防止任务同时触发，错过任务重出发等功能。主要还是使用Quartz本身的定时调度功能，为了便于控制，每个任务都使用独立的线程池。多作业模式将定时任务分为多种流程，有不经任何修饰的简单任务；有用于处理数据的fetchData/processData的数据流任务；以后还将增加消息流任务，文件任务，工作流任务等。用户能以插件的形式扩展并贡献代码。作业即定时任务。一般来说，系统可使用消息传递代替部分使用作业的场景。两者确有相似之处。可互相替换的场景，如队列表。将待处理的数据放入队列表，然后使用频率极短的定时任务拉取队列表的数据并处理。这种情况使用消息中间件的推送模式可更好的处理实时性数据。而且基于数据库的消息存储吞吐量远远小于基于文件的顺序追加消息存储。但在某些场景下则不能互换：时间驱动OR事件驱动：内部系统一般可以通过事件来驱动，但涉及到外部系统，则只能使用时间驱动。如：抓取外部系统价格。每小时抓取，由于是外部系统，不能像内部系统一样发送事件触发事件。批量处理OR逐条处理：批量处理堆积的数据更加高效，在不需要实时性的情况下比消息中间件更有优势。而且有的业务逻辑只能批量处理，如：电商公司与快递公司结算，一个月结算一次，并且根据送货的数量有提成。比如，当月送货超过1000则额外给快递公司多1%的快递费。非实时性OR实时性：虽然消息中间件可以做到实时处理数据，但有的情况并不需要。如：VIP用户降级，如果超过1年无购买行为，则自动降级。这类需求没有强烈的时间要求，不需要按照时间精确的降级VIP用户。系统内部OR系统解耦。作业一般封装在系统内部，而消息中间件可用于系统间解耦。elastic-job的主要功能主要功能分布式：重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心。并行调度：采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项。弹性扩容缩容：将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片。集中管理：采用基于Zookeeper的注册中心，集中管理和协调分布式作业的状态，分配和监听。外部系统可直接根据Zookeeper的数据管理和监控elastic-job。定制化流程型任务：作业可分为简单和数据流处理两种模式，数据流又分为高吞吐处理模式和顺序性处理模式，其中高吞吐处理模式可以开启足够多的线程快速的处理数据，而顺序性处理模式将每个分片项分配到一个独立线程，用于保证同一分片的顺序性，这点类似于kafka的分区顺序性。其他功能失效转移：弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样失效转移功能也会牺牲部分性能。Spring命名空间支持：elastic-job可以不依赖于spring直接运行，但是也提供了自定义的命名空间方便与spring集成。运维平台：提供web控制台用于管理作业。非功能需求稳定性：在服务器无波动的情况下，并不会重新分片；即使服务器有波动，下次分片的结果也会根据服务器IP和作业名称哈希值算出稳定的分片顺序，尽量不做大的变动。高性能：同一服务器的批量数据处理采用自动切割并多线程并行处理。灵活性：所有在功能和性能之间的权衡，都可通过配置开启/关闭。如：elastic-job会将作业运行状态的必要信息更新到注册中心。如果作业执行频度很高，会造成大量Zookeeper写操作，而分布式Zookeeper同步数据可能引起网络风暴。因此为了考虑性能问题，可以牺牲一些功能，而换取性能的提升。幂等性：elastic-job可牺牲部分性能用以保证同一分片项不会同时在两个服务器上运行。容错性：作业服务器和Zookeeper断开连接则立即停止作业运行，用于防止分片已经重新分配，而脑裂的服务器仍在继续执行，导致重复执行。Elastic-job在当当内部也是刚刚进行推广，目前支付系统、订单系统、发票系统、促销系统都有使用，快递系统和仓储系统也即将使用。开源后也得知不少公司有使用计划。
背景：远在天边近在眼前的OpenStack用户OpenStack开源的特性，使其普及的速度比想象中要快得多。尤其受到电商的欢迎。其中携程是目前国内典型的OpenStack用户，从2012年开始搭建私有云，该公司目前基于OpenStack部署了超过1000个虚拟桌面，未来计划部署130000个。除此之外，爱奇艺也是涉足OpenStack的用户，在2012年爱奇艺加入中国开源云联盟，与英特尔、新浪等企业进行OpenStack项目的开发。目前爱奇艺也成为中国视频行业规模最大的OpenStack技术应用商，该技术已被运用到内容生产、广告投放、账号管理、用户付费和大数据分析等方面。 不仅如此，京东商城已经利用OpenStack平台接入了大量线上业务，实现了自动部署、OpenStackHA、桌面云(CallCenter)以及ElasticScalingELB等功能。其中线上业务和CallCenter都属于需要保持高度稳定的服务，京东已经在OpenStack应用部署方面下了相当的功夫，克服了目前OpenStack版本迭代过快和bug问题，已经使其达到了商业化运营的效果。 除了京东，网易使用OpenStack构建了自己的私有云web服务提供云主机支持，并把网易相册，博客等访问量较大的服务迁移到云平台中，目前已稳定运行近1年，中间经历了在线平滑升级和10多个新产品上线，并且网易还针对其产品自身的业务特点在监控、报警、运维自动化方面开发了新功能。OpenStack简介OpenStack是一个开源的IaaS实现，它由一些相互关联的子项目组成，主要包括计算、存储、网络。由于以Apache协议发布，自2010年项目成立以来，超过200个公司加入了OpenStack项目，其中包括AT&T、AMD、Cisco、Dell、IBM、Intel、RedHat等。目前参与OpenStack项目的开发人员有17,000+，来自139个国家，这一数字还在不断增长中。OpenStack兼容一部分AWS接口，同时为了提供更强大的功能，也提供OpenStack风格的接口（RESTFulAPI）。和其他开源IaaS相比，架构上松耦合、高可扩展、分布式、纯Python实现，以及友好活跃的社区使其大受欢迎，每半年一次的开发峰会也吸引了来自全世界的开发者、供应商和客户。OpenStack的主要子项目有：网易私有云使用了Nova、Glance、Keystone、Neutron这4个组件。Compute（Nova）提供计算虚拟化服务，是OpenStack的核心，负责管理和创建虚拟机。它被设计成方便扩展，支持多种虚拟化技术，并且可以部署在标准硬件上。ObjectStorage（Swift）提供对象存储服务，是一个分布式，可扩展，多副本的存储系统。BlockStorage（Cinder），提供块存储服务，为OpenStack的虚拟机提供持久的块级存储设备。支持多种存储后端，包括Ceph，EMC等。Networking（Neutron）提供网络虚拟化服务，是一个可拔插，可扩展，API驱动的服务。Dashboard提供了一个图形控制台服务，让用户方便地访问，使用和维护OpenStack中的资源。Image（glance）提供镜像服务，它旨在发现，注册和交付虚拟机磁盘和镜像。支持多种后端。Telemetry（Ceilometer）提供用量统计服务，通过它可以方便地实现OpenStack计费功能。Orchestration（Heat）整合了OpenStack中的众多组件，类似AWS的CloudFormation，让用户能够通过模板来管理资源。Database（Trove）基于OpenStack构建的database-as-a-service。网易私有云平台概况图1.网易私有云架构网易私有云平台由网易杭州研究院负责研发，主要提供基础设施资源、数据存储处理、应用开发部署、运维管理等功能以满足公司产品测试/上线的需求。图1展示了网易私有云平台的整体架构。整个私有云平台可分为三大类服务：核心基础设施服务（IaaS）、基础平台服务（PaaS）以及运维管理支撑服务，目前一共包括了：云主机（虚拟机）、云网络、云硬盘、对象存储、对象缓存、关系型数据库、分布式数据库、全文检索、消息队列、视频转码、负载均衡、容器引擎、云计费、云监控、管理平台等15个服务。网易私有云平台充分利用云计算开源的最新成果，我们基于OpenStack社区的keystone、glance、nova、neutron组件研发部署了云主机和云网络服务。为了与网易私有云平台其他服务（云硬盘、云监控、云计费等）深度整合以及满足公司产品使用和运维管理的特定需求，我们团队在社区OpenStack版本的基础上独立研发了包括：云主机资源质量保障（计算、存储、网络QoS）、镜像分块存储、云主机心跳上报、flat-dhcp模式下租户内网隔离等20多个新功能。同时，我们团队在日常运维OpenStack以及升级社区新版本中，也总结了一些部署、运维规范以及升级经验。两年多来，网易私有云平台OpenStack团队的研发秉承开源、开放的理念，始终遵循"来源社区，回馈社区"的原则。在免费享受OpenStack社区不断研发新功能以及修复bug的同时，我们团队也积极向社区做自己的贡献，从而帮助OpenStack社区的发展壮大。两年来，我们团队一共向社区提交新功能开发/bug修复的commits近100个，修复社区bug50多个，这些社区贡献涉及OpenStack的Essex、Folsom、Havana、Icehouse、Juno等版本。得益于OpenStack的日益稳定成熟，私有云平台目前已经稳定运行了2年多时间，为网易公司多达30个互联网和游戏产品提供服务。从应用的效果来看，基于OpenStack研发的网易私有云平台已经达到了以下目标：提高了公司基础设施资源利用率，从而降低了硬件成本。以物理服务器CPU利用率为例，私有云平台将CPU平均利用率从不到10%提升到50%。提高了基础设施资源管理与运维自动化水平，从而降低了运维成本。借助于Web自助式的资源申请和分配方式以及云平台自动部署服务，系统运维人员减少了50%。提高了基础设施资源使用弹性，从而增强了产品业务波动的适应能力。利用虚拟化技术将物理基础设施做成虚拟资源池，通过有效的容量规划以及按需使用，私有云平台可以很好适应产品突发业务。网易OpenStack部署参考方案介绍在具体的生产环境中，我们为了兼顾性能和可靠性，keystone后端使用Mysql存储用户信息，使用memcache存放token。为了减少对keystone的访问压力，所有服务（nova，glance，neutron）的keystoneclient均配置使用memcache作为token的缓存。由于网易私有云需要部署在多个机房之中，每个机房之间在地理位置上自然隔离，这对上层的应用来说是天然的容灾方法。另外，为了满足私有云的功能和运维需求，网易私有云需要同时支持两种网络模式：nova-network和neutron。针对这些需求，我们提出了一个面向企业级的多区域部署方案，如图2所示。从整体上看，多个区域之间的部署相对独立，但可通过内网实现互通，每个区域中包括了一个完整的OpenStack部署，所以可以使用独立的镜像服务和独立的网络模式，例如区域A使用nova-network，区域B使用neutron，互不影响，另外为了实现用户的单点登录，区域之间共享了keystone，区域的划分依据主要是网络模式和地理位置。图2.多区域部署方法和典型OpenStack部署将硬件划分为计算节点和控制节点不同的是，为了充分利用硬件资源，我们努力把部署设计成对称的，即任意一个节点下线对整体服务不会照成影响。因此我们将硬件分为两类：计算节点，控制计算节点。计算节点部署nova-network，nova-compute，nova-api-metadata，nova-api-os-compute。控制计算节点除了计算节点的服务外还部署了nova-scheduler，nova-novncproxy，nova-consoleauth，glance-api，glance-registry和keystone，如图3所示。对外提供API的服务有nova-api-os-compute，nova-novncproxy,glance-api，keystone。这类服务的特点是无状态，可以方便地横向扩展，故此类服务均部署在负载均衡HAProxy之后，并且使用Keepalived做高可用。为了保证服务质量和便于维护，我们没有使用nova-api，而是分为nova-api-os-compute和nova-api-metadata分别管理。外部依赖方面，网易私有云部署了高可用RabbitMQ集群和主备MySQL，以及memcache集群。图3.计算节点，控制计算节点网络规划方面，网易私有云主要使用nova-network的FlatDHCPManager+multi-host网络模式，并划分了多个Vlan，分别用于虚拟机fixed-ip网络、内网浮动IP网络、外网网络。运维上使用网易自主研发的运维平台做监控和报警，功能类似Nagios，但是更加强大。其中较重要的监控报警包括日志监控和进程监控。日志监控保证服务发生异常时第一时间发现，进程监控保证服务正常运行。另外网易私有云使用Puppet做自动部署，以及使用StackTach帮助定位bug。OpenStack各组件配置OpenStackHavana的配置项成百上千，大部分配置项都是可以使用默认值的，否则光是理解这么多的配置项的含义就足以让运维人员崩溃，尤其是对那些并不熟悉源码的运维人员来说更是如此。下文将列举若干网易私有云中较关键的配置项，并解释它们如何影响到服务的功能，安全性，以及性能等问题。Nova关键配置my_ip=内网地址此项是用来生成宿主机上的novametadataapi请求转发iptables规则，如果配置不当，会导致虚拟机内部无法通过169.254.169.254这个IP获取ec2/OpenStackmetadata信息；生成的iptable规则形如：-Anova-network-PREROUTING-d169.254.169.254/32-ptcp-mtcp--dport80-jDNAT\--to-destination${my_ip}:8775它另外的用途是虚拟机在resize、coldmigrate等操作时，与目的端宿主机进行数据通信。该项的默认值为宿主机的外网IP地址，建议改为内网地址以避免潜在的安全风险。metadata_listen=内网地址此项是nova-api-metadata服务监听的IP地址，可以从上面的iptables规则里面看出它与my_ip的配置项有一定的关联，保持一致是最明智的选择。novncproxy_base_url=vncserver_proxyclient_address=${private_ip_of_compute_host}vncserver_listen=${private_ip_of_compute_host}novncproxy_host=${private_ip_of_host}我们仅在部分节点上部署novncproxy进程，并把这些进程加入到HAProxy服务中实现novnc代理进程的高可用，多个HAProxy进程使用Keepalived实施HAProxy的高可用，对外只需要暴露Keepalived管理的虚拟IP地址即可：这种部署方式好处是：1）实现novnc代理服务的高可用2）不会暴露云平台相关节点的外网地址3）易于novnc代理服务的扩容但也有不足：1）虚拟机都监听在其所在的计算节点的内网IP地址，一旦虚拟机与宿主机的网络隔离出现问题，会导致所有虚拟机的VNC地址接口暴露出去2）在线迁移时会遇到问题，因为VNC监听的内网IP在目的端计算节点是不存在的，不过这个问题nova社区已经在解决了，相信很快就会合入J版本。resume_guests_state_on_host_boot=true在nova-compute进程启动时，启动应该处于运行状态的虚拟机，应该处于运行状态的意思是nova数据库中的虚拟机记录是运行状态，但在Hypervisor上该虚拟机没有运行，在计算节点重启时，该配置项具有很大的用处，它可以让节点上所有虚拟机都自动运行起来，节省运维人员手工处理的时间。api_rate_limit=false不限制API访问频率，打开之后API的并发访问数量会受到限制，可以根据云平台的访问量及API进程的数量和承受能力来判断是否需要打开，如果关闭该选项，则大并发情况下API请求处理时间会比较久。osapi_max_limit=5000nova-api-os-computeapi的最大返回数据长度限制，如果设置过短，会导致部分响应数据被截断。scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ImagePropertiesFilter,JsonFilter,EcuFilter,CoreFilternova-scheduler可用的过滤器，Retry是用来跳过已经尝试创建但是失败的计算节点，防止重调度死循环；AvailabilityZone是过滤那些用户指定的AZ的，防止用户的虚拟机创建到未指定的AZ里面；Ram是过滤掉内存不足的计算节点；Core是过滤掉VCPU数量不足的计算节点；Ecu是我们自己开发的过滤器，配合我们的CPUQoS功能开发的，用来过滤掉ecu数量不足的计算节点；ImageProperties是过滤掉不符合镜像要求的计算节点，比如QEMU虚拟机所用的镜像不能在LXC计算节点上使用；Json是匹配自定义的节点选择规则，比如不可以创建到某些AZ，要与那些虚拟机创建到相同AZ等。其他还有一些过滤器可以根据需求进行选择。running_deleted_instance_action=reapnova-compute定时任务发现在数据库中已经删除，但计算节点的Hypervisor中还存在的虚拟机（也即野虚拟机审计操作方式）后的处理动作，建议是选择log或者reap。log方式需要运维人员根据日志记录找到那些野虚拟机并手工执行后续的动作，这种方式比较保险，防止由于nova服务出现未知异常或者bug时导致用户虚拟机被清理掉等问题，而reap方式则可以节省运维人员的人工介入时间。until_refresh=5用户配额与instances表中实际使用量的同步阈值，也即用户的配额被修改多少次后强制同步一次使用量到配额量记录max_age=86400用户配额与实际使用量的同步时间间隔，也即距上次配额记录更新多少秒后，再次更新时会自动与实际使用量同步。众所周知，开源的nova项目目前仍然有很多配额方面的bug没有解决，上面两个配置项可以在很大程度上解决用户配额使用情况与实际使用量不匹配的问题，但也会带来一定的数据库性能开销，需要根据实际部署情况进行合理设置。###计算节点资源预留###vcpu_pin_set=4-$虚拟机vCPU的绑定范围，可以防止虚拟机争抢宿主机进程的CPU资源，建议值是预留前几个物理CPU，把后面的所有CPU分配给虚拟机使用，可以配合cgroup或者内核启动参数来实现宿主机进程不占用虚拟机使用的那些CPU资源。cpu_allocation_ratio=4.0物理CPU超售比例，默认是16倍，超线程也算作一个物理CPU，需要根据具体负载和物理CPU能力进行综合判断后确定具体的配置。ram_allocation_ratio=1.0内存分配超售比例，默认是1.5倍，生产环境不建议开启超售。reserved_host_memory_mb=4096内存预留量，这部分内存不能被虚拟机使用reserved_host_disk_mb=10240磁盘预留空间，这部分空间不能被虚拟机使用service_down_time=120服务下线时间阈值，如果一个节点上的nova服务超过这个时间没有上报心跳到数据库，api服务会认为该服务已经下线，如果配置过短或过长，都会导致误判。rpc_response_timeout=300RPC调用超时时间，由于Python的单进程不能真正的并发，所以RPC请求可能不能及时响应，尤其是目标节点在执行耗时较长的定时任务时，所以需要综合考虑超时时间和等待容忍时间。multi_host=True是否开启nova-network的多节点模式，如果需要多节点部署，则该项需要设置为True。Keystone配置项较少，主要是要权衡配置什么样的后端驱动，来存储token，一般是SQL数据库，也可以是memcache。sql可以持久化存储，而memcache则速度更快，尤其是当用户要更新密码的时候，需要删除所有过期的token，这种情况下SQL的速度与memcache相差很大很大。glance包括两个部分，glance-api和glance-registry，：workers=2glance-api处理请求的子进程数量，如果配置成0，则只有一个主进程，相应的配置成2，则有一个主进程加2个子进程来并发处理请求。建议根据进程所在的物理节点计算能力和云平台请求量来综合确定。api_limit_max=1000与nova中的配置osapi_max_limit意义相同limit_param_default=1000一个响应中最大返回项数，可以在请求参数中指定，默认是25，如果设置过短，可能导致响应数据被截断。OpenStack底层依赖软件版本、配置以及性能调优虚拟化技术选型在私有云平台的体系架构中，OpenStack依赖一些底层软件，如虚拟化软件，虚拟化管理软件和Linux内核。这些软件的稳定性以及性能关系着整个云平台的稳定性和性能。因此，这些软件的版本选择和配置调优也是网易私有云开发中的一个重要因素。在网易私有云平台中，我们选用的是Linux内核兼容最好的KVM虚拟化技术。相对于Xen虚拟化技术，KVM虚拟化技术与Linux内核联系更为紧密，更容易维护。选择KVM虚拟化技术后，虚拟化管理驱动采用了OpenStack社区为KVM配置的计算驱动libvirt，这也是一套使用非常广泛，社区活跃度很高的一套开源虚拟化管理软件，支持KVM在内的各种虚拟化管理。另一方面，网易采用开源的Debian作为自己的宿主机内核，源使用的是Debian的wheezy稳定分支，KVM和libvirt采用的也是Debian社区wheezy源里面的包版本：qemu-kvm 1.1.2+dfsg-6+deb7u3libvirt-bin 0.9.12内核选型在内核的选型方面，我们主要考虑如下两方面的因素：稳定性：在开发私有云平台的一开始，稳定性就是网易私有云开发的一大基本原则。我们采用DebianLinux版本，相对来说，Debian的原生内核无疑更为稳定。这也是我们最开始的一个选择。功能需求：在网易的定制开发中，为了保证虚拟机的服务性能，我们开发了CPUQoS技术和磁盘QoS，它依赖底层的CPU和blkiocgroup支持。因此，我们需要打开内核中的cgroup配置选项。另一方面，网易私有云综合各方面考虑，将支持LXC这种容器级别的虚拟化，除了cgroup外，LXC还依赖Linux内核中的namespace特性。综合上述因素的考虑，我们选择了Debian社区的Linux3.10.40内核源代码，并且打开了CPU/mem/blkio等cgroup配置选项以及usernamespace等namespace选项，自己编译了一个适配网易私有云的Linux内核。从使用情况来看，选择上述版本的OpenStack底层依赖软件后，网易私有云运行还比较稳定，我们后续还会适时的对这些软件进行更新。配置优化在网易私有云的稳定性得到了保障之后，我们开始了性能方面的调优工作。这一方面，我们参考了IBM公司的一些优秀实践，在CPU、内存、I/O等方面做了一些配置方面的优化。整体而言，网易私有云在注重稳定性的基础上，也会积极借鉴业界优秀实践来优化私有云平台的整体性能。CPU配置优化为了保障云主机的计算能力，网易私有云开发了CPUQoS技术，具体来说就是采用cfs的时间片均匀调度，外加processpinning的绑定技术。参考IBM的分析，我们了解到了processpinning技术的优缺点，并且经过测试也验证了不同绑定方式的云主机间的性能存在较大的差异。比如，2个VCPU分别绑定到不同numa节点的非超线程核上和分配到一对相邻的超线程核上的性能相差有30%~40%(通过SPECCPU2006工具测试)。另一方面，CPU0由于处理中断请求，本身负荷就较重，不宜再用于云主机。因此，综合上面的因素考虑以及多轮的测试验证，我们最终决定将0-3号CPU预留出来，然后让云主机在剩余的CPU资源中由宿主机内核去调度。最终的CPU配置如下所示（libvirtxml配置）：XML/HTMLCode复制内容到剪贴板1 1024 100000 57499 内存配置优化内存配置方面，网易私有云的实践是关闭KVM内存共享，打开透明大页： 复制代码代码如下:echo0>/sys/kernel/mm/ksm/pages_sharedecho0>/sys/kernel/mm/ksm/pages_sharingechoalways>/sys/kernel/mm/transparent_hugepage/enabledechonever>/sys/kernel/mm/transparent_hugepage/defragecho0>/sys/kernel/mm/transparent_hugepage/khugepaged/defrag经过SPECCPU2006测试，这些配置对云主机CPU性能大概有7%左右的提升。I/O配置优化.1）磁盘I/O的配置优化主要包含如下方面：KVM的diskcache方式：借鉴IBM的分析，网易私有云采用none这种cache方式。diskioscheduler：目前网易私有云的宿主机磁盘调度策略选用的是cfq。在实际使用过程中，我们发现cfq的调度策略，对那些地低配置磁盘很容易出现I/O调度队列过长，utils100%的问题。后续网易私有云也会借鉴IBM的实践，对cfq进行参数调优，以及测试deadline调度策略。磁盘I/OQoS：面对日渐突出的磁盘I/O资源紧缺问题，网易私有云开发了磁盘I/OQoS，主要是基于blkiocgroup来设置其throttle参数来实现。由于libvirt-0.9.12版本是在QEMU中限制磁盘I/O，并且存在波动问题，所以我们的实现是通过Nova执行命令方式写入到cgroup中。同时我们也开发并向libvirt社区提交了blkiotune的throttle接口设置patch（已在libvirt-1.2.2版本中合入）来彻底解决这个问题。2）网络I/O的配置优化我们主要是开启了vhost_net模式，来减少网络延时和增加吞吐量。运维经验使用经验开源软件bug在所难免，但是新版本比旧版本会好用很多，尤其是对于OpenStack这种正在迅速成长壮大的开源软件来说更是如此，这一点在我们使用过Essex、Folsom和Havana版本后深有体会，所以建议各种OpenStack用户能及时的跟进社区版本，与社区保持同步。不要轻易的对社区版本进行各类所谓的功能性能方面的"优化"，尤其是在没有与社区专家交换意见之前，千万不要轻易下手，否则此类"优化"极有可能演变成故障点或者性能瓶颈点，最终可能导致无法与社区同步，毕竟一个公司或团队（尤其是小公司、小团队）的能力和知识储备，是很难与社区成百上千的各类专家相提并论的。多参考各类大型公司分享的部署架构方案，尽量不要自己闭门造车，尤其是对于开源软件来说，各类公司、团队的使用场景千差万别，各种周边组件也是应有尽有，多参考业界实践是最好的方式。一些细节实现可能有很多途径，但每种方式都有优缺点，需要经过充分的论证、分析、测试验证后，才能考虑部署到生产环境使用。所有的部署方案、功能设计都要考虑到平滑升级问题，即使你得到的信息是升级时可以停服，仍然要尽量避免这种情况，因为停服的影响范围很难界定。运维准则OpenStack也是一个后端系统服务，所有系统运维相关的基本准则都适用，这里简单的提几点实际运维过程中根据遇到的问题总结的一些经验：配置项默认值与实际环境不匹配可能导致各种问题，尤其是网络相关配置与硬件有很强的关联性，生产环境和开发环境硬件异构，导致部分默认值在生产环境不适用。应对准则：每个版本都必须在与线上硬件相同的环境测试过才能上线。做好容量规划，已分配的配额量要小于云平台总容量，否则会出现各种问题，导致运维开发耗费很多不必要的精力去定位分析问题。配置项过多容易出错，需要与开发人员一起仔细核对，上线时首先要通过puppet的noop功能验证改动是否正确后，才能真正上线。网络规划要提前做好，如固定IP、浮动IP、VLAN数量等，网络扩容难度和风险都比较大，所以提前规划好是最保险的，一个原则是大比小好，多比少好。网络隔离要做好，否则用户网络安全没办法保证。信息安全问题要重视，这个是老生常谈的问题了，每个平台都有相同问题，但还是要重视再重视，一旦出现安全漏洞，所有虚拟机都面临严重威胁。
如何做好商城类的网站？自从电商的发展不断走向繁荣以来，各种商城网站在互联网上更是铺天盖地，面对竞争激烈的市场，尽管企业建设商城类的网站不能像淘宝京东那些大商城那样做得成功，但是，只要做好以下几个方面，商城类的网站前景还是美好的。下面我们就来看看吧，希望能对大家有所帮助！ 商城类的网站建设有别于其他类型的网站，毕竟此类网站关系到商品直接的线上交易，同时，与产品本身以及网站是否能带给用户购物的便利有着一定的联系，因此，围绕这几点做好网站建设工作至关重重要。 第一，解决货源。企业在决定建设商城网站时，必须要解决货源问题，定位好货源优势。商城类网站是电子商务的典型模式之一，面对广大的用户群，最主要的前提是保证货源充足，当用户在交易的过程中遇到退换商品的情况时，应提供及时有效的解决渠道，让用户有一定的退换空间。 第二，质量保障。通常情况下，商品质量对于喜欢网购的用户来说是衡量信任度的标准，现在的价格战已经很难打了，没有足够的运营成本，靠砸钱的都显得不靠谱，没有明显的价格优势就只能靠商品质量来取得用户的信任，上面已经提到用户在交易中可能会遇到退换商品的情况，能够提供良好的商品售后服务才能给用户提供一定的保障。 第三，商城定位。在保证好商品来源和质量之后，启动商城建设工作时，就要针对产品做好商城的定位，首先要清晰面对的市场群体是哪些，他们存在哪些消费特点，其次是针对这些用户群体设计适合的网站架构，最后是围绕用户体验设计网站布局，尤其是导航指引以及产品分类，一定要做到细致，有条不紊。 第四，购物流程。商城类网站的购物流程是指引用户在网站上完成交易的重要一步，有些用户并不重视这一点，整个购物流程得设计没有逻辑性，那么用户点击购买之后并不知道下一步该怎么做，进一步交易还需要通过慢慢研究才能获得更多的交易信息，浪费太多的时间，有些用户就会选择放弃购买。因此，购物流程要做到简单易懂，操作便捷，减少环节。 第五，安全保证。用户在商城网站可以直接下单支付，有直接的金钱交易，这就关系到网站的资金安全问题，网站在建设时就要考虑好选择哪些支付方式与网站对接，保障网站的后台数据安全。一般这种网站不建议使用便宜的模板网站或者是廉价的网站建设，其存在的漏洞多，宁可多考察，花些成本做一个安全的网站。 当然，以上五个方面只是建好一个商城网站的前提，后期还需要靠自身的运营才能把网站发展起来，只有在运营的过程中发挥出网站的优势，才能在竞争市场上脱颖而出。 下面分享一些商城类的网站建设模板，可供大家参考。 网站一： 网站二： 网站三： 以上就是建设商城类的网站应做好五个方面介绍，希望能对大家有所帮助！~
首先从技术角度看。去年，豌豆荚的研发团队首先拟出了应用内搜索的技术协议，然后基于这个技术协议接入了一些合作伙伴的内容。在他们的配合之下，这些内容被应用到豌豆荚主产品里面，比如跟猫眼做的电影票，再比如可以直接搜到知乎的问答，还有具体场景底下的一些用例。今年，研发团队调整了具体的执行策略，但觉得还是不够快，所以又探索了一些新的方式。仍然是原来的那一套协议，但是不用开发者进来，不用他们配合，而是自己做最快的数据接入的工作。这是今年的改变。这主要是从效率方面考虑的：需要开发者来配合的话，要考虑开发者的响应时间，来来回回去沟通协议具体是什么样的，可能一个来回就是一个星期，有两三个来回一个月就过去了。其他的方向都是一样的，接入的内容还是会跟开发者沟通，一定是他们愿意接入的东西。进展确实很明显，改变了策略之后，目前已经接入了500家左右的应用内容。还有一个很重要的事情，豌豆荚有一个很重要的、叫做Chana（刹那）的技术，集成到了一览里面。Chana是豌豆荚的邓草原老师基于Akka开发的一个实时计算框架，是用Scala语言编写的。研发团队在底层做了应用内搜索的架构升级，包括把这样一个实时性和扩展性都很棒的实时计算平台引入进来，以及对于底层的Storm等平台的升级，这些可能是用户看不见的，但是能很大地扩展数据处理能力。再从产品角度看。产品方面也很清楚，在去年一开始的时候，研发团队主要是在豌豆荚的主产品里做了很多创新的探索，看一下如何将提供给用户的价值最大化。今年又有了更进一步的全新的探索，基于应用内搜索技术，推出了“豌豆荚一览”和“Snap效率锁屏”这样的产品。研发团队也在产品中加了很多的应用场景，比如用户购买了电影票，可以很快地告诉用户，你的电影马上开始了，可以选择打车过去，或是附近有什么好的餐厅，这些都是通过应用内搜索的技术把服务和内容跟用户当前的产品结合在一起的具体例子。这两个产品也是豌豆荚在应用内搜索产品化上给出的阶段性答案。协议：应用内搜索的基石在刚开始的时候，研发团队会把每一个门类特别细节的东西都定义得很清楚，在接入的时候希望接入的内容在每个门类下，这些字段都应该很清楚再接入，这样效率会比较低，现在会倾向于尽可能结构化，一些不能结构化的东西先把它半结构化地拿进来。这样达到一个效率和最结构化的信息和将来结构化信息的利用有一个平衡。另外，研发团队也在不断地做一些细节的优化。像前面提到的今年的变化，不再需要开发者主动的配合，所以内部要考虑怎么能够把各种各样不同的、千奇百怪的应用内容跟协议搭进来。说得通俗一点，是怎么样才能够更聪明地去做适配，怎么样才能更智能化地提高适配效率，在这方面做了很多工作。这个工作可能不是重新制定协议，而是对协议进行一些简单的升级，让它能够普适性做得更好。这里还要提一下DeepLink。之所以有这个概念，是因为移动互联网发展起来，原来那套基于HTTP、超链接实现互联互通的互联网被割成了以应用为中心的信息孤岛。要解决这个痛点，所以很多厂商纷纷提出了自家的DeepLink，但是目前还没有一个事实上的行业标准。比如说谷歌做了一个AppIndexing，Facebook做了一个AppLinks，大家的协议都会有或多或少的差异。目前看来，Facebook的协议因为考虑得更全面一些，所以成为事实标准的可能性会更大。但不管怎么样，这个格局还是很纷乱的，大家更多是从自己的应用场景、自己的应用需求出发，制定这样的一套一套的规则。豌豆荚去年做这件事的时候，更多是从自己和用户的角度去考虑这件事情，主要是从三个点来考虑，一是普适性，二是经济性，三是实时性。先看普适性，豌豆荚做这件事情的时候，市面上已经有谷歌和Quixey的两种协议，所以想兼容这两种协议。如果开发者支持这两种协议，可以直接接入进来。再看经济性，豌豆荚采用的方案都是Microdata这种很成熟的技术方案，开发者可以很快地、比较容易地通过这些技术提交内容。最后看实时性，对于豌豆荚接入的应用内容，如果在手机上看到一个内容，它能够更快地触达用户，还是很重要的。所以开发者可以通过实时API，快速提交内容。当时整个协议的思路主要是从这三个点出发。在应用调起方面，国内的开发者其实对调起支持都不是特别友好，有一个效率比较高的方法，先去看开发者到底对调起的支持怎么样，对于支持好的会在产品里直接调起应用去打开这个页面，如果不行的话，则会调起H5页面。如果所有的开发商和厂商都能够更重视调起这一块，能够把DeepLink这一块做得更好，将来有希望做到应用里面的每一个页面都能够被标准的调起，这样以后应用内搜索可以做成跟网页搜索一样。不过这是下一步要做的工作，当前还不是最重要的。最重要的是先让用户看到这里的价值，用户喜欢用，反过来开发者就会看到里面的价值。团队：小而美应用内搜索方面，豌豆荚一直保持着一个小而精的工程团队，工程人员一直没有特别大的增长，但是工程师搭配比较合理，有搜索领域的专家，也有工程能力很强的软件工程师，还有很有创新精神、勇于探索的年轻人。另外，这个团队的工作也并不是完全自成一套，不是说完全从头开始做的，也会用到很多外界成熟的第三方开源软件。像公司里的Codis和Chana，觉得做得很好的东西，都会有机的结合到产品和工程里面来。团队也是挺开放的。另外，像搜索团队，其实负责了豌豆荚的应用内搜索和应用搜索等工作。改组为项目制要想了解一个团队的工作流程，必须先要了解团队的架构。可能和你想的不一样，豌豆荚团队的架构并不是比较普遍的部门制，而是项目制。改组的原因是之前采用的部门矩阵管理制度使得同一位设计师或工程师会同时负责多个项目，不仅沟通成本大，排期优先级也混乱难以协调。新的项目制的流程是这样的，当一个新的项目确定后，便会确定对应的设计、开发、运营人员临时组成一个项目团队。项目完成后该项目团队解散，再重组进行下一个项目或进入其他项目中（中间过程，项目成员每过3个月也可以申请调换到其他项目）。没有产品经理另外一个你可能意想不到的是，豌豆荚是没有专门的产品经理的。当一个项目组建后，如果该项目产品是以设计为主导的，就由产品设计师整体负责，如果该项目产品是以开发为主导的，就由开发工程师主导。主导人相当于该项目临时的产品经理。对工程师能否负责起这个角色的疑问，张涛告诉极客公园，在豌豆荚，很多产品都是由工程师自己做出来的，包括产品的原型、界面设计等，刚刚又有一位工程师从开发转岗到产品设计，这在豌豆荚并不是第一例。年初王俊煜在接受infoQ采访的时候也有提到过，“有不止一位豌豆在工程师和产品设计师之间有过相互转换的经历”。基础了解后，下面就来从一个项目的流程（从设计开始到开发、测试、上线、后续的运营、反馈迭代）来看看豌豆荚是如何利用工具增加工作的效率，减少那些“为了能够完成工作而需要做的工作”的吧。产品设计前期设计通过团队头脑风暴讨论，然后用便签把idea分类，然后作为一个个的任务归类到项目管理工具Asana里，并指派给负责的人。以后这件事情只和这个人相关，后续的进度、流程都通过Asana的邮件通知去了解和安排。另外在Asana中默认所有人都能看到所有项目，如果想和该负责人一样实时跟进的话只要follow一下就可以收到邮件提醒，保证透明性。产品开发开发的进度管理也是使用Asana，就像前面提到的那样，最早人少的时候开发进度是通过Excel管理的，后来使用一个类似微软Visio的工具，但因为比较臃肿且无法跟踪BUG所以很快就被抛弃。再后来转向使用Jira，因为Jira对BUG跟踪以及进度控制得很好，分配也比较细，还可以统一协调。但后来因为使用成本太高，也被抛弃。Jira之后开始试用37signals的Basecamp，后来因为进度不明确、速度慢也被抛弃。最后开始试用Asana，当时豌豆荚是Asana的第一批用户，也是第一个完整地将团队切换到Asana平台上的（现在使用的团队还有Foursquare,Airbnb,DISQUS等）。继续接着上面的流程，当设计输出高保真原型图后，将包括每一个像素点是多少等在内的具体细节描述都写在GoogleDocs文档上，稍后工程团队会跟进，在这份文档上与设计沟通确定好（中间会有改动），然后工程团队这边也会出一份和设计文档类似的实施文档。这份文档会给工程师以及一些技术大牛们过一遍，大体指出哪些地方应该是什么样，中间可能会面临哪些风险及遇到哪些问题，做一些技术上的指导。然后就是最后的Coding编码了。Coding过程中也是使用Asana进行管理，哪些功能完成了就勾选一下选择完成，之后工程师会收到通知，确认这一块已经完成。后续每周有一个周会来检查回顾上周碰到什么问题并确定本周来做什么，整个研发的过程就是这样。
豌豆荚作为创新工场的首批孵化项目之一，从2009年12月发展至今，用户量已经增长至4.1亿。豌豆荚的主要业务在国内，帮助用户在手机上发现、获取和消费应用、游戏、视频、电子书、壁纸等娱乐内容，在东南亚地区等海外市场也做了类似的业务探索。这样一个快速增长的系统，对IT的底层支持也是一个相当大的挑战。本文将介绍豌豆荚在IT基础架构、工具、流程方面做过的一些事，在不同需求之间如何平衡，团队职责的划分，以及遇到的一些挑战。挑战豌豆荚创立初期国内还没有可靠的公有云服务，所以从2010年开始，豌豆荚通过自购服务器的方式，伴随着豌豆荚在中国市场发展规模逐渐扩大，豌豆荚已经在国内建成了规模较大的数据中心。2014年豌豆荚开始国际化布局，但自建数据中心的方式却很难在国外复制。“不同国家的采购流程和管理政策都不一样，在一些东南亚国家，甚至基础网络提供商都千差万别，自建机房不仅速度缓慢而且无法控制进度。”豌豆荚工程生产力部门质量总监高磊表示，“而业务部门又对迅速提供IT资源支持有着非常紧迫的要求，最终我们发现只用采用云服务才能真正解决我们的问题。”为什么使用AWS在决定采用云服务后，豌豆荚便确定了使用AWS，“我们的工程师团队和运维人员对AWS比较熟悉，如果采用其他公有云产品势必需要一个适应和学习的过程，但我们使用AWS的学习成本很低，因此使用AWS可以说是顺理成章。”质量总监高磊说。除了减少团队的学习成本，AWS服务与自身业务的高度契合也是促使豌豆荚决定采用AWS的重要原因。通过AmazonElasticComputeCloud(AmazonEC2)，豌豆荚提升了新产品在海外的发布速度，还可以根据实际使用量确定服务器计算资源，既提升了工作效率还显著降低了成本，而且由于AmazonEC2的高可用性架构，也大大提升了应用的稳定性和可用性。此外，豌豆荚还使用AmazonElastiCache自动检测并调换运行不畅的缓存节点，降低了基础设备日常管理的费用，同时豌豆荚也使用AmazonElasticCache集成的AmazonCloudWatch功能对设备进行监控，从而更加准确和清楚的了解与Redis等节点相关的性能指标，保证服务和产品稳定。收益如果豌豆荚采用传统自建数据中心的形式，保守估计每个机房需要3-4个月才能完成，而在AWS上只需要几分钟便可以完成一切基础设施的调试。更重要的一点，豌豆荚并没有因为开始拓展海外业务增加任何运维人员，并且与负责传统数据中心的人员投入相比，管理AWS日常运行所需要的人力几乎可以忽略不计。在固定资本投入上，使用AWS与自建数据中心相比较，也能有一定程度的节约。不仅如此，通过对AWS收费政策的理解不断加深，豌豆荚也发现了更多降低使用成本的方法。豌豆荚与AWS的合作处于起步阶段，随着对AWS各项业务的了解不断加深，豌豆荚还将继续将更多业务迁移至AWS上。基础设施的建设与增长豌豆荚诞生于2009年12月，机房部署是从2010年年初开始。那时候因为还没有成熟的云服务可用，所以选择了自建机房的方案。到目前为止，豌豆荚已经在全国各地尤其是北京、天津地区建立了多个节点。从对基础设施资源使用的情况来看，豌豆荚的主要业务对带宽和CDN资源用量会比较高；而从单一业务来看，各类数据挖掘和分析对服务器资源的占用是最大的。豌豆荚从创建一开始就是数据驱动的业务，有很强的用户行为导向，因此数据挖掘的工作量非常多。数据挖掘主要是基于Hadoop集群。豌豆荚有一个数据挖掘团队专门做产品研发（主要是面向内部），而豌豆荚这个团队则提供硬件资源和底层的Hive、HBase等基础设施的支撑和维护。整体的数据量、计算量一直都在增长，一开始的几年增长极快，最近几年稍微慢一些，也有每年几倍的增长。差不多在2011年左右，豌豆荚开始尝试做海外版的豌豆荚Snappea。当时评估过在海外自建机房的可行性，在考察过各个地方不同位置、不同IDC、不同运营商的选项之后，豌豆荚发现即使在进展顺利的情况下，也至少需要两三个月才能建成，这个时间成本太高。如果不自建，那就只有公有云这一个选择，正好当时豌豆荚很多工程师都自己用过亚马逊的AWS，出于时间、知识门槛、成本的考量，就决定在海外使用AWS作为豌豆荚的基础支撑。团队EP团队的目标很明确：在主要产品的完整生命周期内，实现一流的效率、质量和服务稳定性；至于具体用什么技术或者方法，则并不做限制。一开始豌豆荚团队比较关注流程、开发工具等方面，现在豌豆荚对CI、代码库、自动化测试、运维、基础设施建设等各个方面都做了很多工作，有时候工程师要引入一些新的基础设施相关的技术或框架，豌豆荚也会进行review它们是不是靠谱，总的目标就是让产品从开始开发到线上生产环境运行这整条路径下，其稳定性和质量都有所保证。现在整个团队的全职工程师有不到三十人，其中运维团队有十个人，而且他们也都会承担开发任务（豌豆荚叫做SRE，网站可靠性工程师），运维过程中需要什么工具、支持系统，都是由他们自己开发。运维团队的主要工作都在维护豌豆荚自建的机房系统上，AWS上面现在平均投入的维护人力差不多只有三分之一个人。这一方面是因为AWS的维护成本确实低，另一方面也是因为豌豆荚在AWS上面的规模还不是太大。从代码库到生产环境豌豆荚的产品发布流程还是相对成形的。不同的产品线有不同的发布频率，比较稳定的在一周两次，有些比较早期的项目可能一天一次，没有太大的压力。产品下一个release要发布哪些feature、发布周期设置成多久间隔，主要是由产品经理和设计师来决定，工程师实现需求。到了发布日期截止之前，从代码库的主干拉一支发布分支出来做featurefreeze和最后的验收测试，到发布分支上只能做bug修复，不再接受新的feature。有的产品线有统一的测试机制，有的产品线则主要靠工程师自己做测试。无论是哪种测试模式，在进入CI做集成之前和之后都会统一进行静态检查和已有的单元测试用例，然后才上到staging环境。从staging环境开始就属于运维负责的领域了，豌豆荚的staging没有真实的流量，但是环境跟线上是一模一样的，可以说是一直处在最新版本的服务，然后staging再跟线上环境同步代码。这一套自动发布、部署的流程虽然也不是很完善，比如持续集成的检查点还不够多，单元测试率还比较低，不过还算跑的不错。现在AWS上也是同样的一套部署过程，当时适配起来也很快，大概做了一个星期就跑上去了。监控豌豆荚的监控系统要实现的目的无非是两个：实时的报警，以及可以追溯的历史数据，其他都是衍生的功能。跟大部分互联网公司一样，豌豆荚一开始做监控也都是用开源软件搭起来的，不过开源的监控软件现在越来越不能满足豌豆荚的需求。这里面有两个挑战：性能问题数据采集的定制化问题数据采集的定制化主要是涉及到一些业务数据的采集，通用的开源软件也还是要做适配，需要自己去写实现，这个其实还好。性能问题是一个更加严重的问题，这个问题来自于三个方面：越来越多的机器、越来越多的采集项、越来越高的采集频率。以前豌豆荚监控，可能5分钟抓一次数据就行；现在豌豆荚希望做到秒级的采集。监控系统需要有实时分析日志的能力，而到机器数量增长到千台以上之后，要做秒级的采集和分析，无论是数据收集的速度还是数据分析的速度都会遇到瓶颈。所以现在豌豆荚正在自己重写一套监控的系统，专门针对豌豆荚自建的机房体系，包括对多机房架构的支持、与资产系统的对接等等。而AWS上豌豆荚直接使用了其CloudWatch监控功能，目前来讲完全够用了。新的挑战因为业务跟数据密切相关，而豌豆荚部门承担了给数据分析团队提供基础设施的责任。业务对数据报告的需求一般有两类：1、定制化的、定期的数据指标报告此类报告有按天的、按周的、按月的或者按小时的，一般都是比较常规的监测指标，持续监控、持续分析，中间数据保留完整，需要的计算量和存储量容易预测。这种报告需求比较容易满足。2、按需出报告此类需求经常是针对之前没有中间数据的监测值，之前并不知道需要针对此类数值做分析，现在忽然发现需要了，业务部门会要求一次性分析过去半年到一年跟该数据相关的趋势。此类报告往往很耗时，有时候豌豆荚做估算，一年的数据分析完毕需要用多长时间，结果可能是用豌豆荚现在的计算资源，可能要分析一个月才能产出他想要的报告，但这是无法满足业务需求的。要提高分析速度，最直接的做法就是投入更多的计算资源——放在豌豆荚自建的机房就是扩容，如果用公有云就是起更多的实例。一方面扩容是要做的，另一方面现在AWS进入国内，豌豆荚也在考察使用AWS来做这种任务的可能性。实际上豌豆荚用了AWS以来，也逐渐发现豌豆荚之前系统设计的并不是那么好。比如豌豆荚在海外的数据分析，原本是想用EMR的，但是发现豌豆荚现在这套东西搬过去不好直接用，只好基于EC2来做这个事情。为什么呢？因为AWS的理念是让不同的组件做不同的事，比如EC2只做计算，数据持久化存储最好都放在S3；但是豌豆荚的系统一开始设计并没有考虑这些，数据都存在本地计算节点上，如果要重构，需要投入的时间还是挺多的。包括scaling这件事也是，现在豌豆荚基本没有用到scaling，因为豌豆荚的应用上下游之间的依赖关系太重，所以对scaling机制支持的不好。这些都是需要努力的方向。一个比较好的事情是，豌豆荚豌豆荚的工程师都是比较有情怀的，对重构这件事情比较支持。当然，这里面有投入成本和产出的考量，豌豆荚首先要满足的还是业务需求，解决业务问题，至于重构的工作，会随着豌豆荚在AWS上的业务规模更大而变得优先级更高。最后想分享的是，EC2的reservedinstance如果用好了，能够比ondemand模式节省很多。豌豆荚一开始不知道AWS除了ondemand之外还有reservedinstance、spotinstance这些玩法，最近才刚知道。Reservedinstance非常适合WebService使用，临时性数据分析用spotinstance则比较合适。
中国互联网举报中心