互联网架构的演进之路

互联网架构的演进之路

互联网的四个阶段

1. web 1.0 时代 传统广告业务化

2. web 2.0 时代 内容产业数据化

3. 互联网+ 移动互联网时代 生活服务业数据化

4. 万物互联 云计算大数据时代 一切产业数据化

1. 第一阶段

单一应用架构

all in one 所有模块集中在一起，不做任何分层!

单机部署所有应用程序和软件，所有代码写在一块 称之为all in one

特点：

1. 不具备代码可维护性

2. 容错性差 （出错不容易恢复，无法捕获异常，处理异常，出错容易引起宕机）

分层开发

解决方案：

1. 分层开发 （提高项目可维护性）【解决容错性】
2. MVC 设计模式 （web 应用三层架构）
   

特点：

1. MVC分层开发

2. 数据库独立出来

出现问题：

随着用户访问量增长，但应用已经无法满足需求。

解决方案：

集群

2. 第一阶段 后期

引出问题

1. 高可用

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

2.高并发

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

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

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

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

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

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

提升系统的并发能力

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

1.垂直扩展

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

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

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

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

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

2.水平扩展

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

3. 高性能

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

集群部署

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

特点：

1. 项目采用多台服务器（集群）部署

优点：

1. 支持高并发

2. 支持高可用

问题：

1. Session 如何共享

   Redis Cluster 集群方案

2. 用户请求如何转发

   nginx 做请求分发，负载均衡

注意 ： 好多老公司用这套架构

解决数据库压力

nginx+tomcat 集群有效减少业务层压力，但此时数据库压力增大

1. 读写分离

解决方案：

读写分离，主从复制

主从数据库之间进行数据同步，master负载均衡，slave负载操作。

MySql 本身就提供主从复制功能

问题：

1. 数据库本身对模糊查询的功能支持也不是很优秀，即使做了读写分离，也很难解决搜索业务使用搜索引擎缓解数据库访问压力

2. 引入搜索引擎

流行的搜索引擎技术 solr elasticsearch whoosh

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

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

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

3. 数据库拆分

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

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

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

表：垂直拆分。

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

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

表：水平拆分。

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

分库分表：

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

当前状态特点：

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

（不断对服务器进行扩容，支持高并发，高可用）

问题：

1. 服务器成本、维护成本，人工成本？
2. 可维护性差
3. 可扩展性差（组件重用性基本没有）
4. 协同开发不方便 （大家都去改相同的业务代码，易发生代码错误/冲突）
5. 单体架构（随着业务的不断增加，代码会变得越来越多），导致服务部署时文件越来越大。

3. 第二阶段

垂直应用架构

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

水平拆分：

将大的单体应用，拆分多个小应用

横着拆 ：

exam-parent

1. exam-common   公共
2. exam-pojo           javaBean
3. exam-mapper     数据库操作
4. exam-service       业务逻辑
5. exam-web            前台
6. exam-admin        后台

利用父工程聚合，把各个层进行拆分，提高复用，需要应用时可以进行依赖注入。（注：Maven具有以来传递特性，依赖工程所依赖的项目会传递依赖过来，可以在父工程进行版本管理，提高项目规范）

解决问题：

1. 模块复用
2. 解决服务器部署内容大小

闲置了大量的服务器 （如果用户对某个层访问量过大时，只需要将该业务多部署一些服务即可）

（阿里云、百度云、腾讯云、新浪云、京东云······）

---

在没有出现云之前：

一些公司需不需要购买服务器+需要运维人员对服务进行维护。

行业：大量Linux 运维工程师

企业： 服务器托管企业

垂直拆分：

将大的单一应用，按功能模块进行拆分

解决问题：

1. 可维护性（改需求，只需要改对应模块即可）
2. 功能扩展（只需要加新的模块即可）
3. 协同开发（不同团队，负责不同业务模块）
4. 性能扩展（灵活部署，对访问量大的服务器，多部署）

问题：

1. （用户对前端页面要求越来越大，修改越来越频繁）页面变化大，每一个应用从头到尾都是完整的，如果客户要对页面进行修改，整个应用服务都需要重新部署
2. 随着业务的不断增加，应用模块会越来越多，各个模块之间一定需要业务交互？

4. 第三阶段

分布式架构

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

分布式，将一个业务拆分多个子业务，部署不同服务器

针对如上情况

解决问题：

1. （用户对前端页面要求越来越大，修改越来越频繁）页面变化大，每一个应用从头到尾都是完整的，如果客户要对页面进行修改，整个应用服务都需要重新部署

   前后端分离 【横着拆】
   

2. 随着业务的不断增加，应用模块会越来越多，各个模块之间一定需要业务交互？
   
   分析：

以前在同一个服务器上（模块之间的依赖可以完成调用）

通过上图，发现不同的应用部署在不同服务器上，服务和服务之间的调用【进程间调用】

解决方案：

RPC / HTTP(RESTful)

RPC（Remote Procedure Call）- 远程过程调用，他是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

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

分布式事务、分布式锁、分布式Session、分布式日志管理

---

问题：

1. 服务和服务之间的调用，会变得非常混乱
2. 服务越来越多，容量评估，小服务资源浪费等问题逐渐出现

5. 第四阶段

流动计算架构

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

SOA 面向服务架构

功能： 解决多服务混乱问题

服务治理中间件(dubbo / springCloud )

基于访问压力实时管理集群容量，提高集群利用率，提高机器利用率的资源调度和治理中心

微服务架构 = 80%的SOA的服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

第五阶段

微服务架构

微服务： 单体应用拆分成互不相干具备原子性的服务，每个小应用叫微服务

问题：

1. 构建单体应用时，（SSM、web.xml、需要相应的所有jar、相应的配置文件）

   当拆分成多个微服务应用时（需要大量的项目（服务）创建）

   springBoot 出现为了简单代码的初始化构建和开发配置

总结：

优点：

1. 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
2. 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
3. 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
4. 微服务能使用不同的语言开发。
5. 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, bamboo 。
6. 一个团队的新成员能够更快投入生产。
7. 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
8. 微服务允许你利用融合最新技术。
9. 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
10. 微服务能够即时被要求扩展。
11. 微服务能部署中低端配置的服务器上。
12. 易于和第三方集成。
13. 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

缺点：

1. 服务过多，服务管理（治理）成本高

2. 不利于部署（Docker 镜像/容器 k8s）

3. 技术难点增加（分布式事务、分布式锁、分布式Session、分布式日志）

4. 对团队技术能力要求增高（dubbo/springCloud）

当前应用比较广的成熟的架构

传统的比较完善的