一 : 广告和推荐系统部署机器学习模型的两种架构

广告和推荐系统是机器学习是最成熟的应用领域。那么广告和推荐系统是怎么在线上部署机器学习模型的呢?

1. 预测函数上线

刚刚学习机器学习时候，我认为广告和推荐系统过程如下图所示：1)线下部分，从用户和广告(物品)属性抽取用户和物品特征，将抽取的特征合并进日志生成训练数据，训练机器学习模型;2)线上部分，来了一个请求，从用户和广告(物品)属性抽取请求中的用户和物品的特征，将这些特征合并请求生成预测实例，用线上模型得到预测结果。

但是这个架构有两个问题：1)从用户和广告(物品)属性抽取特征的程序有线上线下两套，这两套程序必须保持完全一致。但由于调参的原因，特征抽取是机器学习系统中最经常发生变化的模块。经常变化的模块需要保持一致，这很困难。那么我们能不能强行地用一套程序呢?比如，我们把特征抽取和特征处理模块写成 .so 文件。这样也有问题：线下要求快速变化以方便工程师调特征，可能会使用一些训练框架(比如 Spark);线上要求程序快速实时，要求工程师编码严谨。写成严谨的 .so 文件，能够保证线上的需求，但无法快速变化，也不能在 Spark 上使用。2)线上特征抽取要求非常快速，特别在线上吞吐量很大的情况。但有些重度特征不可能在短时间内抽取出来，比如广告的历史点击率(生成这个特征需要遍历一段时间的点击日志)。

在读书期间，这两个问题困扰了我很久, 直到 2014 年我知道了神器 Redis。Redis 是一个开源内存数据库，支持集群模式、持久化和 Key-Value 数据结构。在使用时，我们可以将 Redis 看成一个巨大的哈希表。Redis 在后台开发中经常用作 cache 服务器, 后来被工程师们用于广告和推荐系统中的特征服务器。工程师将用户和广告(物品)的 ID 作为 Key，将用户和广告(物品)的特征作为 Value 存入 Redis，这样线上程序只需要用户和广告(物品)的 ID 就能知道特征。引入 Redis 之后，广告和推荐系统过程如下所示：1)线下部分，从用户和广告(物品)属性抽取用户和广告(物品)特征，把抽取的特征合并进日志生成训练数据用于训练机，并把抽取的特征上载到线上 Redis 服务器;2)线上部分，来了一个请求，从 Redis 服务器取出用户和广告(物品)特征，将特征合并进请求生成预测实例，用线上模型得到预测结果。

这种架构还有一个变种：在线下抽取特征之后不生成训练数据而是直接送到 Redis，在线上用 Storm 实时拼接训练数据。但我对这个变种的前因后果不太了解，就不展开讨论了。这种架构将预测函数(也就是训练出来的模型)部署在线上。为了和下面的架构区分开来，我们将这种架构称为预测函数上线架构。

2. 预测结果上线

了解预测函数上线架构之后，我将之作为广告和推荐系统线上部署模型的 “正统”。 因此当 2014 年我接触到另一种架构时，我内心是拒绝的。这种架构的要点在于把预测结果上线，具体过程如下所示：1)在线上，从用户和广告(物品)属性抽取用户和物品特征，将抽取的特征合并进日志生成训练数据，训练机器学习模型;将几乎所有可能的请求合并特征，进而生成预测实例，用模型得到预测结果;2)线上就很简单了，接入线下传过来的预测结果。这里稍微难理解的是 “穷尽几乎所有可能的请求”，疑惑那么多可能的请求怎么可能穷尽呢?微博广告系统(虚构的)所有可能的请求貌似很多，但每个用户只需要匹配若干个广告就行了。因此微博广告系统的预测结果 “userid,adid1,adid2...,adidn” 上载到线上，一旦线上传一个 userid 请求展示广告，线上模块就按照一定的逻辑返回预测结果中这个用户对应的广告。这种架构是将预测结果部署到线上，我们将之称为预测结果上线架构。

慢慢地我也开始明白预测结果上线的好处了。预测结果上线架构将机器学习全过程和绝大部分控制逻辑都搬到线下，规避了线上的各种隐患。这样不那么厉害的工程师用不那么厉害的机器也能搞定线上模块了，毕竟线上模块只需要实现少量的控制逻辑和展示。这大大降低了建立一个广告系统或者推荐系统的难度。

