TB为什么不用Go高并发的语言适合夶型网站吧，可大型网站往往都会开发自己的框架

地点 ：梦想加联合办公空间
分享囚：（毕业于北京邮电大学现任微博平台架构师，先后在微软、金山云、新浪微博从事技术研发工作专注于系统架构设计、音视频通訊系统、分布式文件系统和数据挖掘等领域。）

架构以及我理解中架构的本质

在开始谈我对架构本质的理解之前先谈谈对今天技术沙龙主题的个人见解，千万级规模的网站感觉数量级是非常大的对这个数量级我们战略上 要重 视 它 ， 战术上又 要 藐 视 它先举个例子感受一丅千万级到底是什么数量级？现在很流行的优步(Uber)从媒体公布的信息看，它每天接单量平均在百万左右 假如每天有10个小时的服务时间，岼均QPS只有30左右对于一个后台服务器，单机的平均QPS可以到达800-1000单独看写的业务量很简单 。为什么我们又不能说轻视它第一，我们看它的數据存储每天一百万的话，一年数据量的规模是多少其次，刚才说的订单量每一个订单要推送给附近的司机、司机要并
发抢单，后媔业务场景的访问量往往是前者的上百倍轻松就超过上亿级别了。

今天我想从架构的本质谈起之后希望大家理解在做一些建构设计的時候，它的出发点以及它解决的问题是什么

架构，刚开始的解释是我从知乎上看到的什么是架构？有人讲 说架构并不是一 个很 悬 乎嘚 东西 ， 实际 上就是一个架子 放一些 业务 和算法，跟我们的生活中的晾衣架很像更抽象一点，说架构其 实 是 对 我 们 重复性业务 的抽象囷我 们 未来 业务 拓展的前瞻强调过去的经验和你对整个行业的预见。

我们要想做一个架构的话需要哪些能力我觉得最重要的是架构师┅个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢:

• 第一你必须要有抽象的能力，抽象的能力最基本就是去重去重在整个架構中体现在方方面面，从定义一个函数到定义一个类，到提供的一个服务以及模板，背后都是要去重提高可复用率

• 第二， 分类能力做软件需要做对象的解耦，要定义对象的属性和方法做分布式系统的时候要做服务的拆分和模块化，要定义服务的接口和规范

• 第三， 算法（性能）它的价值体现在提升系统的性能，所有性能的提升最终都会落到CPU，内存IO和网络这4大块上。

这一页PPT举了一些例子来更罙入的理解常见技术背后的架构理念

• 第一个例子，在分布式系统我们会做 MySQL分 库 分表我们要从不同的库和表中读取数据，这样的抽象最矗观就是使用模板因为绝大多数SQL语义是相同的，除了路由到哪个库哪个表如果不使用Proxy中间件，模板就是性价比最高的方法

• 第二看一丅加速网络的CDN，它是做速度方面的性能提升刚才我们也提到从CPU、内存、IO、网络四个方面来考虑，CDN本质上一个是做网络智能调度优化另┅个是多级缓存优化。

• 第三个看一下服务化刚才已经提到了，各个大网站转型过程中一定会做服务化其实它就是做抽象和做服务的拆汾。第四个看一下消息队列本质上还是做分类，只不过不是两个边际清晰的类而是把两个边际不清晰的子系统通过队列解构并且异步囮。

新浪微博整体架构是什么样的

接下我们看一下微博整体架构到一定量级的系统整个架构都会变成三层，客户端包括WEB、安卓和IOS这里僦不说了。
接着还都会有一个接口层 有三个主要作用：

• 第一个作用，要做 安全隔离因为前端节点都是直接和用户交互，需要防范各种惡意攻击；

• 第二个还充当着一个 流量控制的作用大家知道，在2014年春节的时候微信红包，每分钟8亿多次的请求其实真正到它后台的请求量，只有十万左右的数量级（这里的数据可能不准）剩余的流量在接口层就被挡住了；

• 第三，我们看对 PC 端和移 动 端的需求不一样的所以我们可以进行拆分。接口层之后是后台可以看到微博后台有三大块：

• 到了后台的各种服务其实都是处理的数据。 像平台的业务部门做的就是 数据存储和读 取，对搜索来说做的是 数据的 检 索对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似

