架构的演变

架构生命周期

简介
本篇幅主要讲述架构的各阶段出现的需求问题、业务问题、性能问题以及相应的解决方案。

1、web1.0时代（1996年左右）

2、web2.0时代（2006年左右）

3、互联网时代（2012年左右）

–》互联网±-》智慧城市。

滴滴打车。

饿了么（工商局）

4、大数据+云计算

5、AI 未来以来时代

…

第一时期

单一应用架构

all in one。所有的模块和代码都在一起。技术也不分层。(2000年左右)

网站的初期的最早架构。也是互联网发展的最早时期。所有的代码、业务都写在JSP里面。

问题：

1、代码不具备可维护性

2、容错性差
因为我们所有的代码都写在JSP页面里面，当用户访问或某些原因发生异常
1、用户会直接看到异常信息。
2、有些情况下，该错误可能会导致服务宕机。

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

   
   

   
   
1
2

第一时期后阶段

解决方案：

1、分层开发（提高维护性）

2、 MVC架构（是一个基于JAVA WEB应用的设计模式）

3、服务器分离部署

特点：

1、MVC分层开发（提高了维护性、解决了容错性问题）

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

问题：

随着用户的访问量持续增加，单台应用服务器已无法满足需求。（高并发问题）

解决方案：

集群。（集群方案解决）

一个服务部署在多个服务器上

会出现的如下问题：

而在互联网项目下，因单个tomcat默认并发量有限制。如果请求量过大，会产生如下问题：

高并发（High Concurrency）

是互联网分布式系统架构设计中必须考虑的因素之一，

它通常是指，通过设计保证系统能够同时并行处理很多请求。

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

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

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

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

并发用户数：同时承载正常使用系统功能的用户数量。

高可用（High Availability）

通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

(一直都能用 99.9999%) -->docker–>k8s

https://www.idcbest.com/idcnews/11002927.html

高性能

是指服务响应时间快，（CPU/处理器/内存）特别是在高并发下响应时间不会急剧增加。

提高系统的并发能力：

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

1.        垂直扩展
   
        
        
   
        
        
   1

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

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

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

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

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

2.        水平扩展
   
        
        
   
        
        
   1

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

集群操作

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

特点：

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

解决：

支持高并发

支持高可用

问题：

1、（集群）用户的请求该往哪里进行转发？ 答：nginx

2、Session如何共享？ 答：Redis Cluster(Spring session+Redis)实现

数据库压力变大

我们通过nginx+tomcat集群方案 支持高并发（应用的性能进行提升访问），但是数据库的负载能力慢慢增加。

问题：

怎么来提高数据库层面的访问压力？

解决方案：

读写分离

主从数据库之间进行数据同步。master主要负责增删改操作。slave负责读（查询）操作。

mysql本身就支持master-slave的功能（主从复制）。

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

数据库本身对大数据量查询效率慢，对模糊查询支持不是特别优秀，像电商类网站。搜索是非常核心的功能。（即使做了数据库读写分离），很多功能也不能有效解决（分词技术），针对于该问题，有必要引入全文检索服务器功能。

目前市场上主流的搜索引擎技术：

Solr ElasticSearch

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

随着访问量的持续增加，（数据库的访问压力持续增大，甚至都无法满足需求）。[虽然做了主从复制]。对于热点数据，如果每次都从数据中查询，数据库无法应对，导致无法对外提供服务。

最佳解决方案：Redis

1、读写性能非常好。

2、提供了丰富的数据类型。

3、原子性。

数据库的表进行水平/垂直拆分

一张表里面有1千条数据，查询的性能很高。

如查有100万数据，查询的性能很慢。

单个表性能做提升。（能力终归还有限的）

表为主

垂直：

假设一张表里面 用户表（有30个字段）

id,姓名，年龄，身份证号，身高，体重，性别，手机号，家庭住址，爱好…

热数据/冷数据

user(id，姓名，身份证号，年龄，性别，手机号)

user_info(id,身高，体重)

水平：

按需求进行拆分。（省份、时间）

按省份拆分。

分库分表：

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

https://blog.csdn.net/jornada_/article/details/82947677

当前设计特点：

通过设计保证高并发、高可用。（不断的对服务器进行扩容）

当前很多公司用的这种架构。

问题：

1、服务器价钱。（忙闲不均问题）【服务器的维护、人工成本）大量运维工程师

2、可维护性差

3、可扩展性差（服务器）

4、协同开发不方便（大家都去修改相同业务代码，易发生代码冲突/错误问题）

5、单体架构（随着业务需求的不断增加，应用代码会变的越来越多）导致服务器部署时占用的硬盘也大。

第二时期

垂直应用架构

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

理解 什么是垂直分布？

水平拆分：（横着拆）

按层来拆分

将一个大的应用拆分成多个小应用。

exam_project( controller/service/mapper/pojo…)

