本周开始除了每日的微信公众号闲来无事的阅读，周末时候再加入些以前知乎或微博收藏的文章来阅读，做到慢慢消化些碎片知识吧。

星期日（知乎特别篇）：

C++的奇特写法int b = 4[a];，可以用来做type trait/constraint，用来判断一个类型到底是一个重载了[ ](取下标)操作符的用户定义的类（比如vector），还是一个原生的数组或指针。当你的模板希望只处理原生数组或指针，而不希望处理实现了取下标操作的类（比如vector)的时候，可以使用这个技巧。这时编译会报错，实际上这个特性是从 C 继承的。

原文链接：有哪些能炫技的代码写法？

周一：

梳理了下实现一个ChatBot的核心技术要点：

1. 语言模板引擎：action->template，倒排索引加速template检索
2. 对话配置系统：会话主题、会话树及跳转

其中框架的关键是对话配置系统，需要实现：intercept会话拦截、match 匹配了哪些模板或算法分类器、chain_type节点类型、msg 应答的语句包含format_class或query_class来实现复杂查询或应答的设置、step 表示当前处于会话的那个节点，这个节点处理完后的下一个节点会是target_step。

原文链接：ChatBot Framework开发实践

周二：

感觉这篇文章是发现了区块链上的数据金矿，思路很有意思，统计分析真的可以做很多事情。

既然 eth的所有数据都是公开的，那我是不是可以把所有的链上游戏的交易数据都拿下来，然后看看，

针对所有游戏来说
有多少人玩了区块链游戏？
有多少人赚了钱？
有多少人亏了钱？
针对某款游戏来说
有多少人玩过？ 每天的日活是多少？ 有多少人赚了钱？ 有多少人亏了钱？

通过这些数据，那么我也就能分析出来

这款游戏我现在玩能赚到钱么？
哪些游戏可能有猫腻？
哪些游戏一玩就亏钱？
甚至还可以跟踪大佬（也就是赚钱最多的人)
看看他在玩什么。这样我们就可以愉快的”玩游戏”了

原文链接：发现区块链好项目

区块链游戏目前本质是获得一堆ERC721数字资产，区块链游戏的核心在于可以在链上验证查询，过程透明。比如在cryptokitties中，团队表示0代猫（gen 0）只会有45000只，那么这个数字我们可以在智能合约中进行核查。多数游戏目前感觉缺少好玩的地方，吸引人的核心仍然是数字资产交易赚钱。

区块链游戏缺点在于无法及时交互、发送指令费用较高（进行的一次战斗都需要耗费10元人民币）、开发环境不成熟

原文链接：花了600万玩区块链游戏，我觉得智能合约还是有点靠谱的

周三：

形成了一篇总结文章：Zookeeper系统设计的缺陷

周四：

修改WordPress插件Post-series的bug

周五：

据称成熟度和企业级特性要远远强于Spring Cloud Config 产品，和Dubbo看来是竞争关系。

不同于Dubbo的是其本身内部也是微服务架构部署，Client/ConfgService/AdminService/Portal 是 Apollo 的四个核心微服务模块，相互协作完成配置中心业务功能，NginxLB /MetaServer/Eureka是辅助微服务之间进行服务发现的模块。部署估计会比较麻烦，不过可扩展性强，理论上一套就可以为多个环境服务（实际估计还是很难执行）。

架构里面服务发现既采用 Eureka 注册中心式的服务发现，也采用 NginxLB 的集中 Proxy 式。这块架构看起来复杂，实际就是用简单的软代理来提升服务中心的可扩展性。

原文链接：携程Apollo配置中心架构深度剖析

SOFA从一开始的开发框架演进到目前的蚂蚁内部的基础中间件，不断向微服务化演进。从单体架构转到服务化架构，再往前演进到单元化架构，再往前演进到弹性架构。

SOFA在推微服务的Service Mesh方向，个人理解Service Mesh就是为Dubbo这类软件起了个专业名字，做的还是服务注册发现，服务代理负载均衡等内容，只是功能更完备包括：熔断等异常处理、监控、组件升级、多语言支持等，抽象就是一个服务通信层的标准。但是Mesh化感觉又不限于此，是将更多的框架内容做成单独的服务部署，本身好像是微服务上面的一层业务抽象，好处还是具体业务与基础框架的解耦。

以前是开发出来一个开发框架，开发团队要用我这个框架，框架升级的时候要追着开发团队说，你要把我的版本给升了。使用Mesh之后，我们的协作方式就很简单，现在我们去和 SRE 确定说，我发现我有这个Bug，然后我要去做升级了。我们和SRE确定之后，我们就开始去做一个灰度升级，灰度完成之后，就可以去做全面的升级。这个周期是非常快的，我们这个版本现在推到二三十个应用当中，只需要一周的时间就够了，之前二三十个系统起码要好几个月。

原文链接：蚂蚁金服研发的金融级分布式中间件SOFA背后的故事

周六：

Ceph的节点分布CRUSH算法（一个类似一致性哈希的节点分布算法）在学术界还颇受好评，但是在工业界却成为一个灾难。这篇文章就总结了该算法导致多种问题：扩容粒度不好确认、扩容时的再平衡时间可能不幸很长、扩容时大量的资源必须浪费（资源可利用率不高，50%就必须扩容否则很可能无法继续服务）、缺少的元数据信息也为运维造成麻烦。

原文链接：Ceph运维告诉你分布式存储的那些“坑”

chao

微信支付

支付宝