我正式工作之后，组里支持运营活动的推荐系统采用了预测结果上线的架构。我发现有不少时间浪费在重跑数据上，原因在于有时需要临时增加或者删除物品。一旦增加或者删除物品，预测结果上线的推荐系统就需要重新生成预测数据(因此之前跑的数据要么没有要加的物品，要么有要删的数据)。另外一个问题就是预测结果上线架构有延时性：今天线上展示的是昨天准备的预测结果，今天准备的预测结果要等明天才能展示，这会导致节奏慢一些。最后还有一个问题，预测结果上线架构只适用于几乎所有可能的请求能够穷尽的场景。比如，预测结果上线架构不适用于搜索广告系统，因为搜索广告系统不能穷尽所有可能的请求。

3. 总结

预测函数上线架构能够覆盖预测结果上线架构的适用场景，但是预测结果上线架构不能够覆盖预测函数上线架构的适用场景。同时预测函数上线架构更具灵活性。预测函数上线架构不愧为部署机器学习模型的 “堂堂正正” 之法。

预测结果上线架构的好处就是难度比较低。预测结果上线架构将机器学习全过程和绝大部分控制逻辑，规避了线上的各种隐患。在机器、时间和人力等各种条件不充足的情况，预测结果上线架构不失为一个好的选择。预测结果上线架构是 “剑走偏锋” 的机器学习模型部署之法。兵法有云：以正合以奇胜，选择哪一种架构还是需要仔细的分析和权衡。

【本文为51CTO专栏作者“李立”的原创稿件，转载请通过51CTO获取联系和授权】

戳这里，看该作者更多好文

 

二 : XXX公司网站集群系统架构及建设思路

XXX公司网站集群系统架构及建设思路

拟稿人：水滴

日期：2011年X月XX日

网站集群系统 XXX公司网站集群系统架构及建设思路

XXX公司网站集群系统架构及建设思路

企业网站建设作为企业建设的一部分，必将受企业文化、发展理念、企业定位等诸多因素制约和影响，并时时体现和折射出上述因素。［www.61k.com)随着企业发展的不断壮大，电子商务应用的日趋成熟，企业网站建设在企业整体建设中的地位,也将更加突出，因为网络平台所能带给企业的高效收益,是传统业务平台所无法实现和相比的。

XXX公司是专业的体育产业整合、策划、推广、商业运作公司。以XX为核心项目；以打造产业链为目标；以树立标准、引领行业发展为己任。XXX，不仅是一家体育品牌运营机构，同时也是健康生活方式的传播者和推动者，更是民族精神和文化精粹的承载者和发扬者。

公司的发展、业务的拓展离不开资源整合，网络平台是资源整合的有力工具，可以高效的整合各类资源。而资源整合过程中需要考虑各种相关要素，即要突显企业商业品牌，又要承载民族文化；即有商业的，又有民间的；同时企业线下业务的拓展，也要求公司线上网络平台给予强有力的辅助和支持。以上种种，都意味着，公司原一站式的传统网络布局很难满足企业未来发展不断增长的需求，新的系统的企业网络平台的构架及建设正当其时,网站集群技术与相关系统的应用提上日程中来。

一、技术分析

1．网站集群技术的产生

网站集群,简单的说就是一群能够进行数据共享与呈送的相互关联的网站集合。

当今，很多网站在建立时，相互独立，采用的是各自不同的技术构架体系，在建立门户网站消除信息孤岛的同时，我们也在不断建立着新的信息孤岛。实现部署在不同服务器上的，相互独立的网站间互联互通，是目前网站集群建设的难 - 1 -

网站集群系统 XXX公司网站集群系统架构及建设思路

点，也是迫切需要解决的课题，网站集群技术从而产生。(www.61k.com)

2．网站集群技术的发展

网站集群技术早期是从CMS发展而来，作为CMS内容管理系统的一种扩展，可以实现单站到多站点的管理；数据的存储模式自然的选择了集中存储的模式，即多站点的信息统一存储到一个库、表中，通过标记进行区分。这样的模式，使得产品从CMS升级到网站集群的成本降低，也为早期快速满足用户的需求做出了贡献。

在网站集群逐步走向成熟的过程中，用户不断增长的需求对第一代网站集群技术提出了挑战：

