Microservice transaction - The first sight

Transaction across Microservices

  1. 盡可能避免 transactions 在多個 microservices
  2. Two-phase commit protocol 兩階段提交協議，用於跨不同software components (databases, message queues...)的transaction
    • Architecture of 2PC
      • transaction coordinator 調節器包含兩個部分
        • 準備階段 prepare phrase
        • Commit and rollback phrase
      • 會拖垮操作service的速度，例如 A -> B , A 先設定成prepare，等待 Ｂ執行結束返回，A才update成 commit/rollback
    • XA standard (Open XA, (XA stands for extended Architecture) based on 2PC, 目標是保證執行在全域性transaction的原子性. 定義global transaction manager 以及special application，做交易都須透過此library，讓transaction manager track每筆交易。XA maintain logs 去決定是否要commit/rollback)
      • 優點是cross service transaction 可以使用各自的技術去實作，包含各自有各自的database
      • 缺點就會在transaction manager  有 bottle neck on 處理大量請求，必須保持service always alive
    • Rest-AT Standard  Draft
      • Standard 允許 application server as a transaction coordinator, 用rest API建立分散式 transaction
      • 最終還是要要部署到local 或個環境、編寫橋接服務的邏輯
  3. Eventual Consistency and Compensation (最終一致性跟補償)
    此模型不強制跨維服務執行分散式的ACID行為，而是運用些機制：狀態、flag、batch process來確保系統在未來的某個時間點資料最終一致性。
    • 在眾多可行性分析中眾多可行性分析中能夠達到跨microservices是eventual consistency最終一致性
      假設有以下服務：
      • user microservice 用於註冊使用者
      • validation microservice 用於 backgrand check
      • message platform 處理資料持久層
    • 快樂案例
      • 當註冊使用者，就會在先建立使用者在資料庫並給個flag 等待validation
      • 傳送註冊成功訊息但提醒使用者尚未驗證完畢。
      • validation 成功則 unblock user, 否則block user
      • 結論：雖然沒能及時同步，但至少最終是一致的
    • 失敗案例
      • 假設validation掛掉，message platform 保留待驗證的user請求，等上線後再次call validation
      • 假設 message platform 掛掉，也可用batch-process去把該需被處理的資料挑出並在修復後再送一次

Microservice Design Pattern

為了保持service的彈性，來面對非預期性的硬體、網路、service performance，等問題，並且有能力從failure中recover來保持service運作，實踐pattern能預防一連串的錯誤。

Timeout pattern:

最簡單的模型，利用設定timeout設定讓request處理有問題或效能過慢的服務直接回傳失敗結果。但缺點就是在down stream service掛掉後，接下來的每個request都需要等待到timeout才會回response。

Retry pattern:

完整的microservice架構都是HA, 若down stream service response很慢超過timeout，可以藉由retry機制再次訪問service, 確保連線到其他正常的instance進而讓整個e2e process順利進行。但缺點就在retry也是會增加overall response time.

Bulkhead Pattern:

Bulkhead字面上的意思就是船艙的隔間，預防一個艙隔破了就導致船底都進水。運用Bulkhead pattern, 安排資源給特定component來讓application不至於資源耗盡，若超過上限，則觸發callbackMethod做處理。

circuit breaker pattern:

當down stream service出現問題，並回應callback method/default value時，表示不能再對下游service打入更多的request，則會根據臨界值（如預設request的一半）去控制打開阻斷器，並返回call back method的內容。

Rate limit pattern:

Rate limit 在控制突發大量throughput，藉由設定concurrent上限以及不同request queuing演算法，可以防止資源受到惡意攻擊造成停擺。 可參考 Rate limiting with NGINX - The first sight 這篇介紹。


references:

留言

張貼留言

這個網誌中的熱門文章

[專案] 銀行端末系統

