fabric v1.4 新特性

写在前面

fabric 终于在1月10日发布了 v1.4.0 版本（1月9日 github 上版本库已经有了 v1.4.0 的标签了，1月10日收到官宣邮件）。

其实在1个多月内，1.4.0 已经发布了两个候选版本，新功能基本都有了，但是因为一直忙（lan），所以没怎么看。这次终于等到 1.4 正式版的发布，赶紧看看都有什么新东西。

本文主要是对官方文档 what's new in v1.4 和 v1.4.0 Release Notes 的翻译。由于水平有限，本文不做一对一的中英对照翻译，主要结合本人的'还凑合'英文水平进行意译--即我看着像什么意思就翻译成什么。如果读者遇到有疑义的地方，请翻阅原文。

新特性（翻译）

fabric 的首个长期支持版本

超级账本 fabric 项目自从 1.0 发布以来已经同社区的运营者一道逐渐成熟起来。fabric 的开发者一直在和网络运维人员一起合作，将 v1.4 的重心放在了稳定性和生产运维上面。因此，v1.4 将会是我们的第一个长期支持版本。

我们一直以来的策略就是只对最近发布的主版本和次要版本提供缺陷修复。我们计划多后续版本也采用同样的支持策略。但是，对于超级账本 fabric 的 v1.4 版本，fabric 的维护者们承诺会提供自发布之日起为期一年的缺陷修复支持。这就是说后面会有一系列的针对 v1.4 的补丁版本（v1.4.1,v1.4.2,...）,每个补丁版本会包含很对修复。

如果你正在跑的是 fabric 的 v1.4 版本，那么你可以放心你能够很安全的升级到后续任何一个补丁版本。如果出现需要通过升级操作来修复某些缺陷的情况，我们会通过补丁版本来提供这种升级操作。

可维护性和操作的改进

随着越来越多的超级账本 fabric 网络部署起来并进入生产阶段，可维护性和可操作性方面的要求是非常重要的。fabric v1.4 版本在日志改进、健康检查和运行指标方面有了一个巨大的提升。因此 fabric v1.4 版本是推荐的生产应用版本。

• 运维服务：新的 RESTful 运维服务为运维人员提供了3个服务来监控和管理 peer 和 orderer 节点。
  • 关于日志的/logspec端点允许运维人员动态的为 peer 和 orderer 节点设置或获取日志级别。
  • /healthz端点允许运维人员或者容器编排服务能够检查 peer 和 orderer 的 活跃度和健康情况。
  • /metrics端点允许运维人员利用Prometheus来从 peer 和 orderer 节点获取运行指标。运行指标也可以发布到StatsD

应用开发的编程模型改进

编写分布式应用变得越来越简单了。Node.js SDK 和 Node.js 智能合约在编程模型上的改进使得分布式应用的开发变得更直观，这让你你只需要关注自己的业务逻辑。已发布的 npm 包仍然可以使用，于此同时新的 npm 包提供了一个抽象层来帮助提高开发者的效率并且使用起来更容易。

v1.4.0 发布说明（release note）

• Fabric 运维服务

peer 和 orderer上提供了一个新的基于operations的 HTTP 服务端点。这个端点暴露的API可以用来进行服务的健康检查、查询或修改日志级别，如果被配置了也可以暴露运行指标。

• FAB-3388 - fabric 组件的运行指标

peer 和 orderer 服务已经具备监测功能用于提供基本的运行指标。这些指标可以用Prometheus 或者 StatsD 消费后进行展示。

• FAB-10851 - 健康检查端点

orderer 和 peer 提供了一种通过 HTTP 请求来进行健康检查的机制。在运维节点上执行对GET /healthz请求，如果服务正常，会返回一个状态200。如果健康检查失败，服务端壶返回状态503 - 服务不可用，以及一段 JSON 数据来说明那个组件检查出了问题。被执行的健康检查类型会随着时间不断扩展。

• FAB-12265 - 动态日志级别

orderer 和 peer 提供了一种对活动的日志规范进行获取或更新的机制。在运维节点上执行GET /logspec请求会返回一个包含活动日志规范的 JSON 数据。当一段形如{"spec":"the-log-spec"}的 JSON 数据被通过PUT /logspec请求发送后，活动的日志规范会被更新。

• FAB-12357 - 日志相关更新

在早期的 fabric 版本中，logger 都是和命名的组件关联在一起，配置会控制每个logger的活动级别。但是这个模型只是理论上可行，受 fabric 使用的配置管理库和 fabric 的基础代码框架所限，这个模型在实际应用中会有很多问题。
在 1.4 版本中，我们稍稍改动了下这个模型。跟以前将logger关联到命名组件不同，我们直接对logger进行命名，并帮助减少初始化过程中的副作用，日志相关的配置也不再从 fabric 系统配置中获取，而是从包含日志规范和日志格式的环境变量中获取。
日志规范是一个由分号分隔的多个token组成的单个字符串。每个token定义了一个或多个logger的名称前缀（逗号分隔）和可选的日志级别。当logger名称前缀以句号结尾，这表明这个日志级别应该只被应用到有那个准确名称的logger上，不包含后面的句号。当日志名称部分省略的时候，这表示默认日志级别。如果多项引用了同样的名称或者提供了多个默认实例，最后一个规范拥有优先权。
（示例：logger.a,logger.b=info:logger.c=WARN:DEBUG）

• FAB-12363 - gRPC 交互相关日志

orderer 和 peer 现在提供对 gRPC 交互的日志（INFO 级别）记录

• FAB-12372 - 非中断情况下获取 goroutine 栈信息

当 peer 或者 orderer 收到SIGUSR1信号后，所有 goroutine 的状态会被采集并用 INFO 级别日志记录。此收集过程不会中断进程。

• FAB-5093 - 私有数据取回

允许那些已加入私有数据集的组织的 peer 节点能够在有资格时获取先前交易所属的私有数据。这个功能只支持那些在 v1.4 之后加入通道的 peer 节点。

• FAB-11409 - 私有数据客户端访问控制

基于客户端的组织成员身份在 chaincode 层面自动执行访问控制的能力，不需要额外编写特殊的 chaincode 逻辑。这个特性通过私有数据集配置的属性memberOnlyRead:true来配置。如果你有一个混合了 v1.4 版本的peer节点和之前发布版本的 peer 节点的网络，之前发布版本的 peer 节点不会对这个配置生效，直到它升级到 v1.4 为止。

总结

• 这是一个LTS (Long Term Support，长期支持) 版本（Long=1年，捂脸.jpg)
• 这是一个生产应用推荐的版本
• 新增的特性主要围绕运维相关，监控管理等
• 核心功能并没有大的变化，从1.3的升级应该比较平滑
• 并没有新的共识算法支持