# GRASP 通用职责分配软件模式

# 信息专家 ( Information Expert )

为对象分配职责的通用原则 – 把职责分配给拥有足够信息可以履行职责的专家

# 创建者 ( Creator )

将创建 A 的职责赋给 B ，如果至少下面一种情况为真：

• B “包含” 或者聚合 A
• B 记录 A 的实例
• B 密切地使用 A
• B 拥有 A 的初始化数据

# 低耦合 ( Low Coupling )

赋予职责使得对象间的耦合度尽可能低，最小化对象间的依赖和变更影响，最大化重用。

# 高内聚 ( High Cohesion )

赋予职责使得每个对象的职责尽可能保持聚焦和单一，易于管理和理解。

# 控制器 ( Controller )

把职责赋予系统、设备或者子系统的表示类 (门面控制器)，或者某个用例的表示类 (用例控制器)，让控制器接收事件并协调整个系统的运作。

# 多态 ( Polymorphism )

将职责分配给多个具有同名方法的多态子类，运行时根据需要动态切换子类，让系统行为变得可插拔。

# 纯虚构 ( Pure Fabrication )

针对真实问题域中不存在，但是设计建模中有用的概念，设计虚构类并赋予职责。

# 间接 ( Indirection )

在两个或者多个对象间有交互的情况下，为避免直接耦合，提高重用性，创建中间类并赋予职责，对象的交互交由中间类协调。

# 受保护的变化 ( Protected Variation )

简单讲就是封装变化。识别系统中可能的不稳定或者变化，在不稳定组件上创建稳定的抽象接口，将可能的变化封装在接口之后，使得系统内部的不稳定或者变化不会对系统的其它部分产生不良影响。

# SOLID 面向对象设计原则

S.O.L.I.D 是面向对象设计和编程 ( OOD&OOP ) 中几个重要原则的首字母缩写，受 Robert Martin 推崇。

# 单一职责原则 ( The Single Responsibility Principle )

修改某个类的理由应该只有一个，如果超过一个，说明类承担不止一个职责，要视情况拆分。

# 开放封闭原则 ( The Open Closed Principle )

软件实体应该对扩展开放，对修改封闭。一般不要直接修改类库源码（即使你有源代码），通过继承等方式扩展。

# 里氏替代原则 ( The Liskov Substitution Principle )

当一个子类的实例能够被替换成任何超类的实例时，它们之间才是真正的 is-a 关系。

# 依赖倒置原则 ( The Dependency Inversion Principle )

高层模块不应该依赖于底层模块，二者都应该依赖于抽象。换句话说，依赖于抽象，不要依赖于具体实现。比方说，你不会把电器电源线焊死在室内电源接口处，而是用标准的插头插在标准的插座 (抽象) 上。

# 接口分离原则 ( The Interface Segregation Principle )

不要强迫用户去依赖它们不使用的接口。换句话说，使用多个专门的接口比使用单一的大而全接口要好。

# AKF 架构原则

# N + 1 设计

永远不要少于两个，通常为三个。比方说无状态的 Web/API 一般部署至少 >=2 个。

# 回滚设计

确保系统可以回滚到以前发布过的任何版本。可以通过发布系统保留历史版本，或者代码中引入动态开关切换机制 ( Feature Switch )。

# 禁用设计

能够关闭任何发布的功能。新功能隐藏在动态开关机制 ( Feature Switch ) 后面，可以按需一键打开，如发现问题随时关闭禁用。

# 监控设计

在设计阶段就必须考虑监控，而不是在实施完毕之后补充。例如在需求阶段就要考虑关键指标监控项，这就是度量驱动开发 ( Metrics Driven Development ) 的理念。

# 设计多活数据中心

不要被一个数据中心的解决方案把自己限制住。当然也要考虑成本和公司规模发展阶段。

# 使用成熟的技术

只用确实好用的技术。商业组织毕竟不是研究机构，技术要落地实用，成熟的技术一般坑都被踩平了，新技术在完全成熟前一般需要踩坑躺坑。

# 异步设计

能异步尽量用异步，只有当绝对必要或者无法异步时，才使用同步调用。

# 无状态系统

尽可能无状态，只有当业务确实需要，才使用状态。无状态系统易于扩展，有状态系统不易扩展且状态复杂时更易出错。

# 水平扩展而非垂直升级

永远不要依赖更大、更快的系统。一般公司成长到一定阶段普遍经历过买更大、更快系统的阶段，即使淘宝当年也买小型机扛流量，后来扛不住才体会这样做不 scalable ，所以才有后来的去 IOE 行动。

# 设计时至少要有两步前瞻性

在扩展性问题发生前考虑好下一步的行动计划。架构师的价值就体现在这里，架构设计对于流量的增长要有提前量。

# 非核心则购买

如果不是你最擅长，也提供不了差异化的竞争优势则直接购买。避免 Not Invented Here 症状，避免凡事都要重造轮子，毕竟达成业务目标才是重点。

# 使用商品化硬件

在大多数情况下，便宜的就是最好的。这点和第 9 点是一致的，通过商品化硬件水平扩展，而不是买更大、更快的系统。

# 小构建、小发布和快试错

