乐趣区

关于后端:架构师必须掌握的架构设计原则

jiezi

如果一个架构或设计准则曾经存在 15 年，例如繁多职责和依赖倒置准则，我能够预期它还有 15 年甚至更久的生命期。准则是比具体技术更形象，更靠近事物本质，也更经得起工夫考验的货色。这些准则积淀在架构师的脑海中，最终内化成他的 mindset，以潜意识形式影响和领导他的架构和设计工作。

明天给大家分享下，给我留下深刻印象的软件架构设计和组织准则。

软件设计准则

GRASP 通用职责调配软件模式

来自 Craig Larman 的软件设计书《UML 和模式利用》，Larman 在书中提出软件设计的要害工作是职责调配，并提炼总结出 9 种 (5 种外围 +4 种扩大) 软件职责分配模式，这些模式是比 GoF 设计模式更形象的元模式。

  1. 信息专家 (Information Expert)

为对象调配职责的通用准则 – 把职责调配给领有足够信息能够履行职责的专家

  1. 创建者 (Creator)

将创立 A 的职责赋给 B，如果至多上面一种状况为真：

  • B“蕴含”或者聚合 A
  • B 记录 A 的实例
  • B 亲密地应用 A
  • B 领有 A 的初始化数据
  1. 低耦合 (Low Coupling)

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

  1. 高内聚 (High Cohesion)

赋予职责使得每个对象的职责尽可能放弃聚焦和繁多，易于治理和了解。

  1. 控制器 (Controller)

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

  1. 多态 (Polymorphism)

将职责调配给多个具备同名办法的多态子类，运行时依据须要动静切换子类，让零碎行为变得可插拔。

  1. 纯虚构 (Pure Fabrication)

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

  1. 间接 (Indirection)

在两个或者多个对象间有交互的状况下，为防止间接耦合，进步重用性，创立两头类并赋予职责，对象的交互交由两头类协调。

  1. 受爱护的变动 (Protected Variation)

简略讲就是封装变动。识别系统中可能的不稳固或者变动，在不稳固组件上创立稳固的形象接口，将可能的变动封装在接口之后，使得零碎外部的不稳固或者变动不会对系统的其它局部产生不良影响。

SOLID 面向对象设计准则

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

  1. 繁多职责准则 (The Single Responsibility Principle)

批改某个类的理由应该只有一个，如果超过一个，阐明类承当不止一个职责，要视状况拆分。

  1. 凋谢关闭准则 (The Open Closed Principle)

软件实体应该对扩大凋谢，对批改关闭。个别不要间接批改类库源码（即便你有源代码），通过继承等形式扩大。

  1. 里氏代替准则 (The Liskov Substitution Principle)

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

  1. 依赖倒置准则 (The Dependency Inversion Principle)

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

  1. 接口拆散准则 (The Interface Segregation Principle)

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

解读

GRASP 和 SOLID 设计准则, 对我影响很深，尤其是繁多职责，信息专家，关注拆散，依赖倒置 封装变动，分而治之等外围准则，当初日常研发中我时罕用这些准则领导老手工程师。

高内聚 + 低耦合，就像道中的一阴一阳，是所有其它 OO 设计准则的准则 (元准则)，其它设计准则都是在这两个根底上泛化衍生进去的。

上述准则尽管是针对 OO 设计和编程提出，然而对于大规模零碎架构依然实用。比方，微服务架构就体现了：

繁多职责 ：一个微服务尽可能要职责繁多，提供的接口也尽可能繁多 (接口拆散准则)，平安 路由 限流等跨横切面的关注点 (Cross-Cutting Concerns) 由独立网关负责，体现关注拆散 (Separation of Concerns)。

信息专家：当不确定哪个团队应该负责某个微服务时，个别准则也是谁领有数据谁负责，基于有界上下文 Bounded Context（个别是边界比拟清晰的畛域数据源）构建微服务。

涣散耦合 ：服务之间通过 HTTP/JSON 等轻量机制通信，服务之间不强耦合。

