亲历者复盘：快手前端工程质量诊断平台建设与演进之路

导读：本文以快手天守平台核心建设者视角，系统梳理了大规模前端工程质量保障体系的演进路径。通过解构其分层架构设计、分布式调度引擎等关键技术组件，深度剖析平台在应对亿级DAU场景下的工程实践，为行业提供可借鉴的质量保障体系建设范式。

​

​

即使你的工厂被拆除了，只要它的精神还在，你就能很快重新建立起另一家。如果一场革命摧毁了旧政府，但新政府思想和行为的系统模式没有变化，它就仍然难逃再次被推翻的命运。关于系统，我们很多人经常挂在嘴上，但几乎没有多少人真正理解。

——罗伯特·波西格《禅与摩托车维修艺术》

​

「天守」是快手主站技术部孵化出的前端工程质量诊断平台（下文简称”天守“），在快手前端技术演进过程中扮演了关键角色。到 24 年末，天守圆满完成了其历史阶段性使命，携手商业化部门升级为「青鸾」平台 ——一个面向快手大前端体系度量诊断领域的、公司通道级白盒化解决方案。

​

在这新老交替之际，作为一线实践者，我愿与大家共同回顾天守的建设历程。回答一个最关键的问题：“天守，在守护什么？”本文将分为三部分展开：场景背景、设计思考与实践总结。常言道“凡夫畏果，菩萨畏因”，所有「结果」都深植于「原因」之中，因此前半部分的论证铺陈尤为重要，而后端的设计实现更多是水到渠成。

​

在行文风格上，我尝试采用更开放的姿态，与诸位同行展开一场深度对话，我们将探讨快手在平台建设过程中的设计思考与决策权衡，并坦诚剖析其中的经验得失。期望通过这样的分享，能激发更多思考与启示，促进交流探讨，让我们在技术探索的道路上并肩前行。

​

Part1：Context（场景）

理论基础

程序员的价值维度

​

——“作为软件系统的研发人员，我们到底在做什么？我们的价值何在？”

​

程序员的日常工作，可以概括为面向两个价值维度 —— 行为价值和架构价值。

• 行为价值：​第一个维度行为价值比较直观，研发的工作就是让计算机按照某种指定方式运转，给用户提效、创造收益。为达成这个目的，需要产品经理给出需求文档，然后将其转换为实际的代码。大部分研发认为这就是我们的全部工作，我们的工作是且仅是：按照需求文档编写代码，并且修复相关 Bug。大错特错！
• 架构价值：第二个维度是架构价值，主要体现在「软件 software」 这个词上："ware" 指产品本身，而 "soft" 指软件的灵活性。即软件必须保持灵活性，即易于修改、演进。

​

哪个价值维度更重要呢？答案是：架构价值维度，只有易于修改，才能让程序持续产生价值。

​

代码即架构

​

——“架构是一个挺大的词，而我仅仅是一个一线研发。谈架构，我配吗？”

​

我始终相信一个观点：“代码即架构”。架构与代码设计没有本质区别，架构即设计决定的集合。

软件架构是系统设计过程中的重要设计决定的集合，可以通过变更成本来衡量每个设计决定的重要程度。—— 《架构整洁之道》

​

顺便提一下，书中也揭示了所有 “大泥球” 系统的成因：持续低估那些好的、良好设计的、整洁的代码的重要性。

​

因此，从本质上讲，思考如何编写优雅、易读代码的思维过程，与进行系统架构设计的决策过程，二者并无二致。它们都蕴含着对结构、逻辑、可读性、可维护性等多方面的深度考量，都需要以严谨的态度、长远的目光，从宏观到微观对每一处细节进行雕琢，力求打造出兼具高效与美感的产物。

​

软件设计复杂之根因 —— 变化

​

——“感觉设计挺完美的、也开发完了，产品又双叒叕改需求了！咋办呀？”

​

