5 块钱，就可以给娃训练一个专属的 AI 模型

发表回复

上周末花了 5 个小时，从零开始给娃训练了一个基于 flux1_dev 的 lora，用于生成娃的照片。

以下为详细（保姆级）的过程记录，有想法又没有自己训练过 lora 的程序员爸爸或妈妈们可以尝试一下。

可能的时间成本：2 ~ 5 小时，资金成本：5 ~ 10 块。

环境准备

因为我们会用到 GPU 机器，去类似于阿里云这种云平台租，太贵。

这里我们选择的是 audodl ，一个比阿里云便宜 60% 的可按小时租 GPU 服务器的算力平台。autodl 基于容器实现，在使用上有一些局限性，但是对于我们当下的需求来说，还是非常匹配的。

我们选择如图 1 所示的配置：

图1

4090D + 50 G 额外的空间

尽量选择空闲 GPU 多的主机或所在区，因为可能会存在主机 GPU 不够的情况。

下单付款，等待容器启动。

容器启动后，直接使用官方提供的 web 的终端，这个终端有一个好处是当你关掉浏览器以后，终端还在，有点类似于 nohup 的执行状态。

需要说明一下，autodl 的存储分为系统盘和数据盘，在 /root/autodl-tmp 下为数据盘空间。我们要下载的模型、项目等都放到数据盘下。

把 commfy UI flux 跑起来

1. 创建 comfyUI 的环境并跑起来

cd ~/autodl-tmp

git clone https://github.com/comfyanonymous/ComfyUI
cd ComfyUI
conda create -n comfyui python=3.12 -y

conda init
source ~/.bashrc

conda activate comfyui
pip install -r requirements.txt 

在 git clone 时可能会遇到克隆失败的情况，此时需要使用 autodl 的学术资源加速：https://www.autodl.com/docs/network_turbo/

另外，在 conda create 后无法直接 conda activate，需要先 conda init，然后 source ~/.bashrc 或重新启动一下终端

接下来是启动 ComfyUI

python main.py

启动是启动了，但是如何访问了，这台机器又不在我本地，难道要启一个外网端口监听，此时就需要启动自定义服务，当然我们也可以使用 ssh 的通道能力，让本地电脑能访问远程的服务，在本地命令行中执行如下的命令：

ssh -CNg -L 8188:127.0.0.1:8188 -p 49027 root@connect.westb.seetacloud.com

以上的 -p 后的参数对于不同的机器不同，请参考控制台上的登录指令，如图2：

图2

输入后会提示：root@connect.westb.seetacloud.com’s password:

当时将控制台的密码复制出来，粘贴即可，回车。此时，可能没有啥反应，嗯。这是正常的。不用管他，除非报错告诉你连接失败或者密码错误，再重新输入。

在浏览器中输入：http://localhost:8188/

就可以看到 ComfyUI 的界面了。

2. 下载并运行 flux

在 ComfyUI 的 flux1 的 Demo 界面中：https://comfyui-wiki.com/tutorial/advanced/flux1-comfyui-guide-workflow-and-examples

可以把 Flux Dev ComfyUI workflow example 那张美少女的照片下载下来，直接拖到 ComfyUI 的界面上，或者下载 json 文件加载进来。如下图所示：

图3

要把示例跑起来，我们有 4 个文件要下载，分别是：

  • 放到 models/unet 目录下的 flux1.dev fp8 模型：https://hf-mirror.com/camenduru/FLUX.1-dev/resolve/main/flux1-dev-fp8.safetensors
  • 放到 models/vae 目录下的 VAE 模型：https://hf-mirror.com/camenduru/FLUX.1-dev/resolve/main/ae.safetensors
  • 放到 models/clip 目录下的 clip 编码器：https://hf-mirror.com/camenduru/FLUX.1-dev/resolve/main/clip_l.safetensors
  • 放到 models/clip 目录下的 T5XXL 文本编码器：https://hf-mirror.com/camenduru/FLUX.1-dev/resolve/main/t5xxl_fp8_e4m3fn.safetensors

在 hf 下可能会存在下载失败的情况，这里我们选择 hf-mirror: https://hf-mirror.com/camenduru/FLUX.1-dev/tree/main

下载可能会持续个 20 分钟左右，视网络情况，早上下载可能会快一些。

接下来就比较简单了，在本地浏览器中打开，点击运行 Queue Prompt 按钮

第一次运行会慢一点，因为需要加载模型这些，后面再次执行就大概 10 秒多一点。

图4

把 lora 加到管线并跑起来

1. 下载 lora 模型在类似于 liblib.art 之类的网站下载一个你觉得不错的 lora 模型，将其放到 ComfyUI 的 models/loras 目录中。

在 ComfyUI 的界面中增加一个 lora 的节点，这里我选择的是纯粹的 lora 节点，如图 5 所示

图5

点击 Queue Prompt 按钮，等一会儿就能看到生成的图片了，如果图片不符合预期，可以调整一下 prompt 试试，如你选择的 LoRA 是一个美女明星的 LoRA，简单点的：a girl，portrait, professional portrait

2. 调整 LoRA 强度与权重在 LoRA 节点中，你也可以调整 LoRA 的权重，以影响生成图片时对 LoRA 的依赖程度。通常，权重值可以设置在 0.5 到 1.0 之间，这取决于你希望模型生成的图片与 LoRA 模型的契合度。权重越高，生成的图片越接近 LoRA 模型的风格；而权重越低，则越依赖于你输入的 prompt。

