这个图见过好多次,但是依旧还是不是太懂 如果看介绍的话还可以大体明白
看到这里,我明白了,哦,原来dubbo是可以和spring无缝集成的
那么SOA和RPC又是什么呢?
let's REPEAT it.
SOA是从架构方面,整体支持面向服务泛型的基本概念性架构模型
哦,那我明白,面向对象是怎么回事,而面向服务泛型,大概就是说去吃饭时,面对打菜的服务大妈,好几个大妈,她们可以统称为<"打菜服务生.class">这样的泛型?
SOA是一种业务-IT结合的方法,其中,应用依赖于现有的服务来实现业务过程.
我们可以看上图,服务消费者(consumer), 服务提供者(provider) 这又是什么关系呢?
是吃饭的人比如小明和打菜的食堂大妈的关系,吃饭的人是服务消费者,而食堂大妈则是服务提供者.
消费者有什么呢?大家都知道在服务提供者和服务消费者之间隔着一个放托盘的地方.
我们且称之为(小明)前台和后台(大妈)吧.
那么小明这个站在打菜吧台外围的人说,我要吃烤鱼,花甲粉,和大米饭.这就是说小明这个消费者提了一些需求给后台(大妈)
也就是说消费者层,业务过程层,传递给服务层(吧台).
大妈知道了,大妈给小明往碟子中打上这些菜饭,大妈这工作时提供了服务,即包含了操作型系统层(大勺),服务组件层(几个菜),服务层(吧台)
让我们回顾 知乎是怎么说的:
作者：光太狼 链接：https://www.zhihu.com/question/42061683/answer/251131634 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 对于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
那么让我这个选择困难症比较犯难的地方就是,到底是使用SOAP还是REST还是RPC的形式呢?这点其实各有各的选择,也有的时候得听技术领导经理的,并不能做决定.
可以看到SOA的好处也不少
SOA的好处
从IT角度触发:
松耦合,消除假依赖 -- 复用
- 语言,平台和厂商中立
- 消除时间依赖
- 消除访问地址依赖
- 消除访问协议依赖
服务间接寻址 -- 灵活
从业务角度出发:
保护企业投资,提升现有IT资源的作用,促进IT资源的复用
提高企业灵敏度
支持企业外包管理模式
SOA在不同粒度上提供了本质性的指导: 业务层,过程层,中间件层和编程层.
在每个层次中
SOA按照"自顶向下"的方式,将一个较大的单元分解为较小的,以服务为中心的单元/
SOA按照"自底向上"的方式,将可供使用的较小单元组织成为较大的单元,用以提供全新的服务.