软件设计之所以复杂、难搞，根本原因因在于「变化」—— 客户需求的变化、技术平台的变化、开发团队的变化、市场环境的变化......「变化」是「复用」的天敌；一切都在变化，唯一不变的就是变化本身。

​

不变只是愿望，变化才是永恒。There is nothing in this world constant but inconstancy。——《人月神话》

​

编程的本质其实也是对复杂度的管理，无论是自顶向下的结构化分解思维，还是自底向上的面向对象抽象设计，无非是我们抵御变化的手段。

​

架构特征：什么是 “重要的东西”

​

——“面对外界环境及架构内涵的快速变化，有什么是不变的（准确点说是相对稳定的）？如何抓住这些 ‘常量’，作为架构演进之船的压舱石？”

​

在设计系统架构时，我们除了考虑产品的功能需求，也关注一些非功能需求，如可用性、一致性、安全性、可维护性等。

​

然而，许多因素是互相矛盾的，比如我们常常为了提升性能，而一定程度上牺牲代码的可维护性；再比如根据 CAP 理论，在分布式场景下，我们必须在可用性与一致性之间做出取舍。

​

作为架构设计者，我们的职责就是在变化中找到 「重要的东西（whatever it is）」 。本文中我们将那些「重要的东西」定义为 「架构特征」。架构特征也就是大家常说的各种 「-abilities」 —— Usability、Accessibility、Flexibility、Extensibility、Customizability、Scalability、Reliability、Localizability、Testability、Measurability、Maintainability 等。

​

​

架构设计者需要理解并权衡这些特征，并不断的重新思考架构随时间的推移要如何变化，以及当这样的演进发生时，如何保护重要的架构特征。

​

质量模型与度量函数

​

——“理清了我们最重要的架构特征之后，如何防止架构特征出现磨损？如何避免架构比特衰减？”

​

随着时间推移、技术发展、业务需求变更以及系统的不断迭代维护等因素影响，架构原本设计的完整性、合理性、高效性等特性会逐渐降低或变差。为了防护系统演进各种架构特征磨损，我们引入了两个核心概念：「质量模型」和「度量函数」。

​

​

理解质量模型

由于业务驱动、技术能力及团队阵型等，组织对项目的需求会有较大区别：有些项目要求很高的安全性，有些要求高性能，还有一些要求更好的可用性或故障恢复能力。这些考量形成了架构师所关心的架构特征，从概念上来讲，质量模型体现了系统架构特征的保护机制。

​

很多时候架构师在调和对立力量时，会为权衡犯难，比如在一致性和可用性之间做出取舍。事实上，对架构师而言比较这些不同的特征是永恒的难题，因为它们从根本上是不同的，并且所有利益相关者都认为自己所关心的特征最为重要。

​

质量模型允许架构师通过统一的机制思考不同的问题，捕捉和保留重要的架构特征；同时，架构师可以判断度量函数的重要程度，为其分配权重。

​

关于质量模型的原型出自ISO/IEC 25010：https://www.iso.org/standard/78175.html，如下图所示。

​

理解度量函数

大家都知道函数的定义——输入、处理、输出。在本文中，「度量函数」输入工程或系统的关键信息，经过一组计算过程，输出衡量工程质量的指标。

​

如圈复杂度作为常用的代码衡量指标，用来衡量函数或方法的复杂度。我们可以自动在 CI 环节通过 lint 工具遍历 AST 中带有条件分支语意的 Statement 和 Expression 来采集指标。

​

当然，也有无法自动化的，如千行代码 BUG 率，需要统计代码的变更行数、本次变更关联的 BUG 数量，然后根据合适的阈值来计算该指标。

​

① 度量函数的分类

​

度量函数有很多不同的分类方式，可以依据其范围、使用频率、动态性及其他因素对其进行分类，必要时还可以对不同分类进行组合。

​

​

② 尽早确定度量函数

​

团队应尽早确定度量函数，作为初步理解全局架构关注点的一部分。比较不同架构特征（质量模型及其度量函数）的价值和难度，有助于更早地设定高风险工作的优先级，做出能够应对变化的设计。

