网站架构

6、使用反向代理和CDN加速网站响应 为了进一步加快网站的访问速度，可以考虑使用CDN和反向代理。CDN部署在网络提供商的机房，当用户访问时，可以从距离用户最近的网络提供商机房获取数据。反向代理部署在网站自己的中心机房，当用户请求到达机房时，优先访问的服务器是反向代理服务器，如果反向代理中缓存了用户请求的资源，那么就直接返回给用户，加快了响应的速度，也减轻了后端负载的压力。CDN与反向代理的基本原理都是缓存。 这一阶段涉及到的知识体系： 需要了解CDN和反向代理相关的知识 | 7、数据库的分库分表（垂直/水平拆分）及分布式文件系统 我们的网站演进到现在，用户、商品、交易的数据都还在同一个数据库中。尽管采取了增加缓存，读写分离的方式，但随着数据库的压力继续增加，数据库的瓶颈越来越突出，此时，我们可以采用分库分表两种方法进行解决。 分库： 又叫垂直拆分 ，就是把数据库中不同的业务数据拆分到不同的数据库中，结合现在的例子，就是把用户、商品、交易的数据分开。优点：解决了原来把所有业务放在一个数据库中的压力问题，可以根据业务的特点进行更多的优化。缺点：需要维护多个数据库。 分库所遇到的问题： 1）需要考虑原来跨业务的事务；2）跨数据库的join 解决方案： 在应用层尽量避免跨数据库的事物，如果非要跨数据库，尽量在代码中控制。我们可以通过第三方应用来解决，如上面提到的mycat

我也要谈谈大型网站架构之系列（4）——分布式中的异步通信 　　我们知道在面向对象编程中，总会想着各种办法来实现代码的解耦，从而让项目中的各种人员面对自己熟悉的业务进行开发， 做到术业有专攻，比如大家非常熟悉的三层架构，MVC，MVP以及MVVM模式，让前端设计专注于html的制作，让后端开发人员 更加专注于业务逻辑的编写，可以看到，我们这么做的目的就是想最大程度的做到系统的可扩展和可维护性，那么我们的大型网站 是不是也要遵守这种模式呢？ 一：分层和分割 1：分层 对于分层，我们可能非常熟知了，数据访问层，业务逻辑层，缓存层，应用层，层层专注于自己的业务，然后根据需要建立起 各自的集群，各自分离部署，而从达到系统的扩展性和维护性。 2：分割 如果说前面是横向切割，那分割就是纵向切割，我们可以把网站的整体业务切分成很多的小业务，比如博客园的导航栏，我们都 可以认为是一个独立的网站，配上各自的二级域名，建立各自的集群来实现系统的扩展性，当然这个粒度可大可小。 如果说这些子网站不存在相互调用，那么我们新增模块或者修改模块基本上都不会对其他模块造成影响，这也是我们做扩展性的终极 目标，现在既然都做到解耦了，下面的目标就是做如何通信了，通信可以分为“同步”和“异步”，这篇主要是讨论下异步操作，在分布式 系统中做到"异步操作“，当然少不了强大的消息队列。 二：消息队列

我也要谈谈大型网站架构之系列（3）——死了都要说的缓存 　　说到缓存，我想大家跟我一样都很兴奋，当我们遭遇网站性能瓶颈的时候，缓存是一剂强心针，也是一粒紧急妈富隆，从而在优化网站 性能方面冠上了第一定律的帽子，我们前年在做淘应用的时候，就遭遇了性能瓶颈，短时间内采用缓存紧急优化，给我们大优化之前争取了 宝贵的时间。 一：缓存的种类 要说缓存有多少种，太多了，比如浏览器缓存，文件缓存，片段缓存，数据库缓存等等，合理利用这些缓存则能大幅度的提高系统性能， 利用不好反而会偷鸡不成蚀把米，给服务器造成巨大的压力，所以这里就存在一个缓存的使用原则的问题。 二：合理的使用缓存 1. 读写小于10:1的情况下，不适合用缓存，我们用缓存的目的就是想分摊下数据库的压力以及利用内存来提速性能，如果读写差不多，或者 压根就没读过，这样的死数据就会造成内存资源的浪费。 2. 既然是缓存，就注定了它的资源是有限的，宝贵的，也就注定了我们必须合理利用它的内存空间，也就被迫的让我们清楚的认识到热点数据， 　 不易修改的应该放在缓存，反之不宜放。 3. 大公司在缓存方面做的好的地方就是在一个“控”字上，他们会为缓存专门做一套“缓存系统”，当系统预加载的时候，同时也充当内存数据库 使用，将这些元数据加载到缓存系统中，比如“县市区”，“分类信息”等等作为预热数据。 三：分布式缓存 一般情况下，会有两种形式

