談談架構非功能性

架構的功能性要求有：吞吐量、穩定性、業務性等。這些都是架構的基本要求。

那麼架構的非功能性要求有哪些呢？

從實踐中發現，好的架構有如下這些常見的非功能性要求

1、優雅的代碼

一、不產生NULL對象，不須要做NULL對象判斷。

代碼中最多見的代碼多是在使用對象前要先對對象做非NULL的判斷，特別是業務代碼中。這樣的代碼重複性高且意義不大，不單形成性能開銷，也嚴重影響了代碼的美感。

這就像一遍文章裏出現了不少「他說：」，「你說：」等一些重複性高的，沒多大涵義的詞同樣。

但若是不做這些判斷又會容易引發空指針異常。

最佳實踐是，被調用方不要返回任何NULL對象。這樣使用方就能不做判斷的直接使用對象，或只需一個簡單的詢問就能知道返回結果是否是能正常使用，從而決定是否要跳出執行。

因此除了不返回NULL對象，最好仍是創建統一的返回結果，將結果和一些處理封裝起來，例如：

Result<T>{

　　private Result<T>();//私有構造函數，外面不能用new來建立

　　static newSuccess(data);//成功結果傳入數據

       static newError();//異常結果不需數據

　　T data;//數據

　　isSuccess();//簡單詢問數據是否正常

　　getData();//能夠做一些NULL的處理

}

二、減小重複代碼。

2、易擴展

一、不直接使用new來建立對象，可用spring注入或用工廠方法、靜態的生成器來建立對象

二、面向接口或超類編程

3、易修改

一、容易發生修改的地方都提供操做類或配置表，例如系統名稱、數據規則、權限規則等。

二、集中管理

例如數據源的管理，對於分佈式系統來講業務服務器很容易就能夠作到無狀態 ，由於讓全部的服務器都能提供同同樣的計算這並不會形成多大的開銷和浪費。但存儲卻很難作到無狀態的，若是全部機器都存儲同一份數據，那這個開銷將會很龐大，並且數據的一致性也很難去保證。

常見的存儲管理策略有：

1）若是存儲的是輕量的數據，能夠採用集中存儲管理，例如會話信息，緩存系統。

2）若是是較重的業務數據，就只有根據業務類型對應到相關的數據源。但獲取數據源的方式需集中起來管理，業務方獲取數據源時都通過可管理的方式來注入，而不是業務方本身去構建。

4、易維護

一、日誌管理，維護通常是經過日誌來查錯，定位問題。

開發時可能經過打印堆棧信息來快速定位問題，但線上是不可能打印堆棧信息的，只能經過對日誌的查找，關鍵字定位等方式來發現問題。

因此構建好日誌的關鍵字索引，內容格式，輸出方式，攔截位置就很重要。

最佳實踐有將日誌分類輸出與管理，只要有如下三類：

1）、方法入參與輸出監控，可經過AOP來做切面處理

2）、堆棧日誌，某些日誌框架提供堆棧日誌輸出，例如logback

3）、邏輯日誌，這部分是最重要也是最容易混亂的，它至關因而在程序中埋下監測點，經過這些點的數據幾乎能還原程序的調用過程。但若是沒有統一好日誌的內容格式，記錄方式 ，操做類等便會很容易引發混亂，且較難修改，當日志規則發生改變的時候。