精华内容
下载资源
问答
  • 互联网的架构演进过程分为三个时代:单机时代、集群时代和分布式时代。三个时代并非按照历史时间顺序排列,更多的是由团队或产品所处的时期来决定。 二、过程 单机时代 互联网早期,好比杭研某个产品团队初创...

    一、导读

    互联网的架构演进过程分为三个时代:单机时代、集群时代和分布式时代。三个时代并非按照历史时间顺序排列,更多的是由团队或产品所处的时期来决定。

    二、过程

    • 单机时代

      互联网早期,好比杭研某个产品团队初创之时,资源有限,人力不足,为了快速开发一个产品,或上线一个网站,单机往往是一个不错的选择,此时会将应用程序、文件服务、数据库服务等资源集中在一台 Server 上。其中应用程序通常整体打包和部署,具体格式依赖于应用的语言和框架,例如 Java 的 WAR 文件、Rails 的目录文件,此种架构通常称为单体架构。

      单体架构

      其系统架构图往往长这个样子:
      在这里插入图片描述
      图-1: 单机时代-ALL IN ONE
      优点:如上文所述,简单快速,易于开发,易于测试,易于部署
      缺点:也非常显著,只适合早期项目,变大后不易维护,且存在单点,升级需要停服

      分层架构

      明眼的人很快发现,此时的应用程序架构显得杂乱无章,这在早期的 Web 开发中可能存在,比如使用 JSP+JDBC,ASP+ADO,但这显然不是一个友好的标准架构,于是分层架构应运而生,分层架构如下图所示,一般分为表现层(presentation)、业务层(business)、持久层(persistence)和数据库(database)。这其实也是最常见的 MVC 架构了。
      在这里插入图片描述
      图-2: 单机时代-软件架构-分层架构
      改造之后的系统架构图如下:
      在这里插入图片描述
      图-3: 单机时代-分层架构
      优点:结构简单,分工明确,分层测试,如果你不知道用什么软件架构时,推荐用它
      缺点:扩展性差,迭代开发效率低,有时候层次过多导致流程复杂

      数据分离

      添加了分层架构,应用上好看点了,团队的开发效率有了一定的提升。此时业务量进一步增大,并且有了一定的用户规模,逐渐发现一台主机上应用和数据资源争夺的非常厉害。因为每种服对硬件资源的要求是不同的,应用服务器需要更快的CPU,文件服务器需要更大的硬盘,数据库服务器需要更大的内存和硬盘,于是决定把应用和数据服务分离,形成了如下架构:
      在这里插入图片描述
      图-4: 单机时代-数据分离
      优点:资源分散,提高不同服务对硬件的利用率,方便维护
      缺点:增加了资源消耗和网络开销,同时还存在单点

      缓存登场

      产品有了一定的口碑,用户量持续增长,访问开始频繁,想提升访问速度,缓存必不可少,闪亮登场。
      在这里插入图片描述
      图-5: 单机时代-缓存登场
      服务端缓存又可以分为本地缓存和远程缓存,各有优劣,本地缓存访问速度快,但数据量有限,而且后续集群化不方便共享;远程缓存可以共享,可以集群,容量不受限制,但要注意缓存更新的问题。
      优点:简单有效,减少对 DB 的查询
      缺点:增加逻辑判断,不适合存储大对象,此架构同样有单点

      读写分离

      市场反响不错,业务也在持续增长,但性能又有所下降,分析整个架构,发现数据库读写非常频繁,甚至有些业务,读大于写,单台数据库服务器又成了瓶颈,此时就可以尝试做读写分离和主从复制了。
      在这里插入图片描述
      图-6: 单机时代-读写分离
      优点:降低数据库单台压力,从机的数量可以灵活变更
      缺点:架构开始变得复杂,维护难度加大
      自此,单机时代的架构已然成型,“麻雀虽小五脏俱全”,初期已经能很好的支撑业务的运转。但随着业务的增长,各个模块还是可能出现瓶颈。而单机时代最大的问题,就是整个架构都存在单点,这个问题将在集群时代一一解决。

    • 集群时代

      单机时代,做了不少措施来缓解数据库层的压力,包括服务器分离、引入缓存、数据分离等,但随着访问量的猛增,对高可用的要求越来越高,减轻应用层压力、解决单点问题是当务之急,这就是集群时代需要做的事情。

      负载均衡

      代码是架构的基础,但前期改造代码的工作量较大,如果人员变动频繁,那风险就更高了,所以提高服务器性能,常用的手段还是先将应用集群化,做负载均衡。
      在这里插入图片描述
      图-7: 集群时代-负载均衡
      优点:去除应用层单点,可用性得到保证,性能有所提高
      缺点:这时要注意应用之间的一致性问题,比如对缓存的访问,对Session的存储

      冗余集群

      以上一个中型网站架构基本成型。当中型网站继续向大型网站演进,最终的目标是要保证“三高”:高并发、高性能、高可用。以上架构基本可以满足性能需求,接下来更多的是关注“高可用”,确保“无单点”。
      此时,就要对关键的服务,做冗余集群负载。
      理想情况下,我们将以下服务/应用都集群化:
      数据库服务集群
      文件服务集群
      缓存服务集群
      应用服务集群
      负载均衡调度器集群
      静态内容服务集群
      CDN服务器集群
      在这里插入图片描述
      图-10: 集群时代-冗余集群
      优点:去单点,高可用
      缺点:数据有状态问题、数据一致性问题,资源成本、人力维护成本都上去了
      到此为止,一个大型网站的架构也基本成型了,能“加机器”的地方都加完了,是不是就终结?当然不是!伴随着 DT/分布式 时代的到来,大流量和大数据的场景的出现,对应用提出了更高的要求,接下来就需要对应用程序开刀了。

    • 分布式时代

      应用拆分

      在前面,我们只是把应用程序做了分层架构,在创业初期或产品前期还是一个不错的选择。虽然应用也做了集群和负载均衡,但应用架构层面还是“集中式”的。随着业务越来越复杂,网站的功能越来越多,应用拆分势在必行了。
      优点:应用解耦,分拆团队负责,分而治之
      缺点:架构变复杂
      应用拆分之后,还伴随着一个相互依赖、公共模块的问题,特别是依赖于相同的逻辑或功能代码。这时就可以考虑将这些共用的服务提取出来,独立部署,统一治理,提高重用度,这就是面向服务的架构(service-oriented architecture,缩写 SOA)了。

      消息队列

      应用拆分、服务独立部署之后,还是会出现一些通信或依赖问题,这时就可以引入消息队列,提高吞吐量。
      优点:异步、解耦,提高吞吐量
      缺点:消息消费延迟等问题
      数据分库
      应用拆分之后,DB分库理所当然,否则多个应用连接在单个数据库上,连接数、QPS、TPS、I/O处理能力都非常有限。
      优点:DB分压,降低耦合
      缺点:数据访问模块冗余、复杂
      提到分库,不少人会想到分表,这一块我并未实践过,不好下笔。但想来会引入更复杂的数据架构和数据一致性问题,而且市面身上成熟开源的分库分表方案并没有,保不准又是一个深坑。拆或不拆,也是一个值得思考的问题。

      微服务架构

      微服务架构(microservices architecture)一度成为热点,在文章、博客、大会演讲上经常被提及。微服务并不是凭空出现,有人说,它是面向服务的架构(SOA)的升级,在此之前,还有诸如集中式架构、分布式的架构等。这里借用一副抽象的图来描述下常见的几种架构:
      在这里插入图片描述
      图-11: 分布式时代-微服务架构-抽象对比
      微服务架构由多个微小服务构成,每个服务就是一个独立的可部署单元或组件,它们是分布式的,相互解耦的,通过轻量级远程通信协议(比如REST)来交互,每个服务可以使用不同的数据库,而且是语言无关性的。它的特征是彼此独立、微小、轻量、松耦合,又能方便的组合和重构,犹如《超能陆战队》中的微型机器人,个体简单,但组合起来威力强大。
      在这里插入图片描述
      图-12: 分布式时代-微服务架构
      优点:扩展性好,服务之间耦合性低,服务间相互独立,容易部署,易于开发,方便测试每一个服务
      缺点:容易过度关注服务的大小,可能拆分的很细,导致系统依赖于大量的微服务,而服务之间的相互通信也会变得复杂,系统集成复杂度增加,很难实现原子性操作。
      微服务之所以这么火,另一个原因是因为 Docker 的出现,它让微服务有一个非常完美的运行环境,Docker 的独立性和细粒度非常匹配微服务的理念,Docker的优秀性能和丰富的管理工具,让大家对微服务有了一定的信息,概括来说 Docker 有如下四点适合微服务:
      独立性:一个容器就是一个完整的执行环境,不依赖外部任何的东西。
      细粒度:一台物理机器可以同时运行成百上千个容器。其计算粒度足够的小。
      快速创建和销毁:容器可以在秒级进行创建和销毁,非常适合服务的快速构建和重组。
      完善的管理工具:数量众多的容器编排管理工具,能够快速的实现服务的组合和调度。
      当然,好的架构和技术,要应用于实践、让用户认可才行,这就需要在微服务架构和 Docker 技术之上有丰富的场景化应用。网易蜂巢也在积极探索微服务架构和容器云平台的场景化服务,欢迎一起来实践落地。

    至此,架构变迁的三个时代介绍完成。总的来说架构不是一成不变的,时间不停,进步不止,人如此,架构依然。

    展开全文
  • 互联网演变过程

    2019-10-22 15:25:26
    文章目录互联网演变过程1 简介2 第一时期3第一时期的后期阶段集群**读写分离****搜索引擎**缓存引入数据库拆分问题4 第二时期(垂直架构)项目拆分解决的问题问题5 第三时期(分布式架构)分布式方案问题6 第时期...

    互联网演变过程

    1 简介

    • web1.0 时代

    • web2.0时代

    • 互联网时代

    • 云计算+大数据时代

      阿里Dubbo的演变也充分体现了互联网架构的演变

    在这里插入图片描述

    2 第一时期

    单一应用架构(All in one) 所有模块在一起,技术也不分层

    在这里插入图片描述

    网站的初期,也认为是换联网发展的最早期,会在单机部署上所有的应用和程序。

    所有的代码都是写在JSP里面,所有的代码都写在一起,这种方式成为 all in one。

    特点:

    1. 不具备代码的可维护性
    2. 容错性差
    容错性,是指软件检测应用程序所运行的原件或硬件中发生的错误并从错误中恢复能力,通常可以从系统的可靠性、可用性、可测性等几个方面衡量。
    
    单体地狱:只需要一个应用,将所有功能部署在一起,以减少部署节点和成本。
    

    3第一时期的后期阶段

    解决方案

    1. 分层开发(提高维护性)【解决容错性】
    2. MVC架构(Web应用程序的设计模式)
    3. 服务器的分离部署

    在这里插入图片描述

    特点:

    1. MVC分层开发
    2. 数据库分离部署

    问题:

    随着用户的访问量持续增加, 单台应用服务器无法满足需求。

    集群

    集群:同一个业务,部署在不同服务器上。

    在这里插入图片描述

    特点:

    1. 项目采用多台服务器(集群)部署。

    优点:

    1. 支持高并发。
    2. 支持高可用。

    问题:

    1. Session如何共享。

      Redis Cluster集群方案

    2. 这些集群的服务器、用户的请求该往哪里转发。

      用nginx服务器来完成分发请求、实现负载均衡策略机制。

    在这里插入图片描述

    问题:

    1. 我们通过集群方案nginx+taomcat将应用层的性能进行有效的提升。但是数据库的负载能力慢慢增加。

      怎么来提高数据库层面的访问压力(负载)。

    读写分离

    在这里插入图片描述

    读写分离:主从数据库之间的数据同步, Master负载增删改查、slave负责读写操作。

    mysql本身提供master-slave的方式完成主从复制的功能。

    搜索引擎

    数据库做读库的情况下、数据库本身对模糊查询的功能支持并不是特别优秀,像电商类的网站,搜索是非常核心的功能模块。即使做了读写分离这个问题也不能解决电商网页查询(分词技术)等,针对于该问题,引入搜索引擎。

    目前流行的搜索引擎: solr elasticsearch whoosh

    在这里插入图片描述

    缓存引入

    随着访问量的持续增加,数据库的访问压力变的越来越大(虽然做了主从复制)。 对于这些热点数据(用户访问频繁的信息),如果每次都到数据库中进行查询。(很多通用查询的功能)放在内存中又不特别合适。(手机登录验证码操作、为了Ip限制频繁访问服务器)尝试使用Redis。

    数据库拆分

    垂直扩展能力有限, 单个表:10002万到1亿(单个表的数据能力终归有限)。

    • 垂直拆分 冷热数据。

    • 水平拆分 按照:时间、地区(按照业务逻辑拆分)

    • 分库分表:采用第三方数据库中间件:mycat sharding-jdbc

    在这里插入图片描述

    当前状态:

    通过设计保证高可用、高并发

    问题

    • 问题1:服务器价格。

    • 问题2:可维护性差。

    • 问题3:可扩展性差。

    • 问题4:协同发展不方便。

    • 问题5:单体架构。导致服务部署时,文件变的越来越大。

    4 第二时期(垂直架构)

    垂直应用架构

    当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的Web框架(MVC)是关键。
    

    项目拆分

    拆分项目拆分完成后对项目进行聚合,提出概念父工程(ssm_parent)

    exam-parent
         pom.xml 项目需要在依赖信息、在父工程中定义、子模块继承。
      exam-commos
      exam-pojo
      exam-service
      exam-web
    

    利用Maven做的模块的拆分和聚合。

    解决问题:

    1. 模块复用

    2. 解决服务器部署内容变小

    垂直拆分:

    将一个大的应用拆分成互不相干的几个小应用, 每个应用都是独立的Web项目部署。

    在这里插入图片描述

    解决的问题

    1. 维护性(如果想做需求变更,只需要调整该应用模块即可)。
    2. 功能扩展(随着业务的不断增加,只需要创建新的应用即可)。
    3. 协同开发方便。
    4. 性能扩展。(只需要对访问量大的服务器多部署几台)。

    问题

    1. 随着业务的不断增加,各个模块交互频繁

    5 第三时期(分布式架构)

    分布式:将一个业务拆成多个子模块。

    当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式服务框架(RPC)是关键。
    

    在这里插入图片描述

    在这里插入图片描述

    以前如果在同一台服务器(模块之间的调用)

    通过上图发现,不同的应用在不同的服务器上,服务之间的调用(RPC)

    分布式方案

    • RPC (Remote procedure call)Dubbo
    • HTTP - spring cloud

    架构的改变一定会带来新的技术和问题。

    问题

    1. 分布式事务
    2. 分布式锁
    3. 分布式session
    4. 分布式日志管理
    5. 当服务越来越多,服务之间的调用会变得非常混乱
    6. 当服务越来越多,容量的苹果,小服务资源浪费的问题也组件显现。

    6 第四时期(流动式计算架构)

    流动计算架构(SOA)

    当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键。
    

    SOA(面向服务架构)

    调度中心

    服务中间件(Dubbo/Spring Cloud)

    在这里插入图片描述

    7 第五时期 (微服务架构)

    微服务:单体应用拆分成互不相干的小应用,每一个小应用都被称为微服务。

    问题

    1. 构建单体应用时(SSM xml 需要相应的jar)

      当拆分多个微服务时(需要进行大量的代码和配置)

      答:Springboot 简化代码的初始化架构和开发配置

    8 总结

    优点

    1. 服务拆分粒度变得更细。服务复用性强、提高开发效率。
    2. 根据需求自定义优化方案。
    3. 适合互联网项目(产品迭代快、开发效率快)。

    缺点

    1. 微服务过多,服务治理成本高。
    2. 不利于服务部署 部署不方便 (Docker/k8s)。
    3. 技术难点增加(分布式事务、分布式锁、分布式日志)。
    4. 对团队要求过高(dubbo/spring cloud)。
    展开全文
  • 文章目录互联网架构概述一、互联网架构特点二、衡量网站性能的指标三、互联网架构目标、集群和分布式五、互联网架构演变1. 单体架构2. 垂直架构3. 分布式架构4. SOA架构5. 微服务架构 一、互联网架构特点 用户多 ...

    互联网架构概述

    一、互联网架构特点

    1. 用户多
    2. 流量大,高并发
    3. 海量数据
    4. 易受攻击
    5. 功能繁琐
    6. 变更快

    二、衡量网站性能的指标

    1. 响应时间:发送一个请求到收到响应数据所花费的时间
    2. 并发数:系统同时能处理的请求数量
    3. 并发连接数:每秒钟服务器的总TCP连接数量
    4. 请求数:每秒钟的请求数量
    5. 并发用户数:单位时间内的用户数量
    6. 吞吐量:单位时间内系统能处理的请求数量

    三、互联网架构目标

    1. 高性能:提供快速的访问体验
    2. 高可用:网站服务一直可以正常访问
    3. 可伸缩:通过增加硬件的数量,提高处理能力
    4. 高可扩展:系统间耦合度低,方便的增加、移除功能模块
    5. 安全性:提供安全的网站访问和数据加密
    6. 敏捷性:随需应变,快速响应

    四、集群和分布式

    1. 集群:多台机器一起做同样的事,即多台服务器的业务模块都相同

    2. 分布式:多台机器一起做不同的事,即一个大的业务系统,拆分成多个小的业务模块部署在不同 的服务器上

    五、互联网架构演变

    在这里插入图片描述

    1. 单体架构

    多个业务模块部署在一台服务器上;功能单一,难以扩展

    2. 垂直架构

    将单体架构中的多个模块分为多个独立的项目,形成多个单体架构;由于独立,导致每个单体 架构中都需要的相同模块每个单体架构中都需要实现一次,造成重复功能太多

    3. 分布式架构

    在垂直架构的基础上,将公共的业务模块抽取出来,作为独立的服务供其他调用者共享;底层 通过RPC (远程过程调用)实现

    存在的问题:服务提供方一旦产生变更,所有的使用方(消费方)都需要随之变更,比如提供方 服务器的ip地址产生变化,消费方调用的ip地址也要随之变更

    4. SOA架构

    使用ESB (企业服务总线)作为消费方和提供方的服务中介;消费方不再和提供方直接交互,通 过总线转发请求,消费方无需知道提供方发生的变化,只需要向总线发出与消费方交互的请求, 由总线找到消费方

    5. 微服务架构

    基于SOA架构,但更注重对业务的组件化,将原有的业务拆分成多个可以独立开发、运行的小 模块,这些小模块之间进行交互和集成

    Dubbo是SOA时代的产物,SpringCloud是微服务时代的产物

    展开全文
  • 互联网架构演变模型

    千次阅读 2010-07-13 17:09:00
    互联网架构演变模型

    author:skate

    time:2010-07-13


     

     互联网架构演变模型


    之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的、ebay的,都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不少人都很难明白为什么一个网站需要那么复杂的技术,于是有了写这篇文章的想法,在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系,希望能给想从事互联网行业的同学一点初步的概念,:),

     

    文中的不对之处也请各位多给点建议,让本文真正起到抛砖引玉的效果。

     

    架构演变第一步:物理分离webserver和数据库


    最开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设这个时候 已经是托管了一台主机,并且有一定的带宽了,这个时候由于网站具备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题,于是进入了第一步演变阶段:将应用和数据库从物理上分离,变成了两台机器,这个时候技术上没有什么新的要求,但你发现确实起到效果了,系统又恢复到以前的响应速度了,并且支撑住了更高的流量,并且不会因为数据库和应用形成互相的影响。


    看看这一步完成后系统的图示:


     

    这一步涉及到了这些知识体系:


    这一步架构演变对技术上的知识体系基本没有要求。

     

     

    架构演变第二步:增加页面缓存


    好景不长,随着访问的人越来越多,你发现响应速度又开始变慢了,查找原因,发现是访问数据库的操作太多,导致数据连接竞争激烈,所以响应变慢,但数据库连接又不能开太多,否则数据库机器压力会很高,因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力,这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面(例如一两天才会有更新的页面)进行缓存(当然,也可以采用将页面静态化的方案),这样程序上可以不做修改,就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争,OK,于是开始采用squid来做相对静态的页面的缓存。


    看看这一步完成后系统的图示:


     
    这一步涉及到了这些知识体系:


    前端页面缓存技术,例如squid,如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。


     
    架构演变第三步:增加页面片段缓存


    增加了squid做缓存后,整体系统的速度确实是提升了,webserver的压力也开始下降了,但随着访问量的增加,发现系统又开始变的有些慢了,在尝到了squid之类的动态缓存带来的好处后,开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢,因此考虑采用类似ESI之类的页面片段缓存策略,OK,于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。


    看看这一步完成后系统的图示:


     

    这一步涉及到了这些知识体系:


    页面片段缓存技术,例如ESI等,想用好的话同样需要掌握ESI的实现方式等;


     
    架构演变第四步:数据缓存


    在采用ESI之类的技术再次提高了系统的缓存效果后,系统的压力确实进一步降低了,但同样,随着访问量的增加,系统还是开始变慢,经过查找,可能会发现系统中存在一些重复获取数据信息的地方,像获取用户信息等,这个时候开始考虑是不是可以将这些数据信息也缓存起来呢,于是将这些数据缓存到本地内存,改变完毕后,完全符合预期,系统的响应速度又恢复了,数据库的压力也再度降低了不少。

    看看这一步完成后系统的图示:

     


    这一步涉及到了这些知识体系:


    缓存技术,包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。


     
    架构演变第五步: 增加webserver


    好景不长,发现随着系统访问量的再度增加,webserver机器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台webserver,这也是为了同时解决可用性的问题,避免单台的webserver down机的话就没法使用了,在做了这些考虑后,决定增加一台webserver,增加一台webserver时,会碰到一些问题,典型的有:


    1、如何让访问分配到这两台机器上,这个时候通常会考虑的方案是Apache自带的负载均衡方案,或LVS这类的软件负载均衡方案;
    2、如何保持状态信息的同步,例如用户session等,这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等;
    3、如何保持数据缓存信息的同步,例如之前缓存的用户数据等,这个时候通常会考虑的机制有缓存同步或分布式缓存;
    4、如何让上传文件这些类似的功能继续正常,这个时候通常会考虑的机制是使用共享文件系统或存储等;


    在解决了这些问题后,终于是把webserver增加为了两台,系统终于是又恢复到了以往的速度。


    看看这一步完成后系统的图示:


     

    这一步涉及到了这些知识体系:


    负载均衡技术(包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等)、主备技术(包括但不限于ARP欺骗、linux heart-beat等)、状态信息或缓存同步技术(包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等)、共享文件技术(包括但不限于NFS等)、存储技术(包括但不限于存储设备等)。


     
    架构演变第六步:分库


    享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈,导致了系统变慢,这下怎么办呢,此时可选的方案有数据库集群和分库策略,集群方面像有些数据库支持的并不是很好,因此分库会成为比较普遍的策略,分库也就意味着要对原有程序进行修改,一通修改实现分库后,不错,目标达到了,系统恢复甚至速度比以前还快了。


    看看这一步完成后系统的图示:


     

    这一步涉及到了这些知识体系:


    这一步更多的是需要从业务上做合理的划分,以实现分库,具体技术细节上没有其他的要求;
    但同时随着数据量的增大和分库的进行,在数据库的设计、调优以及维护上需要做的更好,因此对这些方面的技术还是提出了很高的要求的。

     


    架构演变第七步:分表、DAL和分布式缓存


    随着系统的不断运行,数据量开始大幅度增长,这个时候发现分库后查询仍然会有些慢,于是按照分库的思想开始做分表的工作,当然,这不可避免的会需要对程序进行一些修改,也许在这个时候就会发现应用自己要关心分库分表的规则等,还是有些复杂的,于是萌生能否增加一个通用的框架来实现分库分表的数据访问,这个在ebay的架构中对应的就是DAL,这个演变的过程相对而言需要花费较长的时间,当然,也有可能这个通用的框架会等到分表做完后才开始做,同时,在这个阶段可能会发现之前的缓存同步方案出现问题,因为数据量太大,导致现在不太可能将缓存存在本地,然后同步的方式,需要采用分布式缓存方案了,于是,又是一通考察和折磨,终于是将大量的数据缓存转移到分布式缓存上了。


    看看这一步完成后系统的图示:

     


     

    这一步涉及到了这些知识体系:


    分表更多的同样是业务上的划分,技术上涉及到的会有动态hash算法、consistent hash算法等;
    DAL涉及到比较多的复杂技术,例如数据库连接的管理(超时、异常)、数据库操作的控制(超时、异常)、分库分表规则的封装等;
     
    架构演变第八步:增加更多的webserver


    在做完分库分表这些工作后,数据库上的压力已经降到比较低了,又开始过着每天看着访问量暴增的幸福生活了,突然有一天,发现系统的访问又开始有变慢的趋势了,这个时候首先查看数据库,压力一切正常,之后查看webserver,发现apache阻塞了很多的请求,而应用服务器对每个请求也是比较快的,看来是请求数太高导致需要排队等待,响应速度变慢,这还好办,一般来说,这个时候也会有些钱了,于是添加一些webserver服务器,在这个添加 webserver服务器的过程,有可能会出现几种挑战:


    1、Apache的软负载或LVS软负载等无法承担巨大的web访问量(请求连接数、网络流量等)的调度了,这个时候如果经费允许的话,会采取的方案是购 买硬件负载,例如F5、Netsclar、Athelon之类的,如经费不允许的话,会采取的方案是将应用从逻辑上做一定的分类,然后分散到不同的软负载集群中;


    2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈,需要进行改进,也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等;


    在做完这些工作后,开始进入一个看似完美的无限伸缩的时代,当网站流量增加时,应对的解决方案就是不断的添加webserver。

    看看这一步完成后系统的图示:

     

     

    这一步涉及到了这些知识体系:


    到了这一步,随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高,这个时候要求对所采用的技术都要有更为深入的理解,并需要根据网站的需求来做更加定制性质的产品。
     
    架构演变第九步:数据读写分离和廉价存储方案


    突然有一天,发现这个完美的时代也要结束了,数据库的噩梦又一次出现在眼前了,由于添加的webserver太多了,导致数据库连接的资源还是不够用,而这个时候又已经分库分表了,开始分析数据库的压力状况,可能会发现数据库的读写比很高,这个时候通常会想到数据读写分离的方案,当然,这个方案要实现并不容易,另外,可能会发现一些数据存储在数据库上有些浪费,或者说过于占用数据库资源,因此在这个阶段可能会形成的架构演变是实现数据读写分离,同时编写一些更为廉价的存储方案,例如BigTable这种。


    看看这一步完成后系统的图示:


     

    这一步涉及到了这些知识体系:


    数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解,同时会要求具备自行实现的技术;
    廉价存储方案要求对OS的文件存储有深入的掌握和理解,同时要求对采用的语言在文件这块的实现有深入的掌握。
     
    架构演变第十步:进入大型分布式应用时代和廉价服务器群梦想时代


    经过上面这个漫长而痛苦的过程,终于是再度迎来了完美的时代,不断的增加webserver就可以支撑越来越高的访问量了,对于大型网站而言,人气的重要毋庸置疑,随着人气的越来越高,各种各样的功能需求也开始爆发性的增长,这个时候突然发现,原来部署在webserver上的那个web应用已经非常庞大了,当多个团队都开始对其进行改动时,可真是相当的不方便,复用性也相当糟糕,基本是每个团队都做了或多或少重复的事情,而且部署和维护也是相当的麻烦, 因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间,出问题的时候也不是很好查,另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导致了全站都不可用,还有其他的像调优不好操作(因为机器上部署的应用什么都要做,根本就无法进行针对性的调优)等因素,根据这样的分析,开始痛下决心,将系统根据职责进行拆分,于是一个大型的分布式应用就诞生了,通常,这个步骤需要耗费相当长的时间,因为会碰到很多的挑战:


    1、拆成分布式后需要提供一个高性能、稳定的通信框架,并且需要支持多种不同的通信和远程调用方式;
    2、将一个庞大的应用拆分需要耗费很长的时间,需要进行业务的整理和系统依赖关系的控制等;
    3、如何运维(依赖管理、运行状况管理、错误追踪、调优、监控和报警等)好这个庞大的分布式应用。


    经过这一步,差不多系统的架构进入相对稳定的阶段,同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量,结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。


    看看这一步完成后系统的图示:


     

    这一步涉及到了这些知识体系:


    这一步涉及的知识体系非常的多,要求对通信、远程调用、消息机制等有深入的理解和掌握,要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。


    运维这块涉及的知识体系也非常的多,多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。


    说起来确实不怎么费力,整个网站架构的经典演变过程都和上面比较的类似,当然,每步采取的方案,演变的步骤有可能有不同,另外,由于网站的业务不同,会有不同的专业技术的需求,这篇blog更多的是从架构的角度来讲解演变的过程,当然,其中还有很多的技术也未在此提及,像数据库集群、数据挖掘、搜索等,但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量,因此在真实的发展过程中还会有很多的不同,另外一个大型网站要做到的远远不仅仅上面这些,还有像安全、运维、运营、服务、存储等,要做好一个大型的网站真的很不容易,写这篇文章更多的是希望能够引出更多大型网站架构演变的介绍。

     

    还有从上面的架构演变中,缓存这一技术对于提高系统性能起着非常重要的作用----使数据更接近cpu

     

     

     

     

    ----end---


     

    展开全文
  • 目录互联网项目架构演变一、起源--单机版项目二、改进版本1--Memcache缓存三、改进版本2--MySQL主从读写分离、改进版本3--MySQL集群五、目前互联网常用架构六、目前互联网的新要求:3V和3高 一、起源–单机版项目...
  • 互联网发展的四个阶段

    千次阅读 2019-12-20 16:00:39
    1.应用场景 身处互联网世界, 还是要了解其发展的历史. 2.... 后续补充 ... https://blog.csdn.net/sky0816/article/details/103569874 //互联网发展的四个阶段 后续补充 ... ...
  • 随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一治理系统确保架构有条不紊的演进。 1、第一时期 单一应用架构 all in one(所有的...
  • 一、演变过程思路图二、何为大型网站三、架构体系演进、架构总结五、参考文章 一、演变过程思路图 二、何为大型网站 1. 大型网站特性 既然说的是大型网站架构,那么架构的背后自然是解决人因面对大型网站特性而...
  • 这是互联网时代

    2019-09-15 21:29:58
    这是互联网因特网时代 互联网基础设施经历了三个演变阶段,随着时间的推移有一些巧合。 因特网 1:从单个ARPAnet网络到互联网:1969年,美国国防部。 UU。他创建了第一分组交换网络。 ARPAnet只是一分组交换网络...
  • 声明,这篇文章的作者是 BlueDavy ,并非我。本人认为写的很好,从中抽取出有用的章节,留做备忘并与大家分享。 ...网站运营的最开始阶段,在每天高峰期的时候总是会...以上阐述为互联网架构演变的典型过程之一。
  • 后来大家干脆就用云这单词,或者一云朵形状的图标,代表电话交换网络和互联网。云的图标,在1977年的ARPANET想和和1981年的CSNET项目中,都用来代表一计算设备网络。 有人将云计算的基本思想——共享资源,往...
  • 互联网+双“高新”时代

    千次阅读 2018-08-20 23:41:57
    前言: 说起移动互联网,想必大家都不陌生,它在人们进步的历史长河中,是一伟大创举,是...如今,我国的互联网,甚至,国际的互联网又进入了一新的高度,那就是互联网+,互联网+的时代带给人民的便利更是强悍...
  • 社群更具价值的商业模式 目录 第一章 「失控」时代与群体智慧 第二章 社群与社群经济 ...从古代社群、近现代社群、城市化社区到互联网社群的演变。 移动互联网尤其是微信、陌陌等社交工具的发展催...
  • 互联网架构主要解决的问题 高并发 海量数据 什么是分布式
  • 互联网时代产品研发的思考

    千次阅读 2018-03-27 23:07:12
    传统软件企业向互联网企业的转型2005年我提出将公司CRM产品向SaaS化发展的战略时,很多人都认为那是一巨大的冒险,而如今已经没有人再质疑传统软件向SaaS化发展的趋势。很多决心向互联网产品转型的企业,都会遇到...
  • 运营简史:一文读懂互联网运营的20年发展与演变(转) 文 / 黄有璨 (范晓俊亦为本文搜罗了大量资料,并采写了文中部分内容)前言“运营”是有趣的东西。作为一现今互联网行业中最为普及的工作职能,它却又往往...
  • 作为一现今互联网行业中最为普及的工作职能,它却又往往被称为是一大“玄学”。 一方面它的地位和权重越来越高;另一方面,似乎它又很模糊,看起来,少有人能够从真正意义上讲清楚到底“运营”是什么。 回溯...
  • 一、 前言从过去的OA、CRM、ERP等单机即可满足要求的系统到现代互联网时代各大公司的分布式、微服务平台,互联网架构正在经历着巨大的变革,技术也在不断的更新迭代,这也意...
  • 计算机产业、互联网造富的时代

    千次阅读 2012-05-21 22:15:13
    做电子商务公司如果没有强大的信息系统支撑的话(这里是指拥有自己独立的网开站发团队、服务器维护团队等等),因为等公司业务发展到一定规模的时候会面临非常严重的瓶颈,而这瓶颈在短期内是无法解决的,因为系统的...
  • 云计算时代,数据中心架构三层到大二层的演变 author:pasca time:2018/1/16 文章目录一、数据中心是什么二、传统数据中心网络架构三、云计算的发展对数据中心的影响、数据中心流量丰富化带来的挑战五、总结 一、...
  • 随着中国互联网的发展,互联网开始由web端访问逐渐演变为智能手机端、智能终端,而产生的数据从简单的结构化二维数据逐渐演变成视频音频图片的非结构化数据、专属网络的JSON&XML半结构化数据,对于互联网的运营...
  • 10月20日消息,在10月18日的Web 2.0峰会上,凯鹏华盈(KPCB)知名分析师Mary Meeker发表报告,谈及2011年互联网趋势。 下面是报告主要内容:   第一点:全球化 主题一:苹果、Google、...
  • 互联网时代下的市场营销

    千次阅读 2008-10-25 23:26:00
    互联网时代,传统的市场营销模式和手段一定要随之变化,这一点,无论是传统企业,还是在互联网上做生意的企业都需要用心体会。 被企业界称为“江南营销第一吴”的吴泗宗教授有句名言:“企业的宗旨是成长,成长的...
  • 浅谈因特网时代的操作系统演变

    千次阅读 2002-11-08 00:24:00
    《浅谈因特网时代的操作系统演变》北京科泰世纪科技有限公司首席科学家陈榕操作系统存在的目的只有一,就是为了更好地支持应用程序运行。在某种程度上,操作系统所提供的支持决定了应用程序的工作方式。随着因特网...
  • 后来大家干脆就用云这单词,或者一云朵形状的图标,代表电话交换网络和互联网。云的图标,在 1977 年的 ARPANET 想和和 1981 年的 CSNET 项目中,都用来代表一计算设备网络。 有人将云计算的基本思想...
  • 原文地址:互联网时代的十大特征和趋势作者:正见品牌顾问 特征一:在线化。    进入3G时代之后,Wi-Fi开始普及,绝大多数手机客户如果愿意的话都可以永远在线,移动互联会成为未来十年,甚至更长一段时间的主...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,935
精华内容 3,574
关键字:

互联网演变的四个时代