前几天，在淘宝网站买了一本书--《构建高性能web站点》，不得不说这是我第一次真正意义上完全看完一本书，尽管曾经看过许多技术类的书。其中一个原因，就是大部分的技术类书籍偏向枯燥，即使是本着某种虔诚的目的和愿望去阅读，仍然很容易中途放弃。但是这本书却不同，它十分能吸引我的阅读愿望，几乎在所有的环节上能够引起我的共鸣思考，于是便快速的阅读了一遍此书。

   它讲述了一个网站的基本架构，

图下：

概览图

下面这张图我花了比较长的时间绘制，提炼了书中关于基础架构设计方面的部分，希望能把它们浓缩在一张图中，而且图中包含image-map，可以通过点击虚框链接到下文的对应部分。不过需要强调的是，这张图仅仅是一个杂烩，并不是实际的架构，切勿对号入座。

 

HTTP重定向

通过使客户端重定向，来分散和转移请求压力，比如一些下载服务通常都有几个镜像服务器。

 

分布式缓存

无法使用页面级别缓存时，需要考虑直接缓存数据，比如使用memcached作为缓存。此时，需要考虑并发写memcached的问题。 另外，当memcached横向规模扩大，服务器数量增加时，需要一种对应算法，能够使应用程序知道应该链接哪个memcached服务器（比如，取模运算）。分布式缓存能够自动重建缓存，不必担心down机。

 

负载均衡

负载均衡就是将请求分散，这涉及到应当如何设计调度策略，以让集群发挥最大的性能。当集群中的主机能力相当时应当尽量平均调度，能力不均时应当能者多劳。随着问题的复杂，要时刻关注调度的性能，不要让调度成为性能瓶颈。

反向代理负载均衡

反向代理服务器工作在HTTP层，类似代理服务器，与普通的代理服务器不同的是，服务器在代理的后端，而不是客户端在代理的后端，这类似于NAT，只是NAT工作在网络层。同样是负载均衡，反向代理服务器强调“转发”而不是“转移”，因为它不仅要转发客户端的请求，还要转发服务端的响应。可以用作反向代理服务器的软件有Nginx、lighttp、Apache，另外目前也有一些专业的代理转发设备能够工作在应用层，例如A10。

使用代理转发要注意以下问题：

• 由于反向代理的转发特性，使得代理本身很可能成为性能瓶颈。一般对于CPU密集型请求，使用代理比较合适，如果是IO密集型的话，这种集群方式很可能无法发挥最大性能
• 在代理上要开启健康检查，及时发现集群中的故障机，从而调整转发策略，这通常比DNS方式实时性更好
• 黏滞会话：对于启动session保存用户信息，或者后端服务器使用动态内容缓存的应用，必须将用户在一段会话中的的请求保持在同一台服务器上。代理服务器一般支持类似的配置。然而，尽量不要使应用过于本地化，比如可以使用cookie保存用户数据，或者分布式Session或分布式缓存。

IP负载均衡

字面上看，便是利用网络层进行请求转发，类似NAT网关。然而，使用网关转发在带宽上可能出现瓶颈，因为出口只有一个，所以出口的带宽要求较高。Linux中的Netfilter模块可以通过iptables的配置。比如：对外网端口8001的请求转发给内网某台服务器，而对外网端口8002的请求转发给内网另一台服务器。这种方式简单易行，但是无法对调度做太多配置。LVS-NAT同样是Linux中的在网络层进行转发的方式，与Netfilter不同，它支持一些动态调度算法，比如最小链接、带权重的最小链接、最短期望延迟等。

直接路由

直接路由是通过调度器修改数据包的目的MAC地址，转发请求数据包，但是响应数据包可以直接发送给外网的方式。这样做显而易见的好处就是无需担心网关瓶颈，但是实际的服务器和调度服务器都需要链接在WAN交换机上，并且拥有独立的外网IP地址。

