2017-12-02

2016 Qcon北京

1.1 七周七并发

1 2	for(int n: numbers) sum += n;

(defn sum [numbers]
	(reduce + numbers))

(defn count-words [pages]
	(frequencies (mapcat get-words pages)))

(defn count-words [pages] 
	())

1.2 JVM G1

performance tuning: throughput/ response time/ footprint/ availability / capacity

analyzing log
monitoring
- lock stats, utilizations[cpu,mem]
profiling

JVM (class loader + gc + runtime + JIT compiler)

JVM monitoring
app profiling
process & plot GC logs
online& offline GC monitoring

NOT eliminate your memory leaks!(GC heap dump)
throughput & latency(no footprint) two main drivers
- throughput max (generational + parallel work
- latency (pause + concurrent mark/sweep)
All GC in OpenJDK HotSpot are generational
- fast path alloc == thread local alloc buffer == lockfree alloc [epoch 机制！]
- young gc == reclamation via scavenging(eden -> survivor)
- old gc(different algothm!) reclamation via parallel mark-swept compact/ multi-threaded
All non/partial compacting GC fallbak to full gc [like g1?]

young collection(partial) -> initial mark(less pause) -> remark(big pause) -> cleanup(little pause) -> mixed collection(partial)
collect most region(mixed collection)
heap configuration

Tuning GC

elapsed time
- copying costs(in compact!)
overhead(more possible)
- alloc rate & promotion rate

size generations(faster filled sonner gc trigger)
size appropiate (more copy more pause)

adaptive alogithm for gen size(do steps - find in “print”)
java performance tuning? monica@codekaram.com (left oracle)
openJDK hotspot vs jeorocket

sp

kubernet 1000node限制封装+100ms延迟
华为王宇冬提问：扩展存储问题（有状态就使用ceph，性能下降问题[无解？]）

1.3 网易蜂巢容器云

docker 开发人员与sa关系（改变部署、协作方式)

- 运维定义仅镜像-》自动化容器云平台
- 成熟度 Docker（网络、存储坑）/ kubernetes（多租户、有状态坑）/ OpenStack（公有云运用坑多）

容器网络: 容器互联
复杂情况：
NAT

- 长连接问题、IP注册服务发现问题、迁移复杂
端口映射
- 运维复杂度、端口冲突、内外IP
层级网络
- 不利于故障恢复、IP变化（控制IP分配）

VxLAN网络(Openstack Neutron)
- 每个租户独立私有、外网网卡直接挂载、私有网络>容器网络
基础服务暴露为统一url
编排（选择kubernetes）
- 多租户 node、存储、网络隔离
- 性能问题：所有操作都在任务队列串行执行、LB聚合多个etcd集群（超过1千节点）、调度器以租户调度(?)
诊断工具
- 统一日志调用链！rsyslog收集
- 基础服务监控定制化(慢查询、死锁、复制等)
容器运行
- 保持状态：网络、存储（远程盘、实现reload命令）
  数据库docker化？ ceph或高IO块

1.4 Startup大数据平台架构 AppAnnie

王佳 ramon@appannie.com 应用商店分析和市场数据
Startup与大数据(人员成本、运维成本)
架构平台设计原则（每天20TB压缩数据、6+集群、500+数据处理任务、100~200服务器）

数据驱动（引入data schema中间层）
使用工作流引擎管理（数据节点复用，通过executer来封装底层执行引擎）
- 自实现 Dagre-D3(js, UI) + Engine(Python RQ，取工作流，找task丢到Redis) + Redis
- oozie, Azkaban, luigi（内部大数据）
  Pig 构建数据管道，HIVE 临时查询与分析，Python 实现各种ETL、算法模型、Pig的UDF函数

1.5 OS导致非典型GC停顿（zhenyun）

bg: java(HotSpot JVM) + linux (paging[huge page] + swapping + page cache[writeback] )
理论来自IEEE Cloud 2014
三种场景：

startup state
steady state with memory pressure
steady state with heavy io

workload:

java app alloc/de objects
bg app taking mem or disk ios

Startup State

Q: java heap（resident size查看）逐渐增大-> 导致OS启动direct page scanning(cpu飙升) -> OS启动swapping
A：”-XX:AlwaysPreTouch”初始化 + 设置Swappiness = 1 + cgroup具体设置

Steady State (mem)

Q: 以为是heap被swap out导致(55 s时间太大，sys/usr/real time中为55/0不应该cpu这么高) -> linux默认特性THP导致(加速寻址,malloc超过2M自动启动)
A: mem压力时不用THP，没有再开

Steady State (IO)

Q: sys/usr/real(0.01/0.18/11.45) disk io比较高 -> gc之后1.5s停顿(要小写gclog文件导致，但是异步花这么长时间return?) -> stable page write(pdflush启动) / journal commit导致(包括需要alloc新block时启动)
A：gclog写能否异步？否！

mission control

先看usr/sys/real
小心linux新的特性
注意各层的问题

QA：CMS容易full gc-> mem leak->静态变量太多 / object size比较大?

1.6 (百万量级)细粒度查询意图识别

搜索广告-基于关键字匹配

查询短、特征稀疏、歧义强
广告缺乏相关性