受爱护的变动和依赖倒置：服务之间只依赖形象接口，实现可能随时变动。

间接：网关在里面的客户端和外部的服务之间减少了一层间接，使两者不强耦合，能够互相独立演变。

作为架构师或者设计师，有两个设计能力是须要重点造就的，也是最难和最能体现架构设计程度的：

正当的职责调配能力，也就是每个类 组件 子系统应该承当什么职责，如何保障职责繁多，它们之间如何合作；

零碎形象和外围领域建模能力，须要深刻一线业务域。

分布式系统架构设计准则和实践

AKF 架构准则

这 15 个架构准则来自《架构即将来 (The Art of Scalability)》一书，作者马丁 L. 阿伯特和迈克尔 T. 费舍尔别离是 eBay 和 PayPal 的前 CTO，他们经验过 eBay 和 PayPal 大规模分布式电商平台的架构演进，在一线实战经验的根底上总结并提炼出 15 条架构准则：

  1. N + 1 设计

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

  1. 回滚设计

确保零碎能够回滚到以前公布过的任何版本。能够通过公布零碎保留历史版本，或者代码中引入动静开关切换机制 (Feature Switch)。

  1. 禁用设计

可能敞开任何公布的性能。新性能暗藏在动静开关机制 (Feature Switch) 前面，能够按需一键关上，如发现问题随时敞开禁用。

  1. 监控设计

在设计阶段就必须思考监控，而不是在施行结束之后补充。例如在需要阶段就要思考要害指标监控项，这就是度量驱动开发 (Metrics Driven Development) 的理念。

  1. 设计多活数据中心

不要被一个数据中心的解决方案把本人限制住。当然也要思考老本和公司规模倒退阶段。

  1. 应用成熟的技术

只用的确好用的技术。商业组织毕竟不是钻研机构，技术要落地实用，成熟的技术个别坑都被踩平了，新技术在齐全成熟前个别须要踩坑躺坑。

  1. 异步设计

能异步尽量用异步，只有当相对必要或者无奈异步时，才应用同步调用。

  1. 无状态零碎

尽可能无状态，只有当业务的确须要，才应用状态。无状态零碎易于扩大，有状态零碎不易扩大且状态简单时更易出错。

  1. 程度扩大而非垂直降级

永远不要依赖更大、更快的零碎。个别公司成长到肯定阶段广泛经验过买更大、更快零碎的阶段，即便淘宝当年也买小型机扛流量，起初扛不住才领会这样做不 scalable，所以才有起初的去 IOE 口头。

  1. 设计时至多要有两步前瞻性

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

  1. 非核心则购买

如果不是你最善于，也提供不了差异化的竞争劣势则间接购买。防止 Not Invented Here 症状，防止凡事都要重造轮子，毕竟达成业务指标才是重点。

  1. 应用商品化硬件

在大多数状况下，便宜的就是最好的。这点和第 9 点是统一的，通过商品化硬件程度扩大，而不是买更大、更快的零碎。

  1. 小构建、小公布和快试错

全副研发要小构建，一直迭代，让零碎一直成长。这个和微服务理念统一。

  1. 隔离故障

实现故障隔离设计，通过断路爱护防止故障流传和穿插影响。通过舱壁泳道等机制隔离失败单元 (Failure Unit)，一个单元的失败不至影响其它单元的失常工作。

  1. 自动化

设计和构建自动化的过程。如果机器能够做，就不要依赖于人。自动化是 DevOps 的根底。

解读

这 15 条架构准则基本上是 eBay 在倒退，经验过流量数量级增长冲击过程中，通过一直踩坑踩进去的，是干货中的干货。消化吸收这 15 条准则，根本可保零碎架构不会有原则性问题。

这 15 条准则同样实用于当初的微服务架构。eBay 倒退较早，它外部其实很早 (差不多 2010 年前) 就已造成欠缺的微服务生态，只是没有提出微服务这个概念。