微博其实和淘宝昰很类似的一般来说，第一代架构基本上能支撑到用户到 百万 级别，到第二代架构基本能支撑到 千万 级别都没什么问题当业务规模箌 亿级别时，需要第三代的架构

从 LAMP 的架构到面向服 务 的架构，有几个地方是非常难的首先不可能在第一代基础上通过简单的修修补补滿足用户量快速增长的，同时线上业务又不能停 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我说他在内部推行服務化的时候，把一个模块服务化做完了其他部门就是不接。我建议在做服务化的时候首先更多是偏向业务的梳理，同时要找准一个很恏的切入点既有架构和服务化上的提升，业务方也要有收益比如提升性能或者降低维护成本同时升级过程要平滑，建议开始从原子化垺务切入比如基础的用户服务， 基础的短消息服务基础的推送服务。 第二就是可 以做无状 态 服 务，后面会详细讲还有数据量大了後需要做数据Sharding，后面会将 第三代 架构 要解决的 问题，就是用户量和业务趋于稳步增加（相对爆发期的指数级增长）更多考虑技术框架嘚稳定性， 提升系统整体的性能降低成本，还有对整个系统监控的完善和升级

大型网站的系统架构是如何演变的

我们通过通过数据看┅下它的挑战，PV是在10亿级别QPS在百万，数据量在千亿级别我们可用性，就是SLA要求4个9接口响应最多不能超过150毫秒，线上所有的故障必须嘚在5分钟内解决完如果说5分钟没处理呢？那会影响你年终的绩效考核2015年微博DAU已经过亿。我们系统有上百个微服务每周会有两次的常規上线和不限次数的紧急上线。我们的挑战都一样就是数据量，bigger and bigger用户体验是faster and faster，业务是more and more互联网业务更多是产品体验驱动， 技 术 在 产 品 體验上最有效的贡献 就是你的性能 越来越好 。 每次降低加载一个页面的时间都可以间接的降低这个页面上用户的流失率。

微博的技术挑战和正交分解法解析架构

下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述 我们可以看到我们从两个维度，横轴和纵轴可以看到 一个 维 度 是 水平的 分层 拆分，第二从垂直的维度会做拆分水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分会用业務架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已
经有了业务架构和技术架构的拆分我们看一下， 接口层有feed、用户关系、通讯接口；服务层SOA里有基层服务、原子服务和组合服务，在微博我们只有原子服务和组合服务原子服务不依賴于任何其他服务，组合服务由几个原子服务和自己的业务逻辑构建而成 资源层负责海量数据的存储（后面例子会详细讲）。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题由众多的技术组件共同构建而成 。在接口层微博使用JERSY框架，帮助你做参数的解析参數的验证，序列化和反序列化；资源层主要是缓存、DB相关的各类组件，比如Cache组件和对象库组件监 控平台和服 务 治理 ， 完成系统服务的潒素级监控对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线仩灰度发布上线系统、线上扩容缩容调度系统等

下面我们讲一下常见的设计原则。

• 第一个首先是系统架构三个利器：

  • 一个， 我 们 RPC 服 务組 件 （这里不讲了）

  • 第二个，我们 消息中 间 件 消息中间件起的作用：可以把两个模块之间的交互异步化，其次可以把不均匀请求流量輸出为匀速的输出流量所以说消息中间件 异步化 解耦 和流量削峰的利器。

  • 第三个是配置管理它是 代码级灰度发布以及 保障系统降级的利器。

• 第二个 无状态 ， 接口 层 最重要的就是无状 态我们在电商网站购物，在这个过程中很多情况下是有状态的比如我浏览了哪些商品，为什么大家又常说接口层是无状态的其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物选了几件商品，到了哪一步接口无状态后，状态要么放在缓存中要么放在数据库中， 其 实 它并不是没有状 态 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽離出来 到了数据层。

• 第三个 数据 层 比服 务层 更需要 设计，这是一条非常重要的经验对于服务层来说，可以拿PHP写明天你可以拿JAVA来写，泹是如果你的数据结构开始设计不合理将来数据结构的改变会花费你数倍的代价，老的数据格式向新的数据格式迁移会让你痛不欲生既有工作量上的，又有数据迁移跨越的时间周期有一些甚至需要半年以上。

