工程結構
其它相關文章
Java 編碼規範1(編程規約-命名風格)
Java 編碼規範2(編程規約-常量定義)
Java 編碼規範3(編程規約-代碼格式)
Java 編碼規範4(編程規約-OOP規約)
Java 編碼規範5(編程規約-集合處理)
Java 編碼規範6(編程規約-併發處理)
Java 編碼規範7(編程規約-控制語句)
Java 編碼規範8(編程規約-註釋規約與其它)
Java 編碼規範9(異常日誌)
Java 編碼規範10(單元測試)
Java 編碼規範11(安全規約)
Java 編碼規範12(MySQL-建表規約)
Java 編碼規範13(MySQL-索引規約)
Java 編碼規範14(MySQL-SQL語句與ORM映射)
Java 編碼規範15(工程結構)
包含應用分層、二方庫依賴、服務器
一. 應用分層
[推薦] 圖中默認上層依賴於下層，箭頭關係表示可直接依賴，如：開放接口層可以依賴於Web層，也可以直接依賴於Service層，依此類推：
- 開放接口層：可直接封裝Service方法暴露成RPC接口；通過Web封裝成http接口；進行網關安全控制、流量控制等。
- 終端顯示層：各個端的模板渲染並執行顯示的層。當前主要是velocity渲染，JS渲染，JSP渲染，移動端展示等。
- Web層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
- Service層：相對具體的業務邏輯服務層。
- Manager層：通用業務處理層，它有如下特徵：
- 對第三方平臺封裝的層，預處理返回結果及轉化異常信息；
- 對Service層通用能力的下沉，如緩存方案、中間件通用處理；
- 與DAO層交互，對多個DAO的組合複用。
- DAO層：數據訪問層，與底層MySQL、Oracle、Hbase等進行數據交互。
- 外部接口或第三方平臺：包括其它部門RPC開放接口，基礎平臺，其它公司的HTTP接口。
[參考] 在DAO層，產生的異常類型有很多，無法用細粒度的異常進行catch，使用catch(Exception e)方式，並throw new DAOException(e)，不需要打印日誌，因爲日誌在Manager/Service層一定需要捕獲並打印到日誌文件中去，如果同臺服務器再打日誌，浪費性能和存儲。
- 在Service層出現異常時，必須記錄出錯日誌到磁盤，儘可能帶上參數信息，相當於保護案發現場。
- 如果Manager層與Service同機部署，日誌方式與DAO層處理一致.
- 如果是單獨部署，則採用與Service一致的處理方式。
- Web層絕不應該繼續往上拋異常，因爲已經處於頂層，如果意識到這個異常將導致頁面無法正常渲染，那麼就應該直接跳轉到友好錯誤頁面，加上用戶容易理解的錯誤提示信息。
- 開放接口層要將異常處理成錯誤碼和錯誤信息方式返回。
- 在Service層出現異常時，必須記錄出錯日誌到磁盤，儘可能帶上參數信息，相當於保護案發現場。
[參考] 分層領域模型規約：
- DO（Data Object）：與數據庫表結構一一對應，通過DAO層向上傳輸數據源對象。
- DTO（Data Transfer Object）：數據傳輸對象，Service或Manager向外傳輸的對象。
- BO（Business Object）：業務對象。由Service層輸出的封裝業務邏輯的對象。
- AO（Application Object）：應用對象。在Web層與Service層之間抽象的複用對象模型，極爲貼近展示層，複用度不高。
- VO（View Object）：顯示層對象，通常是Web向模板渲染引擎層傳輸的對象。
- Query：數據查詢對象，各層接收上層的查詢請求。注意超過2個參數的查詢封裝，禁止使用Map類來傳輸。
二. 二方庫依賴
[強制] 定義GAV遵從以下規則：
- GroupID格式：com.{公司/BU }.業務線.[子業務線]，最多4級。
- 說明：{公司/BU} 例如：alibaba/taobao/tmall/aliexpress等BU一級。子業務線可選。
- 正例：com.taobao.jstorm 或 com.alibaba.dubbo.register
- ArtifactID格式：產品線名-模塊名。語義不重複不遺漏，先到中央倉庫去查證一下。
- 正例：
dubbo-client / fastjson-api / jstorm-tool
- 正例：
- Version：詳細規定參考下方。
- GroupID格式：com.{公司/BU }.業務線.[子業務線]，最多4級。
[強制] 二方庫版本號命名方式：
主版本號.次版本號.修訂號- 主版本號：產品方向改變，或者大規模API不兼容，或者架構不兼容升級。
- 次版本號：保持相對兼容性，增加主要功能特性，影響範圍極小的API不兼容修改。
- 修訂號：保持完全兼容性，修復BUG、新增次要功能特性等。
- 注意起始版本號 必須 爲： 1.0.0，而不是 ，而不是 ，而不是 0.0.1
- 正式發佈的類庫必須先去中央倉庫進行查證，使版本號有延續性，正式版本號不允許覆蓋升級。如當前版本：1.3.3，那麼下一個合理的版本號：1.3.4 或 1.4.0 或 2.0.0
[強制] 線上應用不要依賴SNAPSHOT版本（安全包除外）。
- 說明：不依賴SNAPSHOT版本是保證應用發佈的冪等性。另外，也可以加快編譯時的打包構建。
[強制] 二方庫的新增或升級，保持除功能點之外的其它jar包仲裁結果不變。如果有改變，必須明確評估和驗證，建議進行dependency:resolve前後信息比對，如果仲裁結果完全不一致，那麼通過dependency:tree命令，找出差異點，進行排除jar包。
[強制] 二方庫裏可以定義枚舉類型，參數可以使用枚舉類型，但是接口返回值不允許使用枚舉類型或者包含枚舉類型的POJO對象。
[強制] 依賴於一個二方庫羣時，必須定義一個統一的版本變量，避免版本號不一致。
- 說明：依賴springframework-core,-context,-beans，它們都是同一個版本，可以定義一個變量來保存版本：${spring.version}，定義依賴的時候，引用該版本。
[強制] 禁止在子項目的pom依賴中出現相同的GroupId，相同的ArtifactId，但是不同的Version。
- 說明：在本地調試時會使用各子項目指定的版本號，但是合併成一個war，只能有一個版本號出現在最後的lib目錄中。可能出現線下調試是正確的，發佈到線上卻出故障的問題。
[推薦] 所有pom文件中的依賴聲明放在語句塊中，所有版本仲裁放在語句塊中
- 說明：裏只是聲明版本，並不實現引入，因此子項目需要顯式的聲明依賴，version和scope都讀取自父pom。而所有聲明在主pom的裏的依賴都會自動引入，並默認被所有的子項目繼承。
[推薦] 二方庫不要有配置項，最低限度不要再增加配置項。
[參考] 爲避免應用二方庫的依賴衝突問題，二方庫發佈者應當遵循以下原則：
- 精簡可控原則。移除一切不必要的API和依賴，只包含 Service API、必要的領域模型對象、Utils類、常量、枚舉等。如果依賴其它二方庫，儘量是provided引入，讓二方庫使用者去依賴具體版本號；無log具體實現，只依賴日誌框架。
- 穩定可追溯原則。每個版本的變化應該被記錄，二方庫由誰維護，源碼在哪裏，都需要能方便查到。除非用戶主動升級版本，否則公共二方庫的行爲不應該發生變化。
三. 服務器
[推薦] 高併發服務器建議調小TCP協議的
time_wait超時時間。- 說明：操作系統默認240秒後，纔會關閉處於
time_wait狀態的連接，在高併發訪問下，服務器端會因爲處於time_wait的連接數太多，可能無法建立新的連接，所以需要在服務器上調小此等待值。 - 正例：在linux服務器上請通過變更
/etc/sysctl.conf文件去修改該缺省值（秒）：net.ipv4.tcp_fin_timeout = 30
- 說明：操作系統默認240秒後，纔會關閉處於
[推薦] 調大服務器所支持的最大文件句柄數（File Descriptor，簡寫爲fd）。
- 說明：主流操作系統的設計是將TCP/UDP連接採用與文件一樣的方式去管理，即一個連接對應於一個fd。主流的linux服務器默認所支持最大fd數量爲1024，當併發連接數很大時很容易因爲fd不足而出現“open too many files”錯誤，導致新的連接無法建立。
- 建議將linux服務器所支持的最大句柄數調高數倍（與服務器的內存數量相關）。
[推薦] 給JVM設置
-XX:+HeapDumpOnOutOfMemoryError參數，讓JVM碰到OOM場景時輸出dump信息。- 說明：OOM的發生是有概率的，甚至有規律地相隔數月纔出現一例，出現時的現場信息對查錯非常有價值。
[推薦] 在線上生產環境，JVM的Xms和Xmx設置一樣大小的內存容量，避免在GC 後調整堆大小帶來的壓力。
[參考] 服務器內部重定向使用forward；外部重定向地址使用URL拼裝工具類來生成，否則會帶來URL維護不一致的問題和潛在的安全風險。