Telemetry，客户端监测工具，用于搜集 node 的运行信息，发送到远端的 Prometheus 服务器。

　　Substrate 是一个通用开发框架。它为不同层次的开发者提供了三种开发风格。

　　一：直接使用 Substrate 自带的 node 起链。对于想快速起链，体验效果的开发者，可以直接使用 Substrate 预置的 node 的实现。只需要修改一个 JSON 配置文件，就可以跑起来，具体可定制以下内容：

• 　　创始区块的状态信息

• 　　账户 Account

• 　　余额 Balance

• 　　Staking 比例等

　　二：Runtime FRAME pallets 的开发。这种开发模式通过写 Runtime 中的 pallet 代码，将业务逻辑实现到 pallet 中。然后将自定义的 pallets 和其依赖的 Substrate 自带的 pallets 一起编译成 wasm 字节码运行，这是大部分 Substrate 开发者的选择。

　　三：基于 Substrate Core 深度定制。Substrate 已实现成分散的组件，做了充分的抽象和解耦。对于一些高级开发者，在某些特定的场景下，可以完全从底层重新组合这些组件，实现深度的 node 的定制。比如，可以做到：

• 　　使用不同的密码曲线和哈希算法

• 　　使用不同的序列化方法

• 　　替换不同的共识算法

• 　　完全去除 FRAME 层代码，使用另一种语言编写业务，只要能保证编译到 wasm 且遵循 Substrate 的规范即可

• 　　等等

　　下图展示了三个层次的开发难度和技术灵活性之间的关系。

　　直接使用 Substrate Node 最简单，但是最不灵活。基于 Substrate Core 开发最灵活，但是最难。进行 FRAME pallets 开发处于中间位置。也是大部分 Substrate 开发者应该采用的方式。

　　Substrate 的设计有很多优秀之处，我们来了解一下。

　　由于 Substrate 的 Runtime 代码编译为 wasm 运行，然后 wasm 字节码本身作为交易的数据直接提交到链上，再藉由链本身的 p2p 网络全网传播，实现业务逻辑的更新。每个节点在收到更新版本的 wasm 字节码后，将其更新到代码段，在某个块之后就使用新版本的 wasm 来执行逻辑。

　　有了这种热更新代码机制，业务代码的升级不再会引起分叉（软分叉或硬分叉）了，也就是说，不会因为是技术客观的原因，导致网络的分叉（人为主动分叉还是可以的）。

　　需要注意的是，这种升级仅限于 wasm 字节码能覆盖的部分——也即 Runtime 中的代码——的升级。如果改动了 node 代码本身（即 Runtime 外的部分），仍然需要通知所有节点进行手动或devops 替换。 (责任编辑：admin)