知識星球SOFA WEEKLY | 每週精選，篩選每週精華問答
同步開源進展，歡迎留言互動
SOFAStack（Scalable Open Financial Architecture Stack）是螞蟻金服自主研發的金融級分散式架構，包含了構建金融級雲原生架構所需的各個元件，包括微服務研發框架，RPC 框架，服務註冊中心，分散式定時任務，限流/熔斷框架，動態配置推送，分散式鏈路追蹤，Metrics 監控度量，分散式高可用訊息佇列，分散式事務框架，分散式資料庫代理層等元件，也是在金融場景裡錘煉出來的最佳實踐。
SOFA 檔案: https://www.sofastack.tech/
SOFA: https://github.com/alipay
每週讀者問答提煉
歡迎大家向公眾號留言提問或在群裡與我們互動
我們會篩選重點問題透過
” SOFA WEEKLY ” 的形式回覆
@劉洋 提問：
線上 RPC 出了問題，但是丟擲來的異常是 please check the server log，這種控制檯都不會列印日誌的，需要到服務的目錄下檢視 bolt-error.log，這個操作很不友好啊，有沒有其他解決辦法，一般根本就進不去伺服器。
A：服務端異常分幾種吧：
第一種是服務端 RPC 框架相關的例如序列化異常，這種一般客戶端能拿到一個服務端序列化異常，但具體的異常資訊只會落到服務日誌裡。
第二種是服務端業務底層異常，例如資料庫異常等，這種也不建議也不適合直接拋給客戶端。
第三種是服務端的業務資料異常，例如傳的值不對，這種可以丟擲自定義異常或者傳回值裡帶異常碼。
第一種進不去伺服器看日誌的話，是否可以搭一個輕量級的日誌收集處理，例如 ELK，從頁面上看看日誌呢？
我們現在遇到的業務場景，server log 的基本都是 node 端傳遞的引數有問題，但是不夠明顯，他們拿到之後並不知道是引數序列化異常，而我們也不確定是不是真的，只能去伺服器檢視日誌。
A：如果要把這個服務端的異常資訊帶回去，需要在 Bolt 上稍微修改具體的反序列化資訊。下個版本我們會針對這個問題進行 Bolt 升級。
@吳偉 提問：
SOFA 需要單獨部署嗎？部署大概需要多少伺服器才能夠支撐？有這塊的介紹嗎？
A：目前開源出來都是應用使用的，應用直基於 SOFA 開發，不需要單獨部署，後面註冊中心這種系統要單獨部署。
註冊中心會在 3 月 24 日釋出開源，之後會有詳細的介紹。
@天行健 提問：
如果我執行一個批處理的後臺任務，希望每次迴圈開始都能使用一個新的 traceId，應該怎麼做？
A：批處理後臺任務會用到什麼元件？SOFATracer 目前是針對元件埋點的，你的後臺批處理可以理解為新起執行緒。在這種情況下，比如你的批處理中會發起一次 RPC 呼叫，那麼直接調就可以，因為 SOFATracer 現在不支援手動埋點，所以作為發起方必須是 SOFATracer 已經實現的埋點外掛。
比如說 Elastic-Job，在批處理時，我一個任務（在一個執行緒中）可能要處理很多條資料，每條資料處理邏輯都可能會發起 RPC 呼叫，如果所有資料處理時使用的都是一個 traceId，那定位問題就會非常困難。
A：這種只能透過手動埋點來實現，SOFATracer目前不具備這個能力。
一個後臺任務處理成千上萬條資料，如果不換 traceId ，那這個 Trace 就會非常龐大。
A：這個你們可以自己來擴充套件，基於 Tracer 的 API，每次發起時自己生成新的 Span 作為一個新鏈路的發起。
每週 SOFA 進展
本週釋出詳情如下：
1、釋出 SOFATracer v2.3.4 版本，主要變更如下：
i. 修複 Root Span 作為預設取樣為 false
ii. 修複 Root Span 起始 spanId 為 0.1 問題
iii. 最佳化上報 Zipkin 時對於異常的處理
iiii. 最佳化 SpringMVC 外掛提取 SpanContext 的邏輯
iv. 移除測試用例中所有取樣引數的設定
詳細參考釋出報告：
https://github.com/alipay/sofa-tracer/releases/tag/v2.3.4
2、釋出 SOFATracer v3.0.3 版本，主要變更如下：
i. v3.0.3 版本中同步了 master 上的一些基礎能力 ，包括取樣、Zipkin 依賴升級及支援中文 UI、Zipkin 上報模型移除對 SOFARPC 的特殊處理等
ii. 修複 DataSource 埋點接入配置問題
詳細參考釋出報告：
https://github.com/alipay/sofa-tracer/releases/tag/v3.0.3
