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