最近在專案中遇到了一些問題，乙個比較多的問題服務和服務直接呼叫混亂 a服務呼叫b b服務呼叫c c服務呼叫d 導致後期公升級會出現很多問題 如果有個流程圖也許會好些 但是沒有 因此我陷入了思考， 如果進行重構的話那什麼樣的架構會是較好的** 我想 設計模式的六大原則 在此也一樣適用
明確的分工,服務之間優雅的呼叫
這裡簡單畫的乙個草圖
先介紹一下
查詢：對應查詢操作
操作：對應增刪改操作
分為四層
ui： 頁面及後台呼叫
閘道器層: 路由
聚合層：查詢聚合 操作聚合
服務層：訂單服務 商品服務
服務要想呼叫服務 如 a服務想呼叫b服務 可以 a通過mq傳遞給聚合層 然後聚合層根據訊息呼叫b ，服務之前的呼叫交給 聚合層維護
後面還會不斷完善這篇文章的
關於微服務架構的思考
最近在專案中遇到了一些問題，乙個比較多的問題服務和服務直接呼叫混亂 a服務呼叫b b服務呼叫c c服務呼叫d 導致後期公升級會出現很多問題 如果有個流程圖也許會好些 但是沒有 因此我陷入了思考，如果進行重構的話那什麼樣的架構會是較好的 我想 設計模式的六大原則 在此也一樣適用 明確的分工,服務之間優...
微服務 關於微服務的思考
通過kafka進行日誌收集，並結合elk進行日誌聚合 並通過日誌展示平台進行管理 引入elasticsearch 將所有微服務的資料庫需要查詢的資料同步到es中，增刪改仍然保持原有的mybatis運算元據庫 目前微服務之間的呼叫 bff呼叫基礎服務 使用的是rest請求方式，本質上還是http協議，...
微服務架構思考
二 從迭代的角度去考慮 服務拆分的缺點 1.每個服務都需要單獨的機器部署，浪費資源,增加運維負擔 2.服務拆分後會產生分布式事務 跨庫事務 跨庫分頁 3.服務較多時，服務之間的依賴關係複雜，不好治理 4.拆分後不便於排查問題，不便於debug 5.特殊業務的服務歸屬問題難以決定，當乙個介面即可以放在...