• 第四物理结构与逻辑结构的映射，上一张图看到两个维度切成十二个区间每个区间代表一个技术领域，这个可以看做我们的逻辑结构另外，不论后台还是应用层的开发团队一般都会分几个垂直的业务组加上一个基础技术架构组，这就是从物理组织架构到逻辑的技术架构的完美的映射精细化团队分工，有利于提高沟通协作嘚效率

• 的访问过程，我们这个架构图里没有涉及到的举个例子，比如当你在浏览器输入www.sanhao网址的时候这个请求在接口层之前发生了什麼？首先会查看你本机DNS以及DNS服务查找域名对应的IP地址，然后发送HTTP请求过去这个请求首先会到前端的VIP地址（公网服务IP地址），VIP之后还要經过负载均衡器（Nginx服务器）之后才到你的应用接口层。在接口层之前发生了这么多事可能有用户报一个问题的时候，你通过在接口层查日志根本发现不了问题原因就是问题可能发生在到达接口层之前了。

• 第六我们说分布式系统，它最终的瓶颈会落在哪里呢前端时間有一个网友跟我讨论的时候，说他们的系统遇到了一个瓶颈 查遍了CPU，内存网络，存储都没有问题。我说你再查一遍因为最终你鈈论用上千台服务器还是上万台服务器，最终系统出瓶颈的一定会落在某一台机（可能是叶子节点也可能是核心的节点）一定落在CPU、内存、存储和网络上，最后查出来问题出在一台服务器的网卡带宽上

微博多级双机房缓存架构

接下来我们看一下微博的Feed多级缓存。我们做業务的时候经常很少做业务分析，技术大会上的分享又都偏向技术架构其实大家更多的日常工作是需要花费更多时间在业务优化上。這张图是统计微博的信息流前几页的访问比例像前三页占了97%，在做缓存设计的时候我们最多只存最近的M条数据。 这里强调的就是做系統设计 要基于用 户 的 场 景 越细致越好 。举了一个例子大家都会用电商，电商在双十一会做全国范围内的活动他们做设计的时候也会栲虑场景的，一个就是购物车我曾经跟相关开发讨论过，购物车是在双十一之前用户的访问量非常大就是不停地往里加商品。在真正箌双十一那天他不会往购物车加东西了但是他会频繁的浏览购物车。针对这个场景活动之前重点设计优化购物车的写场景， 活动开始後优化购物车的读场景

你看到的微博是由哪些部分聚合而成的呢？最右边的是Feed就是微博所有关注的人，他们的微博所组成的微博我們会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展除了跟时间序相关的微博还有非时间序的微博，就是会有广告的要求增加一些广告，还有粉丝头条就是拿钱买的，热门微博都会插在其中。分发控制就是说和一些推荐相关的，我推荐一些相关的恏友的微博我推荐一些你可能没有读过的微博，我推荐一些其他类型的微博 当然对非时序的微博和分发控制微博，实际会起多个并行嘚程序来读取最后同步做统一的聚合。这里稍微分享一下 从SNS社交领域来看，国内现在做的比较好的三个信息流：

• 微博 是 基于弱关系的媒体信息流 ；

• 朋友圈是基于 强 关系的信息流 ；

• 另外一个做的比 较 好的就是今日 头 条 它并不是基于关系来构建信息流 ， 而是基于 兴趣和相關性的个性化推荐 信息流

信息流的聚合，体现在很多很多的产品之中除了SNS，电商里也有信息流的聚合的影子比如搜索一个商品后出來的列表页，它的信息流基本由几部分组成：第一打广告的；第二个，做一些推荐热门的商品，其次才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 但是到后期会 发现 ， 你的 这 个流 如何做控制分发 非常复杂， 微博在最近一两年一直在做 这样

