正交性
所谓正交性（orthogonal 意为正交的），就是设计的维度与其他维度完全隔离，一个正交的设计/值域设计，其变化绝不会受其他正交维度影响，也不会影响其他正交维度。
我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。
我们可以把问题域切分清楚。问题域之间完全不相互干涉（注意跨问题域问题）。
我们可以把变量、字段、列设计成正交的。这样不同业务场景下，列之间的赋值不会相互覆盖。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
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...
2020-09-02
异地多活与单元化
核心结论 单元化不是“多建几套机房”，也不是把应用复制到多个城市就结束。它解决的是一个更具体的问题：当业务规模大到单机房、单库、单服务集群都无法继续水平扩展时，如何让一部分用户或一部分业务身份的请求，从接入层、服务层、中间件到数据层，都尽量闭环在同一个逻辑单元里。 一个成熟的单元化系统，至少要把四个域对齐： 域 需要对齐的内容 失配后的结果 流量域 请求能按用户、商家、地域、订单等分片标识进入指定单元 入口正确，内部调用仍然乱跳 数据域 核心数据按同一分片规则落到对应单元 服务闭环，数据库跨城访问 故障域 单元故障只影响该单元承载的流量和数据 一个局部故障拖垮全站 治理域 路由规则、注册中心、发布、监控、演练都理解单元 规则靠人工同步，切换时失控 这个定义能把几个常被混用的词分开： 概念 隔离对象 是否要求存储隔离 常见用途 AZ（Availability Zone） 基础设施故障域 不要求 机房级容灾、容量冗余 Set / Cell 业务流量和业务数据 通常要求 容量扩展、故障隔离、异地多活 RZone / GZone / ...
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 代表虚线框，也代表抽象。
2020-10-11
数据密集型应用系统设计 - Designing Data Intensive Applications
数据密集（Data-Intensive）与计算密集（Compute-Intensive）是当今两大负载类型。前者以大数据为代表，后者以深度学习和 HPC 为主要代表。 谨以本书献给那些追逐梦想的人们。 [另一个电子版本。][1] 前言 数据密集型应用要处理的瓶颈往往是数据的规模、数据的复杂度和数据产生与变化的速率；与之对应的是计算密集型应用，CPU 往往成为其瓶颈。 本书是关于数据处理系统及其相关技术的（NoSQL、消息队列、缓存、搜索引擎、批处理和流处理框架）。 每一种技术都基于一定的设计理念，而且只适用于特定的场景。 不要过度优化。 数据系统基础 可靠、可扩展与可维护的应用系统 现在的典型系统架构已经很明确了，因为业界已经有成功的案例，对这些组件做了很好的抽象，我们只要做好拿来主义就行了。 可靠性（Reliability） fault tolerance 和 resilience 是系统的容错的体现。 硬件故障 对于大型 IDC，即使磁盘的 MTTF 很高，磁盘数量大了以后，每天发生磁盘损坏也是正常的事情。 硬件容错的方案是制造冗余（冗余磁盘、冗余电源）。 软件容错是第二种方...
2022-01-10
郭东白博士《关于中台的思考和尝试》
FROM：《关于中台的思考和尝试》 围绕中台的争议非常多，但是往往争议的原因是连中台这个概念都完全没有达成共识，可以说是毫无意义的争吵。在 12 月 20 日由极客邦科技举办的 QCon 全球软件开发大会 2020（上海站）上，车好多 CTO 郭东白博士发表了主题演讲《从中台技术谈架构师的独立思考能力》。由于演讲时间有限， 关于中台的思考没办法讲得非常透彻，本文是对演讲的补充，期望能与大家形成思想碰撞。识别文末二维码，可免费下载郭东白博士的主题演讲PPT。 中台的定义 我们的讨论先从定义中台这个概念开始。 定义中台我认为可以有两个角度， 一个是从中台本身的价值和出发点来： 中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合；另一个定义从中台的相对定位来：前台是面向终端用户的一组业务能力，业务中台是对前台应用的抽象，提供多个前台业务之间共享的业务逻辑、数据和计算能力。 我想特别强调这个定义是相对中性的， 我们能够通过这个定义区分什么东西是中台，什么不是中台。有的中台定义严格来说不是定义， 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略...
2021-08-25
基本业务架构设计方法
如何实现自己的 validation 123456789101112131415161718192021222324252627282930313233343536373839// 抛出异常private void validateParam(Map<String, String> paramValues) { boolean validate = MapUtils.isEmpty(paramValues) || !paramValues.containsKey(ParamConstant.CUSTOMER_N0) || StringUtils.isEmpty(paramValues.get(ParamConstant.CUSTOMER_N0)); if (validate) { throw new DataBusinessException(ResultCodeEnum.PARAM_NULL); } ...