调整 LoRA 节点的参数后，再次点击 Queue Prompt 按钮，等待生成的新图片。如果生成的图片依然不符合预期，可以继续调整 LoRA 权重，或者尝试修改 prompt 来更好地引导模型。

打标

在 LoRA 跑起来并生成合适的图片后，下一步就是准备训练数据集。数据集的质量对模型的效果至关重要，因此我们需要对数据集进行打标。打标的目的是为每张图片生成准确的描述标签，使模型能够理解图片的内容，以便在未来生成类似的图像时能够参考这些标签。

打标工具

选择合适的打标工具或方案可以帮助我们生成高质量的标签。以下是一些常用的打标工具或方案：

  1. Florence 2：Florence 2 是一个强大的自动打标工具，能够为图片生成高精度的标签。它的优点是标签的细节和准确性较高，适合用于需要精确描述的图片场景。
  2. JoyCaption：JoyCaption 是 WD14 的替代工具，提供了更细致的标签生成能力。它能够为每张图片生成更详细的描述，适合用于生成具备复杂场景或人物的标签。不过，它也有一定的出错概率，因此需要额外的人工检查。
  3. MiniCPM：MiniCPM 是一个轻量级的打标工具，适合小规模数据集的快速打标。它的优点是操作简便，生成速度快，缺点是生成的标签可能不够详细，适合用于简单场景的图片。
  4. WD14：WD14 是一个非常流行的打标工具，特别适合用于文生图任务。它的标签生成能力较强，能够根据图片生成与文本 prompt 相关性较高的标签。特别适用于需要高质量和一致性的图片生成任务。

打标策略

为了确保数据集的质量，打标时可以采用以下策略：

  1. 多工具结合使用：如果你的图片集包含不同类型的图片，可以使用多个打标工具来生成初步标签，然后对标签进行合并和校对。比如：使用 Florence 2 生成的标签作为基础，再用 WD14 生成补充标签。
  2. 人工校对：虽然自动打标工具能够节省大量时间，但是人工校对是必不可少的环节。检查和修正错误标签，确保每张图片的标签描述都准确无误。
  3. 标签标准化：在打标过程中，确保使用一致的标签格式和风格。比如：尽量使用标准化标签（如 “portrait”, “landscape”, “girl”, “cityscape” 等）来确保不同图片的标签一致性。
  4. 使用特定的标签：对于我们当前这个场景，对每个图片在 AI 打标的基础上增加额外的一个标签来代表娃，比如我在这里使用的是 bbdr，具体参考打标的脚本。

WD 打标

在这里我选择的是 https://huggingface.co/SmilingWolf/wd-swinv2-tagger-v3 来实现的打标，在其 web demo 的基础上做了一点小改造，具体代码见：https://github.com/phppan/wd-swinv2-tagger-v3-script/blob/main/wd_tag.py

git clone https://github.com/phppan/wd-swinv2-tagger-v3-script

cd wd-swinv2-tagger-v3-script/

conda create -n wds python=3.12 -y
conda activate wds
pip install -r requirements.txt 
mkdir data

export HF_ENDPOINT=https://hf-mirror.com

可能会存在克隆失败的情况，如：

fatal: unable to access 'https://github.com/phppan/wd-swinv2-tagger-v3-script/': GnuTLS recv error (-110): The TLS connection was non-properly terminated.

多试几次。

最后的 export HF_ENDPOINT=https://hf-mirror.com 要执行，我们从镜像网站下载模型，hf 有时候无法直接访问。

如果嫌麻烦，可以 vim ~/.bashrc，在此文件中添加后 source ~/.bashrc

上传数据集并生成打标内容

将前面准备好的 10 张照片上传到上面创建的 data 目录。执行

python wd_tag.py

在上面的打标脚本中，我将特定的标签 bbdr 加到标签中，后续在生成的时候都会带上这个标签。你也可以改成你自己的标签，赖博说这里：最好几个辅音叠加，不容易冲突

等待模型下载完成，并执行完打标工作，在 output 目录中可以看到生成和图片名称同名的 txt 文件，这就是我们打好了的标签。

开始训练模型

模型训练，这里我选择的是 ai-toolkit：https://github.com/ostris/ai-toolkit

git clone https://github.com/ostris/ai-toolkit
cd ai-toolkit/
git submodule update --init --recursive

conda create -n aitool python=3.12 -y
conda activate aitool

pip3 install torch
pip3 install -r requirements.txt

修改配置文件并执行训练

cp config/examples/train_lora_flux_24gb.yaml ./config/bbdr.yaml
vim ./config/bbdr.yaml

一些参数的修改可以参考视频：https://www.youtube.com/watch?v=HzGW_Kyermg 主要是修改：name（名字）、training_folder（训练生成的目录）、folder_path(训练集路径)

python run.py ./config/bbdr.yaml

接下来就是等待训练完成。

训练完成后，在上面参数中设置的生成目录中可以看到你想要的 lora 模型文件，如我们设置的名字是 bbdr，则生成的模型名为：bbdr.safetensors

将其复制到前面我们已经部署好了的 ComfyUI 项目的 models/loras 目录下，在界面中选择你要的 lora 模型，在 prompt 中把你自定义的标签加上，如我们这里是 bbdr，一个简单的示例：bbdr,a girl,cute,perfect body,standing,street

等一下，就能看到专属于娃的 AI 模型生成的图片了。

