重拾TCP/IP协议簇
TCP/IP 协议簇是互联网的基石，是每个工程师都应该掌握的知识。这篇文章将系统地回顾 TCP/IP 协议簇的核心内容。 OSI 模型与 TCP/IP 模型 OSI 模型将网络通信分为七层，而 TCP/IP 模型则将其简化为四层。虽然 OSI 模型是理论标准，但实际应用中 TCP/IP 模型更为广泛。 OSI 七层模型与 TCP/IP 四层模型对应关系 graph TB subgraph OSI七层模型 A[7. 应用层<br/>Application Layer] B[6. 表示层<br/>Presentation Layer] C[5. 会话层<br/>Session Layer] D[4. 传输层<br/>Transport Layer] E[3. 网络层<br/>Network Layer] F[2. 数据链路层<br/>Data Link Layer] G[1. 物理层<br...
Hyperledger Fabric 完整知识图谱（2017-2018 旧文整合）
本文整合了 2017 年 10 月到 2018 年 4 月间一系列 Hyperledger Fabric 学习笔记，包括网络启动、配置文件、MSP 与身份治理、容器内部结构、链码示例、Cello 与 Composer 周边工具、以及文档拾遗。内容覆盖 Fabric v1.0 ~ v1.1 时代的实践，时间戳与"截至日前（2017.10.27）"这类标注一并保留，便于追溯具体版本背景。 一、概述 Hyperledger Fabric 可以说是 Hyperledger 的拳头项目。虽然同为 Apache 的顶级项目，但大部分其他 Hyperledger 项目都以 Fabric 为基础。它是顶级项目中的顶级项目，可以认为是 0 级项目。 Fabric 的核心组件构成一个联盟链网络： peer：保存账本（ledger）、运行链码（chaincode），分背书节点（endorser）、提交节点（commiter）、锚节点（anchor）、leader 节点等角色 orderer：负责对事务排序、打包成区块。orderer 可被视作跨 channel 的 channel...
一个滚动重启的状态保存问题
很多时候滚动重启，都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的，然后在上游的服务上做好 failover，然后增加 standby server，让 sticky 数据 transmit 到 standby 机器上，让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下，除了发布新的 feature 升级以外，都应该尽量用热配置来避免重启。
重读 Martin Fowler 的微服务论文原文
背景 Martin Fowler 和 James Lewis 于 2014 年发表的 “Microservices: a definition of this new architectural term” 是微服务架构领域最具影响力的文章之一。这篇文章并非提出微服务的概念（Netflix、Amazon 等公司早已在实践），而是对这一架构风格进行了系统性的定义和特征总结。 文章的核心论点是：微服务架构是一种将应用程序构建为 一组小型服务 的方法，每个服务运行在自己的进程中，通过轻量级机制（通常是 HTTP RESTful API）进行通信。 微服务也是面向服务的（Service-Oriented），但与传统 SOA 有本质区别。传统 SOA 倾向于将集成复杂度集中在 ESB（Enterprise Service Bus）中，试图用一个庞然大物来隐藏分布式系统的复杂性；而微服务则主张将智能放在端点（endpoint），保持通信管道的简单。 以下是对原文九个核心特征的重读和展开。 组件化（Componentization）与服务（Services） Fowler 在文中区分了两种组件...
X.509证书问题
X.509证书里有一段属性主题，大概是这样： 12 C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft,CN=www.freesoft.org/emailAddress=baccala@freesoft.org 这些 attribute 的含义是： country (countryName, C), organization (organizationName, O), organizational unit (organizationalUnitName, OU), distinguished name qualifier (dnQualifier), state or province name (stateOrProvinceName, ST), common name (commonName, CN) and serial number (serialNumber). locality (locality, L), title (title), surname (surName, SN), given...
精通比特币读书笔记
第一章 介绍 传统货币的防止双花，必须在一个中心化（centralized）的清算所（clearing house）里清算。比特币则用全局选举的机制达到共识，来清算双花问题。本质上来讲，就是把一个固定的中心化的清算过程，用选举的方式转化为无数个去中心化的局部清算过程。这就弥补了在比特币之前出现的数字货币的缺点。 clearing 在比特币网络里就被称作 mining 。 钱包是保存地址和管理密钥的地方。不要害怕公开自己的钱包地址。 全节点可以获取全部的交易信息，也因此可以验证交易，发出交易。硬件钱包是运转在专有硬件上的节点（树莓派？），冷钱包就是纸一类的东西。离线钱包是非常安全的。 第二章 比特币原理 比特币最多可以分割到一亿分之一的大小。 Transaction就像是复式记账法账簿上的行，即每行都有输入和输出。 简单来说，每一笔交易包含一个或多个“输入”，输入是针对一个比特币账号的提款（而不是债务）。 这笔交易的另一面，有一个或多个“输出”，被当成信用点数记入到比特币账户中。这些输入和输出的总额（负债和信用）不需要相等。相反，当输出累加略少于输入量时，两者的差额就代表了一笔隐含...
重放攻击问题
比特币靠不同的地址前缀可以规避重放攻击问题。 以太坊可以靠 EIP155 钱包来规避重放攻击问题。 何为重放攻击问题？ 一个区块链有若干个测试网络。如果一套公私钥可以在不同的网络上通用，则可以恶意地把在测试网络中出现的 transaction 播放到主网上。如果在测试网络上有人从账户 A 转了一笔钱到账户 B，而账户 B 是一个傻瓜测试账户，私钥是由类似123456之类的种子生成的话。那么只要账户 A 在主网中的余额大于这笔钱，心怀恶意者就能把主网中 A 的钱财转走，从主网中的账户 B 里把钱取出来。即使心怀恶意者没有 B 的取款方法，也能让账户 A 蒙受资金损失。 所以不要跨网使用相同的公私钥对。
UTXO 与 account balance 模型
UTXO 简介 UTXO 的全称的 unspent transaction output，就是没有被人用过的可用资金。 这个模型是比特币首创的，被其他货币所模仿。以太坊天然的模型不是 UTXO 而是 account balance。 UTXO 必须配平，UTXO 的输入者必须上一个 UTXO 的输出者： 这就把一个一个账户型数据库，转成了链式的交易数据库，交易要靠 merge 整个数据库的相关节点。 UTXO 的好处是： 更加好的隐私模型 更加强的并发范型（因为不会触发间隙锁了吗？） ZCash 的 UTXO ZCash 也一样有 UTXO，但它的 UTXO 是加密过的，而且每个矿工那里还有一个专门的 UTXO 作废数据库。具体情况见《不是程序员也能看懂的ZCash零知识证明》。 ##以太坊中的 account 模型## 以太坊没有使用 UTXO 模型，而使用 account balance 模型，他们把 account balance 模型称为 world state。account balance 模型比 UTXO 模型更加容易实现智能合约，...
重新学习 Solidity
以下内容还是从 Solidity 文档里摘出来的。 智能合约入门/介绍 第一个基本的例子 12345678910111213pragma solidity ^0.4.0;contract SimpleStorage { uint storedData; function set(uint x) public { storedData = x; } function get() public constant returns (uint) { return storedData; }} 一个 contract 可以被认为是一个类型。 默认的 unint 就是256位的。 storedData 可以被认为是 state variable，状态变量。在 Solidity 的概念里面，这个东西可以被认为是数据库里面的一个槽，可以被函数查询和修改。注意看它不是 public 的，所以没有合成方法。 访问状态变量不需要用 this前缀（在什么 scope 下都不需要吗？）。 ...
语义版本化问题
语义化版本 2.0.0 《语义化版本 2.0.0》，三段版本号语义： 版本格式：主版本号.次版本号.修订号（MAJOR.MINOR.PATCH），版本号递增规则如下： 主版本号（MAJOR）：当你做了不兼容的 API 修改， 次版本号（MINOR）：当你做了向下兼容的功能性新增， 修订号（PATCH）：当你做了向下兼容的问题修正。 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面，作为延伸。例如 1.0.0-alpha、1.0.0-beta.1、1.0.0-0.3.7。 版本号的初始阶段 在主版本号为 0.x.y 的阶段，API 被认为是不稳定的，任何变更都可能发生。这个阶段的软件不应该被用于生产环境。1.0.0 的发布意味着公共 API 的正式定义，后续的版本号变更都基于这个公共 API 的变化来递增。 先行版本号（Pre-release） 先行版本号通过在修订号后面加上连字符和一系列以点分隔的标识符来表示。例如： 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-b...
