- 博客(567)
- 资源 (17)
- 收藏
- 关注
原创 【架构实战】API网关设计与演进:从Nginx到自研网关
Nginx + OpenResty 是顶配起点:单机 50 万 QPS,但配置难以管理Kong 是成熟的过渡方案:Plugin 体系 + 管理后台,适合中等规模场景自研网关是终局选择:当路由规则从几十条变成几百条、灰度策略从按 Header 变成按用户画像时,你需要一个"懂业务"的网关教训网关的瓶颈永远不在网关本身——在后端服务的响应速度。网关引入的延迟应控制在 1ms 以内配置管理比性能更重要——10 万 QPS 够了,但 5000 行 Nginx 配置的风险远超性能不足。
2026-07-04 09:02:36
51
原创 【架构实战】本地消息表:最终一致性的低成本实现方案
本地消息表是一种基于数据库事务保证消息可靠投递的最终一致性方案。把业务操作和消息记录放在同一个数据库事务里,利用 ACID 特性保证原子性。│ 本地消息表方案 ││ ││ │ 业务服务 │ ││ │ │ ││ │ ┌─────┐ │ 同一个事务 ││ │ │业务表│◄─┼──┤ INSERT INTO 业务表 │ ││ │ └─────┘ │ │ INSERT INTO 消息表 │ ││ │ │消息表│ │ ┌─────────────────┐ │。
2026-07-03 14:57:55
212
原创 【架构实战】Saga分布式事务:长事务的拆解与补偿设计
Saga是Hector Garcia-Molina和Kenneth Salem在1987年提出的长事务解决方案。将一个跨多个服务的分布式事务拆解为一系列本地事务,每个本地事务有对应的补偿事务,用于回滚。Saga事务 = T1 → T2 → T3 → ... → Tn补偿链 = C1 ← C2 ← C3 ← ... ← Cn其中:Ti:正向事务(执行业务操作)Ci:补偿事务(撤销Ti的效果)与ACID事务的本质区别维度ACID事务Saga事务范围单数据库内跨多个服务/数据库隔离性。
2026-07-02 14:57:47
252
原创 【架构实战】整洁架构Clean Architecture:分层之道与依赖规则
/ 输入端口:支付用例// 输出端口:支付网关// 输出端口:支付仓储// 输出端口:账户服务// 用例的输入和输出DTO@Data@Builder@Data@Builder整洁架构的本质不是画几个同心圆,而是通过严格的依赖规则让核心业务逻辑不被框架绑架、不被数据库定义、不被外部系统左右。核心原则依赖只能向内:外层依赖内层,内层不知道外层边界是接口:用例层定义端口接口,适配器层实现业务规则集中:企业级规则在实体层,应用级规则在用例层。
2026-07-02 09:00:20
882
原创 【架构实战】CQRS命令查询职责分离:读写分离的进阶实践
CQRS(Command Query Responsibility Segregation,命令查询职责分离)是Greg Young在2010年提出的一种架构模式。将系统的读操作和写操作分离到不同的模型。【传统架构】││ Service │ ← 读写混合,一个模型同时处理││ │ ││ 查询1 │ │ 写入 │ │ 查询2 ││ (报表) │ │ (下单) │ │ (详情) │【CQRS架构】│ 应用层 │││ ││ 命令模型 │ │ 查询模型 │。
2026-06-30 14:59:10
224
原创 【架构实战】领域驱动设计DDD:复杂业务系统的建模与落地
将业务领域的核心逻辑封装在领域模型中,代码结构与业务结构保持一致。关键转变【贫血模型】Entity(只有 getter/setter)↓Service(承载所有业务逻辑,越来越胖)↓数据库(数据存储)【充血模型(DDD)】聚合根(Aggregate Root,封装业务规则和行为)↓实体(Entity,有唯一标识和业务行为)↓值对象(Value Object,无标识,不可变)↓领域服务(Domain Service,处理跨聚合的业务逻辑)DDD不是银弹,它是一套。
2026-06-30 08:59:33
340
原创 【架构实战】客服系统架构:智能客服降本增效
智能客服核心:知识库 + NLP + 多轮对话。智能客服是"降本"利器,但不能完全替代人工,关键问题仍需人工介入。个人观点,仅供参考。
2026-06-29 16:57:39
214
原创 【架构实战】服务降级与容灾设计:高可用系统的最后一道防线
服务降级(Service Degradation)是指在系统面临压力、故障或资源紧张时,主动降低某些服务的质量或功能级别,以保证系统整体的稳定性和核心功能的可用性。降级不等于失败,而是有策略地"减配运行"。服务降级是系统设计中常被低估但至关重要的一环。限流和熔断解决的问题是"不让系统坏掉",而降级解决的是"系统坏了也能用"。核心要点降级是无损架构的补充,100%可靠的系统不存在分级降级是核心设计,从轻度读到重度拒绝自动化比手动重要,自动触发+自动恢复降级需要常态化演练,没验证过的降级等于没有。
2026-06-29 15:54:30
429
原创 【架构实战】分布式事务最终一致性:从理论到工程实践
分布式事务最终一致性是微服务架构的核心挑战,没有银弹,需要根据业务场景选择合适的技术方案。核心要点理解CAP和BASE理论,在一致性和可用性之间权衡Saga模式适合大多数业务场景,优先采用编排式TCC提供更强一致性,但实现复杂度高事务消息适合异步解耦场景幂等性、对账、监控是保障一致性的"三板斧"未来演进服务网格(Service Mesh)提供分布式事务基础设施Dapr等框架提供简化的分布式事务API云原生场景下的分布式事务标准化。
2026-06-29 09:00:59
348
原创 【架构实战】事件驱动架构:从异步解耦到最终一致性的落地之道
定义:事件驱动架构是一种软件架构模式,系统通过"事件"进行通信,事件的产生者不直接调用消费者,而是发布事件到事件总线,消费者订阅并处理事件。核心三要素事件:状态变化的事实,如事件生产者:产生事件的服务,只负责发布事件,不关心谁消费事件消费者:订阅事件并执行业务逻辑,可以多个消费者并行处理架构对比【同步调用架构】订单服务 ──HTTP调用──> 库存服务 ──HTTP调用──> 积分服务│ │└──────────HTTP调用──> 优惠券服务 ────────┘。
2026-06-28 15:07:12
311
原创 【架构实战】消息队列选型完全指南:Kafka、RocketMQ、RabbitMQ深度对比
日志/大数据/流处理 →Kafka交易/订单/分布式事务 →RocketMQ轻量解耦/小系统 →RabbitMQ没有最好的消息队列,只有最适合的消息队列。技术选型时,不要追新,不要炫技,把业务需求吃透,再去匹配技术能力。很多系统的故障,根源不在消息队列本身,而在于对消息队列能力的误用。你们系统目前用的是什么消息队列?有没有踩过什么坑?欢迎评论区分享!个人观点,仅供参考。
2026-06-28 09:00:04
377
原创 【架构实战】从百到千万QPS:我的系统架构演进血泪史
写时先更新DB,再删缓存(而不是更新缓存)。单机跑得好好的,不要为了"未来可能的大流量"就上微服务。架构没有最优,只有最适合。每个阶段解决当时最痛的问题,这就是最好的架构。架构稳定了,但资源利用率低——平时30%利用率,大促时又不够。引入MQ后,系统变成了最终一致性。团队从最初的3个人发展到20人,服务器从8台到200+容器。2019年初,我们产品上线半年,日活从几千暴涨到50万。我们最终选了RocketMQ,因为有事务消息需求。同步调用的扩展性有天花板,必须上消息队列。这不是技术不行,是架构撑不住了。
2026-06-27 08:59:28
445
原创 【架构实战】实时计算架构:Flink处理亿级数据流
组件作用选型消息队列数据缓冲Kafka计算引擎实时处理Flink状态存储状态管理RocksDB结果存储结果输出Redis/ES实时计算是数据的"高速公路",搭建好了,数据才能流得快。个人观点,仅供参考。
2026-06-24 14:58:11
519
原创 【架构实战】推荐系统架构:从千人一面到千人千面
阶段方法目的召回多路召回查全率排序精排模型查准率重排多样性控制用户体验推荐系统是流量分发器,好的推荐能显著提升转化率。个人观点,仅供参考。
2026-06-24 09:14:48
311
原创 【架构实战】搜索系统架构:从LIKE查询到ES的演进
方案QPS延迟功能复杂度LIKE查询100秒级简单低全文索引1000毫秒级中等中ES10000+毫秒级丰富高搜索是用户找商品的入口,性能差直接影响转化率。个人观点,仅供参考。
2026-06-23 14:57:48
573
原创 【架构实战】账户系统架构:资金安全是底线
要点说明原子性余额更新和流水记录同一事务一致性余额 = 流水汇总,每日对账幂等性业务订单号去重可追溯所有操作有记录安全性敏感操作有审批资金安全是底线。账户系统出问题,不是丢数据,是丢信任。个人观点,仅供参考。
2026-06-23 08:59:00
997
原创 【架构实战】库存系统架构:扣减并发10万的背后
方案QPS一致性复杂度适用场景数据库悲观锁500强低小规模数据库乐观锁5000强低中等规模Redis同步10万+弱中大规模Redis异步10万+最终高超大规模库存系统是电商的心脏,设计不当会导致超卖或漏卖,直接影响收入和用户信任。个人观点,仅供参考。
2026-06-22 14:57:48
502
原创 【架构实战】DevOps流水线:从代码到上线的自动化
DevOps流水线建设的关键要点:规范先行:在搭建流水线之前,先规范Git分支策略、代码审查流程、发布流程小步快跑:不要一开始就追求完美,先实现基础的CI,再逐步添加CD能力自动化一切:重复的事情一定要自动化,人工操作必然出错可观测性:构建过程、部署过程必须有完整的日志和监控,出问题能快速定位安全第一:敏感信息不要写在代码里,使用Vault或KMS管理密钥容错设计:任何自动化步骤都要考虑失败情况,要有回滚预案永远不要相信"手动操作小心一点就没问题"。人是会犯错的,而自动化不会。
2026-06-21 08:57:57
241
原创 【架构实战】电商秒杀架构:高并发场景的终极挑战
优化点实现方案解决什么问题前端优化CDN静态化、按钮置灰、答题验证码减少无效请求,削峰填谷网关限流全局QPS限流、IP限流、用户限流防止流量冲垮系统Redis预减库存DECR原子操作、热点Key不过期减少DB压力,快速响应用户MQ异步下单持久化、Confirm机制、手动ACK削峰填谷,提升系统吞吐量幂等设计唯一RequestId、Redis去重防止重复下单,避免超卖乐观锁扣库存版本号+库存校验保证DB库存一致性,防止超卖缓存优化互斥锁、随机TTL、热点Key保护。
2026-06-20 14:57:53
246
原创 【架构实战】服务降级与熔断:Hystrix到Sentinel的演进
从Hystrix到Sentinel的演进,本质上是分布式服务容错从"基础熔断"到"全链路流量治理"的升级。Hystrix解决了早期微服务熔断的问题,但由于线程池隔离的局限性和维护停滞,逐渐被Sentinel取代。Sentinel凭借轻量级的隔离、动态的规则配置、丰富的流量控制策略,成为当前分布式系统容错的首选方案。对于还在使用Hystrix的系统,建议逐步迁移到Sentinel:可以先在新业务中使用Sentinel,老业务保留Hystrix,逐步替换;
2026-06-20 08:57:54
314
原创 【架构实战】性能调优方法论:系统化提升性能
指标优化前优化后提升幅度P50 响应时间200ms30ms6.7xP95 响应时间1500ms80ms18.75xP99 响应时间3000ms180ms16.7x数据库连接数502550% 节省服务器 CPU 使用率35%(大量等待)15%(真正计算)更高效Full GC 频率每5分钟一次每天1-2次95% 减少系统吞吐量2000 TPS8000 TPS4x最终 P99 从 3 秒降到了 180ms,远超最初设定的 200ms 目标。
2026-06-19 14:57:55
238
原创 【架构实战】API网关限流:保护后端的第一道防线
*** 限流Key解析器*//*** 基于IP的限流*/@Bean// X-Forwarded-For头处理(如果经过代理)/*** 基于用户的限流(需要登录)*/@Beanif (auth!// 未登录用户,使用IP/*** 基于接口的限流(对不同接口设置不同限流阈值)*/@Bean// 高频接口(写操作):更严格的限流// 低频接口(读操作):宽松限流// 默认API网关限流的关键要点:层次化限流。
2026-06-18 15:10:57
212
原创 【架构实战】安全架构设计:让攻击者无从下手
安全架构的关键要点:纵深防御:不要依赖单一安全措施,多层防护默认安全:安全应该是默认配置,不是可选功能最小权限:只授予必要的权限,不过度授权日志审计:所有操作都要有日志,方便溯源定期渗透测试:请专业团队定期做渗透测试安全培训:提高全员安全意识不要觉得"这只是内部接口"就不做安全。攻击者永远比你想象的更执着。你们系统有哪些接口可能存在安全漏洞?如果发现系统在遭受攻击,你能在几分钟内止血?个人观点,仅供参考。
2026-06-18 08:58:04
364
原创 【架构实战】云原生架构设计:从传统架构到云原生的蜕变
容器化:环境一致,快速部署编排:Kubernetes自动化管理微服务:独立部署,独立扩缩容服务网格:流量管理,可观测性声明式配置:GitOps,以代码管理基础设施云原生不是目的,提升交付效率才是。个人观点,仅供参考。
2026-06-17 17:09:15
501
原创 【架构实战】DevOps工程化体系:从混乱到秩序
规范先行:分支策略、代码规范、提交流程测试为本:测试金字塔,自动化测试流水线自动化:CI/CD,减少人工干预监控告警:构建状态、部署结果、线上质量好的工程化体系,不是让开发变慢,而是让开发更快、更安全。个人观点,仅供参考。
2026-06-17 09:11:42
313
原创 【架构实战】全链路压测:上线前的最后一道关卡
我们压测了下单接口,QPS能到1万。压测发现性能不行,但不知道瓶颈在哪。压测产生的订单数据混入了生产订单,运营同事以为是真实订单,导致发货错误。我们在白天高峰期压测,压测流量和真实流量混在一起,导致真实用户响应变慢。信心满满,没有做全链路压测,只是单接口压了一下,觉得没问题。从那以后,大促前必须全链路压测,用压测数据指导容量规划。:压测完出了报告,但没有优化,大促时照样挂。:压测数据写入了生产数据库,导致数据混乱。:压测占用了大量资源,真实用户体验下降。:单个接口没问题,但完整链路有瓶颈。
2026-06-16 17:56:43
290
原创 【架构实战】技术债务管理:欠的债迟早要还
我们曾计划一次大重构,花了2个月。期间业务方催新功能,团队压力很大,最终重构没完成就草草收场。项目赶进度时,大家说"先这样,后面再优化"。我们一直在还债,但不知道还了多少,也不知道还有多少。花大力气重构了代码,但过了几个月又变烂了。还债任务总是被排在最后,大家都觉得"不影响业务,不着急"。终于恢复了正常的开发节奏,Bug率下降了70%。:花了2个月重构,期间没有新功能,业务方不满意。:不知道技术债有多少,也不知道还了多少。:大家都想做新功能,没人愿意还技术债。:每次赶进度都欠技术债,但从来不还。
2026-06-15 14:59:15
279
原创 【架构实战】架构评审方法论:让每个决策经得起考验
每次评审会,大家都说"没问题",结果上线后问题一堆。因为大家觉得"反正是架构师定的,出了问题也是他的责任"。过了几个月,大家忘了当时的决策理由,出了问题不知道为什么这样设计。评审发现设计有问题,但代码都写完了,改不动。评审会上提了10条意见,会后没人跟进,项目上线后发现问题还在。:参加评审的人都不了解业务,提不出有价值的意见。如果当时做了评审,这些问题在5分钟内就会被发现。:评审讨论了很多,但没有记录,后来忘了。:评审提了很多意见,但没有跟进落实。:方案已经开发完了才评审,改不动了。
2026-06-15 09:03:54
712
原创 【架构实战】Docker容器化:从镜像到部署的完整实践
在16GB内存的机器上,堆大小变成4GB,超出容器限制,被OOMKilled。order-service调用user-service,报"Connection refused",但两个容器都在运行。标签,某天误推了一个有bug的版本,所有环境都受影响,无法回滚到之前的版本。2020年,我们的Docker镜像有1GB,启动时间长达3分钟。排查问题时,看日志时间是上午10点,但实际是下午6点,差点误判。,容器重启后日志还在积累,最终撑满磁盘。:每次构建都从零开始,耗时很长。:日志写在容器内,磁盘被撑满。
2026-06-14 15:02:58
254
原创 【架构实战】灰度发布实战:安全上线不翻车
原则说明小步快跑对比监控新旧版本指标对比自动回滚错误率超阈值自动回滚向前兼容数据库变更要兼容完整回滚应用+配置+数据一起回滚每一次全量发布都是在赌命。灰度发布不是浪费时间,是买保险。你的团队是怎么做灰度发布的?个人观点,仅供参考。
2026-06-12 14:58:23
204
原创 【架构实战】数据脱敏与隐私保护:合规是底线
层面方案传输HTTPS + 字段加密存储数据库字段加密展示脱敏返回日志自动脱敏密钥KMS管理数据安全不是可选项。一次数据泄露的代价,远超安全建设的成本。你的系统做了哪些数据脱敏措施?个人观点,仅供参考。
2026-06-12 08:58:18
244
原创 【架构实战】分布式会话:从Session到JWT的演进
场景推荐传统Web移动端/APIJWT需要主动失效JWT + Redis黑名单SSOJWT只存必要信息Access Token短有效期(2小时)Refresh Token长有效期(7天)Token安全存储做好Token刷新和失效JWT不是万能的。无状态是优势也是劣势,选择方案前先想清楚你的业务需要什么。你的系统用了什么会话管理方案?个人观点,仅供参考。
2026-06-10 14:58:26
259
原创 【架构实战】注册中心选型:Nacos vs Eureka vs Consul
我们用namespace区分dev/test/prod环境,但有个服务的配置没指定namespace,默认用了public,结果覆盖了其他环境的配置。我们有个服务因为死锁卡住了,但心跳线程还在,Nacos认为服务健康,继续把流量打过去,导致大量请求超时。更悲剧的是,我们的熔断器配置了"当实例数为0时直接熔断",导致整个服务链路瞬间熔断,用户下单全部失败。凌晨批量发布,几百个服务同时启动注册,Nacos扛不住,注册延迟长达30秒,导致服务启动后找不到依赖。迁移成本极高,选型时一定要考虑长远。
2026-06-10 08:58:20
270
原创 【架构实战】网关架构设计:微服务的统一入口
功能方案路由鉴权限流熔断灰度自定义路由规则监控网关多实例部署只做轻量操作统一鉴权和限流合理的超时配置完善的监控告警网关是微服务的大门。门没守好,再多的内部安全措施也白搭。你的系统用了什么网关方案?有没有踩过坑?个人观点,仅供参考。
2026-06-09 14:58:08
321
原创 【架构实战】对象存储架构:从NAS到OSS的演进
原则说明私有Bucket默认私有,需要签名才能访问预签名URL临时授权访问秒传MD5去重生命周期自动清理过期文件图片处理自动压缩、缩略图防盗链Referer白名单文件存储不是"能存就行"。安全、成本、性能,每一个都要考虑清楚。你的系统用了什么文件存储方案?个人观点,仅供参考。
2026-06-08 14:58:33
211
原创 【架构实战】日志体系设计:从ELK到可观测性的演进
环节方案规范统一格式、级别、脱敏采集存储展示Kibana告警ElastAlert链路统一JSON格式日志MDC传递链路信息生产环境关闭DEBUG日志脱敏告警及时好的日志体系不是锦上添花,是雪中送炭。出问题时,日志是你唯一的救命稻草。你的日志体系是怎样的?排查问题快吗?个人观点,仅供参考。
2026-06-06 08:58:13
282
原创 【架构实战】分布式缓存策略:从缓存穿透到缓存雪崩的全链路防护
问题方案穿透布隆过滤器 + 空值缓存击穿互斥锁 + 逻辑过期雪崩随机过期 + 多级缓存 + 熔断一致性延迟双删 + Canal永远设置随机过期时间热点数据用逻辑过期多级缓存保底缓存和数据库一致性用Canal大促前做好缓存预热缓存不是万能的,没有缓存是万万不能的。用好了是加速器,用不好是定时炸弹。你的系统有没有遇到过缓存问题?怎么解决的?个人观点,仅供参考。
2026-06-05 14:58:19
240
原创 【架构实战】线程池设计:高并发系统的资源管理艺术
*** 自定义拒绝策略:记录日志 + 降级处理*/@Slf4j@Overridelog.error("线程池拒绝执行: pool={}, active={}, queue={}, completed={}",executor,// 降级方案1:尝试再次入队(等待1秒)try {if (!log.error("再次入队失败,执行降级处理");// 降级方案2:记录到数据库,后续重试log.error("等待入队被中断");// 将任务保存到数据库或消息队列,后续重试。
2026-06-05 08:58:20
247
原创 【架构实战】分布式事务Saga模式:长事务的优雅解决方案
Saga模式:将一个长事务拆分成多个本地事务,每个本地事务完成后,通过消息或事件触发下一个本地事务。如果某个步骤失败,则反向执行之前所有步骤的补偿操作。正向执行:T1 → T2 → T3 → T4 → 完成补偿回滚:T1 → T2 → T3(失败) → C2 → C1vs TCC:- Saga:只有正向操作和补偿操作,没有try阶段- TCC:有try/confirm/cancel三个阶段- Saga更适合长事务,TCC更适合短事务/*** Saga定义*/@Data。
2026-06-04 14:58:15
236
界面完美,多平台应用的航空订票系统
2009-10-10
eCharts全国及各省、市、县三级下钻数据(珍藏版)
2018-11-15
支持多种数据库数据一直的最好的工具
2009-10-10
java相关开发的ppt
2009-09-20
ie上的firebug,好用
2010-07-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