其它

  1. 如果在编写/调试代码、上传下载数据到实例、给他人做代码展示等不需要GPU卡场景时，可以关机后使用无卡模式开机，无卡模式开机的区别在于对于这次开机会使用0.5核；2GB内存；无GPU卡的配置，价格统一为￥0.1/小时
  2. 如果不想等训练完成，可以设置定时关机。
  3. 照片请准备同一时期的照片，不同时期的照片，特别是小朋友，可能相貌差别较大，会导致最终生成的效果不好

以上是程序员逻辑，主打一个学习和挑战。

不想整这么复杂的，可以选择在类似于 liblib 的 lora 训练平台上生成：https://www.liblib.art/pretrain 或者类似于 https://www.mimicpc.com/ 这样的平台。

强哥说：看了这么久的理论，这次终于破天荒来了篇工程的。

以上。

最后感谢赖博的指导

研发效能之规模管理：工程化与系统化的思考

发表回复

随着业务的发展，研发团队和系统架构往往面临一个共同的难题：如何在规模不断扩大的情况下，保持高效、稳定的输出。

你是否曾经历过这样的困境：系统运行环境中的负载不断攀升，不得不频繁进行性能优化；团队规模扩充后，开发协作开始变得混乱，沟通成本直线上升；技术债务不断积累，系统的开发和维护变得艰难？

这些问题的本质在于规模管理的缺失或不足。规模不仅仅体现在系统需要处理越来越多的用户和数据层面，还包括团队管理、开发流程和技术栈的复杂性增长。如果缺乏系统化和工程化的管理方法，规模的扩大往往会拖慢研发效率，甚至导致项目失控。

那么，如何通过系统化、工程化的手段，来解决规模扩展带来的复杂性和挑战呢？

1 研发中的规模

在软件研发中，规模主要可以分为生产规模和开发规模两大类。具体来说，研发中的规模主要包括以下几个方面：

1.1 生产规模

生产规模指的是系统在实际运行环境中所需处理的负载、并发能力和扩展性。它关注的是一个系统在面对业务增长时，是否能够高效处理不断增加的数据量、用户请求、并发任务等。包括：

  • 并发处理能力：系统可以同时处理多少用户请求或任务。
  • 数据处理能力：系统能够处理的数据量级别如何，是否支持大数据量的存储、查询和分析。
  • 网络流量承受能力：系统在面对大规模用户访问时，是否能够保持稳定的响应时间，并在流量高峰期依然能够正常工作。
  • 弹性扩展能力：系统是否可以根据流量的变化自动扩展资源，避免高负载时的性能瓶颈和低负载时的资源浪费。
  • 容错与高可用性：系统在面对硬件或软件故障时是否具备自我恢复能力，确保业务的连续性。

1.2 开发规模

开发规模指的是随着项目和团队的扩展，如何有效管理代码库、开发流程和团队协作。随着开发人数、代码库复杂度的增长，团队需要更加系统化的管理手段，以保持高效的开发效率和高质量的代码输出。

  • 代码库规模：项目的代码量逐渐增加，模块和功能变得更加复杂。如何确保代码库的可维护性、可测试性和可扩展性是关键。
  • 团队规模：参与开发的工程师人数增多，如何确保团队成员高效协作、避免冲突和重复工作是管理的重点。
  • 协作复杂度：随着团队规模扩大，沟通和协作的难度也会增加。如何通过协作工具、流程规范和文档化手段确保团队高效运转。
  • 开发流程的复杂度：团队规模和项目复杂度增加，开发流程自然也会变得更复杂。如何通过流程优化和工具化手段（如CI/CD、自动化测试等）简化开发、测试、发布流程。
  • 知识管理：随着项目复杂度增加，技术债务和知识流失的风险也随之增加。如何通过文档化、知识共享平台等手段，确保团队成员（尤其是新人）快速上手和理解项目。

除了上面的 5 点，还有一些技术规模相关的点：

  • 技术栈的扩展性：技术选型是否具备支撑未来业务增长的能力，是否容易扩展、维护和升级。
  • 基础设施的扩展性：从服务器、数据库到网络架构，是否能够支持高并发、大数据量、快速响应等需求。
  • 技术债务管理：随着项目的发展，技术债务的积累不可避免。如何在技术规模扩展的同时进行技术债务的管理和偿还。

2 如何管理规模

作为研发管理者，面对系统和团队规模的不断扩大，如何确保研发效能的持续提升，是一个复杂且多维度的挑战。规模管理的核心在于通过技术手段与管理方法的结合，保证系统和团队能够适应业务增长，同时避免因规模扩大而带来的效率损失和质量问题。

2.1 管理生产规模

生产规模通常指的是系统在实际运行环境中所能处理的负载、并发能力和扩展性。然而，生产规模的扩展实际上离不开架构、基础设施、自动化手段等，即通过技术手段来保证系统能处理不断增长的业务需求。

2.1.1 架构设计与扩展性

生产规模的扩展依赖于架构设计的弹性和扩展性。架构设计是生产系统能否承载更大负载、更高并发的根本。

  • 微服务架构：在面对大规模扩展时，单体架构往往难以承受较大负载和频繁的变更。微服务架构通过将系统拆分为多个独立的服务，每个服务可以独立扩展、部署和维护。这种架构设计允许生产系统根据业务需求水平扩展，避免单点瓶颈。

  • 事件驱动架构：在高并发环境下，事件驱动架构可以通过异步消息处理来解耦系统中的模块，从而提高弹性和扩展性。这种架构设计允许系统通过消息队列（如Kafka、RabbitMQ）来处理大量并发请求，并减少同步通信带来的延迟和性能瓶颈。

  • 分布式架构：对于需要处理海量数据和高并发请求的生产系统，分布式架构是必不可少的。通过水平扩展（如分布式数据库、分布式缓存、分布式存储等），系统可以在生产环境中扩展以应对更高的负载。

