寫在前面

fabric 終于在1月10日發(fā)布了 v1.4.0 版本（1月9日 github 上版本庫已經(jīng)有了 v1.4.0 的標(biāo)簽了，1月10日收到官宣郵件）。

其實(shí)在1個多月內(nèi)，1.4.0 已經(jīng)發(fā)布了兩個候選版本，新功能基本都有了，但是因?yàn)橐恢泵Γ╨an），所以沒怎么看。這次終于等到 1.4 正式版的發(fā)布，趕緊看看都有什么新東西。

本文主要是對官方文檔 what's new in v1.4 和 v1.4.0 Release Notes 的翻譯。由于水平有限，本文不做一對一的中英對照翻譯，主要結(jié)合本人的'還湊合'英文水平進(jìn)行意譯--即我看著像什么意思就翻譯成什么。如果讀者遇到有疑義的地方，請翻閱原文。

新特性（翻譯）

fabric 的首個長期支持版本

超級賬本 fabric 項(xiàng)目自從 1.0 發(fā)布以來已經(jīng)同社區(qū)的運(yùn)營者一道逐漸成熟起來。fabric 的開發(fā)者一直在和網(wǎng)絡(luò)運(yùn)維人員一起合作，將 v1.4 的重心放在了穩(wěn)定性和生產(chǎn)運(yùn)維上面。因此，v1.4 將會是我們的第一個長期支持版本。

我們一直以來的策略就是只對最近發(fā)布的主版本和次要版本提供缺陷修復(fù)。我們計(jì)劃多后續(xù)版本也采用同樣的支持策略。但是，對于超級賬本 fabric 的 v1.4 版本，fabric 的維護(hù)者們承諾會提供自發(fā)布之日起為期一年的缺陷修復(fù)支持。這就是說后面會有一系列的針對 v1.4 的補(bǔ)丁版本（v1.4.1,v1.4.2,...）,每個補(bǔ)丁版本會包含很對修復(fù)。

如果你正在跑的是 fabric 的 v1.4 版本，那么你可以放心你能夠很安全的升級到后續(xù)任何一個補(bǔ)丁版本。如果出現(xiàn)需要通過升級操作來修復(fù)某些缺陷的情況，我們會通過補(bǔ)丁版本來提供這種升級操作。

可維護(hù)性和操作的改進(jìn)

隨著越來越多的超級賬本 fabric 網(wǎng)絡(luò)部署起來并進(jìn)入生產(chǎn)階段，可維護(hù)性和可操作性方面的要求是非常重要的。fabric v1.4 版本在日志改進(jìn)、健康檢查和運(yùn)行指標(biāo)方面有了一個巨大的提升。因此 fabric v1.4 版本是推薦的生產(chǎn)應(yīng)用版本。

• 運(yùn)維服務(wù)：新的 RESTful 運(yùn)維服務(wù)為運(yùn)維人員提供了3個服務(wù)來監(jiān)控和管理 peer 和 orderer 節(jié)點(diǎn)。
  • 關(guān)于日志的/logspec端點(diǎn)允許運(yùn)維人員動態(tài)的為 peer 和 orderer 節(jié)點(diǎn)設(shè)置或獲取日志級別。
  • /healthz端點(diǎn)允許運(yùn)維人員或者容器編排服務(wù)能夠檢查 peer 和 orderer 的 活躍度和健康情況。
  • /metrics端點(diǎn)允許運(yùn)維人員利用Prometheus來從 peer 和 orderer 節(jié)點(diǎn)獲取運(yùn)行指標(biāo)。運(yùn)行指標(biāo)也可以發(fā)布到StatsD

應(yīng)用開發(fā)的編程模型改進(jìn)

編寫分布式應(yīng)用變得越來越簡單了。Node.js SDK 和 Node.js 智能合約在編程模型上的改進(jìn)使得分布式應(yīng)用的開發(fā)變得更直觀，這讓你你只需要關(guān)注自己的業(yè)務(wù)邏輯。已發(fā)布的 npm 包仍然可以使用，于此同時新的 npm 包提供了一個抽象層來幫助提高開發(fā)者的效率并且使用起來更容易。

v1.4.0 發(fā)布說明（release note）

• Fabric 運(yùn)維服務(wù)

peer 和 orderer上提供了一個新的基于operations的 HTTP 服務(wù)端點(diǎn)。這個端點(diǎn)暴露的API可以用來進(jìn)行服務(wù)的健康檢查、查詢或修改日志級別，如果被配置了也可以暴露運(yùn)行指標(biāo)。

• FAB-3388 - fabric 組件的運(yùn)行指標(biāo)

