劉華：想入門軟件系統架構設計，看這篇就夠了

“ 分享軟件系統架構設計要解決什麼問題，好的設計是怎麼來的和一些非互聯網架構的設計樣例。”

我在《爲什麼每個軟件人都要懂點系統架構？》裏提到，每個軟件人都要懂點系統架構。這篇文章將明確告訴大家，即使是小白也可以學習做架構設計。我將分享架構設計要解決什麼問題，好的設計是怎麼來的和一些非互聯網架構的設計樣例。

—

要解決什麼問題

要回答這個問題，首先要明確架構設計是什麼。我就不抄網上的標準答案了。下面我通過4W1H來分享我的理解，更便於小白理解：

What：網絡、服務器、存儲、中間件、數據庫等硬件資源的搭配；
Why：系統在生產環境上能滿足非功能性需求，確保服務連續性，並確保在極端情況下能在規定時間內恢復業務；
Who：架構設計師、系統設計師和系統負責人共同配合；
When：收集到系統非功能需求後，獲取硬件資源之前；
How：

確定業務重要性；
收集非功能性需求；
架構設計；
設計評審；
獲取硬件資源。

下面我將具體展開How這個問題。

—

好的設計是怎麼來的？

確定業務重要性

由於不同系統所服務的業務的重要性是不一樣的，通常採用恢復時間目標（Recovery Time Objective，RTO）來確定，也就是該業務可以允許系統服務中斷最長的時間有多長。

對於業務和用戶來說，當然希望系統服務完全無中斷，但是要實現完全無中斷，所需要的架構成本會非常高，這個成本不光是首次採購服務器的建設成本，還有系統將來運行過程中，所有服務器的運行和維護成本。所以，架構設計不求“最好”，只求最合適。在每個項目立項時或系統開發前，業務都需要評估他們的RTO，然後架構設計師選擇與RTO匹配的設計。

比如，最重要的業務，不允許任何服務中斷的，其RTO就是0，在架構設計上必須採納同機房內服務器的“雙活”或“多活”，機房間的災備方案也應該是“雙活”或能實現自動的故障切換，機房間的數據是完全同步的，實現單臺服務器故障或機房間的切換對業務影響最低。當然，這套方案的成本最高。

如果業務的RTO是4個小時，也就是允許系統服務中斷時間最長的時間不超過4個小時，在架構設計上可以採納同機房內服務器的故障切換，機房間的災備方案可以是“雙活”或自動的故障切換。如果業務的RTO是8個小時，在架構設計上可以採納同機房內的故障切換，機房間的災備設計可以是手動的故障切換。

收集非功能性需求

這裏主要圍繞着系統所需要支撐的業務量、併發用戶數、系統響應要求，以及未來可預見的業務量和用戶數的增長，確定硬件配置方案。CPU配置可以參考SPEC值，也就是“跑分”。

如果是現有硬件因業務增長而升級，需要收集現有硬件各種運行指標，如CPU、內存、存儲等的使用情況，來確定當前負載，並以此爲基礎推算升級後的硬件指標。

架構設計

就是畫圖了。

業務與用戶都期望IT系統的服務是連續的，不會因故障而中斷服務。要滿足這一要求，在架構設計上，必須考慮避免單點故障導致整個系統的服務中斷，也就是雞蛋不能放在一個籃子裏的道理。可以想象，如果一個IT系統只部署在一臺服務器上，那麼只要這臺服務器出現故障，服務就會中斷。

應對這種情況，有兩種方案：

故障轉移（Failover）——把系統部署到兩臺服務器，其中一臺服務器是主服務器，所有用戶請求默認發到這臺服務器；另一臺服務器是備用服務器。一旦主服務器出現故障，所有用戶請求切換到備用服務器，繼續提供服務，爲修復主服務器故障爭取時間。
雙活或多活（onsite resilience）——把系統部署到兩臺服務器，並把用戶的請求均衡地分配給這兩臺服務器分別處理，那麼不光系統的處理能力提升了，而且即使其中一臺服務器出現故障，另一臺服務器依然可以支撐服務，處理用戶請求，這種設計叫“雙活”。如果是通過多臺服務器來實現這種設計，就叫“多活”。

