欢迎各位兄弟 发布技术文章

这里的技术是共享的

You are here

如何通俗易懂地解释什么是SOA 有大用

           

对于SOA,感觉这个概念性的东西没那么容易理解,看了各位大神的解释感觉很多都说的很抽象,所以想尝试用自己的语言解释下,仅做参考。


               

SOA粗暴理解:把系统按照实际业务,拆分成刚刚好大小的、合适的、独立部署的模块,每个模块之间相互独立。


               

比如现我有一个数据库,一个JavaWeb(或者PHP等)的网站客户端,一个安卓app客户端,一个IOS客户端。

现在我要从这个数据库中获取注册用户列表,如果不用SOA的设计思想,那么就会这样:JavaWeb里面写一个查询方法从数据库里面查数据然后在网页显示,安卓app里面写一个查询方法查询后在app上显示,IOS同样如此。这里就会出现查询方法重叠了,这样的坏处很明显了,三个地方都有相同的业务代码,要改三个地方都要改,而且要改的一模一样。当然问题不止这一个。

于是乎出现了这样的设计思想,比如用Java(或者是其他语言皆可)单独创建一个工程部署在一台服务器上,并且写一个方法(或称函数)执行上述查询操作,然后使其他人可以通过某种途径(可以是http链接,或者是基于socket的RPC调用)访问这个方法得到返回数据,返回的数据类型是通用的json或者xml数据,就是说把这个操作封装到一个工程中去,然后暴露访问的方式,形成“服务”。比如这里就是注册用户服务,而关于注册用户的所有相关增删改查操作这个服务都会提供方法。

这样一来,JavaWeb这边可以访问这个服务然后得到数据使用,安卓和IOS这里也可以通过这个服务得到数据。而且最重要的是,要修改关于注册用户的业务方法只要改这个服务就好了,很好的解耦。同理,其他业务比如商品、广告等业务都可以单独形成服务部署在单独服务器上。

还有就是一旦哪天突然有一堆人要注册,假设这堆人仅仅只是注册而不做其他事情,其他业务比如商品、广告服务等都不忙,唯独注册这个功能压力很大,而原有的一台部署了注册服务的服务器已经承受不了这么高的并发,这时候就可以单独集群部署这个注册服务,提供多几台服务器提供注册服务,而其他服务还不忙,那就维持原样。

当然,还有很多其他好处。


               

以上我所描述的都还不能完全称为SOA,还不够完整,因为它少了服务治理这一环节。

什么是服务治理,就是当服务越来越多,调用方也越来越多的时候,它们之间的关系就变得非常混乱,需要对这些关系进行管理。举例,还是上面的例子,假如我有一个用户服务,一开始有调用方1和调用方2来使用这个服务,后来越来越多,将近上百个调用方,这个时候作为服务方,它只知道提供服务,却不知道具体为谁提供了服务。而对于开发者来说,知道这N多调用方和N多服务方之间的关系是非常重要的。

所以这个时候就需要能进行服务治理的框架,比如dubbo+zookeeper,比如SpringCloud,有了服务治理功能,我们就能清晰地看到服务被谁谁谁调用,谁谁谁调用了哪些服务,哪些服务是热点服务需要配置服务器集群,而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。

这个时候就是更加完善一点的SOA了。

当然,还可以更进一步,加上服务监控跟踪等等等等之类的。


               

实际上SOA只是一种架构设计模式,而SOAP、REST、RPC就是根据这种设计模式构建出来的规范,其中SOAP通俗理解就是http+xml的形式,REST就是http+json的形式,RPC是基于socket的形式。上文提到的CXF就是典型的SOAP/REST框架,dubbo就是典型的RPC框架,而SpringCloud就是遵守REST规范的生态系统。


               

以上就是我的个人理解,有错漏请指正、

           
编辑于 2019-10-14                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           
《微服务设计》第1.3节:
               
SOA是一种设计方法,其中包含多个服务,而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用,而非采用进程内调用的方式进行通信。