我也要谈谈大型网站架构之系列（2）——纵观历史演变（下） 　　这篇文章本来准备前几天就得写的，谁也没想到这段时间公司的RC太多了，含酸苦逼的加班，加班。。。所以在大一点的公司上班， 写代码的责任心一定要强，或许就因为你的一些小bug，给公司带来不少损失。。。这在以前公司真的没多大体会的。 　　好了，继续说说架构的演变，从第四代架构中可以看到，我们通过做应用程序层的负载均衡可以比较完美的解决了在整个架构中让应 用程序层不再成为瓶颈，通过A10，我们可以让用户的访问请求分发到集群中的任何一台服务器上，当访问量继续膨胀的时候，我们就可 以继续在集群中增加服务器来解决负载的压力，达到系统的可伸缩性，现在我们的业务规模像滚雪球一样越来越大，用户数暴增。。。这 时候我们缓存中的数据也越来越多，虽然我们用了缓存，但是大量的“ 缓存过期重新读取 ”和“ 缓存不命中 ",导致数据库压力非常大，这时候 数据库的压力成为了我们架构中的瓶颈。 五： 第五代架构 　　 既然数据库成为了我们第四代架构的瓶颈，这时候必须解决数据库的压力问题，最常见的做法也就是“读写分离”，将写和读的库进行拆 分来缓解数据库的压力。 　　 现在我们做了多个库，写的时候进主库，然后数据库分发到从库中，然后应用程序在从库中读取，这里为了让数据库对应用程序更加 透明，我们通常加一个“数据访问层”

1 前言 即使是在传统的企业当中，日常的备份、服务器状态监控和日志，通过手动的方式来进行的效率也很低，是一种人力的浪费。因此，自动化早已是每个运维都必须掌握的看家本领。 在不同的企业中，自动化的规模、需求与实现方式都各不相同，因此在技术细节层面，运维之间很难将别的企业的方法整个套用过来。然而在很多情况下，自动化的思路是有共通之处的。 运维自动化前三阶段 ◆纯手工阶段：手工操作重复地进行软件部署和运维。 ◆脚本阶段：通过编写脚本、方便地进行软件部署和运维。 ◆工具阶段：借助第三方工具高效、方便地进行软件部署和运维。 这几个阶段是随着运维知识、经验、教训不断积累而不断演进的。而且，第2个阶段和第3个阶段可以说是齐头并进，Linux下的第三方工具虽说已经不少了，但是Linux下的脚本编写对运维工作的促进作用是绝对不可以忽视的。 在DevOps出现之前，运维工作者在工作中还是以这两种方式为主。 下面的研究，都是一些linux下开源的第三方工具，借助第三方工具高效、方便地进行软件部署和运维。 2 业界开源的自动化部署工具 2.1 chef Chef 是一款自动化服务器配置管理工具，可以对所管理的对象实行自动化配置，如系统管理，安装软件，基于ruby语言编写的。 2.1.1 Chef的架构 2.1.2 Chef的工作原理： Chef 由三大组件组成：Chef Server、Chef

课程主讲： 互联网应用高级架构师 白贺翔 涉及技术： Redis 、 SSDB 、 Memcached 课程描述： 介绍互联网 分布式 技术的重要性、背景、应用范围；目前互联网行业使用分布 式缓存进行设计的比例，以及大型网站使用的方式和方法，讲解分布式 缓存技 术 、数据类型、实战应用场景、缓存库主从同步、读写分离、高并发、安全性、 事务特性、分布式锁、负载均衡、 Session 共享、发布订阅、数据持久化、哨兵、 高可用、可扩展性、水平垂直扩容、集群环境搭建与应用等。 课程目录 01_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第一节 02_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第二节 03_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第三节 04_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第四节 05_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第五节 06_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第六节 07_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第七节 08_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第八节 09_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第九节 教程下载地址： 互联网分布式缓存技术 本文来自 >> 尚学堂 ； 转载请注明

