架構思維-《信談架構理念》
架構師
閒扯架構師
成為一名知名的架構師，想必是許多程式員的夢想，不僅僅是因為架構師擁有絢麗的光環，也是因為對技術信手拈來指點江山般的自信和篤定的一種無限嚮往。然而要想成為一名合格的架構師，背後卻需要苦行僧的自律。好在合格與不合格目前並沒有明確的界定，眾生百家議論紛紛，各執一詞，所以作者本人不吐不快，發表一下自己眼中架構的相關理念以及架構師應該有的樣子。
文章章節
- 架構的定義理解
- 架構的演進和考量
- 微服務架構
- 架構師的職責
架構的定義和理解
什麼是架構，借用維基百科給出的定義：是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。簡單明瞭，但給人的感覺就是假大空，沒有說出本質性的問題。筆者認為架構實際和專案管理的概念類似，是依託於現有的資源解決掉各個關係人的利益關注點，並對將來應對業務增長有一定的前瞻性的軟體設計。所以我們可以將架構暫時分為兩個部分，一個是業務功能性需求和另一個是非功能性需求。
功能性需求
對系統進行架構前，架構師的首要任務是盡最大可能找出所有的干係人，業務方、產品經理、客戶/使用者、開發經理，工程師、專案經理、測試人員、運維人員、產品運營人員等等都有可能是干係人，架構師要充分和干係人溝通，深入理解他們的關注點和痛點，統籌規劃並出架構解決這些關注點。於此同時一定要解決掉一些潛在的衝突，不同的干係人對系統的關注點不同，比如管理層（可管理性）vs技術方(效能)，業務方(多快好省) vs 技術方（可靠穩定），這些都需要在架構時候需要考量的地方。
非功能性需求
系統的前瞻性體有一大部分是在非功能性上的考量，客戶往往關注的是功能性需求，所以這時候架構師就需要在非非功能性的系統設計方面做出設計。通常要考慮的點有：
非功能性需求
上面的圖基本上涵蓋了系統架構設計非常重要的非功能性需求。
系統的演進和考量
好的架構是演進出來的，不是一開始設計出來的，很多架構師多多少少有完美主義情節，所以開始做架構的時候都是大而全，但是一旦出現問題，往往改動的成本就會很大。這時候我們應該採用小步快跑的形式進行架構。
迭代
可以採用最小可用產品（Minimum Viable Product， MVP）理念，做出最小可用產品，儘快丟給使用者試用，快速獲取客戶反饋，在此基礎上不斷迭代和演化架構和產品。
mvp
在系統真正地投入生產使用之前，再好的架構都只是假設，產品越晚被使用者使用，失敗的成本和風險就越高，而小步行進，通過MVP快速實驗，獲取客戶反饋，迭代演化產品，能有效地減少失敗的風險和成本。
系統架構體系工具
微服務架構
網際網路井噴式的發展，傳統的單體應用已經不能很好的滿足業務的發展，所以微服務大行其道。從技術角度講，我微服務主要體現的是單一職責和關注分離的思想，從單程序模組化進一步擴充套件到跨程序分散式的模組化。微服務是獨立的開發、測試、部署和升級單元，微服務中每個服務可以獨立演變，它的cost of change比較小，整體架構比較靈活，是一種支援創新的演化式架構。
但是微服務有額外成本，需要搭建配套的框架、釋出和監控等基礎設施。初創和小規模團隊不建議採用。主要決定因素是系統複雜性和團隊規模，當到達一個點，單塊架構嚴重影響效率才考慮引入微服務。
架構師的職責
硬技能
所以的硬技能就是主要是針對於技術層面的把控，每一項技術都有深入的理解，知道內部的實現邏輯。在這也是想描述一下架構師到底要不要寫程式碼，其實很難一概而論，筆者認為架構師要寫系統的核心程式碼，即便不寫程式碼，那應該有個前提就是對各種框架已經瞭然於心，對問題有可預見的能力。
軟技能
架構師是軟體開發中比較特殊的角色，除了做系統架構和軟體設計之外，還需要承擔一些管理的技能，規劃產品路線，估算人力資源和時間資源，安排人員職責分工，確定計劃的里程碑，指導工程師工作，工程評估和控制等。這些管理事物需要對產品技術架構，功能模組劃分，技術風險都熟悉才能勝任。
- 架構師在系統架構的初期要進行大量的溝通以便能夠對業務和干係人關注點有深入的瞭解，所以溝通是架構師必須有的技能。
- 更多的關注人而非產品，所以架構師需要尋找一個共同的目標，營造一個大家都能最大限度發揮自我價值的工作氛圍
- 知道是事情成就了人，而非人成就的事情，架構師應該成就他人。
- 共同參與架構，架構不是一個人的，多一種不一樣的聲音，可能會為架構師帶來不一樣的設計理念
- 架構師的目的是做成一種軟體，而非是當老大的。
關注公眾號 架構思維 乾貨搶先看
架構思維