感觉够通俗易懂了,就偷个懒不做比喻了,感谢邀请。
           
编辑于 2017-01-23                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

通俗地讲?就通俗下。

农民怎么养猪的?围个场地让猪跑,去餐馆弄泔水,下地打猪草,一个人包圆了。后来来了个奇怪的猪,不吃餐馆的泔水,只吃猪草,那要教育好多农民伯伯怎么养,改变养猪方式,结果没几个月又来了奇怪的猪,一定要喂82年的啥,只好又教育一遍农民伯伯。

后来某易的磊磊去养猪。他让一波人专门锻炼猪,一拨人专门打泔水,一拨人专门打猪草,还修了仓库和道路,路上运送猪猪,猪猪早上运到训练场,中午弄到泔水厂,晚上弄到猪草厂。来了不吃餐馆泔水的猪,那这猪就绕着泔水厂走。专门喝82年的,就有弄了波人专门做假酒,喝82年的猪就在晚上多去一次假酒厂。

两者的区别,你看增加了一种猪,不需要全部人员都教育一遍,对吧,原来的基础设施还能重用,有了道路改变养猪方法更容易了( •̀ ω •́ )y。即便来了更多奇怪的猪猪,也就是在道路上挂上新的工厂呗。多好。

这就是SOA养猪法。

           
编辑于 2017-11-22                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

我们使用maven进行项目的模块化进行管理,它有2中管理方式,一种是水平切分一种是垂直。垂直管理就是项目分模块进行管理,优点是项目模块特别清晰,但是代码耦合性高,一个登陆模块就是管登陆的,这块单管搜索就是搜索的。 那么SOA就是水平切分,web层切出来了,service层做了一个分布式服务架构,这样提高代码的常用性,第一种会项目变大一倍,而现在你用你就引。分布式服务架构涉及到了dubbo的技术

           
发布于 2017-11-01                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

SOA

Service Oriented Ambiguity 即面向服务架构, 简称SOA。

SOA的提出是在企业计算领域,就是要将紧耦合的系统,划分为面向业务的,粗粒度,松耦合,无状态的服务。服务发布出来供其他服务调用,一组互相依赖的服务就构成了SOA架构下的系统。

首先,你要知道SOA并不是某一种具体的技术实现,它是一个系统架构的设计思想。这个架构设计思想的提出背景是随着我们的软件系统解决的问题越来越复杂,那么会带来难以维护、难以扩展,容易出错等问题。那么SOA思想的提出就是为了解决这个问题。

举个生活中的例子,随着人们生活水平的提高,出现了越来越多的肥胖人群,肥胖会容易带来一些高血压、糖尿病的发病几率,有人就得出了“减肥”这想法来解决肥胖,减肥不但降低得那些病的几率,还可以让人变得更漂亮。

不同的厂商和个人对SOA有着不同的理解,但从SOA的定义中可以看到几个关键特性:

一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。                

SOA的技术实现是什么?继续往下看


               

web serveice

1996年SOA的思想被提出,它只是一个理论概念。到了2000年,W3C才成立了相关的委员会,开始讨论Web Service的相关标准,各大厂商一边积极参与标准制定,一边推出了一系列实实在在的产品。新的技术和新的产品出现,SOA找到了可以落地的技术方案。

有人提出节食可以变瘦,一天只吃一顿;有人提出运动可以变瘦,一天跑2000米,“减肥”的想法终于有了具体的实施方案。

你要明白一个关系:SOA不是Web Service,Web Service是实现SOA的一种具体的技术方案。

Web Service的定义:                

