交易系统模型设计
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2019-09-05
《应用架构之道》笔记
架构师的职责 化繁为简。架构师是职责就是把复杂的问题简单化，使得其他人能够更好地在架构里工作。 架构师要努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，做出合理的设计。 软件架构 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件的链接则明确和相对细致地描述组件之间的通信。 软件架构为软件系统提供了结构、行为和属性的高级抽象。，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。 软件架构的核心价值应该只围绕一个核心命题：控制复杂性。 软件架构分类 业务架构：由业务架构师负责，也可以称为业务领域专家、行业专家。业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。 应用架构：由应用架构师负责，他需要根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维...
2020-12-08
活动保障性体系建设和实践的总结
大促规划.xmind 活动的定义和特点 活动具有大并发、高流量的特点，前期充足的准备是活动顺利完成的必要条件。 准备好完备的保证流程，可以为相关人员提供指引。 基本的保障方案 事前：严格按照保障步骤分工执行，活动要报备，核心链路要梳理，梳理完要评估容量和准备，要治理风险，要准备预案，要建设大盘，准备压测和演练预案，要安排值班。 事中：相关责任方（要分技术负责人和运维负责人，召集相关人员，组成稳定性保障小组）监控线上数据，以线上/线下会议、群聊和电话等多个方式参与值班并及时响应异常事件。 事后：组织复盘，总结亮点，指出不足，沉淀经验。 活动报备 要理清活动信息：活动背景、活动时间、用户参与路径、活动链接、活动 玩法、预计UV数、负责人。 核心链路的设计与梳理 核心链路的梳理、设计需和活动保障的几个核心要素相结合，核心要素分为：隔离、限流、容量。 隔离：域名隔离、Nginx集群隔离、核心服务隔离、以及其他一些重要服务的隔离。 限流：前端活动业务限流、Nginx限流（HTTP限流）、服务限流（RPC）等。特别要关注接入层的限流能力和方案。 容量：从域名解析到后端存储的系列容量评...
2020-09-02
异地多活与单元化
背景介绍 名词解释 ldc logical data center idc internet data center ldc 是 idc 的进化版，是一种单元化部署方案。 扩展模式 vs 镜像模式 扩展模式是把服务/数据库分拆，然后部署到不同的机房里面，相当于放大了一个物理机房。 镜像模式是每个机房里部署的服务都是一样的，每个机房承担一定流量。 镜像模式的容灾效果更好，难度在如何切分流量上。容灾还要考虑机房级容灾、部署地容灾的问题。多地部署带来距离，距离带来延时，延时带来 replica 的风险。 单元化部署 所谓 cell，是一个能完成所有业务操作的自包含集合（每个单元，都是其他单元的镜像）。一般的 soa 架构，服务是分层的，而且每一层的任一节点都可以被其他机房调用。而单元化部署的结果是，本单元的上层节点，只会调用本单元的下层节点。它具有一个站点全部的功能，但不具有一个站点全部的流量。 这种单元化部署实际上就要求底层的数据也要做 sharding。单元化的结果是，数据库连接可以更好地被复用-多个单元互相跨 db 连接，其实很浪费资源。 单元化是按核心数据维度，对业务系统的部署...
2022-03-18
如何写业务代码
业务研发面对的问题 稳定的业务模式 不稳定的需求 业务对交付的渴望 假设 命名规范（《clean code》） 面向对象设计（SOLID原则、贫血/充血模型、设计模式） 系统要拆分 流程控制系统与领域系统.drawio 每一个用例（解决的一个问题）都由访问逻辑和执行逻辑组成。访问逻辑负责用例执行的顺序与分支，并调用执行逻辑完成完整业务逻辑。 访问逻辑由单独的交易系统负责。执行逻辑由个子系统负责。 工程要拆分 三层架构 + 洋葱架构 代码要拆分 业务代码：描述核心业务逻辑的代码，核心是保持业务的流程及业务状态的一致性 领域对象与领域服务，不得对外部有任何依赖（工具类除外） 最核心的几个抽象： 校验：参数有效性校验、参数的业务属性校验。在进入正常业务逻辑代码前，完成所有的校验工作。 异常：业务异常：所有不符合业务逻辑而产生的异常。 系统异常：因为程序本身or依赖产生的异常。 所有的异常第一位runningtime异常。 数据: 业务数据：保存领域对象状态的数据。 非业务数据：过程数据。业务的核心流程中，只对业务数据的持久化负责。 参数：任何时候，任何方法的参数都需要...
2020-03-23
缓存的套路
缓存的套路 本文探讨缓存设计的通用模式，涵盖从选型决策、更新策略到故障防护的完整体系。 mindmap root((缓存架构)) 何时使用 读多写少 热点集中 可容忍最终一致性 缓存层次 近端缓存 Guava Caffeine EhCache 远端缓存 Redis Memcached 核心挑战 更新策略 Cache Aside Read Through Write Through Write Behind 一致性保障 故障防护 击穿防护 雪崩防护 穿透防护 模式总览 # 模式名称 一句话口诀 适用场景 1 分层降级 本地兜底，远程扩展 多级缓存架构 2 惰性填充 触发加载，按需扩容 冷启动与预热 3 旁路同步 先库后删，读写互斥 Cache Asi...
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...
