開發框架選型需考慮的性能因素

              開發框架選型需考慮的性能因素

在新產品進入研發階段前，技術、操作系統、硬件、數據庫等選型是必須要完成的一項重要工作，這是對產品非功能需求、架構設計中的各種要素及約束的綜合評估，是驗證將來的技術框架能否滿足業務不斷擴展過程中是否能持續運維擴展的綜合抉擇。

 從上圖可以看出，技術選型實際上是從不同維度對產品技術進行分解的過程，通過分析，合理分解出各項技術需求，然后對各項技術/產品需求進行綜合評估并最終選擇合適的框架,例如互聯網時代很關鍵的分析指標即非功能性指標中的性能指標。

 從業后面這幾年雖然會配合公司到各個地產出差做售前POC非功能技術支持或者出差到各個城商行等協助當地項目經理處理非功能性問題、偶爾也應邀去當地一些互聯網企業協助他們做生產性能故障處理或開發框架選型等測試與調優等工作，其實在做這些非功能咨詢或故障處理時，碰到的大部分問題都是框架開始設計等不成熟導致出現故障的幾率占比比較高。所以很多企業為了防范未來，在新產品上架前的技術開發框架選型愿意投入精力做這些技術驗證，主要目的是為了保證投入回報和最優化IT投入成本，例如框架公共類性能維護、容量規劃性能驗證、硬件平臺與軟件平臺采購選型等非功能性測試驗證來預測性能表現和容量規劃以及預測公司將來業務發展增加時其架構是否能支撐住高并發、架構擴展、敏捷開發等軟件設計能力和市場發展趨勢，例如現在很多企業選型首選考慮微服務架構。

而我們做為專業非功能技術人員，在幫忙客戶選型時，不能因技術而實施技術，產品最終是要給實際客戶使用的，但是產品也是技術的產物，所以需要考慮如下四象思維，站在不同角色考慮非功能因素：

其實就是技術人員和非技術人員不同維度去考慮，如何驗證性測試，

?  用戶關注的是用戶操作的相應時間。

a)    業務操作的簡易敏捷

b)    數據檢索的合理性和正確性

c)    數據交互的效率等

?  其次是技術性角度考慮，例如

?   技術管理員的角度考慮需要關注的性能點。

     a)    DBA角度看待數據庫性能，如表鎖等問題？

     b)    網絡管理員看是否出現網絡堵塞等傳輸性能問題？

     c）  系統運維人員看是否資源利用率是否出現瓶頸，例如磁盤空間等？

     d） 中間件管理人員，檢查是否出現連接數、線程數不足or內存回收異常等?

     e） 架構管理人員，框架開發設計階段考慮起可擴展性、安全性、容錯性、移植性、可拆解、傳輸模式異步等？

?  再次，站在開發（設計）人員角度去考慮

      a)    應用線程鎖問題？

      b） 索引合理性？

      C） 對象釋放及時？

      d） 數據展現數量合理性？等

?   那么站在性能測試工程師的角度，我們要關注什么呢？

a)       響應時間的層次問題分解

b)       系統用戶數的計算公式

c)       各服務資源利用問題分解與根源分析

d)       TPS數值的估算與計算工作和對應問題的定位分析

e)       吞吐量如何求證大小？

例如：吞吐量的計算公式

?  從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量

?  從網絡角度看，吞吐量可以用：字節/秒來衡量