基于SOA的高并发和高可用分布式系统架构和组件详解

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: 基于SOA的分布式高可用架构和微服务架构,是时下如日中天的互联网企业级系统开发架构选择方案。在核心思想上,两者都主张对系统的横向细分和扩展,按不同的业务功能模块来对系统进行分割并且使用一定的手段实现服务之间的通信,并且基于弹性云服务搭建高可用的分布式解决方案。

基于SOA的分布式高可用架构和微服务架构,是时下如日中天的互联网企业级系统开发架构选择方案。在核心思想上,两者都主张对系统的横向细分和扩展,按不同的业务功能模块来对系统进行分割并且使用一定的手段实现服务之间的通信,并且基于弹性云服务搭建高可用的分布式解决方案。

但它们之间的区别可能比相似的地方要多,特别是体现在对服务的使用和与云服务的深度结合上。在具体实践中,微服务的架构也可以与其它互联网中间件组合在一起,组成规模更为庞大的SOA分布式系统。本文主要对一个典型的SOA分布式应用的架构和组件做详细的说明。

企业级系统架构的演变

单体式

单体架构即所有系统功能和模块基于MVC的设计模式耦合在一个单体服务器单元中。基于传统的MVC思想,单体应用基于前后端分离的原则,通过Model、Control和View共同来完成一个特点的服务请求。这种传统的架构模式带了了多人团队合作、代码更新和维护、持续部署方面的困难,更重要的是,这种架构无法支持互联网行业对高并发的需求。下图为一个典型商城应用的单体架构及其SSM实现架构:

 

关于单体式应用的更多资料,可参看:

JavaWeb开发之详解Servlet及Servlet容器

基于SSM的Java Web应用开发原理初探

集群

至少在高并发的需求上,单体应用的缺陷是行业所无法忍受的, 那如何提升并发性能呢?一个直接的思路是,把单体应用变成多体,变成集群,通过负载均衡分发服务请求到不同的应用服务器中。这也是早期淘宝的解决思路。下面是集群的架构草图:

虽然集群的架构有效解决了高并发的问题,但是却带来了难度极大的维护和可用性问题。另外在功能上,哪怕是解决用户单点登录,都需要通过Session广播的方式进行,消耗了资源和宽带。虽然集群面向高并发而生,但是如果要达到上万的并发级别,即便是强力增加节点数量,性能也不会提升很大,有其瓶颈。

分布式

上面的集群,相当于把一份工程代码部署到多台服务器中,每台服务器独立部署运行;而分布式的思想是,把系统按照模块划分为多个子系统,多个子系统之间需要进行通信,来共同完成业务流程。分布式的架构如下图所示: 

分布式的架构具有很多优势:

  1. 把模块拆分,使用接口通信,降低模块之间的耦合度。
  2. 把项目拆分成若干个子项目,不同的团队负责不同的子项目。
  3. 增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。
  4. 可以灵活的进行分布式部署。

但是,分布式接口通信的开发,带来了相应的开发压力,提高了团队的学习成本。 

基于SOA的架构

SOA:Service Oriented Architecture面向服务的架构。也就是把工程都拆分成服务层工程、表现层工程。服务层中包含业务逻辑,只需要对外提供服务即可。表现层只需要处理和页面的交互,业务逻辑都是调用服务层的服务来实现。工程都可以独立部署。 

在一个典型的SOA架构中,加入了大量的中间件和子系统,用于解决分布式架构中的服务通信及衍生问题,具体包括服务间通信、负载均衡、反向代理、信息中心、文件管理、主从备份等等。

核心模块和中间件详解

SOA架构为高并发而生,需要解决高并发下不同服务之间的通信问题。在实践中,SOA架构需要配合多种中间件技术,包括缓存服务、数据库中间件、服务发布和订阅、消息队列等等。以下为一个典型的SOA商城架构简图:

一、系统间通信