#何为大型网站# ##大型网站特性## 既然说的是大型网站架构，那么 架构的背后自然是解决人因面对大型网站特性而带来的问题 。这样可以先给大家说下大型网站的特性， 这些特性带来的问题就是人要解决的问题 ： 高并发、大流量：PV 量巨大； 高可用：7*24 小时不间断服务； 海量数据：文件数目分分钟 xxTB； 用户分布广泛，网络情况复杂：网络运营商； 安全环境恶劣：黑客的攻击； 需求快速变更，发布频繁：快速适应市场，满足用户需求； 渐进式发展：慢慢地运营出大型网站； ##大型网站目标## 既然说到了大型网站的特性，那么**解决这些特性带来的问题要达到什么目标呢？**如下： 每个目标背后面临着技术、设计、维护等诸多方面的挑战； 而目标本身的期望值也会根据实际情况进行调整，这也意味着网站架构建设是个不断调整的过程。 有了问题，也定了伟大的目标，那么网站在不同阶段面对不同的问题，是如何解决的？又是如何一步步成长为大型网站架构，实现这些伟大的目标呢？ ##如何网站架构## 首先，什么是大型网站架构呢？ 其实大型网站架构的概念对于每一个开发者来说很笼统、很模糊，正如盲人摸象，看到的、了解到的只是很小的一部分，大部分情况下我们只是负责架构中的一小块内容，所以很难清晰地给出具体定义。这就是所谓“不识庐山真面目 只缘身在此山中”的尴尬吧。所以我们要跳出来，站在宏观的角度

TSP：每秒的事务数，是吞吐量的一个常用化指标，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。 参考 HPS：每秒HTTP请求数 QPS：每秒查询数，是一台服务器每秒的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准 System Load：系统负载，指当前正在被CPU执行和等待被CPU执行的进程数目总和，是反应系统忙闲程度的重要指标 贫血模式和充血模式 资源复用的两种主要模式：单例（Singleton）和对象池（Object Pool） 缓存memcached和redis 来源： https://www.cnblogs.com/baisheng/p/11877646.html

我也要谈谈大型网站架构之系列（1）——纵观历史演变（上） 　　我们知道一个网站都是随着业务的发展，逐渐演变成几万服务器，几亿用户数的大型网站，经历了若干年，甚至上十年的 发展成为大型网站，然而真正亲身经历这个发展过程的人已经不多了，这种人也是拿着公司股票，赶都赶不走的人，所以正因 为很多人没有亲身经历过，所以对架构的演变没有深刻的了解，包括我自己在内，不过没吃过猪肉，也看过猪跑。。。 一：第一代架构 　　这年头创业大多都是从穷屌丝开始的，奔着 “快好省”的原则建立网站，将“应用程序”，“文件”，“数据库”通通放在一台服务 器上，匆匆的就走上了网站架构之路。 我们知道业务的发展对技术会有更高的要求，业务的创新会触动技术的创新，当业务逐渐发展起来的时候，最容易出现的问题就是 ”存储空间“和通用的”性能低下“，这个时候就需要做到”应用程序“和”数据“的分离。 二：第二代架构 　 随着业务规模的扩大，需要将”应用程序“，”文件“，”数据库“进行分离，用更强大的cpu处理服务器来承载应用程序，记得在上一 家用的cpu就是16核，”文件“的话则需要更大的磁盘空间的服务器，”数据库“的话需要更大的磁盘和超大内存的服务器，我们知道 sqlserver还是很吃内存的，记得用过最大的是120g的内存。 随着业务规模不断扩大，访问人数逐渐增多，我们也开心了，起码挣到钱了

1. 从RDBMS到NoSQL的架构演化 互联网时代背景下大机遇，为什么用nosql 1 单机MySQL的美好年代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 在那个时候，更多的都是静态网页，动态交互类型的网站不多。 上述架构下，我们来看看数据存储的瓶颈是什么？ 1.数据量的总大小 一个机器放不下时 2.数据的索引（B+ Tree）一个机器的内存放不下时 3.访问量(读写混合)一个实例不能承受 如果出现了上述1 or 3个上述瓶颈，架构开始演化到下一个阶段： 2 Memcached(缓存)+MySQL+垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。 Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展