Web服務端軟件的服務品質概要

軟件品質概述

---

提供一樣功能、產品和服務的服務者中， 競爭力來自功能的多樣化和服務品質的差別化， 不管是個體、企業仍是國家。

• 這裏的服務指功能、產品的實現程度和處理能力，以及研發/客服提供的技術支持程度（7*24, 隨時響應, 溝通便捷，快速解決，舒適提示，有效指南等）。

• 從某種意義來講， 一切皆服務。 功能和產品只是形式， 服務纔是本質。服務響應某種需求從而具有存在價值。個體、企業爲社會提供某種類型、某種程度的服務，並得到相應回報。

程序員提供的服務是，在特定的工做環境和企業文化中，運用可用的資源以及本身的知識、技能、經驗、時間、精力、資源，在適當可接受的開發成本下，經過將現實問題構造和組織成正確的邏輯流而得到問題的解決並持續維護的能力程度。

• 這種能力程度既包括服務能力自己，也包括經過這種能力所創造的服務的能力。 服務能力自己主要包括： 精通特定語言、技術、平臺、架構等的技術深度； 組合技術、產品、運營、服務、商業的綜合認知廣度；具有多樣化技能（開發、寫做、外語、溝通、組織、談判等）；作事的能力素養，耐心、專一、縝密、魄力、幽默等； 具有非技術方面的特長，好比體育、音樂、文學、藝術、設計等。 經過這種能力所創造的服務， 一般是指軟件、產品或服務。

每次解決用戶最關心的前三個問題， 不爲無關痛癢的事情浪費時間、精力和資源。

• 首先是功能與服務，功能與服務是核心，是存在的價值；
• 其次是設計，設計使功能與服務更加突出具備吸引力，更好的使用品質；
• 接着是成本和傳播。保證優秀功能和設計的基礎上下降資源時間和人力成本，同時良好的傳播和使用讓邊際成本更低。

如何保證服務端開發的功能和服務達到應有的品質呢？

1. 明確須要達成的品質； 知道作什麼以及如何作；
2. 將服務品質儘量量化並進行測量，作到服務品質透明化；
3. 更傾向於情感因素的服務品質，採用情感化方法處理。不在本文討論範圍內。

基本品質屬性

---

正確性

軟件是否正確實現了指定的功能， 知足客戶的多樣化須要。

• 繪製業務流程圖、子系統交互圖，遵循意圖導航編程方法，經過分解、實現和鏈接若干緊密聯繫的邏輯單元而實現。
• 在內部實現上，是數據記錄是否正確完整地構造、存取或銷燬，且沒有產生髒數據和無效數據【內部品質】。
• 須要創建功能實現的整個流程環路，對其中的全部細節知根究底，對交互的外部系統提供的相關服務也瞭如指掌。
• 量化： 業務數據是否合理的存取；若涉及多個子系統，則須要保證數據的一致性。
• 相關建議：

1. 溝通， 準確理解需求、場景及業務流；
2. 仔細挑選開發使用的工具箱、庫與框架；
3. 經常使用子任務使用公認主流開發庫並仔細測試；
4. 完整理解API， 包括其功能、原理、適用場合與侷限性；
5. 編寫類/方法/函數時註明使用契約及特殊處理；
6. 每一個類/方法/函數各司其職，相互協做。

性能成本

軟件在指定時間和可用資源的前提下實現功能和服務的響應能力和請求處理能力。 須要有偏差範圍的測量或估算。

• 構造單個請求測量運行時間和響應時間；構造大量併發請求測量吞吐量。
• 可參考 SLA (服務等級協議)。 程序的執行效率應當在可接受的開發成本下達到最佳。
• 這就是說，在 "開發功能所須要的時間和資源成本" 與 "最終實現的服務可以提供的品質" 存在一個權衡。
• 通常來講，品質越高的服務所須要的時間和資源成本越高；無止境追求更高效率而不計成本和服務目標是不可取的。
• 比較理想的狀況是： 經過適量改進、技術革新、管理改善等，可使得花費較少的時間和資源成本可以得到更高的服務品質。
• 量化： 運行時間、 所需的存儲資源（數據庫記錄數、KV 數、緩存、文件）、 響應時間、吞吐量/併發能力（QPS, TPS, UPS）。
• 相關建議：

