2018 年掘金 AMA 年度总结：16 位技术大牛他们的技术事

掘金AMA（ask me anything) 是掘金沸点的一个话题，掘金团队会邀请一位技术大牛通过「你问我答」的形式回答你的问题，让大家在技术、工作、生活方面有所成长。

* Tips：本人不喜欢太过官方 or 正式的文字，本篇文章比较口语化，见谅(≧▽≦)

2018 年 16 期 AMA

本文会从每期 AMA 会选一个高赞或极有价值问题，仅供技术交流。

旁白：第一期 AMA，也是我个人最喜欢的 AMA 之一，宗心的海报真的让人感到开心。

本期优质问题：你怎样看待最近 Airbnb 和 Udacity 都相继放弃了 RN ？-- 来自@zyf在掘金

请问，闲鱼 App 中有哪些地方使用 RN，你怎样看待最近 Airbnb 和 Udacity 都相继放弃了 RN ？

宗心回复

闲鱼 app 里没有使用 RN，但有不少页面使用 Weex，在我看来，不管是 Weex 还是 RN，我们去看成本：

1. 前端体系的学习成本
2. debug和兼容性的成本
3. 基础设施建设的成本

这三个成本是逃不过的，所以如果觉得这三个成本大于你的收益，建议不要用。而对于闲鱼来说

1. 我团队有专门的weex专家带一些有前端知识体系的同学
2. 基础设施有阿里巴巴集团的基础设施做基础，自己需要再建设的不多。

这两个其实已经决定了我们在使用过程中成本没有那么高，目前最高的可能就是 debug 成本和兼容性问题了，暂时是可以接受的。再说收益

1. 我们有一套从sketch到代码的生成工具，所以UI还原部分，我们基于此少写了很多代码
2. 三端一致性，在部分业务上确实带来了好处，尤其闲鱼要在外部多端进行投放，不管是手淘还是外部投放，我就写一份代码，相比来说成本肯定要低一些，所以这个要看场景
3. 作为前端使用，性能上比h5还是会好很多，前端使用过程中也有一些收益。 均衡来看，我们还是在对应的场景下会持续使用下去。

本期 AMA 小故事

AMA 进行回答的第一天，宗心去了医院，所以第一天的问题下的回复都是在医院里诞生的。 延伸下：接触下来优秀的人对事态度都特别认真。

旁白：这期和上一期的嘉宾都是一颗香菜安利给我的，感谢香菜，以及 Rand 是一个非常 Nice 的人--详见小故事。

本期优质问题：作为一位资深的 Android 开发者，请问您觉得哪些技能点是比较重要的？--来自@Snailer

作为一位资深的 Android 开发者，请问您觉得哪些技能点是比较重要的？

Rand 回复

1. 从技术方面，围绕着快速高效的解决问题来讲：
   1. 熟练掌握性能优化手段，包括卡顿，FPS，CPU，布局优化，内存优化等。
   2. 架构能力，熟练掌握 MVP，MVVM，组件化，并能够针对业务场景实施合适的架构方案。
   3. 开发组件上，要熟练掌握常用组件的原理及扩展方式，比如图片加载库，RxJava，OkHttp 等，在团队碰到常用组件的问题上能够给与解决思路或方案。
   4. 掌握系统原理，比如安装包结构，打包安装过程，插件原理等。
2. 从软技能上，要培养分享沟通表达能力，这些能力对传播知识和方法论，培训新生力量，提高整个团队的战斗力有很大的帮助。

本期 AMA 小故事

Rand 的海报个人照被设计小姐姐否了 N+ 次，最后用了现拍的照片， 是不是 程序员 自拍水平普遍上来说都不大好呢？

旁白：个人很喜欢这期嘉宾的海报，个人照带着一丝萌。

分布式的线上代码更新和服务重启有什么好的方法么？ -- 来自@wking

分布式的线上代码更新和服务重启有什么好的方法么？

黄挺回复

分布式的架构下，应用的代码更新发布上线的确没有单体应用的架构下来得这么容易。目前业界也有比较多的发布方案可以借鉴，比如蓝绿发布，灰度发布，金丝雀发布等等，来保证代码的更新在分布式的环境下可以做到充分的验证。

关于服务重启这个问题，可以从两个方面去看，一个是服务如何做到平滑的关闭，一个是服务如何做到平滑的启动。

