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：目前是用檔案+記憶體的，我們後面很快會釋出一個資料庫的。