这 15 条准则可依据 TTM(Time To Market)，可用性 可扩展性 品质，老本 效率散布在三个环内，如下图所示。

12 因素利用

Heroku 是国外出名的云利用平台。基于上百万利用的托管和经营教训，创始人 Adam Wiggins 提出了 12 因素利用宣言。简略讲，满足这 12 个因素的利用是比拟容易云化并寓居在 Heroku 平台上的。

  1. 基准代码

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

  1. 依赖

显式申明依赖。如果用镜像部署，则个别依赖被间接打在镜像中，或者申明在 docker file 中。

  1. 配置

在环境中存储配置。在 Heroku 或者相似的 PaaS 平台上，配置个别是举荐注入到环境变量中的。当初采纳集中式配置核心也是一种风行形式。

  1. 后端服务

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

  1. 构建、公布和运行

严格拆散构建和运行。如果应用镜像部署，则构建、公布 运行是通过镜像这种两头格局严格拆散的。

  1. 过程

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

  1. 端口绑定

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

  1. 并发

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

  1. 易解决

疾速启动和优雅终止可最大化健壮性。docker 容器反对秒级启动和敞开。

  1. 开发环境和线上环境等价

尽可能放弃开发、测试、预发和线上环境雷同。容器能够保障容器内运行时环境的一致性，还须要保障不同环境的一致性，例如不同环境内的操作系统，负载平衡，服务发现，后盾服务，监控告警等要尽可能统一。

  1. 日志

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

  1. 治理过程

后盾治理工作当作一次性的过程。其实相当于在 Heroku 上以独立过程形式运行工作 Job。

解读

12 因素利用也是以后云原生利用 (Cloud Native App) 的参考规范，我把这 12 因素也称为云利用迁徙准则。满足这 12 个因素的利用，能够比较顺利迁徙到各种云平台 (Kubernetes, Marathon, Cloud Foundry 等) 上。

对于面临企业遗留利用革新和云化迁徙的架构师，能够重点参考这 12 条迁徙准则。

Docker 容器技术能够认为是为云迁徙量身定制的技术。容器化是后续云迁徙的捷径，所以遗留利用革新能够先想方法做到容器化。

CAP 定理

2000 年 7 月，加州大学伯克利分校的 Eric Brewer 传授在 ACM PODC 会议上提出 CAP 猜测。2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从实践上证实了 CAP。之后，CAP 实践正式成为分布式计算畛域的公认定理。

CAP 认为：一个分布式系统最多同时满足一致性 (Consistency)，可用性 (Availability) 和分区容忍性 (Partition Tolerance) 这三项中的两项。

1. 一致性 (Consistency)

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

2. 可用性 (Availability)

可用性指“Reads and writes always succeed”，即服务始终可用，而且响应工夫失常。

3. 分区容忍性 (Partition tolerance)

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

BASE 实践

eBay 架构师 Dan Pritchett 基于对大规模分布式系统的实际总结，在 ACM 上发表文章提出了 BASE 实践，BASE 实践是对于 CAP 实践的延长，核心思想是即便无奈做到强一致性 (Strong Consistency，CAP 中的一致性指强一致性)，然而能够采纳适当的形式达到最终一致性 (Eventual Consistency)。

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

1. 根本可用 (Basically Available)

根本可用是指分布式系统在呈现故障时，容许损失局部可用性，即保障外围可用。比方服务降级。

2. 软状态 (Soft State)

软状态是指容许零碎存在中间状态，而该中间状态不会影响零碎的整体可用性。分布式存储中个别一份数据至多存三个正本，容许不同节点间正本同步的提早就是软状态的体现。

3. 最终一致性 (Eventual Consistency)

最终一致性是指零碎中的所有数据正本通过一段时间后，最终可能达成统一状态。弱一致性和强一致性相同，最终一致性是弱一致性的一种非凡状况。

解读

CAP 和 BASE 实践能够抠得很深，背地甚至有很简单的数学证实。我了解得绝对简略通俗：性能、高可用、不丢数据和数据一致性对分布式系统来说个别是强需要，随着流量的增长，复制和分区在劫难逃：