​

反之，可能面临风险：做出的设计选型在时间和成本上出现不必要的浪费；系统无法轻松应对日后的环境变化。

​

③ 审查度量函数

​

度量函数审查以 TC 评审的形式进行，会上主要业务和技术利益相关者一起讨论如何修改度量函数以满足设计目标。审查大致涉及如下几点 ：

• 审查已有的度量函数；
• 审查当前度量函数的范围；
• 确定是否有更好的方法测量系统的度量函数；
• 发现系统可能需要支持的新的度量函数；
• 定期审查度量函数，比如每年至少一次。

​

机制保障：DMAIC 模型

——“在具备充分的理论依据后，是否能够凭借有效的机制切实将质量模型落地，从而正确引导系统演进？”

​

关于如何落地，这里包含两个关键问题：其一，在持续变化的环境中，怎样长效确保系统于演进期间始终维持良好的质量水准；其二，在系统完成交付或者改造之后，又该如何避免其逐步走向退化呢？

​

对此，我们引入了「DMAIC 模型」：https://asq.org/quality-resources/dmaic

​

DMAIC 模型是 Six Sigma 质量管理体系的核心工具之一，用于解决问题和改进流程的方法；DMAIC是一个缩写词，代表了五个阶段：定义（Define）、测量（Measure）、分析（Analyze）、改进（Improve）和控制（Control）。

​

​

那么，天守平台作为 DMAIC 具像化实现，究竟是如何构炼成的呢？下面我们将聊聊这一段有关天守平台诞生之前的前尘往事。

​

历史故事

遗留系统改造

在刚接手业务与研发中台团队之际，我针对业务范围、客户群体、上下游关联以及协作方展开了一次全面的梳理与盘点，在此过程中，一些棘手的问题逐渐浮出水面：

​

1、诸如用户中台、消息中台以及地理位置中台等系统存在极为严重的历史遗留问题，大量的功能实现杂乱无章，致使系统的迭代优化与日常维护工作举步维艰，几乎陷入僵局。

​

2、与之对应的业务开展由于技术团队的不给力而受到严重阻碍，业务需求的交付不仅进度缓慢，而且在质量把控与系统稳定性方面也面临着诸多严峻考验。与此同时，上级领导与业务部门均对这些问题的根本性解决寄予了颇高的期望，期望能够彻底扭转当前的不利局面。

​

3、团队内部人员的主动流失现象，这无疑给团队的稳定性与持续性发展带来了极大的冲击。

​

依据过往积累的实践经验来判断，当前所面临的这些困境归根结底属于技术债务范畴，亟待开展系统性的治理工作。

​

于是，我迅速组建了一支 “外科手术式” 的专业攻坚队伍，决定率先对问题最为突出的用户中心这块 “重灾区” 进行集中整治与优化。

​

1. 问题：系统老旧、债务严重。

​

2. 思路

（1）关键词：巨无霸单体解耦、绞杀者模式、防腐层（Anti-Corruption Layer）

（2）策略：

• 由大到小，由粗到细
• 关注监控，快速反馈
• 循序渐进，增量实现

​

3.方案

（1）建设新城区

• 拆分：划分子系统，Fork 到新建代码仓库，梳理程序中各个模块之间的关系和依赖，保证每个子系统能独立运行。
• 适配：建立 ACL（防腐层、或适配器），保证对外接口不变：对于业务方，页面地址、包名称、调用方法等；对于后端，接口、字段、数据结构等。
• 改造：优化内部结构，采用重构或重写的方式变更模块、组件等，具体采用哪种方式视场景而定。

（2）疏散老城区

• 摸底：部署监控，排查所有消费者（业务方），确定影响范围，更新旧接口、下线老页面、收敛版本，逐步渗透。
• 灰度：让新老系统在一定的时间段内共存，使遗留系统能够平滑的迁移到新的技术架构。
• 兜底：能在部署后发现异常时快速的切换回老系统，使迁移风险降到了最低。