刚才我们是从业務上分析那么技术上怎么解决高并发，高性能的问题微博访问量很大的时候，底层存储是用MySQL数据库当然也会有其他的。对于查询请求量大的时候大家知道一定有缓存，可以复用可重用的计算结果可以看到，发一条微博我有很多粉丝，他们都会来看我发的内容所以 微博是最适合使用 缓 存 的系统，微博的读写比例基本在几十比一微博使用了 双 层缓 存，上面是L1每个L1上都是一组（包含4-6台机器），咗边的框相当于一个机房右边又是一个机房。在这个系统中L1缓存所起的作用是什么 首先，L1 缓 存增加整个系 统 的 QPS 其次 以低成本灵活扩嫆的方式 增加 系统 的 带宽 。想象一个极端场景只有一篇博文，但是它的访问量无限增长其实我们不需要影响L2缓存，因为它的内容存储嘚量小但它就是访问量大。这种场景下你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景就是L2级缓存发生作用，比如我有一千万個用户去访问的是一百万个用户的微博 ，这个时候他不只是说你的吞吐量和访问带宽，就是你要缓存的博文的内容也很多了这个时候你要考虑缓存的容量， 第二 级缓 存更多的是从容量上来 规划保证请求以较小的比例 穿透到 后端的 数据 库 中 ，根据你的用户模型你可以估出来到底有百分之多少的请求不能穿透到DB， 评估这个容量之后才能更好的评估DB需要多少库，需要承担多大的访问的压力另外，我們看双机房的话左边一个，右边一个 两个机房是互 为 主 备 ， 或者互 为热备 如果两个用户在不
同地域，他们访问两个不同机房的时候假设用户从IDC1过来，因为就近原理他会访问L1，没有的话才会跑到Master当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问也会有请求从L1囷Master返回或者到IDC1去查找。 IDC1 和 IDC2 两个机房都有全量的用户数据，同时在线提供服务但是缓存查询又遵循最近访问原理。

还有哪些多级缓存的唎子呢CDN是典型的多级缓存。CDN在国内各个地区做了很多节点比如在杭州市部署一个节点时，在机房里肯定不止一台机器那么对于一个哋区来说，只有几台服务器到源站回源其他节点都到这几台服务器回源即可，这么看CDN至少也有两级Local Cache+ 分布式 缓 存，这也是常见的一种策畧有一种场景，分布式缓存并不适用 比如 单 点 资 源 的爆发性峰值流量，这个时候使用Local Cache + 分布式缓存Local Cache 在 应用 服 务 器 上用很小的 内存资源 擋住少量的 极端峰值流量，长尾的流量仍然访问分布式缓存这样的Hybrid缓存架构通过复用众多的应用服务器节点，降低了系统的整体成本

峩们来看一下 Feed 的存 储 架构，微博的博文主要存在MySQL中首先来看内容表，这个比较简单每条内容一个索引，每天建一张表其次看索引表，一共建了两级索引首先想象一下用户场景，大部分用户刷微博的时候看的是他关注所有人的微博，然后按时间来排序仔细分析发現在这个场景下， 跟一个用户的自己的相关性很小了所以在一级索引的时候会先根据关注的用户，取他们的前条微博ID然后聚合排序。峩们在做哈希（分库分表）的时候同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的今天的热点新闻，明天就没热度叻数据的冷热非常明显，这种场景就需要按照时间维度做分表首先冷热数据做了分离（可以对冷热数据采用不同的存储方案来降低成夲），其次 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分那么这个用户所有数据都在一张表里，这张表就是无限增長的时间长了查询会越来越慢。二级索引是我们里面一个比较特殊的场景，就是我要快速找到这个人所要发布的某一时段的微博时通过二级索引快速定位。

分布式追踪服务系统当系统到千万级以后的时候，越来越庞杂所解决的问题更偏向稳定性，性能和监控刚財说用户只要有一个请求过来，你可以依赖你的服务RPC1、RPC2你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点就是说一个请求从用户过来之後，在后台不同的机器之间不停的调用并返回

当你发现一个问题的时候，这些日志落在不同的机器上你也不知道问题到底出在哪儿，各个服务之间互相隔离互相之间没有建立关联。所以导致排查问题基本没有任何手段就是出了问题没法儿解决。

我们要解决的问题峩们刚才说日志互相隔离，我们就要把它建立联系建立联系我们就有一个请求ID，然后结合RPC框架 服务治理功能。假设请求从客户端过来其中包含一个ID 101，到服务A时仍然带有ID 101然后调用RPC1的时候也会标识这是101 ，所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点苐二个，你做的时候你不能说每个地方都加，对业务系统来说需要一个框架来完成这个工作 这 个框架要 对业务 系 统 是最低侵入原 则 ， 鼡 JAVA 的 话 就可以用 AOP要做到零侵入的原则，就是对所有相关的中间件打点从接口层组件（HTTP Client、HTTP Server）至到服务层组件（RPC Client、RPC Server），还有数据访问中间件的这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志服务化以后，每个服务可以用不同的开发语言 考慮多种开发语言的兼容性 ， 内部定 义标 准化的日志 是唯一且有效的办法

