互联网架构的演进之路
互联网架构的演进之路
互联网的四个阶段
-
web 1.0 时代 传统广告业务化
-
web 2.0 时代 内容产业数据化
-
互联网+ 移动互联网时代 生活服务业数据化
-
万物互联 云计算大数据时代 一切产业数据化
1. 第一阶段
单一应用架构
all in one 所有模块集中在一起,不做任何分层!
单机部署所有应用程序和软件,所有代码写在一块 称之为all in one
特点:
-
不具备代码可维护性
-
容错性差 (出错不容易恢复,无法捕获异常,处理异常,出错容易引起宕机)
分层开发
解决方案:
- 分层开发 (提高项目可维护性)【解决容错性】
- MVC 设计模式 (web 应用三层架构)
特点:
-
MVC分层开发
-
数据库独立出来
出现问题:
随着用户访问量增长,但应用已经无法满足需求。
解决方案:
集群
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低
集群部署
集群:同一个业务,部署在多个服务器上。
特点:
- 项目采用多台服务器(集群)部署
优点:
-
支持高并发
-
支持高可用
问题:
-
Session 如何共享
Redis Cluster 集群方案
-
用户请求如何转发
nginx 做请求分发,负载均衡
注意 : 好多老公司用这套架构
解决数据库压力
nginx+tomcat 集群有效减少业务层压力,但此时数据库压力增大
1. 读写分离
解决方案:
读写分离,主从复制
主从数据库之间进行数据同步,master负载均衡,slave负载操作。
MySql 本身就提供主从复制功能
问题:
- 数据库本身对模糊查询的功能支持也不是很优秀,即使做了读写分离,也很难解决搜索业务使用搜索引擎缓解数据库访问压力
2. 引入搜索引擎
流行的搜索引擎技术 solr elasticsearch whoosh
引入缓存机制减轻数据库的访问压力
随着访问量的持续增加,数据库的访问压力变的越来越大(虽然做了主从复制)。对于这些热点数据(用户访问频繁的信息),如果每都到数据库中进行查询。(很多通用查询的功能)。
放在内存中又不特别合适。(手机登录验证码操作、为了IP限制频繁访问服务器…) 尝试使用Redis.
3. 数据库拆分
数据库的水平/垂直拆分。
垂直扩展 能力终归还是有限的。
单个表: 1000万–》1个亿数据 (单个表的数据能力终归还是有限的)
表:垂直拆分。
id ,name,age,bire…tel…remark…
热数据/冷数据 --》垂直拆分方案。
表:水平拆分。
按照:时间、地区、(按照业务逻辑进行拆分)。
分库分表:
采用第三方数据库中间件:mycat sharding-jdbc drds(阿里)
当前状态特点:
通过设计保证高可用、高并发。
(不断对服务器进行扩容,支持高并发,高可用)
问题:
- 服务器成本、维护成本,人工成本?
- 可维护性差
- 可扩展性差(组件重用性基本没有)
- 协同开发不方便 (大家都去改相同的业务代码,易发生代码错误/冲突)
- 单体架构(随着业务的不断增加,代码会变得越来越多),导致服务部署时文件越来越大。
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具有以来传递特性,依赖工程所依赖的项目会传递依赖过来,可以在父工程进行版本管理,提高项目规范)
解决问题:
- 模块复用
- 解决服务器部署内容大小
闲置了大量的服务器 (如果用户对某个层访问量过大时,只需要将该业务多部署一些服务即可)
(阿里云、百度云、腾讯云、新浪云、京东云······)
在没有出现云之前:
一些公司需不需要购买服务器+需要运维人员对服务进行维护。
行业:大量Linux 运维工程师
企业: 服务器托管企业
垂直拆分:
将大的单一应用,按功能模块进行拆分
解决问题:
- 可维护性(改需求,只需要改对应模块即可)
- 功能扩展(只需要加新的模块即可)
- 协同开发(不同团队,负责不同业务模块)
- 性能扩展(灵活部署,对访问量大的服务器,多部署)
问题:
- (用户对前端页面要求越来越大,修改越来越频繁)页面变化大,每一个应用从头到尾都是完整的,如果客户要对页面进行修改,整个应用服务都需要重新部署
- 随着业务的不断增加,应用模块会越来越多,各个模块之间一定需要业务交互?
4. 第三阶段
分布式架构
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐步形成稳定的服务中心。使前端应用快速响应多变的市场需求,此时,用于提高业务复用及整合的分布式服务框架(RPC)是关键
分布式,将一个业务拆分多个子业务,部署不同服务器
针对如上情况
解决问题:
-
(用户对前端页面要求越来越大,修改越来越频繁)页面变化大,每一个应用从头到尾都是完整的,如果客户要对页面进行修改,整个应用服务都需要重新部署
前后端分离 【横着拆】
-
随着业务的不断增加,应用模块会越来越多,各个模块之间一定需要业务交互?
分析:
以前在同一个服务器上(模块之间的依赖可以完成调用)
通过上图,发现不同的应用部署在不同服务器上,服务和服务之间的调用【进程间调用】
解决方案:
RPC / HTTP(RESTful)
RPC(Remote Procedure Call)- 远程过程调用,他是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。
架构的改变会带来新的技术和新的问题
分布式事务、分布式锁、分布式Session、分布式日志管理
问题:
- 服务和服务之间的调用,会变得非常混乱
- 服务越来越多,容量评估,小服务资源浪费等问题逐渐出现
5. 第四阶段
流动计算架构
当服务越来越多,容量的评估,小服务资源浪费等问题逐渐显现,此时只需要增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率,此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键。
SOA 面向服务架构
功能: 解决多服务混乱问题
服务治理中间件(dubbo / springCloud )
基于访问压力实时管理集群容量,提高集群利用率,提高机器利用率的资源调度和治理中心
微服务架构 = 80%的SOA的服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
第五阶段
微服务架构
微服务: 单体应用拆分成互不相干具备原子性的服务,每个小应用叫微服务
问题:
-
构建单体应用时,(SSM、web.xml、需要相应的所有jar、相应的配置文件)
当拆分成多个微服务应用时(需要大量的项目(服务)创建)
springBoot 出现为了简单代码的初始化构建和开发配置
总结:
优点:
- 每个微服务都很小,这样能聚焦一个指定的业务功能或业务需求。
- 微服务能够被小团队单独开发,这个小团队是2到5人的开发人员组成。
- 微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的。
- 微服务能使用不同的语言开发。
- 微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如Jenkins, bamboo 。
- 一个团队的新成员能够更快投入生产。
- 微服务易于被一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
- 微服务允许你利用融合最新技术。
- 微服务只是业务逻辑的代码,不会和HTML,CSS 或其他界面组件混合。
- 微服务能够即时被要求扩展。
- 微服务能部署中低端配置的服务器上。
- 易于和第三方集成。
- 每个微服务都有自己的存储能力,可以有自己的数据库。也可以有统一数据库。
缺点:
-
服务过多,服务管理(治理)成本高
-
不利于部署(Docker 镜像/容器 k8s)
-
技术难点增加(分布式事务、分布式锁、分布式Session、分布式日志)
-
对团队技术能力要求增高(dubbo/springCloud)
本文地址:https://blog.csdn.net/zhj52666/article/details/107383434