这种方式的工作原理略微复杂：

首先每台服务器都需要设置一个IP别名，这个IP别名是面向客户端的一个虚拟IP，只有代理服务器对这个IP别名的ARP请求做出响应，这样客户端发给这个IP的请求包首先会到代理服务器。然后代理服务器将这个请求包的目的MAC地址填写为实际服务器的MAC地址（通过某种调度算法决定目的服务器），由于目标服务器也具有这个IP别名，因此，转发过来的数据包能够被实际的服务器接收并处理。最后由于数据包的源IP地址还是客户端请求的IP地址，因此，实际的服务器将通过交换机直接将响应包转发给客户端而无需通过代理服务器。

Linux下可以通过LVS-DR实现直接路由方式

IP隧道

IP隧道的意思是，调度器将原始的IP数据包封装在新的IP数据包中，以实现调度，实际的服务器可以将响应数据包直接转发给用户端。

 

共享文件系统

对于一些简单的提供文件下载的服务（包括html中静态资源等），自然要考虑利用集群来减压，但是如何使这些资源在集群中的主机上同步呢。

NFS

一种方案是让这些主机从同一个地方取数据。比如采用NFS（Network File System），基于PRC。这种方式简单易行，但是由于NFS服务器本身的磁盘吞吐率，或者并发处理能力以及带宽等问题，往往很有局限性。

冗余分发

另一个方案就是在主机上冗余存储资源，这样主机无需访问共享文件系统，只需读取本地磁盘上的资源即可。但是这也带来了一个同步的问题，如何同步这些数据呢：

主动分发式，还分为单级分发和多级分发，分发可以借助SCP、SFTP、HTTP扩展协议WebDAV

• 单级分发：通过一次分发，就达到目的，这样的方案简单易行，但是性能瓶颈会出现在磁盘压力和网络带宽，难以扩展
• 多级分发：通过多次分发，才达到目的地，这样的方案能够分散磁盘压力和网络带宽压力，而且容易扩展，坏处是成本高

被动同步式容易理解，可以使用rsync，rsync同步时是根据最后更新时间进行判定是否需要同步的条件的，因此，如果一个文件夹中有的文件数量太多的话，rsync扫描的时间就很长了，可以通过给文件夹设置最后更新时间，并合理的规划文件目录，来加快rsync的扫描时间。即使不使用rsync，自己开发同步程序也可以借助这样的思想来提升性能。

 

分布式文件系统

分布式文件系统工作在用户进程层面上，它是一个管理文件的平台，内部维护冗余，检索，追踪、调度等工作，通常包含一个物理层面的组织结构和逻辑层面的组织结构。物理层面的组织结构由分布式文件系统自行维护，逻辑层面的组织结构面向用户。其中“追踪器”起到了关键的作用。

MogileFS就是一个开源分布式文件系统，用Perl编写，包含追踪器、存储节点、管理工具，它使用MySQL分布式文件系统的所有信息、使用WebDAV实现文件复制。其他著名的还有Hadoop。

每个文件由一个key定义，需要读取文件时，指定一个key，追踪器会返回一个实际的路径，在访问这个地址即可获得文件。甚至可以将这个key对应的path用分布式缓存缓存起来，这样可以减少追踪器的查询开销，但这样也会失去分布式文件系统的调度策略的优越性。另外，可以利用支持reproxy的反向代理服务器（比如：Perlbal）让路径重定向的工作由反向代理服务器完成。

 

数据库扩展

主从复制，读写分离

这种方式是指利用数据库的复制或镜像功能，同时在多台数据库上保存相同的数据，并且将读操作和写操作分开，写操作集中在一台主数据库上，读操作集中在多台从数据库上，对于读取比写更多的站点适合使用这种方式。如果不想在应用程序层面维护这种分离映射，那么可以使用数据库反向代理来自动完成对读写的分离。

垂直分区

