成規模後的業務系統，一般都會走到微服務拆分的階段。雖然這種方式有各種弊端，但也有顯而易見的好處。
先說好處：
那凡事有好有壞，接下來說說壞處：
一般而言，我們會要求服務粗粒度化，盡量避免過於碎片化後的服務導致的複雜度攀公升問題。
在這裡，僅說說針對cp，ap的業務模型設計方案思考。
對於cp場景的定義一般如下：
多個系統必須準確的保證一致性，否則當前請求不可用（比如：拋異常，返回錯誤之類）。
使用者提交訂單後，請求會在訂單系統中進行一系列校驗後，進行後續處理，比如扣庫存。
為了保證不超賣，不少買，業務系統一般如下流程。
在這個過程中，對於客戶而言就是要求扣減庫存成功了再生成正確的訂單，兩者缺一不可。但是，業務方更關注正向流程的強一致性，逆向可以接受微小延遲。
針對這種場景的要求，會採用cp+ap模式，通過正向強一致性，逆向弱一致性來保證一致性&可用性的均衡。
運營在商品後台更新商品資訊後，一般會重新整理若干個子系統的資料。比如：商品子系統，商品快取，dns快取等。
對於資料的同步重新整理，運營會要求大部分資料能及時更新，如果不能，可以分拆成多個階段分步驟成功也行。不能接受響應乙個成功，過段時間可能成功，可能失敗這種情況。
從需求角度來看，這是乙個cp的場景。但是對這個流程分解下來後，會拆分成如下幾個部分：
這些內容中，涉及dns快取的，僅有多**資訊部分。一般的做法，是生成新的url，歷史的不再使用即可。並不需要重新整理歷史url對應的內容。
其它內容要解決的問題就是商品子系統&商品快取之間資料同步保持一致的問題。
要做到運營期望的cp系統，要解決如下問題，即：如何保證更新db後的資料能正確，及時重新整理到快取中？
一般的資料更新流程如下：
主要的問題在於更新db成功後，針對快取的操作如何保證一致性。
這類異構系統，要保證2個系統的保持一致性，有幾種方式。
無論哪種方式，會要求在提交時，涉及多系統互動部分全部成功才算成功（依賴定時器的不算）。那這種設計出發點就是cp，但是每乙個互動可能並不直接完成同步，或者存在異常情況下短暫的不一致，需要其它環節或者步驟來補充一致性。這裡考慮的就是ap，因為短暫的不一致不會導致業務出現嚴重錯誤，出於功能可用性角度，可以接受這種有損解決方案。
但是，如果真有客戶較真，比如涉及**部分的調整，正好被顧客碰上了的情況，還需要在執行環節做資料的校驗，最終以db中儲存為標準，同時給到使用者相應友好提示，降低客訴的概率。
比如閘道器協議配置管理場景下，配置的下發是否實時且一致推送到所有例項並不是最關鍵的，因為即便存在網路問題，最終也會推送到位。關鍵是在這個過程中閘道器服務必須正常可用，即便部分例項得到更新拒絕前端訪問，部分例項未得到更新前端可以正常訪問出現也無妨。可以這麼說，依賴這種變更推送機制的場景，都需要支援ap的設定，系統集群需要相容多種配置共存的情況。
業務方案設計的時候，圍繞不同的場景會經常ap，cp或者ap+cp等定義不停的變換方案。相比中介軟體而言，這種變換會非常頻繁。比如kafka，可以在不同的配置下是乙個ap系統或者乙個cp系統。不同實現機制抽象到理論層面一直在cap範疇中打轉，區別大部分僅僅在於乙個ap設計方案下，接近cp的過程區別。
微服務你必須知道的CAP理論
簡介 講解分布式應用核心cap知識 cap理論就是說在分布式儲存系統中，最多只能實現上面的兩點。而由於當前的網路硬體肯定會出現延遲丟包等問題，所以分割槽容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡 ca 如果不要求p 不允許分割槽 則c 強一致性 和a 可用性 是可以保證的。...
微服務架構中的業務邏輯設計
前言 企業應用程式的核心是業務邏輯，業務邏輯實現了業務規則。但是由於業務邏輯分散在多個服務上，因此在微服務架構中開發複雜的業務邏輯更具有挑戰性。我們需要解決兩個問題 首先，典型的領域模型是由各種類交織在一起的乙個網路。雖然這在單體應用程式中不是問題，但是在微服務架構中，類分散在不同的服務中，就需要跨...
微服務系統中的認證策略
在傳統的單體架構中，單個服務儲存所有的使用者資料，可以校驗使用者，並在認證成功後建立http會話。在微服務架構中，使用者是在和服務集合互動，每個服務都有可能需要知道請求的使用者是誰。一種樸素的解決方案是在微服務系統中應用與單體系統中相同的模式，但是問題就在於如何讓所有的服務訪問使用者的資料。解決這個...