這是【一文一點】的第5篇文章，不拘泥于篇幅字數，用一篇文章說清一個知識點。
1、
當談到軟體架構的時候你不能隻想到spirng、springmvc、mysql，你也真不應該想到它們，雖然它們是你落地的載體。
至少你不能先想到它們，軟體架構不依賴這些架構或者具體的資料庫，這些東西統統需要延後，延後。
正像《架構整潔之道》序言中餘晟老師講到的，架構設計是一門複雜的學問，要綜合考慮編碼、品質、部署、運維、排障、更新等各種因素，并作出權衡。
是以，架構設計就不是指首先想到的那些架構，那麼的簡單了。
軟體架構應該要獨立于架構、獨立于UI、獨立于資料庫、獨立于任何外部庫。
2、
如果是想要描述架構的話，可以用4+1視圖，這裡的4是指邏輯視圖、實作視圖、程序視圖、部署視圖，這裡的1是指場景。
圖來自網絡
剛才我們也提到了軟體架構設計是一件比較複雜的事情，包含了很多種因素，同時呢，它不僅要滿足使用者的功能需求，某個場景的使用者需求流程是怎樣的，對應到設計中應該是什麼樣的模式和設計流程。
還要滿足系統的可靠性、可用性、安全性、性能、容量等架構的品質屬性，這往往會涉及到基礎平台、架構應用、甚至還有硬體。
這就需要多方合作才能最終落地實作架構的設計目标，這中間會有軟體研發人員、測試人員、運維人員、産品人員、業務營運人員的參與，也就是說我們設計的軟體架構包含了他們所有人員的參與。
有這麼多角色參與的工程，如果有一個架構或模式能夠把它們串起來，是再好不過的了，而4+1視圖就可以起到這樣的作用。
4+1視圖可以讓架構師自頂向下的去分解架構設計，還可以形成合理的抽象，進而将我們剛才說的這麼多角色”拉在一起“。
因為要使得架構落地必須有他們的參與和協同工作。
3、
另外，在做架構設計的時候，我們也不能僅僅高談闊論，總聊"高大上"的理論，雖然那些理論可能是有用的。
一個被架構設計指導的軟體項目總歸是要通過一行行的代碼實作的，"脫離了一行行的代碼，脫離了具體的細節設計，架構設計就無從談起"。
以至于在《架構整潔之道》一書中，提到，軟體品質，不但依賴于架構及項目管理，而且與代碼品質緊密相關，甚至還有說到，“對于代碼，應無情地做重構”。
是以你在架構設計的時候還要引入一些模式或者原則性的編碼指導，比如SOLID原則。
除此之外，我們還要考慮架構的可擴充性，畢竟一個落地的架構，不僅要滿足使用者、系統的一時的需求，還要滿足後面他們持續的需求。
如果你要設計一個彈性、"皮實"的架構，至少你要考慮這三方面的事情，避免過度設計，向内依賴設計、面向失敗設計。
說了以上這麼多，到底什麼是軟體架構設計呢，正像《架構整潔之道》這本書描述的。
所謂軟體架構，就是你希望項目在一開始就能做對，但是卻不一定能夠做的對的決策的集合。
為什麼這麼說呢，架構設計，架構設計，雖然有【設計】倆字，但架構真不是"設計"出來的，而是演進出來的。
4、
優秀的軟體架構也不是一成不變的，需要經過不斷的打磨，疊代改進。
在《演進式架構》這本書裡面，在如何建構可演進式的架構方面給了我們指導性建議，從三方面考慮：适應度函數、增量變化、适當耦合。
我們首先來看什麼是适應度函數。
按照這本書中介紹的，适應度函數是進化計算中的一個概念，進化計算有多種機制，通過對每一代軟體進行小的變更使方案逐漸成形。
另外書中也給了一個明确的定義：架構的适應度函數為某些【架構特征】提供了客觀的完整性評估。
那什麼是架構特征呢。
系統被提的要求可能不太相同，比如有的系統要求高吞吐量和低延遲，有的系統要求安全性要高，有的系統要求自我故障恢複的能力要強，這些呢，都是架構的特征。
舉一個比較容易了解的适應度函數的例子，就是功能測試，一個測試用例可以看成是某一個單一功能的适應度函數，增量開發應該在測試成功的限制下進行變更。
而适應度函數這個概念，則就很好的展現了這些架構特征的保護，有關适應度函數更多的了解大家可以去詳細閱讀這本書。
再來看增量變化。
架構應該支援增量開發和增量部署。
增量開發也就是，我編寫了一個功能的代碼，可以立馬送出，并可以被進行功能測試，性能測試。
增量部署的意思可以了解為AB釋出，比如書中舉了github的例子，每次功能重構上線，github都先随機挑選1%的使用者進行舊功能與新功能同步執行，持續4天輸出結果相同時，将用新代碼替換掉舊代碼。
這是一個非常值得借鑒的思路。
最後，來看适當耦合。
我們反對強耦合，但世界上卻沒有不耦合的系統，你試想，如果你的系統之間沒有一點耦合，企業系統還怎麼對外統一提供服務呢。
是以，我們才一直強調的是弱耦合，過渡耦合使得架構難以演進，但我們要保持适當耦合。
關于适應度函數、增量變化、适當耦合的内容，同時也參考了 知乎上面的這篇文章https://zhuanlan.zhihu.com/p/133517172
5、
軟體設計如果又從宏觀視角來看的話，包括需求、研發、運維，那麼其中維護的成本又是最高的。
另外呢，還有一條真理性的警句：世上沒有不出問題的系統。
那麼緻力于高可用上的成本也是不小的隐性成本，甚至有的公司專門對此有對稱職位，比如google就有SRE工程師，全稱是 Site Reliability Engineer 網站可靠性工程師。
好了，我又寫完一個知識點，希望對你有一點幫助。