目标：从日志挖掘查询意图，处理高频与长尾查询
现有方法：Google Rephil系统(Bayesian网络推断)使用在adsense
识别意图3类方法(短文本聚类[长尾无法覆盖，缺失推断能力]、Topic Modeling[不同topic难对应，精确度不足]、查询分类[粒度较粗])
方法：查询聚类(聚类算法抗噪、图挖掘中社团发现算法->MMO算法)
网络构造：2年点击日志-> 抽取query-url关系
问题：过大不纯类、太多细粒度 -> 质量评估（纯度、文本相关性）
意图推断：候选分类发现、拒绝项
应用：广告召回、广告质量保证

2.1 Twitter message queue

2012年每个不同基础服务对应一个message
database – Bookeeper

kestrel (simple, Fan-out queue, Reliable reads, cross DC rep)
问题：
- each queue is a file(持久化性能问题)
- 读旧数据性能(mem cache设计问题)
Kafka (小规模订阅的顺序io性能非常好)
- 依赖OS的page cache(文件多导致random io)
  更大问题：各个软件组件维护问题(client, upgrade, hardware)

消息总线目标：1.unified stack; 2. Durable writes(intra-cluster, geo-repli); 3. 多租户; 4. scale resources independent; 5. 易于维护

仍然采用日志追加模型 entry(DLSN, Sequence ID, tid)

- 没有实现partition
- 存储层Bookeeper
- 核心层writer, reader 读写分离
- 无状态服务层 write proxy(ownership tracker)/read proxy(routing service)
- 方便服务层(container去做)与存储层扩展    
- 冷数据存储 HDFS

注意：write proxy写是2PC的(Bookeeper实现or自己逻辑实现？BK使用的是Paxos)
最终一致性实现：LastAddConfirmed(读) & Fencing(写，争强问题？hash)：owner tracking(不需要严格选举，lease机制即可，zk就能提供，failure detect: TickTime=500ms Session Timeout=1000ms)
Geo-repli要求zk多机房部署一个集群
总结：底层保证、不要相信文件系统(page cache)
guosijie_

2.2 intel Spark 优化

10%~15%内存给OS做cache(dcache, page cahce)

memory per node * (85~90)% / executors per node
2~5GB per core: * spark.executor.cores

memoryOverhead参数：默认太小，防止offheap mem size导致被yarn kill
serializer参数：kryo序列化 15~20%提升
partition选择：太大(磁盘压力、轮数太多)，先设大值再慢慢降(GC问题)
IO调整：

storage level
compression 默认rdd不压,shuffle压
dynamicAllocation: 在Spark SQL好使
GC：WebUI(GC Time 大部分GC严重开始调)，尝试减少并行度
blktrace 分析io，顺序(大IO,延迟小,磁道数连续)/随机(小IO,延迟大,磁道)分类(通过lba地址时间线判断) -> shuffle read是随机的，易于造成io瓶颈

QA：除非内存超大，全在OS page cache中shuffle，但是提升相比也不多，因为瓶颈主要体现在CPU了

2.3 百度分布式计算调度

资源调度+资源管理mesos
Omega论文图片说明历史 Yarn -> mesos(双层) -> Brog/Omega(乐观锁)
作业无法区分 -> 资源利用率 -> 异构系统 (60% CPU利用)
实现：

虚拟化交付，资源审计
自研RPC
丰富调度算法
物理队列、逻辑队列、优先级抢占等
lib raft

2.4 服务治理

qlang语言 GO语言的TPL 从富媒体存储开始起步
服务端程序员特殊职责：on call
服务治理：更高可用性、业务开发更简单
服务发现与负载均衡、调度、配置变更。。。
微服务：变多，治理压力更大 -> 业务化组织

服务发现：服务的扩容缩容、调度，同时有负载均衡的问题；实现为客户端（性能更好）或负载均衡器（API gateway，治理能力更好）Kubernetes方案就不错，可以参考
过载保护：自动扩容可能因为异常导致问题更严重，建议区分好坏请求，扩容增加上限，拒绝部分请求(N*2 高于报警线)
服务降级：为重要请求保证资源
故障定位：找root cause（首先可以进行集群拓扑发现，根据服务请求链条找根源，预案处理），xushiwei（注：七牛求才）
QA：如何区分资源问题和机器硬件问题（比如慢盘问题，upstream检测）
QA：拓扑发现如何做？

2.5 Elastic Stack数据分析

曾勇Medci Elastic于2012年成立
ELK -》Bees
ElasticSearch：搜索与聚合、数据分析(运维日志)、支持超过1700多节点1.3PB数据
Ingest：Logstash（多数据源收集中间件）、Beats（golang，简单收集行为数据，包括三类：网络、系统状态、日志）
Kibana：可视化

2.5 分布式存储

设计考虑

本地海量小文件例：Swift
聚合存储 g:方便迁移，EC恢复; b:垃圾回收比较复杂例：Heystack

美团云设计：

s3模型底层对象存储，用户建立域名
Mangix系统 StoreServ（c语言、并发网络框架） ProxyServ（Golang、http访问入口）SchedServ（Golang 监控恢复调度小文件垃圾回收） MetaDB（Oceanbase，中心化元数据存储）

