对SOA架构思想的一些说明

标签: IT咨询 | 发表时间:2014-12-10 22:43 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
从纵向到横向

传统业务系统的构建更多的是竖井式的纵向思想,这个主要是从单个业务系统孤立来看都是垂直应用。那么SOA架构的视角是从整个企业应用架构环境来看,思想的核心转变就是从传统的纵向独立构建模式转变为横向从底朝上逐层构建模式,在这个构建模式中首先是底层的资源层(独立的业务组件),然后是服务层,再上面才是应用层和门户展现层。这种横向思维模式的驱动力本身在端到端的流程支撑和分析,没有这种横向思考模式的转变很难构建出来真正企业全局意义上的SOA架构风格。

从交换到共享

为何很多企业做了多年的SOA最后仍然仅仅是一个接口平台或者数据交换平台,其核心的原因还是集成关注的是接口和数据交换,其本质思维还是点对点的思维模式。而共享则关注的是组件本身的可重用服务识别和能力开放,首先思考的是可重用的服务能力的开放而不是点对点的数据集成和交换。同时在转换到共享能力开放的时候,将从原来数据集成的时候数据多点落地,转化为新服务共享模式下的仅仅能力按需调用。业务间的协同和交互各个组件之间关注更多的是能力的消费和调用,而不是一定要底层同步和传递数据。这个思考的转变才能从大量的数据服务为主的集成模式,转化为数据服务+业务服务能力提供的服务共享模式。

从系统到组件

对于一个企业完整的应用架构来说,前面已经写过很多文章再强调整个企业就是一个大的业务系统,而不是孤立建设了多个业务系统。对于原来的业务系统本身已经转变为业务组件下层到资源层和服务层,而上层的应用本身仅仅是服务的组合,流程的编排。只有这种构建模式上层的应用才可能真正灵活的根据需求进行组合和组装,当业务流程和需求发生变化的时候仅仅是组件或服务的重新组合。

对于一个新业务需求的产生,我们要看到有可能会产生新的业务组件,也有可能仅仅是底层服务的组合就能够实现新的业务需求或流程。这个的核心区别就在于,新增加的业务需求是否存在自己为Owner的核心业务对象产生,如果有这些核心业务对象产生很可能新需求本身会规划为一个新的业务组件。但是当一个业务需求本身不产生核心业务对象的时候,那么这个需求的满足很可能通过已有业务组件的提供的能力即可。例如我们在规划电商客户服务模块的时候,这个模块可能仅仅是已有的客户关系管理,订单管理,物流管理,财务管理等各个业务组件能力的进一步组合即可完成客户服务。从这个意义上说客户自服务本身不是业务组件,而是已有业务组件的服务组合和编排,形成的一个新的应用能力单元。

从集成到集中


可以讲这个思想是SOA和云思想的一个重要集成点,即对于遗留系统的集成和重构我们考虑的更多的是集成和已有的遗留系统服务能力的抽取。但是如果是全新的构建企业内部的完整应用架构,那么就必须要考虑很多共性的技术组件和基础数据本身就不属于任何一个上层业务系统,而是属于公共平台层的内容。既然属于平台层的内容就应该集中化的模式进行构建,然后再将能力开放和暴露出去。集中化的构建是云和平台的思想,而服务最终的开放和暴露是SOA的思想,两者得到很好的融合演进。

从系统外转到系统内

如果一个企业的SOA架构仅仅应用在业务系统间,那么就很难叫做完整的SOA化。只有将SOA的架构思想应用到业务系统内部的时候,才可能形成完整的组件化和服务化构建模式。即业务系统本身也是多个松耦合的业务组件构成的,业务组件本身才是最小的可以独立管理,独立进行设计,开发,测试,部署和运维的管理单元。组件之间本身交互需要通过粗粒度的服务进行以保证组件本身的高内聚性,由于组件本身松耦合并可以灵活的组合,那么原来规划的业务系统边界逐渐就没有存在的意义。只有这样从企业全局思考角度才能够形成一个完整的SOA参考架构模式。对于遗留系统集成这点比较难,但是对于全新的IT系统规划和建设就必须一开始采用这种模式和思考方法进行,否则即使应用了SOA中间件还是烟囱式的系统架构。

从同步到异步

单独将这点拿出来谈逐渐该点的重要性。其原因就是一个SOA架构我们更希望的是各个组件和模块之间的完全松耦合,任何一个模块出现故障不至于马上影响到其它模块,从这个意义上来看如果全部是同步服务模式则很容易出现问题,提供服务的模块宕机各个消费模块马上受到影响。而基于消息中间件的异步消息和服务模式可以较好的解决这个问题,即通过消息中间件的异步和重试机制真正实现了服务消费方和提供方之间的解耦,对于业务应用来说只需要保证最终的一致性即可。包括现在谈到的EDA时间驱动架构,CEP复杂事件处理很多都是异步消息模式思想的应用。即在定义服务的时候能够用异步模式尽量用异步模式以实现真正的解耦。

