微服务架构中模块划分和服务识别

架构设计 专栏收录该内容
29 篇文章 0 订阅

微服务架构中模块划分和服务识别

最近在进行微服务架构的交流和讨论中,除了谈到微服务技术架构外,客户往往更加挂你微服务模块的划分粒度,已经具体的微服务API接口的识别和定义问题,因此这篇文章将重点谈下微服务架构实践过程中的微服务模块划分和服务识别。



最近在进行微服务架构的交流和讨论中,除了谈到微服务技术架构外,客户往往更加挂你微服务模块的划分粒度,已经具体的微服务API接口的识别和定义问题,因此这篇文章将重点谈下微服务架构实践过程中的微服务模块划分和服务识别。

首先我们还是再总结在在跨系统间的接口集成中服务的识别和定义方法,可以总结为:

1. 基于流程架构和业务架构,从跨系统交互流程出发,分析业务交互接口点,识别关键的业务服务能力。

2. 基于数据架构和主数据建模分析,识别关键的数据服务能力。

3. 基于技术架构和共性平台层技术组件的分析和定义,以能力开放原则识别关键技术服务能力。

因此对于跨系统间的集成,对于服务识别和定义思路是相对清晰的。那么在传统方法中业务系统的划分和定义粒度又是如何?在前面企业架构分析中,我曾经谈到过,通过跨系统交互流程分析,识别出最细粒度的业务功能模块和功能单元,然后再从底向上进行聚合,以CRUD分析为主要方法,多次迭代出最佳的满足高内聚,松耦合条件的业务系统划分。这里面没有一个精确方法,但是却有该大原则下的指导方法。

微服务模块的划分

微服务模块的划分不是什么新鲜事物,就是传统的业务系统内部的业务功能组件的划分,但是我要注意到的关键一点还是业务组件本身的粒度和大小。原来没有完全拆分为独立的微服务模块的时候,我们一个业务系统可以划分20个以上的业务模块,因为由于数据库本身没有拆分,同时业务模块间的调用本身又是内部的API调用,因此感觉不到有什么问题。但是如果把这20个业务模块完全拆分为独立的微服务模块,你才会发现模块间的紧耦合或者说大量的交互集成接口,会导致整个系统集成和交互关系相对复杂,后期很难管理。

这也是我们原来经常强调的,传统的一个大业务系统划分微服务模块的时候,尽量是划分到6到8个模块比较合适,当你本身的IT成熟度达到一定水平后你可以划分的更加细点。同时在微服务模块划分的时候一定要考虑数据库本身的划分,即底层的数据库也是划分开的,类似我原来谈私有云PaaS的时候谈的数据库的水平拆分。

究竟如何拆?实际上方法仍然是一样的,还是要分析单个业务系统内部的流程,然后分解到具体的业务组件或功能,再按照高内聚的原则进行聚合,尽量确保各个微服务模块之间的交互最少。同时对于大家都要用到的基础数据模块,仍然采用共性下沉的策略和思路进行。同时一个有价值的参考方法是,分析该业务系统承载的主体业务流程是什么?然后分析这个业务流程可以横向划分微哪几个独立的阶段,然后先将这些独立的阶段划分微不同的微服务模块,在划分好后再进行CRUD分析进行修正。

微服务接口的识别和定义

不管是传统的跨业务系统间交互的接口,还是微服务模块间的交互API接口,我一直强调的一个关键就是接口一定要保证粗粒度特性,实现业务规则和逻辑的高度内聚。接口面对的应该是核心的业务对象,领域对象或业务规则能力暴露,而不是微服务模块内部的数据库表的CRUD操作的暴露。如果将数据库表CRUD操作暴露为Rest API接口并在微服务模块间相互调用。一个是耦合性增加,一个是完全没有实现高内聚的基本要求。

基于以上基础原则,我们在进行微服务接口识别和定义的时候,仍然需要从业务流程出发,梳理清楚完成一个完整的业务流程各个微服务模块之间有哪些业务交互接口,然后将这些接口识别出来后,才进行接口的拆分或合并,最终形成微服务API接口,只有这样最终的微服务API接口才是可以复用的。

由于我们已经将基础数据管理独立到一个基础模块,因此可以基于数据能力开放和暴露的原则将这些基础数据的能力以查询服务方式暴露为独立的数据服务能力接口。要求仍然是领域对象级而不是数据库表级别。

每一个微服务模块在开发和实现的时候,如果都是基于领域驱动架构设计的思路进行的,那么只有微服务模块的领域对象定义完整,完全可以将领域对象的能力以API接口的方式暴露出去,这里既包括了查询类接口,也包括了导入或数据插入类接口,其次对于核心的业务规则的实现可以独立暴露为接口服务。

在前面微服务架构咨询里面我曾经谈到过,在多个微服务模块之上,还可能有一个微服务能力组合层,实现类似流程服务和组合服务类的能力。如果存在这种情况,那么最好也是独立的微服务模块来实现,这个微服务模块本身可能并不对应具体的数据库,而是将底层的微服务模块之间服务能力进行组合,形成新的接口服务能力。

由于在微服务架构设计中,我们更加强调数据不落地的方式进行后续的开发和实现,由于数据不落地,我们就可以更好的以能力开放的思路来进行接口的识别和暴露。简单来说有哪些数据或业务对象在你这,有哪些业务规则属于你管理?这些都在经过粗粒度聚合后,都可以识别和定位为微服务API接口。

  • 0
    点赞
  • 0
    评论
  • 1
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

查重率不足1%计算机软件工程毕业设计论文,希望大家一块学习,若有错误请及时指正 摘 要 I Abstract(英文摘要) II 第1章 引言 1 1.1 课题目的意义 1 1.1.1 目的 1 1.1.2 意义 1 1.2 资料调研分析 2 1.3 关键技术 2 1.3.1 微服务架构理论与技术对比 2 1.3.2 SpringCloud微服务系统架构 4 1.3.3 Dubbo微服务系统架构 8 1.3.4 微服务架构有效的容器Docker 9 1.3.5 微服务架构容器编排kubernetes 9 1.3.6 微服务架构的拆分原则 11 1.3.7 微服务架构CAP定理 12 1.3.8 微服务架构之分布式锁 13 1.3.9 微服务架构之分布式事务 15 1.3.10 微服务架构之单点登录 20 1.3.11 Netty百万长连接并发服务 20 1.3.12 Haar+Adaboost人脸识别技术 21 1.3.13 MVVM模式下Hybird跨平台应用前端框架 23 第2章 系统需求分析 25 2.1 系统功能总体介绍 25 2.1.1 深度学习模块 25 2.1.2 长连接模块 25 2.1.3 短连接模块 25 第3章 系统概要设计 27 3.1 系统结构 27 3.1.1 系统技术架构 27 图3-1-1-2 长连接用户匹配架构图 28 3.2 数据库的设计 28 3.2.1 数据库表的设计 28 3.2.2 数据库关系图 29 3.3 模块与类的设计 30 3.4 消息队列的设计 31 第4章 系统详细设计与实现 33 4.1 开发环境的搭建与实现 33 4.2 多模块系统结构与功能划分 33 4.2.1 微服务拆分模块依赖管理图 33 4.2.2 各个模块与包的功能详细介绍 36 4.3 系统页面实现展示 37 第5章 系统测试优化 47 5.1 ActiveMq优化与测试 47 5.2 文件上传异步优化与测试 48 总结与展望 50 参考文献 51 致 谢 52
©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值