深入浅出SOA

前一阵换了份工作,来到新公司,恰好新同事问起SOA是什么,我随口说了几点,其实自己以前研究过,不过并没有详细的整理过,说的比较模糊,恰好周末,拿出点时间整理下以前对SOA的认知。

SOA是什么?SOA全英文是Service-Oriented Architecture,中文意思是中文面向服务编程,是一种思想,一种方法论,一种分布式的服务架构(具体可以百度)。

用途:SOA解决多服务凌乱问题,SOA架构解决数据服务的复杂程度,同时SOA又有一个名字,叫做服务治理。

通过一个系统我们看一下架构的演变过程(由统一到分布式):

当我们的项目比较小时,我们只有一个系统,并且把他们写到一起,放在一个服务器上,但是随着平台越来越大,数据量越来越大,我们不得不通过分库,把多个模块的数据库分别放在对应得服务器上,每个模块调用自己的子系统即可。

随着我们系统的进一步复杂度的提示,我们不得不进一步对系统的性能进行提升,我们将多个模块分成多个子系统,多个子系统直接互相调用(因为SOA一般用于大型项目,比较复杂,所以一般总系统不会再集成,会拆分多个,分别做成服务,相互调用)。当我们的电商UI进行一个下订单的任务时,多个服务直接互相调用,系统通过数据总线,分别调用对于的子系统即可。

企业数据总线:企业数据总线不是对多个子模块的集成,他在这里充当数据通道的作用,数据总线不关心业务,数据总线根据给的地址和协议去调服务,上端不关心服务在哪里是什么,只找数据总线。

上面几个图应该算是比较清楚了,随着业务的深入,我们不得不对系统进行调整,分别是对数据和业务的拆分,最后每个子系统对面提供服务。

还要提的一点就是下面那个图,下面的IP库以及几个子系统是公共服务,分别向上提供功能,也是SOA方法论的一部分。

二、SOA主要的使用场景,如下图:

通过上面的图我们可以看出,多个子系统直接相互交互,相互调用非常凌乱,这样我们就很不爽,所以我们就用到了我们的SOA架构,SOA又叫服务治理,SOA就是帮助我们把服务之间调用的乱七八糟的关系给治理起来,然后提供一个统一的标准,把我们的服务治理成下图所示,以前我们的服务是互相交互,现在是只对数据总线进行交互,这样系统就变得统一起来。

统一标准:各系统的协议、地址、交互方式。

新的交互方式:各个系统分别根据统一标准向数据总线进行注册,各子系统调用其他子系统时,我们并不关心如果找到其他子系统,我们只招数据总线,数据总线再根据统一标准找其他子系统,所以数据总线在这里充当一个只路人的作用。

SOA的好处:

1、降低用户成本,用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们,只要通过统一标准找数据总线就可以了。

2、程序之间关系服务简单

3、识别哪些程序有问题(挂掉)

缺点:提示了系统的复杂程度,性能有相应影响。

三、数据总线是什么?

其实我在上面写了,数据总线是起到调度服务的作用,数据总线不是集成服务,数据总线更新一个调度框架,每个服务需要根据约定向数据总线注册服务,那么如何注册那?其实数据总线就像一个字典结构,

数据总线里面一个key对于一个value,key指的是服务名,value则是服务的调度方式,还有一点需要说明的是,数据总线只是指路人,服务是不经过数据总线的,如上图的黄色线的路径。

数据总线通过域名解析实现:一个域名绑定多台服务器,ajax也可以,dns也可以,解析域名嘛。

其实数据总线还有一些高级应用,比如心跳检测,实现负载均衡等等,就不细说了,目前应用数据总线的有阿里的dubbo,还有zookeeper。

基本上SOA的架构体系我的理解就是这样,上面配合图基本上也算清晰,如果哪里有不对的地方,欢迎大牛指出,大家可以互相探讨,相互学习。

时间: 2024-10-11 17:05:41

深入浅出SOA的相关文章

SOA、REST 和六边形架构

SOA.REST 和六边形架构 上一篇:<IDDD 实现领域驱动设计-架构之经典分层> 阅读目录: SOA-面向服务架构 REST 与 RESTful 资源(Resources) 状态(State) 六边形架构 DDD 的一大好处就是并不需要使用特定的架构,经典分层架构只是一种,由于核心域位于限界上下文中,我们可以使用多种风格的架构,既然如此,我们应该把眼界看的更宽广些,有意思的东西多着呢. SOA 和 REST 这两个货,我们都比较熟悉,他俩并不是由 DDD 引入,但却可以适用于 DDD.我

由SOAP说开去 - - 谈谈WebServices、RMI、RPC、SOA、REST、XML、JSON

