大型网站技术架构演变辩析.pptx

大型网站技术架构演变 黄若儒 大型网站软件系统的特点 高并发、大流量——需要面对高并发用户，大流量访问。 高可用——系统7x24小时不间断服务。 海量数据——需要存储、管理海量数据，需要使用大量服务器。 用户分布广泛，网络情况复杂——需要为全球范围的用户提供服务。 安全环境恶劣——互联网开放性，导致更容易受到攻击。 需求快速变更，发布频繁——需要快速适应市场，满足用户需求。 渐进式发展——没有全盘一篮子规划，只有基于实际的无限变更发展 初始架构 小型网站最开始没有太多人访问，一台服务器绰绰有余 应用、数据库、文件都在一台机 使用以开源免费的软件为主（Apache、MySQL、Tomcat…） 应用服务和数据服务分离 用户访问越来越多，性能越来越差 数据越来越多导致存储空间不足 3台服务器分别存放应用程序、非结构化数据、结构化数据 应用服务器独立部署使之能占用更多CPU、内存资源 数据库服务器独立部署使之能占用更多CPU、内存、硬盘 文件服务器独立部署使之能够占用更多硬盘空间 并发处理能力和数据存储空间得到很大改善！ 使用缓存改善网站性能 基于2~8原则（ 80% 业务访问集中在20%的数据上） 读多写少 缓存分类：本地缓存、远程缓存 本地缓存快，但受限单机缓存容量，可缓存内容少；不利于分布式应用架构（ACD） 远程缓存有网络损耗，但可缓存内容多，扩展性高。 数据访问压力得到有效缓解 使用应用服务器集群改善网站的并发处理能力 应用服务器处理请求连接有限，存在瓶颈 提升单一服务器性能花费巨大，扩展能力有限，存在瓶颈 通过增加更多服务器，提升请求处理能力，可伸缩 应用服务器集群式网站可伸缩集群架构设计中较为简单成熟的一种 利用负载均衡调度服务器，实现按需请求分发 负载均衡调度可以是软件级、硬件级、网络级 请求再多也能通过扩展支撑 数据库读写分离 存在不能缓存的情况多，数据库写入也不少的情况下，数据库负载压力成为网站瓶颈 利用热备功能，配置主-从关系，实现读-写分离，分摊单一节点数据库压力 利用独立数据库访问模块，实现读写分离调度，对应用透明 读、写分离调度模块，可以是独立硬件，也可以程序级调度程序 主-从复制基于时间调度（简单但不够实时）或事件调度（复杂但相对精准） 使用反向代理和CDN加速网站响应 中国网络环境复杂，不同地域访问速度存在差异 单一网络节点无法“公平”地提供一致的访问质量 利用CDN及反向代理机制，缓存静态数据 为用户请求分派距离最近的网络服务点 减轻服务核心支撑点的访问压力 使用分布式文件系统和分布式数据库系统 集中式存储（文件、数据库）无法满足庞大数据量环境 分布式数据库是数据库拆分的最后手段，只有单表数据规模非常庞大的时候才使用 网站更常用的数据库分拆手段是业务分库 分布式数据库及文件架构，就应用程序而言，不透明 一般需要与集群式、分布式架构中作出权限后才决定方案 使用NoSQL和搜索引擎 数据存储和检索需求越来越复杂 传统关系型技术无法满足需求（存储、速度） 数据交互能力大大提升 一般都会涉及集群架构 对持久化、ACD需要有折冲 业务拆分 大型网站业务场景复杂，需要分而治之地解决不同业务（产品线问题）问题 根据业务划分多个不同产品线及板块，由不同业务团队负责，并最终提供不同服务 不同应用独立部署，通过链接、消息队列、接口服务进行交互通讯，最多的是通过共享同一存储系统实现关联 性能减弱 可用性提升 维护更容易，项目更简单 分布式服务 存储系统越来越庞大，整体复杂度指数级增长 部署维护困难 资源链接数是服务器规模的平方，出现链接资源不足 大型网演化的价值观 大型网站都是从小型网站发展而来 网站价值在于它能为用户提供什么价值 大型网站架构技术的核心价值是：随网站所需，灵活应对 驱动大型网站技术发展的主要力量是网站的业务发展 网站架构设计误区 一味追随大公司的解决方案 为了技术而技术 企图用技术解决所有问题 网站架构模式 分层（应用层（视图、业务逻辑）、服务层（接口、逻辑）、数据层（结构化、非结构化、缓存）），横向划分 分割（功能、业务、数据），纵向划分 分布式（分布式应用和服务、分布式静态资源、分布式数据和存储、分布式计算） 集群 缓存（CDN、反向代理、本地缓存、分布式缓存） 异步 冗余 自动化（发布过程（代码管理、测试、安全检查、部署）、监控（检查、报警、失效转移、失效回复、降级、资源分配）） 安全 推荐阅读 《大型网站技术架构演变》 《大型分布式网站架构》 《大型网站系统与Java中间件》