歡迎光臨
每天分享高質量文章

SOFA Weekly | 每週精選【4/22 – 4/26】

SOFA WEEKLY | 每週精選,篩選每週精華問答

同步開源進展,歡迎留言互動

SOFAStack(Scalable Open Financial Architecture Stack)是螞蟻金服自主研發的金融級分散式架構,包含了構建金融級雲原生架構所需的各個元件,包括微服務研發框架,RPC 框架,服務註冊中心,分散式定時任務,限流/熔斷框架,動態配置推送,分散式鏈路追蹤,Metrics 監控度量,分散式高可用訊息佇列,分散式事務框架,分散式資料庫代理層等元件,也是在金融場景裡錘煉出來的最佳實踐。

SOFA 檔案: https://www.sofastack.tech/

SOFA: https://github.com/alipay

  每周推薦閱讀   

海量資料下的註冊中心 – SOFARegistry 架構介紹文末有共建文章領取串列)

分散式事務 Seata TCC 樣式深度解析 | SOFAChannel#4 直播整理

  每週讀者問答提煉  

歡迎大家向公眾號留言提問或在群裡與我們互動

我們會篩選重點問題透過 

” SOFA WEEKLY ” 的形式回覆

 

1、關於 SOFARegistry 的討論

專案地址:

https://github.com/alipay/sofa-registry

@LV 提問:

感知和摘掉之間存在時差,時差之內客戶端快取沒有變更,如何保證的不會發生服務呼叫失敗?

A:時差是一定存在的,這個需要依靠 RPC 框架有一定的容錯能力,比如 SOFARPC 在每次呼叫前會檢查連線是否存活,還有自動故障剔除的機制,詳情可見:

https://www.sofastack.tech/sofa-rpc/docs/Fault-Tolerance

《自動故障剔除機制》一文中透過統計時間視窗內的平均異常率能解決一般性的問題,那對於突發問題來說又該怎樣應對呢?畢竟秒級的影響對重要業務來說是不能容忍的。

A:RPC 在遇到呼叫失敗時(框架層面異常或網路異常)是有重試機制的,即會重新選擇另外的服務 IP 去呼叫,這個過程對業務是透明的。比如您說的某個機器宕機的情況,RPC 的重試機制可以使它在第一時間 failover 到另外的機器。詳見《重試呼叫》:

https://www.sofastack.tech/sofa-rpc/docs/Retry-Invoke

再接著,會收到註冊中心通知移除該宕機 IP,假如因為某些原因沒有移除該IP的話,還有《自動故障剔除的機制》兜底,當然這些相對重試的 failover 來說就滯後了。

2、@閑人 提問:

SOFARPC 預設會把連結跟蹤的包包含進來,現在我們一個消費端呼叫頻率非常高,服務端會拋業務異常出來,但消費端會把業務異常當作中介軟體異常,使我們的日誌檔案極速膨脹。特別是 middleware_error.log 和 rpc-client-digest.log,請問有沒有辦法在未引入鏈路跟蹤元件的情況下,關閉鏈路的日誌?

A:配置檔案中 SofaBootRpcProperties.PREFIX + .defaultTracer=  -D引數可以參考下方連結中的配置:

https://github.com/alipay/sofa-rpc-boot-projects/issues/149

3、@徐利飛 提問:

Springcloud + SOFATracer 怎麼整合?

A:可以看下這個案例,在 Springboot 環境下也是可以的:

https://www.sofastack.tech/sofa-tracer/docs/Usage_Of_openfeign

可以不依賴 Zipkin 或 Zookeeper 嗎?

A:SOFATracer 不依賴 Zookeeper,如果不使用 Zipkin 上報,可以透過 com.alipay.sofa.tracer.zipkin.enabled=false 來關閉。

 

4、@灰太狼 提問:

請教一下,按我的理解,一條業務 SQL,在 Seata 管理下會多出前映象查詢、後映象查詢、Undolog 插入資料庫操作對嗎?

A:是的,Insert 沒有前映象,Delete 無後映象。

5、@文順 提問:

請問 TC 不需要用資料庫嗎?

A:目前是用檔案+記憶體的,我們後面很快會釋出一個資料庫的。

    已同步到看一看
    贊(0)

    分享創造快樂