架构设计决定了生产规模的技术上限。架构设计是生产系统能否在负载增加时保持高效运行的关键。

在管理生产规模时，需要着重考虑当前架构的合理性和前瞻性。

2.1.2 基础设施扩展和性能优化

  • 自动化扩展：利用云计算平台的弹性伸缩功能，根据流量动态增加或减少资源。为了实现更灵活的资源管理和扩展，容器化技术（如 Docker ）和容器编排系统（如 Kubernetes ）成为生产规模扩展的基础。通过容器化，生产环境中的服务可以快速部署、扩展和迁移，从而应对瞬时的流量峰值。同时，Kubernetes 的自动扩展功能可以根据资源的使用情况自动调整服务的实例数量，确保系统在负载变化时能够灵活响应。

  • 缓存与 CDN：在高并发访问场景下，合理使用缓存（如Redis、Memcached）和 CDN 可以显著减轻后端的压力，提升系统的响应速度。缓存机制不仅加快了数据的读写，还减少了数据库的压力。

  • 技术栈的性能和扩展性：技术选型中的语言、框架和数据库等技术栈的扩展性直接决定了生产系统的性能瓶颈。例如，选择支持大规模并发请求的技术栈（如 Node.js、Go、Java 中的 Netty 框架等）可以显著提升系统在高负载下的表现。同时，选择可扩展的数据库技术（如 NoSQL 数据库、分布式数据库）可以确保系统在面对海量数据时依然能够快速响应。当确实存在性能问题时，换一种技术栈可能是一种比较彻底的解决问题的思路。

  • 性能监控与优化：生产规模的管理离不开实时性能监控。通过监控工具（如Prometheus、Grafana）监控系统的关键性能指标（如CPU、内存、带宽、响应时间等），并通过自动化告警机制及时发现并解决瓶颈问题，确保系统的稳定性和高效性。

  • 云计算与弹性扩展：云平台提供的弹性扩展能力是生产规模扩展的重要技术基础。通过云服务（如阿里云、腾讯云、AWS、Azure、Google Cloud）提供的按需扩展资源，生产系统可以根据流量动态调整计算资源、存储资源和网络带宽，确保系统在高并发和高负载下保持稳定。

基础设施扩展能力和性能优化及监控直接影响生产系统的弹性和可扩展性。合理的选型能够为生产系统提供未来业务增长所需的技术保障。

2.1.3 自动化与运维能力

生产规模的扩展离不开自动化运维能力的支持。自动化工具链（如 CI/CD、自动化测试、基础设施即代码）是保障生产系统在扩展过程中保持高效运作的重要手段。

  • 持续集成与持续交付 (CI/CD) ：在生产环境中，频繁的更新和部署可能会带来较高的风险。通过CI/CD工具链，生产系统的更新、测试和部署可以自动化完成，从而减少人工操作带来的错误和延迟。CI/CD工具确保在生产规模扩展的过程中，系统的更新频率不会影响其稳定运行。

  • 自动化测试与监控：在生产规模扩展时，系统的复杂性和负载增加会带来更多的不确定性。通过自动化测试，生产系统可以在每次更新前进行回归测试和性能测试，确保系统在发布新功能时不会出现性能瓶颈或不可预见的错误。同时，通过监控工具（如Prometheus、Grafana），可以实时监控生产系统的性能指标，提前发现并解决潜在的性能问题。

  • 自动化扩展与容灾能力：通过基础设施自动化（如 Terraform、Ansible），生产系统在面对突发流量时可以自动扩展资源，并在发生故障时进行自动化恢复。这种技术规模中的自动化能力，是生产系统在高负载或故障环境下能够保持高可用性的关键。

  • 蓝绿部署和金丝雀发布：在大规模生产环境下，通过蓝绿部署和金丝雀发布，可以减小新功能或修复补丁上线时的风险，确保在问题发生时能够快速回滚。其实就是灰度发布，或者说要严格地执行灰度发布。

自动化能力不仅提高了生产系统的运维效率，还在生产规模扩展时提供了韧性和容错能力。

2.1.4 技术债务管理与可维护性

随着生产规模的扩展，技术债务的管理变得尤为重要。技术债务的管理不当会直接影响生产系统的性能和稳定性。技术规模中的技术债务管理策略需要融入生产规模的规划中，以确保系统在扩展过程中不会因为技术债务的积累而出现故障或性能下降。

  • 定期重构与优化：随着系统的不断扩展，代码复杂度和技术债务不可避免地会增加。通过定期的代码重构和性能优化，可以减少技术债务的积累，确保系统在生产环境中的稳定性。例如，定期优化数据库查询或重构基础代码模块，可以避免随着业务增长而出现的性能瓶颈。

  • 技术债务的监控与清理：通过技术债务监控工具，团队可以定期评估系统中的技术债务，并规划技术债务的偿还时间。特别是在生产系统扩展时，及时清理技术债务能够大幅减少系统的不可预测性，确保生产系统的可维护性。

更多技术债务的内容可以参考之前写的这篇文章：架构师必备：技术债务的识别、管理与解决之道

2.2 管理开发规模

开发规模指的是随着项目复杂度、代码库、开发团队人数的增加，如何有效管理开发流程、代码库和团队协作。包括以下几个部分：

2.2.1 代码库与模块化管理

