【架构与设计】常见微服务分层架构的区别和落地实践

这篇具有很好参考价值的文章主要介绍了【架构与设计】常见微服务分层架构的区别和落地实践。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

作者:京东科技 康志兴

前言

从强调内外隔离的六边形架构,逐渐发展衍生出的层层递进、注重领域模型的洋葱架构,再到和DDD完美契合的整洁架构。架构风格的不断演进,其实就是为了适应软件需求越来越复杂的特点。

可以看到,越现代的架构风格越倾向于清晰的职责定位,且让领域模型成为架构的核心。

基于这些架构风格,在软件架构设计过程中又有非常多的架构分层模型。

传统三层架构

传统服务通常使用三层架构:

• 门面层:作为服务暴露的入口,处理所有的外部请求。部分情况下,门面层甚至不需要单独定义对象而是直接使用服务层的实体定义。

• 服务层:作为核心业务层,包含所有业务逻辑。并对基础层能力进行简单组合提供一定的能力复用。通常服务层会进行实体定义来防止下层对象体直接暴露给外部服务,导致底层任何变化都有可能直接传递到外部,非常不稳定。

• 基础层:用来存放dao和外部rpc服务的封装,二者可以拆分为不同的module,也可合二为一,以不同package进行隔离。

三层架构特点就是简单,适用于一些无复杂业务场景的小型应用,或者“数据不可变”作为基础原则的DOP(面向数据编程)服务。

但是当业务场景稍微复杂一些、调用层级较多时,可复用性、可维护性就都非常差了,很多代码都耦合在一起,牵一发动全身。

DDD架构

DDD架构可以看做是整洁架构的一种实现,分层职责如下:

• 适配层:用来做外部不同端请求的适配器,隔离不同端的协议差异,包装不同端不同样式的响应体。

• 应用层:用例、任务入口、消息队列监听均在这一层,可以理解为业务流程的入口,通过聚合根的构造执行相应的命令操作。

• 领域服务层:包含核心的领域服务定义,并定义了gateway来做一层依赖倒置,使基础设施层仅做实现。

• 基础设施层包含一切基础能力:数据库、ES、远程调用封装等等。

优点

• 核心稳定:领域模型在依赖链上是顶层角色,不依赖任何其他模块,所以极其稳定。其他任何业务域、存储、边缘能力的变化都不会对领域模型造成影响。

• 敏捷:适合不同团队一起开发和维护而不会产生冲突。

• 可拆分:当有届上下文随着演进逐渐膨胀时,很容易拆分成微服务。

• 可扩展:添加新的功能非常简单,从而使得开发人员能够更快的部署和调整。

• 可演进:良好的可测试性带来非常低的重构成本,不会随着不断迭代导致项目成为难以修改的“大泥球”。

如此多的优点自然带来明确的缺点

• 专业性要求较高:需要对业务、架构原则理解深刻的人员进行设计和维护,不恰当的领域模型将使后续迭代极为痛苦。

• 开发成本高:复杂的架构设计,更多的架构分层,自然带来代码行数的指数级增长。尤其是项目前期的开发任务变得异常繁重。

• 不再适合简单的业务场景:实现一个简单的CRUD显得过于复杂。

• 改变决策困难:尝试使用整洁架构需要和团队的管理层和其他成员达成一致,这往往需要非常强大的说服力。如果在架构演进过程中想切换回其他架构模式也十分困难,几乎是整个项目级别的重构工作。

简单的微服务分层架构

基于六边形架构规范的接口适配原则和防腐理念,同时借鉴了CQRS模式的优点,我们定义了一个简单的微服务分层架构。

分层定义如下:

• 门面层:作为程序的入口,通过包隔离来存放JSF服务、Rest服务、定时任务和MQ消费,其中对外提供服务的接口定义存放在单独的api包中。该层的请求定义命名以Request结尾,响应体命名以Response结尾。

• 领域服务层:每一个领域服务存放在单独的module中,并通过单独的api包对外暴露能力。该层的命令请求定义命名以Command结尾,查询请求定义命名以Query结尾,响应体命名以Dto结尾。

• 基础设施层:存放数据库、ES、远程调用服务的封装。该层的持久化数据定义命名以Po结尾。远程命令服务入参命名以RpcCommand结尾,远程查询服务入参命名以RpcQuery结尾,响应体命名以RpcDto结尾。

最佳实践

  1. 命令服务必须访问领域服务层,允许简单查询直接调用基础设施层。

  2. 参数校验、请求出入参日志、审计日志记录、TraceID预埋、异常处理等非核心业务能力均由公共组件完成,减少项目内部的边缘能力代码。

  3. 由于在门面层进行统一的异常处理,非必要时无需在项目中进行大面积的try-catch,让代码更清爽。

  4. 实际开发过程中,门面层、领域服务层和基础设施层均有各自的实体定义,跨层调用的对象体转换使用MapStruct组件来减少手写映射代码的工作量。

  5. 数据层使用Fluent-Mybatis,最大好处是减少后期迭代中,数据对象增减字段时修改Mapper的成本。

优点

1. 开发效率

简单的业务开发过程中,相比较书写核心业务逻辑,更多的工作量几乎都是来自处理跨层调用时对象转换和Mapper定义,通过MapStruct和Fluent-Mybatis等组件的使用(也许再加上GitHub Copilot😁),编写一个实体的增删改查接口基本在5分钟内搞定,省下来的时间可以多走读两遍代码或者多写几个分支的测试用例,也算是降本增效了。

