转载

SOA和微服务架构沟通（2.8）

今天在广州交流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. 数据库+逻辑层+服务层

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

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

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

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

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

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

原文 http://blog.sina.com.cn/s/blog_493a84550102wprs.html

正文到此结束