微服务系统内部模块划分

一个服务内部的模块划分通常是有业务决定的,如果服务的功能比较复杂,服务内模块的划分就会比较多,如果功能简单,服务内模块划分就会比较少。但是总体来书,模块的划分是通过分层的思想来实现。一搬的服务模块划分大概有一下几层:消息接口层,业务控制层,算法逻辑层,数据模型层,数据适配层,公共处理层等六层。下面描述一下每一层的设计规则和注意事项。

消息接口层(facade层)

消息接口层顾名思义就是用于定义微服务对外发布的接口的。在现今比较流行的SOA架构体系里面,这层用于定义各种restful接口:包括接口的URL,参数、返回值等。这一层模块的职责是做消息转发。

消息接口中不应该有太多业务逻辑,或者说根本就不应该有业务逻辑。它通常是很薄的一层,最多记一下日志,记一下接口调用时的输入参数和返回值信息,方便接口联调时的问题定位。

按照契约化编程的思想,接口的所有权归客户所有(方法调用的Client端),我们是不能随意修改的。在有些项目甚至会对定义接口的源代码文件加锁,不允许修改。

业务控制层

这一层就是常说的controller,接收从消息接口层转发过来的消息,调用下层的算法和数据库访问接口实现业务处理逻辑。

业务控制层是一个算法组装工厂。在算法层提供了通用的算法接口,算法控制层通过调用一个或者多个算法接口完成整个业务流的处理。对于比较简单的业务(普通的CRUD操作),它也可以直接调用数据适配层接口查询或者持久化数据。

算法逻辑层(service层)

算法逻辑层实现数据组装,模型转换等所有业务相关的逻辑处理。如果业务逻辑比较简单,它可能只做一些简单的数据库增删改查接口的调用;对于比较复杂的业务它还可以独立划分出一些专用的算法子模块,如果客户征信评估算法模块、电信网络风险评估算法模块等。

可以在里面抽象出一个common模块存放与业务相关的公用算法,供多个应用层算法使用,避免相同的逻辑每个人都写一遍。

数据模型层(model层)

数据模型层定义了微服务使用的公共业务模型(接口模型也可以定义在这里面,但是需要通过不同的子模块区分)。

业务模型是非常稳定的,只要数据库表不做大的改动业务模型是不需要动的,我们可以在算法逻辑层和数据库适配层提供基于业务模型的通用方法,不同的接口和算法可以共用。

接口模型可能会经常变化,新增一个接口或者接口变更都会改接口模型,这个是正常的。算法逻辑层所做的重要工作就是将数据信息从业务模型转换到接口模型。

数据适配层(dao层)

数据适配层提供访问数据库的接口。如果是使用Spring-Mybatis开发,这个一层是就Mapper层。数据库适配层封装了底层数据库的JDBC访问接口,提供了各种针对不同业务的封装。

公共处理层(common层)

公共处理层提供的都是与业务员无关的公共组件和工具,如日期时间的处理,字符串处理等工具类。还可以定义微服务使用的常量(数字常量、字符串常量)和枚举值等组件。
————————————————
版权声明:本文为CSDN博主「Elon.Yang」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/ylforever/article/details/79983299

你可能感兴趣的:(业务开发专栏,微服务架构)