（一）應用分層
-
圖中默認上層依賴於下層，箭頭關係表示可直接依賴，如：開放接口層可以依賴於Web 層，也可以直接依賴於 Service 層，依此類推：
![在這裏插入圖片描述]()
• 開放接口層：可直接封裝 Service 方法暴露成 RPC 接口；通過 Web 封裝成 http 接口；進行網關安全控制、流量控制等。
• 終端顯示層：各個端的模板渲染並執行顯示的層。當前主要是 velocity 渲染，JS 渲染，JSP 渲染，移動端展示等。
• Web 層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
• Service 層：相對具體的業務邏輯服務層。
• Manager 層：通用業務處理層，它有如下特徵：
1） 對第三方平臺封裝的層，預處理返回結果及轉化異常信息。
2） 對 Service 層通用能力的下沉，如緩存方案、中間件通用處理。
3） 與 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 層絕不應該繼續往上拋異常，因爲已經處於頂層，如果意識到這個異常將導致頁面無法正常渲染，麼就應該直接跳轉到友好錯誤頁面，加上用戶容易理解的錯誤提示信息。開放接口層要將異常處理成錯誤碼和錯誤信息方式返回。
-
分層領域模型規約：
• 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 遵從以下規則：
1） GroupID 格式：com.{公司/BU }.業務線 [.子業務線]，最多 4 級。
說明：{公司/BU} 例如：alibaba/taobao/tmall/aliexpress 等 BU 一級；子業務線可選。
正例：com.taobao.jstorm 或 com.alibaba.dubbo.register
2） ArtifactID 格式：產品線名-模塊名。語義不重複不遺漏，先到中央倉庫去查證一下。
正例：dubbo-client / fastjson-api / jstorm-tool
3） Version：詳細規定參考下方。 -
二方庫版本號命名方式：主版本號.次版本號.修訂號
1）主版本號：產品方向改變，或者大規模 API 不兼容，或者架構不兼容升級。
2） 次版本號：保持相對兼容性，增加主要功能特性，影響範圍極小的 API 不兼容修改。
3） 修訂號：保持完全兼容性，修復 BUG、新增次要功能特性等。 -
線上應用不要依賴 SNAPSHOT 版本（安全包除外）。
-
二方庫的新增或升級，保持除功能點之外的其它 jar 包仲裁結果不變。如果有改變，必須明確評估和驗證。
在升級時，進行 dependency:resolve 前後信息比對，如果仲裁結果完全不一致，那麼通過dependency:tree 命令，找出差異點，進行排除 jar 包。
- 二方庫裏可以定義枚舉類型，參數可以使用枚舉類型，但是接口返回值不允許使用枚舉類型或者包含枚舉類型的 POJO 對象。
- 依賴於一個二方庫羣時，必須定義一個統一的版本變量，避免版本號不一致。
- 禁止在子項目的 pom 依賴中出現相同的 GroupId，相同的 ArtifactId，但是不同的Version。
在本地調試時會使用各子項目指定的版本號，但是合併成一個 war，只能有一個版本號出現在最後
的 lib 目錄中。可能出現線下調試是正確的，發佈到線上卻出故障的問題。
- 底層基礎技術框架、核心數據管理平臺、或近硬件端系統謹慎引入第三方實現
- 所有 pom 文件中的依賴聲明放在語句塊中，所有版本仲裁放在語句塊中。
- 二方庫不要有配置項，最低限度不要再增加配置項。
- 爲避免應用二方庫的依賴衝突問題，二方庫發佈者應當遵循以下原則：
1）精簡可控原則。移除一切不必要的 API 和依賴，只包含 Service API、必要的領域模型對象、Utils
類、常量、枚舉等。如果依賴其它二方庫，儘量是 provided 引入，讓二方庫使用者去依賴具體版本號；
無 log 具體實現，只依賴日誌框架。
2）穩定可追溯原則。每個版本的變化應該被記錄，二方庫由誰維護，源碼在哪裏，都需要能方便查到。
除非用戶主動升級版本，否則公共二方庫的行爲不應該發生變化。
(三) 服務器
- 高併發服務器建議調小 TCP 協議的 time_wait 超時時間。
- 調大服務器所支持的最大文件句柄數（File Descriptor，簡寫爲 fd）。
- 給 JVM 環境參數設置-XX:+HeapDumpOnOutOfMemoryError 參數，讓 JVM 碰到OOM 場景時輸出 dump 信息。
- 在線上生產環境，JVM 的 Xms 和 Xmx 設置一樣大小的內存容量，避免在 GC 後調整堆大小帶來的壓力。
- 服務器內部重定向使用 forward；外部重定向地址使用 URL 拼裝工具類來生成，否則會帶來 URL 維護不一致的問題和潛在的安全風險。