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

对于微服务模块，更多还是应该是包含了前端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接口等。

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

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