? 网站集群中新并入的站点数量越来越多，数据流量越来越大，单数据库

存储模式已成为整个平台访问速度提高的瓶颈；

? 网站互动功能的要求越来越高，原先整个网站全部生成静态网页的模式

越来越不可用；

? 单站点在不断成长，个性化的要求越来越高，并伴有很多不断衍生的扩

展性定制需求；

? 用户希望现有的或新并入的网站也可以集成到网站集群里。

这些日益强烈的需求推动了网站集群技术的进一步发展,形成了第二代网站集群技术，主要标志有：

? 每个站点的数据库独立、文件系统独立、应用独立，从而降低因对个别

站点的高度依赖而带来的整个网站集群大面积崩溃的风险；

? 使用LDAP(Lightweight Directory Access Protocol) 轻量目录访问协

议技术建立全局的用户体系，使用户体系更加开放和可扩展；如论坛、博客、SNS(Social Network Site)等系统通过LDAP技术均可实现SSO(Single Sign On)单点登录；

? 信息资源的共享采用独立的信息交换平台进行统一管理，实现信息的采 - 2 -

网站集群系统 XXX公司网站集群系统架构及建设思路

集、整合、传递、共享等操作。[www.61k.com]

3．现存网站集群的主要问题

? 众多的网站样式各异、域名不统一、VI（Visual Identity）不统一、质量

参差不齐、管理杂乱无章；

? 一些已过时的项目网站仍然存在，长期不更新，已经成为睡眠网站；

? 网站功能仍停留在品牌展示、产品展示、新闻发布等橱窗式功能上，无法满

足对外实际业务需求。

4．原因分析及解决方案

究其原因主要是：缺乏统一的网站集群规范；缺乏策略规划指导下的全盘规划与分步实施；管理制度及考核监督机制缺失。运用新一代的网站集群技术构建全新的系统管理平台将可有效解决上述问题。

二、我司采用网站集群技术搭建和运营行业网络平台的好处。

1、有利于组建行业网站，抢占行业发展制高点。

从2002年到2009年，国内行业B2B电子商务网站数量持续高速增长。2011年行业网站数在2月成功突破2万大关，截至到3月末，全国电子商务行业网站数达到2.17万家，相比去年同期增长了31.16%，组建行业网站成为企业网络建设热点。

相对于大型企业而言，中小型企业，特别是创新型企业无论在人力、财力、品牌影响力以及技术实力等方面都相对较弱，要想把握住网络时代带来的机遇，深入细化整合行业资源，打造上下游产业链,搭建行业网站平台是个不容错过的 商机。凭借专业和资源上的优势，抢占行业发展制高点，有利于提升公司品牌形象，也有利于拓展公司业务,挖掘企业新的增值潜力。

对我司而言，传统的单一型、宣传式网站已无法跟上企业快速发展的步伐,行业网站平台搭建机不可失，我司应尽早组建，运营专业的柔力球行业垂直型门户网站，集中力量打造专业的网络信息平台，推进本行业信息流转和资 源整合，并按照市场经济规则推进行业平台的建设和发展，产生有XXX特 - 3 -

网站集群系统 XXX公司网站集群系统架构及建设思路

色的服务内容和盈利模式，为企业带来更多的增值服务利润，迅速提升企业在行业内的核心和领导地位。（www.61k.com）

行业网站平台的搭建和发展必然会产生网站集群，网站集群技术的合理利用则必不可少。

2、全盘规划才能分步实施。

网站的建设离不开总体规划，系统策划，只有把握大局才会少走弯路， 节约成本，提高平台整体效率。尽管目前公司的网站建设还处于起步阶段，但也要尽量做到全盘着眼，分步落实，切不可盲目发展，毫无统筹。

扩展：秒杀系统架构优化思路 / linux系统集群架构师 / 系统集群架构师

3、在保证网站效果的前提下，可以大幅度降低网站建设的资金投入。

用网站集群的眼光和思路搭建公司网络平台，使公司整个网络建设成为一个系统。采用先进的网站集群技术和管理系统，使得平台中大量结点网站的建设轻松快捷，即有模板可依，又可个性化定制，从整体和长远看，能为公司节约大量人力和财力，即降低了企业资金投入，又加快了整体的网络建设速度。

4、更有利于各平台信息资源的整合与共享。