由不同專案中可以了解不同領域的些許瑣事 台灣有許多銀行，在端末terminal system的架構幾乎差不多。而所謂的櫃員、櫃姊也就是在各櫃檯負責做交易的人員。 (台灣其實可以不必這麼多銀行，這情況並沒有因為競爭而讓使用者受惠，這跟台灣不必這麼多大學一樣，但這就是另外一些故事了..) 會叫做端末系統，是因為古早能下指令command line畫面稱為terminal終端機，操作方式如PTT。 櫃源系統就如機場的系統、醫院的病例系統長年已存在，幾乎是由組合語言、C、COBOL之纇的語言撰寫，再傳遞資訊的方式是以一大量的字串，統稱"電文"的方式傳遞、接收訊息。不同銀行接收資訊的雙方(中心與櫃員)的格式各有不同，以這種方式來傳遞資訊安全、快速且又不容易被外部擷取。(相對於現在網頁之間傳遞訊息，訂立相同的header與該傳到畫面的內容body，讓 不同瀏覽器皆能解析 ) 櫃員在每個櫃台都有一定量的現金來提供顧客臨櫃提款，若是櫃員金額不足，則需要向主管申請提領金額到櫃台。 主管授權分為近端與遠端，近端為自己就可敲入主管櫃員帳號密碼，遠端則是會發送訊息到主管櫃元的電腦中請他做核准。 銀行印表機有不同的形式： 存摺印表機：列印存摺，最大能放得下A4大小的紙 匯兌印表機：大型印表機，能印寬版紙。可放入連續報表紙列印 快速印表機：機型如洗衣機，印表機底下有大櫃子能夠放連續報表紙 ‧‧‧ 銀行代碼共七碼，前三碼為銀行碼，接續三碼為分行碼，最後一碼為檢查碼 代碼查詢  http://www.trdo.gov.tw/mtn201/mtn201.asp 附註： 系統環境：iBranch SDK (包含電文、畫面、列印報表格式、程式邏輯) 遇到困難：無技術上困難 (It's long time to go, coming soon)
閱讀完整內容

如何在MacOS 中自由切換不同Python版本 - pyenv + virtualenv

  https://stackoverflow.com/questions/48470540/how-to-work-with-pyenv-virtualenv-and-pipenv 假設要不同資料夾、不同專案設定不同的python版本，可以由以下兩中方式達成 pyenv + virtualenv pyenv + pipenv 此篇介紹第一種方式pyenv 與virtualenv的組合，相對簡單明瞭。 mac os terminal操作步驟 更新pip sudo pip3 install --upgrade pip 用homebrew安裝pyenv-virtualenv (會一併的安裝這兩者與他們的dependency) brew install pyenv-virtualenv  安裝指定版本於本機，在此用python 3.7.7為例 pyenv install 3.7.7 以 python 3.7.7為版本，建立一個名為 venv377的虛擬環境 pyenv virtualenv 3.7.7 venv377 切換到專案的資料夾下 cd project_101 將預設的python版本使用venv377這個環境 pyenv local venv377 ＊pyenv 有三種scope: global, local, shell，顧名思義就是修改系統python、當前目錄python、以及目前登入terminal的shell ＊＊ 若是遇到Failed to activate virtualenv，是因為啟動shell時沒有加上pyenv, virtualenv 的init，please check "add script in .zshrc" 所以說，有兩個方法可以切換python版本 在virtualenv去指定某個版本 就要在該目錄下第6步 - pyenv local project_py377 這樣就會在該目錄下生成 .python-version 裡面就會寫用什麼環境的python e.g.: venv377 在任何folder下指定某個版本 就直接下 pyenv activate venv377, 即可用python3.7.7 source deactivate就能脫逃 add script in .zshrc $ echo '
閱讀完整內容

用 C# 控制 Win7 輸入法

圖片
參考網址 - VISTA 與輸入法程式介面 文/黃忠成 http://www.dotblogs.com.tw/code6421/archive/2010/09/27/17909.aspx (感謝上述作者提供此方便的程式，範例可從網站中下載) 由於舊的win32應用程式和.NET FRAMEWORK 2.0有些無法在VISTA以後的作業系統順利執行。控制win7作業系統輸入法亦然，但利用上述參考網址的範例在Visual Studio 2012 Desktop中開啟並執行後，會發生程式直接關閉的情形。輸出訊息最後一行如下所示： '[2672] VistaIMEHelperNet.vshost.exe: Managed (v4.0.30319)' 程式以返回碼 0 (0x0) 結束。 造成此問題是TSFWrapper.cs程式在做記憶體釋放使用到的函式 Marshal.FreeCoTaskMem(ptr) 有問題，詳細原因等待日後深入研究。目前把方法改用Marshal.FreeBSTR(ptr)的方式，即可在Win7 中執行。(後來發現是範例程式雖然是寫FreeCoTaskMem，但網址中的程式碼是寫FreeBSTR) 點擊第一個按鈕"Fetch Input Profile List"後列出所有安裝的輸入法，但只限中文輸入法。若安裝多國不同語言的輸入法，在Form1.cs中 button1_Click函式裡TSFWrapper.GetInputMethodList(langIDs[0])的langIDs可用其他值帶入，langIDs = TSFWrapper.GetLangIDs()可取得所有語言的ID。 例如：langID中文 = 1028;英文 = 1033;日文 = 1041 點選按鈕一列出所有安裝的輸入法 點擊第二項與第三項按鈕分別可切換輸入法與設定回預設英文輸入法。 不過將此做法用於非GUI的方式，也就是非windows form的方式，而是純console介面來呼叫第二與第三個按鈕function會出現crash。以下為跳出錯誤訊息視窗的內容： 類型 'System.Runtime.InteropServices.COMException' 的未處理例外狀況
閱讀完整內容