引子: 关于SOAP其实我一直模模糊糊不太理解,这种模模糊糊的感觉表述起来是这样: 在使用web服务时(功能接口),本来我就可以通过安卓中固有的http类(使用http协议),来发送http请求,并且解析返回的数据(一般是xml或者json),得到我要的结果 为什么还非得多此一举使用soap呢,而且soap自己的介绍也说,它其实没有发明技术,它其实就是http+xml 在安卓中使用soap的方法是:(下载第三方类库),装配一个soap请求体,使用soap包装过的http类,通过http把请求体发

下载-深入浅出Netty源码剖析、Netty实战高性能分布式RPC、NIO+Netty5各种RPC架构实战演练三部曲视频教程

下载-深入浅出Netty源码剖析.Netty实战高性能分布式RPC.NIO+Netty5各种RPC架构实战演练三部曲视频教程 第一部分:入浅出Netty源码剖析 第二部分:Netty实战高性能分布式RPC 第三部分:NIO+Netty5各种RPC架构实战演练

看完深入浅出的Javascript,简单写下

628页,几天的时间,慢慢的从头看过来,也一遍遍实践过来,一些概念一直都知道,但是程序的世界就是这样,所有的东西就是那些,但是就是喜欢看这种深入浅出的书,就是喜欢看自己知道的东西,能讲出来多少不一样的角度,真的还是有很多收获. 这也许就是技术的魅力,可以给你一个安心的地方 但是这里有的是无止境的学习,而且这里也会交给你做事的道理,也许不太能教会你职场的学问,不能教你怎么做生意,但是这里教给你的,内化在心里的是别人谁也没有办法抢走的,这就是我们学习语言的乐趣所在. 即使是半路出家,及时我接触网络的

Rxjava+ReTrofit+okHttp深入浅出-终极封装

Rxjava+ReTrofit+okHttp深入浅出-终极封装 背景: 学习Rxjava和retrofit已经很长时间了,功能确实很强大,但是使用起来还是有点复杂,代码的重复性太高,所以决定把基于retrofit和rxjava的处理统一封装起来,实现的功能: 1.Retrofit+Rxjava+okhttp基本使用方法 2.统一处理请求数据格式 3.统一的ProgressDialog和回调Subscriber处理 4.取消http请求 5.预处理http请求 5.返回数据的统一判断 效果: 封装

深入浅出JMS(二)--ActiveMQ简单介绍以及安装

现实的企业中,对于消息通信的应用一直都非常的火热,而且在J2EE的企业应用中扮演着特殊的角色,所以对于它研究是非常有必要的. 上篇博文深入浅出JMS(一)–JMS基本概念,我们介绍了消息通信的规范JMS,我们这篇博文介绍一款开源的JMS具体实现--ActiveMQ.ActiveMQ是一个易于使用的消息中间件. 消息中间件 我们简单的介绍一下消息中间件,对它有一个基本认识就好,消息中间件(MOM:Message Orient middleware). 消息中间件有很多的用途和优点: 1. 将数据从

深入浅出nodejs(一) 模块加载机制

声明: 深入浅出nodejs系列文章将会在后面持续更新. 该系列文章部分参考 朴灵<深入浅出nodejs>,并加以总结补充 你真的了解require函数吗? 看似简单的require函数, 其实内部做了大量工作...下面我们将详细说明require为我们所做的一切 nodejs模块加载原理 node加载模块步骤: 1) 路径分析 (如判断是不是核心模块.是绝对路径还是相对路径等) 2) 文件定位 (文件扩展名分析, 目录和包处理等细节) 3) 编译执行 原生模块加载顺序 1) 缓存 2) 本地

SOA与基于CDIF的API的联动

几千年来,巴别塔的故事一直是人类面对的一个核心的困境.为了交流和沟通我们人类创造出语言,但沟通与交流仍然存在障碍……相同语言之间的沟通依语境的不同,尚且存在巨大的鸿沟,不同语言之间更是让人坐困愁城. 在物质文明高度发达.人工智能都已触手可及的今天,程序员一样在面对这样的困境.我们的先辈基于那时的技术条件,基于那时的业务需求,映射性地逐步发展出FORTRAN/COBOL这样命令式的程序设计.C/PASCAL这样过程式的程序设计,到C++/JAVA这样的面向对象的程序设计,再到今天WebServic

面向服务的体系架构(SOA)—架构篇

面向服务的体系架构(SOA)-架构篇 1.面向服务的体系架构(SOA) 面向服务的架构(service-oriented architecture)是Gartner于2O世纪9O年代中期提出的面向服务架构的概念.2002年的l2月,Gartner提出"面向服务的架构(SOA)"是"现代应用开发领域最重要的课题"之后.国内外计算机专家.学者掀起了对SOA的积极研究与探索. 在分布式的环境中,将各种功能都以服务的形式提供给最终用户或者其他服务.如今,企业级应用的开发都采