​

4.执行节奏

​

​

以上问题的处理过程或解决路径总体上比较常规且脉络清晰，然而，在推进中仍遗留了两个关键问题亟待解决（常被挑战、难以自证）：

​

1、整个治理流程主要依赖于个人经验的主观判断与人为操作，尚未建立起一套明确且具有量化指标的规范体系来加以引导与约束，呈现出明显的 “人治” 特征而非 “法治” 模式；

​

2、对于后续如何有效防止问题的再次恶化与劣化，同样过度依赖于人员的自觉与手动干预，缺乏一套长效的、具有制度性保障的机制来确保问题不会死灰复燃，从而无法从根本上为系统的持续稳定运行提供坚实的保障。

​​

并非个例（I'm Not Alone）

​

架构升级、债务治理、防劣化也好，很难说清，怎么办？

后来借着各种会议的机会，和大家深入交流债务治理、架构升级的经验时，我才发现面临上述两个问题的并非我一人，I'm not alone！

​​除了在治理决策方面过度依赖个人经验，且后续防劣化环节也仅仅仰仗人员的自觉性与手动操作之外，还存在一系列亟待解决的问题：

​

1、团队成员业务水平参差不齐，直接致使在工程与代码质量的度量标准上难以达成统一共识，缺乏一致性的评判尺度。

​

2、在技术债务治理方面投入了大量人力，然而其实际效果却难以进行精准衡量与评估，无法确切知晓人力投入与产出效益之间的量化关系。

​

3、各团队在技术债务处理进程中，相关操作与进展无法实现量化呈现，众多行之有效的最佳实践仅仅零散地分布于各自的文档库中，难以开展集中化的管控工作，更无法在不同团队之间进行横向的比较与分析。

​

针对以上困境的解题思路：“白盒化与统一标准” 。其核心在于将原本处于中间环节、不可见的部分予以透明化处理，使其能够被清晰地观察、精准地度量，进而为全面、系统地解决技术债务问题，也能为系统演进提供长效保障。

​​

天守：白盒化与统一标准

名字的由来

“天守”一词源自一款手残游戏《只狼：影逝二度》的著名景点 “苇名城天守阁”，作为军事要塞，具有瞭望、指挥、防御的功能。

​

一句话描述

天守是面向快手前端工程架构改进与债务治理的白盒化解决方案，围绕项目的可维护性、可靠性、工程规范性、安全性等维度提供问题识别、数字化度量、改进建议与门控能力。

​

典型应用场景

工程架构改进、技术债务治理、合规性治理、技术规范落地推动与运营、重构决策依据。

​

​

​

Part2:Design（设计）

​

质量模型设计

​

什么是质量模型

回顾上一章中我们对质量模型的定义，「质量模型」与「架构特征」对应，为某些架构特征（安全性、可维护性、可靠性等）提供了客观的完整性评估，由一组带权重的指标所组成。

​

参考业界方案

ISO/IEC 对于工程质量提供了一套评价框架和抽象解法， 包括功能适用性、性能效率、兼容性、可用性、可靠性、安全性、维护性和可移植性，每个属性进一步细分为多个子属性。详细定义见ISO/IEC 25010：https://www.iso.org/standard/78175.html

​

本地化设计

回到快手前端工程场景，我们对于系统演进中最关注的架构特征：代码可维护性、工程规范化程度、系统可靠性和安全性。

​

因此，我们做了一些本地化改造，去掉功能适用性、可移植性等，增加 CDN 容灾、监控配置完善度等符合前端研发规范的度量维度。

​

版本升级 ——「四维八方」

为了深化基建能力与影响力，优化单领域内的基建项目人力投入，避免重复建设和资源浪费，通道层面希望建设公司工程度量领域下的标准解决方案。

​

因此，我们决定与商业化部门共建、品牌升级，同时质量模型也升级为 “四维八方”。

​