对于不需要进行联合查询的数据表可以分散到不同的数据库服务器上，这称为垂直分区；当然每个分区自身也可以使用读写分离。

水平分区

将同一个表的记录拆分到不同的表甚至是服务器上，称为水平分区，这往往需要一个稳定的算法来保证读取时能正确从不同的服务器上取得数据，比如简单的对ID取模、范围划分、亦或者是保存映射关系。 也可以使用类似代理的产品spock。

   一些名站的网站架构分析图

1.支付宝网站架构分析

支付宝系统架构概况大数据

典型处理默认大数据

资金处理平台大数据

财务会计大数据

支付清算大数据

核算中心大数据

交易大数据

柔性事务

 2，优酷网网站架构分析

视频网站老大

一、网站基本数据概览

• 据2010年统计，优酷网日均独立访问人数（uv)达到了8900万，日均访问量（pv）更是达到了17亿，优酷凭借这一数据成为google榜单中国内视频网站排名最高的厂商。
• 硬件方面，优酷网引进的戴尔服务器主要以 PowerEdge 1950与PowerEdge 860为主，存储阵列以戴尔MD1000为主，2007的数据表明，优酷网已有1000多台服务器遍布在全国各大省市，到现在2016应该更多了吧。

二、网站前端框架

从一开始，优酷网就自建了一套CMS来解决前端的页面显示，各个模块之间分离得比较恰当，前端可扩展性很好，UI的分离，让开发与维护变得十分简单和灵活，下图是优酷前端的模块调用关系：

这样，就根据module、method及params来确定调用相对独立的模块，显得非常简洁。下面附一张优酷的前端局部架构图：

三、数据库架构

应该说优酷的数据库架构也是经历了许多波折，从一开始的单台MySQL服务器（Just Running）到简单的MySQL主从复制、SSD优化、垂直分库、水平sharding分库，这一系列过程只有经历过才会有更深的体会吧，就像MySpace的架构经历一样，架构也是一步步慢慢成长和成熟的。

1、简单的MySQL主从复制:

MySQL的主从复制解决了数据库的读写分离，并很好的提升了读的性能，其原来图如下：

其主从复制的过程如下图所示：

但是，主从复制也带来其他一系列性能瓶颈问题：

1. 写入无法扩展
2. 写入无法缓存
3. 复制延时
4. 锁表率上升
5. 表变大，缓存率下降

那问题产生总得解决的，这就产生下面的优化方案，一起来看看。

2、MySQL垂直分区

如果把业务切割得足够独立，那把不同业务的数据放到不同的数据库服务器将是一个不错的方案，而且万一其中一个业务崩溃了也不会影响其他业务的正常进行，并且也起到了负载分流的作用，大大提升了数据库的吞吐能力。经过垂直分区后的数据库架构图如下：

然而，尽管业务之间已经足够独立了，但是有些业务之间或多或少总会有点联系，如用户，基本上都会和每个业务相关联，况且这种分区方式，也不能解决单张表数据量暴涨的问题，因此为何不试试水平sharding呢？

3、MySQL水平分片（Sharding）

这是一个非常好的思路，将用户按一定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增加，只要简单地配置一台服务器即可，原理图如下：

如何来确定某个用户所在的shard呢，可以建一张用户和shard对应的数据表，每次请求先从这张表找用户的shard id，再从对应shard中查询相关数据，如下图所示：

但是，优酷是如何解决跨shard的查询呢，这个是个难点，据介绍优酷是尽量不跨shard查询，实在不行通过多维分片索引、分布式搜索引擎，下策是分布式数据库查询（这个非常麻烦而且耗性能）

四、缓存策略

貌似大的系统都对“缓存”情有独钟，从http缓存到memcached内存数据缓存，但优酷表示没有用内存缓存，理由如下：

1. 避免内存拷贝，避免内存锁
2. 如接到老大哥通知要把某个视频撤下来，如果在缓存里是比较麻烦的

