【转】大型系统架构重构经验总结

本文转自大型系统架构重构经验总结,以下为文章原文(顺便修改了错别字)

本文目的

笔者在一线互联网公司,经历过数次大型系统的重构项目,也多次担任技术负责人,经历的重构项目包含:日吞吐量数万亿的计算型系统、基础架构中间件系统、高并发高稳定性要求的C端系统、业务复杂性较高的B端系统等。
同时了解到大型重构项目风险高、难度大、易流产,因此总结了本文供大家参考。

重构挑战大原因剖析

任何系统在持续的演进迭代的历程中,都难免因各类因素导致迈向重构,比如:系统可塑性与业务需求无法匹配、扩展性无法支撑业务体量的膨胀、技术债务引发研发效率的严重下滑等。
笔者收集了20余个失败的重构案例并深度交流,普遍感受到重构是一个难度很大的事情,总结原因有4个:

  • 重构比从零建设更复杂
    业务兼容、基础设施兼容、在线不影响服务前提下完成架构替换等,挑战性都非常高。

  • 深度!重构需要对系统有全面、深入的认识

    • 深度是对问题剖析的是否准确,见过有所谓“架构师”绘制几张架构图就开干(个人对架构师这个职位是非常尊重的,身边很多优秀的架构师对系统的认识及演进决策拿捏的非常准确,另外很多项目的流产并不是架构师的责任,但确实不乏一些空谈架构不考虑落地的“架构师”存在)。
    • 对系统有深刻的认识是重构项目成功落地的必要条件,这里的“认识”包含 (1)困境与根因的因果关系、(2)技术如何支撑复杂的业务场景、(3)多方位的评估等等诸多因素。
  • 广度!重构需要对系统周边情况、业界优秀方案有较好的把握

    • 对周边系统的了解程度往往能决定项目的下限(能否避免流产);
    • 对业界方案的把握往往能决定上限。
  • 重构周期较长,不可控因素较多
    重构对技术负责人的综合能力要求是非常高的。因为领导重构并不是一项仅依靠技术能力的工作,同时要求对目标及进度管理、跨团队协作、工程规范等诸多方面也必须能较好把握。

重构的系统性方法

下面是笔者总结的一套较完善的重构流程方法,可以针对大部分场景下的重构项目。包含应遵循的10个准则及各个准则的解释或分析,归纳如下:

  • 问题梳理,原因必根究。

    • 首先明确矛盾与问题,务必确定待解决问题的必要性;
    • 其次清晰的说清楚根因与待解决问题间的逻辑关联;
    • 最后确认覆盖全部问题。
  • 旧系统足够深度了解。

    • 首先完成所有业务(中间件或平台就是能力)的梳理;
    • 其次梳理业务与工程的关联(如业务架构图、数据流转图、数据表关联等);
    • 最后梳理重构期间需整合的新需求,思考与重构同步落地的计划。
      注:如果1、2无法顺利完成,建议停止重构,不论出于人力、新接手或其他原因,重构成功率会非常低
  • 目标导向、目标可量化。

    • 明确并量化目标,这是方案选型的基础,也是确保演进路径清晰的必要条件。
    • 如果目标无法量化(比如:具备理论无上限的水平扩展能力),应该做到可推导。
  • 业界调研、技术选型。

    • 业界调研尽量覆盖国内外大厂、公司内部的同类产品的情况(比如在不了解某领域业界最优能力是 T 的情况时,目标随意定为 T+,就很不现实)。
    • 新业务线从头建设订单系统,可以参考内部成熟业务的相关方案,少走弯路,同时根据系统及团队情况确定选型。
  • 方案设计,充分认识方案的优缺点。

    • 首先,技术方案多次review,方案多次review,多次review,review
    • 其次,判定重构是否对业务无损,有损需完成影响面评估,并对管理层达成一致;
    • 再次,对新方案的可支撑容量做评估 (如有新组件引入等不确定因素,先对组件做压测,确保心中有底而不是贸然拍数据);
    • 最后是全方位的风险预估(如:第三方依赖可行性及排期评估、人力成本、异常定位成本、兼容性、安全、可用性、可靠性等)。
  • 提前规划系统切换方案。
    必须定制小流量方案;稳定性要求高的系统必须可回滚,无法回滚等于飞蛾扑火 (笔者职业生涯至今所经历的重构项目,上线完全符合预期且不需优化的情况,都没达到 …)。

  • 接口定义清晰,方案不过于复杂;测试驱动(视情况选择)。

    • 建议问题暴露周期长的系统使用测试驱动方式;
    • 基于脚本测试的,脚本高度复用可以大幅提效。
  • 方案调整趁早回归。
    很多时候调整方案不可避免,早回归整体效率更高。

  • 架构迁移监控先行、日志先行。

    • 重构改动范围大,很难不出BUG,好的监控体系下,系统可以比人更早发现问题,风险也更加可控;
    • 新架构发布时,日志往往是定位问题最便捷的工具。
  • 上线后再次做容量、扩展性等多方面预估。

    • 可能(或者说经常)发现做方案时的评估并不准确,可靠的数据对后续工程迭代及业务发展是至关重要的。
    • 1个月后做这个事情,效率大概率骤降!

总结

在这里插入图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值