作者：編碼專家
部落格：https://www.codingbrick.com
寄語：就算終其一生是個平凡人，那也不算什麼失敗。
在軟體系統裡面，功能性需求是面向使用者、詳細明確的需求，由產品人員根據市場的需要提煉出來，是產品生命週期裡最重要的一環。比如電商系統裡面的優惠券功能，通常包含需求：優惠券分類、細分領券人群、核銷優惠券等等。一旦需求通過技術評審，開發人員必須依照檔案實現功能，不允許輕易變更。
非功能性需求是什麼呢？保障系統持續健康運轉的輔助需求。依然以電商系統的優惠券為例，在促銷活動期間發放大量優惠券，如何防止使用者集中領券時系統不崩盤呢？活動結束後，如何收縮伺服器，節省伺服器資源呢？ 非功能性需求是面向運維的，重要但是不太緊迫，有時候可以沒有操作介面，由架構師提出解決方案，再推動各個業務開發部門去接入相應元件。這些輔助系統對業務系統效能影響很小，並且長期處於優化狀態。
可伸縮性是指系統根據外部負載自動調節計算能力，常見的做法是水平擴充套件和垂直擴充套件。
當系統負載很高時，增加伺服器端的節點數量，也叫做擴容；當負載很低時，釋放閒置的機器，也叫做縮容。這兩個過程有幾個重要的思考點：
（1）節點越多，承載能力越高嗎：任何事情都有兩面性，為了解決問題引入一個方案，就必然帶來新的問題。節點越多，協調節點的開銷就越大，額外增加的計算資源抵不上協調節點的開銷，並行能力不升反降。
（2）擴容多少節點才夠用：資源總是有限的，用有限的資源做更多的事情，才能得到資本家的歡心。合理擴容的數量根據壓測的結果來定。在日常的運維中，要求系統能夠自動化擴容少量機器處理突發流量，如果超出負載再發出警報。
垂直擴充套件是指增強單機處理能力，比如增加記憶體、升級CPU、更換固態硬碟等等。這個做法的好處是簡單快速，無需調整系統設計；缺點是單機的處理能力始終有限，不可能無限升級，而且更換硬體必須停機，影響系統可用性。
系統可用性是指系統在規定的時間內正常執行的能力，是衡量系統質量和穩定性的重要指標之一。例如，一個系統的可用性為99.9%，表示在一年中的時間裡，系統正常執行的時間佔據了99.9%。以下是計算公式：
Availability = (Total Time - Downtime) / Total Time * 100%
Total Time表示總的時間，Downtime表示系統的停機時間。
除了自然災害如水災、地震等不可抗因素，降低可用性的主要原因是：
對於大型網際網路公司尤其是SaaS、雲服務等公司，系統可用性就是生命線，只要出現時間過長的服務不可用，會大大影響口碑和品牌。通常這類公司採取的技術措施是異地多活，在不同城市建立獨立的資料中心。「活」是相對於冷備份而言的，冷備份是備份全量資料，平時不支撐業務需求，只有在主機房出現故障的時候才會切換到備用機房，而多活，是指這些機房在日常的業務中也需要做業務支撐。
可維護性是衡量系統升級的能力，修改或者增加需求，開發週期越短越好，注意與「可伸縮性」區分。
需求變更是無比尋常的事情，可維護性是所有團隊都會關注的重點。一旦系統的可維護性變差，程式設計師的頭髮會迅速脫落。影響可維護性的因素主有三個：
近些年在大型專案開發裡，領域驅動設計（Domain Driven Design）的出鏡率很高。領域驅動設計是一套從系統分析到軟體建模的設計思想和方法論。核心思想是以領域為核心驅動力構建軟體設計體系，並圍繞業務概念抽象出領域模型，通過領域和邊界劃分將複雜的業務模型抽象化、簡單化，最終實現複雜軟體應用系統的拆解和封裝。領域驅動設計並沒有發明新的東西，每個概念都是沿用已久的軟體開發理念。它的實施成本很高，專案程式碼更加繁瑣，人員的溝通成本也較高。
如果團隊規模很小或者開發小型專案，提高可維護性至少要做好兩個事情：
資料是系統最重要的資產，資料不能丟也不能錯，保持資料一致性萬分重要。一致性分兩種情況：
在分散式系統中，保持資料一致性是公認的難題，主要體現在下面幾點：
保持強一致性的成本很高，最好的解決方案就是避免分散式事務，但是在金融、電信領域中的部分業務場景要求資料強一致性，同時要保證服務的可延伸性和可靠性。結合實際的業務場景，一致性可以細分五個級別：
彈性，是指系統可以優雅地處理意外、從故障中恢復過來。故障是不可避免的，甚至不可預測。由於微服務的普及，故障發生的機率與計算節點數量成正比。分散式系統具備一定的容忍故障的能力，故而彈性設計又稱容錯設計，主要的解決方法有如下兩點：
系統必須具備防止故障從一個系統傳播到另一個系統的能力，常見場景如下：
（1）系統間強依賴：如果系統間存在強依賴，當一個系統發生故障時，強依賴它的元件將無法正常工作。通常的手段是將強依賴轉化為弱依賴或最弱依賴，比如設定合適的超時、捕獲異常、同步依賴轉非同步依賴、提供備份元件等。
（2）系統共用資源：如果系統間存在共用的資源，如執行緒池、資料庫連線池、網路連線池、記憶體區等等。當一個系統因為故障耗盡了共用的資源後，所有依賴該資源的系統也都會發生故障。通常的手段是對元件的資源使用建立配額體系，或者為重要元件提供專用資源。
（1）服務降級：當出現系統故障後，在有限的資源情況下犧牲某些業務功能或者某些客戶群體，保障更關鍵的業務服務質量。服務降級可以是人工觸發的，也可以是系統自動執行的。所有核心交易場景下的非關鍵服務存取均應進行服務降級設計，以保證核心交易成功率。
（2）服務限流：當負載超出系統處理能力時，可能會造成系統部分業務失敗，需要通過業務限流來防止系統進一步化。例如在一個分散式系統中，每秒最多隻能處理2000個請求。為了防止系統過載，可以設定規則限制上游服務請求量，當超過2000時隨機拋棄一些請求來實現限流。
（3）服務熔斷：微服務與微服務之間有依賴性，可能導致故障傳播，對整個系統造成災難性的後果，即服務的雪崩效應。熔斷器是通過快速失敗（Fail Fast）的機制，避免請求大量阻塞，從而保護呼叫方。比如：服務A呼叫當下遊B失敗時，會導致請求超時引起堆積佇列，進而加大了B系統的壓力，增加了整個鏈路的請求時間。B系統本身就出現了問題，不斷的請求又把問題加重了。如果使用了A觸發了熔斷，拒絕了上游的請求，會降低下游B服務的壓力，給與B服務恢復的時間。
可觀測性是指通過度量、監控和分析系統元件，瞭解系統的狀態、效能和問題的能力。可觀測性可以幫助開發人員快速定位和解決系統中的問題，提高系統的穩定性和可靠性。系統可觀測性設計還有助於優化系統效能，幫助研發人員針對性地做出調整和優化，提高系統的吞吐量和響應速度。
系統可觀測性設計應遵循幾個重要原則：
主流的可觀察系統基於三類資料構建，覆蓋了一個應用伺服器產生的大部分資料：
可觀察性系統是監控系統的超集，監控能夠檢測到系統當前的問題，但是可觀察性系統要幫助研發人員預判故障發生的可能性。
安全性是指保障硬體正常執行，讓使用者只能存取合法授權的資源。安全是架構設計中很重要的一部分，很多大型企業都因為安全漏洞洩露過資料。廣義的安全性涉及到所有的軟硬體，比如物理機房、伺服器及網路、作業系統、應用系統。架構安全設計可以遵循如下五個原則：
系統安全等級越高，運作成本越高。為了節省成本，中小型團隊主要聚焦應用系統的安全，其他的交給雲服務。雲服務商負責雲端安全，尤其是用於託管資源的物理基礎設施的安全，包含如下內容：
開發團隊根據自身人力和財力，酌情實施安全設計，通常可以借鑑的安全措施有5條：