Web Service是一个平台独立的,低耦合的,自包含的、基于可编程的web的应用程序,可使用开放的XML(标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序,用于开发分布式的互操作的应用程序。

Web Service有三个部分组成,分别解答三个问题:

  • 服务之间如何传输数据?

  • 数据的格式是怎样的?

  • 如何发布和查找这些服务?

SOAP                

Simple Object Access Protocol,即简单对象访问协议, 简称SOAP。

SOAP是基于XML在分散或分布式的环境中交换信息的简单的协议,用于访问网络服务。可使应用程序在 HTTP 之上进行信息交换。

如果你用Wireshark这种网卡级别的抓包工具抓取过SOAP的信息就会发现它传输数据用的HTTP协议。所以,许多人以为SOAP就是HTTP+XML,或者认为SOAP是HTTP的post请求的一个专用版本,遵循一种特殊的XML消息格式。

虽然,我们看到的情况确实如此,但这并不是SOAP本质与全部。当SOAP消息真正需要在网络上实际传输的时候,SOAP消息能够与不同的底层传输协议进行绑定,同时,SOAP消息可以在很多种消息传输模式中使用。包括超文本传输协议(HTTP),简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME)。但是,目前SOAP的实现只通过与HTTP进行绑定这么一种。所以,就变成我们看到的这一种样子。

WSDL                

Web Services Description Language,即网络服务描述语言,简称WSDL。它是一门基于XML的语言,用于描述Web Services以及如何对它们进行访问。

WSDL格式:


               

<definitions>

<types>
   definition of types........
</types>

<message>
   definition of a message....
</message>

<portType>
   definition of a port.......
</portType>

<binding>
   definition of a binding....
</binding>

</definitions>
               

WSDL文档主要使用以下几部分组成:

  • <portType> Web Service执行的操作。

  • <message> Web Service使用的消息。

  • <types> Web Service使用的数据类型。

  • <binding> Web Service使用的通信协议。

UDDI                

Universal Description, Discovery and Integration",可译为“通用描述、发现与集成服务”,简称UDDI。

UDDI是一个独立于平台的框架,通过使用Internet来描述服务,发现企业,并对企业服务进行集成。

图:

扩展:                

如何开发一个Web Service服务,使用这个项目:
https://pypi.org/project/spyne/                

如何调用Web Serveice服务(即接口),参考这个项目:
https://pypi.org/project/suds-jurko                

终于把Web Service给你讲清楚了,但是,我要告诉你,Web Service技术过时了。我认为由以下两个原因:

1、技术实现比较麻烦。我用spyne开发过Web Service服务,实现比较麻烦,跟Flask Web框架实现个HTTP接口没法比。

2、数据描述太臃肿,XML描述数据本来就不够简洁,WSDL在XML的基础上定义数据的传输格式就更复杂了。跟JSON这种格式描述数据没法比。


               

HTTP

HyperText Transfer Protocol,超文本传输协议,简称HTTP。HTTP是因特网上应用最为广泛的一种网络传输协议。

我想这个我不需要做过多的介绍,但有一个问题你要搞明白,HTTP协议和接口是什么关系?

我举一个生活当中的例子:高速公路和物流是什么关系? 高速公路规定什么样的工具才能上高速(轮船、飞机机不行),必须带轮子的车,上路之后如何运行,每个车道的时速多少等,车必须按照规则才能在上面运行。 物流是一个模糊的概念,这一般指运输公司运送货物。高速公路只能跑物流吗?当然不是,运输人也可以嘛。物流也不是定走高速公路,走航空的物流也是可以的。高速公路就是HTTP协议,物流就是接口。

启动的Chrome浏览器,打开前端开发者工具,切换到“network”标签,刷新页面。你看到了什么?JS、CSS、Img、media、font、doc、WS、Other等。各种类型的数据,哪个是接口?

JSON                

JavaScript Object Notation, JavaScript 对象表示法,简称JSON。JSON是存储和交换文本信息的语法。类似XML。JSON比XML更小、更快,更易解析。

在接口的技术实现上 JSON和HTTP是最佳拍档。它可以更简洁的描述要传输的数据,而且解析也很简单。

物流要运的货物,车厢如何设计节省空间,能装更多的货物,装货/卸货方便。货物是数据,车厢设计就是数据格式。


               