而且Squid 的 write() 用户进程空间有消耗，Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。

3，京东网站架构分析

咚咚是什么？咚咚之于京东相当于旺旺之于淘宝，它们都是服务于买家和卖家的沟通。 自从京东开始为第三方卖家提供入驻平台服务后，咚咚也就随之诞生了。 我们首先看看它诞生之初是什么样的。

1.0 诞生（2010 – 2011)

为了业务的快速上线，1.0 版本的技术架构实现是非常直接且简单粗暴的。 如何简单粗暴法？请看架构图，如下。

1.0 的功能十分简单，实现了一个 IM 的基本功能，接入、互通消息和状态。 另外还有客服功能，就是顾客接入咨询时的客服分配，按轮询方式把顾客分配给在线的客服接待。 用开源 Mina 框架实现了 TCP 的长连接接入，用 Tomcat Comet 机制实现了 HTTP 的长轮询服务。 而消息投递的实现是一端发送的消息临时存放在 Redis 中，另一端拉取的生产消费模型。

这个模型的做法导致需要以一种高频率的方式来轮询 Redis 遍历属于自己连接的关联会话消息。 这个模型很简单，简单包括多个层面的意思：理解起来简单；开发起来简单；部署起来也简单。 只需要一个 Tomcat 应用依赖一个共享的 Redis，简单的实现核心业务功能，并支持业务快速上线。

但这个简单的模型也有些严重的缺陷，主要是效率和扩展问题。 轮询的频率间隔大小基本决定了消息的延时，轮询越快延时越低，但轮询越快消耗也越高。 这个模型实际上是一个高功耗低效能的模型，因为不活跃的连接在那做高频率的无意义轮询。 高频有多高呢，基本在 100 ms 以内，你不能让轮询太慢，比如超过 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 三个级别不同的子业务服务系统。 另外就是独立了一组接入服务，针对不同渠道和通信方式的接入端，见下图。

更细化的应用服务和架构分层方式可见下图。

这次大的架构升级，主要考虑了三个方面：稳定性、效率和容量。 做了下面这些事情：

1. 业务分级、核心、非核心业务隔离

2. 多机房部署，流量分流、容灾冗余、峰值应对冗余

3. 读库多源，失败自动转移

4. 写库主备，短暂有损服务容忍下的快速切换

5. 外部接口，失败转移或快速断路

6. Redis 主备，失败转移

7. 大表迁移，MongoDB 取代 MySQL 存储消息记录

8. 改进消息投递模型

前 6 条基本属于考虑系统稳定性、可用性方面的改进升级。 这一块属于陆续迭代完成的，承载很多失败转移的配置和控制功能在上面图中是由管控中心提供的。 第 7 条主要是随着业务量的上升，单日消息量越来越大后，使用了 MongoDB 来单独存储量最大的聊天记录。 第 8 条是针对 1.0 版本消息轮询效率低的改进，改进后的投递方式如下图所示：

不再是轮询了，而是让终端每次建立连接后注册接入点位置，消息投递前定位连接所在接入点位置再推送过去。 这样投递效率就是恒定的了，而且很容易扩展，在线人数越多则连接数越多，只需要扩展接入点即可。 其实，这个模型依然还有些小问题，主要出在离线消息的处理上，可以先思考下，我们最后再讲。

3.0 经过了两年的迭代式升级，单纯从业务量上来说还可以继续支撑很长时间的增长。 但实际上到 2014 年底我们面对的不再是业务量的问题，而是业务模式的变化。 这直接导致了一个全新时代的到来。

4.0 殉道（2015 至今 )

2014 年京东的组织架构发生了很大变化，从一个公司变成了一个集团，下设多个子公司。 原来的商城成为了其中一个子公司，新成立的子公司包括京东金融、京东智能、京东到家、拍拍、海外事业部等。 各自业务范围不同，业务模式也不同，但不管什么业务总是需要客服服务。 如何复用原来为商城量身订做的咚咚客服系统并支持其他子公司业务快速接入成为我们新的课题。