统一与定制

如前文所述，对于「度量函数」的使用，可以依据其范围、使用频率、动态性及其他因素对其进行分类，必要时还可以对不同类别进行组合。

​

因此，鉴于业务导向、技术水准以及团队结构等多方面因素的综合作用，组织对项目的需求会有较大差异；质量模型既支持团队视角的标准统一质量模型，也支持个人用户针对临时、或特定场景通过组合度量函数定制质量模型。

度量函数设计

​

什么是度量函数​

回顾上一章中我们对度量函数的定义，「度量函数」输入工程或系统的关键信息，经过一组计算过程，输出衡量工程质量的指标。

​

功能需求：

• 输入：项目元信息、代码源文件、构建产物
• 输出：工程评分、问题列表、优化建议等

​

谁来贡献/开发度量函数？

关于度量函数的提供者问题，在平台建设之初，我们经历了长期访谈、调研；最终决定将主权赋予用户自身，由用户自行开发、自行测试、自行发布、集成测试，并独立完成工程质量的度量。

​

因此，在形态上，我们需要提供开放型生态体系；在架构上，采用微内核架构设计，达成松散耦合的效果；设计原则上，遵循依赖倒置原则，即依赖稳固且标准的开放接口协议，而非依赖度量函数内部的具体实现细节。事实上，天守平台建设至今 50% 左右的度量函数来自于大家共建。

​

非功能需求：开放生态、接口协议简洁易读、可测试性。

微内核设计

• 微内核架构、可插拔
• 度量函数插件独立、插件间无耦合、可灵活编排
• 单一职责、原子化
• 纯函数、无副作用
• 发布复用等同原则

接口协议设计

import { BaseScanner, type Issue, type ScanOptions } from '@sky-dmaic/core'

export default YourScanner extends BaseScanner { 
    scan(options: ScanOptions): Promise<Issue[]> | Issue[] { 
        const issueList: Issue[] = [];
        // TODO: 你的检测执行过程
        return issueList; // 问题列表
    }

    calculate(issueList: Issue[], options: ScanOptions): number {
        // TODO：你扣分计算逻辑[0, 100]
        return 0;
    }

    suggest(issueList: Issue[], negativeScore: number): string {
        // TODO：你的优化建议
        return'你的优化建议';
    }
}

​

​

系统架构设计

关于系统架构设计

Q：什么是系统架构？

A：一个系统的架构是由一系列软件组件以及它们之间的边界共同定义的。架构设计本身就是一门划分边界的艺术，边界的作用是将软件分割成各种元素，以便约束边界两侧之间的依赖关系。

​

Q：为什么需要架构设计？

A：我们需要先了解一个系统最消耗人力资源的是什么？答案：耦合，尤其是那些过早做出的、不成熟的决策所导致的耦合。因此，合理的架构设计决定了我们能否在多人协作中避免掉入不当耦合、功能蠕变、过度设计等陷阱，更好的拥抱未来变化。

​

软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求——《Clean Architecture》

​

Q：那什么是过早且不成熟设计决策呢？

A：实现细节。比如我们要采用的框架、数据库、Web 服务器、工具库等。一个设计良好的系统架构不应该依赖于这些细节，而应该尽可能地推迟这些细节性的决策。因此，在项目初期划分边界的目的是方便我们尽量将这些决策延后，并且确保未来这些决策不会对系统的核心业务逻辑产生干扰。

​

Q：什么是好的架构设计？

A：一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该成本很低，并且在系统的整个生命周期内一直都能维持这样的低成本，那么这个系统的设计就是优良的。如果该系统的每次发布都会提升下一次变更的成本，那么这个设计就是不好的。就这么简单。——《Clean Architecture》

​

天守的用户故事

在开始编码之前，让我们先用户故事公式分析一下我们的核心诉求是什么，以便我们作出良好、清晰的设计决策。

​

用户故事公式：As a <Role>, I want to <Activity>, so that <Business Value>.

​

Web 界面