RESTful

Representational State Transfer,中文直译感觉不对味,简称REST,如果一个架构符合REST原则,就称它为RESTful架构。

REST只是一个接口设计的风格。

古代的物流叫走镖,走镖是有讲究的,前面有一个喊口号的人叫“趟子手”,例如中原镖局一般喊:“中原镖局,请江湖朋友让个道!” 这江湖规矩,你可以把这种江湖规矩看成REST风格。

比如,一个通过id查询用户信息的接口。

  • 一般的风格

/get_user/?id=1
               
  • REST风格

/user/1/
               

扩展:
请参考阮一峰的博客:
http://www.ruanyifeng.com/blog/2011/09/restful.html                


               

RPC

Remote Procedure Call,远程过程调用。RPC通常特指在一个应用中调用另一个应用的接口而实现的远程调用。

一个RPC框架的实现包含以下部分:

  • 动态代码

  • 序列化和反序列化

  • 通信

  • 异常处理

其中,通信部分可使用HTTP协议(七层协议),如 grpc框架使用的就是HTTP2协议;也可以使用TCP/UDP协议(四层协议),如dubbo使用的是TCP协议。

这就好比顺丰快递,他们有自己的一套物流系统,可以走高速,也可以走空运;不仅仅是包含的运送这一项服务,还有上面取件、称重打包,自己的仓储,分拣中心,甚至货物寄丢了还有保险理赔等。你选择了一个rpc框架就相当于选择了一个物流公司的全套服务。

本文的编写我又翻阅了不少资料,并且加入了自己的思考。通过这一些例子来帮助你理解这些概念。

           
发布于 2020-03-05                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

SOA英文直译是,面向服务的体系结构。
或者说是以服务为核心的体系结构,SOA只是描述了软件成型后的样子,就像面向对象编写的程序,都是一个一个类组成的。面向服务的软件,可以理解为是由一个一个服务组装成的。
SOA是一种问题解决方法或者解决框架。
比如你现在有很多服务:新闻服务(提供新闻的发布,查看,修改,删除),订单服务(订单添加,订单修改,订单查看,订单删除等)财务服务(收入,支出,统计等等)员工服务(新增,修改,查看,统计)考勤服务(签到,签退,导出,统计等)销售服务(卖出上报,销售统计。)

假如你是一个销售集团,有1000家经销商,有50个分公司,有400个办事处,它们都需要软件办公。但是你不可能做一个最全的系统开放他们用。因为很多分公司,经销商,办事处都有定制功能。那你应该开发多少套,多少种系统呢?每种系统都从头开始写代码,直接访问数据库吗?

假如在加上,手机版,aap版,平板电脑版,电脑版桌面版,网页版。你怎么办呢?

这个时候再去看看SOA的概念就容器理解了,其实单靠soa无法解决这么复杂的问题,还需要很多组合方法。
           
发布于 2017-01-19                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

三个生活小故事,大白话微服务的那些概念:服务化,微服务,SpringCloud,服务治理

关于SOA,微服务这些概念

  • 不能单独的去理解,新技术会站在老技术的基础上,解决老技术出现的问题的同时,进行迭代和演化

  • 直接看概念也有问题,不太好理解,所以我写了三个小故事,通过生活的小故事更加轻松的理解微服务相关的概念

小故事讲明白架构演变                

鹿老师的Java笔记:F版本SpringCloud1—大白话为啥要有微服务?啥是微服务?                

搭建微服务架构就像是买电脑                

鹿老师的Java笔记:F版本SpringCloud 2—什么是SpringCloud?SpringCloud版本选择                

服务注册与发现,就像是租房子一样                

鹿老师的Java笔记:F版本SpringCloud 3—大白话Eureka服务注册与发现                

收藏等于白嫖,点赞才是真爱

               


               

           
发布于 2020-03-27                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

我节选了我的一篇文章中SOA与微服务对比一节

               

SOA与微服务的优劣对比

