面汤放盐(uzong)
码龄11年
求更新 关注
提问 私信
  • 博客:1,548,729
    社区:3
    1,548,732
    总访问量
  • 293
    原创
  • 4,381
    排名
  • 991
    粉丝
  • 2
    关注
IP属地以运营商信息为准,境内显示到省(区、市),境外显示到国家(地区)
IP 属地:重庆市
加入CSDN时间: 2015-09-08

个人简介:专注架构设计、AI工程化与高并发实战;分享云原生落地、技术项目管理与工程师成长思维;从微服务治理到系统架构,从模型部署到业务突围,持续输出一线实战总结与技术复盘

博客简介:

uzong

博客描述:
好好学习,天天向上
查看详细资料
个人成就
  • 获得2,607次点赞
  • 内容获得144次评论
  • 获得4,649次收藏
  • 代码片获得3,724次分享
  • 原力等级
    原力等级
    5
    原力分
    1,821
    本月获得
    0
创作历程
  • 59篇
    2026年
  • 42篇
    2025年
  • 33篇
    2024年
  • 1篇
    2022年
  • 102篇
    2019年
  • 126篇
    2018年
成就勋章
TA的专栏
  • PostgreSQL
    31篇
  • SpringBoot starter 最佳实践与源码分析
    12篇
  • MySQL典型题目(leetcode)
    19篇
  • UML
    7篇
  • 深入理解Java虚拟机
    7篇
  • 设计模式之路
    10篇
  • SQL进阶笔记
    10篇
  • UML
    7篇

TA关注的专栏 2

TA关注的收藏夹 0

TA关注的社区 1

TA参与的活动 7

创作活动更多

AtomGit「码动四季·开源同行」秋季征稿活动

秋季征稿主题:开源成果经验分享 成果不止一种形态,我们为你准备了六大赛道,总有一款适合你: 开源项目成果复盘 把项目一年/一季的成长摊开来看:里程碑复盘、Star 与用户增长复盘、版本迭代复盘、从 0 到 1 的发布复盘。 🖊️ 示范选题: ●开源项目从 0 到 1000 Star,我做对了什么 ●开源一周年,我交出的成绩单 这类文章不只是一次经验分享,也是一张项目名片。欢迎将项目托管到 AtomGit 并申请成为 G-Star 项目,通过后可获得平台流量推荐、项目宣传等权益。(G-Star:AtomGit 最具影响力开源项目) ![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/1f90c61528ad410d8d66f9d0e3707a5a.png) 咨询 G-Star 项目申请 2️⃣ 技术经验体系化沉淀 踩坑合集、最佳实践总结、工具链实战、CI/CD 流水线搭建、代码重构与架构演进。 🖊️ 示范选题: ●提了 50 个 PR 后,我总结的开源协作避坑清单 ●一次重大重构复盘:把单体拆成可维护的模块 3️⃣ AI 赋能开源的实战成果 AI 编程助手实战测评、基于开源模型的微调与应用开发、AI 辅助研发提效流水线。 🖊️ 示范选题: ●我用 AI 编程助手把提 PR 效率翻了 3 倍 ●基于开源大模型搭了个 XX 工具(附完整教程) 4️⃣ 开源共建笔记|文档、社区与布道 开源文档写作与翻译、issue 互助经验、组织 meetup、用开源项目做教学与分享。 🖊️ 示范选题: ●一个优秀开源项目,文档应该怎么写 ●我用开源项目做了个线上 Workshop ![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/23e83ceebc594c379f7fc6aa8dcfa40c.png) 扫码加入码动四季投稿交流群,和更多伙伴一起交流技术!

16人参与 去参加
  • 最近
  • 专栏
  • 资源
  • 收藏
  • 关注/订阅/互动
  • 最近

  • 专栏

  • 资源

  • 收藏

  • 关注/订阅/互动

搜索 取消

业务新老系统数据迁移-负责人经验总结和复盘

