每秒处理10万订单乐视集团支付架构
&&&&您可以捐助，支持我们的公益事业。
每天15篇文章
不仅获得谋生技能
更可以追随信仰
每秒处理10万订单乐视集团支付架构
作者：梁阳鹤 &来源：CSDN 发布于：&
859 次浏览
&&&&评价：
随着乐视硬件抢购的不断升级，乐视集团支付面临的请求压力百倍乃至千倍的暴增。作为商品购买的最后一环，保证用户快速稳定的完成支付尤为重要。所以在15年11月，我们对整个支付系统进行了全面的架构升级，使之具备了每秒稳定处理10万订单的能力。为乐视生态各种形式的抢购秒杀活动提供了强有力的支撑。
一、库分表
在redis，memcached等缓存系统盛行的互联网时代，构建一个支撑每秒十万只读的系统并不复杂，无非是通过一致性哈希扩展缓存节点，水平扩展web服务器等。支付系统要处理每秒十万笔订单，需要的是每秒数十万的数据库更新操作（insert加update），这在任何一个独立数据库上都是不可能完成的任务，所以我们首先要做的是对订单表（简称order）进行分库与分表。
在进行数据库操作时，一般都会有用户ID（简称uid）字段，所以我们选择以uid进行分库分表。
分库策略我们选择了&二叉树分库&，所谓&二叉树分库&指的是：我们在进行数据库扩容时，都是以2的倍数进行扩容。比如：1台扩容到2台，2台扩容到4台，4台扩容到8台，以此类推。这种分库方式的好处是，我们在进行扩容时，只需DBA进行表级的数据同步，而不需要自己写脚本进行行级数据同步。
光是有分库是不够的，经过持续压力测试我们发现，在同一数据库中，对多个表进行并发更新的效率要远远大于对一个表进行并发更新，所以我们在每个分库中都将order表拆分成10份：order_0，order_1，&.，order_9。
最后我们把order表放在了8个分库中（编号1到8，分别对应DB1到DB8），每个分库中10个分表（编号0到9，分别对应order_0到order_9），部署结构如下图所示：
根据uid计算数据库编号：
数据库编号 = (uid / 10) % 8 + 1
根据uid计算表编号：
表编号 = uid % 10
当uid=9527时，根据上面的算法，其实是把uid分成了两部分952和7，其中952模8加1等于1为数据库编号，而7则为表编号。所以uid=9527的订单信息需要去DB1库中的order_7表查找。具体算法流程也可参见下图：
有了分库分表的结构与算法最后就是寻找分库分表的实现工具，目前市面上约有两种类型的分库分表工具：
1.客户端分库分表，在客户端完成分库分表操作，直连数据库
2.使用分库分表中间件，客户端连分库分表中间件，由中间件完成分库分表操作
这两种类型的工具市面上都有，这里不一一列举，总的来看这两类工具各有利弊。客户端分库分表由于直连数据库，所以性能比使用分库分表中间件高15%到20%。而使用分库分表中间件由于进行了统一的中间件管理，将分库分表操作和客户端隔离，模块划分更加清晰，便于DBA进行统一管理。
我们选择的是在客户端分库分表，因为我们自己开发并开源了一套数据层访问框架，它的代号叫&芒果&，芒果框架原生支持分库分表功能，并且配置起来非常简单。
1.芒果主页：mango.jfaster.org
2.芒果源码：/jfaster/mango
二、订单ID
订单系统的ID必须具有全局唯一的特征，最简单的方式是利用数据库的序列，每操作一次就能获得一个全局唯一的自增ID，如果要支持每秒处理10万订单，那每秒将至少需要生成10万个订单ID，通过数据库生成自增ID显然无法完成上述要求。所以我们只能通过内存计算获得全局唯一的订单ID。
JAVA领域最著名的唯一ID应该算是UUID了，不过UUID太长而且包含字母，不适合作为订单ID。通过反复比较与筛选，我们借鉴了Twitter的Snowflake算法，实现了全局唯一ID。下面是订单ID的简化结构图：
上图分为3个部分：
这里时间戳的粒度是毫秒级，生成订单ID时，使用System.currentTimeMillis()作为时间戳。
每个订单服务器都将被分配一个唯一的编号，生成订单ID时，直接使用该唯一编号作为机器号即可。
当在同一服务器的同一毫秒中有多个生成订单ID的请求时，会在当前毫秒下自增此序号，下一个毫秒此序号继续从0开始。比如在同一服务器同一毫秒有3个生成订单ID的请求，这3个订单ID的自增序号部分将分别是0，1，2。
上面3个部分组合，我们就能快速生成全局唯一的订单ID。不过光全局唯一还不够，很多时候我们会只根据订单ID直接查询订单信息，这时由于没有uid，我们不知道去哪个分库的分表中查询，遍历所有的库的所有表？这显然不行。所以我们需要将分库分表的信息添加到订单ID上，下面是带分库分表信息的订单ID简化结构图：
我们在生成的全局订单ID头部添加了分库与分表的信息，这样只根据订单ID，我们也能快速的查询到对应的订单信息。
分库分表信息具体包含哪些内容？第一部分有讨论到，我们将订单表按uid维度拆分成了8个数据库，每个数据库10张表，最简单的分库分表信息只需一个长度为2的字符串即可存储，第1位存数据库编号，取值范围1到8，第2位存表编号，取值范围0到9。
还是按照第一部分根据uid计算数据库编号和表编号的算法，当uid＝9527时，分库信息＝1，分表信息＝7，将他们进行组合，两位的分库分表信息即为&17&。具体算法流程参见下图：
上述使用表编号作为分表信息没有任何问题，但使用数据库编号作为分库信息却存在隐患，考虑未来的扩容需求，我们需要将8库扩容到16库，这时取值范围1到8的分库信息将无法支撑1到16的分库场景，分库路由将无法正确完成，我们将上诉问题简称为分库信息精度丢失。
为解决分库信息精度丢失问题，我们需要对分库信息精度进行冗余，即我们现在保存的分库信息要支持以后的扩容。这里我们假设最终我们会扩容到64台数据库，所以新的分库信息算法为：
分库信息 = (uid / 10) % 64 + 1
当uid＝9527时，根据新的算法，分库信息=57，这里的57并不是真正数据库的编号，它冗余了最后扩展到64台数据库的分库信息精度。我们当前只有8台数据库，实际数据库编号还需根据下面的公式进行计算：
实际数据库编号 = (分库信息 - 1) % 8 + 1
当uid＝9527时，分库信息＝57，实际数据库编号＝1，分库分表信息=&577&。
由于我们选择模64来保存精度冗余后的分库信息，保存分库信息的长度由1变为了2，最后的分库分表信息的长度为3。具体算法流程也可参见下图：
如上图所示，在计算分库信息的时候采用了模64的方式冗余了分库信息精度，这样当我们的系统以后需要扩容到16库，32库，64库都不会再有问题。
上面的订单ID结构已经能很好的满足我们当前与之后的扩容需求，但考虑到业务的不确定性，我们在订单ID的最前方加了1位用于标识订单ID的版本，这个版本号属于冗余数据，目前并没有用到。下面是最终订单ID简化结构图：
Snowflake算法：/twitter/snowflake
三、最终一致性
到目前为止，我们通过对order表uid维度的分库分表，实现了order表的超高并发写入与更新，并能通过uid和订单ID查询订单信息。但作为一个开放的集团支付系统，我们还需要通过业务线ID（又称商户ID，简称bid）来查询订单信息，所以我们引入了bid维度的order表集群，将uid维度的order表集群冗余一份到bid维度的order表集群中，要根据bid查询订单信息时，只需查bid维度的order表集群即可。
上面的方案虽然简单，但保持两个order表集群的数据一致性是一件很麻烦的事情。两个表集群显然是在不同的数据库集群中，如果在写入与更新中引入强一致性的分布式事务，这无疑会大大降低系统效率，增长服务响应时间，这是我们所不能接受的，所以我们引入了消息队列进行异步数据同步，来实现数据的最终一致性。当然消息队列的各种异常也会造成数据不一致，所以我们又引入了实时监控服务，实时计算两个集群的数据差异，并进行一致性同步。
下面是简化的一致性同步图：
四、数据库高可用
没有任何机器或服务能保证在线上稳定运行不出故障。比如某一时间，某一数据库主库宕机，这时我们将不能对该库进行读写操作，线上服务将受到影响。
所谓数据库高可用指的是：当数据库由于各种原因出现问题时，能实时或快速的恢复数据库服务并修补数据，从整个集群的角度看，就像没有出任何问题一样。需要注意的是，这里的恢复数据库服务并不一定是指修复原有数据库，也包括将服务切换到另外备用的数据库。
数据库高可用的主要工作是数据库恢复与数据修补，一般我们以完成这两项工作的时间长短，作为衡量高可用好坏的标准。这里有一个恶性循环的问题，数据库恢复的时间越长，不一致数据越多，数据修补的时间就会越长，整体修复的时间就会变得更长。所以数据库的快速恢复成了数据库高可用的重中之重，试想一下如果我们能在数据库出故障的1秒之内完成数据库恢复，修复不一致的数据和成本也会大大降低。
下图是一个最经典的主从结构：
上图中有1台web服务器和3台数据库，其中DB1是主库，DB2和DB3是从库。我们在这里假设web服务器由项目组维护，而数据库服务器由DBA维护。
当从库DB2出现问题时，DBA会通知项目组，项目组将DB2从web服务的配置列表中删除，重启web服务器，这样出错的节点DB2将不再被访问，整个数据库服务得到恢复，等DBA修复DB2时，再由项目组将DB2添加到web服务。
当主库DB1出现问题时，DBA会将DB2切换为主库，并通知项目组，项目组使用DB2替换原有的主库DB1，重启web服务器，这样web服务将使用新的主库DB2，而DB1将不再被访问，整个数据库服务得到恢复，等DBA修复DB1时，再将DB1作为DB2的从库即可。
上面的经典结构有很大的弊病：不管主库或从库出现问题，都需要DBA和项目组协同完成数据库服务恢复，这很难做到自动化，而且恢复工程也过于缓慢。
我们认为，数据库运维应该和项目组分开，当数据库出现问题时，应由DBA实现统一恢复，不需要项目组操作服务，这样便于做到自动化，缩短服务恢复时间。
先来看从库高可用结构图：
如上图所示，web服务器将不再直接连接从库DB2和DB3，而是连接LVS负载均衡，由LVS连接从库。这样做的好处是LVS能自动感知从库是否可用，从库DB2宕机后，LVS将不会把读数据请求再发向DB2。同时DBA需要增减从库节点时，只需独立操作LVS即可，不再需要项目组更新配置文件，重启服务器来配合。
再来看主库高可用结构图：
如上图所示，web服务器将不再直接连接主库DB1，而是连接KeepAlive虚拟出的一个虚拟ip，再将此虚拟ip映射到主库DB1上，同时添加DB_bak从库，实时同步DB1中的数据。正常情况下web还是在DB1中读写数据，当DB1宕机后，脚本会自动将DB_bak设置成主库，并将虚拟ip映射到DB_bak上，web服务将使用健康的DB_bak作为主库进行读写访问。这样只需几秒的时间，就能完成主数据库服务恢复。
组合上面的结构，得到主从高可用结构图：
数据库高可用还包含数据修补，由于我们在操作核心数据时，都是先记录日志再执行更新，加上实现了近乎实时的快速恢复数据库服务，所以修补的数据量都不大，一个简单的恢复脚本就能快速完成数据修复。
五、数据分级
支付系统除了最核心的支付订单表与支付流水表外，还有一些配置信息表和一些用户相关信息表。如果所有的读操作都在数据库上完成，系统性能将大打折扣，所以我们引入了数据分级机制。
我们简单的将支付系统的数据划分成了3级：
第1级：订单数据和支付流水数据；这两块数据对实时性和精确性要求很高，所以不添加任何缓存，读写操作将直接操作数据库。
第2级：用户相关数据；这些数据和用户相关，具有读多写少的特征，所以我们使用redis进行缓存。
第3级：支付配置信息；这些数据和用户无关，具有数据量小，频繁读，几乎不修改的特征，所以我们使用本地内存进行缓存。
使用本地内存缓存有一个数据同步问题，因为配置信息缓存在内存中，而本地内存无法感知到配置信息在数据库的修改，这样会造成数据库中数据和本地内存中数据不一致的问题。
为了解决此问题，我们开发了一个高可用的消息推送平台，当配置信息被修改时，我们可以使用推送平台，给支付系统所有的服务器推送配置文件更新消息，服务器收到消息会自动更新配置信息，并给出成功反馈。
六、粗细管道
黑客攻击，前端重试等一些原因会造成请求量的暴涨，如果我们的服务被激增的请求给一波打死，想要重新恢复，就是一件非常痛苦和繁琐的过程。
举个简单的例子，我们目前订单的处理能力是平均10万下单每秒，峰值14万下单每秒，如果同一秒钟有100万个下单请求进入支付系统，毫无疑问我们的整个支付系统就会崩溃，后续源源不断的请求会让我们的服务集群根本启动不起来，唯一的办法只能是切断所有流量，重启整个集群，再慢慢导入流量。
我们在对外的web服务器上加一层&粗细管道&，就能很好的解决上面的问题。
下面是粗细管道简单的结构图：
请看上面的结构图，http请求在进入web集群前，会先经过一层粗细管道。入口端是粗口，我们设置最大能支持100万请求每秒，多余的请求会被直接抛弃掉。出口端是细口，我们设置给web集群10万请求每秒。剩余的90万请求会在粗细管道中排队，等待web集群处理完老的请求后，才会有新的请求从管道中出来，给web集群处理。这样web集群处理的请求数每秒永远不会超过10万，在这个负载下，集群中的各个服务都会高校运转，整个集群也不会因为暴增的请求而停止服务。
如何实现粗细管道？nginx商业版中已经有了支持，相关资料请搜索
nginx max_conns，需要注意的是max_conns是活跃连接数，具体设置除了需要确定最大TPS外，还需确定平均响应时间。
nginx相关：http://nginx.org/en/docs/http/ngx_http_upstream_module.html
编辑推荐：架构技术实践系列文章（部分）：
梁阳鹤：每秒处理10万订单乐视集团支付架构
沈辉煌：亿级日PV的魅族云同步的核心协议与架构实践
携程Docker最佳实践
游戏研发与运营环境Docker化
当当网高可用架构之道
黄哲铿：应对电商大促峰值的九个方法
1号店交易系统架构如何向「高并发高可用」演进<
从C10K到C10M高性能网络的探索与实践
服务化架构的演进与实践
1号店架构师王富平：一号店用户画像系统实践
唯品会官华：实现电商平台从业务到架构的治理体系
沈剑：58同城数据库架构最佳实践
荔枝FM架构师刘耀华：异地多活IDC机房架构
UPYUN的云CDN技术架构演进之路
初页CTO丁乐：分布式以后还能敏捷吗？
陈科：河狸家运维系统监控系统的实现方案
途牛谭俊青：多数据中心状态同步&两地三中心的理论
云运维的启示与架构设计
魅族多机房部署方案
艺龙十万级服务器监控系统开发的架构和心得
京东商品详情页应对&双11&大流量的技术实践
架构师于小波：魅族实时消息推送架构
更多课程...&&&
更多咨询...&&&
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
|&京ICP备号&京公海网安备号架构设计｜LOFTER（乐乎） - 记录生活，发现同好
LOFTER for ipad —— 记录生活，发现同好
&nbsp&nbsp被喜欢
&nbsp&nbsp被喜欢
{list posts as post}
{if post.type==1 || post.type == 5}
{if !!post.title}${post.title|escape}{/if}
{if !!post.digest}${post.digest}{/if}
{if post.type==2}
{if post.type == 3}
{if !!post.image}
{if post.type == 4}
{if !!post.image}
{if !!photo.labels && photo.labels.length>0}
{var wrapwidth = photo.ow < 500?photo.ow:500}
{list photo.labels as labs}
{var lbtxtwidth = Math.floor(wrapwidth*(labs.ort==1?labs.x:(100-labs.x))/100)-62}
{if lbtxtwidth>12}
{if !!labs.icon}
{list photos as photo}
{if photo_index==0}{break}{/if}
品牌${make||'-'}
型号${model||'-'}
焦距${focalLength||'-'}
光圈${apertureValue||'-'}
快门速度${exposureTime||'-'}
ISO${isoSpeedRatings||'-'}
曝光补偿${exposureBiasValue||'-'}
镜头${lens||'-'}
{if data.msgRank == 1}{/if}
{if data.askSetting == 1}{/if}
{if defined('posts')&&posts.length>0}
{list posts as post}
{if post_index < 3}
{if post.type == 1 || post.type == 5}
{if !!post.title}${post.title|escape}{/if}
{if !!post.digest}${post.digest}{/if}
{if post.type == 2}
{if post.type == 3}
{if post.type == 4}
{if post.type == 6}
{if drlist.length>0}
更多相似达人：
{list drlist as dr}{if drlist.length === 3 && dr_index === 0}、{/if}{if drlist.length === 3 && dr_index === 1}、{/if}{if drlist.length === 2 && dr_index === 0}、{/if}{/list}
暂无相似达人，
{if defined('posts')&&posts.length>0}
{list posts as post}
{if post.type == 2}
{if post.type == 3}
{if post.type == 4}
{if post.type == 6}
this.p={ currentPage:1,pageNewMode:true,isgooglead3:false,ishotrecompost:false,visitorId:0, first:'',tag:'架构设计',recommType:'new',recommenderRole:0,offset:18,type:0,isUserEditor:0,};58同城沈剑：好的架构源于不停地衍变，而非设计
发表于 01:37|
摘要：对很多创业公司而言，很难在初期就预估到流量十倍、百倍以及千倍以后网站架构会是什么样的一个状况。同时，如果系统初期就设计一个千万级并发的流量架构，很难有公司可以支撑这个成本。
【编者按】对很多创业公司而言，随着业务增长，网站的流量也会经历不同的阶段。从十万流量到一百万流量，再从一百万流量跨越到一千万甚至上亿的流量，网站的架构需要经历哪些变化？在“”第一期中，58同城的技术委员会执行主席沈剑对此进行了详细剖析。以下为演讲整理本次演讲主要会阐述，58同城从小流量、中等规模流量、大流量，到更大的流量过程中，架构是如何演进的？遇到了哪些问题？以及如何解决这些问题？好的架构不是设计出来的，而是演进出来的对很多创业公司而言，很难在初期就预估到流量十倍、百倍以及千倍以后网站架构会是什么样的一个状况。同时，如果系统初期就设计一个千万级并发的流量架构，很难有公司可以支撑这个成本。因此，这里主要会关注架构的眼花。在每个阶段，找到对应该阶段网站架构所面临的问题，然后在不断解决这些问题，在这个过程中整个架构会一直演进。在58同城建立之初，站点的流量非常小，可能也就是十万级别，这也就意味着，平均每秒钟也就是几次的访问，此时网站架构的特点是：请求量比较低，数据量比较小，代码量也比较小。这个时候的站点可以被几个工程师轻易搞定，因此根本没什么“架构”可言。其实这也是很多创业公司初期面临的问题，最开始58同城的站点架构用一个词概括就是“ALL IN ONE”，如下图所示：就像一个单机系统，所有的东西都部署在一台机器上，包括站点、数据库、文件等等。而工程师每天的核心工作就是CURD，前端传过来一些数据，然后业务逻辑层拼装成一些CURD访问数据库，数据库返回数据，数据拼装成页面，最终返回到浏览器。相信很多创业团队初期都面临一个与之类似的情况，每天写代码，写SQL、接口参数、访问数据等等。这里需要说明一个问题，大家都知道最初58同城使用的是Windows、iis、SQL-Sever、C#这条路。现在很多创业公司可能就不会这么做。如果可以重来？那么会选择LAMP很多创业的同学可能会想，初期什么样的一个架构合适？ 如果重来，站在现在这个角度上58会选择LAMP，为什么？首先是无须编译，而且快速发布功能强大，从前端到后端、数据库访问、业务逻辑处理等等全部可以搞定，最重要都是成熟的开源产品，完全免费的。如果使用LAMP搭建一个论坛，两天的时间就足够了。所以，如果在创业初期，就尽量不要再使用Windows。在这个阶段58同城面临的主要问题是什么？其实就是招人，最初工程师写CURD都容易出错。当时引进了DAO和ORM，从而避免直接面对CURD语句，而是面对工程师比较擅长的是面向对象，能够极大的提高工作效率，降低出错率。中等规模：流量跨过十万的阶段，数据库成为瓶颈随着58同城的高速增长，系统很快跨越了十万流量阶段。主要需求是什么？网站能够正常访问，当然速度更快点就好了。而此时系统面临的问题有：在流量峰值期容易宕机，因为大量的请求会压到数据库上，所以数据库成为新的瓶颈，从而，人越多访问越慢。而在这个时候，机器数量也从一台变成了多台，所以很自然的行程了分布式架构，如下图所示：首先，使用了一些非常常见的技术，一方面是动静分离，动态的页面通过Web-Servre访问，静态的像图片等就单独放到了一些服务器上。另外一点就是读写分离。其实，对58同城或者说绝大部分的站点而言，一般来说都是读多写少。对58同城来说，绝大部分用户是访问信息，只有很少的用户过来发贴。那么如何扩展整个站点架构的读请求呢？常用的是主从同步，读写分离。同时原来只有一个数据库，现在使用多个不同的数据库提供服务，这样的话，就扩展了读写，很快就解决了中等规模下数据访问的问题。在这个阶段，系统的主要矛盾就是“站点耦合+读写延时”，58同城是如何进行解耦，如何缓解延时呢？对58同城而言，典型业务场景是主页，发布信息有发布页，信息聚合、标题聚合有列表页，点开一个标题有详细页，而这些站点都是耦合在一个程序中的，或者说耦合在一个站点中的，当一个站点出现问题，整个站点就会因为耦合一起出问题。第二个问题，大家都知道做数据库读请求和写请求，分布在不同的数据库上，这个时候如果再读取可能读到的是旧数据，因为读写有一个延时。如果有用户发帖子，马上去找的话肯定找不到，很可能带来的后果就是陆续在发布两条信息，这就是一个很大的问题。尤其是在请求量越来越大的时候，这个问题就更加突出。在解决这些问题时，最先想到的是针对原来站点的核心业务做切分，然后工程师根据自己的站点和业务场景进行细分。首先，业务拆分是58同城最先尝试的优化——将业务垂直拆分成了首页和发布页。另外，在数据库层面，随之也进行了拆分，将大数据量拆分成一个个小的数据量。这样，读写延时就马上得到了缓解。尤其是在代码拆分成了不同的层面之后，站点耦合也得到了缓解，数据加载速度也提升了很多。当时，还使用了一些技术，前面也提到了对动态资源和静态资源进行拆分。其中，我们对静态资源使用了CDN服务，便于数据缓存和就近访问，访问速度得到很明显的提升。除此之外，还使用了MVC模式，擅长前端的去做展示层，擅长协作逻辑的工程师就做Contorller，擅长数据的人就负责数据，效率就会逐步的提高，最后就是负载均衡技术。大流量：将整个Windows技术体系转向了Java体系流量越来越大，当流量超过一千多万时，58同城面临的最大问题就是性能和成本。此前曾提到58同城最初的技术选型是Windows，整个网站的性能变得非常之低。即使进行了业务拆分和一些优化，依然解决不了这个问题，所以当时做了一个非常艰难的决定，就是转型：将整个Windows技术体系转向了Java体系，这涵盖了操作系统、数据库等多个维度。其实，现在很多大的互联网公司在流量从小到大的过程中都经历过转型，包括京东、淘宝等等。对技术的要求越来越高，任何一个站点都不能挂，对站点的可用性要求也是越来越高。就在这个时候，58同城业务量也出现一个爆发期。于是招聘了很多工程师，大家一起写越来越多的站点，但是发现效率很低，经常做一些重复性的工作，比如参数解析等等。同时，业务之间相互依赖，无论是分类的子系统还是信息的子系统，二手车业务、房产业务都要访问用户和信息等一些底层数据，代码之间频繁的沟通，效率也不可能很高。问题随之而来，站点数越来越多，数据量越来越大，机器数从最开始的几台上升到几百台的级别。那么如何提供整个架构的可用性呢？首先，在上层进行了一些改进和优化，再做进一步的垂直拆分，同时引入了Cache，如下图所示：在架构的改进上，这里构建了一个相对独立的服务层，这个服务层做的每个业务线都会写对应的代码。如果用户发出请求，就由这个服务层统一来管理，所有的上游业务线就像调用本地函数一样，通过IDC的框架来调用这个服务。整个用户登录先访问Cache，如果Cache变动了就直接返回，如果Cache不变动，就会访问数据库，这样把数据库的数据拿到本地再放回Cache，再打回上一轮。如此一来，业务逻辑全部封装在这个服务的上游管理，该业务逻辑只有服务层能够编写代码，然后由这个服务层集中管理、集中优化，这样就提高了效率。除此之外，为了保证站点的高可用，主要使用了反向代理技术。因为对用户而言，他主要为了使用58同城的服务，不会关注访问是58同城或者有十台首页的服务器。58同城通过反向代理技术，通过DNS群，通过LVS技术，来保证接入层的高可用性，同时还保证了服务层、站点层、数据层的高可用。另外，为了保证高可用还使用了冗余的方法，无论是站点服务和数据服务都可以使用这种方式进行解决，一个站点不可用，就换一个站点，一个数据库不够用，就多加几个。当然，数据冗余也会带来一些副作用，如果数据量更新的话，那就需要将所有的“冗余”都要进行更新。58同城也做了一个图片存储系统，开始都是存储在操作系统之上，随着新增站点、新增服务，压力就变得越来越大。于是，58同城就自建了站点框架和服务框架，现在这两个框架也已经开源（如何降低站点开发成本？/58code/Argo&如何降低服务开发成本？&&）只需要修改一些基本的配置就可以使用了。当架构变成“蜘蛛网”，人肉已很难搞定！随着用户量、数据量并发量进一步的增长，58同城也拓展了很多的新业务，那么对产品迭代速度要求就非常高，整体的架构对自动化的要求越来越高。为了支撑业务的发展，技术团队对架构做了进一步的解耦，另外就是引入了配置中心，如果要访问任何一个服务，不会直接在本地的配置中留下一个服务，配置中心告诉这个服务的特点，如果扩展的话，配置中心自动下达消息，如果有机器要下线的话，配置中心会反向通过发邮件的方式进行通知。而柔性服务是指当流量增加的时候，自动的新增服务。可以看到进一步解耦之后，有垂直业务、无线业务、集成业务等等，这些子系统之间都是通过配置中心相应之间发生关系的。另一点就是关于数据库，当某一点成为一个业务线重点的时候，就会集中解决这个点的问题。最初期的时候每个业务线都要访问数据库，访问缓存，访问用户数据，于是把代码集中的放到了服务层。现在数据量越来越大，大家都要做数据切分，每个业务线都做切分，这个时候58同城的每个页面都面对这样的痛点，于是把这个痛点拿到集中的层面来解决。最后一点就是效率矛盾，此时有很多问题，靠“人肉”已经很难进行搞定了。这就需要自动化，包括回归、测试、运维、监控等等都要回归到自动化。这里需要补充一点，就是在产品层面引入了智能化，比如说智能推荐，主动推荐一些相关的话题；智能广告，通过一些智能的策略，让用户对广告的点击更多，增加对58同城的收录；智能搜索，在搜索的过程中加入一些搜索的策略，可以提高搜索的权重，也可以增加58同城的PV。当然，所有的自动化的产品背后都是由技术在驱动。未来的挑战现在，58同城的流量已经突破了10亿量级，那么架构上未来面临哪些挑战呢？一方面是无线化、移动化。另一方面就是需求的变化，必须加快迭代一些东西。如果拥有10亿的流量，却跑在一亿的架构上肯定是不行的。未来，还会使用更多的并行计算、实时计算，如果能做到实时推荐，效果肯定非常好，这也是挑战之一。最后一点，58同城现在的服务器大概在3000台左右，未来将拓展到10000台，这就是运维的挑战了。总结最后做一个小的总结，网站在不同的阶段遇到的问题不一样，而解决这些问题使用的技术也不一样，流量小的时候，主要目的是提高开发效率，在早期要引入ORM，DAO这些技术。随着流量变大，使用动静分离、读写分离、主从同步、垂直拆分、CDN、MVC等方式不断地提升网站稳定性。面对更大的流量时，通过垂直拆分、服务化、反向代理、开发框架（站点/服务）等等，不断提升高可用。在面对上亿级的更大流量时，通过中心化、柔性服务、消息总线、自动化（回归，测试，运维，监控）来迎接新的挑战。未来的就是继续实现移动化，大数据实时计算，平台化……系统架构会一直迭代衍变，就像最初的从零到现在。（整理/技术编辑王鹏 责编/仲浩）
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章