深入解析大型应用架构：以dify为例进行分析

原文：https://juejin.cn/post/7437015214351286309

Dify 是一款开源的大语言模型（LLM）应用开发平台，旨在简化和加速生成式 AI 应用的创建和部署。

它融合了后端即服务（Backend as a Service, BaaS）和 LLMOps 的理念，使开发者能够快速搭建生产级的生成式 AI 应用。

即使是非技术人员，也能参与到 AI 应用的定义和数据运营过程中。

本文主要从代码结构上进行分析，以学习其基础架构设计。

开源地址（截止写文章时已有5.1万stars)：github.com/langgenius/…

让我们开始看代码吧（先摸清楚代码的“骨骼”）

第一层：最外层（前端与后端的分离）

根据目录结构可以推测：

1. 核心代码的可能位置：通常在目录结构中，api、sdks 和 web 目录是放置核心代码的常见位置。这些目录的功能可能如下：

• • api：通常用于存放后端 API 相关代码，是项目的核心业务逻辑部分。
  • sdks：存放用于与 API 或服务交互的开发工具包或客户端库，这可能包含用于不同编程语言的接口代码。
  • web：通常用于存放前端代码，处理用户界面及相关的逻辑，可能包含 HTML、CSS、JavaScript 或前端框架的代码。

1. 辅助文件和目录：

• • docker 和 docker-legacy：可能包含 Docker 配置文件，用于容器化部署。
  • dev：可能是开发环境相关的配置或脚本。
  • images：可能用于存放图像或媒体文件，但也可能是 Docker 的镜像构建文件。
  • Makefile：通常用于构建和自动化任务。
  • LICENSE 和 README 文件夹：用于项目文档和说明。
  • CONTRIBUTING* 文件：包含项目贡献指南。

基于以上推测，api 和 sdks 目录很可能包含了项目的核心逻辑，而 web 则可能负责项目的前端或用户界面逻辑。

第二层：查看/api服务端目录结构基础能力

在这类项目结构中，核心代码通常分布在一些特定的目录中，主要包含业务逻辑、数据模型、控制器以及服务层等部分。以下是对主要目录的解读及其潜在内容：

1. app.py / app_factory.py: 这些文件通常是应用程序的入口点。app.py 可能用于直接运行应用，而 app_factory.py 则可能是用于创建应用实例的工厂函数，适合复杂配置或多实例情况。
2. configs: 存储应用的配置文件或配置模块。核心配置代码，例如数据库配置、API密钥和其他环境参数，可能在这里。
3. controllers: 这一目录通常存储路由或控制器，负责处理请求和响应。它包含核心业务逻辑的接口层，通过控制器将应用的不同模块整合在一起。
4. core: 这个目录通常包含应用的核心功能和逻辑，是较为独立且核心的模块。它可以包含重要的业务逻辑、工具方法或通用的功能模块。
5. models: 存储数据模型（可能是数据库表的ORM映射），通常包括核心的数据结构定义。这是涉及数据的核心模块，通常和数据库交互最频繁。
6. services: 服务层，用于封装业务逻辑或与第三方服务交互。这部分代码的逻辑复杂度较高，可能包括了应用的核心功能。
7. commands / tasks / schedule:

• commands：存储管理命令或CLI命令，通常与Flask或Django等框架的命令行工具相关。
• tasks：用于存储异步任务或批处理任务，可以是核心功能的辅助模块。
• schedule：存储调度任务，可能用于定时任务。

1. libs / extensions / factories:

• libs：常见的工具库或自定义功能。
• extensions：扩展模块，通常包括第三方库或插件的初始化代码。
• factories：创建对象或服务实例的工厂函数。

基于这些目录的分工，可以初步推测核心业务逻辑代码可能分布在 controllers、core、models、services 四个目录中，其中 models 和 services 尤其可能承载着主要的核心逻辑。

看到这里，熟悉SpringBoot框架的朋友是不是就明白了，即使是Python代码，也是特别传统的基础架构设计模式（和Java一样）。

看前端/web目录结构

这个项目目录结构包含多个文件夹和文件，通常用于一个基于 Next.js 的前端或全栈项目。以下是对每个目录的解释，以及可能包含核心代码的目录。

目录说明

• Dockerfile：用于 Docker 容器的构建文件。
• app：这个目录一般是 Next.js 的应用入口，包含页面、路由和核心逻辑。核心代码通常会在这里，特别是如果这是 Next.js 项目。
• config：存放项目的配置文件，如环境变量、API 端点、应用设置等。
• global.d.ts：类型声明文件，通常用来为 TypeScript 添加全局类型定义。
• jest.config.ts：Jest 测试配置文件。
• next.config.js：Next.js 配置文件，用于设置项目的构建、路由和其他 Next.js 特性。
• public：静态资源目录，存放图像、字体等可公开访问的文件。
• themes：通常存放主题文件（样式、配色方案等），与项目的 UI 相关。
• typography.js：可能是与排版样式相关的配置或逻辑文件。
• README.md：项目说明文档。
• assets：存放项目资源文件，如图片、SVG 图标等。
• context：可能包含 React 的 Context API 定义，用于全局状态管理。
• hooks：自定义 Hook 的文件夹，用于定义和组织项目的自定义逻辑。
• middleware.ts：中间件文件，可能用于处理请求或应用层面的逻辑。
• package.json：项目的依赖和脚本配置。
• service：一般是服务逻辑的目录，可能包含 API 调用或业务逻辑代码。
• tsconfig.json：TypeScript 配置文件。
• utils：通常是通用的实用函数和工具库。
• mocks：用于测试的 mock 文件。
• bin：一般用于存放脚本文件或命令行工具。
• docker：与 Docker 相关的配置或脚本。
• i18n：国际化文件，通常用于多语言支持。
• models：通常是数据模型相关的代码，例如数据库 schema 或数据类型定义。
• postcss.config.js、tailwind.config.js：PostCSS 和 Tailwind CSS 配置文件。
• types：类型定义文件夹，用于定义 TypeScript 的类型。

核心代码所在位置

在这个项目结构中，核心代码通常会集中在以下几个目录中：

1. app：包含主要的页面、路由和核心业务逻辑。
2. service：如果项目有后端服务逻辑，相关的业务逻辑可能在此目录下。
3. models：用于数据模型和 schema 定义，特别是项目涉及数据库的情况。

此外，hooks 和 context 也可能包含项目的一些核心逻辑。

总体来看：

• 很明显，前端是NextJS，后端是类似于SpringBoot（controller-service...）
• 看到这里，你是不是已经学会了如何看一个大型项目的基础架构？
• 由于dify是多人协同的大型产品，因此在读代码时需要前端-后端的思维切换。如果要更易于看懂，当你在看后端代码时，忘掉所有前端范式；当你读前端代码时，要忘掉所有后端范式；当你设计DB或者服务化能力时，忘掉其他无关范式。
• 不要看代码量大，其实每个人自己只是管好自己的‘域’，其实很容易，很简单。就像机器上的一个零件，管好自己、上游、下游就好，机器就能像齿轮一样往前滚。
• 同样的分析方法，你也可以拿langchain、llama_index、elasticsearch、dubbo来试一试。搞明白了基础架构，再去导读代码，会更容易理解一些，花的时间也将会更少。