全部研发要小构建，不断迭代，让系统不断成长。这个和微服务理念一致。

# 隔离故障

实现故障隔离设计，通过断路保护避免故障传播和交叉影响。通过舱壁泳道等机制隔离失败单元 ( Failure Unit )，一个单元的失败不至影响其它单元的正常工作。

# 自动化

设计和构建自动化的过程。如果机器可以做，就不要依赖于人。自动化是 DevOps 的基础。

# 要素应用

# 基准代码

一份基准代码，多份部署。如果用镜像部署方式，则一个镜像可以部署到多个环境 (测试，预发，生产)，而不是给每个环境制作一个不同镜像。

# 依赖

显式声明依赖。如果用镜像部署，则一般依赖被直接打在镜像中，或者声明在 docker file 中。

# 配置

在环境中存储配置。在 Heroku 或者类似的 PaaS 平台上，配置一般是推荐注入到环境变量中的。现在采用集中式配置中心也是一种流行方式。

# 后端服务

把后端服务 (例如缓存，数据库，MQ 等) 当作附加资源，相关配置和连接字符串通过环境变量注入，或者采用配置中心。

# 构建、发布和运行

严格分离构建和运行。如果使用镜像部署，则构建、发布 / 运行是通过镜像这种中间格式严格分离的。

# 进程

一个或者多个无状态的进程运行应用。容器运行时相当于进程，适用于无状态 Web/API 。

# 端口绑定

通过端口绑定提供服务。容器也是通过端口绑定对外提供服务。

# 并发

通过进程模型进行扩展。容器运行时相当于进程，通过起多个容器可以任意扩展并发数量。

# 易处理

快速启动和优雅终止可最大化健壮性。 docker 容器支持秒级启动和关闭。

# 开发环境和线上环境等价

尽可能保持开发、测试、预发和线上环境相同。容器可以保证容器内运行时环境的一致性，还需要保证不同环境的一致性，例如不同环境内的操作系统，负载均衡，服务发现，后台服务，监控告警等要尽可能一致。

# 日志

把日志当作数据流。 Heroku 不支持本地文件，所以必须以流方式把日志输送到后台日志服务。除了日志以外还要补充考虑 metrics 流的采集和输送。

# 管理进程

后台管理任务当作一次性的进程。其实相当于在 Heroku 上以独立进程方式运行任务 Job。

# CAP 定理

# 一致性 ( Consistency )

一致性指 “ all nodes see the same data at the same time ”，即更新操作成功，所有节点在同一时间的数据完全一致。

# 可用性 ( Availability )

可用性指 “ Reads and writes always succeed ”，即服务一直可用，而且响应时间正常。

# 分区容忍性 ( Partition tolerance )

分区容忍性指 “ the system continue to operate despite arbitrary message loss or failure of part of the system. ”，即分布式系统在遇到某节点或网络分区故障时，仍然能够对外提供满足一致性和可用性的服务。

# BASE 理论

BASE 指基本可用 ( Basically Available )、软状态 ( Soft State ) 和最终一致性 ( Eventual Consistency )。

# 基本可用 ( Basically Available )

基本可用是指分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。比如服务降级。

# 软状态 ( Soft State )

软状态是指允许系统存在中间状态，而该中间状态不会影响系统的整体可用性。分布式存储中一般一份数据至少存三个副本，允许不同节点间副本同步的延迟就是软状态的体现。

# 最终一致性 ( Eventual Consistency )

最终一致性是指系统中的所有数据副本经过一段时间后，最终能够达成一致状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

# 康威法则

康威法则也可以倒过来阐述：
Conway’s law reversed：You won’t be able to successfully establish an efficient organization structure that is not supported by your system design(architecture) 。 如果系统架构不支持，你无法建立一个高效的组织；同样，如果你的组织架构不支持，你也无法建立一个高效的系统架构。

# 系统改进三原则

IT 运维管理畅销书《凤凰项目》 的作者 Gene Kim 在调研了众多高效能 IT 组织后总结出支撑 DevOps 运作的三个原理 ( The Three Ways: The Principles Underpinning DevOps )，我认为也是系统改进提升的一般性原理，

# 原理一：系统思考 ( System Thinking )

开发驱动的组织，其能力不是制作软件，而是持续的交付客户价值。价值从业务需求开始，经过研发测试，到部署运维，依次流动，并最终以服务形式交付到客户手中。整个价值链流速并不依赖单个部分 (团队或个人) 的杰出工作，而是受整个价值链最薄弱环节 (瓶颈) 的限制。所以局部优化通常无效，反而招致全局受损。
Gene Kim 特别指出： Any improvements made anywhere besides the bottleneck are an illusion . 在瓶颈之外的任何优化提升都只是幻象。

# 原理二：强化反馈环 ( Amplify Feedback Loops )

过程改进常常通过加强反馈环来达成。原理二强调企业和客户之间、组织团队间、流程上和系统内的反馈环。没有测量就没有提升，反馈要以测量数据为准，通过反馈数据优化改进系统。

# 原理三：持续试验和学习的文化 ( Culture of Continual Experimentation And Learning )

在企业管理文化层面强调勇于试错和持续试验、学习和改进的文化。