• -------------------------------------------------------------
  • ====================================

谈一下我对如何设计微服务子模块的理解和思考

springcloud dewbay 5年前 (2019-04-12) 2100次浏览 已收录 0个评论 扫描二维码

前面写过两篇文章《谈一下我对如何做需求分析的理解和思考》、《谈一下我对如何设计微服务接口的理解和思考》从需求和外部接口的角度讲了开发一下微服务需要考虑的方方面面;本篇进入微服务内部,谈一下如何设计微服务内部的子模块。

如何设计一个子系统(微服务)的内部模块?模块的划分和设计都有一些套路可寻,在微服务架构体系中,使用不同的开发语言 子模块有不同的载体。使用 Java 开发,子模块可以是不同的 Jar 包或者同一个项目下的不同 package;使用 C++开发,不同的子模块是各个 dll。一般来说,不同子模块的源代码是隔离的,它们或者处于不同 IDE 项目下,或者存放在不同的文件夹目录下。

一个微服务下的子模块如何划分通常是由业务决定的。微服务的功能比较复杂划分的模块就比较多,功能简单划分就少。模块分层划分是基本思想。一般来说,一个服微务的模块会划分为消息接口层,业务控制层、算法逻辑层、数据模型层、数据适配层、公共处理层这六层。下面描述一下这六层模块设计的规则和需要注意事项。

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

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

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

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

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

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

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

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

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

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

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

公共处理层

公共处理层提供的是与业务无关的公共方法,如日期时间的处理,字符串处理等。公共处理层中还可以定义微服务使用的常量(数字常量、字符串常量)和枚举值。

作者:Elon.Yang
来源:CSDN
原文:https://blog.csdn.net/ylforever/article/details/79983299
版权声明:本文为博主原创文章,转载请附上博文链接!


露水湾 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:谈一下我对如何设计微服务子模块的理解和思考
喜欢 (0)
[]
分享 (0)
关于作者:
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址