服务的三种类型

技术平台在构成过程中可以采用大量成熟的技术理念和工具，基本思路就是实现服务化。一般认为服务有以下三种主要的表现类型：

1. 工具服务

工具服务（Utility Service）代表可重用服务，区别业务模型。作为应用程序与技术基础设施之间的交叉点，工具服务的特点是业务领域无关，本质是面向技术、具备高可重用性的低层处理服务，因此能够遵循独立开发和管理生命周期。

工具服务的识别遵循下图中的模式，以Java语言为例，工具服务的识别包括Java标准的API的封装、公共功能区域的提炼、非功能性需求的抽取以及常见开源框架的应用等四个维度，下图展示了提取工具服务的这四个常见维度。因为其业务无关性，相对于其他两种服务，工具服务相对比较容易提炼。

Java领域中存在很大开放、强大而常用的API，如与安全性相关的JCE（Java Cryptography Extension）提供用于加密、密钥生成和协商以及消息认证码（Message Authentication Code，MAC）算法的框架和实现，JMS（Java Messaing Service）提供面向消息中间件（Message Oriented Middleware，MOM）的API规范，JAX-RS（Java API for RESTful Web Services）则支持按照REST风格创建Web服务。这些API可以分别对应到公共功能区域中的安全性、消息传递系统、HTTP数据传输等各个领域，构成工具服务中的一大类型。同时，围绕系统的性能、可扩展性、可用性等因素，工具服务也包含了基于目前主流开源框架的封装需求，如使用Zookeeper实现分布式协调和分布式锁机制，使用Dubbo实现通用的RPC功能和服务治理，使用Redis等Nosql技术实现海量数据存储等，这些工具的应用都可以独立于业务并形成统一化、开放式服务。

工具服务也有一些固定的表现形式，包括公共工具服务，面向多种应用程序，如安全性、记录和审核，该类工具服务通常设计成基于Web的服务，并开放通用、松散类型接口；资源工具服务，封装物理系统资源，如数据存储/消息资源，这类服务处于底层，使用服务门面暴露入口；微工具服务，细粒度、高度特性化，如XML加密服务，这类服务通常本地调用，需要考虑性能、无状态性和线程安全，可以作为JAR包进行直接引用；包装器工具服务，面向遗留系统，建立标准化服务契约，显然这类服务需要明确所支持的数据和消息模型。

2. 实体服务

实体服务（Entity Service）建立一种一致的方法访问和处理业务数据，对应基于业务的功能上下文，侧重于以业务为中心和以数据为中心。实体服务同样可重用，一般被更高级的任务服务使用。实体服务的层次如下图所示，在业务流程中包括各种遗留系统、数据库和外部系统在内所组成的数据孤岛之间形成一种实体服务，其本质是提供一种规范化的数据模型。

         实体服务中包括领域实体（Domain Entity）和消息实体（Message Entity）两种实体，领域实体是指服务库中规范化的数据模型，而消息实体特定于实体服务契约的数据模型，这两种实体体现在实体服务中就是该服务的上下两端。以常见的客户（Customer）这个概念而言，领域实体中可以包括账户（Account）、订单（Order）和地址（Address）等信息，但当实体服务暴露对外的接口时可能并不一定需要所有的领域数据，消息实体消息实体作为领域实体的包装器和简单版本，就能作为一种灵活的、与领域实体相互独立的数据传输和转换机制，领域实体和消息实体示例见下图。

3. 任务服务

任务服务（Task Service）关注实现业务相关逻辑，很大程度上由组合逻辑组成，通常需要维护状态。任务服务在靠近组合服务的位置承载，体现为一种组合结构（见下图）。在任务服务中，确保使用实体服务限制返回数据量，服务调用携带消费者信息和上下文，并由任务服务决定事务边界。

以上三种服务化思想都可以用于构建技术平台，工具服务因为不涉及业务，识别和提取相较另外两种服务而言比较简单。实体服务关注于数据，任务服务关注于业务组合，都需要根据业务本身做抽象。

 

如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型，或扫描下面的二维码。

我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流。