【小白课程】浅谈openKylin微服务代码结构设计—洋葱模型
在上一篇中我们提到，openKylin后端服务坚持微服务架构设计思想，为提供用户持续稳定的系统服务能力，并以软件商城为例，介绍了openKylin微服务架构设计。今天，我们将围绕openKylin微服务代码结构设计—洋葱模型进行讲解。
openKylin系统后端代码分层使用洋葱模型架构进行设计，通过这张图我们可以清晰的理解这种分层：
领域实体是核心和中心部分，洋葱架构则是建立在一个领域模型上，各层通过接口连接。其背后的思想是，在领域实体和业务规则构成架构的核心部分时，尽可能将外部依赖性保持在外。
它提供了灵活、可持续、可移植的架构。 各层之间没有紧密的耦合，并且有关注点的分离。 由于所有的代码都依赖于更深的层或者中心，所以提供了更好的可维护性 提高了整体代码的可测试性，因为单元测试可以为单独的层创建，而不会影响到其他模块 框架/技术可以很容易的改变而不影响核心领域，例如rocketMq可以被kafka替代，SQL可以被MongoDB代替。
洋葱模型架构由多个同心层构成，它们相互连接，并基于控制反转的原则，朝向代表领域的核心。该架构并不关注底层技术和框架，而是关注实际的领域模型，基于以下原则进行：
同心圆代表应用软件的不同部分，从里到外依次是应用服务(领域模型)、领域服务、应用服务和最外围的容易变化的内容。架构中最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。 每个层/圈封装或隐藏内部的实现细节，并向外层公开接口。所有的层也需要提供便于内层消费的信息。其目的是最小化层与层之间的耦合，最大化跨层垂直切面内的耦合。我们在较深的层定义抽象接口，并在最外层提供其具体实现。这样可以确保我们专注于领域模型，而不必过多地担心实现细节。 低耦合性，可以让一个模块与另一个模块交互，而不需要关注另一个模块的内部。所有的内部层都不需要关注外部层的内部实现。 整个系统按系统需求功能分为若干层，每层各司其职，并解决不同的关注点。
目前，洋葱模型架构在业界已经得到普遍的认可。这是一种让软件易于演进的强有力架构，通过把应用划分为几层，可以使系统更加易于测试、维护和移植，有助于在旧框架过时时轻松采用新框架/技术。基于如上模型，我们每个服务的代码结构共分为app、app-interface、controller、internal、internal-api和start等六大层。其中各个层的介绍如下：
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后端微服务架构也能从容的快速进行适配迭代，为用户提供持续稳定的系统服务能力。