咚咚是什么？咚咚之于京东相当于旺旺之于淘宝，它们都是服务于买家和卖家的沟通。自从京东开始为第三方卖家提供入驻平台服务后，咚咚也就随之诞生了。我们首先看看它诞生之初是什么样的。1.0诞生（2010-2011)为了业务的快速上线，1.0版本的技术架构实现是非常直接且简单粗暴的。如何简单粗暴法？请看架构图，如下。1.0的功能十分简单，实现了一个IM的基本功能，接入、互通消息和状态。另外还有客服功能，就是顾客接入咨询时的客服分配，按轮询方式把顾客分配给在线的客服接待。用开源Mina框架实现了TCP的长连接接入，用TomcatComet机制实现了HTTP的长轮询服务。而消息投递的实现是一端发送的消息临时存放在Redis中，另一端拉取的生产消费模型。这个模型的做法导致需要以一种高频率的方式来轮询Redis遍历属于自己连接的关联会话消息。这个模型很简单，简单包括多个层面的意思：理解起来简单；开发起来简单；部署起来也简单。只需要一个Tomcat应用依赖一个共享的Redis，简单的实现核心业务功能，并支持业务快速上线。但这个简单的模型也有些严重的缺陷，主要是效率和扩展问题。轮询的频率间隔大小基本决定了消息的延时，轮询越快延时越低，但轮询越快消耗也越高。这个模型实际上是一个高功耗低效能的模型，因为不活跃的连接在那做高频率的无意义轮询。高频有多高呢，基本在100ms以内，你不能让轮询太慢，比如超过2秒轮一次，人就会在聊天过程中感受到明显的会话延迟。随着在线人数增加，轮询的耗时也线性增长，因此这个模型导致了扩展能力和承载能力都不好，一定会随着在线人数的增长碰到性能瓶颈。1.0的时代背景正是京东技术平台从.NET向Java转型的年代，我也正是在这期间加入京东并参与了京东主站技术转型架构升级的过程。之后开始接手了京东咚咚，并持续完善这个产品，进行了三次技术架构演进。2.0成长（2012）我们刚接手时1.0已在线上运行并支持京东POP（开放平台）业务，之后京东打算组建自营在线客服团队并落地在成都。不管是自营还是POP客服咨询业务当时都起步不久，1.0架构中的性能和效率缺陷问题还没有达到引爆的业务量级。而自营客服当时还处于起步阶段，客服人数不足，服务能力不够，顾客咨询量远远超过客服的服务能力。超出服务能力的顾客咨询，当时我们的系统统一返回提示客服繁忙，请稍后咨询。这种状况导致高峰期大量顾客无论怎么刷新请求，都很可能无法接入客服，体验很差。所以2.0重点放在了业务功能体验的提升上，如下图所示。针对无法及时提供服务的顾客，可以排队或者留言。针对纯文字沟通，提供了文件和图片等更丰富的表达方式。另外支持了客服转接和快捷回复等方式来提升客服的接待效率。总之，整个2.0就是围绕提升客服效率和用户体验。而我们担心的效率问题在2.0高速发展业务的时期还没有出现，但业务量正在逐渐积累，我们知道它快要爆了。到2012年末，度过双十一后开始了3.0的一次重大架构升级。3.0爆发（2013-2014）经历了2.0时代一整年的业务高速发展，实际上代码规模膨胀的很快。与代码一块膨胀的还有团队，从最初的4个人到近30人。团队大了后，一个系统多人开发，开发人员层次不一，规范难统一，系统模块耦合重，改动沟通和依赖多，上线风险难以控制。一个单独tomcat应用多实例部署模型终于走到头了，这个版本架构升级的主题就是服务化。服务化的第一个问题如何把一个大的应用系统切分成子服务系统。当时的背景是京东的部署还在半自动化年代，自动部署系统刚起步，子服务系统若按业务划分太细太多，部署工作量很大且难管理。所以当时我们不是按业务功能分区服务的，而是按业务重要性级别划分了0、1、2三个级别不同的子业务服务系统。另外就是独立了一组接入服务，针对不同渠道和通信方式的接入端，见下图。更细化的应用服务和架构分层方式可见下图。这次大的架构升级，主要考虑了三个方面：稳定性、效率和容量。做了下面这些事情：业务分级、核心、非核心业务隔离多机房部署，流量分流、容灾冗余、峰值应对冗余读库多源，失败自动转移写库主备，短暂有损服务容忍下的快速切换外部接口，失败转移或快速断路Redis主备，失败转移大表迁移，MongoDB取代MySQL存储消息记录改进消息投递模型前6条基本属于考虑系统稳定性、可用性方面的改进升级。这一块属于陆续迭代完成的，承载很多失败转移的配置和控制功能在上面图中是由管控中心提供的。第7条主要是随着业务量的上升，单日消息量越来越大后，使用了MongoDB来单独存储量最大的聊天记录。第8条是针对1.0版本消息轮询效率低的改进，改进后的投递方式如下图所示：不再是轮询了，而是让终端每次建立连接后注册接入点位置，消息投递前定位连接所在接入点位置再推送过去。这样投递效率就是恒定的了，而且很容易扩展，在线人数越多则连接数越多，只需要扩展接入点即可。其实，这个模型依然还有些小问题，主要出在离线消息的处理上，可以先思考下，我们最后再讲。3.0经过了两年的迭代式升级，单纯从业务量上来说还可以继续支撑很长时间的增长。但实际上到2014年底我们面对的不再是业务量的问题，而是业务模式的变化。这直接导致了一个全新时代的到来。4.0涅槃（2015至今)2014年京东的组织架构发生了很大变化，从一个公司变成了一个集团，下设多个子公司。原来的商城成为了其中一个子公司，新成立的子公司包括京东金融、京东智能、京东到家、拍拍、海外事业部等。各自业务范围不同，业务模式也不同，但不管什么业务总是需要客服服务。如何复用原来为商城量身订做的咚咚客服系统并支持其他子公司业务快速接入成为我们新的课题。最早要求接入的是拍拍网，它是从腾讯收购的，所以是完全不同的账户和订单交易体系。由于时间紧迫，我们把为商城订做的部分剥离，基于3.0架构对接拍拍又单独订做了一套，并独立部署，像下面这样。虽然在业务要求的时间点前完成了上线，但这样做也带来了明显的问题：复制工程，定制业务开发，多套源码维护成本高独立部署，至少双机房主备外加一个灰度集群，资源浪费大以前我们都是面向业务去架构系统，如今新的业务变化形势下我们开始考虑面向平台去架构，在统一平台上跑多套业务，统一源码，统一部署，统一维护。把业务服务继续拆分，剥离出最基础的IM服务，IM通用服务，客服通用服务，而针对不同的业务特殊需求做最小化的定制服务开发。部署方式则以平台形式部署，不同的业务方的服务跑在同一个平台上，但数据互相隔离。服务继续被拆分的更微粒化，形成了一组服务矩阵（见下图）。而部署方式，只需要在双机房建立两套对等集群，并另外建一个较小的灰度发布集群即可，所有不同业务都运行在统一平台集群上，如下图。更细粒度的服务意味着每个服务的开发更简单，代码量更小，依赖更少，隔离稳定性更高。但更细粒度的服务也意味着更繁琐的运维监控管理，直到今年公司内部弹性私有云、缓存云、消息队列、部署、监控、日志等基础系统日趋完善，使得实施这类细粒度划分的微服务架构成为可能，运维成本可控。而从当初1.0的1种应用进程，到3.0的6、7种应用进程，再到4.0的50+更细粒度的不同种应用进程。每种进程再根据承载业务流量不同分配不同的实例数，真正的实例进程数会过千。为了更好的监控和管理这些进程，为此专门定制了一套面向服务的运维管理系统，见下图。统一服务运维提供了实用的内部工具和库来帮助开发更健壮的微服务。包括中心配置管理，流量埋点监控，数据库和缓存访问，运行时隔离，如下图所示是一个运行隔离的图示：细粒度的微服务做到了进程间隔离，严格的开发规范和工具库帮助实现了异步消息和异步HTTP来避免多个跨进程的同步长调用链。进程内部通过切面方式引入了服务增强容器Armor来隔离线程，并支持进程内的单独业务降级和同步转异步化执行。而所有这些工具和库服务都是为了两个目标：让服务进程运行时状态可见让服务进程运行时状态可被管理和改变最后我们回到前文留下的一个悬念，就是关于消息投递模型的缺陷。一开始我们在接入层检测到终端连接断开后，消息无法投递，再将消息缓存下来，等终端重连接上来再拉取离线消息。这个模型在移动时代表现的很不好，因为移动网络的不稳定性，导致经常断链后重连。而准确的检测网络连接断开是依赖一个网络超时的，导致检测可能不准确，引发消息假投递成功。新的模型如下图所示，它不再依赖准确的网络连接检测，投递前待确认消息id被缓存，而消息体被持久存储。等到终端接收确认返回后，该消息才算投妥，未确认的消息id再重新登陆后或重连接后作为离线消息推送。这个模型不会产生消息假投妥导致的丢失，但可能导致消息重复，只需由客户终端按消息id去重即可。京东咚咚诞生之初正是京东技术转型到Java之时，经历这些年的发展，取得了很大的进步。从草根走向专业，从弱小走向规模，从分散走向统一，从杂乱走向规范。本文主要重心放在了几年来咚咚架构演进的过程，技术架构单独拿出来看我认为没有绝对的好与不好，技术架构总是要放在彼时的背景下来看，要考虑业务的时效价值、团队的规模和能力、环境基础设施等等方面。架构演进的生命周期适时匹配好业务的生命周期，才可能发挥最好的效果。
自主研发的京东云京东作为国内最大的电商之一，也在搭建自己的云平台，而且大部分的技术都是自主研发。为什么不选择现有的资源而要自己研发?京东云大数据平台技术负责人廖晓辉说：“京东全产业链的电商模式，在国内是独一无二的,没有成熟产品可以借鉴，很多技术问题都需要创新的方式去解决。只有自主研发才能打造出最适合京东的信息系统。第二，“技术驱动”一直是京东的发展战略，我们自主研发的信息系统和积累技术，是京东的核心竞争力之一。但是事实上京东并没有完全自主研发所有的系统，也应用了一些开源的的技术。再结合京东自身的业务，去解决京东遇到的问题，从而更好地为我们业务去服务，为用户去服务。”京东的云平台却包含很多分支包括宙斯、云鼎，移动平台等，是什么原因让京东打算做这么复杂的云平台?廖晓辉认为，京东云对外所推出的公有云服务，都是基于私有云技术的产品。京东自身业务发展非常需要有一个稳定，完善的私有云做基础。在私有云技术产品稳定后我们就对京东生态内的合作伙伴、对社会开放。云平台是京东技术产业化的先锋，要以云技术和云模式，构建一个电商云生态，让京东生态内的卖家和合作伙伴以及让全社会做电商的企业都能在京东云上享受到京东的电商服务。随着京东的发展，京东的卖家越来越多，所有的电商平台都存在这样一个问题：多个租户共享同一数据库实例必然需要一个有效的隔离方案，防止一个用户的慢查询请求或恶意请求影响其他用户访问。廖晓辉说：“就做云数据库来讲，在京东云里面提供的服务既有共享型的数据库，也有独享型的数据库。一些用户特别关注的资源隔离对于这个问题，我们的做法是用独立的虚机方式去做部署，或者基于容器技术—Docker去实现不同级别的资源隔离。”大数据环境下的Spark毫无疑问京东的数据量一定大的惊人，那么在大数据环境下进行数据分析，更多人都会选择Spark，因为大家都知道它是基于内存上面进行运算，这样的话可能处理的数据会有限。廖晓辉告诉记者：“就spark来讲，它出现时间不长发展的却很快，它的RDD分布式内存结构概念和容错性支持，以及利用DAG做执行优化，即性能和可靠性的表现，使得它非常有吸引力。但在内存受限的情况下，确实会影响它的性能表现。对于内存等资源限制的情况下，还需要对大量数据做低延迟处理，，这种场景我们可能需要考虑采取近似计算方式，但如果计算结果的精度要求不能降低，可能我们要走增量计算的方式：持续性地对一些增量数据做一些累进式的实时计算，来得到实时地计算结果来满足业务或用户的需求，相当于把全量数据的离线计算，转变成一种持续性的增量的计算方式。”在数据存储上大致有几类，像通常的key-value数据库，文档型的数据库mongodb，列式分布式数据库HBase等等，京东是如何考量和选择的HBase的?廖晓辉书：其实各种不同的数据库类型我们都有用到,包括HBase和mongodb。选择哪一种需要结合我们的业务需求，考虑数据存取的计算方式以及开发效率。mongodb它对各种语言都非常友好并提供相对丰富的API，它数据在数据量不是非常大的情况下，会有非常好的性能表现。而对于HBase来说，它属于Hadoop生态里面的一款产品，它适合randomaccess场景或少数据量scan，随着数据增长易于扩容同时维持高的读写性能;列存储对于稀疏矩阵数据存储，加上压缩，能提高存储的效率。我们还是根据业务需要，以及数据量的规模，考虑以后的扩容以及项目研发效率来选择。传统上，若是使用HadoopMapReduce框架，虽然可以容易地实现较为复杂的统计需求，但实时性却无法得到保证;反之若是采用Storm这样的流式框架，实时性虽可以得到保证，但需求的实现复杂度也大大提高了我们。SparkStreaming在两者之间找到了一个平衡点?廖晓辉解答：“HadoopMapReduce计算模式实际上降低了做并行计算、大数据处理的门槛，适合于高吞吐量的批处理场景。而Storm和Spark-Streaming，它们都是流式计算的框架。Storm以其低延迟、易扩展性和容错机制等特点发展至今已经非常成熟，也非常优秀，为许多互联网公司所青睐。Spark-Streaming它基于spark将流式数据拆分为mini-batch做持续计算，从目前来看，它的处理延迟可能稍高，但也基本满足实时计算地要求，且它有丰富的计算和转换类API，并易于使用。虽然内部使用Scala去实现但是也支持JAVA的开发，在开发效率方面还是非常高的，此外，我们自己的经验是在生产环境验证了它的稳定性和可靠性。如果对两者进行比较，个人认为，storm适合对实时性要求更高的场合，因为它可以把延迟控制在亚秒级或者更低。而Spark-Streaming作为SparkStack中的一员，如果熟悉了Spark下的开发方式，对Spark-streaming的开发非常容易上手;大部分的大数据处理需求，不同的workload，SparkStack中有相应的技术产品可供选择，可避免维护不同的计算框架。选择Spark-Streaming就要考虑这个生态系统里的其他产品以及开发效率。Spark社区很火，在今年出现1.0版本之后，很快就出现了1.1版本，有非常好的势头，也在实际应用中用它的优异表现在赢得越来越多的用户。”双十一过去不久京东作为国内首屈一指的电商平台在双十一期间如何保证服务器在大量请求、访问的的正常运转而不宕机的?廖晓辉说：“双十一保障是一项有组织有计划地工作。在双十一之前会有一个比较长的筹备时间，会对双十一的流量和业务的增长做一个预估，有计划的去做线上的系统扩容以及完善监控，并对可能的异常做好演练并制定预案。双十一期间近一周左右时间，京东的研发部包括云平台的研发人员会安排人员24小时值班，来解决任何可能出现的线上问题。双十一之后对双十一的情况做一个总结，积累经验，从而提升系统的稳定性。另外，从服务系统架构层面，要有HA,Loadbalance设计，有故障只降服不停服，可弹性扩容;要有非常及时和完善的监控，保障异常情况下，第一时间处理，缩短故障时间。再有就是防攻击系统和灾备方案进一步提供保障。”介绍一下京东云中大数据的云服务，你们的技术实现，对Spark的应用，以及产品路线和遇到的挑战。廖晓辉说：“云海是京东云提供的大数据开放服务，是商家驱动的数据开发平台，商家授权数据，ISV来开发相关数据产品，服务于商家的数据驱动、精细化运营的需求。同时用户也可以上传自己的数据，作为京东平台电商数据的补充。云海中的Spark云海不仅提供大数据存储和计算资源，同时还有云端的数据挖掘和开发工作台，这背后所涉及到的交互查询分析，批处理计算，实时计算，机器学习算法工具，在线OLAP分析，都涉及到Spark相关技术的应用。我们在依托Spark来搭建高效的计算平台和工具集，目的是使挖掘数据价值的过程变得更敏捷，而且是一套全云端的解决方案。京东有大数据平台建设的丰富经验，同时数据驱动业务，数据驱动决策，基于大数据的精细化运营上也有成熟的经验，这些个经验也能帮助在京东上做生意的商家，可以借鉴用于改善运营效率，提高用户满意度。这个价值输出，通过云海，做的方式就是团结在电商领域期望结合大数据提供数字化运营解决方案的软件商这个群体，搭建一个平台以数据为核心，连接商家需求和ISV数据产品服务，同时对ISV的数据产品做一些引导，在解决商家的实际问题中产生价值。在云海的建设过程中我们碰到很多挑战，有大数据处理的技术方面的，对于这类问题，我们也结合业务，基于Spark做自主地研发工作或改进框架本身。同时数据开放的有效和可行方式，我们也在探索中。近些年大数据概念的“热”以及大数据在一些互联网公司，电商企业，以及金融等领域的应用的示范作用，让各组织越来越重视数据资产，现阶段，由于数据的敏感性，对数据收集、处理、挖掘大多限于组织内部。但从另一方面，相信很多人都同。在数据的网络里，数据连接数据，汇聚各领域的数据，数据开放共享、供给不断，让更多人、个体有机会及时、便捷地分析和挖掘其中的价值，势必能让数据发挥更大的作用，甚至把社会信息化带入一个更高的层次。因为这两面性，即在数据资产保护和开放之间求得一种平衡，建立数据交换可行、可信的平台，同时是可持续的，值得更多的组织和个人来探索，合作。京东在云上的新战略京东集团技术副总裁兼首席科学家何刚说道：京东云不止是云计算，是全产业链云服务。在何刚看来：京东在十二年的发展中，构筑了全产业链的互联网电商能力，从供货商到采购、仓库、销售、配送和售后服务，都有了一套成熟的解决方案。京东希望把这些技术能力对外进行输出，包括互联网经验的咨询服务、互联网基础技术的云计算、大数据服务，产品设计、后端核心服务、开发实施等业务信息系统升级建设。并从营销、物流、金融、运营人才等业务资源上结成深度长期的合作关系，做到企业间数据互通，伴随企业共同成长，形成互联网企业生态，做到风险共担、收益共享。战略层面，京东云包含“全产业链能力输出、结成深度合作关系纽带、共享云计算大数据技术、发展互联网企业生态”四个方面，全面帮助中国企业实现“互联网+”的升级。产业链层面，在京东营销、交易、采购、仓储、配送、客服、职能、金融等服务基础上，汇聚信息流、物流和资金流，提供互联网基础技术(云计算和大数据)，互联网经验输出(战略咨询、商业模式、管理咨询)、电商业务资源合作(营销、商品、物流、金融、运营等)，业务信息系统建设升级(系统设计、核心功能模块、开发实施)。产品层面：面向云平台的工具运维服务，如自动编译、统一监控、统一日志、自动部署;面向行业的云计算服务，自动扩展部署、离线/在线数据分析、开放API;面向云托管服务，如云数据库、缓存、VPC、数据复制、灾备、负载均衡、消息队列、云安全;面向资源服务：云存储、云主机、云网络、计量计费等。目标锁定：农业、制造业、服务业、金融、政务、物流。创新联盟启动：京东云与嘉宝集团、锋创科技、福建茶博汇就电商云的合作完成签约;与首农集团、亚信数据、百度就数据云的合作完成签约。未来还有更多传统企业、生态伙伴达成长期稳定合作。何刚表示：“企业的互联网化已经不能仅仅停留在业务电商化的层面上，而是需要将互联网思维和技术结合起来，对外、对内都深度互联网化。”从外部看，在商业模式上，应该采取什么样的电商模式?是委托代运营?官网电商化?还是经销商自建模式?营销推广上，如何获取客户流量?如何实现多个平台、多种渠道的交叉引流?如何做到在不同渠道的统一展现?从企业的内部出发，产品与服务的互联网也是标配，如产品的APP化、智能化等，从而建立互联网化的平台与企业生态。在这些问题上，京东云都能够推出行之有效的解决方案。对于生态联盟，他补充道：京东已经向政府建言献策，希望可以从更高层面构建互联网+联盟，京东云也会积极加入，真正帮助更多企业走向“互联网+”。“京东将以公有云、私有云和混合云的形式，把这些成熟的云计算、大数据和基础技术将对外开放，为企业、政府、科研机构提供云服务。”京东云电商云事业部总经理任成元认为这是京东云的互联网+战略的实际意义和价值所在。值得注意的是，京东基础云由私有云和公有云两部分组成，而“京东私有云和公有云是同一套技术同一个平台同一班人马做的。”京东私有云支撑京东集团各个信息系统。云存储系统稳定支持了主站商品图片、订单、物流等200多个系统的运行，京东私有云可以实现对流控、CPU、I/O等资源细粒度的精准控制和自动伸缩。在系统运行方面，利用弹性计算云，服务器总体使用率提高十倍，网络访问量平均成本同比下降60%，运维自动化率也达到了90%以上。京东公有云服务中的云主机服务、对象存储服务(云存储)通过了云服务可信性的权威认证体系，并获得了可信云年度电商云服务奖。而从京东云产业链服务中可以看出，京东云在IaaS、PaaS和部分SaaS已经完成布局。举例来看，京东云可以从销售信息、用户行为、供应链效率、客户满意度和财务数据上进行数据采集、挖掘以及可视化分析，为用户提供京东级数据分析服务能力，一站式满足企业数据分析的诉求。“”对于近期业内所关注的安全问题，京东云首席架构师杨海明表示：“京东网站、京东金融、京东到家等每天受到很多攻多，所以也积累了各个方面的安全防护经验。比如网络二层、三层、应用层的安全防护。这些经验的都会逐步通过京东基础云安全服务产品来输出。未来，我们是开放的生态系统，也欢迎更多SaaS安全的来合作”。京东云首席数据架构师杜宇甫也表示：“数据服务有不同安全机制，包括授权、身份认证、各方向上安全使用等级划分等，而后续，还会随着需求的变化，提供更多数据防护。”而由于绝大多数京东集团的业务都已在京东云平台上，面临即将到来的电商双十一大考，何刚感到压力很大。“自营式电商，决定了我们采购、销售、交易、物流、服务等都是自己来做，上千套系统在京东云上，业务极为复杂。所以我们备战压力很大，但相信自己不会出一点事，也必须如此。”
推广对一个行业的发展和产品的品牌效应都占有至关重要的影响地位，那么首先说一下贴吧这个众人皆知的大众推广途径！每上映一个新片子，只要这个片子有一定的热度，马上该片子的贴吧就会出现各种索要片源的人。这些流量在这个特定的时间内目的都很明确，满足他们的目的也很容易。所以很容易利用片源将这些收集起来。这是笔者所整理的从11.25-12.31期间会上映的“大片”，也就是所谓的大制作或是明星主演的。如下图：第一步：如何获得片源在某个电影上映后，你要想利用此电影去论坛吸引流量，你最好手里有这部片子，虽说是盗版的，即使不清楚，人们也愿意去看。如何获得片源呢?1.免费的，你可以从一些盗版片子的论坛上找，他们更新的速度很快，而且大多都上传在百度云。你保存起来也容易。2.你可以花几块钱去淘宝上买。第二步：去该电影的贴吧论坛上发帖子一般，新上映的电影，大家去搜索的话，如果想要找片源，第一个去的地方就是该电影的贴吧，其次的话就是百度知道和豆瓣。这些都可以作为你推广的主战场。笔者在这里只说贴吧。操作之前，要想清楚，你要将流量吸引到哪里，是QQ，是QQ群，是论坛，网站，还是微信。这个主要是跟你的盈利线路挂钩。我这里以微信举例。因为你日后可以利用微信的粉丝做发发啦，人人转等。发帖子的格式，现在很多电影的贴吧中都有。你完全可以扒过来。我以这个帖子为例。大家可以发现这种帖子一般有几个固定的组成部分。如，“高清”，“超高清”，“完整版”，电影文件截图，电影画面截图，还有就是链接。我们引流到微信，所以就不用放什么链接，直接放上微信号码就可以了，也可以加上二维码。第三步：微信日常的维护这种以电影片源为诱饵吸引的流量，精准度差，也就是比较大众化，什么人都有。而且，他们都不愿意掏钱看正版电影。所以，如果你利用这种流量去做一般的产品，效果不会好。但是，这些流量有他们的优点：很好培养粘性，忠诚度较高因为上映的片子各个阶段都有，只要你跟他们说清楚，你会第一时间的向他们提供最新的片源，他们也就不会将你删除。所以啊，他们很好维护，你只要不断的更新片子，他们就会对你拥有较高的忠诚度。除了给他们提供各个新上映的片子以外，你还可以通过这个方法来维护：我们可以去淘宝花几块钱，买视频网站的会员，去打开这些VIP才能够看的电影，下载也好，或是拿截屏软件录制也好，把高清的电影录制下来，这样，你就会有高清的高质量的好片源了。价格真的不贵，而且你有了这些片源可以反复的利用。第四步：如何利用这些流量轻松变现我在这里只说一个最为简单的，就是利用发发啦或是人人转。发发啦或人人转，就是你在微信上转发他们的文章，只要有人看你转发的文章，你就可以有钱赚。以发发啦为例。每一篇文章每次阅读可以收入5分钱，如果你分享的文章被好友分享了，他的好友所产生的点击也算你的收入。邀请好友的话，每成功邀请一个好友，奖励5毛钱，并且可以永久获得该下线分享文章收入的百分之20佣金。用这个来变现，非常的简单。因为你不用软文，也不用考虑什么流量的精准度。每天不要多发，一天发上个3篇-4篇就可以了。当然，这个项目收益并不多，所以适合新手来练手的。虽然钱不多，但是好在可以锻炼执行力，边玩边提高嘛!利用资源分享，很容易涨粉，反正也不要求精准的流量。一天拿下个二三十还是容易的。重在执行。千万别光嘴上说说。因为在这个项目中，我们的盈利线路是以转发获得佣金。所以对流量精准度的要求就很低了。你可以去找各种允许“资源分享”的贴吧来吸引流量：一是因为该类贴吧默许资源分享，所以不怎么删除分享资源的帖子。二是因为通过分享某种资源吸引的流量很容易增加其粘性，培养忠诚度。毕竟，你只需要不断的更新该类资源就可以了，所以掉粉的情况会少见些。从哪里找那些允许资源分享的贴吧或是论坛呢?这些贴吧或是论坛很好找，如各种电影贴吧，妈妈类论坛，各种小说贴吧，游戏类贴吧(如：模拟人生吧)，各种考试贴吧论坛。
企业网站正在做SEO优化内容更新时，常常城市环绕枢纽词，偏重于公司静态战公司产物，并且更新的内容篇幅短。那么，企业网站内容更新怎样做才更有档次呢?下面以轮滑网站为例探讨如何做好行业网站的更新。 企业网站在做SEO优化内容更新时，往往都会围绕关键词，侧重于公司动态和公司产品，而且更新的内容篇幅短。企业网站更新是一个长期的工作，如果内容只围绕公司去做，没有将眼光放到行业上或者更高的位置，那么，企业网站内容更新工作会出现两种情况，一种是越写越感觉无内容可写，另一种则是企业网站内容太拘囿企业自身，其实不利于提高网站的档次，一个企业只有站在行业的高度上才能越做越强，企业网站也应该如此。 轮滑在体育锻炼中，因为其具有娱乐性、竞技性，时尚新潮等特点，在青少年中参与的人数越来越多，做一个轮滑网站，无论是做品牌推广，还是产品营销，网站都离不开内容更新。轮滑网站内容更新的方向有很多，现在从众多题材中选择一下方向和各位喜欢轮滑的站长们分享一下： 一、关注行业新闻，实时报道 任何企业网站都隶属于某个行业，而轮滑行业最能引起轮滑爱好者的就是大大下下的轮滑竞赛。谈到轮滑赛事，几乎全国各地举行大大小小不下百余次，有的轮滑赛事甚至具备规模化、规格化、时尚化的特点，而且全国大大小小的轮滑赛事直接推动了轮滑运动爱好者的加入，从而让更多的人喜欢轮滑运动。 当然，对于网站来说，不能将所有的赛事都做内容更新，不过这几个城市的赛事应该加以关注，包括苏州的全国速滑锦标赛、北戴河轮滑节、曾经举办过世界级轮滑赛的海宁。对于这些轮滑运动比较有影响力的城市和赛事，在互联网信息时代，轮滑网站站在专业的角度上去做内容，会吸引通过网络渠道搜索相关的用户访问网站。 二、对企业运营进行内容采写 企业运营是企业日常重要的工作之一，轮滑行业除了制造之外，和企业行业比较，因为属于体育运动项目，那么，在运动场地、轮滑场所就有许多可以采写的内容，轮滑运动具有一定的场地限制，虽然在广场上、公路上都可以进行轮滑运动，但是广场上被大妈所占据，而公路上来来往往的车辆安全系数低。因为轮滑运动的逐渐热起来，一些城市开始建设了大型的轮滑场馆，并且在轮滑场馆举办了休闲健身类的赛事、进行轮滑运动的培训、训练、交流的场所，在一些城市，比如上海、苏州、北戴河、深圳、长春、广州、合肥等城市的轮滑馆还曾经举办过国际性的轮滑赛事，对这些场馆的赛事和运营情况进行内容报道，可以大大丰富轮滑网站的内容空间，而且具有一定影响和规模后，以轮滑资讯内容为主的网站可以获得这些场馆的广告收入。 三、关注企业的主要目标人群 企业不仅要更新和企业相关的内容，也要关注企业的目标人群。作为轮滑行业，目标用户群校园大概占据三分之二左右，据轮滑网统计，全国有上万个轮滑俱乐部，包括专业和非专业的，这些俱乐部主要集中在校园，尤其是以大学和小学为主要群体，在中国大学校园，超过60%的学校都开展了轮滑运动，甚至定期举行轮滑比赛，而在小学，是引导孩子喜欢轮滑运动的最好时机，很多轮滑企业通过赞助小学开展轮滑运动或者举行相关赛事增加其品牌影响力。校园是轮滑运动的主要阵地之一，可以通过兼职的方式向网站提供关于学校举行的轮滑比赛，加大这方面的内容更新，增加轮滑网站的访问量! 同时，因为轮滑运动的特殊性和具有一定的难度性，和其他运动比较，不是很容易上手，所有参加轮滑运动的人都需要专业人士指导，轮滑培训、轮滑教材等被初学轮滑者关注。那么，对于网站来说，适当的报道一些轮滑运动的心得、新手体会、轮滑技巧体验等，对于一些访问流畅的网站来说，不妨分享一些视频，更有效果! 四、企业产品内容更新是重点 企业产品是企业的核心，产品主导的企业的发展，所以，企业网站产品内容更新一直是重中之重。那么作为专业的轮滑网站，对轮滑器材的展示和报道也是一个重心，我们在各类展销会上通常看到，很多轮滑企业都会展示自己公司的最新产品。甚至有的轮滑企业在一些重大轮滑赛事时加大新产品的宣传力度。对轮滑器材的专业解读，可以让网站变得更加专业、有深度，对轮滑器材进行内容更新的时候，每篇文章配上相关轮滑产品的图片更有效果! 在行业细分的大势所趋下，轮滑网站也各有侧重点，比如有专门分享教学的视频网站，有专门介绍重大赛事的资讯网站，也有做产品代理的营销网站，根据各自侧重点不同，在内容更新上会有不同的侧重点，以上是和大家分享的网站更新上档次的方向建议，随着轮滑运动的不断普及，那么关注这方面的人群会越来越多，轮滑行业中无论是轮滑企业还是轮滑网站想要通过网站活动用户或者出售产品，在网站内容报道上围绕核心关键词多方面多视角的进行内容更新，才能有利于网站的搜索引擎优化! 以上就是关于如何做好企业网站的内容更新介绍，希望大家通过这篇教程能对大家有所帮助！
背景：2014年9月4日，魅族科技今日与戴尔签署合作备忘录，双方将建立长期战略合作伙伴关系，致力于加速魅族移动互联网基础建设，同时协助魅族搭建内部私有云。这一举动，也体现了戴尔对中国高端手机制造业的支持。魅族云服务的优势在于系统级别整合、权限智能分配、一站式帐号管理，这也对互联网整体解决方案提出了更高的要求，并面临更多难点。此次合作的建立标志着魅族又一次与国际顶尖信息技术供应商的接轨，业界更佳期待戴尔发挥其解决方案优势，全力帮助魅族加速其云架构建设，实现更大的成功。应用商店可以说是移动设备上最特殊的一个应用，它用于分发和管理其它应用，是移动操作系统的核心之一，但和操作系统其它组件不同，它需要一个庞大的云端作为支持。魅族应用商店是国内最早的应用分发平台，在国内首创了许多业务模式，本次魅族工程师将分享魅族应用商店云端的整体架构。水平分层、垂直拓展应用商店首先定位于应用管理平台，其次更是应用分发平台，其典型业务场景包括：帮助Flyme用户找应用；帮助Flyme开发者推广、分发应用；营造维护应用分发生态圈。根据业务场景，不难推导出业务架构特点：读多写少；请求量大、并发高；系统要求延时低；数据规模可控；用户关联弱。随着用户规模的增长，不断的重构、线上运行、探索与沉淀，逐步形成了当前平台的架构。如下图所示。横向、典型的三层架构；纵向、以业务为驱动，积累沉淀了众多技术规范、基础组件，丰富完善全栈业务监控。依托完善的监控体系，衍生出相应的服务治理机制。服务化框架平台早期，规模小、结构简单。伴随公司互联网转型，用户规模高速增长、业务增多，平台关系复杂、扩展难、开发效率低，原有架构完全无法服务大规模的Flyme用户。为了减少业务依赖、提升集群效率、提高开发部署效率，我们基于业务典型场景，把业务逻辑模块化，单元化。拆分出了应用管理、应用展示（榜单）、应用推荐（个性化推荐）、应用搜索等多个服务。服务分为两类，一类是基础服务，该类不依赖其他服务，业务逻辑简单，仅提供基础业务逻辑，例如应用管理服务。另一类是聚合服务，该类聚合多个基础服务，形成相对复杂的业务逻辑，例如应用搜索服务。成型服务化框架能满足大众化的需求，如远程调用、动态发现、负载均衡、监控等，同时势必会引入一些无关的功能，影响性能。外加此类产品无法满足我们的定制化需求，我们重复造轮子。与以往同类产品不同，我们做了如下改进：精细化度量指标实时度量计算系统依赖、调用链无缝IT系统集成服务间采用自研的Kiev框架通讯。Kiev底层通讯基于Netty网络框架，序列化支持协议支持Hessian、Protobuffer等，支持跨语言（C/Java）调用，通讯协议支持TCP、UDP等。框架基于ZK(ZooKeeper)实现了HighAvailability与LoadBalance策略。服务调用时会采样，生成详细的调用链，收集，产生丰富的服务状态数据（ResponseTime,QPS），为服务治理提供了详实有力的数据支撑。消息队列（MetaQ）消息队列是分布式应用间交换信息的一种技术。为了解核心业务及辅助业务，我们引入消息队列，将搜索团队、大数据团队需要的业务数据定期全量同步，实时增量更新。既隔离了业务间的强耦合，又保障了数据的及时性。接口规范接口众多、形式多样，管理维护成本高，为了规范开发流程、便于问题跟踪定位，我们制定了统一的接口规范。例如接口采用RESTful风格，统一接口返回形式，约定每个业务层的错误编码，每个错误编码还会携带可选的错误提示，方便问题跟踪。安全性也是平台不可忽略的一个关键点，基于通用型的原则，我们采用了业界通用OAuth协议来保障接口安全。为了应对异常流量对系统造成的冲击，我们给接口层添加了流量控制功能。分布式缓存平台早期，分发接口采用DB+本地缓存的方式提供数据，这种模式DB压力大、接口吞吐量小、本地缓存更新不及时。为了解决这些问题，我们引入分布式缓存Redis。业务接口数据全部被缓存到Redis集群，缓存数据由定时任务主动刷新，零穿透，缓存即存储、存储即缓存。依托Redis的高性能极大的提高了系统吞吐量。Redis集群先按业务场景做垂直切分、再根据数据量做水平分片。业务通过代理（Twemproxy）连接所有分片。Redis集群基于ZK实现HA（HighAvailability），基于定制化脚本实现线上自动扩容，这样既保障了缓存集群的高可用性，又满足了集群容量自动扩充的需求。MySQL水平分片随着用户规模增长，单库单表已无法满足业务需求，为此我们将数据量大的用户数据库横向拆分出多个数据库。为了降低运维成本，我们采用了单实例多数据库的部署模式。业务层通过分库路由组件透明的访问数据库。当单实例多数据库的模式无法支撑当前业务需求时，通过更新路由规则就可以平滑的完成DB扩容。GSLB(GlobalServerLoadBalance)使用域名提供服务的互联网企业，都无法避免在有中国特色的互联网环境中遭遇到各种域名被缓存、用户跨网访问缓慢等问题。Flyme互联网基础架构团队推出了一种全新的域名解析调度系统：GSLB。GSLB是为移动客户端量身定做的基于Http(s)协议的流量调度解决方案，解决LocalDNS解析异常以及流量调度不准。GSLB的原理非常简单，主要有两步：A、客户端直接访问GSLB服务接口，获取业务在GSLB服务中配置的访问最优的IP。基于容灾考虑，我们保留了运营商LocalDNS域名解析的方式。B、客户端获取到的业务服务IP后，直接向此IP发送业务协议请求。GSLB将域名解析的协议由DNS协议换成了Http(s)协议，并不复杂。但是这一转换，却带来了许多收益：A、解决域名解析异常：用户使用Http(s)协议向魅族GSLB服务发起域名解析请求，绕过了运营商的LocalDNS，用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰，有效预防DNS劫持。B、用户就近访问：GSLB能直接获取到用户IP，结合魅族自有IP地址库以及测速机制，可以为用户搜索最优的IDC服务节点。C、实现精准流量调度：流量异常（周年庆推广活动）或机房故障时，方便快捷的将流量平滑的调度到附近的机房，保障服务的高可用性。下载防劫持运营商HTTP劫持推送广告的情况相信大家并不陌生，近来国内各大应用分发平台都有不同的程度的应用下载被劫持现象，我们也难置身事外，为此，我们上线文件下载防劫持方案。如下图所示。应用商店在分发应用时，会同时分发应用文件的摘要等相关信息，客户端下载获取到应用文件(Apk)后，会计算并比对文件的摘要，以此来判别文件是否被修改或替换。如果文件比对失败，则更换为HTTPS通道继续下载应用。为防止CDN与源站的网络被劫持，CDN回源前后也会校验文件信息。除了比对应用文件的摘要，我们还会比对文件的大小、包名（Android应用的唯一标识）、版本号等信息。针对APK下载场景，生产环境我们主要使用文件大小和包名来做校验。有些游戏应用文件比较大，如热门游戏《植物大战僵尸》大小在100M左右、热门网络游戏《梦幻西游》大小在300M左右。如果全量计算文件摘要这样会比较耗时、耗资源，对硬件资源有限的手机来说是一笔很大的开销，势必会影响到用户的操作体验。为此，针对大文件，我们采用了部分比对文件摘要的方式。应用商店应用数量大、渠道不单一，为了预防分发信息异常造成大面积应用下载失败事故，云端新增了动态关闭、调整客户端判别逻辑的机制。无论劫持动作是否成功修复，客户端均会上报操作日志，借助大数据的优势，我们可以分析改进防劫持效果。
网站从制作到上线到运营，这是一个比较长期的过程，其中牵扯到千丝万缕的因素。其实网站真正的能否到达预想的效果，这不仅仅是建站公司存在的问题，客户方面其实也是有很大原因的。其实吧，我们能做也是很少的，这就好比印刷名片，我们只是印刷名片的厂家，而对于客户来说，名片能否发出去，发到用户的手上，让用户了解到客户的服务，这就得依靠客户自己去想和自己去发掘，再解决掉。因此，这其中忽视掉的问题，就来进行分析分析。宗罪之一：网站作用的定位在谈单的过程中，很多时候听客户说网站建设的需求的时候，很喜欢说一句话：公司原来没有网站，现在想建一个官网挂在上面。每次听到这的时候，作者就在想客户对对网络推广应该从没进行过吧。因此很多的时候，客户只是把公司网站定位为：可以挂在网上，让别人也知道有网站，有这个东西。这种想法导致网站根本没有被利用起来，网站建设的目的是为了宣传，扩大企业的影响力，彰显企业品牌。其实网站建好后，可以利用网络把网站的优势发挥出来，通过网络使企业可以和消费者直接沟通。所以呢，当网站最后没有达到理想的效果，没有给客户带来利益的时候，最后客户肯定会说：这家建设公司建的网站真不咋地。宗罪之二：忽视搜索引擎习惯国内网站设计方面的飞速发展和不断创新，所以网站的类型和风格上可谓是百花齐放。很多网站上，图片、Flash、音乐各色各样的都有，那就会引起一个问题：这个站或者那个站比较耀眼的东西要是被自己的客户看到了，客户肯定会说这个我要，那个我要。其实吧，如果在放很多的图片、Flash、音乐就会导致网站的打开速度会变慢很多，这样会导致用户不会花那么多时间去看网站而是选择直接关掉。这样网站就直接失去了作用。更深层的是，现在搜索引擎对图片、Flash、音乐是无法做完全识别的，那也就是用户和搜索引擎都看不到，那这些东西就没起到任何作用了。受欢迎的网页是会给人很清爽的感觉，条理清晰，网站中有丰富的内容，却不会显得杂乱，给人舒服的感觉。所以网页不需要做的太花哨，简单就好。宗罪之三：不重视用户的体验，不积极与用户沟通网站好不好，其实很多程度上还是用户说了算。如果你网站的排版和内容能够引用用户，那么客户就会经常去访问你的网站，这些你网站的流量就大了。同时在和客户的沟通过程中，当我们和客户很熟悉的时候，客户会对网站提出大量的意见，这不得不说是宝贵的。只要我们主动地寻求用户的反馈，追求良好的用户体验度，那么用户的体验度提高了，自然你的客户就多了。宗罪之四：网站从不更新很多时候，网站做好了，客户从来不去打理，就像前面说的一样，建一个网站只是为了“挂在网上而以”。网站，我们可以理解为在网上，我们占领了一席之地。原本大家都是平等的，大家领地的大小都是一样的。但是我们从不去管理我们的领导导致我们的范围越来越小，能容纳的客户也越来越少。其实，哪怕你一天更新个1，2篇，只要是自己写的，这不仅仅是我们对自己服务的一个认识，同时也是自己对产品的经验。也只有这样，我们才可以对我们的产品和服务了解的越来越透彻，我们才可以做得更好。宗罪之五：一味的仿照多企业的客户在网站做好了以后，看见别人家的网站好看，功能又多，就想把自己的网站也做成那个样子的，每次当作者遇到这样的客户的时候，真的很想给客户好好的上一课。做网站不能总想着好看和一味的仿照，东西终究还是别人，就算我们拿来了，给我们带来的作用那也已经全部被别人赚去了。而重要的是这个网站的实用性，以及网站的前途。做网站的目的不是为了好看，而是看这个网站的功能能否能满足企业的需要，并借助网站来为我们带来客户，带来效益。宗罪之六：网站推广无计划在签单之前，都会和客户沟通一下网站的后期发展问题，但是很多的时候，客户都会说没时间，忙，不会。这时候作者是很纳闷的，网站做好后，又不是作用的而是客户自己的。如果网站做好了，但是客户自己都不去想网站的后期发展，我想这个网站注定是没有前途的。好的网站推广计划的制定都是对网站有意义的事情，同时也是自己过大公司规模和销路的时候，而客户却没有考虑这么多，很多的时候看重的只是眼前的利益。网站建设需要专注，想要依靠网络取得效益，那么你就必须在网络上多下功夫，扩大推广，增强公司的影响力，在市场营销上多动脑。互联网是一块大蛋糕，而有的客户却从未去考虑。而很多时候，我们提的意见和建议在客户眼里，只会是我们再向他进行推销产品的借口。而网站是客户自己的，其实和我们真的没有任何关系。以上就是小编为大家整理的网站建设中的六宗罪.希望对大家有所帮助，请继续关注站三界导航。
内容与表现分离，从标准到国人重视那天起，就已经讨论了，但是停留在div+cssxhtml+css纯代码的分离，思想上流程上，到底如何分离?古老的话题：一首古诗的分离1.给你一首古诗，保存为毫无格式的一堆文字，你去理解它的内容，进行结构的处理。用word排版之后，他有了结构2.这个结构其实包含了语义和表现3.用html进行结构化，抛开一切的表现形式，只考虑语义4.用CSS进行表现处理，包括html的默认表现，他拥有了视觉表现，这个表现体现出了结构化，也体现出了用户体验，用户体验中包含了交互的排版和视觉体验5.如果加上行为，比如点击注释序号，缓缓跳转到注释内容。再看看css禅意花园同样是上面的5个步骤，形成第一版本的css禅意花园而更多的模板提供者所做的工作是交互线稿+视觉设计。体现在网页上就是CSS可以看出从编码角度来讲第一步，内容处理为结构，纯HTML的编写第二步，结构处理为表现，纯CSS的编写第三步，给表现加上行为。从流程的角度来讲第一步，策划文档第二步，结构处理第三步，交互设计(交互样式构建)第四步，视觉设计(视觉样式构建)第五步，样式构建
首先，面对这一问题，我们第一要做的不是去该如何去做，而是要确定企业网站要做成什么样子，我们的目的在于什么?明确了这一点，其他的都不是问题。企业之所以建设网站，肯定是希望网站能给他们带来更多的效益，一般企业也会对网站投入一定的资金，所以，这就变成了营销型、宣传性、推广型的网站了。但一般，企业网站分为两类，一类是进行商品交易的网站，另一类则是企业品牌宣传型网站。前一类可以宽泛点称之为营销型网站，后一类称之为企业官方网站。 营销型网站建设，最主要的就是售卖产品或服务，随着网络科技的发展，人们都热衷于在网上购买产品，再加上现在付款方式多样，大大方面了人们的购物需求。但是这一切利好的条件都不是你一家独享的，而是众多的竞争对手一起“共享”的，地方就那么大，有自己的位子，将越过越好，没有的话，你将一直沉沦。营销型网站，既然是要售卖产品或者服务，那么你肯定是要第一时间将自己的产品特色或者优势服务传递给你的客户，让他们第一时间去了解，去选择你的产品或服务。那么此类的企业网站建设就需要以用户为标准去建设，满足用户需求，以用户需求为导向，潜移默化的引导用户去购买自己的产品，而不是硬生生的将自己的产品直接推送给我们的客户。那么?大家肯定会问，关于用户需求该怎去做呢?其实用户需求很简单，把你自己想象成用户，你需要什么?这样就行了!举个例子：如果你的产品只是针对于儿童，一般情况下，上网搜索我们产品的都是一些成人妈妈或者爸爸，他们对这些产品会有什么看法，再或者是小孩的爷爷奶奶他们会关心产品的哪些方面。爸爸妈妈可能会更关心对孩子未来的成长，能不能增量记忆力，操作能力，抵抗力等等很多方面，而小孩子的爷爷奶奶可能会更关心价格方面(当然这是我的想法，仅作参考)，爷爷奶奶一般都不舍得花钱，尽管是自己的孙子，但一听说这件玩具花了几百上千元，没玩几天就不玩了，不免觉得太可惜了!当然还有其他的人，可能会对送这件产品合不合适，有没有什么危害或者有什么注意事项等等感兴趣。你把这些问题解决好了，自然而言会有源源不断的流量资源，这就是满足用户需求!满足用户需求，需要结合SEO优化和SEM推广，这两项可以根据不同的企业需求去做调整，但是满足用户需求，必须要有SEO的优化。企业官方网站，这类网站比较特殊，没有什么特别的需求，唯一的需求就是展示，所以同行业也叫作展示型网站，制作较为简单，无论是模板框架，还是后台功能制作都是比较简易，方便操作，这类网站管理起来，也不需要什么特别的人才，一般只需要向网站制作公司简单学习一下，就可以了。企业官方网站值得一提的是页面的效果上面，做的非常棒，气势磅礴，栩栩如生，惟妙惟肖，让人流连忘返，陶醉其中。企业网站怎么建设，看你的定位了，做成营销型网站，就要重视用户体验，做成展示型网站，就要注重页面效果，你可以根据你的用户去做选择，如果你的产品是针对高精尖人群，那么展示型网站比较适合你，如果你做大众化的产品，那么营销型的网站比较适合你。
初期架构选型在2010年10月真正开始动手做知乎这个产品时，包含李申申在内，最初只有两位工程师；到2010年12月份上线时，工程师是四个。知乎的主力开发语言是Python。因为Python简单且强大，能够快速上手，开发效率高，而且社区活跃，团队成员也比较喜欢。知乎使用的是Tornado框架。因为它支持异步，很适合做实时comet应用，而且简单轻量，学习成本低，再就是有FriendFeed的成熟案例，Facebook的社区支持。知乎的产品有个特性，就是希望跟浏览器端建立一个长连接，便于实时推送Feed和通知，所以Tornado比较合适。最初整个团队的精力全部放在产品功能的开发上，而其他方面，基本上能节约时间、能省的都用最简单的方法来解决，当然这在后期也带来了一些问题。最初的想法是用云主机，节省成本。知乎的第一台服务器是512MB内存的Linode主机。但是网站上线后，内测受欢迎程度超出预期，很多用户反馈网站很慢。跨国网络延迟比想象的要大，特别是国内的网络不均衡，全国各地用户访问的情况都不太一样。这个问题，再加上当时要做域名备案，知乎又回到了自己买机器找机房的老路上。买了机器、找了机房之后又遇到了新的问题，服务经常宕掉。当时服务商的机器内存总是出问题，动不动就重启。终于有一次机器宕掉起不来了，这时知乎就做了Web和数据库的高可用。创业就是这样一个情况，永远不知道明早醒来的时候会面临什么样的问题。这是当时那个阶段的架构图，Web和数据库都做了主从。当时的图片服务托管在又拍云上。除了主从，为了性能更好还做了读写分离。为解决同步问题，又添加了一个服务器来跑离线脚本，避免对线上服务造成响应延迟。另外，为改进内网的吞吐量延迟，还更换了设备，使整个内网的吞吐量翻了20倍。在2011年上半年时，知乎对Redis已经很依赖。除了最开始的队列、搜索在用，后来像Cache也开始使用，单机存储成为瓶颈，所以引入了分片，同时做了一致性。知乎团队是一个很相信工具的团队，相信工具可以提升效率。工具其实是一个过程，工具并没有所谓的最好的工具，只有最适合的工具。而且它是在整个过程中，随着整个状态的变化、环境的变化在不断发生变化的。知乎自己开发或使用过的工具包括Profiling（函数级追踪请求，分析调优）、Werkzeug（方便调试的工具）、Puppet（配置管理）和Shipit（一键上线或回滚）等。日志系统知乎最初是邀请制的，2011年下半年，知乎上线了申请注册，没有邀请码的用户也可以通过填写一些资料申请注册知乎。用户量又上了一个台阶，这时就有了一些发广告的账户，需要扫除广告。日志系统的需求提上日程。这个日志系统必须支持分布式收集、集中存储、实时、可订阅和简单等特性。当时调研了一些开源系统，比如Scribe总体不错，但是不支持订阅。Kafka是Scala开发的，但是团队在Scala方面积累较少，Flume也是类似，而且比较重。所以开发团队选择了自己开发一个日志系统——Kids（KidsIsDataStream）。顾名思义，Kids是用来汇集各种数据流的。Kids参考了Scribe的思路。Kdis在每台服务器上可以配置成Agent或Server。Agent直接接受来自应用的消息，把消息汇集之后，可以打给下一个Agent或者直接打给中心Server。订阅日志时，可以从Server上获取，也可以从中心节点的一些Agent上获取。具体细节如下图所示：知乎还基于Kids做了一个Web小工具（KidsExplorer），支持实时看线上日志，现在已经成为调试线上问题最主要的工具。Kids已经开源，放到了Github上。事件驱动的架构知乎这个产品有一个特点，最早在添加一个答案后，后续的操作其实只有更新通知、更新动态。但是随着整个功能的增加，又多出了一些更新索引、更新计数、内容审查等操作，后续操作五花八门。如果按照传统方式，维护逻辑会越来越庞大，维护性也会非常差。这种场景很适合事件驱动方式，所以开发团队对整个架构做了调整，做了事件驱动的架构。这时首先需要的是一个消息队列，它应该可以获取到各种各样的事件，而且对一致性有很高的要求。针对这个需求，知乎开发了一个叫Sink的小工具。它拿到消息后，先做本地的保存、持久化，然后再把消息分发出去。如果那台机器挂掉了，重启时可以完整恢复，确保消息不会丢失。然后它通过Miller开发框架，把消息放到任务队列。Sink更像是串行消息订阅服务，但任务需要并行化处理，Beanstalkd就派上了用场，由其对任务进行全周期管理。架构如下图所示：举例而言，如果现在有用户回答了问题，首先系统会把问题写到MySQL里面，把消息塞到Sink，然后把问题返回给用户。Sink通过Miller把任务发给Beanstalkd，Worker自己可以找到任务并处理。最开始上线时，每秒钟有10个消息，然后有70个任务产生。现在每秒钟有100个事件，有1500个任务产生，就是通过现在的事件驱动架构支撑的。页面渲染优化知乎在2013年时每天有上百万的PV，页面渲染其实是计算密集型的，另外因为要获取数据，所以也有IO密集型的特点。这时开发团队就对页面进行了组件化，还升级了数据获取机制。知乎按照整个页面组件树的结构，自上而下分层地获取数据，当上层的数据已经获取了，下层的数据就不需要再下去了，有几层基本上就有几次数据获取。结合这个思路，知乎自己做了一套模板渲染开发框架——ZhihuNode。经历了一系列改进之后，页面的性能大幅度提升。问题页面从500ms减少到150ms，Feed页面从1s减少到600ms。面向服务的架构（SOA）随着知乎的功能越来越庞杂，整个系统也越来越大。知乎是怎么做的服务化呢？首先需要一个最基本的RPC框架，RPC框架也经历了好几版演进。第一版是Wish，它是一个严格定义序列化的模型。传输层用到了STP，这是自己写的很简单的传输协议，跑在TCP上。一开始用的还不错，因为一开始只写了一两个服务。但是随着服务增多，一些问题开始出现，首先是ProtocolBuffer会生成一些描述代码，很冗长，放到整个库里显得很丑陋。另外严格的定义使其不便使用。这时有位工程师开发了新的RPC框架——Snow。它使用简单的JSON做数据序列化。但是松散的数据定义面对的问题是，比如说服务要去升级，要改写数据结构，很难知道有哪几个服务在使用，也很难通知它们，往往错误就发生了。于是又出了第三个RPC框架，写RPC框架的工程师，希望结合前面两个框架的特点，首先保持Snow简单，其次需要相对严格的序列化协议。这一版本引入了ApacheAvro。同时加入了特别的机制，在传输层和序列化协议这一层都做成了可插拔的方式，既可以用JSON，也可以用Avro，传输层可以用STP，也可以用二进制协议。再就是搭了一个服务注册发现，只需要简单的定义服务的名字就可以找到服务在哪台机器上。同时，知乎也有相应的调优的工具，基于Zipkin开发了自己的Tracing系统。按照调用关系，知乎的服务分成了3层：聚合层、内容层和基础层。按属性又可以分成3类：数据服务、逻辑服务和通道服务。数据服务主要是一些要做特殊数据类型的存储，比如图片服务。逻辑服务更多的是CPU密集、计算密集的操作，比如答案格式的定义、解析等。通道服务的特点是没有存储，更多是做一个转发，比如说Sink。这是引入服务化之后整体的架构。而目前在产品方面，知乎保留着以下几个重点：1.基础模块（1问题-n回答-n评论模块）知乎基础模块中一个问题对应于n个回答，一个回答又对应于n个评论，因此我们可以把基础模块称为1问题-n回答-n评论模块。假设知乎架构模型中仅存在基础模块，将会是一个怎样的场景？那就是信息流随着时间的推移不断生成新的内容并把旧信息快速替换冲刷掉，这种对基础模块无差别的线性陈列，对用户来说将是一个灾难：在简单罗列的线性信息海洋中，用户汲取其所需信息的成本太高；信息流如同大河奔流，那些有挖掘价值的信息点稍纵即逝，即信息价值被严重挥霍；用户不能将有价值的信息点从信息大河里“舀”出来，信息可见而不可用，无法产生长效作用。知乎的产品设计者很好地意识到了这些潜在的“灾难”，并对每个问题点做出了针对性的产品设计方案，下面木柄逐一展开分析。2.话题模块话题模块用来解决“在线性简单罗列的信息海洋中，用户汲取所需信息的成本太高”的问题。知乎中，每一个基础模块（1问题-n回答-n评论模块）可以添加“话题”标识，“话题”描述了基础模块的“类别”，话题模块与基础模块是多对多的映射关系（many2many）。事实上，为内容添加“标识”的做法在以内容为核心的网站的组织架构模型中屡见不鲜，很多网站将这种“标识”称为标签（比如lofter）。但是知乎的话题比普通网站的标签走的更远：知乎的各个话题之间不像标签那样是孤立的，它定义了一套将话题组织起来的数据结构。请注意，话题本身就是对基础模块的一种组织形式，而又存在一套数据结构描述了话题的组织形式，那么我们可以将这种数据结构称作“描述结构组织的结构组织”，知乎自己是这么介绍这个“描述结构组织的结构组织”：知乎的全部话题通过父子关系构成一个有根无循环的有向图；根话题即为所有话题的最上层的父话题；请不要在问题上直接绑定根话题。3.发现模块发现模块解决了信息流如同大河奔流，那些有挖掘价值的信息点稍纵即逝，即信息价值被严重挥霍的问题。发现模块主要有两部分内容组成：推荐与热门。热门内容是由用户群体行为所做出来的“内容精选”，而推荐内容是知乎运营人员对“群体行为”的补充完善，最大程度地让有价值的信息减缓流速，或者二次“逆流”，目的就是让有价值的信息得以“上浮”与“驻留”。此外值得一提的是，如果说发现模块是构筑在知乎基础模块上的信息“驻留模块”,那么话题模块也有一个针对其信息的“驻留模块”——“话题精华模块”。发现模块是挖掘全局的有价值的信息，而“话题精华模块”挖掘的是该话题的有价值的信息，从而使有价值的信息在不同的组织维度上得到“驻留”，而不被浩大的信息流冲的无影无踪。4.收藏模块收藏模块解决了用户不能将有价值的信息点从信息大河里“舀”出来，信息可见而不可用，无法产生长效作用的问题。收藏功能是很多内容为王的网站架构中重要的一环，使用户可以从浩淼的信息流中舀出其感兴趣的那一瓢。知乎的收藏模块支持创建收藏文件夹，即用户可以对收藏内容再组织，存放到相应的收藏文件夹中。此外知乎的收藏模块还走的更远，用户组织的收藏夹可以设置为“公有”状态，并分享给其他用户。也就是用户的利己行为（收藏自己感兴趣或者有帮助的内容），产生了利他的效果（其他用户也能看到由别人的收藏夹并从中获益）。从内容组织角度上来说，知乎的收藏夹不但提供了将信息“舀”出保存的作用，而且也起到将优质信息“驻留”与“上浮”的作用。5.知乎日报模块知乎日报模块是一个比较特殊的模块，它并不是知乎的主体模块，你可以将其理解成知乎产品的衍生模块，它事实上也从另外一个角度在解答信息价值被严重挥霍的问题。知乎日报模块与知乎主体模块采用松耦合的架构模式，它是对知乎这个庞大的优质内容生产机器的二次开发。知乎日报采取“日报”的方式，每天对知乎中产生的经典内容做一次组织成刊。知乎日报简单的布局、呈现方式，更加符合人们在移动端的阅读习惯，使那些觉得在移动端使用知乎不方便的用户，或者想在碎片时间里进行阅读的用户，有一个更加贴心的知乎产品可以选择。
豆瓣整个基础架构可以粗略的分为在线和离线两大块。在线的部分和大部分网站类似：前面用LVS做HA，用Nginx做反向代理，形成负载均衡的一层；应用层主要是做运算，将运算结果返回给前面的用户，DAE平台是这两年建起来的，现在大部分豆瓣的应用基本都跑在DAE上面了；应用后面的基础服务也跟其他网站差不多，MySQL、memcached、redis、beanstalkd，不一样的是NoSQL的选择——BeansDB，这是我们在几年前开源的KV数据库，也是国内比较早开源的KV数据库。豆瓣的技术架构与主要组件豆瓣作为一个早期就选择以Python为主要编程语言的公司，网站所使用到的技术很多都与Python相关，包括主要框架quixote、自行实现的DPark等等。在其它技术的选择上，并没有太大不同：nginx、MySQL、memcached、BeansDB、redis……都是知名开源项目。在这些开源项目之上，豆瓣根据自己产品的特性，针对性地做了配置与部署设置。除了使用开源项目，豆瓣也根据自身需要自主研发或实现了一些产品，比较有特色的如DAE、DPark等等。DAE全名DoubanApplicationEngine，顾名思义它是一个类似于GAE、SAE的内部PaaS系统。使用这样的PaaS有很多好处，比如第三方库数量丰富并且支持多个版本并存、资源配置灵活等等，能够为工程师省去很多不必要的工作。BeansDB是DAE中非常重要的一个组件，设计思想源于亚马逊的Dynamo，但是简化了Dynamo的一些复杂之处。BeansDB主要应用于小型文本和中型的图片、音频，它们的共同特点在于写次数特别少，这也正是BeansDB所擅长的领域。DPark类似于Spark，是豆瓣用Python实现Map-Reduce类似框架。虽然Python的性能低于基于JVM的Clojure，但这样做避免了程序员程序员进入不熟悉的领域，而且豆瓣使用开源项目的原则是：如果无法完全掌握，宁可不用。“此外将Spark移植到Python上也很简单，基本上是一对一的翻译。BeansDB项目可以说是一个简化版的AWSDynamoDB，该项目在2008年启动，2009年开源，第⼀版使⽤tokyocabinet作为存储引擎，2010年使⽤bitcask存储格式重写了存储引擎，性能更好。BeansDB对key做哈希运算找到节点来实现分布和冗余，一个写操作会写好几个节点，而现在的配置是写三份读一份。BeansDB主要的特点是支持海量KV数据库——相比Redis这种支持几十个G到几百个G的内存KV数据库，BeansDB可以支持到上百T的数据。另外BeansDB最大的好处就是运维很简单，性能、可用性、扩容都很好，也实现了最终一致性。BeansDB中间的Proxy是用Go语言写的，也是一个开源的组件。整体来说BeansDB的设计结构比较简单，相比Redis那种有多种value类型的方式，BeansDB的Value比较简单一些。在豆瓣内部建立了两个不同的BeansDB集群，一个是doubandb，一个是doubanfs，分别针对不同的场景。doubandb主要存储小型文本数据，如影评、用户个人介绍、帖子内容等，这样的好处是可以大大降低我们对MySQL的性能依赖，算是给MySQL减负；doubanfs主要存放图片和音频等中型数据。DAE可以说是基于很多以前积累的、旧的组件做起来的。我们做的这种对内的PaaS，相比对外的PaaS而言做了很多简化，尤其是安全方面如应用间隔离、权限管理方面，我们都不用像公有云那样花大量精力去做，所以工作量其实还好。DAE现在在计划开源，当然它现在只支持Python应用。以后我们也许会让DAE支持Go语言。上面是在线的部分，对高可用性和低时延有较大要求。离线部分则包括数据挖掘、数据分析等，技术组件分别是海量分布式文件系统MooseFS，这个文件系统的结构类似HDFS，用C语言编写，其好处在于FUSE模块实现的比较好，用文件系统就可以直接进行操作，而不需要专门的命令，可以支持的数据量也很大。另外就是自己开发的分布式计算平台DPark。DPark顾名思义是Spark的Python实现，不过现在已经跟Spark越来越不一样了。和Hadoop相比，Spark可以使用内存做为缓存加速分布式计算，DPark继承了这个优点，这对于大规模数据的迭代计算非常有用。在豆瓣的应用场景下，因为我们的离线计算很多是推荐算法计算，这种计算涉及大量的迭代算法，如果每次计算的结果都入磁盘再在下一轮计算加载，那性能是很差的，所以DPark能够大幅提升性能。另外，因为DPark的编写使用了函数式语言的特点，所以可以写的非常简洁：
中国互联网举报中心