- 综合排序
- 最热优先
- 最新优先
- 来自专栏JavaEdge
架构重构的技巧
属于架构重构，架构设计方案了，实现系统可扩展性。 3 代码重构 V.S 架构重构 4 架构重构技巧 4.0 手段 架构重构是否可以修改 4R 中的 Rank？ 不能！ 定义：优化系统架构，整体提升质量，架构重构会影响架构的4R定义。 明确时间、目标、版本 5 架构重构FAQ 架构重构是否可以引入新技术？ 收集需要重构的证据，技术汇报的时候有理有据 6 测试 6.1 判断 代码重构、架构重构、架构演进都不需要去修复问题 × 微服务拆分既可以是架构重构的手段，也可以是架构演进的手段 √ 架构重构应该搭业务版本的便车 ，可以避免对业务版本有影响 × 架构重构是为修复问题，因此应该将系统遗留的问题都在架构重构的时候修复 × 架构重构应该分门别类，按照优先级逐步落地 √ 6.2 思考 架构重构的时候是否可以顺手将代码重构也做了
48530编辑于 2023-04-12 【架构师重构与重写】
架构师视角下的系统重构与重写 系统重构与重写是架构师在技术演进中常面临的核心决策。重构侧重优化现有代码结构，而重写通常涉及技术栈或架构模式的彻底更换。以下从案例分析、方法论和代码实现展开说明。 案例分析：电商订单系统重构 某电商平台订单系统因历史代码耦合度高，导致新功能开发效率低下。通过重构实现模块化： 问题诊断：订单处理与支付逻辑强耦合，单元测试覆盖率低于30%。 系统重写的决策与实施 重写适用于技术债务过高或架构不匹配业务场景的情况。以某金融系统迁移至微服务为例： 决策依据：单体架构无法支撑高并发交易，模块部署相互影响。 代码实现：重构模式与技巧 1. vs 重写 维度 重构 重写 成本 较低，渐进式改进 较高，需全面测试与迁移 风险 可控，逐步验证 高风险，可能影响线上稳定性 适用场景 代码质量差但架构合理 技术栈陈旧或架构无法扩展 建议：通过“
27610编辑于 2025-12-18- 来自专栏Keegan小钢
Android项目重构之路:架构篇
首先是其架构，是按功能模块进行划分的，本来按模块划分也挺好的，可是，他却分得太细，总共分为了17个模块，而好几个模块也就只有两三个类而已。 整个项目从架构到代码都是又臭又乱，开发人员只是不停地改bug，根本没法做新功能，更别谈扩展了。当时，公司已经有为不同客户定制化app的需求，而现有的架构完全无法满足这样的需求。 因此，我决定重构，搭建一个易维护、易扩展、可定制的项目。 我将项目分为了四个层级：模型层、接口层、核心层、界面层。 所以，从架构到代码，很多东西都需要设计好，以及规范好，才能保证程序易维护、易扩展。后续的文章里将会详细分享下我在这方面的经验。 结束 以上就是最基本的架构了，讲得比较简单，只列了几个核心的东西。并没有进一步去扩展，扩展是下一步的事情了，后续的文章里会慢慢展开。
1.2K40发布于 2018-08-10 - 来自专栏勇哥编程游记
Feed流应用重构-架构篇
重构，于我而言，很大的快乐在于能够解决问题。 第一次重构是重构一个c#版本的彩票算奖系统。当时的算奖系统在开奖后，算奖经常超时，导致用户经常投诉。 接到重构的任务，既兴奋又紧张，花了两天时间，除了吃饭睡觉，都在撸代码。重构效果也很明显，算奖耗时从原来的1个小时减少到10分钟。 去年，我以架构师的身份参与了家校朋友圈应用的重构。 应用麻雀虽小，五脏俱全，和诸君分享架构设计的思路。 01 应用背景 1. 应用介绍 移动互联网时代，Feed流产品是非常常见的，比如我们每天都会用到的朋友圈，微博，就是一种非常典型的Feed流产品。 重构过程 《重构：改善既有代码的设计》这本书重点强调: “不要为了重构而重构”。重构要考虑时间(2个月)，人力成本(3人)，需要解决核心问题。 写在最后 这篇文字主要和大家分享应用重构的架构设计。其实重构有很多细节需要处理。 数据迁移方案 团队协作，新人培养 应用平滑升级 每一个细节都需要花费很大的精力，才可能把系统重构好。
70420编辑于 2022-07-27 - 来自专栏程序员的SOD蜜
架构重构改善既有代码的设计
这时候我们就需要对架构模型进行修改了。而架构设计的过程本身是一个迭代的过程，这就意味着在每一次的迭代周期中，都需要对架构进行改进。 Problem 我们如何避免对架构模型进行修改？ 又如何保证架构进行正确的改进？ Solution 我们从XP中借用了一个词来形容架构模型的修改过程――Refactoring，中文可以译作重构。这个词原本是形容对代码进行修改的。 我们把这个词用在在精化和合并模式中，我们提到了改变和改进的区别，因此，我们的对策主要分为两种：如何防止改变的发生，以及，使用重构来改进软件架构。 对软件架构进行重构 Martin Fowler的Refactoring一书为我们列举了一系列的对代码进行重构方法。架构也是类似的。 在初始模型完成后（参见精化和合并模式中的例子），我们会对架构进行重构，而随着迭代的演进，需求的演进，架构也需要演进，这时候也需要重构行为。
1.4K60发布于 2018-02-26 AI时代推动计算架构全面重构
从通用硬件到专用计算过去几十年间，通过基于近乎相同的商用服务器的横向扩展架构，计算能力实现了民主化。这种统一性允许灵活的工作负载放置和高效的资源利用。 这些限制凸显了对更高带宽连接的迫切需求，并强调了在处理和内存架构方面取得突破的紧迫性。没有这些创新，强大的计算资源将因等待数据而闲置，极大地限制效率和规模。 安全与隐私：内建而非外挂互联网时代的一个重要教训是，安全和隐私不能有效地附加到现有架构上。恶意行为者的威胁只会变得更加复杂，需要将用户数据和专有知识产权的保护构建到ML基础设施的结构中。 从架构到监控和修复，每个步骤都必须简化和自动化，以在前所未有的规模上利用每个硬件世代。
31210编辑于 2025-09-14- 来自专栏大数据
Flume日志采集应用架构升级与重构
MOB数据采集平台升级也快经历了半年时间，目前重构后线上运行稳定，在这过程中挖过坑，填过坑，为后续业务的实时计算需求打下了很好的基础。 一、升级与重构的原因 旧有架构 上图为旧有架构，主要服务于Hadoop2.x离线计算(T+1)以及Spark的实时计算（T+0），但在数据采集、数据流动、作业调度以及平台监控等几个环节存在的一些问题和不足 channel的使用，可能导致高峰期队列堵塞，数据丢失的问题 平台监控： 只有系统层面的监控，数据平台方面的监控等于空白 针对以上问题，结合在大数据中，数据的时效性越高，数据越有价值的理念，因此，开始大重构数据采集平台架构 二、升级后的架构设计 这张图是升级后的数据采集架构图，从图中可以了解到大数据采集过程以及数据走向：数据源，数据缓存，存储计算等环节。 将原来数据采集与数据计算架构进行聚合解耦，节省了服务资源，加强了数据采集的数据流的监管，对文件传输及数据完整性监控都有所补充，有利于后期离线或实时运算的可插拔接入。
1.7K90发布于 2018-01-10 新版发布：Falcon支持与后端架构重构
✨ 新功能与改进新增：重构为从后端中心转向模型中心架构。 #183) 更新langchain依赖 (#196) 使少样本文件读取器对文件格式更加健壮 (#184)⚠️ 向后兼容性说明移除了对MiniChain的内置支持 (#176) 从后端中心到模型中心架构的转换
10010编辑于 2025-10-27JBoltAI：事件驱动 AI 架构，重构 Java AI
而事件驱动架构，正是解决这些痛点的关键思路。 异步非阻塞的事件处理机制，让 JBoltAI 的事件驱动 AI 架构能够轻松支撑企业级的高并发场景。 JBoltAI 的事件驱动 AI 架构，还与 Java 生态的开发习惯高度适配，大幅降低了 Java 团队的学习与落地成本。 ，即可实现能力升级，无需重构现有系统，让企业可根据业务节奏逐步投入，降低试错成本。 作为 AIGS 范式的核心实践者，JBoltAI 的事件驱动 AI 架构，重新定义了企业级 Java AI 开发的模式。
13010编辑于 2026-03-13- 来自专栏iOS技术
YBImageBrowser 重构心得：如何优化架构、性能、内存？
时隔一年多，接近 1.3k stars，处理了 100+ issues，200+ commits，30+ releases，两次深度重构。重构的原因很简单，无法忍受自己写的拙劣代码 ? 下面就从几个方面谈谈这次重构引出的值得分享的东西。 一、图片处理流程 一张图片展示到屏幕上的流程： ? 二、架构设计 界面展示类型组件需要有良好的深度定制性，这就对架构设计要求较高，难点在于区分变量与不变量，各模块职责划分，以及合理的抽象。总的来说思维方向是不变的，落地到代码需要做很多的变化和取舍。 (void)implementProtocolA:(id<ProtocolA>)anyObject { 协议有关、具体类型无关的方法调用 } 2、解耦的意义 需要理解解耦的目的，并不是一说架构就是解耦 后语 每过段时间都会审视自己的代码，重构是个苦力活，特别是代码量比较大，逻辑较为复杂的项目，别看这篇文章三言两语，因为都是些结论。
1.6K11发布于 2019-07-18 Dify 基于 TiDB 的数据架构重构实践
这种架构的意义远不止于技术整合。它体现了 Dify.AI 如何将整个数据基础设施整合为一个统一系统，实现从数据采集到 AI 驱动应用的全流程数据管理。 该架构分为以下四层：用户交互层：从一个简洁易用的界面开始，用户可以输入数据和查询指令与系统交互。用户交互层是吸引用户并确保交互过程顺畅的关键所在。 Dify.AI 将数十万个数据库整合至单一的 TiDB Cloud，极大地简化了基础设施架构，显著降低了操作复杂性与维护成本。 这一方案最吸引人的地方在于，通过引入 TiDB 带来的这种架构革新，让我们能够在一套系统中同时处理传统数据库操作和 AI 特有的向量相似性搜索，这不仅是基础架构升级，更是一次对平台构建和未来扩展方式的根本性变革 简化架构：将多套专用数据库整合为一个统一系统，大幅降低运维复杂性。提升性能：优化传统操作与向量操作的查询模式，显著提高数据处理效率。
63310编辑于 2025-04-10- 来自专栏Java职业技术分享
Java架构：一文读懂微服务架构的重构策略
通过开发所谓的绞杀者应用程序(strangler application)，可以逐步将单体架构转换为微服务架构。 它通常是一种快速展示微服务价值的方法，有助于让迁移和重构的工作获得公司内部各个层面支持。另外两种策略打破了单体。 对了，你还需要重构数据库。 提取服务通常很耗时，尤其是当单体的代码库很混乱时。因此，你需要仔细考虑要提取的服务。应当重点关注重构那些能够提供很多价值的应用程序部分。 延迟并可能避免进行这些昂贵更改的一种好方法是使用类似于《数据库重构》一书中描述的方法。重构数据库的一个主要障碍是更改该数据库的所有客户端以使用新模式。 你应该花费很短的时间，例如几周，集思广益讨论理想架构并定义一组服务。这将为你提供一个目标。但是，重要的是要记住，这种架构并非一成不变。
95960发布于 2019-05-28 - 来自专栏Linyb极客之路
唯品会架构师是如何实现架构重构的
随着唯品会业务的快速发展，订单量的不断增长，原有的订单存储架构已经不能满足公司的发展了，特别是在大促高峰期，原订单库已经成为抢购瓶颈，已经严重制约公司的发展。 唯品会旧订单库包含几十张订单相关表，旧订单库是典型的一主多从架构；主库容量已接近服务器物理空间上限，同时也已经达到 MySQL 的处理上限，很快将无法再处理新增订单。 占用的硬盘空间已经接近了服务器的硬盘极限，很快将无空间可用； 2、性能问题 单一服务器处理能力是有限的，单一订单库的 TPS 也有上限，不管如何优化，总会有达到上限，这限制了单位时间的订单处理能力，这个问题在大促时更加明显，如果不重构 总结与思考 本文是对唯品会订单库重构——采用分库分表策略对原订单库表进行拆分的粗略总结，在订单库重构过程中遇到的问题远远超过这些，比如：历史数据的迁移、各外围系统的对接等，但这些在公司强大的技术团队面前
1.2K21发布于 2018-12-19 - 来自专栏开发经验
微服务架构的黄金法则：拆分、重构、扩展
实践中的微服务架构 4.1 版本管理 4.2 数据一致性 4.3 安全性 结论 欢迎来到架构设计专栏~微服务架构的黄金法则：拆分、重构、扩展 ☆* o(≧▽≦)o *☆嗨~我是IT·陈寒 ✨博客主页 然而，要成功实施微服务架构，需要遵循一些关键的黄金法则，包括拆分、重构和扩展。本文将深入探讨这些法则，并提供示例代码以便于理解。 1. 扩展（Scale） 一旦微服务架构完成拆分和重构，接下来的挑战是如何扩展每个微服务，以满足不断增长的需求。 实践中的微服务架构 微服务架构的黄金法则在实践中是相互关联的，开发团队需要不断拆分、重构和扩展微服务，以适应不断变化的需求。 结论 微服务架构的黄金法则——拆分、重构、扩展，是实施微服务架构的关键步骤。通过遵循这些法则，开发团队可以更好地管理和维护微服务，实现高可维护性、可扩展性和高性能的应用程序。
73210编辑于 2023-12-13 - 来自专栏SpringCloud专栏
京东app后台多端融合架构代码重构实战
一 简介 重构是一个非常常见且古老的课题，涉及重构的文章、书更是不可胜数。 有的来源需要执行逻辑ABC，有的来源需要执行BCD，有的只需要执行BC，并且不同的来源返回值也有所不同，这就对之前的单一来源的系统架构产生了较大的冲击，如果处理不当，则不可避免地出现大量的if-else 那么针对这种情况，以及对提高系统整体配置化率的诉求，我们对后台架构做了一次重构。本文就是对重构内容做的一个浓缩后的抽象讲解，线上实战性质，非单纯设计模式类的demo。 我们该如何支撑这种可能随时增删改模块和来源的业务架构呢？ 三 原始问题点——复杂的排列组合 当多个层级均出现了多个变量时，这个系统的逻辑就变成了一个复杂的排列组合问题。 在重构前，代码进入主流程后，如下图，就是简单地根据refer来决定是否走哪些模块、返回哪些参数。
1.1K31编辑于 2021-12-09 - 来自专栏腾讯Bugly的专栏
微信Android模块化架构重构实践
为此，微信开启了第三次架构改造(v3.x)。我们对各种产品功能进行解耦并拆分到相互独立的p_xxx工程中，这是微信第一次进行模块化架构的重构。 新的p工程架构支撑了微信更快速的业务发展，配合多分支开发模式的改进，能够支持团队多分支多team的并行开发。 图2 - 架构图 为何再次重构微信 原本好好的架构出了什么问题？ 所以当我们重新审视代码架构时，以前良好模块化的架构设计已经逐渐变了样。 图3 - 架构逐渐的变化 “君有疾在腠理，不治将恐深”，在我们还在犹豫到底要不要重构的时候，硬件同学向我们提出了需求。 取舍和选择 对于架构重构，我们也曾放眼行业内已经发布过的各种方案，希望从中找到一些解决思路。 我们参考了很多业界开放和发表的架构设计。 最后 重构整体架构不是一件容易事，通常也不太可能让整个团队停下来只做重构。所以一直以来微信的重构都是随着版本迭代进行“拆分”-> “灰度” -> “回流”的循环节奏。
1.6K51编辑于 2023-04-02 - 来自专栏phodal
回到单体架构：一个开源项目的重构
…… 其中，最有意思的一个故事莫过于：从微服务到单体架构。因为，它是一种反主流的形式，又或者是反主流的技术架构。 复杂的部署架构。同样是工具，对比于 Jenkins/Sonarqube 的部署方式，相对较为复杂。 不一定合理的服务划分。 考虑采用 DDD （领域驱动设计）分层架构来划分，以方便未来拆分为微服务。 在这个场景之下，几乎违反了上面的一系列规则。所以，我就回到了上述的 6 中去，采用 DDD 的分层架构模式。 原因诸如于： 单体部署架构决定应用架构。使用 Docker，尽管 Saas 也是更友好的。但是，作为一个刚起步的开源项目，并不会资金来支撑这种规模的 SaaS 服务。 最终用户是开发者。 所以，常规的软件开发架构，并不一定适用，我们需要一些更好的模式。 那么，我们还有别的选择吗？ 我们的目标架构是单体吗？ 从某种意义上，就当前来说，它是的。
79560编辑于 2022-03-04 - 来自专栏北京马哥教育
从西直门立交桥谈IT架构与重构（干货）
今天主要跟大家分享的，是近几年来我在网站、应用、信息系统等方面，架构与重构的一些经验与心得。 当网站或应用，已经到了让开发者、运营者、运维者，感觉无奈、疲惫时，重构的时机到来了。 架构师在对应用进行重构时，首先要考虑哪些点呢？ 有过这样一句话：架构靠业务，重构重功力。我非常认同后半句。 问：在架构领域里面，其实是分企业架构和技术架构的。我想你想更多的表达纯粹的技术架构。 最后，在我的建议和带领下，研发部门组建了重构组，由两名架构师、一名安全顾问、一名数据顾问和N名程序员组成。 问：这期间你需要了解业务，梳理业务流程吗 答：无论架构或重构，对业务都是需要充分理解的。 问：重构分布式系统，往往牵扯太多，感觉需要及时重构 答：嗯，分布式系统是最难把控的。
90570发布于 2018-05-03 《GIL移除下Python并发架构重构实操手册》
，重构的核心起点便是打破全局锁带来的粗粒度管控惯性。 这种语义重构的核心价值，在于让并发语义成为底层机制的上层抽象，既保留了底层优化的灵活性，又让开发者能够摆脱繁琐的底层同步细节，聚焦于业务逻辑的实现，真正降低了并发编程的技术门槛。 生态工具链的适配重构是GIL移除后Python新并发模型落地普及的关键支撑，第三方库与运行时环境的协同优化程度，直接决定了新并发模型的实际实用性与生态兼容性，而重构的核心原则是分层适配，而非要求所有库进行全盘重写 GIL移除带来的Python并发模型重构，本质上是一次全层级的分层进化，从底层的调度机制与内存管理，到中层的并发语义与生态工具链，再到上层的开发范式，每个层级都在建立新的协同关系，而非简单的技术替代，这种重构并非一蹴而就的工程 各层级的重构并非孤立进行，而是形成了相互支撑、相互适配的闭环，底层的偏向引用计数与细粒度调度机制，为中层的并发语义提供了底层支撑，而并发语义则成为上层开发范式的具象化规则，生态工具链的适配重构则让底层机制与上层语义能够落地到实际的业务场景中
17410编辑于 2026-01-23- 来自专栏微信终端开发团队的专栏
微信 Android 模块化架构重构实践（下）
作者：carlguo 接上篇：《微信 Android 模块化架构重构实践（上）》 取舍和选择 对于架构重构，我们也曾放眼行业内已经发布过的各种方案，希望从中找到一些解决思路。 我们参考了很多业界开放和发表的架构设计。总的来说，目前Android端App整体架设计上，除了聚焦在“大前端”之外，基本上都在“插件化/应用沙盒”上面下功夫。 在微信的角度看，我们最关心的问题是如何能约束住代码边界，如何防止架构劣化，如何提高开发效率。这样的情况下，重新审视了具备动态性的插件化和沙盒方案。 所以不定期的推动一些模块的重构，将一些对代码的不满释放出来，是一种不错的激活。 此外在重构之后，还要考虑引导开发的代码组织方式切换，多用模板、正确的代码实例等，让他们可以放心参考。 最后 重构整体架构不是一件容易事，通常也不太可能让整个团队停下来只做重构。所以一直以来微信的重构都是随着版本迭代进行“拆分”-> “灰度” -> “回流”的循环节奏。
5K51发布于 2017-08-08
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号