JPA 的 id 生成策略
JPA 有一个@GeneratedValue注解，有一个strategy attribute，如@GeneratedValue(strategy = GenerationType.IDENTITY)。 常见的可选策略主要有IDENTITY和SEQUENCE。 GenerationType.IDENTITY要求底层有一个 integer 或者 bigint 类型的自增列（ auto-incremented column)。自增列的赋值必须在插入操作之后发生，因为这个原因，Hibernate 无法进行各种优化（特别是 JDBC 的 batch 处理，一次 flush 操作会产生很多条insert 语句，分别执行）。如果事务回滚，自增列的值就会被丢弃。数据库在这个自增操作上有个高度优化的轻量级锁机制，性能非常棒。 MySQL 支持这种 id 生成策略， 使用 MySQL 应该尽量使用这个策略，即使它无法优化。 JPA 用它生成 id，会一条一条地插入新的 entity。 GenerationType.SEQUENCE数据库有一个所谓的 sequence 对象，可以通过 select...
convention over configuration over programming
convention over configuration over programming in configuration, cmd args > env > configuration file option 是命令可选的参数，可以影响程序的how to do，算是一种特殊的argument，通常与flag同义（flag在很多时候是boolean形态的option）。普通的 argument 则是告诉程序 what to do。如果command是一个动词，option就是一个副词或者形容词，argument则是它的宾语，通常是名词或者代词。 该模型也可以这样理解：APPNAME VERB NOUN —ADJECTIVE或者APPNAME COMMAND ARG —FLAG
重拾TCP/IP协议簇
TCP/IP 协议簇本质上是 OSI 三层（网际层）和四层（传输层）协议簇的总结，通常包括TCP、UDP、IP、ICMP和ARP等几种协议。 IP 协议 链路层协议和物理层协议解决了点对点通信的问题。 而在大范围的多个子网通信问题则由 IP 协议解决。 IP地址族的分类32 位的地址空间可以分为5 类地址（常用的地址空间只用到A/B/C）。 A 类地址：0.0.0.0-127.255.255.255 B 类地址：128.0.0.0-191.255.255.255 C 类地址：192.0.0.0-223.255.255.255 实际上用二进制来看地址开头的话，还有一种巧妙的分法： 如果 32 位的 IP 地址以 0 开头，那么它就是一个 A 类地址。 如果 32 位的 IP 地址以 10 开头，那么它就是一个 B 类地址。 如果 32 位的 IP 地址以 110 开头，那么它就是一个 C 类地址。 这三类地址是用来做unicast（也就是单播）的。我们常见的环回地址127.0.0.0和本机地址0.0.0.0是A类地址。 IP 协议报文格式 IP 的 header...
Fabric 文档拾遗
基本名词解释ledger账本上一系列由事务驱动的状态迁移的记录。状态迁移是链码调用（调用即事务）的结果。这些记录是不可修改顺序的，因此也上抗篡改的。 每个channel有一个账本，但恐怕不只一个账本。 理论上账本是由产生它的链码的命名空间隔离开来的，不能直接被其他链码访问到。 chain由包含一系列 transaction 的 block 通过hash-link（由散列值作为前驱指针的一种连接方式）组成的数据结构。 state database记录各种 key 的 latest value。可以被认为上chain的indexed view，可以随时被从链上重建出来。 所以 Fabric 自己就有双层数据结构。 读写集语义读集和写集搞不好是同一个事务里的数据结构（待查）。 12345678910111213<TxReadWriteSet> <NsReadWriteSet name="chaincode1"> <read-set> <read key="K1",...
Fabric 中的 peer
每个 peer 可以拥有若干个 chaincode，也可以拥有若干个 ledger，但并不是一开始就拥有的，而是逐渐被创建出来的。chaincode 一定会定义一个 asset，也就生成了 ledger。一个peer 可以拥有 ledger 而无 chaincode，可见也并不是必然由 chaincode 生成 ledger。比如同一个组织里面多个 peer，只有一个安装了 chaincode（只有这个 peer 可以当作 endorser），其它的peer一样可以拿到 ledger。 peer 的流程架构图大致上是： 为了预防有 peer 的数据不一致，有可能需要 client application 向多个 peer 进行查询。 channel 可以认为是一系列 peers 的逻辑组合，orderer 可以被认为是跨channel的。同一个 channel 的 peers 共享完全一样的账本。 不同的组织完全可以基于同样的账本copy，产生不同的 application。 Fabric 有 identity，identity 有...
Hyperledger Fabric 各个容器内环境
peer 容器/opt/gopath/src/github.com/hyperledger/fabric/peer虽然是WORKING_DIR，什么都没有。这个目录是/bin/bash永远的进入路径，不管在哪个目录退出，重新进入还是会进入这个路径。 /etc/hyperledger/fabric12345678910# 原生的三个配置文件。所以修改peer的行为要通过环境变量来修改，让docker用COMMAND启动peer进程的时候吸收这几个配置文件和环境变量core.yaml# 这两个文件似乎不关peer的事情configtx.yamlorderer.yaml# 这两个文件夹要被外部的数据卷映射修改过来，实际上只能依赖于外部# 这个文件夹本质上还是 core.yaml 默认的 mspConfigPath 的值msptls /var/hyperledger/production这个文件夹存放unix系统里面的动态程序数据。 123456# 它下面有打包好的CIP（chaincode install package）格式的链码...
一个滚动重启的状态保存问题
很多时候滚动重启，都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的，然后在上游的服务上做好 failover，然后增加 standby server，让 sticky 数据 transmit 到 standby 机器上，让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下，除了发布新的 feature 升级以外，都应该尽量用热配置来避免重启。
重读 Martin Fowler 的微服务论文原文
微服务也是面向服务的，但 SOA 意味着 ESB。试图把复杂度隐藏在一个庞然大物里面。 几个小标题 组件化（Componentization ）与服务（Services）组件化的好处就是可以独立部署和升级，把变化隔离在组件之内。 缺点就是会引入大量的进程间交互，引入系统交叉点，引入性能下降的瓶颈以及失败的交互。 围绕业务功能的组织不要被 conway 定律左右，按照 feature 组织 team。每个 project 都应该能够独立拥有自己的全部功能—UI、数据库。 产品不是项目产品要有 ownership，要对这个产品的全部生命周期负责。 强化终端及弱化通道弱化 ESB 的复杂协议、集中式的框架。强化各个 end，或者是 client。 两种做法：基于 RESTful 通信，像 Unix 过滤器一样。基于轻量级消息总线。 分散治理这一条的意思大概是，不要考虑用一个技术方案 rule them all。 分散数据管理就是每个服务拥有自己的数据库。 基础设施自动化持续集成都全自动化。 容错性设计监控错误指标，引入断路器和仪表盘。总之提高各种...
Hyperledger Fabric MSP 相关问题
Fabric要求所有的 paticipant 有相关的 identity。identity是由x509证书认证的（大致上也就是各种signcert），每个 identity 有自己的 principal，包含了大量的 property，包括但不仅限于组织名。 PKI 生成 identity，而 MSP 表达治理组织的规则，包括哪些 identity 属于哪些组织，且参与网络中。 PKIPKI 是一种标准，一般由四个元素组成： Digital Certificates Public and Private Keys Certificate Authorities Certificate Revocation Lists 数字证书一个持有一个组织的系列属性的数字文件。常见的数字证书是X509标准的，很像一个国家发放的身份证（有名称，省份，国家，还有组织的名字）。 For example, John Doe of Accounting division in FOO Corporation in Detroit, Michigan might have a digital...
Hyperledger Fabric 的配置文件解读
Crypto Generatorx.509 相关的文件主要包含两个东西：证书和 signing keys。 cryptogen 使用的配置文件是crypto-config.yaml。 x.509 的根证书是ca-cert。它把 peers 和 orderers 绑定到一个 Org 里面。在这个网络里，每个组织都有签发自己的证书的能力，可以用这个 ca 来签发其他证书给节点和 client。 签发交易用的是私钥（keystore），验证交易用的是公钥（signcerts）。 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293# Copyright IBM Corp. All Rights Reserved.## SPDX-License-Identifier:...