存储设计 [partition] 迁移复制最小单位，对应一个文件256MB，三副本 [record] 2MB落盘，流式写入 [Record Index]Record ID -> File Position
恢复时间与可靠性 LRC算法
元数据设计多版本、数据去重(sha-1)、对象覆盖写？
sharding表如何设计方便EC RecordID(ServerIP+DiskID+timestamp)
垃圾回收标记删除、孤儿数据
MetaDB 万亿级数据、读多写少：LSM Tree实现就行
进程独占机器 StoreServ/ProxyServ
测试：glibc钩，不间断压力测试

consistent hash问题：扩容、数据迁移代价

2.6 MVVM与FRP

美团变为平台+业务，挑战：代码复用率低、团队分工 -》分层+组件化

2.6 Apache Eagle ebay

分布式策略引擎

SQL on Streaming
实时流处理 Storm+Kalfka

3.1 大数据技术演进

Delivery(Kafka/RabbitMQ/Flume[push-based]) -> Processing(spark streaming[batches]/storm/samza/flink[stream]/spark/hadoop[batch]) vs Querying(SQL-on-Hadoop[using both hadoop & db]/Impala/Hive[SQL like]/HBase[KV,pre-comput,range scans]/Druid[column store & query,even BI])[output smaller] -> Storage(HDFS/ALLUXIO[mem]/Kafka)

reaching saturation point
Delivery(Kafka) -> Stream Processing(spark) -> Querying
BI ??? -> TensorFlow DL4J -> AI ???

druid join问题: 只是还没实现好
data mining & trend predict问题：问题仍没有很好解决方案
传统BI与Query Engine区别问题：开源，支持stream data，性能，功能目前无法比但很快会赶上

3.2 大数据、人工智能——京东VP

Hadoop核心思想 -> Partition data(key思路来源于search中倒排索引的token) + Coordinate & Schedule

Hadoop优化（主要集中于DiskIO）：Column存储、利用内存(Spark特别在数据挖掘)

如何开始build，有哪些坑：

大数据安全性（更多）
BI应用（传统数据库已经研究很长时间）data model与Schema设计非常重要（减小数据复制，支持业务）
任务调度（10K+ 节点）
高性能与吞吐（每天100K+，除了平台，自身业务也要优化）
low lantency（实时搜索）

如何挖掘数据价值：

Deep learning 数据量增大，对多媒体数据分析，SL RL
Baysian program learning 不需要大数据，必须对问题有深刻了解，LDA

feature engineering 很常用，人工提供数据，实际上找特征比较难 Regression/GBDT/CRF
Supervised Deeping Learning nero-network算法降维，自学习隐藏特性

Search ranking/personal recom/customer attrition/product price

大数据不一定覆盖重要特征，可能导致model失效
feature engineering 比模型更重要
real-time数据使用应该用在最后一步

Thinking Tech 未来big data

AlphaGo

combine 多个 SL deep learning models & RL models
Reinforcement learning[NEW!]

产销决策 jd采用RL策略
Elon Musk’s Open AI
data scientist与业务domain之间的gap解决：应该管理来解决（培训）

3.3 JS选型 - Dylan Schieman@dojo, sitepen

挑战：Browser release；new platforms(even watches & VR)；
优势：Ubiquitous；Easy；Zero install；
挑战：各种标准的冲突；缺少长期稳定一致；

模块化（包括HTTP2支持）
测试
独立性

typescript帮助代码健壮(特别是动态属性)，interface帮助选择
A limited Test Drive问题
fat-controller & bi-directional slow -> virtual dom(maquette) & Redux
templating vs JSX vs HyperScript(dojo2)

3.4 数据库高可用——网易

同步方案：
DRBD性能 SAN价格 BINLOG MMM一致性问题 MHA都在用，主机硬盘问题
Semi-Replication事务提交顺序 Galera锁冲突比较多 NDB新存储引擎，使用人少

优化：

异步复制->同步复制？ 5.5.20-v3 => 5.7.2吸收
组提交：Binary log Group Commit 5.5.20-v3 => 5.6.6吸收
实时切换：从机并行回放（组里） => 5.6不同db进行；5.7完全吸收
可用域和存储池

切换成本问题（应用断连接）SQL响应时间长 80%切换可用避免（可以提前预知）

数据库健康检查：

索引设计主键索引(无主键[复制性能差、多表插入性能]或主键非自增) 冗余索引或无效索引(影响插入性能) 低效索引(索引区分度[information.cardinality/tables] 低于0.1则有问题)
容量规划 cpu利用率、buffer_pool命中率(判断mem设置)、带宽、iops等
参数配置 Binlog(expire_logs_days/sync_binlog[不开不一致]/binlog_format[raw]) Redo(Innodb_file_log_size过小造成SSD下间歇hang住/Innodb_flush_log_at_trx_commit=1) 内存(pre-thread buffers * max_connections + 其他共享内存 < 物理内存)
服务安全
用户访问死锁(error log中判断) 慢查询(按照SQL类型归并)

3.5 Druid介绍 @imply

开源分布式数据库(2011) 应用场景是billion~trillion的数量级

History & Motivation: scalable/Multi-tenancy/Real-time
power for BI/OLAP

traditional data warehouse - star schema -> Aggregates tables/query caches (very slow!)
KV stores - Hbase etc. pre-compute slow as data grows
Column stores - Druid! after fail with postgre & HBase

Design

supports custom column format -> summarization(agre on index -> shard on time[segment]) -> Multi-tenancy(deal with segment each)

Arch

