【小白课程】浅谈openKylin微服务代码结构设计—洋葱模型
在上一篇中我们提到，openKylin后端服务坚持微服务架构设计思想，为提供用户持续稳定的系统服务能力，并以软件商城为例，介绍了openKylin微服务架构设计。今天，我们将围绕openKylin微服务代码结构设计—洋葱模型进行讲解。
openKylin系统后端代码分层使用洋葱模型架构进行设计，通过这张图我们可以清晰的理解这种分层：
领域实体是核心和中心部分，洋葱架构则是建立在一个领域模型上，各层通过接口连接。其背后的思想是，在领域实体和业务规则构成架构的核心部分时，尽可能将外部依赖性保持在外。
- 它提供了灵活、可持续、可移植的架构。
- 各层之间没有紧密的耦合，并且有关注点的分离。
- 由于所有的代码都依赖于更深的层或者中心，所以提供了更好的可维护性
- 提高了整体代码的可测试性，因为单元测试可以为单独的层创建，而不会影响到其他模块
- 框架/技术可以很容易的改变而不影响核心领域，例如rocketMq可以被kafka替代，SQL可以被MongoDB代替。
洋葱模型架构由多个同心层构成，它们相互连接，并基于控制反转的原则，朝向代表领域的核心。该架构并不关注底层技术和框架，而是关注实际的领域模型，基于以下原则进行：
目前，洋葱模型架构在业界已经得到普遍的认可。这是一种让软件易于演进的强有力架构，通过把应用划分为几层，可以使系统更加易于测试、维护和移植，有助于在旧框架过时时轻松采用新框架/技术。基于如上模型，我们每个服务的代码结构共分为app、app-interface、controller、internal、internal-api和start等六大层。其中各个层的介绍如下：
- openKylin后端系统使用spring cloud框架搭建微服务系统，采用nacos作为注册中心、openFeign作为服务调用RPC框架、ribbon实现负载均衡。
- 每个服务的start层，会引用公共的starter的maven引用，此starter的maven引入了spring cloud的组件。以此更好的管理好依赖及其版本升级。
- 采用spring kafka框架来进行服务间解耦，针对消费失败进行扩展，提供重试机制，保障数据的稳定安全。同时，考虑系统并发资源竞争的情况，系统基于redisson封装了分布式锁的功能。
- 采用mapstruct插件实现各个模块中对象之间的转换，避免使用传统的BeanUtils.copyProperties方式因使用反射带来性能的损耗。
openKylin后端微服务系统，通过上述技术选项方案，保障系统核心稳定，其他任何层的变化不会对app层造成影响，同时敏捷性方面也得到保障，即便多人同时开发和维护，也不易产生冲突。
openKylin基于微服务架构思想，围绕不同业务模块的特性，从开发语言、数据缓存、数据持久化以及服务治理等，为其“量身打造”最适合该服务的技术选型。在当下快节奏的技术更新迭代环境下，openKylin后端微服务架构也能从容的快速进行适配迭代，为用户提供持续稳定的系统服务能力。
| 投稿作者 | 作者网站 |
|---|---|
评论
为您推荐
请支持IMCN发展！
| 微信捐赠 | 支付宝捐赠 |
|---|---|
 |
 |
还没有任何评论，你来说两句吧