【摘要】本文总结了业务系统数据迁移的实践经验,强调数据迁移本质是业务治理项目而非纯技术工作。关键要点包括:1)迁移前需明确业务与技术双重标准,建立数据字典对照表;2)方案设计需关注字段映射、数据清洗、迁移工具选择和应急机制;3)实施过程需分阶段执行,区分全量/增量数据,建立"作战室"协同;4)验收要以业务验证为准;5)注意事项包括测试环境验证、灰度发布和避免多租户问题。文章还分享了项目管理中的干系人协调、风险管控等经验教训,建议输出完整的迁移文档作为交付物。核心观点是数据迁移的成功标准在
原创
博文更新于 2026.08.15 ·
207 阅读 ·
5 点赞 ·
0 评论 ·
4 收藏

BFF 架构实践指南

本文是一份BFF架构实践指南,介绍了BFF(面向前端的后端)的概念、核心功能、代码实现及注意事项。BFF主要为不同前端客户端提供专属适配层,解决数据聚合和多端接口适配问题。文章详细对比了BFF与API网关的区别,阐述了BFF的数据聚合、多端定制API、统一异常处理等功能,并提供了两种数据聚合方式的代码示例(CompletableFuture和响应式编程)。同时,文章强调了避免代码复制、过度聚合等问题,提出了BFF的落地约束和拆分方案,最后提醒要根据实际业务需求决定是否采用BFF架构,避免盲目套用。
原创
博文更新于 2026.08.13 ·
432 阅读 ·
7 点赞 ·
0 评论 ·
5 收藏

把一面面试总结做成一个 Skill:重复的事,就别每次都重写

最近一段时间,我作为一面面试官,需要在一个月内集中完成不少技术面试。这些事情每次都不完全一样,但动作非常重复。
原创
博文更新于 2026.07.25 ·
184 阅读 ·
5 点赞 ·
0 评论 ·
6 收藏

一个好的面试官,应该让候选人感到被尊重

摘要: 优秀面试官的核心在于营造尊重、平等的交流氛围,注重专业性与真诚表达。面试不仅是能力筛选,更是公司文化的传递。关键要点包括:保持平等态度,避免压迫感;善于引导而非审问,帮助候选人打开思路;注重细节(准时、清晰反馈);在面试结尾真诚表达认可与期待。技术面试官代表公司形象,其专业度、耐心与尊重直接影响候选人对公司的判断。优秀的面试应聚焦候选人成长空间与业务价值,而非机械考核,从而吸引真正匹配的人才。
原创
博文更新于 2026.07.23 ·
196 阅读 ·
3 点赞 ·
0 评论 ·
3 收藏

企业智能助手的实践分享(LLM/RAG)

写Prompt请多一些耐心,把问题说清楚。few-shot 是效果最好的方式。(告诉LLM不胡编乱造)
原创
博文更新于 2026.06.11 ·
301 阅读 ·
8 点赞 ·
0 评论 ·
4 收藏

面试官:如何做好架构设计

摘要: 软件架构设计是一个持续演进的过程,而非一次性设计。它需要在正确方向指引下,通过实践不断迭代优化。宏观上,架构应遵循演进式原则(从简单到复杂)和因地制宜策略(适配业务需求与资源)。战术层面需关注可扩展性(弹性伸缩)和可观测性(监控、日志、链路追踪)。实施时需结合竞品分析、技术选型与业务理解,平衡资源、时间与团队能力。核心模式包括分层架构和微服务拆分,同时需遵循KISS、YAGNI、SOLID等黄金法则。架构师应注重技术为业务服务,优先简单方案,保持代码实践,避免过度设计。最终目标是构建灵活、健壮且可持
原创
博文更新于 2026.05.30 ·
277 阅读 ·
2 点赞 ·
0 评论 ·
5 收藏

分布式下的系统,什么是算是好的架构设计

本文探讨了分布式系统架构设计的核心要素与实践原则。架构设计本质上是多约束条件下的权衡过程,需从高可用性(负载均衡、容错设计、SLA)、可扩展性(水平/垂直切分、弹性扩缩容)、可观测性(监控、日志、链路追踪)和数据一致性(CAP定理、BASE理论)四个维度综合考量。关键设计原则包括:避免过度设计、预设故障场景、全面监控和幂等性实现。发布策略推荐蓝绿发布和金丝雀发布以降低风险。优秀的架构应具备持续演进能力,采用"做一年、看三年"的前瞻思维,在业务需求与技术可行性间取得平衡,通过实践闭环不断优
原创
博文更新于 2026.05.30 ·
394 阅读 ·
5 点赞 ·
0 评论 ·
3 收藏