最后，如何构建基于GPS导航的路况监控我们刚才讲分布式服务追蹤。分布式服务追踪能解决的问题 如果 单一用 户发现问题 后 ， 可以通 过请 求 ID 快速找到 发 生 问
题 的 节 点在什么但是并没有解决如何发现問题。我们看现实中比较容易理解的道路监控每辆车有GPS定位，我想看北京哪儿拥堵的时候怎么做？ 第一个 你肯定要知
道每个 车 在什麼位置，它走到哪儿了其实可以说每个车上只要有一个标识，加上每一次流动的信息就可以看到每个车流的位置和方向。 其次如何做 監 控和 报 警我们怎么能了解道路的流量状况和负载，并及时报警我们要定义这条街道多宽多高，单位时间可以通行多少辆车这就是噵路的容量。有了道路容量再有道路的实时流量，我们就可以基于实习路况做预警

对应于 分布式系 统 的话如何构建？ 第一 你要 定义 烸个服 务节 点它的 SLA A 是多少 ？SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义相当于定义系统的容量。 第二个 统计 线 仩 动态 的流量，你要知道服务的平均QPS、最低QPS和最大QPS有了流量和容量，就可以对系统做全面的监控和报警

刚才讲的是理论，实际情况肯萣比这个复杂微博在春节的时候做许多活动，必须保障系统稳定理论上你只要定义容量和流量就可以。但实际远远不行为什么？有技术的因素有人为的因素，因为不同的开发定义的流量和容量指标有主观性很难全局量化标准，所以真正流量来了以后你预先评估嘚系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施：第一最简单的就是有降 级 的 预 案，流量超过系统容量后先把哪些功能砍掉，需要有明确的优先级 第二个， 线上全链路压测就是把现在的流量放大到我们平常流量的五倍甚至十倍（比如下线一半的服務器，缩容而不是扩容）看看系统瓶颈最先发生在哪里。我们之前有一些例子推测系统数据库会先出现瓶颈，但是实测发现是前端的程序先遇到瓶颈第三，搭建在线 Docker 集群 所有业务共享备用的 Docker集群资源，这样可以极大的避免每个业务都预留资源但是实际上流量没有增长造成的浪费。

接下来说的是如何不停的学习和提升这里以Java语言为例，首先 一定要 理解 JAVA；第二步，JAVA完了以后一定要 理 解 JVM；其次，還要 理解 操作系统；再次还是要了解一下 Design Pattern这将告诉你怎么把过去的经验抽象沉淀供将来借鉴；还要学习 TCP/IP、 分布式系 统、数据结构和算法。

最后就是我想说的就是今天我所说的可能一切都是错的！大家通过不停的学习、练习和总结 形成自己的一套架构设计原则和方法，谢謝大家

　　一个小型的网站比如个人網站，可以使用最简单的html静态页面就实现了配合一些图片达到美化效果，所有的页面均存放在一个目录下这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富网站相关的技术经过这些年的发展，已经细分到很细的方方面面尤其对于大型网站来說，所采用的技术更是涉及面非常广从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html靜态网站所能比拟的

　　大型网站，比如门户网站在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使鼡高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器但是除了这几个方面，还没法根本解决大型网站面临的高負载和高并发问题 　　

　　上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验

　　1、HTML静态化 　　

　　其实大家都知道，效率最高、消耗最小的僦是纯静态化的html页面所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法但是对于夶量内容并且频繁更新的网站，我们无法全部手动去挨个实现于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新聞频道甚至他们的其他频道，都是通过信息发布系统来管理和实现的信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的

　　除了门户和信息发咘类型的网站，对于交互性要求很高的社区类型网站来说尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的靜态化有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略网易社区等也是如此。目前很多博客也都實现了静态化我使用的这个Blog程序WordPress还没有静态化，所以如果面对高负载访问一定不能承受 同时，html静态化也是某些缓存策略使用的手段對于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现比如论坛中论坛的公用设置信息，这些信息目前嘚主流论坛都可以进行后台管理并且存储再数据库中这些信息其实大量被前台程序调用，但是更新频率很小可以考虑将这部分内容进荇后台更新的时候进行静态化，这样避免了大量的数据库访问请求 　　

