Hyperledger fabric整理

1、版本统一很重要；

docker-image的版本一致性要求比较高，如果不一致最终导致各种问题；如果你不是按照流程从头开始，那就重新拉取下最新镜像，clone一下最新fabric吧。

2、通过docker的volumes进行数据固化，再次启动数据不会丢失；

既然是数据存储就一定有路径，因为docker的优势，可以通过volumes做docker内外的文件映射，而且不会随着docker的关闭而删除，所以数据固化还是很方便的：
orderer数据
volumes:
    - ./chainData/orderer/:/var/hyperledger/production/
peer数据
volumes:
    - ./chainData/peer/peer1org2:/var/hyperledger/production/

3、文件存储的使用?

目前存储文件是非常耗费资源的，建议将文件生成二进制流然后使用hash进行计算，只存储hash的值；或者存储文件路径；
方式仍待议

4、链码数据对象设计

fabric提供一个简单查询，提供一个json作为查询参数：
stub.GetQueryResult(queryString)
queryString："{\"selector\":{\"docType\":\"user_info\",\"key1\":\"tmpValue\"}}"，即查询docType为user_info且key1为tmpValue的数据；当然可以增加更多key+value条件；当然docType也是我们自己定义的一个名字；
所以每个对象都设计一个docType字段，其实用tableName做key名称更好理解点，相当于设计数据库的表名，每次查询的时候先根据docType查询哪个表的数据，然后再根据其他条件进行进一步筛选；
对象第一个字段当作表名；

5、GetHistoryForKey获取key的历史至今value值，getBlocks是获取channel上的区块的信息；

对于GetHistoryForKey因为获取到的是每个交易后的值，但是不会返回什么交易导致改变的，所以建议在对象设计的时候多设计一个remark，记录每次交易操作；

6、joinchannel做节点之间的数据隔离

如果某个组织的peer节点未加入到channel中，则这个节点不会同步这个节点上的数据。

7、多个order创建channel方式

指定多个order即可

8、表字段增加备注字段，保存每次操作的信息 与getHistory结合使用

方便查看某个数据的变化原因

9、多节点背书问题

安装链码时指定，在逻辑成addpeer时，每个peer相当于一个背书，这里的背书只是做验证和预运算

10、solo 跟 kafka区别

solo 是单进程的，必然会有单点问题，处理性能上远远不够；
kafka 在大数据领域应用很广泛，所以处理数据的能力不容小觑，而且没有单点问题；

11、多个channel

新增channel，需要用工具生成新的tx，但管理员证书不需要再新增

sdk -
12、ca服务器的用途

ca-server在启动的时候有配置admin:adminpw，详见yaml配置文件；
ca-server提供校验和获取证书功能，当然注册登记也有，但是不常用。
sdk中用户上下文setUserContext设置的用户需要有证书文件，一般有两种方式获取：1）本地文件方式，即一开始生成的管理员证书；2）本地不保存，用的时候从ca-server获取，caClient.enrollment即可获得证书文件

13、通过数据库进行对象实例化保存

对象实例化时用到的证书等配置可以用数据库保存起来

14、需要用admin账户进行节点通讯

15、链码中GO 变量名要大写

16、链码安装后找不到方法或者日志未打印抑或逻辑未改变问题

单单使用 删除通过docker ps -aq 查询出来的镜像是无法清理干净的，需要将docker images 查询出来的临时镜像也删除掉，再重新安装；