SOA架构

SOA 架构

        为了更好地理解SOA,我们来看两个场景:
        假设一个用户执行下单操作,系统的处理逻辑是先去库存查商品的库存,
        只有在商品库存足够的情况下才能够提交订单,那么这个检查库存的逻辑,
        是放在订单子系统还是库存子系统中呢?在整个系统中一定会存在非常
        多的类似的共享业务的场景,这些业务逻辑的场景一定会被重复的创建,
        从而产生非常多冗余的业务代码,这些冗余的业务代码的维护成本会随着
        时间越来越高,能不能把这些共享业务逻辑抽离出来,形成可重用的服务
        呢?
        在一个集团公司下有很多的子公司,每个子公司都有自己的业务模式和信息
        沉淀,各个子公司之间不进行交互和共享。这个时候各个子公司虽然能够
        创建一定的价值,但是由于各个子公司之间信息不是互联互通的,彼此
        之间形成了信息孤岛,使得价值无法最大化

基于这些问题就引入了SOA(Service-Oriented-Architecture),也就是面向服务的框架

	  从语义上来说,它和面向过程、面向对象、面向组件的思想都是一样的,
	  都是一种软件组件及开发的方式。核心目标是把一些通用的、会被多个
	  上层服务调用的共享业务提取成独立的基础服务,这些被提取出来的
	  共享服务相对来说比较独立,并且可以重用,所以在SOA中,服务是最核心
	  的抽象手段,业务被划分为一些粗粒度的业务服务和业务流程。

如图所示:提取出了,用户服务,库存服务,商品服务等多个共享服务。在SOA中会采用ESB(企业服务总线)来作为系统和服务之间的通信桥梁。ESB本身还提供服务地址的管理、不同系统之间的协议转化和数据格式转化,调用端不需要关心目标服务的位置,从而使得服务之间是动态的,这样做的好处是实现了服务的调用者和服务的提供者之间的高度解耦。总的来说:SOA主要解决的问题是:

  • 信息孤岛
  • 共享业务的重用

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值