迷你书地址：http://www.infoq.com/cn/minibooks/architect-201807
Spark 团队开源新作：全流程机器学习平台 MLflow
An open source platform for the complete machine learning lifecycle
这是一个能够覆盖机器学习全流程（从数据准备到模型训练到最终部署）的新平台，旨在为数据科学家构建、测试和部署机器学习模型的复杂过程做一些简化工作。
- 开放接口：MLflow 可与任何机器学习库、算法、部署工具或编程语言一起使用。它基于 REST API 和简单的数据格式（例如，可将模型视为 lambda 函数）而构建，可以使用各种工具，而不只是提供一小部分内置功能。用户可以很容易地将 MLflow 添加到现有的机器学习代码中，并在组织中共享代码，让其他人也能运行这些代码。
- 开源：MLflow 是一个开源项目，用户和机器学习库开发人员可以对其进行扩展。
目前在 alpha 版，包括三个组件：
- MLflow 的跟踪组件提供了一组 API 和用户界面，用于在运行机器学习代码时记录参数、代码版本、度量指标和输出文件，以便在后续进行可视化。
- MLflow 的项目组件提供了一种用于打包可重用代码的标准格式。项目可以是一个包含代码的目录或 Git 仓库，并使用一个描述符文件来描述依赖关系以及如何运行代码。MFflow 项目通过一个叫作 MLproject 的YAML 文件进行定义。MLflow 将自动为项目设置合适的环境并运行它。
- MLflow 的模型组件提供了一种将机器学习模型打包成多种格式的规范，这些格式被称为“flavor”。MLflow 提供了多种工具来部署不同 flavor 的模型。每个 MLflow 模型被保存成一个目录，目录中包含了任意模型文件和一个 MLmodel 描述符文件，文件中列出了相应的 flavor。
一个快速的示例：
https://www.mlflow.org/docs/latest/quickstart.html
Google 发布Flutter Release Preview 1
Flutter 是 Google 用以帮助开发者在 iOS 和 Android 两个平台开发高质量原生 UI 的移动 SDK。
独家揭秘：腾讯千亿级参数分布式ML 系统无量背后的秘密
模型的生产和使用过程，大致分为几个步骤：
- 日志采集与样本生成。通过收集用户的线上行为信息，生成模型需要的样本。这些样本可以被存储起来用于离线训练，也可以使用流式数据的方式推送给在线训练集群。
- 模型训练。有了样本之后，在训练集群中训练出具体的模型。开发人员通过调整的超参数或模型结构来获取好的模型。
- 模型评估。在模型被放到线上服务之前，需要对模型进行一些评估工作。
-
模型上线预测。无量系统目前包括以上步骤中的模型训练，模型评估和上线预测。
几个步骤
参数服务器架构：
- 有一种新的角色 Server，专门用于分布式地存储模型参数，并进行参数的更新计算。这使得能够训练的模型规模不再受限于单机的内存大小，同时将多个 worker 节点的参数请求分摊到多个 server 上，减少了单个 server 上因参数和梯度传输导致的网络瓶颈。
- 负责计算的 Worker 节获取参数的方式是 pull 方式。由于不是被动的等待广播参数，pull 方式使得 worker 节点可以根据训练数据的需求来获取参数。尤其是在推荐场景下，样本都是非常稀疏的。
阿里巴巴为什么不用 ZooKeeper 做服务发现？
2011 年，阿里巴巴开源 Dubbo，为了更好开源，需要剥离与阿里内部系统的关系，Dubbo 支持了开源的 ZooKeeper 作为其注册中心，后来在国内，在业界诸君的努力实践下，Dubbo + ZooKeeper 的典型的服务化方案成就了 ZooKeeper 作为注册中心的声名。
让我们回归对服务发现的需求分析，结合阿里巴巴在关键场景上的实践，来一一分析，一起探讨为何说 ZooKeeper 并不是最合适的注册中心解决方案。
注册中心是 CP 还是 AP 系统?
-
数据一致性需求分析
注册中心最本质的功能可以看成是一个 Query 函数Si = F(service-name)，以service-name为查询参数，对应的服务的可用的endpoints (ip:port)列表为返回值。
先来看看关键数据endpoints (ip:port)不一致性带来的影响，即 CAP中的 C 不满足带来的后果 :
如上图所示，如果一个svcB部署了 10 个节点 (副本 /Replica），如果对于同一个服务名svcB，调用者svcA的 2 个节点的 2 次查询返回了不一致的数据，例如:S1 = { ip1,ip2,ip3...,ip9 },S2 = { ip2,ip3,....ip10 }, 那么这次不一致带来的影响是什么？相信你一定已经看出来了，svcB的各个节点流量会有一点不均衡。
ip1和ip10相对其它 8 个节点{ip2...ip9}，请求流量小了一点，但很明显，在分布式系统中，即使是对等部署的服务，因为请求到达的时间，硬件的状态，操作系统的调度，虚拟机的 GC 等，任何一个时间点，这些对等部署的节点状态也不可能完全一致，而流量不一致的情况下，只要注册中心在 SLA 承诺的时间内（例如 1s 内）将数据收敛到一致状态（即满足最终一致），流量将很快趋于统计学意义上的一致，所以注册中心以最终一致的模型设计在生产实践中完全可以接受。 -
分区容忍及可用性需求分析
考虑一个典型的 ZooKeeper 三机房容灾 5 节点部署结构 (即 2-2-1 结构)，如下图:
当机房 3 出现网络分区 (Network Partitioned) 的时候，即机房 3 在网络上成了孤岛，我们知道虽然整体 ZooKeeper 服务是可用的，但是节点ZK5 是不可写的，因为联系不上 Leader。
也就是说，这时候机房 3 的应用服务svcB是不可以新部署，重新启动，扩容或者缩容的，但是站在网络和服务调用的角度看，机房 3 的svcA虽然无法调用机房 1 和机房 2 的svcB, 但是与机房 3 的svcB之间的网络明明是 OK 的啊，为什么不让我调用本机房的服务？
现在因为注册中心自身为了数据一致性（C）而放弃了可用性，导致了同机房的服务之间出现了无法调用，这是绝对不允许的！可以说在实践中，注册中心不能因为自身的任何原因破坏服务之间本身的可连通性，这是注册中心设计应该遵循的铁律！
通过以上我们的阐述可以看到，在 CAP 的权衡中，注册中心的可用性比数据强一致性更宝贵，所以整体设计更应该偏向 AP，而非 CP，数据不一致在可接受范围，而 P 下舍弃 A 却完全违反了注册中心不能因为自身的任何原因破坏服务本身的可连通性的原则。
服务规模、容量、服务联通性：
当数据中心服务规模超过一定数量，作为注册中心的 ZooKeeper 很快就会不堪重负。
在服务发现和健康监测场景下，随着服务规模的增大，无论是应用频繁发布时的服务注册带来的写请求，还是刷毫秒级的服务健康状态带来的写请求，还是恨不能整个数据中心的机器或者容器皆与注册中心有长连接带来的连接压力上，ZooKeeper 很快就会力不从心，而 ZooKeeper 的写并不是可扩展的，不可以通过加节点解决水平扩展性问题。
注册中心需要持久存储和事务日志么？
需要，也不需要。
我们知道 ZooKeeper 的 ZAB 协议对每一个写请求，会在每个 ZooKeeper 节点上保持写一个事务日志，同时再加上定期的将内存数据镜像（Snapshot）到磁盘来保证数据的一致性和持久性，以及宕机之后的数据可恢复，这是非常好的特性，但是我们要问，在服务发现场景中，其最核心的数据 - 实时的健康的服务的地址列表真的需要数据持久化么？
对于这份数据，答案是否定的。因为在服务发现中，服务调用发起方更关注的是其要调用的服务的实时的地址列表和实时健康状态，每次发起调用时，并不关心要调用的服务的历史服务地址列表、过去的健康状态。
使用 ZooKeeper 作为服务注册中心时，服务的健康检测常利用 ZooKeeper 的 Session 活性 Track 机制 以及结合 Ephemeral ZNode 的机制，简单而言，就是将服务的健康监测绑定在了 ZooKeeper 对于 Session 的健康监测上，或者说绑定在 TCP 长链接活性探测上了。
这在很多时候也会造成致命的问题，ZK 与服务提供者机器之间的 TCP 长链接活性探测正常的时候，该服务就是健康的么？答案当然是否定的！注册中心应该提供更丰富的健康监测方案，服务的健康与否的逻辑应该开放给服务提供方自己定义，而不是一刀切搞成了 TCP 活性检测！健康检测的一大基本设计原则就是尽可能真实的反馈服务本身的真实健康状态，否则一个不敢被服务调用者相信的健康状态判定结果还不如没有健康检测。
向左走，向右走：
阿里巴巴是不是完全没有使用 ZooKeeper？并不是！
熟悉阿里巴巴技术体系的都知道，其实阿里巴巴维护了目前国内乃至世界上最大规模的 ZooKeeper 集群，整体规模有近千台的 ZooKeeper 服务节点。
如果以我们近 10 年在各个业务线和生产上使用 ZooKeeper 的实践，给 ZooKeeper 用一个短语评价的话，那么我们认为 ZooKeeper 应该是 “The King Of Coordination for Big Data”！
- 在粗粒度分布式锁，分布式选主，主备高可用切换等不需要高 TPS 支持的场景下有不可替代的作用，而这些需求往往多集中在大数据、离线任务等相关的业务领域，因为大数据领域，讲究分割数据集，并且大部分时间分任务多进程 / 线程并行处理这些数据集，但是总是有一些点上需要将这些任务和进程统一协调，这时候就是 ZooKeeper 发挥巨大作用的用武之地。
- 但是在交易场景交易链路上，在主业务数据存取，大规模服务发现、大规模健康监测等方面有天然的短板，应该竭力避免在这些场景下引入 ZooKeeper，在阿里巴巴的生产实践中，应用对 ZooKeeper 申请使用的时候要进行严格的场景、容量、SLA 需求的评估。
所以可以使用 ZooKeeper，但是大数据请向左，而交易则向右，分布式协调向左，服务发现向右。
Airbnb 弃用之后，我们还应该用React Native 吗？
https://facebook.github.io/react-native/
Build native mobile apps using JavaScript and React.
React Native lets you build mobile apps using only JavaScript. It uses the same design as React, letting you compose a rich mobile UI from declarative components.
- 你使用React Native 从头开始构建一个新应用，并希望使用JavaScript 开发所有的东西（适合用）
- 你正在使用 React Native 开发少量的二级页面（适合用）
- 你有一个使用 Swift/Java/Objective-C/Kotlin 开发的应用程序，现在你想要使用 React Native 开发其中的一部分
- 你的公司里有一个 iOS 团队和一个 Android 团队
从宏观角度来看，使用像 JavaScript 这样的脚本语言来开发移动应用程序几乎是不可避免的，因为使用 Swift/Objective-C/Java/Kotlin 这些语言来开发 UI 效率太差。此外，每个应用程序都要开发两次（或者如果算上Web 就是三次），这根本就是个大麻烦。无论是 React Native、Flutter 还是其他羽翼未满的新产品，它们也都大致如此。
如何“计算”CEPH 读写性能
https://ceph.com/
http://ceph.org.cn/
中心化or 去中心化？聊聊交易所的辩证发展
现阶段，数字货币的交易场所有3种：
- 中心化交易所
- 去中心化交易所
- 场外 OTC 点对点交易。场外点对点交易因为点对点交易带来的撮合效率低下，基本上只作为大额交易和规避法律风险的交易途径存在。当前的主流交易都是在中心化交易所内完成的。
目前来看，去中心化交易所是作为中心化交易所的补充存在的。原因是很多小币种因各种原因无法挂牌主流的中心化交易所而选择在去中心化交易所挂牌，或是某些新发行的币种在登陆主流的中心化交易所之前会被去中心化交易所抢先挂牌。
预计在区块链底层基础设施完善前，市场依旧会是由主流交易所主导，只有当撮合效率、交易成本以及用户学习成本能与中心化交易所相似时，去中心化交易所才有可能占据更大的交易份额。
得出上述结论的具体原因，要从用户需求的角度来看。用户“交易”的目的是将自己手中的币以一个能接受的价格兑换成另一种币。交易能否达成，取决于两个方面：效率和代价。
效率，是指用户想交易时，能不能快速找到对手方，能不能快速找到理想的价格，能不能快速完成交易，交易完成后能不能快速交割；代价包括行业的共识推广代价，用户的教育学习代价，以及用户在每一笔交易的背后，付出的显性及隐性代价。
去中心化交易所，一般都采用智能合约方式编写交易撮合和清结算逻辑，并且将合约代码开源出来供所有人查看。这样的话，代码是公开的，又是运行在链上，就可以在一定程度上保障用户的资金安全，防止内部交易。
但是，去中心化交易所也存在不稳定因素。为了获得用户信心，合约代码是需要开源的，谁都可以拿这份代码资金单独部署一套交易所，长期下去会导致多个交易平台出现，多个交易平台的竞争将导致市场流动性的分割，进而导致单个交易市场的深度不足，影响到参与用户的交易机会成本，也会带来价格不稳定的因素。
去中心化交易所因为区块链本身的特性和不同去中心化交易所的技术方案不同，目前很难在技术层面集中解决去中心化交易所带来的流动性分割的问题，一般是通过市场自动平衡价格的力量来解决。
