正交性
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

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...

2021-03-01
HATP 问题
问题定义 AP 的出现 在互联网浪潮出现之前,企业的数据量普遍不大。通常一个单机的数据库就可以保存核心的业务数据。那时候的存储并不需要复杂的架构,所有的线上请求(OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online Analytical Processing) 都跑在同一个数据库实例上。后来业务越来越复杂,数据量越来越大,产生了一个显著问题:单机数据库支持线上的 TP 请求已经非常吃力,没办法再跑比较重的 AP 分析型任务,在这样的大背景下,于是AP开始从TP系统分离,某种程度上,AP是TP的一个分支。 这等于是在存储层做 CQRS 架构设计-另一种方案是在应用层也设计读写分离的架构。 AP 的玩法 在这样的背景下,以 Hadoop 为代表的大数据技术开始蓬勃发展,它用许多相对廉价的 x86 机器构建了一个数据分析平台,用并行的能力破解大数据集的计算问题。 AP 系统的典型技术栈演进: 阶段 代表技术 特点 第一代 Hadoop MapReduce + Hive 批处理,延迟高(分钟到小时级) 第二...

2019-08-30
《高可用恢复思路》笔记
遇到线上问题,经常陷入一个误区:一定要找到问题的根因(root cause)。但实际上对线上应用而言,最重要的是恢复可用性,所以在开发设计环境除了完成功能性需求以外,还需要加入非功能性设计的需求: 限流保护。抵挡来自突发流量冲垮整个集群。 降级保护,对调用的服务接口保持警惕,其各种因素导致不可用,可以对齐降级,从而确保核心功能可用。 削峰填谷(traffic shaping),不因突发数据来袭,造成任务消费陡增,造成调用系统的连串抖动。 这些基本的系统保护,是应对未来的各种突发不确定事件的高可用思考。 以上描述的是问题的应对机制设计,问题的发现机制,也需要结构化地考虑,体系化地建设: 发现机制,是我们的眼睛,也是基础。 监控主指标,需要找对业务的主要指标,常见的主指标一般是:RT(响应时间)、总量、成功量、失败量、成功率。 主指标有异常,还要有细分维度(即结果还可以内部 group by aggregation)。 快速恢复 根据监控快速寻找问题发生的方向和位置。 找对恢复的人、恢复的预案。 倾向于选择成本低的恢复手段。---- 并不是所有的恢复都用大招(熔断、限流),大招...

2018-04-02
一个滚动重启的状态保存问题
很多时候滚动重启,都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的,然后在上游的服务上做好 failover,然后增加 standby server,让 sticky 数据 transmit 到 standby 机器上,让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下,除了发布新的 feature 升级以外,都应该尽量用热配置来避免重启。

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-01-10
面向不确定性编程
本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。 本文探讨到底不确定性和复杂性源于何处,并引出互联网业务系统的一种“可适应性架构”,适用于平台型业务系统。 定义问题 软件难写,是软件工程师的共同感觉。 特别地,对于中国的互联网公司的“业务团队”的工程师而言,“业务系统”在业务的复杂度堆积到一定程度以后,软件本身的“熵增效应”会特别严重:一个业务系统的内部会充满了难以理解的分层、堆积如山的 if-else 分支,以至于很多工程师都不愿意进入密密麻麻复杂逻辑深处,去做高风险的维护工作。但是,只要公司正常发展,业务总会越做越大/复杂,所以要维持系统的可维护性,成为了一门很重要的学问。 现实中的系统的高复杂度问题,可以简单表述为“不确定性矛盾”:需求具有高度不确定性,一直都在高速变化;而工程师高度倾向于确定实现(因为高度抽象、反复抽象的成本很高),所以具体的实现难以变更,这两种相反的特性难以调和。 其实我们现在遇到的困境,历史上发生过很多次,比如我们现代的很多软件工程理论,就是从历次的软件危机中诞生的。归根结底,软件之所以叫软件(Software),是因为相...
Announcement
人生只是,守株待兔