最早要求接入的是拍拍网，它是从腾讯收购的，所以是完全不同的账户和订单交易体系。 由于时间紧迫，我们把为商城订做的部分剥离，基于 3.0 架构对接拍拍又单独订做了一套，并独立部署，像下面这样。

虽然在业务要求的时间点前完成了上线，但这样做也带来了明显的问题：

1. 复制工程，定制业务开发，多套源码维护成本高

2. 独立部署，至少双机房主备外加一个灰度集群，资源浪费大

以前我们都是面向业务去架构系统，如今新的业务变化形势下我们开始考虑面向平台去架构，在统一平台上跑多套业务，统一源码，统一部署，统一维护。 把业务服务继续拆分，剥离出最基础的 IM 服务，IM 通用服务，客服通用服务，而针对不同的业务特殊需求做最小化的定制服务开发。 部署方式则以平台形式部署，不同的业务方的服务跑在同一个平台上，但数据互相隔离。 服务继续被拆分的更微粒化，形成了一组服务矩阵（见下图）。

而部署方式，只需要在双机房建立两套对等集群，并另外建一个较小的灰度发布集群即可，所有不同业务都运行在统一平台集群上，如下图。

更细粒度的服务意味着每个服务的开发更简单，代码量更小，依赖更少，隔离稳定性更高。 但更细粒度的服务也意味着更繁琐的运维监控管理，直到今年公司内部弹性私有云、缓存云、消息队列、部署、监控、日志等基础系统日趋完善， 使得实施这类细粒度划分的微服务架构成为可能，运维成本可控。 而从当初 1.0 的 1 种应用进程，到 3.0 的 6、7 种应用进程，再到 4.0 的 50+ 更细粒度的不同种应用进程。 每种进程再根据承载业务流量不同分配不同的实例数，真正的实例进程数会过千。 为了更好的监控和管理这些进程，为此专门定制了一套面向服务的运维管理系统，见下图。

统一服务运维提供了实用的内部工具和库来帮助开发更健壮的微服务。 包括中心配置管理，流量埋点监控，数据库和缓存访问，运行时隔离，如下图所示是一个运行隔离的图示：

细粒度的微服务做到了进程间隔离，严格的开发规范和工具库帮助实现了异步消息和异步 HTTP 来避免多个跨进程的同步长调用链。 进程内部通过切面方式引入了服务增强容器 Armor 来隔离线程， 并支持进程内的单独业务降级和同步转异步化执行。而所有这些工具和库服务都是为了两个目标：

1. 让服务进程运行时状态可见

2. 让服务进程运行时状态可被管理和改变

最后我们回到前文留下的一个悬念，就是关于消息投递模型的缺陷。 一开始我们在接入层检测到终端连接断开后，消息无法投递，再将消息缓存下来，等终端重连接上来再拉取离线消息。 这个模型在移动时代表现的很不好，因为移动网络的不稳定性，导致经常断链后重连。 而准确的检测网络连接断开是依赖一个网络超时的，导致检测可能不准确，引发消息假投递成功。 新的模型如下图所示，它不再依赖准确的网络连接检测，投递前待确认消息 id 被缓存，而消息体被持久存储。 等到终端接收确认返回后，该消息才算投妥，未确认的消息 id 再重新登陆后或重连接后作为离线消息推送。 这个模型不会产生消息假投妥导致的丢失，但可能导致消息重复，只需由客户终端按消息 id 去重即可。

这是京东网站技术

58网站架构分析

对 很多创业公司而言，随着业务的增长，网站的流量也会经历不同的阶段。从十万流量到一百万流量，再从一百万流量跨越到一千万甚至上亿的流量，网站的架构需要 经历哪些变化？我们一起听听

58 同城的技术委员会执行主席沈剑在 OneAPM 技术公开课上的回答（以下演讲整理）：

