基于 SOA 的分布式高可用架构和微服务架构, 是时下如日中天的互联网企业级系统开发架构选择方案. 在核心思想上, 两者都主张对系统的横向细分和扩展, 按不同的业务功能模块来对系统进行分割并且使用一定的手段实现服务之间的通信, 并且基于弹性云服务搭建高可用的分布式解决方案.
但它们之间的区别可能比相似的地方要多, 特别是体现在对服务的使用和与云服务的深度结合上. 在具体实践中, 微服务的架构也可以与其它互联网中间件组合在一起, 组成规模更为庞大的 SOA 分布式系统. 本文主要对一个典型的 SOA 分布式应用的架构和组件做详细的说明.
企业级系统架构的演变
单体式
单体架构即所有系统功能和模块基于 MVC 的设计模式耦合在一个单体服务器单元中. 基于传统的 MVC 思想, 单体应用基于前后端分离的原则, 通过 Model,Control 和 View 共同来完成一个特点的服务请求. 这种传统的架构模式带了了多人团队合作, 代码更新和维护, 持续部署方面的困难, 更重要的是, 这种架构无法支持互联网行业对高并发的需求. 下图为一个典型商城应用的单体架构及其 SSM 实现架构:
关于单体式应用的更多资料, 可参看:
Javaweb 开发之详解 Servlet 及 Servlet 容器
基于 SSM 的 Java Web 应用开发原理初探
集群
至少在高并发的需求上, 单体应用的缺陷是行业所无法忍受的, 那如何提升并发性能呢? 一个直接的思路是, 把单体应用变成多体, 变成集群, 通过负载均衡分发服务请求到不同的应用服务器中. 这也是早期淘宝的解决思路. 下面是集群的架构草图:
虽然集群的架构有效解决了高并发的问题, 但是却带来了难度极大的维护和可用性问题. 另外在功能上, 哪怕是解决用户单点登录, 都需要通过 Session 广播的方式进行, 消耗了资源和宽带. 虽然集群面向高并发而生, 但是如果要达到上万的并发级别, 即便是强力增加节点数量, 性能也不会提升很大, 有其瓶颈.
分布式
上面的集群, 相当于把一份工程代码部署到多台服务器中, 每台服务器独立部署运行; 而分布式的思想是, 把系统按照模块划分为多个子系统, 多个子系统之间需要进行通信, 来共同完成业务流程. 分布式的架构如下图所示:
分布式的架构具有很多优势:
把模块拆分, 使用接口通信, 降低模块之间的耦合度.
把项目拆分成若干个子项目, 不同的团队负责不同的子项目.
增加功能时只需要再增加一个子项目, 调用其他系统的接口就可以.
可以灵活的进行分布式部署.
但是, 分布式接口通信的开发, 带来了相应的开发压力, 提高了团队的学习成本.
基于 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 的消息形式
对于消息的传递有两种类型:
一种是点对点的, 即一个生产者和一个消费者一一对应;
另一种是发布 / 订阅模式, 即一个生产者产生消息并进行发送后, 可以由多个消费者进行接收.
JMS 定义了五种不同的消息正文格式, 以及调用的消息类型, 允许你发送并接收以一些不同形式的数据, 提供现有消息格式的一些级别的兼容性.
六, 反向代理
Nginx
Nginx 是一款高性能的 http 服务器 / 反向代理服务器及电子邮件 (IMAP/POP3) 代理服务器. 由俄罗斯的程序设计师 Igor Sysoev 用 c 语言所开发, 官方测试 nginx 能够支支撑 5 万并发链接, 并且 CPU, 内存等资源消耗却非常低, 运行非常稳定, 而且开源. Nginx 的应用场景包括:
http 服务器. Nginx 是一个 http 服务可以独立提供 http 服务. 可以做网页静态服务器.
虚拟主机. 可以实现在一台服务器虚拟出多个网站. 例如个人网站使用的虚拟主机.
反向代理, 负载均衡. 当网站的访问量达到一定程度后, 单台服务器不能满足用户的请求时, 需要用多台服务器集群可以使用 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 协议的.
来源: https://www.cnblogs.com/leoliu168/p/9948245.html