2016，我們一起追過的架構
年終復盤，總結那些滋養我成長的架構思想。謂之曰：transformation!
1 屬性派
任何系統必有其自身的架構屬性。
An architecture—a system’s attributes—and what an architect produces—a set of documents—definitely are not the same thing.
An architectural description (AD) is a set of artifacts that documents an architecture in a way its stakeholders can understand and demonstrates that the architecture has met their concerns.
石頭記：選錄這個觀點并把它放在本文第一個，是想摧毀架構師的個人主義和英雄主義，以及提醒架構的ownership在團隊。特別是在大型組織中，軟件架構有時是不受控制的。
2 組成派
軟件架構是軟件組件及其屬性，組件之間關系組成的系統結構。
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
An architectural element (or just element) is a fundamental piece from which a system can be considered to be constructed.
石頭記：這是教科書，也是最基礎的思維方式。個人認為組成派更多是從空間維度考慮架構。
3 決策派
軟件架構是軟件一些重要方面決策的集合。這種說法的典型代表是RUP中對于軟件架構的定義。
軟件架構包含了關于以下問題的重要決策：
1.軟件系統的組織;
2.選擇組成系統的結構元素和它們之間的接口，以及當這些元素相互協作時所體現的行為;
3.如何組合這些元素，使它們逐漸組成更大的子系統;
4.用于指導這個系統組織的架構風格：這些元素以及他們的接口、協作和組合。
5.軟件架構并不僅僅注重軟件本身的結構和行為，還注重其它特性：功能性、性能、可擴展性、可重用性、可理解性以及美學等等。
石頭記：依然是教課書般定義，更有設計的感覺。
4 橋梁派
Software Architecture in Context is the crucial bridge between requirements and design.
This interplay is core to the architectural process
石頭記：架構是需求和設計之間的橋梁，并且特別強調和需求方，設計方的互動。這是瀑布研發的思維。
5 平衡派
架構是各個方面因素平衡的結果。
石頭記：特別務實的定義方式。花名叫做："tradeoff"。
6 康威定律：組織結構決定軟件架構
Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.
設計系統的組織，最終產生的設計等同于組織之內、之間的溝通結構。
石頭記：意識到康威定律，是架構師成熟的標志。在微服務架構流行的今天，康威定律被一再的提及。微服務的本質是技術倒逼組織結構變革。“你建構了你所知，你所知又影響了建構的方式。”——這或許就是架構和架構師的關系吧。
7 建筑派：堅固，實用，美觀
公元前1世紀，古羅馬御用工程師、建筑師Marcus Vitruvius Pollio在其《建筑十書》中最早提出了建筑的三要素“堅固、實用、美觀”。英文的表述為Firmitas, Utilitas, Venustas，通俗的說也就是Solid, Useful, Beautiful，用計算機的術語表述就是：
Firmness: Achieve a satisfactory level of freedom from damaging failure.
Commodity: Utility to accomplish the tasks it is purported to be for.
Delight: Pleasure in use.
石頭記：時至今日，這三個要素仍然是優秀軟件架構的重要組成部分。
8 The “4+1” View Model
邏輯視圖主要強調面向對象設計;進程視圖主要強調并發和同步;物理視圖主要強調軟件和硬件的映射;部署視圖則強調軟件在部署環境中的靜態組織。場景則強調主需求或者用例。
石頭記：經典的“4+1”架構視圖，有很多衍生版本。架構師入門必備，是指導軟件架構設計，開發實現的重要思想。
9 使用視圖與視角與利益相關者合作
利益相關者是對架構感興趣的任何人和組織。關切是利益相關者對架構的任何期許，需求，或目標。
視圖是架構對利益相關者關切的結構化呈現。視角是構建視角的模式，模板。
使用視圖和視角的第一個好處是關注點分離。單一視角和很難描述一個復雜系統的架構的。其次是便于和利益相關者溝通。同時便于對系統復雜性進行管理和增加開發者的關注度。其缺點是分片視圖，錯誤視角的選擇和視角之間的不一致性。
架構透視是保證系統屬性的一系列活動，策略，指導。
石頭記：基礎且經典的架構方法。合格架構師拿證的license。掌握此法，可以闖蕩架構江湖，還特別適合在大型組織混跡，玩技術。推薦經典書籍：《軟件架構設計》，《軟件架構師12項修煉》，《軟件系統架構:使用視點和視角與利益相關者合作》。
10 以終為始
石頭記：
作者右軍是從架構到團隊管理，回頭再看架構。初級的架構師往往關注在邊界和職責，只掃自家門前雪，避免背鍋，并以此為榮。作者一針見血，站在用戶需求角度考慮架構——以終為始的架構觀——闡述了一個良心架構的思考和擔當：不為未來挖坑。
作者首創的PMC框架(P>platform\M>merchant\C>customer)值得所有互聯網行業的專家借鑒。
從作者的行文中，我對架構的體察總結是：
1.架構的空間屬性：視圖，視角，層次
2.架構的時間屬性：動態，演進
3.架構的組成屬性：功能，質量(非功能)
全文以黃金圈理論組織結構，是謂本章架構。
本文有真意，欲辨已忘言。請閱讀原文體會妙處。
11 閉環架構
系統架構層面的閉環主要體現在系統監控方面，系統監控主要分為三個層次：
1.系統層監控，監控底層硬件如CPU、網絡和存儲等的性能狀況;
2.應用層監控，監控應用性能如頁面/服務調用計數，調用延遲，錯誤計數等;
3.業務層監控，監控重要的業務指標如PV/UV，用戶登錄數和訂單量等。
上圖是一個假想的電商網站的分層架構圖，
1.系統層監控，監控底層硬件如CPU、網絡和存儲等的性能狀況;
2.應用層監控，監控應用性能如頁面/服務調用計數，調用延遲，錯誤計數等
3.業務層監控，監控重要的業務指標如PV/UV，用戶登錄數和訂單量等。
石頭記：作者楊波的文章是我今年認知升級最大信息來源。閉環思維也適用于人，組織，流程。
12 演進架構
網站在不同的階段遇到的問題不一樣，而解決這些問題使用的技術也不一樣，流量小的時候，主要目的是提高開發效率，在早期要引入ORM，DAO這些技術。隨著流量變大，使用動靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC等方式不斷地提升網站穩定性。面對更大的流量時，通過垂直拆分、服務化、反向代理、開發框架(站點/服務)等等，不斷提升高可用。在面對上億級的更大流量時，通過中心化、柔性服務、消息總線、自動化(回歸，測試，運維，監控)來迎接新的挑戰。未來的就是繼續實現移動化，大數據實時計算，平臺化……系統架構會一直迭代衍變，就像最初的從零到現在。
石頭記：演化思想是敏捷架構的核心。對很多創業公司，需要仔細讀讀58同城的技術委員會執行主席沈劍的這邊文章。
13 全棧架構
“全棧，不是全能，和所選擇的技術棧甚至業務棧相關。”，老曹這么描述全棧的定義。“我說過全棧架構師可能是自己的杜撰， 但是，全棧思維優先還是被大多數朋友認可的，實際上是一種大局觀，一個功能既可以前端又可以后端實現，利弊和方案的選擇是需要有全棧架構師的，至少要有全棧的思維。全棧的思維，簡單地可以理解成系統的思維方式。”
如果問題分為：已知的已知，已知的未知，未知的未知 的話，全棧架構師這一角色，就是從未知的未知變成已知的未知。
石頭記：全棧思維和全棧能力，架構師的硬技能。
14 軟件是用戶參與的協同創造
張林老師從一個問題出發：你重新開發一個微信，和微信的功能一模一樣，還是微信嗎?沒有用戶的微信它還是微信嗎?由此推導出軟件是代碼+算法+數據結構+用戶。
由此，軟件開發就是開發者和用戶群體創造的信息再造過程。而架構是對大量無結構的信息進行重構整合梳理，得到有結構的信息的過程。
石頭記：是技術承載雙11的狂歡?還是雙11的狂歡塑造了技術架構?
15 架構擴展立方體
石頭記：推薦經典書籍《架構即未來》。
16 架構擴展原則
AKF采用的最普遍的架構原則
1、N+1設計
2、回滾設計
3、禁用設計
4、監控設計
5、設計多活數據中心
6、使用成熟的技術
7、異步設計
8、無狀態系統
9、水平擴展非垂直升級
10、設計至少要有兩個步驟的前瞻性
11、非核心則購買
12、使用商品化硬件
13、小構建、小發布、快試錯
14、隔離故障
15、自動化
石頭記：推薦經典書籍《架構即未來》。
17 OKR架構觀
石頭記：這個是石頭的杜撰。石頭一直認為，優秀的架構師應該首先負責關鍵技術的突破，解決技術可行性問題，拿出從0到1的那些關鍵結果。
18 架構六步思考法
美團點評外賣配送和到店餐飲總架構師夏華夏總結架構師三大能力和六步思考法。
架構師三大能力：
1.站的高——考慮“整體”：站在更高的層次綜合看問題
2.望的遠——考慮“未來”：良好的前瞻和規劃
3.扎的深——考慮“細節”：洞察底層落地的細節
架構六步思考法：
石頭記：架構過程的閉環，很多團隊都沒有完成這個閉環吧?
19 開發運維三板斧
The Three Ways: The Principles Underpinning DevOps.
石頭記：強調從開發到運維的價值流，打破組織壁壘。并在這個價值流上增強反饋閉環，提高交付效率。團隊文化上支持不斷試錯。思考一下三板斧是否反映出你的組織存在的問題?
20 領域驅動架構設計
【本文是51CTO專欄作者石頭的原創文章，轉載請通過作者微信公眾號補天遺石(butianys)獲取授權】
