NEWS

新闻

了解openKylin最新资讯,关注社区和产品动态。

NEWS

Learn about the latest news.

【小白课程】浅谈openKylin微服务代码结构设计—洋葱模型

2024-01-16 17:13:56

在上一篇中我们提到,openKylin后端服务坚持微服务架构设计思想,为提供用户持续稳定的系统服务能力,并以软件商城为例,介绍了openKylin微服务架构设计。今天,我们将围绕openKylin微服务代码结构设计—洋葱模型进行讲解。

openKylin后端微服务基于洋葱模型架构进行设计,通过多层次的整合技术和方法,满足对业务数据交互性和可监督性,以及灵活适应业务变化能力的要求,提供持续稳定的后端服务。其中,在领域驱动的指导思想下,对各个业务服务进行拆分,每个服务解决系统中划分的一个问题空间,以此构建出高可用、可拓展、易维护的后端服务。

代码分层结构

openKylin系统后端代码分层使用洋葱模型架构进行设计,通过这张图我们可以清晰的理解这种分层:

openKylin(开放麒麟)

领域实体是核心和中心部分,洋葱架构则是建立在一个领域模型上,各层通过接口连接。其背后的思想是,在领域实体和业务规则构成架构的核心部分时,尽可能将外部依赖性保持在外。

为什么使用洋葱模型架构?



  • 它提供了灵活、可持续、可移植的架构。

  • 各层之间没有紧密的耦合,并且有关注点的分离。

  • 由于所有的代码都依赖于更深的层或者中心,所以提供了更好的可维护性

  • 提高了整体代码的可测试性,因为单元测试可以为单独的层创建,而不会影响到其他模块

  • 框架/技术可以很容易的改变而不影响核心领域,例如rocketMq可以被kafka替代,SQL可以被MongoDB代替。

洋葱模型架构由多个同心层构成,它们相互连接,并基于控制反转的原则,朝向代表领域的核心。该架构并不关注底层技术和框架,而是关注实际的领域模型,基于以下原则进行:

01
依赖性

同心圆代表应用软件的不同部分,从里到外依次是应用服务(领域模型)、领域服务、应用服务和最外围的容易变化的内容。架构中最主要的原则是依赖原则,它定义了各层的依赖关系,越往里依赖越低,代码级别越高,越是核心能力。外圆代码依赖只能指向内圆,内圆不需要知道外圆的任何情况。

02
数据封装

每个层/圈封装或隐藏内部的实现细节,并向外层公开接口。所有的层也需要提供便于内层消费的信息。其目的是最小化层与层之间的耦合,最大化跨层垂直切面内的耦合。我们在较深的层定义抽象接口,并在最外层提供其具体实现。这样可以确保我们专注于领域模型,而不必过多地担心实现细节。

03
耦合性

低耦合性,可以让一个模块与另一个模块交互,而不需要关注另一个模块的内部。所有的内部层都不需要关注外部层的内部实现。

04
关注点分离

整个系统按系统需求功能分为若干层,每层各司其职,并解决不同的关注点。


目前,洋葱模型架构在业界已经得到普遍的认可。这是一种让软件易于演进的强有力架构,通过把应用划分为几层,可以使系统更加易于测试、维护和移植,有助于在旧框架过时时轻松采用新框架/技术。基于如上模型,我们每个服务的代码结构共分为app、app-interface、controller、internal、internal-api和start等六大层。其中各个层的介绍如下:

01
app-interface:此层主要为核心业务的接口层,供上层的controller及其他的internal调用使用
02
app:此层为核心业务逻辑的实现,做业务功能,负责数据的处理入库出库等。服务的真正实现,不被外部引用。
03
controller:此层为外部接口,负责对接前端的请求。各位同学可以开始有意识地按照上学时间有规律地作息,提前适应开学时间。
04
internal-api:此层为对内部服务提供的通信接口,整个服务严格区分对外和对内接口。
05

internal:此层为对内部接口的实现,处理内部服务调用的逻辑。

微服务使用
  • openKylin后端系统使用spring cloud框架搭建微服务系统,采用nacos作为注册中心、openFeign作为服务调用RPC框架、ribbon实现负载均衡。

  • 每个服务的start层,会引用公共的starter的maven引用,此starter的maven引入了spring cloud的组件。以此更好的管理好依赖及其版本升级。

  • 采用spring kafka框架来进行服务间解耦,针对消费失败进行扩展,提供重试机制,保障数据的稳定安全。同时,考虑系统并发资源竞争的情况,系统基于redisson封装了分布式锁的功能。

  • 采用mapstruct插件实现各个模块中对象之间的转换,避免使用传统的BeanUtils.copyProperties方式因使用反射带来性能的损耗。


openKylin后端微服务系统,通过上述技术选项方案,保障系统核心稳定,其他任何层的变化不会对app层造成影响,同时敏捷性方面也得到保障,即便多人同时开发和维护,也不易产生冲突。


总结

openKylin基于微服务架构思想,围绕不同业务模块的特性,从开发语言、数据缓存、数据持久化以及服务治理等,为其“量身打造”最适合该服务的技术选型。在当下快节奏的技术更新迭代环境下,openKylin后端微服务架构也能从容的快速进行适配迭代,为用户提供持续稳定的系统服务能力。