軟體架構（software architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。

一、定義

        軟體架構是一個系統的草圖。軟體架構描述的物件是直接構成系統的抽象元件。各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。在實現階段，這些抽象元件被細化為實際的元件，比如具體某個類或者物件。在面向物件領域中，元件之間的連線通常用介面來實現。

        軟體體系結構是構建計算機軟體實踐的基礎。舉個栗子，栗子是用來看的不是用來吃的哈，吃貨觀眾們，口水收收，先學習。

        沒蓋過房子，我想，大家都看過蓋房子吧，特別是樓房。首先，選一片地方，然後打地基，搭建樓房的架子，再慢慢刷牆，貼瓷磚等等。這個過程跟軟體架構師是一樣的，先做出一個軟體的框架來，然後不斷完善軟體程式碼。

二、目標

        架構設計要達到的目標是什麼呢？一般而言，軟體架構設計要達到如下的目標：

        可靠性（Reliable）。軟體系統對於使用者的商業經營和管理來說極為重要，因此軟體系統必須非常可靠。

        安全性（Secure）。軟體系統所承擔的交易的商業價值極高，系統的安全性非常重要。

        可伸縮性（SCAlable）。軟體必須能夠在使用者的使用率、使用者的數目增加很快的情況下，保持合理的效能。只有這樣，才能適應使用者的市場擴充套件得可能性。

        可定製化（CuSTomizable）。同樣的一套軟體，可以根據客戶群的不同和市場需求的變化進行調整。

        可擴充套件性（Extensible）。在新技術出現的時候，一個軟體系統應當允許匯入新技術，從而對現有系統進行功能和效能的擴充套件。

        可維護性（MAIntainable）。軟體系統的維護包括兩方面，一是排除現有的錯誤，二是將新的軟體需求反映到現有系統中去。一個易於維護的系統可以有效地降低技術支援的花費。

        客戶體驗（Customer Experience）。軟體系統必須易於使用。

        市場時機（Time to Market）。軟體使用者要面臨同業競爭，軟體提供商也要面臨同業競爭。以最快的速度爭奪市場先機非常重要。

        這塊概念我想大家應該都比較瞭解，就不多詳細說明啦。

三、常見架構分類

1. 分層模式（三層架構）

        這種模式也稱為三層架構模式。它可以用來構造可以分解為子任務組的程式，每個子任務都處於一個特定的抽象級別。每個層都為下一個提供更高層次服務。一般資訊系統中最常見的是如下所列的3層。

        表示層(也稱為UI層)

        業務邏輯層(也稱為領域層)

        資料訪問層(也稱為持久化層)

2.客戶端-伺服器模式

        這種模式由兩部分組成：一個伺服器和多個客戶端。伺服器元件將為多個客戶端元件提供服務。客戶端從伺服器請求服務，伺服器為這些客戶端提供相關服務。此外，伺服器持續偵聽客戶機請求。

        這種就比較常見了，或者說很常見，就在我們身邊，我們用的QQ，手機淘寶，支付寶，優酷客戶端等等，都是這類模式的典型代表。

        這種模式有一個很洋氣的名字，我們稱之為C/S架構。

3.瀏覽器-伺服器架構

        這種架構也稱為B/S架構，它是隨著Internet技術的興起，對C/S架構的一種變化或者改進的結構。在這種結構下，使用者工作介面是通過WWW瀏覽器來實現，極少部分事務邏輯在前端(Browser)實現，但是主要事務邏輯在伺服器端(Server)實現，形成所謂三層3-tier結構。B/S架構是WEB興起後的一種網路結構模式，WEB瀏覽器是客戶端最主要的應用軟體。這種模式統一了客戶端，將系統功能實現的核心部分集中到伺服器上，簡化了系統的開發、維護和使用。

        我們每次上網逛得那些不為人知的小頁面啊，廣為人知的小頁面啊，大多數都是這種架構的。

4.微服務架構

        微服務架構是一項在雲中部署應用和服務的新技術。大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。

        微服務可以在“自己的程式”中執行，並通過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立程序所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小程序範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體程序。

        說的這個概念有些深奧了，從我個人理解來看，你可以想象一下積木，每一個積木塊都是一個獨立的個體，雖然有時候每個積木必不可少，但是如果一個積木丟失或者損壞，只需要立馬補上這一個積木塊就可以了，不需要將整體積木全部更換或者維修。微服務就是如此，它將一個大型的專案分解成不同的小塊，通過相互之間的介面呼叫或者繼承來實現相關的聯絡，從而實現整體功能，但是有一個功能模組更新，或者出現問題，只需要修改這個模組即可，很少會影響到整體。

5.響應式架構

        關於響應式架構，我不想找網上的定義了，只是想在這裡，跟大家一起分享我自己的理解和看法，也希望對架構有了解，有興趣的同學一起討論，一起交流。

        從名字來看，響應式架構是什麼呢？就是我叫了某一個人的名字，他迴應了我，他的這個行為就是對我的行為的響應。包括JAVA裡面有事件監聽，就是程式對你觸發滑鼠或者鍵盤事件的一個響應。

        響應有什麼好處呢？我叫了你，你可以不用迴應我，我去做別的事，我叫你只是我完成了我的事件，你隨時都可以響應我，只不過我著急的時候，我會催你，再給你發第二個事件，等你響應。這個期間，我可以先去做別的事情。如果沒有相應式，我會一直等你，等到我死（系統崩潰）當然，異常處理能夠解決大部分的問題，如果觸發異常，計算機會自動採取一些行動來退出，防止系統崩潰。但是，程式設計師不能保證在所有的可能出錯的地方都設定異常處理，他們應該把更多的精力放在如何讓程式更加完善上。魯棒性只是其中一部分，所以響應式應運而生。所有的介面呼叫，資訊傳遞等都採取響應式。可能會在一定程度上減緩程式的效率，但是可以大大的增加系統的魯棒性。

        在響應式方面，做的最好的應該是基於Scala語言的akka框架，當時瞭解到這個架構的時候，小編還從網上找資料學過一些Scala。Scala和Java比較相似，但是我認為Scala還是更強大一些，是因為Scala支援函數語言程式設計。如果不是對C++有深沉的愛，對數學有深沉的愛，我想，我已經踏上Scala之路了。

        扯得有些遠啦，讓我們再扯回來，在akka框架中還應用到了分析模式，話說，我看了5個月的分析模式，也沒有弄懂相關的概念，還是太年輕啊。在這方面有一本書不錯，推薦給大家：《響應式架構：訊息模式Actor實現與Scala,Akka應用整合》這本書將帶領你通過Actor模型使用響應式訊息傳輸模式，編寫出具有高效能、高響應性、高可伸縮性和高韌性的併發應用程式。當然，如果你還是一個程式設計小白，我的建議是你可以簡單看看這本書，對書中的概念有個印象，然後多做專案，多做專案，多做專案。架構思想，程式設計思想，不是你看書看幾次就能學會的，是通過積年累月的專案經驗和自己的不斷總結得出來的。