1：微服務架構的乙個缺點是服務間介面呼叫太過頻繁。特別是在獲取乙個資料集合，每條記錄都需要去呼叫其他微服務的介面時，過多的服務間介面呼叫會導致速度慢，效能降低。
專案中遇到問題如下：
需要從乙個業務模組中獲取訂單詳情，其中還包括銷售人員的名字一起展示，但是該業務模組只有訂單資訊，訂單資訊中只有銷 售人員的id，沒有名字，這個時候如果採用微服務的介面呼叫方式，從員工模組中根據銷售人員id獲取名字的方式，會導致每條訂單記錄都需要呼叫員工模組介面，導致大量的系統間頻繁的通訊。
解決方案：
傳統的解決辦法是將訂單表擴充套件乙個銷售人員名字的字段，增加資料冗餘，修改訂單下發介面。但如果已經上線的專案後期小的優化這樣改的話存在風險。
另一種替代辦法在採用微服務的介面呼叫方式的基礎上，將每次獲取的銷售人員的id和名字都儲存到redis中，每次呼叫員工模組時都先去redis中查詢是否其已存在。這樣的話可以降低系統間的通訊，同時減少資料庫的資料冗餘。
還有一種方式就是在呼叫介面查詢時將列表資料一次性傳送請求，接收端查詢出所有列表結果資料返回，避免多次請求，減少網路通訊次數。
2：電商專案中資料庫表不推薦外來鍵關聯，但是在被關聯表中刪除資料時會導致關聯表中經常出現資料缺失的問題，但如果在刪除資料時在業務層刪除資料做關聯查詢來判斷是否被關聯使用，會導致業務層邏輯複雜，特別是被多個業務表關聯，會導致多次關聯查詢操作，後面每次增加乙個業務關聯都得增加一次判斷。
解決方案：
可以在關聯表中增加乙個被關聯次數的字段，每次關聯時都加1，每次取消關聯都減一。
3: 在使用activities 工作流過程中，無法滿足業務人員視覺化的定義流程，也無法去修改已建立好的流程。
解決方案: 可以做乙個節點任務池，將業務中用到的大部分節點任務都提前建立好，在定義流程時，將各個節點任務做串聯就可！
4: 訂單表水平切分多庫時如何儲存資料，業務方面有客戶查詢和商家查詢的需要，是通過客戶id來做hash還是通過商家id來做hash?
可以通過客戶id裡面包含商家id，對商家id做hash.
企業遇到問題ERP管理系統的解決方案
當今時代，在全球競爭激烈的大市場中，很多企業突顯出來的管理問題越來越多，而erp管理系統能不能解決這些問題，成為了企業老闆們關心的問題。而隨著中小企業的興起，企業管理過程中存在的問題也日益展現出來，這些問題不解決也將影響著企業長期問題頂的發展。今天就給大家深度解析一下erp管理系統的應用能實實在在的...
面試必問題 專案中遇到過的問題及解決方案
原因 因為chrome公升級80之後，samesite預設為lax.解決 設定samesite為none，secure secure必須設定不然無效 原因 未知 解決 方法一 先開啟頁面，設定上有cookie，這時候再跨域設定就可以。方法二 window.open url 定時關閉，通過這種方式載入...
iTVLobby專案中問題以及解決方案 2
專案中的後台是幾個 的人做的，他們給予webservice給我指定了一套請求介面。網上down了一些例子試試可以就開始做了，整體是基於ksoap2 android assembly 3.1.1 jar with dependencies.jar 來做的。整個流程是我通過webservice andr...