本场演讲我主要阐述一下，58同城从小流量、中等规模流量、大流量，到更大的流量过程中，架构是怎么演进的？遇到了哪些问题？以及如何解决这些问题？

好的架构不是设计出来的而是演进出来的

对很多创业公司而言，在初期的时候，我们很难在初期就预估到流量十倍以后、百倍以后、一千倍以后网站的架构会变成什么样。当然，如果在最初的时期，就设计一个千万级并发的流量架构，那样的话，成本是也是非常之高的，估计很难有公司会这样做。

所以，我们主要来讲架构是如何进行演化的。我们在每个阶段，找到对应该阶段网站架构所面临的问题，然后在不断解决这些问题的过程中，整个战略的架构就是在不断的演进了。

其实，在 58 同城建立之初，站点的流量非常小，可能也就是是十万级别，这也就意味着，平均每秒钟也就是几次的访问。此时网站架构的特点：请求量是比较低，数据量比较小，代码量也比较小。可能找几个工程师，很容易就做一个这样的站点，根本没什么「架构」可言。

其实，这也是很多创业公司初期面临的问题，最开始58同城的站点架构用一个词概括就是「ALL IN ONE」，如下图所示：

就 像一个单机系统，所有的东西都部署在一台机器上，包括站点、数据库、文件等等。而工程师每天的核心工作就是 CURD，前端传过来一些数据，然后业务逻辑层拼装成一些 CURD 访问数据库，数据库返回数据，数据拼装成页面，最终返回到浏览器。相信很多创业团队，初期做的工作也是类似，每天写代码，写 SQL、接口参数、访问数据等等。

这里需要说明一个问题，大家都知道目前 58 同城使用的是 Windows、iis、SQL-Sever、C# 这条路。现在很多创业公司可能就不会这么做。58 同城为什么当时选择了这条路？原因是公司招聘的第一个工程师和第二个工程师只会这个，所以只能走这条路。

如果可以重来？那么会选择LAMP

很 多创业的同学可能会想，如果我们初期希望做一个产品的话，我们应该使用什么架构？ 如果让我们重来，可能我们现在会选 LAMP，为什么？首先是无须编译，而且快速发布功能强大，从前端到后端、数据库访问、业务逻辑处理等等全部可以搞定，最重要的是因为开源产品，是完全免 费的。如果使用 LAMP 搭建一个论坛，两天的时间就很足够了。所以，如果在创业初期，就尽量不要再使用 Windows 的技术体系了。

在 这个阶段 58 同城面临的主要问题是什么？其实就是招人。很多工程师可能都是再培训学校里培训了3月就过来上班，所以他们写 CURD 的话很容易出错。当时，我们引进了 DAO 和 ORM。虽然那些培训了几个月的工程师可能写CURD不是特别的擅长，但是他们写面向对象的一些程序引入了 DAO 和 ORM，让他们不再直接面对 CURD 语句，这样就会相对容易一些。因为工程师比较擅长的是面向对象的数据，不是 CURD，所以我们当时引入了 ORM，总的来说，如果大家现在的项目处于一个初期孵化的阶段，DAO 和 ORM 能够极大的提高效率，而且可以降低出错的概率。

中等规模：流量跨过十万的阶段，数据库成为瓶颈

随 着 58 同城的高速增长，我们很快跨越了十万流量的阶段。主要需求是什么？网站能够正常访问，当然速度更快点就好了。而此时系统面临问题包括：在流量的高峰期容易 宕机，因为大量的请求会压到数据库上，所以数据库成为新的瓶颈，而且人多的时候，访问速度会很慢。这时，我们的机器数量也从一台变成了多台。现在的架构就 采用了分布式，如下图所示：