随着项目的规模扩大，代码库的复杂度也随之增加。为了保持代码库的可维护性和可扩展性，合理的技术架构设计和技术栈选型至关重要。

  • 模块化与组件化：模块化设计（例如微服务架构）能帮助团队将系统拆分为多个独立的模块或服务，减少耦合性，并允许团队并行开发。合理的模块化设计不仅可以简化代码管理，还能减少不同团队之间的依赖，提升开发效率。

  • 技术栈的扩展性：技术栈的选择对开发规模的扩展至关重要。选用成熟、可扩展的技术栈（如Kubernetes、容器化、云原生技术）可以帮助团队更好地应对复杂的开发需求。技术栈选型不仅影响系统的运行能力，还影响团队的学习曲线、代码质量和开发速度。

  • 接口设计与抽象：合理的接口抽象能够减少模块之间的依赖。通过面向接口编程，团队可以在不破坏项目整体架构的情况下，灵活地扩展或替换某些模块。这种设计使得开发团队在面对复杂业务时，能够保持系统的灵活性和可维护性。

2.2.2 开发流程与自动化

随着团队人数的增加和代码库的扩展，开发流程的复杂性也随之增加。为了提升开发效率，技术规模中的基础设施扩展性和自动化能力是开发流程中的重要组成部分。

  • 持续集成与持续交付 (CI/CD) ：自动化工具链是开发规模扩展中的关键要素。通过自动化测试、构建、部署流程，开发团队能够更频繁地发布代码，减少人为操作的风险。技术规模中的自动化工具（如Jenkins、GitLab CI、CircleCI，各公有云的云效产品）对开发效率的提升至关重要。

  • 代码评审与规范：制定统一的代码规范，确保团队成员的代码风格一致，避免“代码腐化”为难以维护的“意大利面条式代码”。通过代码评审（Code Review），团队可以发现潜在问题，提升代码的整体质量和可维护性。

  • 自动化测试：技术规模扩展中的自动化程度直接影响开发团队的效率。通过引入单元测试、集成测试、端到端测试，团队可以在不断扩展的代码库中保持代码质量，并快速识别回归错误。

  • 技术债务管理与重构计划：随着开发规模的扩大，技术债务的管理变得尤为重要。技术债务的积累会降低开发效率，增加维护成本。因此，定期的技术债务清理和代码重构计划是开发流程管理中的必要步骤。通过技术规模中的架构优化和代码重构，团队可以确保系统在业务增长时依然保持可维护性。

2.2.3 团队协作与知识管理

开发规模不仅仅依赖于技术架构和工具链的管理，还需要通过良好的协作机制和知识管理确保团队的高效运作。技术规模中的技术栈选型和架构设计也会影响团队的协作方式。

  • 知识共享与文档化：在开发规模扩展的过程中，技术栈的复杂性增加，团队成员需要通过高效的知识管理平台（如Confluence、Notion）来共享与管理技术文档。特别是当团队采用复杂的技术架构时（如微服务或分布式架构），通过文档化来规范开发流程和技术决策，可以减少沟通成本，提升协作效率。

  • 技术栈选择对协作的影响：选择合适的技术栈不仅影响系统的技术规模，也会影响团队的协作方式。例如，采用微服务架构可以让不同团队独立开发、部署自己的服务，减少团队之间的依赖。而采用更紧耦合的单体架构则需要更多的沟通与协调。因此，技术栈的选择在开发规模扩展中起到至关重要的作用。

2.2.4 选择合适的开发模型

开发模型是帮助团队组织开发流程、管理代码质量和发布节奏的框架。在不同的开发规模下，开发模型需要根据技术规模中涉及的技术栈、架构设计和自动化能力进行调整。

在开发规模扩展的过程中，技术栈和架构设计往往决定了开发模型的选择。例如：

  • 微服务架构与敏捷开发模型：微服务架构鼓励独立发布和独立开发，因此更适合敏捷开发模式。在这种模式下，技术团队可以迭代地发布小的功能模块，并通过自动化测试和持续集成工具确保代码质量。微服务架构的技术规模管理要求开发模型灵活且高效，以适应快速变化的业务需求。

  • 单体架构与瀑布模型：对于采用单体架构的系统，开发模型往往倾向于传统的瀑布模型或迭代开发模型。由于单体架构的耦合性较强，系统的发布和开发需要更为慎重，开发模型在这种情况下会更注重前期设计、集成测试和代码审核。

3 小结

管理规模的扩展不仅仅是对技术的挑战，更是对一个企业工程化与系统化能力的考验。通过清晰的架构设计、自动化工具的引入、规范化的流程和有效的团队协作机制，企业可以在规模扩张的同时保持研发效能和系统的稳定性。

这不仅要求架构师从技术角度进行弹性设计，还需要研发管理者从整体角度系统化地规划团队协作和流程优化。规模扩展的成功，依赖于工具、流程、架构和团队的有机结合与协同运作。只有通过持续的工程化改进和系统化的管理方法，企业才能在面对规模扩展时从容应对，并建立起长久的竞争优势。

规模的扩展并不可怕，真正的挑战在于能否通过合理的手段，保证系统和团队在快速变化的环境中依然具备强大而灵活的应对能力。

正如一座高楼，只有在扎实的地基之上，才能随风而屹立不倒。在研发管理的世界里，规模的管理就是那座高楼的地基。通过科学的规模管理，企业不仅能够应对当前的增长，更能够为未来的持续创新打下坚实的基础。

最后再次推荐一下 cursor 编辑器，写起来代码来真的很 6。

以上。

架构劣化，系统复杂度飙升，如何应对？

发表回复

在构建和演进复杂企业级系统时，架构师常常面临一个令人头痛的现象：架构劣化。