data->Hadoop–> Historical Node[segments] <–Broker Node<-query
streaming data -> Real-time Nodes(改为reverse index Nodes) –> Historical Node <–Broker Node<-query
Real-time Nodes: convert write optimized(hash map) -> read optimized(segments)
UI: Pivot/Grafama/Panoramix …
shard保证数据字典变得太大 random hash
summary rollup会丢失秒级数据
为何选择time做hash 可以很容易filter
传统数据库导入：first export raw data format
cache也是根据时间(segments为单位)
grafana UI 新指标添加比较慢
tableu在大数据表现不好[crash data]

3.6 数据访问层 ele.me

Netty.io 踩的坑
ele.me 纯python平台 -> 引入java生态
限流削峰、连接复用、用户隔离、分表、熔断、读写分离

指标：单价1万QPS(极限4.8万、日志trace都关了->2万)、延迟0.6ms、1.5万降为1千
DAL功能引入演进：小功能2周左右
限流削峰 -> 主从分离 -> 二维分表(用户、商家的订单在一张表，拆分同时映射) 先用户再商户显式commit -> 一维分表
DAL架构选型（康威定律）2015/04 -> 独立进程服务（非库服务，多语言，mysql协议进程通信）-> 业务可以回滚接入前
HAProxy -> Netty NIO -> MySQL解码 -> 限流队列(痛点！) -> 事件驱动SQL状态机 -> Netty NIO -> MySQL
非核心功能可以在线关闭网络层/jdbc
同步（看起来是顺序的）-> 客户端/服务端超时 Netty IO异步 -> 清理资源不能释放两次 -> 加锁（标志）加好多！-> 去掉并发 SQL事件线程排队
切换工具长时间能否工作 -> 系统升级与容灾切换一起做 -> 注意事务没有commit的情况
CMS垃圾收集 170ms停顿->G1 20ms停顿指定目标工作时间即可
客户端至少1s超时，因此GC不会太影响
Netty线程性限制解决流量减小CPU压力
读写数据一致性，从库10ms延迟，应用读从库需要忍受秒级延迟

2017-12-02

Introduction to Basic Fixed Income Securities

Lottery payments

A major lottery advertises that it pays the winner \$ 10 million. However this prize money is paid at the rate of \$ 500,000 each year (with the first payment being immediate) for a total of 20 payments. What is the present value of this prize at 10% interest compounded annually?

$PV = \sum^N_{k=0}\frac{ck}{(1+r)^k} = \sum^{20}{k=0}\frac{500000}{(1+10\%)^k} = 4.2567818598792826 $ 4.68?
Sunk Costs (Exercise 2.6 in Luenberger)

A young couple has made a deposit of the first month’s rent (equal to \$ 1,000) on a 6-month apartment lease. The deposit is refundable at the end of six months if they stay until the end of the lease. The next day they find a different apartment that they like just as well,
but its monthly rent is only \$ 900. And they would again have to put a deposit of \$ 900 refundable at the end of 6 months. They plan to be in the apartment only 6 months. Should they switch to the new apartment? Assume an (admittedly unrealistic!) interest rate of 12% per month compounded monthly.

$ NPV1 = -\sum^5{i=0}\frac{1000}{1.12^i} + \frac{1000}{1.12^6}$
$ NPV2 = -1000-\sum^5{i=0}\frac{900}{1.12^i} + \frac{900}{1.12^6}$
Relation between spot and discount rates

Suppose the spot rates for 1 and 2 years are s1=6.3% and s2=6.9% with annual compounding. Recall that in this course interest rates are always quoted on an annual basis unless otherwise specified. What is the discount rate d(0,2)?

$ d(0,2) = \frac{1}{(1+s_2)^2} = 0.8750736155679097 $
Relation between spot and forward rates

Suppose the spot rates for 1 and 2 years are s1=6.3% and s2=6.9% with annual compounding. Recall that in this course interest rates are always quoted on an annual basis unless otherwise specified. What is the forward rate, f1,2 assuming annual compounding?

$ f(1,2) = (F_2 - F_0)d(2,2) - (F_1-F_0)d(1,2) = (1.069^2 / 1.063 - 1) = 7.503386641580434% $
Forward contract on a stock

The current price of a stock is \$400 per share and it pays no dividends. Assuming a constant interest rate of 8% per year compounded quarterly, what is the stock’s theoretical forward price for delivery in 9 months?

$ F = \frac{S}{d(0, T)} = 400*(1+0.02)^3 = 424.48320000000007 $
Bounds using different lending and borrowing rate

Suppose the borrowing rate rB=10% compounded annually. However, the lending rate (or equivalently, the interest rate on deposits) is only 8% compounded annually. Compute the difference between the upper and lower bounds on the price of an perpetuity that pays A=10,000\$ per year.

$ PV = \sum^N_{k=0}\frac{c_k}{(1+r)^k} = 168.3501683501676$ 25000?
Value of a Forward contract at an intermediate time

Suppose we hold a forward contract on a stock with expiration 6 months from now. We entered into this contract 6 months ago so that when we entered into the contract, the expiration was T=1 year. The stock price \$ 6 months ago was S0=100, the current stock price is 125 and the current interest rate is r=10% compounded semi-annually. (This is the same rate that prevailed 6 months ago.) What is the current value of our forward contract?

$ f = S_t - F_0 e ^{-r t} = 125 - 100/(e^(-10%1)) e^(-10% * 2) = 43.12692469220181 $