1. 大數據量結果集使用多線程技術獲取子集並彙總；
2. 多IO任務使用異步方式來處理；
3. 耗時長的任務進行分解/併發/異步處理；
4. 避免沒必要要的重複建立/計算開銷；
5. 耗內存的大對象的延遲建立與複用；
6. 耗時長/頻繁讀操做適當利用緩存；
7. 短時操做控制在 0.5-1s 內， 長時操做採用「異步+消息通知」模式；
8. 測量時間，對熱點區域進行適宜程度的優化；
9. 測量和改進響應時間與吞吐量， 使之達到良好的平衡；
10. 使用更好的硬件提高性能；
11. 減小啓動加載組件，按需加載和緩存；
12. 使用異步模式逐步加載與展現；
13. 加載與執行分離；

健壯性

軟件應對錯誤的能力。可以在非預期環境降級運行，在預期環境可以捕獲全部的錯誤條件（前提不符合、非預期輸入、髒數據等）和異常狀況並給出合適的返回信息。

• 對於前端交互而言，須要友好容易理解的提示信息； 對於後臺服務而言， 須要規範的錯誤碼和錯誤消息。
• 軟件健壯性的提升須要大量的錯誤檢測，容易致使維護性下降。最好將錯誤檢測從主業務流程中抽離出來，創建可複用的檢測庫函數。
• 建議先創建正確完整的業務主流程，而後對於主流程的每一個環節進行推敲，找出各類錯誤場景並進行處理。
  
• 量化： 錯誤場景測試用例數；覆蓋場景數。
• 相關建議：

