交易系统模型设计
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2022-01-19
演进式架构
如果读一本书，没有附带正确的复盘（提出反馈并总结反馈），则浪费了这次读书的完整机会。 复盘需要经过痛苦的思索，把一些之前自己没有办法充分接受的观点，充分接受。 本书是一本讲战略的书。 这本书告诉我们很多概念，一旦加上“架构”前缀，突然就有了特殊的含义：架构特征（architectural characteristic）、架构量子（architectural quantum）、架构维度（architectural dimension）、架构模式（architectural pattern）。 新时代的架构愿景-怎样用敏捷的方式来拥抱变化？ 架构难以被修改是由架构本身的不变性决定的，架构天然就是难以修改的。 有些人可能认为，就好像建筑业的实践那样，应该先完成这类架构设计，再开始开发。但需求是快速变动的这一事实告诉我们，我们可能要经常修改我们架构，以拥抱需求变化。 “需求总是在动态变化的”，比“架构应该是被预先确定”，更加像是一个事实（后者更加像是一个观点）。 当代的架构是： 不断努力的结果 【能够响应不断变化的需求和外部人员的反馈】 实施这种架构以替代传统架构，是需要决策者（技术...
2019-12-29
彩色 UML 建模
理论基础与来源 彩色 UML 建模（也称为四色模型）是由 Peter Coad、Eric Lefebvre 和 Jeff De Luca 在经典著作《Java Modeling in Color with UML》中提出的领域建模方法。该方法通过四种颜色区分不同类型的域对象，帮助开发人员更好地理解和设计业务领域模型。 四色模型的核心思想是将领域对象分为四种架构型（Archetype），每种架构型用不同的颜色表示： 粉色（Moment-Interval）：表示业务过程中发生的某个时刻或时段 黄色（Role）：表示参与方在特定时刻时段中扮演的角色 绿色（Party-Place-Thing）：表示参与方、地点和事物 蓝色（Description）：表示描述性信息，通常是可重用的数据 四色模型与 DDD 的关系 四色模型与领域驱动设计（Domain-Driven Design，DDD）有很强的关联性： 关注领域本质：两者都强调深入理解业务领域，建立符合业务语义的模型 限界上下文：四色模型的彩色分类可以帮助识别和定义限界上下文 聚合根：粉色 MI 通常对应聚合根，负责维护业务不变性 ...
2022-03-11
面向好的架构编程
前言 本文是《架构随笔》系列的第五篇，也是它的收官之作。 架构的定义 架构是一个界定不清的东西，我们很难讲清楚哪些东西是架构，哪些东西不是架构。但软件行业里其实人人都在搞架构，软件设计就是架构本身。 架构这个词出现得很早，有些人认为是 NASA（也可能是NATO） 发明的。最早的架构定义就是描述软件的结构而已，但现在已经没有多少人谈论他们定义的“软件架构”了。工程师很难以克制描述复杂结构的原始冲动，但描述复杂结构的普世标准并不存在。大家常见的各种定义，翻来覆去地重新讲着“软件架构是软件结构的顶层设计或者抽象设计”之类的话。即使是这种软件架构的定义，也并不为所有人都接受。汗牛充栋的架构书籍里有各种各样的观点，有的进一步把软件架构视作一堆组件和交互的设计，有的则把软件架构视作架构师主观意图的体现。把自己当作架构师的人们，着迷于把软件里的“不变与抽象的部分”和“易变与具体的部分”分离出来，把前者当作架构。架构师们是如此地热衷于做这样一件事，以至于有些人认为架构设计好了就解决了基本问题，设计不好通常是因为架构不好。于是很多人开始刻舟求剑：从某某颗粒度开始的设计应该叫概要设计，从某某颗粒度...
2018-04-02
一个滚动重启的状态保存问题
很多时候滚动重启，都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的，然后在上游的服务上做好 failover，然后增加 standby server，让 sticky 数据 transmit 到 standby 机器上，让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下，除了发布新的 feature 升级以外，都应该尽量用热配置来避免重启。
2019-08-30
《高可用恢复思路》笔记
遇到线上问题，经常陷入一个误区：一定要找到问题的根因（root cause）。但实际上对线上应用而言，最重要的是恢复可用性，所以在开发设计环境除了完成功能性需求以外，还需要加入非功能性设计的需求： 限流保护。抵挡来自突发流量冲垮整个集群。 降级保护，对调用的服务接口保持警惕，其各种因素导致不可用，可以对齐降级，从而确保核心功能可用。 削峰填谷（traffic shaping），不因突发数据来袭，造成任务消费陡增，造成调用系统的连串抖动。 这些基本的系统保护，是应对未来的各种突发不确定事件的高可用思考。 以上描述的是问题的应对机制设计，问题的发现机制，也需要结构化地考虑，体系化地建设： 发现机制，是我们的眼睛，也是基础。 监控主指标，需要找对业务的主要指标，常见的主指标一般是：RT（响应时间）、总量、成功量、失败量、成功率。 主指标有异常，还要有细分维度（即结果还可以内部 group by aggregation）。 快速恢复 根据监控快速寻找问题发生的方向和位置。 找对恢复的人、恢复的预案。 倾向于选择成本低的恢复手段。---- 并不是所有的恢复都用大招（熔断、限流），大招...
2022-01-20
常见架构推导法
架构演进之路，路漫漫其修远兮 架构关乎不变的顶层设计抽象。 架构关乎组件（元素）、交互（连接器）、功能（function or feature）、约束（constraint 面向当前、未来-下一场景、下一个规模、下一个地域或国家） 洋葱架构的另一种解读 系统是洋葱，看似有边界，但是每次改动总是端到端，过程让⼈人泪流满⾯面。 系统的本质 功能与质量量的结合体：功能是核心价值 + 质量实现增值或保值。 系统的复杂性 过程与过程数据 过程与过程数据.drawio 易变性 系统复杂度.drawio 系统复杂度 = 功能的数量 * 功能的过程 《人月神话》：本质复杂度(Essential Complexity)和偶然复杂度(Accident Complexity)。 解法 分离业务复杂度和系统复杂度。 回归面向对象的本质，重拾抽象思维的价值 维护效率曲线.drawio 三种编程范型.drawio 领域驱动设计 战略设计 领域驱动设计-战略设计-一般过程.drawio 需求分析 需求分析.xmind 词汇提取 知识提取.drawio 领域语⾔定义-合理的上下⽂和领域划分 顺序-...