首 先，我们使用了一些非常常见的技术，一方面是动静分离，动态的页面通过 Web-Servre 访问，静态的像图片等就单独放到了一些服务器上。另外一点就是读写分离。其实，对 58 同城或者说绝大部分的站点而言，一般来说都是读多写少。对 58 同城来说，绝大部分用户是访问信息，只有很少的用户过来发贴。那么如何扩展整个站点架构的读请求呢？常用的是主从同步，读写分离。我们原来只有一个数据 库，现在使用多个不同的数据库提供服务，这样的话，就扩展了读写，很快就解决了中等规模下数据访问的问题。

在这个阶段，系统的主要矛盾就是「站点耦合+读写延时」，58 同城是如何进行解耦，如何缓解延时呢？

对 58 同城而言，典型业务场景是主页，发布信息有发布页，信息聚合、标题聚合有列表页，点开一个标题有详细页，而这些站点都是耦合在一个程序中的，或者说耦合在一个站点中的，当我们有一个站点出现问题的时候，整个站点就会因为耦合一起出问题。

第 二个问题，大家都知道做数据库读请求和写请求，分布在不同的数据库上，这个时候如果再读取可能读到的是旧数据，因为读写有一个延时。如果有用户发帖子，马 上去找的话肯定找不到，很可能带来的后果就是陆续在发布两条信息，这就是一个很大的问题。尤其是在请求量越来越大的时候，这个问题就更加突出。

在 解决这些问题是，最先想到的是针对原来站点的核心业务做切分，然后工程师根据自己的站点和业务场景进行细分。首先，业务拆分是 58 同城最先尝试的优化。我们将业务垂直拆分成了首页和发布页。另外，在数据库层面，我们也随之进行了拆分，将大数据量拆分成一个个小的数据量。这样，读写延 时就马上得到了缓解。尤其是在代码拆分成了不同的层面之后，站点耦合也得到了缓解，数据量加载速度也提升了很多。

当 时，还使用了一些技术，前面也提到了对动态资源和静态资源进行拆分。其中，我们对静态资源使用了 CDN 服务，便于数据缓存和就近访问，访问速度得到很明显的提升。除此之外，我们还使用了 MVC 模式，擅长前端的去做展示层，擅长协作逻辑的工程师就做 Contorller，擅长数据的人就负责数据，效率就会逐步的提高，最后就是负载均衡技术。

大流量：将整个 Windows 技术体系转向了 Java 体系

流 量越来越大，当流量超过一千多万时，58 同城面对最大的问题就是性能和成本。此前，我提到58同城最初的技术选型是 Windows，应该是在 2006 年的时候，整个网站的性能变得非常之低。即使进行了业务拆分和一些优化，但是依然解决不了这个问题，所以我们当时做了一个非常艰难的决定，就是转型：将整 个 Windows 技术体系转向了 Java 体系，这涵盖了操作系统、数据库等多个维度。

其实，现在很多大的互联网公司在流量从小到大的过程中都经历过转型，包括京东、淘宝等等。对技术的要求越来越高，任何一个站点都不能挂，对站点的可用性要求也是越来越高。

就 在这个时候，58 同城业务量也出现一个爆发期。于是我们招聘了很多的工程师，大家一起写越来越多的站点，但是发现效率很低，经常做一些重复性的工作比如参数解析等等。同 时，业务之间相互依赖，无论是分类的子系统还是信息的子系统，二手车业务、房产业务都要访问用户和信息等一些底层数据，代码之间频繁的沟通，效率也不可能 很高。

问题随之而来，站点数越来越多，数据量越来越大，机器数从最开始的几台上升到几百台的级别。那么如何提供整个架构的可用性呢？首先，在上层我们进行了一些改进和优化，再做进一步的垂直拆分，同时我们引入了 Cache，如下图所示：

