稀音微服务框架开发日记 - 基础架构
我的微服务框架开发的也有一段时间了,今天就来简单介绍一下框架的基础架构吧
架构图
架构概览
架构的设计主要受到了Uncle Bob的Clean Architecture的启发。
Uncle Bob的Clean Architecture 是一个流行的软件架构设计方法。它的核心思想是将系统分解为不同的层,每一层都有其明确的职责。这种分层的目的是使得系统更加模块化、可维护和可扩展。
主体思想
稀音微服务框架的核心思想即是模块化。
每个业务分割成最小的模块。在每个模块中,进一步分解为不同的层,每个层中都实现业务所定义的接口(以下统称为Interface)。
业务之间的项目调用是通过Interface来实现的,这样可以确保不涉及任何具体的业务实现。
首先,所有的路由层由Scenes统一定义并管理。在Scenes里,它包含了delivery的具体实现,即application。
每个业务都是架构中的一个单元,这个单元被称为Module。Module内部包含三个层:delivery, service 和 repository。
- repository 是持久层,负责数据的存储和检索。
- service 是业务逻辑层,处理核心的业务流程。
- delivery 是与外部通信的层,负责处理如HTTP请求等的输入和输出。
除此之外,还有一个 infrastructure 层,作为基础层,提供框架所必要的基础服务,如日志、配置管理等。
Scenes
Scenes负责定义不同的Application以及相对应的Application Container。
Application Container是一个容器,它可以加载同类型的application并控制其启动和停止。
简而言之,Application Container负责管理和运行对于的application。
Module
Module定义了所有暴露给外部的Interface,这包括repository interface和service interface,以及相应的数据结构(struct)。这里不涉及任何具体的实现,具体的实现是由repository和service层来完成的。
在这个架构中,delivery层依赖于service,而service层依赖于repository。这三个层的依赖关系是通过依赖注入和控制反转技术来实现的,这样可以方便地替换不同的实现。
Repository层
Repository层相对简单,它负责与外部环境(如数据库)进行交互。它需要实现Module中定义的repository interface。这个层可以有多种实现,例如可以有针对MongoDB的实现、针对MySQL的实现等,这为依赖注入和控制反转提供了便利。
Service层
Service层是业务逻辑的核心,它依赖于本Module的repository interface或其他Module的service interface。Service层不关心repository的具体实现,它只通过repository interface来调用,从而完成所有的业务逻辑。
Delivery层
Delivery层包含了多种application的实现。例如,可以有基于HTTP的实现、基于WebSocket的实现、基于gRPC的实现等。
Infrastructure层
Infrastructure层是框架的基础服务层,它提供了一些必要的服务,如配置管理、日志记录等。
Reference
- Uncle Bob. (2012). The Clean Architecture.
- Better Programming. The Clean Architecture — Beginner’s Guide.
- Microsoft. Design a DDD-oriented microservice.
- ZQ99299. DDD实践.
- Meituan Tech. (2017). 领域驱动设计在互联网业务开发中的实践.
- Go Dev. (2012). Go at Google: Language Design in the Service of Software Engineering.
- Ben Johnson. Structuring Applications in Go.
- 咖啡拿铁.你的项目应该如何正确分层你的项目应该如何正确分层