什麼是架構屬性
本文探討如下幾個問題：
- 什麼是架構屬性
- 約束和架構屬性的關係
- 有哪些架構屬性
- 各個架構屬性涉及知識點
什麼是架構屬性
首先，問個很簡單的問題！請看下面的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就是架構所具有的功能！
架構屬性一般又稱為質量屬性 ！
這些架構屬性和架構功能是從哪來的呢？
在ofollow,noindex" target="_blank">什麼是軟體架構 中提到過約束 包含：功能性約束（這個系統要完成的功能）、非功能性約束（可用性、擴充套件性、容錯性等）、其它約束（人員技能、法律法規、公司規定等）
實際上，架構屬性和架構功能是從約束 而來:
- 對「功能性約束」的決策結果就是架構功能
- 對「非功能性約束」的決策結果就是架構屬性
- 而對「其它約束」的決策可能會同時影響到架構功能 和架構屬性
給架構屬性和架構功能下個定義：
- 架構屬性 是對「非功能約束」決策後，架構所具有的特徵，且受到一些其它約束的影響
- 架構功能 是對「功能約束」決策後，架構所具有的功能，且受到一些其它約束的影響
以線上教育系統為例，來說明一下：
- 這個系統需要具有線上直播的功能，完成這個功能約束後，系統即有了線上直播這個架構功能
- 這個系統需要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%E6%B3%A8%E5%85%A5/">SQL注入，指令碼注入，DDos等），https，鑑權，授權，單點登入，加解密等
容錯性
做系統時，我們都聽說過，要把使用者當傻瓜，要把操作做得儘量簡單。而實際上，我們也要把使用者當做破壞分子，他們不小的概率不會按照正常情況來操作你的系統。
比如：電話號碼裡面寫了字元啦，添加了各種表情啦，狂點提交按鈕啦，狂重新整理啦等等等等。你的系統需要應對這些。
容錯性就是：「系統對非正常情況（輸入、輸出、操作，異常資料等）的寬容程度」。
你不能動不動就給個500錯誤，需要對可能的情況做容錯處理。比如：前後端的資料檢查，友好的錯誤提示。
容錯性涉及知識點：如何進行異常處理？非正常輸入輸出處理。網路波動，請求超時，服務掛掉，硬體問題，使用者體驗等
災難恢復
災難恢復和容錯性比較類似，只是程度上的區別。使用者輸入錯誤這樣的問題，可能只是導致這個使用者的流程無法走下去。而「災難」會影響一部分甚至所有使用者都無法使用系統，從而導致可用性問題。
比如：伺服器宕機、機房斷電、硬碟損壞、甚至地震了。你如何保證你的系統在上述情況下還能正常對外提供服務？
災難恢復涉及的知識點：線路的快速切換，負載均衡演算法，硬體損壞的恢復，跨DC備份等
可訪問性
類似讓視覺障礙之類的殘疾人也能使用你的軟體，這個好像目前考慮得不是太多，暫不討論。主要還是使用者體驗方面，只是面向的群體不同，優化的點也就不同。
監測（可運維）
上面說可用性，4個9時基本就要保障機器全年都要可用，為了達到這個目標，就要對系統進行監控，以期在早期發現問題，在影響系統可用性前，就將其解決。這就是監測。主要包括完善的監控檢視，異常資料的提醒，日誌的記錄等
監測涉及知識點：日誌記錄，日誌統計，請求跟蹤，機器負載監控，請求監控等，偏運維。
管理
如果你做過線上系統，應該會遇到過需要不停機調整系統某些引數的情況。例如：調整日誌的輸出級別，刪除某些資料，重新整理快取。
管理指：「執行時修改系統配置、重新整理快取等能力」。這裡需要注意的是，要避免對線上系統的影響，比如：全量重新整理了快取，導致系統雪崩了。
管理涉及知識點：需要權衡哪些配置需要線上進行調整。
靈活性
系統上線後，可能主要是運營人員對系統進行操作，一般運營人員不懂技術，如何提供方便的功能，能夠讓運營人員方便的使用系統。例如：使用者下錯單了，運營人員需要取消訂單；敏感詞稽核了；遮蔽某些使用者了；調整工作流流程了等等等等
靈活性指：「非技術人員修改軟體內部使用的業務規則的能力」。
靈活性涉及知識點：確定哪些功能需要後臺管理功能，及相關功能的設計。比如是否需要完善的許可權體系，及運營人員如何管理許可權體系。
可擴充套件性
系統開發是個持續的過程，對內專案一般會分期，一期二期三期；網際網路專案會不斷的根據使用者反饋進行迭代。如何方便的進行迭代就是架構的可擴充套件性。
擴充套件性指：「擴充套件軟體使其可以做現在還不能做的事的能力。即新增新功能的難易程度。」
擴充套件性涉及知識點：主要是設計方面的考量。面向物件設計、元件設計，高內聚，低耦合等。一些架構風格，例如外掛風格，過濾器風格等對擴充套件性比較友好。其實大部分架構都支援可擴充套件性，只是支援的程度不同而已
可維護性
開發為什麼要使用框架？為什麼要走變更流程？為什麼有各種開發流程？為什麼釋出程式碼還要提交運維申請？是為了管理專案，提高開發進度，能夠跟進專案計劃，確定是否出現偏差，及時進行調整。這些都是可維護性的範疇。
可維護性指：「系統是否能快速的開發、測試、釋出？」
可維護性這個屬性偏流程管理，包括編碼規範，開發流程，測試流程，釋出流程等
國際化
支援多國語言的能力。比如：很多網站分為中文站，國際站。這就需要考量，是使用相同的資料進行翻譯，還是部署不同的系統等。
本地化
以符合終端使用者文化習俗的方式展示數字、貨幣、日期等
其它影響因素
- 法律法規：某些行業會受到法律或監管機構的管理，需要符合法律法規。例如金融行業
- 成本：成本不夠，可能就會先降低甚至忽略某些架構屬性的要求
- 人員水平：人員水平也可能會降低或提高某些架構屬性
舉個例子
這些架構屬性，就是在做系統架構時需要考慮的點。依然以線上教育系統為例：
- 這個系統需要支援多少學員同時線上學習？能容忍多長時間的系統響應？這是「效能」
- 系統需要連續多長時間不出問題？3個9?4個9？還是5個9？這是「可用性」
- 如果系統出現了問題，該如何處理？如何響應？這是「系統容錯」
- 如果學員增多了，能否能方便的多部署系統來支援？反之，如果學員減少了，能否減少系統部署來節約成本？這是「伸縮性」
- 如果要新增直播的功能，能否方便的新增？且基本不影響現有功能？這是「擴充套件性」
- 系統能否防禦惡意攻擊？是否能保證使用者的資訊保安？這是「安全性」
- 如何能以最小的花費來完成系統？這是「成本」考量
- 目前的團隊技術水平如何？這是「人員」考量
- 系統出現問題或異常情況，是否能快速的通知相關人員？這需要完善的監控系統，這是「可運維性」
- 系統如何能快速的開發、測試、釋出？這是「可維護性」
- 有哪些法律法規需要遵守？是否需要申請直播功能
- 有國外使用者嗎？需要國際化嗎？
總結
本文梳理了什麼是架構屬性；有哪些架構屬性及相關知識點！後續對各個屬性進行詳細討論。
每個約束之間並不是正交的，可能滿足的某個約束，卻違背了另外一個或多個約束，這就需要架構師來進行取捨。就像CAP原則一樣，一個分散式系統不可能同時滿足可用性、一致性和分割槽容錯性。一個架構也不可能同時滿足所有的約束。