2. 服务隔离

通过module隔离不同的领域服务,降低不同领域服务之间的耦合程度。

3. 外部服务防腐

远程调用统一封装在基础设施层中,降低外部变化对系统内部的影响。

缺点

  1. 基础设施层的实体作为顶层依赖

由于对基础设施层的依赖没有通过api包进行隔离,所以基础设施层的对象会直接暴露在领域服务层和门面层。对此可以通过使用ArchUnit组件进行架构防腐。

如果需要定义完善的领域实体充血模型,建议参考DDD架构定义gateway层来进行基础设施层的依赖倒置。

最后

软件工程的方方面面都遵循一个最基本的道理:没有银弹,架构分层模型更是如此,每一种都有各自优缺点,所以请根据不同的业务场景,并遵循简单、可演进这两个重要的架构原则选择合适的架构分层模型即可。

架构不只是工作,更是一门艺术。文章来源地址https://www.toymoban.com/news/detail-417517.html

到了这里,关于【架构与设计】常见微服务分层架构的区别和落地实践的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 微服务架构设计与实践

    随着互联网的发展,软件开发已经成为各种企业发展的重要手段。然而,单体应用在长时间的维护中会变得复杂、难以扩展、难以修改。因此,为了满足业务需求,微服务架构应运而生。本篇文章将深入探讨微服务架构的设计与实践。   一、微服务架构的概述 1.1 微服务架构

    2023年04月22日
    浏览(48)
  • 系统架构设计师教程(十五)面向服务架构设计理论与实践

    面向服务的体系结构 (Service-Oriented Architecture, SOA) 是一种应用框架,它将业务应用划分为独立的业务功能和流程(服务),并通过定义良好的接口和契约将这些服务联系起来。SOA 提供了业务流程的灵活性,使企业能够更快速地发展、降低总体拥有成本,并改善对准确信息的访

    2024年01月25日
    浏览(59)
  • ChatGPT技术产品落地实践:从技术架构到实际应用

    简介 在本次分享中,想跟大家探讨ChatGPT技术产品的落地实践,从技术架构的角度出发,剖析GPT模型的核心原理、关键技术以及实际应用场景。将从以下几个方面展开讨论: 1. ChatGPT模型概述:首先,简要介绍ChatGPT(Chatbot based on Generative Pre-trained Transformer)模型的基本概念、

    2024年02月15日
    浏览(52)
  • 【新版系统架构】第十五章-面向服务架构设计理论与实践

    软考-系统架构设计师知识点提炼-系统架构设计师教程(第2版) 第一章-绪论 第二章-计算机系统基础知识(一) 第二章-计算机系统基础知识(二) 第三章-信息系统基础知识 第四章-信息安全技术基础知识 第五章-软件工程基础知识(一) 第五章-软件工程基础知识(需求工

    2024年02月16日
    浏览(46)
  • Java架构师设计模式分层架构

    想学习架构师构建流程请跳转:Java架构师系统架构设计 设计模式的分层架构是一种常见的软件设计模式,它将应用程序划分为不同的层次,以便更好地组织和管理代码。每个层次

    2024年02月01日
    浏览(35)
  • 前端不同架构的分层设计

    (1). 系统架构: (2). 应用级架构: (3). 模块级架构: (4). 代码级架构:

    2024年02月03日
    浏览(45)
  • 构建稳健的微服务架构:关键的微服务设计原则和最佳实践

            在现代软件开发中,微服务架构正逐渐成为构建复杂应用程序的首选方法之一。微服务架构的核心理念是将应用程序划分为一系列小型、自治的服务,每个服务专注于一个特定的业务功能。然而,要实现一个稳健的微服务架构并不仅仅是将功能拆分成微服务,还需

    2024年02月14日
    浏览(54)
  • 领域驱动设计DDD实际项目落地最佳实践

    领域驱动设计(Domain Driven Design,简称:DDD)设计思想和方法论早在2005年时候就被提出来,但是一直没有被重视和推荐使用,直到2015年之后微服务流行之后,再次被人重视和推荐使用。 下面我来介绍一下DDD设计思想和方法论,同时结合我们在实际项目中应用总结和思考。 目录

    2024年02月08日
    浏览(65)
  • [架构之路-245/创业之路-76]:目标系统 - 纵向分层 - 企业信息化的呈现形态:常见企业信息化软件系统 - 企业资源管理计划ERP

    目录 前言: 一、企业信息化的结果:常见企业信息化软件 1.1 企业资源管理计划 1.1.1 什么是ERP:企业最常用的信息管理系统 1.1.2 ERP的演进过程 1.1.3 EPR模块 1.1.4 EPR五个层级 1.1.5 企业EPR业务总体流程图 1.1.6 什么类型的企业需要ERP 1.1.7 创业公司什么情况需要ERP 1.1.8 ERP与人工管

    2024年02月07日
    浏览(56)
  • [架构之路-251/创业之路-82]:目标系统 - 纵向分层 - 企业信息化的呈现形态:常见企业信息化软件系统 - 商业智能、决策支持系统、知识管理

    目录 前言: 一、企业信息化的结果:常见企业信息化软件 1.1 商业智能 - 管理层 1.1.1 什么是商业智能What 1.1.1.1 商业智能常见工具 1.1.2 为什么需要商业智能Why? 1.1.3 谁需要商业智能who? 1.1.4 商业智能在企业管理中的位置where 1.1.5 什么情况下需要使用商业智能When 1.1.6 如何实

    2024年02月06日
    浏览(50)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包