关于平滑的关闭，一般上的做法是先从服务注册中心里面把对应的节点拿掉，等一段时间上游系统收到的地址列表里不再有对应的节点，并且对应的节点已经没有请求在处理了，那么就可以开始关闭了。

关于应用的平滑的上线，首先应用在启动完成之后，最好先做一遍自检，检查应用自己是否当前是健康的，健康了之后，再对外提供服务，这个过程一般上被称为 Readiness Check，目前 SOFABoot 中也提供了这个能力： www.sofastack.tech/sofa-boot/d…

除了 Readiness Check 之外，因为 Java 的 JIT 的问题，一个应用刚刚启动的时候，往往性能相对比较差，这个时候，就要做服务的预热，在 SOFARPC 中，也提供了服务预热的能力： www.sofastack.tech/sofa-rpc/do…

本期 AMA 小故事

在蚂蚁金服分布式架构 SOFA 技术沙龙见过黄老师，运营妹纸和他对话说道：我还没吃饭的时候，黄老师开启了无视模式进入到了下一个话题， 是不是程序员都不大会关心人呢？

旁白：第一期没有嘉宾个人照上海报，老钱说不大好意思，我：？？？行吧。

有哪些高效工作和高效学习的秘诀？--来自@蒋海博

老钱，您好，既然您有孩子，请问如何平衡陪伴孩子和工作的时间？我看您又工作又写出，应该很忙吧。还有是否能分享下如何高效工作和高效学习的秘诀。谢谢。

老钱回复

我在掌阅的工作本身不是太忙，至少近期时间上还有不少闲鱼。所以我才会有时间来做一些技术写作的事。白天家里有老人帮我看孩子，每天下班回家，孩子睡得也早。到了周末，我总会花一些时间带着孩子去逛商场，这也就是平时最主要的亲子活动了。我本人比较宅，社交活动很少，所以剩下的时间就可以专心做自己喜欢的事，如果一个人整天到处跑，除了没时间之外，估计心态也会比较浮躁。

市面上所有的编程书籍都有一个规律，那就是越基础的书越多，越高级的书越少。随着自己知识的渐长，市面上的书籍大多已经不能满足我的需要，所以平时的学习知识来源还是主要靠网络分享、靠源码、靠 google、靠 stackoverflow。除非是对某个新的领域感兴趣，我会买一些基础的书来了解入门。工作上当我做一件事的时候，我会非常专心地去做，我会带着耳机希望自己不被打扰，安静的状态平和的心境就会带来效率的提升。

本期 AMA 小故事

正如之前说的，优秀的人对事的态度极为认真，你可以从老钱的 AMA 回复感受到。

旁白：死月是我一个前端同事超迷的一位开发。

node 未来的方向？ --来自@wujunze

你好 node未来的方向 和 它真正能擅长的场景是哪些 ？

死月回复

Web 领域应该会继续守住，但也不会去撼动谁谁谁的地位，各有所长，在大家的熟练度、性能以及研发效率之间找一个平衡。相似的还有就是游戏类的服务器，但是竞品太多了，而且还没完成一个太集中和完善的生态，老大哥柚子感觉已经好久没人维护了。

在渲染方面会有优势。因为这一层比较轻薄，上 Java 就显得厚重了。

一些 Serverless 引擎以及类似场景可能会有天然的优势。例如 leancloud 在你做各种事情的时候可以写一些 JavaScript 源码作为补充逻辑，自己解释自己的开发成本通常比你在 Java 层面搞个解析器或者上 V8 之类的研发成本会低一些，而且性能也不错。

IoT 方面也是一个不错的选择，不过我还在观望。

其它方面就是客户端的东西，例如 Electron，NW.js 等，的确会降低客户端软件的开发门槛以及研发效率，毕竟样式什么的直接上 HTML + CSS 了，这个方法比较好，以前就有人这么用了，以前就是 qt 也用了类似的方法。我一直期待会有一个内置 Node.js 的无线终端引擎，而不是 React Native 之类的，也许是因为相较于他们现在的引擎 Node.js 还比较笨重吧。

包括 Cocos2d 之类的也一样，不知道为什么就是不基于 Node.js，可能是那边的开发者不在一个领域，大家都不 care 里面有什么，生态里面能做什么，只要是能写 JavaScript 就够了。

最近在写一个桌面的 2D 游戏引擎的 Node.js 玩具 Wrapper，就想验证一下自己的想法，Node.js 也可以写游戏，而不只能是基于别的运行时的 JavaScript。