公司网络平台建设采用网站集群技术，利用网站集群管理系统，使企业资源整合变得轻松和高效。真正做到平台统一接口，结点间无缝对接，产品、人力、市场、技术、民族文化等各类资源得到高效的整合与利用。

5、通过运营能够产生极大价值。

以网站集群模式运营公司网络平台，纵深整合网络资源，吸引行业内产业链条上大量业内企业及相关组织加盟到这个蓬勃发展的网络平台中来,通过满足用户和市场的多样化需求、增加用户对公司和产品的信赖度，必将会产生有XXX特色的服务内容和盈利模式，为企业带来更多的增值利润，跳出传统企业范畴，进军到现代企业争相发展的B2B与B2C有机结合的行业电子商务平台中来，通过网络平台的建设与运营，创造新的价值，完善企业综合实力，提高行业竞争力。

三、 架构

- 4 -

网站集群系统 XXX公司网站集群系统架构及建设思路

1．

行业网站群图解

如上图，网络平台的搭建一定要有预见性，随着公司的发展，平台的扩建和延伸必不可少，这就要做到全盘规划，分步实施。［www.61k.com］

2． 常见的网站群架构模型:

常见的站群总体架构模式:

- 5 -

网站集群系统 XXX公司网站集群系统架构及建设思路

3.我司网站群系统构架设计图

如上图，本系统构架设计，在业务应用层上，能实现公司实际业务的协同共进，即重点考虑了国内市场上的业务拓展，又兼顾了海外市场可挖掘的巨大潜力，即有商场上市场的开拓与抢占，又有民族精神与传统文化的发扬与传播；在系统底层数据接口上，实现了各网站集群结点子系统间的无缝对接，打造与完善公司网络集群系统综合数据库。[www.61k.com］对公司现有网上办公平台OA系统的对接与新工作界面的应用、企业呼叫中心系统的建设及与新网络平台的结合等，都体现了技术应用与实际业务的协调统一。

- 6 -

网站集群系统 XXX公司网站集群系统架构及建设思路

四、 实施分析

1. 明确衡量网站集群的关键指标

(1)外显性指标

? 站内单点登录

? 统一网站搜索

? 一站式受理服务

? 相对统一的界面设计和风格

(2)内在性指标

? 网站集群之间的信息复用程度

? 成熟统一的技术、管理和制度

? 基于网站集群的绩效考核和评测规则

? 相对一致的网站运行和服务规范

2. 采用合适的途径并入结点组建网站集群

网站集群结点的并入通常有二种途径，一种是以投资或并购模式吞并现有的业内大型专业网站，另一种是以分站，分公司，办事处，连锁俱乐部、加盟培训中心等方式吸引并入的他建或平台通过提供自助建站服务而形成的本行业内的所有相关专业网站。［www.61k.com)后者为目前我司主要采用模式。互惠共赢的经济运作方式必将大大推进相关业务的发展速度，并形成规模效益。

3. 一些常见的行业网站群盈利模式

除了直接产品收益外，相对更精、更专、更细的服务，也能成为平台运营的盈利点，即专业的服务在公司平台上也必将是一种可获利的商品。另外，高级会员，重点广告位、排名位，培训，赛事报名，技术指导，企业网络服务，展会举办，自主营销，贸易撮合，短信服务，杂志出版等等，都有可能成为平台发展壮大后的闪光盈利点。

- 7 -

网站集群系统 XXX公司网站集群系统架构及建设思路

4. 网站集群统一权限管理系统框架

? 总站可对集群内各站点实时管理，可对任意一级站点进行启用、暂停、请出

