正交性
所谓正交性（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...
2018-04-02
一个滚动重启的状态保存问题
很多时候滚动重启，都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的，然后在上游的服务上做好 failover，然后增加 standby server，让 sticky 数据 transmit 到 standby 机器上，让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下，除了发布新的 feature 升级以外，都应该尽量用热配置来避免重启。
2019-08-30
《高可用恢复思路》笔记
遇到线上问题，经常陷入一个误区：一定要找到问题的根因（root cause）。但实际上对线上应用而言，最重要的是恢复可用性，所以在开发设计环境除了完成功能性需求以外，还需要加入非功能性设计的需求： 限流保护。抵挡来自突发流量冲垮整个集群。 降级保护，对调用的服务接口保持警惕，其各种因素导致不可用，可以对齐降级，从而确保核心功能可用。 削峰填谷（traffic shaping），不因突发数据来袭，造成任务消费陡增，造成调用系统的连串抖动。 这些基本的系统保护，是应对未来的各种突发不确定事件的高可用思考。 以上描述的是问题的应对机制设计，问题的发现机制，也需要结构化地考虑，体系化地建设： 发现机制，是我们的眼睛，也是基础。 监控主指标，需要找对业务的主要指标，常见的主指标一般是：RT（响应时间）、总量、成功量、失败量、成功率。 主指标有异常，还要有细分维度（即结果还可以内部 group by aggregation）。 快速恢复 根据监控快速寻找问题发生的方向和位置。 找对恢复的人、恢复的预案。 倾向于选择成本低的恢复手段。---- 并不是所有的恢复都用大招（熔断、限流），大招...
2019-09-05
《应用架构之道》笔记
架构师的职责 化繁为简。架构师是职责就是把复杂的问题简单化，使得其他人能够更好地在架构里工作。 架构师要努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，做出合理的设计。 软件架构 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件的链接则明确和相对细致地描述组件之间的通信。 软件架构为软件系统提供了结构、行为和属性的高级抽象。，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。 软件架构的核心价值应该只围绕一个核心命题：控制复杂性。 软件架构分类 业务架构：由业务架构师负责，也可以称为业务领域专家、行业专家。业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。 应用架构：由应用架构师负责，他需要根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维...
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 代表虚线框，也代表抽象。
2019-12-29
彩色 UML 建模
常见的例子 MomentInterval：订单、消费、事务、退款申请 Role：购买对象、供应商、购买人、服务提供商、消费者（这些东西更偏向于元数据）、审核方、发起方。role 按照原书而言是 person 可以 associate 的一些角色，person 可以根据 role 进行一些 action。RBAC 体系即这一思想的实践。保险的干系人在元数据的设定上也是一种role。 PartyPlaceThing：Role 的具体实现：投保人、被保人、用户、商家、产品、客服。注意，这一类型几乎穷尽了所有的领域实体，也包括各种 person。 Description：订单的附属对象：消费码、数量、联系⼈、游玩人；用户的附属对象：用户 ID；商家的附属对象：商家 ID、商家名称；产品的附属对象：产品名称、产品价格、产品 ID；退款申请的附属对象：场景金额原因 架构型、彩色和领域无关的组件 四色模型.xmind 架构型 构造型即 stereotype，架构型即 archetype。 四种彩色的架构型 粉色的时刻时段（MI）架构型，粉色的时刻时段明细（MIDetail）架构型。由业...
