本文探討如下幾個問題：

• 什麼是架構屬性
• 約束和架構屬性的關係
• 有哪些架構屬性
• 各個架構屬性涉及知識點

什麼是架構屬性

首先，問個很簡單的問題！請看下麵的Java代碼：

class Person {
    private String name;
    private int age;

    public void skill() {
        ......
    }
}

請問上面的代碼中:

• name和age被稱為Person這個類的什麼？
• skill又稱為Person這個類的什麼呢？

name和age一般被稱為欄位、成員變數或屬性；skill一般被稱為方法，表示Person所具有的功能！

我們稍微修改下代碼：

class Architecture {
    private String safe;
    private String performance;

    public void func() {
        ......
    }
}

safe(安全性)和performance(性能)就是Architecture(架構)的屬性！func就是架構所具有的功能！

架構屬性一般又稱為質量屬性！

這些架構屬性和架構功能是從哪來的呢？

在什麼是軟體架構中提到過約束包含：功能性約束（這個系統要完成的功能）、非功能性約束（可用性、擴展性、容錯性等）、其它約束（人員技能、法律法規、公司規定等）

實際上，架構屬性和架構功能是從約束而來:

• 對「功能性約束」的決策結果就是架構功能
• 對「非功能性約束」的決策結果就是架構屬性
• 而對「其它約束」的決策可能會同時影響到架構功能和架構屬性

給架構屬性和架構功能下個定義：

• 架構屬性是對「非功能約束」決策後，架構所具有的特征，且受到一些其它約束的影響
• 架構功能是對「功能約束」決策後，架構所具有的功能，且受到一些其它約束的影響

以線上教育系統為例，來說明一下：

• 這個系統需要具有線上直播的功能，完成這個功能約束後，系統即有了線上直播這個架構功能
• 這個系統需要4個9的可用性，如果這個系統達到了這個非功能性約束，系統即有了高可用的架構屬性
• 法律法規規定，現在直播需要有《信息網路傳播視聽節目許可證》或《廣播電視節目製作經營許可證》，如果你沒有，那麼你的系統就沒法進行直播也就沒有了直播這個功能；而如果人員技能不達標或者某些突發情況，那可能導致系統就不具備高可用這個屬性，號稱「能同時支持8位明星同時出軌的微博」，不是又掛了嗎？

架構屬性

架構屬性一般包括如下方面：性能，伸縮性，可用性，安全性，容錯性，災難恢復，可訪問性，可運維，管理，靈活性，可擴展性，可維護性，國際化，本地化。還有法律法規，成本，人員等對上面架構屬性的影響。下麵分別討論（由於涉及的內容很多，這裡只是一個概要，詳細內容後續慢慢討論）。

性能

我們經常掛在嘴邊的優化，絕大部分情況下指的是「性能優化」。「性能優化」的目的就是提高系統響應速度。而優化的原因就是系統響應速度不夠快。

一般認為，一個網頁打開速度超過3s，用戶就開始沒有耐心了；如果超過5s，用戶就要打算放棄訪問了；而如果超過10s以上用戶還沒關閉，這個網站不是12306就是查分網站。

上面指的「響應速度」主要分為系統性能和用戶感知性能。這兩者的區別是：

• 系統性能指系統自身的響應，即調用一個介面，此介面多久能返回。
• 而用戶感知性能，是用戶操作後到操作反饋的時間。

舉個簡單的例子，假設一個頁面完整載入完要3s，如果用戶一點擊就白頁，3秒後再顯示出來，那麼用戶感知性能就是3秒；而如果一點擊1秒之內就載入了第一屏或者立即就有一個載入反饋，那麼用戶感知性能就在1s以內。雖然系統性能實際是一樣的，但是用戶的感知性能卻不同。

性能方面的知識點主要涉及各種優化：前端優化，網路優化，代碼優化，資料庫優化，JVM優化等等等等，提高TPS，QPS等系統性能和用戶感知性能（用戶體驗）

伸縮性

如果你玩游戲的話，你肯定知道「開服」和「合服」吧？其實這就是伸縮性！

