探寻架构师职责（二）----盘活老系统

很多人一听到“架构师”这个词，脑子里可能会冒出几个印象：技术大牛、头发不多、天天画着一堆看不懂的框框图，感觉特高大上，但具体是干嘛的，又有点说不清楚。我们用两篇文章分别从「建新系统」和「盘活老系统」这2个视角去看看架构师的真正的职责。

很多人对架构师的印象，是那种在项目之初，面对一块白板，挥斥方遒，画出宏伟蓝图的总设计师。很多公司都是从小到大一步一步做起来的，刚起步的时候由于资金紧张或者老板根本都没想到能做大做强，都是秉承着「咋么快、怎么来」的原则快速搭建，有问题快速修改，随着各种「堆砌式」的开发，架构开始腐烂，这个时候才想起来「哦，我们需要一个架构师来解决问题」

所以，在现实中，更多的架构师扮演的是“救火队长”和“改造专家”的角色——他们接手的，往往不是一张白纸，而是一栋已经运转多年，但墙体开裂、管道漏水、电线老化的“老旧建筑”。

这种情况下，架构师的任务，更多的情况不是推倒重建（成本太高，业务等不起），而是在保证大楼正常“住人”的情况下，进行一场精密的“外科手术”和“现代化改造”。

痛点一：研发效能低 —— “改一行业务代码，要花一个月”

症状表现： 业务团队抱怨，一个看似很小的需求，比如给商品详情页增加一个“分享”按钮，开发团队评估下来却要一个月。程序员们则天天诉苦，说系统代码像一团乱麻，没人敢动，“祖传代码，屎山一座”，牵一发而动全身。

架构师的改造思路：

1. 绘制现状图，先当“考古学家”

在这种情况下，架构师会先做“考古”工作：深入代码库，和老员工访谈，使用系统依赖分析工具，把这栋“老楼”的隐蔽结构和管线走向给摸清楚，绘制出一份系统现状架构图。这份图或许很丑陋、很复杂，但它是所有改造工作的基础，让你知道哪里是承重墙，哪里可以动。

2. 拆分“大通铺”，从“微”处着手

老系统效能低下的原因有很多，其中一种是所有功能都挤在一个巨大的“单体应用”里，像一个巨大的通铺，彼此严重依赖。架构师的思路是“分而治之”，他会识别出那些可以独立出去的业务模块，比如“评论系统”、“优惠券系统”，把它们从主应用中剥离出来，改造成独立的微服务。

这个过程是渐进的，先从最边缘、风险最小的模块开始。每成功拆分一个，就相当于把“大通铺”隔出了一个独立的“单间”，这个“单间”的开发和上线，就不再会影响到其他人了，研发效率自然就上来了。

3. 统一“施工标准”，分发“现代化工具”

光拆分还不够，架构师还会建立一套现代化的“施工标准”和“工具箱”。比如，制定统一的编码规范、引入自动化的测试流程、搭建持续集成/持续部署（CI/CD）流水线。这相当于给所有装修师傅都配备了一本清晰的操作手册，确保大家干活又快又好，质量还有保障。

痛点二：性能扛不住 —— “一搞大促就崩溃”

症状表现： 平时系统运行还算平稳，可一旦遇到双十一、秒杀这类流量洪峰，网站就变得奇慢无比，甚至直接宕机。用户刷不出页面，订单下不成功，技术团队只能干着急。

架构师的改造思路：

1. 性能“CT扫描”，定位核心病灶

“性能不行就加服务器”是最简单粗暴但成本高昂的做法。架构师会先扮演“医生”的角色，利用各种性能监控和分析工具，给整个系统做一次全方位的“CT扫描”，精准定位性能瓶颈到底在哪里。是数据库的某条SQL查询太慢？是某个API接口逻辑太复杂？还是缓存命中率太低？

2. 多维度、针对性“动手术”

找到病灶后，就可以对症下药了：

• 引入高速缓存： 在数据库这个“大仓库”前，增加 Redis 这样的高速“前置货架”，把热门商品信息等频繁访问的数据放进去，90%的访问请求直接在“货架”上就满足了，大大减轻“大仓库”的压力。

• 优化数据库： 对那些拖慢系统的“慢查询”进行专项治理，比如加索引、改写SQL、甚至对海量数据表进行“分库分表”，把一个不堪重负的大账本，拆成多个小账本分区域管理。

• 异步化改造： 像下单成功后发送短信、增加用户积分这类操作，没必要让用户在线等着。架构师会引入消息队列（Message Queue），把这些耗时操作变成“待办事项”扔进消息队列里，系统后台再慢慢处理。这样，用户下单的瞬间就能得到响应，体验立刻顺滑。