1. 錯誤碼和錯誤消息使用配置文件，與代碼分離；
2. 不一樣類型的參數檢測使用不一樣的參數驗證器（一般是正則表達式）;
3. 使用全局統一的錯誤檢測函數儘可能在一個地方集中檢測錯誤。
4. 細分應用中出現的各類異常並進行不一樣的處理；
5. 在系統底層處理可以處理的異常， 沒法處理的使用異常轉譯傳給頂層；
6. 在系統頂層統一處理各類應用異常並返回友好提示；
7. 提示和異常消息放置在配置文件，與代碼分離；
8. 錯誤處理全局框架。 `

易追蹤性

程序運行過程當中輸出適量的日誌信息，便於追蹤程序執行狀態，快速排查錯誤【內部品質】。

• 識別業務流程的關鍵路徑和關鍵狀態，記錄其運行時狀態便於分析。
• 須要格式良好規範的適量且關鍵的 INFO 日誌和 Error 日誌。我的認爲 DEBUG 日誌能夠經過提高代碼質量來消除其必要性。
• 量化： 排查、定位每一個問題的所需時長。

易測試性

主要是單元測試、自動化功能測試和性能測試。 單元測試和功能測試保證正確性，性能測試保證效率【內部品質】。

• 單元測試要求在開發過程當中儘可能編寫具備單一職責的短小方法、類；代碼對象越小，單元測試所發揮的做用越大。
  
• 功能測試要求針對具體使用場景設計有效的測試用例、測試計劃和測試執行。
• 性能測試要求對業務處理所需的時間和資源進行測量，給出最佳值、最差值和平均值。至少要對運行時間進行測量。
• 量化： 業務方法的測試覆蓋度、代碼行、分支覆蓋程度、測試用例集合、性能測試報告。

安全性

避免泄漏重要、敏感、隱私信息； 保護業務和數據不受非法訪問、非受權訪問的破壞； 追蹤系統訪問日誌。

• 常見的方法有敏感信息識別和屏蔽、訪問受權機制、 訪問日誌審計、代碼漏洞防備。
• 相關建議：
  

1. 用戶角色與權限分級；
2. 只讀與操做權限分離；
3. 機密數據加密保護/權限控制/操做限制/身份認證；
4. 權限申請加入審批流程制度；
5. 記錄請求日誌與用戶操做日誌；
6. 請求鏈接進行加密；
7. 避免顯示請求 URL；
8. 防止注入攻擊，識別非法請求模式。

可擴展性品質屬性

---

可擴展性

• 相關建議：

1. 總體架構模塊化設計， 組件服務化， 最小化公共服務接口；
2. 設計時老是考慮變化；
3. 使用配置參數， 避免硬編碼；
4. 編寫自包含、自封裝、不修改外部狀態的代碼，最小化依賴；
5. 使用設計模式優化代碼表達結構， 加強軟件的「柔韌度」；
6. 文檔化順序與依賴關係， 按期整理、更新依賴關係；
7. 表達與執行分離， 使用領域語言/規則表達邏輯， 預編譯規則， 規則的動態生成、配置和加載。

可複用性

要求軟件中的函數、方法、類、庫、模塊、組件、框架等可以在同一工程或不一樣項目或不一樣產品中屢次使用，便於替換更新【內部品質】。

• 單一職責原則；
• 接口定義與設計正交；
• 對於每一個知識點、業務點和事實都有合理的抽象；
• 每一個業務方法最好不超過 60 行；
• 最起碼要求是在同一工程中可以儘量複用， 避免重複代碼段；
• 量化： 重複代碼段數量； 函數、方法、類、庫、模塊、組件、框架的複用次數。

可維護性

要求軟件容易理解、容易作出修改以知足新的需求，一般系統應具有模塊化、高內聚、鬆耦合的特性【內部品質】。

容易理解

• 須要可複用性的支持，同時要求代碼儘量具備語義與細節分離、自解釋能力、適量註釋、使用習慣用法。
• 語義與細節分離"指高層代碼表達意圖，低層代碼呈現細節；"自解釋能力"指代碼經過合適的變量和函數命名可以望文生義；

• "適當的註釋"須要註明代碼意圖及設計思路， 做爲理解代碼的有效指南；"習慣用法"是代碼的經常使用模式，便於快速瀏覽和理解。

  容易修改

  須要快速定位一個功能服務所應對的代碼集合，要求代碼具備良好的組織和實現結構，避免對多個地方作出相同或相似的修改； 避免對原有總體設計作出大幅度修改。

• 請參考《敏捷軟件開發：原則、模式和實踐》一書，儘量知足五大設計原則(SRP, OCP, LSP, DIP, ISP)，實現「對修改關閉，對擴展開放」的境界。即：對於新需求的開發，儘量僅僅是增長代碼，而不須要修改原有代碼。

量化： 理解一個功能須要的時長； 修改或擴展一個功能須要修改的代碼行。

全局性品質屬性

---

穩定性

程序運行中可以始終如1、持續長時間地提供正確、一致性的服務。

• 要求程序可以合理地使用和釋放資源，監控程序的運行狀態並及時發現異常狀況解決。
• 對於高併發場景， 須要採用合適的技術進行分流，及時處理或拒絕請求，避免由於資源消耗過快過大而致使服務崩潰。
• 量化： 程序的持續可用性時長； 高併發能力。
• 相關建議：

1. 確保軟件的運行環境正常穩定，包括硬件、操做系統、依賴系統；
2. 軟件可以有效應對環境波動（好比網絡中斷）而不至於終止；
3. 外部系統服務調用的影響局部化， 不影響總體運行；
4. 系統組件服務模塊的影響局部化， 不影響總體運行；
5. 避免內存泄露，死循環，死鎖等會致使程序崩潰的問題；
6. 批量資源釋放問題要仔細檢查，是否會由於錯誤或異常致使內存泄露；
7. 操做失敗可回滾；

可靠性

服務在嚴重錯誤狀況下的可恢復能力和可替換能力，避免單點故障，保證可用性，保證用戶數據的正確性和完整性。

• 主要包括服務的冗餘、容錯、備份、監控、自檢測和恢復機制。
• 量化： 服務發生錯誤時是否可用； 是否能夠從錯誤中恢復。
• 相關建議：

1. 負載均衡避免單點故障；
2. 主備容災應對緊急狀況；
   
3. 高負載/性能測試；
4. 添加系統監控， 展現指定時間間隔內的系統各項指標/服務/資源的運行情況。

易用性

易用性是用戶使用產品的難易程度的度量。 一般用於描述用戶體驗的前端領域。 不過服務端也有可用性的概念。

• 服務端的可用性， 深層次上體如今接口、庫方法是否容易學習和使用、是否容易被濫用、誤用；淺層次上體如今代碼排版是否悅目易讀、代碼風格是否一致美觀。
• 相關建議：

1. 知識與信息的準確性和豐富度，符合或超出指望；
2. 操做的引導設計、正確性與溫馨度；
3. 外觀與設計的實用美觀，賞心悅目；
4. 使用動畫或添加趣味內容消弱等待時間的影響；
5. 使用變化效果提示用戶請求已經發送，正在處理。

彈性伸縮

服務能夠經過簡單地部署在更多機器上提高服務能力(吞吐量)，能夠經過減小機器部署來下降成本。

• 須要從架構設計上進行支持。請求處理儘量是無狀態的。
• 量化：併發請求處理量與機器數的比率。　
• 水平擴展： 增長多個邏輯單元資源並使他們做爲一個總體在工做， 好比集羣、分佈式、負載均衡；
• 垂直擴展： 在同一個邏輯單位添加資源以增長容量， 好比增長CPU、內存、磁盤空間。

可移植性

軟件可以在多種運行環境、平臺上一致性地正確運行而只須要作出少許修改或無需修改。

• 使用可移植語言和平臺、在實現功能和服務時儘量遵循標準接口和行爲，減小非標準行爲的使用；
• 在底層提供接口統一不一樣平臺的差別性；在高層使用統一接口進行處理，避免處理平臺細節。
• 可移植性最好在系統構建之初進行考慮，好比初始採用 PHP， 後續移植到 Ruby, Python 或 Java 平臺。
• 量化： 從一種語言移植到另外一種語言或從一個平臺移植到另外一個平臺所須要的代碼行。
• 相關建議：

1. 使用抽象屏蔽不一樣平臺之間的差別；
2. 使用跨平臺SDK；
3. 儘量遵循可移植的標準；
4. 儘量採用標準寫法；
5. 響應式設計。

可運維性

服務發佈後，管理大規模服務的運行、排查/診斷/解決問題的難度和速度、處理用戶反饋的工做量。

• 服務發佈後，可能產生的問題有哪些？ 怎麼排查？ 服務的運行規模有多大？ 併發程度如何？
• 在服務開發上，須要避免的是低級問題的產生，減小低級錯誤致使的工做量；
• 對於疑難問題，則須要提供關鍵的日誌信息/運維文檔便於排查；
• 對於大規模服務的運行，一般的方法是監控、報警以及可視化。
• 量化： 參考運維的量化標準。

可定製／熱升級

是否容易針對客戶的特殊需求進行定製；服務升級時是否能夠儘可能不影響到用戶的正常使用。

• 相關建議：

1. 模塊化應用程序和系統服務組件；
2. 每一個獨立組件有一個標識， 標識其是否可顯示/加載；
3. 經過配置文件指定啓動或初始化時能夠顯示/加載的模塊和組件；
4. 使用定時Job或有時限的緩存機制來加載配置文件；
5. 使用觀察者模式檢測配置的變化並從新加載配置到應用中；
6. 當檢測配置變化時，能夠發送外部命令給應用系統觸發其從新加載配置；
7. 提供界面修改配置文件參數並實時更新應用和配置文件（可能有安全隱患）；
8. 使用全局單例管理者來負責根據配置文件的變化動態顯示/隱藏和動態加載/卸載模塊；
9. 使用策略模式靈活替換和切換具備相同功能的模塊， 使用抽象抽取其公共使用接口。

互操做性

軟件與其餘系統交互的難易程度。主要包括通訊方式、版本兼容性。

參考文章

---

• 軟件質量模型
• 實現軟件架構質量屬性的戰術
• 可複用性：專題
• 可伸縮性最佳實踐：來自eBay的經驗
• 軟件設計的可用性

轉載請註明出處。謝謝！ :)