簡單來說，伸縮性就是：「你的系統能否能通過簡單的增加部署，來應對更多的訪問量」！
例如：原來你的系統只有一臺伺服器，現在一臺伺服器撐不住了，你能否不修改任何代碼，只增加一臺一樣的伺服器就可以支撐更多的人來訪問？

相對的，反過來，如果你的用戶量減少了，兩台伺服器浪費了，你能否直接關閉一臺服務集，來節約成本？

伸縮性涉及的知識點主要涉及分散式相關內容：應用集群，負載均衡，負載均衡演算法，分散式事務，分庫分表，拆分應用，服務化，SOA，微服務等

可用性

可用性可能是最基本的架構屬性了。你經常聽到的3個9,4個9,5個9就是指可用性的。
可用性指的是：「系統能夠連續多長時間正常運行？」

• 3個9就表示系統全年可用時間占全年時間的99.9%，即不可用時間是365*24*60*60*0.1%=31536秒，大概8個多小時，好像時間還挺長的
• 4個9就表示系統全年可用時間占全年時間的99.99%，即不可用時間是365*24*60*60*0.01%=3154秒，大概50多分鐘。基本上最多只能出一次故障
• 5個9就表示系統全年可用時間占全年時間的99.999%，即不可用時間是365*24*60*60*0.001%=315秒，大概5多分鐘。基本上等於系統全年都要保證可用。一般情況下，系統故障了5分鐘還不一定能定位到問題，更不要說解決問題了。

可用性和伸縮性涉及知識點有些重合，因為保障可用性的方法就是「冗餘」，實際就是集群和分散式：集群，多數據中心，主備切換，心跳，註冊中心，負載均衡，負載均衡演算法（輪詢、隨機、hash），容錯（見容錯處理）等

安全性

最近Facebook出現了系統漏洞，5000多萬的用戶數據被泄露了。之前的攜程也是，不少的知名系統都出現過安全問題。

安全性就是：「保障用戶在使用系統的過程中，信息不會被泄露，導致個人財產受到損失，個人安全受到威脅等」

安全性相關知識點包括：各種攻擊防範（CSRF，SQL註入，腳本註入，DDos等），https，鑒權，授權，單點登錄，加解密等

容錯性

做系統時，我們都聽說過，要把用戶當傻瓜，要把操作做得儘量簡單。而實際上，我們也要把用戶當做破壞分子，他們不小的概率不會按照正常情況來操作你的系統。

比如：電話號碼裡面寫了字元啦，添加了各種表情啦，狂點提交按鈕啦，狂刷新啦等等等等。你的系統需要應對這些。

容錯性就是：「系統對非正常情況（輸入、輸出、操作，異常數據等）的寬容程度」。

你不能動不動就給個500錯誤，需要對可能的情況做容錯處理。比如：前後端的數據檢查，友好的錯誤提示。

容錯性涉及知識點：如何進行異常處理？非正常輸入輸出處理。網路波動，請求超時，服務掛掉，硬體問題，用戶體驗等

災難恢復

災難恢復和容錯性比較類似，只是程度上的區別。用戶輸入錯誤這樣的問題，可能只是導致這個用戶的流程無法走下去。而「災難」會影響一部分甚至所有用戶都無法使用系統，從而導致可用性問題。

比如：伺服器宕機、機房斷電、硬碟損壞、甚至地震了。你如何保證你的系統在上述情況下還能正常對外提供服務？

災難恢復涉及的知識點：線路的快速切換，負載均衡演算法，硬體損壞的恢復，跨DC備份等

可訪問性

類似讓視覺障礙之類的殘疾人也能使用你的軟體，這個好像目前考慮得不是太多，暫不討論。主要還是用戶體驗方面，只是面向的群體不同，優化的點也就不同。

監測（可運維）

上面說可用性，4個9時基本就要保障機器全年都要可用，為了達到這個目標，就要對系統進行監控，以期在早期發現問題，在影響系統可用性前，就將其解決。這就是監測。主要包括完善的監控視圖，異常數據的提醒，日誌的記錄等

監測涉及知識點：日誌記錄，日誌統計，請求跟蹤，機器負載監控，請求監控等，偏運維。

管理

如果你做過線上系統，應該會遇到過需要不停機調整系統某些參數的情況。例如：調整日誌的輸出級別，刪除某些數據，刷新緩存。