新晋管理者应该关注的几个事情

有格局有肚量有定力。
原创
博文更新于 2026.05.30 ·
279 阅读 ·
7 点赞 ·
0 评论 ·
4 收藏

在大厂待了四年的过往反思

要事第一、明确轻重缓急。先完成后完美。总结复盘要及时,别错过黄金时间。一次性做好,避免返工。闭环思维。
原创
博文更新于 2026.05.30 ·
205 阅读 ·
8 点赞 ·
0 评论 ·
4 收藏

思考如何高效开会

高效开会需要做好会前、会中、会后全流程把控。会前提前发送材料并明确议题,避免临时拉人;会中由主持人把控节奏,防止跑题,及时总结共识;会后形成行动项清单,确保结论落地。核心是尊重时间,目标明确,避免无效讨论,让会议真正解决问题而非流于形式。
原创
博文更新于 2026.05.30 ·
215 阅读 ·
6 点赞 ·
0 评论 ·
4 收藏

这套AI技术栈可将你的人工智能成本削减80%

《低成本AI架构:从算力堆砌到系统优化》揭示了当前AI应用开发的核心痛点:高昂的运营成本。文章指出,80%的日常AI任务无需顶级大模型,并提出分层架构解决方案:1)智能路由分流请求;2)轻量模型处理基础任务;3)缓存机制复用结果;4)检索优先于生成;5)按需调用顶配资源。通过案例对比证明,优化后的架构可降低60-90%成本,同时保持性能。作者强调,未来AI竞争力不在于模型规模,而在于资源利用效率,建议开发者转向系统工程思维,构建智能调度体系而非单纯堆砌算力。
原创
博文更新于 2026.05.16 ·
525 阅读 ·
7 点赞 ·
0 评论 ·
14 收藏

每位工程师都必须掌握的十大数据库扩容策略

《数据库扩容十大核心策略解析》 摘要:本文系统梳理了数据库扩容的十大关键策略,从基础的垂直扩容到复杂的分片架构,为工程师提供应对业务增长的完整解决方案。垂直扩容虽简单但存在上限;读写分离有效分担读负载;分片技术实现真正横向扩展;表分区提升大表查询效率;缓存层缓解数据库压力;CQRS分离读写模型;反范式设计优化查询性能;异步写入提高吞吐量;索引优化加速检索;数据归档降低存储成本。文章强调,扩容策略选择需综合考虑业务特征、一致性要求和增长预期,建议采取渐进式架构演进:初期优化硬件和索引,中期引入缓存和分区,后期
原创
博文更新于 2026.05.09 ·
248 阅读 ·
4 点赞 ·
0 评论 ·
4 收藏

9 种 RAG 架构,每位 AI 开发者必学:完整实战指南

RAG通过让语言模型在生成回答前参考外部知识库来优化输出。模型不再纯粹依赖训练时学到的内容,而是从你们的文档、数据库或知识图谱中提取相关、最新的信息。用户提问系统从外部数据源检索相关信息将问题 + 检索结果一起交给模型模型基于这些真实信息生成答案不再只依赖模型训练数据,而是使用最新、可验证的信息。最好的系统不是最复杂的。而是在你的约束内可靠服务用户的那个。从简单开始。衡量一切。仅在明确证据表明需要时才扩展复杂性。先掌握基础。
原创
博文更新于 2026.05.03 ·
708 阅读 ·
7 点赞 ·
0 评论 ·
7 收藏

我研读了 500 个 Spring Boot 生产级代码库,90% 都犯了这 7 个致命错误

本文总结了SpringBoot生产环境中7个常见致命错误:数据库连接池配置过小、懒加载导致N+1查询、滥用@Transactional注解、异常被静默吞噬、Jackson序列化无限递归、生产环境配置缺失、盲目使用缓存。这些错误在500个代码库中出现率高达90%,导致系统崩溃、营收损失等严重后果。作者通过实际案例指出,这些问题往往因开发者不了解底层原理、依赖默认配置所致,建议上线前必须核查连接池大小、避免N+1查询、合理使用事务注解等关键点。文章强调生产环境不会为开发者的想当然兜底,正确配置是系统稳定运行的基
原创
博文更新于 2026.04.30 ·
470 阅读 ·
10 点赞 ·
0 评论 ·
10 收藏

