交易系统模型设计
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2020-10-11
数据密集型应用系统设计 - Designing Data Intensive Applications
数据密集（Data-Intensive）与计算密集（Compute-Intensive）是当今两大负载类型。前者以大数据为代表，后者以深度学习和 HPC 为主要代表。 谨以本书献给那些追逐梦想的人们。 [另一个电子版本。][1] 前言 数据密集型应用要处理的瓶颈往往是数据的规模、数据的复杂度和数据产生与变化的速率；与之对应的是计算密集型应用，CPU 往往成为其瓶颈。 本书是关于数据处理系统及其相关技术的（NoSQL、消息队列、缓存、搜索引擎、批处理和流处理框架）。 每一种技术都基于一定的设计理念，而且只适用于特定的场景。 不要过度优化。 数据系统基础 可靠、可扩展与可维护的应用系统 现在的典型系统架构已经很明确了，因为业界已经有成功的案例，对这些组件做了很好的抽象，我们只要做好拿来主义就行了。 可靠性（Reliability） fault tolerance 和 resilience 是系统的容错的体现。 硬件故障 对于大型 IDC，即使磁盘的 MTTF 很高，磁盘数量大了以后，每天发生磁盘损坏也是正常的事情。 硬件容错的方案是制造冗余（冗余磁盘、冗余电源）。 软件容错是第二种方...
2022-01-07
如何写复杂业务系统
引言 本文只是一家之言。 本文是一系列文章的缩略版本（完整版只写了个开头），尽量只讲具体的东西，如果有东西太干了，没有具体的“体感”，是作者的责任。 不喜欢看纯理论分析的可以跳到单一系统层次和模块设计（大多数人可能更加关注这一节，其实前面的部分更重要）。 几个很干的原则 解决复杂问题要用高级思维，不要用低级思维。 蚂蚁/ebay 等若干家企业架构师四大原则 - 听过的可以往下跳： 分治（其他所有原则都是从分治里衍生的） 分层 抽象 演化 solid 5 原则很重要很重要 -很多人读过，很多人可能没有读过，温故知新很重要。 注重过程质量，拿到结果质量。 业务系统为什么难写？ 纯粹的业务驱动：技术的输入和决策完全来源于业务同事，甚至只受业务摆布的团队，架构容易混乱 业务又不懂架构、业务又不懂功能点罗列的合理性，业务只会往技术团队身上扔需求。 怎么把需求和实现分门别类是技术自己的事情。 但技术人员如果一直都很忙，没有自己的空闲时间或者对设计洁癖的坚持，慢慢地就会养成“把需求翻译成代码，然后往老的系统里面扔”（混乱根源 1）的坏习惯- 问题：翻译只是普通的低级思维，不能解决很复杂...
2020-12-02
服务治理组件笔记
背景 service-centric architecture 以服务为中心的架构，和 SOA 的区别是？ 服务治理的模式 server-side pattern：容易集中管控，易单点失败。 client-side pattern：不容易集中管控，不易单点失败。 演化流程 基础治理能力：通信协议统一、命名服务的统一、监控预警、运营平台 高性能/易用性：通信框架高性能/通信框架轻量化/分布式链路追踪/测试工具可视化 全方位的治理能力：全链路压测平台/深度服务化 SOA/链路级流量治理/易用化平台构建 业界前言探索：SET 化高扩展架构/云原生架构治理 治理体系 该有的治理能力都要有。 注册中心 服务注册 服务概要 提供者 消费者 监控报警 节点监控 性能监控 业务监控 异常监控 服务运营 配置管理 服务分组 节点管理 服务鉴权 数据分析 性能指标 来源去向 主机分析 数据报表 调用链路 关键组件-本地代理 比如 LocalAgent，能够做到：策略下沉，解耦功能，对业务服务侵入性低。 但 Provider/Consumer 还需要使用自己的 sdk，它和远端的 ...
2021-05-27
插件化架构
为什么要实现插件化架构 业务和平台要解耦。业务和平台都是多对多的关系。全链路里既有业务，也有平台。大家应该如何 talk by interface。我们看待复杂组织的业务流程，要线性看，看到很多节点；也要分层看，看到复合的层次。在这种情况下，上层架构域和下层架构域之间怎么实现复杂度的管理？ 如果我们需要构建大规模的泛交易平台，我们需要靠插件化架构把我们的系统组装起来。 插件化架构通常需要一个 runtime 层（或者 boot 层）、core 层。 从业务视角来看，要解决多团队协同的问题 因为多个业务域/团队没有把能力用统一的方式透出，所以没有人能够知道统一的技术能力应该怎么串联。进行全链路沟通需要大量的沟通对齐工作。 从业务视角来看，复杂性业务要素包含本业务用例里的各种模型。 从平台视角来看，要解决复杂性管理问题 平台要支撑多种业务，业务的复杂性、差异性，以及众多业务需求不确定性，在各平台内部如何管理和支撑？简单的 if-else 不易于管理，确保对业务的支撑能力不相互影响。隔离是最好的管理手法。 从平台视角来看，复杂性业务要素包含本域内标准系统用例里的各种模型。 同一个模型，...
2019-09-26
架构整洁之道笔记
最早的《The Clean Architecture》诞生于 2012年，这个问题很早就被讨论清楚了。 思维导图： 注意，所有的接口都是在高层声明的：UseCase Input Port 和 UseCase Output port，所以高层可以实现高层的接口，低层也可以实现高层的接口。 注意，sofa的分层就是在一个横向的模块里声明了业务用例的接口和 core-model 的接口，这样源代码级的依赖都集中在抽象上： Use Case Interactor 和 Presenter 应该是可测试的，而 Data Access Interface、View、ORM 应该是 humble object。所以一个应用的低层（外层）应该是被排除掉不做测试的。 附件下载： xmind 关于源代码中的依赖关系的一些澄清： “使用”并不意味着“定义”，而只是引用 dashed outline 代表虚线框，也代表抽象。
2022-01-12
《架构师修炼之道》
刻戒于碑，铸法于鼎 软件特性、质量属性。 将两个元素以某种方式连接在一起，就形成了结构。 module component-connector 就是我们经常讲的系统交叉点 allocation 就涉及到我们的部署设计 每一本书都会讲到利益相关者，也就是 stakeholder。 主动撰写设计决策，承担设计职责。 软件之所以叫软件，是因为它灵活而易于变动。架构是软件里硬的部分，为变动提供了章法，也制造了约束-否则我们不用经常“对架构产生冲击”，而需要打破架构。 设计原则： 以人为本（能落地能产生价值的架构才是真的好架构） 推迟决策 善于借鉴 化虚为实 推迟决策不是推迟大的设计决策，要推迟的是细枝末节的决策。不要陷入舍本逐末的优化中，导致项目无法受控。 忽视前人的设计，是最低效的设计方法之一。所以寻找架构风格是很重要的。 设计思维模式： 理解：换位思考 探索：尝试各种结构组合，找到最能提升目标质量属性的那种组合。-大多数情况下，是我们手头最简单最现成的解决方案。 展示：用图、表、模型、原型来展示，探讨。原型应该尽量具有交互性，可以直接和客户评审。 评估：评估到底我们要做什么东西...
