事务性外发模式确保在对数据库进行更改时，消息总是会发布到消息代理，即使消息代理最初发生故障。这对于事件驱动架构来说至关重要，因为它可以确保当其他服务从您的事件中重建状态时的一致性。 0:00 网络故障 0:54 原子性事务 2:00 发布消息 2:52 至少一次投递 3:32 幂等性 4:14 结束语 Outbox Pattern | Drawing Boxes 翻译 […]
1 背景介绍 2 工作原理 2.1 短链接生成与存储 2.2 短链接返回与传播 2.3 用户点击与跳转 3 核心算法 3.1 哈希算法 3.2 分布式 ID 3.3 Base62 编码 4 安全与防护 4.1 长链接合法性校验 4.2 重复生成短链接防护策略 4.3 短链接有效性验证 5 系统性能优化 5.1 数据库索引 5.2 缓存应用 5.3 号段模式优化 5.4 分表 […]
本视频探索了事件溯源这一强大概念。通过事件溯源，系统不再只存储当前状态，而是记录每个状态变化作为事件。这允许我们能够追溯某一特定时间点的状态，并确保数据完整性。视频讲述了如何通过分析事件序列来优化审计和分析，同时解决了并发问题，确保系统的松散耦合。还介绍了乐观并发技术、状态快照、最终一致性等关键概念，以及事件溯源如何与CQRS和DDD结合使用，以实现更加高效和可靠的系统架构 […]
本视频详细介绍了领域驱动设计（DDD）的关键概念，包括统一语言、聚合根、领域事件、实体、值对象以及仓库等术语。DDD 的核心并非技术细节，而是强调软件设计的语言和结构应与业务领域对齐，从而构建出领域专家与技术人员都能理解的丰富模型。值对象（如颜色）应当是不可变且基于它们的值来比较相等性。实体（如轮胎）则通过唯一ID标识，即使属性相同也视为不同实例。领域事件表示领域中重要发生 […]
我们在《系统设计 | 如何表达技术架构？（规划篇）》中讨论了一个新的项目启动时如何表达技术架构，类似的我们还需要在敏捷项目的迭代前进行更细致的技术方案设计。 进入迭代的技术方案可以类比为瀑布模型中的详细设计，其目的是为了让迭代中的具体开发工作顺利进行。 本文，整理了一些日常项目上进入迭代前的技术方案输出物。 迭代技术方案的逻辑 迭代技术方案和规划类的技术方案不同，为了让迭代 […]
在多年软件开发的经验中，我看过各种各样的架构图和技术方案。其中不乏看到非常精美架构图，以及非常详细的技术方案。 非常遗憾的是，目前没有流传开的标准来规范架构图的绘制，不同公司架构文档风格也五花八门。如果说有 UML 这类图例标准，也非常古老了，大部分人也不怎么使用 UML 来设计架构图。 这会让很多架构师非常困惑，不知道如何上手，参考哪些材料来完成这类工作。 本文，整理了一 […]
分布式事务一直是微服务设计的一个难点，是解决业务一致性问题的重要手段，一直很谨慎不敢写这部分内容，担心水平不够弄错误导大家。 但是如果在项目上出现了跨服务的业务一致性需求，在网络上搜索出来的材料往往是一些理论和具体的框架使用，对问题场景的分析不多。 在和多个公司的架构师讨论后，大家的共识是：分布式事务很难有一个通用的解决方案，需要在场景中获得比较好的平衡，往往是捏着鼻子选择 […]
写作的价值不仅仅是传播想法，更在于总结和反馈。系统设计系列收到了一些读者的反馈和补充，定期整理更新。 时间方案中补充频率表达格式 在 《系统设计中需要考虑到的时间问题》文章中我们讨论了时间的标准化表达格式，在其中提到了 ISO-8601 规范。 其实 ISO-8601 中有非常多很有价值的表达方式，只不过使用不够频繁没有拿出来讲。我们应该尽可能使用现有的规范来实现业务，可以 […]
微服务架构中的一些概念非常模糊，业界往往没有取得共识。对于应用来说，其原因是业务背景多种多样，往往单一的模式不能满足现实需要。个人认为这是架构意识形态之争的根本原因。 今天来辨析一下微服务架构中 BFF，其含义和两种架构形态。 胖瘦 BFF 之争 我自 2015 年开始参与的所有应用系统都是服务化的了，都算比较大型的系统，这可能是解决大型复杂应用的必然之路。 在服务化的系统 […]
企业在使用微服务架构时，虽然会获得微服务架构的一些便利，但是也需要付出一些基础设施成本，而集成和部署就是其中一部分。 持续的集成和部署通常被叫做 CI/CD，意思是通过一个工具平台，在代码被推送后自动构建、部署，以此提高软件研发和集成效率。 这一期的系统设计，就来聊聊如何搭建持续集成和部署流水线。 CD/CD 简介 CI/CD 是 Continuous integratio […]
虽然 RESTful API 已经成为业界对于 API 的共识，但是不得不说，但是不得不说它具有很多局限性。 RESTful API 和很多的技术流传的原因类似：始于一种非常理想化的愿景，但是在落地时却需要做出权衡和取舍。 它的流行开始于 Roy Fielding 的演讲，Roy Fielding 也是 HTTP 协议标准作者之一。 我猜测 Roy Fielding 的想法 […]
一般来说，有经验的程序员不会使用多对多关系。因为存在“多对多关系”说明领域模型在设计时丢失了一些重要概念，无法建立清晰的模型。 这篇文章整理了一些多对多关系拆解的案例，作为日常领域模型设计的参考资料。 为了让图更简洁，本文使用 E-R 图作为分析模式来描述，在实际工作中可以转换为类图。 订单和商品 订单和商品是最常见的多对多关系，一个订单中可以有多个产品构成的订单行，而商品 […]
在过去几年一直对编程语言本身很敬畏。一方面编译原理本身是非常困难的领域，另外一方面图灵完备的语言完全满足日常需求。 直到最近，在一些技术问题上不得不尝试使用 DSL（领域特定语言，相对于 GPL，即通用编程语言）去解决。在和一些伙伴交流后把相关经验整理下来，收录到系统设计专栏中，当产生 DSL 需求时再拿出来看。 什么时候会考虑使用 DSL 或者 GPL？ DSL 语言实际 […]
对于大型系统或者大型企业来说，业务系统需要支撑的场景往往多到超过想象，这也是大厂业务复杂的原因。 我们需要对这些场景进行抽象，并设计合理的拓展点。例如： 某电子产品的售后工单系统，需要处理各种场景：咨询、安装、维修、退换货、配件销售等场景，这些场景都有不同的字段，但是工单流转过程类似，如何设计模型？ 财务结算系统，需要处理各种来源结算场景，生成不同的结算单，如何使用结算单统 […]
在软件工程中，术语管理是一个极其冷门但是却非常重要的话题。 在很多项目上开发人员和业务人员之间的讨论有很大一部分是词汇的误解造成的，即使在技术人员、业务人员内部讨论也存在同样的情况。例如，某电信运营商项目，话费套餐属于商品还是产品这个问题经常被拿出来讨论，直到找到了总部给出的规范性文件才定性下来。 越是专业的软件系统对专业术语的定义需求越发迫切，这些定义往往需要极其精确，甚 […]