网站集群、纳入网站集群等。(www.61k.com）

? 总站将默认提供网站集群内建立过互信关系的站点进行统一登录的身份校验

功能，通过此登录校验后可以通过集群内漫游入口，进行集群内任意互信站点的访问与管理工作。

? 总站还拥有对网站集群管理人员的管理工作。对网站集群功能的设臵与管理

将由网站集群管理人员进行，网站集群管理人员分为两类人员，站群总管、站群辅管；站群总管默认为总站系统管理员；站群辅管由站群总管指定的其他站点系统管理员担任。

? 集群内站点的互信管理。站群总管即可以对网站集群内各站点是否可以进行

互信建立进行审批或直接建立，站群辅管主要对总管的工作进行辅助与协作，分解总管的工作量。

? 互信管理中的权限识别，在群内的互信建立过程中权限问题将会主要由站群

辅管进行全面的建设与设定。

5. 信息共享模式

? 广播式共享

对于广播式共享业务,提供对下级站点的无条件的数据共享广播与推送服务（此类共享的任何数据信息包括产品、资讯、新闻、广告、通知等，需统一即时发布于任何下级站点）。

? 点播式共享

对于点播式共享,其与任意级别站点相同，可提供任意格式的数据信息的共享，供其他群内任意站点订阅与应用。

? 数据共享

数据共享模式分为两大类，其一是热链式应用，其二是仓储式应用；热链式

- 8 -

网站集群系统 XXX公司网站集群系统架构及建设思路

扩展：秒杀系统架构优化思路 / linux系统集群架构师 / 系统集群架构师

应用是指数据共享提供者只提供此类数据的一些链接参数，而不对数据本身提供给对方去存储与应用；仓储式应用,主要是指数据共享提供者,直接提供此类数据给对方去存储并且应用。（www.61k.com)

? 推送式共享

推送式共享是指总站分配给具有推送共享权限的站点，可以将某些数据推荐给他的上级站点，通过上级站点审批后可直接应用于上级某推送频道。 6. 子站的独立性与个性化展现

从根本上讲，子站本身就是个独立的网站，是一个独立系统，未来维护与升级可以完全按照独立系统进行；当然前提是数据框架是在整个集群管理体系中。我们可以在每一个独立的系统中进一步集成和外挂更多的其他应用或模块，而丝毫不会影响整个系统的运行。各子站允许完全个性化设计，但也要体现统一标识，总站提供数量众多的模板组，供子站选择使用；同时，提供工具允许各子站自行设计模板，并可提交服务器共享给其他子站。

6. 几个可供企业选择和参考的网站集群系统产品及成功案例

系统软件供应商：

- 9 -

网站集群系统 XXX公司网站集群系统架构及建设思路

8．分布实施计划

? 商定网络平台系统策划案。［www.61k.com］

? 确立系统开发及运营管理团队。确定核心商务产品及相应定制程序开发模

式。建议采用成型的商业系统并直接购买相应的定制服务，并派专业团队协助实现完整的定制开发与综合调试，确保技术应用与业务实现的和协统一。 ? 开发总站，要求所有程序代码均采用UTF-8国际代码标准并经SEO技术优化

处理，为平台国际化运作和后期推广运营，打下坚实基础。

? 开发总站下各主站模块(俱乐部模块、赛事平台模块、国际论坛模块、电子

商城模块等)，前期各主站数据量不大的情况下，考虑降低企业资金投入，各主站可先以子站的形式存在于总站之下,一旦业务猛增，数据量过大，随时可以独立出来，单独运营。另外电子商务平台主站的安全性要格外注意。俱乐部主站和综合论坛主站，对高级会员也要开放DIY博客功能。

? 开发公司下属各分站模块，创建系列模板可供下属公司选用，提供自助建站

功能，关联分站与各主站间对应接口，同样各分站也要做好将来升级独立运营的规划。

? 开发合作网站相关接口，确定相关权限，使相应信息采集和发布功能通行无

误。

? 开发公司网络平台与OA系统相关接口，完善并设臵OA系统实用工作界面。 ? 开发CALL CENTER呼叫中心系统，并实现与网络平台的无缝对接，并确立相

关维护与管理人员。

? 购买商用服务器，确定主机托管事宜，搭建网络系统硬件平台。 ? 上传系统，做好综合测试,正式开始运营。

? 网站推广及相关后期维护与二次开发等。

五、 过渡期XXX老网站维护与二次开发计划

- 10 -

网站集群系统 XXX公司网站集群系统架构及建设思路

1. 目的

为满足公司业务进展中急需网络平台支持的紧急业务需要，及相应长远规划，而临时实施的网络建设任务。［www.61k.com］

2. 功能

公司对外展示性、宣传性的形象类工程的建设与完善，紧急应用类的中小型功能模块的定制与开发

3. 优点

资金投入小，可按需定制，反应相对讯速。

4. 缺点

受原系统框架束缚，只能做小范围功能增删动作，无法做大的系统级的调整。 与其他网站接口对接和资源整合相对难度较大，效率不高。缺乏系统性统一规划，容易产生无用作业，长期看，易造成阶段性资源浪费。

