首先，不是所有的專案都適合微服務，微服務的開發部署和傳統的單體應用是完全兩套獨立的東西，主要表現為：
1.微服務的架構比單體應用更加複雜；
2.架構搭好後，微服務的開發比傳統的應用要簡單，每個服務的職責更加單一；
3.微服務主要依賴ci 、cd、docker、k8s等工具進行部署及運維，更加穩定可靠；
基於以上特性，你可以根據以下幾點來考慮，你的應用到底適不適合使用微服務：
1.使用者規模是不是很大；
2.開發、運維是否具備開發微服務的技術；
4.預算是否足夠，微服務至少要好幾臺服務，還需要kafka、redis等中介軟體；
微服務 關於微服務的思考
通過kafka進行日誌收集，並結合elk進行日誌聚合 並通過日誌展示平台進行管理 引入elasticsearch 將所有微服務的資料庫需要查詢的資料同步到es中，增刪改仍然保持原有的mybatis運算元據庫 目前微服務之間的呼叫 bff呼叫基礎服務 使用的是rest請求方式，本質上還是http協議，...
微服務分布式事務的一些思考
關於微服務分布式事務的一些思考，筆者沒有參與過複雜分布式事務的場景，各位大神路過可以分享一些遇到的案例，大家一起 關於分布式事務，筆者推薦的處理方法是 盡量避免 如果實在避免不了 這已經是高併發 使用者量比較多的 了 則使用 最終一致性 處理 參照cap理論base思想 如果處理了事務，但還是遇到了...
關於微服務架構的思考
最近在專案中遇到了一些問題，乙個比較多的問題服務和服務直接呼叫混亂 a服務呼叫b b服務呼叫c c服務呼叫d 導致後期公升級會出現很多問題 如果有個流程圖也許會好些 但是沒有 因此我陷入了思考，如果進行重構的話那什麼樣的架構會是較好的 我想 設計模式的六大原則 在此也一樣適用 明確的分工,服務之間優...