作为一名用户，我期望拥有一个展示工程信息的区域，能够自主选择质量模型以触发检测流程，并可以便捷地查看检测结果，如此一来，便能轻松知晓工程的质量状况。

​

度量函数插件

作为用户的我，我希望通过一段特定的计算流程，以便依据工程信息精准剖析出质量问题。

​

任务调度引擎

每当一次质量检测启动时，会涉及数十个相互独立的度量函数需要执行。此时，作为一个用户，有必要依据集群资源状况来选定适宜的策略，对任务进行调度并合理安排优先级，从而避免长时间等待或资源的无端浪费。

​

服务端

作为平台用户，我需要一个专门的服务提供组件，能够对用户权限、质量模型配置以及检测结果多维度筛选等服务进行集中化管理。

​

数据库

作为平台用户，我需要持久化存储三类数据，即集群资源状态、质量模型与目标工程配置以及工程检测结果指标，以此确保在系统遭遇故障时，数据得以完好保存而不致丢失。

​

架构大图

​

调度引擎设计

需求分析

1. 功能需求：度量函数的高并发、长任务、IO 密集等特性，且允许灵活组合。为了何合理利用内存和 CPU 资源，避免资源争抢引发延迟或饥饿，我们需要调度引擎有序分配资源、提升效率、避免浪费。

2. 非功能需求：高可用、可水平扩展。

3. 设计思路：

• 天守平台任务调度引擎参考了 K8S 架构设计，遵循声明式设计范式，副作用小、高可用、避免不良依赖透传等反模式。
• 声明式设计：通过描述期望状态来管理资源的方式，用户不需要详细说明如何达到某个状态，而是只需要声明想要的最终状态。

架构分层

1. 用户接入层

• 流水线插件（Pipeline Plugin）
• Web 界面（Web UI）
• 命令行工具（CLI）

2. 控制层

• API 服务器（API Sever）：整个系统的通信核心，作为「桥梁」；处理内部请求（控制层、工作层）和外部请求（用户接入层）。
• 任务控制器（Task Controller）：管理系统整体状态，如工创建工作节点、节点回收等；接受请求，管理任务列表。
• 任务调度器（Task Scheduler）：封装调度算法，根据现有资源状态、任务运行情况，将预定的任务，派发给「空闲」的工作节点。
• Database：负责存储工作节点的运行状态、任务执行状态、任务执行结果、时间等关键信息，不保存业务指标信息。

3. 工作层

• 工作节点（Worker Node）：接受任务，并完成任务执行流程。

​

​

任务执行流​

执行流程详述如下：

1、用户发起一次代码分析（比如 3 个 scan tasks，1 个 compute task），API Server 接受请求；

2、Controller 接到通知，根据​请求内容，在任务列表中添加 4 个任务；

3、Scheduler 接受通知，遍历任务列表，根据当前资源状况、任务之间的依赖关系，结合调度算法，将任务调度到具体 Worker Node。

4、Worker Node 中的 Task Receiver 接收到任务，创建一个进程，作为 Task Runner。

任务调度算法

一句话简述：让优先 Ready 的任务，调度到最空闲的 Worker 节点。

​

1、 当 Controller 接到通知，解析用户 Request，并创建 Tasks，每个 Task 维护自己的依赖任务列表 Deps。

2、Scheduler 接到任务通知，查询 Worker Node 状态，发现有 N 个可用节点；从前往后遍历任Task List，找到前 N 个可执行的任务；依次调度到可用节点，完成一次任务调度。

3、当一个任务执行完成，Worker Node 通过 Tasker Reciever 完成上报，并 destroy Task Runner 进程；Controller 接收到通知，更新 Task Queue 和 Worker Node states。

小结

1. WorkerNode 节点在高并发时可以水平扩展，无需任何代码变更。

​

