wechat后端读后感

基于许家滔10/17/2018在架构师大会上的presentation，link

Summary:

得着：

1. 微信的后台系统从high-level看很清晰（也加上是图画的好），接入层BFF分移动端和PC端，业务逻辑收发消息和朋友圈，登录都是常用功能，收藏功能没有试过。其实他不知道是不是故意漏了支付功能，和搜索功能。再下层的业务逻辑类似中台（mid-end）。提供技术切入的基础设施/基础业务（从基础设施定制化的业务components），比如账号服务，contact服务，消息服务，登录服务，收藏服务。最底层是定制的存储PaxosStore和WFS。
2. 微信的高可用其实需要五个9，99.999%。一年故障时间5分钟。因为微信支付属于金融应用了，5个9也是正常需求。
   2.1 应用跨数据中心，workload自动均衡
   2.2 一个多主集群系统（Multi-master， active-active）
3. PaxosStore是主要的后台存储系统，采用非租约的Paxos交互实现同步复制，在数据分区内部实现完整ACID语义。
4. 2017年会议论文 http://www.vldb.org/pvldb/vol10/p1730-lin.pdf， 和开源代码 github.com/tencent/paxosstore
5. Paxos整体架构是一个两地三中心的。AA两个主要中心，第三个中心是只读副本。（理论上Paxos可能可以支持多中心）。第三个中心作为Listener，不投票。
6. 本地存储引擎是在Bitcask, 或LSM的基础（也许是leveldb，Rocksdb？）上提供各种KV，小表tablelet，大表，集合队列。
7. 之上的同步复制引擎由Paxos键值和Paxos log组成。
8. 数据分布与复制。分片不叫shard/partition，叫Set。采用了Consistent hashing, 上下层调用按照Set对齐。
9. 上海，深圳，天津组成三角。2000km距离。读是本地，写有30ms-40ms的延迟
   10.仿照Google的风格，在分布式存储的基础上实现了 更多的组件，比如微信Chubby, 分布式文件系统，表格。
10. 微信chubby，支持分布式锁。基于paxos同步。并且在Paxosstore上构建，代码量减少。
11. 微信分布式文件系统WFS对应HDFS，namemode基于PaxosStore，DataNode基于Raft同步，文件AppendWrite，和随机读。
12. 微信分布式表格，对应HBASE。通过Chubby实现锁，通过WFS提供文件，把Tablets组织起来。
13. DevOps流程，发布一个二进制，到几千台机器，内部实现了一套BT协议。
14. PaxosStore是核心应用，为性能采用多进程。其它应用采用多线程。Both采用类似协程coroutine的机制（用户态线程，保存上下文）提高并发。协程服务，同步编程，异步执行。不需要自己设计各种状态保存数据结构，临时状态/变量在一片连续的栈分配。库叫做Libco。co_create/co_resume/co_yield, cond/signal
15. Libco协程框架，CO1网络调用，注册网络事件，co_yield。事件发生后，co_resume。
16. Stack size 128K，支持单机千万级co-routine.
17. PaxosStore和Libco是底层架构的关键技术，其上构建组件。