守株阁

试着回答一下这个问题。 首先要划分系统类型：有状态还是无状态，业务系统还是存储系统。根据不同的业务场景，设立性能测试的目标：是要测 QPS，还是 TPS 还是 TPS，还是任何其他【性能】-从广义来讲，一个存储系统到底能够以多高的平均时延来管理大多的存储空间，可能也是性能的一种。 有了性能测试的目标，接下来就是拆解用例。如果把性能测试归为测试的话，测试就需要测试用例，测试用例只是用例的形式化表达。把用户的使用场景勾勒出来，把每一步拆解成的流程图或者时序图–我们已经得到了一个纸上的集成测试计划，只是没有跟性能挂上钩。 接下来就进入真正写测试用例的环节了。 我们的测试报告如果要涵盖足够立体的信息，则既要了解每一个环节/接口/API 的性能指标，又要了解整体的性能指标。 这个时候测试工具的覆盖面就很重要了。如果我们选择偏黑盒的测试工具，apache ab /JMeter，则我们的测试用例就要围绕着对外交互的 API写，也只能测到外围接口的性能。这样的测试用例写起来最简单，无需侵入任何内部代码中。 如果我们使用了 JMH 一类的工具，则可以自由编写对任何方法的测试用例。但需要对系统有非常...

git DAG 区块链 saga binlog/WAL

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 对象，可以通过 selec...

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 协议簇本质上是 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 的...

基本名词解释 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", versio...

每个 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 有 principal。 transactio...

peer 容器 /opt/gopath/src/github.com/hyperledger/fabric/peer 虽然是WORKING_DIR，什么都没有。这个目录是/bin/bash永远的进入路径，不管在哪个目录退出，重新进入还是会进入这个路径。 /etc/hyperledger/fabric 12345678910# 原生的三个配置文件。所以修改peer的行为要通过环境变量来修改，让docker用COMMAND启动peer进程的时候吸收这几个配置文件和环境变量core.yaml# 这两个文件似乎不关peer的事情configtx.yamlorderer.yaml# 这两个文件夹要被外部的数据卷映射修改过来，实际上只能依赖于外部# 这个文件夹本质上还是 core.yaml 默认的 mspConfigPath 的值msptls /var/hyperledger/production 这个文件夹存放unix系统里面的动态程序数据。 123456# 它下面有打包好的CIP（chaincode install package）格式的链码 chaincodes/mycc.1.0。ch...

很多时候滚动重启，都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的，然后在上游的服务上做好 failover，然后增加 standby server，让 sticky 数据 transmit 到 standby 机器上，让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下，除了发布新的 feature 升级以外，都应该尽量用热配置来避免重启。

微服务也是面向服务的，但 SOA 意味着 ESB。试图把复杂度隐藏在一个庞然大物里面。 几个小标题 组件化（Componentization ）与服务（Services） 组件化的好处就是可以独立部署和升级，把变化隔离在组件之内。 缺点就是会引入大量的进程间交互，引入系统交叉点，引入性能下降的瓶颈以及失败的交互。 围绕业务功能的组织 不要被 conway 定律左右，按照 feature 组织 team。每个 project 都应该能够独立拥有自己的全部功能–UI、数据库。 产品不是项目 产品要有 ownership，要对这个产品的全部生命周期负责。 强化终端及弱化通道 弱化 ESB 的复杂协议、集中式的框架。强化各个 end，或者是 client。 两种做法：基于 RESTful 通信，像 Unix 过滤器一样。基于轻量级消息总线。 分散治理 这一条的意思大概是，不要考虑用一个技术方案 rule them all。 分散数据管理 就是每个服务拥有自己的数据库。 基础设施自动化 持续集成都全自动化。 容错性设计 监控错误指标，引入断路器和仪表盘。总之提高各种 resilience（...