Merge pull request #83 from GuoXiCheng/dev-c

add methodology

src/.vitepress/config.mts

@@ -56,6 +56,15 @@ export default defineConfig(
         },
         { text: "后端", link: "/backend/nodejs/index" },
         { text: "云原生", link: "/cloud-native/index" },
+        {
+          text: "方法论",
+          items: [
+            {
+              text: "12 因素应用",
+              link: "/methodology/12-factor-app/what-is-12-factor-app",
+            },
+          ],
+        },
         { text: "AI", link: "/ai/index" },
         { text: "参考", link: "/reference" },
       ],

src/.vitepress/sidebars/12-factor-app.yaml

@@ -0,0 +1,31 @@
+/methodology/12-factor-app:
+  - text: 12 因素应用介绍
+    items:
+      - text: 什么是 12 因素应用
+        link: /methodology/12-factor-app/what-is-12-factor-app
+  - text: 主要内容
+    items:
+      - text: 基准代码
+        link: /methodology/12-factor-app/codebase
+      - text: 依赖
+        link: /methodology/12-factor-app/dependencies
+      - text: 配置
+        link: /methodology/12-factor-app/config
+      - text: 后端服务
+        link: /methodology/12-factor-app/backing-services
+      - text: 构建、发布、运行
+        link: /methodology/12-factor-app/build-release-run
+      - text: 进程
+        link: /methodology/12-factor-app/processes
+      - text: 端口绑定
+        link: /methodology/12-factor-app/port-binding
+      - text: 并发
+        link: /methodology/12-factor-app/concurrency
+      - text: 易处理
+        link: /methodology/12-factor-app/disposability
+      - text: 开发与生产环境等价
+        link: /methodology/12-factor-app/dev-prod-parity
+      - text: 日志
+        link: /methodology/12-factor-app/logs
+      - text: 管理进程
+        link: /methodology/12-factor-app/admin-processes

src/methodology/12-factor-app/admin-processes.md

@@ -0,0 +1,13 @@
+# 管理进程
+
+## 核心思想
+
+后台管理任务当作一次性进程运行。
+
+## 后台管理任务
+
+用来管理或维护应用的一次性任务，例如数据的移植（migrate）、数据库检查或一次性脚本。
+
+## 一次性进程
+
+12-Factor APP 青睐提供 REPL shell 的语言，这让运行一次性脚本变得简单，无论本地部署还是线上部署，开发人员都可以通过 REPL shell 来运行一次性脚本。

src/methodology/12-factor-app/backing-services.md

@@ -0,0 +1,17 @@
+# 后端服务
+
+![](/images/12-factor-app/attached-resources.png)
+
+## 核心思想
+
+把后端服务当作附加资源。
+
+## 后端服务的定义
+
+后端服务是指应用程序运行时所需要通过网络调用的各种服务，例如数据库服务、消息队列服务、缓存服务等。
+
+## 后端服务作为资源
+
+对 12-Factor APP 而言，每个不同的后端服务都是一份资源，应用程序通过 URL 或其他存储在配置中的连接信息来使用所有的服务，并与所有后端服务的部署保持松耦合。
+
+所有后端服务的部署都可以按需加载或卸载，无需修改应用程序的代码。

src/methodology/12-factor-app/build-release-run.md

@@ -0,0 +1,27 @@
+![](/images/12-factor-app/build-release-run.png)
+
+## 核心思想
+
+严格分离构建、发布和运行阶段。
+
+## 基准代码部署的三个阶段
+
+### 构建阶段
+
+将基准代码转化为可执行包，包括获取依赖项、编译成二进制文件和资源文件。
+
+构建阶段可以相对复杂，并且需要人为触发，错误信息可以立即展现在开发人员面前，从而得到妥善处理。
+
+### 发布阶段
+
+将构建得到的结果与部署所需配置结合，形成可立即运行的版本。
+
+每发布一个版本必须对应一个唯一的发布 ID，例如使用发布时的时间戳或一个增长的数字。
+
+发布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。
+
+### 运行阶段
+
+在执行环境中启动应用程序进程，使用选定的发布版本运行。
+
+运行阶段是可以自动进行的，如服务器重启，或是进程管理器重启了一个崩溃的进程。因此，运行阶段应该保持尽可能少的模块，这样假设半夜发生系统故障而开发人员又捉襟见肘也不会引起太大问题。