peer 和 orderer 服務(wù)已經(jīng)具備監(jiān)測功能用于提供基本的運(yùn)行指標(biāo)。這些指標(biāo)可以用Prometheus 或者 StatsD 消費(fèi)后進(jìn)行展示。

• FAB-10851 - 健康檢查端點(diǎn)

orderer 和 peer 提供了一種通過 HTTP 請求來進(jìn)行健康檢查的機(jī)制。在運(yùn)維節(jié)點(diǎn)上執(zhí)行對GET /healthz請求，如果服務(wù)正常，會返回一個狀態(tài)200。如果健康檢查失敗，服務(wù)端壺返回狀態(tài)503 - 服務(wù)不可用，以及一段 JSON 數(shù)據(jù)來說明那個組件檢查出了問題。被執(zhí)行的健康檢查類型會隨著時間不斷擴(kuò)展。

• FAB-12265 - 動態(tài)日志級別

orderer 和 peer 提供了一種對活動的日志規(guī)范進(jìn)行獲取或更新的機(jī)制。在運(yùn)維節(jié)點(diǎn)上執(zhí)行GET /logspec請求會返回一個包含活動日志規(guī)范的 JSON 數(shù)據(jù)。當(dāng)一段形如{"spec":"the-log-spec"}的 JSON 數(shù)據(jù)被通過PUT /logspec請求發(fā)送后，活動的日志規(guī)范會被更新。

• FAB-12357 - 日志相關(guān)更新

在早期的 fabric 版本中，logger 都是和命名的組件關(guān)聯(lián)在一起，配置會控制每個logger的活動級別。但是這個模型只是理論上可行，受 fabric 使用的配置管理庫和 fabric 的基礎(chǔ)代碼框架所限，這個模型在實(shí)際應(yīng)用中會有很多問題。
在 1.4 版本中，我們稍稍改動了下這個模型。跟以前將logger關(guān)聯(lián)到命名組件不同，我們直接對logger進(jìn)行命名，并幫助減少初始化過程中的副作用，日志相關(guān)的配置也不再從 fabric 系統(tǒng)配置中獲取，而是從包含日志規(guī)范和日志格式的環(huán)境變量中獲取。
日志規(guī)范是一個由分號分隔的多個token組成的單個字符串。每個token定義了一個或多個logger的名稱前綴（逗號分隔）和可選的日志級別。當(dāng)logger名稱前綴以句號結(jié)尾，這表明這個日志級別應(yīng)該只被應(yīng)用到有那個準(zhǔn)確名稱的logger上，不包含后面的句號。當(dāng)日志名稱部分省略的時候，這表示默認(rèn)日志級別。如果多項(xiàng)引用了同樣的名稱或者提供了多個默認(rèn)實(shí)例，最后一個規(guī)范擁有優(yōu)先權(quán)。
（示例：logger.a,logger.b=info:logger.c=WARN:DEBUG）

• FAB-12363 - gRPC 交互相關(guān)日志

orderer 和 peer 現(xiàn)在提供對 gRPC 交互的日志（INFO 級別）記錄

• FAB-12372 - 非中斷情況下獲取 goroutine 棧信息

當(dāng) peer 或者 orderer 收到SIGUSR1信號后，所有 goroutine 的狀態(tài)會被采集并用 INFO 級別日志記錄。此收集過程不會中斷進(jìn)程。

• FAB-5093 - 私有數(shù)據(jù)取回

允許那些已加入私有數(shù)據(jù)集的組織的 peer 節(jié)點(diǎn)能夠在有資格時獲取先前交易所屬的私有數(shù)據(jù)。這個功能只支持那些在 v1.4 之后加入通道的 peer 節(jié)點(diǎn)。

• FAB-11409 - 私有數(shù)據(jù)客戶端訪問控制

基于客戶端的組織成員身份在 chaincode 層面自動執(zhí)行訪問控制的能力，不需要額外編寫特殊的 chaincode 邏輯。這個特性通過私有數(shù)據(jù)集配置的屬性memberOnlyRead:true來配置。如果你有一個混合了 v1.4 版本的peer節(jié)點(diǎn)和之前發(fā)布版本的 peer 節(jié)點(diǎn)的網(wǎng)絡(luò)，之前發(fā)布版本的 peer 節(jié)點(diǎn)不會對這個配置生效，直到它升級到 v1.4 為止。

總結(jié)

• 這是一個LTS (Long Term Support，長期支持) 版本（Long=1年，捂臉.jpg)
• 這是一個生產(chǎn)應(yīng)用推薦的版本
• 新增的特性主要圍繞運(yùn)維相關(guān)，監(jiān)控管理等
• 核心功能并沒有大的變化，從1.3的升級應(yīng)該比較平滑
• 并沒有新的共識算法支持