本文介紹在應用微服務架構的過程中，對遷移場景下不一致問題的解決方案。
在大多數企業裡，新專案和老專案一般會共存，大家都在努力的去掉老專案，但是由於種種原因總是去不掉，如果要徹底的去掉老專案，就必須有非常完善的遷移方案。
在遷移過程中必須使用開關，開關一般都會基於多個維度來設計，例如：全域性的、使用者的、角色的、商戶的、產品的，等等。如果在遷移過程中遇到問題，則我們需要關閉開關，遷移回老的系統，這需要我們的新系統相容老系統的資料，老系統也相容新系統的資料。從某種意義上來講，遷移比實現新系統更加困難。
有的開關設計在應用層次，通過乙個curl語句呼叫，沒有許可權控制，這樣的開關在服務池的每個節點中都有可能是不一致的；還有的系統將開關配置在中心化的配置系統、資料庫或者快取等中，處理的每個請求都通過統一的開關來判斷是否遷移等，這樣的開關有乙個致命缺點：在服務請求的處理過程中，開關可能會有變化，各節點之間的開關可能不同步、不一致，導致重複的請求可能既走到新邏輯又走了老邏輯，如果新邏輯和老邏輯沒***冪等，則這個請求就被重複處理了，如果是金融行業的應用，則可能會導致資金損失，電商系統可能會發生法活和退款同時進行等問題。
這裡推薦使用訂單開關，不管我們在什麼維度上設計了開關，在接收到服務請求後，在請求建立的關聯實體（例如：訂單）上標記開關，對於以後的處理流程，包括同步的和非同步的處理流程，都通過訂單上的開關來判斷，而不是通過全域性的或者基於配置的開關來判斷，這樣在訂單建立時，開關已經確定，不再變更，若乙份資料不再發生變化，那麼他永遠是併發安全的，並且不會有不一致的問題。
這種模式在生產中的使用比較頻繁，建議每個企業都把這種模式作為設計評審的一項，如果不檢查這一項，則很多開發人員都會偷懶，直接在配置或者資料庫中做個開關就上線了。
微服務1之微服務設計要點
在開始轉為微服務之前，需要注意如下要點，考慮清楚再決定要不要做微服務。1 服務粒度 如何劃分各個服務之間的職責邊界。劃分過粗，則服務中包含的業務過多，時間長了之後，又會變為乙個複雜的單體應用。劃分過細，則服務增多，又會增加整體複雜性。2 通訊協議 各服務之間的通訊模式。是採用json，還是xml，還...
微服務設計思路
微服務編碼 微服務名稱 協議主機 埠訊息碼起止 錯誤碼起止 100000 使用者服務 商品目錄服務 進銷存服務 微服務編碼 微服務名稱 協議主機 埠訊息碼起止 錯誤碼起止 100000 使用者服務 使用者管理服務 登陸服務 商品目錄服務 進銷存服務 第1，2，3專案通過apidoc在jenkins部...
微服務設計原則
相比於單機服務與其他架構，微服務架構的主要特徵是元件化 松耦合 獨立 去中心化。主要表現在如下幾個方面 細粒度的服務分解 將專案中每個模組 每個職責拆分出來，專注做好一件事情。獨立部署執行和擴充套件 每個微服務又是乙個單獨的專案，獨立執行在自己的程序裡。它可以不依賴於其他服務進行單獨使用和靈活擴充套...