当系统初始设计时一切都井然有序，但随着业务需求的不断增多、新功能的迭代、技术栈的多样化引入，系统开始逐渐变得复杂，模块间的耦合度不断上升，开发者在维护和扩展时难免感到力不从心。系统的可预测性降低，Bug 频发，技术债务迅速累积，甚至每一次小的改动都可能引发意想不到的问题。

为什么曾经清晰的架构会走向失控？如何在长期的系统演化中，保证架构的灵活性与可维护性，而不让其逐渐腐化？

这一切都指向了一个关键问题：架构设计中的一致性。

正如 Fred Brooks 在《设计原本（The Design of Design）》中所言：「一致性应该是所有质量原则的根基。」

今天我们将从风格一致性、解决方案一致性、以及形式一致性三个方面，聊下架构设计中如何实现一致性。

1 风格一致性：统一的架构模式

何谓风格？

架构风格是构建系统时遵循的一套原则和模式，它为系统的设计提供了抽象框架。风格可以看作是架构中一系列可重复的微观决策，这些决策在不同上下文中应用，旨在最小化开发者的脑力负担。

风格具有其属性：

  • 妥适性：根据奥卡姆剃刀原理，风格应避免引入不必要的复杂性，满足基本功能即可。这意味着架构设计中应当聚焦于最核心的需求，避免过度设计。
  • 普遍性：风格应该具备广泛适用性，能够通过有限的功能支持多种结果。这种普遍性有助于减少架构中的冗余，提升系统的灵活性。

架构风格的一个经典例子是「管道-过滤器」模式。在数据处理系统中，通过一系列过滤器对数据流进行处理，开发者只需理解这种模式的核心思想，即可快速理解系统的其他部分。这种风格的一致性使得系统更加可预测，减少了开发和维护中的复杂性。

风格的一致性的落地会从架构到系统设计。

风格一致性要求在设计系统时，所有模块都遵循相同的架构模式。例如，在一个复杂的企业应用中，如果我们选择了领域模型来处理业务逻辑，那么整个系统的其他部分也应遵循这一模式，而不应在某些模块中使用事务脚本。这种不一致会导致开发者陷入不同模式的转换中，增加理解和维护的成本。

风格一致性的核心在于正交性原则，即各个模块应独立处理自己的职责，减少彼此间的耦合。通过保持架构风格的一致性，系统可以更好地实现模块化和松耦合，这不仅有助于当前的开发，还为未来的扩展打下了基础。

需要注意的是，架构风格并非一成不变。随着技术的发展和业务需求的变化，架构风格也会不断演化。因此，架构师应当通过文档化的方式，确保风格的一致性能够在团队内传播和延续。文档不仅是风格的记录，更是团队成员在开发过程中保持一致的指南。

2 解决方案一致性：统一的实现方式

2.1 为什么解决方案需要一致？

风格一致性更多体现在宏观的架构层面，而解决方案一致性则体现在系统具体实现的细节中。解决方案的一致性要求在同一系统中，开发者应使用相同的技术栈、设计模式和实现方式，以避免由于不同方案混用而导致的系统复杂性。

举例来说，假设在一个大型系统中，某些模块使用了Node.js和Express作为后端技术栈，而其他模块则使用了Java和Spring Boot。这种不一致的解决方案会导致以下问题：

  • 开发效率低下：Node.js 和 Java 的编程范式截然不同，前者是 JavaScript 的异步、事件驱动模型，后者则是 Java 的多线程模型。开发者在不同模块之间切换时，需要调整思维方式和适应不同的编程风格。这种上下文切换会降低开发效率，尤其是在跨模块协作时。

  • 技术债务增加：两种技术栈在依赖管理、错误处理、性能调优等方面有着不同的最佳实践。团队需要为每个技术栈制定不同的管理策略，这可能导致技术债务的积累。例如，Node.js 的异步编程需要处理回调或 Promise 链，而 Java 则更多依赖传统的 try-catch 机制。如果开发团队未能统一错误处理方式，后续的维护工作将变得更加复杂。

  • 测试和部署复杂化：不同技术栈会导致不同的测试和部署工具链。例如，Node.js 项目可能使用 Jest 或 Mocha 进行测试，而 Java 项目则依赖 JUnit 或 TestNG。在部署阶段，Node.js 通常使用 npm 来管理依赖并构建项目，而 Java 则依赖 Maven 或 Gradle。这意味着，CI/CD 流水线需要针对不同的模块配置不同的工具链，增加了自动化部署的复杂性。

  • 团队协作障碍：团队中的开发者可能对某一种技术栈更加熟悉。如果团队成员分工不明确，或者需要在不同技术栈的模块间协作时，可能会遇到技能鸿沟。例如，擅长 Java 的开发者在接手 Node.js 代码时可能不熟悉 JavaScript 的异步处理方式，导致 Bug 频发或进度延迟。反之亦然。

相反，通过保持解决方案的一致性——例如，统一选择使用Java + Spring Boot或Node.js + Express作为后端技术栈——可以确保团队在开发、测试和部署的各个阶段都能使用一致的工具和框架。这样不仅降低了学习成本和上下文切换的负担，还使得团队在协作时更具一致性。测试和部署流程也可以标准化，开发者能够更加专注于核心业务逻辑的实现，从而提高整体开发效率和系统的可维护性。

2.2 如何实现解决方案一致性？

为了实现解决方案一致性，我们需要采取一系列技术和管理上的措施，确保团队在开发过程中能够遵循统一的标准和原则。以下是我们在实际工作中常用的一些的策略和实践：

