IT瘾在线推荐

“AI垃圾”泛滥，最后的防线在人类自身-新华网

Thu, 29 Jan 2026 16:18:40 CST

如今的互联网上充斥着大量由AI工具生成的劣质信息。图片由AI生成

　　如今的互联网上，看似信息海量，但也充斥着大量单调、重复且缺乏质量的内容。

　　美国《纽约时报》网站在12月8日的报道中指出，当前网络，尤其社交平台正泛滥一种被称为“AI垃圾”（AI Slop）的内容。英国《新科学家》网站10日也发表文章称，今年，许多人感觉仿佛置身于一堆华而不实的“AI垃圾”中。英国《经济学人》杂志更是将“Slop”一词选为2025年度词汇。这类错漏百出、古怪甚至令人尴尬的内容遍布各平台，也在悄然侵蚀着人们的思想。

　　“假冒伪劣”信息充斥网络

　　“Slop”原指“猪食”“泔水”等廉价、粗糙、缺乏营养之物。如今，借由AI技术的浪潮，一些如同“Slop”的垃圾内容正在互联网上肆意蔓延。

　　“AI垃圾”特指由AI工具生成的大量劣质、重复或无意义的文字、图像或视频，常见于社交媒体和自动化内容农场。

　　美国科技网站CNET在10月28日的报道中提到，如今社交平台上“AI垃圾”五花八门：OpenAI的Sora可让人几秒内生成滑稽荒诞的视频；LinkedIn上满是由AI包装的“专家箴言”，例如“有时领导力就是保持沉默的能力”；谷歌搜索结果也宛如AI杂货铺，竟会出现“姜黄能治愈心碎”这类无稽之谈。

　　“AI垃圾”与“深度伪造”或“AI幻觉”虽有重叠，却并不相同，其区别在于意图与质量。

&sp; “深度伪造”指利用AI伪造或篡改影音，目的在于欺骗，从虚假政治演讲到诈骗语音皆属此类，其关键在于以假乱真。“AI幻觉”则属技术错误，聊天机器人可能引用不存在的研究，或编造法律案例，本质是模型在预测词语时出现了偏差。而“AI垃圾”范围更广，也更随意：当人们用AI批量生产内容却疏于核对准确性与逻辑时，便会产生此类垃圾。它们堵塞信息渠道，抬高广告收益，用重复无意义的内容占据搜索结果。其错误源于敷衍，而非欺骗或技术局限。

　　技术滥用与贪婪心态成推手

　　“AI垃圾”之所以泛滥，一方面因为AI技术日益强大且成本低廉。AI公司开发这些模型，本意是降低创作门槛，让有好点子却缺乏技能或资源的人也能制作出更优质的内容。然而，有些人却滥用AI工具海量生成文本、图片与视频，只为博取点击和广告收入。

　　随着ChatGPT、Gemini、Claude等工具，尤其是Sora、Veo这类新型生成器的出现，几秒内生成可读文本、图像与视频已成为可能。于是，内容农场应运而生。一些人发现，用AI填充网站、社交动态和YouTube频道，远比人工创作更快。

　　AI不在意真相、品位或原创性，它只关注概率。这使得“AI垃圾”易于制作，迅速传播。例如，某个YouTube频道仅凭4个视频，就积累了420万订阅和数亿播放量。

　　平台也在无形中助推此风。算法往往更看重内容的点击与互动数据，而非质量。发布越频繁，获得关注就越多，哪怕内容纯属胡扯。AI让这类操作变得易如反掌。

　　另一方面，利益亦是幕后推手。有些创作者大量发布虚假名人消息或夹带广告的标题党视频；也有人滥用AI内容误导用户，将其引向劣质网站。

　　乍看之下，“AI垃圾”似乎无伤大雅——无非是动态里几条劣质帖子，或许还能博人一笑。然而当数量爆发，一切便会不同。随着垃圾信息充斥网络，可信来源在搜索结果中排名下降，真实与虚构的界限也变得模糊。

　　这种信任危机带来切实后果：当无人能辨真假，错误信息便传得更快。

　　应珍视人类的真诚创作

　　目前尚未有完美解决方案，但一些企业已开始尝试。

　　例如，Spotify等平台开始为AI生成内容添加标签，并调整算法以降低劣质内容的推荐权重。谷歌、抖音与OpenAI等公司也承诺推出水印系统，帮助用户区分人工内容与合成内容。不过，若有人对内容进行截图、转码或改写，这些方法仍可能失效。

　　部分应对措施基于一项名为C2PA（内容来源与真实性联盟）的行业标准。该标准由Adobe、亚马逊、微软、Meta等企业共同支持，通过将元数据嵌入数字文件，记录其创建与编辑过程。若顺利推行，C2PA可帮助追溯图片、视频或文章的来源，无论其来自可信人类创作者，还是AI生成器。然而难点在于普及：元数据可能被剥离或忽略，且多数平台尚未形成一致的执行规范。

　　当然，最有效的防护，其实在于人类自身。“AI垃圾”依赖自动化生产和人们无意识地刷屏与转发——大多数人都曾有过这类体验。因此，放慢节奏、核实来源、支持那些仍坚持用心创作的作者，虽不能立竿见影，却是重要的开始。

　　垃圾泛滥在互联网世界并非新事。人们曾对抗垃圾邮件、点击诱饵、虚假信息……“AI垃圾”只是同一故事的新篇章：更快、更流畅，也更难察觉。网络能否保持其应有的品质，取决于人们是否依然珍视人类的真诚创作，而非机器的机械输出。（记者刘霞）

拔掉网线后，原本的 TCP 连接还存在吗？

Sun, 18 Sep 2022 00:00:00 CST

大家好，我是小林。

今天，聊一个有趣的问题： 拔掉网线几秒，再插回去，原本的 TCP 连接还存在吗？

可能有的同学会说，网线都被拔掉了，那说明物理层被断开了，那在上层的传输层理应也会断开，所以原本的 TCP 连接就不会存在的了。就好像，我们拨打有线电话的时候，如果某一方的电话线被拔了，那么本次通话就彻底断了。

真的是这样吗？

上面这个逻辑就有问题。问题在于，错误的认为拔掉网线这个动作会影响传输层，事实上并不会影响。

实际上，TCP 连接在 Linux 内核中是一个名为 struct socket的结构体，该结构体的内容包含 TCP 连接的状态等信息。当拔掉网线的时候，操作系统并不会变更该结构体的任何内容，所以 TCP 连接的状态也不会发生改变。

我在我的电脑上做了个小实验，我用 ssh 终端连接了我的云服务器，然后我通过断开 wifi 的方式来模拟拔掉网线的场景，此时查看 TCP 连接的状态没有发生变化，还是处于 ESTABLISHED 状态。

通过上面这个实验结果，我们知道了，拔掉网线这个动作并不会影响 TCP 连接的状态。

接下来，要看拔掉网线后，双方做了什么动作。

所以，针对这个问题，要分场景来讨论：

拔掉网线后，有数据传输；
拔掉网线后，没有数据传输；

拔掉网线后，有数据传输

在客户端拔掉网线后，服务端向客户端发送的数据报文会得不到任何的响应，在等待一定时长后，服务端就会触发 超时重传机制，重传未得到响应的数据报文。

如果在服务端重传报文的过程中，客户端刚好把网线插回去了，由于拔掉网线并不会改变客户端的 TCP 连接状态，并且还是处于 ESTABLISHED 状态，所以这时客户端是可以正常接收服务端发来的数据报文的，然后客户端就会回 ACK 响应报文。

此时，客户端和服务端的 TCP 连接依然存在的，就感觉什么事情都没有发生。

但是， 如果如果在服务端重传报文的过程中，客户端一直没有将网线插回去，服务端超时重传报文的次数达到一定阈值后，内核就会判定出该 TCP 有问题，然后通过 Socket 接口告诉应用程序该 TCP 连接出问题了，于是服务端的 TCP 连接就会断开。

而等客户端插回网线后，如果客户端向服务端发送了数据，由于服务端已经没有与客户端相同四元祖的 TCP 连接了，因此服务端内核就会回复 RST 报文，客户端收到后就会释放该 TCP 连接。

此时，客户端和服务端的 TCP 连接都已经断开了。

那 TCP 的数据报文具体重传几次呢？

在 Linux 系统中，提供了一个叫 tcp_retries2 配置项，默认值是 15，如下图：

这个内核参数是控制，在 TCP 连接建立的情况下，超时重传的最大次数。

不过 tcp_retries2 设置了 15 次，并不代表 TCP 超时重传了 15 次才会通知应用程序终止该 TCP 连接，内核还会基于「最大超时时间」来判定。

每一轮的超时时间都是倍数增长的，比如第一次触发超时重传是在 2s 后，第二次则是在 4s 后，第三次则是 8s 后，以此类推。

内核会根据 tcp_retries2 设置的值，计算出一个最大超时时间。

在重传报文且一直没有收到对方响应的情况时，先达到「最大重传次数」或者「最大超时时间」这两个的其中一个条件后，就会停止重传，然后就会断开 TCP 连接。

拔掉网线后，没有数据传输

针对拔掉网线后，没有数据传输的场景，还得看是否开启了 TCP keepalive 机制（TCP 保活机制）。

如果 没有开启TCP keepalive 机制，在客户端拔掉网线后，并且双方都没有进行数据传输，那么客户端和服务端的 TCP 连接将会一直保持存在。

而如果开启了 TCP keepalive 机制，在客户端拔掉网线后，即使双方都没有进行数据传输，在持续一段时间后，TCP 就会发送探测报文：

如果 对端是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
如果 对端主机崩溃，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后， TCP 会报告该 TCP 连接已经死亡。

所以，TCP 保活机制可以在双方没有数据交互的情况，通过探测报文，来确定对方的 TCP 连接是否存活。

TCP keepalive 机制具体是怎么样的？

这个机制的原理是这样的：

定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。

在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔，以下都为默认值：

  net.ipv4.tcp_keepalive_time=7200   
net.ipv4.tcp_keepalive_intvl=75     
net.ipv4.tcp_keepalive_probes=9

tcp_keepalive_time=7200：表示保活时间是 7200 秒（2小时），也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制
tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；
tcp_keepalive_probes=9：表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接。

也就是说在 Linux 系统中，最少需要经过 2 小时 11 分 15 秒才可以发现一个「死亡」连接。

图片

注意，应用程序若想使用 TCP 保活机制需要通过 socket 接口设置 SO_KEEPALIVE选项才能够生效，如果没有设置，那么就无法使用 TCP 保活机制。

TCP keepalive 机制探测的时间也太长了吧？

对的，是有点长。

TCP keepalive 是 TCP 层（内核态）实现的，它是给所有基于 TCP 传输协议的程序一个兜底的方案。

实际上，我们应用层可以自己实现一套探测机制，可以在较短的时间内，探测到对方是否存活。

比如，web 服务软件一般都会提供 keepalive_timeout参数，用来指定 HTTP 长连接的超时时间。如果设置了 HTTP 长连接的超时时间是 60 秒，web 服务软件就会 启动一个定时器，如果客户端在完后一个 HTTP 请求后，在 60 秒内都没有再发起新的请求， 定时器的时间一到，就会触发回调函数来释放该连接。

总结

客户端拔掉网线后，并不会直接影响 TCP 连接状态。所以，拔掉网线后，TCP 连接是否还会存在，关键要看拔掉网线之后，有没有进行数据传输。

有数据传输的情况：

在客户端拔掉网线后，如果服务端发送了数据报文，那么在服务端重传次数没有达到最大值之前，客户端就插回了网线，那么双方原本的 TCP 连接还是能正常存在，就好像什么事情都没有发生。
在客户端拔掉网线后，如果服务端发送了数据报文，在客户端插回网线之前，服务端重传次数达到了最大值时，服务端就会断开 TCP 连接。等到客户端插回网线后，向服务端发送了数据，因为服务端已经断开了与客户端相同四元组的 TCP 连接，所以就会回 RST 报文，客户端收到后就会断开 TCP 连接。至此，双方的 TCP 连接都断开了。

没有数据传输的情况：

如果双方都没有开启 TCP keepalive 机制，那么在客户端拔掉网线后，如果客户端一直不插回网线，那么客户端和服务端的 TCP 连接状态将会一直保持存在。
如果双方都开启了 TCP keepalive 机制，那么在客户端拔掉网线后，如果客户端一直不插回网线，TCP keepalive 机制会探测到对方的 TCP 连接没有存活，于是就会断开 TCP 连接。而如果在 TCP 探测期间，客户端插回了网线，那么双方原本的 TCP 连接还是能正常存在。

除了客户端拔掉网线的场景，还有客户端「宕机和杀死进程」的两种场景。

第一个场景，客户端宕机这件事跟拔掉网线是一样无法被服务端的感知的，所以如果在没有数据传输，并且没有开启 TCP keepalive 机制时，， 服务端的 TCP 连接将会一直处于 ESTABLISHED 连接状态，直到服务端重启进程。

所以，我们可以得知一个点。在没有使用 TCP 保活机制，且双方不传输数据的情况下，一方的 TCP 连接处在 ESTABLISHED 状态时，并不代表另一方的 TCP 连接还一定是正常的。

第二个场景，杀死客户端的进程后，客户端的内核就会向服务端发送 FIN 报文， 与客户端进行四次挥手。

所以，即使没有开启 TCP keepalive，且双方也没有数据交互的情况下，如果其中一方的进程发生了崩溃，这个过程操作系统是可以感知的到的，于是就会发送 FIN 报文给对方，然后与对方进行 TCP 四次挥手。

完！

开发一个在线代码对比工具

Sat, 23 Jul 2022 09:32:39 CST

highlight: monokai

我正在参加「创意开发投稿大赛」详情请看：掘金创意开发大赛来了！

前言

在开发过程中，我们经常需要用到代码对比，对比下代码是否一致，有哪些改动，方便我们可以查看问题，今天我们就来说实现下，其实很简单，不需要后端，纯前端就可以实现。

Monaco Editor

Monaco Editor 是 VS Code 中使用的开源代码编辑器，拥有代码高亮和代码自动补全的功能，并且内置了一个 Diff Editor。

官网就有一个 Diff Editor 的演示，我们要开发的就是在这个基础之上，加上语言切换的功能，让这个 Diff Editor 拥有内置云语言的语法高亮。

TypeScript, JavaScript, CSS, LESS, SCSS, JSON, HTML、XML, PHP, C#, C++, Razor, Markdown, Diff, Java, VB, CoffeeScript, Handlebars, Batch, Pug, F#, Lua, Powershell, Python, Ruby, SASS, R, Objective-C

官网罗列了这些语言，但远不止于此。

马上掘金

代码片段使用 monaco-editor 创建一个简单的代码编辑器

代码片段使用 monaco-editor 创建一个简单的 Diff 编辑器

Monaco Editor 有 2 种加载方式，分别是 amd 和 esm，也就是 Requirejs 和 ES Modules。马上掘金中使用的是 requirejs。

技术栈选择

我准备把常用的工具做成一个工具网站，所以我选择使用 next.js，并且可以使用 vercel 免费持续部署。

关于 Monaco Editor 在 next.js 中的配置，之前有介绍过，大家可以看这篇文章《在 Next.js 中使用 Monaco Editor》。

实现 Diff Editor

  import type { editor as MonacoEditor } from "monaco-editor";
import { useEffect, useRef, useState } from "react";
import * as monaco from "monaco-editor";

export default function TextDiffPage() {
 const editorContainer = useRef<HTMLDivElement | null>(null);
 const [language, setLanguage] = useState("text");
 const [inlineView, setInlineView] = useState(false);

 const [diffEditor, setDiffEditor] =
   useState<MonacoEditor.IStandaloneDiffEditor | null>(null);

 const createModel = (
   value: string,
   language: string,
   type: "original" | "modified"
 ) => {
   return monaco.editor.createModel(value, language);
 };

 const initEditor = async () => {
   const originalModel = createModel(`Hello World`, language, "original");
   const modifiedModel = createModel(`Goodbye World`, language, "modified");
   const editor = monaco.editor.createDiffEditor(editorContainer.current, {
     minimap: { enabled: false },
     theme: "vs-dark",
     renderSideBySide: !inlineView,
     originalEditable: true,
   });
   editor.setModel({
     original: originalModel,
     modified: modifiedModel,
   });

   setDiffEditor(editor);
 };

 useEffect(() => {
   initEditor();
   return () => {
     if (diffEditor) diffEditor.dispose();
   };
 }, []);

 useEffect(() => {
   if (diffEditor) {
     diffEditor.updateOptions({
       renderSideBySide: !inlineView,
     });
   }
 }, [inlineView]);

 return (
   <div className="h-screen flex flex-col">
     <header className="h-16 border-b dark:border-neutral-800 flex-shrink-0 flex items-center px-3 space-x-5">
       <label className="space-x-1 flex items-center">
         <input
           type="checkbox"
           checked={inlineView}
           onChange={(e) => setInlineView(e.target.checked)}
         />
         <span>Inline diff</span>
       </label>
     </header>
     <div ref={editorContainer} className="h-full"></div>
   </div>
 );
}

上述代码很简单，可能有同学对 createModel 方法比较疑惑，为什么是 Model ？好比 Monaco Editor 是一个容器，容器可以设置 Model、切换 Model，比如 vscode 中，每打开一个文件就是一个 Model，文件切换就是切换 model，每个文件都有状态，比如光标位置，历史记录等，这些状态都存在 model 中，这样就不会因为文件切换而状态混淆。

  // typescript 禁用类型检查
monaco.languages.typescript.typescriptDefaults.setDiagnosticsOptions({
  noSemanticValidation: true,
  noSyntaxValidation: false,
});

// typescript jsx 格式使用 React 语法解析
monaco.languages.typescript.typescriptDefaults.setCompilerOptions({
  jsx: monaco.languages.typescript.JsxEmit.React,
});

对与一些 typescript 的语法校验我们可以选择关闭，jsx 不支持，可以设置为 react 语法支持。

最后

最后我的工具网站也开源了，包含一些前端常用工具，还可以在线刷面试题。

如果对你有帮助，可以随手点个赞，这对我真的很重要。

以上就是本文全部内容，希望这篇文章对大家有所帮助，也可以参考我往期的文章或者在评论区交流你的想法和心得，欢迎一起探索前端。

当土木工程系毕业生在线“劝学”

Sat, 04 Dec 2021 17:45:00 CST

土木工程不要怕，猛子教你走天下。/Bilibili@大猛子ym

户外工地、早六晚十、无双休，这是包括大猛子在内的许多土木工程毕业生的日常。

一名普通的土木工程专业学生，毕业后会经历什么？

家住吉林白城的大猛子，是河北农业大学土木工程专业的一名应届毕业生。今年夏天，他完成四年的学业，参加校招，签约国企，成为一名技术员。

大猛子的毕业照。

这听起来和其他专业的毕业生没什么不同。但入职后，一切才刚刚开始：先是工地恶劣的户外环境，早六晚十、没有休息日的高强度工作；然后是和陌生工人们的艰难相处，每天要接的几十个电话；接着还有难以排解的负面情绪，看着同事跑路的辛酸……

大猛子用视频记录下了这一切。最初他只想用视频来发泄情绪，但在分享工地辛苦日常的同时，他的幽默和坚持吸引了很多人，也引起了诸多对于土木工程毕业生现状的讨论。

“我适合做这一行吗？”“我什么时候也会跑路？”“在今天，年轻人还应该学土木吗？”——这是大猛子工作的第五个月，很多疑问依然在他心里，但也被更多的人看见了。

“提醒一下，UP主今年22岁”

“我一直认为，自己最大的优势，就是我会做人。”东北口音的大猛子自信地说。

在东北，“会做人”是一种综合能力。上大学期间，大猛子做过很多兼职，当过便利店收银员、超市促销员，还在烧烤店打过工，他认为自己了解底层生活，和任何人都能交朋友，有着很强的环境适应能力。

但即便如此，在刚来工地的一两个月，这里的生活还是对他造成了“重创”。

上工地不到半年，大猛子看上去像老了十岁。

到黑龙江漠河工地的第一天，大猛子先在食堂吃了一顿饭，那顿饭有三个菜：红烧肉、豆角炒肉、尖椒干豆腐。“伙食也太好了，我当时就跟领导说，我要下工地。”大猛子回忆说。

领导却笑着说：“今天不用。我问你个事儿，明天早上6点，你能起来上班不？”

从那天起，大猛子需要每天早上6:00起床，在工地待到11：30，吃完饭再返回工地，工作到下午5:30，晚饭后，再去办公室加班到夜里10:00，且无双休日。

猛子曾经吐槽，比土木工程更能抗的专业只有水利水电了。/Bilibili@大猛子ym

大猛子的职位是技术员，技术员的上级领导是监理，监理不需要长期待在工地，因此技术员是工地最高级别的负责人。技术员的主要工作内容是调度，把一个项目切割成不同的小部分，分发给下面的工程分包人员，分包带领工人们完成各自的具体工作。有些无法细分的工作，也需要技术员自己动手。

这期间，所有的沟通都需要由技术员完成，为此大猛子每天需要接几十个电话。而所有工作的成果也需要技术员检查验收，因此他也常常会和分包或工人产生冲突。工人们往往很难接受一个刚毕业的“小孩”来挑毛病，有一次，大猛子因为要求工人返工，被一个情绪激动的中年工人推搡，大猛子跟他吵了几句，但没还手，动手的工人被旁边的工友拉走了。

猛子上工地，要么干仗要么佛系。/Bilibili@大猛子ym

拍视频的初衷，就是发泄这些事情所带来的负面情绪，他只发在B站，因为其他视频平台上熟人太多了，他害怕被认出来，不想让周围人发现自己过得这么惨。

入职第46天，大猛子掉到了工地两米多深的下水道里，他第一反应是拿出手机拍下来。“就想让大家看看土木人到底有多惨。”大猛子说。

如今的大猛子胖了，圆脸、黑皮肤，安全帽下面的脸上是风吹日晒后留下的干纹。“看起来像40岁”——一条弹幕从视频上方飘过。

而5个月前，他比现在瘦20斤，干净的头发向后背，皮肤也没这么粗糙，他喜欢穿T恤和牛仔外套，是一个充满活力的年轻人。

每个视频下面，总有这样一条评论：“提醒一下，UP主今年22岁。”

对外貌这件事，猛子已经看开了。/Bilibili@大猛子ym

“不好好学习的

就来跟我做同事吧”

高考后报志愿时，八个志愿，大猛子报的几乎都是工程相关的专业。尽管他从小最想做的职业是警察，但父母认为那太危险，坚决不同意，因为父母自己有着包工程的经历，他们建议大猛子学土木工程，理由是“不愁找工作，稳定，而且挣得多”。

从某种意义上来说，大猛子大学毕业找工作时，这几点似乎都得到了验证，他迅速通过校招拿到了三家国企的offer。他原本已经决定接受其中一家，但入职前夕，另外一家公司的HR打电话给他，HR说了一句：“你是东北人吧？因为我们的总部在沈阳，我希望东北的孩子都能回到自己的家乡。”

大猛子一下被打动了，违约了上一家，选择了现在的公司。见习期是一年，其间月薪5000元，转正后的工资大约是见习期的两倍。

这个扑闪的大眼睛里憧憬的应该不会是工地吧。

但只有来了工地才会发现，高就业率所对应的是更高的离职率。据一位从业者观察，他所在的央企，土木工程毕业生在工作一年内离职的比例在60%以上。如果统计时间延长到三年，这一比例会更高。

“高”工资则是靠着每天超过12小时的高强度工作换取的。不过，终日奔走在没有精致生活，甚至没有消费途径的工地上，倒是很容易攒钱。大猛子说：“工地的生活就两种——生存和活着，生存就是干饭，活着就是保持健康，不出啥危险。”

猛子拍摄的工作环境。/Bilibili@大猛子ym

谈恋爱更是奢侈的事情，来到工地以后，大猛子没能和女朋友见到一次面，只能在每天晚饭后，抽出时间打个电话。

体会了全方位的艰辛生活后，大猛子开始在每个视频的最后三分钟进行“劝学”：“土木工程太好玩了。兄弟们，好好学习吧，考公、考研，不学习以后就来跟猛子做同事。”

猛子最常挂在嘴边的苦口婆心就是考公考研。/Bilibili@大猛子ym

但有时候他又很纠结，担心自己真的劝退了很多对土木专业有热情的年轻人：“毕竟如果这些年来没有建筑行业，中国发展也不会那么快。而且每份工作都需要有人去承担。”

在这个常常有人跑路的行业里，他称自己是“不会跑路的大猛子”。一天傍晚，大猛子完成了一天的工作，把手机对着自己的脸拍视频，镜头无法对焦到他的脸，他对着屏幕说：“天太黑了，和猛子的未来一样，一片黑暗，不知道往哪儿去。兄弟们，可能你们也和猛子一样迷茫。”

土木工程，还是热门专业吗？

一位2010级土木工程专业的学生说，在十年前，土木的确是很多人眼中的“热门专业”。和大猛子一样，他也是听从家里人的建议报了土木专业，原因是亲戚家比自己大5岁的表姐，从土木专业本科毕业后，成功进入了某省设计院工作。这让家人们觉得这是一个很有发展前景的专业。

很多人根本没有搞清楚土木和建筑专业的区别，就盲目地选择了大家口耳相传的“热门专业”。这名同学所在的大学中，同届的2000名学生里，光是土木专业就有600人，占据了10个班。而毕业时，这些学生几乎没有找不到工作的。房地产和基础建设兴盛的十几年间，土木行业有着巨大的用人需求。

大猛子的结构力学也许只能留在课堂上了。

而时代发展到今天，情况在慢慢发生改变。2020年，清华大学土木类（土木、水利与海洋工程）不再在一批次招生，仅在提前批和贫困批进行招生。作为清华长期以来绝对的一流专业，这显然意味着土木专业学生供需关系的变化，即使是清华，报考土木专业的学生也变少了。

而现实情况是，毕业以后，本科生所学到的课程与工作时的实际也有着很大的差距。“来了我才知道，理论力学、结构力学、材料力学在工地都用不上。工地需要的是办事的能力。心疼我的公司，他们花那么多钱，没买到我的知识，只买到了我的能力。”大猛子调侃说。

而更注重实操技术的专科学校毕业生，面临的是另一种尴尬。工地上，和大猛子同为技术员的一位同事是大专毕业，他俩的工作内容几乎完全一样，但他的薪资只有大猛子的一半。就在上个月，这位同事也跑了。

每一期视频，大猛子都保证自己不会跑路。

与此同时，尽管在职位上，技术员是工地的“领导”，但工人的工资远高于他们。成熟的工人是稀缺的，他们大多是年纪在40岁以上、常年待在工地、富有经验的技术工人。在工地上，你几乎见不到什么二三十岁的人，年轻工人因为缺乏经验，只能做最辛苦却赚钱最少的“力工”，而如今的年轻人，更多地选择去城市里送外卖、快递，并不愿意在建筑工地上卖苦力。

大猛子是比较幸运的，他所在的公司始终每个月按时发薪。但土木行业本身存在着拖欠工资的普遍问题，很多企业因为无法及时拿到项目款项，往往会把员工的工资积压到半年乃至一年发一次。

在不断“劝学”的过程里，大猛子也迷茫于什么才是这个时代的好专业，但他至少觉得，供需关系会在很大程度上影响一个专业的未来：“如果所有人都不选土木，那土木反而会成为一个热门专业；如果所有人都来学土木，那它就会变得没那么好。”

当被问到如果重新选择一次，会选择什么专业时，大猛子回答说：“如果现在让我选，我也不知道会选什么专业。我会选好好学习，多给自己一些可能的方向。”

猛子坐在工地真情实感劝学了。/Bilibili@大猛子ym

冬天到了，大猛子所在的第一个项目即将结束。东北的冬天太冷，无法持续施工，因此他可以得到为期一个月的短暂休息。在那之后，他将被调往黑龙江的另一处工地，开始一个新项目，预计时间是两年。

大猛子还没有跑路。

来源：新周刊

喷嚏网官方App :【安卓】在豌豆荚、360手机助手、小米应用商店，搜索：喷嚏阅读；【ios】App store里搜索：喷嚏网官方阅读；

喷嚏网官方网站：http://dapenti.com (海外访问：https://dapenti.com)

每天网络精华尽在【喷嚏图卦】喷嚏网官方新浪围脖

启动资金两百万，能做精品酒店么？海滨三线城市，在这里三星级酒店房价两百左右，做精品酒店可行么？

Wed, 01 Sep 2021 19:45:32 CST

姑婆那些事儿的回答

题主你好，我从2010年开始进入酒店投资行业，经手了包含7天、如家、汉庭、速8、和颐、格林豪泰、桔子酒店等市面上见得到的快捷酒店的投资，累积项目超60多个。现在是一家国内黑马级中档酒店品牌的投资总监。

下面我将根据亲身经历，从三个方面对这个问题做一些分享，希望能帮到你。

1. 什么是精品酒店？

2. “小而美”的酒店案例分享

3. 酒店设计、施工、采购备品、运营、营收方面的经验分享

1.在回答可行性的问题前，我们首先需要厘清一个概念： 什么是精品酒店。

我们常说的精品酒店，它起源于上世纪80年代初，先在美国和欧洲等发达国家和地区发展。1998年后，我国经济正处于发展迅速阶段，一线城市（北、上、深）开始出现了几家精品酒店，如北京东升凯莱酒店、北京颐和安缦等等。那时的精品酒店属性中还带着“高端”“奢华”等词汇。

随着后续我国经济不断突飞猛进，以商务人群为代表的中产阶级队伍日益壮大，精品酒店现已成为酒店时尚的风向标。无论是从城市经济特区，还是各个酒店品牌，精品酒店都成了投资方向的香饽饽。

现在的精品酒店依旧包含了像安缦、东升凯莱这样的高端品牌，同时顺应着市场的发展，也推导了新的分支——即以中档精品、主题精品和民宿精品为核心的中端精品系列。

安缦酒店

2.实话实说，题主的这个启动资金做中档精品和主题精品酒店是有些捉襟见肘的，可能在有合适物业的大前提下做个民宿精品是没问题。

我在中档精品领域的经验比较丰富，所以分享一个我经手过的，被许多业内人士谬赞为 “经典”的中端精品酒店案例。

这个酒店项目地址坐落在北京西四环边的五棵松。首都的地段大家都知道，景色条件虽无法跟海滨比，但寸土寸金的地段更要求投资回报，我介绍的这个案例就是物业小、回报高的典型， 从综合性角度来看是当之无愧的“小而美”。

在这插一句，说下我们多年来对小型酒店的定位和市场竞争力看法。

从用户角度讲，小型酒店或者小型精品都是卖方市场决定的产物，即物业方的条件决定（地段、租金、面积、政策等等综合）了酒店的产品属性。作为客人，他们更愿意花同样的价钱住相对更大的房间，只是市场供求原因让他们没有多余的选择。那 如何让顾客在小空间里没有“吃亏”感，我们认为在空间和舒适度上找突破点是比较合适的——把“看着舒服”切切实实地落到“住着舒服”。从投资的角度来讲，面积和租金是固定的，相同面积能设计出来更多房间，那多出的房间都是增加的净利润，所以优化排房、多排房是实现利润最大化不二法门。

好了，回归正题

我们是2015年4月份拿到的这个项目，地址位于北京五棵松六建社区的大院里，从大道进来需要通过社区的大门，穿过一小节绿化带，然后映入眼帘的就是这一栋2200㎡的破旧的小楼——一个不怎么样的社会旅馆。

老酒店正门酒店侧后方（像不像童话里的藤蔓屋？）

这里面有83间房，每间大概在12-15㎡，当时RevPAR （Revenue Per Available Room ，每间可销售房收入）在250左右的样子，楼体不但破旧，还布满了爬山虎。周边更是脏乱嘈杂，而且位置较为隐蔽，并不处于现眼地段。

我们第一个“动刀”的地方就是加固，因为住宿服务业安全永远是“1”，其余的内容都是“0”。只有有“1”在牢牢的牵头，后续的工作才不会落到归于0。所以在我的建议下，我们花超过一个月的时间去做结构加固的设计，绝对不允许敷衍了事，因为一旦发生坍塌那将会是“灭顶之灾”。

然后就是房间问题。第一是要保证排房的房间数量，第二是受面积有限，空间虽小但不能让宾客感到压抑感。所以对公区进行了优化，确保了一定量的房间数，同时摈弃掉很多 “华而不实”设计。

我们没有设计高级的宴会厅。而是把前厅、大堂、读书吧、餐厅、咖啡厅、商务、休闲等功能场景融合在一起，还取了一个直白的名字——七合一空间。

前厅公区餐区只能放三套桌椅的小院

这个酒店的目标客群大多是商旅人士和旅游的家庭，路途中奔波劳累，洗个舒服的澡、睡个好觉、吃个好早餐是酒店解决宾客的核心之一。我们准备的淋浴能够3秒快速来热水；床垫采用进口独立弹簧的，翻身都不影响他人；床上标配两种枕头，另有额外的十余种可替换选择；60x80的高星级酒店布草标准。

明星商务间和风间（因为小，放床都过于拥挤，索性改成榻榻米）

值得一提的是我们在淋浴间有个小创新（在当时来说，现在有些酒店也在效仿），那就是我们的沐足石。通常我们淋浴时，洗脚都得弯着腰，花洒的水疯狂地冲着后脑勺和后背，常常手忙脚乱地搓两下就完事，体感不是很好。有了沐足石，就完美的解决了此类问题。

沐足石

由于市面没有现成的，当年是手稿拿给供应商做的

沐足石与淋浴喷头的距离（也是手稿）

此外，我们在酒店的走道区域还添加了“维生素加油站”，随时让宾客补充能量、补充营养。

夜间8点-12点在七合一空间免费供应“深夜暖胃粥”，帮助宾客舒缓肠胃，营造入睡心情

还有免费的商务打印区，方便出差、旅行的宾客修改和打印资料。

酒店一方面要满足住客关注的舒适度，服务质量等问题，另一方面我们也需要关注营收问题（RevPAR）。所以当时产品设计时请了“京圈”的好几家公司来设计，关键部分甚至是亲自操刀解决的。

项目合同是2016年4月签订，5月份做加固并装修进场，经过3个月的日夜拼搏，8月中下旬进入筹备上线工作，于9月8号开始试营业。个别股东提议干脆直接上线，先有进账再慢慢整改，被我严词拒绝。

服务业面向市场，必须是要自己认可能拿得出手的东西，一旦不好的口碑形成，后面修补的成本会出奇的高。基于此，整理完一系列问题后，我们又紧锣密鼓的调整了近2个月的时间。

最终，我们于11月18日正式上线。

外立面（正面）改造前改造后酒店秋季的外立面

正是因为我们在开业之前严苛的自检和调整，加上前期针对“小”房间做大量的创新和呈现，“小”并没有影响到店面生意，反而是开业一周就满房，携程APP好评条数激增，评分直奔4.9。

7月RevPAV 514;8月RevPAR 543，与之前180-200相比，增涨了2.5倍左右

作为当时的第一家中档精品酒店，RevPAR竟持续高过同商圈某星级酒店和某上市公司中档品牌酒店。（快捷酒店的RevPAR在150左右，中档则在350左右）

这让我们更加笃定：小不是问题，只要美就会吸引客人来！

3.以上就我想分享的真实的案例，在这也 总结几条经验吧，望选择性采纳：

设计方面：

1. 要用运营思维做设计，好多设计在实际运营过程中非常鸡肋，属于花钱耽误事。

2. 要用成本思维做设计，华而不实不要，哗众取宠不要。

3. 要用用户思维做设计，站在住客的角度上去思考产品，才能做出让顾客舒服的产品。

施工方面：

1. 一定要有同档次酒店装修经验的，你要相信干快捷的施工队伍做不好精品酒店的装修。

2. 根据自身的经验、精力来选择，如果两者都具备，那自管是第一选择。倘若经验精力都不能支撑，那么我建议最好大总包，不然分包一个个天天干仗，你天天要当家长化解矛盾。

3. 假设你是做加盟品牌，一定要找个靠谱且专业的品牌方项目经理帮你盯现场，不然干完了品牌方验收通不过，你就前后为难了。

采购备品方面：

1. 采购要讲供应链的价值，B端的采购水分非常之大，很多“玄机”，如果能借助大企业的供应链，就能买到性价比高的物料。

2. 开放采购方式，一定要货比三家，有些东西一比较就明白了。

运营管理方面：

1. 团队方面：重视人才，善用人才，建议把你的店长当做自己合伙人，满足他的需求，解决他的痛点，让他来服务好客人，管理好他的团队

2. 服务方面：结合上一条，酒店属于传统行业，又是个劳动密集型产业，从业人员大多心中没有服务意识，只是机械地完成工作。所以重视团队成员，满足团队成员，“服务好”他们，让他们由衷的带着关爱和微笑去服务好宾客，

3.卫生方面：卫生是衡量一个酒店的重中之重，也是基础中的基础。卫生做得好，证明团队管理好，执行到位。卫生好，代表服务自然不会差。酒店可以卫生好，服务不怎么样的情况；但如果卫生差，它的服务就一定差。

营收方面：

好产品+好服务获得好口碑，好口碑产生复购，复购产生高出租率，有了高出租率，就可以做收益管理，我们每两个小时会统计一下同商圈竞品的数据，根据我们的库存和同商圈酒店的数据来实时调整我们的卖价，就像机票售价一样实时变动，一天一间房多卖10块钱，100间房一年下来都是几十万的纯利润。

我罗里吧嗦的也码了这么多字了，大家看完有什么想商讨或者批评指正的欢迎留言私信。或者大家想了解更多的案例细节，也可以联系我，我也会持续补充干货内容。

大型系统在线问题诊断与定位

Mon, 19 Apr 2021 06:11:33 CST

本文是武汉 gopher meetup 的分享内容整理而成，分享内容在 “无人值守” 的两篇和其它社区分享中亦有提及。(也就是说你看过那两篇，这个可以不用看了)

先来看看苦逼的开发人员

老板说：

队友说：

外组同事说：

底层团队说：

你：

业界的思路？

混口饭吃也是不容易，既然有问题了，我们还是要解决的。要先看看有没有现成的思路可以借鉴？

Google 在这篇论文里提到过其内部的线上 profile 流程：

架构图已经比较简单了，线上应用暴露 profile 接口，collector 定时将 profile 信息采集到二进制存储，由统一的在线平台展示。

这篇论文催生了一些开源项目和创业公司，例如在这篇文章中，对 continuous profiling 有很不错的解释。

我们日常的 CI 和 CD 流水线可以高频次发布线上系统，当线上有 continuous profiling 系统在运行时，每次发布我们都能够得到实时的性能快照，并与发布前的性能做快速对照。

系统的性能问题和其它技术问题一样，同样是发现得越早，解决起来就越快，损失越小。

Google Cloud 上也有 profiler 相关的产品，是由 Go 原先的 pprof 开发者开发的，她在文章中声称每分钟对应用采集 10s 的 profile，大约有 5% 的性能损失，还是可以接受的。

简单来说，continuous profiling 带给我们的优势主要就是三点：

缩短性能问题反馈周期
节省服务器成本
改进开发者的工作流程

有了思路，再看看有没有具体的开源产品可以参考。

我们的方案

求人不如求己，我们需要定位的是抖动问题，那我们以 5s 为单位，把进程的 CPU 使用 (gopsutil)，RSS(gopsutil)，goroutine 数 (runtime.NumGoroutine)，用 10 大小的环形数组保存下来，每次采集到新值时，与之前多个周期的平均值进行 diff 就可以了：

当波动率超过可以接受的范围，则认为当前进程发生了资源使用抖动，那么：

若 CPU 抖动，从当前开始采集 CPU profile 5 秒
若 RSS 抖动，将当前进程的 heap profile 记录下来
若 goroutine 抖动，将当前进程的 goroutine profile 记录下来

一套方案做下来，还挺简单的。当我们收到模块的 CPU、内存或 goroutine 数报警时，上线到相应的实例来查看即可。

实际的案例

解码 bug

某模块突然出现了 RSS 使用飚升，上线看之后发现自动 dump 文本的 profile 中，单个对象的 inuse_space 超过了 1GB：

   // inuse_objects: inuse_space [alloc_objects : alloc_space]
1 : 1024000000 [1 : 1024000000]  git.xxx.xxx


复制代码

这是很反常的，阅读代码后发现在 decode 中没有对这些情况进行一定的防御操作，有形如下面的代码：

   var l = readLenFromPacket()
var list = make([]byte, l)


复制代码

虽然理论上 body 是可以传 1GB 的，不过内部的 RPC 框架，还是应该对这种情况进行一些限制。

CPU 尖刺

有些在线系统是定时任务调用的，所以其访问峰值非常不平均，在定时任务触发后，会有一段时间 CPU 使用非常高，有了自动 CPU profile dump，就非常容易找到具体哪里使用的 CPU 很高了。

goroutine 泄露

类似这样的 goroutine 泄露问题，也是可以很容易发现的。

deadlock(扩展)

因为我们可以采集到所有 goroutine 的栈信息，所以理论上通过遍历我们可以发现哪些 goroutine 是持锁的，例如下列代码，当发生死锁时，我们可以直接把持锁的 goroutine dump 下来，就很容易发现死锁了：

thread block(扩展)

，当线程因为调用 cgo 等原因发生了阻塞，会造成线程数暴涨，这时候我们可以将 goroutine 和 thread profile dump 下来，进行诊断。

总结

有了自动化的工具，日子更好过了。

如何构建更健壮的在线系统_heiyeluren的blog（黑夜路人的开源世界）-CSDN博客

Sun, 06 Dec 2020 09:23:24 CST

【原创】如何构建更健壮的在线系统

作者：黑夜路人（heiyeluren）

时间：2020年11月

说明：本文主要面对PHP为主要开发语言的业务系统，Golang、Java等语言可以学习参考。

0. 背景

Why 为什么要健壮的系统？

1. 为什么测试好好的，上到线上代码一堆bug，一上线就崩溃或者一堆问题？

2. 为什么感觉自己系统做的性能很好，上线后流量一上来就雪崩了？

3. 为什么自己的系统上线以后出问题不知道问题在哪儿，完全无法跟踪？

What 构建健壮系统包含哪些方面？

软件系统架构关注：可维护性、可扩展性、健壮性（容灾）

做出健壮的软件和系统的三个方向：

1. 良好的软件系统架构设计

2. 编程最佳实践和通用原则

3. 个人专业软素质

How 构建健壮系统执行细节？

1、系统架构：网络拓扑是什么、用什么存储、用什么缓存、整个数据流向是如何、那个核心服务采用那个开源软件支撑、用什么编程语言来构建整个软件连接各个服务、整个系统如何分层？

2、系统设计：采用什么编程语言、编程语言使用什么编程框架或中间件、使用什么设计模式来构建代码、中间代码如何分层？

3、编程实现：编程语言用什么框架、有什么规范、编程语言需要注意哪些细节、有哪些技巧、那些编程原则？

一、系统架构与设计遵循哪些关键原则？

0. 用架构师的视角来思考问题

程序员视角更多考虑的是我如何快速完成这个项目，架构师视角是不仅是我完成整个项目，更多需要思考整个架构是否清晰、是否可维护、是否可扩展、可靠性稳定性如何，整个技术框架和各种体系选型是否方便容易开发维护；整个思考维度和视角是完全不一样的。程序员视角是执行层面具体编码的视角，架构师视角是设计师的视角，会更宏观，想的更远。

（比如编程语言选型 PHP vs Golang、Java vs Golang、C++ vs Rust等等）

1. 服务架构链路要清晰

整个服务架构包含：接入层（网关、负载均衡）、应用层（PHP程序等）、服务层（微服务接口等）、存储层（DB、缓存、检索ES等）、离线计算层（不一定包含，一般会以服务层或存储层出现），服务互相不要混了，各干各的活；

服务链路要清晰，每一层各司其职：

2. 每个服务都需要考虑灾备或分布式，不能出现单点架构（持续进化）

比如mysql不能只有1个，最少考虑 master/slave架构，保持数据不丢，访问不断，数据量大以后是否做分布式存储等等，redis等同样；后端微服务层同样必须多台服务（通过ServiceMesh等调度，或者是etcd/zookeeper等服务发现等方式）；

分布式进化：

初级阶段：

中级阶段：

高级阶段：

3. 每个服务都必须考虑最优的技术选型（最佳实践）

比如PHP框架选择，语言选择都是稳定成熟可靠（高性能API选Swoole、Golang等，业务系统考虑Laravel、Symfony、Yii等主流框架）；比如微服务框架，远程访问接口协议（TCP/UDP/QUIC/HTTP2/HTTP3等），信息内容格式可靠（json/protobuf/yaml/toml等）；选择的扩展稳定可靠（PHP各个可靠扩展，具备久经考验，超时、日志记录等基础特性）；

一些优秀开源软件推荐：（个人最佳实践推荐）

4. 服务必须考虑熔断降级方案

在大流量下，如何保证最核心服务的运转（比如在线课堂中是老师讲课直播重要，还是弹幕或者点赞重要），需要把服务分层，切分一级核心服务、二级重要服务、三级可熔断服务等等区分，还需要有对应的预案；（防火/防火演练等）；需要对应的系统支持，比如API网关的选择使用。（OpenResty/Kong/APISIX等，单核2W/qps，4核6W/qps）

5. 运维部署回滚监控等系统需要快速高效

整个代码层次结构，编译上线整个流程，如何是保证高效率可靠的；上线方便，回滚也方便，或者回滚到任何一个版本必须可靠；日志监控、系统报警等等。（常规运维上线系统 Jenkins/Nagios/Zabbix/Ganglia/Grafana/OpenFalcon/Nightingale）

监控系统价值：

监控系统工作原理：

监控系统选择：

6. 编写的接口和前后端联合调试要方便快捷

接口可靠性测试必须充分，并且善于使用好的工具（比如Filder/Postman/SoapUI等），并且对应接口文档清晰，最好是能够通过一些工具生成好API文档（APIJson/Swagger/Eolinker），大家按照对应约定格式协议进行程序开发联调等；

7. 让整个系统完全可监控可追踪

比如对应的trace系统（包含trace_id），把从接入层、应用层、服务层、存储层等都能够串联起来，每个环节出现的问题都可追踪，快速定位问题找到bug或者服务瓶颈短板；也能够了解整个系统运行情况和细节。（比如一些日志采集系统 OpenResty/Filebeat/Flume/LogStash/ELK）

8. 系统中的每个细节都是需要可以量化的，不能是模糊不明确的

比如单个服务的QPS能力（预计流量需要多少服务器)、并发连接数（系统设置、系统承载连接）、单个进程内存占用、线程数、网络之间访问延迟时间（服务器之间延迟、机房到机房的延迟、客户端到服务器的延迟）、各种硬件性能参数（磁盘IO、服务器网卡吞吐量等）。

比如：【QPS计算PV和机器的方式】

原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间

公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)

机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器

QPS统计方式

QPS = 总请求数 / ( 进程总数 * 请求时间 )

QPS: 单个进程每秒请求服务器的成功次数

单台服务器每天PV计算

公式1：每天总PV = QPS * 3600 * 6

公式2：每天总PV = QPS * 3600 * 8

问：每天300w PV 的在单台机器上，这台机器需要多少QPS？

答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

问：如果一台机器的QPS是58，需要几台机器来支持？

服务器数量 = ceil( 每天总PV / 单台服务器每天总PV )

答：139 / 58 = 3

PS: 在实际情况中，会把这个考虑的更多一点，就是把QPS再往多了调一调，以防万一

9. 让你的应用无状态化、容器化、微服务化

让你的应用可以做到：去中心化、原子化、语言无依赖、独立自治、快速组合、自动部署、快速扩容，采用微服务+容器化来解决。

在面对大并发量请求情况下，在寻求系统资源的状态利用场景，大部分考虑的都是横向扩展，简单说就加机器解决。在docker和k8s的新的容器化时代，横向扩展最好的方法是快速扩充新的应用运行容器；阻碍我们横向扩展的最大的阻碍就是“有状态”，有状态就是有很多应用会存储私有的东西在应用运行的内存、磁盘中，而不是采用通用的分布式缓存、分布式存储解决方案，这会导致我们的应用在容器化的情况下无法快速扩容，所以我们的应用需要“去有状态化”，让我们的应用全部“无状态化”。

微服务化的逻辑是让的每个服务可以独立运行，比如说用户中心系统对外提供的不是代码级别的API，而是基于RESTfu或者gRPC协议的远程一个服务多个接口，这个服务或接口核心用来解决把整个用户中心服务变成独立服务，谁都可以调用，并且这个服务本身不会对内外部有太多的耦合和依赖，对外暴露的也只是一个个独立的远程接口而已。

尽量把我们的关键服务可以抽象成为一个个微服务，虽然微服务会增加网络调用的成本，但是每个服务之间的互相依赖性等等都降低了，并且通过容器技术，可以把单给微服务快速的横向扩展部署增加性能，虽然不是银弹，也是一个非常好的解决方案。

基于容器的微服务化以后，整个业务系统从开发、测试、发布、线上运维、扩展等多个方面都比较简单了，可以完全依赖于各种自动半自动化工具完成，整个人工干预参加的成分大幅减少。

从单体服务到微服务：

微服务后应用架构变化：

容器简单工作原理：

      /*
  简单容器底层机制实现模拟演示
  说明：主要利用Linux的Namespace机制来实现，linux系统中unshare命令效果类似
  Docker 调用机制是： Docker -> libcontainer(like lxc) -> cgroup -> namespace
  Code by Black 2020.10.10
*/
#include <sys/types.h>
#include <sys/wait.h>
#include <linux/sched.h>
#include <sched.h>
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#define STACK_SIZE (1024 * 1024)

static char container_stack[STACK_SIZE];
char* const container_args[] = { "/bin/bash",  NULL };

//容器进行运行的程序主函数
int container_main(void *args)
{
    printf("容器进程开始. \n");
    sethostname("black-container", 16);
    //替换当前进程ps指令读取proc环节
    system("mount -t proc proc /proc");
    execv(container_args[0], container_args);
}

int main(int args, char *argv[])
{
    printf("======Linux 容器功能简单实现 ======\n");
    printf("======code by Black 2020.10 ======\n\n");
    printf("正常主进程开始\n");
    // clone 容器进程: hostname/消息通信/进程id 都独立 (CLONE_NEWUSER未实现)
    int container_pid = clone(container_main, container_stack+STACK_SIZE, 
        SIGCHLD | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET, NULL);
    // 等待容器进程结束
    waitpid(container_pid, NULL, 0);
    //恢复 /proc 下的内容
    system("mount -t proc proc /proc");
    printf("主要进程结束\n");
    return 0;
}

代码执行效果：

Docker工作机制：

K8s工作机制：

微服务+容器化后的架构：

容器+微服务运维部署架构：

架构设计结束语：

在架构设计中，没有最好的架构，只有适合业务的架构，只有持续优化进步的架构。

二、系统程序实现里哪些关注原则

0. 充分理解你的业务需求

保证理解业务后，整个程序设计符合需求或者未来几个月可以扩展，既不做过度设计，也不做各种临时硬编码。

1. 代码核心原则：KISS（Keep it simple,stupid）

来自于Unix编程艺术，你的东西必须足够简单足够愚蠢，好处非常多，比如容易读懂，容易维护交接，出问题容易追查等等。

因为，长期来看复杂的东西都是没有生命力的。（x86 vs ARM / 微型服务器 vs 大型机 / 北欧简约风 vs 欧洲皇室风 / 现在服装 vs 汉服）

2. 遵守编码规范，代码设计通用灵活

学会通过用函数和类进行封装（高内聚、低耦合）、如何定义函数，缩进方式，返回参数定义，注释如何定义、减少硬编码（通过配置、数据库存储变量来解决）。

3. 设计模式和代码结构需要清晰

比如我们常规使用的MVC设计模式，为了就是把各个层次代码区分开。（M干好数据读取或者接口访问的事儿，C干好变量收发基本教研，V干好模板渲染或者api接口输出；M可以拆分成为：DAO数据访问层和Service某服务提供层）；

比如一个主流的MVC层结构图：

4. 程序中一定要写日志，代码日志要记录清晰

（Info、Debug、Waring、Trace等等，调用统一的日志库，不要害怕多写日志）

      //程序里关键的日志都要记录（Debug/Notice/Warning/Error 等信息可以打印，warning/error 信息是一定要打印的
SeasLog::debug('TRACE_ID:{traceId}; this is a {userName} debug',array('{traceId}'=>9527, '{userName}' => 'Black'));
SeasLog::notice('TRACE_ID:{traceId}; this is a notice msg', array('{traceId}'=>9527));
SeasLog::warning('TRACE_ID:{traceId}; this is a warning', array('{traceId}'=>9527));
SeasLog::error('TRACE_ID:{traceId}; a error log', array('{traceId}'=>9527));

5. 稳健性编程小技巧（个人最佳实践）

a. 代码里尽量不要使用else（超级推荐，Unix编程艺术书籍推荐方法）

      //获取一个整形的值 （使用else，共12行）
function getIntValue($val) {
    if ( $val != "" ) {
    $ret = (int)$val;
        if ($ret != 0 ) {
            return $ret;
        } else {
            return false;
        }
    } else {
        return false;
    }
}

      //获取一个整形的值（不使用else，共10行）
function getIntValue($val) {
    if ( $val == "" ) {
        return false;
    }
    $ret = (int)$val;
    if ($ret == 0 ) {
        return false;
    } 
    return $ret;
}

b. 所有的循环必须有结束条件或约定，并且不会不可控

c. 不要申请超级大的变量或内存造成资源浪费

d. 无论静态还是动态语言，内存或对象使用完以后尽量及时释放

e. 输入数据务必要校验，用户输入数据必须不可信。

f. 尽量不要使用异步回调的方式（容易混乱，对js和nodejs的鄙视，对协程机制的尊敬）

6. 所有内外部访问都必须有超时机制：保证不连锁反应雪崩

超时是保证我们业务不会连带雪崩的很关键的地方，比如我们在访问后端资源或外部服务一定要经常使用超时操作。

超时细化下来，一般会包括很多类型：连接超时、读超时、写超时、通用超时等等区分；一般超时粒度大部分都是秒为单位，对于时间敏感业务都是毫秒为单位，建议以毫秒(ms)为单位的超时更可靠，但是很多服务没有提供这类超时操作接口。

常用使用超时的场景：

Swoole框架里控制超时：

      //Swoole 里通用超时设置（针对TCP协议情况，包含通用超时、连接超时、读写超时）
Co::set([
    'socket_timeout' => 5,
    'socket_connect_timeout' => 1,
    'socket_read_timeout' => 1,
    'socket_write_timeout' => 1,
]);

//Swoole 4.x协程方式访问MySQL
Co\run(function () {
    $swoole_mysql = new Swoole\Coroutine\MySQL();
    $swoole_mysql->connect([
        'host'     => '127.0.0.1',
        'port'     => 3306,
        'user'     => 'user',
        'password' => 'pass',
        'database' => 'test',
        'timeout'     => '1',
    ]);
    $res = $swoole_mysql->query('select sleep(1)');
    var_dump($res);
});

//Swoole 4.x协程方式访问Redis
Co\run(function () {
    $redis = new Swoole\Coroutine\Redis();
    $redis->setOptions(
        'connect_timeout'    => '1',
        'timeout'    => '1',
    );
    $redis->connect('127.0.0.1', 6379);
    $val = $redis->get('key');
});

通过cURL接口访问HTTP服务超时设置：

          function http_call($url)
   $ch = curl_init($url);
   curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
   //注意，毫秒超时一定要设置这个
   curl_setopt($ch, CURLOPT_NOSIGNAL, 1);    
   //超时毫秒，cURL 7.16.2中被加入。从PHP 5.2.3起可使用
   curl_setopt($ch, CURLOPT_TIMEOUT_MS, 200);  
   $data = curl_exec($ch);
   $curl_errno = curl_errno($ch);
  $curl_error = curl_error($ch);
  curl_close($ch);
}
http_call('http://example.com')

访问MySQL超时处理（非Swoole情况），调用mysqli扩展方式：

mysql 默认在扩展层面没有把很多超时操作暴露给前台，所以需要用一些隐藏方式：

      <?php
//自己定义读写超时常量
if (!defined('MYSQL_OPT_READ_TIMEOUT')) define('MYSQL_OPT_READ_TIMEOUT',  11);
if (!defined('MYSQL_OPT_WRITE_TIMEOUT')) define('MYSQL_OPT_WRITE_TIMEOUT', 12);

//设置超时
$mysqli = mysqli_init();
$mysqli->options(MYSQL_OPT_READ_TIMEOUT, 3); //读超时，没办法超过3秒
$mysqli->options(MYSQL_OPT_WRITE_TIMEOUT, 1); //写超时，最小可设置为1秒
 
//连接数据库
$mysqli->real_connect("localhost", "root", "root", "test");
//执行查询 sleep 1秒不超时
printf("Host information: %s/n", $mysqli->host_info);

//执行查询 sleep 1秒不超时
printf("Host information: %s/n", $mysqli->host_info);
if (!($res=$mysqli->query('select sleep(1)'))) {
    echo "query1 error: ". $mysqli->error ."/n";
} else {
    echo "Query1: query success/n";
}

//执行查询 sleep 9秒会超时，处理3秒超时情况，因为mysql自己会重试3次
if (!($res=$mysqli->query('select sleep(9)'))) {
    echo "query2 error: ". $mysqli->error ."/n";
} else {
    echo "Query2: query success/n";
}

$mysqli->close();
?>

目前大部分主流框架都没有提供mysql超时配置，包括Laravel、Symfony、Yii 等框架都没有提供，因为都是基于底层mysqli或pdo等扩展。

Socket或流处理超时：

      // ## fsockopen访问HTTP ## 
$timeout = 5; //超时5秒
$fp = fsockopen("example.com", 80, $errno, $errstr, $timeout); 
if ($fp) { 
        fwrite($fp, "GET / HTTP/1.0\r\n"); 
        fwrite($fp, "Host: example.com\r\n"); 
        fwrite($fp, "Connection: Close\r\n\r\n"); 
        stream_set_blocking($fp, true);   //重要，设置为非阻塞模式
        stream_set_timeout($fp,$timeout);   //设置超时
        $info = stream_get_meta_data($fp); 
        while ((!feof($fp)) && (!$info['timed_out'])) { 
                $data .= fgets($fp, 4096); 
                $info = stream_get_meta_data($fp); 
                ob_flush; 
                flush(); 
        } 
        if ($info['timed_out']) { 
                echo "Connection Timed Out!"; 
        } 
       else { 
                echo $data; 
        } 
}

通过上下文环境处理超时：

      //fopen & file_get_contents 访问HTTP超时控制
//设置超时和压入上下文环境
$timeout = array(
    'http' => array(
        'timeout' => 5 //设置一个超时时间，单位为秒
    )
);
$ctx = stream_context_create($timeout);
//fopen
if ($fp = fopen("http://example.com/", "r", false, $ctx)) {
  while( $c = fread($fp, 8192)) {
    echo $c;
  }
  fclose($fp);
$text = file_get_contents("http://example.com/", 0, $ctx);
echo $text;

延伸阅读： https://blog.csdn.net/heiyeshuwu/article/details/7841366

7. 成熟稳定的SQL语言使用习惯和技巧

a. 所有SQL语句都必须有约束条件

常规习惯：

      SELECT uid,uname,email,gender FROM user WHERE uid = '9527'

好习惯，增加对应的WHERE条件和LIMIT限制

      SELECT uid,uname,email,gender FROM user WHERE uid = '9527' LIMIT 1

b. SQL查询里抽取字段中明确需要抽取的字段

常规习惯：

      SELECT * FROM user WHERE uid = '9527'

良好习惯，需要什么字段提取什么字段：

      SELECT uid,uname,email,gender FROM user WHERE uid = '9527' WHERE 1 LIMIT 1

主要受约束的是一些mysql的配置相关，包括：max_allowed_packet 之类的会超过限制或者是把网卡带宽打满；

c. 熟知各种SQL操作的最佳实践技巧，包括不限于：常用字段建立索引（单表不超过6个）、尽量减少OR、尽量减少连表查询、尽量不要SQL语句中使用函数（datetime之类）、使用exists代替in、使用explain观察SQL运行情况等等。

延伸学习： https://blog.csdn.net/jie_liang/article/details/77340905

8. 开发中时刻要记得代码安全

我们系统在完成业务开发的基础上，还需要考虑代码安全问题，大部分时候安全和方便中间会存在冲突，但是因为一个不安全的系统，对业务的伤害是巨大的，轻则被非法用户“薅羊毛”，重则服务器被攻陷，整个数据遭到泄露或者遭受恶意损失。

我们常见遇到的安全问题包括：SQL注入、XSS、CSRF、URL跳转漏洞、文件上传下载漏洞等等，很多在我们只是关注业务实现不关注安全的时候问题都会出现。

安全问题	常见解决方法
SQL注入	输入参数校验：intval、is_numeric、htmlspecialchars、trim 数据入库格式化：PDO::prepare、mysqli_real_escape_string
XSS	过滤危险的HTML/JS等输入参数和显示内容，在js代码中对HTML做相应编码，多使用正则或者 htmlspecialchars、htmlspecialchars_decode 等处理函数；
CSRF	Client和Server交互采用token校验操作，敏感操作判断来源IP等
URL跳转	跳转目标URL必须进行校验，或者采用URL白名单机制
文件上传下载	限制文件上传大小(upload_max_filesize / post_max_size配置) 采用可靠上传的组件（Flash/JS组件）；检查上传文件类型（扩展名+内容头），控制服务器端目录和文件访问权限
配置安全	PHP环境配置做好安全配置，屏蔽敏感函数：eval / exec / system / get_included_files ；敏感配置关闭：register_globals / allow_url_fopen / allow_url_include/ safe_mode / magic_quotes 等；资源管控配置： max_execution_time / max_input_time /memory_limit / open_basedir / upload_tmp_dir 等
数据库安全	数据库访问不能用root账户，不同库不同的访问用户，读写账户分离；敏感库表需要特殊处理（比如用户库表密码库表等加盐存储）；
服务器安全	DDoS攻击防范（流量清洗、黑白名单）、服务安全运行权限（非root运行php进程）、服务器之间访问白名单机制

9. 调优后端服务的性能配置

开发语言只是一个粘合剂，整个过程是把前端用户操作进行逻辑处理，粘合后端存储和各种RPC服务的数据进行展现输出。除了你的PHP服务或代码、SQL执行效率高，同样也需要考虑前后端各个服务的性能是非常优化高性能的。

我把一些关键的Linux系统到各个各个服务一些关键性能相关选项简单罗列一下。

服务类型	核心性能影响配置
Linux系统	1. 并发文件描述符永久修改： /etc/security/limits.conf * soft nofile 1000000 * hard nofile 1000000 Session临时修改：ulimit -SHn 1000000 3. 进程数量限制永久修改：/etc/security/limits.d/20-nproc.conf * soft nproc 4096 root soft nproc unlimited 4. 文件句柄数量临时修改：echo 1000000 > /proc/sys/fs/file-max 永久修改：echo "fs.file-max = 1000000" >>/etc/sysctl.conf 5. 网络TCP选项，关注 somaxconn/backlog/mem系列/time系列等等 6. 关闭SWAP交换分区（服务器卡死元凶）： echo "vm.swappiness = 0">> /etc/sysctl.conf
Nginx/OpenResty	Nginx Worker性能： worker_processes 4; worker_cpu_affinity 01 10 01 10; worker_rlimit_nofile 10240; worker_connections 10240; Nginx网络性能： use epoll; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 30; proxy_connect_timeout 10; Nginx缓存配置： fastcgi_buffer_size 64k; client_max_body_size 300m; client_header_buffer_size 4k; open_file_cache max=65535 inactive=60s; open_file_cache_valid 80s; proxy_buffer_size 256k; proxy_buffers 4 256k; proxy_cache*
PHP/FPM	listen.backlog = -1 #backlog数，-1表示无限制 rlimit_files = 1024 #设置文件打开描述符的rlimit限制 rlimit_core = unlimited #生成core dump文件限制，受限于linux系统 pm.max_children = 256 #子进程最大数 pm.max_requests = 1000 #设置每个子进程重生之前服务的请求数 request_terminate_timeout = 0 #设置单个请求的超时中止时间 request_slowlog_timeout = 10s #当一个请求该设置的超时时间后
MySQL/MariaDB	MySQL服务选项： wait_timeout=1800 max_connections=3000 max_user_connections=800 thread_cache_size=64 skip-name-resolve = 1 open_tables=512 max_allowed_packet = 64M MySQL性能选项： innodb_page_size = 8K #脏页大小 innodb_buffer_pool_size = 10G #建议设置为内存80% innodb_log_buffer_size = 20M #日志缓存大小 innodb_flush_log_at_trx_commit = 0 #事务日志提交方式，设置为0比较合适 innodb_lock_wait_timeout = 30 #锁获取超时等待时间 innodb_io_capacity = 2000 #刷脏页的频次默认200，高一些会让io曲线稳
Redis	maxmemory 5000mb #最大内存占用 maxmemory-policy allkeys-lru #达到内存占用后淘汰策略，存在热点数据，淘汰不咋访问的 maxclients 1000 #客户端并发连接数 timeout 150 #客户端超时时间 tcp-keepalive 150 #向客户端发送tcp_ack探测存活 rdbcompression no #磁盘镜像压缩，开启占用cpu rdbchecksum no #存储快照后crc64算法校验，增加10%cpu占用 vm-enabled no #不做数据交换

延伸阅读： https://blog.csdn.net/heiyeshuwu/article/details/45692407

10. 善用常用服务的系统监测工具

为了快速的监控我们的线上服务情况，需要能够熟练使用常用的性能监控的各种工具和指标。

服务类型	常用工具或指令
Linux	top、vmstat、iostat、netstat、sar、nmon、dstat、iftop、free、df/du、tcpdump
PHP	Xdebug、xhprof、Fiery、第三方APM工具
MySQL	MySQL主要指令： show processlist show global variables like '%xxx%' show master status; show slave status; show status like '%xx%' 细节查询：查看连接数：SHOW STATUS LIKE 'Thread_%'; 查看执行事务：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX; 查看锁定事务：SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; 每秒查询QPS：SHOW GLOBAL STATUS LIKE 'Questions'; #QPS = Questions / Uptime 每秒事务TPS：SHOW GLOBAL STATUS LIKE 'Com_%'; #TPS = (Com_commit + Com_rollback) / Uptime InnoDB Buffer命中率：show status like 'innodb_buffer_pool_read%'; #innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100%
Redis	查看redis服务的各项状态：info / info stats / info CPU / info Keyspace 实时监控redis所有命令：monitor 查看redis慢日志：slowlog get 128 性能测试监控：redis-benchmark -h localhost -p 6379 -c 100 -n 100000

编码健壮性结束语：

在程序开发中，没有最优质的代码，只有解决业务问题，良好设计和规范，持续精进的程序。

三、健壮代码有哪些通用原则

1、模块性原则：写简单的，通过干净的接口可被连接的部件。（比如类、函数，高内聚低耦合）

2、清楚原则：清楚要比小聪明好。（代码中注释需要清晰明确，最好有历史迭代，不要耍小聪明，或者用一些奇怪的实现算法并且没注释）

3、合并原则：设计能被其它程序连接的程序。（提供好输入输出参数，或者设计好的openapi，尽量让程序可以复用）

4、简单原则：设计要简单；只有当你需要的时候，增加复杂性。（每个函数类要简单明确，不要太冗长）

5、健壮性原则：健壮性是透明和简单的追随者。（透明+简单了，健壮就来了）

6、沉默补救原则：当一个程序没有异常的时候就只是记录，减少干扰或者啥都不说；当你必须失败的时候，尽可能快的吵闹地失败。（失败了一定要明确清晰的提示形式，包括错误代码，错误原因的信息，不要悄无声息）

7、经济原则：程序员的时间是宝贵的；优先机器时间节约它。（能够用内存+CPU搞定，不要过多纠结在算法上）

8、产生原则：避免手工堆砌；当你可能的时候，编写可以写程序的程序。（用程序来帮你实现重复的事儿）

9、优化原则：在雕琢之前先有原型；在你优化它之前，先让他可以运行。（先完成，再完美）

10、可扩展原则：为将来做设计，因为它可能比你认为来的要快。（尽量考虑你这个代码2，3，5年后才会重构，为未来负责）

四、个人软素质：细心、认真、谨慎、精进、专业

1、细心：写完代码都需要重新Review一遍，变量名是否正确，变量是否初始化，每个SQL语句是否性能高超或者不会导致超时死锁；

2、认真：每个函数是否都自己校验过输入输出是满足预期的；条件允许，是否核心函数都具备单元测试代码；

3、谨慎：不要相信任何外部输入的数据，包括数据库、文件、缓存、用户HTTP提交各种变量，都需要严格校验和过滤。

4、精进：不要惧怕别人说你代码烂，必须能够持续被人吐槽下优化，在在我革新下优化；要学习别人优秀的代码设计思想和代码风格，持续进步。

我持续三年优化过的一个代码：（大约十四年前第一版）

5. 专业：专业是一种工作态度，也是一种人生态度；代码要专业、架构要专业、变量名要专业、文档要专业、跟别人发工作消息邮件要专业、开会要专业、沟通要专业，等等，专业要伴随自己一生。

我在十三年前写的代码：

本文结束语：

愿每一位阅读本文的技术伙伴，都能够成为优秀的程序员，优秀的架构师。

作者简介：

谢华亮，网名“黑夜路人”，目前是学而思网校技术委员会主席；作者系CSDN博客技术专家，互联网后端开发架构师，多年PHP/Golang/C 开发者，LNMP技术栈/分布式/高并发等技术爱好者，国内开源技术爱好和布道者。

个人博客： http://blog.csdn.net/heiyeshuwu

新浪微博： http://weibo.com/heiyeluren

微信公众号：黑夜路人

工商银行打造在线诊断平台的探索与实践

Mon, 19 Oct 2020 23:03:33 CST

作者 | 刘慕雨中国工商银行软件开发中心云计算实验室

在信息系统建设方面，工商银行一直积极探索，以开放的姿态借鉴行业先进经验，旨在为客户提供更优质的金融服务和用户体验。随着分布式架构和云计算平台在工行的广泛应用，如何高效排查程序错误或性能瓶颈，是个棘手的问题。

为此，我们基于 Arthas 建设了在线诊断平台，在保护客户信息安全的原则基础上，对相关能力做了剪裁和整合，通过 Web 方式支持更复杂的交互场景，在实际线上问题分析中发挥关键作用。

工行在线诊断平台：

下面对工行在线诊断平台的建设做个阶段性总结，分享一下我们的建设经验、实际效果以及未来展望，也希望能给社区提供一个参考。

传统方式排查问题的痛点

对于后端工程师，一旦线上程序逻辑出错，问题排查如同破案，在分析研判时，问题现场的第一手信息是最珍贵的。开发人员很容易首先想到的就是阅读日志，从海量的日志中寻找蛛丝马迹，这就好比是对犯罪现场周边的视频监控录像逐一回看，非常辛苦。如果问题现场的日志记录缺失，就尝试在本地重现问题并调试解决，本地难以重现的，只能再加日志，再部署，再重现，然后再查日志，效率较低。对于复杂一些的比如程序性能问题，如何定位性能瓶颈，一不小心又要回到加日志、部署、查日志、再加日志的老路，不仅效率不高，也破坏了问题现场。

JDK 提供的工具如 jps、jmap、jstat、jstack、jconsole 等，可以为工程师提供一些帮助。Linux 操作系统的命令，如 top、free、pidstat、vmstat、iostat 等，也是排查问题尤其是性能调优必不可少的工具。但直接使用这些工具，对工程师的个人技术能力和经验要求较高。而且对企业来说，在生产环境直接通过命令行操作，是很敏感的行为。因此，如何在保证安全的基础上，又能像调试本地程序一样更便捷的排查分析，是个棘手的问题。

Arthas 的解决方案

2018 年我们在参加一次 Dubbo Meetup 上，听了关于使用开源的 Arthas 工具排查 Dubbo 问题的分享。研究发现，Arthas 通过 JVM 的 Attach 机制，在不影响服务连续性的情况下，实时连接到目标进程，便于工程师在线排查问题。此外，Arthas 的字节码增强框架，可以通过 Instrumentation 技术动态修改字节码（需要 Java 虚拟机实现支持 retransformClasses），替换成新的 class，这就为在线调试提供了可能。

Arthas 原理图：

比如，使用 watch 命令，实时观测方法的调用情况；使用 jad 命令，把字节码反编辑成 java 代码；使用 redefine 命令，可以对代码做热更新，让开发人员告别不停“加日志、部署、查日志、再加日志”的套娃时代。在 Arthas 刚推出没多久，还提供了一个简单的 Web Console 功能，实际是一个以 Websocket 访问 Arthas 进程的方式，这也为我们后面建设在线诊断平台提供了思路。

落地使用上的困难

直接使用 Arthas 的命令行交互方式，不能满足金融级运维要求，在落地使用上存在一些实际的问题：

信息安全问题：Arthas 可以通过命令行方式，直接观测方法的入参、返回值，这就涉及到一些客户敏感信息，直接在生产环境使用命令行操作显然是不合适的。
学习成本问题：工具的安装使用存在一定的学习成本，尤其是对于新员工来说。
多人协作问题：当多个开发者对同一个目标进程进行诊断时，可能存在冲突，例如，一个同学正在 watch 某个方法，另一个同学把这个方法 redefine 了，那么第一个同学 watch 到的其实是别人替换后的代码的运行情况，这就像一个多线程访问共享资源的线程安全问题。再比如两个同学都在 attach 同一个进程，一个同学用完了，直接把 Arthas 进程 shutdown（关闭），而另一个还在使用的同学就突然不能用了。
资源占用问题：如果开发者忘记关闭 Arthas，Arthas 进程会占用一定的系统资源（如内存、CPU）。当然，Arthas 本身对资源开销是有很多考虑的，比如 Arthas 使用自定义的类加载器加载自身的类，在关闭时将引用置空，这样在下一次垃圾回收的时候，自定义类加载器加载的类就会被回收，从而避免对原有工程的影响。因此，我们认为 Arthas 应该在排查问题时使用，而不应该当作常规监控工具一直运行。
环境不统一问题：在不同的 Java 虚拟机实现安装和使用 Arthas，可能会碰到一些奇怪的问题，比如用 Hotspot 虚拟机运行 Arthas 进程，而目标虚拟机是 J9 实现，attach 的时候可能会出错。另一方面，生产环境云上、云下节点规模庞大，网络访问权限是严格控制的，开发人员想远程连接目标进程，涉及到权限开通、版本管理、安装程序下发等问题。

技术方案

我们设计了一套轻巧的架构，让开发人员以 Web UI 的方式，便捷、直观的使用各类在线诊断能力。那么我们是怎么做的呢？

1. 整体架构

整体架构大致分成在线诊断平台、在线诊断网关（后简称网关）、在线诊断进程三部分，通过一个网关集群统一代理对云上、云下节点的访问，网关提供 Restful 接口给在线诊断平台（后简称平台）调用。一个接口可能组合了多个 Arthas 指令，也可能对指令的执行结果进行剪裁和修改，处理成 json 格式数据返回给平台做展示。

整体架构图：

1）在线诊断平台

在线诊断平台是开发人员进行在线诊断的入口，平台通过 Web UI 的方式提供一站式在线诊断能力，支持复杂的交互场景。除了提供出色的用户体验，平台还解决了安装卸载、多人协作、用户鉴权、连接保持、操作审计等问题。

安装卸载：根据用户在平台输入目标节点和进程信息，实现诊断程序的安装和卸载，具体将在下一节介绍。
多人协作：当多个用户同时诊断同一个进程时，对于存在冲突的功能，平台通过分布式锁实现互斥，保障同一时刻只有一个用户能使用，当然这么做的前提是平台在功能设计时考虑原子性。另外，当一个用户试图关闭一个其他用户正在使用的连接时，也会被拒绝。
用户鉴权：建立审批和黑白名单机制，基于 RBAC 模型，同时联动 CMDB，对操作人员的权限进行严格管控，普通开发者需要被授权才可使用，各类诊断功能的使用权限也和用户角色挂钩，权限控制强度从生产环境到开发环境逐渐减弱。
连接保持：Arthas 一些命令比如 dashboard，提供了实时监控目标进程整体运行情况的功能，默认每 5 秒刷新一次。对于这样的功能，平台的前端通过 websocket 与后端保持连接，后端内存中维护了一个目标对象和已连接用户的对照关系，如果多个用户同时监控某个目标对象，后端每次只会定时发送一次请求给网关。这么做的好处，是在保证了实时监控的同时，节约连接资源，避免了多人访问时，到目标服务器的不必要的重复连接。此外，为了防止用户忘记卸载诊断进程，对照关系也会同步到配置中心，当内存中某个目标对象对应的用户全部下线时，会触发一次检查，如果发现配置中心中的用户也已经全部下线，平台会自动发送 shutdown 请求给网关，卸载诊断进程。
操作审计：通过切面的方式，对用户的各类操作进行记录和存储，达到审计的目的。

2）在线诊断网关

网关的作用，一是统一打通了到行内云上、云下环境的火墙；二是由于我们当时使用的 Arthas 版本还不支持 Restful 接口（最新版本已支持），返回报文都是文本的形式，网关侧在这里会对文本进行解析，处理成 json 格式的结构数据，方便平台侧做展示。归纳起来，网关的主要目的是统一代理对目标节点的访问，同时封装诊断能力，提供标准 json 结构数据的 Restful 接口给行内各平台访问。网关在封装诊断能力时，还会进行参数校验、超时管理、数据脱敏、文本处理等工作。

参数校验：网关需要对诊断命令的参数做合法性校验，比如tt命令要控制最大观测次数防止撑爆内存，保证使用安全。
超时管理：一些监听类的命令，比如watch命令，如果一直监听不到调用，需要设置超时时间，防止连接一直不被释放。
数据脱敏：对于涉及客户敏感信息的命令，网关会做数据脱敏，保障客户信息安全，部分关键业务的敏感数据，网关侧会做封闭禁止访问。
文本处理：网关向 Arthas 进程发送指令后，收到的报文是文本形式，为了便于平台侧展示，网关将非结构数据处理成结构数据，并对文本中的一些非关键数据进行剪裁。这里要注意因为 telnet 有个窗口大小的配置要适当调整，配置太小的话有可能导致文本不全。

3）在线诊断进程

也就是 Arthas 进程，需要考虑安装、启停、版本管理、网络隔离等问题，具体做法在下一节详细介绍。

2. 诊断过程详解

工程师第一次对目标服务器进行诊断时，涉及安装、启动、使用、卸载等一系列步骤，如下图所示：

1）诊断前准备

下图是我们的安装界面，当用户授权通过后，即可填写目标服务器信息开始安装。如果是传统虚拟机时，用户需输入虚拟机 ip 和目标进程关键字（如进程的 pid、进程的启动类名、进程的 jar 名称等）；如果是容器，还需提供容易 id：

2）开始安装

用户点击安装后，会触发一系列操作。首先在线诊断平台发送一个探活请求给网关，网关收到请求后相应的也发送一个空指令给目标节点。平台根据响应判断，如果探活成功，则发送诊断请求开始诊断；否则发送安装请求到行内指定的管理系统（传统虚拟机/容器，后续简称通道）。

3）获取安装介质

以传统虚拟机为例（如果是容器则把安装介质下发到宿主机），通道去目标服务器指定目录查找诊断程序的版本文件，如果获取成功且版本是最新的，则通道直接执行启动脚本。否则，通道会通知目标服务器从公共的文件服务器上，下载最新版本的安装介质。

4）启动诊断程序

安装介质实际是一个压缩包，包括安装脚本、jar、版本文件等。安装介质首次下载到目标服务器后，通道对其解压并执行启动脚本。我们修改了 Arthas 的启动脚本，根据用户输入的进程关键字，找到目标进程，然后使用和目标进程相同的 jdk 版本，启动诊断程序。注意，启动时 Arthas 的 target-ip 参数被设置为网关地址，以隔离其他渠道访问，默认值 127.0.0.1 表示只能本地访问。

5）使用和卸载

诊断进程接收用户诊断指令，开始诊断。使用完用户可手工点击卸载，销毁诊断进程。

实际使用效果

这里举几个例子，看一下平台的实际使用效果。

1. 控制面板

基于 dashboard 命令，控制面板实时展示目标进程的整体运行情况，包括线程、jvm、操作系统等，每隔 10s 刷新一次，用户也可选择手动刷新。线程按 CPU 使用率取 TOP10，jvm 主要展示内存分布和 GC 情况：

点击查询更多可以查看详情，比如监控 jvm 的内存及垃圾回收情况：

2. 线程清单

线程清单页面按 CPU 使用率分页展示所有线程，支持按线程状态（如 RUNNABLE、BLOCKED）过滤，在控制面板页面点击查看更多，也可以直接跳到此页面：

点击某条记录，跳转到线程详情，展示线程堆栈，在堆栈中选中一个方法，则可以直接进行方法观测、方法追踪、方法追溯、方法监控、反编译等操作：

3. 方法监测

方法监测指的是对方法运行情况的监控和观测，具体包括下面几个功能。

1）方法观测

支持对选中的堆栈中的方法进行观测，也就是 watch 命令，这里以开发环境举例（开发环境不做数据脱敏），可以实时捕获方法的输入、输出、异常堆栈、执行耗时等，并且支持指定观测次数、耗时限制等条件。比如我这里对 UserServiceImpl 类的 findUser 方法的调用情况进行观测：

当方法抛异常时展示堆栈：

2）方法追踪

方法追踪指的是追踪方法的调用栈，打印每个方法的执行耗时，基于 trace 命令实现，在排查性能问题时非常有用。看一下方法追踪的界面，直接高亮标记出调用栈上耗时最久的方法，也支持配置过滤规则，过滤一些不关心的方法（比如 java 底层代码）。在这个方法调用栈界面，又可以选中其中某个方法，进行观测、追溯、监控等操作，不同的诊断能力之间都是打通的：

3）方法追溯

有时需要追溯方法被谁调用了，则可以使用方法追溯。比如这里通过方法追溯可以看到 Dubbo 的 Filter 处理链：

4）方法监控

有时我们需要对某个方法一段时间的执行情况进行观测，这时可以使用方法监控功能。比如这里每隔 10 秒统计一次方法的执行次数、成功失败次数、平均耗时、失败率等指标：

4. 反编译

当我们需要确认 Java 虚拟机加载的代码情况时，比如你修改的代码是否生效，我们在本地经常使用一些反编译工具以达目的。jad 命令提供了在线反编译能力，我们基于 jad 以界面的形式展示 Java 虚拟机加载的实际代码，同时也会展示类加载器树、类的路径。比如这里对 findUser 方法的反编译情况（不指定方法名的话，则对整个类反编译），可以看到这个类属于 springboot 项目，被 spring 的类加载器加载：

5. 其他能力

我们对其他的实用命令，也做了一些封装和定制，比如 sc、sm、redefine、tt 等，这里就不一一介绍。此外，我们也将实时诊断能力和内部监控运维系统相整合，在排查问题时，可以通过直接跳转的方式申请在线诊断权限，对目标进程做实时诊断。下图是行内全链路跟踪产品截图，支持直接对问题链路关联的节点进行诊断：

回顾与展望

简要回顾一下前面提到的几个困难和我们的解决方案：

学习成本问题：我们通过 Web UI 的方式降低学习成本，也提供了更复杂的交互场景和出色的用户体验。通过网关统一提供 Resful 接口提供结构数据，也更便于集成到企业内部其他运维平台。
多人协作问题：通过会话管理、互斥访问、自动卸载等手段，解决多人协作问题。
信息安全问题：通过用户鉴权、数据脱敏、操作审计、网络隔离等手段，解决信息安全问题。
资源占用问题：通过自动卸载、减少连接、自定义类加载器（Arthas自带）等手段，在充分性能测试基础上，保障资源占用可控。
环境不统一问题：通过搭建网关集群，统一代理对云上、云下环境的访问。采用一致的策略，统一管理云上、云下环境介质的版本、下发和安装。

当前，工行在线诊断平台已在实际线上问题分析中持续发挥关键作用，Arthas 也越来越得到社区的关注和开发者的认可。Arthas 官方在新版本中已经支持了 Restful 接口，提供结构数据，也支持了更丰富的诊断命令，这跟我们的建设思路不谋而合。未来，我们将继续积极参与社区建设，将工行的实践经验分享给大家。

Arthas 有奖征文正在进行中！

为了让更多开发者开始用上 Arthas 这个 Java 诊断神器，今年 3 月 26 日，Arthas 社区联合 JetBrains 推出 Arthas 有奖征文活动： 聊聊这些年你和 Arthas 之间的那些事儿。活动已进行至第五期，点击链接即可参与： http://alibabacloud.mikecrm.com/9khcRrs，欢迎大家踊跃投稿，参与即有可能获奖！

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

从Oracle到MySQL，金融核心场景在线换库落地实战 - MySQL

Thu, 17 Sep 2020 10:46:56 CST

本文根据王英杰老师在〖deeplus直播第234期〗线上分享演讲内容整理而成。 （文末有获取本期PPT&回放的方式，不要错过）

大家好，我是陆金所数据库团队的负责人王英杰。这次的分享主要集中在陆金所去O在线换库的技术特点上，之后详细给大家剖析陆金所设计的在线换库方案以及方案如何在一个庞大的金融系统里通过多个团队的紧密配合稳妥落地。

同时还会给大家介绍我们团队自研的一些去O工具，它们是怎么确保陆金所长达两年的全站去O，来帮助方案从开发测试、架构、运维等各个方面有条不紊地推进和落地。

除了去O方案外，我还会解答不少业内朋友的疑问——“为什么陆金所会启动这个全站去O的项目”，以及分享我们这个项目背景、去O前的设定目标等，以供大家去O参考。

希望通过这次介绍能让大家更深入地了解，一个金融系统要把Oracle这种商业数据库去掉会碰到的难点和风险，并且给想去O但是又不敢落地实施的同学提供一些案例实战解决的思路和方法。

一、成果

在完全不做服务降级的情况下，陆金所整个去O项目从2018年年中启动以来，历时两年已经把全站98%的数据库从Oracle无缝切换到MySQL上，这98%的数据库涉及到陆金所的账务、资金、资产中心以及我们能够想到的金融行业的主要业务场景。

在整个去O过程中我们也实现了全程0故障、0风险、对用户几乎不感知，因为我们在凌晨的流量低峰期才进行切换，而在整个切换过程中我们也不会做服务降级，所以整个过程用户也几乎不感知。

陆金所去O具备四大特质：

无缝：在线更换底层数据，库完全不做服务降级，让类似去O的重大项目改造、架构改造在最终落地实施的时候对外部用户的影响下降到最小，这一部分非常考验研发团队做去O架构改造的技术实现能力；
稳妥：把一个非常大的系统拆分成上百层次，再一点一点把数据库替换掉，全程实现0故障、0风险。在过去两年，陆金所没有因为去O而引发任何生产事故，所以说这一块在考验团队研发能力的同时也考验去O落地工具的设计和研发水平；
高效：短短两年就完成数据库98%的去O落地，最后2%也会在9月之前全部做完，也就是说在Q3，陆金所的数据库都会完成去Oracle化，整个推进速度还是比较快的；
智能：借助去O对陆金所整个生产环境的架构实现比较大范围的重构，实现从开发到测试再到运维自研各种落地智能工具，来把控去O各个核心环节的质量，真正对一个庞大复杂、对架构改造来说风险较大的金融核心系统做到大幅度落地去O。

在这个过程中也大幅度降低了去O过程中投入的人力成本，借助经验和辅助工具，在前期提前设计、规划好整个流程，在后期整个研发团队按照规划按部就班地推进，研发投入有了一定可控性。

在去O完成以后，也没有因为切换MySQL而增加特殊招聘的成本，整个运维团队也跟着实现了从Oracle到MySQL的转型，在人力成本方面做到了完全可控。

二、背景

1、为什么要启动全站100%去O的项目

为什么我们要启动全站去O这个项目，我们在立项之初希望通过去O对整个陆金所的研发有三方面的提升。

1）降低运营成本

成本是个非常现实的问题。如果一个金融系统增长的速度很快，体量已经到了一定规模的时候，能够把IOE去掉的话，能够很大程度降低运营成本，这一点是非常肯定的。也就是说，一个金融系统越大，它越能完成去IOE的话，对降低运营成本的提升也会非常大。

2013到2018年期间，陆金所的业务呈现快速增长的趋势，业务拓展了上百倍，在这种业务体量增长的情况下，我们继续使用传统的IOE设备的话对数据库运维成本来说是非常大的挑战。就算我们仅仅把I、E去掉，使用X86 + Oracle的存储架构、前台也做细粒度的拆分，Oracle的实例还是会很多，而全都购买Oracle实例的软件数对公司成本来说也是非常高的。

所以说评估下来，无论是在IOE还是X86+Oracle的架构，一个金融系统在业务量迅速增长的情况下，数据库运营成本都是非常高的。

2）摆脱技术绑架

其次很重要的一点是，我们想通过去O打造一个不依赖特定数据库特性的金融交易系统。

如果我们能够做到这一点，就可以彻底摆脱被商业数据库厂商技术绑架的风险。也就是说，我们希望通过去O对我们生产环境的系统进行大规模的重构，包括水平拆分、应用层服务化改造等一系列操作。

很多传统金融行业的系统都非常依赖数据库这个角色，包括利用数据库的存储过程、一些特有特性来确保金融场景的业务，甚至整个数据库的高可用也是通过硬件层面来实现的。

所以我们就想通过去O、使用最廉价的X86服务器，把数据库的角色转化为只支持最基本的增、删、改、查的存储引擎，涉及把原本由数据库实现的一些特性往上移，移到应用层和服务层来进行实现，这也是我们希望通过去O来实现的一个目标。

这样我们可以做到把传统金融的数据库承担的大量的业务逻辑和架构属性从数据库这个层面剥离出来，数据库层承担的角色就会更加简单和单一，以至降低整个运维层面的风险和难度。

3）提升研发能力

除了在运营和架构上会有一个很大的提升以外，我们也希望通过全站去O这个涉及到开发、测试、架构和DBA等全研发团队都参与的一个重大架构改造项目，来锻炼整个研发团队，提升研发能力。

在陆金所去O之前，整个系统会更偏向传统金融系统。而且它本身也有一些在历史上的架构设计不完善的问题，我们也希望通过去O来实现数据库的拆分、微服务化、分布式事务改造的架构工作，同时锻炼我们研发团队的能力。

以上主要就是陆金所最开始为去O制定的一些研发目标和相关的研发任务，后面的介绍的话也会围绕着我们通过解决这三个方面而最终实现了什么效果，给大家详细进行展开。

2、为什么选择MySQL，但不仅仅是MySQL

在去O之前需要对数据库进行选型，如果把Oracle替换掉的话我们要选择什么数据库来承载Oracle的流量呢？在这个过程中我们会从功能、资源、案例和压测这四个方面对后续选型进行通篇的考虑。

1）功能和性能

首先我们要评估能承接Oracle的数据库各种场景下的计算和IO能力。

2）资源

非常重要的是它必须具备非常广泛的社区资源、技术资料、问题处理案例（包括成功和踩坑的经验），这些都是我们评估替换的存储引擎非常重要的因素。

还有一点就是，它要有比较广泛的用户基础，方便我们技术栈后续转型时招聘对应的开发和运维工程师能有更大的选择。

3）案例

在整个行业，特别是金融场景下有比较好的参考案例。国内比较大的互联网公司之前在去O方面也给了我们一些好的成功案例以去借鉴和参考。

4）压测

最终在确定之后，陆金所上线之前会通过非常严格的压测环境，把一些想用的存储引擎使用生产环境最真实的数据在陆金所核心应用、核心接口反反复复进行压测，并且得到最终的压测数据，与生产环境的Oracle数据库的性能表现做对比以得到最终的评估。

陆金所在切换任何一张表流量的时候，我们都会使用生产环境最真实的数据进行Oracle和MySQL的压测，最终的压测结果还是非常不错的。我们发现在之前使用Oracle 11.2在sql语句的话sql接口比较简单，区分度和选择性又很高的情况下，其实Oracle和MySQL在性能上没有太大差别。而且我们也发现了，MySQL在一些特性，特别是在并行复制上，它的性能和表现比我们想象中的更好。

所以我们在两年前对MySQL 5.7进行多能压测以后，最终选定使用MySQL5.7成为我们去O的主要存储引擎。它在去O上主要承接所有与事务相关的写入，还有和用户的交互，金融层面上的订单、交易、账户、资产、资金的数据写入。

Oracle实际上是一个非常好的数据库，它能覆盖非常全面的场景。很多传统型公司，无论是前台交易库还是后台的数据仓库，都会选择使用Oracle。它在OLTP和OLAP场景下表现得都非常优秀，但是要把Oracle所有的计算场景全都承接下来的话，光使用MySQL是不够的。所以在这个过程中，我们也想借助去O的这个机会对生产环境引入更多的存储引擎，让它们在最合适的使用场景下发挥最大价值。

在使用过程中我们发现，实际效果还是不错的。基本上很多存储引擎都是开源系统，成本很低，而且在一些特定场景下的性能和处理速度比Oracle更快，所以最终选型决定了以MySQL为主，以TiDB、Redis、ES、HBase等存储引擎为辅的方式。

我们在去O的过程中不仅仅是去掉Oracle，我们也根据不同使用场景来引入更多的主流存储引擎。

三、方案

1、去O双写和切换方案

本次介绍特别重要的技术亮点是在线换库，图中左方是在线替换Oracle的主要架构图。

应用层面：

说到核心思路，在应用层面上看，Oracle和MySQL两套防御数据库的DAL层实现双写，中间有一个流量开关用于控制业务逻辑是走和Oracle相关的这一块还是和MySQL相关的这一块。

而且在去O的时候会有一个整体的规划，很重要的一点是要把一个特别大的系统拆分成多个独立落地的批次。有些像交易、资产中心的系统做底层服务，上面被关联、调用到的系统会很多。

在去O过程中的某一个晚上，把特别大的流量从Oracle迁移到MySQL的风险是非常高的，所以我们在去O的过程中会拆分成特别小的批次，而且每一个小的批次做到每一次变更的风险、改造的工作量和难度都在可控范围内。基于这个方式，我们把一个应用系统拆分成多个批次以后，会在应用层面将业务逻辑层面进行上移。

这个时候，我的业务逻辑层面无论是仿Oracle还是MySQL都是同样的一套，只是最终是由流量开关来决定流量从Oracle的DAL层走还是从MySQL的DAL层走，每一个批次都会有专属的流量开关来进行控制。

数据库层面：

在整个改造的过程中，会涉及应用版本的发布。应用在发版的过程中会不断将流量开关发布上线，包括和Oracle对等的MySQL的代码也一起发布上线。

在发版的过程中Oracle数据库并没有发生变化，同时它还在对外提供服务。这个时候我们会在Oracle后面建立一个实时数据同步的MySQL数据库。

假设Oracle这边有一笔事务提交，它会以秒级的速度往MySQL数据库进行同步。在这个过程中，大家可以将整个架构理解为，Oracle后面挂了一个秒级实时同步的备库。

根据这套框架，陆金所研发了一套自动化的双建框架，如果我们的Oracle数据库需要去O，系统流程如下：

确定好批次，框定需要去O的表的批次再在系统中勾选好；
系统会对这些批次的表中的数据做全量增量，包括双向同步的建立，都在后台自动完成。这样是把整个运维层面、数据库层面等需要人为介入的工作都通过自动化的方式来完成；
等待应用版本发布上线以后进行流量切换。其中设置了一个总控开关控制从应用到数据库，从到Oracle到MySQL数据同步的整个流向，从而进行全盘切换；
最后实现Oracle的数据实时同步到MySQL。在流量切换的瞬间，可以做到当这笔事务在Oracle成功提交且同步到MySQL以后，确保在MySQL中也成功提交了的话后台会对这笔事务进行最后一次质量校验，校验后才会将流量从Oracle切换到MySQL，全程由流量开关控制整个过程。在这个过程中的步骤比较复杂，无论是哪一步出了问题，总控开关都可以让整个流量切换过程回到最开始的原点。这个过程类似于Oracle数据库里的在线重定义，不同的是在线重定义是Oracle的一张表到Oracle的另一张表，是从Oracle到MySQL，并且流量切换到了MySQL以后会把流量进行反向同步。

2、应用流量在O和M之间快速切换

接下来介绍整个流量切换的三个状态，在图中这三个状态描写得比较简单，在真正的实际操作中大约会有16个步骤，但整个流程会在10秒内落地完成：

初始状态：最开始所有的流量会从Oracle到同步到MySQL，这时候还是由Oracle提供服务；
中间状态：切换时，在确保Oracle上的最后一笔数据提交成功且同步到MySQL以后，完成最后一笔增量比对。在这个过程中，Oracle和MySQL的写服务会短暂地处于不可用状态，为了确保Oracle同步到MySQL的最后一点数据都没有问题，所以整个过程非常快速。我们实践中完成上百个批次的切换，平均单个批次4秒钟；
完成状态：最后把MySQL的写开关打开，几乎所有流量在MySQL上且从MySQL上写入，之后数据会反向从MySQL同步到Oracle。在整个流量切换的过程中，反向同步是为了避免切换过去后20%-30%概率的应用问题，比如运用上的bug，或者说接口性能不符合预期，这种时候就要往回切。

往回切时，MySQL在完成切换的时间点就已经开始对外提供服务了。所以这时要确保Oracle和MySQL的数据一致性，必须确保在MySQL写入的数据实时反向同步到了Oracle。在切换过去之后，一旦主库从Oracle变成了MySQL，MySQL的数据就要反向同步回Oracle，它就变成了一个备库，所以保证两个数据库中的数据一致非常重要；
万一切换到MySQL的时候出现问题，在10秒之内整个流量会从MySQL再往Oracle切。这个过程中，无论走到哪一步都要确保Oracle和MySQL的数据一致，其中任何一步出错，都可以快速回滚到最开始的状态。如果整个切换流程结束，但是MySQL那边的数据出现问题，也可以快速往Oracle回切。

3、适用于金融核心系统的稳妥去O推进方案

接下来分享的是大家在去O过程中的一个痛点：我们对大规模的系统进行去O改造，到底要从哪里入手？怎么做才能将系统风险降到最低而且全程可控？

这个痛点也是非常重要的一点，上面说到过陆金所很多系统的规模都很大，我们就会将其拆分成很多个批次。图中显示的是拆分成的3个批次，但在一些更大的系统当中，会被拆分成15个以上的批次，整个持续改造的时间超过12个月，我们在很长的时间里应用将数据一点一点地从Oracle切换到MySQL。

这整个过程可以总结为： 以表为粒度建立批次，以批次为单位推进去O落地。那我们为什么要这么做呢？

如果以表为粒度，把一个包括了庞大金融系统的阀拆分成多个批次的话，我们只要把跟业务、事务相关的表放在同一个批次下，就可以确保在做去O改造的过程中单个批次的改造难度、上线进度、切换风险是可控的。这样，我们就把一个需要花费高时间、人力成本要做去O的核心系统，通过拆分降低成本，每一次做变更和上线发版的时候就只用对其中的一部分表做去O，而且整个推进的过程中单个去O版本里需要改造的内容也非常少。如果这个批次在改造过程中有些问题，拆分批次的操作也会将全站的风险降到最小；
另外，如果在这个批次足够小的情况下，去开发进行去O改造，也可以快速落地和推进到生产环节；
最后进行相关流量的切换。因为整个流量切换的过程不做服务降级，那么单个批次切换的表越小，单个切换的瞬间对系统造成的影响就会越小。

刚才说的就是一个 “小步快跑”高速迭代的过程，我们按照这个原则进行操作。图中可以看到，应用层上不断有版本发布，以下是我们实践中的操作流程：

将大系统拆分成多个批次；
逐步对这些批次进行去O改造；
在做去O改造的过程中将整个业务逻辑层往上移；
之后完成Oracle和MySQL两边的流量开关、DAL层相关的代码的改造工作；
持续做版本发布。

整个过程中Oracle持续对外提供服务。版本上线后运维会进行测试，之后整个数据库的双写机制就会通过自动化运维体系建立起来。

我们在图中看到，Oracle和MySQL是完全对等的关系，但实际上Oracle上IOE设备的比例非常重，在拆分的过程中不同的表会往不同的X86服务器去拆。我们以表为粒度就实现了数据库的架构拆分的相关工作。

按照这个维度一点点地进行拆分，只要这张表要上线和切换，我们在后台完全建立起这套同步机制之后，就等待应用上线完成。从应用1.0版本到1.1、1.2，最后到应用1.3的版本，应用不断迭代发版。

每上线一个版本后台中就会切换一个批次，这个批次从Oracle切到MySQL只会涉及少量部分的表，切换过去没有问题的话就会在生产环境中不断地跑。如果有问题的话再把它再从Oracle往MySQL进行回切。整个过程按这种思路来落地和推进的话会非常稳妥。

但是这个过程需要运维团队有足够好的工具进行支撑，才能顺利完成。可以从图中看到，整个过程中有一些应用改造所需要的时间跨度很长，比如说持续超过一年，会有十几个批次需要进行去O改造。

第一张表从Oracle往MySQL切的时候，整个应用的服务会由两个数据库同时对外提供服务，在这个过程中就涉及到了在做版本发布的时候的很多问题。

比如，要发哪个表？加哪个字段的时候要加哪个表？是加Oracle还是MySQL？是先加Oracle还是先加MySQL？这个过程包括了后续相关的运维操作，所以这部分首先需要一整套完善的自动化运维体系来确保这个操作框架顺利推进，同时保证我们在长时间的去O改造过程中，以Oracle和MySQL作为一个应用同时提供服务的时候，每天高频上线的所有版本和数据库变更都不会出任何问题。

以陆金所为例，我们采用了这套框架来推进去O改造，我们很多核心系统的改造基本上花费12个月或以上，基本上一点点地把Oracle数据库给替换掉。并且整个过程是完全不做服务降级的，所以对陆金所4500万多用户来说几乎无感知。

四、目标 / 效果

1、通过去O大幅降低运营成本

1）去O前

陆金所去O之前使用的都是IOE设备，数据库的量不多、也没有进行服务化的改造。那个时候的架构就是一个比较传统的金融架构，很多应用向一个比较大的Oracle数据库进行访问。DBA团队每天的工作就做好几个核心数据库的预用。

做完去O之后的架构没有了IOE的设备，通过普通的MySQL+X86服务器支撑起陆金所整个的数据库架构。由于X86服务器的价格非常低，从投入成本方面来说，每年的运营成本大幅度下降，整个数据库软硬件的采购成本下降至不到之前采购成本的百分之十。

整个去O过程持续两年左右，让我们团队对人员的要求有了全方位的变化，因为后续自动化运维体系和MySQL的运维都需要有一整套相对完善的自动化运维工具用作支撑。

而且去O过程中两个数据库之间会有长达一年的双写过程，整个版本在发布和日常数据库变更中是完全不能出现问题的，所以这个工作必须通过自动化来完成。如果通过人为介入完成双写，在上线之后在很多细节问题上有很大几率会出错，所以我们在这过程中就运用了一套强大的CMDB和数据库的运维体系进行支撑。

2）去O后

完成去O之后，陆金所整体的架构变得非常清晰，同时我们也通过去O完成了服务化改造。

这样，我们各个核心的业务模块都以微服务化驱动的方式形成一个分布式的相关架构，而且每个服务都有自己的应用和数据库，每个数据库在完成去O和服务化改造之后只给服务内的应用提供直接访问。

如果非服务内的应用想直接访问数据库的话，我们会通过配置中心进行配置，它们是完全没有相关访问权限的；如果服务之外的应用想要访问数据库的话，必须走应用层提供的相关服务接口，这样就避免了跨服务器直接访问数据库。

整个服务访问分为同步调用和相关异步调用。如果服务比较大，在服务内部我们就会对数据库进行水平拓展；如果是类似用户、交易、资金这种公共类服务，后续它们会陆续迭代成一些比较大的中台服务。

通过整个去O的过程，陆金所整个IT的架构就变成集中式的大库和MySQL的小库。之后如果对容量有扩展的需求，我们还可以对这套架构进行更细粒度的拆分，可以呈现数据库水平扩展。

2、通过去O在架构上大幅优化

完成去O之后，我们实现了数据库层面的几个特性：

去中心化：在去O之前，陆金所的几套大库如果任何一套出现问题，都会对陆金所的全站可用率产生影响。而拆分到MySQL之后，MySQL跑到X86上，X86的硬件可用率比之前存储盒小型机的时候差很多，所以在MySQL这部分会做更细粒度的拆分。对单个MySQL数据库来说，拆分之后一旦出现故障、需要切换的时候，对全站可用率的影响完全可控。实现这套框架后，我们也可以把不同的MySQL布置在不同的机房，在网络调用可控的情况下，实现真正意义上的机房多活；
弹性扩容；
应用层的服务化拆分；
应用访问数据库的规范化落地。

3、通过去O在各种不同场景引入最合适的存储引擎

陆金所在去O前对存储引擎进行了架构选型，涉及到架构选型的时候会支持哪些业务场景、通过哪些数据库承接。

去O不仅仅是流量去到MySQL，因为MySQL无法承接Oracle的全部流量，所以需要特别考虑下面几种场景的流程承接方案：

Oracle当中少量hash join查询场景 ：这些在OLTP场景下的查询的qps不大，Oracle处理这种查询相对比较得心应手，而在MySQL 5.7下完全无法处理这种查询；
Oracle中多表关联和多层复杂嵌套查询场景；
在MySQL细粒度拆分后，跨库、跨分片的查询场景；
在MySQL集群和Hadoop集群之间构建一个秒级数据同步的ODS层。

为了解决以上问题，我们引用了一些新的存储引擎，发现它们在合适的场景下替换Oracle产生的效果不仅比IOE的成本更低、性能更快。

五、场景

使用TiDB承接Oracle流量：

六、落地

1、应该如何落地呢

左边是一套传统的金融架构系统框架，那么怎样变成右边这一套做过I域拆分、水平分片、去O改造的一套陆金所系统架构？PPT里画得比较简单，在实际生产环境中系统还在对外提供服务的时候，我们应该怎样对一个7*24小时的金融核心系统进行这么大的架构改造呢？

这本身就是一个高风险的工作。我们在过程中要做到规避风险，又确保各种工程实现细节有效落地，还同时保证系统的业务连续性，甚至是对外部用户几乎不感知。

2、理解去O这类架构改造的本质

3、建立起强大的去O风控系统

4、有效支持多团队协同配合

5、陆金所去O的落地节奏

七、写在最后

比起降低成本，陆金所去O收益更大的是整个研发团队的提升：

去O的细节内容除了数据库外，还会涉及：

去O的架构改造方案
去O中间件
去O的开发规范和开发技巧
如何进行去O压测
去O的运维变更方案
去O工具

通过全站系统的去O落地实践，我们对去O改造各个阶段中需要谨慎处理哪些细节，规避什么风险都有了一定的研究和积累。

>>>>

Q & A

Q1：这里的数据同步用的工具是什么？ Oracle和MySQL间数据如何实时同步？事务提交是否要在Oracle和MySQL双提交交易才返回？ 最后一步交易如何识别？

A：数据同步是使用陆金所自研的同步工具，原理是解析Oracle的redolog和MySQL的binlog来实现O和M之间的双向同步，要特别注意解决循环写入的问题。事务只要在当前的写流量所在的写库提交即返回事务成功响应。以CAP的方式来看待这个方案，可以理解为在数据同步双写阶段是一个确保AP模式的分布式架构，在写流量切换的一瞬间切换为CP模式，切换完成后又恢复到AP模式。目标是确保以异步方式实现双写，不要因为双写同步而影响生产的写流量。

Q2：前后数据库服务器的数量增加了多少？

A：因为服务化和分片改造，去O后MySQL的实例数量大概是Oracle的5到10倍之间。

Q3：存储过程是如何处理的？全部转移到应用端处理吗？

A：存储过程的业务逻辑在应用层通过java重构，存储过程的数据库交互操作在应用DAL层实现，SQL写在mybatis里。

Q4：这个切换的批次是如何划分的？有什么方法吗？

A：按在业务和服务尽可能的拆分小，让单个批次的去O改造工作量和变更风险足够可控。

Q5：单个微服务MySQL采用什么高可用架构?

A：一主多从，两地三中心，MHA。

Q6：选型时有考虑PostgreSQL吗？

A：PGSQL这几年成长很快，但目前找到顶尖的PGSQL工程师相对MySQL工程师会更难。同时金融场景使用MySQL重构在一线互联网公司有更多的落地，所以我们选择了使用MySQL来替换Oracle中的事务写入场景。未来我们会在陆金所生产环境使用更多的PGSQL来承接流量。

Q7：有运行在国产处理器平台的数据吗？

A：国产处理器评估中，未来会采用。

Q8：异地机房数据同步怎么做的？

A：使用MySQL原生的主备同步模式。

Q9：在保证Oracle与MySQL写保持一致时，对前端业务会有影响吧？有多大影响？

A：切换期间写操作会有瞬间抖动，抖动持续几秒后恢复，写接口具备重试能力且批次拆分的足够小，对外部用户几乎不感知。

Q10：是否全部是community版本？分库分表使用现有中间件还是自研的？

A：Percona分支版本，自研中间件。

Q11：请问自动化管理工具是用什么开发的？

A：Python，涉及到运维和开发两个板块。

Q12：请问你们的异步消息总线用的什么？

A：自研的日志解析器+消息中间件+管理平台。

Q13：切换到MySQL后，同城双活架构（数据层双活）变成怎么样的？

A：基于数据路由层+数据库分片架构实施。

Q14：Oracle redolog解析是用的开源工具还是自研工具？

A：自研。

Q15：对于有关联的业务查询，拆分细了如何解决？有时关联操作的代价太大了。

A：先做服务化改造，数据库对象仅提供给服务内的应用访问，服务之外的应用不能直接访问数据库对象。这是去O改造的基础。

Q16：传统行业的存储过程是怎么处理的？

A：具体问题具体分析，功能拆分、服务化、数据库拆分是重点工作，在这个过程中实现去存储过程、去O。

Q17：双写的功能可以开发，但切到MySQL之后，如何评估它是否能支撑原来Oracle的高并发业务？或者说，压测如何模拟实际业务的流量？

A：在切换之前要进行严格的压力测试，压测数据库的数据来源于生产脱敏，确保数据量和数据分布和生产一致。压测需要覆盖每一个去O接口，开发和DBA需要自动或人工审核每一笔改造的SQL执行计划，压测需要得到所有接口和SQL在O和M之间的响应时间。

获取本期PPT请添加助手微信：dbachen

↓点这里可回看本期直播
阅读原文

转@架空管线 “要有新的歌颂方法”转@絕望的鹹魚所有能自由创作的东西，在这片土地上都不能创作，然后社会永远都是在追求「创新」。呼唤什么缺什么。

Fri, 12 Jun 2020 22:08:20 CST

转@架空管线 “要有新的歌颂方法”转@絕望的鹹魚所有能自由创作的东西，在这片土地上都不能创作，然后社会永远都是在追求「创新」。呼唤什么缺什么。

中移在线容器平台入选云原生应用十大优秀案例，成为全球最大客服云案例

Tue, 09 Jun 2020 23:55:32 CST

近日，中国通信标准化协会云计算标准和开源推进委员会（已下简称信通院）主办《OSCAR 开源先锋日——云原生专场》，由云原生开源产业联盟、CNCF基金会联合选出的2020年度云原生应用十大优秀案例重磅发布。谐云为中移在线服务有限公司（以下简称中移在线）搭建的容器云PaaS平台项目在众多头部企业实践案例的激烈角逐中脱颖而出，成功入选云原生十大优秀案例，并成为全球最大的客服专有云案例。

近几年，中国本土的云原生力量已得到长足发展，生态体系逐步完善，本土引领的云原生开源项目开始反哺国际社区。云原生应用范围也逐步由互联网向传统行业拓展，帮助传统企业构建“好用的架构”和“适用于云的应用”。云原生应用十大优秀案例的评选，旨在推广云原生应用在行业成功落地的实践经验，树立行业先锋典范。同时本次活动征集的十大优秀案例将入选首版中国云原生生态图景（landscape）。中移在线容器化PaaS项目以高资源弹性伸缩、高持续交付效率、大规模集群&容器实例、跨中心容器、技术/应用服务等创新等高效应用价值博得了评委的一致好评与认可。

入选理由

中移在线容器云PaaS 平台的创新价值主要体现在三个方面：

第一，搭建了全球最大的客服专有云。实现了自主研发容器云在客服多场景中大规模应用，打造了开源自主、国产可控、技术领先的客服专有容器云，为其提供10亿级用户支撑能力。

第二，降低IT 资源运行和集成成本，打造了高性能高效率高可靠环境。利用容器化带来的虚拟化能力替代原有虚拟机的资源隔离方式，节约大量的许可成本，实现资源层面的降本增效，并通过混合部署，结合业务负载自动弹性扩缩容，资源利用率提升至业内领先水平。

第三，建设容器化云服务环境，从整体提高开发、运维、管理的收益。利用容器云的标准化帮助开发效率提升70%，管理定责效率提升90%以上，同时通过建设高可靠高性能集群，为中间件容器化提供切实有效的运行基础，结合Operator组件，在中移在线生产环境实现了企业级的容器化中间件自助服务能力。

中移在线容器云PaaS 平台的落地，具有明显的示范意义。目前，谐云为中移在线容器云PaaS平台搭建已经到了第三期，实现了全量业务的容器化改造迁移和全面的技术升级。谐云作为中国数字基础设施建设云原生软件的领军企业，独自凭借着强大的底层核心技术实力和专业的服务交付能力，在大型企业中获得了广泛、成功的实践，为企业奠定了坚实的技术基石。

接下来，谐云也将一同继续参与信通院在云原生白皮书撰写等方面的工作，为云原生技术的应用落地和加速创新做出贡献！

Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾

Wed, 27 May 2020 11:22:28 CST

Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。

本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。

前言

Service Mesh 在企业落地中有诸多挑战，当与传统微服务应用共同部署治理时可用性挑战更为严峻。本次分享将以 Service Mesh 与 Spring Cloud 应用互联互通共同治理为前提，着重介绍基于 Consul 的注册中心高可用方案，通过各种限流、熔断策略保证后端服务的高可用，以及通过智能路由策略（负载均衡、实例容错等）实现服务间调用的高可用。

Service Mesh 与 Spring Cloud 应用的互通、互联

微服务是时下技术热点，大量互联网公司都在做微服务架构的推广和落地。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。而在这个技术转型中，国内有一个现象，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。近年来，新兴的 Service Mesh 技术也越来越火热，受到越来越多开发者的关注，大有后来居上的趋势。

在听到社区里很多人谈到微服务技术选型时，注意到他们讨论一个非此即彼的问题：采用 Spring Cloud 还是以 Istio 为代表的 Service Mesh 技术？然而这个答案并非非黑即白、非你即我，一部分应用采用 Spring Cloud，另一部分采用 Service Mesh（Istio）是完全可能的。今天我就和大家一起来讨论这个问题。

首先，我们来看一下 Spring Cloud 这个传统侵入式微服务框架。它包含以下优点：

集大成者，Spring Cloud 包含了微服务架构的方方面面；选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架；
轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者；
开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发；
开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件；

特别感谢 Netflix，这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡献给了社区，早期的 Spring Cloud 主要是对 Netflix 开源组件的进一步封装。不过近两年，Spring Cloud 社区开始自研了很多新的组件，也接入了其他一些互联网公司的优秀实践。

接下来，我们简单看一下 Service Mesh 框架。它带来了两大变革：微服务治理与业务逻辑的解耦，异构系统的统一治理。此外，服务网格相对于传统微服务框架，还拥有三大技术优势：可观察性、流量控制、安全。服务网格带来了巨大变革并且拥有其强大的技术优势，被称为第二代“微服务架构”。

然而就像之前说的软件开发没有银弹，传统微服务架构有许多痛点，而服务网格也不例外，也有它的局限性。这些局限性包括：增加了链路与运维的复杂度、需要更专业的运维技能、带来了一定的延迟以及对平台的适配。

更多关于 Spring Cloud 与 Service Mesh 的优缺点与比较，请阅读 Istio-Handbook [ Service Mesh 概述]。

前面提到过，对于传统微服务框架 Spring Cloud 与新兴微服务框架 Service Mesh，并非是个非黑即白，非你即我，延伸到微服务与单体架构，它们也是可以共存的。

也可以将其与混合云相类比，混合云中包含了公有云、私有云，可能还有其它的自有基础设施。目前来看，混合云是一种流行的实践方式；实际上，可能很难找到一个完全单一云模式的组织。对多数组织来说，将一个单体应用完全重构为微服务的过程中，对开发资源的调动是一个很严峻的问题；采用混合微服务策略是一个较好的方式，对开发团队来说，这种方式让微服务架构触手可及；否则的话，开发团队可能会因为时间、经验等方面的欠缺，无法接受对单体应用的重构工作。

构建混合微服务架构的最佳实践：

最大化收益的部分优先重构；
非 Java 应用优先采用 Service Mesh 框架；

混合微服务出现的原因是为了更好的支持平滑迁移，最大限度的提升服务治理水平，降低运维通信成本等，并且可能会在一个较长的周期存在着。而实现这一架构的前提，就是各服务的“互联互通”。

要想实现上述“混合微服务架构”，运行时支撑服务必不可少，它主要包括服务注册中心、服务网关和集中式配置中心三个产品。

传统微服务和 Service Mesh 双剑合璧（双模微服务），即“基于 SDK 的传统微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标：

互联互通：两个体系中的应用可以相互访问；
平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知；
灵活演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进；

这里还包括对应用运行平台的要求，即两个体系下的应用，既可以运行在虚拟机之上，也可以运行在容器/K8s 之上。我们不希望把用户绑定在 K8s 上，因此 Service Mesh 没有采用 K8s 的 Service 机制来做服务注册与发现，这里就突出了注册中心的重要性。

百度智能云 CNAP 团队实现了上述混合微服务架构，即实现了两个微服务体系的应用互联互通、平滑迁移、灵活演进。上述混合微服务架构图包括以下几个组件：

API Server：前后端解耦，接口权限控制、请求转发、异常本地化处理等等；
微服务控制中心：微服务治理的主要逻辑，包括服务注册的多租户处理、治理规则（路由、限流、熔断）的创建和转换、微服务配置的管理；
监控数据存储、消息队列：主要是基于 Trace 的监控方案使用的组件；
配置中心：微服务配置中心，最主要的功能是支持配置管理，包括治理规则、用户配置等所有微服务配置的存储和下发，微服务配置中心的特色是借助 SDK 可以实现配置/规则热更新；

接下来主要看一下注册中心的服务注册和发现机制：

Spring Cloud 应用通过 SDK、Service Mesh 应用实现 Sidecar 分别向注册中心注册，注册的请求先通过微服务控制中心进行认证处理与多租户隔离；
Mesh 控制面直接对接注册中心获取服务实例、Spring Cloud 应用通过 SDK 获取服务实例；
双模异构，支持容器与虚机两种模型；

注册中心与高可用方案

前面提到过，要想实现实现混合微服务架构，注册中心很关键。谈到注册中心，目前主流的开源注册中心包括：

Zookeeper：Yahoo 公司开发的分布式协调系统，可用于注册中心，目前仍有很多公司使用其作为注册中心；
Eureka：Netflix 开源组件，可用于服务注册发现组件，被广大 Spring Cloud 开发者熟知，遗憾的是目前已经不再维护，也不再被 Spring Cloud 生态推荐使用；
Consul： HashiCorp 公司推出的产品，其可作为实现注册中心，也是本文介绍的重点；
Etcd：Etcd 官方将其定义为可靠的分布式 KV 存储；

我们注册中心选择了 Consul，Consul 包含了以下几个重要的功能：

服务发现：可以注册服务，也可以通过 Http 或 DNS 的方式发现已经注册的服务；
丰富的健康检查机制；
服务网格能力，最新版本已经支持 Envoy 作为数据面；
KV 存储：可以基于 Consul KV 存储实现一个分布式配置中心；
多数据中心：借助多数据中心，无需使用额外的抽象层，即可构建多地域的场景，支持多 DC 数据同步、异地容灾；

上图是 Consul 官网提供的架构图。Consul 架构中几个核心的概念如下：

Agent: Agent 是运行在 Consul 集群的每个节点上的 Daemon 进程，通过 Consul Agent 命令将其启动，Agent 可以运行在 Client 或者 Server 模式下；
Client：Client 是一种 Agent，其将会重定向所有的 RPC 请求到 Server，Client 是无状态的，其主要参与 LAN Gossip 协议池，其占用很少的资源，并且消耗很少的网络带宽；
Server：Server 是一种 Agent，其包含了一系列的责任包括：参与 Raft 协议写半数（Raft Quorum）、维护集群状态、响应 RPC 响应、和其他 Datacenter 通过 WAN gossip 交换信息和重定向查询请求至 Leader 或者远端 Datacenter；
Datacenter: Datacenter 其是私有的、低延迟、高带宽的网络环境，去除了在公共网络上的网络交互；

注册中心作为基础组件，其自身的可用性显得尤为重要，高可用的设计需要对其进行分布式部署，同时因在分布式环境下的复杂性，节点因各种原因都有可能发生故障，因此在分布式集群部署中，希望在部分节点故障时，集群依然能够正常对外服务。注册中心作为微服务基础设施，因此对其容灾和其健壮性有一定的要求，主要体现在：

注册中心作为微服务基础设施，因此要求出现某些故障（如节点挂掉、网络分区）后注册中心仍然能够正常运行；
当注册中心的发生故障时，不能影响服务间的正常调用；

Consul 使用 Raft 协议作为其分布式一致性协议，本身对故障节点有一定的容忍性，在单个 DataCenter 中 Consul 集群中节点的数量控制在 2*n + 1 个节点，其中 n 为可容忍的宕机个数。Quorum size: Raft 协议选举需要半数以上节点写入成功。

Q1: 节点的个数是否可以为偶数个？ A2：答案是可以的，但是不建议部署偶数个节点。一方面如上表中偶数节点4和奇数节点3可容忍的故障数是一样的，另一方面，偶数个节点在选主节点的时候可能会出现瓜分选票的情形（虽然 Consul 通过重置 election timeout 来重新选举），所以还是建议选取奇数个节点。

Q2: 是不是 Server 节点个数越多越好？ A2：答案是否定的，虽然上表中显示 Server 数量越多可容忍的故障数越多，熟悉 Raft 协议的读者肯定熟悉 Log Replication（如上文介绍，日志复制时过半写成功才返回写成功），随着 Server 的数量越来越多，性能就会越低，所以结合实际场景一般建议 Server 部署3个节点。

推荐采用三节点或五节点，最为有效，且能容错。

注册中心设计的一个重要前提是：注册中心不能因为自身的原因或故障影响服务之间的相互调用。因此在实践过程中，如果注册中心本身发生了宕机故障/不可用，绝对不能影响服务之间的调用。这要求对接注册中心的 SDK 针对这种特殊情况进行客户端容灾设计，『客户端缓存』就是一种行之有效的手段。当注册中心发生故障无法提供服务时，服务本身并不会更新本地客户端缓存，利用其已经缓存的服务列表信息，正常完成服务间调用。

我们在设计时采用同 Datacenter 集群内部部署3个 Server 节点，来保障高可用性，当集群中1个节点发生故障后，集群仍然能够正常运行，同时这3个节点部署在不同的机房，达到机房容灾的能力。

在云上环境，涉及多 region 环境，因此在架构设计设计时，我们首先将 Consul 的一个 Datacenter 对应云上一个 region，这样更符合 Consul 对于 Datecenter 的定义（DataCenter 数据中心是私有性、低延迟、高带宽的网络环境）。中间代理层实现了服务鉴权、多租户隔离等功能；还可以通过中间代理层，对接多注册中心。

云上环境存在多租户隔离的需求，即：A租户的服务只能发现A租户服务的实例。针对此场景，需要在『中间代理层』完成对多租户隔离功能的实现，其主要实践思路为使用 Consul Api Feature 具备 Filtering 功能：

利用 Filtering 功能实现租户隔离需求；
减少查询注册中心接口时网络负载；

通过治理策略保证服务高可用

什么是高可用？维基百科这么定义：系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。我们通常用 N 个9来定义系统的可用性，如果能达到4个9，则说明系统具备自动恢复能力；如果能达到5个9，则说明系统极其健壮，具有极高可用性，而能达到这个指标则是非常难的。

常见的系统不可用因素包括：程序和配置出 bug、机器故障、机房故障、容量不足、依赖服务出现响应超时等。高可用的抓手包括：研发质量、测试质量、变更管理、监控告警、故障预案、容量规划、放火盲测、值班巡检等。这里，将主要介绍通过借助治理策略采用高可用设计手段来保障高可用。

高可用是一个比较复杂的命题，所以设计高可用方案也涉及到了方方面面。这中间将会出现的细节是多种多样的，所以我们需要对这样一个微服务高可用方案进行一个顶层的设计。

比如服务冗余：

冗余策略：每个机器每个服务都可能出现问题，所以第一个考虑到的就是每个服务必须不止一份，而是多份。所谓多份一致的服务就是服务的冗余，这里说的服务泛指了机器的服务、容器的服务、还有微服务本身的服务。在机器服务层面需要考虑，各个机器间的冗余是否有在物理空间进行隔离冗余。
无状态化：我们可以随时对服务进行扩容或者缩容，想要对服务进行随时随地的扩缩容，就要求我们的服务是一个无状态化，所谓无状态化就是每个服务的服务内容和数据都是一致的。

比如柔性化/异步化：

所谓的柔性化，就是在我们业务允许的情况下，做不到给予用户百分百可用的，通过降级的手段给到用户尽可能多的服务，而不是非得每次都交出去要么 100 分或 0 分的答卷。柔性化更多是一种思维，需要对业务场景有深入的了解。
异步化：在每一次调用，时间越长存在超时的风险就越大，逻辑越复杂执行的步骤越多，存在失败的风险也就越大。如果在业务允许的情况下，用户调用只给用户必须要的结果，不是需要同步的结果可以放在另外的地方异步去操作，这就减少了超时的风险也把复杂业务进行拆分减低复杂度。

上面讲到的几种提高服务高可用的手段，大多需要从业务以及部署运维的角度实现。而接下来会重点介绍，可以通过 SDK/Sidecar 手段提供服务高可用的治理策略，这些策略往往对业务是非侵入或者弱侵入的，能够让绝大多数服务轻松实现服务高可用。

微服务之间一旦建立起路由，就意味着会有数据在服务之间流通。由于不同服务可以提供的资源和对数据流量的承载能力不尽相同，为了防止单个 Consumer 占用 Provider 过多的资源，或者突发的大流量冲击导致 Provider 故障，需要服务限流来保证服务的高可用。

在服务治理中，虽然我们可以通过限流规则尽量避免服务承受过高的流量，但是在实际生产中服务故障依然难以完全避免。当整个系统中某些服务产生故障时，如果不及时采取措施，这种故障就有可能因为服务之间的互相访问而被传播开来，最终导致故障规模的扩大，甚至导致整个系统奔溃，这种现象我们称之为“雪崩”。熔断降级其实不只是服务治理中，在金融行业也有很广泛的应用。比如当股指的波动幅度超过规定的熔断点时，交易所为了控制风险采取的暂停交易措施。

负载均衡是高可用架构的一个关键组件，主要用来提高性能和可用性，通过负载均衡将流量分发到多个服务器，同时多服务器能够消除这部分的单点故障。

以上治理规则在某种程度上可以在 Spring Cloud 与 Service Mesh 两个框架上进行对齐，即同一套治理配置，可以通过转换分发到 Spring Cloud 应用的 SDK 上以及 Service Mesh 的 Sidecar 上。可以由 Config-server 负责规则下发，也可以由 Service Mesh 的控制面负责下发，取决于具体的架构方案。

服务限流

对于一个应用系统来说一定会有极限并发/请求数，即总有一个 TPS/QPS 阀值，如果超了阀值则系统就会不响应用户请求或响应的非常慢，因此我们最好进行过载保护，防止大量请求涌入击垮系统。限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务或进行流量整形。

常用的微服务限流架构包括：

接入层（api-gateway）限流：
- 单实例；
- 多实例：分布式限流算法；
调用外部限流服务限流：
- 微服务收到请求后，通过限流服务暴露的 RPC 接口查询是否超过阈值；
- 需单独部署限流服务；
切面层限流（SDK）：
- 限流功能集成在微服务系统切面层，与业务解耦；
- 可结合远程配置中心使用；

常用的限流策略包括：

拒绝策略：
- 超过阈值直接返回错误；
- 调用方可做熔断降级处理；
延迟处理：
- 前端设置一个流量缓冲池，将所有的请求全部缓冲进这个池子，不立即处理。然后后端真正的业务处理程序从这个池子中取出请求依次处理，常见的可以用队列模式来实现（MQ：削峰填谷）；
- 用异步的方式去减少了后端的处理压力；
特权处理：
- 这个模式需要将用户进行分类，通过预设的分类，让系统优先处理需要高保障的用户群体，其它用户群的请求就会延迟处理或者直接不处理；

常用的限流算法包括：

固定时间窗口限流：
- 首先需要选定一个时间起点，之后每次接口请求到来都累加计数器，如果在当前时间窗口内，根据限流规则（比如每秒钟最大允许 100 次接口请求），累加访问次数超过限流值，则限流熔断拒绝接口请求。当进入下一个时间窗口之后，计数器清零重新计数；
- 缺点在于：限流策略过于粗略，无法应对两个时间窗口临界时间内的突发流量。
滑动时间窗口算法：
- 流量经过滑动时间窗口算法整形之后，可以保证任意时间窗口内，都不会超过最大允许的限流值，从流量曲线上来看会更加平滑，可以部分解决上面提到的临界突发流量问题，是对固定时间窗口算法的一种改进；
- 缺点在于：需要记录在时间窗口内每个接口请求到达的时间点，对内存的占用会比较多。
令牌桶算法：
- 接口限制 t 秒内最大访问次数为 n，则每隔 t/n 秒会放一个 token 到桶中；
- 桶中最多可以存放 b 个 token，如果 token 到达时令牌桶已经满了，那么这个 token 会被丢弃；
- 接口请求会先从令牌桶中取 token，拿到 token 则处理接口请求，拿不到 token 就阻塞或者拒绝服务。
漏桶算法：
- 对于取令牌的频率也有限制，要按照 t/n 固定的速度来取令牌；
- 实现往往依赖于队列，请求到达如果队列未满则直接放入队列，然后有一个处理器按照固定频率从队列头取出请求进行处理。如果请求量大，则会导致队列满，那么新来的请求就会被抛弃；
- 令牌桶和漏桶算法的算法思想大体类似，漏桶算法作为令牌桶限流算法的改进版本；

令牌桶算法和漏桶算法，在某些场景下（内存消耗、应对突发流量），这两种算法会优于时间窗口算法成为首选。

熔断

断路器模式是微服务架构中广泛采用的模式之一，旨在将故障的影响降到最低，防止级联故障和雪崩，并确保端到端性能。我们将比较使用两种不同方法实现它的优缺点: Hystrix 和 Istio。

在电路领域中，断路器是为保护电路而设计的一种自动操作的电气开关。它的基本功能是在检测到故障后中断电流，然后可以重置(手动或自动)，以在故障解决后恢复正常操作。这看起来与我们的问题非常相似：为了保护应用程序不受过多请求的影响，最好在后端检测到重复出现的错误时立即中断前端和后端之间的通信。Michael Nygard 在他的《Release It》一书中使用了这个类比，并为应用于上述超时问题的设计模式提供了一个典型案例，可以用上图来总结。

Istio 通过 DestinationRule 实现断路器模式，或者更具体的路径 TrafficPolicy (原断路器) -> OutlierDetection，根据上图模型：

consecutiveErrors 断路器打开前的出错次数；
interval 断路器检查分析的时间间隔；
baseEjectionTime 最小的开放时间，该电路将保持一段时间等于最小弹射持续时间和电路已打开的次数的乘积；
maxEjectionPercent 可以弹出的上游服务的负载平衡池中主机的最大百分比，如果驱逐的主机数量超过阈值，则主机不会被驱逐；

与上述公称断路器相比，有两个主要偏差:

没有半开放的状态。然而，断路器持续打开的时间取决于被调用服务之前失败的次数，持续的故障服务将导致断路器的开路时间越来越长。
在基本模式中，只有一个被调用的应用程序(后端)。在更实际的生产环境中，负载均衡器后面可能部署同一个应用程序的多个实例。某些情况下有些实例可能会失败，而有些实例可能会工作。因为 Istio 也有负载均衡器的功能，能够追踪失败的实例，并把它们从负载均衡池中移除，在一定程度上: ‘maxEjectionPercent’ 属性的作用是保持一小部分的实例池。

Hystrix 提供了一个断路器实现，允许在电路打开时执行 fallback 机制。最关键的地方就在 HystrixCommand 的方法 run() 和 getFallback()：

run() 是要实际执行的代码 e.g. 从报价服务中获取价格；
getFallback() 获取当断路器打开时的 fallback 结果 e.g. 返回缓存的价格；

Spring Cloud 是建立在 Spring Boot 之上的框架，它提供了与 Spring 的良好集成。它让开发者在处理 Hystrix 命令对象的实例化时，只需注释所需的 fallback 方法。

实现断路器的方法有两种，一种是黑盒方式，另一种是白盒方式。Istio 作为一种代理管理工具，使用了黑盒方式，它实现起来很简单，不依赖于底层技术栈，而且可以在事后配置。另一方面，Hystrix 库使用白盒方式，它允许所有不同类型的 fallback:

单个默认值；
一个缓存；
调用其他服务；

它还提供了级联回退（cascading fallbacks）。这些额外的特性是有代价的：它需要在开发阶段就做出fallback 的决策。

这两种方法之间的最佳匹配可能会依靠自己的上下文: 在某些情况下，如引用的服务，一个白盒战略后备可能是一个更好的选择，而对于其他情况下快速失败可能是完全可以接受的，如一个集中的远程登录服务。

常用的熔断方法包括自动熔断与手动熔断。发生熔断时也可以选择 fail-fast 或者 fallback。这些用户都可以基于需求灵活使用。

智能路由

最后，我们来看一下智能路由带来的高可用。智能路由这里包括（客户端）负载均衡与实例容错策略。对于 Spring Cloud 框架来说，这部分能力由 Ribbon 来提供，Ribbon 支持随机、轮询、响应时间权重等负载均衡算法。而对于 Service Mesh 框架，这部分能力由 Envoy 提供，Envoy 支持随机、轮询（加权）、环哈希等算法。为了实现两套系统的规则统一对齐，可以采用其交集。

而容错策略包括：

failover：失败后自动切换其他服务器，支持配置重试次数；
failfast：失败立即报错，不再重试；
failresnd：将失败请求放入缓存队列、异步处理，搭配 failover 使用；

Istio 支持重试策略配置，而 fail-fast即对应与重试次数为0。

总结

微服务的高可用是一个复杂的问题，往往需要从多个角度去看，包括：

从手段看高可用。主要使用的技术手段是服务和数据的冗余备份和失效转移，一组服务或一组数据都能在多节点上，之间相互备份。当一台机器宕机或出现问题的时候，可以从当前的服务切换到其他可用的服务，不影响系统的可用性，也不会导致数据丢失。
从架构看高可用。保持简单的架构，目前多数网站采用的是比较经典的分层架构，应用层、服务层、数据层。应用层是处理一些业务逻辑，服务层提供一些数据和业务紧密相关服务，数据层负责对数据进行读写。简单的架构可以使应用层，服务层可以保持无状态化进行水平扩展，这个属于计算高可用。同时在做架构设计的时候，也应该考虑 CAP 理论。
从硬件看高可用。首先得确认硬件总是可能坏的，网络总是不稳定的。解决它的方法也是一个服务器不够就来多几个，一个机柜不够就来几个，一个机房不够就来几个。
从软件看高可用。软件的开发不严谨，发布不规范也是导致各种不可用出现，通过控制软件开发过程质量监控，通过测试，预发布，灰度发布等手段也是减少不可用的措施。
从治理看高可用。将服务规范化，事前做好服务分割，做好服务监控，预判不可用的出现，在不可用出现之前发现问题，解决问题。比如在服务上线后，根据经验，配置服务限流规则以及自动熔断规则。

以上就是本期分享的全部内容。

直播回放地址： www.bilibili.com/video/BV1WT… 分享 PPT 下载地址： github.com/servicemesh…

参考资料

公众号：金融级分布式架构（Antfin_SOFA）

霸榜世界第一的在线教育App，靠什么增长到3亿用户？ - 增长黑盒 - 增长黑客专用工具箱 - 增长黑客社区

Sun, 24 Feb 2019 08:22:16 CST

Alan@增长黑盒最近和国内不少知识付费公司都聊了一遍，发现国内的知识付费市场还是相当野蛮的。除了争相模仿和同质化的竞争，还有一个更核心的问题：

目前，绝大部分知识付费公司的核心指标是销售量和销售额，这就导致公司必然是 销售和营销导向型的。这也导致大家更注重对课程的包装，而不是质量，变相地使得 完课率和复购要画个问号。赚钱的秘密武器自然是 收割用户的焦虑，而这种行为也容易被人联想为割韭菜、收智商税。

只有少数公司将 完课率和课程效果作为核心指标，而这样做的问题在于服务和运营成本会变重，卖课的数量反倒不一定能多起来。最终导致认真打磨课程的公司可能卖不过那些营销做的好的公司，成功实现 劣币驱逐良币，最终使得知识付费行业的 市场变得混乱。

不过，目前来说头部公司还是那些用心做产品的，例如国内英语类的知识付费产品—— 薄荷阅读。他们就属于深耕英语教育行业，又专心 打磨用户体验和 产品内容的那种，所以自然也成了大家竞相模仿的对象。

知识付费到底还有什么玩法？我们不妨放眼全球，来看看国外教育类App下载排行榜榜首之作—— Duolingo （多邻国）。

这是一款 神奇的语言学习APP：没有卖过 付费广告，仅通过 游戏化的设计和 口碑传播，七年时间在全球做到3亿用户，2500万月活，并在去年估值超过7亿美金。多邻国的用户还包括很多大咖，例如比尔盖茨和扎克伯格。

如果只是这样也就一般神奇，更神奇的是： 这家公司的口号是学语言永远免费，不收用户一分钱 ！

于是，我决定和团队的小伙伴Rhino@增长黑盒深入研究一下这款APP，搞清楚两个问题：

1.“知识免费”靠什么商业模式赚钱？2.实现从0到3亿的增长，其核心策略是什么？

价值观和商业模式探索之路

2009年——从知识付费到知识免费

神奇的公司必然有神奇的创始人，多邻国创始人 Luis von Ahn是 卡内基梅隆大学计算机教授，曾经做过一个验证码公司reCAPTCHA后来卖给了Google。

reCAPTCHA这个系统，使得验证码不仅可以验证用户是否为真人，同时这些人填写的验证码还能帮助机器识别难以辨别的文字。最终，大家的众包劳动，会把一些老旧而经典的书籍给数字化，正所谓 一箭双雕。

卖掉公司后，Luis开始寻找新的市场，而他看中的是 外语学习的“知识付费”领域。

在2009年，美国市场上混的风生水起的外语学习软件是 Rosetta Stone。他们于2009年上市，公司年 营收超过2.09亿美元。

但Luis并不满意这样的模式，这里有 两个原因：

一方面，他意识到这样的商业模式 想象的空间小， 市场有限，一眼就 望得到头（毕竟之前一箭双雕，要求有点高）。
更重要的是，这样简单粗暴地卖语言学习课并不是他的目标，他想做更加 普惠的语言教育。这也是他的联合创始人 Severin Hacker（并且也是他的学生，名字里自带黑客）一直以来想要做的事情。

他们会这样想，也是源于 他们两个人自身的“痛点”：

Luis来自 危地马拉，位于加勒比海沿岸，他们那里有很多人想要去美国学习和工作。但是对于动辄上千美金的外语学习资料来讲，这实在是许多人一辈子也不可企及的梦想。而Severin来自瑞士，一个有 4种官方语言的国家，在他成长过程中有一段 很困难的语言学习期。

所以他们不想把自己圈在知识付费软件的条条框框里，而是决定通过“知识免费” 切入更广阔的增量市场。

可以说这是个 超越时代的想法。不过，从这些年的谷歌趋势可以看出来，多邻国确实是比Rosetta Stone 更具成长性。

2011年——宣布永远免费的外语学习产品

“We believe true equality is when spending more can’t buy you a better education.”

永远免费，成为了Luis在创办多邻国的时候立下了一个flag。竞争对手还在销售昂贵学习软件的 红海里拼得你死我活，Luis开始把脚步迈向了 “知识付费”的进阶版“知识免费”。

这大概和当年 360开始免费杀毒有异曲同工之妙，在付费软件你死我活的时候，免费就是最好的获客手段，然后再想办法开发出 “二级火箭”的商业模式来挣钱。

2009年Luis把reCAPTCHA卖了，正在寻找新的项目；而付费英语软件Rosetta Stone刚好在 同年上市， 生意如日中天。Luis留意到教育行业的火热，但又不认可这种昂贵付费学习软件的商业模式，就开始自己捣鼓产品。2011年，终于有了 多邻国Beta版本可用于测试，而 如何冷启动一个产品？还是 最小化可执行产品，这又是一个难点。

这里要给创业老手Luis点个赞，他深知PR的玩法，尤其是如何发布一款 全球性的、 免费的语言学习工具。对于这么有 前瞻性和话题性的产品， TED演讲是一个值得一试的渠道。

于是Luis以一个创业者的身份登上了TED演讲，上来先阐述了自己之前一箭双雕的reCAPTCHA项目。之后，他顺着reCAPTCHA的逻辑，讲了自己想要做的新项目，这个社区有可能成为 免费学习英语的网站。不仅如此，你在 学习一门外语的同时，还在 翻译全球的网页内容。

在那个线上软件和线下纸质书都很贵的时代， 免费学习加 全球协作 翻译这个概念引起了轰动的效果。

该视频当时在网络上就被观看100万次（七年后累计达到300万），这个零成本的 “冷启动”最终筛选到了 10万种子用户，并且有 多达50万人在排队（waiting list），效果可以说是完美。

2013年——模仿reCAPTCHA，开始众包翻译

既然承诺了用户“免费”，那就必然要想办法嵌套一个 二级火箭的商业模式来挣钱，有过reCAPTCHA众包经验的Luis早已准备尝试 “众包翻译“这个模式。

体验过多邻国的朋友应该比较容易理解，多邻国的基本学习逻辑就是 “母语和目标语言互译”，通过单词、句子和图片的翻译达到 练习和强化记忆的目的，从而掌握一门语言。

它一开始会让你 翻译一些简单的单词和句；到了 学习的高阶，它会将CNN（美国CCTV）上的新闻报道拆分成小章节交给用户翻译，通过 多个用户对同一素材的翻译得到 精准的翻译结果，再整合成一整篇卖给媒体。

这种 “众包”的模式不仅不会伤害到用户体验，反而让用户感知多邻国的语料素材丰富且拥有相当高的时效性。而多邻国自己，把翻译内容“众包”出去，降低了 翻译的人力成本，让价格有很大的竞争力。

一般的翻译公司给的价格是 6-10美分一个词，而多邻国可以 压到4美分，且由于 用户数量大，产量可以保证 平均每天600篇，这才让CNN和Buzzfeed（美国今日头条）都来和它合作。

于是，这个模式成功地跑了起来。

2014年初——开始做外语培训的认证

虽然翻译业务可以让公司有一定的营收，但整个公司并 没有停止探索新的商业模式。更重要的是，他们已经 暗自决定缩小翻译业务的规模了，具体原因后面会介绍。

那有什么新的盈利方向可以参考呢？大家可以想一下 传统教育行业是如何 为结果负责的。

那就是先不管你学没学到， 最终来一场考试，通过了就给你 发证书，而且证书认可范围越广越好。

一份独立的调查显示，多邻国的 英语测试结果跟 托福分数有很强的联系。此外，全球有 8亿人希望获得一个英语水平验证以有更好的工作机会，但是标准的英语能力测试，如托福、雅思对于普通人来讲太贵，并且还要负担去考试中心的差旅费。

独立调查报告链接：

https://s3.amazonaws.com/duolingo-certifications-data/CorrelationStudy.pdf

基于这些内部和外部的调研，多邻国上线了测试中心，只需要 托福考试的10%价格—— 20刀就能在家里考试（现在已经涨价到49刀了），通过了考试即获得英语学历证明。

可是，一个 App开出的认证资格，别人认吗?

不要忘了，Luis可是卡内基梅隆大学计算机教授，又是被Google收购过的创业者。 有愿景，有实力， 有过硬的产品和用户口碑。你没有看错，这个认证资格从一

开始就联合了大公司、高等学府和机构。

Uber、哈佛继续教育学院、哥伦比亚政府等纷纷站出来给它站台，测试既有 权威性，还顺便拓展了一下 “职场人士学外语”这个细分市场。

2015年初——砍掉众包翻译业务，拒绝销售导向

根据Techcrunch（世界最大的科技媒体之一）报道，多邻国在15年初又获得Google领投的 D轮融资，此时他们已经有 一亿用户了！

在这篇融资采访稿中，让大家没想到的是，Duolingo的发言人透露其实他们一年多以前就 已经没有再去扩大 翻译业务，只留下了CNN一家合作伙伴。

他们认为如果全力去做翻译业务，会需要更多的人员去把控翻译质量，并雇佣更多销售。这样的商业模式 有悖于 做普惠教育的初衷，且极有可能伤害 用户体验。

2015年——做B端的外语教学工具

所以，多邻国又开始探索 新的增长方式和 盈利模式。

在和企业、学校、机构打交道的过程中，Luis又看到了 和B端合作的巨大潜力。

当 D轮融资后多邻国把团队从30人扩大到了50人，终于可以腾出手来去开发一个呼声很高的功能 —— Duolingo教育版。

很多教育机构、企业、政府都曾经向多邻国提过需求，说希望 发布一个供机构使用的Duolingo版本，方便老师 统一管理学生的学习进度。

多邻国据此开发了一个新的版本 Duolingo for Schools，帮助老师建立错误答案看板以及学生学习进度表。

这本是个挣钱的机会，但是Luis最终还是坚持了 “免费教育”的初衷，最终决定对老师和学生端 完全免费。

这个尝试虽然没有给多邻国带来任何收入，但是给多邻国带来了别的收获—— 爆发式用户增长。因为 良好的体验、 免费的价格、 长期用户使用习惯的培养，多邻国一下子打入学生个人市场，在广大的学生群体中间流行起来。

同时也在企业用户中流行起来，类似Slack（国外企业版qq群）的增长方式 —— 与机构合作， 通过机构层面切进用户使用场景，培养用户习惯。

几个月后，教师端用户数 从0增长到10万；与此同时，在16年年初，多邻国的用户 规模突破1.5亿。

2017年——上线App内购和广告

经历过这么多商业模式的探索，多邻国一直在坚持自己的承诺—— 不向用户收费。

不仅如此，之前App内也没 有任何道具内购和广告。

只不过，在团队扩招后， 考试认证和翻译那点营收似乎不够看了。17年4月的一篇报道中(https://www.makeuseof.com/tag/duolingo-plus-easier-learn-new-language/)，CEO Luis说公司已经有 多达150人，每天需要花费约 4.2万美金，于是他们选择了App变现的一些常规方式：

免费版App中 加入了广告，用户可以选择观看获得 额外奖励
同时上线了 付费版（Duolingo Plus），每月9.99美金订阅可以 取消广告，并且可以 离线学习所有内容
加入了 游戏化道具的内购，生命值、宝石等等，可以帮助你 加快学习进度

App内的广告还是比较克制的，比如在课程结束后，会出现广告页面，有两个“按钮”可以选择：“观看加倍你的生命值”和“不看，谢谢”。

广告一般是一个20s的手游推广，右上角有倒计时告知你 广告进度，左下角还可以关掉声音。

虽然用户多少 会有些抱怨，但是绝大部分用户还是 表示可以接受的，他们的iOS App Store评分还是有4.7分之多。

那么，“知识免费”究竟 能赚多少钱呢？Luis在最近的采访透露，多邻国2018年的营收估计会达到3000万到4000万美元，公司有望在明年实现盈利，希望在最近2-3年内上市。

以留存为核心的增长策略

从12年上线到18年8月9号，多邻国用户突破了 3个亿，虽然营收没有做的那么漂亮，但是一直保持着 很高的用户增长效率，而且关键是 没有烧钱买量。那么，多邻国是如何用具体的技巧和策略来推动增长呢？

多邻国拥有 一支顶尖的增长团队，几乎所有内容都经历过AB测试并且在不断优化。

多邻国的 增长总监Gina Gotthilf曾在Growthhackers.com（世界最大的增长黑客社区）举行过一次问答活动 – 就连“增长黑客之父”肖恩·埃利斯都借机说明自己是多邻国的 “上瘾”用户，并向她请教：多邻国究竟是如何做增长的？

Gina坦言，他们的 增长策略就是：

将留存和完课率的重要性放在首位

采用游戏化的产品设计

数据驱动，用A/B测试等实验来增长各种指标

教育应该是以“结果”为导向，产品关心的指标应该是 “留存”、“完课率”或“复购”等一系列持续使用的行为，所以在多邻国的 增长策略里留存才是是核心。

但是，学习 是反人性的，让人长期 坚持并掌握一门语言，难度是 超乎想象的。全球都在研究的，也是被认为最有效的留存手段就是 Gamification（游戏化），多邻国的 增长团队甚至参考了消消乐和愤怒的小鸟这些 游戏的原素，让用户爱上学习，上瘾学习。

多邻国将 产品游戏化放到了仅次于 产品免费的战略地位上，甚至在官网清晰的展现了自己这种理念：

比如，众多游戏化设计中， 每日连续学习（Day Streak）是多邻国最重要的一个 用户留存的手段，围绕它有很多玩法。用户每天完成10分钟的打卡训练，获得升级条（Streak）作为凭证；升级条作为连续的系统，如果间断一天不练习，前面的升级条也会失效，而且还会失去“特别奖励”。

为了让用户坚持每日学习，团队 煞费苦心做出了这些 有趣的产品功能。但用户究竟买不买账？这些功能真的能提高用户留存吗？

在增长总监Gina的带领下，多邻国贯彻了 增长黑客最经典的策略： 高频实验– 针对产品的各个模块循环进行 “试错 – 分析 – 改进”，从而达到不断优化用户体验、推动留存提高的目的。

多邻国做实验的速度究竟有多快？在一次采访中，Gina表示，增长团队大 概每天会做5-8个增长实验。而在Gina的带动下，整个公司都产生了一种 热衷实验的习惯 – 在增长团队之外，其它部门也会主动去做各种实验，全公司加起来甚至能达到每天80次！

Gina坦言在多邻国，他们几乎 测试每个细节，只要能上线AB测试的，不多啰嗦，直接上线测试、观测结果、作出决策。

下面，我们就来看 三个提升留存的有效策略，以及它们背后的 实验细节：

1. 善用推送信息。用户万一真的一狠心“前功尽弃”，就真的不会再回来了。所以Gina的增长团队决定给 用户适当的提醒，让用户成功地回归。

比如他们在一个法语课程的推送文案中，他们做了一组 善恶分明的测试：

善良版：嗨！友情提示，亲爱的你应该练习法语了！

刻薄版：喂傻x，为什么不治好你的懒癌，去练习那该死的法语呢？

但是这两种推送效果都不理想，收到“善良版”的用户数量在一周后开始明显下降，而收到“刻薄版”的用户数量在一天后明显下滑。

所以团队想出了一个方法，就是把文风保持在“ 善良”和“刻薄”之间，于是就有了这条充满 “丧文化“的推送——

“反正给你发提醒也没用，再不来学我们就停止给你推送了。”

这招还是挺奏效的，用户数量维持了 三周才开始出现明显下滑，不少用户被这条“傲娇”的自残式推送吓到了，赶紧拿起手机学习。但这个 “被动积极”的方式毕竟用力过猛，像“狼来了”的故事讲多了就不吓人了，所以“有效”也“有毒”，基本上用过几次就没什么用了。

2. 周末保护盾牌。多邻国从数据洞察到一个有趣的现象，周一到周五大家都是精神饱满地学语言，但一到了周末， DAU平均下降9%，并且有一部分人在周末搁置任务之后永远地流失了。这时他们提出了一个 “周末保护盾牌”的实验想法。

用户可以并且只能在周五买到“盾牌”，盾牌可保护用户在 周末不上线的时候“每日连续学习”（day streaks）状态不会丢失。这个盾牌的效果就是它把7天的留存率提高了2.1%、14天提高了4%。

3. 徽章制度

徽章是 游戏化很常见的一环，团队自然也做了大量测试。

一开始，他们试图在用户注册的时候就送徽章，但这个数据结果 差得令人影响深刻，日活无变化，14天留存无变化，其它数据也都没有变化，于是团队就把这徽章设计这部分 搁置了一年。

但在这一年中他们参考了 大量其它打卡类app和游戏化设计，比如国外的大众点评“FourSquare”，感觉这个“徽章”项目还有的做，在一年之后的一次增长会议上，团队提出了 70多条优化建议，决定 再优化一次。

相比于上一次只测试一个徽章在一个场景的使用，这一次团队引入了 多个徽章，并且 分为不同等级，安排在 App不同场景测试。比如在这些不同场景可以获得徽章：

鼓励完成学习任务

邀请朋友

在App内体验更多产品功能和经验

但不同行为都有一个导向——让用户在app内留存久一点。

实验结果竟然与 原来有惊人的不同，徽章刚上线不久，日活上升了2.4%；用户开课率提高了4.1%；完课率提高了4.5%。另外，上线徽章还有预料之外的收获：

虚拟商城购买率增加了13%

加好友的行为增加了116%

他们复盘一年前的实验，发现当时 疏忽了以下几点：

使用场景不对，用户在刚进来注册好的时候发徽章没有成就感

徽章数量太少，徽章的背后是收集的逻辑，单个的徽章对留存作用不大

人们喜欢与朋友攀比徽章

看到这里，相信大家都会有个疑问：Gina提到的三个策略，都在强调 留存环节。那多年来， 新用户究竟是从哪来的呢？毕竟冷启动只有几十万用户，后期几乎也没有营销预算，为何会有源源不断的人来使用这个App？

为了弄清楚这个问题，我首先画出了多邻国的用户增长曲线：可以看出，它的病毒 系数k值约等于1，曲线平稳上升， 而不是几何级数式爆发。根据我的经验，这意味着多邻国一直保持着有效且长期的“裂变 ”，用户增长的驱动力来自留存的老用户持续带来新用户 – 不靠各种花哨的拉新活动，而是靠产品本身的自传播。这样一来，不仅获客成本极低，用户还非常精准，从而实现了正向循环。

因此，多邻国的 留存策略确实是 增长的基础。而 合理的自传播设计，却是另一个重要的增长要素。Gina并没有提到这点，所以我简单调查了一下，发现多邻国的自传播机制还是 归结于游戏化。

多邻国设计自传播的理论基础是：“轻量化”的小游戏可以帮助增强社区内“人与人-点对点”的联系，他们常常可以通过大社区的人际关系网络来加速小社区的成长。有人曾对多邻国的 facebook传播网络进行过 可视化分析，如下图所示，是很明显的 “由小到大”：

举个例子，在多邻国内玩小游戏，你不仅可以邀请现有的好友来玩，还可以从更大的通讯列表（比Facebook 通讯录）中邀请朋友，召唤玩伴。就像小游戏里常常鼓励分享，并邀请你的微信好友加入，即从 大的流量平台里导流。

除了小游戏，多邻国还把推荐内嵌到 其它功能里面，比如前文提到的 “徽章”。用户只要邀请 朋友加入多邻国，就可以获得徽章一枚，比起起早贪黑背单词，这种动动手指就能得奖的方式岂不更好？

用大社区带动小社区、呼朋引伴、分享趣味，其实跟我们现在的教育类产品付费是同样的逻辑。只在自己 封闭的生态中实现用户增长是不行的，要打通与 更大社区间的联系，从那里稳定引流。

正如我们上次做的增长实验复盘《微信裂变一定要刷屏才好吗》，增长不一定要刷屏才好， 把K值稳定在1左右，有助于触达到 更精准的用户、 注重服务和品牌口碑。

最后，我们可以总结：多邻国增长 策略的核心是 留存+自传播的强效配合，是K=1的“长期裂变”。同时又将游戏化的各种增长的技巧应用到这两个环节，以测试循环来不断优化。微小的改变能对用户增长带来强力的拉升作用，比如：

优化打卡文案使学习学习效果更明显，提高了1%的DAU；
推迟强制注册页面提高了20%的DAU；
优化推送文案使用户平均留存时间增加了3周；
上线徽章功能提高了2%的DAU，双周留存提高了2%，App内购收入增加了5%；
引入打卡对赌功能，14天日活提高了5%，App内购增加了600%！

我们增长黑盒做了一张图进行简单的总结：

多邻国的产品一直保持着 “小步快跑”的 迭代速度，在每一个微小的改变中 打磨产品，在 关键节点上 提高转化漏斗效率，才有了当前3亿规模的用户体量。

“知识免费”的启示

多邻国 从10万用户涨到2亿，7年估值7亿美金，坚持不收用户一分钱，旨在向全世界想学语言的人 提供免费的线上教育。在这种情况下，它一直在 优化用户体验、打磨产品，变现就是个 顺水人情。那么，对于国内的在线教育、知识付费来说，能够从多邻国身上得到什么启发？

1.价值驱动，以用户为中心

B2B的翻译业务既轻松，又有一定营收，多邻国 却放弃去扩大它，而是 回归到为用户创造价值。教育不能以销售为导向，而是要为用户提供 实实在在的服务，赚快钱的想法永远要放在 第二位。

我用一个大家比较熟悉的案例来类比一下：不久之前，罗振宇曾经谈到，自己曾想过给得到 App做一个付费会员制– 只要 一次性付一年的钱，就可以 全平台听课了！这一方面是部分用户的建议，另一方面，会员制非常赚钱 – 有罗振宇自身的背书，售价可以卖的很高。但是，罗胖最后 放弃了这个想法，他说：

以to B业务为导向，就必然会让公司重心 向销售倾斜，团队自然 不再有热情去打磨产品。而多邻国的愿景是为全世界提供免费的、高质量的语言教育，用户的体验才是真正的核心和驱动力。

2.长远来看，留存>获客

短期来看，很多 知识付费贩卖的是焦虑。这就导致，获客环节声势浩大，但完 课率和留存率十分惨淡。如果用户在后续学习过程中没有获得足够好的体验，这只能是 一锤子买卖– 再有新课，很可能他们就不会来购买了。

我们经常看到的 裂变分销，确实是有效的获客手段。但我们需要 深刻思考：自己是否有能力在下游承载这么多用户？课程质量是否经过了验证？售后服务是否能跟得上？

过度追求拉新规模、只看重裂变系数K，这是 “收智商税”的典型表现。 K值过高的 最大缺陷，就是带来 大量不精准用户，严重影响留存。一时冲动的消费，虽然能化解焦虑，却不能真正创造价值。我个人认为，真正健康的模式是通过 低频的拉新活动，吸引精准的目标用户，然后依靠超高的留存以及合理的分享机制，让产品实现自发传播，从而能在长期内将 K值稳定到1左右。“老带新”的前提是不论新老用户，都对产品价值产生了认可。

我观察发现，大家都很熟悉用户获取的指标监测，比如K值、裂变层级等等，但很容易忽略留存的关键指标： 用户满意度和NPS。各位回想一下，在课程结束后，普遍会给你一个二维码，让你加客服、加群，或者推荐其它课程，却并没有问你对课程是否满意，愿不愿意推荐给朋友等等。课后的调查问卷，还是非常有必要的 – 根据用户洞察，我们才能对产品做到心里有数。

3.从小处着手，逐渐积累优势

很多人十分看重 爆发式增长：课程一定要裂变出几万人才算成功。但很多时候，这是几乎是不可能的。我们必须从 细节入手，慢慢改进产品，才能真正让用户满意。 A/B测试和数据驱动，就是最强大的武器。

多邻国是 高度实验导向，数据驱动的。通过微小的改变，持续不断的优化，多邻国一点点地积累起 增长和留存。这些微小的改变可能在当下看来是个不 值一提的提升，但是每天提升的那百分之几，成就了他们7年增长2000倍。

“高频实验”的策略已经被硅谷众多增长团队验证过，不论是facebook这种巨头，还是airbnb这些独角兽，每天都用惊人的速度在做测试。

回归到知 识付费领域，除了产品本身，其实 最容易入手测试的地方就是 裂变海报。大家是否还记得今年鉴锋团队操盘的“网易微课”？看起来似乎是一夜之间就刷屏了，但实际上他们预先对4种不同的海报进行了测试，最后挑选了裂变层级最高，也就是传播潜力最大的那张（第一张）。

4.快速的商业转型

在硅谷流行的精益创业理论中，有个概念叫做 pivot（本意：中心点、支点、枢轴） – 这里是商业模式的转型。创业公司一定要拥有及时 “掉头”的能力。

做一个大胆的设想，如果当时多邻国一直 守着B2B业务的模式不放手，那结果会怎样？

他们可能会建立 企业级销售团队， 攫取用户价值来保证翻译数量？反正不可能打磨出现在这款有趣又有用的产品的。

在商业模式探索上兼具 灵活性和实验性，让他们能够在关键时刻不拘泥于自己的成就，做出重大的变革，推动公司向前。

一个好产品，有灵魂才能生长！

参考资料：

How Duolingo Built a $700 Million Company Without Charging Users

http://firstround.com/review/the-tenets-of-a-b-testing-from-duolingos-master-growth-hacker/

Gina Gotthilf on growing Duolingo to 200 million users

https://mashable.com/2017/11/23/ceo-duolingo-notifications/#oWgYuEaRPgq5

https://medium.com/@jensenloke/duolingo-a-user-retention-case-study-7ebabf6c8853

多邻国下一个阶段的商业模式是怎样的？我们拭目以待。有兴趣探讨的朋友可以加入我们知识星球，圈子还有增长黑客大佬坐镇、增长和营销的策略和思路分享、国内国外最新的案例研讨！每满500人，圈子会涨价100块，知识不等人，还是先扫为敬了。

另外，对文章参考资料有兴趣，或者对知识付费、在线教育行业的朋友也可以加我的个人号哦，聊增长，不失联～

如何应对在线故障

Thu, 22 Nov 2018 22:29:34 CST

线上运行的Java应用突然没有响应、响应缓慢，进程突然消失，遇到这些情况应该如何应对呢？

直白介绍卷积神经网络（CNN） - 文章 - 伯乐在线

Sat, 03 Nov 2018 17:43:07 CST

什么是卷积神经网络，它为何重要？

卷积神经网络（也称作 ConvNets或 CNN）是神经网络的一种，它在图像识别和分类等领域已被证明非常有效。卷积神经网络除了为机器人和自动驾驶汽车的视觉助力之外，还可以成功识别人脸，物体和交通标志。

图1

如图1所示，卷积神经网络能够识别图片的场景并且提供相关标题（“足球运动员正在踢足球”），图2则是利用卷积神经网络识别日常物品、人类和动物的例子。最近，卷积神经网络在一些自然语言处理任务（如语句分类）中也发挥了很大作用。

图2

因此，卷积神经网络是当今大多数机器学习实践者的重要工具。但是，理解卷积神经网络并开始尝试运用着实是一个痛苦的过程。本文的主要目的是了解卷积神经网络如何处理图像。

对于刚接触神经网络的人，我建议大家先阅读这篇关于多层感知机的简短教程，了解其工作原理之后再继续阅读本文。多层感知机即本文中的“完全连接层”。

LeNet 框架（20世纪90年代）

LeNet 是最早推动深度学习领域发展的卷积神经网络之一。这项由 Yann LeCun 完成的开创性工作自1988年以来多次成功迭代之后被命名为 LeNet5。当时 LeNet 框架主要用于字符识别任务，例如阅读邮政编码，数字等。

接下来，我们将直观地了解 LeNet 框架如何学习识别图像。近年来有人提出了几种基于 LeNet 改进的新框架，但是它们的基本思路与 LeNet 并无差别，如果您清楚地理解了 LeNet，那么对这些新的框架理解起来就相对容易很多。

图3: 一个简单的卷积神经网络

图 3中的卷积神经网络在结构上与原始的 LeNet 类似，并将输入图像分为四类：狗，猫，船或鸟（原始的 LeNet 主要用于字符识别任务）。从上图可以看出，接收船只图像作为输入时，神经网络在四个类别中正确地给船只分配了最高概率值（0.94）。输出层中所有概率的总和应该是1（之后会做解释）。

图 3 的卷积神经网络中有四个主要操作：

卷积
非线性变换（ReLU）
池化或子采样
分类（完全连接层）

这些操作是所有卷积神经网络的基本组成部分，因此了解它们的工作原理是理解卷积神经网络的重要步骤。下面我们将尝试直观地理解每个操作。

一张图片就是一个由像素值组成的矩阵

实质上，每张图片都可以表示为由像素值组成的矩阵。

图4: 每张图片就是一个像素矩阵

通道（channel）是一个传统术语，指图像的一个特定成分。标准数码相机拍摄的照片具有三个通道——红，绿和蓝——你可以将它们想象为三个堆叠在一起的二维矩阵（每种颜色一个），每个矩阵的像素值都在0到255之间。

而灰度图像只有一个通道。鉴于本文的科普目的，我们只考虑灰度图像，即一个代表图像的二维矩阵。矩阵中每个像素值的范围在0到255之间——0表示黑色，255表示白色。

卷积

卷积神经网络的名字来源于 “卷积”运算。在卷积神经网络中，卷积的主要目的是从输入图像中提取特征。通过使用输入数据中的小方块来学习图像特征，卷积保留了像素间的空间关系。我们在这里不会介绍卷积的数学推导，但会尝试理解它是如何处理图像的。

正如前文所说，每个图像可以被看做像素值矩阵。考虑一个像素值仅为0和1的5 × 5大小的图像（注意，对于灰度图像，像素值范围从0到255，下面的绿色矩阵是像素值仅为0和1的特殊情况）：

另外，考虑另一个 3×3 矩阵，如下图所示：

上述5 x 5图像和3 x 3矩阵的卷积计算过程如图 5中的动画所示：

图5：卷积操作。输出矩阵称作“卷积特征”或“特征映射”

我们来花点时间理解一下上述计算是如何完成的。将橙色矩阵在原始图像（绿色）上以每次1个像素的速率（也称为“步幅”）移动，对于每个位置，计算两个矩阵相对元素的乘积并相加，输出一个整数并作为最终输出矩阵（粉色）的一个元素。注意，3 × 3矩阵每个步幅仅能“看到”输入图像的一部分。

在卷积神经网路的术语中，这个3 × 3矩阵被称为“ 过滤器”或“核”或“特征探测器”，通过在图像上移动过滤器并计算点积得到的矩阵被称为“卷积特征”或“激活映射”或“ 特征映射”。重要的是要注意，过滤器的作用就是原始输入图像的特征检测器。

从上面的动画可以明显看出，对于同一张输入图像，不同的过滤器矩阵将会产生不同的特征映射。例如，考虑如下输入图像：

在下表中，我们可以看到上图在不同过滤器下卷积的效果。如图所示，只需在卷积运算前改变过滤器矩阵的数值就可以执行边缘检测，锐化和模糊等不同操作 [ 8] —— 这意味着不同的过滤器可以检测图像的不同特征，例如边缘，曲线等。更多此类示例可在这里8.2.4节中找到。

另一个理解卷积操作的好方法可以参考下面图 6中的动画：

图6: 卷积操作

一个过滤器（红色边框）在输入图像上移动（卷积操作）以生成特征映射。在同一张图像上，另一个过滤器（绿色边框）的卷积生成了不同的特征图，如图所示。需要注意到，卷积操作捕获原始图像中的局部依赖关系很重要。还要注意这两个不同的过滤器如何从同一张原始图像得到不同的特征图。请记住，以上图像和两个过滤器只是数值矩阵。

实际上，卷积神经网络在训练过程中会自己学习这些过滤器的值（尽管在训练过程之前我们仍需要指定诸如过滤器数目、大小，网络框架等参数）。我们拥有的过滤器数目越多，提取的图像特征就越多，我们的网络在识别新图像时效果就会越好。

特征映射（卷积特征）的大小由我们在执行卷积步骤之前需要决定的三个参数[ 4]控制：

深度：深度对应于我们用于卷积运算的过滤器数量。在图 7所示的网络中，我们使用三个不同的过滤器对初始的船图像进行卷积，从而生成三个不同的特征图。可以将这三个特征地图视为堆叠的二维矩阵，因此，特征映射的“深度”为3。

图7

步幅：步幅是我们在输入矩阵上移动一次过滤器矩阵的像素数量。当步幅为1时，我们一次将过滤器移动1个像素。当步幅为2时，过滤器每次移动2个像素。步幅越大，生成的特征映射越小。
零填充：有时，将输入矩阵边界用零来填充会很方便，这样我们可以将过滤器应用于输入图像矩阵的边界元素。零填充一个很好的特性是它允许我们控制特征映射的大小。添加零填充也称为 宽卷积，而不使用零填充是为 窄卷积。这在[ 14]中有清楚的解释。

非线性部分介绍（ReLU）

如上文图 3所示，每次卷积之后，都进行了另一项称为 ReLU 的操作。ReLU 全称为修正线性单元（Rectified Linear Units），是一种非线性操作。其输出如下图所示：

图8: ReLU 函数

ReLU 是一个针对元素的操作（应用于每个像素），并将特征映射中的所有负像素值替换为零。ReLU 的目的是在卷积神经网络中引入非线性因素，因为在实际生活中我们想要用神经网络学习的数据大多数都是非线性的（卷积是一个线性运算 —— 按元素进行矩阵乘法和加法，所以我们希望通过引入 ReLU 这样的非线性函数来解决非线性问题）。

从图 9可以很清楚地理解 ReLU 操作。它展示了将 ReLU 作用于图 6中某个特征映射得到的结果。这里的输出特征映射也被称为“修正”特征映射。

图9: ReLU 操作

其他非线性函数诸如 tanh或 sigmoid也可以用来代替 ReLU，但是在大多数情况下，ReLU 的表现更好。

池化

空间池化（也称为子采样或下采样）可降低每个特征映射的维度，并保留最重要的信息。空间池化有几种不同的方式：最大值，平均值，求和等。

在最大池化的情况下，我们定义一个空间邻域（例如，一个2 × 2窗口），并取修正特征映射在该窗口内最大的元素。当然我们也可以取该窗口内所有元素的平均值（平均池化）或所有元素的总和。在实际运用中，最大池化的表现更好。

图 10展示了通过2 × 2窗口在修正特征映射（卷积+ ReLU 操作后得到）上应用最大池化操作的示例。

图10: 最大池化

我们将2 x 2窗口移动2个单元格（也称为“步幅”），并取每个区域中的最大值。如图 10所示，这样就降低了特征映射的维度。

在图 11所示的网络中，池化操作分别应用于每个特征映射（因此，我们从三个输入映射中得到了三个输出映射）。

图11: 在修正特征映射上应用池化

图 12展示了我们对图 9中经过 ReLU 操作之后得到的修正特征映射应用池化之后的效果。

图12: 池化

池化的作用是逐步减少输入的空间大小[ 4]。具体来说有以下四点：

使输入（特征维度）更小，更易于管理
减少网络中的参数和运算次数，因此可以控制过拟合[ 4]
使网络对输入图像微小的变换、失真和平移更加稳健（输入图片小幅度的失真不会改池化的输出结果 —— 因为我们取了邻域的最大值/平均值）。
可以得到尺度几乎不变的图像（确切的术语是“等变”）。这是非常有用的，这样无论图片中的物体位于何处，我们都可以检测到，（详情参阅[ 18]和[ 19]）。

至此…

图13

目前为止，我们已经了解了卷积，ReLU 和池化的工作原理。这些是卷积神经网络的基本组成部分，理解这一点很重要。如图 13所示，我们有两个由卷积，ReLU 和 Pooling 组成的中间层 —— 第二个卷积层使用六个过滤器对第一层的输出执行卷积，生成六个特征映射。然后将 ReLU 分别应用于这六个特征映射。接着，我们对六个修正特征映射分别执行最大池化操作。

这两个中间层的作用都是从图像中提取有用的特征，在网络中引入非线性因素，同时对特征降维并使其在尺度和平移上等变[ 18]。

第二个池化层的输出即完全连接层的输入，我们将在下一节讨论。

完全连接层

完全连接层是一个传统的多层感知器，它在输出层使用 softmax 激活函数（也可以使用其他分类器，比如 SVM，但在本文只用到了 softmax）。“完全连接”这个术语意味着前一层中的每个神经元都连接到下一层的每个神经元。如果对多层感知器不甚了解，我建议您阅读这篇文章。

卷积层和池化层的输出代表了输入图像的高级特征。完全连接层的目的是利用这些基于训练数据集得到的特征，将输入图像分为不同的类。例如，我们要执行的图像分类任务有四个可能的输出，如图 14所示（请注意，图14没有展示出完全连接层中节点之间的连接）

图14: 完全连接层——每个节点都与相邻层的其他节点连接

除分类之外，添加完全连接层也是一个（通常来说）比较简单的学习这些特征非线性组合的方式。卷积层和池化层得到的大部分特征对分类的效果可能也不错，但这些特征的组合可能会更好[ 11]。

完全连接层的输出概率之和为1。这是因为我们在完全连接层的输出层使用了 softmax 激活函数。Softmax 函数取任意实数向量作为输入，并将其压缩到数值在0到1之间，总和为1的向量。

正式开始——使用反向传播进行训练

如上所述，卷积+池化层用来从输入图像提取特征，完全连接层用来做分类器。

注意，在图 15中，由于输入图像是船，对于船类目标概率为1，其他三个类为0

输入图像 = 船
目标向量 = [0, 0, 1, 0]

图15：训练卷积神经网络

卷积网络的整体训练过程概括如下：

步骤1：用随机值初始化所有过滤器和参数/权重
步骤2：神经网络将训练图像作为输入，经过前向传播步骤（卷积，ReLU 和池化操作以在完全连接层中的前向传播），得到每个类的输出概率。
假设上面船只图像的输出概率是 [0.2,0.4,0.1,0.3]
由于权重是随机分配给第一个训练样本，因此输出概率也是随机的。
步骤3：计算输出层的总误差（对所有4个类进行求和）
总误差 =∑ ½(目标概率 – 输出概率)²
步骤4：使用反向传播计算网络中所有权重的误差梯度，并使用 梯度下降更新所有过滤器值/权重和参数值，以最小化输出误差。
根据权重对总误差的贡献对其进行调整。
当再次输入相同的图像时，输出概率可能就变成了 [0.1,0.1,0.7,0.1]，这更接近目标向量 [0,0,1,0]。
这意味着网络已经 学会了如何通过调整其权重/过滤器并减少输出误差的方式对特定图像进行正确分类。
过滤器数量、大小，网络结构等参数在步骤1之前都已经固定，并且在训练过程中不会改变 —— 只会更新滤器矩阵和连接权值。
步骤5：对训练集中的所有图像重复步骤2-4。

通过以上步骤就可以训练出卷积神经网络 —— 这实际上意味着卷积神经网络中的所有权重和参数都已经过优化，可以对训练集中的图像进行正确分类。

当我们给卷积神经网络中输入一个新的（未见过的）图像时，网络会执行前向传播步骤并输出每个类的概率（对于新图像，计算输出概率所用的权重是之前优化过，并能够对训练集完全正确分类的）。如果我们的训练集足够大，神经网络会有很好的泛化能力（但愿如此）并将新图片分到正确的类里。

注1 ：为了给大家提供一个直观的训练过程，上述步骤已经简化了很多，并且忽略了数学推导过程。如果想要数学推导以及对卷积神经网络透彻的理解，请参阅 [ 4] 和 [ 12]。

注 2 ：上面的例子中，我们使用了两组交替的卷积和池化层。但请注意，这些操作可以在一个卷积神经网络中重复执行多次。实际上，现在效果最好的一些卷积神经网络都包含几十个卷积和池化层！另外，每个卷积层之后的池化层不是必需的。从下面的图 16中可以看出，在进行池化操作之前，我们可以连续进行多个卷积 + ReLU 操作。另外请注意图16卷积神经网络的每一层是如何展示的。

图16

卷积神经网络的可视化

一般来说，卷积步骤越多，神经网络能够学习识别的特征就更复杂。例如，在图像分类中，卷积神经网络在第一层可能会学习检测原始像素的边缘，然后在第二层利用这些边缘检测简单形状，然后在更高级的层用这些形状来检测高级特征，例如面部形状 [ 14]。图 17演示了这个过程 —— 这些特征是使用卷积深度信念网络学习的，这张图片只是为了演示思路（这只是一个例子：实际上卷积过滤器识别出来的对象可能对人来说并没有什么意义）。

图17: 卷积深度信念网络学习特征

Adam Harley 创建了一个基于 MNIST 手写数字数据集 [ 13]训练卷积神经网络的可视化。我强烈推荐大家使用它来了解卷积神经网络的工作细节。

我们在下图中可以看到神经网络对于输入数字“8”的具体操作细节。请注意，图 18中并未单独显示ReLU操作。

图18：基于手写数字训练卷积神经网络的可视化

输入图像包含 1024 个像素点（32 × 32 图像），第一个卷积层（卷积层1）由六个不同的5 × 5（步幅为1）过滤器与输入图像卷积而成。如图所示，使用六个不同的过滤器得到深度为六的特征映射。

卷积层1之后是池化层1，它在卷积层1中的六个特征映射上分别进行2 × 2最大池化（步幅为2）。将鼠标指针移动到池化层的任意像素上，可以观察到它来自于2 x 2网格在前一个卷积层中的作用（如图 19所示）。注意到2 x 2网格中具有最大值（最亮的那个）的像素点会被映射到池化层。

图19：池化操作可视化

池化层1之后是十六个执行卷积操作的5 × 5（步幅为1）卷积过滤器。然后是执行2 × 2最大池化（步幅为2）的池化层2。这两层的作用与上述相同。

然后有三个完全连接（FC）层：

第一个FC层中有120个神经元
第二个FC层中有100个神经元
第三个FC层中的10个神经元对应于10个数字 —— 也称为输出层

注意，在图 20中，输出层的10个节点每一个都连接到第二个完全连接层中的全部100个节点（因此称为完全连接）。

另外，注意为什么输出层中唯一明亮的节点是’8’ —— 这意味着神经网络对我们的手写数字进行了正确分类（节点亮度越高表示它的输出更高，即8在所有数字中具有最高的概率）。

图20：完全连接层可视化

该可视化系统的 3D 版本在此。

其他卷积神经网络框架

卷积神经网络始于20世纪90年代初。我们已经讨论了LeNet，它是最早的卷积神经网络之一。下面列出了其他一些有影响力的神经网络框架 [ 3] [ 4]。

LeNet (20 世纪90 年代) ：本文已详述。
20 世纪 90 年代到 2012 年：从20世纪90年代后期到2010年初，卷积神经网络正处于孵化期。随着越来越多的数据和计算能力的提升，卷积神经网络可以解决的任务变得越来越有趣。
AlexNet （2012 ）– 2012年，Alex Krizhevsky（和其他人）发布了 AlexNet，它是提升了深度和广度版本的 LeNet，并在2012年以巨大优势赢得了 ImageNet 大规模视觉识别挑战赛（ILSVRC）。这是基于之前方法的重大突破，目前 CNN 的广泛应用都要归功于 AlexNet。
ZF Net （2013 ）– 2013年 ILSVRC 获奖者来自 Matthew Zeiler 和 Rob Fergus 的卷积网络。它被称为 ZFNet（Zeiler 和 Fergus Net 的简称）。它在 AlexNet 的基础上通过调整网络框架超参数对其进行了改进。
GoogLeNet （ 2014 ）– 2014年 ILSVRC 获奖者是 Google 的 Szegedy 等人的卷积网络。其主要贡献是开发了一个初始模块，该模块大大减少了网络中的参数数量（4M，而 AlexNet 有60M）。
VGGNet （ 2014 ）– 2014年 ILSVRC 亚军是名为 VGGNet的网络。其主要贡献在于证明了网络深度（层数）是影响性能的关键因素。
ResNets （ 2015 ）– 何凯明（和其他人）开发的残差网络是2015年 ILSVRC 的冠军。ResNets 是迄今为止最先进的卷积神经网络模型，并且是大家在实践中使用卷积神经网络的默认选择（截至2016年5月）。
DenseNet （ 2016 年 8 月）– 最近由黄高等人发表，密集连接卷积网络的每一层都以前馈方式直接连接到其他层。 DenseNet 已经在五项竞争激烈的对象识别基准测试任务中证明自己比之前最先进的框架有了显着的改进。具体实现请参考这个网址。

结论

本文中，我尝试着用一些简单的术语解释卷积神经网络背后的主要概念，同时简化/略过了几个细节部分，但我希望这篇文章能够让你直观地理解其工作原理。

本文最初是受 Denny Britz 《理解卷积神经网络在自然语言处理上的运用》这篇文章的启发（推荐阅读），文中的许多解释是基于这篇文章的。为了更深入地理解其中一些概念，我鼓励您阅读斯坦福大学卷积神经网络课程的笔记以及一下参考资料中提到的其他很棒的资源。如果您对上述概念的理解遇到任何问题/建议，请随时在下面留言。

文中所使用的所有图像和动画均属于其各自的作者，陈列如下。

参考

karpathy/neuraltalk2: Efficient Image Captioning code in Torch, Examples
Shaoqing Ren, et al, “Faster R-CNN: Towards Real-Time Object Detection with Region Proposal Networks”, 2015, arXiv:1506.01497
Neural Network Architectures, Eugenio Culurciello’s blog
CS231n Convolutional Neural Networks for Visual Recognition, Stanford
Clarifai/Technology
Machine Learning is Fun! Part 3: Deep Learning and Convolutional Neural Networks
Feature extraction using convolution, Stanford
Wikipedia article on Kernel (image processing)
Deep Learning Methods for Vision, CVPR 2012 Tutorial
Neural Networks by Rob Fergus, Machine Learning Summer School 2015
What do the fully connected layers do in CNNs?
Convolutional Neural Networks, Andrew Gibiansky
W. Harley, “An Interactive Node-Link Visualization of Convolutional Neural Networks,” in ISVC, pages 867-877, 2015 ( link). Demo
Understanding Convolutional Neural Networks for NLP
Backpropagation in Convolutional Neural Networks
A Beginner’s Guide To Understanding Convolutional Neural Networks
Vincent Dumoulin, et al, “A guide to convolution arithmetic for deep learning”, 2015, arXiv:1603.07285
What is the difference between deep learning and usual machine learning?
How is a convolutional neural network able to learn invariant features?
A Taxonomy of Deep Convolutional Neural Nets for Computer Vision
Honglak Lee, et al, “Convolutional Deep Belief Networks for Scalable Unsupervised Learning of Hierarchical Representations” ( link)

基于 TensorFlow Serving 的深度学习在线预估

Sat, 13 Oct 2018 00:00:00 CST

一、前言

随着深度学习在图像、语言、广告点击率预估等各个领域不断发展，很多团队开始探索深度学习技术在业务层面的实践与应用。而在广告CTR预估方面，新模型也是层出不穷： Wide and Deep[1]、DeepCross Network[2]、DeepFM[3]、xDeepFM[4]，美团很多篇深度学习博客也做了详细的介绍。但是，当离线模型需要上线时，就会遇见各种新的问题：离线模型性能能否满足线上要求、模型预估如何镶入到原有工程系统等等。只有准确的理解深度学习框架，才能更好地将深度学习部署到线上，从而兼容原工程系统、满足线上性能要求。

本文首先介绍下美团平台用户增长组业务场景及离线训练流程，然后主要介绍我们使用TensorFlow Serving部署WDL模型到线上的全过程，以及如何优化线上服务性能，希望能对大家有所启发。

二、业务场景及离线流程

2.1 业务场景

在广告精排的场景下，针对每个用户，最多会有几百个广告召回，模型会根据用户特征与每一个广告相关特征，分别预估该用户对每条广告的点击率，从而进行排序。由于广告交易平台（AdExchange）对于DSP的超时时间限制，我们的排序模块平均响应时间必须控制在10ms以内，同时美团DSP需要根据预估点击率参与实时竞价，因此对模型预估性能要求比较高。

2.2 离线训练

离线数据方面，我们使用Spark生成TensorFlow[5]原生态的数据格式tfrecord，加快数据读取。

模型方面，使用经典的Wide and Deep模型，特征包括用户维度特征、场景维度特征、商品维度特征。Wide 部分有 80多特征输入，Deep部分有60多特征输入，经过Embedding输入层大约有600维度，之后是3层256等宽全连接，模型参数一共有35万参数，对应导出模型文件大小约11M。

离线训练方面，使用TensorFlow同步 + Backup Workers[6]的分布式框架，解决异步更新延迟和同步更新性能慢的问题。

在分布式ps参数分配方面，使用GreedyLoadBalancing方式，根据预估参数大小分配参数，取代Round Robin取模分配的方法，可以使各个PS负载均衡。

计算设备方面，我们发现只使用CPU而不使用GPU，训练速度会更快，这主要是因为尽管GPU计算上性能可能会提升，但是却增加了CPU与GPU之间数据传输的开销，当模型计算并不太复杂时，使用CPU效果会更好些。

同时我们使用了Estimator高级API，将数据读取、分布式训练、模型验证、TensorFlow Serving模型导出进行封装。

使用Estimator的主要好处在于：

单机训练与分布式训练可以很简单的切换，而且在使用不同设备：CPU、GPU、TPU时，无需修改过多的代码。
Estimator的框架十分清晰，便于开发者之间的交流。
初学者还可以直接使用一些已经构建好的Estimator模型：DNN模型、XGBoost模型、线性模型等。

三、TensorFlow Serving及性能优化

3.1 TensorFlow Serving介绍

TensorFlow Serving是一个用于机器学习模型Serving的高性能开源库，它可以将训练好的机器学习模型部署到线上，使用gRPC作为接口接受外部调用。TensorFlow Serving支持模型热更新与自动模型版本管理，具有非常灵活的特点。

下图为TensorFlow Serving整个框架图。Client端会不断给Manager发送请求，Manager会根据版本管理策略管理模型更新，并将最新的模型计算结果返回给Client端。

图1. TensorFlow Serving架构，图片来源于TensorFlow Serving官方文档

美团内部由数据平台提供专门TensorFlow Serving通过YARN分布式地跑在集群上，其周期性地扫描HDFS路径来检查模型版本，并自动进行更新。当然，每一台本地机器都可以安装TensorFlow Serving进行试验。

在我们站外广告精排的场景下，每来一位用户时，线上请求端会把该用户和召回所得100个广告的所有信息，转化成模型输入格式，然后作为一个Batch发送给TensorFlow Serving，TensorFlow Serving接受请求后，经过计算得到CTR预估值，再返回给请求端。

部署TensorFlow Serving的第一版时，QPS大约200时，打包请求需要5ms，网络开销需要固定3ms左右，仅模型预估计算需要10ms，整个过程的TP50线大约18ms，性能完全达不到线上的要求。接下来详细介绍下我们性能优化的过程。

3.2 性能优化

3.2.1 请求端优化

线上请求端优化主要是对一百个广告进行并行处理，我们使用OpenMP多线程并行处理数据，将请求时间性能从5ms降低到2ms左右。

  #pragma omp parallel for    
for (int i = 0; i < request->ad_feat_size(); ++i) {   
    tensorflow::Example example;   
    data_processing();   
}

3.2.2 构建模型OPS优化

在没有进行优化之前，模型的输入是未进行处理的原格式数据，例如，渠道特征取值可能为：'渠道1'、'渠道2' 这样的string格式，然后在模型里面做One Hot处理。

最初模型使用了大量的高阶tf.feature_column对数据进行处理，转为One Hot和embedding格式。使用tf.feature_column的好处是，输入时不需要对原数据做任何处理，可以通过feature_column API在模型内部对特征做很多常用的处理，例如：tf.feature_column.bucketized_column可以做分桶，tf.feature_column.crossed_column可以对类别特征做特征交叉。但特征处理的压力就放在了模型里。

为了进一步分析使用feature_column的耗时，我们使用tf.profiler工具，对整个离线训练流程耗时做了分析。在Estimator框架下使用tf.profiler是非常方便的，只需加一行代码即可。

  with tf.contrib.tfprof.ProfileContext(job_dir + ‘/tmp/train_dir’) as pctx:   
   estimator = tf.estimator.Estimator(model_fn=get_model_fn(job_dir),   
                                      config=run_config,   
                                      params=hparams)

下图为使用tf.profiler，网络在向前传播的耗时分布图，可以看出使用feature_column API的特征处理耗费了很大时间。

图2. 优化前profiler记录，前向传播的耗时占总训练时间55.78%，主要耗费在feature_column OPS对原始数据的预处理

为了解决特征在模型内做处理耗时大的问题，我们在处理离线数据时，把所有string格式的原生数据，提前做好One Hot的映射，并且把映射关系落到本地feature_index文件，进而供线上线下使用。这样就相当于把原本需要在模型端计算One Hot的过程省略掉，替代为使用词典做O(1)的查找。同时在构建模型时候，使用更多性能有保证的低阶API替代feature_column这样的高阶API。下图为性能优化后，前向传播耗时在整个训练流程的占比。可以看出，前向传播的耗时占比降低了很多。

图3. 优化后profiler记录，前向传播耗时占总训练时间39.53%

3.2.3 XLA，JIT编译优化

TensorFlow采用有向数据流图来表达整个计算过程，其中Node代表着操作（OPS），数据通过Tensor的方式来表达，不同Node间有向的边表示数据流动方向，整个图就是有向的数据流图。

XLA（Accelerated Linear Algebra）是一种专门对TensorFlow中线性代数运算进行优化的编译器，当打开JIT（Just In Time）编译模式时，便会使用XLA编译器。整个编译流程如下图所示：

图4. TensorFlow计算流程

首先TensorFlow整个计算图会经过优化，图中冗余的计算会被剪掉。HLO（High Level Optimizer）会将优化后的计算图生成HLO的原始操作，XLA编译器会对HLO的原始操作进行一些优化，最后交给LLVM IR，进而根据不同的后端设备，生成不同的机器代码。

JIT的使用，有助于LLVM IR根据 HLO原始操作生成更高效的机器码；同时，对于多个可融合的HLO原始操作，会融合成一个更加高效的计算操作。但是JIT的编译是在代码运行时进行编译，这也意味着运行代码时会有一部分额外的编译开销。

图5. 网络结构、Batch Size对JIT性能影响[7]

上图显示为不同网络结构，不同Batch Size下使用JIT编译后与不使用JIT编译的耗时之比。可以看出，较大的Batch Size性能优化比较明显，层数与神经元个数变化对JIT编译优化影响不大。

在实际的应用中，具体效果会因网络结构、模型参数、硬件设备等原因而异。

3.2.4 最终性能

经过上述一系列的性能优化，模型预估时间从开始的10ms降低到1.1ms，请求时间从5ms降到2ms。整个流程从打包发送请求到收到结果，耗时大约6ms。

图6. 模型计算时间相关参数：QPS:1308，50line:1.1ms，999line:3.0ms。下面四个图分别为：耗时分布图显示大部分耗时控制在1ms内；请求次数显示每分钟请求大约8万次，折合QPS为1308；平均耗时时间为1.1ms；成功率为100%

3.3 模型切换毛刺问题

通过监控发现，当模型进行更新时，会有大量的请求超时。如下图所示，每次更新都会导致有大量请求超时，对系统的影响较大。通过TensorFlow Serving日志和代码分析发现，超时问题主要源于两个方面，一方面，更新、加载模型和处理TensorFlow Serving请求的线程共用一个线程池，导致切换模型时无法处理请求；另一方面，模型加载后，计算图采用Lazy Initialization方式，导致第一次请求需要等待计算图初始化。

图7. 模型切换导致请求超时

问题一主要是因为加载和卸载模型线程池配置问题，在源代码中：

uint32 num_load_threads = 0; uint32 num_unload_threads = 0;

这两个参数默认为 0，表示不使用独立线程池，和Serving Manager在同一个线程中运行。修改成1便可以有效解决此问题。

模型加载的核心操作为RestoreOp，包括从存储读取模型文件、分配内存、查找对应的Variable等操作，其通过调用Session的run方法来执行。而默认情况下，一个进程内所有Session的运算均使用同一个线程池。所以导致模型加载过程中加载操作和处理Serving请求的运算使用同一线程池，导致Serving请求延迟。解决方法是通过配置文件设置，可构造多个线程池，模型加载时指定使用独立的线程池执行加载操作。

对于问题二，模型首次运行耗时较长的问题，采用在模型加载完成后提前进行一次Warm Up运算的方法，可以避免在请求时运算影响请求性能。这里使用Warm Up的方法是，根据导出模型时设置的Signature，拿出输入数据的类型，然后构造出假的输入数据来初始化模型。

通过上述两方面的优化，模型切换后请求延迟问题得到很好的解决。如下图所示，切换模型时毛刺由原来的84ms降低为4ms左右。

图8. 优化后模型切换后，毛刺降低

四、总结与展望

本文主要介绍了用户增长组基于Tensorflow Serving在深度学习线上预估的探索，对性能问题的定位、分析、解决；最终实现了高性能、稳定性强、支持各种深度学习模型的在线服务。

在具备完整的离线训练与在线预估框架基础之后，我们将会加快策略的快速迭代。在模型方面，我们可以快速尝试新的模型，尝试将强化学习与竞价结合；在性能方面，结合工程要求，我们会对TensorFlow的图优化、底层操作算子、操作融合等方面做进一步的探索；除此之外，TensorFlow Serving的预估功能可以用于模型分析，谷歌也基于此推出What-If-Tools来帮助模型开发者对模型深入分析。最后，我们也会结合模型分析，对数据、特征再做重新的审视。

参考文献

[1] Cheng, H. T., Koc, L., Harmsen, J., Shaked, T., Chandra, T., Aradhye, H., … & Anil, R. (2016, September). Wide & deep learning for recommender systems. In Proceedings of the 1st Workshop on Deep Learning for Recommender Systems (pp. 7-10). ACM.

[2] Wang, R., Fu, B., Fu, G., & Wang, M. (2017, August). Deep & cross network for ad click predictions. In Proceedings of the ADKDD'17 (p. 12). ACM.

[3] Guo, H., Tang, R., Ye, Y., Li, Z., & He, X. (2017). Deepfm: a factorization-machine based neural network for ctr prediction. arXiv preprint arXiv:1703.04247.

[4] Lian, J., Zhou, X., Zhang, F., Chen, Z., Xie, X., & Sun, G. (2018). xDeepFM: Combining Explicit and Implicit Feature Interactions for Recommender Systems. arXiv preprint arXiv:1803.05170.

[5] Abadi, M., Barham, P., Chen, J., Chen, Z., Davis, A., Dean, J., … & Kudlur, M. (2016, November). TensorFlow: a system for large-scale machine learning. In OSDI (Vol. 16, pp. 265-283).

[6] Goyal, P., Dollár, P., Girshick, R., Noordhuis, P., Wesolowski, L., Kyrola, A., … & He, K. (2017). Accurate, large minibatch SGD: training imagenet in 1 hour. arXiv preprint arXiv:1706.02677.

[7] Neill, R., Drebes, A., Pop, A. (2018). Performance Analysis of Just-in-Time Compilation for Training TensorFlow Multi-Layer Perceptrons.

作者简介

仲达，2017年毕业于美国罗彻斯特大学数据科学专业，后在加州湾区Stentor Technology Company工作，2018年加入美团，主要负责用户增长组深度学习、强化学习落地业务场景工作。

鸿杰，2015年加入美团点评。美团平台与酒旅事业群用户增长组算法负责人，曾就职于阿里，主要致力于通过机器学习提升美团点评平台的活跃用户数，作为技术负责人，主导了美团DSP广告投放、站内拉新等项目的算法工作，有效提升营销效率，降低营销成本。

廷稳，2015年加入美团点评。在美团点评离线计算方向先后从事YARN资源调度及GPU计算平台建设工作。

欢迎加入 美团机器学习群，跟作者零距离交流。如需进群，请加美美同学的微信（微信号： MTDPtech01），回复： TF，美美会自动拉你进群。

基于TensorFlow Serving的深度学习在线预估

Thu, 11 Oct 2018 21:30:45 CST

一、前言

二、业务场景及离线流程

2.1 业务场景

在广告精排的场景下，针对每个用户，最多会有几百个广告召回，模型根据用户特征与每一个广告相关特征，分别预估该用户对每条广告的点击率，从而进行排序。由于广告交易平台（AdExchange）对于DSP的超时时间限制，我们的排序模块平均响应时间必须控制在10ms以内，同时美团DSP需要根据预估点击率参与实时竞价，因此对模型预估性能要求比较高。

2.2 离线训练

离线数据方面，我们使用Spark生成TensorFlow[5]原生态的数据格式tfrecord，加快数据读取。

模型方面，使用经典的Wide and Deep模型，特征包括用户维度特征、场景维度特征、商品维度特征。Wide 部分有 80多特征输入，Deep部分有60多特征输入，经过Embedding输入层大约有600维度，之后是3层256等宽全连接，模型参数一共有35万参数，对应导出模型文件大小大约11M。

离线训练方面，使用TensorFlow同步 + Backup Workers[6]的分布式框架，解决异步更新延迟和同步更新性能慢的问题。

在分布式ps参数分配方面，使用GreedyLoadBalancing方式，根据预估参数大小分配参数，取代Round Robin取模分配的方法，可以使各个PS负载均衡。

同时我们使用了Estimator高级API，将数据读取、分布式训练、模型验证、TensorFlow Serving模型导出进行封装。
使用Estimator的主要好处在于：

单机训练与分布式训练可以很简单的切换，而且在使用不同设备：CPU、GPU、TPU时，无需修改过多的代码。
Estimator的框架十分清晰，便于开发者之间的交流。
初学者还可以直接使用一些已经构建好的Estimator模型：DNN模型、XGBoost模型、线性模型等。

三、TensorFlow Serving及性能优化

3.1 TensorFlow Serving介绍

下图为TensorFlow Serving整个框架图。Client端会不断给Manager发送请求，Manager会根据版本管理策略管理模型更新，并将最新的模型计算结果返回给Client端。

TensorFlow Serving架构，图片来源于TensorFlow Serving官方文档

3.2 性能优化

3.2.1 请求端优化

线上请求端优化主要是对一百个广告进行并行处理，我们使用OpenMP多线程并行处理数据，将请求时间性能从5ms降低到2ms左右。

  #pragma omp parallel for 
for (int i = 0; i < request->ad_feat_size(); ++i) {
    tensorflow::Example example;
    data_processing();
}

3.2.2 构建模型OPS优化

  with tf.contrib.tfprof.ProfileContext(job_dir + ‘/tmp/train_dir’) as pctx:
   estimator = tf.estimator.Estimator(model_fn=get_model_fn(job_dir),
                                      config=run_config,
                                      params=hparams)

下图为使用tf.profiler，网络在向前传播的耗时分布图，可以看出使用feature_column API的特征处理耗费了很大时间。

优化前profiler记录，前向传播的耗时占总训练时间55.78%，主要耗费在feature_column OPS对原始数据的预处理

优化后profiler记录，前向传播耗时占总训练时间39.53%

3.2.3 XLA，JIT编译优化

TensorFlow计算流程

首先TensorFlow整个计算图会经过优化，图中冗余的计算会被剪掉。HLO（High Level Optimizer）会将优化后的计算图生成HLO的原始操作，XLA编译器会对HLO的原始操作进行一些优化，最后交给LLVM IR根据不同的后端设备，生成不同的机器代码。

网络结构、Batch Size对JIT性能影响[7]

在实际的应用中，具体效果会因网络结构、模型参数、硬件设备等原因而异。

3.2.4 最终性能

经过上述一系列的性能优化，模型预估时间从开始的10ms降低到1.1ms，请求时间从5ms降到2ms。整个流程从打包发送请求到收到结果，耗时大约6ms。

模型计算时间相关参数：QPS:1308，50line:1.1ms，999line:3.0ms。下面四个图分别为：耗时分布图显示大部分耗时控制在1ms内；请求次数显示每分钟请求大约8万次，折合QPS为1308；平均耗时时间为1.1ms；成功率为100%

3.3 模型切换毛刺问题

通过监控发现，当模型进行更新时，会有大量的请求超时。如下图所示，每次更新都会导致有大量请求超时，对系统的影响较大。通过TensorFlow Serving日志和代码分析发现，超时问题主要源于两个方面，一方面，更新、加载模型和处理TensorFlow Serving请求的线程共用一个线程池，导致切换模型时候无法处理请求；另一方面，模型加载后，计算图采用Lazy Initialization方式，导致第一次请求需要等待计算图初始化。

模型切换导致请求超时

问题一主要是因为加载和卸载模型线程池配置问题，在源代码中：

uint32 num_load_threads = 0; uint32 num_unload_threads = 0;

这两个参数默认为 0，表示不使用独立线程池，和Serving Manager在同一个线程中运行。修改成1便可以有效解决此问题。

模型加载的核心操作为RestoreOp，包括从存储读取模型文件、分配内存、查找对应的Variable等操作，其通过调用Session的run方法来执行。而默认情况下，一个进程内的所有Session的运算均使用同一个线程池。所以导致模型加载过程中加载操作和处理Serving请求的运算使用同一线程池，导致Serving请求延迟。解决方法是通过配置文件设置，可构造多个线程池，模型加载时指定使用独立的线程池执行加载操作。

通过上述两方面的优化，模型切换后请求延迟问题得到很好的解决。如下图所示，切换模型时毛刺由原来的84ms降低为4ms左右。

优化后模型切换后，毛刺降低

四、总结与展望

参考文献

[1] Cheng, H. T., Koc, L., Harmsen, J., Shaked, T., Chandra, T., Aradhye, H., ... & Anil, R. (2016, September). Wide & deep learning for recommender systems. In Proceedings of the 1st Workshop on Deep Learning for Recommender Systems (pp. 7-10). ACM.
[2] Wang, R., Fu, B., Fu, G., & Wang, M. (2017, August). Deep & cross network for ad click predictions. In Proceedings of the ADKDD'17 (p. 12). ACM.
[3] Guo, H., Tang, R., Ye, Y., Li, Z., & He, X. (2017). Deepfm: a factorization-machine based neural network for ctr prediction. arXiv preprint arXiv:1703.04247.
[4] Lian, J., Zhou, X., Zhang, F., Chen, Z., Xie, X., & Sun, G. (2018). xDeepFM: Combining Explicit and Implicit Feature Interactions for Recommender Systems. arXiv preprint arXiv:1803.05170.
[5] Abadi, M., Barham, P., Chen, J., Chen, Z., Davis, A., Dean, J., ... & Kudlur, M. (2016, November). TensorFlow: a system for large-scale machine learning. In OSDI (Vol. 16, pp. 265-283).
[6] Goyal, P., Dollár, P., Girshick, R., Noordhuis, P., Wesolowski, L., Kyrola, A., ... & He, K. (2017). Accurate, large minibatch SGD: training imagenet in 1 hour. arXiv preprint arXiv:1706.02677.
[7] Neill, R., Drebes, A., Pop, A. (2018). Performance Analysis of Just-in-Time Compilation for Training TensorFlow Multi-Layer Perceptrons.

作者简介

廷稳，2015年加入美团点评。在美团点评离线计算方向先后从事YARN资源调度及GPU计算平台建设工作。

招聘

美团DSP是美团在线数字营销的核心业务方向，加入我们，你可以亲身参与打造和优化一个可触达亿级用户的营销平台，并引导他们的生活娱乐决策。同时，你也会直面如何精准，高效，低成本营销的挑战，也有机会接触到计算广告领域前沿的AI算法体系和大数据解决方案。你会和美团营销技术团队一起推动建立流量运营生态，支持酒旅、外卖、到店、打车、金融等业务继续快速的发展。我们诚邀有激情、有想法、有经验、有能力的你，和我们一起并肩奋斗！参与美团点评站外广告投放体系的实现，基于大规模用户行为数据，优化在线广告算法，提升DAU，ROI, 提高在线广告的相关度、投放效果。欢迎邮件wuhongjie#meituan.com咨询。

各大公司广泛使用的在线学习算法FTRL详解 - EE_NovRain - 博客园

Thu, 30 Aug 2018 15:22:15 CST

转载请注明本文链接：http://www.cnblogs.com/EE-NovRain/p/3810737.html

　　现在做在线学习和CTR常常会用到逻辑回归（ Logistic Regression），而传统的批量（batch）算法无法有效地处理超大规模的数据集和在线数据流，google先后三年时间（2010年-2013年）从理论研究到实际工程化实现的 FTRL（Follow-the-regularized-Leader）算法，在处理诸如逻辑回归之类的带非光滑正则化项（例如1范数，做模型复杂度控制和稀疏化）的凸优化问题上性能非常出色，据闻国内各大互联网公司都第一时间应用到了实际产品中，我们的系统也使用了该算法。这里对FTRL相关发展背景和工程实现的一些指导点做一些介绍，凸优化的理论细节不做详细介绍，感兴趣可以去查阅相应paper，相关paper列表会在文后附上。机器学习并非本人在校时的专业方向，不过在校期间积累的基础不算太差，而且很多东西也是相通的，钻研一下基本意思都还能搞明白。当然，有不准确的地方欢迎大家讨论指正。

本文主要会分三个部分介绍，如果对理论产生背景不感兴趣的话，可以直接看第3部分的工程实现（这一部分google13年那篇工程化的paper介绍得很详细）：

相关背景：包括通用性的问题描述、批量算法、传统在线学习算法等
简单介绍与FTRL关系比较密切的Truncated Gradient、FOBOS以及RDA（Regularized Dual Averaging）等算法
FTRL理论公式以及工程实现（对前因后果和理论方面不感兴趣的可以直接看这一小节的工程实现部分）

一、相关背景

【问题描述】

对于loss函数+正则化的结构风险最小化的优化问题（逻辑回归也是这种形式）有两种等价的描述形式，以1范数为例，分别是：

　　a、无约束优化形式的soft regularization formulation：

b、带约束项的凸优化问题convex constraint formulation：

当合理地选择g时，二者是等价的。这里提这两种形式的问题描述，原因在于引出下面无约束优化和带约束优化问题的不同算法，对于不同的描述形式，会有一系列相关算法。

【批量（batch）算法】

批量算法中每次迭代对全体训练数据集进行计算（例如计算全局梯度），优点是精度和收敛还可以，缺点是无法有效处理大数据集（此时全局梯度计算代价太大），且没法应用于数据流做在线学习。这里分无约束优化形式和约束优化（与上面问题描述可以对应起来）两方面简单介绍一下一些传统批量算法。

a、无约束优化形式：1、全局梯度下降，很常用的算法，就不细说了，每一步求一个目标函数的全局梯度，用非增学习率进行迭代；2、牛顿法（切线近似）、LBFGS（割线拟牛顿，用之前迭代结果近似Hessian黑塞矩阵的逆矩阵，BFGS似乎是几个人名的首字母的简称）等方法。牛顿和拟牛顿等方法一般对于光滑的正则约束项（例如2范数）效果很好，据说是求解2范数约束的逻辑回归类问题最好的方法，应用也比较广，但是当目标函数带L1非光滑、带不可微点的约束项后，牛顿类方法比较无力，理论上需要做修改。感兴趣的可以去查查无约束优化的相关数值计算的书，我也没有更深入研究相关细节，这里不做重点关注。

b、不等式约束凸优化形式：1、传统的不等式约束优化算法内点法等；2、投影梯度下降（约束优化表示下），gt是subgradient，直观含义是每步迭代后，迭代结果可能位于约束集合之外，然后取该迭代结果在约束凸集合上的投影作为新的迭代结果（第二个公式中那个符号标识向X的投影）：

　　 【在线算法】

　　如上所述，批量算法有自身的局限性，而在线学习算法的特点是：每来一个训练样本，就用该样本产生的loss和梯度对模型迭代一次，一个一个数据地进行训练，因此可以处理大数据量训练和在线训练。常用的有在线梯度下降（OGD）和随机梯度下降（SGD）等，本质思想是对上面【问题描述】中的 未加和的单个数据的loss函数 L（w，zi)做梯度下降，因为每一步的方向并不是全局最优的，所以整体呈现出来的会是一个看似随机的下降路线。典型迭代公式如下：

这里使用混合正则化项：，例如可能是1范数与2范数强凸项的混合（后面会看到其实很多都是这种混合正则化的格式，而且是有一定直观含义的）。迭代公式中：gt是loss函数（单点的loss，未加和）的subgradient，与gt相加的那一项是混合正则化项中的第二项的梯度，投影集合C是约束空间（例如可能是1范数的约束空间），跟上面介绍的投影梯度下降类似的做法。

　　梯度下降类的方法的优点是精度确实不错，但是不足相关paper主要提到两点：

　　1、简单的在线梯度下降很难产生真正稀疏的解，稀疏性在机器学习中是很看重的事情，尤其我们做工程应用，稀疏的特征会大大减少predict时的内存和复杂度。这一点其实很容易理解，说白了，即便加入L1范数（L1范数能引入稀疏解的简单示例可以产看PRML那本书的第二章，我前面一篇blog的ppt里也大概提了），因为是浮点运算，训练出的w向量也很难出现绝对的零。到这里，大家可能会想说，那还不容易，当计算出的w对应维度的值很小时，我们就强制置为零不就稀疏了么。对的，其实不少人就是这么做的，后面的Truncated Gradient和FOBOS都是类似思想的应用；

　　2、对于不可微点的迭代会存在一些问题，具体有什么问题，有一篇paper是这么说的：the iterates of the subgradient method are very rarely at the points of non-differentiability。我前后看了半天也没看明白，有熟悉的同学可以指导一下。

二、Truncated Gradient、FOBOS以及RDA（Regularized Dual Averaging）

　　上面提到了，稀疏性在机器学习中是很重要的一件事情，下面给出常见的三种做稀疏解的途径：

　　1）、简单加入L1范数

　　　　–局限如上面所提，a+b两个float数很难绝对等于零，无法产生真正稀疏的特征权重

　　 2）、在1范数的基础上做截断，最直观没技术含量的思路，那就设定一个阈值，做截断来保证稀疏，可以结合L1范数

　　　　–简单截断方法，每online训练K个数据截断一次，对OGD的迭代结果，每K步做一次截断置零：

　　　　但是简单截断方法有问题：权重小，可能是确实是无用特征，还或者可能是该特征才刚被更新一次（例如训练刚开始的阶段、或者训练数据中包含该特征的样本数本来就很少），另外，简单rounding技术太aggressive了，可能会破坏在线训练算法的理论完备性。

　　　　-简单截断基础上，不太aggressive的Truncated gradient （09年的工作），其实后面的FOBOS也可以归为这一类：

　　3）、Black-box wrapper approaches：

　　　　–黑盒的方法去除一些特征，然后重新训练的看被消去的特征是否有效。

　　　　–需要在数据集上对算法跑多次，所以不太实用

下面会提一下FOBOS（Forward-Backward Splitting method，其实应该叫FOBAS的，历史原因）以及RDA，因为后面的FTRL其实相当于综合了这两种算法的优点：

　　a、FOBOS，google和伯克利09年的工作：

　　　　–可以看作truncated gradient的一种特殊形式

　　　　–基本思想：跟projected subgradient方法类似，不过将每一个数据的迭代过程，分解成一个经验损失梯度下降迭代和一个最优化问题。分解出的第二个最优化问题，有两项：第一项2范数那一项表示不能离第一步loss损失迭代结果太远，第二项是正则化项，用来限定模型复杂度抑制过拟合和做稀疏化等。这个最优化问题有一些特殊的性质，从而保证了最终结果的稀疏性和理论上的完备，具体细节感兴趣的可以查看对应paper。我这里更多关注直观含义和工程实现，忽略理论方面的内容。

　　 b、RDA（Regularized dual averaging），微软10年的工作，更加理论性一些，这里就直接略过去了，仅对其特点做一个简单介绍：

　　　　–非梯度下降类方法，属于更加通用的一个primal-dual algorithmic schema的一个应用

　　　　–克服了SGD类方法所欠缺的exploiting problem structure，especially for problems with explicit regularization。

　　　　–能够更好地在精度和稀疏性之间做trade-off

　　ok，背景和一些铺垫终于完成了，下面重点进入FTRL的部分。。。

三、FTRL (Follow-the-regularized-Leader)

【发展历程】

　　FTRL的理论推进和工程应用首先要感谢这个人：H. Brendan McMahan, google这哥们儿护了三年的坑，直到13年工程性paper出来。发展历程和基本说明如下：

　　　 –10年理论性paper，但未显式地支持正则化项迭代；11年证明regret bound以及引入通用的正则化项；11年另一篇的paper揭示OGD、FOBOS、RDA等算法与FTRL关系；13年的paper给出了工程性实现，并且附带了详细的伪代码，开始被大规模应用。

　　　 –可以看作RDA和FOBOS的混合，但在L1范数或者其他非光滑的正则项下，FTRL比前两者更加有效

【基本思想及迭代公式】

　　我简单画了个图：

　　与其他在线算法的迭代公式的对比（其实OGD如何一步步到类似形式的迭代公式的过程，限于时间，这里就不细说了，最后我会附一篇自己做分享会时做的ppt，里面有，感兴趣的可以下载看看），不同的方法在这种统一的描述形式下，区别点仅在第二项和第三项的处理方式：

　　–第一项：梯度或累积梯度；

　　–第二项：L1正则化项的处理；

　　–第三项：这个累积加和限定了新的迭代结果x不要离已迭代过的解太远（也即FTRL-Proximal中proximal的含义），或者离0太远（central），这一项其实也是low regret的需求

【工程实现】

　　大家对上面那一大坨前因后果和公式都不感兴趣，ok，没关系，google非常贴心地在13年给出了一篇工程性很强的paper，其实大部分公司使用FTRL的，根本不会关心上面那一大段东西，直接按着伪代码写，调调参，看结果很不错就可以了。我们公司开始就是这么搞的，哈哈，不过人总是要有点儿好奇心的不是，深究一下前因后果和基本的理论公式感觉还是挺不同的。

　　逻辑回归下的per-coordinate FTRL_Proximal的伪代码如下，在公式表达的基础上做了一些变换和实现上的trick，细节paper里有，大家在自己做实现的时候，可以在实际数据集上再并行加加速：

　　四个参数的设定结合paper里的指导意见以及反复实验测试，找一组适合自己问题的参数就可以了。这里我想提一点，即上面所谓的 per-coordinate，其意思是 FTRL是对w每一维分开训练更新的，每一维使用的是不同的学习速率，也是上面代码中lamda2之前的那一项。与w所有特征维度使用统一的学习速率相比， 这种方法考虑了训练样本本身在不同特征上分布的不均匀性，如果包含w某一个维度特征的训练样本很少，每一个样本都很珍贵，那么该特征维度对应的训练速率可以独自保持比较大的值，每来一个包含该特征的样本，就可以在该样本的梯度上前进一大步，而不需要与其他特征维度的前进步调强行保持一致。

【工程实现中的memory saving策略】

　　这里对google所提的一些节省内存的实现细节做一个介绍

Predict时的memory saving：

　　　　–L1范数加策略，训练结果w很稀疏，在用w做predict的时候节省了内存，很直观，不细说了

Training时的memory saving：

在线丢弃训练数据中很少出现的特征(probabilistic feature inclusion)，但是对于online set，对全数据进行pre-process查看哪些特征出现地很少、或者哪些特征无用，是代价很大的事情，所以要想训练的时候就做稀疏化，就要想一些在线的方法（FTRL分开更新的w各维度，每一维不同的步长，per-coordinate）

　　　　1）Poisson Inclusion：对某一维度特征所来的训练样本，以p的概率接受并更新模型；

　　　　2）Bloom Filter Inclusion：用bloom filter从概率上做某一特征出现k次才更新

　　2. 浮点数重新编码

　　　　1)　　特征权重不需要用32bit或64bit的浮点数存储，存储浪费空间

　　　　2)　　16bit encoding，但是要注意处理rounding技术对regret带来的影响

　　3. 训练若干相似model

　　　　1）对同一份训练数据序列，同时训练多个相似的model

　　　　2）这些model有各自独享的一些feature，也有一些共享的feature

　　　　3）出发点：有的特征维度可以是各个模型独享的，而有的各个模型共享的特征，可以用同样的数据训练。

　　4. Single Value Structure（据说有公司已经在实际中这么搞，大数据量下也能够保证不错的auc）

　　　 1）多个model公用一个feature存储（例如放到cbase或redis中），各个model都更新这个共有的feature结构

　　　 2）对于某一个model，对于他所训练的特征向量的某一维，直接计算一个迭代结果并与旧值做一个平均

　　5. 使用正负样本的数目来计算梯度的和（所有的model具有同样的N和P）

　　6. Subsampling Training Data

　　　　1）在实际中，CTR远小于50%，所以正样本更加有价值。通过对训练数据集进行subsampling，可以大大减小训练数据集的大小

　　　　2）正样本全部采（至少有一个广告被点击的query数据），负样本使用一个比例r采样（完全没有广告被点击的query数据）。但是直接在这种采样上进行训练，会导致比较大的biased prediction

　　　　3）解决办法：训练的时候，对样本再乘一个权重。权重直接乘到loss上面，从而梯度也会乘以这个权重。

　　　　　先采样减少负样本数目，在训练的时候再用权重弥补负样本，非常不错的想法。

【References】

我大概标注了一下各篇paper的主要内容，感兴趣的可以有选择性地看一下，如果只关注工程实现，看标红的那篇就ok了：

[1] J. Langford, L. Li, and T. Zhang. Sparse online learning via truncated gradient.JMLR, 10, 2009. （截断梯度的paper）

[2] H. B. McMahan. Follow-the-regularized-leader and mirror descent: Equivalence theorems and L1 regularization. In AISTATS, 2011 （FOBOS、RDA、FTRL等各种方法对比的paper）

[3] L. Xiao. Dual averaging method for regularized stochastic learning and online optimization. In NIPS, 2009 （RDA方法）

[4] J. Duchi and Y. Singer. Efficient learning using forward-backward splitting. In Advances in Neural Information Processing Systems 22, pages 495{503. 2009. （FOBOS方法）

[5] H. Brendan McMahan, Gary Holt, D. Sculley, Michael Young, Dietmar Ebner, Julian Grady, Lan Nie, Todd Phillips, Eugene Davydov, Daniel Golovin, Sharat Chikkerur, Dan Liu, Martin Wattenberg, Arnar Mar Hrafnkelsson, Tom Boulos, Jeremy Kubica, Ad Click Prediction: a View from the Trenches, Proceedings of the 19th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD) (2013) （这篇是那篇工程性的paper）

[6] H. Brendan McMahan. A unied analysis of regular-ized dual averaging and composite mirror descent with implicit updates. Submitted, 2011 （FTRL理论发展，regret bound和加入通用正则化项）

[7] H. Brendan McMahan and Matthew Streeter. Adap-tive bound optimization for online convex optimiza-tion. InCOLT, 2010 （开始的那篇理论性paper）

后面附上我在组里分享时做的ppt，感兴趣的可以看看： http://pan.baidu.com/s/1eQvfo6e

从先进走向普遍的广告和推荐系统方法之一: 在线学习 | AlgorithmDog

Sun, 15 Apr 2018 18:27:32 CST

文章目录

广告和推荐系统作为机器学习领域的“摇钱树”，一直受到广泛的关注。在这 5 年，或者说 10 年的维度上，广告和推荐系统发生了改头换面的变化。传统的方法已经远去，一时先进的新兴的方法广泛走向千家万户。今天介绍的在线学习，就已经从先进走向了千家万户。

广告和推荐系统的 CTR 预估模型有三种部署形态: 离线预测，在线预测和在线学习，其中在线学习是近几年迅速推广的架构。

1. 离线预测

离线预测的架构很简单，其要点离线计算好所有的可能的预测结果。具体过程如下所示：1）在线上，从用户和物品属性抽取用户和物品特征，将抽取的特征合并进日志生成训练数据，训练机器学习模型；将几乎所有可能的请求合并特征，进而生成预测实例，用模型得到预测结果；2）线上就很简单了，接入线下传过来的预测结果。这里稍微难理解的是 “穷尽几乎所有可能的请求”，疑惑那么多可能的请求怎么可能穷尽呢？微博广告系统（虚构的）所有可能的请求貌似很多，但每个用户只需要匹配若干个广告就行了。因此微博广告系统的预测结果 “userid,adid1,adid2…,adidn” 上载到线上，一旦线上传一个 userid 请求展示广告，线上模块就按照一定的逻辑返回预测结果中这个用户对应的广告。

离线预测架构最大的优势是简单，其将机器学习全过程和绝大部分控制逻辑都搬到线下，规避了线上的各种隐患。这样不那么厉害的工程师用不那么厉害的机器也能搞定线上模块了，毕竟线上模块只需要实现少量的控制逻辑和展示。这大大降低了建立一个广告和推荐系统的难度。

离线预测架构也有其劣势，其中两个突出问题是系统开销大和灵活性不够。系统开销大主要是预测时需要对所有可能用户物品对进行预测，消耗大量的系统资源。这逼得我们发展出一系列的预测优化技巧，我之前的工作: 超大规模 LR 预测优化便是优化了 LR 的预测性能，使之 10 分钟处理完 380 亿量级的预测实例，应该能够处理万亿级预测数据。腾讯同学可以关注下 km 中 wxg 同学的文章：万亿级实例打分预测，优化了 XGBoost 的预测性能，使之能够处理万亿级预测数据。离线预测架构的另一个大问题就是灵活性不够，比如离线预测架构完全无法支撑用强化学习或者多臂老虎机解决冷启动问题。

为了解决这些问题，我们引入在线预测架构。很多大团队直接跳过了离线预测架。我 2010 年在百度实习见识的就是在线预测架构了。

2. 在线预测

在线预测的广告和推荐系统过程如下所示：1）线下部分，从用户和物品属性抽取用户和物品特征，把抽取的特征合并进日志生成训练数据用于训练机，并把抽取的特征上载到线上 Redis 服务器；2）线上部分，来了一个请求，从 Redis 服务器取出用户和物品特征，将特征合并进请求生成预测实例，用线上模型得到预测结果。

在线预测解决了离线预测的问题，系统变得更加灵活，也变得更加复杂了。随着数据量的增加，业务场景多样化，在线预测面临了两个突出问题。

第一个问题是系统性能。随着特征工程和深度学习的发展，机器学习要求和能够利用的数据量越来越多。这个时候线下训练需要的系统资源和时间越来越长。训练系统需要利用十亿级，甚至百亿级的训练数据，需要大规模分布式训练，很多时候需要一整天时间。

第二个问题是实时性。离线训练差不多要一天收集数据，训练差不多需要半天，上线的模型得到的是一天前的规律。另外还存在一个问题，我们生成训练数据是用日志 userid, itemid, is_click，拼接数据库中用户 (user) 和物品 (item) 的属性。我们使用的用户和物品的属性是一个时间切片的，而日志记录的浏览点击行为发生在不同时间。这些浏览点击行为发生时间的用户和物品属性，和数据库中的用户和物品属性不一致，生成的训练数据就有偏差。用户行为与用户状态紧密关联的情况下，比如刚刚买奶粉就不会再买奶粉，训练数据的偏差就会造成很大的问题。

3. 在线学习

为了解决在线预测的系统性能和实时性，人们发展出了在线学习的框架。在线学习是在线预测的基础上更进一步，将模型的训练也搬到了线上。在线学习架构和在线预测架构基本相似，区别在于：业务系统根据广告和推荐系统预测做出相应动作，并得到用户反馈之后，将展示点击记录给还给广告和推荐系统；广告和推荐系统根据业务系统的反馈，在线更新模型。

对于广告和推荐系统性能的影响。在线学习并不直接提升训练效率，也不减少训练样本数量。整体训练时间和资源效率并不会减少。但是在线学习改变了模型完全训练完才部署上线的模式，使得模型能够边训练边部署。这样对模型训练的耗时的要求就降下来了。

对于广告和推荐系统实时性的影响。这样模型训练能够使用最新训练样本，就能时刻保持最新状态。同时，由于用户和物品属性的迁移会近乎实时地更新到广告和推荐系统中，避免了训练数据中用户物品属性和用户行为直接的时间差。

上图就是在线学习简略框架图。从工程复杂度来说，离线预测最容易，在线预测次之，在线学习最难；从灵活性和效果性来说，离线预测最差，在线预测次之，在线学习最好。

4. 总结

在这 5 年，或者说 10 年的维度上，在线学习的广告和推荐系统就从先进走向了普遍。业内很多广告和推荐系统都进入了在线学习模式。这个发展速度是机器学习领域蓬勃发展的一个侧面，反映了整个人工智能技术的快速推进。

我们这些计算机同学需要一直适应，利用甚至推动技术的快速进步。因为跟不上，就落后了。这是我们的宿命，也是我们开心的来源吧。停留在 “技术往往体现在‘最恰当’几个字上面” 的同学们还是自勉吧。

最前线 | 比亚迪首次官方回应：电池业务独立上市正在酝酿之中

Thu, 29 Mar 2018 20:09:01 CST

文 | 高小倩张嫣

关于比亚迪将拆分旗下电池业务的消息由来已久，而在公司发布了2017年全年财报后这一事情似乎有了实质的进展。3月29日，《经济观察报》报道，其记者获悉：汽车生产厂商比亚迪欲将旗下的动力电池和光伏板块进行拆分并进一步推动上市。

对此，比亚迪官方回应36氪，并确认此事：比亚迪从去年开始做零部件产业的市场化，首先在公司内部实行市场化战略，按照市场机制定价，形成利润中心，按照利润为中心激励团队做好。同时， 推动各个零部件进行分拆上市的计划，现在酝酿之中。相信未来几年，公司会根据业务的情况和政策法规环境推出零部件产业的市场化。

此外，比亚迪表示：去年包括电池等零部件市场化后，在与很多厂家在洽谈，现在在商讨中，未来会达成一系列的合作。

这意味着，目前处在电池行业老二位置的比亚迪将在更开放的体系内，与该领域的独角兽宁德时代展开竞争，以开启下一个千亿市场。

打破零部件封闭体系，寻利润新增长点

3月27日，比亚迪发布了2017年的业绩报告。虽然收入微增，但利润正在下滑。

数据显示，公司实现1059.15亿元的收入，同比增长2.36%。归属于上市公司股东的净利润为40.66亿元，同比下降19.51%。导致这一结果的原因有二：新能源补贴的下降；以及公司燃油汽车的销量同比下降24.62%。

第一季度预计新能源汽车销量与去年同期相比实现了近200%增长，但受新能源汽车补贴退坡影响，该业务尤其是电动大巴部分盈利能力正在下滑。公司将2018年第一季度的净利润预期调整为下降75.24%——91.75%。

尽管补贴下降、利润下滑是所有企业都面临的，但针对利润下滑这一问题，近年来比亚迪已经开始做出调整。在过去很长一段时间，比亚迪的零部件体系一直比较封闭。但由于电动汽车行业垂直整合红利开始下降，“每一颗螺丝钉都要自己做”的时代已经过去。

于是，比亚迪通过裁撤、合并事业部、放弃非核心零部自行生产等方式，比亚迪对零部件体系进行整合，以使供应链体系逐渐开放。比如座椅方面，去年，比亚迪通过与佛吉亚成立合资公司，实现了相关业务的剥离。

相比而言，电池业务则是比亚迪的下一个盈利增长点。

依靠电池起家的比亚迪曾多年担任全球充电电池生产商老大，镍镉电池、手机锂电池出货量全球第一2017年该业务收入同比增长19.37%，占总收入的比重为8.28%。

其实早在2017年5月10日，比亚迪董秘办就曾表示，目前这件事（拆分）还在探讨阶段，没有正式确定。但一位长期关注比亚迪、位于深圳某证券公司的分析师透露，动力电池业务拆分方案已经获得比亚迪高层通过，只等下一步公告。

不甘居第二，欲与宁德时代厮杀

在2016年时，比亚迪董事长王传福还表示：“暂不对外供电池。”但变化太快。比如，比亚迪刚刚丢掉了中国国内锂动力电池企业出货量第一的位置。在前年，宁德时代出货量还位居第二，但在2017年，这家企业就快速增长，大幅甩开了比亚迪。

虽然比亚迪的电池业务早于宁德时代，但它的封闭体系反而让后者迅速占领市场。宁德时代已为宝马、北汽新能源、吉利汽车、长安汽车、东风汽车等车企提供电池，还与上汽成立了合资公司。

另外，宁德时代不仅成为了新能源汽车领域的独角兽，而且还打算登陆资本市场。公司于3月12日更新招股书。数据显示，公司2017年实现营业收入199.97亿元，同比增长逾34%；实现净利润39.72亿元，同比增长31.4%。从营收来看，要远超比亚迪电池业务的营收，后者为87.67亿元。

科技部公布的独角兽

所以，比亚迪拆分电池业务并独立上市，有与宁德时代展开竞争的意图，同时也可视为是公司补回缺失的战略机会，而规模化也是大幅摊薄成本、分摊风险的手段。

据称，比亚迪已经就动力电池领域与长城、北汽、广汽等各大汽车主机厂进行业务对接。对此，资本市场认为比亚迪动力电池业务看点十足，一旦比亚迪成功实现对于动力电池业务的拆分和上市，比亚迪将开启一个新的千亿市场的业务，而动力电池业务所带来的对于比亚迪估值的提升也将成为又一利好。

此前，中国化学与物理电源行业协会秘书长刘彦龙表示：“比亚迪动力电池业务开放会在市场具有一定的竞争力，但是和整车厂合作还需要一定过程，从认证到产品开发至少需要两三年时间。”

据36氪了解，目前比亚迪的电池在内部已经出于供不应求的状态，其青海工厂即将扩大电池产能，达到8GWh，缓解这一情况。因此未来对外销售的电池可能在这一工厂生产。

丁磊两会提案：促进中小学精品在线开放课程平台建设

Mon, 12 Mar 2018 15:27:17 CST

3月3日，全国政协十三届一次会议正式开幕。作为新当选的全国政协委员，网易公司董事局主席兼首席执行官丁磊履职首年向全国两会提交了多份提案，重点聚焦在两个话题：

一是推进信息的精品化建设，围绕教育、文化、网络内容改善等领域提出具体建议，包括建设中小学精品教育、在线开放课程、精品图书数字化、青少年健康上网等；二是关注民生问题的改革，围绕个税综合计征、慢性病防控、食品安全、“互联网+农业”精准扶贫、老年人便捷出行等。

其中，教育相关问题是丁磊最为重点关注的内容之一，在提案中被多次提及；而网易打造的有道精品课、网易公开课、网易云课堂等多款有口皆碑的在线教育产品，也成为了践行提案中“建设中小学精品教育、在线开放课程”的最好体现。

丁磊：互联网会解决传统教育所遇到的问题

之所以重点关注教育问题，是因为丁磊自己也遭遇过传统教育问题所带来的困扰。

“我大女儿读书时，为了学区房，我租了5年的房子住。”在一场小范围“两会”媒体沟通会上，丁磊提到了自己的经历。

丁磊还坦言，目前的现状是优质教育资源集中大城市，甚至是大城市的少数学校。而未来，应该依靠互联网、依靠科技的力量，可以让孩子不用学区房也能接受高质量教育、让三四线城市的孩子接受到一线城市的优质教育。

因此，针对国内中小学精品在线开放课程发展不平衡、不充分的问题，丁磊在《关于加快义务教育信息化改革，深化精品在线开放课程平台建设的提案》中提议：促进中小学精品在线开放课程平台建设，实现教育资源平台共享；重视STEAM教育资源在中小学精品在线开放课程平台的应用；继续加大对基础设施落后地区的支持；引导学校、教师观念升级，完善课程评价机制。

丁磊还强调：“现在的教育模式还很传统，应该有更多的互动和创新”，“因此应该在教育科技方面多研究、多投入，包括用游戏的方法去引导儿童教育，利用互联网开展线上精品教育课程手段等。”

在线教育蓬勃发展优化教育资源分配

实际上，教育问题是全社会关心的大事，是提升全民素质最为关键的路径。在今年的政府工作报告上，总理说：“发展公平而有质量的教育。”“教育公平”也连续四年成为政府工作报告中“教育主要任务”。

然而，我国由于区域经济发展不均、城市和农村教育资源分配不均等种种客观因素的影响，三四线及广大农村的孩子，依然不能享受到同等优质的教育。

但随着互联网及科技的发展，在线教育正如火如荼的发展，正如丁磊所说“从技术上来讲，让三四五线的孩子接受到大城市一流的教育已经可行。”

来自CNNIC的一份数据报告显示，在线教育课程成为中国国民手机APP 用户增长率第二，仅次于网上外卖，甚至高于游戏。

包括网易在内的不少互联网公司，都已经布局在线教育，大力发展网络课程，这让更多的三四线城市的孩子们，只要通过一部手机、一台电脑就可以快速、高效、便捷地享受到和一线大城市的孩子们同等优质的师资和课程。

而其中，以“匠心精神”著称的网易，打造出了有道精品课这样的优质在线教育产品，受到众多学生的追捧和喜爱。

网易匠心打造精品化网络课程

虽然今年是丁磊首次作为全国政协委员，并提出建设中小学精品教育、发展在线开放课程等内容的相关提案，但网易进入在线教育领域并不晚，尤其是在丁磊重点关注的青少年和中小学教育。

2014年有道精品课推出，为用户提供小学/初中/高中、四六级、考研、外语等精品课程。有道精品课的推出，正是今年丁磊在提案中 “促进中小学的精品在线开放课程平台的建设”的践行。

在线教育要做精品，不仅是“网易匠心”使然，更是行业和社会的极大需求。

目前，市面上做在线教育、提供网络内容的产品繁多，但同时也面临着鱼龙混杂、内容良莠不齐。尤其是在青少年和中小学领域，由于大部分未成年人对网络内容辨别能力有限、自控能力不高，因此，精品化的高质量课程就显得尤为重要。

以重点关注关注青少年和中小学在线教育的有道精品课为例，在2016年推出了的“同道计划”，目的是为了精选业内最顶尖的老师进行合作，从而保证课程的高质量。

例如，通过“同道计划“精选出来的高中老师，组成了“有道高中牛师团”，这是在高中学生群体中有相当号召力的一个团体，他们针对语文、数学、英语、物理等高中学科，认真研发有针对性、高品质的课程，每节课程都历时多个月的打磨，力求精品；老师们寓教于乐的教学方式，不仅能够带来学生们学习到课程重点，不少学生因此高考分数大幅提升，考上了理想的大学，还能帮助他们在网络上结交良师益友，树立正确的人生观、价值观。

实际上，除了“有道高中牛师团”外，秉承“精品”策略，有道精品课还孵化出了“有道四六级””有道考研““逻辑英语”等多个有口皆碑的教育产品，深受用户的喜欢。

而关于丁磊在提案中表示的“重视STEAM教育资源在中小学精品在线开放课程平台的应用”，有道精品课也早已做了不少探索。

例如，有道精品课专门开设“AI创客“等系列课程，能够帮助青少年快速学习编程、人工智能等领域的知识，从小培养良好的科学和技术基础，更好的适应未来科技社会。

据悉，有道精品课用户有超过六成来自三四线城市，初高中相关课程的比例甚至更高。通过技术手段，如有道精品课这样的在线教育产品，打破了传统教育资源分配不均的问题，让最优质的教育资源不受时间和地点的限制，最大范围的触及到更多的学生，尤其是三四线及广大农村，更好地助力我国教育事业的均衡发展。

为了弄清联通为何成立在线公司，我和业内人士细聊了这6个问题

Sun, 10 Dec 2017 18:09:00 CST

12月8号，联通在线信息科技有限公司成立，这是业内的一件大事。

一是联通面向消费互联网领域的专业化公司，二是联通全资平台控股公司，三是这个公司是在2006年注册成立的联通宽带在线公司主体上变更成立的。

关于此，我和资深科技媒体记者、移动员工、联通员工、投资人、互联网公司高管、专家六个圈内人士聊了下关于联通在线公司细节。他们对联通成立在线公司这件事的观点比较多样，但是也很有意思。