Wrapper 在 GitHub 的私有仓库。而 github.com/XadillaX/no… 这个是更小的一个仓库，用于验证通过 Node.js C++ 扩展能搞这么一个 Wrapper 的正确性的小 Demo。

未来如果真有这么一个引擎了，我感觉开发游戏起来会更方便吧，不过这只是我的个人业余爱好而已。

本期 AMA 小故事

死月对于海报只有文字版和真人上镜无卡通形象版本很执念，最后我问他要照片无果，他劝说我上卡通版失败，文字版海报上线…

旁白：这期嘉宾是一个简介都在秀恩爱的人。

下一个会被弃用的框架会是哪个？ -- 来自@长大之后我就成了你

前阵子 github 弃用了 jquery，我想问下你觉得下一个会被弃用的框架会是哪个？

phodal 回复

要预测下一个被弃用的框架很难。但是像 GitHub 这种弃用，不代表 jQuery 被弃用。GitHub 是一个面向开发者的网站，他们对于浏览器的兼容性要求没有那么高，可以轻松使用各种新的 HTML 5 API。并且对于那些不是单页面应用的前端项目来说，jQuery 实现上更能满足他们的需求——修改下颜色，做做动画。jQuery 可以用在非 SPA 应用上，基本上很难被完全弃用。

而现有前端应用的变革——新的框架都替换了旧的框架，多数是在开发 SPA 应用上。从这个角度来看，就会发现过去的 SPA 框架，如 Backbone、Mustache 都处于一个被弃用的阶段上。

本期 AMA 小故事

请当 phodal 当嘉宾的时候原想让大家学习下撩妹和恋爱之道，万万没想到，他也是个以买买买为最终手段的人

旁白：我男神:heart:。

正确的参与开源项目的姿势是什么呢？--来自@DateBro

我是一名大二学生，想问一下尤大，计算机领域的内容那么多，前端，后端，移动开发，机器学习。。。您是如何在确立好兴趣方向后做出个人发展的规划的呢？正确的参与开源项目的姿势是什么呢？:eyes:

尤雨溪回复

我的路线可能对你参考价值一般，因为我是学艺术和设计出身，所以很自然的首先接触了和用户打交道的前端，最感兴趣的也是前端。对你自己来说，感兴趣，有热情是最重要的。是做出令人愉悦的交互让你更有成就感呢，还是提升算法准确度，增加转化率数据呢，又或者是设计出一个吞吐量巨大的后端系统呢？只有找到最能给你带来成就感的那个方向，才最有可能做出成就，也最值得去钻研。

至于参与开源，这是一个比较大的话题，所以只能概括地说说。

首先，要避免以一种商家／用户的关系去看待开源，而是以一种共同利益去思考，也就是把自己放在维护者的角度去想，什么样的贡献对于这个项目是有益的。

其次，报 bug 的时候，一定要留意项目对 bug 的格式要求。很多开发者有个不好的习惯就是报 bug 的时候把错误堆栈甚至是截图一丢就算是报 bug 了，但维护者修 bug 需要了解 bug 产生的根本原因，没有一个真正的重现，很多信息根本不可能猜得到。而来回询问需要浪费非常多的时间，对于大项目来说，每天都会有十几个 issue，维护者是没有这么多精力一个一个去来回询问的。

最后，关于贡献代码。遇到举手之劳的错误，直接开 PR 会更好，但如果要做较大的改动，则应该注意先和维护者沟通，并且一定要说清楚自己的场景、用例，为什么需要做这样的改动，为什么需要这样的功能。有些时候，一些开发者觉得我辛辛苦苦贡献了一个 PR 你居然不要，觉得不爽，这样的情况一般都是缺乏沟通导致的。

本期 AMA 小故事

AMA 为期三天，第一天的时候已经有 100+ 个问题，为了方便尤大回复我对问题进行分类整理文了文档给他，最后他还是自己把所有问题筛选了回答了部分问题， 尤大真的很 Nice，对事超认真。

旁白：jjc 大大认识挺久了，大家对他的争议挺大，但个人觉得 jjc 大大还是有技术傍身可以来交流一番的。

如何阅读有些枯燥的技术书籍？--来自@人民币玩家

阅读一些逐渐深入的书籍，如何有效处理长篇大论枯燥难寻。

justjavac 回复