2. 遵循声明式设计范式：用户向平台 claim 一份任务 manifest，集群定期检测任务状态，如果发现没有达到期望，就去 fulfil 这份期望。与命令式的实现方式相比：命令式操作在简单场景下可能很有效，但在复杂的分布式系统中，尤其是面对动态变化的环境和大量的资源时，就会变得非常复杂和难以管理。声明式设计则更具优势，它允许用户集中精力在期望的最终结果上，而系统会负责根据当前状态和期望状态之间的差异进行自动协调和调整。例如，当一个节点出现故障，调度引擎会自动根据声明的副本数在其他健康节点上重新调度容器，以维持期望的状态。

​

3. 调度算法与集群控制节点正交、隔离、独立演进。为后来控制逻辑切换（消息中间件从野生 Redis 替换为公司的统一的 Kafka）、调度算法优化（增加重试逻辑、超时状态、调整任务节点之间的依赖关系图等）提供了便利。

​

Part 3:Summary（得与失）

天守之得

1. 做好原型设计：一个以保障系统可演进性为使命的系统，倘若自身缺失演进的能力，这着实难以令人信服。值得庆幸的是，在早期的系统原型设计阶段，我们团队花了一些功夫。也正因如此，即便在后续的演进中历经了频繁的功能更迭、调度算法升级甚至底层消息中间件替换等各种挑战，该系统依然能够维持清晰的边界与鲜明的架构特征，具备良好的灵活性和可演进性。

​

做好原型设计可以帮助你避免为蝇头小利而投入过多的时间。——《UNIX 编程艺术》

​

2. 好协议产生好实践：我们有约 50% 的度量函数插件来自用户的贡献。开放生态，得益于简洁透明的接口协议设计，以及接口背后的任务调度引擎参考了 K8S 优雅的设计。

​

好的 API 应是意义清楚，不用看具体如何实现就能够理解的。对此有一个经典的测试方法：通过电话向另一个程序员描述。如果说不清楚，API很可能就是太复杂，设计太糟糕了。——《UNIX 编程艺术》

​

3. “即使你的工厂被拆除了，只要它的精神还在，你就能很快重新建立起另一家。” 正如文章开头所传达的信念一般，令人欣慰的是，即便天守在某种形式上 “消逝”，但「青鸾」平台作为其升华的 “天守 2.0 版本”，在未来的发展中，仍将传承天守的核心特质与思想脉络，使其仿佛以另一种姿态继续存在，让天守的影子得以延续，续写其未竟的使命。

​

天守之失

1. 任务调度引擎有一处设计不够 pure，即复杂的任务创建逻辑是在调度器内实现的。按照声明式设计思路，用户通过 Server 鉴权、查询各种配置信息后，claim 这份复杂的任务清单，如果放在调度引擎内，稍微有点 “脏乱”。能清理吗？能。但是需要现在就优化吗？不需要，最好再观察一段时间。

​

“过早优化是万恶之源” —— 《计算机程序设计艺术》。

​

2. 与公司的研发流程打通的设计决策，初期被定位为”实现细节“而延迟执行，导致后续推广落地和技术运营中遇到诸多不畅。所幸，在与商业化共建的「青鸾」平台的过程中，我们弥补了这一设计上的不足。然而，我们仍需高度警惕 “第二系统效应”的潜在风险。

​

未来已来：青鸾

正如 Brian Kernighan曾经说过的：“计算机编程的本质就是控制复杂度”。排错占用了大部分的开发时间，弄出一个拿得出手的可用系统，通常与其说出自才华横溢的设计成果，还不如说是跌跌撞撞的结果。天守演进至今，也是跌跌撞撞的结果。

​

而且，历史远未结束。天守已经蜕变为青鸾，继续成长。

​

我们都知道，未来属于 AI。在 AI 时代，继续谈论架构设计这种传统工艺、老话题，还合时宜吗？

​

借用木心的一句话回答：「老话题，老是老，话也够多，题还是题。」

​

鸣谢：前路漫漫，道阻且长。感谢曾经参与共建，以及目前依旧在参与、不离不弃的小伙伴们。