一、是不是浪费？

混改拿了BATJ的钱，又去搞BAT搞得消费互联网，这不是浪费吗？

—— 某资深科技媒体记者

这个观点思考的角度很有代表性：在消费互联网领域，BATJ（百度、阿里、腾讯、京东）加上TMD（头条、美团点评、滴滴）在国内基本上已经无人能够超越。

别说电信运营商，就是这些巨头们彼此之间要想在不是自己擅长的主航道布局，也往往是难以成功，比如电商基本是阿里和京东的天下，百度和腾讯已经放弃；社交是腾讯的地盘，其他人只能在细分领域偏安。

那么联通在线公司的185计划到底是要达成什么目标呢？

所谓185，就是1个APPs（移动互联网应用提供商）,8大能力（网络资源运营、内容与应用聚合、代计费、触点整合、通信创新、渠道推广、安全服务、精准营销），5大业务（视频、音乐、阅读、游戏、家庭互联网）。

所以这位科技媒体记者的疑问也可以理解。

不过在我看来，如果联通在线主要是帮助BATJ和TMD们分发APPs是不是就对了呢？

反正我觉得是。

二、向中国移动致敬？

这种中国联通向老大哥中国移动致敬，学习咪咕。

——中国联通友商中国移动的员工

某种意义上这个观点有可取之处，在消费互联网领域，中国移动早在2014年11月18日就正式成立了咪咕文化科技有限公司。

咪咕的定位是“面向移动互联网领域设立的，负责数字内容领域产品提供、运营、服务一体化的专业子公司，是中国移动旗下音乐、视频、阅读、游戏、动漫数字内容业务板块的唯一运营实体”。

联通在线与咪咕有两点不同：联通在线没有获得唯一的尚方宝剑；咪咕公司没有获得APP和应用商店以及家庭。

中国移动把家庭给了杭研，把APP和应用商店给了互联网公司。联通在线之所以把家庭互联网业务也收入囊中，主要原因是成立的前主体是联通宽带在线公司。

一位中国移动前员工的留言颇有亮点：咪咕每次去集团汇报工作都压力山大，因为领导老是拿BAT比，联通在线成立以后就轻松多了。

这么说来，联通在线是来解救咪咕的了。

相互解救才是正道吧？

三、不做好主业没资格做互联网？

联通有钱建议先把主业做好，确保生存再说其他的。

——一位联通员工

这位员工颇有恨铁不成钢的味道。

联通主业主要是指通信业务，包括移动业务、宽带业务。这两大业务，移动业务领域联通已经被电信超越，宽带业务领域已经被移动超越。

但是客观的说，联通这些年的确在很努力的做好主业，尤其是王晓初先生执掌联通之后，除了专注于混改，最主要的进步就是为联通主业寻找新的出路。

出路就是B2X2C，包括B2B2C和B2I2C，联通与互联网公司合作的各种王卡、王宽带为联通第三季度的突出表现的确作出了不可忽视的贡献。

但是在财务指标上，主业的表现的确进步空间还是很大。

这位同学的言下之意大概是担心新成立的联通在线公司无法创造收入，还成为吸血联通母体的负担。

从电信运营商目前的专业化和集中化运营现状来看，这个担心不无道理，目前脱离母体能够在市场的大海里独自存活的专业公司还没有。

四、没有投资价值吗？

我没看出来运营商的消费互联网业务有什么值得投资的。

——一位TMT领域的投资人

这句话实在是令很多人躺枪，这是一位直接的投资人。他想表达的是从联通在线目前的业务布局来看，都是消费互联网成熟的业务，而且是竞争非常激烈的业务，而且联通在线未来能否上市，让自己的投资退出变现都是问题，那么为什么要投资？

但是关于投资这件事情，我引用一位匿名的联通内部人士对某媒体说的话放在这里：“我们是第一家放出去做混合所有制的企业，先从联通体系剥离出去，做混改的试点，整个大网（联通集团）也在做试点，但进度会比较稳妥一些，我们放出去以后步子会走得更快，会引入BAT等互联网公司资本，进行资本层面的合作。”

这到底是什么意思呢？——联通在线否认了这位联通内部人士的话：“关于混改目前在集团层面，按照集团统一部署来做，从联通在线公司来讲，目前听从集团安排。”

不过运营商的消费互联网业务有上市融资的必要吗？

五、为啥三大运营商越干越相同？

为什么在消费互联网领域，运营商没有机会了却还在坚持不懈的进入，而且三大电信运营商越干越相同？

——一位互联网公司高管

他这个问题我觉得并不难以回答。

我告诉他，可以从三个方面来解释作为国企的电信运营商为何在看不到希望的领域坚持不懈的投入：

第一，国企的钱不是自己的，所以投资决策不受经济学理性人的假设影响；

第二，有钱的运营商没发把钱投到非TMT相关的地方，没钱的运营商有影子银行也不缺钱；

第三，这几年，所有电信运营商已经患上了互联网迷信症不能自拔，总想在这个领域证明自己也是行的，这是运营商找回自信的过程。

至于三大运营商为什么越干越相同？

因为在主业上三大运营商都是相同的，资源禀赋、组织结构和企业战略都是如出一辙，要是能越干越不同，那才是奇怪了。

六、跟美国运营商比还是小儿科？

美国运营商早就不把自己当运营商了，比中国运营商激进多了 。

——一位信通院的专家

言之也有理。

AT&T收购了时代华纳，买了Direct TV，Verizon收购ALO和雅虎，这手笔和跨界的幅度可不是中国的运营商能比的。

所以中国三大运营商在消费互联网领域成立个专业公司，实在算不上什么惊天动地的伟大事业。

美国运营商转型转的成立广告公司、媒体公司、影视公司、软件公司，那才是惊天地泣鬼神，步子幅度才叫一个大。

不过话说回来，联通在线公司能够解决运营商在互联网业务领域曾经面临的产品研发、经营管理、业务支撑、渠道销售，尤其是用户体验的问题吗？

很多人表示不乐观，也有很多人表示乐观。

乐观者把电信运营商的属地化经营模式看做是优势，不乐观者认为运营商无法在互联网业务领域建立与互联网业务匹配的激励机制、组织结构和运营模式。

都有道理，但是还是要看时间和执行力。

万幸的是，联通在线并不孤单，前面已经有了领跑的来自兄弟运营商的专业公司做示范。

如果不知道该怎么办的时候，照猫画虎也是可以的。 （本文首发钛媒体）

更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App

不拼爹不拼妈，哈佛教授教你如何让孩子赢在起跑线上

Wed, 22 Nov 2017 21:58:44 CST

▲凯瑟琳·斯诺教授在首届全国儿童早期阅读发展与教育峰会现场发言（活动主办方/图）

全文共 4625字，阅读大约需要 10分钟。

“对那些要求5、6岁的孩子懂得三门语言、两种乐器的焦虑的家长来说，更应该思考的是孩子成长到20、30岁时，是否还对学习保有兴趣、对世界怀有好奇、乐意以积极的态度尝试新东西。”
无字或者字比较少的书，确实需要家长学习比较具体的技巧，去发现故事到底怎么发展的。家长要具有引导孩子关注某些特定细节的能力，比如到故事关键处，向孩子提问核心的信息、去问孩子接下来会发生什么、去做一些预测和猜想。

文 | 南方周末记者卫佳铭

南方周末实习生曹婧淳

在中国深圳，1044个家庭平均月收入超过3万的中产家庭中，每天陪同0-3岁孩子读书一次的家长仅占9%，这让美国哈佛大学教育学院终身教授，国际著名儿童语言与阅读发展教育权威专家、前美国教育学会会长凯瑟琳·斯诺和她的研究团队大为意外。在英语国家，同样类型的研究中，即使是来自低收入家庭的家长就有50%可保证每天至少一次家庭亲子阅读。

2016年4月23日，深圳启动0至6岁儿童早期阅读公益项目“阅芽计划”，该项目由深圳市爱阅公益基金会和多家政府部门联合发起，针对学龄前儿童及其家庭的早期阅读教育公益项目，是目前世界范围内最大型的汉语儿童早期阅读干预项目。

一年多来，由哈佛大学教育学院博士后研究员陈思、终身教授凯瑟琳·斯诺教授领衔的研究团队对阅芽计划进行了跟踪评估研究。研究发现，0-3阶段的阅芽计划，有效提高了学前儿童的语言发展，同时显著地增进了家长群体对于高质量的早期阅读教育的理解。

2017年11月18日，在 “早期阅读与更好的未来” 首届全国儿童早期阅读发展与教育峰会现场，南方周末记者对话凯瑟琳·斯诺教授和陈思研究员，探讨早期阅读研究的最新发现以及对我国的早期阅读教育课程、教师培训和政策制定的启示。

家庭亲子阅读或可弥补阶级差异

南方周末：家庭亲子阅读究竟会对儿童会产生怎样的影响？

凯瑟琳·斯诺：儿童的读写发展是一项复杂的社会学习，儿童需要通过与成人的积极互动，学习阅读、获得读写能力的发展、将阅读与知识的活动融会贯通。这个过程中，成人，特别是家长和家庭的阅读环境、教师和学校的阅读环境都对儿童的发展至关重要。

陈思：我们通过大量研究发现，家庭亲子阅读和儿童的语言发展在短期内有着直接的联系。丰富家庭阅读环境对孩子的语音意识、词汇发展、文字意识，以及认知等方面发展都有着积极的促进作用。同时从长期来看，当孩子进入小学之后，家庭亲子阅读对孩子的快速认读、阅读理解、独立思考和表达及未来的终身发展都有帮助。

南方周末：有没有数据说明这一影响到底有多大？

陈思：我们在最新的教育干预实验里对同卵双胞胎的追踪研究中发现，家庭亲子阅读对儿童深层次的阅读理解能力、词汇发展等方面都提供了独立贡献超过20%的影响因素。

南方周末：独立贡献20%怎么理解？

陈思：在美国的研究中，中产阶级家庭和低收入家庭的孩子在发展中产生的差异大概为33%。家庭亲子阅读能够独立贡献20%的差异，也就是说33%由社会经济地位带来的差异中，有20%是可以通过家庭亲子阅读来弥补。

仅9%受试家长每天陪同孩子读书

南方周末：你们的样本是如何抽取的？

陈思：研究团队从深圳二十几所早教机构和幼儿园托班收集到了1044个0—3岁儿童家庭的数据，这些儿童的平均月龄是32个月左右，家庭平均成人数量为3.29人，家庭平均月收入大概为3万元。样本中，64%的母亲具有本科及以上教育文化水平。

南方周末：这代表的应该是一个典型的高教育、高收入水平的中国大城市中产阶级家庭的情况？

陈思：一般大家会认为参加早教机构的家庭，平均收入会比较高，所以我们有意识地寻找中低收入的家庭家长参加，特别去找了光明区、龙港区的低收入家庭，还在富士康举办了讲座，讲座后给家长发问卷调查二维码，以此额外招募家长。但在实际操作中，绝大多数愿意参加以及回应问卷的家庭，他们实际收入水平仍旧是比较高的。

南方周末：这样得出的结论是否有失偏颇？

陈思：需要解释的是，因为家庭收入水平完全是由家长自己报告，所以会存在家庭收入不高的家长就不愿意报告，最终成为研究的缺失值，不计入平均收入计算，所以可能会让最终的结果存在偏差。

南方周末：整个调查的周期是多长？

陈思：2015年7月起，我们开始设计研究，于2016年5月正式开始，配合阅芽计划第一期开始做的前测，目前还在继续跟踪项目的发展和变化，还需一年才会结束。

南方周末：样本的数据如何？

陈思：根据这些家庭家长报告的数据，平均每个家庭拥有的汉语图画书47.3本、英语图画书10.9本。每天都能够和孩子一起看书的家长比例只有9%，一周2—6次的家庭也只有8%，这些数字让我们感到震惊。而在英语国家同样类型的研究中，哪怕是低收入家庭家长，每天保证和孩子一起阅读的占50%。

南方周末：为何如此之低？

陈思：确实是低于我们的预期。可能的原因是家长们觉得0-3岁之间的孩子还比较小，往往要到上了幼儿园后才会有意识地培养孩子的阅读习惯。此外，这一年龄阶段的孩子多数由祖辈抚养，父母工作比较忙，确实没有时间坐下来陪孩子读图画书。

“阅芽计划”：家长观念明显改变的干预实验

南方周末：研究设计中，通过什么方式去改变这一现状？

陈思：我们借助已知范围内最大型的汉语阅读教育干预计划——“阅芽计划”，通过阅芽包、线上资源APP、免费线下活动为家长提供教育支持。

南方周末：具体怎么做？

陈思：阅读包里包括：两本适龄图画书、一本60种图书画的导读、一本分阶段的早期阅读指导手册，还有一份图书馆之城的邀请函，让家长了解在周围的社区还有什么资源可以应。利用APP，家长可以获得更多的电子图画书资源、在线讲座，还可以与其他家长社交、互动。线下活动可以让家长参加讲座、图画书分享和交流活动，更直观讨论亲子阅读观念和更好的实践方法。

南方周末：研究中遇到了哪些挑战？如何克服？

陈思：有两个，如何建立一个可靠的因果联系和如何准确测量家长的观念变化。对此，我们做了三件事，第一是在2016年5—6月进行基线测试，给所有的家长发放了问卷，问卷中包括家庭基本情况、家长的观念，以及由家长报告的儿童词汇发展测试。基线测试结束后，2016年7月，我们随机抽出半数家长拨打电话，告诉他们阅芽计划的情况，随后观察哪些家长来领了阅芽包。最后我们在2017年1月进行了后测，后测包问卷和调查实验，观察家长的观念和儿童词汇发展的变化。等这些都完成以后，再进行模型拟合和数据分析。

南方周末：第一次测试是6个月，为什么选择这一时间跨度？

陈思：半年在语言发展中是一个非常重要的时间段，能够观察到孩子发生比较明显的变化，并且我们希望能在一年中有三次彻查，所以半年的跨度是比较理想的。

南方周末：后期测试发现了哪些变化？

陈思：与未参与阅芽计划的儿童相比，参与阅芽计划的儿童的词汇发展有着明显的进步。通过阅芽计划，家长也获得了对高质量亲子阅读教育的理解：他们普遍认同应该为孩子提供更多的图画书、在阅读时有更好的亲子互动、并认为应该同时增加自己的阅读量。

凯瑟琳·斯诺：一项有趣的发现就是家长观念的改变。以往调查的结果显示，家长的育儿观念是很难改变的。而在我们的调查里，很多家长却改变了他们的教育观念，并且是朝着积极的方向。这一点让我们备受鼓舞。也有一种可能是参与我们研究的家长有进行亲子阅读的意愿，但却没有实际操作的能力。他想要知道，因此他就来了。

南方周末：在幼儿园或早教机构中，老师如何介入早期阅读？

凯瑟琳·斯诺：增加成人和孩子交流的频率和讲话数量，以及有更多想象空间的深入对话，可以让孩子获得更多的支持和发展。而在幼儿园的环境中，孩子跟老师一起读书，比如说读图画书、角色扮演或者深入交谈，都可以帮助孩子们发展语言和读写能力。

南方周末：似乎还应该给家长组织一些培训？

凯瑟琳·斯诺：无字或者字比较少的书，确实需要家长学习比较具体的技巧，去发现故事到底怎么发展的。家长要具有引导孩子关注某些特定细节的能力，比如到故事关键处，向孩子提问核心的信息、去问孩子接下来会发生什么、去做一些预测和猜想。家长往往会觉得读图画书就是孩子学习词汇的过程，实际上这只是很小一部分。图画书真正作用在于让孩子学习更多的知识、了解日常生活中接触不到的话题。因此，图画书学习的重点是需要成人参与其中，为孩子提供更多讨论和交流的机会。

家长焦虑程度越低孩子语言发展更好

南方周末：很多中国父母在教育问题上表现出竞争焦虑，我们的研究过程中是否涉及这一点？

陈思：有，我们发现焦虑程度越低的家长他孩子语言发展会更好，特别是表达性的语言。越焦虑的妈妈可能会导致孩子讲话机会变少，孩子表达性语言的发展就会受到阻碍。

凯瑟琳·斯诺：支持型（即放手型）的母亲，她们孩子的语言表达和叙述能力会更好，这绝不是偶然的，母亲的焦虑会在亲子关系和孩子的发展中带来负面影响。当然，目前只是发现了这俩者间的相关性，而非因果联系，我们也不希望这个结果让她们变得更加焦虑。

南方周末：有没有好的建议给到焦虑的家长？

凯瑟琳·斯诺：如果你觉得养育孩子不是一件有趣的事情那就最好别那么干。请母亲们冷静下来就好，长期焦虑可能会是对孩子压力的来源。越放松的妈妈可能越能站在孩子的角度去思考。很多家长都会焦虑孩子5、6岁的时候有多少知识储备，但是家长们也要思考当孩子到了20、30岁的时候是否还对学习保有兴趣、对世界怀有好奇，还是否乐意以积极的态度去尝试新的东西。相比孩子在5、6岁懂得三门语言、会玩两种乐器，这才是最重要的事情。

南方周末：教育焦虑是否也存在文化差异？

凯瑟琳·斯诺：亚洲文化圈里，家长的权威感更强也更重视教育，因此焦虑会更甚，包括日本韩国的家长也非常焦虑。至于中国家长，我的猜测是之前几十年中国的独生子女政策，会让他们感觉到不能失败，从而带来更大的育儿压力。

美国经验：社会力量助力早期教育

南方周末：近期，斯坦福大学罗斯高教授的演讲在中国引发热烈讨论，他指出0－3岁是孩子智商发展的关键期。你是否认同？对于语言学习来说，是否也存在关键期？

凯瑟琳·斯诺：0-3（岁）这个阶段，孩子确实能学很多包括语言、社会知识、处理问题的能力，因此公认是一个很重要的阶段。但不幸的是，很多人因此把它理解成如果孩子在3岁的时候没有获得相应的知识，就会一辈子落后，甚至不再有机会学习赶上。这种说法是错误的，这是一个重要的阶段但不是绝对关键期，并不是说错过了这个时期以后就没有其他机会发展了。

南方周末：美国早期阅读的现状是怎样？

凯瑟琳·斯诺：在美国，早期阅读实践的水平要高很多。我们通过20年的实践，让很多人认识了到这个问题的重要性。不同社会阶层的家长对早期阅读的态度有很大差异，部分拉丁裔家庭，家长和孩子一起阅读的方法和策略还是比较简单和低水平的。因此，现在美国面临的挑战是如何为不同社会阶层的人设计方案，帮助他们达到比较理想的早期阅读效果。

南方周末：20年时间改变全社会早期阅读理念，美国是如何做到的？

凯瑟琳·斯诺：除了家长积极实践，很重要的一点是社会力量支持。在美国，很多的社会组织和公立图书馆都会提供机会，给孩子派书送贴纸，鼓励他们阅读。例如：波士顿的公共图书馆一直有一项名为“1000本书”的阅读计划，鼓励孩子在6岁上小学之前读满1000本图画书。我觉得这是中国社会可以借鉴的，早期阅读不仅是家长和老师的责任，还需要社会力量的支持。

陈思：和其他城市相比，深圳的阅芽计划也算是非常大的进步了，先从60本书做起，未来才可能有600本、1000本，我们也希望这个项目来日可以推广到更为广阔的乡村。

南方周末：确实，中国还有数量巨大的留守儿童群体，他们大多数不具备家庭亲子阅读的客观条件。这该如何解决？其它在发展中国家进行的研究可否可以借鉴？

凯瑟琳·斯诺：学术圈已有探索，比如：举办集体活动，邀请乡村孩子家长在节假日到公立图书馆，陪同孩子参与集体读书。智利的情况有跟中国类似的地方——来自低收入的群体的家长很少有和孩子一起看书的习惯。在这种情况下，我们尝试把家长请到学校里来，陪孩子一起做图画书，把生活里的一些小事描摹下来、写写画画，做图画书。我们发现，平时缺乏资源、很少有机会了解该怎么和孩子阅读的家长参与的积极性很高，并且在这种环境中做的事情会给他们一个很好的榜样。

点击下方蓝字

下载：南方周末 新版客户端

聊聊高并发长连接架构：百万在线的美拍直播弹幕系统如何实现

Tue, 07 Nov 2017 08:21:39 CST

导读：直播弹幕是直播系统的核心功能之一。如何迅速作出一个有很好扩展性的弹幕系统？如何应对业务迅速发展？相信很多工程师/架构师都有自己的想法。本文作者是美拍的架构师，经历了直播弹幕从无到有，从小到大的过程。本文是作者对构建弹幕系统的经验总结。

王静波，毕业于西安交通大学，曾任职于网易和新浪微博，微博工作期间负责开放平台业务和技术体系建设。2015 年 9 月加入美图，就职于架构平台部，目前负责部分核心业务和基础设施的研发工作，包括弹幕服务、Feed 服务、任务调度和质量监控体系等。十余年的后端研发经历，拥有丰富的后端研发经验，对于构建高可用、高并发的系统有较多实践经验。欢迎通过 wjb@meitu.com 跟他交流。

直播弹幕指直播间的用户，礼物，评论，点赞等消息，是直播间交互的重要手段。美拍直播弹幕系统从 2015 年 11 月到现在，经过了三个阶段的演进，目前能支撑百万用户同时在线。比较好地诠释了根据项目的发展阶段，进行平衡演进的过程。这三个阶段分别是快速上线，高可用保障体系建设，长连接演进。

一、快速上线

消息模型

美拍直播弹幕系统在设计初期的核心要求是： 快速上线，并能支撑百万用户同时在线。基于这两点，我们策略是前中期 HTTP 轮询方案，中后期替换为长连接方案。因此在业务团队进行 HTTP 方案研发的同时，基础研发团队也紧锣密鼓地开发长连接系统。

直播间消息，相对于 IM 的场景，有其几个特点

消息要求及时，过时的消息对于用户来说不重要；
松散的群聊，用户随时进群，随时退群；
用户进群后，离线期间（接听电话）的消息不需要重发；

对于用户来说，在直播间有三个典型的操作：

进入直播间，拉取正在观看直播的 用户列表；
接收直播间持续 接收弹幕消息；
自己 发消息；

我们把礼物，评论，用户的数据都当做消息来看待。经过考虑选择了 Redis 的 sortedset 存储消息，消息模型如下：

用户发消息，通过 Zadd，其中 score 消息的相对时间；
接收直播间的消息，通过 ZrangeByScore 操作，两秒一次轮询；
进入直播间，获取用户的列表，通过 Zrange 操作来完成；

因此总的流程是

写消息流程是: 前端机 -> Kafka -> 处理机 -> Redis
读消息流程是: 前端 -> Redis

不过这里有一个隐藏的并发问题：用户可能丢消息。

如上图所示，某个用户从第6号评论开始拉取，同时有两个用户在发表评论，分别是10,11号评论。如果11号评论先写入，用户刚好把6,7,8,9,11号拉走，用户下次再拉取消息，就从12号开始拉取，结果是：用户没有看到10号消息。

为了解决这个问题，我们加上了两个机制:

在前端机，同一个直播间的同一种消息类型，写入 Kafka 的同一个 partition
在处理机，同一个直播间的同一种消息类型，通过 synchronized 保证写入 Redis 的串行。

消息模型及并发问题解决后，开发就比较顺畅，系统很快就上线，达到预先预定目标。

上线后暴露问题的解决

上线后，随着量的逐渐增加，系统陆续暴露出三个比较严重的问题，我们一一进行解决

问题一：消息串行写入 Redis，如果某个直播间消息量很大，那么消息会堆积在 Kafka 中，消息延迟较大。

解决办法：

消息写入流程：前端机-> Kafka -> 处理机 -> Redis
前端机：如果延迟小，则只写入一个 Kafka 的partion；如果延迟大，则这个直播的这种消息类型写入 Kafka 的多个partion。
处理机：如果延迟小，加锁串行写入 Redis；如果延迟大，则取消锁。因此有四种组合，四个档位，分别是

一个partion, 加锁串行写入 Redis, 最大并发度:1
多个partition,加锁串行写入 Redis, 最大并发度:Kafka partion的个数
一个partion, 不加锁并行写入 Redis, 最大并发度: 处理机的线程池个数
多个partion, 不加锁并行写入 Redis，最大并发度: Kafka partition个数处理机线程池的个数

延迟程度判断：前端机写入消息时，打上消息的统一时间戳，处理机拿到后，延迟时间 = 现在时间 - 时间戳；
档位选择:自动选择档位，粒度:某个直播间的某个消息类型

问题二：用户轮询最新消息，需要进行 Redis 的 ZrangByScore 操作，redis slave 的性能瓶颈较大

解决办法:

本地缓存，前端机每隔1秒左右取拉取一次直播间的消息，用户到前端机轮询数据时，从本地缓存读取数据；
消息的返回条数根据直播间的大小自动调整，小直播间返回允许时间跨度大一些的消息，大直播间则对时间跨度以及消息条数做更严格的限制。

解释：这里本地缓存与平常使用的本地缓存问题，有一个最大区别：成本问题。

如果所有直播间的消息都进行缓存，假设同时有1000个直播间，每个直播间5种消息类型，本地缓存每隔1秒拉取一次数据，40台前端机，那么对 Redis 的访问QPS是 1000 * 5 * 40 = 20万。成本太高，因此我们只有大直播间才自动开启本地缓存，小直播间不开启。

问题三:弹幕数据也支持回放，直播结束后，这些数据存放于 Redis 中，在回放时，会与直播的数据竞争 Redis 的 cpu 资源。

解决办法:

直播结束后，数据备份到 mysql；
增加一组回放的 Redis；
前端机增加回放的 local cache；

解释：回放时，读取数据顺序是: local cache -> Redis -> mysql。localcache 与回放 Redis 都可以只存某个直播某种消息类型的部分数据，有效控制容量；local cache与回放 Redis 使用SortedSet数据结构，这样整个系统的数据结构都保持一致。

二、高可用保障

同城双机房部署

分为主机房和从机房，写入都在主机房，读取则由两个机房分担。从而有效保证单机房故障时，能快速恢复。

丰富的降级手段

全链路的业务监控

高可用保障建设完成后，迎来了 TFBOYS 在美拍的四场直播，这四场直播峰值同时在线人数达到近百万，共 2860万人次观看，2980万评论，26.23亿次点赞，直播期间，系统稳定运行，成功抗住压力。

使用长连接替换短连接轮询方案

长连接整体架构图如下

详细说明：

客户端在使用长连接前，会调用路由服务，获取连接层IP，路由层特性：a. 可以按照百分比灰度；b. 可以对 uid，deviceId，版本进行黑白名单设置。黑名单：不允许使用长连接；白名单：即使长连接关闭或者不在灰度范围内，也允许使用长连接。这两个特性保证了我们长短连接切换的顺利进行；
客户端的特性：a. 同时支持长连接和短连接，可根据路由服务的配置来决定；b. 自动降级，如果长连接同时三次连接不上，自动降级为短连接；c. 自动上报长连接性能数据；
连接层只负责与客户端保持长连接，没有任何推送的业务逻辑。从而大大减少重启的次数，从而保持用户连接的稳定；
推送层存储用户与直播间的订阅关系，负责具体推送。整个连接层与推送层与直播间业务无关，不需要感知到业务的变化；
长连接业务模块用于用户进入直播间的验证工作；
服务端之间的通讯使用基础研发团队研发的tardis框架来进行服务的调用，该框架基于 gRPC，使用 etcd 做服务发现；

长连接消息模型

我们采用了订阅推送模型，下图为基本的介绍

举例说明:用户1订阅了A直播，A直播有新的消息

推送层查询订阅关系后，知道有用户1订阅了A直播，同时知道用户1在连接层1这个节点上，那么就会告知连接层有新的消息
连接层1收到告知消息后，会等待一小段时间（毫秒级），再拉取一次用户1的消息，然后推送给用户1.

如果是大直播间（订阅用户多），那么推送层与连接层的告知/拉取模型，就会自动降级为广播模型。如下图所示

我们经历客户端三个版本的迭代，实现了两端（Android 与 iOS）长连接对短连接的替换，因为有灰度和黑白名单的支持，替换非常平稳，用户无感知。

总结与展望

回顾了系统的发展过程，达到了原定的前中期使用轮询，中后期使用长连接的预定目标，实践了原定的平衡演进的原则。从发展来看，未来计划要做的事情有

针对机房在北京，南方某些地区会存在连接时间长的情况。我们如何让长连接更靠近用户。
消息模型的进一步演进。

号外：

美图架构，专注于虚拟化平台建设、流媒体、云存储、千万同时在线的通讯服务、音视频编解码等基础设施建设，现急需相关领域爱好者加入，工作地点可自由选择北京、厦门、深圳，待遇从优，美女多多。现紧缺岗位如下：

Go/C 开发工程师：我们 50% 以上代码使用 Go
Java 开发工程师
音视频编解码研究人员
Docker 虚拟化底层研发工程师

有兴趣者请联系：yt@meitu.comorwjb@meitu.comorzl3@meitu.com

推荐阅读

人工智能在线特征系统中的生产调度

Fri, 22 Sep 2017 19:34:20 CST

前言

在上篇博客《人工智能在线特征系统中的数据存取技术》中，我们围绕着在线特征系统存储与读取这两方面话题，针对具体场景介绍了一些通用技术，此外特征系统还有另一个重要话题： 特征生产调度。本文将以美团点评酒旅在线特征系统为原型，介绍特征生产调度的架构演进及核心技术。架构演进共包含三个阶段，不同阶段面临的需求痛点和挑战各有不同，包括导入并发控制、特征变更原子切换、实时特征计算框架涉及、实时与离线调度融合等。本文我们将从业务需求角度出发，介绍系统演进的三个阶段所解决的主要问题和技术手段，然后把系统演化过程中的一些常见问题和解决方案抽象出来，放在特征生产技术章节统一讨论。

特征生产调度演进

从离线到在线

在线特征系统最核心的目标是将离线的特征数据通过在线服务的方式，提供给策略系统使用。在线特征系统的出现是为了实现如下的系统目标：

将离线的特征数据，以接口访问的形式提供给线上策略系统使用
特征数据每日更新一次
支撑的数据量在百亿级以上，可以水平扩展
每秒特征访问量峰值达到百万，平均响应延迟在20ms以内

从整体系统功能上来划分，在线特征系统需要做两件事情：第一，每日将离线更新的特征数据写入到存储引擎，这里我们选用分布式KV（Key-Value）存储引擎Tair作为线上存储引擎，利用公司的ETL工具定期将离线数据写入到Tair；第二，提供接口服务，我们搭建了一个基于Thrift接口协议的RPC服务来对外提供特征读取服务。

由于不同特征集查询方式都相同，只是数据不同，因此在Service层我们把一组特征集合以及它的查询维度抽象成Domain。举个例子，Domain=ABC表示用户基础画像特征，包含性别、年龄、星座等特征，同时它又定义了查询维度为用户ID。这样对于不同的特征集，只需要调用同一个接口，传入不同的Domain即可。

从离线到在线

在这一阶段，系统的重点是搭建一套特征导入、存储、读取的流程。我们利用公司提供的工具和组件迅速完成了任务。当有新的特征表需要接入时，开发一个导入ETL，在服务端做相应的配置即可生效。同时，结构上的松散也带来很大的灵活性。在业务发展初期，团队组织结构单一，需求量少，变化快，种类多，系统保持简单、松耦合，有助于灵活应对不断变化的需求。

从手动到自动

随着每日接入Domain数量的增加，接入新Domain工作显得繁琐而效率低下：每接入一个新的特征表，需要开发ETL，而且ETL需要测试、上线、配置调度。因此，我们重新设计了数据导入的方案。

元数据驱动，平台化导入

ETL工具需要开发数据导入脚本，它的灵活性相对较高，写出错的可能性也很大，测试和审核流程难以避免，新入职同学更是需要较大的学习成本。而对于特征导入这个需求，它的模式固化，可以抽取出以下元数据：

数据源信息：离线数据库、表名称等。
存储引擎信息：引擎类型、机房、IP等。
存储格式信息：Key字段、Value字段等。
特征更新信息：更新周期、分区字段、分区方式等。

根据这些元数据，将导入流程都固化下来，可以进行平台化的统一调度。用户通过填写或选择少量的表单信息注册任务，出错的可能性大大降低，流程也可以从原来的写ETL代码、测试作业、配置调度、上线审核，简化成了填写表单和审核。接入流程从原来的几个小时，缩短到几分钟。同时，存储引擎从原来的仅支持Tair，到现在Squirrel（美团点评基于Redis的KV分布式存储中间件）等多引擎加入，系统调度架构如下。

离线特征生产调度

控制台（Console）是元数据的入口，用户在这里完成表单的填写，元数据落入Settings模块的MySQL库中。
调度模块（Scheduler）从Settings模块读取元数据，每日扫描需要导入的Hive表，待当日离线数据生产完成，便会启动Map Reduce Job来执行导入工作。
接口服务（Service）接收来自客户端的请求，根据Domain名称从Settings库中加载Domain元数据，然后从存储引擎取到对应的特征信息。由于调度模块与接口服务模块统一了元数据，因此新特征的接入可以实现服务端工作零成本，新上线的Domain可以直接从服务接口取到数据，无需任何人工操作。

阶段二的完成大大简化了离线特征的上线流程，使接入工作从几个小时缩短到几分钟，也降低了出错的可能性。导入平台化的实现，也为通用性优化功能提供了土壤：数据压缩功能使得内存、带宽资源得到了更充分的利用；多引擎存储功能满足了需求方对性能的不同要求；导入调度功能解决了更新流量峰值的问题，提高了系统的整体可用性。

从天级到秒级

迄今为止，原始特征数据都是离线的，且更新周期都是一天，这跟离线数据仓库的T+1模式有关。而很多关键的业务指标希望做到实时化，特征工程也是如此。用户近几分钟、近几秒的行为信息往往比很多离线特征更具有价值，实时特征必然会在策略系统中发挥越来越重要的作用。

参考离线特征的计算过程，离线大部分是利用了数据平台的ETL工具，它的输入输出都相对固定，只能落地到Hive，用户大部分的精力只需要关心计算逻辑。因此从离线Hive导入到线上存储引擎，成为了特征系统的主要工作，无需操心特征计算。而目前公司没有很完备的、类似Hive SQL的计算框架支持实时特征计算，生产计算实时特征需要自己写流式处理作业。因此我们有必要提供一个专用、便捷的特征计算工具来支持常见特征的计算工作，利用简单配置完成实时特征计算。

实时特征生产调度

实时部分的系统架构如上图所示，与离线类似，Console部分接受用户的表单配置并将元数据写入Settings持久化。Scheduler会负责读取Settings的元数据信息调度实时特征生产任务。我们采用Storm流式服务计算实时特征，从实时数据仓库的Kafka Topic接收流式数据，并按照预先配置好的特征计算逻辑生产、计算实时特征，然后写入到线上存储引擎。

下面详细讨论一下我们对于实时特征计算的平台化以及优化方案。

实时特征计算平台化

算法使用的特征有繁有简，复杂多变，设计一个自动化的实时特征计算系统难度很大。回到业务需求，我们的目的是通过特征生产系统来简化开发工作量，而非完全取代特征开发；因此我们选择一部分常见的实时特征类型，实现自动化生产和导入。对于更复杂的实时特征，提供了更新接口来支持第三方特征生产程序对接。

以下是系统支持配置化生产的特征类型。首先是不同的 时间跨度分类：

固定时间窗口，时间窗口的起止时间点是固定的，比如某日的销售额。
滑动时间窗口，时间窗口的长度是固定的，但起止时间点一直在向前滚动，比如近2小时销售额。
无限时间窗口，时间窗口的起点是固定的，但终止时间点一直在向前滚动，比如商家历史上销售总额。

销售额这个指标其实是对订单金额做求和（SUM）操作，总结常见的 计算类型有如下几种：

求和（SUM），如销售额。
计数（COUNT），如订单量。
最大值（MAX），如最大订单金额。
最小值（MIN），如最小订单金额。
平均数（AVG），如平均订单金额。
去重计数（DISTINCT COUNT），如页面的用户浏览量（同一个用户多次浏览算一次）。
最新值（LAST），如最后支付时间。
列表（LIST），如最近的支付用户ID列表。

以上时间窗口与指标的组合，一共支持24种常见特征的计算类型。

对于实现上述特征的计算，主要包含如下三个抽象步骤：

读取相关的数据（如上次特征值，或一些中间结果）。
根据收到的业务数据，以及步骤1取到的数据进行计算（如累加或求去重数），得到新的特征值（和中间结果）。
将特征（和中间结果）更新到系统。

不同时间窗口的实现方式应该尽量跟 计算类型解耦，可以抽象出各自的处理方式：

固定时间窗口，这类特征应该将时间窗的标识放在特征的Key当中。例如某商户某日销售额这个特征，将Key设置成${商户ID}_${日期}，这样可以实现时间窗的自然滚动。
滑动时间窗口，常见的做法是缓存时间窗内的所有明细数据作为中间结果，当新的明细数据到来时，删除时间窗内过期的明细数据，并利用缓存的明细数据重新计算特征值。但这种实现方式缺点是当滑动时间窗的跨度较大时，需要缓存大量中间结果，可能成为系统瓶颈。对于这个问题，我们采用了延迟队列的实现方式。

延迟队列实现滑动时间窗，当新的明细数据到来时，会直接累计到特征值，同时将明细数据发送到延迟队列。延迟队列的作用是可以将数据延迟指定时间后重新发送回系统。系统接收到延迟消息时，再从特征值中抵消该部分数据（例如计算近2小时销售额，收到订单数据后累加销售额，收到延迟订单消息则减去销售额），这样可以只保留特征值，无需缓存明细数据即可实现窗口滑动的逻辑。延迟队列的实现方式只适用于可抵消的计算类型，如求和、计数等，但像最大值、最小值、去重计数等无法满足
无限时间窗口，简单粗暴的方式是回溯所有历史消息即可。然而这样存在的问题是，第一，流式实时数据本身一般不会持久化保留太长的时间（通常是几天）；第二，这种方式太耗费资源，特征的每一次更新都涉及多次RPC。较为合适的办法是离线数据计算特征的基准值，实时数据基于离线计算结束的时间点继续累积。详细过程参考下文 数据融合与数据恢复。

为了保证数据可靠性与查询效率，中间结果和特征都存放在分布式Key-Value存储引擎中。下图是Storm计算框架的拓扑逻辑图，其中Calc Bolt承担着不同计算类型的实现，而Mafka Delay Topic则是延迟队列组件，用于实现滑动时间窗口。

实时计算框架

上述24个特征是常见的一些实时统计类特征，开发者只需要填写表单，选择需要的特征类型即可完成特征开发工作。对于现阶段不支持配置实现的个性化、计算逻辑复杂的特征，开发者可以自己开发Storm拓扑实现计算逻辑（对应实时特征生产调度图中灰色的Third Party模块），并通过更新接口写入到线上存储引擎。

实时特征计算优化

从上述支持的特征列表中可以看出，实时计算框架目前只支持聚合、明细列表这样的简单特征。即便如此，实时特征计算还是面临很大的挑战。离线特征只需要计算出更新周期内特征的最终值即可，而实时特征需要把每次特征变化都要实时计算出来，它既要计算的快，又要计算的多，因此它无法支持很大量的数据。

实时特征与离线特征对比

当面临数据计算量的挑战时，优化思路之一是利用一些中间结果或上次计算结果简化计算量，化全量计算为增量计算。例如求平均数这种特征，你可以存住所有的明细数据，当新的一条明细数据加入进来时，将所有明细数据求和再除以总数。这样需要O(N)的时间和空间复杂度，N是明细数据个数。而你也可以仅保留总和跟总数，每次更新只要做一次加法和除法即可。