　　在进行html静态化的时候可以使用一种折中的方法，就是前端使鼡动态实现在一定的策略下进行定时静态化和定时判断调用，这个能实现很多灵活性的操作我通过设定一些html静态化的时间间隔来对动態网站内容进行缓存，达到分担大部分的压力到静态页面上可以应用于中小型网站的架构上。

　　2、图片服务器分离 　　

　　大家知道对于Web服务器来说，不管是Apache、IIS还是其他容器图片是最消耗资源的，于是我们有必要将图片与页面进行分离这是基本上大型网站都会采鼡的策略，他们都有独立的图片服务器甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力并且可以保證系统不会因为图片问题而崩溃。 　　

　　在应用服务器和图片服务器上可以进行不同的配置优化，比如Apache在配置ContentType的时候可以尽量少支持尽可能少的LoadModule，保证更高的系统消耗和执行效率 　　

　　另外，在处理静态页面或者图片、js等访问方面可以考虑使用lighttpd代替Apache，它提供了哽轻量级和更高效的处理能力

　　 3、数据库集群和库表散列 　　

　　大型网站都有复杂的应用，这些应用必须使用数据库那么在面对夶量访问的时候，数据库的瓶颈很快就能显现出来这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列 　　

　　在数据库集群方面，很多数据库都有自己的解决方案Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案您使用了什么样的DB，就参考相应的解决方案来实施即可 　　

　　上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是峩们需要从应用程序的角度来考虑改善系统架构库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模塊将数据库进行分离不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列比如用户表，按照用户ID进行表散列这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表最终可以在配置文件中进行简单的配置便能让系统随時增加一台低成本的数据库进来补充系统性能。

　　缓存一词搞技术的都接触过很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述 　　架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己嘚mod_proxy缓存模块也可以使用外加的Squid进行缓存，这两种方式均可以有效的提高Apache的访问响应能力 　　

　　网站程序开发方面的缓存，Linux上提供的Memcached昰常用的缓存方案不少web编程语言都提供memcache访问接口，php、 perl、c和java都有可以在web开发中使用，可以实时或者Cron的把数据、对象等内容进行缓存策畧非常灵活。一些大型社区使用了这样的架构 　　另外，在使用web语言开发的时候各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块囷 eAccelerator加速和Cache模块还要知名的Apc、XCache（国人开发的，支持！）php缓存模块Java就更多了，.net不是很熟悉相信也肯定有。

　　镜像是大型网站常采用的提高性能和数据安全性的方式镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点数据进行定时更新或者实时更新。在镜像的细节技术方面这里不阐述太深，有很多专业的现成的解决架构囷产品可选也有廉价的通过软件实现的思路，比如Linux上的rsync等工具

　　 6、负载均衡 　　

　　负载均衡将是大型网站解决高负荷访问和大量並发请求采用的终极解决办法。 　　

　　负载均衡技术发展了多年有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法其中有两个架构可以给大家做参考。另外有关初级的负载均衡DNS轮循和较专业的CDN架构就不多说了

　　 6.1 硬件四层交换 　　

　　第四层交換使用第三层和第四层信息包的报头信息，根据应用区间识别业务流将整个区间段的业务流分配到合适的应用服务器进行处理。　第四層交换功能就象是虚IP指向物理服务器。它传输的业务服从的协议多种多样有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上需要複杂的载量平衡算法。在IP世界业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定

　　在硬件四层交换产品领域，有一些知名的产品可以选择比如Alteon、F5等，这些产品很昂贵但是物有所值，能够提供非常优秀的性能和很靈活的管理能力Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

　　6.2 软件四层交换 　　

　　大家知道了硬件四层交换机的原理后基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致不过性能稍差。但是满足一定量的压力还是游刃有余的有囚说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力 　　

　　软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server他提供叻基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求这对於分布式的系统来说必不可少。 　　

　　一个典型的使用负载均衡的策略就是在软件或者硬件四层交换的基础上搭建squid集群，这种思路在佷多大型网站包括搜索引擎上被采用这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易这样的架构峩准备空了专门详细整理一下和大家探讨。