本文探討如下幾個問題：
- 什么是架構屬性
- 約束和架構屬性的關系
- 有哪些架構屬性
- 各個架構屬性涉及知識點
什么是架構屬性
首先，問個很簡單的問題！請看下面的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原則一樣，一個分布式系統不可能同時滿足可用性、一致性和分區容錯性。一個架構也不可能同時滿足所有的約束。