5. 实施计划

? 完善公司产品库

? 整理视频库、文章库

? 完善网站在线订购模块

? 开发和设计网站系列模板组，以满足不同时期企业对网站风格的要求。 ? 根据网站运营情况，实时维护与增加相应紧急辅助功能模块。

六、网络集群系统应用前后对比

1．功能上

应用前，原网络平台是单一型、孤立的信息发布与企业展示型站点，功能简单；应用后，新网络平台是系统化、综合型的大型行业门户集群网络平台，即对接了OA系统，又打造了企业呼叫中心系统，功能上要先进和复杂的多。

- 11 -

网站集群系统 XXX公司网站集群系统架构及建设思路

2．价值上

应用前，原网络平台的价值体现为广告与宣传作用；应用后，新网络平台的价值体现为企业综合数据库的完善与应用，企业新业务增长点的拓展与实现，是企业提高自身价值的重要元素。（www.61k.com)

3、意义上

应用前，原网络平台只是普通企业常规建设中的简单一环；应用后，新平台是现代新型、创新型企业抢占行业发展制高点与把握时代新商机的综合体现。

水滴

- 12 -

扩展：秒杀系统架构优化思路 / linux系统集群架构师 / 系统集群架构师

三 : 大型网站系统架构的演化

前言

一个成熟的大型网站(如淘宝、京东等)的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性，它总是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随业务扩展而完善出来的，并不是一蹴而就;不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿的用户实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段可以广泛运行在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。

一、最开始的网站架构

最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图：

二、应用、数据、文件分离

随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。

三、利用缓存改善网站性能

在硬件优化性能的同时，同时也通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则(即80%的访问请求，最终落在20%的数据上)，所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。

缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等，这个后面再讲。本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，OSCache就是常用的本地缓存组件。本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。

四、使用集群改善应用服务器性能

应用服务器作为网站的入口，会承担大量的请求，我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求，根据分发策略将请求分发到多个应用服务器节点。

常用的负载均衡技术硬件的有F5，价格比较贵，软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡，根据目标地址和端口选择内部服务器，Nginx是七层负载均衡和HAProxy支持四层、七层负载均衡，可以根据报文内容选择内部服务器，因此LVS分发路径优于Nginx和HAProxy，性能要高些，而Nginx和HAProxy则更具配置性，如可以用来做动静分离(根据请求报文特征，选择静态资源服务器还是应用服务器)。

五、数据库读写分离和分库分表

随着用户量的增加，数据库成为最大的瓶颈，改善数据库性能常用的手段是进行读写分离以及分表，读写分离顾名思义就是将数据库分为读库和写库，通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分，水平切换则是对一个数据库特大的表进行拆分，例如用户表。垂直切分则是根据业务不同来切换，如用户业务、商品业务相关的表放在不同的数据库中。

六(www.61k.com]、使用CDN和反向代理提高网站性能

假如我们的服务器都部署在成都的机房，对于四川的用户来说访问是较快的，而对于北京的用户访问是较慢的，这是由于四川和北京分别属于电信和联通的不同发达地区，北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器，返回路径也一样，所以数据传输时间比较长。对于这种情况，常常使用CDN解决，CDN将数据内容缓存到运营商的机房，用户访问时先从最近的运营商获取数据，这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。

而反向代理，则是部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有没有缓存数据才会继续走应用服务器获取，也减少了获取数据的成本。反向代理有Squid，Nginx。

七、使用分布式文件系统

用户一天天增加，业务量越来越大，产生的文件越来越多，单台的文件服务器已经不能满足需求。需要分布式的文件系统支撑。常用的分布式文件系统有NFS。

八、使用NoSql和搜索引擎

对于海量数据的查询，我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb和redis，搜索引擎有lucene。

九、将应用服务器进行业务拆分

随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者同享数据库来实现。

十、搭建分布式服务

这时我们发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。淘宝的Dubbo是一个不错的选择。

小结

大型网站的架构是根据业务需求不断完善的，根据不同的业务特征会做特定的设计和考虑，本文只是讲述一个常规大型网站会涉及的一些技术和手段。

本文作者:李平;转载自：飘扬的红领巾

本文标题：大型网站系统架构-广告和推荐系统部署机器学习模型的两种架构
本文地址： http://www.61k.com/1152120.html