架构生命周期
简介
本篇幅主要讲述架构的各阶段出现的需求问题、业务问题、性能问题以及相应的解决方案。
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)增强单机硬件性能,例如:增加CPU核数如32核,升级更好的网卡如万兆,升级更好的硬盘如SSD,扩充硬盘容量如2T,扩充系统内存如128G;
(2)提升单机架构性能,例如:使用Cache来减少IO次数,使用异步来增加单服务吞吐量,使用无锁数据结构来减少响应时间;
在互联网业务发展非常迅猛的早期,如果预算不是问题,强烈建议使用“增强单机硬件性能”的方式提升系统并发能力,因为这个阶段,公司的战略往往是发展业务抢时间,而“增强单机硬件性能”往往是最快的方法。
总结:不管是提升单机硬件性能,还是提升单机架构性能,都有一个致命的不足:单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。
-
水平扩展
- 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)
分布式+微服务