- 综合排序
- 最热优先
- 最新优先
- 来自专栏mazhen.tech
遗留系统
CORBA 定义了一系列服务，如Naming Service，Transaction Service，Security Service等，作为分布式系统的基础服务。 CORBA 的 ORB（Object Request Broker） 负责分布式系统中对象之间的通信。用户可以像调用本地对象一样调用远程对象上的方法，ORB 会处理网络通信和远程调用的细节。 在2024年的今天，有着30多年历史的 CORBA 和20多年历史的 EJB 已经是遗留系统，不会再有大批聪明的年轻人愿意投入到这个技术领域。 不过对于像我这样还在一线搬砖的大龄程序员，遗留系统也是一种选择。它们和自身的境况很像：激情已过，一天天的老去。
46110编辑于 2024-05-15 - 来自专栏斑斓
处理遗留系统
倘若我们需要维护遗留系统，或者需要为它添加新的功能，又或者需要将新的系统与遗留系统进行集成，就必须正视遗留系统带来的问题了。 处理遗留系统，首先需要分析和了解遗留系统，尤其这个遗留系统并非你开发时，更需如此。我们可以考虑双管齐下的办法。一是从业务逻辑方面去了解。 相比新系统而言，遗留系统的唯一好处就是它往往是可以运行可以使用的。因此，最好的办法是直接运行遗留系统，通过实际操作了解系统的各个功能点、业务流程。 可以阅读架构文档和源代码，如果能够咨询遗留系统的设计者或开发人员，就更好。尽快地描绘出遗留系统的轮廓图，可以帮助你从技术的宏观角度剖析遗留系统的结构与组成。 因为我们抱着改善遗留系统性能的目的，所以在分析遗留系统时，就应该事先确定可能导致性能损耗的地方，而不是全方位地去了解整个系统。 在维护遗留系统时，需要根据不同的场景做出不同的决策。
79040发布于 2018-03-07 - 来自专栏IT大咖说
遗留系统改造策略
随着改造过程的推进，新系统提供的功能和价值越来越多，逐步地取代原有遗留系统的功能，用户流量也会越来越多地导入到新系统上，最后原有遗留系统不再被使用时，就可以安全地下线了，此时门面服务也可以安全地移除。 图6-3 绞杀者模式 绞杀者模式特别适合用于对复杂度较高的大型遗留系统进行逐步改造，但在迁移过程中也需要注意以下问题： 考虑新系统和遗留系统之间的数据共享或者同步方式。 6.2.3 挎斗模式 传统企业中存在大量的遗留系统，如果要对这些遗留系统全部进行微服务化改造，成本会很高，并不现实，而且有些遗留系统甚至是无法完全改造的。 在部署结构上，挎斗服务与原遗留系统紧密相关，原遗留系统在哪里它就在哪里。对于原遗留系统应用程序的每个实例，旁边都部署和托管了一个挎斗实例。挎斗是支持与原应用一起部署的进程或服务。 由于是非侵入式的接入方法，通常不需要改写原遗留系统的代码，可以实现零修改成本的接入。 挎斗服务与原遗留系统相邻部署，可以访问与原系统相同的资源，有时可以拿来作为监控服务的接入代理。
1.5K10发布于 2019-08-21 - 来自专栏后端知识开放麦
遗留系统微服务改造（一）：遗留系统改造策略与实战场景分析
遗留系统，每个程序员都有话要说。这些老系统虽然能正常运行，甚至承载着公司的核心业务，但维护起来确实是个挑战——代码结构复杂，改个小功能都需要谨慎考虑。 1.1改造前的系统状况这个房产搜索平台是典型的遗留系统，存在多个问题：代码规模庞大：300万行代码，包含房源管理、用户系统、搜索引擎、推荐算法、支付模块等各种功能，结构比较复杂。 2.遗留系统特征分析2.1遗留系统的定义遗留系统是指那些技术相对陈旧但仍在运行的系统——虽然年代久远，技术栈过时，但由于承载着重要业务，仍需要继续使用。 因此，适时进行系统改造是必要的。2.3遗留系统的具体问题维护成本高在大规模代码库中定位问题比较困难，就像在复杂的系统中寻找特定的组件。每次修改代码都需要谨慎分析影响范围，避免引发连锁反应。 3.遗留系统改造策略既然推倒重来风险较高，我们需要寻找更稳妥的改造方法。改造遗留系统就像给运行中的系统更换组件——既要保证系统正常运行，又要完成技术升级。虽然有一定挑战，但确实有成熟的方法可以参考。
31220编辑于 2025-10-14 - 来自专栏斑斓
【系统架构】遗留系统的技术栈迁移
什么是遗留系统（Legacy System）？根据维基百科的定义，遗留系统是一种旧的方法、旧的技术、旧的计算机系统或应用程序[1]。这一定义事实上并没有很好地揭露遗留系统的本质。 这意味着遗留系统会逐渐随着时间的推移，不断地增加维护成本。 维护一个软件系统，就需要了解该软件系统的知识。若知识缺失，就意味着这会给维护人员带来极大的障碍和困难。 从这个角度讲，所谓“遗留系统”，就是缺少了一部分重要知识，使得维护人员“知其然而不知其所以然”的软件系统。 若要让遗留系统焕发青春，最彻底的做法自然是推倒重来，但这样付出的代价太高；而且，即使对系统重新设计和开发，仍然免不了会重蹈遗留系统的覆辙。 最后，还有一种方式，则是对遗留系统进行技术栈迁移。
1.3K70发布于 2018-03-07 - 来自专栏ThoughtWorks
遗留系统的服务拆分
最近一年来，我所在的项目为一个传统行业客户的 IT 核心系统做遗留系统改造，我参与了该系统一个业务模块的拆分和服务化，在这过程中落地了一些有意思的实践，特此记录下来和大家分享。 当然，该系统也没有落下“没有自动化测试”这个遗留系统的典型标签。 图1 单个代码仓库里包含的各种业务模块和技术模块 客户PO是一个对技术有理想有抱负的人物，不希望这个系统再继续腐化下去，所以找到我司对该系统进行现代化改造，其中一个落地措施就是对这个单体系统进行拆分和服务化 结语 “ 让我们面对现实吧，我们今天所做的一切就是在编写明天的遗留系统 —— Martin Fowler ” 我们正在书写、即将面对、正在面对遗留系统。 在与遗留系统的相爱相杀中，需要我们基于项目目标和现状、结合过往经验、经过剪裁和取舍，才能迎面不断出现的挑战。我以此文抛砖引玉，欢迎大家交流拍砖。
59420编辑于 2022-07-12 - 来自专栏ThoughtWorks
如何交接复杂的遗留系统？
2020年10月，Thoughtworks的C团队从客户团队交接了一个有近20年历史的支付网关系统。这个支付网关主要向英语系地区的企业提供信用卡支付，储蓄卡支付等支付相关的功能，每个月的交易额过亿。 分阶段制定目标、建立重点 我们一般如何衡量一个遗留项目维护的质量呢？ 短期：至少做到跟前团队一样。也就是说，在客户团队成员离开时，团队能具备足够的知识和技能来处理线上事故和日常业务工作。 利用C4模型梳理系统架构 通常处理的问题都是业务问题，如果不能把一个个服务放在业务流程中去理解就没有意义。 支付系统C1简化图（简化版） 3. 通过结对在团队内部分享上下文 在第一阶段交接的过程中，我们和客户团队是“1+1”的模式进行知识交接，业务知识是像孤岛一样分散在各个成员那里。 在正式接手系统之前，团队感受到了比较大的压力。这些压力一方面是因为大部分项目成员缺少 On Call 的实战经验，另外一方面因为在交接的第一阶段里，我们缺少对业务实现细节和系统的深入了解。
98110编辑于 2022-02-16 - 来自专栏无敌码农
关于遗留系统怎么办？
前段时间经常聊到Legacy System（遗留系统）的一些话题，特别是在IT信息化比较早的行业中，如运营商和金融行业。 遗留系统，最大的问题：年代久远，人员更迭频繁，对当前的维护人员来说，就是一个黑盒，只知道它外在的能力是什么，但是内部运行逻辑已经没有几个人能讲清楚了。 特别是，当一个技术团队，要面临多个，甚至更多的遗留系统时，情况会更为复杂。 以下是Google SRE第二本书中关于遗留系统的内容，有些共鸣，这两天刚看到，这里一并分享下。 Google专门提遗留系统，主要原因也是早期还没统一标准，到了后期部分系统也没改造，所以就没法融入Google强大的自动化体系中。
1.4K30发布于 2019-07-31 - 来自专栏ThoughtWorks
使用CDC模式改造遗留系统
项目改造背景及挑战 在我们经历的各种遗留系统改造之旅中，使用绞杀者模式来改造一个巨大的单体服务，是一种被广泛采用且验证行之有效的手段，在应用传统的绞杀者模式时，通常采用逐步替换的方式，将遗留系统中某一独立的部分抽取出来进行改造 同时遗留单体系统中的代码仓库已经非常庞大，并且复杂到难以修改，任何对于遗留系统的代码修改都需要经过繁复的测试和严格的 Code Review，同时也会增加交付开发人员的认知负担，并且还会给现有系统带来一定的风险 基于以上背景，我们发现，通过修改遗留系统代码的方式来完成新老两个系统之间数据的同步代价是比较大的，而且会引入一定的风险。 通过 Debezium，我们便可以捕获到所有遗留系统数据库产生的变化，并将其推送到 Kafaka 特定的 Topic 中去，只要新服务能够响应这些变化，就可以将旧系统中数据产生的变化同步到新系统里去。 基于此种解决方案，我们将整个遗留系统改造分为了三个阶段， 阶段一：前端对遗留系统读和写，但是对遗留系统所造成的修改都会被同步到新系统中 阶段二：前端对遗留系统进行写操作，但是对于读操作都会被引向新系统
63211编辑于 2023-04-28 - 来自专栏coderidea
如何平稳的迁移遗留系统
X公司的Y软件被归类为遗留系统，这不同于Michael Feathers所说的“没有测试的系统即遗留系统”。Y软件的历史已经超过五年，最初的开发者也早已离职。 如今仍在维护这个系统的开发者精疲力尽。 当一个请求到达时，代理层会判断这个请求应该由新系统处理，还是应该由旧系统处理。随着新系统功能的逐步完善，越来越多的请求会被新系统处理，直到最后，新系统完全替代了老系统。 为什么要使用绞杀者模式？ 优点 渐进式迁移：绞杀者模式允许我们逐步地迁移系统，降低了一次性替换系统的风险。 降低风险：通过代理层，我们可以灵活地切换新系统和旧系统，从而降低系统出现问题的风险。 绞杀者模式是一种非常高效的系统迁移方案，它允许我们逐步地迁移旧系统，降低了一次性替换系统的风险，并且通过代理层，我们可以灵活地切换新旧系统并动态调整系统的负载，从而提高系统的性能。 总的来说，绞杀者模式是一个强大而灵活的工具，它能够帮助我们更好地处理淘汰老旧遗留系统的问题，提供更高效、更稳定的服务。尽管它可能增加了一些复杂性，但是如果正确使用，其好处可能会远远超过它的缺点。
62120编辑于 2023-09-07 - 来自专栏Java进阶架构师
架构-遗留系统的重灾区
今天想跟大家聊聊遗留系统，首先，看一下这张图 这是一家银行的核心应用系统模块之间的交互图，我想没有一个人愿意工作在这样的系统上吧？ 架构混乱，模块之间职责不明，一个需求就要需要修改四五个服务，这就是遗留系统，留给我们的问题。 遗留系统与架构 一个软件架构的作用，是要解决多个业务模块之间的协作问题。 系统之所以成为遗留系统的本质之一，就是架构的混乱。 综合来看，代码和架构的质量差，会导致遗留系统的维护成本相当高昂。 深入剖析了遗留系统的特点和问题，详解遗留系统现代化的原则、模式和最佳实践，并从代码、架构、DevOps 和团队现代化 4 大方向，解决遗留系统治理的疑难杂症，带你走出遗留系统的泥潭。 实战篇：将带着你一起对一个典型的遗留系统进行现代化
78110编辑于 2022-05-17 - 来自专栏软件方法
遗留系统的UML建模有没有不同
公司有一套零售门店系统，领导让我负责在现有系统基础上开发，像这种"遗留系统"，UML建模的知识还用得上吗，或者使用上有没有不同？ 潘加宇： "遗留系统"是一个从开发人员视角定义的术语，大致意思是（1）这个系统已经出现了比较长一段时间（2）这个系统的代码不是我写的（3）很可能接下来我要负责做一些事情来改进或集成这个系统。 图上所有的系统都是"遗留系统"。 分析工作流的结果（分析类图、分析序列图、分析状态机图）和"目前是否有了一些代码"无关，也就是说，和"遗留"不"遗留"无关。 也就是说，应用UML建模，和"遗留"无关。 （4）设计 到了设计工作流，才和"遗留"有关系。 设计工作流需要思考：为了实现分析的结果，已有的代码哪些可以利用以及如何利用。
1K10发布于 2019-09-23 - 来自专栏ThoughtWorks
组件测试：改建遗留系统的起点 | 洞见
实践中，为遗留系统添加单元测试和端到端的界面测试都会遇到其对应的困难，而我们发现组件测试却能由于其关注行为的特点在单元测试和端到端测试之间取得平衡，对于改建遗留系统来说，它提供了一个不错的起点。 ---- 避开单元测试实践的被动 遗留系统从最初发布到现在，早已过去多年，当初的开发人员早已离开，徒留一段代码给后来者。在遗留系统上的工作通常要求不能破坏现有其他功能，只能按要求“恰好”地修改。 实际上，很多遗留系统甚至连清晰的层次化设计都没有。 除非要改建的遗留系统的外部依赖无法高效地基于代码进行设置、不能通过代码在进程内启动，否则应该优先采用进程内的组件测试。 ---- 总结 没有人愿意每天与遗留系统为伍，但总有些约束让我们不得不妥协。 基于遗留系统开展工作，总是会遇到很多挑战。在实践中，我们发现在遗留系统的改建过程中，组件测试总是能够在我们遭遇困境时，给出令人满意的答案。
69730发布于 2018-07-23 - 来自专栏网络安全技术点滴分享
GitHub Copilot与AI代理如何拯救遗留系统
AI驱动的遗留系统现代化三步框架Julia和她在微软的团队开发了一个系统化方法，适用于任何遗留现代化项目，不仅仅是COBOL。以下是他们经过实战检验的GitHub Copilot驱动框架。 步骤1：代码准备（逆向工程）遗留系统的最大问题？组织不再知道他们的代码实际上做了什么。他们使用它，依赖它，但理解它？那是另一回事。 ）## 业务目的客户账户验证与余额检查- 根据主文件验证账户号码- 执行带有透支保护的余额计算- 生成审计合规的交易日志## 发现的依赖关系- 通过SQLCA的DB2数据库连接- 外部验证服务调用- 遗留打印队列系统步骤 从这里开始：成为现代化英雄的路径无论你处理的是COBOL、古老的Java还是任何遗留系统，以下是今天就可以开始的方法：从小处开始识别一个有问题的遗留系统（从少于5,000行代码开始）使用GitHub Copilot 当这三种力量协同工作时，遗留系统现代化从不可能完成的挑战转变为可实现的项
42310编辑于 2025-11-04 - 来自专栏日志服务CLS
特征开关：遗留系统重构中的关键利器
前言在软件开发的世界里，遗留系统常常被视为一座难以逾越的高山。它们承载着企业多年来的业务逻辑，但也因为年代久远、代码复杂、缺乏文档等原因，成为了开发团队的“噩梦”。 那么本文就来通过一个订单系统的改造案例，详细探讨特征开关如何在遗留系统重构中实现新旧逻辑的并行运行，帮助开发团队克服“不敢改”的难题，推动系统的现代化进程。 2、特征开关在遗留系统重构中的价值在遗留系统重构中，特征开关的核心作用主要体现在为开发团队带来了诸多便利，有助于降低风险、实现并行测试和灵活控制。 结束语通过上文的详细介绍，可以看到遗留系统的重构是一个复杂而艰巨的任务，尤其是对于核心业务系统，如订单系统。特征开关技术为解决这一问题提供了新的思路和方法。 通过不断地实践和总结，开发团队可以更好地掌握特征开关的使用方法，逐步提升遗留系统的可维护性和扩展性，最终实现系统的现代化。希望本文的介绍和案例能够帮助大家更好地理解和应用特征开关技术。
27421编辑于 2025-05-21 - 来自专栏深度学习与python
千万级规模遗留系统债务度量改造实践
作者｜白嗣健 编辑｜支小亚 本文由极客时间整理自华为云化平台技术专家白嗣健在 QCon+ 案例研习社的演讲《千万级规模遗留系统债务度量改造实践》。 追求商业价值对于一个企业来说是正常的，投资重构代表企业承认这些在过程中产生的技术债务，并愿意主动去消减，从而让系统持续演进。 如果没有管道让这些债务流走，它们会一直留在系统中。久而久之，当债务积重难返，架构师 Tech Lead 往往会主张用新技术把系统重写。做过架构师的人应该知道，程序员更喜欢重写一遍。 我们有一个 dashboard 系统，哪个团队选择了哪些架构检查要素？他们的检查要素的结果是什么？通过看板全部可以展示出来。
42820编辑于 2022-06-13 - 来自专栏深度学习与python
破解遗留系统重构问题的 6 步心法
我会从以下四个部分来分享，第一部分给大家分享遗留系统典型特征，介绍这类系统的特征以及对团队的影响。 一、遗留系统典型特征 我在工作中遇到过很多遗留系统，总的来说有两个很明显的特征。第一，从整个工程上来看它是呈大泥球的架构，通常代码是百万行起而且随意依赖。 重构以后又成为了遗留系统怎么办？ 四、总结 本文主要讲了四个部分，第一部分分享了遗留系统典型特征，主要是大泥球架构、ALL In Class，还分享了遗留系统对整个团队及业务的影响。 活动推荐 遗留系统一直是技术领域的“重灾区”，想要深入剖析遗留系统的特点和问题，推荐你学习这门专栏，它将从代码、架构、DevOps 和团队现代化四大方向，解决遗留系统治理的疑难杂症，帮你和所在团队走出遗留系统的泥潭
69110编辑于 2023-03-29 - 来自专栏ThoughtWorks
如何做好大型遗留系统的数据迁移
历史悠久的大型企业，都会存在遗留系统。这些系统运转着重要的业务，但使用到的技术已经跟不上时代潮流。因此有着维护成本高、难以扩展、用户体验差等缺陷。 最终，企业一定会下决心开发一套全新的系统来替代遗留系统。除了完成新系统的开发，还有一项重要的工作，是将老系统中存留的数据迁移进新系统，也就是我们常说的数据迁移。 陌生的遗留系统 DB 设计 作为新系统的开发方，你一定熟知新系统的 DB 设计。但是遗留系统的 DB 设计想必你一定不甚了解。作为要被替换的遗留系统，其开发方肯定也不会提供技术支持。 古老的遗留系统数据库新系统一般都会采用当前主流的数据库，例如 MySQL、Oracle 等。但遗留系统可能采用的是几十年前古老的技术，数据库的名字你可能听都没听过。 如何连接老系统的 DB，查询出里面的数据都会是一个难题。迁移海量数据量遗留系统经过几年甚至几十年的使用，累积了海量的数据。业务一般不会轻易放弃这些数据。
1.5K10发布于 2021-09-15 用Agentic AI修复无法替换的遗留系统
在某机构的通用人工智能实验室，团队训练代理的对象不是理想化的接口，而是这些遗留系统的高保真模拟环境。 并且，通过在后台管理遗留系统的种种特性，该代理实际上变成了一个通用API——一个可供用户执行各种特定任务的单一接口。 为日常生活提供动力的遗留系统走进任何大型机构（银行、保险公司、医院、政府机构）的幕后，你都会发现同样的情况：一层维持软件运转的无形人力劳动。 驾驭这些异常特性所需的机构知识，如同遗留系统的口述传统一样代代相传。这些工作流之下的许多基础设施，比管理它们的人还要古老。 遗留系统背后的逻辑通过摩擦最清晰地展现出来：一个因编码了顺序规则而姗姗来迟的模态窗口；一个在另一值保存前拒绝输入的字段；一个因后台作业中途重启而重置的表单。这些行为不是故障，而是系统真正的语义。
8910编辑于 2026-04-29- 来自专栏网络安全技术点滴分享
守护遗留系统的安全挑战与应对策略
守护我们的遗留系统大家好，我是iSEC Partners的Scott Stender。最近我有幸在布鲁塞尔的微软BlueHat活动上就"保护遗留系统安全"这一主题进行了演讲。 随着近期关于保护国家、企业和个人网络系统需求的广泛讨论，我认为BlueHat活动是时候将聚光灯转向那些支撑我们互联社会运转却鲜受关注的遗留系统了。这些系统正是我们构建当今丰富计算环境所依赖的基石。 我原本希望与参会者讨论并可能辩护以下几点：遗留系统将始终伴随我们。毕竟，每个完成的软件项目都在创造新的遗留系统。针对系统的攻击手段不断变化且日益复杂。防御方需要同样复杂且持续不断的应对措施。 例如，系统中可能包含通过多年错误修复和实际运行积累的宝贵经验，重新开始可能导致这些知识的丢失。相反，与会者向我提出了以下挑战性问题：如何展示保护遗留系统的进展并证明资源投入的价值？ 通过持续改进软件和即时安全技术，我们或许能够应对保护遗留系统的挑战。Scott Stender, iSEC Partners
9400编辑于 2025-08-17
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号