正文共： 3166字 10圖 預計閱讀時間： 8分鐘程序員
在2020年這個非同尋常的年份裏面，本身與團隊小夥伴一塊兒利用周例會時間，分享學習了《架構整潔之道》系列內容，同團隊一塊兒學習成長。在這個歲末年終的日子裏，來對本身本年度帶領團隊學習成長作個總結，分享給你們參考。數據庫
本文主要內容思路圍繞如下幾點：編程
-
經過系列學習分享，咱們get到了什麼？安全
-
咱們搞這個系列的分享，初衷是什麼？微信
-
經過系列分享，是否能夠指導咱們技術設計？多線程
Part1：收穫
1.1 《架構整潔之道》系列內容
主要內容總結一下，主要分如下幾部分：架構
-
編程範式（結構化編程、面向對象編程和函數式編程）併發
-
設計原則（主要是SOLID）異步
-
組件處理（依賴、邊界）分佈式
-
軟件架構（其中講了不少高屋建瓴的內容）
簡單概況一下即包括 微觀（代碼層面）和宏觀（架構層面）兩個層面的主要開發技能。
1.2 「架構」究竟是什麼？
可能咱們每天會說到「架構」，那它究竟是什麼呢？
軟件架構（software architecture）
有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。-- 來自維基百科
系統實際上是一羣關聯個體的組成，系統中的個體須要「根據某種規則」協做，架構須要明確這種協做規則。
架構＝骨架、結構，源於建築學。
骨架 揭示架構中內在的支撐物；
結構 則代表架構關心支撐物相互結合的某種構造方式。
架構的價值是什麼呢？
-
最少的人力成本知足構建和維護該系統的需求
-
支撐軟件系統的全生命週期，讓系統便於理解、易於修改、方便維護、輕鬆部署
1.3 「架構」的目的是什麼？
架構設計的主要目的是爲了解決軟件系統複雜度帶來的問題。
當明確了架構的目的以後，會有哪些好處？
主要對於「老鳥」架構師與「新手」架構師區分而言
-
心中有數，而不是一頭霧水
-
有的放矢，而不是貪大求全
現實中咱們還會遇到一些這樣的討論：
-
「咱們的系統必定要作到QPS 10w」
-
「淘寶的架構就是這麼作的，咱們也要這樣」
-
「Docker如今很熱，咱們的架構應該將Docker引入進來」
影響咱們作決策的首要依據應該是系統複雜度，那該如何分析呢？
1.4 複雜度主要分析點
系統複雜度主要分爲如下幾點：
-
高性能
單機複雜度、集羣複雜度
-
高可用
計算高可用、存儲高可用
-
可擴展性
預測變化、應對變化
-
低成本
創新（NoSQL、全文搜索引擎、Hadoop）
Facebook HHVM、新浪微博 SSD Cache、LinkedIn Kafka
NoSQL爲了解決關係型數據庫沒法對應高併發訪問帶來的訪問壓力
全文搜索引擎爲了解決關係型數據庫like檢索低效的問題
Hadoop爲了解決傳統文件系統沒法應對海量數據存儲和計算的問題
-
安全性
功能安全、架構安全
-
規模程度
量變引發質變
功能越多（數據越多），致使系統複雜度指數級上升
1.5 架構設計的原則有哪些？
一樣的代碼，不管是不是同一人寫的，執行結果是肯定的，可是同一個系統，不一樣的架構師，最終均可以解決問題，但設計方案卻可能大不相同。
架構設計的原則主要是解決不肯定性，也是優秀程序員與架構師區分點所在。
如何解決這種「不肯定性」呢？
-
合適原則：合適優於業界領先
將軍難打無兵之仗（人手不足，卻想產出多）
羅馬不是一天建成的（例如各大電商平臺的「雙11」搶購技術能力支持）
冰山下面纔是關鍵（沒有業務場景，卻幻想靈光一現）
-
簡單原則：簡單優於複雜
結構複雜性（組件多，關聯多，故障機率大，定位問題困難）
邏輯複雜性（集全部功能於一身）
《UNIX 編程藝術》KISS：Keep it Simple，Stupid!
-
演化原則：演化優於一步到位
就軟件而言，變化纔是主題
知足當前的業務須要
應用過程當中迭代，保留優秀，修復缺陷的設計，改正錯誤的設計
業務變化時，擴展、重構，甚至重寫
Part2：初衷
2.1 軟件系統的價值
軟件系統價值主要分爲行爲價值和架構價值。
-
業務價值（核心價值）
需求的實現，以及業務可用性保障（功能性 bug 、性能、穩定性）
-
架構價值
需求變動時，軟件變動成本低且可控
事實代表，隨着軟件複雜度的上升，工程師人數隨之增長，可是代碼量到達必定量以後漲幅呈現緩慢。可是代碼維護成本卻呈指數級上升，同時工程師的生產效率也會隨之下降，需求變動維護成本增大。
2.2 對程序員的簡單分類
-
普通程序員
-
工程師
-
架構師
編寫代碼的方式有不少，只要能讓程序跑起來，能正確地處理業務流程和對數據進行計算，就能夠說「會編寫代碼」。
程序員須要熟悉整個程序的邏輯及處理過程，須要熟悉程序語言的特性，還須要熟悉一些計算機操做系統的交互調用方式，才能寫出從用戶側交互，到數據和業務邏輯處理，再到與計算機系統交互的代碼，有效地把用戶信息、數據、業務和計算機串聯和拼裝出來。
還須要易讀、易擴展、易維護，甚至能夠直接重用。因而，這些人使用各類各樣的手段和技術不斷提升代碼的易讀性、可擴展性、可維護性和重用性。
2.3 咱們的初衷
談到咱們學習《架構整潔之道》系列課程內容的初衷，其實便是迴歸軟件系統的價值，利用多維的指導分析，幫咱們作出正確的架構決策和架構設計。
Part3：收益
3.1 架構分類
咱們須要針對當前業務需求，選擇合適的應用架構，關於如何支持當前業務發展，如何面向將來，保證架構平滑過渡。
主要架構分類：
-
業務架構
戰略層面，業務方向是什麼，要作什麼；
-
應用架構
戰術層面，承上啓下做用；
-
技術架構
裝備層面，負責業務的具體落地實施。
3.2 架構演進
架構的主要演進過程：
-
單體式架構
俗稱「煙囪式」架構
-
分佈式架構
按功能模塊，服務化拆分
-
SOA架構
-
微服務架構
其實不管哪一種架構方式，在當時環境下均可以解決現實問題的，都具備必定的意義的。
總結起來仍是那句話：存在便是合理的。
3.3 請求鏈路
除了系統架構自己，還須要關注每層技術架構的設計點。過程質量關乎總體質量，各環節的架構合理性相當重要。
3.4 編程之鑽
編程之鑽（The Programming Diamond）
上圖描繪了編程做爲一個完整工做流程（work process）的四項最基本活動
-
需求分析
-
設計實現
-
測試驗證
-
調試糾錯
咱們開發任何一個軟件功能、實現某個軟件需求，通常都須要經歷這 4 項基本的活動或狀態。把這四個狀態連起來剛好造成一個菱形，因此我把它叫做「編程之鑽」（The Programming Diamond）。
猶如一顆大鑽鑲嵌了四顆小鑽，把它們稱做編程的「鑽石」，也凸顯了這幾個基本任務及其相關技術與方法在軟件開發、軟件工程中的重要性。
Part4：總結
4.1 「悖論」？
一般咱們在解決具體問題時候，最多見的想法就是快速的完成本身的工做任務，這樣一來，是否是建設優質的軟件架構造成了悖論呢？
4.2 觀點
不管是微觀世界的代碼，仍是宏觀層面的架構，不管是編程範式仍是微服務架構，它們都在解決一個問題：分離控制和邏輯。
所謂控制就是對程序流轉的與業務邏輯無關的代碼或系統的控制（如多線程、異步、服務發現、部署、彈性伸縮等），所謂邏輯則是實實在在的業務邏輯，是解決用戶問題的邏輯。控制和邏輯構成了總體的軟件複雜度，有效地分離控制和邏輯會讓你的系統獲得最大的簡化。
其中 簡單vs.簡陋、平衡vs.妥協、迭代vs.半成品 就是咱們須要涉及到軟件架構中平衡的藝術。
4.3 學習建議
最後給你們一些學習上的建議：
-
1w小時學習定律
不斷的踩坑與填坑，會帶給你真正的成長
-
關鍵點
對技術的保持熱情
須要持續不斷的精力投入
堅持學習、實踐、思考、總結
-
指導原則
經驗的沉澱與積累
拓寬視野，不拘泥於現狀
鍛鍊深度思考能力，抓本質問題
你們好，我是「架構精進之路」公號做者 flyer0126，公號文章主要來自於我的平常工做問題總結思考，相信問題及解決方案均具備普適性，但願同你們一塊兒學習成長。
你們若有任何疑問/困惑，可關注公號回覆關鍵字 「wx」 添加我的微信，繼續勾搭~
「技術架構精進」專一架構研究，技術分享
Thanks for reading!
本文分享自微信公衆號 - 架構精進之路（jiagou_jingjin）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。