管理指：「運行時修改系統配置、刷新緩存等能力」。這裡需要註意的是，要避免對線上系統的影響，比如：全量刷新了緩存，導致系統雪崩了。

管理涉及知識點：需要權衡哪些配置需要線上進行調整。

靈活性

系統上線後，可能主要是運營人員對系統進行操作，一般運營人員不懂技術，如何提供方便的功能，能夠讓運營人員方便的使用系統。例如：用戶下錯單了，運營人員需要取消訂單；敏感詞審核了；屏蔽某些用戶了；調整工作流流程了等等等等

靈活性指：「非技術人員修改軟體內部使用的業務規則的能力」。

靈活性涉及知識點：確定哪些功能需要後臺管理功能，及相關功能的設計。比如是否需要完善的許可權體系，及運營人員如何管理許可權體系。

可擴展性

系統開發是個持續的過程，對內項目一般會分期，一期二期三期；互聯網項目會不斷的根據用戶反饋進行迭代。如何方便的進行迭代就是架構的可擴展性。

擴展性指：「擴展軟體使其可以做現在還不能做的事的能力。即添加新功能的難易程度。」

擴展性涉及知識點：主要是設計方面的考量。面向對象設計、組件設計，高內聚，低耦合等。一些架構風格，例如插件風格，過濾器風格等對擴展性比較友好。其實大部分架構都支持可擴展性，只是支持的程度不同而已

可維護性

開發為什麼要使用框架？為什麼要走變更流程？為什麼有各種開發流程？為什麼發佈代碼還要提交運維申請？是為了管理項目，提高開發進度，能夠跟進項目計劃，確定是否出現偏差，及時進行調整。這些都是可維護性的範疇。

可維護性指：「系統是否能快速的開發、測試、發佈？」

可維護性這個屬性偏流程管理，包括編碼規範，開發流程，測試流程，發佈流程等

國際化

支持多國語言的能力。比如：很多網站分為中文站，國際站。這就需要考量，是使用相同的數據進行翻譯，還是部署不同的系統等。

本地化

以符合最終用戶文化習俗的方式展示數字、貨幣、日期等

其它影響因素

• 法律法規：某些行業會受到法律或監管機構的管理，需要符合法律法規。例如金融行業
• 成本：成本不夠，可能就會先降低甚至忽略某些架構屬性的要求
• 人員水平：人員水平也可能會降低或提高某些架構屬性

舉個例子

這些架構屬性，就是在做系統架構時需要考慮的點。依然以線上教育系統為例：

• 這個系統需要支持多少學員同時線上學習？能容忍多長時間的系統響應？這是「性能」
• 系統需要連續多長時間不出問題？3個9?4個9？還是5個9？這是「可用性」
• 如果系統出現了問題，該如何處理？如何響應？這是「系統容錯」
• 如果學員增多了，能否能方便的多部署系統來支持？反之，如果學員減少了，能否減少系統部署來節約成本？這是「伸縮性」
• 如果要新增直播的功能，能否方便的添加？且基本不影響現有功能？這是「擴展性」
• 系統能否防禦惡意攻擊？是否能保證用戶的信息安全？這是「安全性」
• 如何能以最小的花費來完成系統？這是「成本」考量
• 目前的團隊技術水平如何？這是「人員」考量
• 系統出現問題或異常情況，是否能快速的通知相關人員？這需要完善的監控系統，這是「可運維性」
• 系統如何能快速的開發、測試、發佈？這是「可維護性」
• 有哪些法律法規需要遵守？是否需要申請直播功能
• 有國外用戶嗎？需要國際化嗎？

總結

本文梳理了什麼是架構屬性；有哪些架構屬性及相關知識點！後續對各個屬性進行詳細討論。

每個約束之間並不是正交的，可能滿足的某個約束，卻違背了另外一個或多個約束，這就需要架構師來進行取捨。就像CAP原則一樣，一個分散式系統不可能同時滿足可用性、一致性和分區容錯性。一個架構也不可能同時滿足所有的約束。

參考資料

• 《Architectural Styles and the Design of Network-based Software Architectures》Roy Thomas Fielding
• Wiki