架构与设计演化：大型系统不停机现代化改造路径-育师

2026 C++ 及系统软件技术大会 · 议题前瞻
演讲嘉宾：Michael Wong（奇点智能研究院首席科学家、C++标准委员会机器学习组主席）、吴咏炜（奇点智能研究院首席技术咨询师）、李华圣（字节跳动性能优化工程师）
大会时间：2026年11月20-21日 · 北京万达文华酒店

一、现代化改造的驱动力：为什么"不能停下来重构"

大型系统（数据库、操作系统、编译器、分布式存储）的现代化改造面临"不能停"的硬约束：

金融系统：停机 1 分钟 = 数百万损失
电商平台：大促期间零停机是底线
云服务：SLA 承诺 99.99% 可用性，年停机时间 < 52 分钟
嵌入式系统：设备部署后无法远程升级，或升级成本极高

核心挑战：如何在持续服务的前提下，完成技术债务清偿、架构现代化、性能优化？

二、技术债务识别：从"凭感觉"到"数据驱动"

2.1 技术债务的多维度量

吴咏炜在系统咨询中提出的"技术债务五维模型"：

维度	度量指标	工具	健康阈值
代码债务	圈复杂度、重复代码率、注释覆盖率	SonarQube、CodeClimate	圈复杂度 < 10
架构债务	模块耦合度、循环依赖数、接口稳定性	Structure101、ArchUnit	循环依赖 = 0
测试债务	测试覆盖率、 flaky test 比例、测试执行时间	JaCoCo、pytest	覆盖率 > 80%
文档债务	API 文档完整度、架构决策记录（ADR）数	Swagger、Archbee	API 文档 100%
运维债务	部署频率、回滚时间、故障恢复时间	Prometheus、PagerDuty	回滚 < 5 分钟

2.2 代码级债务检测

// 技术债务检测示例：圈复杂度计算classCyclomaticComplexityAnalyzer{public:intcalculate(constFunctionDecl&func){intcomplexity=1;// 基础路径// 遍历 AST，统计决策点for(constauto&stmt:func.body()){if(isa<IfStmt>(stmt)||isa<WhileStmt>(stmt)||isa<ForStmt>(stmt)||isa<CaseStmt>(stmt)||isa<ConditionalOperator>(stmt)){complexity++;}// 短路逻辑运算符if(isa<BinaryOperator>(stmt)){auto*binOp=cast<BinaryOperator>(stmt);if(binOp->isLogicalOp()){complexity++;}}}returncomplexity;}DebtSeverityclassify(intcomplexity){if(complexity<=10)returnDebtSeverity::LOW;if(complexity<=20)returnDebtSeverity::MEDIUM;if(complexity<=50)returnDebtSeverity::HIGH;returnDebtSeverity::CRITICAL;}};

2.3 架构级债务检测

# 架构依赖分析：检测循环依赖和模块耦合importnetworkxasnxfromcollectionsimportdefaultdictclassArchitectureDebtAnalyzer:def__init__(self,source_dir):self.dependency_graph=nx.DiGraph()self.module_map=defaultdict(set)defanalyze(self):# 1. 构建模块依赖图forfileinself.scan_source_files():module=self.get_module(file)forincludeinself.extract_includes(file):dep_module=self.get_module_from_include(include)ifmodule!=dep_module:self.dependency_graph.add_edge(module,dep_module)# 2. 检测循环依赖cycles=list(nx.simple_cycles(self.dependency_graph))# 3. 计算模块耦合度coupling={}formoduleinself.dependency_graph.nodes():fan_in=self.dependency_graph.in_degree(module)fan_out=self.dependency_graph.out_degree(module)coupling[module]=fan_in+fan_outreturn{'cycles':cycles,'coupling':coupling,'total_modules':len(self.dependency_graph.nodes()),'total_edges':len(self.dependency_graph.edges()),}defgenerate_remediation_plan(self,max_cycles=0,max_coupling=10):"""生成技术债务清偿计划"""analysis=self.analyze()plan=[]# 优先处理循环依赖forcycleinanalysis['cycles']:plan.append({'type':'break_cycle','modules':cycle,'effort':len(cycle)*3,# 每个模块 3 人天'priority':'CRITICAL'})# 处理高耦合模块formodule,couplinginanalysis['coupling'].items():ifcoupling>max_coupling:plan.append({'type':'reduce_coupling','module':module,'current_coupling':coupling,'target_coupling':max_coupling,'effort':(coupling-max_coupling)*2,'priority':'HIGH'})returnsorted(plan,key=lambdax:x['priority'])

三、模块化拆分策略：从"大泥球"到"微内核"