2017-04-08

新技术跟踪

区块链技术总结与架构实战

周围所有想了解区块链的人一上来都会问我们这样的问题：什么是区块链？和比特币是什么关系？到如今，稍微了解区块链技术的人应该可以很容易地回答第二个问题：区块链是比特币的底层账本技术的衍生技术，比特币是目前区块链最成熟的一个应用。但是第一个问题至今仍然很难说清楚。接下来就让我们脱离所有区块链的经济属性，纯粹从技术来探讨看看目前的区块链技术，思考一下区块链技术本质特征，个人也推测一下未来可能的发展情况。

我们知道区块链本身是一个技术系，而非一种具体技术或产品，名词状况有点像云计算或NoSQL，当我们问“什么是云计算”或“什么是NoSQL”时，我们也无法简单的概括出来，我们会首先尝试开始描述这类技术系的特征，因此我们不妨也从区块链的技术特征描述入手。

一、技术特征

区块链衍生于比特币的底层机制，目前涌现的产品包括：以太坊、Fabric、Corda、Ripple等，这些系统总体表现为分布式P2P通信结构，每个节点拥有运算或存储能力，所有节点共同维护一个账本。

系统的明显技术特征表现为：

存储信息难篡改
每个节点都拥有完整历史信息
拜占庭容错一致性
系统可靠性极高
系统拥有执行运算能力
安全的账号体系

想更好理解这些目前表现出的技术特征，我们需要牢记从技术本源出发做思考，否则很容易被各种产品不同设计和宣传的不同特性弄糊涂。区块链技术创造的初衷就是要解决分布式环境下存储可靠性的问题，这里的可靠既指系统的服务时间不能因为节点数的减少而暂停，更重要是指存储信息的真实性。因此，存储信息不能被节点私自篡改，传输拜占庭容错且系统整体一致性都是最基本的要求。

试想下攻破区块链有哪几种方法，然后结合区块链上述六个特性进行对比思考，就能对区块链功能设计有更深刻的理解：

利用分叉处理弱点直接修改节点系统存储信息（比如伪造某个节点的ip加入然后宣称刚刚出现网络分割现象，应该同步自己的这些信息），由特性1、2防范
部分节点被停电或关停，由特性2、4防范
造成区块链网络故障或拦截并伪造信息，由特性3防范
在区块链上执行恶意逻辑或同步类似病毒信息，由特性1、特性5防范
攻破区块链的账号体系，直接变成合法修改内部状态，由特性6防范

智能合约一定要在区块链技术之上实现吗？当然不是，传统中心化数据库也可以存储实现智能合约逻辑。但是在分布式环境下，合约有很高的被篡改之类道德风险，抑或被黑客攻击的技术风险，因此才需要使用区块链来存储智能合约，保证逻辑的可靠性，因此合约代码本身发布后也是难篡改的。需要注意这里跟数据一样，难篡改不等于不能修改，只是存储的历史记录不会篡改而已。

二、技术实质

区块链通过设计链式存储结构，每次新信息产生实际需要使用系统中所有历史信息产生的摘要，这样其他节点就可以对新信息的真实性进行验证。

比特币和以太坊依靠椭圆曲线非对称算法完成难篡改特性和拜占庭容错一致性，基本思路是增加作恶代价，保证节点产生新信息困难但是验证简单
Fabric则依靠？？？（谁知道可以回答一下Fabric怎么保证历史信息不被篡改，完成合法性验证）实现难篡改特性，利用PBFT算法保证拜占庭容错一致。

根据上面总结的六个区块链特性，大家可以发现区块链也并没有什么特别的，完全可以把区块链视为一个由多方共同来使用运维的分布式数据库，智能合约类似触发器和存储过程，区别在于：

区块链不一定要是关系型数据库，现阶段产品更类似一个NoSQL数据库
这里的分布式仅用于加强系统可用性，每个节点都是完整备份节点，并不用于水平扩展，因此系统存在存储极限，需要其他技术配套解决这个问题而非区块链本身
系统默认保证节点间的网络通信安全，可以支持类似跨境的互联网环境
因为多方参与维护运维且节点拥有全量数据，因此账号权限划分需要内置提供相关机制（这点最需要加强，但相信会有解决方案出现）

因此，目前工程使用时可以将区块链视为一个分布式部署的NoSQL数据库解决方案，该方案要求公网通信环境即可，未来运维需要多方参与。

留存疑惑：各种产品如何保证通信信道安全，又如何保证存储历史信息安全，PBFT只能保证通信安全情况下，节点之间接收交易请求顺序一致且内容未在其他节点上被篡改或伪造。

三、如何使用

注意区块链使用的基本：

区块链和智能合约能实现的，现在IT系统都能实现；
区块链不保证提升系统性能而是系统架构模式的改变；
只有链内信息保证信任，外部信息不能保证；
区块链应用不一定非要数字货币参与

正如上面分析的，目前使用区块链产品就跟使用数据库一样：首先是要设计建立表格，对应区块链就是设计智能合约中的数据结构，确定哪些数据需要记录到区块链上；接着是设计权限和逻辑，对应智能合约中的业务逻辑，保证记录到区块链上数据的正确性与合法性；最后是确定智能合约的访问接口。

作为一名区块链应用架构设计师，可以从下面几个维度去设计架构：