TIOBE 指数:2026 年编程语言排行榜

TIOBE 指数由荷兰 TIOBE 软件公司自 2002 年起持续编制,长期追踪全球编程语言的流行度。该指数整合谷歌、必应、雅虎、维基百科、亚马逊、油管、百度等主流搜索引擎的检索数据。评判逻辑十分直白:某门语言的教程、技术文档、问题排查相关搜索量越高,代表其行业关注度与实际使用率越高。有批评者认为,这种统计方式更偏袒历史悠久、文档资料庞大且遗留项目繁多的老牌语言。而支持者则反驳,相比 GitHub 星标数、Stack Overflow 问卷调查,该方式更能真实反映行业实际开发生态。事实上,两种观点各有道理。
原创
博文更新于 2026.04.30 ·
1503 阅读 ·
9 点赞 ·
0 评论 ·
8 收藏

更简单的架构如何让我成为更好的高级开发者

摘要:文章分享了资深开发者通过简化架构提升系统质量的实践经验。作者指出,过度复杂的架构(如过早采用微服务、过度抽象、事件驱动等)往往导致系统脆弱难维护。通过5个案例展示了简化方法:1)仅在必要时拆分系统;2)避免过度抽象;3)选择简单而非花哨的架构;4)遵循YAGNI原则;5)减少过度配置。核心观点是:优秀系统始于简单,应通过去除不必要复杂性来保持可理解性,随着真实需求逐步演进而非预先优化。
原创
博文更新于 2026.04.28 ·
372 阅读 ·
8 点赞 ·
0 评论 ·
12 收藏

何时使用以及何时不应使用微服务:没有银弹

在这篇文章中,我们将学习何时使用以及何时不应使用微服务架构。图示:微服务架构通过这篇文章,我们将了解微服务架构的最佳应用场景,并使用微服务架构来设计我们的电子商务应用程序。
原创
博文更新于 2026.04.28 ·
413 阅读 ·
8 点赞 ·
0 评论 ·
9 收藏

架构对比:单体架构与微服务架构

本文比较了单体架构与微服务架构的差异。单体架构将应用作为单一单元开发部署,结构简单但耦合度高;微服务则将应用拆分为独立服务,灵活性高但复杂度大。文章从架构特征、扩展性、部署流程、团队需求等维度进行对比分析,并通过电子商务应用案例展示了两种架构的具体实现方式。最后指出架构选择应基于具体业务需求和技术能力,单体适合简单项目,微服务则更适合需要快速迭代的复杂系统。
原创
博文更新于 2026.04.28 ·
589 阅读 ·
9 点赞 ·
0 评论 ·
13 收藏

从单体架构到微服务架构:模式与最佳实践

本文探讨了如何从单体架构演进到微服务架构,重点介绍了设计模式、原则和最佳实践。文章首先分析了单体架构的优缺点,适用于小型应用程序但难以扩展。随后详细讲解了微服务架构的特征和优势,包括敏捷性、独立部署和数据隔离。关键部分阐述了微服务通信设计模式,如API网关模式、BFF模式和服务聚合模式,以及异步通信的发布-订阅模式。此外,文章介绍了CQRS和事件溯源等数据管理模式,最终提出事件驱动的微服务架构方案,推荐使用Apache Kafka和Spark等技术栈实现高扩展性和低延迟。这些模式和实践为构建云原生微服务系统
原创
博文更新于 2026.04.28 ·
1179 阅读 ·
37 点赞 ·
0 评论 ·
10 收藏

软件架构设计的考虑:如构建一个长生周期的系统

《软件系统的复杂性演化与设计之道》摘要:软件系统普遍经历从优雅到混乱的退化过程,这种现象被称为"泥球系统"。其根源在于系统设计未能随业务增长同步演进。软件设计的核心在于控制复杂性和隔离变化,通过模块化、高内聚、低耦合等原则构建可持续演化的系统架构。分层架构和服务化是应对规模扩张的有效手段,但需警惕过度设计。持续重构是维持系统健康的关键,而非一次性完成的任务。优秀的软件系统本质上是能够在长期演化中保持适应能力的系统,这需要团队始终坚持基础设计原则和技术债务管理。
原创
博文更新于 2026.04.28 ·
534 阅读 ·
15 点赞 ·
0 评论 ·
8 收藏
加载更多