錯誤的設計：

我發現公司很多程式碼，比如去統計某個頁面的訪問量，很多開發同事都是在相應的controller去統計訪問量，打個比方說統計userManager頁面訪問量，就在UserManagerController中，跳轉usermanager頁面的方法中做點選統計訪問。這是非常不合理的，為什麼呢，因為這可能會導致業務邏輯程式碼和非業務邏輯程式碼混攪在一起。舉個極端的例子，假如你有1000個頁面，你是不是也在1000跳轉頁面方法中寫點選統計，這的是多大的工作量，假如有一天業務變動，將頁面訪問量改為頁面add操作訪問量，你是不是要去修改1000個方法。

總之這樣設計壞處：後期維護難，開發成本高。

我公司原先就這麼搞的，後來我建議改了，當時還沒接觸微服務，下面主要用微服務方案來處理。

設計：

我們統一將這類非業務邏輯部分放到一個服務單元處理。

閘道器部分對這類請求，多新增一個服務單元

介面設計提供一個公共介面，該介面處理請求特定引數。我的設計是操作型別，URL。URL通過spring容器獲取請求方法和跳轉頁面。上面介面已經可以做統計了，接下來是持久化了，因為這是一個頻繁資料庫互動操作（涉及操作日誌），所以我選擇Redis記憶體資料庫，因為是分散式系統，我沒有使用上下文處理。