src/methodology/12-factor-app/codebase.md

@@ -0,0 +1,27 @@
+# 基准代码
+
+![](/images/12-factor-app/codebase-deploys.png)
+
+## 核心思想
+
+在 12-Factor APP 中，一份基准代码应与一个应用保持一一对应关系，但可以存在多份部署。
+
+## 基准代码的定义
+
+- 在集中式版本控制系统（如 SVN）中，基准代码是指单一的代码库。
+
+- 在分布式版本控制系统（如 Git）中，基准代码是指最上游的代码库。
+
+## 基准代码与应用的关系
+
+一份基准代码对应一个应用，多份基准代码对应多个应用，多个应用组成一个分布式系统。
+
+在分布式系统中，每一个组件都是一个应用，每个应用都可以使用 12-Factor 进行开发。
+
+多个应用共享一份基准代码有悖于 12-Factor 的原则，可以将共享代码拆分为独立的类库，然后将类库发布到代码仓库或包管理器中。
+
+## 部署的多样性
+
+一份基准代码的多份部署中，每份部署都相当于一个应用的实例，例如：开发环境、测试环境、生产环境等。
+
+所有部署的基准代码相同，但可以有不同的版本。

src/methodology/12-factor-app/concurrency.md

@@ -0,0 +1,23 @@
+# 并发
+
+![](/images/12-factor-app/process-types.png)
+
+## 核心思想
+
+通过进程模型进行水平扩展。
+
+## 进程模型基本构成
+
+在 12-Factor APP 中，一个应用被设计为一组小型、独立的进程。这些进程可以是处理 Web 请求的 web 进程、处理后台任务的 worker 进程，或是执行其他特定任务的进程。
+
+每个进程都是无状态的，它们不会直接共享内存或存储状态信息。这种设计使得每个进程都可以独立运行，互不干扰。
+
+## 扩展的类型
+
+### 垂直扩展
+
+通过增加单个进程的计算资源（如 CPU、内存）来增加处理能力。这是传统的扩展方式，但它有物理和成本的限制。
+
+### 水平扩展
+
+通过增加进程的实例数量来扩展处理能力。在 12-Factor APP 中，这通常是通过增加同一类型的无状态进程实例来实现的，比如增加更多的 web 进程来处理更多的并发用户请求。

src/methodology/12-factor-app/config.md

@@ -0,0 +1,9 @@
+# 配置
+
+## 核心思想
+
+在环境中存储配置。
+
+## 基准代码和配置严格分离
+
+判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。

src/methodology/12-factor-app/dependencies.md

@@ -0,0 +1,19 @@
+# 依赖
+
+## 核心思想
+
+在 12-Factor APP 中，应显式声明所有依赖项，避免隐式依赖，以确保构建和运行环境的一致性。
+
+## 依赖清单
+
+通过依赖清单显式声明依赖项，例如`package.json`、`requirements.txt`等。
+
+## 依赖隔离
+
+通过依赖隔离确保程序不会调用系统中存在但清单中未声明的依赖，例如：`virtualenv`、`node_modules`等。
+
+依赖清单声明必须和依赖隔离一起使用。
+
+## 依赖管理
+
+通过依赖管理工具，只需要通过一个构建命令来安装所有的依赖项，即可开始工作，例如：`npm install`、`pip install`等。

src/methodology/12-factor-app/dev-prod-parity.md

@@ -0,0 +1,19 @@
+# 开发环境与线上环境等价
+
+## 核心思想
+
+尽可能保持开发、预发布和线上环境的等价性。
+
+## 缩小本地与线上差异
+
+- 缩小时间差异：开发人员可以几小时，甚至几分钟就部署代码。
+
+- 缩小人员差异：开发人员不只要编写代码，更应该密切参与部署过程以及代码在线上的表现。
+
+- 缩小工具差异：尽量保证开发环境以及线上环境的一致性。
+
+|                      | 传统应用 | 12-Factor 应用 |
+| -------------------- | -------- | -------------- |
+| 每次部署间隔         | 数周     | 几小时         |
+| 开发人员 vs 运维人员 | 不同的人 | 相同的人       |
+| 开发环境 vs 线上环境 | 不同     | 尽量接近       |