一般来说，研发效能低对一个企业的影响是最大的，因为无形中大量的人力成本被浪费，但因为各种原因，研发效能是最不被重视的。而大促崩掉这种情况对企业是无法容忍的，那么对于一个有节操的架构师而言，其实可以借助解决性能问题来提升话语权，然后进而去解决研发效能的问题。

痛点三：线上问题频发 —— “按下葫芦浮起瓢”

症状表现： 团队大部分精力都耗在处理线上故障上，不是这里报错，就是那里功能不正常。好不容易修复一个Bug，上线后又常常引发新的、意想不到的问题。整个团队疲于奔命，士气低落。

这栋老楼就像电路老化，今天卧室灯不亮了，修好后发现厨房插座又没电了。

架构师的改造思路：

1. 安装“监控探头”，提升“可观测性”

架构师首先会推动建立完善的监控体系，包括日志收集、性能指标监控和告警系统。这就像给大楼的每个角落都装上高清摄像头、烟雾报警器和温度传感器。一旦出现异常，系统能第一时间自动告警，并提供充足的“现场录像”（日志和调用链），让开发人员能快速定位问题根源，而不是像无头苍蝇一样乱猜。

2. 设立“质量门禁”，严控“交付质量”

为了防止问题代码被带到线上，架构师会建立严格的“质量门禁”制度。比如，强制要求代码必须经过同事评审（Code Review），关键代码的单元测试覆盖率必须达到90%以上，上线前必须在预发环境进行充分回归测试。同时，他还会引入灰度发布、蓝绿部署等先进的发布策略，确保即使新版本有问题，也只会影响一小部分用户，并且可以秒级回滚到旧版本。

3. 设计“应急预案”，实现“优雅降级”

架构师要承认：系统一定会出故障。关键在于，故障发生时，核心功能是否还能用。架构师会梳理出系统的核心链路（比如电商的“浏览-下单-支付”），并为非核心功能设计“降级”和“熔断”开关。例如，当推荐系统出现故障时，可以自动“降级”，不展示个性化推荐，但用户依然可以正常搜索和购买商品。这保证了即使大楼的健身房关门了，居民的核心居住功能不受任何影响。

痛点四：数据不一致 —— “两本账对不上”

症状表现： 这是分布式系统里最头疼的问题之一。库存系统显示还有货，但订单系统就是创建不了订单；用户的账户在一个系统里显示是VIP，在另一个系统里却是普通用户。财务和运营团队天天为了对账而抓狂。

架构师的改造思路：

1. 明确“数据产权”，指定“唯一负责人”

数据混乱的根源往往是“权责不清”。架构师会梳理核心业务数据（如用户、商品、订单、库存），为每一种数据确定一个“唯一来源”。比如，所有库存的变更，必须且只能由“库存中心”这一个服务来操作和解释，其他任何服务都只能向它查询，不能自己修改。这就从根本上杜绝了“多头管理”造成的混乱。

2. 引入“柔性事务”，保障最终一致

在微服务架构下，一个操作常常需要跨越多个服务。比如用户下单，需要同时“创建订单”和“扣减库存”。架构师会引入分布式事务解决方案，比如基于消息队列的最终一致性方案。下单操作会先在订单系统里记录一个“待处理”状态，然后发送一个消息给库存系统，库存系统处理成功后再发消息回来确认。通过这种可靠的消息传递和重试机制，来保证这些跨系统的操作，要么最终都成功，要么就都回滚，避免出现“钱付了，库存没扣”的尴尬局面。

3. 建立“审计”机制，定期“对账”

即便有上述保障，他也知道数据在复杂链路中仍有极小概率出现不一致。因此，他会设计一个自动化的数据核对系统，定期（比如每天凌晨）去比对各个系统间的核心数据。一旦发现不一致，就自动发出预警，并由预设的程序或人工介入进行修复。

结语

当架构师面对一个老旧系统时，他的角色不再仅仅是一个“建筑设计师”，他更像一个集“结构工程师”、“管道专家”、“消防顾问”和“城市规划师”于一身的复合型人才。

他的工作，不是推倒重来的革命，而是深思熟虑、循序渐进的改良。他需要有“考古学家”的耐心去摸清现状，有“外科医生”的精准去切除病灶，更要有“规划师”的远见去引领系统走向更健康、更稳固、更能支撑业务发展的未来。他的价值，就在于将混乱变为有序，将脆弱变为健壮，最终让这栋“老楼”重新焕发活力。