3.1 拆分原则：Michael Wong 的"三边界法则"

法则一：按变更频率拆分
高频变更的模块（业务逻辑）与低频变更的模块（基础设施）分离，减少变更影响范围。

法则二：按稳定性拆分
稳定接口（已发布 API）与不稳定实现分离，保护外部依赖者。

法则三：按团队边界拆分
模块边界与团队边界对齐，减少跨团队协调成本。

3.2 拆分模式：绞杀者模式（Strangler Fig Pattern）

阶段一：识别边界 ┌─────────────────────────────────────────┐ │ 遗留单体系统 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 用户模块 │ │ 订单模块 │ │ 支付模块 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 库存模块 │ │ 物流模块 │ │ 报表模块 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────┘ 阶段二：建立 facade ┌─────────────────────────────────────────┐ │ API Gateway │ │ ┌─────────────────────────────────────┐│ │ │ 遗留单体系统 ││ │ │ ┌─────────┐ ┌─────────┐ ... ││ │ │ │ 用户模块 │ │ 订单模块 │ ││ │ │ └─────────┘ └─────────┘ ││ │ └─────────────────────────────────────┘│ └─────────────────────────────────────────┘ 阶段三：逐个替换 ┌─────────────────────────────────────────┐ │ API Gateway │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 新用户 │ │ 新订单 │ │ 遗留支付 │ │ │ │ 服务 │ │ 服务 │ │ 模块 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 遗留库存 │ │ 遗留物流 │ │ 遗留报表 │ │ │ │ 模块 │ │ 模块 │ │ 模块 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────┘ 阶段四：完成替换 ┌─────────────────────────────────────────┐ │ API Gateway │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 新用户 │ │ 新订单 │ │ 新支付 │ │ │ │ 服务 │ │ 服务 │ │ 服务 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 新库存 │ │ 新物流 │ │ 新报表 │ │ │ │ 服务 │ │ 服务 │ │ 服务 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────┘

3.3 接口稳定性保证

// 接口稳定性设计：版本化 API + 向后兼容// v1 接口（已发布，不可修改）namespaceapi_v1{structUserInfo{std::string id;std::string name;std::string email;};// 已发布的 API，签名不可变更UserInfoget_user(conststd::string&user_id);voidupdate_user(conststd::string&user_id,constUserInfo&info);}// v2 接口（新增字段，向后兼容）namespaceapi_v2{structUserInfo:api_v1::UserInfo{// 新增字段，不影响 v1 布局std::optional<std::string>phone;std::optional<std::string>avatar_url;};// 新增 APIUserInfoget_user_v2(conststd::string&user_id);// 旧 API 保留，内部转发到 v2inlineapi_v1::UserInfoget_user(conststd::string&user_id){autov2_info=get_user_v2(user_id);returnstatic_cast<api_v1::UserInfo>(v2_info);// 切片，安全}}// 适配器模式：内部实现替换不影响外部接口classUserServiceAdapter{std::unique_ptr<UserServiceImpl>impl_;public:// 接口稳定，内部实现可替换api_v1::UserInfoget_user(conststd::string&user_id){returnimpl_->get_user(user_id);}// 运行时切换实现（A/B 测试、灰度发布）voidset_impl(std::unique_ptr<UserServiceImpl>new_impl){impl_=std::move(new_impl);}};

四、依赖管理：从"依赖地狱"到"可控依赖"

4.1 依赖管理策略

策略	描述	适用场景	风险
版本锁定	精确锁定依赖版本	生产环境	安全补丁延迟
语义化版本	允许兼容版本自动升级	开发环境	破坏性变更漏入
供应商化	将依赖源码纳入项目	关键依赖	维护成本增加
抽象隔离	通过接口隔离依赖	可能变更的依赖	接口设计成本

4.2 依赖健康度检查

# 依赖健康度分析classDependencyHealthChecker:defcheck_health(self,dependency):checks={'maintenance':self.check_maintenance(dependency),'security':self.check_security(dependency),'compatibility':self.check_compatibility(dependency),'license':self.check_license(dependency),}# 综合评分score=sum(checks.values())/len(checks)return{'dependency':dependency.name,'version':dependency.version,'health_score':score,'checks':checks,'recommendation':self.generate_recommendation(score,checks)}defcheck_maintenance(self,dep):"""检查维护活跃度"""last_commit=dep.repo.last_commit_date days_since_commit=(datetime.now()-last_commit).daysifdays_since_commit<30:return1.0ifdays_since_commit<90:return0.8ifdays_since_commit<365:return0.5return0.2# 超过一年未更新defcheck_security(self,dep):"""检查安全漏洞"""vulns=dep.security_advisories critical_vulns=[vforvinvulnsifv.severity=='CRITICAL']ifnotvulns:return1.0ifnotcritical_vulns:return0.7return0.3# 存在关键漏洞defgenerate_recommendation(self,score,checks):ifscore<0.5:return"URGENT: Consider replacing this dependency"ifchecks['security']<0.5:return"HIGH: Update to fix security vulnerabilities"ifchecks['maintenance']<0.5:return"MEDIUM: Monitor for alternative solutions"return"LOW: Dependency is healthy"

