Twitter 的 snowflake 在分布式生成唯一 UUID 应用还是蛮广泛的，基于 snowflake 的一些变种的算法网上也有不少。使用 snowflake 生成 UUID 很多都是在分布式场景下使用，我看了下网上有其中有几篇 PHP 实现的都没有考虑到线程安全。现在 PHP 有了 Swoole 的锁和协程的加持，对于我们开发线程安全和高并发模拟还是很方便的，这里用 PHP 结合 Swoole 来学习下实现最简单的 snowflake（好久没写 PHP，感觉没有 IDE 真写不了 PHP 了）。 先来看以下 snowflake 的结构： 生成的数值是 64 位，分成 4 个部分： 第一个 bit 为符号位，最高位为 0 表示正数 第二部分 41 个 bit 用于记录生成 ID 时候的时间戳，单位为毫秒，所以该部分表示的数值范围为 2^41 - 1（69 年），它是相对于某一时间的偏移量 第三部分的 10 个 bit 表示工作节点的 ID，表示数值范围为 2^10 - 1，相当于支持 1024 个节点 第四部分 12 个 bit 表示每个工作节点没毫秒生成的循环自增 id，最多可以生成 2^12 -1 个 id，超出归零等待下一毫秒重新自增 先贴下代码:

在 gRPC 作为服务间通信的过程中为了数据安全我们一般要进行安全认证，比如 HTTP Restful Api 经常需要做接口之间调用的认证，我们来看下 gRPC 的认证方式。 安全证书认证 gRPC 建立于 HTTP/2 所以对 TLS 支持，我们可以使用服务端客户端双向证书验证通信来提供安全可靠的 gRPC。这里假如我们已经生成好了服务端和客户端的证书和私钥文件，并已经通过根证书做了签名。 我们先来看下服务端大概代码 server.go: package main import ( ...... ) ...... func main() { certificate, err := tls.LoadX509KeyPair("server.crt", "server.key") if err != nil { log.Fatal(err) } certPool := x509.NewCertPool() ca, err := ioutil.ReadFile("ca.crt") if err != nil { log.Fatal(err) } if ok := certPool.AppendCertsFromPEM(ca); !ok { log.Fatal("failed to append certs") } creds := credentials.NewTLS(&tls.Config{ Certificates: []tls.

在公司要做一个技术分享，同事里面没有人会 Flutter 开发的，所以我只能讲点基础的装逼一下，把 PPT 贴出来凑一篇博客吧。。。 转载请注明： 转载自Ryan 是菜鸟 | LNMP 技术栈笔记 如果觉得本篇文章对您十分有益，何不 打赏一下 本文链接地址: Flutter 快速开发移动端跨平台 APP 本作品采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。

之前做后端开发的时候，不管是什么语言或者框架，都习惯根据不同环境加载不同的开发配置，比如本地开发的时候，加载 local.env 配置,部署开发环境的时候加载 develop.env 配置，通常通过一个环境变量来决定加载相应的配置。最近在开发一款 Flutter App，我也希望 App 在不同的环境中加载不同的配置文件，实现的方式如下，如有不妥还请指出。 首先在lib建立多个main.dart，比如main_local.dart表示本地开发运行时执行的入口文件，main_develop.dart和main.dart分别表示开发环境和生产环境: lib/ ├── api/ ├── main.dart ├── main_develop.dart ├── main_local.dart ├── models/ ├── pages/ ├── utils/ └── widgets/ 这样如果我们运行在本地开发，那么执行 flutter run -t lib/main_local.dart 那么如何在执行本地开发环境的时候来调用本地开发的配置呢？其实很简单，我来定义配置文件，比如utils/config.dart enum Env { PROD, DEV, LOCAL, } class Config { static Env env; static String get apiHost { switch (env) { case Env.PROD: return "http://yuanxuxu.com"; case Env.DEV: return "http://develop.yuanxuxu.com"; case Env.LOCAL: default: return "http://local.yuanxuxu.com"; } } } 其中Env就是一个环境变量，比如我们要获取 api 请求的地址，那么根据环境变量来获取不同的请求地址，接下来我们只要在运行的入口函数 main 中定义我们当前运行的环境变量，在main_local.

MPT(Merkle Patricia Tries)是以太坊中存储区块数据的核心数据结构，它是 Merkle Tree 和 Patricia Tree 融合一个树形结构，理解 MPT 结构对之后学习以太坊区块 header 以及智能合约状态存储结构的模块源码很有帮助。 首先来看下 Merkle 树： 它的叶子是数据块的 hash，从图中可以看出非叶子节点是其子节点串联字符串的 hash，底层数据的任何变动都会影响父节点，这棵树的 Merkle Root 代表对底层所有数据的“摘要”。 这样的树有一个很大的好处，比如我们把交易信息写入这样的树形结构，当需要证明一个交易是否存在这颗树中的时候，就不需要重新计算所有交易的 hash 值。比如证明图中 Hash 1-1，我们可以借助 Hash 1-0 重新计算出 Hash 1，然后再借助 Hash 0 重新计算出 Top Hash，这样就可以根据算出来的 Top Hash 和原来的 Top Hash 是否一样，如果一样的话那么 Hash 1-1 就属于这棵树。 所以想象一下，我们将这个 Top Hash 储存在区块头中，那么有了区块头就可以对区块信息进行验证了。同时 Hash 计算的过程可以十分快速，预处理可以在短时间内完成。利用 Merkle 树结构能带来巨大的比较性能提升。 再来看下 Patricia 树: 从它的名字压缩前缀树再结合上图就可以猜出来 Patricia 树的特点了，这种树形结构比将每一个字符作为一个节点的普通 trie 树形结构，它的键值可以使用多个字符，降低了树的高度，也节省了空间，再看个例子： 图中可以很容易看出数中所存储的键值对： 6c0a5c71ec20bq3w => 5 6c0a5c71ec20CX7j => 27 6c0a5c71781a1FXq => 18 6c0a5c71781a9Dog => 64 6c0a8f743b95zUfe => 30 6c0a8f743b95jx5R => 2 6c0a8f740d16y03G => 43 6c0a8f740d16vcc1 => 48 以太坊中的 MPT： 在以太坊中 MPT 的节点的规格主要有一下几个:

RLP(Recursive Length Prefix)，递归长度前缀编码，它是以太坊序列化所采用的序列化和反序列化的主要方式。区块、交易等数据结构在 网络传输和持久化时会先经过 RLP 编码后再存储到数据库中。rlp 适用于任意的二进制数据数组的编码，在以太坊中，rpl 接受的数据分为两类：1.字节数组 2.类 list 数据结构。 以太坊中 rlp 的具体定义和规则我们可以在黄皮书中找到（Appendix B. Recursive Length Prefix）： 序列化定义 * O 所有byte的集合 * B 所有可能字节数组 * L 不只单一节点的树形结构（比如结构体或者树节点分支节点，非叶子节点） * T 所有字节数组的树形结构组合 序列化处理 通过两个子函数定义 RLP 分别处理上面说的两种数据类型 Rb(x)字节数组序列化处理规则 如果字节数组只包含一个字节（对于 [0x00, 0x7f] 范围内的单个字节），而且这个字节的大小小于 128，那么不对数据进行处理，处理结果就是原数据，比如:a 的编码是 97。 如果字节数组的长度小于 56，那么处理结果就等于在原始数据前面加上（128+字节数据的长度)的前缀,比如 abc 编码结果是 131 97 98 99，其中 131=128+len(“abc”)，97 98 99 依次是 a b c。 如果不是上面两种情况，那么处理结果就等于在原始数据前面加上原始数据长度的大端表示，然后在前面加上（183 + 原始数据大端表示的长度)，比如编码下面这段字符串The length of this sentence is more than 55 bytes, I know it because I pre-designed it编码结果如下184 86 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116,其中前三个字节的计算方式如下:1.

这里假设已经存在 bootnodes 服务节点了，需要给私有网络中添加一个以太坊节点，用 docker 来部署比较方便，不用手动去添加。这里只是写了个简单的 demo，并不是一个完整基于 bootnodes 来部署以太坊私有网络的方法。 当然创建一个 bootnode 也很简单，大致步骤如下： bootnode -genkey boot.key bootnode -nodekey boot.key -verbosity 9 -addr :30310 如果需要一个完整的基于 docker 的一台私有网络，可以通过 docker-compose 将 bootnode 和节点来编排，后面有空来完善一下。 具体源码 => https://github.com/yuansir/bootnodes-ethereum-peer-docker Usage genesis.json 复制 bootnodes 链接所有节点的共同 genesis.json 文件 Dockerfile 根据需求修改 Dockerfile 中的环境变量 build image 比如 tag 为 eth-peer:1.0 docker build -t eth-peer:1.0 . run // docker run -it --rm --name your-name eth-peer:1.0 /bin/bash docker run -d --name your-name eth-peer:1.

服务的注册发现对于微服务来说是一个非常重要的环节，在单一架构应用中，service 之间的互相调用，通过一个固定的 host 和 port 来发起 REST 或者 RPC 来调用，但是在微服务架构中，各个服务往往是动态变化的，所以需要一个服务发现机制来发送客户端的请求到动态的 service 实例中去。 在利用 go micro 来实现服务发现便利很多，micro 中默认支持使用 Consul 来做服务发现，当然它使用插件机制（go-plugins）还支持 Etcd, Gossip, NATS 等其他的第三方服务注册发现工具。在每个服务启动的时候，都将自己注册到 registry 上，退出时也自动解注册，具体实现我们可以来看一下go-micro/service.go的相关代码片段: ...... func (s *service) run(exit chan bool) { if s.opts.RegisterInterval <= time.Duration(0) { return } //定时注册自己 t := time.NewTicker(s.opts.RegisterInterval) for { select { case <-t.C: err := s.opts.Server.Register() if err != nil { log.Log("service run Server.Register error: ", err) } case <-exit: t.Stop() return } } } .

ERC721 官方简介是：A standard interface for non-fungible tokens, also known as deeds.也叫非同质代币，或者不可置换代币（NFTs）。提到 ERC721，一个好理解的例子就是CryptoKitties 迷恋猫，每一只猫都是独一无二的拥有不同基因，有收藏价值属性。ERC721 对于虚拟资产收藏品领域会有很好的应用价值和市场需求。 它和我写的上一篇《OpenZeppelin ERC20 源码分析》介绍的 ERC20 有所不同，ERC721 最小的单位为 1 无法再分割，代表独一无二的，针对不可置换的 Token 的智能合约标准接口。从 ERC721 标准草案中可以看到，兼容 ERC20 的方法有 4 个：name，symbol，totalSupply，balanceOf 添加的新方法：ownerOf，takeOwnership ERC721 还重写了approve和transfer。 分析 OpenZeppelin ERC721 源码前同样我画了一个继承和调用关系的思维导图，可以帮助更容易地看源码。 ERC721Basic.sol pragma solidity ^0.4.23; /** * @title ERC721 标准的基本接口 * @dev see https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md */ contract ERC721Basic { event Transfer( address indexed _from, address indexed _to, uint256 _tokenId ); event Approval( address indexed _owner, address indexed _approved, uint256 _tokenId ); event ApprovalForAll( address indexed _owner, address indexed _operator, bool _approved ); function balanceOf(address _owner) public view returns (uint256 _balance); function ownerOf(uint256 _tokenId) public view returns (address _owner); function exists(uint256 _tokenId) public view returns (bool _exists); function approve(address _to, uint256 _tokenId) public; function getApproved(uint256 _tokenId) public view returns (address _operator); function setApprovalForAll(address _operator, bool _approved) public; function isApprovedForAll(address _owner, address _operator) public view returns (bool); function transferFrom(address _from, address _to, uint256 _tokenId) public; function safeTransferFrom(address _from, address _to, uint256 _tokenId) public; function safeTransferFrom( address _from, address _to, uint256 _tokenId, bytes _data ) public; } ERC721Basic 合约定义了基本的接口方法：

ERC20：Ethereum Request for Comments 20，是一个基于以太坊代币的接口标准（协议）。所有符合 ERC-20 标准的代币都能立即兼容以太坊钱包，它能让用户和交易所，都能非常方便的管理多种代币，转账、存储、ICO 等等。 OpenZeppelin 的 Token 中实现了 ERC20 的一个安全的合约代码，本篇主要来分析一下源码，了解一下 ERC20 的实现，由于代码之间的调用可能略复杂，直接每个文件每个文件的来看会有点绕，我直接画了一个继承和调用关系的思维导图，可以帮助更容易地看源码。 ERC20Basic.sol pragma solidity ^0.4.23; contract ERC20Basic { function totalSupply() public view returns (uint256); function balanceOf(address who) public view returns (uint256); function transfer(address to, uint256 value) public returns (bool); event Transfer(address indexed from, address indexed to, uint256 value); } ERC20Basic 合约主要定义了 ERC20 的基本接口，定义了必须要实现的方法: totalSupply 返回总共发行量 balanceOf 查询指定 address 的余额 transfer 发送指定数目的 token 到指定账户，同时发送后需要触发Transfer事件 Transfer事件,任何 token 发送发生时，必须触发该事件，即使是 0 额度。 当一个 token 合约创建时，应该触发一个 Transfer 事件，token 的发送方是 0x0，也就是说凭空而来的 token，简称空气币。