往往没有对比就没有伤害,因此我们通过SOA架构与微服务架构的对比,来更深刻的认识SOA架构的优势与劣势,同时也能掌握到微服务优劣特征。

                   
单体向微服务过渡架构

我们往往会从上图的角度去寻求微服务的发展踪迹,也就是单体向微服务的过渡。但很少有人会去从SOA的变种这个角度去思考微服务。                

点这里↓阅读文章版                

通俗地理解面向服务的架构(SOA)以及微服务之间的关系mp.weixin.qq.com图标                

因此我们需要定义一个问题,微服务到底和SOA有没有关系?其实,这其中就隐藏着两种关系:

  • (1)微服务简化了SOA架构思想,是SOA一个离经叛道的继任者,

  • (2)微服务进行了SOA基因改造,成了一个新的变种,

微服务是SOA一个离经叛道的继任者,其实这是一句赞美之词!

我们来看看微服务和SOA比起来有多么的相似,又多么的不同。

(1)微服务专注小的个体问题,形成服务,通过松耦合的通讯机制协作起来,解决更大的问题;反之,SOA一开始就专注大的协调问题,首先关注的是服务协议、规则、表述的统一性,然后才是设计足够大的独立服务,并通过流程建模,解决整体上的问题。

(2)微服务倾向于拆分,也就是将单体应用尽量拆分到一个适当的粒度,形成个人或小团队去关注独立的服务个体;但SOA不同,服务要足够的粗粒度,服务接口只是作为异构系统调用的统一手段,甚至我们可以将一个大系统作为SOA的一个构建服务而独立存在,例如前面说到的应急指挥系统的SOA架构中通讯调度系统作为一个独立的SOA服务而存在。

(3)微服务的实施模式是自底向上型:不同的小团队分配不同的微服务进行开发、构建、部署、发布。系统整体上的把控,是在发布、测试过程中所有团队共同参与的结果,这时候开发变成了运维,运维变成了顾问,这就是Devops的思想,因此微服务更适合小型团队的持续化发布;反之SOA是自顶向下的实施模式,必须进行分层式的过程管理,要有人对流程管理负责、ESB企业数据总线负责、各个构件服务也是不同组织的项目或开发团队负责。因此SOA架构在实施过程中具备清晰的责任关系,特别适合项目跨企业、大企业跨部门的复杂应用系统建设。这和微服务的实施过程可以说是天壤之别。

(4)微服务与SOA一样,都是在分布式环境下,形成很多不同的独立服务,相对于SOA,微服务是细粒度的,SOA是粗粒度的,而且它们在技术的异构性的兼容上有着一致的风格,微服务是通过通讯机制,主要是Restful,实现不同微服务的相互协作,但微服务自身用什么技术来实现,那都不影响;同样前面的内容也说清楚了SOA的服务接口定义和Webservices实现,本身就是为了统一兼容异构平台之间的协作。

从上面的对比,我们可以看到不能把任何问题都统一论之。微服务有其适合的场景,若在一个复杂的社会关系体系下建立一套复杂的应用系统,微服务的架构思想就是无源之水了。反倒是SOA架构思想就具备这种复杂体系下的生存条件,但是,例如放到很多互联网应用需要快速应对需求、敏捷迭代开发,灵活建立部署发布机制,那么SOA架构肯定就不适合了,这种环境正是微服务架构所适应的。

因此我们可以总结到微服务在形式上与SOA很类似,在分布式环境中都是进行更多独立的服务、独立的部署,我们可以理解是SOA的继任者。但是骨子里微服务又将SOA那一套沉重的前期规划、设计和分层实施的思路彻底打烂,形成了一个新的思想变种,灵活、敏捷、小巧,更适合团队密切的协作。这就是进行了SOA基因的彻底改造,形成了更简化的一种分布式架构形态,尤其满足更为互联网化应用的需求。

关注                 

 了解更多大数据知识


               

编辑于 04-08                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