2.2.1 建立统一的架构原则和技术规范

在项目启动或架构设计的早期，架构师或技术负责人需要制定明确的架构原则和技术规范，并确保团队中的所有成员都理解并遵守这些规范。具体措施包括：

  • 制定技术选型指南：明确系统中使用的核心技术栈（如数据库访问技术、缓存管理、消息传递机制等）。例如，团队可以决定在整个项目中统一使用Spring Data JPA作为ORM解决方案，而不允许直接使用原生SQL或其他ORM框架。这种技术选型需要根据系统的需求和团队的技能水平做出合理的决策。

  • 定义设计模式的应用场景：对于常见的问题，架构师应当指定适当的设计模式。例如，规定在服务层使用策略模式（Strategy Pattern）来处理不同的业务逻辑，而不是让开发者随意选择不同的模式或技术实现。

  • 确定编程规范与代码风格：统一的代码风格不仅能提高代码的可读性，还能增强代码的一致性。通过制定编码规范（如命名规则、注释风格、格式化规则等），并在代码中使用一致的编程风格，可以避免因风格差异导致的困惑和误解。

  • 文档化架构决策：对于每一个重要的架构和技术决策，都要形成文档。这份文档不仅是为了当前的团队成员，也是为了以后加入的开发者能够快速了解并遵循既定的架构规范。

2.2.2 使用代码模板和生成工具

代码模板和生成工具可以帮助团队在技术实现上保持一致性。通过提供预先定义好的代码模板，开发者可以快速生成符合架构规范的代码，避免了手动编写过程中出现的风格不一致问题。具体措施包括：

  • 使用框架提供的代码生成工具：如 beego 框架的  bee generate 。

  • 创建内部代码模板：团队可以根据项目的实际需求，创建一系列内部的代码模板。这些模板可能包括控制器、服务层、数据访问层的标准实现，确保每个模块的代码结构一致。

  • 自动化配置管理：对于基础设施的配置（如数据库连接、日志管理、安全配置等），可以使用框架中的自动化工具或约定优于配置原则，减少开发者手动调整配置的需求，从而保证一致性。

2.2.3 落实 Code Review

Code Review 是确保解决方案一致性的有效手段之一。通过固定的代码审查机制，以及定期的代码评审，团队可以及时发现并纠正不一致的实现方式，确保整个系统遵循统一的设计和技术规范。具体措施包括：

  • 建立严格的代码审查流程：每个开发者在提交代码前，必须经过团队的代码审查。审查的重点除了代码质量之外，还应包括检查代码是否符合项目的架构规范、是否使用了统一的技术栈和设计模式。

  • 引入静态代码分析工具：使用静态代码分析工具（如SonarQube、Checkstyle等）可以自动检测代码中的不一致问题，包括代码风格、架构违规、潜在的错误等。这种工具能够根据预先定义的规则对代码进行检查，并在问题出现时发出警告，帮助开发者在早期修复问题。

  • 定期的架构评审：架构评审是对整个系统架构设计及实现进行统一检查的活动。在架构评审中，团队可以讨论当前的架构是否依然适用，是否有新的技术或模式需要引入，以及现有的解决方案是否一致。通过架构评审，还可以确保整个系统的技术决策继续符合既定的架构原则。

2.2.4 保持团队的沟通与协作

解决方案一致性不仅仅依赖于技术选型和工具，它也需要团队成员之间的高效沟通和协作。团队中的每个人都应该理解和认同一致性原则，并遵循这些原则进行开发。具体措施包括：

  • 定期技术分享与培训：为了确保所有开发人员对系统的架构和技术栈有深入理解，团队可以定期组织技术分享会或培训，帮助开发者熟悉统一的解决方案和设计模式。例如，可以安排关于如何正确使用Spring Data JPA的培训，确保每个开发者都能使用该技术栈的一致实现方式。

  • 建立架构讨论机制：在遇到复杂的技术问题或不确定的实现方式时，开发者应及时与架构师或其他团队成员进行讨论，而不应各自为战。这种持续的沟通有助于避免不一致的解决方案和技术决策。

  • 跨团队协作：在大型项目中，可能会有多个团队同时开发不同模块。在这种情况下，跨团队的技术交流和协作至关重要。团队间的定期同步会议、共享架构文档和技术决策，都有助于确保各个团队在技术实现上的一致性。

2.2.5 标准化的工具链与 CI/CD 流程

工具链和自动化流程的标准化是实现解决方案一致性的另一个关键因素。通过使用相同的开发工具、CI/CD 流程和部署工具，团队可以在从开发到发布的各个环节保持一致性。具体措施包括：

  • 统一的开发环境：为所有开发者提供标准化的开发环境。例如，通过 Docker 容器提供统一的开发环境，确保每个开发者在本地的开发环境与生产环境一致，从而避免由于不同环境配置导致的实现差异。

  • 标准化的CI/CD流程：在 CI 和 CD 中，使用统一的流水线和自动化测试，确保每次代码提交都经过相同的测试和质量检查流程。例如，可以在 CI 管道中集成代码质量检查、单元测试和集成测试工具，确保每个模块都通过相同的验证过程，避免出现质量参差不齐的代码。

  • 统一的发布和部署策略：通过标准化的部署工具（如Kubernetes、Docker Compose等）和配置管理工具（如Ansible、Terraform等），确保系统在不同环境中的部署过程一致，这样可以避免因不同的部署方式导致的运行时错误和不兼容问题。

2.2.6 逐步消除遗留系统中的不一致

