您的位置:首页 > 运维架构 > 网站架构

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

2018-11-12 18:36 3651 查看

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

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

企业级系统架构的演变

单体式

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

 

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

JavaWeb开发之详解Servlet及Servlet容器

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

集群

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

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

分布式

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

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

li.li1 { margin: 0.0px 0.0px 0.0px 0.0px; text-align: justify; font: 10.5px "PingFang SC" } ol.ol1 { list-style-type: decimal }
  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协议的。    
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: