互联网架构的演变过程(一)

简介

web1.0时代

web2.0时代

互联网时代 互联网+ –》智慧城市。 2012年提出。

云计算+大数据时代

背景

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

1、第一时期

单一应用架构

all in one(所有的模块在一起，技术也不分层)

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

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

特点：

1、不具备代码的可维护性。

2、容错性差。

​ 因为我们所有的代码都写在JSP页里。当用户或某些原因发生异常。（1、用户直接看到异常错误信息。2、这个错误会导致服务器宕机）

容错性，是指软件检测应用程序所运行的软件或硬件中发生的错误并从错误中恢复的能力，通常可以从系统的可靠性、可用性、可测性等几个方面来衡量。

单体地狱。:只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

2 第一时期后阶段

解决方案:

1、分层开发（提高维护性）【解决容错性】

2、MVC架构（Web应用程序的设计模式）

3、服务器的分离部署

特点：

1、MVC分层开发（解决容错性问题）

2、数据库和项目部署分离

问题：

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

解决方案：

集群。

3 可能会产生的几个问题：

1.1. 高可用

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。(一直都能用)

1.2. 高并发

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。

吞吐量：单位时间内处理的请求数量。

QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

1.2.1. 提升系统的并发能力

提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。

1. 垂直扩展

垂直扩展：提升单机处理能力。垂直扩展的方式又有两种：

（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；

（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；

在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。

总结：不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。

2. 水平扩展

水平扩展：只要增加服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的，难点在于：如何在架构各层进行可水平扩展的设计，

可扩展性。

1.3. 高性能

高性能（High Performance）就是指程序处理速度快，所占内存少，cpu低

4、集群操作

集群：同一个业务，部署在多个服务器上。

特点：

1、项目采用多台服务器(集群）部署

优点：

​ 支持高并发。

​ 支持高可用。

问题1： Session如何共享？

答： Redlis Cluster集群方案

问题2：这些集群的服务器，用户的请求该往哪里进行转发？

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

注意：很多IT公司用的都是这种架构需求

数据库压力变大

我们能过集群方案nginx+tomcat将应用层的性能进行有效的提升。但是数据库的负载夺力慢慢增加。怎么来搞高数据库层面的访问压力（负载）？

解决方案：

读写分离

读写分离：主从数据库之间进行数据同步。master负载增删改操作。 slave负载读操作。

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

使用搜索引擎缓解数据库的访问压力+能力

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

目前非常主流的搜索引擎技术：

solr  elasticsearch  whoosh

引入缓存机制减轻数据库的访问压力

随着访问量的持续增加，数据库的访问压力变的越来越大（虽然做了主从复制）。对于这些热点数据（用户访问频繁的信息），如果每都到数据库中进行查询。（很多通用查询的功能）。

放在内存中又不特别合适。（手机登录验证码操作、为了IP限制频繁访问服务器…) 尝试使用Redis.

数据库的水平/垂直拆分。

垂直扩展 能力终归还是有限的。

单个表： 1000万–》1个亿数据 （单个表的数据能力终归还是有限的）

表：垂直拆分。

id ,name,age,bire..tel…remark….

热数据/冷数据 –》垂直拆分方案。

表：水平拆分。

按照：时间、地区、（按照业务逻辑进行拆分）。

分库分表：

采用第三方数据库中间件：mycat sharding-jdbc drds(阿里)

当前状态特点：

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

（不断的对服务器进行扩容…)

问题1：服务器价钱？（服务器维护成本、人工维护）？

问题2：可维护性差。

问题3：可扩展性差（组件重用性基本没有）

问题4：协同开发不方便。(大家都去改相同的业务代码。易发生代码错误/冲突)

问题5：单体架构（随着业务的不断增加，代码会变得越来越多）。导致服务部署时，文件变的越来越大。