精华内容
下载资源
问答
  • 互联网演变的四个时代
    千次阅读
    2021-01-22 13:02:55

    互联网架构概述

    一、互联网架构特点

    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是微服务时代的产物

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

    一、导读

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

    二、过程

    • 单机时代

      互联网早期,好比杭研某个产品团队初创之时,资源有限,人力不足,为了快速开发一个产品,或上线一个网站,单机往往是一个不错的选择,此时会将应用程序、文件服务、数据库服务等资源集中在一台 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--Memcache缓存三、改进版本2--MySQL主从读写分离、改进版本3--MySQL集群五、目前互联网常用架构六、目前互联网的新要求:3V和3高 一、起源–单机版项目...

    互联网项目架构演变

    在这里插入图片描述

    一、起源–单机版项目

    在这里插入图片描述

    二、改进版本1–Memcache缓存

    在这里插入图片描述
    着访问量上升,大部分使用MySQL架构的网站在数据库上都开始出现性能问题,Web程序不能再仅仅专注在功能上,同时也在追求性能。开始使用缓存技术缓解数据库压力,优化数据库的结构和索引。刚开始时比较流行的是通过文件缓存来缓解数据库压力,但是当访问量继续增大,文件缓存中的数据不能在多台Web服务器之间共享,大量的小文件IO也带来了比较高的IO压力。在这种情况下,Memcache就成了一款非常有效的解决方案。

    Memcache作为一个独立的分布式缓存服务器,为多个Web服务器提供了一个共享的高性能缓存服务,在Memcache服务器上,又发展了根据hash算法来进行多台Memcache缓存服务的扩展,然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效问题。

    三、改进版本2–MySQL主从读写分离

    在这里插入图片描述
    由于数据库的写入压力增加,Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负,大部分网站开始使用主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了

    四、改进版本3–MySQL集群

    在这里插入图片描述
    在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,这时MySQL主库的写压力开始出现瓶颈,而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。

    同时,开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候,分表分库成了一个热门技术,是业界讨论的热门技术问题。也就在这个时候,MySQL推出了还不太稳定的表分区,这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群,但性能也不能很好满足互联网的要求,只是在高可靠性上提供了非常大的保证。

    MySQL数据库也经常存储一些大文本字段,导致数据库表非常的大,在做数据库恢复的时候就导致非常的慢,不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小,如果能把这些数据从MySQL省去,MySQL将变得非常的小。关系数据库很强大,但是它并不能很好的应付所有的应用场景。MySQL的扩展性差(需要复杂的技术来实现),大数据下IO压力大,表结构更改困难,正是当前使用MySQL的开发人员面临的问题。

    五、目前互联网常用架构

    在这里插入图片描述

    六、目前互联网的新要求:3V和3高

    大数据时代的3V

    • Volume:海量,数据量极大
    • Variety:多样
      数据类型:文本、图片、音频、视频……
      终端设备:PC、移动端、嵌入式设备……
    • Velocity:实时
      直播,金融证券……

    互联网时代的3高

    • 高可扩
      不断优化现有的功能,不断开发新的功能;
    • 高性能
      不能让用户感觉到等待的时间;
    • 高并发
      同时处理并发请求的能力,如双十一的秒杀、抢购火车票;
      提升硬件,优化系统,优化项目,将费时的操作进入异步处理;
    展开全文
  • 随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一治理系统确保架构有条不紊的演进。 1、第一时期 单一应用架构 all in one(所有的...
  • 社群更具价值的商业模式 目录 第一章 「失控」时代与群体智慧 第二章 社群与社群经济 ...从古代社群、近现代社群、城市化社区到互联网社群的演变。 移动互联网尤其是微信、陌陌等社交工具的发展催...
  • 互联网发展简史

    万次阅读 多人点赞 2019-01-12 17:12:04
    1. 科研计算机时代 提到计算机的历史首先要提到艾伦·麦席森·图灵,他参与了世界上最早的电子计算机的研制工作,并成功破解了战时密码通讯。 图灵后期提出的自动计算机与约翰·冯·诺伊曼的离散变量自动电子计算机...
  • 特别是在如今客流量逐渐减少、商铺租金越来越高、商品信息愈发透明的经营大环境下,批发商户应从传统的经营思想中走出来,利用互联网销售模式,打通供应链上下游,在快速变化的市场中获得更多机会,从根本上摆脱批..
  • 互联网时代产品研发的思考

    千次阅读 2018-03-27 23:07:12
    传统软件企业向互联网企业的转型2005年我提出将公司CRM产品向SaaS化发展的战略时,很多人都认为那是一巨大的冒险,而如今已经没有人再质疑传统软件向SaaS化发展的趋势。很多决心向互联网产品转型的企业,都会遇到...
  • 大数据时代的到来改变了人们的生活方式、思维模式和研究范式,我们可以总结出 10 重大变化,如图 1 所示。 图 1大数据时代的 10 重大变化 对研究范式的新认识:从第三范式到第范式 2007 年 1 月,图灵奖...
  • 颠覆式创新:移动互联网时代的生存法则作者:李善友引言有一非常著名的哥德尔第一定理。它这样讲:任何一体系,它必是内部和外部自洽的,这样才能有效运行。但是任何一内部逻辑完全自洽的体系,一定存在自身的...
  • 企业组织形态强调企业组织的外部形状与不同时期的生产力发展水平相适应企业的组织形状在不同时期表现出不同特征它是以纵向考察企业特征为主的一概念纵观企业组织形态的演变历史它主要经历了家庭手工劳动工厂作坊...
  • 斯佩茨的遭遇不是他一个人的,是整个人类一个时代的遭遇。势不可挡的网络爬虫们,爬进了千家万户,爬入了你的每一个日夜。你交往交流的所有痕迹,都不再是你自己的。你昨天和今天的每一个足迹,都不会被时间磨损,将...
  • 天天练2020统编版2019高二选择性必修中册第单元素养拓展区 一现代文阅读 ) 1....传说在黄帝时代仓颉创造了文字从字体的演变发展来看中国文字大体经历了甲骨文金文金石竹帛文小篆汉隶楷书等六
  • 作为一现今互联网行业中最为普及的工作职能,它却又往往被称为是一大“玄学”。 一方面它的地位和权重越来越高;另一方面,似乎它又很模糊,看起来,少有人能够从真正意义上讲清楚到底“运营”是什么。 回溯...
  • 互联网+双“高新”时代

    千次阅读 2018-08-20 23:41:57
    前言: 说起移动互联网,想必大家都不陌生,它在人们进步的历史长河中,是一伟大创举,是...如今,我国的互联网,甚至,国际的互联网又进入了一新的高度,那就是互联网+,互联网+的时代带给人民的便利更是强悍...
  • 互联网时代的十大特征和趋势

    千次阅读 2017-06-16 09:29:05
    原文地址:互联网时代的十大特征和趋势作者:正见品牌顾问 特征一:在线化。    进入3G时代之后,Wi-Fi开始普及,绝大多数手机客户如果愿意的话都可以永远在线,移动互联会成为未来十年,甚至更长一段时间的主...
  • 这是互联网时代

    2019-09-15 21:29:58
    这是互联网因特网时代 互联网基础设施经历了三个演变阶段,随着时间的推移有一些巧合。 因特网 1:从单个ARPAnet网络到互联网:1969年,美国国防部。 UU。他创建了第一分组交换网络。 ARPAnet只是一分组交换网络...
  • 移动互联网十年

    千次阅读 2018-10-17 10:16:40
    自此,百度、阿里和腾讯分别掌握了互联网最重要的三应用入口,成为新的三巨头,被称为BAT。 面对BAT的崛起,传统的三大门户则陷入了模式困境。网易放弃了正面战场,专注于网游;搜狐则多面出击,布局...
  • 随着中国互联网的发展,互联网开始由web端访问逐渐演变为智能手机端、智能终端,而产生的数据从简单的结构化二维数据逐渐演变成视频音频图片的非结构化数据、专属网络的JSON&XML半结构化数据,对于互联网的运营...
  • 运营简史:一文读懂互联网运营的20年发展与演变(转) 文 / 黄有璨 (范晓俊亦为本文搜罗了大量资料,并采写了文中部分内容)前言“运营”是有趣的东西。作为一现今互联网行业中最为普及的工作职能,它却又往往...
  • 无论是互联网还是传统行业,都会有自己或大或小的数据中心,甚至如阿里云和亚马逊这种专门以出租计算资源的云计算公司,更是在全世界各地建立了不等的数据中心。 尽管到到如今的云计算时代,将数据中心自身的资源...
  • 产业互联网是传统行业与互联网联合后的新型业态,是企业战略的一种模式;随着网络化进程逐渐从消费互联网向产业互联网的进化,以B端为主要用户和改造对象的全新时代正在来临,而它的底层驱动力正是以...
  • 我大学毕业后第一份工作就用的是 Elixir 这门语言。也许你听都没听说过,和你一样,...小众语言为何能对抗焦虑很多人对小众语言都有一担忧,就是不好找工作。其实这话只能算对一半。正确的那一半是,确实,都“小...
  • 01互联网三高架构的演进之道

    千次阅读 2021-12-13 19:31:43
    常听的四个高:高可靠、高并发、高性能、高可用;怎么划分呢? 高可靠(针对数据),高可用(针对服务) OLAP:On-Line Analytical Processing 联机分析处理, 大数据,追求高可靠 OLTP:On-Line Transaction ...
  • 身为一名新时代互联网工作人员,怎么能对这行业的黑话一无所知呢?下面我给大家整理了互联网行业的基本“黑话”,看看你知道几条。一、互联网人知名大厂别称1、熊厂、狼厂、蓝厂——百度。百度的Logo是一蓝色...
  • 互联网架构演变模型

    千次阅读 2010-07-13 17:09:00
    互联网架构演变模型
  • 网络信息系统安全的发展演变

    千次阅读 2022-04-01 19:47:07
    计算机网络尤其是互联网的出现是信息技术发展中一里程碑事件。计算机网络将通信技术和计算机技术结合起来。信息在计算机上产生、处理,并在网络中传输。网络信息系统安全是通信安全和信息系统安全的综合,网络信息...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,519
精华内容 4,207
热门标签
关键字:

互联网演变的四个时代