交易系统模型设计
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2018-11-28
正交性
所谓正交性（orthogonal 意为正交的），就是设计的维度与其他维度完全隔离，一个正交的设计/值域设计，其变化绝不会受其他正交维度影响，也不会影响其他正交维度。 我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。 我们可以把问题域切分清楚。问题域之间完全不相互干涉（注意跨问题域问题）。 我们可以把变量、字段、列设计成正交的。这样不同业务场景下，列之间的赋值不会相互覆盖。
2025-09-13
分布式事务
问题定义 对经典的电商场景而言：下单是个插入操作，扣减金额和库存是个更新操作，操作的模型不同，如果进行分布式的服务拆分，则可能无法在一个本地事务里操作几个模型，涉及跨库事务。 CAP 定义 根据 Eric Brewer 提出的 CAP 理论： Consistency：All Nodes see the same data at the same time。所有节点看到同一份最新数据。Brewer 论文里的 C 严格定义是 linearizability，工程语境下常被泛化为 strong consistency。 Availability：Reads and writes always succeed。非故障节点必须在合理时间内响应。 Partition tolerance：System continues to operate despite arbitrary message loss or failure of part of the system。网络分区时系统继续运行。在云原生环境（K8s 跨可用区、跨 region）这是默认前提，不是可选项。 由此诞生三种设计约束...
2022-01-19
Gergely Orosz 文章翻译-软件架构被高估，简明设计被低估
原文链接：《Software Architecture is Overrated, Clear and Simple Design is Underrated》
2021-03-01
HTAP 问题
问题定义 AP 的出现 在互联网浪潮出现之前，企业的数据量普遍不大，单机数据库就足以保存核心业务数据。那时候的存储不需要复杂架构，所有线上请求（OLTP，Online Transaction Processing）和后台分析（OLAP，Online Analytical Processing）都跑在同一个数据库实例上。后来业务越来越复杂，数据量越来越大，问题随之而来：单机数据库支持线上 TP 请求已经非常吃力，再跑较重的 AP 分析任务无以为继。AP 由此从 TP 系统分离，某种程度上 AP 是 TP 的一个分支。 这等于在存储层做读写分离的架构设计；另一种思路是在应用层做读写分离。 AP 的玩法 在这种背景下，以 Hadoop 为代表的大数据技术开始蓬勃发展，它用大量相对廉价的 x86 机器构建了一个数据分析平台，用并行能力破解大数据集的计算问题。 AP 系统的典型技术栈演进： 阶段 代表技术 特点 第一代 Hadoop MapReduce + Hive 批处理，延迟高（分钟到小时级） 第二代 Spark + Spark SQL 内存计算，延迟降到秒级 第...
2021-05-27
插件化架构
为什么要实现插件化架构 业务和平台要解耦。业务和平台都是多对多的关系。全链路里既有业务，也有平台。大家应该如何 talk by interface。我们看待复杂组织的业务流程，要线性看，看到很多节点；也要分层看，看到复合的层次。在这种情况下，上层架构域和下层架构域之间怎么实现复杂度的管理？ 如果我们需要构建大规模的泛交易平台，我们需要靠插件化架构把我们的系统组装起来。 插件化架构通常需要一个 runtime 层（或者 boot 层）、core 层。 从业务视角来看，要解决多团队协同的问题 因为多个业务域/团队没有把能力用统一的方式透出，所以没有人能够知道统一的技术能力应该怎么串联。进行全链路沟通需要大量的沟通对齐工作。 从业务视角来看，复杂性业务要素包含本业务用例里的各种模型。 从平台视角来看，要解决复杂性管理问题 平台要支撑多种业务，业务的复杂性、差异性，以及众多业务需求不确定性，在各平台内部如何管理和支撑？简单的 if-else 不易于管理，确保对业务的支撑能力不相互影响。隔离是最好的管理手法。 从平台视角来看，复杂性业务要素包含本域内标准系统用例里的各种模型。 同一个模型，...
2021-05-07
如何画架构图
前言 有意义且具备一致性（coherence）的架构图有助于为不同的利益相关者（stakeholder）澄清（illustrate）事实，并达成共识-反之，图表杂乱无章。 有意义的图表胜过建模（建模指的是With modelling, you're building up a non-visual model of something (e.g. the software architecture of a software system), and then creating different views (e.g. diagrams) on top of that model. ），在架构沟通上，visualization 胜过千言万语。 一致性要求我们有足够好的指导原则，让我们知道标准的图元是什么。 “架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱”。 在同一个架构图里添加不同层级的抽象可能会导致冲突的出现，因为它们是从不同的角度描述问题的。 应该在架构图旁边加上图例（legend），沟通者应该懂得图元（key）是什么。key 和 legen...
