标签：逻辑   共享   结构   通用   表达   应用服务   alt   互联网   技术   

1 互联网的发展阶段

• web 1.0。
• web 2.0。
• 互联网时代。
• 云计算和大数据时代。
• ……

2 互联网架构演变

2.1 单体应用

2.1.1 单体应用早期

• 网站的初期，也认为是互联网发展的最早时期。会在单机部署所有的应用程序和软件。

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

• 特点：

  • 1??不具备代码的可维护性。
  • 2??单点容错性低。

  故障容许度（英语：Fault tolerance）也称容错、容错性，是使系统在部分组件（一个或多个）发生故障时仍能正常运作的能力。

• 单体架构也称为单体地狱。

2.1.2 单体应用后期

• 针对单体应用早期问题的解决方案：分层开发（提高维护性），即MVC架构设计。

• MVC架构设计的特点：

• 1??分层开发，提高了系统的可维护性（方便定位问题）。

• 2??应用和数据库的分开部署。

• 但是，随着用户的访问量的持续增加，单台应用服务器已经无法满足需求（换言之，MVC并不能解决高并发的问题），这时使用应用集群（集群：同一个应用部署在多台服务器上）和数据库集群来提高系统的功能。

• 虽然，集群某种意义上可以解决高并发和高可用，但是却带来了如下的问题：
• 1??session共享问题（使用Redis、SpringSession以及Nginx的Ip Hash等）。
• 2??请求转发问题（使用Nginx服务器来对请求进行转发，实现负载均衡策略机制）。

• 我们通过集群方案Nginx+Redis Cluster将应用层的性能进行有效的提升。但是，虽然业务量的提升，数据库的压力在慢慢增加，此时我们可以使用主从复制、读写分离（主从数据库之间进行数据同步。master负责增删改操作，slave负责读操作）来提升数据库的性能。

• 在数据库做读库的情况下，我们知道数据库本身对模糊查询的功能支持的不是很高，比如像电商类的网站，搜索是非常核心的功能模块。即使做了读写分离，也不能有效的解决电商网站查询（比如分词技术）等，针对该问题，有必要引入搜索引擎技术。

• 随着访问量的持续增加，数据库的访问压力变得越来越大（虽然做了主从复制）。对于一些热点数据（用户频繁访问的信息），或者手机登录的验证码操作，为了限制IP频繁访问服务器等，如果每次都到数据库中进行查询，那么数据库的性能会受到很大的影响，这个时候可以尝试使用Redis。

• 随着访问量的进一步增加，数据库的单表的压力也在增加（比如单表达到了200万），此时就需要考虑数据库表的水平拆分和垂直拆分。
• 所谓的数据库表的垂直拆分，就是指按数据表列的拆分，最常见的就是将数据库中的单表拆为冷数据和热数据。比如：用户表具有id、name、birthday、address、remark等字段，其中address和remark字段就是冷数据，就可以从用户表中拆出来组成一个新表。
• 所谓的数据库表的水平拆分，就是按行的拆分。比如表的行数超过了200行时，这个时候就可以考虑将一个表的数据拆成多张表来保存。
• 目前常用的第三方的分库分表技术有：mycat、ShardingSphere等。

2.1.3 总结

• 优点：
  • 1??所有的功能集成在一个项目工程中。
  • 2??项目架构简单，前期开发成本低，周期daunt，小型项目的首选。
• 缺点：
  • 1??全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。
  • 2??系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
  • 3??技术栈受限。

2.2 垂直应用架构

2.2.1 概述

• 当访问量逐渐增加，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

2.2.2 水平拆分

• 以常见的Maven项目架构为例，以前是一个工程就是一个Maven项目，但是可以通过Maven的多模块功能将一个工程拆为几个模块。

• 可以解决如下的问题：
• 1??模块复用。可以将功能类似的代码抽取出来放到common模块中，其他模块引用即可。
• 2??部署内容变少。以一个电商项目为例，在拆分之前，所有的功能是写在一起，代码重复度很高，在进行水平拆分之后，将一些通用的代码抽成组件，供其他模块使用。

2.2.3 垂直拆分

• 按照功能将单体项目拆分成多个互不相干的小应用。每个应用都是独立部署的项目。

• 可以解决如下的问题：
• 1??维护性：如果需要做需求的变更，只需要到对应的某个应用的模块修改即可。
• 2??功能扩展：随着业务的不断增加，只需要创建新的应用即可。
• 3??协同开发方便：不同的开发团队，修改不同的代码，甚至不同的开发团队可以使用不同的技术。
• 4??部署内容大小/性能扩展（只需要对访问量大的应用多部署几台服务器）。

2.2.4 总结

• 优点：
  • 1??系统结构简单，前期开发成本低，周期短，小型项目的首选。
  • 2??通过垂直拆分，原来的单体项目不至于无限扩大。
  • 3??不同的项目可以采用不同的技术。
• 缺点：
  • 1??全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。
  • 2??系统性能扩展只能通过集群结点，成本高、有瓶颈。

2.3 分布式架构

2.3.1 概述

• 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。例如：在2.2.3中的垂直拆分的电商系统中，用户管理在CRM或物流管理系统中就是重复的。所以，在分布式架构中就是将所有的功能抽取成独立的服务，如下图所示：

• 但是，服务的评估、治理和调度等都是需要解决的问题。

2.3.2 分布式SOA架构

• SOA，面向服务的架构。它可以根据需要通过网络对松散耦合的粗颗粒度应用组件（服务）进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
• 站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。

• 优点：

• 1??抽取的公共的功能为服务，提高开发效率。

• 2??对不同的服务进行集群化部署，解决系统压力。

• 3??基于ESB/Dubbo减少系统耦合。

• 缺点：

• 1??抽取服务的粒度较大。

• 2??服务提供方和调用方接口耦合度较高。

2.3.3 微服务架构

• 微服务和SOA架构类似，微服务是在SOA上做得升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分成多个独立运行开发、设计、运行的小应用。这些应用之间通过服务完成交互和集成。

• 优点：

  • 1??通过服务的原子化拆分、以微服务的独立打包、部署和升级，小团队的交互周期将缩短，运行成本也将大幅度下降。
  • 2??微服务遵循单一原则。微服务之间采用REST等轻量级协议传输。

• 缺点：

  • 1??微服务过多，服务治理成本高，不利于系统维护。
  • 2??分布式系统开发的技术成本高（容错、分布式事务等）。

互联网架构演变

标签：逻辑   共享   结构   通用   表达   应用服务   alt   互联网   技术   

原文地址：https://www.cnblogs.com/xuweiweiwoaini/p/13690427.html