互联网演变过程

文章目录

• 互联网演变过程
• • 1 简介
  • 2 第一时期
  • 3第一时期的后期阶段
  • • 集群
    • **读写分离**
    • **搜索引擎**
    • 缓存引入
    • 数据库拆分
    • 问题
  • 4 第二时期（垂直架构）
  • • 项目拆分
    • 解决的问题
    • 问题
  • 5 第三时期（分布式架构）
  • • 分布式方案
    • 问题
  • 6 第四时期（流动式计算架构）
  • • 调度中心
  • 7 第五时期 （微服务架构）
  • • 问题
  • 8 总结
  • • 优点
    • 缺点

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 &＃8211; 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）。