1）区块链或分布式账本技术：根据业务特性，在需要增加“信任”的场景下，选择区块链或分布式账本技术解决方案。

2）身份管理：构建一个弱中心的认证中心，补充目前区块链解决方案在权限和账号认证上面的不足。

3）安全数据访问：存储的数据需要在区块链中全局共享，需考虑数据访问层对安全的要求。

4）链上-链下数据访问：分布式应用程序需要与传统的链下系统进行互操作；在区块链高速发展期，不可避免需要与传统数据库应用系统进行交互。

5）智能合约：通过设计出细粒度运作的独立子链（逻辑/物理），考虑通过多个智能合约满足不同的业务需求。

7）编程接口：需要提供熟悉的API接口方便调用区块链上的智能合约程序。

所以不同领域的区块链应用在智能合约的设计上会稍有不同，需要一些最基础的业务逻辑支撑，比如金融区块链中应该有几个基础合约来解决一些最基础的业务逻辑，包括验证、冻结、仲裁等，特别是仲裁逻辑，可以应用到包括合约升级、节点加入、审计发起、分叉解决等多个业务行为中。

四、未来技术走向

对应数据库的技术走向，一定程度可以预测区块链技术的未来发展。下图是美国提交的区块链架构标准，拥有相当的参考学习价值。

国际区块链架构参考标准

区块链节点保存全量数据，历史信息完全保存做到可追溯，这两个特性的初衷是为加强信息真实性，未来可能会出现部分产品舍弃这个特性。通过引入如RAID编码或erase code等技术来解决保存全量数据的问题，做到一定信息的物理隔离，并方便数据压缩。

对于开发者，智能合约需要具备可移植性，尽可能支持多个不同的区块链平台，降低跨平台移植的工作量。对于合约开发平台，应该提供一个语法规范，让不同的区块链平台支持该开发语言。区块链上数据访问构筑肯定会增强，不排除未来直接暴露SQL支持，从底层到外部合约接口都可能支持SQL。

未来可能会实现跨链服务，即不同区块链间的智能合约数据交互。这个服务使得区块链之间构建了互操作性，在复杂的业务场景下，可以设计出细粒度运作的独立子链（逻辑或物理上的），并通过母-子智能合约满足不同的业务需求，提升了全局“臃肿”账本的灵活度。

参考文章

2017-03-23

新技术跟踪

Hyperledger Fabric CA设计

1. 需求描述

基于商业安全需求考虑进行设计，需要身份与角色管理相结合（身份管理将商业中的问责制更加明确）交易隐私表现为：交易匿名和交易不可关联。

实现：

向CA注册静态登记证书（ECerts，仅用于身份认证，包含公钥部分，使用方法A：所有人可访问；使用方法B：仅TCA和审计访问，对交易不可见）
登记用户向交易CA获取伪匿名代表的交易证书（TCerts，用于配置交易可见性，可以选择性暴露身份）

0.6简化Tcerts设计使用对称密钥加密来提供交易保密性。

DB多用户及用户权限

0.6 设计

memsrvc服务

1.0 设计

configtx.yaml包含示例区块链网络内角色的定义；/crypto目录包含管理员证书，CA证书，每个角色的私钥和用于签名的证书

部署合约时可以选择背书策略

改名为fabric-ca服务

2017-02-05

SICP第二章总结

2016-10-31

Token based auth in frontend

参考
https://blog.coding.net/blog/oauth-and-oauth-scribe

2016-07-02

系统经验

程序员实用硬件体系结构归纳

1. 硬件体系结构

硬件关注大致CPU、CPU Cache(L1, L2, L3)、内存、SSD、普通硬盘HDD、网络网卡这几个层次

2. CPU架构

CPU核内主要技术点包括Super pipeling、Superscalar
、Simulaneous Multi-Threading(SMT)、out-of-order等，目前CPU都使用多核架构，例如来自Intel Core i7的Nehalem架构Fetch to retire，

