目錄
文章目錄
架構指標
性能
性能是指響應能力：響應特定事件所需的時間，或給定時間間隔內處理的事件數。性能具備如下指標：編程
- 延遲 ：表示得到響應以前通過的時間間隔。
- 吞吐量：是指在固定時間間隔內得到的響應數。
- 可用容量：以上度量的結合體。
- 可調度的利用率：利用率是資源繁忙時間的百分比，而可調度的利用率是知足必定時間要求的最大利用率。
- 數據丟失：若是使用緩存來提升性能，那麼緩存未命中將成爲性能指標。
可靠性
可靠意味着質量或性能始終如一，且可以被信任。可靠性能夠用平均故障間隔時間（MTBF）來表示，計算公式爲：exp(-t/MTBF)。緩存
可靠性很難用數字度量。但咱們能夠用代碼複雜度、測試覆蓋率來了解可靠性的邊緣狀況。遵循最佳工程實踐將產生更好的產品。使用更好的管理實踐和流程，能夠實現更高的可靠性。安全
可用性
表示可用系統時間與總工做時間的比率。這是可靠性之上的另外一層。它是系統掩蓋或修復特定閾值（例如時間間隔）內故障的能力。公式：架構
- MTBF = 平均無端障時間；
- MTTR = 平均修復時間。
彈性
彈性指的是系統遇到問題時能夠降級（而非中斷服務），等待問題修復完成，表示的是系統在遇到嚴重故障時的持續運行能力。爲實現彈性，須要提早設置防護機制（斷路器模式）。彈性有時被稱爲容錯性 。彈性系統指的是能夠適應壓力並持續運行的系統。很難用數字指標來度量彈性。框架
可信賴性
它包括可靠性、可用性、彈性、可持續性（可用性 / 彈性的比值）、可恢復性（彈性函數）和穩健性（可靠性函數）。咱們應該始終將它們視爲一個總體。編程語言
拿一輛汽車來講，若是它是新車而且是知名的可靠品牌（例如梅賽德斯），咱們能夠說它是可靠的。它有備用輪胎，因此有一些可用性。四輪驅動意味着彈性，其中兩輪出故障還有兩輪能工做（但性能會降低）。可持續性是可用性（備用輪胎）和彈性（四輪驅動）的綜合。健壯性在這裏能夠指道路經過能力。若是汽車是電動的，那麼充電速度就是一個可恢復性指標。函數
可伸縮性
它是系統在重負載下在可接受的閾值內的執行能力。它分爲手動和自動可伸縮性兩種，後者也叫靈活性 。當負載突增時，系統會作出反應並水平縮放（添加 / 刪除更多實例）。咱們能夠查看 CPU 和內存來觀察這些突發事件。這些突發操做完成後，系統將殺死沒必要要的實例，從而下降成本。垂直伸縮意味着咱們向系統添加了更多物理資源（例如：更多的內存、更好的 CPU）。微服務
安全性
它其實是許多特色的集合：工具
- 機密性：是指系統保護用戶數據安全的能力；
- 完整性：是保護外部資源免遭篡改的能力；
- 身份驗證：容許用戶訪問系統；
- 受權：則告訴用戶能夠訪問系統的哪些部分。一般使用 RBAC、ACL 或 ABAC 來實現。
- 不能否認性：保證了消息的發送者不可否認本身發送了消息，而且接收者也不可否認本身接收了消息。
互操做性
它表示系統與外部系統通訊的能力。合約接口是互操做性中最重要的概念，其涵蓋了通訊的全部方面，包括錯誤處理。性能
可調整性
也稱爲可變性，其描述了系統變化的難易程度，通常來講它是一個隱含的特徵。
做爲架構師，你要知道系統變化的機率是未知的，但一旦出現變化，系統應該可以優雅地應對。變化是軟件世界中惟一肯定的事物。話雖如此，咱們不能將整個系統都設計爲可變組件。若是每一個組件都是即插即用組件，設計就作不完了。所以咱們須要找到那些變化機率很高的部分。
改進可調整性的技術，有兩個維度：
- 做爲一名架構師，你須要肯定哪些部分具備較高的變化機率；
- 做爲軟件工程師，你必須確保這些部分容易改動。
可部署性
因爲 Docker 的誕生，如今咱們能夠在一臺機器上擁有多個環境。可部署性是一種將代碼轉換爲客戶可用產品的機制。
CI/CD 系統中，每次代碼推送都將觸發一個生產部署。爲此，應經過適應度函數和自動化測試來保護你的代碼，它是抗脆弱性的關鍵部分。咱們但願能按需部署，一鍵完成工做。咱們也會部署硬件。使用基礎架構即代碼之類的技術能夠提升效率。
可測試性
複雜的系統很難測試。以微服務架構爲例，咱們有不少獨立開發的活動部件。這個特徵常常會讓步給其餘特徵，爲了使系統可測試，咱們須要能控制每一個組件的輸入和輸出。
因此，咱們儘可能控制系統的複雜性，構建較小的組件，不要從新發明輪子，還應該編寫可測試的代碼，在適當的位置應用 TDD。
簡單性
遵循 KISS 原則，但這條特徵是很難實現的。一切都是權衡取捨，而大多數狀況下這一條都會被犧牲掉。但若是咱們須要在有限的時間內快速構建某些東西，那麼就應該優先考慮簡單性。
在構建 MVP（最小可行產品）時，咱們關心的只有簡單性。但要注意，實現目標以後，咱們不該丟掉全部東西。不要與 PoC（概念驗證）混淆。可重用性在這裏也很重要。
可移植性
指的是系統從一個操做系統移植到另外一個的能力，它會影響編程語言的選擇。例如：Golang，它打包爲二進制文件，不須要外部依賴項，所以是可移植的。有了容器技術以後，這個問題就很好解決了。
易用性
談到易用性時一般會提到 「可配置性」 ，即：用戶自定義系統的能力。好比：經過 UI 主題更改外觀和配置系統行爲、控制用戶訪問權限等。
還有 「本地化」，也稱爲 i18n（internationalization）。它指的是系統支持多種標準的能力，通常是經過用戶體驗（UX）實現的。這裏的標準指的是語言、貨幣、公制單位、字符編碼等。本地化資源一般是靜態的。
還有 「可訪問性」，是另外一個易用性特徵。世界上有些人是殘疾的（失明、聽力受損、色盲），咱們如何確保這些人能夠受益於咱們的系統呢？對於色盲來講，選擇顏色會花不少時間。Siri/Alexa 是盲人的好幫手。考慮可訪問性時，請想到咱們的祖父母是否是能方便地使用咱們的系統。
另外還有 「可支持性」 ，好比說幫助頁面或者 24x7 技術支持。咱們應該努力讓系統直觀易用，這會影響可學習性，也就是用戶習慣系統所需的時間。用戶培訓和幫助頁面之類的策略很好用。
可擴展性
它是描述系統對即插即用組件需求程度的特徵。對於使用內核架構的系統來講，這是很重要的特徵。Eclipse Platform 和 OSGI 標準就是經典的例子。
抗脆弱性
它是系統應對壓力、衝擊、波動、噪聲、錯誤、故障或攻擊的能力。
改善抗脆弱性的前提，首先咱們要敲打敲打系統。可使用 CI/CD，它們原本就是作這種事的。每次代碼更改都必須投入生產。
可升級性
它是指系統無縫升級自身的能力。首先咱們須要爲服務提供版本控制。下一步是使用藍綠部署或金絲雀部署等策略進行零停機的時間部署。
合規性
無論咱們須要的是哪一種第三方工具和框架，都應該獲得它們的合法受權。咱們須要重視開源軟件的合規性因素，由於它們可能會附帶一些咱們不想要的額外約束。
理想狀況下，每家公司都應該有一個法律部門，但現實並不是如此。適應度函數（例如許可證檢查）能夠保護咱們免受列入黑名單的許可證的影響。在設計系統時，咱們必須找到一種保護用戶數據隱私的方法。
成本
多是最重要的架構特色。一切都有成本，虛擬的、仍是現實的都同樣，任何成本均可以換算成金錢。開發團隊要發工資，學習新技術或培訓團隊成員須要花錢。
- 不尊重敏捷宣言是有代價的；
- 錯誤的代碼要付出代價；
- 缺乏單元測試會有代價；
- 缺乏 CI/CD 會有代價；
- 沒有基礎架構即代碼也會有代價；
這個列表是沒有盡頭的。
以 Scrum 流程爲例，我我的認爲它沒什麼用。在一個固定的週期（一般爲兩週）中，咱們有這麼多的儀式（計劃、站會、演示、回顧），而後根據（猜出來的）估計值作計算，結果 Sprint 完成度 100％只是偶然而非必然。咱們須要敏捷和適應，而不是盲目地遵循流程。咱們應該減小會議和儀式，這樣成本就會降低。咱們應該專一於完成工做的本質要素。
然而，測試是必要的投資，快速前進的惟一方法就是正確前進。從長遠來看，成本是會降低的，測試會減小錯誤的數量，從而減小成本。
代碼質量是另外一項投資。好的代碼將帶來更好的測試，提升穩健性、可維護性、可調整性等。與難以維護的系統相比，咱們的更改花費的時間會更少，成本會降低。
可存檔性
指系統保留歷史數據記錄的能力。在數據是一等公民的系統中（例如財務系統），這個特徵很是重要。數據毫不會刪除，而只會歸檔，這主要是考慮到法律要求。可歸檔性是對可審計性的支持。
首先是在數據上使用時間戳（例如 updatedOn、createdOn）。而後要有一個 Cron（週期）做業，將全部低於特定閾值的數據移入歷史表中。另外一種技術是將數據標記爲軟刪除，但這會影響查詢性能。
可審覈性 / 可跟蹤性
這是支持重構歷史的系統特徵。咱們必須記錄全部關鍵操做（尤爲是在安全場景中），以便重現問題並從錯誤中學習經驗。咱們也能夠將這些記錄用做法律依據。
實現可審覈性的關鍵是記錄每一個關鍵操做並集中存放這些記錄。可使用 ELK。
參考文檔
https://mp.weixin.qq.com/s/iLJ_2akYcdm3BRrhO92ZGw