五、可测试性设计：改造的前提条件

5.1 测试金字塔在系统软件中的应用

/\ / \ / E2E \ 端到端测试（少而精） /─────────\ 比例：5% / \ / Integration \ 集成测试（模块交互） /──────────────────\ 比例：15% / \ / Unit Tests \ 单元测试（核心逻辑） /──────────────────────────\ 比例：80% / \

5.2 依赖注入与测试替身

// 可测试性设计：依赖注入 + 接口抽象// 抽象接口（稳定）classIStorage{public:virtual~IStorage()=default;virtualstd::vector<uint8_t>read(conststd::string&key)=0;virtualvoidwrite(conststd::string&key,conststd::vector<uint8_t>&data)=0;};// 生产实现classS3Storage:publicIStorage{Aws::S3::S3Client client_;public:std::vector<uint8_t>read(conststd::string&key)override{// 真实的 S3 读取autooutcome=client_.GetObject(...);returnextract_data(outcome);}voidwrite(conststd::string&key,conststd::vector<uint8_t>&data)override{client_.PutObject(...);}};// 测试替身（内存实现，快速、确定性）classInMemoryStorage:publicIStorage{std::unordered_map<std::string,std::vector<uint8_t>>data_;public:std::vector<uint8_t>read(conststd::string&key)override{autoit=data_.find(key);if(it==data_.end())throwstd::runtime_error("Key not found");returnit->second;}voidwrite(conststd::string&key,conststd::vector<uint8_t>&data)override{data_[key]=data;}// 测试辅助方法voidclear(){data_.clear();}size_tsize()const{returndata_.size();}};// 业务逻辑（不依赖具体存储实现）classDataProcessor{std::shared_ptr<IStorage>storage_;public:explicitDataProcessor(std::shared_ptr<IStorage>storage):storage_(std::move(storage)){}std::vector<uint8_t>process(conststd::string&key){autodata=storage_->read(key);// ... 处理逻辑returntransform(data);}};// 测试代码TEST(DataProcessorTest,BasicProcessing){autostorage=std::make_shared<InMemoryStorage>();storage->write("test_key",{1,2,3,4,5});DataProcessorprocessor(storage);autoresult=processor.process("test_key");EXPECT_EQ(result.size(),5);EXPECT_EQ(result[0],1);}

六、实战案例：字节跳动的存储系统现代化改造

6.1 背景

李华圣参与的字节跳动存储系统现代化项目：

遗留系统：10 年历史，200 万行 C++ 代码，单体架构
核心问题：编译时间 45 分钟、测试覆盖率 35%、模块循环依赖 12 个
业务约束：日均 10 亿次请求，停机时间 < 5 分钟/月

6.2 改造路径

阶段	时间	动作	成果
1. 度量	2 周	技术债务五维评估	识别 47 个高优先级债务点
2. 隔离	4 周	建立 API Gateway，识别模块边界	6 个模块边界清晰
3. 抽取	8 周	绞杀者模式逐个替换	用户模块独立部署
4. 优化	6 周	编译优化、测试补强	编译时间降至 8 分钟
5. 验证	4 周	灰度发布、回滚演练	零停机完成切换

6.3 关键经验

经验一：先度量，再动手
没有数据支撑的重构是"拍脑袋"。技术债务五维模型让团队对现状有共识。

经验二：接口是第一生产力
好的接口设计让后续替换实现变得简单。前期在接口设计上投入 2 周，节省后续 2 个月。

经验三：测试是改造的保险绳
改造前测试覆盖率 35%，改造中每替换一个模块就要求覆盖率 > 80%。测试让团队敢于动手。

经验四：灰度发布是零停机的关键
不是"一次性切换"，而是"逐步引流"。1% → 5% → 20% → 100%，每个阶段观察 24 小时。

七、参会建议

角色	重点关注	推荐演讲
系统架构师	技术债务度量、模块化拆分、接口设计	Michael Wong
研发工程师	依赖管理、可测试性设计、绞杀者模式	吴咏炜
性能工程师	编译优化、灰度发布、回滚策略	李华圣
技术决策者	改造投入产出比、风险评估	三场都建议参加