停下来，思考一下，玩会游戏，然后继续。给自己定个目标，一次读 20-30 分钟，硬着头皮读，然后思考 10 分钟。我用这种方式，花了3个月的时间并行读完了爱因斯坦的《相对论》和 Harari 的《人类简史》，然后整理了 200 多页的笔记和草稿。

也有一部分原因是生活和工作压力太多了，让很多人有了焦虑感。当读书读不进去时，就增增加了自己的挫败感，最终形成的恶性循环。尤其是随着年龄的增加，接受新事物新观念新知识也变得越来越难。

我上大学时，从图书馆借了 2 本 Martin Fowler 的《重构》，一本英文原版，一本中文翻译版。两本书对照着看，大概用了不到一个月的时间吧，就把英文版读完了。

工作后，就只能利用每天的早起时间读书了。再后来我和老婆定了一个家庭读书日，每月选出一个周末，这天一起看书 4 个小时以上。如果再加上选书、布置环境、营造氛围什么的，基本上得耗费一天的时间。

阅读是一种习惯，坚持下来就行

再补充一句，其实仪式感也很重要，突然就觉得读书变得很神圣了

再再补充一句，找个女朋友，一起学习更有动力

本期 AMA 小故事

海报做出来的时候感觉 jjc 大大太黑，问他要不要美白下，他说原本如此。 真是个实诚的 boy

旁白：线下大会见过德来师兄，是一个非常有范的人。

如何走上技术管理岗位？ --来自@liutao

「因为走管理线路的缘故，我现在极少参与 Coding。我是工作了四五年后想清楚自己的发展方向的」请问可以分享一下这块的的思考吗？

施德来回复

我对自己的技术还是蛮自信的，好歹科班出身，浙大计算机学院毕业：），但我发现如果做纯技术，我另外一部分的能力比较难发挥，有点浪费了。比如我有不错的销售能力、不错的商业思维、我能很好地把一个东西用人话归纳清楚、能写让人耐心读下去的文章无论是不是技术的、很能发现问题（无论是不是技术类的，也无论是不是前端范畴）、比较有领导特质，等等吧，自吹自擂结束，至少我自己是这么想的吧，所以就朝这个方向做了。

本期 AMA 小故事

邀请德来师兄的时候被拒绝了很多次，最后和他说可以顺便招人 成功

旁白：天猪一直活在我的朋友圈（认识个妹纸经常提及他的 Nice 点），当邀请当嘉宾却不是找人搭线认识的，具体过程见小故事。

点评下 nest，说说您或者 egg 团队对他的看法？--来自@鲸吃瓜

请问天猪大哥能否简单的点评下 nest，说说您或者 egg 团队对他的看法，以及他的优缺点

天猪回复

nest 是近年来新出的一个框架，比较亮眼的是 TypeScript 和从 Spring 过来的一些概念。

从我们的角度来看，企业级应用有很多要素，包括编程模型约束、扩展点、多进程管理、日志、安全、RPC 等等非常多的方面，TypeScript 静态类型带来的好处，是其中的一小点，但并不是全部。装饰器等特性，目前还在 Stage 阶段，并没有落地到 Node LTS 版本中。在我们看来，静态类型带来的好处，还不如把单元测试覆盖率做上去更实际。

TypeScript 也并不是某个框架独有的，就像蚂蚁凤蝶团队就有在用 TS 开发 Egg 应用（听说他们做了个 tegg 框架，后面也许会放出来）。

顺便重提下框架对比，从我们的角度看来，框架有三层：

• 基础框架：Express，Koa
• 框架的框架：Egg
• 上层业务框架：tegg，chair，sofa-node，ThinkJS，Sails，Loopback，Nest

它们的定位：

• 微框架专注于底层中间件模型，是 Node HTTP 之上很薄的一层。
• 上层业务框架，是针对某个领域和业务场景定制的业务框架，针对团队自身的业务场景和技术选型下的组合。（当然也有一些大教堂式的大而全框架）
• 上层业务框架一般每个团队都会封装一个，就像当年阿里各大 BU 那样，而 Egg 就定位介于前面两者之间，抽象出上层框架的一些共性 -- 一套加载规范，一方面提供插件能力来复用，一方面提供框架定制能力供团队架构师定制自己的上层业务框架。

本期 AMA 小故事

天猪是第一个我在 GitHub 找邮箱联系上并成功成为 AMA 嘉宾的人

docker 并不能完全将资源隔离起来，如何保证安全性？--来自@buheshuicat

docker并不能完全将资源隔离起来，如何保证安全性？

有明回复

Docker 的安全可以从几个角度出发去考虑：

1. 隔离安全，也就是依靠 Docker 实现隔离的 Namespace、CGroup 等机制实现安全隔离。
2. 内核能力限制，即通过限制 Docker 容器及其中应用对内核敏感功能的使用，来达到防范风险的目的。
3. 服务器安全防护，这和普通的服务器防护原则是一致的，也就是设立防火墙，使用证书保护，应用非 root 运行等方式来限制外部攻击。
4. 设立安全机制，通过像 AppArmor、SELinux 这样的安全策略或安全软件来增强内核本身的安全性。

本期 AMA 小故事

本期 AMA 是我见过最实在的一期，基本上都围绕着 Docker 展开技术提问，如果你对 Docker 感兴趣也可以去围观学习下

怎样快速提高自己的 css 能力？--来自@zuishiguang

魔法哥，有什么推荐的国外技术社区、论坛和博客，在现在 js 框架横行天下的今天，js逻辑写的比较多，css 写的较少，怎样快速提高自己的 css 能力？

CSS魔法回复

第一个问题：有什么推荐的国外技术社区、论坛和博客？

因精力有限，我现在基本不会直接阅读国外网站了。不过我找到一些可订阅的人工聚合的日报，我就坐享其成了。要相信这一点：好文章或重要的信息肯定会来找你。

可订阅的信息源有：

• 众成翻译zcfy.cc/
• 博客周报 github.com/qiwihui/git…
• 前端日报 github.com/kujian/fron…
• 云谦早报 github.com/sorrycc/zao…

第二个问题：在现在 JS 框架横行天下的今天，JS 逻辑写的比较多，CSS 写的较少。怎样快速提高自己的 CSS 能力？

为什么现在是 JS 框架横行天下，而不是 CSS 框架横行天下？这在某种程度上说明 CSS 在现阶段没那么重要。对于普通前端开发者来说，我建议顺势而为。除非你在大企业里专职开发 Element UI 或 AntDesign，否则不建议投入大量时间只为提升 CSS 能力。（参见我在下面某个问题下的回复。）

另外，我们得面对一个残酷的现实：CSS 能力无法快速提高。因为 CSS 是一个网状系统，所有概念都不是孤立存在的，无法单点突破，不像 JS 那样学会一个 API 就可以用上一个 API。因此我们对 CSS 的掌控能力一定是一个从量变到质变的过程。想要突破那个临界点，需要投入大量的精力和成本。而这个成本投入是否划算，是需要考量的。

本期 AMA 小故事

魔法哥这期海报做到了 2 点，期间魔法哥一直在线和我沟通海报，o.o 虽然最后勉强能用，但是具体到面部还是有些不自然。

旁白：一直潜水在耗子姐姐的「前端的那些破事」群里，他是个非常活泼的人。没想到他的经历如此的不同，具体可以看看他的 AMA 自我介绍。

网管-印刷工-喷绘机修理工-前端，可以分享下如何走上编程这条路？ --来自@清蒸不是水煮

网管-印刷工-喷绘机修理工-前端，可以分享下如何走上编程这条路，以及编程上对你影响最大的人是谁吗？

:mouse:耗子回复

网管-印刷工-喷绘机修理工-前端，可以分享下如何走上编程这条路，以及编程上对你影响最大的人是谁吗？

或许你会觉得我要发鸡汤，但可能我发的会是毒鸡汤。希望每个人看到我的回答后都能找到自己的成长之路。

我高中时学习不好，很长一段时间陷入到自暴自弃的状态，也因此没有拿到好的文凭，以至于找工作的时候处处碰壁。 很早的时候就对 web 开发兴趣浓厚。从最早的个人主页制作、QQ 空间特效代码、到之后的管理运营 BBS、博客群。积累了一些前后端开发的知识。

我做得最对的事可能是逃离二三线城市，挤进北上广吧。在技术领域内，只有一线和超一线城市，才会汇集最多的产业资源。包括公司、人才和技术。

我只能说赶上了一个前端高速发展的时代，受惠于行业带来的红利。但是，这样的红利期已经在迅速减弱，目前应界生想去一家好公司的难度已经比从前门槛高太多。

过去十年时间，整个行业向浏览器应用、移动端转型，产生的一些新兴技术领域，企业对前端、Android、iOS 等工种需求强烈，但这些领域大家都缺少技术经验，企业不得不降低招聘要求，有个笑话不是说某企业要招 10 年以上 iOS 工作经验嘛。

目前对于上述提到的领域，同样水涨船高，因为这些领域技术趋近于成熟，发展也在放缓，所以并不是前人走过的路后人可以复刻。

可见的未来，比较稀缺的技术工种一定是在人工智能、大数据、虚拟/增强/混合现实、区块链（不是炒币，那只是很小的一块）等领域。但也可以看出，学习门槛也越来越高。

对我影响最大的人，其实有很多。经历的几家公司的领导都非常有魅力，给过我很多指导。只要用心，每个人身上都会有你值得学习的地方。

综上所述，总结几点：

1. 选择好的城市比选择学校和专业更重要
2. 欠缺的知识一定要抽时间补上
3. 不要等一个技术滥大街了再开始了解，那时候已经缺少稀缺性
4. 要相信正态分布和回归平均，幸运不是常态，不幸也不是常态。不是只要奋斗就一定有收获，但不努力一定没有收获。
5. 相信顶端优势、马太效应和 80/20定律，资源总是向头部倾斜，并且强者越强
6. 三人行心有我师，见贤思齐，见不贤而改之

本期 AMA 小故事

耗子姐姐的 AMA 本来是第八期上线的，后来咕咕了我，再后来双十一，好在最后上线了

OB 是如何实现智能运维？--来自@吃提子不吐葡萄籽

终于来了个运维大佬，我之前读过你们的技术文章，某篇文章提到过智能运维的概念，可以具体地讲一讲 OB 是如何实现智能运维的吗？

庆涛回复

【智能运维】是理想，可以无限接近。现实中更多体现为自动化运维，彼此自动化程度上不一样。我这里就说【自动化运维】方面的。

运维最基础的功能就是监控和告警。OB 内部性能指标非常丰富（不比 Oracle 的性能指标少），这为运维提供了很丰富的素材（信息）。告警的目的是提前发现异常，【异常】的定义取决于业务要求和运维人员经验。以前是靠为监控指标定义范围或者波动范围去识别异常，近几年可以通过机器学习去识别以查。 个人认为理论上不会有一个统一的标准能适应所有的业务，机器学习也是一门不确定性技术。所以【漏报】和【误报】永远是运维人员的痛。

数据库告警问题如果是资源相关，有两个处理思路，都可以自动化做。

一是优化 SQL，降低 SQL 对 CPU /内存的消耗。自动获取 DB 运行的所有 SQL，并及时分析其执行计划，应用 DBA 的经验和相关运行时性能数据，程序自动初步判断 SQL 是否有性能问题，并给出初步的索引优化建议，这个是 SQL 自动优化的方向。准确率不会太高，但是只要高于绝大部分研发人员水平，在数据库规模很大的公司内，这个是自动化诊断对研发和运维都是很有意义的。OB 的所有 SQL 都可以计入审计，有详细的运行时性能数据。这是源材料。怎么加工发挥就是运维产品的水平了。

二是资源扩容或迁移，提升数据库享用的资源或者数据库迁移到压力很小的主机上。云数据库就是在资源管理方面做的比较好。RDS 的 mysql 和 sqlserver 都是这个思路。不过这个数据迁移是靠运维产品用数据库自身的备份恢复技术去做（搭建级联备库，然后切换应用的数据库连接等）。OB 在这方面做的自动化程度非常高。OB 是支持多租户管理。资源有集群和租户两个维度。租户是提供给业务的实例。租户资源不足就对租户扩容，一个命令瞬间完成，前提是集群资源有余量；集群资源不足就加机器，也是一个命令。扩容命令结束后会引起租户以及内部Unit的负载均衡（详情请关注 OB 微信公众号，看历史文章【负载均衡】）。均衡操作会有数据重分布动作，都是OB内部异步完成，不依赖外部运维产品，不用担心数据不一致，不用担心中间出现异常或可用性故障等。当然，决策是否扩容目前还是运维人员判断的。原因也一样，没有一个统一的标准适合所有的业务场景，还是人把关比较靠谱。