在引入了异步模式后会出现一个新的问题,即需要我们异常日志的分析和记录清晰和全面,并提供后台异常信息的实时预警能力,否则将出现很多时候出现了服务消费和调用异常而没有及时发现的问题。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [soa 架构 思想] 推荐:

对SOA架构思想的一些说明

- - 人月神话的BLOG
传统业务系统的构建更多的是竖井式的纵向思想,这个主要是从单个业务系统孤立来看都是垂直应用. 那么SOA架构的视角是从整个企业应用架构环境来看,思想的核心转变就是从传统的纵向独立构建模式转变为横向从底朝上逐层构建模式,在这个构建模式中首先是底层的资源层(独立的业务组件),然后是服务层,再上面才是应用层和门户展现层.

SOA架构咨询

- - 人月神话的BLOG
对于SOA架构咨询,其核心还是在于组件化和服务化,然后才是服务管控和治理,基于服务化思想对传统软件开发生命周期过程的改进. SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构,或者更多的人仅仅是将SOA理解为service服务接口,这些都是对SOA方法论很大的误解. SOA咨询一个重点就是业务驱动IT,而非单纯的IT架构咨询,SOA咨询一般都会结合企业架构和云的思想,结合组件化架构和领域服务的思想,高层结合BPM端到端流程整合目标,并对这些内容进行有效的融合.

eBay开源SOA-Turmeric架构

- - 人月神话的BLOG
参考: https://www.ebayopensource.org/wiki/display/TURMERICDOC/Turmeric+Documentation+Overview. Turmeric是一个综合的、由策略驱动的SOA平台,提供了对SOA服务及其消费者的开发、部署、保护、运行和监控等方面的支持.

SOA面向服务架构

- - 人月神话的BLOG
今年在这点上谈的比较多,也逐步开始落地实施,将SOA咨询和实施方法论从系统间真正的引入到系统内,将面向对象的需求分析方法和SOA思想进一步融合,从业务建模到系统用例建模,从流程分析到服务识别和分析,从业务组件化到系统模块化,这些工作都逐步开始落地实施. 这样做的好处就是进一步的体现SOA可复用组件的价值,真正的做到业务组件化和组件能力化.

谈企业架构和SOA的融合

- - 人月神话的BLOG
本篇讲主要强调下在常规的企业架构规划和顶层设计中与SOA规划设计之间的融合. 再次强调下SOA的核心思想是解耦,在首先满足解耦的要求下实现共享,协同和复用. 一个完整的业务系统被拆分了应用,服务和资源层能力三个方面的内容. 资源层的能力最终以粗粒度的服务方式暴露出来,应用的构建需要大部分的借助于共享服务层抽取和接入的各种服务能力.

面向服务的架构SOA

- - CSDN博客架构设计推荐文章
SCA实现SOA的最佳方式. Apache开源框架Tuscany实现SCA架构. SOA(Service-Oriented Architecture)面向服务的体系架构. 为了能够深入理解还专门查了单词:Oriented:面向,Architecture:架构,没办法英语太烂. 实际上是一个组件模型,他将应用程序的不同功能单(称为服务)通过定义良好的接口联系起来.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

再谈SOA和云架构设计的一些要点

- - 人月神话的BLOG
对于SOA和云架构设计方面的内容,前面已经有很多文章涉及到,在这里再重点谈下SOA和云架构设计和传统EA企业架构和单业务系统架构设计之间的一些区别和联系. SOA和云架构设计更多的是在企业架构的应用架构和技术架构层面,然后才过渡到单个应用的架构设计约束,因此也可以理解为是传统软件架构设计更加上层的一个内容.

浅谈SOA面向服务化编程架构(dubbo)

- - ITeye博客
并非淘宝系的技术啦,淘宝系的分布式服务治理框架式HSF啦 ,只闻其声,不能见其物. 而dubbo是阿里开源的一个SOA服务治理解决方案,dubbo本身 集成了监控中心,注册中心,负载集群...等等. 代码和整体的框架还是很优雅滴呀. github地址 https://github.com/alibaba/dubbo.

论SOA架构的几种主要开发方式

- - CSDN博客推荐文章
 面向服务架构soa以其独特的优势越来越受到企业的重视,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用. 服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性. Soa的开发方法一般主要有开源的dubbo、dubbox、mule、wso2、cxf,以及付费的oracle soa、ibm soa等.