复制 (replication)：数据在多个节点上存多份保障不丢和高可用；

分区 (partition)：数据按某个纬度切分散布在不同节点上摊派流量压力保障高性能，同时也是为了升高每个节点的复杂性。例如数据库的分库分表，零碎拆分微服务化也是一种分区。这两者都会带来一致性问题，一致性在工夫上有一点斗争的余地 – 即是最终一致性；工夫上要求强统一的话，只有可用性能够适当折中。零碎架构的游戏很大部分是和状态一致性作奋斗的游戏。

抉择应用分布式产品时，比方 NoSQL 数据库，你须要理解它在 CAP 环中所在的地位，确保它满足你的场景须要。

组织和零碎改良准则

康威法令

Melvin Conway 在 1967 年提出所谓康威法令，指出组织架构和零碎架构之间有一种隐含的映射关系：

Organization which design system […] are constrained to produce designs which are copies of the communication structures of these organization. 设计零碎的组织其产生的设计等价于组织间的沟通构造。

康威法令也能够倒过去论述：

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)

在企业治理文化层面强调敢于试错和继续试验、学习和改良的文化。

解读

康威法令给咱们的启发：零碎架构和组织架构之间有隐含的映射关系，你不能单方面扭转一方的构造，调整时必须两边联动。零碎架构如果是耦合的，就很难组织分散式的团队构造，两边映射不起来，团队之间容易摩擦导致生产率降落。所以个别先按业务边界对单块利用进行解耦拆分，同时做相应的团队拆分，使两边能够映射，每个团队能够独立开发、测试和部署各自的微服务，进而晋升生产率。这就是近年风行的微服务架构背地的组织准则。

零碎思考要求咱们增强团队单干，造就流式思维和瓶颈束缚思维，找出瓶颈并针对性地优化。在研发型组织中，常见的零碎瓶颈如运维机器资源提供 (Provisioning) 迟缓，公布流程繁琐容易出错，开发 测试/UAT 环境缺失或不欠缺，遗留零碎耦合历史负担重，根底研发平台单薄等等。这些瓶颈点特地须要关注优化。

反馈原理要求咱们关注基于数据的反馈，技术上的伎俩包含大数据分析和零碎各个档次的测量监控。没有测量就没有反馈，没有反馈就没有晋升。

在治理文化层面：

管理层要抵赖企业外部近 50% 的翻新或流程改良我的项目是有可能失败的，即便失败，员工不会受到责罚，激励继续的试验和从中学习；

管理层要有技术偿债意识，勿谋求 100% 员工利用率，要预留 20%~30% 的工夫给员工做翻新和零碎改良晋升我的项目。

总结

上述准则是架构师必须深刻了解和把握的，然而不能盲从，理论工作中要依据业务、工夫、资源和团队状况随机应变。准则有时甚至能够被违反，当然这样做肯定有老本，架构师要意识这一点，并适时变通弥补。

参考
UML 和模式利用 (原书第 3 版)

https://www.amazon.cn/UML%E5%92%8C%E6%A8%A1%E5%BC%8F%E5%BA%94…

架构即将来：古代企业可扩大的 Web 架构、流程和组织 (原书第 2 版)

https://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B01DXW29IM

Heroku 云利用平台

https://www.heroku.com/

The Twelve-Factor App

https://12factor.net/zh_cn/

康威法令

https://en.wikipedia.org/wiki/Conway%27s_law

企业的组织架构是如何影响技术架构的

http://www.infoq.com/cn/articles/organization-arch-influence-…

痛定思痛，谈成长型公司应该如何冲破方轮子困局！

http://www.sohu.com/a/123304174_467759

凤凰我的项目：一个 IT 运维的传奇故事

https://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B016VW1I6U

The Three Ways: The Principles Underpinning DevOps

https://itrevolution.com/the-three-ways-principles-underpinni…

本文由 mdnice 多平台公布

退出移动版