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

标签: IT咨询 | 发表时间:2017-02-08 13:04 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
今天在广州交流SOA和微服务架构,特对关键内容做简单记录。

对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用。这些小应用之间通过服务完成交互和集成。

每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务。

如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。对于微服务架构本身强调的两个能力又是首先微服务模块完全独立自治,其次微服务模块间通过轻量 Http API接口进行交互和协同。

对于微服务模块,更多还是应该是包含了前端UI的,即微服务模块本身就是一个完全独立的小系统。如果不考虑多终端支持的话,微服务模块只暴露需要跨模块访问的的API接口服务能力即可。而对于互联网很多应用由于需要多终端支持,可以看到微服务模块本身UI层和服务能力层是彻底解耦开的,对于一个微服务模块的所有服务能力都需要朝外暴露。而要把这些服务都管理起来整个服务治理和管控难度会成倍增加。

即举例来说对于用户管理模块,如果用户新增加只有在该微服务模块完成,那么用户新增加是不需要暴露为独立的API接口服务能力的。因为微服务模块内部可以通过传统的JAVA API接口进行调用。当然你也可以将Java API发布为RPC接口调用以提升性能。即在微服务架构里面,我们需要更多关注跨微服务模块间调用的接口服务,而不是微服务模块内部的横向接口服务能力。

在整个微服务架构中,有可能会出现独立的实现领域服务逻辑的微服务模块,这类微服务模块实现服务组合和编排逻辑。领域服务本身又分为两类, 一类是数据类领域服务,一类是业务规则和逻辑类领域服务,但是这类领域服务的特点就是都需要调用多个底层微服务模块提供的原子服务能力进行组合后才能实现。

对于跨多个微服务模块实现的业务流程,对于传统SOA架构里面可以看到可以在BPM里面来实现,包括流程编排,数据建模和界面设计等,最后再讲完成的UI做为Portal挂接到门户层。在微服务架构里面这类事情仍然可以独立一个微服务模块来做,这个微服务模块就是做流程编排和组合的事情,只是通过代码来实现而已。在这种模模式下可以看到这类微服务模块可能只有服务组装层和UI界面层,而没有实际的对应数据库。

经过上面的分析,可以看到一个微服务本身可以有不同呈现形式,如下:

1. 数据库+逻辑层+服务层+UI展现层
2. 数据库+逻辑层+服务层
3. 逻辑层+服务层+UI展现层


以上几种展现形式都是可以的。要注意到对于互联网很多微服务架构和应用,考虑到多终端能力支持,因此既会进行纵向的模块拆分,本身又会进行横向的彻底服务分层和解耦。

我们经常谈的服务是有业务含义的,包括了业务服务和数据服务,但是即使是数据服务也不是指的简单的将数据库表暴露为CRUD服务,而是将数据对象或叫业务对象暴露为服务。而一个业务对象本身可能涉及到后台多张数据库表,业务对象才是管理的最小单位。

A和B模块相互间有交叉依赖的时候,最好的方式是将共同内容抽出到模块C,变化为A和B都依赖模块C。

接口规范和契约的定义和最终接口的发布和实现方式是可以分开的,包括当前很多微服务框架都能够将定义的API接口发布为不同类型的服务,既可以发布为Http Rest接口,也可以发布为走TCP协议的RPC接口等。

对于一个复杂应用转换为微服务架构的时候,可以看到其中一个难点在于多个微服务模块上层的领域服务层或叫服务组装或编排层的设计。如果这层设计和实现的不好,所有工作都会转到应用展现层去做,即本来期望展现层足够轻,但是最后结果是展现层仍然承担了大量的服务组装和编排逻辑。

对于同一个微服务模块内部的组合服务,要注意一个关键原则是如果该组合服务设计到事务一致性要求,最好的方法不是调用两个原子服务,而是直接调用数据库,方便启用数据库层的事务控制。

 

相关 [soa 服务 架构] 推荐:

SOA面向服务架构

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

面向服务的架构SOA

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

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

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

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

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

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服务共享

- - 人月神话的BLOG
数据本身只是一种资源,而服务是一种能力;数据仅限于各种结构化和非结构化的数据资源,对于数据资源提供的能力可以使一种数据服务,而数据资源+业务规则形成的某种业务能力也可以作为一种服务提供,也就是说各种技术,数据,业务,平台,流程能力都可以做为服务提供. 交换本质是资源会从一个系统通过传输的方式进入到多个系统,资源在多个系统中形成多种拷贝.

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

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

对SOA架构思想的一些说明

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