架構師必须掌握的架構設計原则
若是一個架構或設計原则已存在 15 年，比方单一职责和依靠颠倒原则，我可以预期它另有 15 年乃至更久的生命期。原则是比详细技能更抽象，更靠近事物本色，也更經得起時候磨练的工具。這些原则沉淀在架構師的脑海中，终极內化成他的 mindset，以潜意识方法影响和引导他的架谈判設計事情。今天给大師分享下，给我留下深入印象的軟件架構設計和组织原则。
来自 Craig Larman 的軟件設計書《UML 和模式利用》，Larman 在書中提出軟件設計的關頭使命是职责分派，并提炼总结出 9 種 (5 種焦點 +4 種扩大) 軟件职责分派模式，這些模式是比 GoF 設計模式更抽象的元模式。
為工具分派职责的通用原则 – 把职责分派给具有足够信息可以實行职责的專家
将建立 A 的职责赋给 B，若是最少下面一種環境為真：
B“包括”或聚合 A
B 記實 A 的實例
B 紧密親密地利用 A
B 具有 A 的初始化数据
付與职责使得工具間的耦合度尽量低，最小化工具間的依靠和變動影响，最大化重用。
付與职责使得每一個工具的职责尽量連结聚焦和单一，易于辦理和理解。
把职责付與體系、装备或子體系的暗示類 (門面節制器)，或某個用例的暗示類 (用例節制器)，讓節制器接管事務并协调解個體系的運作。
将职责分派给多個具备同名法子的多态子類，運行時按照必要動态切换子類，讓體系举動變得可插拔。
针對真實問題域中不存在，可是設計建模中有效的观點，設計虚構類并付與职责。
在两個或多個工具間有交互的環境下，為防止直接耦合，提高重用性，建立中心類并付與职责，工具的交互交由中心類和谐。
简略讲就是封装變革。辨認體系中可能的不不乱或變革，在不不乱组件上建立不乱的抽象接口，将可能的變革封装在接口以後，使得體系內部的不不乱或變革不會對體系的其它部門發生不良影响。
S.O.L.I.D 是面向工具設計和编程 (OOD&OOP) 中几個首要原则的首字母缩寫，受 Robert Martin 推重。
點窜某個類的来由應當只有一個，若是跨越一個，阐明類承當不止一個职责，要視環境拆分。
軟件實體應當對扩開展放，對點窜封锁。一般不要直接點窜類库源码（即便你有源代码），經由過程担當等方法扩大。
當一個子類的實例可以或许被更换成任何超類的實例時，它們之間才是真實的 is-a 瓜葛。
高层模块不该该依靠于底层模块，两者都應當依靠于抽象。换句话說，依靠于抽象，不要依靠于详细實現。例如說，你不會把電器電源線焊死在室內電源接口處，而是用尺度的插頭插在尺度的插座 (抽象) 上。
不要逼迫用户去依靠它們不利用的接口。换句话說，利用多個專門的接口比利用单一的大而全接口要好。
GRASP 和 SOLID 設計原则,對我影响很深，特别是单一职责，信息專家，存眷分手，依靠颠倒 封装變革，分而治之等焦點原则，如今平常研發中我時經常使用這些原则引导新手工程師。
高內聚 + 低耦合，就像道中的一阴一陽，是所有其它 OO 設計原则的原则 (元原则)，其它設計原则都是在這两個根本上泛化衍生出来的。
上述原则固然是针對 OO 設計和编程提出，可是@對%58P4H%付大范%l2411%围@體系架構依然合用。好比，微辦事架構就表現了：
单一职责：一個微辦事尽量要职责单一，供给的接口也尽量单一 (接口分手原则)，平安 路由 限流等跨横切面的存眷點 (Cross-Cutting Concerns) 由自力網關賣力，表現存眷分手 (Separation of Concerns)。
信息專家：當不肯定哪一個團隊應當賣力某個微辦事時，一般原则也是谁具有数据谁賣力，基于治療咽喉腫痛，有界上下文 Bounded Context（通常為鸿沟比力清楚的范畴数据源）構建微辦事。
疏松耦合：辦事之間經由過程 HTTP/JSON 等轻量機制通讯，辦事之間不强耦合。
受庇護的變革和依靠颠倒：辦事之間只依靠抽象接口，實現可能随時變革。
間接：網關在外面的客户端和內部的辦事之間增长了一层間接，使二者不强耦合，可以互相自力演變。
作為架構師或設計師，有两個設計能力是必要重點培育的，也是最難和最能表現架構設計程度的：
公道的职责分派能力，也就是每一個類 组件 子體系應當承當甚麼职责，若何包管职责单一，它們之間若何协作；
體系抽象和焦點范畴建模能力，必要深刻一線营業域。
這 15 個架構原则来自《架構即将来 (The Art of Scalability)》 一書，作者马丁 L. 阿伯特和迈克尔 T. 费舍尔别離是 eBay 和 PayPal 的前 CTO，他們履历過 eBay 和 PayPal 大范围散布式電商平台的架構演進，在一線實战履历的根本上总结并提炼出 15 條架構原则：
永久不要少于两個，凡是為三個。例如說無状况的 Web/API 一般摆設最少>=2 個。
确保體系可以回滚到之前公布過的任何版本。可以經由過程公布體系保存汗青版本，或代码中引入動态開關怀换機制 (Feature Switch)。
可以或许封闭任何公布的功效。新功效暗藏在動态開關機制 (Feature Switch) 後面，可以按需一键打開，如發明問題随時封闭禁用。
在設計阶段就必需斟酌监控，而不是在施行终了以後弥补。比方在需求阶段就要斟酌關頭指標监控項，這就是怀抱驱動開辟 (Metrics Driven Development) 的理念。
不要被一個数据中間的解决方案把本身限定住。固然也要斟酌本錢和公司范围成长阶段。
只用确切好用的技能。贸易组织究竟结果不是钻研機構，技能要落地适用，成熟的技能一般坑都被踩平了，新技能在彻底成熟前一般必要踩坑躺坑。
能异步尽可能用异步，只有當绝對需要或没法异步時，才利用同步伐用。
尽量無状况，只有當营業确切必要，才利用状况。無状况體系易于扩大，有状况體系不容易扩大且状况繁杂時更容易犯错。
永久不要依靠更大、更快的體系。一般公司發展到必定阶段廣泛履历過買更大、更快體系的阶段，即便淘宝昔時也買小型機扛流量，厥後扛不住才领會如许做不 scalable，以是才有厥後的去 IOE 举措。
在扩大性問題產生前斟酌好下一步的举措規劃。架構師的價值就體如今這里，架構設計對付流量的增加要有提早量。
若是不是你最长于，也供给不了差别化的竞争上風则直接采辦。防止 Not Invented Here 症状，防止凡事都要重造轮子，究竟结果告竣营業方针才是重點。
在大大都環境下，廉價的就是最佳的。這點和第 9 點是一致的，經由過程商品化硬件程度扩大，而不是買更大、更快的體系。
全数研發要小構建，不竭迭代，讓體系不竭發展。這個和微辦事理念一致。
實現妨碍断绝設計，經由過程断路庇護三重通水管,防止妨碍傳布和交织影响。經由過程舱壁泳道等機制断绝失败单位 (Failure Unit)，一個单位的失败不至影响其它单位的正常事情。
設計和構建主動化的進程。若是呆板可以做，就不要依靠于人。主動化是 DevOps 的根本。
這 15 條架構原则根基上是 eBay 在成长，履历過流量数目级增加打击進程中，經由過程不竭踩坑踩出来的，是干貨中的干貨。消化吸取這 15 條原则，根基可保體系架構不會有原则性問題。
這 15 條原则一样合用于如今的微辦事架構。eBay 成长较早，它內部實在很早 (差未几 2010 年前) 就已構成完美的微辦事生态，只是没有提出微辦事這個观點。
這 15 條原则可按照 TTM(Time To Market)，可用性 可扩大性 質量，本錢 效力散布在三個環內，以下圖所示。
Heroku是外洋知名的云利用平台。基于上百万利用的托管和運营履历，開創人 Adam Wiggins 提出了 12 要素利用宣言。简略讲，知足這 12 個要素的利用是比力轻易云化并栖身在 Heroku 平台上的。
一份基房屋二胎，准代码，多份摆設。若是用镜像摆設方法，则一個镜像可以摆設到多個情况 (测試，预發，出產)，而不是给每一個情况建造一個分歧镜像。
顯式声明依靠。若是用镜像摆設，则一般依靠被直接打在镜像中，或声明在 docker file 中。
在情况中存储設置装备摆設。在 Heroku 或雷同的 PaaS 平台上，設置装备摆設通常為举薦注入到情况變量中的。如今采纳集中式設置装备摆設中間也是一種風行方法。
把後端辦事 (比方缓存，数据库，MQ 等) 看成附加資本，相干設置装备摆設和毗連字符通同過情况變量注入，或采纳設置装备摆設中間。
严酷分手構建和運行。若是利用镜像摆設，则構建、公布 運行是經由過程镜像這類中心格局严酷分手的。
一個或多個無状况的過程運行利用。容器運行時至關于過程，合用于無状况 Web/API。
經由過程端口绑定供给辦事。容器也是經由過程端口绑定對外供给辦事。
經由過程過程模子举行扩大。容器運行時至關于過程，經由過程起多個容器可以肆意扩大并發数目。
快速启動和優雅终止可最大化硬朗性。docker 容器支撑秒级启動和封闭。
尽量連结開辟、测試、预發和線上情况不异。容器可以包管容器內運行時情况的一致性，還必要包管分歧情况的一致性，比方分歧情况內的操作體系，负载平衡，辦事發明，後台辦事，监控诉警等要尽量一致。
把日記看成数据流。Heroku 不支撑當地文件，以是必需以流方法把日記運送到後台日記辦事。除日記之外還要弥补斟酌 metrics 流的收集和運送。
後台辦理使命看成一次性的過程。實在至關于在 Heroku 上以自力過程方法運行使命 Job。
12 要素利用也是當前云原生利用 (Cloud Native App) 的参考尺度，我把這 12 要素也称為云利用迁徙原则。知足這 12 個要素的利用，可以比力顺遂迁徙到各類云平台 (Kubernetes, Marathon, Cloud Foundry 等) 上。
對付面對企業遗留利用革新和云化迁徙的架構師，可以重點参考這 12 條迁徙原则。
Docker 容器技能可以認為是為云迁徙量身定制的技能。容器化是後续云迁徙的捷径，以是遗留利用革新可以先想法子做到容器化。
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.”，即散布式體系在碰到某節點或收集分區妨碍時，依然可以或许對外供给知足一致性和可用性的辦事。
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 co妹妹unication 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 版)
架構即将来：現代企業可扩大的 Web 架構、流程和组织 (原書第 2 版)
Heroku 云利用平台
The Twelve-Factor App
康威法例
企業的组织架構是若何影响技能架構的
痛定思痛，谈發展型公司應當若何冲破方轮子困局！
凤凰項目：一個 IT 運维的傳奇故事
The Three Ways: The Principles Underpinning DevOps
頁:
[1]