一般来说,基于SOA的架构,它的表现层和服务层是不同的工程。所以要实现一个服务流程需要两个系统之间进行通信。那么如何实现远程通信?常用的方式包括:
1、使用WebService:效率不高,它是基于SOAP协议(http+xml)。项目中不推荐使用。
2、使用Restful形式的服务:http+json。很多项目中应用。如果服务越来越多,服务与服务之间的调用关系复杂,调用服务的URL管理复杂,什么时候添加机器难以确定。
3、使用Dubbo。使用rpc协议进行远程调用,直接使用socket通信。传输效率高,并且可以统计出系统之间的调用关系、调用次数,管理服务。
Dubbo
DUBBO是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,是阿里巴巴SOA服务化治理方案的核心框架,每天为2,000+个服务提供3,000,000,000+次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点。Dubbo组件的架构和工作机制如下图所示:

Zookeeper

注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互,注册中心不转发请求,压力较小。使用dubbo-2.3.3以上版本,建议使用zookeeper作为注册中心。
Zookeeper是Apacahe Hadoop的子项目,是一个树型的目录服务,支持变更推送,适合作为Dubbo服务的注册中心,工业强度较高(稳定性好),可用于生产环境,并推荐使用。

二、分布式文件服务器

在分布式应用中,无法通过传统手段解决文件上传和下载问题。因此,对于文件上传,业务系统节点可以把文件集中到分布式文件服务器做统一管理,而用户访问,也可以通过分布式文件服务器提供快速的文件下载支持。

FastDFS

FastDFS是用c语言编写的一款开源的分布式文件系统。FastDFS为互联网量身定制,充分考虑了冗余备份(高可用)、负载均衡(高并发量)、线性扩容(添加服务器或者磁盘)等机制,并注重高可用、高性能等指标,使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。
FastDFS架构包括 Tracker server和Storage server。客户端请求Tracker server进行文件上传、下载,通过Tracker server调度最终由Storage server完成文件上传和下载。
  • Tracker server作用是负载均衡和调度,通过Tracker server在文件上传时可以根据一些策略找到Storage server提供文件上传服务。可以将tracker称为追踪服务器或调度服务器。
  • Storage server作用是文件存储,客户端上传的文件最终存储在Storage服务器上,Storage server没有实现自己的文件系统而是利用操作系统 的文件系统来管理文件。可以将storage称为存储服务器。

FastDFS架构和工作机制如下图所示:

三、负载均衡

以一个SOA商城系统为例,它的首页是系统的门户,也就是系统的入口。所以首页的访问量是这个系统最大的。如果每次展示首页都从数据库中查询首页的内容信息,那么势必会对数据库造成很大的压力,所以需要使用缓存来减轻数据库压力。实现缓存的工具有很多,现在比较流行的是Redis。
Redis是用C语言开发的一个开源的高性能键值对(key-value)数据库(nosql),应用在缓存、任务队列等场景较多。

四、搜索功能

Solr

SolrCloud(solr 云)是Solr提供的分布式搜索方案,当你需要大规模,容错,分布式索引和检索能力时使用 SolrCloud。当索引量很大,搜索请求并发很高,这时需要使用SolrCloud来满足这些需求。
SolrCloud是基于Solr和Zookeeper的分布式搜索方案,它的主要思想是使用Zookeeper作为集群的配置信息中心。Solr集群架构图如下:
Zookeeper它有几个特色功能:
  • 集中式的配置信息(数据库连接池的配置文件,修改文件不用重启就可以生效)
  • 自动容错
  • 近实时搜索
  • 查询时自动负载均衡

五、消息队列

MQ

MQ是一个消息中间件,比如:ActiveMQ、RabbitMQ、kafka都属于MQ,是MQ的产品。一般可以考虑使用Apache开源的消息队列ActiveMQ。

ActiveMQ的消息形式 