CPU使用IMC接口与内存互联，使用QPI连接多个处理器((processors 比如Nehalem Quadcore)

2.1 性能指标

参考性能指标包括：

主频： CPU的时钟频率，内核工作的时钟频率
外频：系统总线的工作频率
倍频： CPU外频与主频相差的倍数
前端总线：将CPU连接到北桥芯片的总线
总线频率：与外频相同或者是外频的倍数
总线数据带宽： (总线频率 * 数据位宽) / 8

相关组件有L1,L2,L3 cache (缓存数据与指令)
L1,L2: core独占；带宽：20-80GB/S；延时：1-5ns
L3： core之间共享；带宽：10-20GB/S；延时：10ns
Cache line size： 64 Bytes

QPI接口
Intel中，连接一个CPU中的多个处理器，直接互联 QPI带宽：~20GB/s

2.2 程序优化

3. CPU Cache

Cache Line是Cache与内存Memory交换的最小单位，X86架构的CPU基本为64B，以组相联的形式组织

一种方案Write Invalidate写导致其他CPU L1/L2的同一Cache Line失效，另一种Write Update写同时更新其他CPU L1/L2的同一Cache Line

写策略通常有Write Back新脏数据先读到Cache然后修改，Write Through新脏数据直接写到Memory

主要问题是Cache Coherence算法，比如MESI, MOESI等

MESI协议，有四种状态：

Invalid 无数据,
Shared 与Memory一致数据且多节点共享,
Exclusive 与Memory一致数据且单节点持有,
Modified 最新修改数据且单节点持有。

有六种交互信息：

Read
Read Reponse
Invalidate
Invalidate Acknowledge
Read Invalidate
Writeback

MOESI协议，五种状态：owned 与Shared共存，持有最新修改且Memory过期

这些协议作用于CPU Cache L1/2和内存，与Register无关

4. Memory

正确理解Memory Ordering与并发的关系

4.1 Atomic

涉及到内存的读写指令，特别是非对齐的双字操作，可以使用专用指令：CMPXCHG, XCHG, XADD等，或使用lock指令（使用在指令之前表示当前指令操作的内存只被当前CPU所用）

4.2 Memory Barrier

程序优化

参考

2016-04-09

前端

深圳node party小结

实战ES2015

classes
export&import 统一标准
使用rollup.js打包、HTTP/2

平台化运营实践

腾讯MTT对比pm2设计

进程管理
日志类型（按大小滚动，按时间滚动）
日志输出时间|pid|级别|文件名:行号
可配置的服务（不重启）
TAF协议与JCE规范（编解码,不动态解析方便debug）
调用监控（流量、耗时、超时率、异常率、服务+接口）与特性监控（自定义）

日常问题

时间计算 Date.now()最快，process.uptime()最好
内存与进程虚拟核心与物理核心问题
用户环境服务调用只在同环境中进行，服务转发？？
染色应用将整个服务调用链日志统一收集展示

push 类推送业务（峰值流量->削峰）
用户访问相关业务（越平滑流量越大）
定时拉取任务（持续资源使用->错峰）

process.setMaxListeners(Infinity)隐患
load高、cpu不高 -> 查io(socket)、swap使用率

Nodejs广发证券：koa2与微服务

nodejs定位（实现API Server）

Restful Extend（Filter&Sort，Bulk Inserts，Pagination，Optional-filds）
Falcor @ Netflix
使用Koa2 async&await（异步，错误处理）koa-adapter
接口验证与数据验证 koa-validate&joi(数据验证)

日常

es2015使用
npm scripts（npm-check）
入库前检查使用husky检查，
测试覆盖（经常修改、复杂、多人合作）npm run coverage:lab plato（js源码可视化）

线上运行

StrongLoop 性能优化系列文章
上线准备（Event Loop监控，通过环境变量与信号来调整log级别，异常重启比忽略好）
支持几千几万的流量（request-debug）
docker运维，镜像部署方便，链路监控（Zebking）

TypeScript在Nodejs应用

techird.com

2016-03-20

docker常用操作总结

1.安装注意

不要直接用apt-get安装docker， apt-get安装的版本有些低。安装用curl -sSL https://get.docker.com/ubuntu/ | sudo sh可以安装最新版
docker对linux内核版本有要求，内核版本不能太低，如果太低会导致docker的一些功能不能使用，比如docker exec命令在低版本的linux内核下不能用，运行linux命令uname -r可以查看linux内核版本， docker官方文档说linux内核版本不能低于3.13，升级linux内核：sudo apt-get install linux-image-generic-lts-trusty手动升级方法：高版本的linux内核不支持aufs的存储类型，建议用devicemapper存储类型。
docker在mac下改用docker-machine，弃用boot2docker用户接口,执行eval "$(docker-machine env docker-vm)"之后即可正常使用docker

2.封装原则

容器要有专职，尽量一个容器只有一个服务，原则上说一个进程就一个容器，不要让一个容器里面有多个进程，进程越大，耦合性越大。
容器内可以用supervision管理进程，防止进程异常退出。
环境变量作为容器配置项，Dockerfile中可以用ENV设置环境变量， docker run命令可以用 -e 设置环境变量。注意这里设置的环境命令都是root用户的。如果想让Apache用户也使用这些环境变量，执行下面shell命令env | grep JD_ | sed "s/^/export /g" >> /etc/apache2/envvars表示以JD_开头的环境变量都设置为Apache的环境变量。

3.docker的坑

最坑的 –link 链接容器。用docker自带的–link把多个容器链接在以前，有重启或升级的问题，比如很多容器都依赖于 db 这个容器，然后db容器重启了，重启时docker分配的ip会变，导致其他依赖于db的容器都要重启。–link 链接的容器还有启动顺序的问题，需要先启动db容器再启动其他依赖于db的容器，这样导致 –link和–restart=always 不能一起用，如果一起用会发现宿主机重启了， docker容器并没有全部重启，因为这时候docker容器是同时被启动的，并不知道启动顺序。最后决定不用 –link 链接容器了。另外有两种链接容器的方法，一种是给容器设置固定ip ，这个方法比较复杂：另外还有一种简单的链接方式，可以用宿主机的端口链接，比如一个mysql容器，先设置宿主机的3306端口映射到mysql容器中。然后查宿主机的内网ip ，用ifconfig 查，eth0的网卡可以看见内网ip，假设内网ip为10.128.130.175 ， docker容器是可以访问这个宿主机内网ip的，这样其他容器要链接mysql容器，链接数据库时链接10.128.130.175:3306 即可。我们可以在docker run启动容器时用–add-host参数为容器设置一个hosts 。这样容器内代码可以用指定的域名去访问数据库，不用关心内网ip的变化。
pid的问题。docker容器中的进程有时会生成pid文件，比如Apache进程会生成的pid文件为 /var/run/apache2/apache2.pid ，当进程启动时，这个pid文件就存在，当进程退出时，这个pid文件也会被删除，我们把正在运行的容器用docker commit 提交为镜像时会把pid文件也提交到镜像中，这样从新镜像运行容器时，容器可能因为已经存在pid文件而无法启动。以Apache为例，可能就会报 “httpd(pid 1) ready runing” 之类的错误，报错告诉你httpd正在运行，但其实并没有运行只是存在pid文件而已。所以最好是用docker stop 把容器停掉，再用docker commit 创建镜像。
pid的问题还可能会出现在docker run时设置–restart=always 参数的时候，设置了此参数容器退出了会自动重启，宿主机重启了容器也能自动重启。但是容器在重启的时候很容易pid文件存在。pid文件存在时进程会自动退出，但又因为设置了–restart=always 进程退出的那一瞬间容器又自动重启，所以容器就在那里不断的退出再自动重启退出再自动重启。此时运行命令 docker ps 是能看见容器是运行中的状态。但是用 docker exec -it container_name bash 始终进不了容器，会报如下错误：
Cannot run exec command 0eb8e17609dd78c9137c62d94cfaa62795de161d643fc3cb00387b60f11090be in container 8837b983fe2f08f5f3b9999259d5f255a83774b19282b6f9c21a9d688f7f7f2a: No active container exists with ID 8837b983fe2f08f5f3b9999259d5f255a83774b19282b6f9c21a9d688f7f7f2a
No active container exists with ID 这句的意思是说找不到有效的容器。但是docker ps又看见容器是在运行中，为什么会找不到有效的容器？这是因为这个容器现在其实一直在不断重启中，所以进不去。

解决方法，可以在容器启动命令脚本（如 /run.sh）中加上一句删除pid文件的代码，如rm /var/run/apache2/apache2.pid这样在启动进程之前强制删除了pid文件，就不会重复重启了。
docker容器的hosts文件。
在正在运行的容器用docker exec 进入修改 /etc/hosts 文件，这个容器被重启后会发现 hosts文件会被还原。所以不要直接修改hosts文件，需要增加hosts ，在docker run时用 –add-host 参数。
虚拟目录不会提交到镜像
Dockerfile 中 VOLUME 指定的目录或 docker run 时 -v 参数指定的目录，在docker commit 时不会提交到镜像中。如果-v 参数指定的容器内的目录原本有文件，原本的文件都会被删除，只存在宿主机目录的文件。

4.docker容器的重启

容器一个容器运行中apache而我们要重启Apache，应该怎么重启？可能新手会docker exec -it container_name bash进入容器，然后运行service apache2 restart启动Apache，这样是不能启动apache的，只会把容器停止掉。因为容器的主进程就是Apache ，主进程退出时会退出容器，在重启apache的时候主进程先退出了，这时候docker容器也跟着退出了，所以Apache不会重启。要重启Apache 用docker命令：docker restart container_name

5.退出容器的方法

如果是docker run运行一个容器，没有加 -d 参数让它后台运行，这时候 ctrl+c 退出进程也会让容器停止，如果先退出但不停止容器可以ctrl+p然后ctrl+q

6.Dockerfile编写技巧

将Ubuntu的源设置为国内的源，这样安装软件会快很多RUN sed -i "s/archive.ubuntu.com/mirrors.163.com/g" /etc/apt/sources.list
RUN

Dockerfile 中可以RUN执行系统命令创建镜像。不能用RUN命令来常驻进程。比如不能运行RUN gearmand -d。

ONBUILD

ONBUILD修饰的命令在子Dockerfile文件中也会被执行，举例说明：
一个Dockerfile中有ONBUILD命令，如ONBUILD ADD . /app/src，运行docker build -t Image_name .创建一个名为Image_name的镜像。另外在创建一个Dockerfile ，第一个行是FROM Image_name现在这个Dockerfile是继承于前一个Dockerfile的，现在这个Dockerfile在build时会执行他父Dockerfile的ONBUILD命令，所以现在这个Dockerfile在build时也会执行 ADD . /app/src 这个命令。

ENTRYPOINT

感觉 ENTRYPOINT 会比 CMD 更省资源， ENTRYPOINT 使用时用数组形式。如：
entrypoint ["/init.sh", "/usr/bin/supervisord", "-n", "-c", "/etc/supervisord.conf"]
/init.sh是一个初始化脚本，初始化脚本内容大概为：

!/bin/bash
set -e
# 执行一些初始化代码
exec“$@”

最后要跟上exec"$@"，这样才能让init.sh 脚本后的supervisord被执行。

.dockerignore文件中列的文件不会被 ADD或COPY 指令添加到容器中。

7.好用的docker镜像

jwilder/nginx-proxy 这是一个nginx反向代理。
启动nginx反向代理：
docker run --name nginx -d -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock -t --restart=always jwilder/nginx-proxy
再启动其他容器，如：
docker run -e VIRTUAL_HOST=yourdomain.com -d tutum/apache-php
nginx的容器会监听其他容器的启动，并根据VIRTUAL_HOST设置域名。这样可以通过 yourdomain.com 访问刚才启动的容器中的网站了。
tutum/apache-php 这个镜像是一个好用的apache环境。