在 架构的改进上，我们构建了一个相对独立的服务层，这个服务层做的每个业务线都会写对应的代码。如果用户发出请求，就由这个服务层统一来管理，所有的上游业 务线就像调用本地函数一样，通过 IDC 的框架来调用这个服务。整个用户登录先访问 Cache，如果 Cache 变动了就直接返回，如果 Cache 不变动，就会访问数据库，这样把数据库的数据拿到本地再放回 Cache，再打回上一轮。如此一来，业务逻辑全部封装在这个服务的上游管理，该业务逻辑只有服务层能够编写代码，然后由这个服务层集中管理、集中优化， 这样就提高了效率。

除 此之外，为了保证站点的高可用，我们主要使用了反向代理技术。因为用户而言，他主要为了使用 58 同城的服务，他不关注访问是58同城或者有十台首页的服务器。58 同城通过反向代理技术，通过 DNS 群，通过 LVS 技术，来保证接入层的高可用性，同时还保证了服务层、站点层、数据层的高可用。另外，为了保证高可用我们经常使用冗余的方法，无论是站点服务和数据服务都 可以使用这种方式进行解决，一个站点不可用，我们就换一个站点，一个数据库不够用，我们就多加几个。当然，数据冗余也会带来一些副作用，如果数据量更新的 话，那就需要将所有的“冗余”都要进行更新。

58同城也做了一个图片存储系统，开始都是存储在操作系统之上，随着新增站点、新增服务，压力就变得越来越大。于是，58 同城就自建了站点框架和服务框架，现在这两个框架也已经开源（如何降低站点开发成本？https://github.com/58code/Argo 如何降低服务开发成本？ https://github.com/58code/Gaea ）只需要修改一些基本的配置就可以使用了。

当架构变成「蜘蛛网」，人肉已很难搞定！

随着用户量、数据量并发量进一步的增长，58同城也拓展了很多的新业务，那么对产品迭代速度要求就非常高，整体的架构对自动化的要求越来越高。

为 了支撑业务的发展，技术团队对架构做了进一步的解耦，另外就是引入了配置中心，如果要访问任何一个服务，不会直接在本地的配置中留下一个服务，配置中心告 诉这个服务的特点，如果扩展的话，配置中心自动下达消息，如果有机器要下线的话，配置中心会反向通过发邮件的方式进行通知。

而柔性服务是指当流量增加的时候，自动的新增服务。可以看到进一步解耦之后，有垂直业务、无线业务、集成业务等等，这些子系统之间都是通过配置中心相应之间发生关系的。

另 一点就是关于数据库，当某一点成为一个业务线重点的时候，我们就会集中解决这个点的问题。最初期的时候每个业务线都要访问数据库，访问缓存，访问用户数 据，于是我们把代码集中的放到了服务层。现在数据量越来越大，大家都要做数据切分，每个业务线都做切分，这个时候58同城的每个页面都面对这样的痛点，于 是把这个痛点拿到集中的层面来解决。

最后一点就是效率矛盾，此时很多问题，靠「人肉」已经很难进行搞定了。这就需要自动化，包括回归、测试、运维、监控等等都要回归到自动化。

这 里需要补充一点，就是在产品层面，我们引入了智能化，比如说智能推荐，主动推荐一些相关的话题；智能广告，通过一些智能的策略，让用户对广告的点击更多， 增加对 58 同城的收录；智能搜索，在搜索的过程中加入一些搜索的策略，可以提高搜索的权重，也可以增加 58 同城的 PV。当然，所有的自动化的产品背后都是由技术在驱动。

未来的挑战

现 在，58同城的流量已经突破的 10 亿的量级，那么架构上未来面临哪些挑战呢？一方面是无线化、移动化。另一方面就是需求的变化，我们必须加快迭代一些东西。如果拥有10亿的流量，却跑在一 亿的架构上肯定是不行的。未来，我们会使用更多的并行计算、实时计算，如果能做到实时推荐，效果肯定非常好，这也是我们的挑战。最后一点，58同城现在的 服务器大概在3000台左右，未来将拓展到 10000 万，这就是运维的挑战了。

end