讲这个问题,首先要有一个层次感,如面向服务的体系架构soa怎么被逼出来的??
在计算机土耕火种的社会,每个系统都是独立的,这时的架构名称:单一应用架构,其特征:极其简单,极其low逼。
随着社会进步,互联网发展,无求无尽的业务需求,单一应用架构已不能支持业务体系的发展,各类需求人员与程序员各种撕逼,于是产生了:垂直应用架构体系。其特征:解决了单一应用架构面临的扩容问题,流量可以分散到各个子系统中,且系统体积可控,提升了开发效率。但是不幸的事又发生了,当垂直应用越来越多时,应用之间相互交互,相互调用,已避无可避。刚开始的做法是,不同系统之间存在重叠的业务,这样就出现了一个几个形容名词,此架构容易形成信息孤岛,重复造轮子(哥们,知道这词怎么来的了?开心否)。

这词名词咋解决嘞?新的撕逼大战随即拉开,为了解决这些个名词,此时相对核心的业务会被抽取出来,作为单独的系统对外提供服务,形成业务之间的相互复用。在这点上重复造轮子消失了!
这时一个闪亮的名字登场:面向服务的体系架构(SOA)
好了,历史讲完了。历史中说了,是什么? 开始说说这个架构适合什么业务场景和怎么用。。。好像你没有问
那么,再见!!!
           
编辑于 2016-05-12                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

看不如直接用理解的快,实践是检验真理的唯一标志,请看dubbo

http://dubbo.io/docs/dubbo-user-book.pdf                


               

           
发布于 2017-11-22                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           
一个可自由组装拆卸的变形金刚            
发布于 2016-04-05                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

不恰当的比方,开饭店普通饭店,一下来了10个人,大家围成一桌开始点菜吃饭,你烧完一桌菜又来了20个人,这20个人点的菜有的和刚才10个人点的重复,当然也有不一样的,但是会出现这样一个问题,这20个人,除了小李和老王其他都不喜欢吃猪蹄,结果呢老王吃把菜点上了,结果最后剩下很多造成了浪费,而且因为店面人手不足的问题,如果出现一下来了好几拨人情况,会忙不过来.


               

某一天这个老板萌生出开自助餐的概念,甭管客人想吃什么,在饭点之前先把各式各样的菜先烧好,你来10个人也好,100个人也好,自己真正喜欢吃什么,有什么需求自己去对应的位置拿菜.


               

这就是我对SOA的粗浅理解,仅供参考.

           
编辑于 2017-11-02                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续

*** 面向服务架构设计SOA及其应用

UDDI:统一描述、发现、集成协议


               

WSDL: web service description language


               

服务定义和描述

服务如何访问:数据格式、协议

服务位于何处:url等


               

以端口集合的形式来描述。

包含:

对一组操作和消息的抽象定义

绑定到这些操作和消息的具体协议

对应的网络端点endpoit规范


               


               

**** 技术例子

soa可以理解为一种架构设计模式

soap、rest、rpc就是根据这种设计模式构建出来的规范

soap是http+xml的形式

rest是http+json的形式,代表案例是SpringCloud

rpc是基于socker的形式,代表是dubbo,grpc


               

**** 业务例子

电子商务的例子:

注册服务

用户服务

商品服务

订单服务

广告服务

售后服务

商家服务

等等


               

**** 服务治理

服务多了,就需要治理了。

服务注册和发现

服务调用关系管理

负载均衡

扩展性

服务监控和跟踪


               

           
发布于 2020-11-01                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续
           

借图回答,如侵,即删。

               


               

               


               

               


               

               


               

           
发布于 04-08                
继续浏览内容
                       
知乎
发现更大的世界
打开
                       
Chrome
继续

看了大佬们的回答。我觉得SOA是以功能分的服务,注重共享与复用。顺便加一句:微服务是以业务划分的服务,做到真正的独立自治。

           

来自 https://www.zhihu.com/question/42061683?sort=created


普通分类: