迷你书地址：http://www.infoq.com/cn/minibooks/architect-201808

Kotlin 生态调查结果出炉：超过 6 成的开发者用过 Kotlin 了

Stream 从 Python 切换到 Go 的原因

Stream 是一套用于构建、伸缩、定制化新闻源和活动流的API。

Go最大的卖点在于它的性能，无论在运行还是编译时它都有突出的性能优势。它与Java或者C++的运算速度几乎相当。在实际使用中，我们发现它比Python大约快30倍。

用Go编写的Go编译器也非常快。Stream中最复杂的微服务就采用Go编写，它的编译时间仅仅需要6秒，Java和C++等工具链则慢得多，快则一分钟，慢则数小时。

Go在语言层面通过goroutine和channel支持了并发。

Go有一句重要的格言，即：不要通过共享内存来通信，相反，通过通信来共享内存 。

Go有助于开发微服务。谷歌的protobuf和gRPC是微服务间通信的基础，Go对它们提供了很好的支持。作为开发人员，我们只需在清单文件中定义一项服务，工具便会自动生成客户端和服务器端代码，并且保证代码的高性能以及很低的网络负载。此外，清单文件还可以被其他语言用来生成他们自己的客户端和服务器端代码。

需要注意的是，对于某些适合使用Python开发的模块，Stream仍然使用Python。例如，我们的仪表板、网站以及用于个性化订阅的机器学习都使用Python实现，因为Python提供的这些工具更好用。我们不会马上完全弃用Python，但是对于性能要求较高的代码，我们今后会使用Go来编写。

腾讯大规模分布式机器学习系统无量是如何进行技术选型的？

GitHub 的 MySQL 高可用性实践

我们的集群使用经典的主-副设置，其中集群的单个节点（主节点）能够接受写操作。其它集群节点（副节点）异步更新主节点的变更并服务我们的读流量。

为了支持写操作，我们显然需要有一个可用的写节点，即集群的主节点。但同样重要的是，我们需要能够识别，或者发现，那个节点。
遇到一个故障时，比如主节点崩溃的场景，我们必须确保存在一个新的主节点，并且能够快速通告其身份。
检测故障、运行故障恢复以及通告新主节点身份所花费的时间组成了总宕机时间。

orchestrator MySQL 集群管理工具

https://github.com/github/orchestrator
orchestrator is a MySQL high availability and replication management tool, allowing for:

• Discovery
  orchestrator actively crawls through your topologies and maps them. It reads basic MySQL info such as replication status and configuration.
• Refactoring
  orchestrator understands replication rules. It knows about binlog file:position, GTID, Pseudo GTID, Binlog Servers.
  Refactoring replication topologies can be a matter of drag & drop a replica under another master. Moving replicas around is safe: orchestrator will reject an illegal refactoring attempt.
• Recovery
  orchestrator uses a holistic approach to detect master and intermediate master failures. Based on information gained from the topology itself, it recognizes a variety of failure scenarios.
  Recovery process utilizes orchestrator's understanding of the topology and of its ability to perform refactoring. It is based on state as opposed to configuration: orchestrator picks the best recovery method by investigating/evaluating the topology at the time of recovery itself.

远离基于 VIP 和 DNS 的服务发现

在我们之前的迭代中，我们使用：

• orchestrator用于故障监听和故障恢复
• VIP和DNS用于发现主节点

在那个迭代中，客户端通过使用一个名称，例如 mysql-writer-1.github.net 来发现写节点。这个名称解析为主节点获取的虚拟IP地址（Virtual IPaddress，VIP）。
因此，平常的时候，客户端会只解析这个名称，连接解析到的IP地址，然后找到正在另一端监听的主节点。
当发生一个主节点故障事件时，一个新的服务器（副本之一），必须被提升为主节点。
orchestrator将监测到一个故障，提升一个新的主节点，然后采取行动重新分配名称/VIP。客户端并不准确地知道主节点的身份：它们所知道的只是一个名称，而那个名称现在一定解析到了新的主节点。

GitHub 的高可用性方案：orchestrator、Consul 和 GLB

• orchestrator用来运行故障监听和故障恢复。
• Hashicorp公司的用于服务发现的Consul。
• 作为客户端和写操作节点之间的代理层的GLB/HAProxy。
• 用于网络路由的anycast。

一个普通的工作流：

• 平常，App通过GLB/HAProxy连接到写操作节点。

• App不会意识到主节点的身份。和以前一样，它们使用一个名称。例如，cluster1的主节点会是 mysql-writer-1.github.net。然而，在我们目前的设置中，这个名称会被解析到一个任播（anycast）IP。

• 通过anycast方法，这个名称在任何地方都被解析为相同的IP，但是流量会根据客户端位置分别进行路由。特别地，我们的每个数据中心都在多个区域部署了GLB（我们的高可用负载均衡）。到 mysql-writer-1.github.net 的流量通常路由到本地数据中心的GLB集群。因此，所有的客户端都是由本地代理服务的。

• 我们在HAProxy上运行GLB。我们的HAProxy有写操作池：每个MySQL集群一个池，而每个池有一个后端服务器作为这个集群的主节点。所有的GLB/HAProxy区域在所有的数据中心都拥有相同的写操作池，而它们都指向这些池中完全相同的后端服务器。因此，如果一个App想要向mysql-writer-1.github.net写入，这跟它与哪个GLB服务器连接无关。它将总是被路由到cluster1主节点。

• 就App而言，服务发现在GLB终止，并且永远不需要重新发现。流量都是在GLB上路由到正确的目的地。

运满满的技术架构演进之路

• 第一次迭代是“服务化拆分”。
• 第二次迭代是“稳定性保障体系与业务服务中台”。

运满满使用 Xgboost 来预测车 - 货的基础相关性，实际是一个 CTR 和 CVR 混布模型，其中部署了在线实时系统，自研了一套基于 FTRL 算法的在线学习算法，将用户实时的行为数据结果和 Xgboost 的离线结果共同训练而得，点击预测的准确率超过 90%。

百度智能运维的技术演进之路

百度提出了指导智能运维的三个原则：

• 书同文：一致运维“语言”；如运维应用、服务、机房、集群的定义；
• 车同轨：一致运维“方法”；如扩缩容执行、流量切换执行；
• 行同伦：一致运维“模式”；如故障诊断策略、弹性伸缩策略、流量调度策略。

针对不同的场景提供不同的异常检测算法解决人工配置困难和监控漏报&误报的问题。

• 周期波动的数据，典型场景：广告收入、搜索流量等。算法：同比基准值检测
• 关心突变的数据，典型场景：交易订单、流水等。算法：环比基准值检测
• 关心是否超出了一定波动范围的数据，典型场景：pvlost。算法：基于概率的恒定阈值检测。

面向大规模 AI 在线推理的可靠性设计