问题1：现在网站分为前台（给用户使用），后台（给管理员使用），是否需要拆成2个项目独立部署？如果需要拆的话，有一些前后台都需要公用的代码，这些代码怎么办？

parent pom    #父工程（放所有的pom.xml)
common.jar    #公共库 相关工具类
pojo.jar      #java bean
mapper.jar    #数据持久层
service.jar   #业务逻辑层
web.war       #web访问层
manager.war   #后台管理

   
   

   
   
1
2
3
4
5
6
7

解决问题：

1、模块复用

2、减少了服务器内容部署就小

垂直拆分：（竖着拆）

按功能拆分

将一个大的应用按功能拆分成多个互不相干的小应用。每个应用都是独立的WEB应用程序–》分布式

解决问题：

1、维护性（如果发生需求变更，只需要调整某个应用模块即可）

2、功能扩展（随着业务的不断增加，只需要创建新的WEB程序即可）

3、协同开发方便（不同的团队修改不同的代码）

4、部署内容大小（性能扩展），如果哪台访问量大，只需要对该服务多部署几台即可。

此时，用于加速前端页面开发的Web框架(MVC)是关键。

   
   

   
   
1

问题：

1、客户对页面的要求会越来越高？（修改频繁）需要重新部署后台应用程序？（每一个应用从头到尾都完整的）。

2、随着业务需求不断增加，需要很多个互不相干应用部署？这些应用之间一定会需要业务交互？

第三时期

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

   
   

   
   
1

分布式服务架构

分布式：将一个业务拆分成多个子业务，部署在不同的服务器上。

问题

1、客户对页面的要求会越来越高？（修改频繁）（每一个应用从头到尾都完整的）快速的响应多变的市场需求?

答：页面+业务代码（前后端分离开发/部署）。

2、随着业务需求不断增加，需要很多个互不相干应用部署？这些应用之间一定会需要业务交互？

分析：

以前如果都在一台服务器上（模块之间通过依赖jar完成调用）

现在都是在不同的服务器上的做的部署（分布式）。服务和服务之间通过进程间调用。

答：

解决方案：RPC/HTTP/HttpClient

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

   
   

   
   
1

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

问题：分布式事务。分布式锁。分布式Session。分布式日志。ELK

问题：

用于提高业务复用及整合的分布式服务框架(RPC)是关键。

   
   

   
   
1

1、当服务越来越多，服务和服务之间的调用非常的混乱（我都不知道你有哪些服务）

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现

   
   

   
   
1

2、例如：支付管理访问量小，部署了100台服务器。物流管理访问量大，部署了50台服务器。

第四时期

流动计算架构

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

   
   

   
   
1

SOA

面向服务的架构（SOA）。

分布式服务治理（解决方案）中间件：（Dubbo/SpringCloud)

基于访问压力实时管理集群容量，提高集群利用率。

SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

以一个公司为例：有基层员工， 有管理层， 有老板。
最初大家都听老板指挥，谁干什么谁干什么，根据需要，你可能今天干A事情，明天干B事情，后来人越来越多了，事情也越来越多了，做事情的效率越来越多，管理也很混乱，
就开始做部门划分（服务化），专门部门做专门事情的，IT部门只做研发，人事部门只做招聘； 这个时候就无法避免的发生跨部门协作（服务器调用）， 但是你怎么知道有这样一个部门可以做这个事情呢，就要依赖行政部门（注册中心），新成立的部门要在行政哪里做一个备案（服务注册），然后公布一下，让其他部门知道了（服务发布），大家就可以在新的工作秩序里面嗨皮的上班了，这个时候依然是在公司的组织架构中运转；

• 1
• 2
• 3
• 4
• 5
• 6

Dubbo 底层用的 PRC协议。（Dubbo是一个RPC框架）

SpringCloud底层用的HTTP协议。

总结：

微服务：

单体应用拆分成多个互不相干的小应用，每一个小的应用称为微服务。

SOA（面向服务架构）–》微服务架构

问题：

1、构建单体应用时，（SSM）即可。服务进行拆分（多个小应用）10个应用（大量重复的JAR包，大量重复的配置文件）？

答： SpringBoot

SpringBoot目的：就是为了简化代码的开发和简介代码的框架构建。

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

SpringBoot

Dubbo

SpringCloud

新的问题：

分布式事务： 两（二）阶段提交

分布式锁：Redis SetNX (Zookeeper)

分布式Session： Redis Spring Session

分布式日志:ELK

优点：

1、微服务对服务的拆分变的更细（复用性强），提高开发效率

2、可根据需求使用最新的.技术（选择新的技术）

3、适用于互联网项目（迭代周期短。开发效率快）

缺点：

微服务过多，服务的管理（治理） 成本高。

不利用服务的部署（Docker–>K8S)

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

对程序员的技术要求也要（Dubbo/SpringCloud)

分布式+微服务