对于消息的传递有两种类型:
  1. 一种是点对点的,即一个生产者和一个消费者一一对应;
  2. 另一种是发布/订阅模式,即一个生产者产生消息并进行发送后,可以由多个消费者进行接收。
JMS定义了五种不同的消息正文格式,以及调用的消息类型,允许你发送并接收以一些不同形式的数据,提供现有消息格式的一些级别的兼容性。
六、反向代理
Nginx
Nginx是一款高性能的http 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。由俄罗斯的程序设计师Igor Sysoev用c语言所开发,官方测试nginx能够支支撑5万并发链接,并且cpu、内存等资源消耗却非常低,运行非常稳定,而且开源。Nginx的应用场景包括:
  1. http服务器。Nginx是一个http服务可以独立提供http服务。可以做网页静态服务器。
  2. 虚拟主机。可以实现在一台服务器虚拟出多个网站。例如个人网站使用的虚拟主机。
  3. 反向代理,负载均衡。当网站的访问量达到一定程度后,单台服务器不能满足用户的请求时,需要用多台服务器集群可以使用nginx做反向代理。并且多台服务器可以平均分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的情况。
七、主从备份
Keepalived
keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。
虚拟路由冗余协议,可以认为是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip(VIP = Virtual IP Address,虚拟IP地址,该路由器所在局域网内其他机器的默认路由为该vip),master会发组播,当backup收不到VRRP包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。
keepalived主要有三个模块,分别是core、check和VRRP。core模块为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析。check负责健康检查,包括常见的各种检查方式。VRRP模块是来实现VRRP协议的。
 
 
相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
目录
相关文章
|
13天前
|
消息中间件 存储 设计模式
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
175 21
RocketMQ原理—5.高可用+高并发+高性能架构
|
5月前
|
存储 SQL 关系型数据库
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
496 3
Mysql高可用架构方案
|
4月前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
153 11
|
4月前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
98 11
|
4月前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
5月前
|
监控 前端开发 数据可视化
3D架构图软件 iCraft Editor 正式发布 @icraft/player-react 前端组件, 轻松嵌入3D架构图到您的项目,实现数字孪生
@icraft/player-react 是 iCraft Editor 推出的 React 组件库,旨在简化3D数字孪生场景的前端集成。它支持零配置快速接入、自定义插件、丰富的事件和方法、动画控制及实时数据接入,帮助开发者轻松实现3D场景与React项目的无缝融合。
354 8
3D架构图软件 iCraft Editor 正式发布 @icraft/player-react 前端组件, 轻松嵌入3D架构图到您的项目,实现数字孪生
|
4月前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
102 11
|
5月前
|
SQL 数据采集 分布式计算
【赵渝强老师】基于大数据组件的平台架构
本文介绍了大数据平台的总体架构及各层的功能。大数据平台架构分为五层:数据源层、数据采集层、大数据平台层、数据仓库层和应用层。其中,大数据平台层为核心,负责数据的存储和计算,支持离线和实时数据处理。数据仓库层则基于大数据平台构建数据模型,应用层则利用这些模型实现具体的应用场景。文中还提供了Lambda和Kappa架构的视频讲解。
601 3
【赵渝强老师】基于大数据组件的平台架构
|
5月前
|
缓存 关系型数据库 MySQL
高并发架构系列:数据库主从同步的 3 种方案
本文详解高并发场景下数据库主从同步的三种解决方案:数据主从同步、数据库半同步复制、数据库中间件同步和缓存记录写key同步,旨在帮助解决数据一致性问题。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
高并发架构系列:数据库主从同步的 3 种方案
|
5月前
|
缓存 负载均衡 网络协议
高并发架构的CDN知识介绍
本文详细介绍了网络请求过程,特别是大型网站架构中DNS和CDN的作用。通过一张常用架构图,文章解释了从客户端请求到服务器响应的全过程,包括DNS解析、负载均衡、CDN加速等关键环节,帮助读者深入了解高并发架构的设计原理和优化方法。
362 1

热门文章

最新文章