【监控】-【告警】-【处理】-【反馈】。当形成闭环后，这个自动化的运维产品的价值就体现了。反馈就是能跟踪 SQL 在【处理】之后的改进情况。这还是要依赖数据库的性能指标和 SQL 的运行时信息等。这个反馈也是对开发做的处理的正向反馈，让他知道应用的性能状况，优化状况，知道哪里做的好哪里做的不好，数据库开发设计方面的能力也得到提升。

本期 AMA 小故事

感觉好像大家对运维、数据库方便并不是很感冒，这期的 AMA 有些冷清，:persevere:有些小难过对不起认真回答问题的庆涛。

旁白：本期有个美国故事小专题

有哪些计算机基础知识让你觉得在工作中依然能够受益 --来自@2014_

有哪些计算机基础知识让你觉得在工作中依然能够受益，希望能够推荐几本书

黄玄回复

这是这次 AMA 里我最喜欢的一道问题 ;)

关于「基础」、「成长」、「深入」的问题很多同学都在问，我想直接在这个回答下面总结一下我自己的感想。

「在特定领域内工作与学习」可以被认为是一种 Top-down （从技术栈的应用层向更下）或者说 Just-in-time 的学习方式，很多非科班前端（或者任何觉得基础不够用的时候）的学习路径可能都会是比如

• 「JS -> JS 中存在的编程语言特性与模式」
• 「JS Callback -> EventLoop -> 并发模型」
• 「JS -> Babal +| V8 -> 编译原理、编程语言运行时/虚拟机」
• 「React + Redux/Flux -> Immutability/FP」
• 「Flow/TS/ReasonML -> 类型系统」
• 「CSS -> 浏览器渲染引擎 -> 图形学」
• 「Ajax -> HTTP -> TCP/QUIC -> 计算机网络」
• 「实时通讯 -> Web Socket -> Socket」
• 「写 UI -> 写更好的 UI -> UX（用户体验）」 这样的路径。这种方式是不可缺少并且在很多时候更加快速实用得，但这种方式可能会由于对「共性更强的基础知识」的欠缺比较容易出现「觉得永远都在跟进新东西」的感觉，并且缺乏「创新」所需要的视野。

我在「如何取舍一些技术」里提过：无论使用的是什么技术，往根上走必然会走到一个更高的抽象层面，这个时候所有「变化的表象」就 merge 成了「更不变的基础」。（这里请想象一颗树，根是最 generic/abstract 的基础（你也可以理解成基类或者类型理论里的 Top type，比如 OO 语言中的 Object），越往叶子节点是越 specific/derived 的技术（你可以理解为派生类）

而「CS 基础的学习」相比之下则更像一种 Bottom-up（以技术栈比喻）或者说 Ahead-of-time 的学习方式，你可以从一种「更高层次抽象」的方式去理解新技术，并且更容易「子类型化」出新的东西。

React 从架构上来说，其实是越来越接近一个编程语言虚拟机的，而从 设计模式 来说，是越来越接近 Haskell/OCaml 这样的函数式编程语言。这些都不是「原有的前端领域内知识」可能自然演化出来的。 这也从另一个侧面回答了为什么中国很多技术团队创新能力不如国际团队，即使只限定在前端框架领域，大部分在技术模型上有突破性的框架也都来自国际团队：Knockout/Rx 来自微软，React 来自 FB，Angular 来自 Google…

所以很多同学问的如何「基础」和「前端有什么深入的方向」也都可以从这个角度来回答，比如说我相对了解比较多的「编程语言」领域，「哪一门语言对前端未来发展或是学习上有很大帮助」？

从 JavaScript 来说，JavaScript 是一门比较杂交的语言，其发明与发展过程一直到目前为止也主要是「借鉴」其他语言的特性。这些特性通常在「原有的上下文」下有着更好的表达，另外大部分这些特性技术（OOP、FP、类型、运行时）本身的或学术或业界的发展也都是贡献在这些语言而非 JS。所以说「基础」可以是「学习 JS 发明与发展中过往或正在借鉴的语言」，「深入」可以是「了解这些语言的发展、了解 TC 39 的动向、了解未来可能影响 JS 去向的语言、影响或贡献 JS 语言的发展」等。 举例来说：