另一种优化思路是利用近似计算。比如求去重数（DISTINCT COUNT）这种指标，要精确计算可能很难找到一个时空复杂度都比较低的方案，而如果可以忍受近似计算的误差， HyperLogLog算法是一个不错的选择。

特征生产调度技术

在生产调度演进过程中，会不断遇到各种系统问题，如可靠性、一致性、性能等等。在这一章节我们把特征生产调度中一些常见的技术手段，以及常见问题的解决方案汇总起来呈现给大家。

逻辑存储层

逻辑存储层的含义是Domain的元数据并不直接存放与存储相关的信息，而是将这些信息抽象成Storage元数据，如下图所示。其中Domain存储了访问控制、离线源信息、Storage ID等信息，而Storage则存储了存储介质、特征元数据、数据存储格式等与存储相关的信息。Domain与Storage是一对多的关系。

逻辑存储层

抽象存储层Storage有很多好处：

支持数据版本灵活切换。一个Domain可能存在多个Storage数据版本，而只有一个是生效的。由于线上存储着多份版本数据，Domain与Storage的对应关系自由切换，从而可以实现不同数据版本的自由变更。
可以做到读写分离。这个特性对离线特征更新是一个好消息，因为离线特征对时效性要求不高，因此可以做到读的Storage跟写的Storage不同，在合适的时机切换读取的Storage。这样切换表结构、更换存储引擎都可以平滑完成，而对读取方做到完全透明。
实现数据切换的原子性。一次数据导入从Domain上看并不是原子操作（更新一个Key-Value对是原子操作，但是整个离线表导入到KV存储引擎并不是原子的），Storage的引入可以实现Domain导入的原子性，当数据格式、特征元数据发生变化时可以保证数据读取的一致性。

增量更新与数据一致性

对于每日的离线特征更新，我们发现有些虽然总数据量庞大，但每天的变化比较少。比如用户画像，有很多沉睡的用户他的特征基本不发生变化。如果每天将全量数据刷到线上，其实做了很多无谓的更新操作，对系统资源是一个巨大的浪费。尤其是更新线上存储引擎，写入压力将导致在线服务稳定性的波动。因此考虑在更新前计算出特征的增量变化数据，只更新变化的部分。而计算增量数据需要有线上特征集合的完整离线数据备份——数据镜像。

数据镜像（SNAPSHOT）是对线上存储引擎数据的离线备份。由于KV存储的特点适用于随机访问，而对顺序访问（如遍历）的支持并不是其强项，因此通过构造离线数据镜像，可以一定程度上帮助我们更为方便的操作线上KV存储引擎中的数据。这里主要是为了支持增量更新和数据恢复功能。

如下图所示同一个更新周期（Period）内需要做两次数据处理流程：归档（Archive）和同步（Sync）。Archive会将上一个更新周期的SNAPSHOT和这个更新周期的特征数据表做差集和并集。差集的结果是增量数据（Diff），并集的结果是该更新周期内的SNAPSHOT。对于数据量大而Diff又少的特征集合来说，增量更新会极大的节约线上的资源。

离线增量更新流程

增量更新可能带来数据一致性的问题。如果Sync步骤出现了少量数据更新失败（比如写操作偶然性超时），会导致SNAPSHOT与KV存储引擎的数据不一致。这种问题在全量更新时并不是什么大问题，当数据在后续更新周期内全量写入时，可以认为总会修复上次的更新失败问题。然而在增量更新时，这种错误是永久性的。因此我们在生成SNAPSHOT时为每条数据附上一条租约（Lease），当租约到期时，强制将该条数据加入Diff参与当次更新，这样可以保证数据的最终一致性。Lease的时间我们可以对每一条数据进行随机分布，这样需要更新的数据会平稳的分布到每一天而不出现明显尖峰。Lease机制其实是全量更新到增量更新的一个平滑过渡，Lease为0时是全量更新，Lease为无穷大时是增量更新。

写入削峰

随着离线特征表增多，同一时刻进行数据导入的作业相互抢占资源，未加控制的写入速度影响了KV存储引擎的正常读取，甚至引起雪崩。实时特征也面临类似问题，实时数据流容易随着集群的状况、业务的特点出现流量峰谷，如果没有消费速度的限制，很容易导致存储引擎压力突增突减，甚至将其打垮。

离线与实时通过不同手段控制并发写入线上存储速度。离线更新的特点是：

更新具有周期性，需要同步时流量很大，同步结束后流量变为0
对更新延迟性要求不高（往往在小时级别）
写入方完全是特征系统内部模块（每个Sync作业）

我们的目标是尽快将这些数据同步到线上存储引擎，同时兼顾写入速度（影响更新延迟）和集群资源（线上存储压力）。鉴于离线更新的特点，且Sync作业本来就由调度器管理，因此很容易将并发控制实现在调度器内部。调度器会控制每个存储引擎的最大Sync作业并发数量，同时每个Sync作业内部并发的写入速度也是固定的。负载限制的关系如下：

同步中的作业数 * 作业内部并发度 ≤ 线上存储引擎的最大写入压力

而实时特征更新的特点是：

每时每刻都有写入的流量
流量随着业务时间变化会有波动
对更新延迟要求较高（往往在秒级）
写入方有特征系统内部模块，也有第三方的服务

由于写入方可能来自特征系统外部，难以统一控制写入方速度，因此我们没有像离线一样让写入方直接操作线上存储，而是在两者之间增加了一个Updater服务（参考图5.实时特征生产调度），由它控制每个写入方的速度。实时特征流量波动大，且对更新延迟要求高，新接入的实时特征需要预估流量峰值并配置到Updater服务中。对于超过预设流量的请求予以拒绝或延迟。

原子更新

离线特征与实时特征面临的原子更新问题各有不同。离线更新的粒度为天级别，所有特征一天只更新一次，有的特征集合希望保证天级别的更新是原子的。即不希望任意时刻出现一部分特征是昨天的值，一部分特征是今天的值。这个问题利用上文提到的 逻辑存储层可以很好的解决，这里不再赘述。

然而实时特征生产更新却面临另一种问题。很多时候需要先读取特征当前值，然后基于当前值做计算得到新值写入KV存储引擎，一次更新过程涉及到读取，计算、写入三步。因此如果要保证数据更新的一致性，必须要保证一次更新的读、算、写操作的原子性或者事务性。对于原子更新的需求主要有两类解决方案：

生产方通过数据分组，保证相同Key的数据只通过一个线程更新，系统配置化生产的特征都基于Storm计算框架，实现起来非常方便。
如果一些第三方（Third Party）不方便做数据分组，我们通过系统内Updater服务提供的CAS（ Compare And Swap）接口，生产方调用CAS接口进行更新，同样也可以做到原子更新。

数据融合与数据恢复

如果说实时数据是离线数据的延伸，那么离线数据可以说是实时数据的备份，二者是相辅相成的。理论上，利用实时数据可以计算出所有想要的特征，但离线数据可以从不同方面解决实时特征计算中诸多棘手问题：

提升效率。可以利用离线计算来提升效率。例如计算每个商家有史以来的营业额，如果全部采用实时数据，那将要实时回放历史上所有订单数据，这样的数据量和计算代价都是巨大的，此时可以利用离线框架计算出历史营业额，在特征初始化时将离线计算好的历史营业额导入线上存储引擎。之后的特征计算更新依赖实时框架，这样可以节省系统开销。
提升可靠性。可以利用离线计算和导入校正实时更新可能产生的误差，提升数据可靠性。实时特征计算采用Storm框架，可以保证数据记录不漏（At Least Once），但不能保证不重（At Most Once）。从系统设计的角度看，对于实时流式处理要做到确保计算一次（Exactly Once）的代价往往很高，相比于让流式计算绝对可靠，与离线计算结果融合往往是更合适的选择。对于像每日营业额这种固定时间窗的特征，实时更新流程只会更新当前时间窗内的特征（今日营业额），而并不会改动历史时间窗的数据，因此历史时间窗的特征可以利用离线数据重新校正一次，这样可以保证数据的最终正确性。

离线实时特征生产整体架构

上图为离线实时特征生产的整体架构。离线与实时的数据融合，需要一个更强大的调度器，它负责协调离线任务与实时任务的关系，高效、可靠的完成数据导入工作。离线作业与实时作业的调度关系分为两种：

离线只初始化一次，后续只有实时数据从基于离线初始化的值做累积运算。如下图的离线初始化。这种调度类型常见于无限时间窗口的一些计算指标，如商户最后一次订单时间，用户累积消费金额等。
离线与实时作业并存，离线作业定期复写历史数据，实时作业更新最近数据。如下图的离线定期修复。这种调度类型常见于提升固定时间窗特征的可靠性，如商户每日营业额等，这类特征在Key中携带时间信息，特征数据天然按时间窗分区，离线与实时作业更新不同分区的数据而互不影响。
离线初始化

离线定期修复

数据恢复是指当线上数据发生问题的时候（可能由于数据源问题、线上故障、硬件故障等）如何修复线上数据，使其恢复到正常状态。数据恢复是效率和可靠性的双重考验，越快速的恢复到正常状态，系统的可靠性就越高。离线增量更新的特征与实时特征都是在原有特征基础上累积计算，一旦某一时刻数据出现问题需要重导数据，只能从第一次增量开始重新累积，这无疑是及其低效的。如果能够定期备份线上特征的数据镜像，当实时更新从某一时刻出现故障时，可以用最近一次正确的离线SNAPSHOT版本刷新数据。离线数据最新的SNAPSHOT应与线上特征数据保持一致，而实时特征的SNAPSHOT会有一定延迟，这时只要将上游实时流数据回退到SNAPSHOT时间点重新开始消费（如下图所示），这样相比没有SNAPSHOT可以较为快速的恢复故障。

数据恢复功能是离线与实时架构融合的产物，只不过它的离线数据不是业务上产出的某张离线表，而是离线镜像数据SNAPSHOT。

数据恢复

后记

一个完整的在线特征系统数据流涵盖加载、计算、导入、存储、读取五个步骤。从两类数据的五个步骤来看，在线特征系统截至目前还并不完整；而深入到每一个步骤，还有很多功能特性需要继续完善：支持离线计算框架、支持更多的实时计算类型、实时特征计算高可用、缩短数据恢复时间、特征实时监控等等。在与其他团队交流时，也有将特征系统深入到策略系统内部，实现算法、特征迭代一体化流程。在线特征系统的工作仍任重而道远。

能力所限，难免管中窥豹，挂一漏万。欢迎感兴趣同学一起交流。

作者简介

杨浩，美团平台及酒旅事业群数据挖掘系统负责人，2011年毕业于北京大学，曾担任107间联合创始人兼CTO，2016年加入美团点评。长期致力于计算广告、搜索推荐、数据挖掘等系统架构方向。

伟彬，美团平台及酒旅事业群数据挖掘系统工程师，2015年毕业于大连理工大学，同年加入美团点评，专注于大数据处理技术与高并发服务。

最后发个广告，美团平台及酒旅事业群数据挖掘组长期招聘数据挖掘算法、大数据系统开发、Java后台开发方面的人才，有兴趣的同学可以发送简历到yanghao13#meituan.com。

美国父母如何让孩子不输在起跑线上

Fri, 18 Aug 2017 23:05:20 CST

▲据美国伊利诺伊大学阅读研究中心主任理查德·安德森教授的研究，美国儿童的阅读量是中国儿童的6倍。看来从娃娃抓起功不可没。（视觉中国/图）

全文共1309字，阅读大约需要4分钟。

Facebook创始人小扎在孩子出生后，直接手捧一本《给宝宝的量子力学》念给娃听。
亚马逊美国微积分类最畅销的一本书是《婴儿微积分介绍》（Introductory Calculus For Infants）。
国内的珠心算等特色兴趣班也都漂洋过海来到美洲大陆。更不要提奥数，这是印度家庭的保留项目，基本上奥数班的发起者都是印度父母。

本文首发于南方周末

有关中国式育儿焦虑的讨论，已经充斥了一线都市人群的朋友圈，各种生动翔实的“幼升小之战”“魔鬼早教”足以吓退后来者的生育意愿——事实也正是如此。然而，我们或许高估了华夏文明对教育投入的痴迷了，不妨也看看大洋彼岸的美国父母，是如何让孩子不输在起跑线上的。

最早“Parent”这个词是没有动词用法的，只有名词的“父母”一义。直到1990年代，“Parenting”（养育）的观念才正式在美国形成。至少对于美国中产阶级来说，为人父母已经不止意味着为孩子提供生计和支持，更是意味着塑造孩子的生命，给孩子提供更多的机会，这样孩子才具备长远的竞争力。媒体人Ann Hulbert在她2014年出版的《养育美国》一书中写道：“美国人对养育孩子的痴迷，都快接近对性和成功的痴迷了。”

2010年时，加州大学学者RAMEY夫妇合著了论文《The Rug Rat Race》，这个论文用数据佐证了“Parenting”的形成。在1990年代中期开始，美国父母花在育儿上的时间急剧上升。这一增长在受过高等教育的父母身上尤为明显：上过大学的母亲，平均每周要比之前增加9小时来陪伴和教育孩子。作者认为，对此最强关联的解释是大学入学竞争越来越激烈。这和中国父母从产房就操心孩子上哪所985、是否出国念书有什么区别呢？

有调查显示，美国5岁以上幼儿家长认为阅读、算数等知识学习最重要，情绪情感发展最不重要。耶鲁大学儿童发展及社会政策领域的专家沃特·捷列姆博士，在接受中国媒体的采访时更形象地描述了美国父母的焦虑——美国曾有一家公司叫“宝贝爱因斯坦”，这个赤裸裸的婴儿版成功学培训，竟然还受到许多父母的追捧。

怎么可能不搞点成功学培训呢？因为那些成功人士对孩子更“狠”啊！Facebook创始人小扎在孩子出生后，直接手捧一本《给宝宝的量子力学》（Quantum Physics for Babies）念给娃听。而这本书的作者是物理学家克里斯·费里（Chris Ferrie），被亚马逊称为“Geek老爹”。他的其它作品还有——《给宝宝的光学物理》《给宝宝的牛顿物理学》《给宝宝的量子信息学》《给宝宝的量子纠缠》，足以从幼儿阶段由浅入深地搭建孩子的理论物理体系。

亚马逊美国微积分类最畅销的书是《婴儿微积分介绍》（Introductory Calculus For Infants），作者是程序员妈妈Omi M. Inouye。而另一位码农爸爸John C. Vanden-Heuvel Sr.则一口气出了多本幼儿网页设计启蒙书：《给宝宝的HTML入门》《给宝宝的CSS入门》《给宝宝的网页设计入门》。

自从美国儿科学会在2014年发文强调了婴儿早期阅读的重要性后，育儿绘本更是美国高知家庭的常规战备物品了。据美国伊利诺伊大学阅读研究中心主任理查德·安德森教授的研究，美国儿童的阅读量是中国儿童的6倍。看来从娃娃抓起功不可没。

当然，美国父母的焦虑恐怕也有来自亚裔家庭的传染，海外子女教育中文论坛里有个著名的网络词汇“推爸推妈”，推源自英文的“Push”，指的是那种成天盯着孩子学业，上各种课外班的妈妈，不停地推着孩子往前走。“推”的一个明显例子，便是美国的公文学校Kumon（可以理解为中国的补习班）常年挤满了华裔孩子，以至于这类学校越来越多地设立了Junior Kumon Program（少儿公文课程），针对3岁以上的幼儿。

北美的华人子女大部分都会在幼儿园学至少一种乐器，以钢琴、小提琴居多，其次是中提琴、大提琴，几乎每个孩子在晚上或者周末都有额外的兴趣班活动，国内的珠心算等特色兴趣班也都漂洋过海来到了美洲大陆。更不要提奥数，这是印度家庭的保留项目，基本上奥数班的发起者都是印度父母，而中国孩子如果基础不好，进去也很快被落下。

总之，哪个国家的起跑线都输不起。

（作者系知名媒体人）

点击下方蓝字

下载：南方周末新版客户端

吴恩达神秘新项目揭晓：迄今最全面的深度学习在线课程！

Wed, 09 Aug 2017 00:24:38 CST

吴恩达 (Andrew Ng) 拥有多个令人仰慕的头衔：斯坦福机器学习教授、大规模开放在线课程 (MOOC) 早期提出人之一、Coursera 创始人、Google 大脑创始人、百度前首席科学家……

在离开百度后，今年 6 月底，吴恩达已经将自己的新项目 deeplearning.ai 上线，网站颇为神秘，配有他本人的照片和一行字“探索人工智能的前沿”(Explore the frontier of AI)。就在刚才，这个神秘的项目终于揭开了面纱：

deeplearning.ai 将和吴恩达创立的另一家公司 Coursera，一起推出在线课程《深度学习专业》 Deep Learning Specialization。吴恩达挑了个挺不错的时间，美国西部时间 8 月 8 日早上 8 点，Deep Learning Specialization 的 5 堂课程已经在 Coursera 上线。

这些课程专为已有一定基础（基本的编程知识，熟悉 Python、对机器学习有基本了解），想要尝试进入人工智能领域的计算机专业人士准备。介绍显示：“深度学习是科技业最热门的技能之一，本课程将帮你掌握深度学习。”

在这 5 堂课中，学生将可以学习到深度学习的基础，学会构建神经网络，并用在包括吴恩达本人在内的多位业界顶尖专家指导下创建自己的机器学习项目。Deep Learning Specialization 对卷积神经网络 (CNN)、递归神经网络 (RNN)、长短期记忆 (LSTM) 等深度学习常用的网络结构、工具和知识都有涉及。

课程中也会有很多实操项目，帮助学生更好地应用自己学到的深度学习技术，解决真实世界问题。这些项目将涵盖医疗、自动驾驶、和自然语言处理等时髦领域，以及音乐生成等等。

Coursera 上有一些特定方向和知识的资料，但一直没有比较全面、深入浅出的深度学习课程——《深度学习专业》的推出补上了这一空缺。

课程的语言是 Python，使用的框架是 Google 开源的 TensorFlow。最吸引人之处在于，课程导师就是吴恩达本人，两名助教均来自斯坦福计算机系。完成课程所需时间根据不同的学习进度，大约需要 3-4 个月左右。学生结课后，Coursera 将授予他们 Deep Learning Specialization 结业证书。

“我们将帮助你掌握深度学习，理解如何应用深度学习，在人工智能业界开启你的职业生涯。”吴恩达在课程页面中提到。

吴恩达年少曾在香港和新加坡生活，后移民美国。2002 年，他在加州大学伯克利分校完成博士学习，同年加入斯坦福大学计算机系任教。他的教学和研究方向包括数据挖掘和数据分析、深度学习等。吴恩达在斯坦福的一些项目后来在工业界取得了不错的成绩，比如斯坦福人工智能机器人 (STAIR) 项目，后来成为了机器人开源操作系统 ROS (Robot Operating System)。

2011 年，他加入了 Google，创立了 Google 大脑计划。他曾带领几个学生和 Google 资深学者杰夫·迪恩一起做了一个有趣的试验：用 Google 大脑训练一个神经网络，不停地看 YouTube 视频，能够在不给予具体物体的定义前提下，分辨出猫等各类物体。这篇名为《用大规模无监督学习建造高层次特征》的论文在非监督学习领域备受关注。

Google 大脑也成为了业界第一个大规模分布式深度学习系统，在科技行业极具影响力和创新性，为 Google 之后更多的深度学习研究课题和产品项目打下了基础。2014 年，吴恩达高调加盟百度担任首席科学家，领导百度美国研究院，前不久刚刚离职。他是深度学习业界的领军人物之一，学生分布在 Facebook、百度、Coursera、Salesforce 等知名公司。

吴恩达支持人工智能的立场和马克·扎克伯格类似，他希望通过教育的方式将人工智能普及化，培养更多的机器学习、深度学习人才。

在斯坦福大学任教期间，他和 Udacity 的创始人，前斯坦福教授塞巴斯蒂安·特朗 (Sebastian Thrun) 都是 MOOC 的早期提出人。吴恩达建立的 MOOC 项目 Stanford Engineering Everywhere，后来成了在线教育公司 Coursera 的雏形。Coursera 获得了斯坦福、布林斯顿、宾夕法尼亚州立大学和密西根州立大学等名校的课程支持，上线的第一堂课就是吴恩达在斯坦福教授的《机器学习》(CS 229: Machine Learning)，结课的学生总数已经超过 150 万人。

吴恩达在 Medium 上透露，本次和 Coursera 合作的深度学习课程，只是 deeplearning.ai 的第一个项目，他一共有三个项目在筹备中，不排除可能会有面向大众的人工智能产品。

久石让在武道馆：与宫崎骏动画一同走过的25年-音乐-高清MV在线观看–爱奇艺

Tue, 20 Jun 2017 08:43:14 CST

久石让在武道馆：与宫崎骏动画一同走过的25年-音乐-高清MV在线观看–爱奇艺

http://m.iqiyi.com/v_19rrhb1wv0.html?social_platform=link&p1=2_22_221

在线AI技术在搜索与推荐场景的应用

Fri, 02 Jun 2017 15:55:41 CST

　　12月6日-7日，由阿里巴巴集团、阿里巴巴技术发展部、阿里云云栖社区联合主办，以“2016双11技术创新”为主题的阿里巴巴技术论坛(Alibaba Technology Forum，ATF)成功在线举办。在本次分享中，来自阿里巴巴集团的研究员徐盈辉带了题为《在线AI技术在搜索与推荐场景的应用》的精彩演讲，他结合本届双11搜索和推荐场景详细介绍了电商搜索推荐的技术演变、阿里搜索推荐的新技术体系以及未来的发展方向。

　　以下内容根据在线分享和幻灯片整理而成。

　　电商搜索推荐技术演变过程

　　对于阿里巴巴电子商务平台而言，它涉及到了买家、卖家和平台三方的利益，因此必须最大化提升消费者体验;最大化提升卖家和平台的收益。在消费者权益中，涉及到了一些人工智能可以发力的课题，如购物券和红包的发放，根据用户的购物意图合理地控制发放速率和中奖概率，更好地刺激消费和提升购物体验;对于搜索，人工智能主要用于流量的精细化匹配以及在给定需求下实现最佳的人货匹配，以实现购物路径效率最大化。经过几年的努力，阿里研发了一套基于个性化技术的动态市场划分/匹配技术。

　　电商搜索和推荐的智能化演进路程可以划分为四个阶段：人工运营和非智能时代、机器学习时代、准人工智能时代、人工智能时代。人工运营和非智能时代，主要靠领域知识人工专业运营，平台的流量投放策略是基于简单的相关性+商品轮播;在机器学习时代，利用积累的大数据分析用户购物意图，最大化消费者在整个链路中可能感兴趣的商品;准人工智能时代，将大数据处理能力从批量处理升级到实时在线处理，有效地消除流量投放时的误区，有效地提高平台流量的探索能力;人工智能时代，平台不仅具有极强的学习能力，也需要具备一定的决策能力，真正地实现流量智能投放。

　　智能化时代，对于搜索和推荐而言，可以提炼为两点：学习能力和决策能力。学习能力意味着搜索体系会学习、推荐平台具有很强的建模能力以及能够索引原始数据到索引知识提升，学习能力更多是捕捉样本特征空间与目标的相关性，最大化历史数据的效率。决策能力经历了从LTR到MAB再到CMAB再到DRL的演变过程，使得平台具备了学习能力和决策能力，形成了智能化体系。

　　借他山之石以攻玉

　　借他山之石以攻玉。在线服务体系中，我们基于参数服务器构建了基于流式引擎的Training体系，该体系消费实时数据，进行Online Training;On Training的起点是基于离线的Batch Training进行Pre-train和Fine Tuning;然后基于实时的流式数据进行Retraining;最终，实现模型捕捉实时数据的效果。

　　上图是基于Wide & Deep Learning for Recommender Systems的工作建立的Large Scale Sparse&Dense DNN训练体系的架构，该架构中利用Batch Learning进行Pre-Train，再加上Online数据的Retrain&fine Tuning。模型在双11当天完成一天五百万次的模型更新，这些模型会实时输送到在线服务引擎，完成Online的Prediction。

　　Streaming FTRL stacking@offline GBDT的基本理念是通过离线的训练，在批量数据上建立GBDT的模型;在线的数据通过GBDT的预测，找到相应的叶子节点作为特征的输入，每一个特征的重要性由online training FTRL进行实时调整。

　　双11当天的成交额是是普通成交日的十到十二倍，点击量将近三十倍。在用户行为密集发生的情况下，有理由相信数据分布在一天内发生了显著的变化，基于这样的考虑，GBDT的Training由原来的日级别升级到小时级别(每小时进行GBDT Training)，这些Training的模型部署到Streaming的计算体系中，对于实时引入的训练样本做实时的预测来生成对应的中间节点，这些中间节点和人工的特征一起送入FTRL决出相应特征的重要性。

　　Online Learning和Batch Learning有很大的区别，在Online Learning的研发过程中，总结了一些技巧：

　　实时streaming样本分布不均匀时，由于线上环境比较复杂，不同来源的日志qps和延迟都不同，造成不同时间段样本分布不一样，甚至在短时间段内样本分布异常。比如整体一天下来正负例1:9，如果某类日志延迟了，短时间可能全是负例，或者全是正例，很容易导致特征超出正常值范围。对应的解决方案是提出了一些 Pairwise sampling：曝光日志到了后不立即产出负样本，而是等点击到了后找到关联的曝光，然后把正负样本一起产出，这样的话就能保证正负样本总是1:9;成交样本缓存起来，正样本发放混到曝光点击中，慢慢将Training信号发放到样本空间中。

　　异步sgd更新造成模型不稳定时，由于训练过程采用的是异步SGD计算逻辑，其更新会导致模型不稳定，例如某些权重在更新时会超出预定范围。对应的解决方案是采用mini batch，一批样本梯度累加到一起，更新一次;同时将学习率设置小一点，不同类型特征有不同的学习率，稠密特征学习率小，稀疏特征学习率大一些;此外，对每个特征每次更新量上下限进行限制保护。

　　预测时，在参数服务器中进行Model Pulling，通过采用合理的Model smooth和Model moving average策略来保证模型的稳定性。

　　智能化体系中的决策环节

　　电商平台下的大数据是源自于平台的投放策略和商家的行业活动，这些数据的背后存在很强Bias信息。所有的学习手段都是通过日志数据发现样本空间的特征和目标之间的相关性;进而生成模型;之后利用模型预测线上的点击率或转化率，由于预测模型用于未来流量投放中，因此两者之间存在一定的时间滞后(systematic bias)，也就观测到的数据和实际失效的数据存在着Gap。在工作逻辑中，如果一个特征和目标存在很强的Correlation，则该特征就应该在线上的预测中起到重要作用。

　　在整个体系中，Systematic Bias很难做到理想化的控制，而且离线模型预期效果与线上的实际生效效果存在差异，这背后的根本原因是Correlation并不等于Causation，也就是特征与目标相关并不意味着特征出现一定导致目标发生。

　　那么怎么解决Offline Reward Signal不等于Online Dashboard Metrics的问题呢?我们引入了强化学习，通过引入Online User Feedback更好地定义Reward，对线上排序策略进行调整，使其具有更强的自适应性。

　　搜索/推荐引擎决策体系

　　搜索引擎和投放页面天然存在互动：搜索引擎观测消费者的交互状态;搜索引擎根据交互状态执行投放策略;投放策略之后，呈现商品结果页，消费者在商品结果页中的操作行为反馈给搜索引擎。引擎决策实际上能改变投放环境，进而影响消费者的交互，改变消费者的状态。如果不需要建立从状态到动作的策略映射，可以采用Multi-armed Bandits方法进行流量探索;如果需要建立该映射时，需要采用Contextual MAB方法;在新状态下，考虑消费者的滞后Feedback对于引擎在之前状态下的Action正确与否产生影响，需要引入强化学习的思想。

　　搜索和推荐过程可以抽象成一个序列决策问题，从消费者与引擎的交互过程中寻找每一个不同状态下的最优排序策略(各种排序因子的合理组合)。

　　我们的目标是希望搜索引擎决策体系进化为具有强化学习能力的智能化平台。过去的搜索，我们只能做到遇到同样的用户购物诉求下，尽可能保证做得不必以前最好的方法差，也就是所谓的Historical Signal==Best Strategy;一切模型都是建立在优化直接收益的基础上。未来的搜索，我们希望能够保证长期收益最大化来决定引擎的排序策略，也就是Immediate Reward+Future Expectation=Best Strategy;未来的排序融合入模式都是建立在优化马尔科夫决策过的基础上，最大化The Discounted Reward。

　　基于强化学习的实时搜索排序调控

　　下面简要介绍下为应对今年双11提出的基于强化学习的实时搜索排序调控算法。

　　对于强化学习，它的目标是最大化时刻T所选择的策略的长期收益最大。对于离散state和离散Action的情况，可以采用Tabular RL方法求解;对于连续State和连续Action，采用RL with Function Approximation。其中State表示用户近期发生行为商品的可量化特征，Action表示权重量化(维度是排序特征分)，Reward是Systematic Valid User Feedback。

　　双11采用Q-learning的方式进行实时策略排序的学习，将状态值函数从状态和策略空间将其参数化，映射到状态值函数的参数空间中，在参数空间中利用Policies Gradient进行求解;将状态值函数Q拆解成状态值函数V(s)和优势函数A(s,a)进行表达。

　　其算法逻辑如上图所示，基本算法是实现线上几十个排序分的有效组合，样本包括日志搜集到的状态空间、Action Space(这里对应的是排序分空间)，奖赏是用户有效的Feedback，具体的排序策略表达公式以及策略更新和值函数更新的公式可以参考Maei，HR的《Toward off-policy learning control with function approximation》一文。

　　在双11采用的基于强化学习的实时搜索排序调控的实现体系如上图所示。当用户输入query时，会向系统询问哪一种排序策略最适合自己;该查询策略请求会上传至在线策略决策引擎，在线策略决策引擎通过实时学习的Q(s，a)模型合理选择有效策略，然后再返回给搜索引擎;搜索引擎依据当前状态下最有效策略执行搜索排序;在搜索排序页面展示的同时，系统会及时搜集相应的状态 action以及用户feedback的信号，并进入到Online Training Process;而Online Training Process会通过Off-policy model-free RL方法学习State To Action的映射关系，再从映射关系中得到线上排序所需要的策略参数;该策略参数由在线策略决策引擎通过Policy Invalid Process输出给在线搜索引擎。

　　总结

　　整体搜索/推荐希望建立一个Close-loop for iCube learning体系，其中iCube要求系统具备immediate、interactive、intelligent的能力。整体从日志搜集到maximize rewards、minimize dynamic regret实现Online Training;其中Training模块能够高效地部署到Online Service;而Online Service必须具有很强的探索和overcome bias能力，进而使得整个体系能够适应新的数据，提升流量投放效率，同时能够探索新奇和未知的空间。

　　在AI应用到商业的过程中，未来努力方向是：

　　From batch to streaming，希望从historical batch learning转化为life long learning;

　　整个学习体系由tailor for tasks 向利用transfer learning实现不同渠道、应用下学习模型的复用转变;

　　Training process 从Blackbox转变为实现合理的knowledge representation，实现线上投放逻辑的controlled&comprehensible;

　　学习体系随着强化学习和在线决策能力的增强，从local optimization向global evolving转变。

　　大会所有资源(视频回放、PDF、文章整理)一键下载：https://yq.aliyun.com/articles/65238

　　大会系列整理文章：

　　阿里双11背后的网络自动化技术——张铭(阿里巴巴研究员)

　　演讲整理文章：https://yq.aliyun.com/articles/64680

　　阿里大规模数据计算与处理平台——林伟(阿里巴巴资深技术专家)

　　演讲整理文章：https://yq.aliyun.com/articles/66113

　　在线AI技术在搜索与推荐场景的应用——徐盈辉(阿里巴巴研究员)

　　演讲整理文章：https://yq.aliyun.com/articles/66158

　　揭秘阿里虚拟互动实验室——袁岳峰(阿里巴巴高级技术专家)

　　演讲整理文章：https://yq.aliyun.com/articles/66105

　　阿里超大规模Docker化之路——林昊(阿里巴巴研究员)

　　演讲整理文章：https://yq.aliyun.com/articles/65377

　　双11媒体大屏背后的数据技术和产品——罗金鹏(阿里巴巴高级技术专家)

　　演讲整理文章：https://yq.aliyun.com/articles/66098

　　数据赋能商家背后的AI技术——魏虎(阿里巴巴资深技术专家)

　　演讲整理文章：https://yq.aliyun.com/articles/66159

　　面对双11的前端“极限挑战”——舒文亮(阿里巴巴高级技术专家)

　　演讲整理文章：https://yq.aliyun.com/articles/66106

创业邦携手阿里云推出创业四重礼，包括1-3万免费云资源、35+产品6个月免费等福利>>http://www.cyzone.cn/aliyun/

在线教育企业七成亏损，15%濒临倒闭！

Fri, 17 Feb 2017 08:00:00 CST

（央视财经《经济信息联播》）从2011年开始，在线教育从语言类在线教育起步，逐渐为人们所知，由于学习方式灵活，而且价格实惠，在线教育吸引了大量的城市注册用户。不过，最新数据却显示，这个火爆一时的行业竟然有70%的企业面临亏损的窘境，一些公司甚至刚上线就倒闭。

七成在线教育企业亏损

唐志云曾是一名培训机构的英语老师，2013年前成立了自己的线上教育工作室，看中的就是线上线下完全不同的传播效果。

唐志云逸卓国际教育创始人我在线下我们一个月，我教10个学生，15个学生，我一年顶多也就教150个到170个学生。但是我在线上，我一期可能就能够教上百个学生。

然而三年过去了，唐志云发现，现实并不像想象得那么美好，很多时候一堂课试听的人数能达到千人级，但是真正愿意为课程掏钱的却并不多。

唐志云逸卓国际教育创始人：线上的转化率应该是在千分之几，可能有那么一千个人几个人买你的课。

唐志云的境遇并非个案。眼前的这栋4层小楼曾经是一个大学校园内的孵化器，从2011年开始，这里见证了在线教育的一个发展高潮期，最多的时候，这里的在线教育机构有20多家，穆德国创立的爱语吧也在这里，不过如今，最初的同行者已经很少了。

穆德国北京爱语吧科技有限公司CEO：存活下来的只有爱语吧、慧科的开课吧，别的都可能销声匿迹了。这个白色板子上，以前密密麻麻的全是公司LOGO，现在已经空了。

市场机构对400家主要在线教育企业的调查结果显示，截至2016年底，当中70%的公司都处于亏损状态，10%的公司能够持平，能够盈利的仅占5%，甚至有15%的企业濒临倒闭。

资本青睐不减在线教育用户增速惊人

在线教育真的只是昙花一现吗？记者采访发现，尽管创业公司总体经营不佳，但资本的热情却未见消减。2016年，在线教育机构51Talk成功赴美上市，新东方网获准挂牌新三板，还有不少资金保持着与创业公司的接触，这又意味着什么呢？

在51Talk创始人黄佳佳看来，企业之所以能在纽交所挂牌，并且拿到累计超过1亿美元的融资额，关键在于让资本看到了在线教育市场的发展速度。

黄佳佳 5Talk无忧英语创始人兼CEO：一般来说在一个线下的教育公司基本上年对年增长30%，最多50%，超过200%的增长，只有在线教育才可以做到。

从创业时的3人团队，发展成如今八千多人的队伍，黄佳佳认为企业如此高速的成长，其实是源于市场足够大。

黄佳佳 5Talk无忧英语创始人兼CEO：我们自己创业这5年，感觉到一个很明显的点就是说，我们看到了在线教育用户的习惯在快速的形成。

中国互联网络信息中心数据显示，截至2016年12月，中国在线教育用户规模达1.38亿，增长25%，市场规模超过1500亿元。尽管确实存在大量创业企业处境困难的现实，但足够大的用户基数，仍然给了这个行业巨大的想象空间。这也是去年11月，新东方集团宣布拆分上市，将其在线业务新东方网单独推出的重要背景。

孙畅新东方集团副总裁：未来可能通过投资，然后通过并购，把我们整个的教育的生态链都把它打造的更加的完整。

公开信息显示，2016年，在线英语学些机构VIPABC获得C轮近2亿美元的融资；哒哒英语宣布B+轮融资3亿元；就在本月，有教未来也宣布获中文在线千万级融资。在投资人看来，目前在线教育仍处于早期发展阶段，企业遭遇困境在所难免，但这也是行业洗牌的一个过程。

刘星红杉资本中国基金合伙人：成本需要有企业做到更大规模的时候，就能够比较好的把它分摊掉。在线教育是一个大幕才刚刚开启。

IT瘾在线推荐

“AI垃圾”泛滥，最后的防线在人类自身-新华网

拔掉网线后， 原本的 TCP 连接还存在吗？

拔掉网线后，有数据传输

拔掉网线后，没有数据传输

总结

开发一个在线代码对比工具

highlight: monokai

前言

Monaco Editor

马上掘金

技术栈选择

实现 Diff Editor

最后

当土木工程系毕业生在线“劝学”

启动资金两百万，能做精品酒店么？海滨三线城市，在这里三星级酒店房价两百左右，做精品酒店可行么？

大型系统在线问题诊断与定位

先来看看苦逼的开发人员

业界的思路？

相关开源产品

我们的方案

实际的案例

解码 bug

CPU 尖刺

goroutine 泄露

deadlock(扩展)

thread block(扩展)

总结

如何构建更健壮的在线系统_heiyeluren的blog（黑夜路人的开源世界）-CSDN博客

【原创】如何构建更健壮的在线系统

0. 背景

一、系统架构与设计遵循哪些关键原则？

二、系统程序实现里哪些关注原则

三、健壮代码有哪些通用原则

四、个人软素质：细心、认真、谨慎、精进、专业

本文结束语：

工商银行打造在线诊断平台的探索与实践

传统方式排查问题的痛点

Arthas 的解决方案

落地使用上的困难

技术方案

1. 整体架构

1）在线诊断平台

2）在线诊断网关

3）在线诊断进程

2. 诊断过程详解

1）诊断前准备

2）开始安装

3）获取安装介质

4）启动诊断程序

5）使用和卸载

实际使用效果

1. 控制面板

2. 线程清单

3. 方法监测

1）方法观测

2）方法追踪

3）方法追溯

4）方法监控

4. 反编译

5. 其他能力

回顾与展望

Arthas 有奖征文正在进行中！

从Oracle到MySQL，金融核心场景在线换库落地实战 - MySQL

转@架空管线 “要有新的歌颂方法”转@絕望的鹹魚 所有能自由创作的东西，在这片土地上都不能创作，然后社会永远都是在追求「创新」。呼唤什么缺什么。

中移在线容器平台入选云原生应用十大优秀案例，成为全球最大客服云案例

Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾

前言

Service Mesh 与 Spring Cloud 应用的互通、互联

注册中心与高可用方案

通过治理策略保证服务高可用

服务限流

熔断

智能路由

总结

参考资料

霸榜世界第一的在线教育App，靠什么增长到3亿用户？ - 增长黑盒 - 增长黑客专用工具箱 - 增长黑客社区

如何应对在线故障

直白介绍卷积神经网络（CNN） - 文章 - 伯乐在线

什么是卷积神经网络，它为何重要？

拔掉网线后，原本的 TCP 连接还存在吗？

转@架空管线 “要有新的歌颂方法”转@絕望的鹹魚所有能自由创作的东西，在这片土地上都不能创作，然后社会永远都是在追求「创新」。呼唤什么缺什么。