這兩套方案均可避免單點故障，但成本是不一樣的。在故障轉移方案中，備用服務器是應急用的，其配置可以低於主服務器，而在“雙活”和“多活”的方案中，所有服務器的配置應該一致，所以從成本上看，故障轉移 < 雙活 < 多活。同等服務器配置的情況下，從業務處理能力上看，多活 > 雙活 > 故障轉移。所以，採取何種方案，需要結合業務的關鍵程度、性能要求、成本等綜合考慮。

以上是從服務器的角度來考慮的。放置服務器的機房也會出現故障，比如當地震、海嘯、水災、火災、斷電、雷擊等災難發生時，可能會出現整個機房無法工作的情況，從而導致企業的所有IT系統無法提供服務。要避免這種情況，很多企業都會建設災備機房，這也是監管機構對某些行業的硬性要求。

對於災備機房，一般要求“同城異地”，也就是主機房和災備機房在同一城市的不同地點，需要有一定的物理距離。更高的要求有“兩地三中心”，也就是在“同城異地”的基礎上，還需要在另外一座城市配置一個機房。

在架構設計上，也要考慮從主機房切換到災備機房的方案。前面提到故障切換、“雙活”和“多活”的思路同樣可以運用到機房的災備設計上。主機房與災備機房之間的數據也需要同步，確保切換後，業務可以延續。

架構設計師需要充分了解各種硬件資源的配置、適應場景和處理能力（如果公司是自建機房，強烈建議對各種種類的硬件資源進行標準化。比如Linux服務器，有統一的品牌、型號和OS版本，有多個配置選項，從而提供同構的資源，簡化管理，統一架構設計師的知識庫，減輕架構設計師的認知負擔，降低採購成本，降低機房的繁雜性。雲服務商也是走這個策略的。）。

架構設計過程中，設計者需要和系統設計師、系統負責人充分了解系統設計、功能、特性和上下游系統關係。整個過程中，要保持溝通，小步推進，確保做出來的設計是得到一致認可的。

架構設計的輸出包括架構設計圖以及詳細的硬件資源清單，資源清單包含網絡、服務器、存儲、中間件、數據庫等的具體類型和配置。將來將按照這份清單來獲取硬件資源。

後面會有一些非互聯網架構的一些設計示例展開講述。

設計評審

設計初稿最好得到資深架構設計師的審閱。

獲取硬件資源

根據審批的架構設計及硬件資源清單，獲取相應硬件資源，從而可以開始進行系統安裝和部署。

—

一些樣例

以下是一些具體的架構設計樣例，供參考。

前面提到，生產環境必須要考慮災備，因此幾乎所有生產環境的架構設計圖紙都是以下這樣的“雙肺”形式。

幾乎所有在生產環境的資源都要在災備環境配置一套，以便生產環境的硬件資源或機房出現故障時，可以快速切換到災備環境。

這張圖是一個典型的MVC模型架構。在圖中，應用服務器和數據庫服務器在生產環境和災備環境均只有一套，因此一旦生產環境中的硬件資源出現不能短期恢復的故障時，只能通過切換到災備環境來“續命”。由於切換到災備環境需要一些時間，因此這張圖其實RTO將是數個小時（具體多少小時將取決於每家公司機房針對各硬件資源切換的承諾時效），也就是最多可允許停機數小時的方案，適合業務重要性不太高的系統。

爲了滿足快速切換，在設計中考慮到了以下因素：

生產環境和災備環境間應用服務器通過NAS（Network Attached Storage：網絡附屬存儲，簡單理解就是一種共享存儲）保存文件，這樣兩套服務器間的文件是共享的，切換後也能訪問到切換前的所有文件。
生產環境和災備環境間應用服務器通過網關配置了主/備切換，一旦生產環境的服務器（主機）不響應，請求會自動切換到災備環境的服務器（備機），無需人工干預。
NAS在生產環境和災備環境也備了兩套，並進行了同步。一旦生產環境的NAS壞了，兩臺應用服務器可以掛到災備NAS，並訪問到已同步的文件。
這個例子的數據庫採用的是Oracle。生產環境和災備環境間數據庫通過Oracle Data Guard進行數據同步，確保切換後系統可以獲取同樣的數據。
數據庫建議存儲在像NAS或SAN（存儲區域網絡Storage Area Network）的共享存儲中（請自行補習NAS和SAN的區別，NAS比SAN便宜），保障性更高。

測試環境由於只需要備份，不需要考慮災備，通常是“單肺”的形式：