專案中遇到了乙個聚合業務，需要從多個（2個以上資料級聯）中臺服務層獲取資料，並做列表分頁。
如從使用者中心（a）獲取一部分特定使用者，再從訂單中心（b）將這些使用者對應的歷史訂單全部獲取並可根據a或b的某些屬性排序。
這樣乙個過程就需要業務層先從a拿到所有使用者id，再根據這些使用者id從b中拿到所有對應的訂單資訊。
一般的解決方案是在b中使用sql的in方式獲取到所有對應資訊，但如果b的資料量較大或a中獲取到的使用者id量較多（成百上千），那麼這個時候試想一下sql執行效率會是怎麼樣的？
同樣的另一種方式，是在業務層使用for迴圈來乙個乙個從b獲取有用資訊，但同樣的，當a的量較大時會極其消耗資源。
那是否可以將相關表做彙總，然後產生乙個快取表，包含了業務需要的資料，資料獲取和分頁就基於這個表來完成，在更新資料庫表時同時更新快取表，確保資料的一致性。看起來這是乙個較好的解決方案，但做快取表時需要注意的是不能存放過大數量的資料（又扯回到資料量的問題，看來資料量是這個業務的最大限制因素）。
那麼終極思路就到搜尋引擎這個層面了，搜尋引擎很強大，但也會產生額外的成本，是否值得使用要根據業務具體情況來衡量了。
回頭來看，對於這種複雜問題，可以優先從業務的角度去考慮是否有優化空間，然後再從技術角度來考慮解決方案，畢竟純從技術角度解決的話總會留下乙個不滿意的小尾巴。
微服務基礎架構解決方案
業務模組 服務模組 工具模組 前端後端 建立資料庫gem admin，資料庫編碼為utf 8 執行gem utlis jpa即可生成資料庫表結構 執行db gem.sql檔案，初始化表資料 在gemframe目錄下，執行mvn clean install eclipse idea開啟專案 webst...
15 26 微服務安全解決方案
restful 的通訊安全有很多中解決方案,例如 http basic auth 認證 cooke session 認證 token 認證 oauth openid 等等，每一種方案都很成熟，這裡不依依解釋，如果不了解，請去搜尋引擎查詢相關資料。這裡我談談在實施微服務專案中的心得，首先專案採用 sp...
微服務架構下互斥資源解決方案
目錄背景 業務流程漏洞 低概率出現重複新增問題 解決方案 併發轉成順序操作 互斥 延時雙校驗 延時雙校驗變體 本地 遠端雙校驗 定時刪除資料 推薦 介面專用 資源互斥 取巧方案 附錄 樂觀鎖新增 刪除示例 現狀 同一公司下2個部門都有人員服務，這2個人員服務由不同的團隊開發，資料庫不公用。需求 同乙...