src/methodology/12-factor-app/disposability.md

@@ -0,0 +1,15 @@
+# 易处理
+
+## 核心思想
+
+快速启动和优雅停止。
+
+## 快速启动
+
+快速启动是指进程应当追求最小启动时间，更少的启动时间提供了更敏捷的发布及扩展过程，进程将更容易迁移到新的物理机上，增加了健壮性。
+
+## 优雅停止
+
+优雅停止是指进程一旦接收到停止信号（SIGTERM），应当停止监听服务的端口，拒绝所有新的请求，并继续执行当前已接收的请求，然后退出。
+
+对 worker 进程而言，应当将当前任务退回队列，并释放所有系统资源。

src/methodology/12-factor-app/logs.md

@@ -0,0 +1,11 @@
+# 日志
+
+## 核心思想
+
+把日志当作事件流。
+
+## 应用的日志管理
+
+12-Factor APP 不应该试图自己管理日志的输出流，不应写或维护日志文件，每一个进程都会直接提供标准输出事件流。
+
+在开发环境中，可以通过实时终端查看应用活动；在预发布或线上环境中，每个进程的输出流由运行环境截获，并发送给一个最终处理程序，用于查看或是长期存档。

src/methodology/12-factor-app/port-binding.md

@@ -0,0 +1,5 @@
+# 端口绑定
+
+## 核心思想
+
+12-Factor APP 通过端口绑定来提供服务，并监听发送至该端口的请求。

src/methodology/12-factor-app/processes.md

@@ -0,0 +1,9 @@
+# 进程
+
+## 核心思想
+
+以无状态且无共享的进程运行应用。
+
+## 无状态进程的原则
+
+进程可以使用内存或磁盘作为事务操作的临时缓存，但不应依赖于这些缓存来保留数据供后续请求使用，因为进程的重启会导致数据丢失。所有需要持久化的数据应存储在后端服务，如数据库中。

src/methodology/12-factor-app/what-is-12-factor-app.md

@@ -0,0 +1,21 @@
+# 什么是 12 因素应用
+
+## 介绍
+
+随着云计算的兴起，软件通常会以服务的形式来交付，它们被称为网络应用程序，或软件即服务（SaaS）。
+
+12-Factor 为如何构建 SaaS 应用提供了最佳实践：
+
+- 为了使新的开发者花费最少的学习成本加入这个项目，而使用标准化流程自动配置。
+
+- 为了在各个系统中提供最大的可移植性，而和操作系统之间尽可能的划清界限。
+
+- 为了在服务器和系统管理方面节省资源，而部署在现代的云计算平台。
+
+- 为了将开发环境和生产环境的差异降至最低，而使用持续交付实施敏捷开发。
+
+- 为了保证工具、架构和开发流程不发生明显变化的前提下实现扩展，而使用容器化技术或微服务架构。
+
+## 参考
+
+- [12-Factor App](https://12factor.net/zh_cn/)

src/public/markmap.mdx

@@ -140,6 +140,20 @@
       - [docker 基本使用命令](cloud-native/docker/basic-commands)
       - [构建 docker 镜像](cloud-native/docker/build-docker-image)
     - kubernetes
+  - 方法论
+    - 12 因素应用
+      - [基准代码](methodology/12-factor-app/codebase)
+      - [依赖](methodology/12-factor-app/dependencies)
+      - [配置](methodology/12-factor-app/config)
+      - [后端服务](methodology/12-factor-app/backing-services)
+      - [构建、发布、运行](methodology/12-factor-app/build-release-run)
+      - [进程](methodology/12-factor-app/processes)
+      - [端口绑定](methodology/12-factor-app/port-binding)
+      - [并发](methodology/12-factor-app/concurrency)
+      - [易处理](methodology/12-factor-app/disposability)
+      - [开发与生产环境等价](methodology/12-factor-app/dev-prod-parity)
+      - [日志](methodology/12-factor-app/logs)
+      - [管理进程](methodology/12-factor-app/admin-processes)
   - AI
     - [AI 发展历程](ai/history-of-ai)
     - [AI 领域](ai/ai-field)