在大型项目中，遗留系统中往往会存在解决方案不一致的情况。为了实现解决方案一致性，团队需要有计划地逐步消除这些不一致的问题。具体措施包括：

  • 逐步替换不一致的技术栈：对于遗留的模块，如果存在与当前技术栈不一致的实现方式，可以通过重构或替换的方式，将不一致的部分替换掉。例如，将原先使用的手写 SQL 查询逐步替换为统一的ORM框架。

  • 分阶段的技术债务清理：技术债务的积累往往是导致解决方案不一致的主要原因之一。团队应定期对系统中的技术债务进行评估，并分阶段清理那些导致解决方案不一致的部分。通过持续的技术债务清理，确保系统在长期演进中保持一致性和可维护性。

解决方案一致性是软件系统成功的关键之一，它不仅可以降低系统的复杂性，还能提升团队的协作效率和系统的可维护性。通过制定明确的架构原则、使用统一的技术栈、引入代码审查机制、保持团队的沟通协作，以及标准化工具链和 CI/CD 流程，团队可以有效地实现解决方案的一致性。

在一个长期演进的系统中，解决方案的一致性有助于减少技术债务，避免「架构腐化」，让系统在面对不断变化的需求时依然保持灵活性和可扩展性。通过这些实践，团队能够构建出更加可靠、易于维护的系统，并为未来的扩展提供坚实的基础。

3 形式一致性

形式一致性是指系统设计中各个部分的结构、风格、和实现方式在形式上保持统一和协调。它不仅仅体现在代码的外观和风格上，还包括系统在设计原则、接口定义、组件交互方式等方面的统一性。形式一致性确保了系统的各个模块之间能够无缝协作，减少了理解和维护的困难，并使得系统更加易于扩展和演进。

形式一致性要求设计者在系统的各个层次上都遵循同样的简约和清晰原则，确保每个模块的设计具有相同的模式和风格。例如，系统中所有 API 的命名规则、参数传递方式和返回结构都应保持一致，这样开发者只需学习一次，便能理解和使用所有接口。在前端设计时，所有的用户界面组件应遵循统一的界面规范和交互逻辑，以确保用户在不同模块之间切换时能够获得相同的用户体验。

3.1 简约

在形式一致性中，简约意味着设计需要尽可能地去除冗余，确保每个组件都是必要的、功能明确的。

简约不仅意味着少量的代码或元素，还意味着减少不必要的复杂性。通过使用更少的元素来完成更多的功能，简约的设计不仅减少了开发和维护的成本，还提升了系统的可预测性和稳定性。

在简约的系统中，开发者能够快速理解每个模块的设计意图，并能够在不增加复杂性的前提下对系统进行扩展。

3.2 结构清晰

结构清晰是形式一致性的重要组成部分。它要求系统的设计逻辑应该是直截了当的，模块的职责和功能应该易于理解。每个模块都应具备独立的功能，且模块间的依赖关系应当保持最小化。

结构清晰的系统不仅让开发者能够快速掌握系统的整体架构，还能轻松推测出其他模块的设计方式。在一个结构清晰的系统中，开发者不必反复查阅文档或进行复杂的调试，因为模块的设计和交互逻辑都是一致且直观的。

如在一个微服务架构中，假设我们有一个用户管理服务和订单服务。为了保持结构清晰，这两个服务应该各自负责单一的职责：用户管理服务处理用户注册、登录、个人信息管理等，订单服务则负责订单的创建、支付以及状态管理。这两个服务之间通过 API 进行通信，并且彼此独立，避免了不必要的耦合。如果将用户信息直接嵌入到订单服务中，会导致结构复杂化，增加了理解和维护的难度。通过保持清晰的模块划分，开发者可以很容易地理解每个服务的职责，并在系统发生变化时轻松进行调整。

3.3 隐喻

隐喻是系统设计中提升可理解性的重要工具。通过使用简单易懂、与现实世界或常见概念相类比的隐喻，开发者能够更快速地理解系统的设计意图。隐喻的使用不仅让系统的架构更具亲和力，还减少了开发者的认知负担。

在形式一致性中，隐喻的应用应当贯穿整个系统——无论是从命名到设计模式，还是从接口定义到用户交互，都应当遵循同样的隐喻理念。

如在构建文件系统时，使用「文件和文件夹」的隐喻可以帮助开发者和用户更好地理解系统的组织结构。现实生活中，人们处理物理文件和文件夹的经验非常直观——文件夹用于存放文件，文件可以被打开、编辑、删除或移动。将这种现实生活中的概念引入到计算机系统中，使用户和开发者能够迅速理解系统的操作模型。

通过这种隐喻，用户不需要理解系统背后的复杂实现逻辑，就能够基于现实世界中的经验快速掌握系统的使用方式。同时，开发者在设计时也能够遵循这一隐喻，确保系统结构和操作符合人们的认知习惯，提升了系统的可用性和可维护性。

4 小结

系统架构设计的本质在于持续演进，而一致性则是这种演进过程中不可或缺的基石。

风格、解决方案、形式上的一致性不仅能够减少开发者的认知负担，还能为系统的扩展和维护提供有力的支持。一个具有一致性的系统，往往更具可预测性、更易于理解，并且能够在面对复杂的业务需求和技术变革时保持灵活性与稳健性。

正如 Fred Brooks 所言，一致性不仅是质量的根基，也是系统能够在复杂环境中持续演进的保证。通过在架构设计中贯彻一致性原则，我们不仅在解决当前的问题，更是在为未来的变革与创新铺平道路。

以上。