• Scheme 作为 JS 的最主要本源之一，学习 scheme 或类似的 Lisp 方言会让你对 lambda 算子、first-class function、CPS、closure 这些函数式编程概念有更纯粹的理解，并对这些概念在 JS 中的运用有更本质的理解。
• Java/python 或类似的 class-based OO 语言会让你对 ES6 以及未来 ES 的 class、field、property、（private、static）有帮助；
• Java/OCaml/Haskell...等任何一门强类型语言会让你理解「类型有什么作用」、「类型安全是什么」对 TypeScript/Flow/Reason 的各种概念和设计有同样帮助；（比如让你更容易理解 subtying、variance、只读只写的关系等）
• Rust/Swift/Kotlin/OCaml/Haskell 等尝试用某种静态分析机制约束异常（比如 option type 或 checked exception）、异步（比如 Promise、async/await）等「效果」的编程语言能让你对 JS 的未来、或是 React 这样的框架 API 设计有帮助；
• Rust/C++ 能让你对一切跟指针和内存有关的概念有无可替代的帮助；
• 学习任何一种与 JS Event Loop 不同的并发（或更好的支持可能的并行）模型的语言会让你对「同步异步」、线程进程、阻塞非阻塞有超过「能理解他们的字面意思和比喻」的理解…对 Web Worker、Sharedworker、sharedbuffer 这些 Web API 有帮助；
• 学习 assembly、JVM bytecode、stack machine 会对 web assembly 有帮助；
• 学习任何一门编译到 JS 的语言都会让你对 JS 「有什么缺陷」这件事有帮助； ……

在「你是如何在前端领域下沉淀下来的？学习心得是什么？」说过得这里就不重复了，前端的复合性体现在他对众多计算机科学（和其他学科）领域都有依赖，而不是说「层展现象」就完全替代计算机科学的基础作用了……

我自身读过的书并不足以推荐太多书籍，但是参考美国大学的课程教材（也就是那些知名大学教授编写的经典书籍）绝对足矣。比如 编程语言相关的 SICP、TAPL、PAPL、Software Foundation、虎书、龙书… 计算机网络的 Top-down approach 体系结构的 CSAPP ……

这些教材都是「大部头」，相比于大多「行业内的 工具 书」要严肃严谨得多，并且有大量「习题」，可以说能啃下来任何一本的任何一个章节都会有一种「被刷新」的感觉。 除了书籍之外，如果希望对某个领域有非常理论化或前沿、试验性的了解，可以尝试观看、阅读学术会议与期刊的 presentation 与论文，其实很多都非常有趣。

以上。

本期 AMA 小故事

小故事挺多的，AMA 文中也说了，另外个小故事就是，这期 AMA 的图片我很努力的抠最后还是一个不及格，被黄同学微博 diss 了，摊手

旁白：严格意义上，这是 19 年的 AMA，但是只有这一期没上本文怪冷清的…本期有个 997 小专题

关于客户端网络层的优化，有哪几个地方可以切入？ --来自@J_Knight_

您好，请问一下关于客户端网络层的优化，有哪几个地方可以切入？而且在监控网络性能方面有哪些实践可以分享一下嘛？

凝睇回复

几个方向可以先搞起来，首先是用长链接代替短链接，增加链接的复用率，减少每次请求的时间，然后数据的序列化方式可以用 PB，再则进一步可以自定义传送协议，本地 dns (通过一定的策略下发 ip 列表)减少 dns 解析耗时和报错，更细的可一些动态建联策略，并发建连，1rtt 这种

监控方面，主要还是靠客户端埋点日志，上传到服务器上做大数据分析

本期 AMA 小故事

凝睇的技术非常的厉害，见 【开篇 | mPaaS 服务端核心组件体系概述】 却没能和大家进行非常好的技术交流，有些小难过，当然已经反思出解决方案了:persevere:怪对不住凝睇的。

2019 年的 AMA

:tada::tada:，19 年的 AMA 暂时排期到了 4 月份，大家如果有啥想清蒸邀请来做客的可以和我说。

• vol 17: 《React 状态管理与同构实战》作者--LucasHC （01.22 - 01.24）
• vol 18: SOFA 团队专家 （01.29 - 01.31）
• vol 19：奇舞团--月影（02.26 - 02.28）
• vol 20：《Android 开发艺术探索》作者--任玉刚（03.12 - 03.14）
• vol 21: Omi 框架作者--当耐特（03.26 - 03.28）
• vol 22：《Android 进阶》系列三部曲作者--刘望舒（04.09 - 04.11）

希望 2019 年大家多多在 AMA 下和嘉宾进行技术交流 ^O^/