hyperledger-fabric1.4

fabric v1.4版本是Fabric的第一个长期支持版本（LTS）

新特性

1. 新增Raft排序服务

Raft是一个基于etcd协议实现的崩溃容错的排序服务。Raft 遵循“leader 和 followers”模型，当一个领导者被选择的时候，它的决定会复制给所有的跟随者。Raft排序服务比起基于Kafka的排序服务更加容易启动和管理，同时，Raft的设计模式允许世界上的所有组织为去中心化的排序服务贡献自己的节点。

2. 可维护性和运营的改进

目前越来越多的fabric联盟网络被用在了生产环境中，因此fabric的可维护性和可操作性变得更加重要，因此在1.4版本中对日志记录、运行状态检查和操作指标方面都做了对应改进。所以，1.4版本也是推荐在生产环境中使用的fabric发行版本。

操作服务：新的RESTful操作服务为操作者提供了三个服务，用于监控和管理peer节点和orderer节点操作：

2.1 日志相关/logspec

/logspec端点允许操作者动态获取或者设置peer和orderer节点的日志等级，该端点就是传统的REST资源支持GET和PUT;

当操作服务接收到Get /logspec请求的时候，服务会响应一个包含当前日志说明的JSON内容：

1
{"spec":"info"}

当操作服务接收到Put /logspec请求的时候，服务将会读取请求主体作为JSON内容。该内容必须包含一个名为spec的单一属性：

1
{"spec":"chaincode=debug:info"}

如果spec被成功激活，服务将会响应 204 “No Content”。如果出错，服务响应 400 “Bad Request”和错误内容：

1
{"error":"error message"}
2.2 健康监控 /healthz

/healthz端点允许操作者和容器编排服务检查peer和orderer节点的存活和健康状态，该端点就是传统的REST资源支持GET请求。该实现主要为了与Kubernetes的存活探测模型所兼容，但可以在其它场景中使用。

当接收到一个Get /healthz请求的时候，操作服务会调用所有为该流程注册过的检查器(checker)，当所有检查器成功返回，操作服务才会响应 200 “OK” 和一个JSON主体：

1
2
3
4
{
"status": "OK",
"time": "2009-11-10T23:00:00Z"
}

如果存在一个或者多个健康检查器返回错误，则操作服务将响应 503 “Service Unavailable”和一个包含具体哪些健康检查器出错信息的JSON主体

1
2
3
4
5
6
7
8
9
10
{
"status": "Service Unavailable",
"time": "2009-11-10T23:00:00Z",
"failed_checks": [
{
"component": "docker",
"reason": "failed to connect to Docker daemon: invalid endpoint"
}
]
}

在当前版本，注册的健康检查只是针对Docker，其它健康检查会在后续版本增强。

2.3 指标 metrics

metrics端点允许操作者利用Prometheus 从peer节点和orderer节点拉取操作指标。指标也可以被推送到StatsD。

peer和orderer中的一些构件会公开一些指标来帮助观察系统的行为。使得操作者和管理员可以更好了解系统是如何随着时间推移而执行的。

Fabric提供两种公开指标的方式： 基于”Prometheus”的拉取(pull)模型和基于”StatsD”的推送(push)模型

2.3.1 Prometheus

典型的Prometheus部署通过从由检测目标公开的HTTP端点请求它们来获取指标。由于Prometheus负责请求度量指标，因此它被认为是一个拉取系统。

  • peer节点通过配置公开 /metrics端点。通过在core.yaml中的metrics部分设置metrics provider为prometheus。

    1
    2
    metrics:
      provider: prometheus

  • orderer节点通过配置公开 /metrics端点。通过在orderer.yaml中的Metrics部分设置metrics provider为prometheus。

    1
    2
    Metrics:
      Provider: prometheus
    2.3.2 StatsD

    StatsD是一个简单的统计数据聚合守护进程。指标被发送到statsd守护进程，在那里它们被收集、聚合并推送到后端以进行可视化和警报。由于该模型要求被检测的进程将指标数据发送到StatsD，因此这被认为是一个推送系统。

  • peer通过在core.yaml文件中的metrics部分将metrics provider设置为statsd,将指标发送给StatsD。statsd子部分必须配置StatsD进程的地址，使用的网络类型tcp或者udp，发送指标的频率。可以指定一个可选前缀，以帮助区分指标的来源–例如，区分来自独立peer节点的指标–这些指标将被添加到所有生成的指标中。

    1
    2
    3
    4
    5
    6
    7
    metrics:
      provider: statsd
      statsd:
        network: udp
        address: 127.0.0.1:8125
        writeInterval: 10s
        prefix: peer-0

  • orderer通过在orderer.yaml文件中的Metrics部分将metrics provider设置为statsd,将指标发送给StatsD。Statsd子部分必须配置StatsD进程的地址，使用的网络类型tcp或者udp，发送指标的频率。可以指定一个可选前缀，以帮助区分指标的来源。

    1
    2
    3
    4
    5
    6
    7
    Metrics:
        Provider: statsd
        Statsd:
          Network: udp
          Address: 127.0.0.1:8125
          WriteInterval: 30s
          Prefix: org-orderer

现有可以获取的指标以及含义可以参考指标附录

3. 私有数据加强

私有数据特性是从Fabric1.2版本开始出现的，1.4版本首次出现2个新特性：

Reconciliation(这个不知道用中文要怎么翻译，原本意思是“和解”，但放这里不太对的样子)：允许添加到私有数据集的组织成员获取他们现在有权获得的以前交易的私有数据。

客户端访问控制可以根据客户端组织集合成员资格自动在链码中强制执行访问控制，而不必编写特定的链码逻辑。

4. 节点组织单元（Node OU）支持

从v1.4.3开始，现在支持将节点OU用于admin和orderer身份分类（扩展了对client和peer的现有节点OU支持）。这些“组织单元”允许组织根据其x509证书的OU将身份进一步分类为管理员和订购者。

最后更新： 2019年11月03日 18:28

原始链接： https://silence-linhl.github.io/blog/2019/11/03/fabric-newfeature/

赏
× 请我吃糖~
打赏二维码