正交性
Created|Updated|系统架构
|Word Count:157|Reading Time:1mins|Post Views:
所谓正交性(orthogonal 意为正交的),就是设计的维度与其他维度完全隔离,一个正交的设计/值域设计,其变化绝不会受其他正交维度影响,也不会影响其他正交维度。
我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。
我们可以把问题域切分清楚。问题域之间完全不相互干涉(注意跨问题域问题)。
我们可以把变量、字段、列设计成正交的。这样不同业务场景下,列之间的赋值不会相互覆盖。
Author: magicliang
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles

2020-12-02
服务治理组件笔记
背景 service-centric architecture 以服务为中心的架构,和 SOA 的区别是? 服务治理的模式 server-side pattern:容易集中管控,易单点失败。 client-side pattern:不容易集中管控,不易单点失败。 演化流程 基础治理能力:通信协议统一、命名服务的统一、监控预警、运营平台 高性能/易用性:通信框架高性能/通信框架轻量化/分布式链路追踪/测试工具可视化 全方位的治理能力:全链路压测平台/深度服务化 SOA/链路级流量治理/易用化平台构建 业界前言探索:SET 化高扩展架构/云原生架构治理 治理体系 该有的治理能力都要有。 注册中心 服务注册 服务概要 提供者 消费者 监控报警 节点监控 性能监控 业务监控 异常监控 服务运营 配置管理 服务分组 节点管理 服务鉴权 数据分析 性能指标 来源去向 主机分析 数据报表 调用链路 关键组件-本地代理 比如 LocalAgent,能够做到:策略下沉,解耦功能,对业务服务侵入性低。 但 Provider/Consumer 还需要使用自己的 sdk,它和远端的 ...
2019-09-05
《应用架构之道》笔记
架构师的职责 化繁为简。架构师是职责就是把复杂的问题简单化,使得其他人能够更好地在架构里工作。 架构师要努力训练自己的思维,用它去理解复杂的系统,通过合理的分解和抽象,做出合理的设计。 软件架构 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件的链接则明确和相对细致地描述组件之间的通信。 软件架构为软件系统提供了结构、行为和属性的高级抽象。,由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系,而且指定了整个软件系统的组织和拓扑结构,提供了一些设计决策的基本原理。 软件架构的核心价值应该只围绕一个核心命题:控制复杂性。 软件架构分类 业务架构:由业务架构师负责,也可以称为业务领域专家、行业专家。业务架构属于顶层设计,其对业务的定义和划分会影响组织结构和技术架构。 应用架构:由应用架构师负责,他需要根据业务场景的需要,设计应用的层次结构,制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平,从而在快速的支撑业务发展的同时,在保证系统的可用性和可维...

2022-01-12
《架构师修炼之道》
刻戒于碑,铸法于鼎 软件特性、质量属性。 将两个元素以某种方式连接在一起,就形成了结构。 module component-connector 就是我们经常讲的系统交叉点 allocation 就涉及到我们的部署设计 每一本书都会讲到利益相关者,也就是 stakeholder。 主动撰写设计决策,承担设计职责。 软件之所以叫软件,是因为它灵活而易于变动。架构是软件里硬的部分,为变动提供了章法,也制造了约束-否则我们不用经常“对架构产生冲击”,而需要打破架构。 设计原则: 以人为本(能落地能产生价值的架构才是真的好架构) 推迟决策 善于借鉴 化虚为实 推迟决策不是推迟大的设计决策,要推迟的是细枝末节的决策。不要陷入舍本逐末的优化中,导致项目无法受控。 忽视前人的设计,是最低效的设计方法之一。所以寻找架构风格是很重要的。 设计思维模式: 理解:换位思考 探索:尝试各种结构组合,找到最能提升目标质量属性的那种组合。-大多数情况下,是我们手头最简单最现成的解决方案。 展示:用图、表、模型、原型来展示,探讨。原型应该尽量具有交互性,可以直接和客户评审。 评估:评估到底我们要做什么东西...
2022-01-10
面向不确定性编程
本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。 本文探讨到底不确定性和复杂性源于何处,并引出互联网业务系统的一种“可适应性架构”,适用于平台型业务系统。 定义问题 软件难写,是软件工程师的共同感觉。 特别地,对于中国的互联网公司的“业务团队”的工程师而言,“业务系统”在业务的复杂度堆积到一定程度以后,软件本身的“熵增效应”会特别严重:一个业务系统的内部会充满了难以理解的分层、堆积如山的 if-else 分支,以至于很多工程师都不愿意进入密密麻麻复杂逻辑深处,去做高风险的维护工作。但是,只要公司正常发展,业务总会越做越大/复杂,所以要维持系统的可维护性,成为了一门很重要的学问。 现实中的系统的高复杂度问题,可以简单表述为“不确定性矛盾”:需求具有高度不确定性,一直都在高速变化;而工程师高度倾向于确定实现(因为高度抽象、反复抽象的成本很高),所以具体的实现难以变更,这两种相反的特性难以调和。 其实我们现在遇到的困境,历史上发生过很多次,比如我们现代的很多软件工程理论,就是从历次的软件危机中诞生的。归根结底,软件之所以叫软件(Software),是因为相...

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)这是默认前提,不是可选项。 由此诞生三种设计约束...
2018-01-30
几种共识算法
达成共识的英文原文是 come to consensus。达成共识以后,也未必代表数据是完全一致的(Raft 算法中 leader 发出 append log 的 commit 命令即算达成共识?但如果中途数据丢失,则还是会有子节点数据不一致)。 在分布式环境下,多个系统协同工作的效率,受制于系统交叉点的性能。在需要达成分布式共识的场景下,分布式共识算法在保证系统安全性的同时,限制了全系统横向扩展的性能提升。 根据环境的不同,可以应用不同的共识算法。 在完全互信的环境下-私有链、私有的分布式数据库,节点之间可以使用 Paxos 或者 Raft 这种 leader 相对固定的算法。 在有限互信的环境下-联盟链,可以使用 PBFT。PBFT 算法是依据确定性的投票(可能是漫长的投票,也可能进入死循环)达到确定性一致的算法。 在没有互信的情况下-公有链,可以使用 POW/POS/DPOS/POA。这类算法是基于概率得到正确的最终一致性,性能比 PBFT 要稍微好点。 最好的共识算法应该模块化,例如 Corda 中的 notary,Hyperledger fabric 中的 solo/k...
Announcement
人生只是,守株待兔
