IT瘾时代推荐

AI造就 “默认为假”的时代 - 太隐

Thu, 19 Mar 2026 08:35:07 CST

本栏目《隐说》由原《棱镜通讯》分离而来，《隐说》主要聚焦于我近期读的一些好书、好文章、好的付费栏目、日常思考等等，其中有摘录、点评、扩展。

1、“默认为假”的时代

随着 AI 技术的发展，网上的垃圾信息会指数级增加，虚假信息会越来越真伪难辨。所以，我们要建立起一个概念：任何信息默认都是假的，除非有理由相信是真的。 —— tombkeeper（信息安全专家，现任腾讯玄武实验室负责人）

太隐识:

过去信息匮乏，大部分人看到消息会先选择相信，毕竟能传播出来的内容，多少经过了筛选。但AI时代不一样了。一篇假新闻、一张假图片、一段假视频，几秒钟就能批量造出来，而且越做越像真的，造假的门槛几乎降到了零。这种情况下，要是还习惯性地“看到就信”，那跟在假货遍地的市场里闭着眼睛买东西没什么区别。我也看到不少人拿豆包这类大模型当标准答案用，但稍微懂点技术原理的人都明白，这个所谓的“标准答案”是可以被人为调整甚至污染的。
所以tombkeeper提出的这个原则，或者说这个观察很有趣，其实是把我们的现在认知的默认值做了一次翻转。有点像笛卡尔在《第一哲学沉思集》里说的，先把一切都当成可疑的，然后再一点一点找到可以确信的东西。以前我们是“先信着，碰到假的再剔除”，现在得反过来，“先存疑，找到证据再接受”。这种感受，做过学术研究的人应该特别有共鸣。

不过这里面也藏着一个隐患，值得留意。

当所有人都对信息失去信任的时候，反而容易滑向另一个极端。人们不是变得更理性了，而是更容易把判断权交给某个“权威”，让别人替自己拿主意。比如汉娜·阿伦特早在《极权主义的起源》里就观察到过这种现象，当一个社会什么都不可信的时候，反而什么都能被人相信。

所以在我看来，“默认为假”只是第一步。在AI时代，真正要紧的还是要坚持养成自己验证信息的习惯，去查源头，去交叉比对，去想想“谁在说、为什么说、对谁有利”。很多AI 的新闻只是表面的雾，关键还是要看透雾后面的东西。

说到底，在这个真假越来越难分的年头，只有自己的脑子才是最靠谱的过滤器。

2、传统好比人体免疫机制

历史学家朱维铮先生在1984年谈过一个关于“传统”的观点，说得很好。他说，“毫无疑问，传统是一种巨大的惰性力量。但也毫无疑问，惰性力量不等于反动力量。我曾把传统比作人体的免疫机制。免疫机制的作用，就在于保护人体功能的稳定、平衡，在正常状态下可以抗御致病菌毒的入侵，否则将使人体处于无抵抗状态。如今仍令群医束手的艾滋病，就属于综合免疫功能缺乏症。然而，当人体处于疾病状态，需要输入健康血液或者移植健康器官，那时如何克服自身免疫机制对于异体的抗拒排斥功能，则又使群医为难。作为一种惰性力量，传统犹如免疫机制，属于社会的特定功能，本身无所谓好或坏，无所谓精华与糟粕；至于它起的作用是好是坏，需要发扬还是需要抛弃，问题也不在于它本身，而在于社会是否健康，或者患了哪种疾病。这就是我说的现状。”

到了1990年，朱维铮先生对中国传统又有一段更具体的论述。他认为，中国社会在20世纪至少有三种传统并存。一是清中叶之前定型的本土文化传统；二是西方资本主义入侵后形成的西学传统；三是20年代"以俄为师"之后出现的苏化传统。在整个20世纪上半叶，这三种传统既相互碰撞、摩擦、猜疑、忌恨，也相互熟悉、容忍、吸取、同化，但始终没有完成整合。它们各自在不同层面、不同层次起作用，各有各的生存范围。如果承认这个历史事实，那么本土文化传统自辛亥革命后逐渐退出政治层面，又在五四运动后逐渐沉入更低的文化层次，也就是一个合乎逻辑的进程了。

3、可以入道

外息诸缘，内心无喘，心如墙壁，可以入道。—— 《少室六门》

太隐识:

《法句经》有句讲“犹如善盖屋，雨水不渗漏；心若善修习，贪欲不漏入”，外息诸缘告诉我们要做减法，内心无喘告诉我们要停止内耗，心如墙壁告诉我们要培养自己坚定的内心，这样才能看清生命的实相，走上觉悟的道路。

4、言语道断

信心不二，不二信心。言语道断，非去来今。 —— 《信心铭》

太隐识:

《信心铭》是禅宗三祖僧璨大师所著，全文五百八十多字，这两句出自结尾，也是最广为人知的。
什么意思呢？

真正的“信”，绝不是盲目崇拜，而是亲身验证后的毫无怀疑。就像你亲口尝到了熟透的芒果，真真切切知道它是甜的。那一刻你和这种“甜味”合而为一，内心再无动摇，再无猜测，这就是“不二”的含义。

“言语道断”说的则是语言的局限，举个例子，无论你用多少华丽的词藻，也没法向一个天生的盲人讲清阳光的明媚是怎样的。因为语言只是指路的木牌，真理才是那条路，当你真的踏上了，木牌就不重要了。这句我特别喜欢，总让我想到维特根斯坦那句“对于不可说的东西我们必须保持沉默”，两者在语言的边界上的确达到了某种契合，不过僧璨讲的是本体论，维特根斯坦指向的是认识论。

最后，“非去来今”讲的则是，真正的平静与解脱不在过去，也不在未来。它不是你死后才能去的地方，而是此刻放下执着，当下就能体会的境界。真理一直都在那里，不生不灭，不随时间流转而改变。

5、王夫之谈史

汉、唐之亡，皆自亡也。宋亡，则举黄帝、尧、舜以来道法相传之天下而亡之也。是岂徒徽、钦以降之多败德，蔡、秦、贾、史之挟奸私，遂至于斯哉？其所繇来者渐矣。 —— 王夫之

太隐识:

王夫之把中国历史上的王朝覆灭分成了两种性质完全不同的类型。在他看来，汉朝和唐朝的灭亡是“自亡”，意思是王朝内部腐朽、权臣割据、秩序瓦解，但文明的根基还在。政权更替之后，继承者仍然延续着华夏的道统与制度传统。汉亡之后有魏晋，唐亡之后有五代入宋，文明的脉络虽经曲折，但并未断裂。
而宋朝的灭亡，在王夫之看来，性质完全不同。他说这是把从黄帝、尧、舜以来“道法相传”的整个天下都给亡了，也就是这导致中华文明直接崩塌了。蒙元入主之后，儒家士大夫政治的传统、华夏礼乐制度的延续，都受到了根本性的冲击。

王夫之对宋朝制度上的缺陷评判是有一定道理的，“其所繇来者渐矣”这个判断尤其精到，直接把历史分析从道德批判拉到了结构分析的层面，在明清之际的思想家中确实难得。

不过，他说宋亡是把“道法相传之天下”都亡了，我不太认同。这个二分法的确草率了些。元朝虽然在很多方面改变了宋代的制度，但儒学并没有消亡，科举在中断一段时间后也恢复了。士人阶层的地位虽有下降，却仍然存在，也仍在发挥文化传承的作用。赵复、许衡等北方儒者在元代延续了理学传统，南方的文人群体也并未完全消散。到了明朝建立，宋代的许多制度和文化传统又被重新接续。所以与其说文明断裂了，不如说是经历了一次剧烈的震荡和变形。

我想，王夫之之所以下这样的判断，恐怕和他自身的经历脱不开关系。他亲历了明朝灭亡，对“华夷之辨”有着极为坚定的态度，笔下对“夷”的痛恨自然是格外强烈。带着这层切身之痛回望宋元之变，难免把判断推得更极端了一些。

6、毛泽东与《三垂冈》

英雄立马起沙陀，奈此朱梁跋扈何。只手难扶唐社稷，连城犹拥晋山河。

风云帐下奇儿在，鼓角灯前老泪多。萧瑟三垂冈下路，至今人唱《百年歌》。
— 清人严遂成《三垂冈》

太隐识:

毛泽东非常喜欢这首诗，曾多次亲笔手书。诗写的是晚唐沙陀族军阀李克用的故事。李克用一生与朱温争锋，虽忠于唐室，却终究"只手难扶唐社稷"，壮志未酬，老泪纵横。而全诗最妙的转折在颈联，"风云帐下奇儿在"，帐下那个"奇儿"，便是后来灭掉后梁、建立后唐的李存勖。
这首诗的历史背景是三垂冈之会。据《旧五代史》记载，李克用在三垂冈宴饮，伶人奏起《百年歌》，歌至衰老之段，李克用望着年仅五岁的李存勖，不禁感慨流涕。然而年幼的李存勖却毫无怯意，意气昂然。李克用拍着他的背说"此子类我"，认定他日后必成大器。后来李存勖果然在同一个三垂冈大破后梁军队，应验了父亲当年的期许。

毛泽东反复抄写这首诗，我想不只是欣赏诗本身，更是因为诗中的内核与他的历史观高度契合。英雄的事业，从来不是一代人能够完成的。李克用没能亲手灭梁，但他留下了基业，留下了意志，更留下了那个“奇儿”。一代人做一代人的事，前人栽树，后人收果，这才是历史真正的运转方式。

7、王阳明没说过“父母即佛，心外无佛”

读了韩毓海老师的《重读毛泽东》，文笔很流畅，但其中错误不少。比如第一章“地才”中引用王阳明一句话，“父母即佛，心外无佛”。这句其实并非王阳明所说。王阳明的核心主张是“心外无物”“心外无理”，从未以佛来立论。“父母即佛”这种说法，应该是后人将阳明心学与佛家孝亲思想揉在一起的产物。

不过说到佛家孝亲思想，倒可以顺带聊几句。佛家其实非常重视孝道，比如《大乘本生心地观经》中说，若子女背恩不孝，令父母心生怨念，母亲发出恶言，子女便随之堕落。经中又将父母恩列为四重恩之首，还有一个很有名的说法，“堪事父母者，即是堪事佛”，意思是能真心侍奉父母的人，就等同于在供养佛。

不过话说回来，不管是阳明心学还是佛家孝亲，讲的内核其实相通，都是在说莫向外求，近处即是道场。

8、

亡国论者看敌人如神物，看自己如草芥，速胜论者看敌人如草芥，看自己如神物，这些都是错误的。
— 毛泽东《论持久战》

太隐识:

人在面对重大困难与挑战的时候，常会陷入极端的二元对立。一种是因恐惧而滋生的悲观主义，另一种是因自大而催生的盲目乐观。前者把对手看成不可战胜的神物，后者把自己看成无所不能的神物，但本质上都是同一种症状，就是丧失了对客观现实的判断力。
这段话的本意并不是简单地取一个“中间值”，因为折中主义本身也是一种思维上的偷懒。真正要坚持的，是以事实为基础、以辩证法为工具的认识方法。亡国论者只看到敌强我弱的一面，速胜论者只看到我方优势的一面，而毛泽东看到的是全面。既看到敌人的强，也看到强中之弱；既看到自己的弱，也看到弱中之强。这种思维方式，与克劳塞维茨在《战争论》中反复强调的精神相通，在信息不完备、情绪最容易失控的极端环境下，谁能保持认知上的清醒，谁就掌握了真正的战略主动权。

这种思维放到当下同样适用。在任何博弈中，无论是国与国之间，还是个人所面对的困境，既不神化对手，也不轻视对手，既不妄自菲薄，也不盲目自大，这才是制定正确战略的前提。说到底，只有先认清现实，才有资格去改变现实。有句话说得好，认清现实是勇气，改变现实是能力，而连接这两者的是理性。

9、洗脚注意事项

去年的时候给父母买了个智能泡脚桶，的确很好用，但是泡脚这个事有些常识，还需要多加注意。

一是水温不要超过 40° 以上；

二是泡脚时间要控制在 15-20 分钟；

三是饭后一小时后再洗脚；

四是泡脚时候添加药材，不要一股脑乱放，要查一下是否适合自己。

简单来说，泡脚并不是温度越高越好，也不是泡得越久越好。现在市面上很多智能泡脚桶，时间能设到40分钟，温度能调到50度以上，这就过头了，不但没有好处，反而会伤身体。

另外特别提醒，有严重心脑血管疾病或糖尿病的人，泡脚时一定要格外小心，温度和时间都要比常人更保守，否则容易加重病情。

教育模式转变：AI时代的顶层学习法

Tue, 20 Jan 2026 23:04:14 CST

【学习的范式转变：AI时代的顶层学习法】

你接受的传统教育模式，本质上是为教师的便利而设计的，而非为学习者优化。这套体系可能让你浪费了数年时间。

AI已经彻底打破了学习的门槛。你不再需要“许可”去学习新领域，你需要的是“动机”和正确的方法。

+ 传统模式的根本问题

传统的自下而上学习法强迫你花费数月钻研那些你并不确定是否需要的基础知识。想学机器学习？先学数学。想学深度学习？先学Python。你必须在每一层“交够学费”才能进入下一层。

在学校里情况更糟。老师几乎不会解释为什么你要花整整一学期学某门课。很多时候这也怪不得他们，因为确实没有充分的理由。

这种模式存在的原因很简单：过去的学习资源默认你具备某种程度的前置知识。十年前你拿起一本深度学习的书，它假设你已经掌握了必要的数学和编程能力。作者不愿意从零开始讲起，所以学A之前必须先学B、C、D。

这是为教师的便利优化的，不是为学习者。

问题在于，自下而上的学习效率极低。你花了几个月甚至几年积累知识，却看不到明确的应用场景。等你终于接触到真正的问题时，你已经忘了一半。

+ 顶层学习法：从问题出发

与之相反的是自上而下的学习。你从一个真正感兴趣的实际问题开始，边做边学，撞墙了再去补相应的基础知识。

这种方法过去几乎不可能大规模实现。你需要一个专家随时在旁边指导你缺少哪些基础，告诉你该往哪个方向学习。学术界对此一直不太认可。

但现在，这个约束不存在了。

那个原本不存在的专家，现在每个人只需花20美元订阅ChatGPT或Claude就能获得。它虽然不完美，但已经足够好，足以从根本上改变谁能学什么、能学多快。

Gabriel Petersson就是一个活生生的例子。他是瑞典小镇的高中辍学生，想弄懂视频AI模型的工作原理。他让ChatGPT解释基础概念并写出扩散模型的代码，一开始完全看不懂，就不断追问：“这部分是做什么的？”“用12岁小孩能懂的话解释一下”“画个图给我看”。

他每天这样问上百次，递归式地填补知识空白。几年后，他被OpenAI录用参与Sora项目，做着传统上需要博士学位的工作。

+ 一项没人教你的元技能

顶层学习有一个前提：你必须能够识别自己什么时候不理解某个东西。

这听起来简单，其实不然。

面对陌生概念时，大多数人要么假装理解继续往下走，要么沮丧放弃。很少有人能坦然面对自己的困惑，搞清楚究竟是哪里不懂，然后提出精准的问题。

这就是“知道自己不知道什么”的元技能。困惑其实是一个信号，意味着你即将学到新东西。真正的顿悟只会在你直面不理解的不适感时发生。

+ 保持控制权

整个过程的核心是你必须保持主动权。你不需要另一个传统老师来决定你该学什么、怎么学、学到什么程度算够。

关键在于能够从AI那里提取你想要的东西。大多数人在这方面做得很糟糕。

AI天生倾向于迎合普通用户。如果你只是简单地问“用简单的话解释强化学习”，你得到的只是一段通用的教科书式回答。

你应该这样问：我想学强化学习。告诉我它为什么存在，解决什么问题，之前的替代方案是什么。我知道智能体通过行动获得奖励，但我不理解它具体是怎么学会哪些行动是好的。在连续的10个动作中，它怎么知道是哪个导致了奖励？用直觉化的方式讲解背后的数学，像对12岁孩子说话那样，并给我一个具体的例子。

精确、具体地表达你想要什么，不要把主动权交给别人。这是一项你会逐渐精进的技能。

+ 两种使用AI的模式

第一种是把AI当作劳动力替代品。“帮我写一篇文章”、“帮我做作业”、“帮我写代码”。短期看这或许有好处，但长期会削弱你的思考能力。把思考、困惑和脑力劳动都外包给AI，最终会让你的认知能力退化。

第二种是把AI当作学习导师。这才是产生超常结果的方式。这种模式的意义在于压缩从困惑到清晰的时间。

+ 递归下降学习法

具体框架如下：

第零步：理解为什么。在任何解释和定义之前，你必须真正理解所学内容的起源。它为什么存在？解决什么问题？实际用在哪里？之前的替代方案是什么？

第一步：从问题而非课程开始。不要问AI“学强化学习该学什么”，而是问“我可以用强化学习做什么项目？然后帮我写代码。”

第二步：让它运行起来。运行代码，观察结果，看可视化效果。如果是一个使用RL智能体的Python游戏，去玩它。

第三步：回讲（费曼技巧）。当你开始阅读代码并理解各个部分时，把你的理解解释给AI听，问它你的理解是否正确。这一步至关重要。

第四步：递归下降。在反复对话中完善理解后，问AI“这个概念依赖哪些基础知识？”然后对那些基础重复整个过程。

第五步：泛化。当你深入理解了某个东西，问“它还能解决哪些问题？有什么局限性？在情况X下我会怎么做？”这一步帮你填补空白。

+ 这个方法不能解决的问题

AI无法给你行动力。如果你需要有人拿着鞭子逼你学习，你需要解决的是比“如何学习”更根本的问题。

AI无法教你品味。知道如何构建一个RL智能体，和知道哪些问题值得解决、哪些方法是优雅的、哪些代码是可维护的，这是不同的事情。这些属于人类特有的判断力。

AI可能自信地犯错。所以你需要结合YouTube视频、论文、书籍、博客等人类创作的资源来验证和补充。

你仍然需要付出努力。跳过不必要的基础知识，不是为了少干活，而是为了把精力用在正确的地方。AI消除的是摩擦，不是工作本身。

+ 分化正在发生

我认为接下来五年会出现这样的分化：训练自己用递归下降方式学习的人，将成为唯一能够高效学习、跟上科技飞速发展步伐的群体。而坚持传统方法、拒绝与AI协作学习的人，会逐渐变得无关紧要。不是因为那些方法不管用，而是因为他们的速度无法与前者竞争。

x.com/Hesamation/status/2013044418228498468

成为超级个体：AI时代的研发人员编程技巧最佳实践 - Phodal | Phodal - A Growth Engineer

Sun, 27 Oct 2024 10:12:53 CST

Posted by: Phodal HuangOct. 26, 2024, 2:31 p.m.

随着AI技术在软件开发中的普及，开发人员的角色正在从单一技术专家逐渐转向“超级个体”——即具备跨界、创新和自我迭代能力的多面手。生成式AI不仅简化了传统开发流程，更通过不断迭代的反馈机制让开发人员掌握新技术栈、快速适应需求变化，并能将复杂的业务知识融入代码。本文结合生成式AI的实践场景，解析如何高效运用AI辅助工具并适应技术转型。

1. 生成式AI的能力与局限性

生成式AI工具，例如GitHub的Copilot，通过学习和理解代码片段生成代码或提供自动补全，显著提升了开发速度。例如，开发人员只需描述想要的功能，AI便可以生成初始代码，甚至包括架构和代码结构。然而，生成式AI的效果参差不齐，并非所有代码都符合项目需求。在GitHub的案例中，Copilot生成的代码的平均接受率为30%左右，主要原因在于AI生成的代码质量不一，有时会生成冗余代码或错误的逻辑，甚至出现“幻觉”代码（无依据的内容），这增加了代码审查的负担。

AI 体验的“曲折”过程

在实际操作中，生成式AI工具的使用体验并非一帆风顺。开发人员在首次接触时，通常会因AI生成的代码质量问题和提示词调试过程所困扰。尽管如此，通过反复迭代提示词和适应AI的特定模式，开发人员可以逐渐掌握生成式AI的应用，从而在实践中有效发挥AI的优势。

然而，生成式AI在实际应用中也面临诸多限制，包括：

上下文不完整：生成内容缺乏上下文，特别是在业务逻辑复杂的情况下，往往需要开发者进行额外的修改和调试。
生成质量不稳定：生成内容可能包含冗余信息或“幻觉”（hallucinations），如生成与需求无关的代码或错误的逻辑。
工具链不完善：现有工具在生成内容质量、与现有IDE集成等方面仍有改进空间。例如，生成代码后还需在IDE中手动进行优化和测试，影响流畅度。

2. AI辅助编程工具的实用技巧

为充分发挥AI辅助编程工具的效果，开发人员需要掌握一些实用的技巧，以便有效运用AI生成的代码和提示。AI辅助编程的三种主要模式为：

聊天模式：通过与AI进行多轮对话，开发人员可以从需求分析到代码示例、架构设计等方面获取全面支持。工具如GitHub Copilot Chat、Genie等允许用户通过自然语言输入获得上下文相关的代码块和最佳实践。
伴随模式：伴随模式工具如JetBrains AI Assistant或AutoDev，支持在开发过程中生成实时建议，包括错误分析、提交信息生成和文档撰写。这样开发人员可以在代码编辑时获得即时反馈，提升编程效率。
实时模式：在编码过程中提供自动完成、错误检测和代码优化建议等，如自动化地识别并修复代码中的潜在错误。这种方式确保了编码的实时反馈，减少了开发过程中的反复修改。

如何构建有效的提示词

构建高质量提示词是提升AI生成代码质量的关键。好的提示词应该包括明确的上下文信息、需求描述和预期输出格式。在复杂需求场景中，开发人员可以通过分步提问，将需求拆分为具体的子任务。比如，如果需要生成一个面向API的提交信息，除了代码片段差异信息，还可以增加描述性内容，使提交信息更符合规范。

不同的AI工具在不同的场景下需要不同的提示词策略。例如，在Copilot中，注释、函数名称和代码片段都是提示词的一部分，而在聊天模式下则需要明确地提出背景、需求和输出形式，以避免生成不符合预期的代码。

3. 融入软件工程实践，降低校验成本

在生成式AI辅助下的开发流程中，生成内容的校验与验证成为重要一环。传统的软件工程校验方法仍然适用于AI生成的代码，以确保代码符合业务逻辑并降低验证成本。以下是几种常见的校验策略：

自动化测试：通过单元测试、集成测试、接口测试等方法验证生成代码的准确性。例如在API开发过程中，可以使用RestAssured生成API测试，或通过WireMock模拟服务请求，以此来验证生成代码的稳定性和正确性。
黑盒测试：通过测试输入和输出，而无需关注代码的具体实现，确保生成的功能模块符合预期。例如在界面开发中，可以通过UI测试验证按钮交互和数据渲染效果。
运行时反馈：在IDE中构建实时反馈机制，结合代码生成平台和云端智能体（如Dify智能体）减少工具间的切换，从而实时校验生成内容是否符合业务需求。

通过这些方法，开发者不仅能快速校验生成内容，还能在验证过程中积累反馈数据，帮助AI不断改进生成质量。

4. 重构开发流程：加速产出，优化知识转化

AI辅助编程带来了重构开发流程的机会，通过更流畅的资产生成与知识转化机制，可以大幅提升产出质量。在软件开发生命周期中，许多隐性知识如业务需求、架构设计等，往往会影响开发过程的效率。在AI的帮助下，这些知识可以系统化地转化为显性资产：

知识积累与转化：将业务逻辑、架构知识转化为规范文档或代码模板，为团队中的新成员提供了学习和上手的便利。例如，开发人员可以将API设计规范和测试用例以模板形式保存，通过AI辅助的提示在新项目中复用。
流程自动化：整合API开发工具链，通过自动生成API规范、测试用例和前端代码，使开发流程中的每个步骤都紧密相连，减少人为干预。例如，在前端代码开发中，通过AI生成与后端服务对接的API，避免手动集成可能导致的错误。
实时反馈机制：构建反馈闭环，通过自动化测试和性能测试结果及时反哺开发过程。例如，通过Apache Benchmark或Gatling进行性能测试，生成性能分析报告并反馈至开发阶段，提升生成代码的实际运行效果。

这种知识转化和流程优化不仅减少了开发过程中的冗余工作，还能显著提高团队整体的响应速度。

5. 面向未来：适应技能变化，放大专业能力

AI辅助编程已成为开发人员扩展专业能力的利器，但未来的竞争力还需要建立在持续适应技能变化的基础上。AI可以提升开发效率，但设计思维、结构化思维和任务分解能力仍然是高效开发的核心。

重新定义技能框架：生成式AI工具促使开发人员重新评估自己的技能架构。通过不断学习和适应，开发人员可以掌握从需求分析到系统设计的全面知识，同时熟练掌握如何与AI工具互动，最大化AI对开发工作的促进作用。
构建专业上下文：AI工具生成内容的质量依赖于上下文的完整性。开发者可以通过精炼的上下文表达（如注释、函数命名等），确保AI理解需求，提高生成质量。例如，通过在任务中详细描述业务需求和技术背景，使生成内容更贴近实际需求。
快速验证与适应AI流：未来的开发人员需要具备快速验证AI内容的专业能力。特别是在需求迭代和验证过程中，开发者应能够灵活应用AI生成的代码，通过实践优化生成的代码段，以提高AI生成内容的专业性和适用性。

结语

AI时代的研发人员已不再仅仅是“执行者”，而是通过AI赋能，掌握全栈开发和跨界思维的“超级个体”。借助生成式AI工具，开发者能够在高效生成代码的同时，保证生成内容的质量，并通过自动化测试和反馈闭环不断优化工作流程。通过在实际项目中不断应用和改进AI辅助策略，未来的开发者将能够充分发挥AI的潜力，持续提升软件开发的整体效率和产品质量。

面向GPT-4编程的时代来了：Github Copilot大升级，首次集成聊天功能

Thu, 23 Mar 2023 23:10:52 CST

从今天开始，面向 GPT-4 编程。

面向 GPT-4 编程，程序员们终于等到了这一天。

作为 Copilot 代码补全工具的升级，GitHub 刚刚宣布了 Copilot X 计划，正式接入 GPT-4，并放出了一系列全新功能。

Copilot X 搭建了一种以代码为中心的聊天模式。升级后的 Copilot 在整个开发生命周期中均可应用，而不仅仅是代码补全。通过整合聊天和语音功能，开发人员可以更自然地与 Copilot 进行交流。此外，Copilot X 将集成到拉取请求、命令行和文档中，为有关项目的问题提供即时答案。

毫不意外，新功能是由 OpenAI 的 GPT-4 驱动的。但出于延迟的原因，来自 GPT-3 的代码补全工具仍然在 GitHub Codex 模型之中。

GitHub Copilot 推出至今还不到两年，已经对软件开发领域产生了颠覆性的影响。据 GitHub 调查报告显示，这款基于 OpenAI Codex 模型构建的 AI 工具，目前已编写了该平台上 46% 的代码，帮助开发人员将编码速度提高了 55%。通过自动完成 comments 和代码，Copilot 能够作为程序员的 AI 助手，让开发人员保持专注和高效。

Copilot X 的诞生，同样延续了这一愿景。让我们来具体看看最新的功能。

Copilot X 功能展示

Copilot X 在开发者体验中添加了聊天功能「Copilot Chat」。Copilot Chat 建立在 OpenAI 和微软在 ChatGPT 和新 Bing 上所做的工作之上。它不仅仅是一个聊天窗口，还可以识别开发人员键入的代码、显示错误消息，并将其嵌入到 IDE 中。开发人员可以深入分析和解释代码块的用途，生成单元测试，甚至获得针对错误的建议修复。

Copilot Chat 不仅仅是将 ChatGPT 带入 IDE，同时也将 IDE 的上下文带入了 ChatGPT。GitHub 至少通过一些巧妙的 prompt 工程实现了这一点，在 prompt 中尽可能多地加入了上下文。今天推出预览版的 Copilot Chat 将在 Visual Studio 和 VS Code 中提供，晚些将支持其他 IDE。

当然，你也可以要求 Copilot Chat 为你写代码。

「它带回了编程本身的乐趣，因为你不必找到一个教程，也不必弄清楚哪一个是正确的教程，你只需继续下去，」Dohmke 说。「我确信，当你让学生和孩子们使用时，他们会大吃一惊。它变成了一种令人上瘾的工具，因为你有一个可以不断提问的东西。」

Copilot Chat 只专注于编程问题，如果用户提问了与编程无关的事项，它将迅速关闭任何不相关的内容。

GitHub CEO Thomas Dohmke 认为，虽然自动补全功能已经让开发者大大提高了生产力，但这一新升级的 Copilot 功能将使开发者的生产力提高 10 倍。

终端是开发人员花费最多时间的地方，即使是最熟练的开发人员也需要滚动浏览许多页面才能记住许多命令的准确语法。作为整体 Copilot X 计划的一部分，GitHub 也将 Copilot 带到了命令行。Copilot CLI 可以组合命令和循环，并通过模糊的查找标志来满足用户的查询。

与 Warp 在终端上所做的类似，GitHub 会帮助开发者编写命令和循环，并找到那些晦涩难懂的特征标志，这些标志往往深藏在手册中（或至少要在 Stack Overflow 上搜索一两次）。

此外，开发人员现在还可以申请参与「Copilot for Pull Requests」的技术预览，该功能可以生成拉取请求的描述并自动标记。这项新功能由 OpenAI 的新 GPT-4 模型提供支持。

Copilot for Pull Requests 减少了样板文件和手动任务，开发人员可以专注于更复杂和更具创新性的工作。毕竟很少有人喜欢模板，这是一项无聊、琐碎的工作，无论是在代码层还是拉取请求层。

同时，GitHub 还在准备一项新功能：如果开发人员缺少足够的拉取请求测试，Copilot 会自动发出警告，然后建议根据项目需要编辑、接受或拒绝的潜在测试。

「Copilot for doc」的功能也是刚刚推出的。Github 计划将该功能引入任何组织的存储库和内部文档，因此开发人员可以通过类似 ChatGPT 的界面提问并获得即时答复。

不过，ChatGPT 数据库的截止日期是 2021 年，这意味着这些信息并不总是最新的，GitHub 正在用更多的最新数据来充实它，类似于微软的 Bing 用其 Prometheus 模型为搜索所做的那样。

可以想象的是，当你在每个应用程序中都拥有一个 Copilot，无论是 Outlook、Word 还是代码编辑器中，这意味着你都可以利用所有在这些环境中写的东西，也可以利用组织中其他工作人员的信息。

某种意义上来看，它消除了公司中长久以来存在的「孤岛」。从开发人员到营销人员，所有人现在可以更轻松地写出公告博文，因为他们在 Copilot 中可以直接看到开发人员放在 git repo 中的发布说明。这或许就是将释放 10 倍以上潜在生产力的机会。

开发效率的大幅提升，你准备好迎接了吗？

参考链接：https://github.blog/2023-03-22-github-copilot-x-the-ai-powered-developer-experience/

大数据时代下，如何识别垃圾信息？

Tue, 16 Aug 2022 14:14:24 CST

编辑导语：大数据时代之下，信息繁杂多样，其中也充斥着大量的假话和谬论。怎么在纷繁复杂的信息里面，去伪存真，需要我们有一定的思辨能力，去识别信息中的垃圾信息。而如何识别辨别这些垃圾信息呢？本篇文章分析了如何识别垃圾信息的方法，感兴趣的话一起来看看吧。

短视频、短信息时代蒸蒸日上，改变了公众话语的内容和意义，政治、宗教、教育、体育、商业和任何其他公共领域的内容，都日渐以“短娱乐”的方式出现，并成为一种文化习惯。

但是这些容易传播的短视频、短信息，大量充斥着假话和谬论。

基思·斯坦诺维奇说，伪科学的传播所造成的代价是巨大的。怎么在纷繁复杂的信息里面，去伪存真，帮助自己解读判断，需要我们有一定的思辨能力，去识别信息中的垃圾信息。

一、如何识别垃圾信息？

1. 大话、空话；让人不知所云

在表达中使用一堆假大空的词汇，每个词你都认识，组合在一起也仿佛说得都对，但是就是不知道对方在说什么。比如各种黑话指南：

2016年：资本寒冬、护城河、上半场、下半场、brief、知识付费、赛道、黑科技、网红、闭环。
2017年：赋能、边界、共享经济、消费升级、新物种、互联网金融、ICO、区块链。
2018-2019 年：打法、优化、下沉、社交电商、壁垒、流量池、组合拳、心智。
2020-至今：抓手、Web 3，去中心化、底层逻辑、第一曲线、第二曲线。

并不是说只要有这些词汇，就是垃圾信息。而是表达者通过一顿组合，让你不知道所云，只有空话的，肯定是垃圾信息。比如：

这次 Campaign 我们要以价格为抓手，横向打通品类覆盖，还要提高内容可复制性，注重投放颗粒度，覆盖消费升级到下沉市场的全域流量，发力打出一套组合拳。

看完之后，一脸问号，他在说啥？

向飙说：“社会生活里有很多问题都是老问题，一定要把老问题吃透。不要制造新的词汇，没有太大的意思”。

2. 缺失的信息

之前文章《如何正确读数和更优决策》，讲了一个关于缺失数据做决策的故事。赛车队成员需要决定是否要参与一场重要的比赛。依据之前的经验，24 场比赛中有 7 场汽车引擎出现故障，故障情况和天气温度之间的关系如下图：

图片来源于《成长边界》

团队里面大部分人的判断都是要参赛。但是当我们把缺失的比赛数据补齐时，我们看到：

图片来源于《成长边界》

40华氏度引擎出问题的概率很高，参赛的结果可想而知。赛车队故事背后是 NASA 真实的案例。1986 年，在一次火箭发射事件中，NASA 的高层基于部分数据，对于密封火箭助推器一个连接处的 O 型圈失效可能性做出了判断。最终结果是，剧烈燃烧的气体直接从连接处冲向外部，“挑战者号”在升空 73 秒后就爆炸了，7 位宇航员全部丧生。

当有人和你阐明数据和观点的时候，你可以思考以下几个问题：

谁在告诉我这些
他们是如何知道的
这些信息里面还有什么，还有哪些信息没有表露出

3. 错把关联当因果

还有一类经常被大家搞错的是，误把关联关系当作因果关系。

多年前，台湾地区有一个研究表明，家用电器的数量和避孕工具的使用最相关。但是你应该不会有这样的想法，在高中发放免费的烤箱以解决青年早孕的问题。因为这两个变量存在相关，但是没有因果关系。

比如你发现汽车儿童座椅销量变高，同时婴儿出生数量也在变高，是一个正相关的关系。但是不能说，因为儿童座椅销量变高了，所以导致婴儿出生率变高。这是逻辑是谬论。

导致两个变量之间产生误导性关联的第三变量，有时候很容易看出来。比如，冰淇淋卖得越多，溺水就越多。是因为吃冰淇淋的人很多，游泳的人也很多，所以溺水的人才很多。

我们在研究一个现象的时候，会带着自己的预设偏见理解为，两个相关因素是因果关系。而相关关系之所以产生，可能是因为这两个变量都与某个甚至尚未被测量的第三变量相关。

读数据的时候，当我们看到相关关系，需要继续提问或者反思，背后的原因是什么，是否还有其他可能性。

4. 小心平均值和中位数

平均数代表一个样本的平均水平。但是当你在查看平均值的时候要留意，样本里面是否有极值（极大值，极小值这些 outliers），如果有的话，平均值就会不准。此外，如果你的样本小，也容易产生更多极端的值。这个时候用中位数更合适。如下图：

图片来源于 B 站公开课程

5. 正确理解 p 值

什么是 p 值？

我们来说一个故事。假设你是一个律师，现在法官要审判一起杀人案件，而你的辩护人被指认谋杀。但是案发时，你当事人在蛋糕房里面做蛋糕，并不在案发现场。现在你要为他辩护。

庭上法官拿出 DNA 检测报告表明，案发现场凶器上的 DNA 和你当事人 DNA 完全吻合。所以你的当事人才被指认。

作为律师你说，“等一等，法官你确定 DNA 匹配不是巧合？”

法官说，“当然，DNA 匹配概率是百万分之一。你的当事人是凶手无疑。”

你说，“别急，我们来画一个图。百万分之一的可能性表达的是所有人群里面，错误识别的可能性。但是我们这里应该要看的是，识别出来的结果里面，被误识别的可能性。”

图片来源于 B 站公开课程

“虽然对于整体样本来说，检错概率很低，为百万分之一。但是在判断为凶手的结果里，总共 5 个人，只有 1 个是真正的凶手，其他 4 个都是误判，只有 20% 的正确率。没有办法判断我当事人就是凶手。”

这则小故事告诉你不能绝对相信 p 值。因为 p 值不是用来告诉你假设的正确性的。而是用来告诉你，在整个群体中检测错误的可能性有多大。

所以对于一个很低的 p 值，不要认为这事就肯定成立了。

6. 误导性坐标轴（misleading axes ）

数据可视化可以降低看数据的难度，但是在数据以图表的方式呈现出来之后，我们也需要去关注一些细节。因为图表会给出一些诱导性的表达方式，影响我们判断。比如误导性坐标轴（misleading axes ）。

以下图为例，作者给你看的图是这样的，我们会快速认为，yes 和 no 的比例是 5/5 开。但是细看我们会发现，这两个分类左边的 y 轴并不一样，根本不是 5/5 开的关系。

图片来源于 B 站公开课程

7. 操作箱尺寸

图表也可以操控每个箱子的尺寸大小来表达他想要的意思。比如下文是华尔街一篇臭名昭著的报道。这张图乍一看中间部分的 y 值最大。

图片来源于 B 站公开课程

但是当我们放大横坐标的时候仔细一看，会发现，横坐标根本不是等分的。从最开始的每 5k 一个间隔，到后面 5百万一个单位。

图片来源于 B 站公开课程

8. 过度装饰

过度装饰的图被称作 data visulization ducks。ducks 原意是用在建筑领域指过度装饰的建筑。图表也是如此，好的图表不要过度装饰，过度装饰反而会失去了他本来想要表达的内容。因为 ducks 会阻碍信息的交流。

（假新闻 & 过度装饰）图片来源于 B 站公开课程

（画个人形，读数反而变得很困难）图片来源于 B 站公开课程

（视觉注意力都被大汉堡和苏打水抢走了）图片来源于 B 站公开课程

（用嘴型来表达家庭的财务安全度）图片来源于 B 站公开课程

（非要用栅栏表达房屋价格，让人看不懂）图片来源于 B 站公开课程

（过度装饰 & 误导性坐标轴）图片来源于 B 站公开课程

9. 科学的可复制和可重复性

‍你看到的信息能否被复制和重复，这也是结论是否科学的一个重要判断因素。要将一个研究发现认定为确凿的科学事实，它的可重复性至关重要。因为科学理论的一个重要定义就是可证伪性。

可证伪性标准声明，一个理论要有用，对其所做的预测必须是具体的。它在告诉我们哪些事情会发生的同时，必须指出哪些事情不会发生。如果不会发生的事情确实发生了，我们就得到了一个明确的信号，这个理论有问题。

越具体的预测在被证实后，给我们的触动越大。预测越具体，越精确，有可能证伪它的观察现象就越多。

只有当一个理论并不试图预知一切，而是做出具体的预测，提前告诉我们世界上会发生什么具体的事情时，该理论才会进步。

所以伪科学/信息的另外一个特征就是不可证伪。不管怎么解释它，都对的。

这些不可证伪理论有着巨大心理吸引力，其奥秘在于它们解释一切的能力。预先知道无论发生什么，你都能理解它，不仅给你一种掌握知识的感觉，而且更重要的是，给你应对这个世界所需要的情绪上的安全感。

但是这种安全感是以知识发展的停滞为代价的。比如我们常常沉迷的占星、星座解释、通灵术等。

二、最后

Steven Pink 说过：活着好过死亡，健康好过疾病，富足好过匮乏，自由好过胁迫，幸福好过苦难，知识好过迷信和无知。

在这个不确定性极高的后疫情时代，多多提高自己对信息的辨别能力，更好的生活，从驳斥垃圾信息开始。

参考资料：

《大数据时代，如何识别 bullshit》，https://www.bilibili.com/video/BV13E411s74P?spm_id_from=333.337.search-card.all.click

《The social dilemma》2020 on Youtube, https://www.youtube.com/watch?v=rvg0eY_Ls4Y

《成长边界》

《这就是心理学》

作者：圈圈，微信公众号：lovepm

本文由 @圈圈授权发布于运营派。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

广汽曾庆洪：电池占车 60% 的成本，我们在给宁德时代打工

Thu, 21 Jul 2022 18:31:57 CST

IT之家7 月 21 日消息，2022 世界动力电池大会今日在四川宜宾举办，一众车企和动力电池厂的高管在会上对行业现状和未来发展发表了各自的看法。

其中广州汽车集团股份有限公司董事长曾庆洪在会上演讲时表示，动力电池不断升价，其成本已经占到车子成本的 40%-60%。曾庆洪笑称：“ 电池占了我一部车的 60% 成本，那我现在不是给宁德时代打工吗？”

在新能源汽车需求端飞速发展的情况下，对于动力电池原材料一路暴涨这件事，曾庆洪认为动力电池产业链目前除了存在上游价格高企问题外，还存在动力电池回收技术和体系建设不到位等问题。因此曾庆洪建议加强对电池行业的监督领导和统筹协调，改善供需的平衡，协调价格回到合理的区间。

值得一提的是，宁德时代董事长曾毓群也在会上发表了演讲，曾毓群首先提到了公司电池的产品线。2022 年，宁德时代在固态电池、无钴电池、锂空电池、五稀有金属电池、钠电池产业链、凝聚态电池进行布局。在今年上半年，宁德时代全球装机的市场份额占比为 34%，而去年这一数字是 28%。曾毓群称：“ 宁德时代累计动力电池突破 400GWH，平均 3 辆电动车就有一辆宁德时代”。

对于动力电池不断涨价，他表示是上游材料涨价导致电池厂商成本增长，其中碳酸锂、六氟磷酸锂、石油焦等锂电池上游材料均出现价格暴涨。但曾毓群也表示，矿产资源并不是产业发展的瓶颈，已探明的锂资源储量已可以生产 160 TWh 的锂电池，完全足够生产全球需要的动力电池和储能电池， 电池原材料上涨的真正原因是资本炒作。

IT之家了解到，宁德时代 2022 年第一季度报告显示，由于部分上游材料价格快速上涨造成成本增加，公司增收不增利。其中第一季度营收 486.78 亿元，同比增长 153.97%。但净利润仅 14.93 亿元，同比甚至下降了 23.62%。

请暂时抛弃使用 eBPF 取代服务网格和 sidecar 模式的幻想

Sat, 11 Jun 2022 11:08:49 CST

最近 eBPF 技术在云原生社区中持续火热，在我翻译了《什么是 eBPF 》之后，当阅读“云原生环境中的 eBPF”之后就一直在思考 eBPF 在云原生环境中究竟处于什么地位，发挥什么样的作用。当时我评论说“eBPF 开启了上帝视角，可以看到主机上所有的活动，而 sidecar 只能观测到 pod 内的活动，只要搞好进程隔离，基于 eBPF 的 proxy per-node 才是最佳选择”，再看到 William Morgan 的这篇文章 ¹之后，让我恍然大悟。下面节选翻译了文章我比统同意的观点，即 eBPF 无法替代服务网格和 sidecar，感兴趣的读者可以阅读 William 的原文。

什么是 eBPF

在过去，如果你想让应用程序处理网络数据包，那是不可能的。因为应用程序运行在 Linux 用户空间，它是不能直接访问主机的网络缓冲区。缓冲区是由内核管理的，受到内核保护，内核需要确保进程隔离，进程之间不能直接读取对方的网络数据包。正确的做法是，应用程序通过系统调用（syscall）来请求网络数据包信息，这本质上是内核 API 调用——应用程序调用 syscall，内核检查应用程序是否有权限获得其请求的数据包；如果有，就把返回数据包。

有了 eBPF 之后，应用程序不再需要 syscall，数据包不需要在内核空间和用户空间之间来回交互传递。而是我们将代码直接交给内核，让内核自己执行，这样就可以让代码全速运行，效率更高。eBPF 允许应用程序和内核以安全的方式共享内存，eBPF 允许应用程序直接向内核提交代码，目标都是通过超越系统调用的方式来实现性能提升。

eBPF 不是银弹，你不能用 eBPF 运行任意程序，实际上 eBPF 可以做的事情是非常有限的。

eBPF 的局限性

eBPF 的局限性也是因为内核造成的。内核中运行的应用程序应当有自己的租户，这些租户之间会争抢系统的内存、磁盘和网络，内核的职责就是隔离和调度这些应用程序的资源，同时内核还要保护确认应用程序的权限，保护其不被其他程序破坏。

因为我们直接将 eBPF 代码交给内核执行，这绕过了内核安全保护（如 syscall），内核将面临直接的安全风险。为了保护内核，所有 eBPF 程序要想运行都必须先通过一个 验证器。但是要想自动验证程序是很困难的，验证器可能会过度限制程序的功能。比如 eBPF 程序不能是阻塞的，不能有无限循环，不能超过预定的大小；其复杂性也受到限制，验证器会评估所有可能的执行路径，如果 eBPF 程序不能在某些范围内完成，或者不能证明每个循环都有一个退出条件，那么验证器就不会允许该程序运行。有很多应用程序都违反了这些限制，要想将它们作为 eBPF 程序来运行的话，要么重写以满足验证器的需求，要么给内核打补丁，来绕过一些验证（这可能比较困难）。不过随着内核版本的升级，这些验证器也变得更加智能，限制也逐渐变得宽松，也有一些创造性的方法来绕过这些限制。

但总的来说，eBPF 程序能做的事情非常有限。对于一些重量级事件的处理，例如处理全局范围内的 HTTP/2 流量，或者 TLS 握手协商不能在纯 eBPF 环境中完成。充其量，eBPF 可以做其中的一小部分工作，然后调用用户空间应用程序来处理对于 eBPF 来说过于复杂而无法处理的部分。

eBPF 与服务网格的关系

因为上文所述的 eBPF 的各项限制，七层流量仍然需要用户空间的网络代理来完成，eBPF 并不能替代服务网格。eBPF 可以与 CNI（容器网络接口）一起运行，处理三层/四层流量，而服务网格处理七层流量。

每个主机一个代理的模式比 sidecar 更糟

对于每个主机一个代理（per-host）的模式，服务网格的早期实践者 Linkerd 1.x 就是这么用的，笔者也是从那个时候开始关注服务网格，Linkerd 1.x 还使用了 JVM 虚拟机！但是经过 Linkerd 1.x 的用户实践证明，这种模式相对于 sidecar 模式，对于运维和安全来说会更糟糕。

为什么说 sidecar 模式比 per-host 模式更好呢？因为 sidecar 模式有以下几个优势，这是 per-host 模式所不具备的：

代理的资源消耗随着应用程序的负载而变化。随着实例流量的增加，sidecar 会消耗更多的资源，就像应用程序一样。如果应用程序的流量非常小，那么 sidecar 就不需要消耗很多资源。Kubernetes 现有的管理资源消耗的机制，如资源请求和限制以及 OOM kill，都会继续工作。
代理失败的爆炸半径只限于一个 pod。代理失败与应用失败相同，由 Kubernetes 负责处理失败的 pod。
代理维护。例如代理版本的升级，是通过如滚动更新，灰度发布等应用程序本身相同的机制完成的。
安全边界很清楚（而且很小）：在 pod 级别。Sidecar 在应用程序实例的同一安全上下文中运行。它是 pod 的一部分，与应用程序具有一样的 IP 地址。Sidecar 执行策略，并将 mTLS 应用于进出该 pod 的流量，而且它只需要该 pod 的密钥。

而对于 per-host 模式，就没有上述好处了。代理与应用程序 pod 完全解耦，处理主机上所有 pod 的流量，这样会代理各种问题：

代理消耗的资源是高度可变的，这取决于在某个时间点 Kubernetes 调度了多少个 pod 在该主机上。你无法有效的预测特定代理的资源消耗情况，这样代理就有崩溃的风险（原文是这么说的，这点笔者还是存疑的，希望有点读者能解帮忙解释下）。
主机上 pod 之间的流量争抢问题。因为主机上的所有流量都经过同一个代理，如果有一个应用程序 pod 的流量极高，消耗了代理的所有资源，主机上的其他应用程序就有被饿死的危险。
代理的爆炸半径很大，而且是不断变化的。代理的故障和升级现在影响到随机的应用程序集合中的一个随机的 pod 子集，意味着任何故障或维护任务都有难以预测的风险。
使得安全问题更加复杂。以 TLS 为例，主机上的代理必须包含该主机上所有应用程序的密钥，这使得它成为一个新的攻击媒介，容易受到混淆代理问题的影响——代理中的任何 CVE 或漏洞都是潜在的密钥泄露风险。

简而言之，sidecar 模式继续贯彻了容器级别的隔离保护——内核可以在容器级别执行所有安全保护和公平的多租户调度。容器的隔离仍然可以完美的运行，而 per-host 模式却破坏了这一切，重新引入了争抢式的多租户隔离问题。

当然 per-host 也不是一无是处，该模式最大的好处是可以成数量级的减少代理的数量，减少网络跳数，这也就减少了资源消耗和网络延迟。但是与该模式带来的运维和安全性问题相比，这些优势都是次要的。我们也可以通过持续优化 sidecar 来弥补 sidecar 模式在这方面的不足，而 per-host 模式的缺陷确是致命性的。

其实归根结底还是回到了争抢式多租户问题上，那么能否利用现有的内核解决方案，改进一下 per-host 模式中的代理，让其支持多租户呢？比如改造 Envoy 代理，使其支持多租户模式。虽然从理论来说这是可行的，但是工作量巨大，Matt Klein 也觉得不值得这样做 ²，还不如使用容器来实现租户隔离。而且即使让 per-host 模式中的代理支持了多租户，仍然还有爆炸半径和安全问题需要解决。

总结

不管有没有 eBPF，在可预见的未来，服务网格都会基于运行在用户空间的 sidecar 代理（proxyless 模式除外）。Sidecar 模式虽然也有弊端，但它依然是既能保持容器隔离和操作的优势，又能处理云原生网络复杂性的最优方案。eBPF 的能力将来是否会发展到可以处理七层网络流量，从而替代服务网格和 sidecar，也许吧，但那一天可能很遥远。

参考

William Morgan 的 eBPF, sidecars, and the future of the service mesh 这篇文章正好回答了我的关于 eBPF、sidecar 的疑问。 ↩︎
关于 per-host 模式中的代理改造问题，Twitter 上有一个精彩的讨论。 ↩︎

平均三天一出手，宁德时代急眼了？

Sun, 30 Jan 2022 14:10:55 CST

宁德时代正在“扫货”锂电池。

根据不完全统计，近三个月，宁德时代投密集投资了近10家锂电池生产商及供应商，同时也在接连成立新能源科技公司。尤其2022年以来，宁德时代的布局节奏急剧加快，几乎“三天一出手”。

据投中网不完全统计，仅2020年1月，宁德时代至少投资3家企业，成立全资或合资新能源科技／新能源材料／矿业公司至少6家。此外，1月19日，宁德时代还与B站关联公司合开了一家私募公司，做起了GP。

频繁出手背后，与宁德时代在锂电池所面临的愈加复杂的竞争环境不无关系。一方面，宁德时代被曝出重要客户削减供货份额，开展自研并引入新的电池供应商；另一方面，比亚迪、LG新能源等老对手虎视眈眈之外，以中创新航、蜂巢能源为代表的二线动力电池厂商也在加速提升产能，资本市场也在积极“助攻”。

身处“合围之势”，宁德时代正在依靠“买买买”缓解焦虑，试图加固“王”的护城河。

疯狂“扫货”，动作直指锂电池

对于宁德时代这样的万亿巨头而言，做投资这件事本身并不稀奇，怪就怪在“过于频繁”。

自进入2021年以来，宁德时代的出手速度明显加快。据投中网不完全统计，2021年1月至今，宁德时代的对外投资高达39起，数量已接近公司过去几年的投资总和。

除了企业直投，宁德时代还做起了LP，参与投资了多家基金，并以独资和合资的形式成立了多家子公司。

虽然方式不同，但通过梳理不难发现，宁德时代的频繁出手目的十分明确——直指锂电池，在其出手的项目中，有近80%都与锂电池上下游产业链密切相关。

具体来看，在锂电池产业链的上游，宁德时代连续投资了澳大利亚锂钽生产商Pilbara、国内有色金属冶炼公司志存锂业以及非洲矿业勘探企业AVZ Minerals；并与湖北宜化成立合资公司，推动磷化产业转型升级；此外还先后成立了三家与矿产资源开采等相关的全资子公司。

值得一提的是，去年9月，宁德时代还曾“截胡”赣锋锂业，向加拿大锂矿企业千禧锂业抛出3.768亿加元（约合人民币19.43亿元）的收购邀约，虽然该收购最终以失败告终，但足以彰显宁德布局上游的迫切。

至于产业链中游，宁德时代则在磷酸铁锂正极材料领域投资了曲靖麟铁，三元正极材料领域投资了振华新材，还成立了全资子公司屏南时代从事硅碳负极材料研发；电解液领域，宁德时代在去年11月参与了永太高新的战略融资。与此同时，宁德时代还投资了孟腾智能、先导智能、金石能源、恒翼能、鼎阳智能等多家核心设备供应商。

投资是掌控产业链的重要手段。通过投资上述企业，宁德时代可以获得更低的原材料采购成本，更稳定的核心生产设备供应。与此同时，宁德时代也在不断拓宽产业链下游的应用场景。

过去一年里，宁德时代曾先后在新能源汽车制造领域投资了爱驰汽车、极氪汽车、阿维塔科技和哪吒汽车，电池相关领域投资了裕能新能源、哈啰换电、云快充，以及自动驾驶企业嬴彻科技，车规级芯片企业芯驰科技、地平线等。

除此之外，宁德时代还和下游整车企业进行资本绑定，合资成立电池制造公司。数据显示，截至目前，宁德时代已经与北汽新能源、上汽集团等10余家车企合资成立了15家电池制造公司。

不止于此，自去年以来，宁德时代还以LP的身份密集投资了多只基金，主投方向也纷纷指向锂电池产业链的上下游。

疯狂扫货的动作背后，宁德时代的焦虑展露无遗。

“宁王”的内忧外患

宁德时代的焦虑，来自身处“合围之势”的掣肘。

业内有句老话，“一块电池半个车”，动力电池对新能源汽车的重要性不言自明，其产能直接影响了电动汽车的交付。宁德时代作为产业链中最具话语权的一环，在国内市场占有近50%的份额。但对于下游车企来说，没有人愿意变成一个只会“造壳子的公司”，于是主机厂们为了摆脱对宁德时代的依赖，掌控产业链的话语权，正在将“去宁化”提上日程。

据36氪此前报道，宁德时代主要客户之一的小鹏汽车已决定削减宁德时代的供货份额，引入新的电池供应商中创新航；而在与小鹏汽车合作之前，中创新航已经取代宁德时代，成为广汽新能源的第一供应商，此外，宝马也引入了亿纬锂能作为其电池供应商。

除了寻找“二供”，部分车企也开启了自研电池之路。

早在2020年，特斯拉CEO马斯克就曾称，其弗里蒙特的“试验工厂”已开始生产全新的4680电池，2021年底该电池的年产量计划达到10GWh。2021年3月，吉利控股集团旗下吉利科技与赣州市签署动力电池投资合作协议，在赣州建设年产42Gwh动力电池项目，总投资达300亿元。随后3月15日，大众汽车集团也首次向外宣布了未来十年电池版图，根据规划，到2030年其将在欧洲建6家电池工厂，总产能达240GWh。

内有下游车企寻找“Plan B”，外有电池厂商奋起直追。

长期占据全球动力电池装机量第二名的LG新能源于1月27日上市，上市首日市值一度达到可怕的7500亿元，总募资规模达到了680亿元。根据招股书，LG新能源除了部分资金投入研发新品、建立智能工厂，其余将都将用于扩产。按照产能规划来看，2025年LG能源的产能将提升至430GWh。

国内就更“卷”了。比亚迪董事长王传福曾在2021年初指出，2021年将是我国电动车快速发展的元年，行业格局加速调整，百年变革从“春秋时期”，开始进入“战国时代”。

过去很长一段时间，宁德时代重点押注的三元锂电池都占据着绝对优势，但进入2021年后，比亚迪所坚持的磷酸铁锂电池迎来爆发式增长。

根据中国汽车动力电池产业创新联盟日前发布的数据来看，2021年1-12 月，我国动力电池装车量累计 154.5GWh, 同比累计增长 142.8%。其中三元电池装车量累计 74.3GWh, 占总装车量 48.1%，同比累计增长 91.3%；磷酸铁锂电池装车量累计 79.8GWh, 占总装车量 51.7%，同比累计增长 227.4%。

除了比亚迪，国内二线电池厂商也在冒尖。前有“宁王”三年股价翻20倍，新一批电池厂商也在一二级市场获得前所未有的追捧——资本开始密集为其他电池公司提供巨额资金弹药。

国内第三大电池供应商中创新航曾在2021年9月完成120亿元股权融资，并被传出将在港交所IPO的计划，估值约500亿元。

值得注意的是，宁德时代此前上市时的估值尚不足500亿元。

而已在A股上市的亿纬锂能和国轩高科也在过去一年实现股价大幅增长，前者市值已超过1800亿元。长城汽车旗下的蜂巢能源自2021年以来也获得了三轮融资，累计融资超200亿元，计划将在科创板上市。

有了资本的巨大加持，这些企业正在急速扩张。根据统计数据显示，自2021年以来，中创新航、国轩高科、亿纬锂能、蜂巢能源等动力电池企业宣布电池扩建项目超20次，合计投入资金超过了2000亿元，预计新建产能700GWh，约为去年总装车量的7倍。

未雨绸缪，开辟第二战场

虽然群雄环伺，但短期来看，宁德时代的领先地位仍无法被撼动。

根据中国汽车动力电池产业创新联盟日前发布的数据来看，2021年全年，动力电池装车量前10名分别是宁德时代，比亚迪，中创新航，国轩高科，LG 新能源，蜂巢能源，塔菲尔新能源，亿纬锂能，孚能科技，欣旺达，其中宁德时代占比高达52.1%，仍占据国内动力电池领域的半壁江山。

未雨绸缪，“宁王“也在更高一层维度寻找新的增长——切入换电领域，正是宁德时代开辟的“第二战场”。

1月18日，宁德时代全资子公司时代电服宣布推出换电服务品牌EVOGO以及组合换电整体解决方案。据了解，该组合换电整体解决方案由“换电块、快换站、APP”三大产品共同构成。

当下，新能源汽车的能源补给模式主要分为充电与换电两种。与充电桩的大量普及不同，目前国内的换电行业尚是一片蓝海。根据头豹研究院数据显示，2020年我国新能源汽车换电市场规模仅为382亿元，但到2030年，换电市场规模将达到10356亿，十年增长27倍。

与此同时，国家政策也在频频利好换电行业。2020年5月，换电站作为新型基础设施建设的重要组成部分，首次被写入《政府工作报告》；随后换电模式迎来全新的发展局面，2021年政府报告提出要大力发展换电站，支持“车电分离”模式；10月，工信部办公厅印发《关于启动新能源汽车换电模式应用试点工作的通知》，决定在北京、南京、武汉等11个城市启动新能源汽车换电模式应用试点工作。

作为全球最大的动力电池生产商，宁德时代进军换电市场拥有天然优势，也将帮助宁德时代实现从ToB业务向ToC端的切入。根据宁德时代2021年半年报数据，目前，在公司的收入构成中，ToB端的动力电池业务占比最高，约为80%。但更重要的是，换电业务可以进一步提高电池销量，通过统一标准掌握更强的电动车产业链的话语权。

时代电服总经理陈伟峰也曾直言：“锂电行业即将跨如TWh时代。如今全球新能源汽车市场进入了爆发式增长的新阶段，动力电池的需求激增，原材料资源大幅涨价，相比之下规模经济和技术进步带来的降本只是杯水车薪，成本曲线正在掉头向上。”

但现实的是，目前为止，换电领域还没有成功案例，没有企业在这一领域实现商业模式打通，信奉“赌性更坚强”的宁王这次恐怕也要“赌”一把。

华语音乐的最后希望在宝岛，宝岛音乐的希望在年轻的乐团，分享一下我心中那些值得一听的新时代台湾乐团

Mon, 20 Dec 2021 00:00:00 CST

前言

我会避免在标题和正文中使用“小众“、”宝藏乐队“等油腻或者已经开始变得油腻的词语。
本文不会包含落日飞车、告五人、茄子蛋等耳熟能详的乐队。
虽然按专辑分享会显得更懂音乐，但我还是会按单曲来分享。
歌曲评级仅代表我个人的喜欢程度。
部分歌曲名在 spotify 上会有不同，比如《挖掘机》在 spotify 上叫《怪手》。

现在让我们开始分享吧

1 、美秀集团

S 级 ——《米儿》《生活袂晓过》
A 级 —— 《细粒的目睭》《小老婆》《挡一根》《卷烟》《做事人》《马克吐温》

第一次听他们的歌曲可能会觉得这是城乡结合部的杀马特土嗨乐队，而且主唱的发型、长相和嗓音都有点像面筋哥。但是只要你接受了他们的风格，就会发现他们真的很牛逼（面筋哥其实也很牛逼）。

2 、浅堤

S 级 ——《挖掘机》《多崎作》《高雄》
A 级 ——《树影》《月光》《青春咱的梦》《叨位是你的厝》

一个轻快、清新的乐队，刚发了新专辑。听他们的快歌会让你觉得来到了阳光明媚的周六上午。但是轻快的歌曲可能在讲一个沉重的故事。女主唱又写词又作曲又唱歌，声音也很好听。我很喜欢他们的吉他和鼓点。

3 、怕胖团

S 级 —— 《我没有用，没办法给你想要的生活》《后照镜》《想想当初吧》
A 级 —— 《鱼》《月旁月光》《抱歉我不想跟你道歉》
搞怪级 —— 《蚊子妳来咬我啊！我才不怕妳？！！！》《内外夹攻大力丸》

一个台味很浓的台湾乐队（诶，你很机车诶！），爱情 hàn 友情是他们的主要创作主题，三个很明显的元素：很纯粹的悲伤、带了点恶搞的悲伤、带了很多恶搞的快乐。但是有一点我不喜欢，就是他们很执着于《抄你妈的笔记本》这个很不雅的谐音梗（甚至还专门出了一个 2021 版）。查了一下居然是 2007 年就创立的乐队了，虽然已经不年轻了但是我还是想加进来。

4 、热写生

S 级 —— 《爱与胶囊》
A 级 —— 《在船底搔痒》《青元春朗》

说实话他们的歌我听不太懂，歌词看上去很有文化很哲学，歌曲听上去给人的感觉是独一无二的——目前还没有听过风格类似的乐队，即使是故弄玄虚也值得一听。

5 、青虫 aoi

S 级 —— 《我毋是刁故意》《青鸟》《大树公》
A 级 —— 《分手后你才送我生日蛋糕》《简幼》《媠花》

这支乐队大多数歌曲都是闽南语，女主唱的声音很温暖，歌词写得也很棒。擅于讲述亲情，发掘生活中有意义的事物。

6 、当代电影大师

S 级 —— 《那些事情是真的有意思吗》
A 级 —— 《我觉得春天好像要来了》

很装逼的一支乐队，刚发了第一张正式专辑(有 15 首歌)，我觉得最惊艳的还是《那些事情是真的有意思吗》的前半段，词、节奏和鼓点都太强了。

7 、Crispy 脆乐团

S 级 —— 《转圈圈》
A 级 —— 《 Deja Vu 》

他们应该还有其他好听的歌，但是因为我听得不多，难做选择。顺带一提，转圈圈的 MV 拍得很有意思，我是在 youtube 看到那个 MV 才关注他们的。

8 、好乐团 /Goodband

S 级 —— 《我们一样可惜》《我把我的青春给你》
A 级 —— 《他们说我是没有用的年轻人》《蒸发》

一个很丧的乐队，女主唱的假音相当牛逼，他们的歌很悲伤但是很好听，深夜 emo 必备。

IoT物联网时代怎么挣钱？_阿朱=行业趋势+开发管理+架构-CSDN博客

Wed, 08 Sep 2021 07:52:25 CST

元宇宙、全真互联网、数字孪生、CPS、工业互联网、可穿戴设备、智能硬件，现在好多词。

（1）应用场景

场景有很多：

1、智能消费：智能产品、智能家居家电、人可穿戴设备

2、智能交易：智能营销、智能零售商店、智能供应链、智能仓储物流

3、智能生产：智能生产设备、智能安环与消防、智能农业种植养殖

4、智能城市：智能汽车与智能交通、智能能源与智能地下管网、智能建造与智能建筑、智能办公空间

（2）基础技术支撑

我随手画了张图，给大家呈现端-管-边缘-云这四个环节的技术体系。

一、端

1、芯片【核心】：我关注RISC-V开源CPU、FPGA可编程芯片

2、模组：我关注Arduino、树莓派

3、操作系统软件【核心】：我关注Fuchsia、FreeRTOS

4、传感器、摄像头、GPS

5、数据网关硬件【核心】：这是数据集中出口

二、管

1、传输软件【核心】：消息传输中间件

2、传输硬件：5G、通信网关

三、边缘

1、IoT接入平台【核心】：这是数据集中入口

2、时序数据库软件【核心】

四、云

1、智能处理【核心】：AI处理非常有门槛

2、应用开发：快速低代码开发工具

3、数字孪生【核心】：数字孪生仿真可视化。中国人不适应数据解读，挺喜欢数据可视呈现

4、数据存储：大数据湖仓

5、云计算

（3）商业模式

刚才咱们第一节就穷举了许多场景，说明市场还是很广阔的。

但这一定是个系统软硬件集成的解决方案，尤其是各行各业都有各种迥异繁多的传感器和自动化部件，怎么大规模标准化地挣钱，这是个需要精心设计的。

我想了想，可卖的东西可能是以下这些：

一、硬件

1、端上芯片、模组

2、端上数据网关

端上操作系统软件虽然是核心，但只能开源、免费了。

3、边缘IoT接入平台：我不容易想出怎么销售/收费/计价这个东西。我目前能想到的只能是软硬一体机边缘服务器

二、软件

1、管上消息传输中间件软件

2、边缘上时序数据库软件

以上两个软件大家都很常见，按主流模式销售/收费/计费就好。

三、服务

1、AI智能处理服务：这按调用次数来收费是非常惯例的。

四、生态

1、生态硬件解决方案合作

2、硬件集成交付生态：硬件安装、数据接出，都需要服务生态

3、数字孪生可视化开发生态：数字孪生可视化软件这个工具很好，但不如消息传输中间件和时序数据库软件拿来就能用的。所以这肯定要发展生态了。靠生态抽水可能会更佳

4、具体应用开发生态

这都需要生态。不搞生态，根本做不了。

这是在IoT物联网时代，必走的商业模式。

海康威视：形成软件开发方法论，社会经济到了由商业需求拉动的时代

Sat, 29 May 2021 17:56:00 CST

近日，海康威视举行投资者问答会议。

在AI市场机会上，海康认为AI的机遇已经得到行业普遍认同，未来AI成本会持续降低，AI技术在改善产品性能上作用很大，AI算法和大数据等，会带来许多之前想做但做不到的业务机会，也会开拓新玩法，未来会打开更多市场。

在软件投入上，组件化的开发已经是海康确定的软件开发方法论。近几年海康的软件开发环境、管理环境、运维环境的使用都已经成熟，过程更规范、更有效率。未来PaaS、DaaS、SaaS层面都有更多的事情可做，海康各个层次的软件研发管理维护的资源团队都会再进一步加大投入。

海康从可见光走向全光谱，发力多维感知，是作为一家做物联网、大数据的公司必然选择，既然是必然选择就先不考虑产出比。海康预期三年未来市场端变化将非常复杂，对海康靠技术创新的公司将有更多机会。

未来10年，创新业务保持更快增长的确定性较高。

未来几年，三个BG都将有不错发展，受不同因素影响会有阶段快慢。

PBG会受限于地方政府的财政和疫情，但政府项目的数据规模大、应用复杂程度高，会一直是应用高地，也会有新的业务形式；

EBG从长期看比PBG市场更大，社会的经济增长到了更多由商业需求拉动的时代；

SMBG会围绕服务渠道伙伴、工程伙伴，连通线上线下，提高运转效率，改善生态，扩大海康的业务影响力。

尽管未来有诸多不确定性，但海康的销售和研发的费用投入上，必须做两件事：

一事平台的搭建与持续维护，与行业应用不断做新的融合；二是产品，基于创新业务和基础技术开发上的产品。

做企业既要有风险管控能力，也需对保持对机会的追求。

以下是调研全文重要内容，雷锋网作了不改变原意的整理与编辑：

Q：目前AI的应用逐渐落地，公司觉得国内外市场机遇怎么判断？

A：经过过去几年的发展，行业中的玩家已经更加认同，AI是个基础技术，在很多方面都会发挥作用。未来AI的成本还会持续的降低，AI技术在帮助产品性能的优化和改善上帮助是很大的，由此会打开越来越多的市场。

AI的算法和大数据相关的应用，会带来许多以往我们想做但是做不到的业务机会，也开拓更多新技术平台上的新玩法。

国内的应用走得快一些，但很难说用我们在国内锻炼出来的产品和方案直接复制海外市场。海外市场对AI应用的观点不同，AI应用的发展节奏也不同，不同国家和地区之间的发展路径也是不一样的。还是要根据每个国家每个地区的不同需求，来制定不同的产品策略与方案。

Q：算法、数据对业务越来越重要，也看到海康为了适应对算法和数据的开发而在软件开发的方式上不断转型，用组件为基础开发软件已经看到很多成效，未来的软件投入主要是什么层次和方向上的？

A：过去几年海康谈的比较多的是统一软件架构，组件化的开发已经是公司确定的软件开发方法论，也是用来整合各个团队开发资源的基础。

这几年的软件开发环境、管理环境、运维环境的使用也都已经成熟，这些环境能保障软件开发和管理维护的过程更规范，更有效率。

在这些基础能力上，我们也在针对数据和应用做很多工作，做PaaS和DaaS，把PaaS和DaaS4这两层搭起来用起来，现在已经有一些应用和模型基本上成熟了。

SaaS部分海康和伙伴们分工协作，直接面对用户场景做定制开发。随着我们统一软件架构这个整体方法论的成熟，以及方法论之下各种技术工具不断被打磨，我们有了将应用和数据做深做厚的能力，也有了协调更多的软件研发资源，做更大规模开发的能力，未来PaaS、DaaS、SaaS层面都有更多的事情可做，我们的产品会更加丰富，公司各个层次的软件研发管理维护的资源团队会再进一步加大投入。

Q：年报中判断未来三年是机遇期，也提到了海康正在从可见光走向全光谱，请问从可见光走向非可见光的部分，公司要怎么投入，能带来多少回报？

A：非可见光在场景中最重要的作用在于，在某些场景下，某种感知方式可以发挥不可替代的作用，比可见光会更加有效，即使只在整体方案中占不多的比例，但作为补充会非常有价值。

对于投入和回报，在初始阶段我们对产出不是特别关心，早期也不知道会做成怎么样。只是觉得对海康来说作为一家做物联网、大数据的公司，多维感知是我们必然的一个选择，既然是必然选择就先不考虑产出，效果交给时间。

未来三年我们预期市场端的变化将是非常复杂的，包括逆全球化的趋势、上游供给侧的变革，会带来很多产业的结构发生深刻的变化。未来几年，尤其是像我们这样靠技术创新发展的公司来说，应该有更好的机遇。

Q：如果未来三年是海康的一个大发展阶段的话，三个BG和创新业务的收入占比会是一个什么样的分布？

A：创新业务整体来说占比还小，但是我们的创新业务很聚焦，可以和海康在技术能力、客户资源、产业链配合上有很强的协同效应，所以创新业务在下一个10年中保持更快的增长都是确定性比较高的。

未来几年，三个BG都会有不错的发展，但是受到某些因素的影响，会出现阶段性的有快有慢，会不一样。

PBG在过去2年多的时间里受限于地方政府的财政状况，今天疫情之下政府也在继续为企业降低负担，也在削减自身的财政收入，但是政府项目的数据规模大，应用复杂程度高，会一直是应用的高地，也会不断有新业务形式发展出来，带动公司的进化。

从长期发展来看，EBG应该比PBG要大一些，社会也到了经济增长更多的由商业需求拉动的时代。SMBG方面我们会围绕服务渠道伙伴、工程伙伴做更多的工作，连通线上线下，让我们生态里的行业从业者更专业、更规范的开展工作，也用互联网后台的建设和管理帮他们提升运转效率，通过他们扩大海康的业务影响力。

Q：海康的费用率从季度环比看是往下走的，在销售费用和研发费用的投入上接下来是什么节奏？

A：未来还有很多不确定性，我们肯定会做很多事情。

一是平台搭建，还需要不断的维护，更多的行业应用会起来，会有一些新的融合；

二是产品，包括在创新业务、在基础技术开发上面，未来可能都会有大的变化。

在当前国内大循环和国际双循环的大环境下，中国和美国在高科技上的投入态势会和过去20年有很大的差别，中国的科技产业的地缘分布结构可能会有很大的调整。

我们相信在包括半导体、高科技、材料、基础算法等很多方面，中国企业在未来10年、15年会有很大的发展空间，这是我们看到的机遇，也要抓住这个机遇，保持相当的投入力度。费用率未来还是会继续往上走，我们做企业既要对风险有能力管控，也要对机会保持追求。雷锋网雷锋网雷锋网

云原生时代 - 知乎

Sat, 20 Mar 2021 15:00:21 CST

今天我们不讲行业和商业，讲讲2019年最热的概念-云原生（Cloud Native）。

我认为云原生是未来10年IT发展最重要的趋势，但是它涵盖的概念非常多，需要花很多时间研究，同时浩如烟海的资料分散在网络上各个地方，缺乏系统性的梳理。今年2月我在基金内部做过一个分享，今日成文，希望让更多的人有所了解。

本文试图解答：

• 为什么云原生概念具有革命性？

• 什么是微服务？

• 微服务和中台的关系

• 容器和微服务为什么是最佳搭档？

• 容器化与虚拟化的区别

• API管理与API集成的区别

• Kubernetes是做什么用的？

• 开源软件商业化遇到的典型问题是什么？

• 等等

涉及到的概念包括云原生、DevOps、持续集成、持续交付、持续部署、微服务、API管理、iPaaS、Service Mesh、Serverless、容器、Docker、Kubernetes等等，我争取用比较形象和通俗的方式把这些技术概念讲清楚。

本文内容较多，共分为六个章节。

第一部分云原生及CNCF基金会

第二部分 DevOps与CI/CD

第三部分微服务、API管理与集成

第四部分容器与Docker

第五部分 Kubernetes与容器编排之战

第六部分思考与机会

第一部分——云原生及CNCF基金会

从集装箱革命说起

有一本非常有名的书，叫《集装箱改变世界》，说的是看起来平淡无奇的铁箱子，如何从二十世纪起永久性的改变了这个世界，并促进了全球化和全球分工。集装箱的出现和发展是实体货物包装、运输、交付方式的一次革命。

" width="360">

《经济学家》杂志曾经评价说“没有集装箱，不可能有全球化”。集装箱为什么具有革命性？

经济全球化的基础就是现代运输体系,而一个高度 自动化、低成本和低复杂性的货物运输系统的核心就是集装箱。集装箱最大的成功在于其产品的标准化及由此建立的一整套运输体系。能够让一个载重几十吨的庞然大物实现标准化，并且以此为基础逐步实现全球范围内的船舶、港口、航线、公路、中转站、桥梁、隧道、多试联运相配套的物流系统，这的确堪称人类有史以来创造的伟大奇迹之一，而撬动这个系统的理念就是 标准化和系统化。

改变世界的不仅仅是集装箱本身，还有 一整套货物处理的新方法，包括港口、货船、起重机、卡车，还有发货人的自身操作方式等。

" width="549">

云原生在IT领域的意义非常类似于集装箱，只是里面装载的不再是实体货物，而是虚拟世界的二进制代码和软件。我们将在介绍完众多概念之后再来对应解释。

云原生的诞生

随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。

" width="872">云原生的发展史，来自CNCF基金会执行董事Dan Kohn

云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。

云原生（Cloud Native）这个概念，是由Pivotal的Matt Stine于2013年首次提出，他还在2015年出版了《Migrating to Cloud-Native Application Architectures（迁移到云原生架构）》一书。

" width="1080">

Gartner提到云原生的定义尚不明确，但含义丰富。云原生对于不同的人和组织来讲，有着不同的理解。众多顶级技术的铸造者、Matt Stine的东家Pivotal 如此定义云原生。

“Cloud native is an approach to building and running applications that fully exploit the advantages of the cloud computing model.”--云原生是一种构建和运行充分利用云计算模型优势的应用程序的方法。

CNCF云原生计算基金会如此定义云原生：

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”

" width="424">

其中服务网格和声明式API是新加入的内容，而不可变基础设施指的是应用的基础设施应是不可变的，是一个自包含、自描述可以完全在不同环境中迁移的东西，容器技术正是这一理念实现的基石。

而CNCF同时把云原生计算定义为：

“Cloud native computing uses an open source software stack to be:
Containerized. Each part (applications, processes, etc) is packaged in its own container. This facilitates reproducibility, transparency, and resource isolation.
Dynamically orchestrated. Containers are actively scheduled and managed to optimize resource utilization.
Microservices-oriented. Applications are segmented into microservices. This significantly increases the overall agility and maintainability of applications.”
——云原生计算使用的开源技术栈包括：
容器化。每个部分（应用、流程等等）都打包在自己的容器中，这有助于提升复用性、透明度以及改善资源隔离。
动态编排。容器受到有效的调度和管理，以便优化资源利用。
以微服务为导向。应用被分割到不同的微服务中，这种分割可以显著的提高应用的整体敏捷性和可维护性。

我个人理解， 云原生是指从云的原生应用角度出发，一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。

下表列举了云原生应用和传统应用的有哪些主要区别。

" width="783">

要转向云原生应用需要以新的云原生方法开展工作，云原生有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。

" width="757">云原生的发展脉络

云原生背后的价值主张有哪些？

• 隔离性：把应用程序打包在容器中加快了代码和组件的重用，并且简化了操作；

• 无锁定：开源软件栈支持在任何公共或私有云上或以组合方式进行部署；

• 无限扩展：为能够扩展到数万个自修复多租户节点的现代分布式系统环境而优化；

• 灵活性和可维护性：将应用程序拆分为具有明确描述的依赖关系的微服务；

• 提高效率和资源利用率：动态管理和调度微服务的中央编排流程降低了与维护和操作相关的成本；

• 应用的弹性：以应对单个容器甚至数据中心的故障，以及不同级别的需求

2019年，Gartner曾经发布报告表示云原生时代已经到来，在未来三年中将有75%的全球化企业将在生产中使用容器化的应用。

请注意，云原生相关技术不仅仅能用于云计算，即便是和云计算即对立又协同的边缘计算，微服务、容器、Kubernetes依然是事实上的杀手应用和标准。如由著名的Kubernetes管理平台创业公司Rancher所贡献的K3s项目，就是Kubernetes（K8s）的最轻量级版本，以满足边缘计算和IOT环境中，在x86、ARM64和ARMv7处理器上运行小型、易于管理的Kubernetes集群日益增长的需求。

云原生计算基金会CNCF

提到云原生，就不能不介绍云原生计算基金会CNCF（Cloud Native Computing Foundation）。CNCF于2015 年7月由Google 牵头成立，隶属于 Linux 基金会，初衷是围绕云原生服务云计算，致力于培育和维护一个厂商中立的开源生态系统，维护和集成开源技术，支持编排容器化微服务架构应用，通过将最前沿的模式民主化，让这些创新为大众所用。

CNCF的使命包括以下三点：

• 容器化包装

• 通过中心编排系统的动态资源管理

• 面向微服务

全球主流的科技企业和云计算厂商绝大部分都是CNCF会员，其中不乏多家来自中国的科技巨头。

" width="1080">CNCF黄金、白金会员

截止2020年4月，CNCF 基金会共托管49个云原生项目，每个CNCF项目都对应一个成熟度等级，申请成为CNCF项目的时候需要确定项目的成熟度级别，Kubernetes和 Envoy等项目基于生产可用和高稳定性首先成为毕业项目（9个），其他项目则根据其成熟度分别位于孵化（17个）和沙箱（23个）阶段。CNCF目前托管的项目共同构成了云原生生态的基石。

值得注意的是其中有三个来自中国的项目：VMware中国团队为企业用户设计的 Registry Server开源项目Harbor，PingCap贡献的分布式事务键值数据库TiKV以及阿里自研的P2P文件分发系统Dragonfly。

" width="831">CNCF项目成熟度等级划分

对于企业在复杂的基础架构之上如何推动云原生应用的更好落地，从而更好地适应环境与业务的发展，CNCF给出了路线图（Trail Map）用于对用户在整体上给出指导建议，共分成十个步骤（容器化；CI/CD；应用定义及编排；监控及分析；服务代理、发现和网格；网络、策略及安全；分布式数据库及存储；流与消息；镜像库与运行时；软件分发）进行实施，而在不同的步骤都可以结合CNCF全景图（Landscape）中列出的产品或服务进行选择。

" width="831">

CNCF全景图则列举了和云原生相关的产品及服务的完整名单，这1381个项目共同构成了恢弘庞大的云原生世界。整个全景图按照功能分为29个模块，分别归属于9种大的类别（应用定义与开发、编排与管理、运行时、配置、平台、可观察性与分析、Serverless、会员和其它）。值得注意的是其中专门有一种分类是 Cards from China，列举了来自中国的145个项目，其中不乏许多大家耳熟能详的知名项目，可惜的是数据并不完整。感兴趣的朋友可以自行研究。

" width="1080">

从CNCF的理念及野心来看，基于云原生的基础设施正在壮大和蚕食非云的市场，未来极有可能成为整个IT生态事实上的意见领袖和领导者。

云原生涵盖的主要概念

上面提到云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。另外一种比较主流的说法是云原生=微服务+DevOps+持续交付+容器化，广泛的见诸于各种文章和资料。

" width="480">

在接下来的内容中，我们将依照这些概念，分成DevOps与CI/CD；微服务、API管理与集成；容器与Docker；Kubernetes与容器编排之战四个部分全面介绍云原生各个组成部分。

" width="1080">

第二部分——DevOps与CI/CD

上一部分我们主要介绍了云原生的由来、定义及CNCF基金会，第二部分我们来讲DevOps与CI/CD。

DevOps

DevOps（Development & Operations，开发和运维）是09年提出来的概念，但一直没有太火。直到14年，容器与微服务架构的提出，DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。

对于DevOps，微服务不是必须的，但微服务为DevOps提供了最好的架构支撑，对于组织和流程的要求也是一致的。所以，也有人称微服务是DevOps架构。

" width="682">DevOps流程示意图

DevOps与下面提到的CI、CD不同，DevOps更偏向于一种对于文化氛围的构建。DevOps也即是促使开发人员与运维人员之间相互协作的文化。DevOps的概念似乎与持续交付的概念有些类似，两者均旨在促进开发与运维之间的协作，但是实际上两者差别很大：DevOps 更偏向于一种文化的构建，在DevOps文化指导下，团队中将包含了具有不同技能的人员（开发、测试等），并通过自动化测试与发布的手段，更快、更高质量的生产软件。

持续集成

持续集成（CONTINUOUS INTEGRATION，CI）指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。

" width="1000">持续集成流程示意图

持续集成带来的好处是：

• 易于定位错误

• 易于控制开发流程

• 易于Code Review

• 易于减少不必要的工作

持续交付

与持续集成相比，持续交付（CONTINUOUS DELIVERY，CD）的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。

" width="1000">持续交付流程示意图

持续交付带来的好处是：

• 繁琐的部署工作没有了。团队不再需要花费几天的时间去准备一个发布

• 可以更快的进行交付，这样就加快了与客户之间的反馈环

• 轻松应对小变更，加速迭代

持续部署

持续部署（CONTINUOUS DEPLOYMENT）指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比，持续部署强调了通过自动部署的手段，对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。

" width="1000">持续部署流程示意图

持续部署带来的好处是：

• 发布频率更快，因为不需要停下来等待发布。每一处提交都会自动触发发布流

• 在小批量发布的时候，风险降低了，发现问题可以很轻松的修复

• 客户每天都可以看到持续改进和提升，而不是每个月或者每季度，或者每年

自动实时的部署上线，是最优的解决办法，但持续部署的要求是团队非常成熟，并且上线前是需要经过QA测试的，所以实际情况下很难实现，一般的团队也很难接受，挑战和风险都很大。

我们总结下，DevOps、持续集成、持续交付、持续部署并不是某种技术栈或者框架，而是开发文化、流程、理念和操作方式。下一部分，我们将介绍云原生最重要的概念之一：微服务。

第三部分——微服务、API管理与集成

上文我们主要介绍了DevOps与CI/CD，第三部分我们来讲云原生的核心概念-微服务。

什么是微服务

微服务（Microservice）概念最早出现于2012年，2015年以后受到越来越多的关注，并且逐渐开始流行开来。其中著名技术大神Martin Fowler功不可没，他于2014年发表的一篇博客《Microservices: a definition of this new architectural term》（微服务：新技术架构的定义）清晰的定义和阐述了微服务概念。

“要开始解释什么是微服务之前，先了解单体（Monolithic）应用是很有用的：作为一整个单元构建的应用程序。企业应用由三个重要部分组成：客户端界面（由HTML、Javascript组成，使用浏览器访问）、数据库、服务端程序。服务端程序处理HTTP请求、执行业务逻辑、检索并更新数据库中的数据、选择和填充HTML视图发送给客户端。这个服务端程序是一个单一结构也即一个整体，系统中的任何修改都将导致服务端重新编译和布署一个新版本。
这样一个单体应用很自然的被构建成为一个系统，虽然可以使用开发语言的基本特性把应用封装成类、函数、命名空间，但是业务中所有请求都要在单一的进程中处理完成，在某些场景中，你可以在开发人员的笔记本电脑中运行和测试，并且通过布署通道将测试通过的程序布署到生产环境中，你还可以水平扩展，利用负载均衡将实例布署到多台服务器中。
的确，单体应用也非常成功，但是越来越多的人感觉到了不妥，特别是应用程序被发布到云的时候，变更周期被捆绑在一起-对应用程序一小部分所做的变更，都需要重新编译和部署整个应用。随着时间的推移，软件开发者很难保持一个好的模块架构，使得单个模块的变更不会影响到其它模块，而且扩展时也只能进行整体扩展，而不能根据需求进行部分扩展。”-- Martin Fowler

下图是传统单体应用的技术及对应的组织架构，Martin Fowler称之为大家已熟知的Siloed Architectures-烟囱式（也称为谷仓）架构。

" width="575">传统单体应用的架构及对应的职能型组织架构

综上，传统的单体应用有很大的局限性，应用程序随着业务需求的迭代、功能的追加扩展，最终成为一个庞然大物。单体应用的局限性大体包括以下几方面：

• 复杂性高：业务规模和团队规模发展的一定阶段，模块耦合严重，代码难以理解，质量变差

• 交付效率低：构建和部署耗时长，难以定位问题，开发效率低，全量部署耗时长、影响范围广、风险大，发布频次低

• 伸缩性差：单体只能按整体横向扩展，无法分模块垂直扩展

• 可靠性差：一个bug有可能引起整个应用的崩溃

• 阻碍技术创新：受技术栈限制，团队成员使用同一框架和语言

解决这一问题的银弹就是微服务。

“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API)。这些服务要基于业务场景，并使用自动化布署工具进行独立的发布。可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。”-- Martin Fowler

微服务架构将单体应用，按照业务领域拆分为多个高内聚低耦合的小型服务，每个服务运行在独立进程，由不同的团队开发和维护，服务间采用轻量级通信机制，如HTTP RESTful API，独立自动部署，可以采用不同的语言及存储方式。微服务体现去中心化、天然分布式，是中台战略落地到IT系统的具体实现方式的技术架构，用来解决企业业务快速发展与创新时面临的系统弹性可扩展、敏捷迭代、技术驱动业务创新等难题。

下图左边是传统的单体应用，右边是微服务模式，图中每种颜色代表一种可拆分的微服务应用。

" width="639">单体应用和微服务

一个比较形象的例子是装配式建筑。传统建筑（单体应用）的施工周期（开发时间）很长，往往依赖于建筑公司（开发团队）的能力和水平，修建完成后难以搬迁和复用，而装配式建筑（微服务）的梁、板、柱、墙等构件（单个服务）可以事先批量化的在工厂（容器）生产，而在建造过程中，我们可以把构件想象成一块块乐高积木，在施工现场只需把它们拼合在一起，大大提升了施工进度和建筑质量。

" width="400">装配式建筑：乐高积木

微服务的特征包括：

• 小：粒度小，专注于一件事

• 独：单独的进程。微服务不等于组件，服务是可以直接使用的商品，组件是待加工的原材料

• 轻：轻量级通信机制，通常是HTTP Restful的接口。此处区别于传统的SOA（面向服务的架构）

• 松：松耦合，可以独立部署。每个微服务可以独立编译、独立部署、独立运行

" width="758">微服务采用独立的数据库服务，数据去中心化 " width="778">微服务运行在独立的进程中，部署去中心化

微服务架构的好处是：

• 易于开发与维护：微服务相对小，易于理解

• 独立部署：一个微服务的修改不需要协调其它服务

• 伸缩性强：每个服务都可按硬件资源的需求进行独立扩容

• 与组织结构相匹配：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力

• 技术异构性：使用最适合该服务的技术，降低尝试新技术的成本

• 企业环境下的特殊要求：去中心化和集中管控/治理的平衡，分布式数据库和企业闭环数据模型的平衡

微服务的实践有两个重要问题：什么时候选择微服务架构，以及颗粒度如何拆分，与经验和实际情况息息相关。

" width="937">

上图来自Martin Fowler另一篇叫《微服务进阶》的文章，揭示了生产率和复杂度的一个关系。在复杂度较小时采用单体应用的生产率更高，复杂度到了一定规模时，单体应用的生产率开始急剧下降，这时对其进行微服务化的拆分才是合算的。

我个人建议是除非在可见的将来，复杂度都不会显著提高的情况下，才选择单体应用，否则其它时候都应提前为微服务架构做好设计和准备。

微服务基础设施及案例

下图是一个典型的微服务技术架构图。

" width="1080">

微服务架构最常见、最广泛使用的框架是基于Java的Spring Cloud（集成了上图里的Netflix OSS技术栈），提供了服务发现、负载均衡、故障转移、动态扩展和数据分区等功能，已经成为微服务的最佳实践。

但是Spring Cloud构建在Java虚拟机之上，不能满足高并发下的性能要求，所以许多开源产品层出不穷，其中也包括中国互联网企业所贡献的微服务框架，例如华为的ServiceComb、阿里的Dubbo等等。

下面我们举一个例子。传统的电商的技术架构如下图所示，这是一个单体应用。

" width="675">

所带来的常见问题包括：

• 不同客户端产品之间，例如小程序、App、网站端有许多相同业务逻辑的重复代码，每个产品都要各自维护一份代码，修改的时候所有地方要一起修改。

• 单个应用经常需要给其他应用提供接口，渐渐地越来越复杂，包含了很多本来不属于它的逻辑，代码变得臃肿，功能边界模糊。

• 系统代码耦合性高，相互之间逻辑复杂，一旦出现开发离职的情况，继任者需要花很长时间review代码，才有可能搞清楚整体架构和逻辑关系。

• 多个应用使用一个数据库，依赖性严重，很难重构和优化。所有应用都在一个数据库上操作，数据库很容易出现性能瓶颈。同时数据库成为单点，出现意外整个系统都会受到影响。

• 即使只改动一个小功能，也需要整个应用一起发布，发布流程繁琐、上线时间长。并且很容易出现一个小bug影响整个系统，每次发布都是胆战心惊，很容易出现开发、运维和测试之间的矛盾。

下面我们用微服务重构整个系统：

" width="716">

改造之后，去除了大量冗余代码，系统复用性得到提升；不同的团队专注于不同的微服务，代码和工程质量得到保证；数据库不再存在单点问题，系统健壮性得以提升；前后端分离，业务逻辑更加清晰；降低了系统耦合性，不同的微服务可以分开部署上线，相互之间并不影响。

组织挑战、康威定律与蜂群理论

请注意，微服务理念不仅反映了技术架构的变化，也反映了组织内部沟通结构为了应对更加灵活、快速、碎片化的需求和环境而变化的结果。例如液态组织就是组织形态应对当前市场环境快速变化的一种输出形式，但实际应该如何构建？

曾经有一张非常有名的组织架构图，如下图所示。

" width="980">

对一家企业来说，能一步步不断发展壮大，进入一个领域就能迅速突破，这其中的根本核心必然是组织模式。在粗放发展的年代，很少有企业强调内部效率，组织模式绝大部分都类似单体应用，按照职能划分的方式进行管理，从而创造了无数的烟囱/谷仓。

" width="1080">单体架构和职能型组织模式相似 " width="540">一张著名的图：技术组织造就了难以逾越的谷仓

我在我的知识星球里提出过企业级产品设计所面临的重要挑战，其中一个问题是：

• 版本。企业级产品现在经常涉及多个平台和不同的版本，例如Web、PC、App、钉钉、企业微信、微信小程序、飞书的版本等等，第一会面临重复开发的问题，第二业务逻辑非常复杂，很容易造成产品逻辑和体验的不统一，以及不同版本产品之间逻辑的缺失。例如登录和注册微信小程序可能用的是手机号，而通过邮件注册需要使用的却是邮箱。如何设计一套比较好的产品流程和组织架构，来保证统一完善的产品逻辑及用户体验？

是的，这不仅仅是产品和技术问题，还是组织问题。现在越来越多的企业意识到了最大的挑战在于组织内部，无论是增长黑客还是MVP的理念都需要快速灵活的机制来配合。为什么有的组织效率高、能力强，能及时响应客户的需求和环境变化？

新的组织设计理念认为传统的烟囱形式会成为创建有效增长和盈利途径的障碍，需要解构组织孤岛，采用跨职能组织的形式以支持增长。企业组织设计是非常专业的领域，有许多文章讨论，例如《战胜组织孤岛的战略之路》，本文不延伸讨论。

" width="1080">职能组织与跨职能组织

我们可以看到单体应用和职能组织，微服务与跨职能组织，在形式上是高度相似的，这引申出微服务背后的理论基础。

“当希望把一个大型应用拆分成多个部分时，管理层通常将重点放在技术层面。而如果组织架构还按UI团队、服务端逻辑团队和数据库团队的标准设立，甚至一个非常简单的变更都将导致跨团队间的项目协作，从而耗费时间和预算审批。一个高效的团队会针对这种情况进行优化，关注它们所涉及的应用逻辑，并从中做出更好的选择。换句话说，逻辑无处不在。这是康威定律的一个实例。”-- Martin Fowler
设计系统的架构受制于产生这些设计的组织的沟通结构（Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations）-- Melvyn Conway, 1967

康威定律可谓软件架构设计中的第一定律，本质是对商业世界的规律总结，但是因为投稿到编程相关的杂志，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway's law），因此得以推广。

" width="833">

只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四项：

• 第一定律组织沟通方式会通过系统设计表达出来（Communication dictates design）

• 第二定律时间再多一件事情也不可能做的完美，但总有时间做完一件事情（There is never enough time to do something right, but there is always enough time to do it over）

• 第三定律线型系统和线型组织架构间有潜在的异质同态特性（There is a homomorphism from the linear graph of a system to the linear graph of its design organization）

• 第四定律大的系统组织总是比小系统更倾向于分解（The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems）

例如微服务的团队间应该是inter-operate，not integrate（互操作、不集成）。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合变弱，跨系统的沟通成本也就能减低。

康威定律可以上升到哲学的高度进行讨论，但是过于复杂。简言之，微服务架构与组织模式互相决定和影响，协同才能发挥出最大价值。

" width="748">跨职能组织-微服务架构/团队边界强化服务边界

凯文·凯利在《失控》中提出了著名的“蜂群理论”，利用蜂巢思维比喻人类的协作带来的群体智慧：依靠成千上万个发条一起驱动一个并行的系统，进行生产，进行自维持。蜂巢思维就是“群体思维”（Collective consciousness）。作为“超级有机体”的蜂群，被称为“分布式系统”，是以生物逻辑建立起来的群集模型。由此形成的蜂巢思维这四个理念至关重要：

1）去中心化。几乎所有的团队都直接接触用户与市场，因此所有的团队都将围绕市场格局而变，充分重视第一线的敏感度与直觉，从而做到真正的应时而动；

2）分布式。与垂直型集团组织不同，这个形态打破单一的行业垂直细分格局。在这种多维度矩阵式结构中，拥有更加专注的功能型团队，可建立起一个紧密围绕具体客户与市场的服务体系；

3）强化合作。从控制权、所有权的角度来说，这些组织单元是分离的，因而要建立起一种横向合作的文化，打破物理团队，提倡交流、合作，整体核心竞争力的提升；

4）适应变化。市场在不断变化，但因所有的团队都直接接触用户与市场，因此无论个人还是团队，都将不断的学习和进化。

微服务理念对应的组织模式包括蜂巢型组织，它具有突出的稳定性和抗弯曲能力，特点是：

• 跨组织：它不一定是一个独立的法人实体，而是为了特定目标或项目形成的联盟

• 相对统一：蜂巢组织不是一成不变的，当市场需求或组织目标发生变化时立即变化

• 分享性：它改变了传统的等级分明的金字塔结构，允许信息横向传递与交流，使信息利用更为充分及时

在这样一个以蜂巢为理念搭建的企业圈层里面，各个独立团队能够得到更好的协助与支撑，不断扩大视野，提高眼界，掌握话语权，团队成员也会更有归属感。这样的团队乃至蜂巢本身，也一定会更有活力和变革力，更加能适应市场的变化。蜂巢型组织有四个突出特点，所谓活系统的特质也正是由此而来：没有强制性的中心控制；次级单位具有自治的特质；次级单位之间彼此高度连接；点对点间的影响通过网络形成了非线性因果关系。

" width="433">微服务：筑巢

蜂巢型组织的典型案例之一是华为。除了组织架构去中心化的管理模式之外，华为的著名的轮值CEO制度正是由此而来，华为有三位轮值CEO，每六个月轮换一次，这体现了依靠集体民主决策而非一人独裁的理念。

再例如国美蜂巢式组织变革的实践是将由四个大区管辖54个分公司，调整为七个大区直接管辖200家分公司的结构，即将原来二级市场里的146家分公司独立出来，直接划归大区管辖，而原来四个大区变成七个大区。实践证明，组织扁平化是国美提升供应链效率，提升消费者消费体验的重要战略。

国外著名的代表案例是微服务先驱Netflix。Netflix是一家技术强大的互联网公司，但是它却没有CTO职位，产品团队和技术团队(包括UI前端工程团队、Discovery搜索工程团队和Platform平台团队等)全部汇报首席产品CPO，产品驱动是该公司的核心文化要素之一，Netflix称其为BusDevOps组织架构。

" width="761">Netflix：BusDevOps组织

在整个系列第二部分中，我们介绍了DevOps，现在我们可以理解，DevOps是配合微服务的理念组织构建团队协作的方式，各团队可以独立开发，测试、发布和迭代各自的微服务，互不干扰，沟通协调成本小。全部业务、研发和运维围绕产品开展工作，统一目标，大家都是产品驱动，分别服务于内外不同客户，避免技术驱动 vs 业务驱动的陷阱。

" width="850">传统水平组织 vs DevOps驱动的垂直组织

在某些文章中，认为微服务的切割应该按照组织架构来划分，我反而觉得应该按微服务的分割方式来划分组织架构， 因为归根结底，组织架构应该为业务服务，而不是业务为组织服务，组织需要贯彻执行微服务的理念，就必须由微服务驱动组织业务的不断迭代演进。

微服务与中台

可能有人会问，中台的目标不也是为了解决企业内部业务系统烟囱林立，数据孤岛严重，各自为战，缺乏复用性，所以要充分提取业务共性，从而及时应对需求变化，听起来和微服务的目标和理念非常相似，那它们之间有什么异同呢？

" width="930">阿里巴巴中台战略架构图

来自阿里官方的定义，“企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。”

中台架构，简单地说，就是企业级能力的复用，一种方法论，企业治理思想。

微服务，是可独立开发、维护、部署的小型业务单元，是一种技术架构方式。

所以中台并不是微服务，中台是一种企业治理思想和方法论，偏向于宏观，微服务是技术架构方式，偏向于微观。而中台化的落地，离不开使用微服务架构。

中台强调核心基础能力的建设，基础能力以原子服务的形式来建设，并通过将原子服务产品化，支撑业务端各种场景的快速迭代和创新；原子服务和微服务所倡导的服务自闭环思想不谋而合，使得微服务成为实现原子服务的合适架构。

支撑业务场景的应用也是通过服务来实现，其生命周期随业务变化需要非常灵活的调整，这也和微服务强调的快速迭代高度一致，所以业务应用服务也适合通过微服务来实现。

API管理与API集成

下面我们讲讲微服务相关的两个具体领域，API管理与API集成。

1、全生命周期API管理

上文提到微服务各个服务对外都是以Restful API形式提供服务。再加上企业越来越多地使用云服务，各种云服务也提供了众多API。

这就导致企业拥有的API越来越多，那就当然需要有一个系统把这些API统一管理起来。同时，如果能够顺便把这些API的权限认证、安全审计等等机制也一并统一了，那就更好了，这样其它系统调用起来就方便多了。能管了以后，当然又会冒出来更多的想法。比如，能不能改一下原有API的格式内容？能不能把两个API合成一个API？能不能让一个API直接调用另一个API？能不能把这些API的调用自动化串起来？

简单来说，API管理就是解决以上这些问题的。我们来看看Gartner全生命周期API管理领域魔力象限，许多巨头都在里面。值得注意的是，Google之所以排名第一，是因为它在2016年用6.5亿美元收购了刚上市一年左右的Apigee。

" width="915">2019年全生命周期API管理魔力象限

2、API网关：微服务基础设施

全生命周期API管理里一个细分的领域是API网关（API Gateway），它是微服务1.0时代最重要的基础设施。

API网关顾名思义，是出现在系统边界上的一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，主要起到隔离外部访问与内部系统的作用，并处理常见的南北向流量。在微服务概念的流行之前，API网关的实体就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换、访问统计等问题的。

API网关的流行，源于近几年来，移动应用与企业间互联需求的兴起。移动应用、企业互联，使得后台服务支持的对象，从以前单一的Web应用，扩展到多种使用场景，且每种使用场景对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量，还增加了后台服务的复杂性。随着微服务架构概念的提出，API网关成为了微服务架构的标配组件。

API网关作为企业能力开放的一个门户，除了具备基本的请求转发、协议转换、路由等功能，以及高性能和高稳定性外，还需具备良好的扩展性，已便于网关能力的不断增强。在网关实施过程中，要规划好网关层与服务层的交互方式，尽量使得网关层与服务层解耦，便于各个团队工作的独立性。另外，在API的管理上，需要提供API全生命周期的发布、配置、鉴权、流控、监控等配套的管理功能。

" width="987">API网关：微服务基础设施

例如Uber，在传统的单体架构遇到越来越大挑战的时候，决定改变自己的架构，效仿亚马逊、Netflix、Twitter等其他超级增长公司，将其整体架构拆分为多个代码库，以形成一个微服务架构。其主要变化是引入了API网关，所有的司机和乘客都是通过这个网关连接的。从API网关，所有的内部点都连接在一起，如乘客管理、司机管理、行程管理等。每个单元是单独的可部署单元，执行单独的功能。例如：如果你想在账单微服务中更改任何内容，那么只需部署账单微服务，而不必部署其他服务。所有的功能都是单独扩展的，即每个特征之间的相互依赖被移除。

" width="768">Uber的微服务架构

API网关带来的的好处包括：

• 网关层对外部和内部进行了隔离，保障了后台服务的安全性

• 对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本

• 减少客户端与服务的耦合，服务可以独立发展。通过网关层来做映射

• 通过网关层聚合，减少外部访问的频次，提升访问效率

• 节约后端服务开发成本，减少上线风险

• 为服务熔断，灰度发布，线上测试提供简单方案。

• 便于扩展

API网关常见的解决方案包括Spring Cloud Gateway、Zuul、Tyk以及下文要介绍的Kong。

" width="336">CNCF Landscape：API Gateway

3、Kong：API网关独角兽

" width="725">

Kong是我去年起就在关注的一家公司，它的创业历程非常有意思。“Kong的创始人Augusto Marietti（简称Aghi）出生在罗马，因为意大利创业环境很弱，在2009年飞来了旧金山。Aghi刚来就参加了一个早期创业者的小聚会，聚会上参加的人不多，但现在都是如雷贯耳的名字：Uber的创始人Travis，Airbnb的CEO Brian，Dropbox的CEO Drew和Box的CEO Aaron。Aghi当时为了省钱，借住在Uber创始人Travis家，每天睡沙发。

后来Travis搬了家，Aghi又去了当时只有十多个人的Airbnb办公室里借住，当时的Airbnb虽然Bug很多，但订单量一天天疯涨。在Travis的帮助下拿到天使投资后，Aghi做了一个把云端的组件连接起来的PaaS公司，一做就是五六年。由于时机不对，公司濒临破产，Aghi告诉团队，这么多年公司写了很多小功能，现在可以把代码开放出去，放在网上看看有没有人用，给社区做点贡献。没想到这看似濒死的挣扎，却给公司带来了巨大的转机。

后来，公司关于API管理的代码模块，在GitHub上被疯狂下载，Kong也接到客户要求，希望购买相应的付费企业版。Kong敏锐地发现了这个大机会，迅速转型成了一个开源软件公司。”如果在CSDN博客上搜索，关于Kong开源版本的教程比比皆是。这是一个成功的开源软件商业化的案例，听起来经历和Docker非常相似。

" width="831">Kong开源版本Github主页

Kong成长的大背景是软件开发技术正在经历革命性变化，全球5000强公司都在转向新的分布式软件架构，因为现代应用程序需要有高度可扩展性、跨平台支持以及处理实时数据流的能力。IDC预计，到2022年90%的应用程序将采用微服务架构和第三方代码，35%的生产应用程序将诞生于云端。由于容器和敏捷方法的采用，预计2018-2023年间将诞生5亿个新应用程序。

同时开源软件初期具有的优势也在逐渐显现。Kong本身基于开源的Openresty（Nginx+lua），但比Nginx提供了更简单的配置方式，数据采用了Apache Cassandra/PostgreSQL存储，由于底层使用Nginx，所以性能比基于Java的Spring Cloud Gateway及Zuul更为出色。Kong另外一个非常诱人的地方就是提供了大量的插件来扩展应用，通过设置不同的插件可以为服务提供各种增强的功能。Kong默认插件包括：身份认证、安全、流量控制、分析监控、转换等等。

" width="1080">Kong的插件功能

Kong提供开源的Kong Gateway和商业版Kong Enterprise两个产品。例如在插件功能上，商业版本提供更多的选择。

" width="971">Kong的部分插件功能

Kong通过云原生、混合和本地部署无缝连接API和微服务，便于程序员开发可扩展的微服务应用，推动业务增长。凭借高性能的开源内核和AI技术以及机器学习，Kong将实现全方位的服务生命周期管理，覆盖前期到后期全过程，帮助客户搭建和管理创新产品及服务。它服务于全球5000强企业，帮助程序员更方便地开发和管理高性能、可扩展的微服务应用，推动业务增长。

从业务和融资上来讲，2018年，Kong订单大幅增加，公司员工数翻倍，已服务超过100家企业客户，包括雅虎日本、法拉利、SoulCycle、WeWork等，开源软件下载量超过5400万次，收入为500万美元。2019年，Kong完成了Index Ventures领投，GGV纪源资本、World InnovationLab跟投，老股东Andreessen Horowitz、Charles Rivers Ventures追加的4300万美元C轮融资，至此Kong累计融资共计7100万美元。

4、RapidAPI：全球最大API市场

和Kong紧密相关的另外一家企业是RapidAPI，2017年，Kong的母公司Mashape将其API市场业务与 RapidAPI合并，从而组成了世界上最大的API市场。

" width="442">

市场研究机构Ovum Research曾经表示，API经济在迅迅猛发展，到2018年将成为产值高达2.2万亿美元的市场。合并后，RapidAPI成为了这个市场的主要提供商之一。

RapidAPI的首席执行官吉纳在宣布合并的博文中表示，“软件相互连接起来后，其功效就要大得多。不妨想一想。你使用Facebook登录到某个游戏应用程序，就能看到玩游戏的所有朋友。当亚马逊的购买门户网站与仓库存货连接起来后，你就能实时获得发货估计日期。如果你在订购机票呢？已经在你的谷歌日历中预定了航班。”吉诺补充道，API正是让那些连接成为可能的秘诀。“它们让不同的软件得以彼此联系，共享信息，并且简化我们的生活。”

吉纳在博文中表示这只是开了个头。API正在迅速发展，打开之前紧闭的许多大门。使用API，开发人员就有可能从任何地方来访问服务，比如IBM公司的超级计算机和谷歌的机器学习模型，这就意味着他们能够充分利用比以前处理的任何资源丰富得多的资源。

吉纳说：“我们想要让广大开发人员更容易寻找、测试和连接API。我们的计划始终未变，那就是将世界上的所有API统统集中到一个地方。将Mashape API市场合并到RapidAPI让我们离实现这个目标比以往更近了一步。现在我们每月总共有370000名开发人员在调用3000亿次API。也就是说，每秒的API调用超过100000次。”

RapidAPI的市场里包括各种各样类型的API，例如天气、体育、科技、通讯、图像处理等等，例如获取新闻信息、实时体育比赛比分、天气信息，甚至还包括新冠病毒API分类。

" width="831">

开发商可以自由的为自己的API接口定价，下图是Twilio SMS接口的报价方案。

" width="1080">

2019年，RapidAPI完成了由微软领投、A16Z等跟投的2500万美元B轮融资，历史累计融资达到3750万美元。RapidAPI表示，它将利用这笔新筹集的资金扩大其API市场规模，并推动其新发布的RapidAPI for Teams产品。它是一个自助服务平台，使开发人员能够发布，管理和协调API和微服务，这些是用于构建现代应用程序的常用组件。

5、Mulesoft：API集成/iPaaS/API管理领头羊

1）从SOA讲起

讲API管理之前，我们得先来说说前文提到过的SOA（Service-Oriented Architecture，面向服务的架构）。

简单地说，一个企业建设了许多业务系统，每个系统都拥有自己的数据，那么如何将这些分散各处的数据打通，从而可以进一步加以利用呢？

这就涉及到企业应用集成（EAI，Enterprise Application Integration）这个领域了。

传统上，企业应用集成很多是利用ETL（Extract-Transform-Load，抽取转换加载）工具，把不同系统里的数据经过抽取、过滤、转换，最终导入到一个集中的数据仓库里，然后再做整合应用。但是这种做法也存在很多问题。

一是只认数据，没有脑子。在数据汇集的过程中，只能针对数据格式本身进行一些处理，很难利用业务系统原有的业务逻辑。

二是随着各个系统数据体量越来越大，把所有系统的数据都汇到一个数据仓库里就变得越来越困难。

为了解决这样的问题，SOA应运而生，就是企业中每个系统都对外发布自己的服务，那么系统之间的集成，就可以通过调用对应系统的服务来解决了。

但是，随着企业拥有的系统越来越多，这种系统之间相互调用服务接口的集成方式又遇到了新麻烦。

可能每两个系统之间都需要相互调用服务，这最终就会演变成一个复杂的蜘蛛网结构，使得整个集成变得越来越脆弱，难以维护。

为了解决这个新问题，ESB（Enterprise Service Bus，企业服务总线）的概念被提出来了，就是把每个系统的服务接口都对接到ESB上，这样在系统集成的时候，只需要跟总线打交道，而不再需要直接跟所有其它系统打交道了，从而大大简化了集成的复杂度。

" width="1080">使用ESB前后

2）Mulesoft

2018年3月，美国SaaS巨头Salesforce花费65亿美元收购iPaaS代表企业Mulesoft，Mulesoft于2017年在纽交所上市，市值约30亿美元。Mulesoft的核心产品是企业软件集成平台Anypoint Platform（旧称Mule ESB），客户可以在Anypoint上集成所有业务系统的服务，实现本地系统与云、以及云与云服务的集成。Anypoint Platform/Mule ESB是世界上使用最广泛的开源ESB产品，已拥有超过数百万的下载量，以及来自世界各地数十万个开发人员，财富500强中35%的企业、全球10大银行中的5家均使用了该平台。

" width="800">Mule ESB

尽管只有一个产品，但从Gartner的划分标准来看，Mulesoft同时踩在了两个领域里：全生命周期API管理和企业集成平台即服务（iPaaS，Enterprise Integration Platform as a Service）。

" width="650">Gartner魔力象限：全生命周期API管理 " width="619">Gartner魔力象限：企业集成平台即服务

Mule ESB同时包括开源和商业版本，在各个技术论坛上遍布其技术教程。

" width="697">Mule开源版讨论文章

Mulesoft的成长历程非常具有参考意义，他们瞄准了一个有7000亿美元空间的市场，目标是解决一个十分困难的IT问题-集成。在摸索过程中Mulesoft不断优化其产品形态和销售方式，例如针对大客户需要的不仅是平台提供的通用功能，还需要更复杂的综合服务。于是MuleSoft把他们的销售方式从出售可靠的集成功能，变成了向高级管理人员出售提升企业连接能力的愿景和相应的解决方案，客单价也从10-30000美元提升到了500万美元。

3）应用场景与案例

Mule ESB的常见应用场景例如：

• 旧系统改造，开放系统的服务能力。举个例子，企业有一个电商系统，需要调用SAP ERP的订单接口来创建订单，这个时候需要将SAP的订单服务暴露成流行的Restful API，以方便电商系统调用。使用Mule ESB可以轻松实现。

• 系统集成。企业之间的数据交换，竟然有一半以上是文件的形态进行的，这在互联网思维普及的今天，是不容易想象的。在10年前，企业间交换数据采用文件形态的比重占60%，当时普遍认为这个比重会迅速下降，最终以接口服务形态进行交换的比重会占绝大多数。然而10年后直至今天，采用文件形态的依然占51%的比重。其实仔细想想，也不无合理。两个对等企业之间，行业上下游多个企业之间，不同系统之间的进行数据交换，采用文件的形式，可能是最简单便捷的方式。举个例子，很多系统之间数据交互可能还是用FTP目录。尤其是企业跟企业之间的数据交互，比如，A企业丢一个EDI文件到B企业的FTP目录，然后B企业会从FTP目录下载解析并放置到数据库。这个场景用Mule ESB实现也很方便。

" width="510">

4）Salesforce为什么收购Mulesoft

Salesforce最初为中小企业提供SaaS的CRM，而随着大客户越来越多，定制化、个性化的需求也越来强烈，所以就需要提供PaaS平台解决个性化、定制化的问题。

而这个定制化，最开始只是以Salesforce为核心的功能延伸及简单扩展，而随着个性化需求的不断深入，这种定制已经逐步演变为更大规模的多个骨干数据源之间的数据集成与交换，Salesforce可能只是多个数据源之一。

所以也可以说，数据集成是PaaS平台的上层建筑，Salesforce需要帮助客户解决整合不同数据源所带来的挑战。

收购之后，Salesforce会将MuleSoft植入进Salesforce Integration Cloud，从而帮助客户连接多个数据源，并计划在之后推出集成云。

所以，可以看出Salesforce其实更在乎的是集成（Integration）这个词。

5）iPaaS、API管理与API集成

iPaaS的集成不光是针对云服务，也包括本地系统，这样就解决了混合云模式下的集成问题。iPaaS集成的范畴，除了API接口之外，一般还会包括更多种类的协议（比如FTP、数据库），也包括对于文件数据的集成。

从这个角度来理解，API管理更关注API的治理与整合，iPaaS关注更大范畴的集成，包含API集成的概念。

6）SOA、ESB与微服务的关系

微服务架构和SOA架构非常类似，微服务是SOA的升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用，这些小应用间通过服务化完成交互和集成。

ESB是一种集中式服务治理的架构，看上去微服务中不需要ESB，Martin Fowler也不赞同在微服务架构中继续用ESB。

我们下面要介绍到的下一代微服务架构核心-服务网格 ，则可以视为分布式的ESB。

微服务2.0：服务网格与Serverless

1、服务网格

微服务当前遇到的挑战包括：

• 技术门槛高：开发团队在实施微服务的过程中，除了基础的服务发现、配置中心和鉴权管理之外，团队在服务治理层面面临了诸多的挑战，包括负载均衡、熔断降级、灰度发布、故障切换、分布式跟踪等，这对开发团队提出了非常高的技术要求。

• 代码侵入性强：Spring Cloud、Dubbo等主流的微服务框架都对业务代码有一定的侵入性，技术升级替换成本高，导致开发团队配合意愿低，微服务落地困难。

为了解决上述问题，号称微服务2.0的服务网格（Service Mesh）应运而生。服务网格这个词最早由著名开源服务网格项目Linkerd所在的Buoyant公司CEO William Morgan所提出。按照他的定义，服务网格是一个软件基础设施层，用于控制和监视微服务应用程序中的内部、服务到服务的流量。

" width="1080">服务网格架构

Sidecar是服务网格中的核心组成部分，可以看到，上图中每一个微服务都配备了一个Sidecar。此时用户只需要关心业务逻辑，而不用关心服务治理等非业务功能，非业务功能都由Sidecar负责，接管对应服务的入流量和出流量，并将微服务架构中的服务订阅、服务发现、熔断、限流等功能从服务中抽离到Sidecar中。

服务网格和API网关是两个联系非常紧密的概念，它们的用途既不同，但是在某些方面又相互重叠。在某种程度上，我们可以认为服务网格是一个 分布式的、微观层面的API网关，解决微服务服务发现、负债均衡、流量控制等需求。在具体用途上，API网关处理的是所谓南北向流量即内外部请求；而服务网格处理的是东西向流量即内部服务相互间的访问。想深入了解两者区别的读者可以仔细阅读《 Service Mesh和API Gateway关系深度探讨》这篇文章。

" width="1080">南北向流量 vs 东西向流量

服务网格相关的著名项目包括Linkerd、Envoy和最受欢迎的服务网格框架Istio。Kong也于2019年发布了基于Envoy的开源服务网格产品Kuma。

" width="897">Kong的服务网格产品：Kuma

下图是CNCF Landscape里服务网格分类所罗列的项目，其中Linkerd正由CNCF进行孵化。

" width="343">

2、Serverless

Serverless（无服务器架构）这个概念在2012年时便已经存在，比微服务和服务网格的概念出现都要早，但是直到微服务概念大红大紫之后，Serverless才重新又被人们所关注。

Serverless是一种构建和管理基于微服务架构的完整流程，它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态、暂存的计算容器内。Serverless相关的重要概念包括FaaS（Functions as a Service，函数即服务）。开发者把函数上传到云厂商的FaaS平台，函数只在被请求时才实例化运行，然后被销毁，其它时候不占用任何服务器资源，完全实现按需使用，大幅度降低了服务器占用和成本。

Serverless通常适用于实时性要求不高、无状态的场景，例如突发事件处理、数据统计分析、视频解码、离线批量计算等等，像AWS FaaS平台Lambda限制用户功能必须在15分钟内完成。

相较服务网格，Serverless概念更为超前，虽然AWS Lambda、阿里云等许多平台都已经提供对其的支持，但是目前仍处于发展早期，无论是成熟项目数量和企业应用程度都相对有限。

" width="1080">FaaS Landscape " width="1080">CNCF Serverless Landscape

微服务 vs 宏服务：新的抉择

最近，Uber支付体验平台的工程经理Gergely Orosz发布推文表示他们的架构方向已经发生了变化。

" width="733">

“声明一下，在Uber，我们正将许多微服务转移到@copyconstruct所称的Macroservices宏服务（大小适中的服务）。确切地说，B/C测试和维护成千上万的微服务不仅很难——它可能会带来更多的长期麻烦，而不是解决短期问题。微服务确实可以帮助团队在早期快速推进。等你意识到服务越少越好时，已为时已晚。你需要解决很多服务的“困难”部分。我们在不断增加更多的服务，但也在停止使用服务，并且会更慎重的思考新的服务。“

全部的上下文可以在这里阅读。有一篇英文文献中这样描述Macroservices宏服务：宏服务应该定义为运行2-20个单独服务的应用程序体系结构，每个服务代表一个中等大小的代码库，可处理业务中定义明确的部分。宏服务的关键是拆分服务，最大程度地从拆分中获得收益，同时最大程度地降低运行多个服务的开销。通俗点讲，宏服务介于单体服务到微服务之间，关注的不再是某一个细节点，而是一个业务点。

实际上，宏服务目前的定义并不清晰，影响和实践相当有限，也并非比微服务更优的解决方案，本质还是不同企业和团队在架构演进中对于系统复杂性的不同度量。

总结

微服务的理念不同的团队有不同的实践，例如微服务如何拆分、组织架构如何搭建、技术栈如何选择。

我们理解，微服务是云原生的核心，后面要介绍到的容器（及Docker）和Kubernetes是实现的技术方法和手段，DevOps是配合的文化和研发流程，但是微服务带来的启发，更多是思维方式上的转变。

从下一部分开始，我们将分两期介绍两大核心技术：Docker和Kubernetes。

第四部分——容器和Docker

上文我们主要介绍了微服务，第四部分我们来讲云原生关键技术之一的容器及Docker。

虚拟化与容器

在容器技术之前，业界的网红是虚拟机。虚拟机技术的代表是VMware和OpenStack，我在虚拟化与超融合系列里做过介绍。很多人都用过虚拟机，就是在操作系统里安装一个软件，然后通过这个软件，再模拟一台甚至多台“子电脑”出来。在“子电脑”里，可以和正常电脑一样运行程序，例如微信、Word。“子电脑”和“子电脑”之间，相互隔离互不影响。

虚拟机虽然可以隔离出很多“子电脑”，但占用空间大，启动慢，虚拟机软件可能还要花钱（例如VMware）。而容器技术恰好没有这些缺点，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境（类似“沙箱”），启动时间很快，几秒钟就能完成。而且，它对资源的利用率很高（一台主机可以同时运行几千个Docker容器）。此外它占的空间很小，虚拟机一般要几GB到几十GB的空间，而容器只需要MB级甚至KB级。虚拟机和以Docker为代表的容器都是虚拟化技术，不过容器属于轻量级的虚拟化。下面是两者的主要对比。

" width="722">

Docker的源起

我们再来看看Docker，Docker本身并不是容器，它是创建容器的工具，是应用容器引擎。虽然Docker 把容器技术推向了巅峰，但容器技术却不是Docker发明的。实际上，容器技术连新技术都算不上，因为它的诞生和使用有些年头了，像最早的容器LXC发布于2008年。

Docker本来是做PaaS的公司，原来叫做DotCloud，成立于2010年。但比起Pivotal、Red Hat等著名企业，DotCloud运营并不成功。眼看就要失败的时候，2013年DotCloud决定开源自己的容器项目Docker。但是短短几个月，Docker迅速崛起，吸引大量的开发者使用。随着Docker在开发者中越来越流行，2013年10月，DotCloud公司正式更名为Docker，2014年8月，Docker 宣布把PaaS业务出售，开始专心致志做Docker。

Docker一词意为码头工人，而它的logo则是一个托着许多集装箱的鲸鱼，非常形象：Docker是鲸鱼，而集装箱则是一个个的容器。在Docker的官网上，对于容器有一个一句话的解释“A standardized unit of software”，即“软件的一个标准化单元”。

" width="300">

下面的图片比较了Docker和传统虚拟化的不同之处，容器是在操作系统层面上实现虚拟化，而传统方式是在硬件层面实现，所以导致两者的特性有很大区别，Docker更小更轻。

" width="1080">Docker vs 虚拟化

而Docker与传统的Linux容器也并不完全一致。Docker技术最初是建立在LXC技术之上的，大多数人都把LXC技术与传统的Linux容器联系在一起，尽管后来它已经摆脱了这种依赖性。LXC作为轻量级虚拟化很有用，但它没有很好的开发人员或用户体验。Docker技术带来的不仅仅是运行容器的能力，它还简化了创建和构建容器、加载镜像和镜像版本控制等过程。传统的Linux容器使用可以管理多个进程的init系统，这意味着整个应用可以作为一个整体运行。Docker鼓励将应用程序分解为它们各自的进程，并提供了实现这一点的工具，这种粒度有不少优点。

" width="1080">传统Linux容器 vs Docker

Docker解决的问题

众所周知，Linux上我们不愉快的经历之一就是安装软件。因为系统硬件、操作系统环境不一样，软件包有不同的依赖性，所以必须要安装完软件依赖路径上的所有包，这个链条之长，往往要耗费几小时甚至几天的时间。例如下面的案例，我要安装Docker，系统提示我必须要先安装selinux-policy、selinux-policy-base、selinux-policy-targeted三个相关模块。而我安装selinux-policy的时候，又提示要先安装python；安装python的时候，又提示我要先安装_bz2、_curses、_curses_panel等等模块…

" width="831"> " width="831">

这就是由于环境不统一带来的巨大问题，每天在世界各地的数千万台机器上都会重复上演无数次。那么，如果服务器环境能够标准化，那我们安装任何软件只需要一个版本就可以解决问题。

同时，如果所有服务器环境统一、标准化，还能保留上面的配置、安装的软件和应用，对于我们来讲就更加有用。Docker正是在操作系统之上实现了这个标准化、统一化的运行环境，并且把各种不同的配置和应用存储成镜像，供未来使用。这有点类似于我们熟悉的Ghost或者虚拟光驱，把需要的环境和状态保留为镜像，随时恢复、随时使用。不过Ghost基于操作系统，镜像是一个大文件，管理起来并不方便，恢复速度也很慢，同时不支持跨平台的镜像恢复；而虚拟光驱则是基于软件层面，使用范围有限；而Docker正处于两者之间，能完成更多功能的同时，还实现了镜像的快速加载和运行。

" width="676">Ghost软件 " width="671">虚拟光驱软件

我们在上一部分讲微服务的时候，将其比喻成装配式建筑。把这个比喻用在Docker上的话，我们只要提前设计好模板（配置环境、部署软件或服务），就能在工厂（Docker）里批量化生产（说复制可能更加合适）出楼板、墙板、楼梯、阳台等构件和配件（容器所装载的、不同的微服务），这些构件在建筑施工现场经过组装拼合（API访问），就能成为各种各样的建筑（各种类型的产品和应用）。

" width="732">装配式建筑由各种构件组成 " width="528">Docker与各种概念的关系

所以，Docker曾经有一句Slogan叫做“Build once，Run anywhere（搭建一次，随处可用）”。

Docker的核心概念

Docker技术的三大核心概念，分别是：

• 镜像（Image）

• 容器（Container）

• 仓库（Repository）

上面的例子里，设计出来的模板就是Docker镜像，生产（复制）出来的构件就是Docker容器，而Docker仓库则是集中放置管理Docker镜像的地方。

Docker镜像是一个特殊的文件系统。它除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的配置参数（例如环境变量）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

每一种模板（镜像）能够创建出一种构件，但是模板可以由不同的设计师来设计，提供不同用途、不同风格，例如斜顶式阳台、嵌入式阳台、包豪斯风格、蒙德里安风格等等，所有人相互之间可以共享，这就形成了大的公共仓库。

Docker官方提供了 Docker Hub来维护管理所有的镜像，只是对于免费用户而言,只能创建一个私有仓库。Docker Hub里提供了大量高质量的官方镜像，例如Oracle、MySQL、redis、Ubuntu、Nginx、python、Docker（Docker in Docker！）等等，开发人员需要一个环境的时候，可以直接到Docker镜像仓库去查找，减少了大量无谓的环境安装工作。

" width="437">Docker Hub

Docker创始人曾经公布过一个相关数据，Docker Hub里镜像的下载数量从2014年的100万次，3年内猛增到了120亿次。

" width="1080">

下面是我从Docker Hub上拉取一个hello world演示镜像，并且运行的示例。

" width="781">

Docker的好处

Docker给我们带来的好处非常多，下面简单列举几点：

• 更高效的利用系统资源

有了Docker，我们可以在一台服务器上运行很多应用，充分利用硬件资源。例如现在我们有一台Linux服务器，可以构建不同版本的Ubuntu镜像启动，并且为不同的用户分配不同的容器。这样用一台服务器就能虚拟出许多运行不同操作系统的虚拟服务器，而对于用户来说，这些都是透明的。许多公有云采用了容器技术为用户提供服务，所以虚拟化与容器共同成为了现代云计算的基石。

• 更快速的启动时间

传统的虚拟机技术启动应用服务往往需要数分钟，而Docker容器应用，由于直接运行于宿主内核，无须启动完整的操作系统，因此可以做到秒级甚至毫秒级的启动时间，大大的节约了开发、测试、部署的时间。

• 保证环境一致性

开发过程中常见的问题之一是环境一致性问题，由于开发环境、测试环境、生产环境不一致，导致有些bug并未在开发过程中被发现，而Docker的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性，再也不会有在线下开发环境中运行正常，而部署到线上有各种错误的情况了。

• 持续交付和部署

对于开发和运维人员来说，最希望的是一次创建或配置，可以在任意地方正常运行。开发者可以使用一个标准的镜像来构建一套开发容器，开发完成之后，运维人员可以直接使用这个容器来部署代码，无论在多少台服务器中部署都是如此。Docker可以快速创建容器，快速迭代应用程序，并让整个过程全程可见。

• 更轻松的迁移

由于Docker确保了执行环境的一致性，使得应用的迁移更加容易，Docker可以在很多平台上运行，无论是物理机、虚拟机、公有云、私有云，其运行结果是一致的，因此用户可以很轻易的将在一个平台上运行的应用，迁移到另一个平台上，而不用担心运行环境的变化导致应用无法正常运行的情况。

• 提升复用性，降低耦合性，维护和扩展更轻松

Docker使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。安装Docker后，我们可以从Docker Hub上获取各种各样的操作系统镜像，这个操作很简单，只需要拉取相应的镜像到本地然后运行即可。另外我们可以将数据库、Web服务器、缓存服务器运行在不同的容器中，降低了各个服务之间的耦合性、便于扩展，Docker Hub上有各种各样的优秀镜像，我们可以直接拿来使用，不需要自己搭建，应用的部署就像搭积木一样简单。

• 实现沙盒机制，提高了安全性

由于应用运行在容器中，与操作系统隔离开，从而使操作系统基本不可能受到破坏。另外如果应用因为攻击而瘫痪，并不需要重启服务器，直接重启容器或者再启动一个镜像就可以了。

容器与微服务

容器是微服务和云原生架构的最佳实现载体。微服务与容器几乎是完美的搭配。单体式架构（Monolithic）变成微服务架构（Microservices），相当于一个全能型变成N个专能型，每个专能型分配一个隔离的容器，赋予了最大程度的灵活。

" width="658">

服务器势必会走上虚拟化的道路，因为虚拟化有太多的优势，例如前文所说的低成本、高利用率、充分灵活、动态调度等等。而采用容器之后，只需要一台服务器，创建十几个容器，用不同的容器，来分别运行不同用途的服务程序。这些容器，随时可以创建，也可以随时销毁。还能够在不停机的情况下，随意变大，随意变小，随意变强，随意变弱，在性能和功耗之间动态平衡。 所以容器化是云计算的终极形态。

如果把传统IT架构比作传统工厂，容器化比作现代化工厂，那么下一部分我们要讲到的Kubernetes则会将现代化工厂进一步提升为智能化无人工厂。那么当Docker遇到Kubernetes之后将会发生什么有趣的事情？让我们拭目以待。

" width="930">

第五部分——Kubernetes与容器编排之战

上文我们主要介绍了容器和Docker，第五部分我们来讲Kubernetes与容器编排之战。

容器编排与Kubernetes

在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势。所以企业需要一套管理系统，对Docker及容器进行更高级更灵活的管理，按照用户的意愿和整个系统的规则，完全自动化的处理好容器之间的各种关系，这叫做编排（Orchestration）。

Orchestration这个词来自于音乐领域，是指一种将不同乐器、音色加以合理的编排等手法营造出一个听感交融、平衡的艺术，它完美地描述了容器编排的含义：为单个应用程序（乐队中的每种乐器）提供协同工作的模式。

" width="720">

在IT领域编排可以理解为一种工作流，它能把整个IT系统都串接起来，然后自动化运作。在云原生时代，整体式的应用早已成为过去时，应用一般由单独容器化的组件即微服务组成，而这些组件需要通过相互间的协同合作，才能使既定的应用按照设计运作。

2014年6月，IT基础设施领域的领先者Google发布了 Kubernetes（简写为K8S）。编排概念并不是由Kubernetes第一个提出的，Kubernetes这个单词来自于希腊语，含义是舵手或领航员。

" width="1080">

Kubernetes是基于Docker的开源容器集群管理系统，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，因为容器本身可移植，所以Kubernetes容器集群能跑在私有云、公有云或者混合云上。

Kubernetes属于主从的分布式集群架构，包含Master和Nodes。Master作为控制节点，调度管理整个系统；Nodes是运行节点，负责运行应用。Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器（Container）、存储资源（Volume）、一个独立的网络IP以及管理控制容器运行方式的策略选项。

" width="803">

Kubernetes的主要功能包括：

• 资源调度：资源调度是一套分布式系统最基本的核心指标

• 资源管理：控制Pod对计算资源、网络资源、存储资源的使用

• 服务发现：管理外在的程序或者内部的程序如何访问Kubernetes里面的某个Pod

• 健康检查：监控检测服务是否正常运行非常重要

• 自动伸缩：因为涉及到环境的快速迁移和复制，虚拟机时代之前都非常难实现。容器化时代很自然的解决了这个问题，Kubernetes保证了资源的按需扩容

• 更新升级：Kubernetes为服务的滚动和平滑升级提供了很好的机制

Kubernetes使用案例：滚动发布

下面我们举一个Kubernetes的应用场景，帮助大家更好的理解Kubernetes的用途。

应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、灰度发布（金丝雀发布）和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。

在微服务架构盛行的时代，用户希望应用程序时时刻刻可用，为了满足不断变化的新业务，需要不断升级更新应用程序，有时可能需要频繁的发布版本。实现"零停机"、“零感知”的持续集成和持续交付/部署应用程序，一直都是软件升级换代必须面对的难题和追求的理想方式，也是DevOps诞生的目的。

滚动发布/滚动更新（Rolling Update Deployment）是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级成为新版本。在整个滚动发布期间，保证始终有可用的副本在运行，从而平滑的发布新版本，实现零停机、用户零感知，是云原生时代非常主流的发布方式。

下图是滚动发布的流程示意图，Load Balance是前端的负载均衡器，橙色是正在运行旧版本服务的节点，紫色是正在更新及更新完毕新版本服务的节点。

" width="1080">滚动发布流程示意图

可以看到，滚动发布开始后（Step 2），负载均衡器将服务器A从集群里摘除，服务器A进行新版本的发布，由服务器B和服务器C对外提供版本1.0的服务；Step 3，服务器A更新完毕，部署验证成功，负载均衡器将其加入集群，开始和服务器C一起对外提供不同版本的服务，同时服务器B开始发布；直至服务器ABC全部发布完成（Step 5），服务都更新到最新的2.0版本。

滚动发布的优点是用户无感知，平滑过渡，同时不需要冗余服务器，节省资源。不足是部署时间慢，取决于每阶段的更新时间；发布策略较复杂；同时涉及自动化的更新策略、部署验证、回滚机制等等，自动化程度比较高，通常需要复杂的发布工具支撑，而Kubernetes正好可以完美的支持这个任务。

Kubernetes通用的编排模式是控制循环，用伪代码表示如下：

" width="587">

解释一下，Kubernetes集群本身状态就是实际状态，而期望状态来自于用户提交的配置文件。滚动发布的时候，Kubernetes将会根据这个控制循环，使用一个叫做Deployment的控制器，通过创建新的集群（下图中的v2版本ReplicaSet复制集）将其控制的Pod副本从0个逐渐变成3个，与此同时旧的集群（下图中v1版本的ReplicaSet）管理的Pod副本数则从3个逐渐变成0个，以此将一个集群中正在运行的多个Pod交替的逐一升级，实现滚动发布的效果。

如果在发布刚开始的时候，集群里只有1个新版本的Pod，这个Pod有问题启动不起来，那么滚动发布就会停止，开发和运维可以及时介入解决问题。而应用本身还有旧版本的集群和Pod在线，所以服务不会受到任何影响。关于滚动发布的详细介绍和互动教程可以阅读这里。

" width="451">

下面这张图展示了使用Kubernetes，配合代码仓库GitLab、Docker镜像仓库Harbor、构建工具Jenkins，实现自动化的CI/CD流程。

" width="678">

上一部分结束时我们提到，传统IT架构好比传统工厂，容器化好比现代化工厂，而Kubernetes则是智能化的无人工厂，让容器和应用能够高效自动、井然有序的被控制和管理；Kubernetes还实现了服务的抽象、解耦、高扩展、统一调度与集中化管理，例如用户可以专注用同样的方式在不同硬件上的应用，比如GPU节点池和低优先级的CPU节点池。Kubernetes不仅解决了容器的编排问题，让容器应用进入大规模工业生产，更进一步对云原生应用提供了定义规范，CNCF整个技术栈都是围绕Kubernetes建立，所以Kubernetes是云原生生态最重要的基石，可以说“Kubernetes是云原生时代的Linux”，即云原生应用的操作系统。

" width="725">高扩展的Kubernetes：兼容不同的硬件节点 " width="1080">Kubernetes：云原生应用的大规模工业生产

回到本文第一部分，我们曾经用集装箱革命比喻云原生。现在大家已经理解，货船可以类比操作系统，集装箱类比容器，里面装的货物则是一个个的微服务，吊臂、吊桥、起重机等自动化操作设备是Kubernetes，而一整套集装箱的操作方法和流程则是DevOps。所有这些加起来构成了现代PaaS所具备的能力：操作系统、集群管理、应用编排、应用发布、持续集成等等。

" width="549">

容器编排之战

意识到容器编排的重要性，Docker在2014年发布了Docker Swarm（Swarm是蜂群的意思），以一个整体来对外提供集群管理功能，最大的亮点就是全部使用Docker项目原来的容器管理API来完成集群管理。

" width="1080">

同时从2014年底开始，Docker收购了最先提出容器编排概念的Fig项目，并改名为Compose（Compose是作曲的意思），它可以用来组装多容器的应用，并在Swarm集群中部署分布式应用。

" width="1080">

2014年Kubernetes发布之后，为了与Swarm竞争，在容器编排地位取得绝对的优势，Google、RedHat等开源基础设施公司共同发起了CNCF基金会，希望以Kubernetes为基础，建立一个由开源基础设施领域厂商主导、按照独立基金会方式运营的平台社区，来对抗以Docker公司为核心的容器商业生态。

一方面Kubernetes脱胎于Google内部久负盛名的大规模集群管理系统Borg，是Google在容器化基础设施领域十余年实践经验的沉淀和升华，Google利用Kubernetes的架构和设计思想成功将其所有应用（搜索、地图、视频、金融、社交、人工智能）运行在超过100万台服务器、超过80个数据中心，每周的20亿个容器上，所以Kubernetes是唯一具有超过10年以上大规模容器生产使用的技术经验和积淀的开源项目。并且Kubernetes采用了非常优雅的软件工程设计和开源开放的态度，使得用户可以根据自己的使用场景、通过灵活插拔的方式，采用自定义的网络、存储、调度、监控、日志等模块，所以在Github上的各项指标一路飙升，将较为简单、并且生态自闭的Swarm项目远远地甩在了后边。CNCF社区也迅速增加了一系列容器生态的知名工具和项目，大量的公司和初创团队将注意力投向CNCF社区而不再是Docker，CNCF本质上成为了以Kubernetes为核心的生态系统。

企业服务大厂也纷纷加入Kubernetes平台战局，在公有云或者私有PaaS平台上来发展自己的Kubernetes产品。像微软直接找来Kubernetes联合创始人Brendan Burns负责领导Azure容器服务团队，自身的混合云产品Azure Stack也大力支持Kubernetes。IBM同样也靠以Kubernetes为核心的PaaS软件IBM Cloud Private来抢占企业私有云容器平台市场，尤其是微服务的管理需求。很早就支持Kubernetes的Redhat，在2015年推出的OpenShift 3.0版中，不惜放弃自己的容器调度工具，开始支持Kubernetes，现在更成为了支持跨多云、混合云架构，以及裸机、容器和虚拟机的企业级通用应用管理平台。而虚拟化龙头VMware也改为力推主打通吃多家IaaS和Kubernetes集群管理的容器服务软件，甲骨文也在旗下云端服务支持Kubernetes。

" width="1080">

在用户、社区和大厂的支持中，Kubernetes逐步成为企业基础架构的部署标准和新一代的应用服务层。

2016年，面对CNCF的竞争优势，Docker公司宣布放弃现有的Swarm项目，将容器编排和集群管理功能转到Docker项目当中。然而这种改变带来的技术复杂度和维护难度，给Docker项目造成了非常不利的局面。不同于Docker，Kubernetes推进的民主化架构从API到容器运行的每一层，都给开发者暴露出了可扩展的插件机制，鼓励用户通过代码的方式介入每一个阶段。Kubernetes的变革非常有效，很快在整个容器社区中催生出了大量的、基于Kubernetes API和扩展接口的二次创新产品，例如前文提到的Istio等等。Docker公司在Kubernetes社区崛起和壮大后，败下阵来。

2017年，Docker公司将容器运行时部分Containerd捐献给CNCF社区，并在自己主打产品Docker企业版中内置Kubernetes项目，持续了两年的容器编排之争终于落下帷幕，Kubernetes成为了最后的胜利者，而Docker输掉了最关键的一仗，失去了成为云原生时代操作系统的机会。

Docker在最重要的容器编排之战中失败，带给我们的教训包括：

• 开源不等于免费，开源是一种商业模式，一个开源组织和开源项目要想生存下去，最重要的基础就是普遍被使用，不然很快就会被竞争者替代

• 开源技术终将走向商业，包括Docker，必然面临企业市场的挑战

• Docker进入企业级市场，有优势也有劣势，优势是挟Docker的大量开发者，劣势是没有做过企业级市场，开发者市场和企业级市场的做法完全不同

• Docker在竞争中失利，看起来是时机和生态构建的问题，但归根结底是基因和能力问题

此系列文章的前五部分，我们详细介绍了云原生的各种理念和技术。在最后一部分，我们将展开总结和思考，分析云原生时代的机遇与挑战。

第六部分——机会与思考

上文主要介绍了Kubernetes与容器编排之战，本文的最后一部分将系统性的总结云原生能带给我们什么样的未来，相关的创业和投资机会在哪里。

每一次IT产业架构的变革都会带来巨大的机遇和行业洗牌的挑战。过去的三四十年间，IT业经历了多次重大的变革，包括20世纪七八十年代从大型机向小型机的转移、九十年代C/S架构的普及，以及21世纪初互联网的兴起，先后造就了IBM、思科、惠普、Oracle、EMC、SAP等巨头企业。

历次IT技术革命还有个共同特点：无论原有的基础软硬件公司此前有多么牢不可破的垄断地位，一旦不能符合新的IT技术变革的趋势，洗牌在所难免。

现代云计算的浪潮开始于2000年以后，已经造就了VMware、ServiceNow、Salesforce、Shopify等数百亿美金的明星企业，以及无数的独角兽公司。

云计算是通过互联网的方式按需交付基础设施（硬件/服务器）、存储、数据库和各种应用服务，通常这些服务是由AWS、Azure等公有云或者私有云平台提供的。

而云原生是一种理念和架构，用于以针对云环境优化的方式组装上述所有基于云的组件。因此云原生也是一个目的地：对于那些希望实现基础设施和流程现代化，甚至组织文化现代化的企业来说，最终的目标是仔细选择最适合其具体情况的云技术。

" width="899">

要从云计算中获得最佳效果，需要使用云原生架构；云原生的普及又会促进云计算的加速发展。

从统计数据和发展趋势来看，云原生被接受的程度和普及速度正在大大加快，例如下图显示，自从2016年以来容器的使用量每年都在快速上升。IDC预计，到2022年90%的应用程序将采用微服务架构和第三方代码，35%的生产应用程序将诞生于云端。由于容器和敏捷方法的采用，预计2018-2023年间将诞生5亿个新应用程序。由数字化转型，以及接受和采用新技术的需求驱动，云原生将更深入地渗透到大型企业组织中。这意味着云原生技术和方法可能会遵循敏捷和DevOps的模式，越来越多地吸引更多的利益相关者，包括管理者和业务线领导人，在未来几年内覆盖一半或更多的组织。

" width="728">各种场景容器使用量都在逐步上升

但目前不是所有的云计算技术和产品都能很好的满足云原生架构分布式、自动化、轻量化的要求，传统的IT基础设施正在受到越来越大的冲击，例如传统集中式数据库正在逐渐被分布式数据库所取代，虚拟机技术受到了容器的巨大冲击，分布式监控系统完全替代了传统的监控产品，而传统的安全产品也远远无法满足云原生安全性的要求。

还需要注意的是，云原生的概念不仅仅只意味着容器、Kubernetes或Serverless，也为下一项技术留下了足够的空间。

云原生投资的分层

对于大多数软件开发组织来说，仍然处于采用微服务和容器的早期阶段。新机遇一方面源自于云原生在各行各业的应用，一方面则是云原生相关新的基础设施。

CNCF全景图呈现了比较完整的云原生项目和分类，我们可以将其简化成如下图所示的几种大的分类：

" width="730">

一共分为AppDev & DevOps；Management；Runtimes；Infrastructure and Services；Serverless；Observability；Security八个大的模块。

从广义的角度来讲，云原生应用的设计、开发、管理、运维、分析与传统应用有非常大的不同，生态的每个环节、技术的每个领域都会有许多机会，例如云原生应用的设计、咨询、开发、培训，需要有方案商、供应商、实施商；在基础设施层面，数据库、开发工具、核心中间件、安全产品等等都会有巨大市场需求，例如Service Mesh+安全、Serverless+安全、容器+安全、多云+安全，例如云原生数据的分析处理，例如云原生架构的灾备管理。

我个人将云原生的生态分为三层：

• 技术层

技术层包括云原生技术相关的基础设施，主要分为两种类型：

1、原有技术的替代品：例如ETCD取代传统的数据库

2、全新基础设施：新技术相关产品，例如Istio和OpenFaaS

• 应用层

应用层主要是云原生在各行业的具体应用。

• 服务层

包括云原生相关的培训、咨询、认证等相关服务。

下面我重点讲讲技术层和应用层。

云原生技术层

下面的表格里代表性的列举了云原生技术层的几个领域及相关项目。

" width="782">

下图展示了当前这些项目的市场占有率情况。

" width="714"> " width="713"> " width="778">

可以看到技术层涉及的范围非常广，机会非常多，本文仅展开介绍其中我比较看好的一个领域-云原生安全。

据CNCF统计，采用容器技术的挑战中，开发团队面临的文化挑战、安全性、复杂性、就绪性和监控分别排在前五位。

" width="733">使用容器的挑战

在云原生架构中，安全问题显得尤其突出的原因有以下几点：

1、快速迁移到云原生架构对企业安全状况和运营产生了深远的影响。在容器、微服务和编排框架的世界中，以持久“状态”运行在“服务器”上的“应用程序”的概念已经过时。现在，该应用程序或服务是一个分布式系统，由多个组件组成，这些组件运行在数量可变的节点上，处于几乎恒定的变化状态。依赖于机器隔离和可预测的系统状态的传统安全控制是无效的。对服务到服务的通信视而不见的安全策略以及缺乏水平可扩展的控件，根本无法跟上当今微服务应用程序的步伐。

2、随着企业将工作负载从数据中心转移到AWS、Google Cloud Platform和Microsoft Azure，它们已经改变了购买安全性的方式。他们需要独立于平台的安全工具，这样就不会被绑定到特定的云平台中。

3、复杂系统可以创建大量的警报和事件日志，这会是一项惊人的任务。安全项目被堆积如山的繁忙工作所淹没，分析师们疲惫不堪。随着分析师对惊人的数据量变得不敏感，真正的问题就从他们的手指间溜走了。

4、DevOps是一种协作方法，它将开发人员和IT操作统一起来，以加快应用程序的构建、测试和部署，它也影响了IT安全。当开发人员可以直接将他们的应用程序部署到生产服务器上，因为业务敏捷性需要它时，他们就不能停下来找出安全问题。DevOps提供了一种完全不同的安全方式，安全自动化有很多机会。

为了在云本机环境中保护业务资产，组织必须将安全实践和技术与它们要保护的系统纳入体系结构中。正如DevOps支持持续开发和部署一样，“DevSecOps”也必须支持持续的安全管道。这意味着要建立全新的方法、功能和工具，以确保旨在保护云原生系统的解决方案呈现以下基本特征：

• 全局的实时可见性：局部的或事后的可见性是不够的。无论位于何处，基础架构层和应用程序都必须可见。

• 快速、迭代的反馈循环：反馈循环允许安全措施不断适应快速变化的环境。

• 解决安全问题的工程方法：自动化、连续测量和受控实验将是解决整个企业安全问题的主要方法，取代手动分析和控制更新。

因此，像Netflix、Lyft和Square等组织已经开始将云原生安全作为工程问题来处理，使用自动化来避免这些陷阱，并使安全团队更加有效。他们还规避了将检测、响应和开发团队分开的烟囱式结构，在构建安全检测机制并将它们与响应编排集成时遵循DevOps的思想。

" width="1080">来自Netflix的安全检测组件示例

Kubernetes官网上认为云原生的安全分为4C，即代码、容器、集群、云四个层级。

" width="1080">

CNCF全景图中安全与合规子分类里包含的项目如下图所示。

" width="1080">

像在我多篇文章里曾经提及的新一代云安全公司，市值189亿美金的CrowdStrike，直接将自己定义为云原生的端点保护平台（Cloud-Native Endpoint Protection Platform），以此同传统的端点保护产品区分开来。

" width="786">

下面我介绍几家和云原生安全相关的初创企业。

1、Capsule8（B轮）

Capsule8是一家由经验丰富的黑客和安全企业家创建的高新科技初创型企业，总部位于纽约布鲁克林，成立于2016年秋季，在2018年8月获得1500万美元的B轮融资。

Capsule8开发了业界第一个也是唯一一个针对Linux的实时0day攻击检测平台，可主动保护用户的Linux基础设施免受攻击。Capsule8实时0day攻击检测平台可显著改善和简化当今基础架构的安全性，同时为未来的容器化环境提供弹性的支持。

混合云架构已经成为企业IT基础设施的重要架构，但其复杂性也使企业面临多种攻击的风险，根据Capsule8与ESG Research赞助的一项新研究表明，仅2017一年就有42%的企业报告了混合云环境受到攻击，28%的企业表示0day攻击是这些攻击的起源。

混合云环境由于存在多云服务商，缺乏中心控制和完整的合规性规划，存在边界模糊，访问策略不一致等问题，加上公有云的暴露面增大，攻击者容易通过攻击薄弱点进入，这也是近年来如软件定义边界SDP、移动目标防护MTD等新方案兴起的原因。

无论是传统环境，还是混合环境，防护利用0day漏洞的高级威胁需要企业安全团队全方位持续防护资产、获得环境的可视性，检测恶意行为。

Capsules8平台整体架构图如下所示：

" width="896">

假设客户生产环境是一个混合云环境，服务器部署于客户侧数据中心、公有云AWS和Azure中。Capsule8的整个工作流程主要分为感知、检测、阻断、调查四步。

" width="740"> " width="800">

2、Aqua Security（C轮）

Aqua Security成立于2015年，它为基于容器、Serverless和云原生应用提供保护解决方案。2019年，Aqua Security完成了6200万美金的C轮融资，累计融资超过1亿美元。它的客户包括能源、航空航天、互联网、媒体、旅游、零售、制药和酒店业的100多家知名企业。

Aqua Security的云原生安全平台使用现代化的零接触方法来检测和预防威胁，在整个应用程序生命周期内提供全面的可见性和安全自动化。例如在漏洞管理方面，Aqua可以实现：

扫描镜像和功能：Aqua几乎与所有CI/CD工具集成在一起，可在构建镜像和功能时主动扫描，及早发现问题并允许快速修复。

关注应用风险：下一个挑战是大规模提供安全性。这种情况是指可能要扫描成千上万个镜像的漏洞。但是，其中许多镜像实际上并未在生产中部署，因此即使处于脆弱状态风险也不高。Aqua提供了对正在运行的工作负载中易受攻击组件的实例化的可见性，这使安全团队可以集中精力修复最容易遭受利用风险的那些组件。

提供可行建议：Aqua提供了有关漏洞的具体可行建议，通常是建议升级到特定的版本或者改变配置和环境变量。

" width="1000">

3、Twistlock（被收购）

位于CNCF全景图里的Twistlock创立于2015年。曾经在以色列著名的网安黄埔8200部队服役，并在微软企业安全部门工作的Ben Bernstein以不到30万美元的种子轮开始起家，定位容器安全。Twistlock自己贴的标签除了容器安全，就是云原生安全。Twistlock的融资节奏很好，2015年5月天使轮280万美元，2016年7月A轮1000万美元，2017年4月B轮1700万美元，2018年8月C轮3300万美元，2019年就被Palo Alto Networks以4.1亿美金的价格收购。

" width="831">Twistlock产品界面

现在，Twistlock已经能为Amazon ECS、Azure、Docker、GCP、Pivotal、OpenShift、Istio等多个平台提供安全方案。Twistlock的自己一句话介绍是“领先的全栈，全生命周期容器安全解决方案，保护容器环境及其中运行的应用程序，具有轻量级，可扩展和自动化特性，自动化的策略构建和全开发生命周期内的无缝集成”。

截至目前，Twistlock总结了6方面的核心能力，分别是漏洞管理、合规、运行时防护、持续集成和持续交付、云原生防火墙和访问控制。像运行时防护包括网络和应用程序防火墙，支持Docker和AWS Fargate运行安全以及主机防护，可以通过机器学习为每个应用程序进行自动建模，保护网络，文件系统，进程和系统调用。云原生防火墙方面，Twistlock包括3层防火墙和7层防火墙，它可以自动学习应用程序的网络拓扑，并为所有微服务提供应用程序的微分段，可以检测和阻止XSS攻击、SQL注入等威胁，还可以自动模拟所有微服务之间的所有流量，并允许安全团队集中查看和实施安全流量，同时自动阻止异常，无需手动创建和管理规则。

除了云原生安全领域，以及前文介绍过的Kong、RapidAPI之外，我再介绍三家知名的云原生技术层创业企业。

1、Rancher（D轮）

在本文第一部分我们提过Rancher（中文意思是放牧人）这家公司，它的创始人梁胜职业生涯贯穿软件开发与云计算的发展历史。作为耶鲁大学计算机博士、Java语言J2SE平台核心组件JNI的作者、JVM的领导设计与开发者，梁胜2000年离开Sun创办了应用防火墙软件公司Teros Networks并担任CTO，2001年公司被Citrix收购。2008年梁胜第二次创业创建了 http://Cloud.com，并推出了著名的云计算管理软件CloudStack，他也因此被誉为“CloudStack之父”，2011年 http://Cloud.com被Citrix又以2亿美金收购，他成为Citrix首位华人CTO。随后2014年梁胜创立了容器管理公司Rancher Labs。这是他创建公司的初衷。

" width="831">

Rancher是一个容器管理平台，通过Rancher可以实现Docker和Kubernetes的轻松部署。Rancher由基础设施编排、容器编排与调度、应用商店、企业级权限管理组成。下图展示了Rancher的主要组件和功能。

" width="1080">

今年3月份，Rancher对外公布了4000万美元的D轮融资，由此Rancher累计融资高达9500万美元。

2、HashiCorp（E轮）

HashiCorp（简称为Hashi，日语“桥梁”的含义）是我一直非常看好的一家云原生技术企业，不过最近因为禁止中国企业使用其商业产品而被刷屏。它成立于2012年，主要开发DevOps和云管理基础设施相关产品，日裔创始人及CTO Mitchell Hashimoto从12岁就开始创业，目前年仅30岁，公司主要产品都出自于他的手笔。

" width="1080">

HashiCorp旗下包含多款知名的云原生相关开源产品，我们自上而下的来看：

• Nomad：程序自动化，集群管理器和调度器，专为微服务和批量处理工作流设计。与Kubernetes相比，Nomad通用性更强。

• Vault：安全自动化，企业级私密信息管理工具。

• Terraform：基础架构自动化，安全有效地构建、更改和版本控制基础设施的工具。

• Packer：镜像工具，旨在通过简易的方式自动化构建镜像。

• Vagrant：用于创建和部署虚拟化开发环境的工具，由Mitchell Hashimoto在23岁时开发，并成为其创建HashiCorp的基石。

• Consul：网络自动化、服务网格解决方案，它提供了一个功能齐全的控制平面，主要功能包括服务发现、健康检查、键值存储、安全服务通信、多数据中心等等。

今年3月HashiCorp对外公布了1.75亿美元的E轮融资，投后估值为51亿美元。

3、Snowflake（G轮）

Snowflake成立于2012年，创始人Bob Muglia曾在微软工作23年，拥有丰富的数据库经验。Bob Muglia认为，NoSQL型数据库并不能完全适应业务要求，基于云端的数据仓库省去了相关软硬件的设置需要，降低了使用门槛。Snowflake包括数据引擎在内的几乎所有技术都是自己研发的，在数据库和数据处理方面拥有非常多的专利，它是一个云原生的SQL数据仓库，完全针对云计算特点设计，部署在AWS等云端平台上，可以将用户所有的数据集中在一个地方，用户只需加载数据然后运行查询就可以查找到各种结构化或半结构化的数据。

为什么要使用云原生数据仓库？

作为一个类别，云原生的数据仓库提供了许多好处。首先，它们使公司摆脱了对设备和机器的担忧：在过去的物理服务器时代，公司需要操心服务器机房，或者至少是运行软件或存储数据的特定机器。构建这个物理基础设施是启动或扩展软件公司的一个巨大障碍。现在，服务器成本要低得多，只需点击几下鼠标就可以创建云端数据仓库。公司只需要按需处理和存储数据，并为他们使用的东西付费。云的使用还可以为公司提供更多的冗余和支持，因为他们不再需要担心单个服务器的故障和整个操作的崩溃。大型云服务提供商拥有多个备份系统，可以在全球数据中心之间自动扩展，以保持一切正常运行。这对客户公司来说是双赢的。

" width="757">

作为一个基于云的数据仓库，Snowflake具有很强的灵活性和可伸缩性。Snowflake基于订阅的模型将存储和计算服务分离，允许它们独立运行。当用户构建插入Snowflake的新解决方案时，他们只支付存储数据或根据需要分析数据的费用。此外，该系统还构建了一个相互连接的云服务器阵列，将数据分散，允许组织内的单个用户或组访问他们需要的特定数据，而无需复杂的数据传输，简化了连接和分析。

对于云原生数据仓库来说，能够在不影响底层的情况下快速查询数据并使用实时数据执行分析是一个强大的功能。由于数据不断地被各种各样的系统所创建，其中许多系统最初都是云端固有的，因此实时分析这些数据的能力对现代公司至关重要。实时分析会根据需要，只对特定实例和项目收费而不产生更高的成本。

Snowflake在今年2月份完成了4.79亿美元的G轮融资，估值高达124亿美元，投资机构包括Salesforce Ventures，Snowflake还由此宣布了与Salesforce的战略合作伙伴关系。Snowflake在《福布斯》最新的“云100强”榜单中位列第二，仅次于Stripe。

云原生技术层的机会我还在《信天研报 | 虚拟化与超融合（一）》系列里提到过，由于容器技术对于传统虚拟机的冲击，众多创业公司正在解构VMware，这将在该系列详细讨论。

云原生应用层

云原生能广泛应用在所有的行业，并发挥其快速、灵活、弹性、扩展性强、迁移能力强等多种优势。在这里我仅抛砖引玉，分析下云原生游戏的优点。

围绕云游戏的许多讨论都集中在其“杀死控制台”的潜力上，从而消除了本地硬件玩游戏的需求。但是，对硬件的持续关注未能抓住云游戏的真正潜力。云游戏的真正创新不仅仅在于我们怎么玩游戏方式，还在于我们玩什么游戏：“云原生”游戏将完全颠覆游戏体验本身，以及这些游戏的销售和销售方式。

云原生游戏是专门为云开发的游戏，其中客户端和服务器托管在同一架构中，有可能产生全新的游戏体验和商业模式。

病毒式传播

大多数MMO（Massively Multiplayer Online，大型多人在线）游戏具有固有的网络效应，这意味着与更多玩家一起玩游戏会更加有趣。然而，MMO通常会遇到冷启动问题：一开始，没有足够的参与者来创造积极的体验，从而导致新用户的流失。与朋友合作玩耍是最好的招募和留住新用户的方式，但是在此过程中可能会遇到很多障碍。例如，用户可以在不同时间或在不同平台上玩。由于不透明的配对规则和服务器限制，在游戏中寻找朋友可能很麻烦。

利用云原生开发的MMO游戏本质上是跨平台的，因此可以从任何设备上访问。没有下载、安装，或者加载时间，用户不用再为了补丁或者一个游戏的副本需要等待三个小时。

为了简化入门过程，云原生游戏可以使用深层链接来无缝地允许新玩家加入朋友的游戏会话。同时，想要获得更轻松体验的用户可以实时选择确切的时点来参加比赛或作为旁观者。

这些支持云的功能共同加速了多人游戏固有的网络效果。如果成功的话，第一个云原生MMO游戏可能会完全通过玩家主导的招募而快速发展，其病毒增长曲线比传统的MMO更类似于Facebook。

创造视频营销机会

除了更强大的病毒性之外，云原生游戏还将为AAA（3A大作，高成本、高体量、高质量）游戏提供新的营销形式。传统上AAA游戏依赖于广告牌和展示广告等营销方式。在没有安装时间的情况下，潜在玩家将能够单击链接立即尝试一款游戏—这是一个巨大的进步。

随着云游戏的普及，视频和有影响力的营销将变得越来越重要。销售佣金和“点击加入”可能会成为云游戏经济中网络大V收入的最大来源。

实现AI驱动的实时内容生成

由于客户端和服务器在同一个网络中，云原生游戏可以方便的跟踪和收集用户旅程中几乎所有的数据，这使得我们可以以开创性的方式在游戏中增强人工智能和机器学习能力。

例如，游戏长期以来通过出售改变玩家外观或周围世界的化妆品来赚钱。由于云提供无限的数据、处理能力和最小的客户端-服务器延迟，人工智能可以实时生成完全动态的环境。以下是基于Nvidia深度学习系统的剪辑，显示用户在AI的帮助下修改了一个逼真的虚拟环境：

" width="1024">

将来，实时内容生成可能会催生新的、沉浸式的故事讲述方法。下一代的“选择你自己的冒险”可能是一个虚拟世界，实时适应你的选择。为了使这些虚拟世界货币化、个性化，自发性的广告可能会出现，类似于《少数派报告》中的生物识别广告。

更远的未来，AI驱动、程序生成的世界可以为用户提供一个无尽的游乐场，那时距离《头号玩家》里的绿洲世界或者著名的网络世界-元界（Metaverse）已经不远。

预计我们将在两三年内看到第一款云原生游戏上市，在谷歌、微软、亚马逊和其他许多公司的投资推动下，下一代云原生游戏将有潜力重塑我们所知道的游戏体验。

在上述认知的推动下，A16Z、腾讯、淡马锡投资了免费沙盒MMO游戏Roblox 1.5亿美金的G轮，相应估值高达40亿美元，他们认为未来游戏将不再只是游戏，甚至将比电影和音乐加在一起的规模还大。游戏的发展也将推动技术革新，而Roblox作为世界上最大的社交平台和多人游戏平台之一，接下来将有望成为未来的Metaverse。

写在最后

至此，这篇接近4万字的《云原生时代》已接近尾声。

我们再来梳理下本文的核心观点：

• 云原生、中台、微服务、CI/CD、Devops、SaaS背后的理念是一致的

• 即更快速、更灵活、更轻量、更自动，从开发开始，不断实现企业的产品目标和业务目标

• 类似理念涉及的维度包括开发、产品、运维、销售，从产品、服务到组织结构

如何判断云原生技术层的项目？

• 是否拥有核心技术是关键

• 单点产品的价值和延展性要足够强。参照Rancher、HashiCorp、Kong

• 面向客户提供一整套产品化的解决方案具有更大价值

• 在云原生体系里，开源项目比普通商业项目更占优势。开源项目更容易被其它产品支持和集成；云原生架构早期使用者以开发者为主，开源项目更容易快速建立口碑和影响力；在社区支持下，开源项目质量更容易得到保证

• 尽量选择成熟和被市场验证的技术和产品

国内的创业机会是否已经到来？

国内已经出现了像PingCap、Kylin、SkyWalking、Dubbo、ServiceComb等优秀的开源项目，在云原生技术不断成熟和普及、国内开源文化和社区逐渐兴起、去IOE和自主可控的时代背景下，国内对标海外的创业机会将会不断涌现。不过由于国内企业IT水平参差不齐，像API集成、API管理等领域的创业时机尚早，所以选择合适的产品切入点和行业将成为成败的关键，另外团队对软件本质的理解、销售和客户服务能力也是相当重要的因素。

最后，我真心希望未来3到5年中国新一代的基础软件企业能够高举国产化的大旗，灯火辉煌。

参考文档：

本文的部分内容参考或者引用以下文章，在此表示感谢，如果有涉及知识产权的问题，请联系我及时修改。

绿盟科技： RSA2019创新沙盒 | Capsule8：混合环境中的实时0day攻击检测、朔源和响应平台

被Palo Alto 4.1亿美元收购的Twistlock是一家什么公司？

DETECTION ENGINEERING FOR CLOUD-NATIVE SECURITY

The Promise of Cloud-Native Games

15 Most Interesting Cloud Native Trends From The CNCF Survey

一文搞懂蓝绿发布、灰度发布和滚动发布

深入剖析Kubernetes学习笔记：“控制器”模型（16）

技术专栏 | 云原生应用之路

极简Docker和Kubernetes发展史

Docker生态到底会不会重蹈Hadoop的覆辙

金丝雀发布、滚动发布、蓝绿发布到底有什么差别？关键点是什么？

10分钟看懂Docker和K8S

极简Docker和Kubernetes发展史

“中台不就是微服务吗？有啥区别？”

火热的云原生到底是什么？一文了解云原生四要素！

大神告诉你如何理解微服务框架

Service Mesh 和 API Gateway 关系深度探讨

一文详解微服务架构

Martin Fowler关于微服务的原文翻译（一）

微服务架构的理论基础 - 康威定律

A text interpretation of the cloud native (rpm)

走访了十几家美国企业服务公司，我们写下了这篇万字文章

从Uber微服务看最佳实践如何炼成？

Mashape 和 RapidAPI 合并，组成全球最大的应用编程接口（API）集市！

放弃微服务，改用宏服务，Uber 这波什么操作？

腾讯大牛深入浅出详解云原生

Service Mesh 和 API Gateway 关系深度探讨

【零壹视界】从Salesforce收购Mulesoft说起，白话讲讲企业数据交换

EnjoyingSoft之Mule ESB开发教程第一篇：初识Mule ESB

微服务架构

持续集成、持续交付、持续部署

What is Cloud-Native? Is It Hype or The Future of Software Development?

A text interpretation of the cloud native (rpm)

RabbitMQ实现即时通讯居然如此简单！连后端代码都省得写了？

Wed, 14 Oct 2020 00:56:41 CST

SpringBoot实战电商项目mall（40k+star）地址： github.com/macrozheng/…

摘要

有时候我们的项目中会用到 即时通讯功能，比如电商系统中的客服聊天功能，还有在支付过程中，当用户支付成功后，第三方支付服务会回调我们的回调接口，此时我们需要通知前端支付成功。最近发现RabbitMQ可以很方便的实现 即时通讯功能，如果你没有特殊的业务需求，甚至可以不写后端代码，今天给大家讲讲如何使用RabbitMQ来实现 即时通讯！

MQTT协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（publish/subscribe）模式的 轻量级通讯协议，该协议构建于 TCP/IP协议上。MQTT最大优点在于，可以以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。

MQTT相关概念

Publisher（发布者）：消息的发出者，负责发送消息。
Subscriber（订阅者）：消息的订阅者，负责接收并处理消息。
Broker（代理）：消息代理，位于消息发布者和订阅者之间，各类支持MQTT协议的消息中间件都可以充当。
Topic（主题）：可以理解为消息队列中的路由，订阅者订阅了主题之后，就可以收到发送到该主题的消息。
Payload（负载）；可以理解为发送消息的内容。
QoS（消息质量）：全称Quality of Service，即消息的发送质量，主要有 QoS 0、 QoS 1、 QoS 2三个等级，下面分别介绍下：
- QoS 0（Almost Once）：至多一次，只发送一次，会发生消息丢失或重复；
- QoS 1（Atleast Once）：至少一次，确保消息到达，但消息重复可能会发生；
- QoS 2（Exactly Once）：只有一次，确保消息只到达一次。

RabbitMQ启用MQTT功能

RabbitMQ启用MQTT功能，需要先安装然RabbitMQ然后再启用MQTT插件。

首先我们需要安装并启动RabbitMQ，对RabbitMQ不了解的朋友可以参考《花了3天总结的RabbitMQ实用技巧，有点东西！》；
接下来就是启用RabbitMQ的MQTT插件了，默认是不启用的，使用如下命令开启即可；

   rabbitmq-plugins enable rabbitmq_mqtt
复制代码

开启成功后，查看管理控制台，我们可以发现MQTT服务运行在 1883端口上了。

MQTT客户端

我们可以使用MQTT客户端来测试MQTT的即时通讯功能，这里使用的是 MQTTBox这个客户端工具。

首先下载并安装好 MQTTBox，下载地址： workswithweb.com/mqttbox.htm…

点击 Create MQTT Client按钮来创建一个MQTT客户端；

接下来对MQTT客户端进行配置，主要是配置好协议端口、连接用户名密码和QoS即可；

再配置一个订阅者，订阅者订阅 testTopicA这个主题，我们会向这个主题发送消息；

发布者向主题中发布消息，订阅者可以实时接收到。

前端直接实现即时通讯

既然 MQTTBox客户端可以直接通过RabbitMQ实现即时通讯，那我们是不是直接使用前端技术也可以实现即时通讯？答案是肯定的！下面我们将通过 html+javascript实现一个简单的聊天功能，真正不写一行后端代码实现即时通讯！

由于RabbitMQ与Web端交互底层使用的是WebSocket，所以我们需要开启RabbitMQ的MQTT WEB支持，使用如下命令开启即可；

   rabbitmq-plugins enable rabbitmq_web_mqtt
复制代码

开启成功后，查看管理控制台，我们可以发现MQTT的WEB服务运行在 15675端口上了；

WEB端与MQTT服务进行通讯需要使用一个叫 MQTT.js的库，项目地址： github.com/mqttjs/MQTT…

实现的功能非常简单，一个单聊功能，需要注意的是配置好MQTT服务的访问地址为：ws://localhost:15675/ws

   html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Titletitle>
head>
<body>
<div>
    <label>目标Topic：<input id="targetTopicInput" type="text">label><br>
    <label>发送消息：<input id="messageInput" type="text">label><br>
    <button onclick="sendMessage()">发送button>
    <button onclick="clearMessage()">清空button>
    <div id="messageDiv">div>
div>
body>
<script src="https://unpkg.com/mqtt/dist/mqtt.min.js">script>
<script>
    //RabbitMQ的web-mqtt连接地址
    const url = 'ws://localhost:15675/ws';
    //获取订阅的topic
    const topic = getQueryString("topic");
    //连接到消息队列
    let client = mqtt.connect(url);
    client.on('connect', function () {
        //连接成功后订阅topic
        client.subscribe(topic, function (err) {
            if (!err) {
                showMessage("订阅topic：" + topic + "成功！");
            }
        });
    });
    //获取订阅topic中的消息
    client.on('message', function (topic, message) {
        showMessage("收到消息：" + message.toString());
    });

    //发送消息
    function sendMessage() {
        let targetTopic = document.getElementById("targetTopicInput").value;
        let message = document.getElementById("messageInput").value;
        //向目标topic中发送消息
        client.publish(targetTopic, message);
        showMessage("发送消息给" + targetTopic + "的消息：" + message);
    }

    //从URL中获取参数
    function getQueryString(name) {
        let reg = new RegExp("(^|&)" + name + "=([^&]*)(&|$)", "i");
        let r = window.location.search.substr(1).match(reg);
        if (r != null) {
            return decodeURIComponent(r[2]);
        }
        return null;
    }

    //在消息列表中展示消息
    function showMessage(message) {
        let messageDiv = document.getElementById("messageDiv");
        let messageEle = document.createElement("div");
        messageEle.innerText = message;
        messageDiv.appendChild(messageEle);
    }

    //清空消息列表
    function clearMessage() {
        let messageDiv = document.getElementById("messageDiv");
        messageDiv.innerHTML = "";
    }
script>
html>
复制代码

接下来我们订阅不同的主题开启两个页面测试下功能（页面放在了SpringBoot应用的resource目录下了，需要先启动应用再访问）：
- 第一个订阅主题 testTopicA，访问地址：http://localhost:8088/page/index?topic=testTopicA
- 第二个订阅主题 testTopicB，访问地址：http://localhost:8088/page/index?topic=testTopicB
之后互相发送消息，让我们来看看效果吧！

在SpringBoot中使用

没有特殊业务需求的时候，前端可以直接和RabbitMQ对接实现即时通讯。但是有时候我们需要通过服务端去通知前端，此时就需要在应用中集成MQTT了，接下来我们来讲讲如何在SpringBoot应用中使用MQTT。

首先我们需要在 pom.xml中添加MQTT相关依赖；

   
<dependency>
    <groupId>org.springframework.integrationgroupId>
    <artifactId>spring-integration-mqttartifactId>
dependency>
复制代码

在 application.yml中添加MQTT相关配置，主要是访问地址、用户名密码、默认主题信息；

   rabbitmq:
  mqtt:
    url: tcp://localhost:1883
    username: guest
    password: guest
    defaultTopic: testTopic
复制代码

编写一个Java配置类从配置文件中读取配置便于使用；

   /**
 * MQTT相关配置
 * Created by macro on 2020/9/15.
 */
@Data
@EqualsAndHashCode(callSuper = false)
@Component
@ConfigurationProperties(prefix = "rabbitmq.mqtt")
public class MqttConfig {
    /**
     * RabbitMQ连接用户名
     */
    private String username;
    /**
     * RabbitMQ连接密码
     */
    private String password;
    /**
     * RabbitMQ的MQTT默认topic
     */
    private String defaultTopic;
    /**
     * RabbitMQ的MQTT连接地址
     */
    private String url;
}
复制代码

添加MQTT消息订阅者相关配置，使用 @ServiceActivator注解声明一个服务激活器，通过 MessageHandler来处理订阅消息；

   /**
 * MQTT消息订阅者相关配置
 * Created by macro on 2020/9/15.
 */
@Slf4j
@Configuration
public class MqttInboundConfig {
    @Autowired
    private MqttConfig mqttConfig;

    @Bean
    public MessageChannel mqttInputChannel() {
        return new DirectChannel();
    }

    @Bean
    public MessageProducer inbound() {
        MqttPahoMessageDrivenChannelAdapter adapter =
                new MqttPahoMessageDrivenChannelAdapter(mqttConfig.getUrl(), "subscriberClient",
                        mqttConfig.getDefaultTopic());
        adapter.setCompletionTimeout(5000);
        adapter.setConverter(new DefaultPahoMessageConverter());
        //设置消息质量：0->至多一次；1->至少一次；2->只有一次
        adapter.setQos(1);
        adapter.setOutputChannel(mqttInputChannel());
        return adapter;
    }

    @Bean
    @ServiceActivator(inputChannel = "mqttInputChannel")
    public MessageHandler handler() {
        return new MessageHandler() {

            @Override
            public void handleMessage(Message message) throws MessagingException {
                //处理订阅消息
                log.info("handleMessage : {}",message.getPayload());
            }

        };
    }
}
复制代码

添加MQTT消息发布者相关配置；

   /**
 * MQTT消息发布者相关配置
 * Created by macro on 2020/9/15.
 */
@Configuration
public class MqttOutboundConfig {

    @Autowired
    private MqttConfig mqttConfig;

    @Bean
    public MqttPahoClientFactory mqttClientFactory() {
        DefaultMqttPahoClientFactory factory = new DefaultMqttPahoClientFactory();
        MqttConnectOptions options = new MqttConnectOptions();
        options.setServerURIs(new String[] { mqttConfig.getUrl()});
        options.setUserName(mqttConfig.getUsername());
        options.setPassword(mqttConfig.getPassword().toCharArray());
        factory.setConnectionOptions(options);
        return factory;
    }

    @Bean
    @ServiceActivator(inputChannel = "mqttOutboundChannel")
    public MessageHandler mqttOutbound() {
        MqttPahoMessageHandler messageHandler =
                new MqttPahoMessageHandler("publisherClient", mqttClientFactory());
        messageHandler.setAsync(true);
        messageHandler.setDefaultTopic(mqttConfig.getDefaultTopic());
        return messageHandler;
    }

    @Bean
    public MessageChannel mqttOutboundChannel() {
        return new DirectChannel();
    }
}
复制代码

添加MQTT网关，用于向主题中发送消息；

   /**
 * MQTT网关，通过接口将数据传递到集成流
 * Created by macro on 2020/9/15.
 */
@Component
@MessagingGateway(defaultRequestChannel = "mqttOutboundChannel")
public interface MqttGateway {
    /**
     * 发送消息到默认topic
     */
    void sendToMqtt(String payload);

    /**
     * 发送消息到指定topic
     */
    void sendToMqtt(String payload, @Header(MqttHeaders.TOPIC) String topic);

    /**
     * 发送消息到指定topic并设置QOS
     */
    void sendToMqtt(@Header(MqttHeaders.TOPIC) String topic, @Header(MqttHeaders.QOS) int qos, String payload);
}
复制代码

添加MQTT测试接口，使用MQTT网关向特定主题中发送消息；

   /**
 * MQTT测试接口
 * Created by macro on 2020/9/15.
 */
@Api(tags = "MqttController", description = "MQTT测试接口")
@RestController
@RequestMapping("/mqtt")
public class MqttController {

    @Autowired
    private MqttGateway mqttGateway;

    @PostMapping("/sendToDefaultTopic")
    @ApiOperation("向默认主题发送消息")
    public CommonResult sendToDefaultTopic(String payload) {
        mqttGateway.sendToMqtt(payload);
        return CommonResult.success(null);
    }

    @PostMapping("/sendToTopic")
    @ApiOperation("向指定主题发送消息")
    public CommonResult sendToTopic(String payload, String topic) {
        mqttGateway.sendToMqtt(payload, topic);
        return CommonResult.success(null);
    }
}
复制代码

调用接口向主题中发送消息进行测试；

后台成功接收到消息并进行打印。

   2020-09-17 14:29:01.689  INFO 11192 --- [ubscriberClient] c.m.mall.tiny.config.MqttInboundConfig   : handleMessage : 来自网页上的消息
2020-09-17 14:29:06.101  INFO 11192 --- [ubscriberClient] c.m.mall.tiny.config.MqttInboundConfig   : handleMessage : 来自网页上的消息
2020-09-17 14:29:07.384  INFO 11192 --- [ubscriberClient] c.m.mall.tiny.config.MqttInboundConfig   : handleMessage : 来自网页上的消息
复制代码

总结

消息中间件应用越来越广泛，不仅可以实现可靠的异步通信，还可以实现即时通讯，掌握一个消息中间件还是很有必要的。如果没有特殊业务需求，客户端或者前端直接使用MQTT对接消息中间件即可实现即时通讯，有特殊需求的时候也可以使用SpringBoot集成MQTT的方式来实现，总之消息中间件是实现即时通讯的一个好选择！

项目源码地址

github.com/macrozheng/…

本文 GitHub github.com/macrozheng/… 已经收录，欢迎大家Star！

全球印钞时代：钱，是如何印出来的？

Fri, 18 Sep 2020 10:03:05 CST

徐瑾：印钱就是货币的扩张。法币时代，钱更多不是央行印的，而是商业银行创造的。按照货币内生观点，不是存款创造贷款，而是贷款创造存款。

上次《徐瑾经济人》专栏，我们谈到在现代信用货币时代，货币的本质就是信用。

信用这个词，就意味着货币可以无中生有。那么我们总在谈的印钞或者印钱，究竟是怎么回事？一张张的纸甚至符号，如何对应价值？

众所周知，早期货币是金银这样的贵金属，而早期银行家，其实许多出身金匠。而最早的纸币或者钞票，其实是银行券的一种。所谓银行券，也就是银行发行的一种票据，用这个票据，你可以按照纸面上的面值多少，拿它兑换多少贵金属。比如英格兰银行发展早期，发行100磅的银行券，当时随时可以拿到银行里去兑换成价值100磅的贵金属。这也是为什么，很多纸币单位都是来源于重量。

刚开始，有多少银行券就有多少的贵金属的对应储备。随后，在17世纪，欧洲出现了存款准备金制度，这意味着什么？这意味着银行得到了解放，可以创造出更多的钱。比如，银行只需有50块钱的储备金，他就可以放出去100块钱银行券的贷款。这个，其实就是一个货币扩张的过程。所以银行的作用很大，可不仅仅是发钞，还有放贷。而且，通过发钞放贷，以前的50块钱的准备金，可以倍增为100块钱的贷款，这样银行就创造了新的货币。下面我详细地告诉你这一行为的结果。

今天这个时代，属于法币时代，也就是“法定货币”时代。简单说，就是我们的主要货币也就是纸币，是国家以法律形式赋予其强制流通使用的货币。

放在中国的情况，不少读者可能就说，印钞嘛，就是央行开动印钞机，刷刷钞票就出来了。或者央行某个人，敲几下键盘，钱也就多了。这个，真没有那么简单。

确实，我们在用的纸币，表面看起来，都是央行在发行。但是你要注意，货币，并不仅仅是纸币。我们的货币很多时候不是现金的形式，而是银行账目上的数字。一种观点认为，央行只是决定了其中一部分，甚至是被动地接受。我比较赞同这种观点，为什么这样说？这个时代，其实也是信贷经济的时代，也就是说银行的存款和贷款，在推动经济。存款和贷款，就是货币，而且是货币的主力。我们理解印钞，就需要从它们入手。

先看过去主流的看法，是因为我们存款，所以银行有钱了，去贷款给企业；这样就制造出新的贷款，这叫做存款创造贷款。这种看法很主流，也很符合直观想象，但是其实不完全正确。真实情况是如何的？一些研究发现的，可能是和我们直觉相反的。

在现实中，往往是我们贷款了，银行贷款给我们，我们往往不会以现金方式拿走，而是付给另外一家公司或者一个人。这样，他们的账户上，就会自然多出一部分存款——这就是贷款创造存款。这样银行通过贷款，就可以源源不断制造出信贷与存款，也就是货币，无论你叫他广义货币M2还是社会融资总额这些名词。关于这方面，你有兴趣的话，可以去看看人民银行孙国峰博士的研究。

这个问题的关键就在于，我们是否贷款，贷款多少，决定了银行提供多少信贷，也间接决定了有多少货币。

在过去，经济学家往往认为是货币是中性的，也就是对经济运行没啥用，就是个记录价格的符号。于是，银行也是一个中性的机构，一个中转站而已。现在看起来，货币不简单，贷款不简单，银行也不简单。在现代经济中，货币的扩张，主要是由银行在推动。在今天，很多人，对于货币的感觉还是来自贵金属时代，认为银行可以存款或者印钞创造货币。其实，从上面的分析可以看出，银行的钱或者经济中的货币，不是印刷出来的，而是通过贷款，源源不断地创造出来的。

中央银行，往往决定一国货币政策。但是一国货币多少，不是央行一家说了算。中国的央行就是人民银行，美国的央行就是美联储，一般每个国家的中央银行，只有一家。但是注意到么，存款贷款的商业银行，却有很多家。你家门口的商业银行，比如工行建行或者城商行，有很多。货币，正是这些商业银行制造的。

一说到印钱，背锅侠就是央行。过去很多人认为，印钞票啊或者印钱啊，这只是中央银行的事。通过上面的分析，你可以看出，事情没有那么简单。确实，央行可以控制一部分货币，但是大多数货币，不是人民银行这样的中央银行印出来的，而是普通的商业银行在贷款的过程中创造出来的。

所以你，老百姓说的印钱，其实就是货币的扩张。到了人民币的时代，也就是所谓法币时代，含义和过去有些不一样。我们平常老说印钱。其实，钱更多不是央行印出来的，而是商业银行系统创造的。更准确地说，是银行体系响应大家的贷款需求，也就是实体经济需要，创造出更多信贷，间接创造更多货币。

这个理论，这也是货币内生理论的立场。早在1931年在《货币论》中，经济学家凯恩斯就指出，货币供给，并不是央行可以自行决定的。这个思想，主流不太重视。但是，很多后凯恩斯主义学者发挥了这个思想。在大印钞时代的，这些思想更应该得到重视

（本文为作者货币系列之一，仅代表作者本人观点。更多可见作者公号《徐瑾经济人》，ID：econhomo）

日本新电影中的爱情：低欲望时代，激情与倦怠的二元对立 - 文化 - 新京报网

Sun, 31 May 2020 07:45:51 CST

撰文｜黄依琳

近年来，日本出品了不少表现青年人爱情纠葛的电影，并且这些不同的作品之间存在着某种互相对照、解答、补充，甚至是情绪蔓延的互文。

比如今泉力哉以片名《爱情是什么》提出的诘问，其他导演可以直接用片名来回答。对于过眠症和躁郁症的女孩来说，爱情是病症的解药，《只有爱能让我生存》；在少男少女飘忽不定的选择障碍中爱情不过是《热情花招》；在夏日函馆的两个男生眼里，爱情是《你的鸟儿会唱歌》；又或者女孩疲于在长相相似的挚爱和替代者之间游离，爱情恐怕就是《睡着也好，醒来也罢》

（《夜以继日》直译）

。

爱情和理性相互拒斥，这些电影往往诉诸于人的内心活动，情绪的千变万化，一瞬间的感觉以及触发的联想，却也难得真切、本能、自然。有趣的是，这些向观众坦白真心的以爱为名，事实上是从恋爱生活的各个细枝末节和蛛丝马迹里，寻找质疑和解构爱情的证据。人与社会，人与他人，人与自己的关系越发显得复杂微妙，充满着谜题。爱情对于我们的生命体验来说，是积极还是消极的意义。不管爱情的结果是成功还是失败，我们是否从中获取了修正未来的方式。抛出疑问的同时，这些电影也试着给出解答。

无处可逃中匮乏的激情

一边“3·11”地震的遗留伤痕还困扰着当下社会，另一边东京奥运会的到来给日本经济同时带来了压力和期盼。在多重矛盾的夹缝中：安保法案、高自杀率、少子高龄化、核泄漏辐射等社会问题频出。

一般来说，对社会困境的表现往往会成为某种意识形态的演绎，但在近年来的日本电影创作中，很多作者似乎脱离了历史和社会的重负，不把个人纳入政治与历史的视野，不试图代表“人民的良心”，反而更关注人与人之间微妙的情感关系。

当下的日本社会，人们的关系普遍变得疏离，大多数青年选择降低欲望，自我隔离。日本管理学家、“策略先生”大前研一在《低欲望社会》中描写当代日本年轻族群：“现今的日本社会，青年人正在自发性地降低欲望，同时孤独与压抑成为弥漫日本社会的情绪。”

《低欲望社会： “丧失大志时代”的新·国富论》，作者：[日]大前研一，译者：姜建强，版本：上海译文出版社2018年10月

这种情绪在电影中的表达首先是对空间的描绘。空间作为人类精神需求的反映，从来不是独立存在的。人们的情感并不依附于某个具体的意象，往往存在于整个空间所营造的情境。

《热情花招》由少女漫画改编，讲述一位高中女生在四个爱慕她的少年中游离的故事。电影在东京的靠海区域豊洲拍摄。为了迎接东京奥运会，豊洲在短短的十年间变成了高楼林立，兼具温泉、酒店、美食街等观光设施的商业旅游区。导演山户结夕与摄影师交涉，要把这里拍成森林的感觉，无处不在的高级公寓群落给少男少女的内心带来强烈的压抑感。少女数次坐在公寓的楼梯间为了爱情垂头丧气，镜头运动跟随着她的心境在公寓间游荡，扭曲建筑四周的超广角镜头仰拍，高楼仿佛随时倒塌。

《热情花招》剧照，豊洲的高级公寓。

不安的背后是当代人欲望的匮乏，对所居住的空间无所期待。城市与城市之间越来越趋向于同质化，这些电影在东京、大阪、京都等不同城市拍摄，却很难分辨其中的差别，即便是拍摄《你的鸟儿会唱歌》的北海道小城市函馆，高速发展的经济也将它与大城市的区别消除。从一座城市到另一座城市，人们原本充满着向往，却陡然发现日本的各个角落都一样，无处可逃。只能在无法获取存在感的角落里游荡，激情消耗，疲惫不堪。

仿佛是一种镜像关系，生存空间的紧张可以通过私人关系的紧张折射出来。滨口龙介的《夜以继日》对这种无所遁逃的窘境做了一个精妙的比喻。女主角朝子在大阪的牛肠茂雄摄影展上与麦相遇，一见钟情。相处几个月后，麦失踪了再也没有回来。两年后朝子在东京遇见了与麦长相极为相似的亮平，还是在牛肠茂雄摄影展上，亮平与朝子的关系更进一步。五年后，亮平与朝子已经开始安稳的生活，麦的突然出现打破了宁静的日常。不管在大阪还是东京，麦的身影始终如同鬼魅萦绕在朝子生活的上空，宿命一般无处可逃。

后来朝子坐上了麦的车，汽车行驶在忽明忽暗的灯光中，没有具体明确的缘由，朝子的激情突然褪去，她离开了麦，回到大阪寻找亮平。如果说激情的褪去是《夜以继日》的结尾，那么在其他电影中，激情的匮乏往往伴随着故事的开端。年轻人的行为很少由激情驱动，没有激情的爱情，也变成可有可无的存在。

《你的鸟儿会唱歌》的开始，在街头游荡的“我”，默念120下终于等到了喜欢的女孩出现。他们相约稍晚在酒吧约会。令人意想不到的是“我”回到家中倒头就睡，半夜醒来错过了约会，他也不过是随口说了一句脏话，并没有放在心上。又或者在《只有爱能让我生存》里，女主角宁子抑郁、嗜睡、暴躁，连准时上班也无法做到。她的男朋友每天买便当回家安静地吃饭，对宁子的任何情绪毫无反应，伤心也好，责骂也罢，只会回答“嗯”。

《只有爱能让我生存》剧照

更有甚者，对恋爱抱有激情的行为会引来他人的嗤之以鼻。在消费主义至上的商品社会，感性层面的谈情说爱被当做是对工作效率的阻碍。《爱情是什么》中，一切以喜欢的男生为中心的女孩小照，为了与对方长时间待在一起故意旷工。她的同事无法理解：“现在很少有人为了男人而被炒鱿鱼了，人们都没法和自己的意中人相遇，这样世界才能运转得起来啊”。

既然爱情无法唤醒激情，人们为何还要寻找恋爱的对象呢？在《冰淇淋与雨声》中，导演松居大悟试图做出解释。女主角的弟弟青木佑认为任何负面情绪都可以依靠时间来解决，生活不过是吃饭、洗澡、呼吸、睡觉。他可以在酒吧里和朋友畅饮，虽然没有女朋友，但一切都很好，心情一百分的美妙。一旦聚会结束，突然袭来的空虚感便会令他感觉非常糟糕，胸口疼，呼吸也不顺畅。他突然想要谈恋爱，要抓住哪怕是稍纵即逝的情感。青木佑的恋爱冲动不过是利用他人来帮助填补自身的匮乏与空虚，这样并不能获得幸福，也不是真正的爱情。

自恋主体的爱情花招

韩炳哲在他的著作《爱欲之死》中提出，真正的爱欲是消除和牺牲自我，肯定他者。所谓的他者，指的是恋爱关系中，与自我截然不同又兼具不可抵挡诱惑力的另一半。当下无差别成为主流，一切归于整齐划一的秩序之中，他者与自我的差异越来越无法感知与认可。为了获得他者的爱，自我所作出的献祭式爱情更难寻觅，更多的形态是以自我牺牲为表象的自恋。关于爱情的一切显得虚伪、冒失、痛苦又尴尬。

《爱情是什么》提出了值得探讨的一个问题：两性关系中言听计从的一方是被支配者，还是自愿且具有自我意识的主动牺牲者。女孩小照始终没有获得喜欢的男生小守的爱，在这段关系中她舍弃了工作，极度地忘我投入，满足对方所有的要求。甚至为了见到小守，在小守喜欢的女生与小照约见时，她会主动联系小守赴会。在主流的叙事中，悲剧人物会经历一些波折，最后认清自己，走出阴霾，完成人物成长。这部电影并非如此，细节的铺陈为的是给观众展现小照行为背后的逻辑，而她本人并未意识到自己的问题。在影片结尾，她还是那个“病入膏肓”的痴情人，并接受了不肯改变的自己。

《爱情是什么》海报

粗看起来，小照对待爱情的态度的确符合韩炳哲所提出的“爱欲会激发一种自愿的忘我和自我牺牲“。小照与小守的关系，也契合“与他者的非对称关系”，即对方与自我永远存在着不可弥合的差异。小守一日清晨起床去上班，他一边收拾一边给小照介绍自己在杂志社的工作。小照睁大眼睛听着，还是不免走神，小守的声音渐渐模糊远去。她与他不在一个频道，她也不曾为了与小守靠近而努力进入他的世界。她所做的所有事情不过是不去上班，等待小守的电话，频繁地重游两人曾去过的地方，沉浸在自我的世界里。小照迷恋的与其说是小守，不如说是自己在恋爱中的状态，到底是一种以自我满足为目的的自恋。

影片的倒数第二场戏，小照与小守挥手告别，挎着新认识的帅哥胳膊离开。最后一场戏却来了一个情节上的大反转，小照站在动物园里，给大象喂食。她的内心独白这样说：“我完成了33岁的小守没能完成的愿望，现在我终于可以成为他了”。原来，她已经彻底不与现实中的小守产生关联，自顾自地进入了一个更加封闭更加忘我的全新自恋境界。

自我牺牲的爱欲不是以自我的消亡作为终点。在坠入爱河忘记自我之后，是自我变强的感觉，通过痴恋对方来重塑人生，找回一个更好的自我。虽然小照通过绝对的忘我、接纳和付出，完成了对自我的否定，也重新建立起了自身的主体性，换来的却是一个停滞甚至倒退的自我。爱情是两个人共同对抗庸常，互相成就彼此的存在。《一个陌生女人的来信》中“爱是我自己的事，与你无关”的表达和《爱情是什么》的结局一样，终归是不太健康的爱情观。

《你的鸟儿会唱歌》中的“我”对爱情的态度截然相反。“我”是一个活在当下的“草食男”。所谓的“草食男”，源自日本劳动局的一项社会调查，调查发现当今日本青年普遍存在一种现象，他们对社交没有兴趣，工作上没有上进心，觉得恋爱婚姻不过如此。主人公“我”就是这样，他随意旷工，对喜欢的女孩佐知子也毫不上心。佐知子与他的舍友静雄互道晚安，一起去卡拉OK，后来发展到两人独自去山间野营几日不归，“我”也不曾提出异议。

佐知子几经试探，经历了短暂的失望和踟蹰，决定放弃“我”，与静雄开始恋爱关系。“我”的第一反应是“我为你高兴”，依然一副事不关己的样子。不过在最后一幕，人物转变的弧光似乎刚刚出现，“我”出乎意料地跑到已经走远的佐知子面前，第一次也是唯一一次表现出明确的爱慕，佐知子的反应极为复杂，不过并非正面的肯定，既像是“我不相信你，别再为难我了”，又像是“我知道了，可是已经晚了”。“我”在面对佐知子时的支支吾吾和反反复复，的确没有理由让一再失望的佐知子信赖。他冲动的表白很难说清是厌恶损失，还是自恋式的自我满足。不论是何种形态，“我”都难以与牺牲自我的爱欲沾上边。或许在第二天，这个活在疲怠社会中的“草食男”就会厌恶麻烦的爱情关系，为前一天的表白后悔。

《你的鸟儿会唱歌》剧照，最后一个镜头定格在佐知子多义的表情中

佐知子的爱情是另一种形态的自恋，她被爱情的圈套与花招迷惑，游走在几个男人之间，爱谁看起来都没什么区别。爱情从某种意义上来说，是客观存在的，它天生充满着各种不确定，不基于人们的努力和能力而存在。包含着快乐，也孕育着痛苦。在当下信息发达的社会，人们可以轻易地同时与多位异性建立情感关系，也可以方便地转换和回避分离带来的痛苦，只剩下积极的满足与享用。尽管佐知子曾寄希望于“我”，但是当她感觉到痛苦时，可以很迅速地转移目标到静雄身上。甚至在与“我”发生关系的同时，佐知子还做着书店店长的情人。

《夜以继日》中的女孩朝子也面临着相似的困境，她在两个长相酷似的男人中左右徘徊，做出逃避痛苦的最终选择后，真爱也荡然无存。导演滨口龙介师承《咒怨》系列的导演黑泽清，用奇怪的配乐、昏暗的色调，辅以演员僵化的表情共同营造出诡异的气氛。这种诡异更像是朝子在回溯这段记忆的口吻，因为爱情的幻影无时无刻不在左右她、干扰她、影响她的选择，所以在讲述的过程中必然支支吾吾、胆战心惊、语焉不详。

如果说影片的前面三分之二，朝子面对的选择题是一见钟情和日久生情之间的二元对立。那么，在朝子当着现任的面跟着前任出逃，而后又“不知廉耻”地回到现任身边时，朝子所要解决的是另一个问题。幻梦戳破，信任崩塌，不再以爱为名欺骗现任后，应该基于什么样的态度生活下去。面对眼前的生活，朝子自我宽恕 “这条河真脏，但是很美”。即便已经道歉，朝子的脸上也不曾有过谢罪的表情。爱情的彻底消亡已经昭然若揭，剩下的不过是极端自私的相互依赖，各取所需而已。

《夜以继日》剧照，全片时常笼罩在鬼魅的气氛之下

承认无能为力，向死而生

爱可以战胜一切，在主流的日本电影里，总是看到这样的表述。但是和生命的无常一样，爱情充满着不确定。在日本新生代的电影中，往往有着类似契科夫小说的结尾：失望、犹豫、彷徨、痛苦，却又包含着些许的希望。

从同名职场剧改编的电影版《从宫本到你》并非是原剧的简单压缩，它抽离了表现宫本大学毕业后遇到的各种具体的社会困境，转而展现在原剧中较弱的情感线。然而，在宫本与婧子恋爱为主轴的电影版中，宫本个人的境遇与社会的冲突作为副线，依然可以通过这段关系的起承转合而得到较为恰当的展现。甚至彼此之间产生了关系紧密的对照，是不可或缺的一部分。

在社会角色上，宫本是一个唯唯诺诺的失败者，面对上司和球队教练的无理要求和谩骂，宫本总是点头哈腰，极尽奉承。但是在心爱的女人婧子面前，当她的前男友闯入房间打闹时，宫本可以大声喊出“让我来保护你”的豪言壮语。可是当真正的危机到来，球队教练的儿子拓马强奸婧子，醉酒的宫本倒在旁边的床上呼呼大睡。为了复仇，宫本在社会角色上的孱弱立刻改变，他几次找到拓马格斗，每次都是赤手空拳，毫不畏惧对方的实力，似乎抱着必死的决心。即便牙齿漏风，手臂被折断，也不曾畏惧。可是宫本却无法再直视婧子，他一再逃避，躲起来哭哭啼啼。

宫本对待拓马和女友前后态度的翻转，折射出一个可悲的事实。他人的尊重，工作的成功，社会地位的提高等，彰显的是个人能力，这些或许可以通过不懈的努力获得。而面对爱情，人们恰恰是无能为力的。宫本的呐喊“你是我的女人”、“让我来保护你”，也不过是无法经受住实践检验的漂亮话。因为爱无法与能力等同，不可把握，不可占有。

宫本最后凭借几近动物性的疯狂激情在与拓马的搏斗中终于取得胜利。他骑着自行车将负伤的拓马载到婧子面前，靖子脸上没有感动，她讥讽地反问“所以是什么意思呢？和我有任何关系吗？”宫本也因此不得不承认“我所做的一切都是为了自己”。但以爱情为名的自私，也不见得与爱情不能共处。宫本想要和婧子一起获得幸福的心意是真实的，否则他也不会毅然选择与婧子结婚，甚至共同抚养不知谁是父亲的孩子。也恰恰是宫本不再说大话，坦承自己的无能为力，才动摇了屡次受到伤害的婧子。他们之间终于建立起了平等的关系。共同经历的苦难，成为幸福的契机。

《从宫本到你》剧照，热血、激情、暴戾，这部电影开辟了一种兽性的新暴力美学。

拳头、血液、泪水、嘶吼，宫本的复仇格斗极尽残暴。特别是最后一次，断指、踢裆、撕扯私处、挂在楼梯栏杆上悬空厮打等暴戾场面，辅以血腥特写和长时间的注视，将痛感和不适传递给观众。可以说，宫本的胜利得益于穿越死亡的激情，向死而生的决心和力量，指向爱与死的永恒命题。

《夜空总有最大密度的蓝色》更贴切地展现了当今社会爱与死相互依存的关系。美香是医院的护士，每天都可见到死亡。慎二的工友工作休息时被汽车碾死，另一位工友身体孱弱，疾病缠身。电视新闻也笼罩在死亡的阴霾中，流浪汉、厌世者、吸毒人士，不断有人因为各种理由死亡。活下来的其他人则沉浸在担心无法苟活的焦虑中，毫无生命力。

在事物的消极面，往往存在着积极面得以活跃的基础。萨德曾说：“要想了解死亡是怎么回事，没有把它和纵情欢愉的念头联系在一起更合适的了”。美香和慎二的爱情接近于个体认识到对生死无能为力后，展现出的向死而生的决心。爱欲把他们从自恋的牢狱中解救出来。他们看清了徒劳的生命和没有过往激情的男女关系，竭尽全力投入新的爱之激情中。慎二穿越大半个东京，奔跑着去见美香，言语尽管笨拙，但是爱的渴望彰显着生命的律动。它穿越了生与死，末世与救赎，在东京最大密度的忧虑蓝色中，得以烂漫。

《夜空总有最大密度的蓝色》剧照

健康的爱情需要包容猝不及防的失败、痛苦的体验和无能为力的失落感，承认这些消极性才能在未来的生活中找到定位。《热情花招》里成田茜对着犹豫不决的爱慕对象大方承认：“我知道无法保护你，但是此刻就是想陪在你身边”。又如《只有爱能让我生存》的结尾，躁郁症的宁子与男友倾诉感激之情流下眼泪“或许只有一瞬间，我们理解了彼此，可是那一瞬间，让我觉得真正地活着”。爱情的无能为力是客观存在的，倾诉也好呐喊也罢，都解决不了根本问题，也许明早生活照旧，但把那一瞬间当作永恒的动力，本来就是对未来的忠诚、肯定和期待。因为舍此，别无他法。

作者丨黄依琳

编辑丨余雅琴；张婷

校对丨危卓

GitHub - cnlh/nps: 一款轻量级、功能强大的内网穿透代理服务器。支持tcp、udp流量转发，支持内网http代理、内网socks5代理，同时支持snappy压缩、站点保护、加密传输、多路复用、header修改等。支持web图形化管理，集成多用户模式。

Mon, 12 Aug 2019 09:52:34 CST

nps

nps是一款轻量级、高性能、功能强大的 内网穿透代理服务器。目前支持 tcp、udp流量转发，可支持任何 tcp、udp上层协议（访问内网网站、本地支付接口调试、ssh访问、远程桌面，内网dns解析等等……），此外还 支持内网http代理、内网socks5代理、 p2p等，并带有功能强大的web管理端。

背景

做微信公众号开发、小程序开发等----> 域名代理模式
想在外网通过ssh连接内网的机器，做云服务器到内网服务器端口的映射，----> tcp代理模式
在非内网环境下使用内网dns，或者需要通过udp访问内网机器等----> udp代理模式
在外网使用HTTP代理访问内网站点----> http代理模式
搭建一个内网穿透ss，在外网如同使用内网vpn一样访问内网资源或者设备----> socks5代理模式

安装

releases安装

releases

下载对应的系统版本即可，服务端和客户端是单独的

源码安装

安装源码

go get -u github.com/cnlh/nps...

编译

go build cmd/nps/nps.go

go build cmd/npc/npc.go

使用示例

统一准备工作（必做）

开启服务端，假设公网服务器ip为1.1.1.1，配置文件中 bridge_port为8284，配置文件中 web_port为8080
访问1.1.1.1:8080
在客户端管理中创建一个客户端，记录下验证密钥
内网客户端运行（windows使用cmd运行加.exe）

./npc -server=1.1.1.1:8284 -vkey=客户端的密钥

域名解析

适用范围：小程序开发、微信公众号开发、产品演示

假设场景：

有一个域名proxy.com，有一台公网机器ip为1.1.1.1
两个内网开发站点127.0.0.1:81，127.0.0.1:82
想通过（http|https://）a.proxy.com访问127.0.0.1:81，通过（http|https://）b.proxy.com访问127.0.0.1:82

使用步骤

将*.proxy.com解析到公网服务器1.1.1.1
点击刚才创建的客户端的域名管理，添加两条规则规则：1、域名： a.proxy.com，内网目标： 127.0.0.1:81，2、域名： b.proxy.com，内网目标： 127.0.0.1:82

现在访问（http|https://） a.proxy.com， b.proxy.com即可成功

https:如需使用https请进行相关配置，详见使用https

tcp隧道

适用范围：ssh、远程桌面等tcp连接场景

假设场景：想通过访问公网服务器1.1.1.1的8001端口，连接内网机器10.1.50.101的22端口，实现ssh连接

使用步骤

在刚才创建的客户端隧道管理中添加一条tcp隧道，填写监听的端口（8001）、内网目标ip和目标端口（10.1.50.101:22），保存。
访问公网服务器ip（1.1.1.1）,填写的监听端口(8001)，相当于访问内网ip(10.1.50.101):目标端口(22)，例如： ssh -p 8001 root@1.1.1.1

udp隧道

适用范围：内网dns解析等udp连接场景

假设场景：内网有一台dns（10.1.50.102:53），在非内网环境下想使用该dns，公网服务器为1.1.1.1

使用步骤

在刚才创建的客户端的隧道管理中添加一条udp隧道，填写监听的端口（53）、内网目标ip和目标端口（10.1.50.102:53），保存。
修改需要使用的内网dns为127.0.0.1，则相当于使用10.1.50.202作为dns服务器

socks5代理

适用范围：在外网环境下如同使用vpn一样访问内网设备或者资源

假设场景：想将公网服务器1.1.1.1的8003端口作为socks5代理，达到访问内网任意设备或者资源的效果

使用步骤

在刚才创建的客户端隧道管理中添加一条socks5代理，填写监听的端口（8003），保存。
在外网环境的本机配置socks5代理(例如使用proxifier进行全局代理)，ip为公网服务器ip（1.1.1.1），端口为填写的监听端口(8003)，即可畅享内网了

http正向代理

适用范围：在外网环境下使用http正向代理访问内网站点

假设场景：想将公网服务器1.1.1.1的8004端口作为http代理，访问内网网站

使用步骤

在刚才创建的客户端隧道管理中添加一条http代理，填写监听的端口（8004），保存。
在外网环境的本机配置http代理，ip为公网服务器ip（1.1.1.1），端口为填写的监听端口(8004)，即可访问了

私密代理

适用范围：无需占用多余的端口、安全性要求较高可以防止其他人连接的tcp服务，例如ssh。

假设场景：无需新增多的端口实现访问内网服务器10.1.50.2的22端口

使用步骤

在刚才创建的客户端中添加一条私密代理，并设置唯一密钥secrettest和内网目标10.1.50.2:22
在需要连接ssh的机器上以执行命令

    ./npc -server=1.1.1.1:8284 -vkey=vkey -type=tcp -password=secrettest -local_type=secret

如需指定本地端口可加参数 -local_port=xx，默认为2000

注意：password为web管理上添加的唯一密钥，具体命令可查看web管理上的命令提示

假设10.1.50.2用户名为root，现在执行 ssh -p 2000 root@1.1.1.1即可访问ssh

p2p服务

适用范围：大流量传输场景，流量不经过公网服务器，但是由于p2p穿透和nat类型关系较大，不保证100%成功，支持大部分nat类型。 nat类型检测

假设场景：内网1机器ip为10.1.50.2 内网2机器2 ip为10.2.50.2

想通过访问内网1机器1的2000端口---->访问到内网2机器3 10.2.50.3的22端口

使用步骤

在 nps.conf中设置 p2p_ip（nps服务器ip）和 p2p_port（nps服务器udp端口）
在刚才刚才创建的客户端中添加一条p2p代理，并设置唯一密钥p2pssh
在机器1执行命令

    ./npc -server=1.1.1.1:8284 -vkey=123 -password=p2pssh -target=10.2.50.3:22

如需指定本地端口可加参数 -local_port=xx，默认为2000

注意：password为web管理上添加的唯一密钥，具体命令可查看web管理上的命令提示

假设机器3用户名为root，现在在机器1上执行 ssh -p 2000 root@127.0.0.1即可访问机器2的ssh

web管理

介绍

可在网页上配置和管理各个tcp、udp隧道、内网站点代理，http、https解析等，功能强大，操作方便。

提示：使用web模式时，服务端执行文件必须在项目根目录，否则无法正确加载配置文件

启动

服务端测试

./npstest

如有错误请及时修改配置文件，无错误可继续进行下去

服务端启动

./nps start

如果无需daemon运行或者打开后无法正常访问web管理，去掉start查看日志运行即可

web管理

进入web界面，公网ip:web界面端口（默认8080），密码默认为123

进入web管理界面，有详细的说明

服务端配置文件重载

如果是daemon启动

./nps reload

说明：仅支持部分配置重载，例如 allow_user_login auth_crypt_key auth_key web_username web_password等，未来将支持更多

服务端停止或重启

如果是daemon启动

./nps stop|restart

服务端配置文件

/conf/nps.conf

名称	含义
web_port	web管理端口
web_password	web界面管理密码
web_username	web界面管理账号
bridge_port	服务端客户端通信端口
https_proxy_port	域名代理https代理监听端口
http_proxy_port	域名代理http代理监听端口
auth_key	web api密钥
bridge_type	客户端与服务端连接方式kcp或tcp
public_vkey	客户端以配置文件模式启动时的密钥，设置为空表示关闭客户端配置文件连接模式
ip_limit	是否限制ip访问，true或false或忽略
flow_store_interval	服务端流量数据持久化间隔，单位分钟，忽略表示不持久化
log_level	日志输出级别
auth_crypt_key	获取服务端authKey时的aes加密密钥，16位
p2p_ip	服务端Ip，使用p2p模式必填
p2p_port	p2p模式开启的udp端口

使用https

方式一：类似于nginx实现https的处理

在配置文件中将https_proxy_port设置为443或者其他你想配置的端口，和在web中对应域名编辑中设置对应的证书路径，将 https_just_proxy设置为false，然后就和http代理一样了

此外：可以在 nps.conf中设置一个默认的https配置，当遇到未在web中设置https证书的域名解析时，将自动使用默认证书，另还有一种情况就是对于某些请求的clienthello不携带sni扩展信息，nps也将自动使用默认证书

方式二：在内网对应服务器上设置https

在 nps.conf中将 https_just_proxy设置为true，并且打开 https_proxy_port端口，然后nps将直接转发https请求到内网服务器上，由内网服务器进行https处理

与nginx配合

有时候我们还需要在云服务器上运行nginx来保证静态文件缓存等，本代理可和nginx配合使用，在配置文件中将httpProxyPort设置为非80端口，并在nginx中配置代理，例如httpProxyPort为8024时

    server {
    listen 80;
    server_name *.proxy.com;
    location / {
        proxy_set_header Host  $http_host;
        proxy_pass http://127.0.0.1:8024;
    }
}

如需使用https也可在nginx监听443端口并配置ssl，并将本代理的httpsProxyPort设置为空关闭https即可，例如httpProxyPort为8024时

    server {
    listen 443;
    server_name *.proxy.com;
    ssl on;
    ssl_certificate  certificate.crt;
    ssl_certificate_key private.key;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    location / {
        proxy_set_header Host  $http_host;
        proxy_pass http://127.0.0.1:8024;
    }
}

关闭代理

如需关闭http代理可在配置文件中将http_proxy_port设置为空，如需关闭https代理可在配置文件中将https_proxy_port设置为空。

将nps安装到系统

如果需要长期并且方便的运行nps服务端，可将nps安装到操作系统中，可执行命令

    (./nps|nps.exe) install

安装成功后，对于linux，darwin，将会把配置文件和静态文件放置于/etc/nps/，并将可执行文件nps复制到/usr/bin/nps或者/usr/local/bin/nps，安装成功后可在任何位置执行

    nps test|start|stop|restart|status

对于windows系统，将会把配置文件和静态文件放置于C:\Program Files\nps，安装成功后可将可执行文件nps.exe复制到任何位置执行

    nps.exe test|start|stop|restart|status

流量数据持久化

服务端支持将流量数据持久化，默认情况下是关闭的，如果有需求可以设置 nps.conf中的 flow_store_interval参数，单位为分钟

注意：nps不会持久化通过公钥连接的客户端

系统信息显示

nps服务端支持在web上显示和统计服务器的相关信息，但默认一些统计图表是关闭的，如需开启请在 nps.conf中设置 system_info_display=true

自定义客户端连接密钥

web上可以自定义客户端连接的密钥，但是必须具有唯一性

关闭公钥访问

可以将 nps.conf中的 public_vkey设置为空或者删除

关闭web管理

可以将 nps.conf中的 web_port设置为空或者删除

服务端多用户登陆

如果将 nps.conf中的 allow_user_login设置为true,服务端web将支持多用户登陆，登陆用户名为user，默认密码为每个客户端的验证密钥，登陆后可以进入客户端编辑修改web登陆的用户名和密码，默认该功能是关闭的。

用户注册功能

nps服务端支持用户注册功能，可将 nps.conf中的 allow_user_register设置为true，开启后登陆页将会有有注册功能，

监听指定ip

nps支持每个隧道监听不同的服务端端口,在 nps.conf中设置 allow_multi_ip=true后，可在web中控制，或者npc配置文件中(可忽略，默认为0.0.0.0)

server_ip=xxx

代理到服务端本地

在使用nps监听80或者443端口时，默认是将所有的请求都会转发到内网上，但有时候我们的nps服务器的上一些服务也需要使用这两个端口，nps提供类似于 nginx proxy_pass的功能，支持将代理到服务器本地，该功能支持域名解析，tcp、udp隧道，默认关闭。

即：假设在nps的vps服务器上有一个服务使用5000端口，这时候nps占用了80端口和443，我们想能使用一个域名通过http(s)访问到5000的服务。

使用方式：在 nps.conf中设置 allow_local_proxy=true，然后在web上设置想转发的隧道或者域名然后选择转发到本地选项即可成功。

客户端

客户端启动

无配置文件模式

此模式的各种配置在服务端web管理中完成,客户端除运行一条命令外无需任何其他设置

    ./npc -server=ip:port -vkey=web界面中显示的密钥

配置文件模式

此模式使用nps的公钥或者客户端私钥验证，各种配置在客户端完成，同时服务端web也可以进行管理

    ./npc -config=npc配置文件路径

配置文件说明

示例配置文件

全局配置

[common]server_addr=1.1.1.1:8284conn_type=tcpvkey=123username=111password=222compress=truecrypt=truerate_limit=10000flow_limit=100remark=testmax_conn=10

项	含义
server_addr	服务端ip:port
conn_type	与服务端通信模式(tcp或kcp)
vkey	服务端配置文件中的密钥(非web)
username	socks5或http(s)密码保护用户名(可忽略)
password	socks5或http(s)密码保护密码(可忽略)
compress	是否压缩传输(true或false或忽略)
crypt	是否加密传输(true或false或忽略)
rate_limit	速度限制，可忽略
flow_limit	流量限制，可忽略
remark	客户端备注，可忽略
max_conn	最大连接数，可忽略

域名代理

[common]server_addr=1.1.1.1:8284vkey=123[web1]host=a.proxy.comtarget_addr=127.0.0.1:8080,127.0.0.1:8082host_change=www.proxy.comheader_set_proxy=nps

项	含义
web1	备注
host	域名(http
target_addr	内网目标，负载均衡时多个目标，逗号隔开
host_change	请求host修改
header_xxx	请求header修改或添加，header_proxy表示添加header proxy:nps

tcp隧道模式

[common]server_addr=1.1.1.1:8284vkey=123[tcp]mode=tcptarget_addr=127.0.0.1:8080server_port=9001

项	含义
mode	tcp
server_port	在服务端的代理端口
tartget_addr	内网目标

udp隧道模式

[common]server_addr=1.1.1.1:8284vkey=123[udp]mode=udptarget_addr=127.0.0.1:8080server_port=9002

项	含义
mode	udp
server_port	在服务端的代理端口
target_addr	内网目标

http代理模式

[common]server_addr=1.1.1.1:8284vkey=123[http]mode=httpProxyserver_port=9003

项	含义
mode	httpProxy
server_port	在服务端的代理端口

socks5代理模式

[common]server_addr=1.1.1.1:8284vkey=123[socks5]mode=socks5server_port=9004

项	含义
mode	socks5
server_port	在服务端的代理端口

私密代理模式

[common]server_addr=1.1.1.1:8284vkey=123[secret_ssh]mode=secretpassword=ssh2target_addr=10.1.50.2:22

项	含义
mode	secret
password	唯一密钥
target_addr	内网目标

p2p代理模式

[common]server_addr=1.1.1.1:8284vkey=123[p2p_ssh]mode=p2ppassword=ssh2target_addr=10.1.50.2:22

项	含义
mode	p2p
password	唯一密钥
target_addr	内网目标

文件访问模式

利用nps提供一个公网可访问的本地文件服务，此模式仅客户端使用配置文件模式方可启动

[common]server_addr=1.1.1.1:8284vkey=123[file]mode=fileserver_port=9100local_path=/tmp/strip_pre=/web/

项	含义
mode	file
server_port	服务端开启的端口
local_path	本地文件目录
strip_pre	前缀

对于 strip_pre，访问公网 ip:9100/web/相当于访问 /tmp/目录

断线重连

[common]auto_reconnection=true

nat类型检测

    ./npc nat

如果p2p双方都是Symmetric Nat，肯定不能成功，其他组合都有较大成功率。

状态检查

    ./npc status -config=npc配置文件路径

重载配置文件

    ./npc restart -config=npc配置文件路径

通过代理连接nps

有时候运行npc的内网机器无法直接访问外网，此时可以可以通过socks5代理连接nps

对于配置文件方式启动,设置

[common]proxy_url=socks5://111:222@127.0.0.1:8024

对于无配置文件模式,加上参数

    -proxy=socks5://111:222@127.0.0.1:8024

支持socks5和http两种模式

即socks5://username:password@ip:port

或 http://username:password@ip:port

群晖支持

可在releases中下载spk群晖套件，例如 npc_x64-6.1_0.19.0-1.spk

项	含义
health_check_timeout	健康检查超时时间
health_check_max_failed	健康检查允许失败次数
health_check_interval	健康检查间隔
health_check_type	健康检查类型
health_check_target	健康检查目标，多个以逗号（,）分隔
health_check_type	健康检查类型
health_http_url	健康检查url，仅http模式适用

webAPI

webAPI验证说明

采用auth_key的验证方式
在提交的每个请求后面附带两个参数， auth_key和 timestamp

    auth_key的生成方式为：md5(配置文件中的auth_key+当前时间戳)

    timestamp为当前时间戳

    curl --request POST \
  --url http://127.0.0.1:8080/client/list \
  --data 'auth_key=2a0000d9229e7dbcf79dd0f5e04bb084&timestamp=1553045344&start=0&limit=10'

注意：为保证安全，时间戳的有效范围为20秒内，所以每次提交请求必须重新生成。

获取服务端时间

由于服务端与api请求的客户端时间差异不能太大，所以提供了一个可以获取服务端时间的接口

    POST /auth/gettime

获取服务端authKey

如果想获取authKey，服务端提供获取authKey的接口

    POST /auth/getauthkey

将返回加密后的authKey，采用aes cbc加密，请使用与服务端配置文件中cryptKey相同的密钥进行解密

注意：nps配置文件中 auth_crypt_key需为16位

解密密钥长度128
偏移量与密钥相同
补码方式pkcs5padding
解密串编码方式十六进制

详细文档

此文档近期可能更新较慢，建议自行抓包

为方便第三方扩展，在web模式下可利用webAPI进行相关操作，详情见 webAPI文档

贡献

欢迎参与到制作docker、图标、文档翻译等工作

如果遇到bug可以直接提交至dev分支
使用遇到问题可以通过issues反馈
项目处于开发阶段，还有很多待完善的地方，如果可以贡献代码，请提交 PR 至 dev 分支
如果有新的功能特性反馈，可以通过issues或者qq群反馈

捐助

如果您觉得nps对你有帮助，欢迎给予我们一定捐助，也是帮助nps更好的发展。

互联网时代，你还在讨论如何做好软件测试，我们已经在讨论如何“干掉”测试了

Fri, 05 Jul 2019 17:48:20 CST

记得在半年前，我在 InfoQ 写了一篇“开发要不要自己做测试？怎么做？”的文章，当时引发了很多开发人员以及测试人员的激烈讨论，那篇文章的主旨是介绍如何通过工程效能团队来赋能开发人员自己进行高效率高质量的软件测试，文中介绍了 Google、Facebook 和 eBay 等一线互联网公司正在推行的“没有专职测试，测试工作由开发人员完成（简称去 QE 化）”的全新模式，并从工具链的视角介绍了测试即服务（Test as a Service）的全局架构。

那么今天的这篇文章，我会从另外一个视角再来聊聊互联网领域“干掉”测试这个话题，只不过这次要讨论的话题会更尖锐、更敏感，不再是“干掉专职测试人员，让开发人员自己做测试”，而是尽量“偷工减料”少做测试，甚至压根不做测试的话题。哇塞，这听起来是不是有点离经叛道，有违大众长久以来的价值观。别急，且听我慢慢道来。

软件测试的本质目的

首先，我们来看一下软件测试的本质目的是什么，你可能会不假思索地告诉我说是为了保证软件产品的质量。那我会继续问你，保证软件产品质量的目的又是什么，你可能稍加思索后会说是为了让大部分软件用户满意，给用户递交价值。完全正确，其实这才是软件测试的本质目的所在。这就有点像你去问一个女生你为什么不吃饭，她会告诉你她的目的是减肥，但仔细一想，减肥真的是不吃饭的目的吗，其实真正的目的应该是“变得更漂亮”，明白了这层利害关系后，你会发现为了“变得更漂亮”的方法就有很多选择了，不吃饭减肥只是其中之一。

恰好“够用”的质量

那么怎么才能使用户对软件满意呢？这里有两种截然不同的思路，一个是通过海量的测试尽最大努力保证软件中没有任何缺陷，由于测试本身的不可穷尽性，显然这种做法的代价是及其巨大的；另一种思路是只测试用户所有可能会使用的软件功能，其他的都不测试，也就是说只提供一个恰好能够满足用户需求的软件产品，这种情况下，软件的研发代价是比较低的。

对于企业，如果产品本身不是与人生命息息相关或者金融相关的，你觉得企业会选择哪个思路？

从经济学的角度出发，一定是后者。也就是说一个“好的”软件产品并不是一个完完全全无任何缺陷的产品，而是一个其质量属性刚好满足用户需求的产品，也就是说不追求完美的质量，而是追求恰好“够用”的质量，恰好够用的质量的另一种表述是软件产品在用户使用的整个生命周期中不会发生问题，或者即使发生问题，但带来风险和损失也足够小，但并不是说软件本身没有任何问题。企业从经济学的角度来讲需要以科学的手段来寻求缺陷风险和研发成本之间的动态平衡。

基于风险驱动的“偷工减料”测试策略

鉴于上述的思想的驱动，现在很多互联网产品在确定测试范围的时候，通常会通过日志数据来分析软件系统的历史使用行为，并根据功能的使用频度来决定测试的优先级，那些被大量使用的功能一定会全面测试，而那些不经常使用的功能只会做基本的测试，而那些很少使用的功能在进度压力较大的情况下就会放弃测试。这就是所谓的基于风险驱动的测试策略。

用户使用频度越高，说明这部分功能更能够为用户带来价值，当这部分功能出问题的时候，产生的风险也就越大，那么这部分功能无疑就是需要重点测试的对象。而那些很少使用的软件功能或者场景，就成为了测试中“偷工减料”的对象。需要强调的是，这里的偷工减料是打了引号的，不是说真的偷工减料，而是指在有足够数据支持的前提下以风险驱动的方式合理缩小测试范围。

基于风险驱动的测试策略在微服务测试中的应用

如果我们将基于风险驱动的测试策略应用与微服务架构的测试，就形成了基于消费者契约的 API 测试策略，而这一测试策略的核心思想就是强调只测试那些有实际使用场景的 API 调用，如果没有使用场景的 API 调用就可以压根不做测试。

为了让你更好地理解这种目前微服务架构下非常行之有效的测试策略，我画了下面的图

图 1：Service A、Service B 和 Service T 的关系图

图中的 Service A、Service B 和 Service T 是一个系统中的三个微服务，其中 Service T 是被测试对象，可见 Service T 的消费者（也就是使用者）一共有两个，分别是 Service A 和 Service B。如果按照传统的 API 测试策略，当我们需要测试 Service T 的时候，我们就需要找到所有可能的参数组合依次来对 Service T 进行调用，同时结合 Service T 的代码覆盖率来进一步补充遗漏的测试用例，这样做就会导致测试用例数量很多，工作量过大。那么基于风险驱动的消费者契约 API 测试是怎么做的呢？

首先 Service T 作为服务的提供者，它的使用者在这里是确定的，就只有 Service A 和 Service B，如果能够把 Service A 和 Service B 对 Service T 的所有可能的调用方式都测试到，那么就一定可以保证 Service T 的质量，即使如果存在某些 Service T 的其他调用会有问题，那也不会影响整个系统的功能，原因是系统中没有其他 Service 会以可能出错的调用方式来调用 Service T。这样就以“偷工减料”的方式减少了测试范围，但同时又能够保证软件的质量，可见，这种方式在工程实践中是具有很大实用价值的。至于如何才能有效抓取 Service T 的完整契约，可以参考我的新书《测试工程师全栈技术进阶与实践》第五章中“微服务模式下 API 测试”的内容，技术细节就不在这里展开了。

不做测试直接上线的实际案例

上面我们讲了互联网产品测试过程中如何“少做”测试的实际例子，那么接下来我们再来看看互联网产品测试中更极端的场景：如何不做测试或者只做很少测试的实际案例。什么，不做测试就敢上线发布，如果你是工作在传统软件企业的工程师，这听起来简直就是天方夜谭，完全是想“删库跑路”的节奏啊！但是在互联网企业，这种极端的做法还是有其存在价值的，最开始的时候，这种不测试或者只做很少量测试就立马上线发布的做法是被竞争对手逼出来的，后来却渐渐发现这种方式也有其可取之处，尤其是想以最快的方式发布新功能的时候。

我们来试想一个商业竞争的场景，假定某电商网站 A 发布了为期三天的家电促销活动，并为此上线了新的活动页面以及相关优惠券的功能，那么另外一个电商网站 B 为了与其竞争（网站 B 如果不参与这个竞争，那么这段时间以及后续一段时间内的流量很可能就被网站 A 抢走了），就必须在很短的时间内设计开发并上线能够与网站 A 相竞争的类似优惠功能。由于网站 A 是有备而来，所以网站 A 的功能在上线发布之前已经做了充分的测试，但是网站 B 就很被动了，网站 B 必须在很短的时间内开发出类似的优惠活动功能，如果开发完成后的测试还需要占用较多的时间，那么在商业上就会更被动。

为此，网站 B 会在这种逼不得已的情况下，采用不测试或者只做很少的测试就上线发布的策略，但这个发布的过程会采用灰度发布策略来降低未经充分测试的软件直接上线的风险。具体的做法是这样的：

从应用服务器集群中选择任意一台服务器 (比如图 2 中的 Node N)，然后从负载均衡器中将其注销。
然后将这台服务器的软件升级到最新的未经过测试的软件版本。
接着，将这台服务器注册到负载均衡器中，并且通过配置负载均衡器，只让这台具有新软件版本的服务器接收万分之一的流量。也就是说，只有很少一部分的用户会访问到新的软件版本。
在接下来大概 10-30 分钟的时间里，密切监控这台具有新软件的服务器各项指标以及后台的业务日志。这段时间，相当于在使用真实的用户行为在对新的软件版本进行测试。
如果服务器各项指标正常，后台日志也没有监测到任何异常，那么说明新的软件版本没有问题，接下来就可以部署更多的服务器。如果发现有问题，那么此时就需要立即回滚有问题的新软件版本，但是幸运的是，即使发现有问题，实际受影响的用户也是极少数，同时还准确找到了软件的缺陷。
如果没问题，就会将新的软件版本部署到更多的服务器上，直到应用服务器集群中所有服务器都部署了新版本。

图 2：应用服务器集群灰度发布示意图

总结一下，上述过程实际上利用了灰度发布，在风险可控的情况下，直接利用了真实的用户流量来对新的软件版本进行了测试，因此省去了研发阶段的测试工作量，并且加速了发布的速度。这个就是不做测试的一个极端案例。

由上面的两个例子我们可以发现，在那种场景下采用那种测试策略，完全取决于“发生问题时带来的风险（经济损失）”，“后期问题暴露后修复问题的代价”以及“前期研发过程中投入的测试成本”三者之间的博弈。同时，产品架构设计（微服务或者服务网格等）和 DevOps 实践（灰度发布等）也为测试策略的最优选取提供了更多的可能性。

另外，除了测试策略这种从源头上的优化，在测试设计和执行层面还有很多我们需要面对问题，并在此基础上又很多值得优化的内容以及执行方法上的微创新，其中涉及测试执行环境准备的最佳实践，测试数据准备的最佳实践，从源头保证软件质量的代码级测试，以及性能测试与调优的最佳实践，如果你对这一系列的主题感兴趣，可以关注我的新书《测试工程师全栈技术进阶与实践》，必定让你有所收获。

人工智能时代，传统PM如何快速转型成AI产品经理？

Thu, 13 Jun 2019 10:47:12 CST

随着科技的快速发展，近几年人工智能（AI，Artificial Intelligence）掀起了一阵阵新浪潮。人类从未停止过对人工智能的预想，从1950年图灵发表论文预言创造智能机器人的可能性开始，人类就在人工智能的道路上越走越远。随着计算机性能的提升，人工智能技术将会广泛运用于各行各业，人工智能产品终将会由各种预想慢慢变成现实。

我们逐步经历了PC互联网时代、移动互联网时代，人工智能时代。传统互联网对人类的主要贡献是通过优化和创造信息存储和传递的方式重新组合各种生产要素（即重构了已有商业模式），人工智能的主要贡献是升级生产要素，进而推动产业升级。

来到人工智能时代，传统互联网产品将面临巨大的挑战，那么如何提升自己转型成为AI产品经理呢？

一、了解AI，寻找切入点

1. AI是什么

AI就是利用技术对人的能力和意识进行模仿和超越。

AI产品经理不仅需要像传统产品经理一样设计产品交互和逻辑流程，还需要改变传统产品流程上能用到人工智能技术的能力范围，实现让技术为产品赋能，为企业赋能。AI技术已经广泛运用于多个领域，如自动驾驶、机器人、电商、语音与图像识别、人机交互、智能控制、医疗诊断等。

人工智能产品没有固定的形态，只是一种将传统产品和服务赋能的一种手段，有了人工智能技术，将会使产品逻辑化繁为简，降低用户学习成本，提升产业的商业价值。

无人驾驶汽车通过运用传感器、高精度地图、高级辅助驾驶系统和车联网等关键技术实现无人驾驶，与传统汽车相比，用户不再需要全程关注路面情况手动驾驶而是仅仅需要输入目的地即可。

语音交互产品与传统的鼠标、键盘、触摸屏等交互方式不同，用户通过与产品进行语音对话即可完成唤醒、查询、订购等一系列复杂的人机语音交互操作。

人脸识别身份验证与传统登录需要输入账号、密码、验证码不同，它只需要用户在摄像头前露个脸即可实现快速登录。

2. AI的三要素有哪些

人工智能在图像识别、语音识别、自然语言处理、信息检索、机器翻译、社交网络过滤、精准推荐、智能医疗等方便的广泛应用离不开深度学习。

深度学习在每个应用场景中的落地离不开“算法”“算力”“数据”三要素：

1）AI第一个核心要素：算力

算力就是支撑需求实现的系统架构支撑，可以简单理解为计算能力。评估某个需求的算力需要着重从硬软件多方面去衡量。算力不是瓶颈，因为现在有云计算，但是有成本的考虑因素在里面，算力的成本在整个AI模型中占到了10-20%。

2）AI第二个核心要素：算法

AI常用的算法有：自然语言生成算法（NLG）、语音识别算法、虚拟现实算法、决策管理技术、深度学习、生物特征识别技术、识别图谱、机器学习……

虽然算法在AI行业里大部分是开源的，想拿到什么样的资源都可以拿到，深度学习、多层次神经网络算法目前也都已经比较成熟，但是AI产品经理在做产品设计时，还需要结合公司算法研发能力避免提出过于超前和落后的产品功能。

3）AI第三个核心要素：数据

在机器学习领域，好的数据通常比算法更重要，有些时候没有数据的话，AI模型是不可能成熟落地的。更有算法工程师扬言“数据秒杀一切算法”。既然数据如此重要，产品经理在设计之初就得考虑数据从哪来、数量质量怎么保证、数据治理的工作怎么开展等问题。

3. 寻找适合自己的切入点

应用AI的公司主要有三类：纯AI公司、AI+公司、+AI公司

1）纯AI公司

纯AI公司是做AI的基础层，主要做芯片、云计算、框架等方向。

这类公司从人工智能的底层平台需求出发，构建完整的从人工智能计算平台的硬件单元研发、数据治理、AI建模再到平台部署的人工智能的“基础设施”。这类公司布局一些PaaS形态的基础计算平台和算法平台供其他公司直接调用，减少其他公司的人工智能研发成本和周期。

2）AI+公司

AI+公司是做AI的技术层，主要研究通用技术，如图像识别、语音识别、文本识别等。

3）+AI公司

+AI公司是做“场景行业+AI”，如智能医疗、智能安防等。

传统产品经理需要根据自己擅长的领域和兴趣去有针对性的强化学习，将自己擅长的点发挥到最大。

如果你擅长场景，那么你着重学习一下算法方面，你在应用层+AI企业中，将自己负责的产品赋能上人工智能将实现更大的价值。

如果你是技术出生，机器算法、机器视觉等都懂，则适合去技术层公司或基础层公司发展自己的才能。

除上所述，还有像BAT这些公司，在基础层、技术层、应用层都有企业布局。

二、转变思维模式

传统产品经理的工作协同方式是优化和创造信息存储和传递的方式重新组合各种生产要素。

比如：滴滴打车，传统思维模式是将古老的路边招手即停的打车方式合理的规划让信息准确传递，使用户和司机双方都能进行信息互通，司机可以接自己想接的单子，乘客可以选择自己要打的车型。

人工智能产品经理的工作协同方式是在传统产品经理的基础上实现变革与创新，升级各种生产要素，而不仅仅是生产要素之间重新组合。比如：无人驾驶，不管是半智能、条件智能、高度智能、完全智能，均改变了“司机”这一生产要素，让必须“人类驾驶员全程监控行驶环境”升级为“汽车自动智能监控驾驶环境”。

故要想成为人工智能产品经理并在产品管理工作中变得优秀，就应该改变自己的思维模式。

传统产品经理会将很大一部分经历分配到功能逻辑、流程推敲、页面设计等等事情上，而人工智能产品经理不仅要懂得传统产品经理的功能梳理和交互设计，更需要懂得硬件运算架构、算法模型、数据分析、有效训练数据等综合能力。

所以，人工智能产品经理应该具备系统性思维，把问题放在整个系统中综合分析，权衡利弊，得到最佳解决方案。

1. 资源管理思维

产品经理的工作离不开资源管理，但人工智能产品经理管理的资源将在传统产品经理的基础上进行升级。人工智能产品经理不仅要关注开发人员、时间、成本，还要应该关注算法、数据资源、硬件资源。确保资源的投入产出比最优。

算法：人工智能产品需要进行算法模型的训练和调优时，可能出现预先设计好的硬件架构无法满足算法需求的情况。所以，产品经理需要大致了解算法，学会预估和评测，并且理解开发人员对项目所要求功能的技术复杂性，而不需开发部门投入人力物力与最终的结果产出不匹配。

数据资源：数据资源包括训练集、研发集、测试集等，优质的数据资源是当前机器学习产品中重中之重的一种资源。但是，人工智能产品经理也不用改用追求完美的数据的眼光去获取该资源，而应该在数据获取成本和训练模型效果之前做相应的权衡最终取得一个最优平衡点。

硬件资源：硬件资源包括计算机芯片、存储和构成产品的各种硬件组合。产品经理应该明白各个硬件、系统集成在人工智能产品上的综合表现，而不能出现单项突破而其他必须资源跟不上的情况。

2. 解决方案思维

人工智能时代，用户需要的是一套解决方案，而不是产品本身。产品经理是离市场和运营最近的人，也是最能从用户的角度换位思考的人。所以，产品经理应该具有解决方案思维，把控需求，让人工智能产品整体实践起来更合理最优。

3. 目标导向思维

人工智能产品经理需要培养自己的目标导向思维，人工智能产品大多使用到复杂的算法模型，所以产品对于用户来说大多属于“黑盒产品”。

这种产品的如果没有提前设置量化的目标，然后让架构师按照目标去设计的话，将很难被定义优劣。所以，产品经理应该将目标量化并具有目标导向的思维，严格把控产品从需求调研、产品设计、技术预研、产品研发、测试、上线等全流程。每个流程需要设定明确的成果物、时间节点、标准。

除此之外，还应该有上帝视角，对公司整理的产品架构有清晰的认知，让自己负责的产品的目标不偏离公司的整体战略规划。

三、了解算法并熟悉算法边界

1. 人工智能算法中，机器“大脑”的处理过程

人工智能是让计算机模拟和延伸人的感知（识别）、理解、推理、角色、学习、交流、移动和操作物体的能力。

人工智能产品的实现逻辑都遵循由感知到认知，由识别到理解、决策的逻辑过程。目前人工智能的研究还处于弱人工智能阶段，它仅能通过海量数据的训练和学习，从中识别规律，当新的数据输入时，机器可以根据训练的结果将新数据按照具体的规律进行分类。

所以，目前人工智能产品还是依赖于机器学习，且仅能在某一特定领域的某一特定事务上实现智能。

2. 机器学习的本质

机器学习就如同模拟人类学习一样，只是人类是通过经验积累，而机器是通过大量数据输入算法模型进行学习。

机器学习阶段有：

训练机器阶段：输入海量数据，让计算机模型对数据进行分类，找到规律。
测试阶段：和训练机器阶段中的同质数据集，输入模型，测试每个输出结果是否正确。

3. 算法相关常识

机器学习算法按照不同的训练方式可以分为：监督学习、无监督学习、半监督学习、强化学习四大类。

按照解决任务的不同来分类，大约可以分为：二分类算法、多分类算法、回归算法、聚类算法、异常检测算法五大类。

监督学习：就像教小孩一样，预先训练机器，告诉他这是行人，那是障碍物。通过海量学习后，机器就能将新输入的数据分到对应的类目中。故监督学习的训练集中，所有数据必须有标签，标签正确率越高数据量越大，则训练的效果就越好。
半监督学习：所有数据都标注的成本比较高，有时候将训练数据中混入一部分没有标签的数据，这种学习方式叫半监督学习。
无监督学习：所有数据都没有标签，这种学习没有人为标注，让机器自行从数据中抽取信息，从分布中采样、去噪、寻找数据分布的聚类的学习方式叫无监督学习。
强化学习：让机器通过不断的尝试，试错，从中选择可以得到最大的回报的行动，然后找到规律达成目标的一种学习方法。强化学习与无监督的学习不同在于强化学习有反馈，机器根据反馈不断尝试。
二分类算法：做很多二分类问题时，让机器二选一的算法，如好评还是差评，男还是女……
多分类算法：当问题的答案有多个选项，让机器做多选一的算法。
回归算法：这类算法一般都是定量输出或者连续变量预测。
聚类算法：描述和衡量不同数据源间的相似性，并把数据源分类到不同类中。
异常检测：对样本的标签进行预测，将数据中存在不正常或者非典型的数据进行检测和标注。

四、重视需求，合理规划工作流程

1. 熟悉常用技术逻辑

人工智能产品经理应该熟悉常用的人工智能技术逻辑，关注技术的趋势，领先性，主流算法框架。横向对比竞争对手之间的技术实现手段和重点产品参数，从而提炼自身产品优势，扬长避短。

如语音交互技术：

图片来自diangon.com

人脸识别技术：

图片来自Adaboost

2. 需求分析与产品设计

当前人工智能市场产品中，技术领先但产品认可度较低的情况屡见不鲜，很多用户对新技术的采用并没有强烈的感知，企业在新技术的投入与实现的商业价值不成正比。

造成此类原因为人工智能产品的设计理念和方式落后于技术革新，因此人工智能产品需要从以下方面多考虑：

产品设计应从需求出发而不应该从技术出发。技术驱动的产品，容易脱离市场，偏离用户需求，最终导致用户不买单。
忽略用户期望，华而不实造成用户失望，如索尼Xperia Touch，投影键盘华而不实。
不能在单一方面做的足够好而忽略了整体流程的体验，导致整体解决方案无法让用户满意。
一味追求底层技术而忽略了用户体验的优化。例如视觉体验差，产品交互不流畅，错误率高，隐私保护不全。

人工智能行业常用的设计原则有：

少即是多：站在用户的角度减轻用户的使用门槛，提升交互效率，让用户不动声响的解决问题而没有复杂的功能模块、交互流程、界面元素、配色字体等。
从微观到宏观逐步深入：采用循序渐进的方式，让产品功能迭代逐步让用户接受。
有效整合资源：整合新的资源和技术，将其融入产品设计理念中，让更多的交互方式成为可能，比如语音交互、手势和表情识别等，挖掘用户最自然最习惯的行为方式来设计人工智能产品。
同理心：学会换位思考，与用户产生共鸣并感同身受。如设计老年人产品时，不能让老年人用这个产品感觉到自己已经老了不中用了，产生自卑感从而抛弃购买该人工智能商品。

3. 参与研发过程

参与项目管理：让架构师项目经理等人员按照需求目标设计产品架构并按时完成子任务。
把控数据质量：联合数据分析师，算法工程师一起完成数据获取、清洗、转换、预处理工作，为模型提供优质的数据。
模型训练：紧密配合算法工程师，让模型出现拟合过的时候有针对性的训练数据方面的改良，并随时对模型效果预期做合适的调整。
测试调优：产品经理需要对技术边界和需求量化有比较深的理解，协助测试团队制定测试标准，让产品在上线前按照设定的目标进行交付。
目标管控：在实际研发过程中出现无法达成目标的情况时，需要实时按照实际情况对目标进行调优，降低产品期望。

4. 持续的产品运营

产品上线后，产品经理应当协助运营团队和市场团队对产品做线上的包装、宣传，让产品正常合理的推向市场。

总结

人工智能产品经理的职责还是和传统产品经理一样，负责产品的始终。但是，人工智能时代技术的变革导致人工智能产品发生了颠覆性的变化，产品经理不仅懂得传统产品经理相关知识技能，更应该了解具体行业中人工智能技术在行业中的运用，让人工智能新技术新算法的作用在自己负责的人工智能产品中发挥最优的价值。

所以，产品经理需要积极的学习AI，建立自己的认知体系。让自己融入时代，不被时代淘汰，并让自己成为推动时代发展的巨人。

本文由@九久玖原创发布于人人都是产品经理，未经允许，禁止转载。

题图来自Unsplash, 基于CC0协议。

华为也看不清时代的方向

Sat, 20 Apr 2019 23:27:38 CST

昨天，有人给我看了，在华为内部论坛上的一篇文章，由一线工程师提出，最终抵达任正非处，并转发全公司的一篇反思文。

不得不说，这是非常非常有价值的一篇文章。

国内的企业报道，普遍是事后报道，习惯性的带着上帝视角，“哦，他这里错了”“哦，他们这里做了一个明智的决策”。要么高颂赞歌，要么一味贬低。

华为的这篇文章由一线提出，被最高总裁办转发，之后引起大量讨论，提供了非常宝贵的真实视角。

作为当事者，身处迷局之中如何破局，如何分清主次矛盾，才是最值得大家思考和学习的。

从中，你可以看见华为作为一个擅长打硬仗的企业，在云计算这一关键战役上，如何在迷雾中前进的。

1 概念多落地少

文章作者写得很用心，用了很多举例来证明一个事实，华为云在这几年的最大问题在于，概念提的过多，落地的少。

典型例子是文章中提到华为云旗舰大会Huawei Connect

比如这边Cloud BU公有云讲专属云，那边IT私有云讲FusionCloud……一个summit一会公有云角度讲一会私有云角度讲。举个很好玩的例子，这次2018 HC大会关于“混合云”，我就看到了各种宣传露出，“FusionBridge混合云”“FCS混合云”“华为AzureStack（微软）混合云”“华为FusionCube混合云”，蹭热点技术词汇也不带这样的，想把客户搞晕吗？软件就是软件，盒子设备就是盒子设备。就一个混合云搞出这么多概念，就不能统一规划，统一呈现，产品组合管理在哪里？具体混合了啥，提供的到底是什么具体能力？解决客户什么问题也讲不清楚

转自：转发《#华为云#听从你心，无问西东》及网友跟帖

“FusionBridge混合云”“FCS混合云”“华为AzureStack（微软）混合云”“华为FusionCube混合云”四个词，不要说客户，做技术的人应该也糊吧。

这么多技术名字和方向，再同一届大会出现，本身就是个问题。会非常混淆用户认知。

那么别家是怎么做的呢？比如前段时间腾讯云架构师任易说，腾讯云的优势就在于，能够连接人、连接事、连接物，然后举了长安汽车的案例。

具体做什么？将长安集团的三万名员工迁移到企业微信，可能说到这里大家觉得没什么东西，

后来任易说，通过企业微信，能帮长安汽车员工干这些，干那些。

以员工交通车为例，员工使用企业微信扫码乘车，司机可以在企业微信中实时了解乘车情况，后台可根据扫描数据生成报表，为排班提供决策支持。

长安汽车还用企业微信实现了企业内部与上下游供应链的管理，通过企业微信连接经销商，打通供应链上下游，就意味着所有的数据都通过格式化，通过微信经过企业微信传到业务系统里。据调查，1000多家经销商中的10000多个销售顾问都在使用企业微信，这是来自销售一线的实时反馈，这又是庞大的想象空间。

如果把500家企业（人）拉到一个群里，可能撮合多少生意上的合作？

你看，腾讯云没有给我找一大堆技术名词，也没有和我科普云计算趋势。

他讲的是看起来和云计算八竿子打不着的汽车行业。

但在他讲述的过程中，我反而清晰看到了云计算的具体运用场景。

不谈是否盈利，不谈开发成本，他至少给了我一个清晰直观的现成案例。

哦，在汽车行业这块，腾讯云确实用新的互联网技术，做了这么一个方案。

如果我是别的汽车制造商呢？如果我是和汽车类似的制造业呢？如果我是上下游的供应商呢？

什么叫打穿一个行业？这就是。

讲完了问题，再来看看原因

华为云出现这种概念多落地少的原因是什么？

文章作者认为是差在了落地生态，没有阿里云腾讯云等他们拟定的追赶目标丰富。

社区里高赞回复认为是执行力太强的副作用

许多员工认为华为的企业文化有点类似军队，强调纪律性，执行力。这一点帮助他们在以往的市场无往不利。但也导致了大家没有战略思维，都等着上层拍板。

我个人，认同后者的观点。

因为华为确实是以执行力强出名，尤其是这种“不惜一切代价完成任务”的习惯。

让大家即便在遭遇困境时，也很少去质疑任务本身。

在手机这样的存量战场，刺刀见血的肉搏战中，他们靠着这一点击败小米，蚕食三星，甚至挑战苹果。

但在云计算这样的新型战场时，靠的是思维能力，单单执行做硬件还行（所以你看华为他们做硬件、做盒子很厉害）。但云计算不是这样子的，缺乏战略方面的主动性，导致他们始终无法确定明确的长期方向，多次改弦易辙之下，大量云名词堆积。

2 把品牌宣传活成了段子手

文章里提到的第二个点，是在华为云的宣传上，出现了问题

典型例子是双11的活动

我发现华为云官网针对双11这种to C市场的购物节搞得花里胡哨，什么红包雨啊，送手机啊，甚至比阿里云搞得还High。你说，双11就是人家造的，淘宝天猫这种to C搞得特别High，没有问题。我就很好奇，to B市场也是这样玩的？我们有时候学习一些新玩法，互联网，且不可High过头了。我不觉得华为云的销售是靠双11这种购物节冲刺的。云关键的还是持续运营，to B也不是这种抢购剁手的玩法。好的产品，to B的大客户，难道还要抢什么“充值200送100”的购物券？

这个其实也是我一直想说的，似乎是杜蕾斯起的坏头。但凡遇见热点事件，都要跑来发个图，编个段子。

但杜蕾斯是大众向的日用品类，加上产品本地调性就是走的非严肃类型，变成段子手没什么问题。

很多公司，包括华为云也把自己活成段子手，其实是不太对的

至少，一个TOB业务，跑来给我搞转发抽奖送手机，我觉得。。。是有点突兀的

品牌官V，要么做专业的解惑科普，要么做品牌宣传，人云亦云的把自己搞成段子手，是有点问题的。

3 赛马机制不包治百病

第三点，文章作者是对华为云各个业务部争抢客户的问题有质疑，而我认为，这实际上，这个表象的背后，应该是长期以来赛马机制的一个疑问。

前两年，腾讯如日中天时，有人总结，这是因为他们内部的赛马机制搞的好。

你看，有QQ，人家别的团队还弄出了微信，第一个拿到了移动时代的船票

有工作室做英雄挑战，也有别的工作室做王者荣耀。最后内部竞赛胜出，吃下了市场。

连做吃鸡，人家也是同时几个工作室一起上做了好几个版本。保证鸡蛋永远在篮子里。

看起来，内部赛马机制似乎是一道万能药，能有效解决大公司内部懈怠问题。

但为什么很多公司不启用呢？在作者的反思中，我们看到了最直观的体现。

记得今年有一次参与一个北京的互联网客户的交流。这家客户每年在阿里云消费3000+万，觉得每年自己花这么多，是不是自己可以建一朵自己的云，想考虑下华为的云计算。结果我们公有云、私有云重复去了一大票人，超过十几个吧。客户核心的决策和技术层人员一共3名。最后一天时间，私有云团队这边给客户针对云的建设、管理，包括跟客户系统对接讨论了一整天。公有云团队也同样准备了IaaS、PaaS、安全、EI等扫盲类介绍，完全就是打了一天酱油。

一个业务，你来两波团队给我重复科普两遍，我是客户我也疯。

甚至这还不是最严重的，在下面别的员工回复中，我看见了更夸张的

业务之间不但存在重复，居然还会互相恶性竞争。你是客户，你会怎么看待这么一家公司？组织管理都出现了问题，还谈什么专业？

我始终认为，盲目赛马不可取，腾讯是TOC的产品，所以根据不同用户给予不同团队和产品，其实是打着吃掉各类细分市场的算盘。这个思路，也可以在大众日化产品的宝洁身上看见。

而华为云，做的是企业服务，这应该讲究的是一站式服务，这个时候你跑来搞赛马，我觉得就有点迷了。尤其在客户角度，会显的非常迷糊，感到你们不专业。

顺带我提一下~百度，这个毛病更突出

百家号，百度问答，百度知道居然是分开体系的，邀请我去百度问答，居然原来的百家号用不了，要新开一个账号注册。

其实新注册也没问题~

但是后台身份证又提示重复了~我当时就觉得

“这产品肯定活不了，你注册机制逻辑都没给我认真做”

大家去看网上的企业报道，尤其是BAT，华为这样级别的企业，普遍能感到一股扑面而来的鸡汤感，比如觉得他们目标明确，意志坚定，执行力强等等，仿佛成功唾手可得。

但实际上，仔细看这篇反思的文章，以及员工们的回复，你就会发现，即便是华为，在云计算这样一个非常明确的重点战场上，目前也是对未来的概念方向不太明确，甚至连组织方向都存在极大疑问的。

有人质疑，有人反思，还有更多的人则是一片迷茫

成功，从来没有故事里说的那么容易

作为时代的旁观者，我们总是能轻易得到各种结论，各种事后的分析，仿佛一切结论都来的如此应当。

只有真正置身于时代大潮，感受被洪流裹挟的力量，才会发现，很多时候，你往往连方向都难以分清。

点击原文链接查看反思文原文

5G 物联网和边缘计算将开启数字时代

Mon, 14 Jan 2019 18:42:23 CST

5G、物联网和边缘计算在过去几年里引发了很多热议，5G预计将处理比4G多1000倍的流量，速度可能会快10倍。下一代全移动网络有可能会改善我们的生活和全球经济。

数字化时代

5G现场试验、试验台和数字实验正在进行中。电信运营商及其供应商正密切合作，设计和实现这种新的开放蜂窝网络架构，为5G及以后的技术奠定基础，并开启一个新的数字时代。5G超快网络将引入大量的新应用，以满足我们对更多、更快和更智能数据日益增长的需求。

边缘计算并不是一个新概念，其中一些功能已经以各种形式存在多年，主要集中在数据和控制平面解决方案的网络元素上，但随着物联网和5G交付等关键服务的出现，其价值得到了放大。边缘计算能够协调5G 的巨大带宽能力，并通过处理需要人工智能处理的数据，大幅降低延迟，也更安全。所有的数据处理、存储、分析和通信都可以在网络边缘完成，而不是在遥远的数据中心和云端(目前几乎所有的数据都是在云端发送和处理的)。重要的数据现在可以在边缘实时地处理，并且可以立即做出决策。

有相关预测，到2025年，从可穿戴设备到智能电表、再到工厂和智能城市传感器，将有超过800亿台设备接入互联网，当年将产生约180万亿字节的数据，全球范围内创建、捕获和复制的数据将达到175千兆字节，其中30%的数据将被实时处理。未来10年或将部署数百亿台5G设备。

5G预计将在2025年达到临界值。电信运营商及其精心挑选的供应商将引领我们进入下一个数字时代，第四次工业革命。

1．互操作性将在2019年继续占据主导地位

有几个关键原因。例如，5G必须支持各种类型的交通和所有能想到的连接设备，从自动运输和无人机到建筑、农场和工厂自动化，再到遥测和植入式医疗设备。5G的设计和实现是为了支持开放标准的硬件和软件，支持新应用程序快速开发并部署的理想网络架构。应用程序之间的互操作性、它们所运行的各种网络、它们所接触的硬件和软件以及它们所基于的标准，都必须在一个开放的生态系统中紧密地协同工作。

2．具有人工智能的新应用

这些应用程序将影响所有数字消费者和行业。例如,运营商可以提供虚拟现实或AR视觉应用程序测试和开发：虚拟助理，智能工厂、城市和公用事业公司，改善与残疾人的沟通，更高的安全性，数据管理等。到目前为止，这类应用仅限于数据科学家和研究实验室。

3．把IT和OT结合在一起的全新商业模式

直到最近，信息技术(IT)和操作技术(OT)一直存在于两个不同的世界，服务于不同的目的。IT由处理和存储数据的计算系统组成，而OT则由运行和监视生产系统的硬件和软件组成。边缘计算是物联网的基础，它需要通过与操作技术的融合来实现。

4．数字实验的数量和种类将呈指数增长

数字实验是一种低门槛的方法，可以在不进行大规模初始投资且不干扰现有系统、操作流程或劳动力的情况下，在真实或模拟环境中测试，这是引入新的数字颠覆性应用程序和技术的唯一途径。数字实验将加速物联网创新，使这一过程更快、更经济。

当然，5G、物联网和边缘计算必须首先在各种系统、应用程序和设备的受控环境中进行适当测试，然后才能成功部署新的应用程序。

360周鸿祎：IOT时代的信息安全六挑战三原则

Sun, 28 Sep 2014 14:15:34 CST

360周鸿祎：IOT时代的信息安全六挑战三原则

前一段时间我干了很多和安全关系不大的事情，看到了很多传统行业的老大如何患上“互联网焦虑症”，他们害怕互联网成为传统价值的毁灭者，其实这些是对于互联网的一些误解，所以我还写了一本书，讲我的互联网方法论。

很多人问我互联网思维是什么？如果用一个词总结是什么？我想了想是在过去的20年里互联网最大的力量就是实现了“网聚人的力量”，互联网把我们很多人连接起来。

在互联网第一代的时候是PC互联网，我们每个人的电脑连接起来，这时候安全问题还OK，当时的防病毒和查杀流氓软件，以及我们很多边界和防火墙的防御技术；但到了互联网的新阶段，我们每个人都用手机了，今天手机已经变成我们每个人手上的一个器官，我们每个人有一种新的病，几分钟不看手机就觉得心里很失落，手机变成了一个新的连接点。手机打破了我们原来对边界的定义，手机更多和我们的个人隐私信息联接在一起，所以，安全的问题变得更加严重。

有一个好消息，也是一个坏消息，手机互联网之后，下一个五到十年我们的互联网将会往何处去？

其实我觉得一个最重要的时代可能要开始那就是IoT——Internet of Things，万物互联。

美国的硅谷现在非常流行IoT这个词，Internet of Things，我早些时候提出来有些人质疑是“物联网”的翻版，但是我认为并不是。物联网被翻译成传感器网络，而IoT网络是万物互联的。

来IoT时代，所有设备都将内置一个智能芯片和智能OS，所有设备都能通过各种网络协议进行通信，而且是7 x 24小时的相连，能够产生真正海量的大数据；并且，伴随大数据应用的逐步升级，也会让机器变得更加智能，甚至具备自己的意识。我认为，IOT时代的信息安全其实也是大数据的安全问题，而且至少要面临六方面的挑战。

首先，当所有的设备都变成智能化，都接入网络以后，边界的概念将会进一步被削弱，也就是说接入点越多，可以被攻破的这种可能的入口就会越多。过去，我们很信奉“隔离”、“切断”，我们可以把电脑放在一个屋子里，我们可以把一个网络进行隔离，但今天你会发现越来越多的不起眼设备都支持Wi-Fi和蓝牙，这里面有太多可以被别人攻击的接入点，而且攻击点越多，对防守的挑战就会越大。

第二，未来企业都将成为互联网企业，企业信息安全面临更大的挑战。过去我们很多企业可能不太重视企业的安全，我们很多时候买防火墙是为了合规，是上级要求和行业要求。过去我们企业的发展，可能把自己割裂在一个安全的孤岛上，但你要变成互联网企业之后，你不可避免要把自己的核心业务系统接入到互联网上。

但当所有的企业都变成互联网企业之后，企业安全一定要提高到一个更重要的优先级上，也就是说当你的服务器或你的网络被攻破之后，可能不意味着仅仅是你内部数据的泄露，可能意味着用户数据的灾难。

第三个问题，大数据污染。就是大数据中如果被人为加入了各种无效、错误的数据，人为操作和注入修改虚假信息，在数据传输存储过程中出现了问题，那么根据大数据所做的一切行业指导和趋势分析，都可能面临灾难性的后果。

第四，智能设备IoT 被控制之后的灾难，这种危害或者会比电脑手机更大。

过去大家都记得，你的电脑中毒了、有问题了，大家最多觉得“今天给老板交的报告写不出来了”，所以我电脑中毒了经常成为工作完不成的一个借口。机出问题了呢，无非你们看到最近多了很多“艳照”，不小心照片上传了；然今天手机和支付系统连在一起，可能当你的通信录被盗用了，就会收到一些诈骗短信。包括前面讲到的那个木马之所以会得逞，就是因为它盗用了你的通信录的地址本，熟人发来的短信，大家都会连接。

但IoT是可被控制的，不是一个单纯的网络，这个被控制了带来的风险就大了。

前段时间中国人崇拜完乔布斯之后，因为中国的假乔布斯太多了，他们又开始崇拜美国另外一个人，号称钢铁侠，他造了一部汽车叫做特斯拉，他上次来中国的时候，我有幸和他们大家一起吃了晚餐。我问了一个他很恼怒的问题，我说你的汽车会被人骇客吗？他说不会，我们所有的应用都是自己写的，我们不会安装任何第三方应用，所以不会有任何问题。我就提了两个问题，第一个你的汽车是有Wi-Fi和蓝牙，我可能骇客不了你的汽车，但你用手机接入的话，我可以骇客你的手机，我一样可以通过手机骇客这个汽车。自然你是一个智能汽车，它就像一个大手机一样，一定要和云端通信，所以如果有人下发了你的通信协议或者破解了你的云端的网络，我一样可以控制你的汽车。

我们后来在全国征得了很多有识之士，有人成功破解了对特斯拉的协议，成功实现了对汽车的控制。所以，中国汽车厂要生产智能汽车，我给他们说最重要的不是边开汽车边看互联网影视，最重要的是老百姓敢不敢开你的车，如果半路上突然死机了，突然蓝屏了，突然弹出一个大窗口说你必须下载一个什么玩意儿，这样的汽车不会有人开的，一旦出现问题就会非常的严重。

第五个问题，当大数据产生了人工智能之后，很可能人类技术发展会到达一个新的“奇点”。

比如说以后的机器人和智能汽车，我有一个断言，它未必是由这个设备里的智能系统单独做智能判断，它一定是和云端一个更大的智能系统相连。

比如真正的智能驾驶，你何止需要这一部汽车的数据才能做判断，可能需要路边很多传感器和很多其他汽车发来的信息，你需要在云端进行高速的分析，再反馈过去。所以，将来有一天可能不仅仅是这台车上的电脑在指挥，很有可能是云端的一个机器在指挥。

因此，各种各样无论是专用机器人还是通用机器人，在几年以后也会越来越普及，都会和互联网相连，甚至它们再反过来对各种设备进行反向控制。

这样，当真正云端安全出现问题以后，机器智能带来的转换，这是我们下一个五到十年必须要考虑的问题。

第六个问题，也是最重要的一个挑战就是对用户隐私的挑战。

如果说IOT时代，各种传感器让每个人的数据维度更加丰富了，而且产生的数据都记录在云端，所以IOT时代的大数据下每个人都是透明的，一旦出现泄露后果也是极其严重的。

而且值得深思的是，在对用户隐私信息的保护，现行的法律和规则的制定都是落后的，有很多问题是不清楚的，怎样在这种情况下更好的去保护我们个人的隐私？除非不用任何先进设备、不接入网络，否则用户的个人隐私信息永远都是安全挑战。

就像前几天我看到美国有一家公司，只要给他的试管吐一口吐沫，就可以免费测出用户的基因组。未来基因的检测的成本会更低，而这样的公司他直接拿到了用户的最隐秘数据——基因。

所以说，IOT时代可以是某些企业的黄金时代，但同样对信息安全的保护却变得无比脆弱。对于这六个方面的挑战，有些已经在发生，有些是即将发生。在此， 我也提出一个新的想法，在大数据时代，如何保护用户信息的三原则。

第一，数据应该是用户的资产，这是必须明确的。虽然未来将有大量的信息存在互联网服务商的服务器上，但是用户数据的所有权必须明确，所有数据与信息都是属于用户的个人资产。

第二，任何企业都需要把收集到的用户数据进行安全存储和安全的传输，这是企业的责任和义务。

不仅仅是提供互联网服务的公司，包括所有暂时存储着用户数据的想做互联网业务的公司，都要提高公司安全能力，都要有加强安全防护水平的责任和义务；既然你们要收集用户数据，就必须解决传输、存储的基本安全问题。

第三，用户信息的使用，一定要保障用户的知情权和选择权，平等交换、授权使用。

存有用户数据的企业，在使用这些数据之前，一定要遵循平等交换，授权使用的原则，不能未经许可采集和滥用。更重要的是，要保障用户说“不”的权力：还有很多用户可以选择，当不需要某项服务时，可以把它关掉，可以拒绝采集数据，用户一定要有这种选择权。

不论是现在，还是未来，这些数据在未经用户授权的情况下进行了交易牟利，这不仅要被视作不道德的行为，更应该视为是非法的。

所以有了这三原则，在我们进入IoT时代时，我们才能让用户对下一代互联网感觉更放心，才能更好的使用。

只有安全的互联网才有美好的互联网，所以在互联网上最重要的就是安全第一。

杭州，AI时代的第一个城市“牺牲品”

Sat, 06 Oct 2018 16:31:21 CST

图片来源：视觉中国

自从杭州踏上了争夺一线城市的战场后，那个在评书中安静闲逸的“人间天堂”，已经陷入了互联网、人工智能和区块链的喧嚣。随着杭州关于人工智能的企业越来越多，就业机会也随之增加，那些喊着“逃离北上广”的AI人才终于找到了一个好去处，殊不知，从“北漂”到“杭漂”，不过是从一个残酷的战场奔向了另一个即将残酷的战场。

尴尬的优秀

不得不说，杭州是十分优秀的，据《中国人工智能发展报告2018》数据显示，截至2018年6月，在全球人工智能企业最多的20个城市中，美国占了9个，中国有4个城市入围。北京以395家居全球第一，杭州“挤开”了广州，与上海、深圳共同进入人工智能企业数全球20强城市之列。但是，杭州的优秀，又有些说不出的尴尬。

1. AI企业众多，但马太效应严重

在科创上，杭州最为人津津乐道的是“特色小镇”模式，而这种模式大概是以色列特拉维夫和新加坡二者的结合，也就是在政府主导下，本土初创企业与大型集团或跨国公司共同推进科技创新。

在这种模式下，杭州取得了相当不错的成绩，仅2017年上半年，杭州特色小镇完成固定资产投资259亿元，杭州市市每万人拥有人工智能企业的数量等指标居全国大中型城市首位。

图为杭州人工智能企业生态

然而，据智投云的监测数据显示，过去五年里，杭州本地的创业融资项目数量在2015年达到峰值后，在2016年出现了下滑。即使当地政府对科创项目给出了极大的优惠政策以及高容忍度，但杭州还是没能复制特拉维夫“第二硅谷”的成功。

这里不得不提到杭州和特拉维夫的融资情况。要知道，特拉维夫吸引外资的能力十分强大，以色列80%的国际银行、风险投资以及国际律师事务所都位于此地。但是，杭州支持人工智能发展的资金主要来自于风险投资、产业基金、政策资金等，存在许多相关企业为了追求短期的经济效益，无法积极投入前沿技术研发，导致发展乏力的情况。

此外，杭州的巨头公司比如阿里、蚂蚁金服、网易、海康威视等已经积累了许多技术成果，比如蚂蚁金服生物识别技术小组与Face++合作研发了人工智能生物识别机器人“蚂可”，海康威视则拥有大数据、人脸识别、深度学习等核心技术，在MOTChallenge中,曾荣获“计算机视觉多目标跟踪算法”世界第一。

反观其他人工智能企业，除了慧芯金服网络科技、宇泛智能科技、辛顿科技这类新兴技术公司能在人脸识别准确率上取得比较不错的成绩，其余人工智能公司都是以点状形式在探索，而如何和互联网、大数据、云技术等进行有机整合，还没有摸索出有效的商业模式。同样的一项智能技术，有雄厚背景的大公司生根C端，商业模式十分成熟，发展速度和业务深度都不可同日而语，而初创企业却难以从零开始积累用户， 火热的初创背后，是面对C端的力不从心。

2.晋级“湾区”，但不具备湾区气质

位于加州的旧金山湾区曾经创造了高达7855亿美金总GDP（仅次于世界18个国家）的传奇，如果对标中国版湾区，深圳所在的珠三角地区无疑最具湾区气质。然而，中国版湾区并非一成不变，在2017年中旬，浙江省政府开始释放谋划“环杭州湾大湾区”的信号，而这一信号也很快被上海市政府所接收。

相比珠三角里香港、广州、深圳三强相争的格局，京津冀借力雄安新区调整优化城市布局，以上海和杭州为核心的长三角湾区，因为区域内更高的经济整合程度，成为中国科技界不可忽略的重要区域力量。

参考加州的湾区，一个区域能在科技上取得成功，首先要保证社会的开放度，也就是拥有发达的对外交往网络。在G20之前，杭州一直都是上海的“后花园”，在此之外，杭州虽然走上了台前，开始社交，却也比不上“老大哥”上海，不得不说，上海在长三角的领头地位十分稳固。

今年年初，人民论坛测评中心对19个副省级及以上城市全面开放度进行了测评。在社会开放度这一项上，杭州排名第八，不仅在四大一线城市之外，还列于天津、重庆和成都之后，得分也在均分之下。从这个角度来看，杭州的“湾区气质”还有待提升。

图为各城市社会开放度得分

成也萧何

杭州是我国重要的高新技术产业基地、电子商务中心和区域性金融服务中心，也是互联网电商高度集聚发展的城市，在探索人工智能的路径上，杭州具有得天独厚的优势。

1.以阿里、网易、海康威视为代表的IT产业巨头纷纷抢占人工智能制高点。2016年4月，杭州市与阿里云共同开创杭州城市大脑概念，同年10月在杭州云栖大会上正式启动建设。2017年底，阿里云ET城市大脑入选国家新一代人工智能开放创新平台。

可以说，在杭州“城市大脑”建设伊始，阿里云就全方位地参与城市大脑建设，尤其是在人工智能、云计算、大数据处理以及互联网架构、数据中台、专有云等方面，阿里投入了众多科研力量攻克技术难关，并以技术优势顺利推进项目落地，打造了杭州的“城市大脑”名片。

2.浙江独特的地缘环境孕育了浙商群体，浙商的特性成就了不少企业。“浙商”这个词汇最早出现在景定《建康志》里，据记载，绍兴元年辛亥(1131年)“(叶)梦得奏，京东诸州艰食，桑柘不熟，二浙商贾转贩入京诸州，收息数倍。朝廷方议收复，必将与天下为一家，京东虽见属伪境，然皆吾民也。今从伪之人日夜不忘本朝，而我因其饥寒而遂困之，是弃之也，毋乃重失其心乎？”由此也可见浙商的机敏。

从个人特性来看，浙商承载着越文化品格的基因,有着越文化朴实勇猛的个性、开拓疆域的价值追求以及实事求是的实践品性等文化特质，拿风头正盛的拼多多创始人黄峥来说，作为一枚纯正的杭州人，在其创业发家的轨迹中，我们总能看到杭派的打法。

从组织特性来说，浙商企业往往建立在亲缘、血缘和地缘关系的基础上，依靠血缘宗族纽带而产生社会关系网络，因而具有特殊的信任模式。从企业特性来讲，浙商是当代中国人数最多、分布最广、实力最强的经营者群体，创造了令人瞩目的经营业绩。浙江商会更是其立于现代经济社会中的一种特殊形式。

3.杭州周边的江浙有着中国最为庞大的产业链分工体系。对于上海和杭州这样的大城市而言，肩扛着的最大责任是，如何对周边城市产生带动作用，通过城市集群将互联网＋人工智能的环境优势放大。

浙江的产业集群有一个特点，即集群内部企业之间的劳动分工高度细化,存在着大量的工序型企业和半成品交易市场，其产品生产过程可分拆为几个不同步骤，为企业间的分工合作提供可能性。此外，浙江的产业集群是建立在无数个中小企业之上的，具有很强的文化、地理根植性和产业关联性。

温州常州有着无数个小型的加工企业和制造企业，如果将智能硬件这一产业要素集中在江浙地区，那么，依托智能硬件为基础的AI初创企业就会集中在这里发展，阿里巴巴的成功就依赖于江浙一带的企业资源网络。

败也萧何

总的来说，杭州在人工智能领域取得好成绩还是情有可原的，然而，水可载舟，亦可覆舟，没有什么先天条件会是绝对无害的。

1. 大树底下不生草

谈起杭州，一定离不开阿里巴巴。文章《阿里系创业人“团灭“？淘宝城2.5公里外是创业“坟场”》提到，“杭州，本不是一个合适创业的地方，由于阿里巴巴的一家独大让本地生态圈的多样性存在一定的问题。阿里的既有基因太强，人才的来源过于单一使得创业公司很难跳出这个圈子思考。”

杭州的大公司们包括阿里巴巴、网易、海康威视等，已经汇集了人工智能产业链的要素，都能够进行全产业链覆盖。显然，单体要素的竞争弱于生态要素的竞争， 在杭州这些人工智能企业中，不是大鱼吃掉了小鱼，而是游得更快的鱼会吃掉游得慢的鱼。

以阿里健康为例，8月20日，阿里健康宣布，联手东仁堂大药房、海王星辰健康药房、九洲大药房和天天好大药房等连锁药房，在杭州地区提供24小时送药上门服务同时，阿里健康还牵手酒店集团共同保障24小时药品供应，入住酒店的用户可以享受前台提供的代收药代送药服务。此外，阿里健康正在研发的24小时无人售药机也将在9月面市。此前，阿里健康还投资了贵州一树连锁药业、注资漱玉平民大药房等。

一连串动作的背后，我们可以看到阿里健康正在医药新零售上加速布局，阿里健康的医药新生态也正在形成，其他小企业想要插入，亦或者是赶上阿里的步伐，实在太难，更遑论建立良性的产业生态了。

2.“低学历”的浙商

说出来你可能不信，作为商帮中的“扛把子”，以高中为界,浙商低学历段（含文盲、小学、初中、普高和职高）四级学历比例都比全国的私营企业主的平均水平要高，而浙商的高学历段（含中专、大专、大学本科和研究生）四级学历都低于全国私营企业主平均水平。

从211/985高校分布数量看：北京有26所、上海有10所、杭州仅1所、深圳更是一所都没有，作为传统的高教中心，北京和上海基础雄厚，而杭州和深圳则大量依赖外来高校毕业生。

专家学者们一直认为，在自然资源相对贫乏的浙江省，之所以能够创造令人瞩目的经济成就，主要靠的是充沛的创业者和企业家资源的供给，即突出的浙商创业能力和他们的创新精神。这里存在的悖论是：为什么受教育程度较低、专业技术人员较少的浙江人，特别是浙商，改革开放以来成为了最具活力的商业群体？

最后，研究者们发现，浙商有其特殊的禀赋形态,，在不确定情形下的强行动力和高效率的小数据决策模使他们取得了成功，这些浙商的特征与浙江深厚的地方性工商业知识、集束化的产业分布以及地域文化价值观互为因果激励。

不过，浙商低学历创业优势具有阶段匹配性。智能时代，基于个人直感决策效率较高但稳定性较差,在面对复杂的技术问题和异动情境的时候,因为“小数据”和知识的局限性，可能影响决策质量。也就是说，在新的历史时期，人口受教育程度在全国处于中下水平的浙商群体要继续保持竞争优势，需要在学习机制、知识结构、决策模式等方面进行有机更新。

从这个角度来看，杭州还需要加大培养人才的力度。当然，作为新一线城市中的佼佼者，杭州还是吸引了相当多的外来人才，据猎聘网的大数据报告统计，在2017年上半年全国主要城市人才净流入率排名中，杭州以11.21%位居榜首。

但是，值得注意的是，北、上、广、深、杭等地方，最近几年回流成都的人才不断增多，而且，比较成都和杭州在新一代信息技术产业中的被关注度，我们发现，杭州仅在时尚方面占优势。杭州不仅要奋力追赶北上广深，还面临着被成都迎头赶上的风险。

图为各城市新一代信息技术产业关注占比图图片来源：《宏观经济管理》2018年第7期

3.人文的“陨落”

漫步西湖，你能想象杭州已经成为全国加班最疯狂的城市吗？人们还能闲适地吟诵出“欲把西湖比西子，谈妆浓抹总相宜”吗？

“杭州的城市气质，逐渐消陨了以文人为代表的自由、闲暇，取而代之的，是以码农为典型的激烈的竞争。”这无疑是令人扼腕叹息的，人文的成果及影响需要长时间的历史积淀,，而在人工智能大力推动着自然科学发展、各大城市致力于提高城市的可见竞争力的进程中，人文的发展缺乏足够的滋养，其危机的种子也就逐渐生根了。

人文的危机并非是因人工智能的出现而诞生，但却因人工智能的发展而遭受到前所未有的本质性怀疑。在智能时代，人文思维逐渐被科学理性思维所取代，甚至于产生了以AI为信仰的科学宗教。楼宇烈在《中国文化的根本精神》中提出：如果完全按照自然科学的方法去看，水就是一堆物质，没有其他意义，而中国传统的人文特质让我们对天地万物都有了感情。

在2015~2016年，杭州竞争力全球排名139，2017~2018排名升至第74名。与竞争力相对的，是人们的幸福感。

国家统计局与中央电视台联合主办的《经济生活大调查》显示，2007年至2010年，杭州持续4年登顶中国最具幸福感城市。至2011年，杭州下跌至第四名，2012年时，杭州已经跌出前十。此后，杭州也曾回归前十，但难登榜首。在今年二月新出的2018年排名中，杭州再次跌出前十。

与杭州类似的城市是成都，近年来，各种文化都在成都迸发，同为新一线，成都的“佛系”人文没有遭到科技侵蚀，相反，对那些在一线城市苦苦挣扎的人而言，成都的开放、包容、闲适以及低房价都充满了吸引力；对城市而言，城市治理无需背负一线城市那样大的人口压力，在许多决策上，也有着新一线的活力，给经济提供了内生动力。

结论：

看起来形势大好的杭州，在人工智能的大潮里，似乎也没有捞到什么好处，人才回报、城市价值、社会关注乃至文化伦理层面都在失守。当然，杭州依旧会在竞争一线城市的独木桥上越走越远，然而，如果没有正确的认知和定位，高歌猛进的后果极有可能是与初衷的背道而驰。

参考文献：

1.《全球经典的科创中心模式》中国经济周刊

2.《杭州市人工智能产业发展现状及对策研究》寿伟义；章正平；潘学冬；王宪保

3.《浙商的伦理禀赋及其当代建构——基于“韦伯命题”的分析维度》董珊珊

4.《浙江产业集群的现状及发展》张璐阳

5.《低“人口素质”与高经济增长—基于浙商群体的解释》杨轶清

6.《我不希望杭州变成一线城市》上流UpFlow

7. 《阿里系创业人“团灭“？淘宝城2.5公里外是创业“坟场”》朱思码记

8. 《中国不应只有一个科技「湾区」》波波夫

9.《谁在为成都创业拾柴火？》曙驰

【钛媒体作者：智能相对论；文 | 颜璇】

更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App

腾讯没有梦想？过奖了，腾讯现在落伍于一个时代

Thu, 27 Sep 2018 23:53:26 CST

现在是 2018 年 9 月 25 日，腾讯内部刚刚由总裁宣讲了形势一片大好，所有的困难都是暂时性，一切尽在把握中的鸡汤。与此同时，在 to C 端，抖音月活超过 5 亿，达到微信的一半；to B 端，腾讯云数据丢失风波刚过去不久，而云服务仍然没有独立作为事业群存在。

有趣的是，代表目前重点的微视和腾讯云，却一直挂在腾讯的社交事业部下面。

腾讯作为中国人寄托了太多感情和故事的公司，无论是恨腾讯还是喷游戏，不可否认，中国人在过去的 20 年中有太多的故事发生在 QQ/ 微信上面。

然而，只有面对问题、面对困难，才能真正去帮助腾讯，不至于让他成为第二个联想，慢慢消失于人们的视野。在近期各种关于腾讯的公关文黑文中，本文只集中在两大问题：

技术体系：为什么说腾讯的技术体系是落后的
管理体系：技术领袖为何会在腾讯消失？

以上述两点出发，从 6 个角度（研发体系、高级人才的流失、人才招聘的误区、企业 IT、香港帮以及马化腾自身），用最直白没有任何花巧的语言，去直面腾讯的几大问题：

1. 研发体系：落伍一个时代

2018 年 4 月，阿里发布“阿里技术参考图册”，将阿里的整体技术架构做了一遍梳理和介绍

阿里技术：速度收藏！《阿里技术参考图册》发布，公开 600 页技术全景图

当时在腾讯内网嘲讽者有之，忽视者有之，觉得应该模仿者有之，然而却没多少人在考虑一个问题：腾讯，你有这个能力吗？

如果腾讯一个 T3（高级工程师）的研发人员告诉你说他不习惯用 git，不太会用。。。你会有什么感觉？

当你从其他公司加入腾讯，突然得知你不能从家里远程浏览代码并修改提交，必须通过一系列繁复的操作去远程登录到你办公室的机器，而这个远程登录只支持 windows，你会有什么感觉？

我们来说几个现象：

当你在腾讯准备召开一个三方远程会议，然后坐在那个看起来高大上的会议室里，却发现压根就没有白板给你绘制，同时内部视频分享的操作复杂度堪比神经网络，你会有什么感觉？

然后你慢慢发现开发人员不懂单元测试为何物，数据跟踪全靠猜，其它团队的代码你是永远无缘一见只能黑盒连调，任何功能开发你想找人讨论也没人负责，没人能说清楚一个部门的整体产品和技术架构。。。

对的，腾讯内部有 hive，有 hadoop，有 spark，有 GPU 集群，也有分布式的机器学习框架和大数据处理机制。然而，仅仅停留在某个特定业务中。

hive，就是存储数据，用起来慢？没有方便的工具或者可视化处理？sorry，那不是要考虑的问题，慢慢等就好了；

有内部 mysql 集群（这算最基础了吧），可是呢，必须从指定的远程跳板机用命令行处理，没有一个可用的客户端或者 web GUI，然后还强制不允许安装 myphpadmin 之类的开源，说是不安全；

数据监控，没有统一框架，各组自造轮子，视 ELK/Grafana 等等为无物，或者只是简单直接套用，套用了觉得效果没有预想好（根本没去深入了解）就开始自己做其实并不咋样的初级监控，一问到呢就说觉得自己开发更“轻量”“更贴近业务”

代码管理，自己山寨了一套模仿 gitlab 的系统，偏偏又不敢真的另外设计，只是在 UI 上去山寨，背后逻辑 bug 一大堆

开发，单元测试是没有的，A/B 测试更是天方夜谭。举个例，大家看到微信前一阵推出了公众号搞成信息流，反响不好，只能更换新版本来验证。这典型的应该用 A/B 测试或者 feature flag 控制的事情，在微信就是做不到，只能用频繁换版本这种大概五六年前的做法，而别家一个版本可以试验开关多个不同功能。

说到微信，微信可能是腾讯里面技术体系最接近现代公司的了，但可以看到其技术之薄弱。企业微信自称要和钉钉对抗，到现在也搞不好一个多设备同步问题，多人会议和 zoom 相比更是个 joke. 微信本身，这么多年了，克制是够克制，视频和图片都无法发高清图，都压缩的真的只适合手机看 ---- 你真以为这是克制，我认为其实是技术上支持不了。

绝大部分团队里压根没有任何人懂机器学习，也没有数据分析人员一直跟进，功能和数据 tracking 全靠 pm 猜，效果好不好靠蒙。。。

还有被人喷过无数次的内网隔离，入域问题，linux 不得入域，默认一切都是基于 windows。这是本人从业十多年来见过最奇葩的限制。这事情我会放到企业 IT 那部分去说。

其它更多的细节就不多说了。

所有这些，没有任何人出来对架构或者工具进行讨论和质疑，一切以把“业务完成”作为目标。从没人想过：如果加班加点也完成不了业务需求呢？去跳楼吗？----- 而现在不是如果了，是真的加班加点砸钱也干不过抖音，干不过阿里（钉钉），人可能不用跳楼，反正股价是跳楼了。

如果你是来自其它公司，你进入腾讯后会有极大的自由，自由到你无法意识到你是在一个庞大的世界前 10 市值的公司工作，自由到和十多个人的创业公司或者学校差不多（什么都要你自己造，从数据处理到 CI）

然而这有个奇特的现象啊：腾讯的一半工作人员都是研发相关，为什么反而如此忽略技术？

这里其实有个分界点：2012 年

2012 年的腾讯确立了“连接一切”的目标。照理说，要连接一切，背后更应该是极度灵活且稳定的底层架构服务，是每个工程师梦寐以求的目标。

在 2012 年以前的腾讯，这个目标是可能的。如果看“腾讯传”，会看到在与 msn 的战斗中，腾讯挖来不少微软的技术人才，后来又引来如 google 的吴军等人。在腾讯内网中，可以看到很多 2012 年以前对代码的规范，对统一数据平台的设计和执行等等。可以说，在提出“连接一切“这个口号前，腾讯的技术人才储备和实力，是位于中国前列，不亚于阿里巴巴，足以有底气提出这个伟大目标的。

然而奇葩的是在提出这个目标之后，我们突然看到腾讯萎靡了。先不谈人员的流失，就来看产品：从微信（诞生于 2011 年）之后，腾讯在社交领域再无任何一款能拿出手的产品 ----- 实际上整个公司从 2012-2018 年就没有任何新品，除了游戏搞出王者荣耀。

在技术上，腾讯云的数据丢失已经让人看到极大的不足。而更直接的，是面对抖音的挑战时，腾讯无力的所谓“反击”，才让人惊讶地发现：原来这个巨人，已经不再能打了。

在潘乱的“腾讯没有梦想”一文中，说到腾讯马放南山，刀枪入库。其实这倒不见得对，软件行业谈不上什么马放南山，如果对手还是新浪（微博），还是 360，还是网易，相信腾讯仍然能用雷霆万钧之势碾压对手。

然而，这是新一代的互联网公司。抖音，或者说头条的背后，是中国互联网 2012～2016 年全民创业的大成。技术上，数据驱动、基于 A/B 测试的快速迭代灰度发布、基于数据的技术运营等等，取代了靠产品经理拍脑瓜设计，靠疯狂发布新版本，数据全靠蒙的上一代做法；团队上，扁平化、敏捷化、数据挖掘机器学习成为团队标配，代替了繁重的层级审批和所谓“大佬带队”；运营商，来自于 O2O 的小团队分区域精细化运营取代了过去靠砸钱买广告没有可靠 metrics 的粗放做法。

腾讯意识到了危机，但当他真正拿起微视准备反击时，却发现自己还停留在坦克飞机大炮数量的比较时，对手已进入了空地一体化 + 电子干扰 + 全军信息化的世代。

年轻，必将战胜衰老 -----20 岁的腾讯，在新一代互联网公司的面前，突然发现自己依赖的技术和“打法“，变得已经不再有效。

对于互联网公司来说，其实不应该存在发现技术和“打法”不再有效。因为互联网技术本就是一个不断发展的领域，没道理说有什么公司会突然一觉醒来发现世界全变了。实际上就像很多人说的，腾讯在 2017 年达到了市值高峰，一片赞歌，那么为什么在 2018 年突然到了谷底。如果说股价的变化因素很多，而技术体系这个问题，为什么在过去的五六年里没有这么多关注？

这里的核心问题就是：腾讯的技术困境，难道没有高级架构师来处理？

2. 技术领袖：2012～2014 的出走

前面说到，在腾讯和 MSN 大战期间，从微软挖来不少人才。实际上在目前腾讯的组织架构中，残留有很重的微软（早期）特色：复杂而繁琐的测试部门和对应的千奇百怪的测试工具。

写出“浪潮之巅”来自 google 的吴军，也曾在腾讯负责 soso.

然而，这些人才，在 2012 之后，却一个一个地离开了,连 CTO 都走了，Why？

这个原因，恐怕没人能真正地回答。但从腾讯在 2012 之后业务的变化上，我们却非常能理解这些人员的离去。

腾讯在 2012 之后，砍掉了两个本来给予厚望的部门：搜索和电商。

从技术上来说，搜索是机器学习数据挖掘最早也是罪合适的落地点，对标的就是 google/ 百度。可以看到，对头条信息流最大的威胁不是腾讯，是百度的信息流。由此可见，在底层技术框架合适的前提下，业务方向的转换是能做到快速有效的。

而电商，阿里和 Amazon 都已经证明了，电商业务带动的就是云计算大数据的基础架构能力（也包括机器学习的推荐系统）。

而这些，都恰恰是腾讯在 2018 年的今天，突然发现自己的最大弱点：机器学习驱动、大数据驱动、云计算架构。

而回头一看，本来在腾讯已经步入中高层的这方面的技术领袖，却已经纷纷离职。

从 2012 之后发生了什么，我们不得而知，吴军在一次采访中隐晦地说到过腾讯没有搜索的基因，另一方面，在近期的一篇文章中，我们通过腾讯云的一角却隐约可以看到技术领袖和腾讯高管思维的冲突：

腾讯正酝酿史上第三次组织架构变革

文中提到，2010 年，拥有谷歌和微软背景的陈磊加入腾讯，并积极推动云计算的发展，但当时 SNG（社交事业群）的负责人却认为要业务优先。2014 年，推动了腾讯云初期发展的陈磊离职。

很有趣的是，上文中明显犯了战略错误，把业务放在并不成熟的云计算之前的高管，却并没有受到任何的指责，反而在文中提到可能会继续负责腾讯云服务。在战略上犯下大错后仍受重用，这在如战场一般的互联网公司是罕见的。

从另外一篇较早谈搜搜的可以看到，在 2010 前后，腾讯是真的下了力气挖业界顶级工程师，致力于往技术方向走的

腾讯搜搜的没落之路：从拔苗助长到部门肢解裁员_科技_中国网

很多人说，搜搜没做出啥来，所以高薪挖这些人是错误的，是不值得的。

实际上，一个大型企业做产品，80%都会失败，但是为什么要去做？真的是一定要产品成功吗？其实不是的，做新产品一方面固然是希望产品本身成功，另一方面则是通过新产品来积累技术、把握技术动向，这样一来通过新产品可以带动兄弟团队和部门，二来可以保持和业界前沿接轨，不至于业务转向时措手不及。

我们可以看到，在挖来 google 大牛及在研发投入重注的 2010 之后，2011 年，诞生了微信。

这中间有关系吗？没有关系吗？我们不能假设没有发生的事情，但现实就是，在这些牛人离开以后的 5、6 年，腾讯再无任何新品。

那么技术呢？这些牛人在技术上到底有什么帮助？

我们不妨反问一下：当年有这些牛人的时候，我想没人质疑过腾讯的技术水平（虽然那时候国内普遍较低）；然而没有这些牛人，腾讯的产品技术水平和业界（中国）前沿差了多少？

腾讯总裁刘某在最近的内部讲话中，把如今抖音的威胁和当年 3Q 大战做对比，说其实不如当年有威胁。作为一个总裁，说出这种背离现实的话，实在是让人失望。一则当年 3Q 大战不是技术之战，是运营、舆论和政策之战，这东西说白了是国家当时监管不严环境下的菜鸡互啄街头斗殴（不信的话，看看现在 360 是个啥角色，而腾讯当年就跟这个档次的打得“有声有色”）。现在和抖音是技术之战，是职业拳手在公开擂台对你挑战。而面对不缺钱不缺流量不缺运营的真正职业对手，技术上的落后，没有任何回旋的余地；二则，当年你有从微软谷歌挖来的各方高端人才助力（当时其实挖几个普通员工已经很牛逼了），而现在腾讯当年挖来的已经基本都离职，从 gm 一层开始基本上全部是土生土长的员工，兢兢业业，但无法在技术上提供太多帮助。与此同时，阿里这几年从西雅图从硅谷挖了多少高端人才？国外 engineer 一谈海归必说阿里，有几个人说腾讯？知道腾讯的岗位和级别要求？

哪怕是在 2010 前后，从微软谷歌挖来的人也帮腾讯铺垫了云计算和机器学习、大数据的一定基础，也拥有着超过类似汤道生这种“原生”员工的视野。然而，在随后的几年，这些人被一一排挤离开，到了今天，马化腾不得不承认腾讯在人才储备的不足。。。

那么，腾讯既然已经知道不足，那他是真的在开始弥补？我们不得不谈第三个问题：什么是高级人才？

3. 高 级人才：发论文的就是高级？

不知道出于什么原因，腾讯对“研究人员”有特殊的偏好，从之前的吴军开始，就爱找研究人员来挑大梁。

问题是，什么时候学术研究和工业产品能混在一起了？一个精研算法的研究员，就能负责一个工程团队并在业务需求中合理取舍作出产品？

马化腾在近期谈 AI 的时候说腾讯在人才储备上不足，所以一直在弥补。然而，我们知道腾讯的 AI Lab 无非是招了一帮发论文的学术界 paper machine，不知道到底打算让他们出什么成果。

腾讯内部对技术嗤之以鼻，一谈技术就用“技术必须服务于业务”来搪塞。可悲的是，大部分腾讯员工连到底别人如何用技术去驱动业务的都没见过，就被所谓的业务优先洗脑了。

回避技术，回避细节，这是典型的缺乏技术领袖，从而缺乏技术自信的表现。大部分中层领导，因为自身已经多年脱离技术，对技术细节无法参与讨论，只能在业务细节上体现控制权。这本身可以理解，然而技术人才因为缺乏明确升职方向（除了做总监 gm，还有啥 title 和高端职位？没了！你说 T4、T5 都是技术职级？来来，我们实打实的看产品代码仓库，t4、t5 提交了多少代码？实际上，有 T5 还在提交代码吗？），因此在腾讯自身并没有一个技术人才的发展通道（所谓 T4 大多也是看业务规模，不是看技术能力），最终，整个腾讯都没有一个对工程人才的正确评价体系和标准，也无人有能力去评价。相对来说，学术就好说了嘛，paper 发了多少引用了多少，这些正好是那什么 AI Lab 所习惯的一套。

而在太平洋一侧的硅谷，从微软到 google，研究院早已是过去式，专门供养一帮发 paper 的“研究人员”已被历史证明是错误的选择，没有哪家还在这么干。对产品团队配备专职机器学习专家(ML Scientist/Data Scientist)，让机器学习在业务组里落地应用，才是目前一线互联网企业的路线。即便在国内，我们看到达摩院、头条等公司，天天在叫着在 ICML 或 CVPR 或哪里发了多少论文吗？只有腾讯，每次腾讯 AI Lab 的论文又说发了多少，说实话都是啪啪打脸，意味着务虚的程度又深了一点。只有那些还处于创业阶段的公司，才天天拿着论文，搞个什么 xxxNet，什么比赛获奖了这些来宣传，而腾讯却在干同样的事情。

据我所知，腾讯在最近五六年，从来没有挖到过相当于在 FLAGUAP 等美国硅谷一线公司 senior engineering manager 以上的角色，也没有挖到过相当于 Google L7/Facebook E7 或以上的角色。而这些，才是真正的业界精英，能够推动技术架构和产品前进的。

悲伤的是，腾讯的 HR 部门，似乎对技术业界真牛人完全缺乏概念。在腾讯内部，HR 对投资圈的简直是无脑膜拜，只要是美帝大学的 MBA，那完全是必须破格录取，直接从实习生赐予中层管理岗位 titile，还说这是业界常规（当国内都是文盲吗？麦肯锡还是 BCG 会给一个刚毕业的 MBA 什么 title？还不都是 associate）。而对于 google/facebook/amazon/etc.这些一线互联网公司的工程师，则开始显示所谓的“架子”，让 google 的 L5 只去面试 T3.1 或 3.2，然后各种压包裹...例如有朋友说的真实案例：腾讯海外招聘：来挖狗 5，面试左一轮右一轮，题也做了，“基础”也问了，项目细节也挖了，架构也做了。末了 hr 说可以给 3.1，3.2 要“争取”一下。。。请问这怎么挖？别人 40 万美元入门的年收入在乎你的 3.2？挖一年能挖到半个人吗？当然鹅厂 HR 也可以说硅谷码农也没什么了不起的，不挖也罢（有趣的是这些 hr 挖些啥 facebook 东南亚或者 Google 什么大区的“市场经理”之类的很热情）。

其实，这又存在另一个问题：真正的工程专家到了腾讯，肯定是无法接受各种牵强无理的内部限制，比如繁琐到必须专人负责的 docker 环境和权限，毫无道理的内网分离等。。。对开发流程也必然提出各种修改意见，这一来未必能被中层接受（改变太大），二来，腾讯的锦衣卫企业 IT 所制定的荒谬内部限制，也必然无法接受高端工程专家的质疑，比如前文所说不允许在家远程提交修改代码之类的问题，企业 IT 压根就无法拿出可信理由，但他们要做的并不是去改进，而是压制其他人的反对。

4. 企业 IT：锦衣卫要办的事，大将军又能如何

终于来到这个环节：企业 IT

从技术和工程层面上来说，这是腾讯的最大毒瘤之一，具体细节可以参看这位的回答：

当下（2018 年）腾讯的技术建设是否处于落后同体量公司的状态？

企业 IT，在绝大公司内部，理论上是一个存在感比较弱的支撑部门，然而在腾讯，这不仅仅是关联到内部网络环境，不管什么项目，你必须按照企业 IT 的要求去安排你的开发、测试、部署和发布，而且没有商量。

腾讯的企业 IT 会在没有任何讨论的情况下告诉你你的网络协议不再被支持，是“不安全“的，是必须禁止的，并在禁止使用的内部黑名单上包括了例如 myphpadmin 这类的知名开源软件

然后他们宣称自己的“安全”能力是世界第一

在大部分互联网公司中，对开源的使用是有一定争议。然而无论什么公司，在禁止某些开源工具的同时，会提供对应的打过 patch 的对应定制版本或相似工具来满足需要。

然而腾讯的企业 IT 像极了锦衣卫和某些大家喜闻乐见的部门：只负责下令，只负责禁止，至于造成什么难题，是否提供可选方案，那是一律不管，也不听。

说直白点，企业 IT 是门槛最低的部门，其中所谓啥网络安全策略、网络隔离方案等等根本在其他人眼里是笑掉大牙，但这帮人却把控着莫大的权势。他们真的可以，背后不知道是什么人在撑腰，一天拿着鸡毛当令箭。

真要讲技术的时候，比如心平气和给他们说其实可以用 public_key 认证，其实 ssh 本身比他们自己包的什么狗屁 shell 工具足够安全，他们听不懂，不再回复。

但是没辙，企业 IT 在腾讯内部不知道后台是什么人，反正可以一手遮天，不跟任何 bg 不跟任何其它技术人员讨论，一句公司不允许，就要求你停止服务。

为此我尝试从他们的角度想过很久，只能认为因为以前的网络开发部署，外网内网要求严格隔离，所以企业 IT 不允许任何对外网的服务和内网产生关联。也有小道消息说是因为早期腾讯内网被人入侵过，所以公司非常在意这个问题。

然而他们把内网又分成了三种网络，每种网络不能互通或者需要特别申请，企业 IT 认为这叫“安全”。。。这简直是滑天下之大稽。在这种滑稽的网络划分下，可以把腾讯企业 IT 的错误，尤其是严重影响内部技术框架的错误归纳如下：

不得从远程浏览提交代码（不可在家访问内部 git）
Linux 机器不可加入内网（真的，这是需要特别审批，不然不允许。这直接导致无数机器学习系统压根无法在内部真正接入数据做 online training）
内网服务不可使用除 80/8080 之外的端口（最近好像 8080 都禁止了）
不可自行组局域网（again，直接禁止内部尝试分布式集群）
内网分成三种网络，并实行物理隔断

可以说，企业 IT 是腾讯最大毒瘤，对腾讯的技术产品发展的罪恶罄竹难书！

我们不反对安全，不反对严格的规定，但是，一个部门，和其它部门没有任何沟通，没有任何公开讨论，如同皇帝圣旨一样下令，随意制定规矩，直接影响产品开发流程，等同于古代太监直接命令出战的军队，这是什么一回事？

或者说，企业 IT 确实是有圣旨。因为在咨询公司和投资公司里面，内部 IT 确实就是在做这些屁事。在这些投资公司里面，IT 人员是上不了台面的，是 disposable 的

而，腾讯，在一些奇怪的思路和群体把持下，正好在把一个世界顶尖的互联网公司往三流投资公司转变！

下面来说投资。

5. 投资问题

腾讯内部投资部门无数次用 google 用 amazon 用苹果来给自己辩解，说什么其它一线公司也大量投资。可惜，别人的投资，挖来了人才和技术，整合到自己的产品线，或者把人才融入到自己团队，例如 google 收购 deepmind，facebook 收购 intagram/parse 等等。而砸钱 600 多家公司，却只是像一个中国大妈一般去买股票成为股东罢了。

连接一切这个本应是具有无比技术挑战和吸引力的口号，在这里，却降格成了疯狂入股（买股票）。

关于这方面的错误，已有很多文章讲过，在这里不用我再废话。公司的方向，必然由公司高层决定，而腾讯作为一家上市公司，高层信息是公开的。24 名高管，去掉国外人士还有 19 名，其中香港商业背景的 6 名。可以说腾讯的高管团队印有强烈的“港味”。而其中大部分于 2004 左右入职，也就是腾讯上市前后。

从历史的眼光来看，2004 前后，不光是中国互联网开始成长，各种金融公司、投资公司也开始进入国内，而这些人是自带光环的，用复杂的金融概念忽悠了大把人，直到 2008 年的泡沫破灭。

在当时这种氛围下，相信来自于香港的“高端投资人士”能够把腾讯从一个本地公司带到“世界级公司”，是可以理解的。可以想像，在 2004 年，成长于深圳大学计算机系的马化腾，接触到香港的投行买办时，会觉得对方如何的高大上。这一点，即便在今天，在很多大陆公司接触到麦肯锡 /BCG 等咨询公司时，也会被对方光鲜的外表和听上去 fancy 的复杂理论所迷惑，觉得对方能帮自己变得高大上，走入华尔街。。。

然而，历史过去了十多年，真正走向世界的，是土生土长的阿里，甚至是土生土长的抖音。

无论是腾讯的香港帮，还是香港金融投资本身，都被历史狠狠扇了一记耳光！

在有一篇叫“马化腾的七种武器”一文中用崇尚的语气这样说：“所以说，大公司最保守和安全的方式就是通过资本的方式，因为公司内部已经不可能有任何的驱动力了，只有通过投资来做。“

简直是放狗屁！Yahoo 做成了世界上有史以来恐怕最好的投资，结果呢？现在死到哪里去了？

对于香港背景的投行人士，一向就是华尔街的边缘，说直白点不过是西装革履的买办罢了。香港这么多年来，本来就没有什么创新和产品出现，而且本身就压根没啥世界一线的企业，有什么资格去谈大公司的驱动？互联网公司在成长后如何保持驱动能力，本来就是一个开放性难题，微软在遇到 google/facebook 后拼命挣扎，google 从大数据驱动到 mobile first 到 AI first 不断革新不断强化自己的开发人员，Amazon 从网上销售走到云计算走到 AI，阿里从淘宝到阿里云，哪家世界一线公司不是努力在自我革新自我驱动？

香港从未有人进入过世界一线公司的行列，就自以为能靠投资来驱动？香港买办连华尔街的边角都没沾到，也好意思谈这些？

然而，泡沫的虚高是金融投资的拿手好戏，一个本可以媲美 google 的公司，一个聚集了中国人情感的产品公司，被强行降格成为一个投资公司？

我们要清楚看到：在互联网时代初期，香港也曾有过互联网热潮，但是历史证明，香港为背景的企业高管，其视野、能力压根不适合经营一个世界顶级的科技企业，不可能带动腾讯去与 google/amazon 争雄 ----- 这个工作，现在是阿里在努力。

身为程序员的腾讯员工更要意识到：如果你们和投资公司咨询公司接触过，就会知道其内部工程技术人员的地位几乎就是外包，连真正的内部年会都没资格参加，更遑论什么高额奖金。而有些人，正在努力把腾讯往那个方向转变！这不仅是个人的悲哀，也是中国的悲哀，把一个本是中国科技带头羊的公司，强行降格成为金融投资人士的垫脚石。对于这些人，他们的未来是可期的，在往着投资公司发展的道路上，他们不但会利用腾讯上万程序员的代码和加班去保障他们玩投资的资金来源（已投出腾讯半个市值的股票，美其名曰“护城河”，谁 tm 会在你不行的时候来“护”你？骗谁？），他们也会踩着真正创造了腾讯价值的鹅厂员工去达到他们的目标，买办从来就是做这些事情。危言耸听吗？恐怕不是。

企业 IT 的强势，恰恰在暗合投资 / 咨询公司的特点：内控重于一切，产品技术靠边，没人在意。

一个市值曾进入世界前五的公司，对自己的定位是南山高盛？这算追求？

这不会是马云的追求，不会是李彦宏的追求，不会是王兴雷军任正非的追求，任何大陆的这一代互联网人，都不会在这个时代把自己局限于某个西方企业的模仿。

香港，和印度一样，他们是西方金融的殖民地，如果说印度人以踏入美国硅谷为荣，香港的“金融精英”则以能为华尔街公司的远东分部工作为耀。

要他们以超越西方一线企业为目标，从基因里就缺了这条弦。

6. pony：还在乎腾讯？

在“硅谷”一剧中，高层 CEO 热衷于心灵鸡汤、瑜伽，对实际业务视而不见。

在 QQ 文档推出后，据说马化腾发了个朋友圈说提了 8 年的需求终于实现了。。。

这是高兴，还是可悲？

在这里，这一段就不再多写。一个人的格局可以很高，比如 Bill Gates，他的格局，绝对超越了微软 CEO，他已经在为人类而努力。然而，格局再高，跟能否把一个公司带回正轨是两码事。

ponyma，还对腾讯这家公司留有多少热情呢？

在当前大环境，ceo 去多做社会工作，打点更高层面的一些事情是合理和必须的，然而在这样做之前，公司能托付给投行出身的人吗？他们能真的懂得如何把控腾讯？

古代有买椟还珠的故事，而这帮香港买办正在上演这一幕。无视腾讯优秀的产品和曾经拥有的研发能力，一心只看到流量和资金，用他们狭隘的目光只聚焦在投资分成上。这帮香港买办的视野，并不比古惑仔好到哪里去，只知道收点保护费和小弟的簇拥，自以为声势浩大，其实在真正的强权到来时不堪一击。

写在后面：

本文纯属个人思考和部分联想，如很多朋友指出，有些地方太偏颇。但本文的目标只是从一些直接的角度激发思考，重在讨论，交流胜于一切。

腾讯纵有千般问题，但对言论的宽容，是我所见过仅有的。无论是内网社区还是对外，都能做到非常好的包容度。包括本文，在最初版本发出后，也只是客气地要求不要搞成人身攻击，这是非常合理的要求，因此做出部分调整。

正如文中所说，腾讯的最大特色就是自由度，我相信这在中国企业是罕见的。一个公司只要能保持这种自由和宽容，那就永远有希望。

Kylin 大数据时代的OLAP利器 - CSDN博客

Fri, 14 Sep 2018 21:15:04 CST

Olap简介

OLAP的历史与基本概念

Olap全称为在线联机分析应用，是一种对于多维数据分析查询的解决方案。典型的Olap应用场景包括销售、市场、管理等商务报表，预算决算，经济报表等等。

最早的Olap查询工具是发布于1970年的Express，然而完整的Olap概念是在1993年由关系数据库之父 Edgar F.Codd 提出，伴随而来的是著名的“twelve laws of online analytical processing”. 1998年微软发布 Microsoft Analysis Services，并且在早一年通过OLE DB for OLAP API引入MDX查询语言，2001年微软和Hyperion发布的XML for Analysis 成为了事实上的OLAP查询标准。如今，MDX已成为与SQL旗鼓相当的OLAP 查询语言，被各家OLAP厂商先后支持。

Olap Cube是一种典型的多维数据分析技术，Cube本身可以认为是不同维度数据组成的dataset，一个Olap Cube 可以拥有多个维度（Dimension），以及多个事实（Fact or Measure）。用户通过Olap工具从多个角度来进行数据的多为分析。通常认为Olap包括三种基本的分析操作：上卷（rollup）、下钻（drill down）、切片切块（slicing and dicing），原始数据经过聚合以及整理后变成一个或多个维度的视图。

ROLAP和MOLAP

传统OLAP根据数据存储方式的不同分为ROLAP（relational olap）以及MOLAP（multi-dimension olap）

ROLAP 以关系模型的方式存储用作多为分析用的数据，优点在于存储体积小，查询方式灵活，然而缺点也显而易见，每次查询都需要对数据进行聚合计算，为了改善短板，ROLAP使用了列存、并行查询、查询优化、位图索引等技术

MOLAP 将分析用的数据物理上存储为多维数组的形式，形成CUBE结构。维度的属性值映射成多维数组的下标或者下标范围，事实以多维数组的值存储在数组单元中，优势是查询快速，缺点是数据量不容易控制，可能会出现维度爆炸的问题

大数据时代Olap的挑战

近二十年内，ROLAP技术随着MPP并行数据库技术的发展，尤其是列存技术的支持下，实现了分析能力大幅度的跨越提升，同时伴随着内存成本的进一步降低，单节点内存扩展性增强，集群单节点的查询性能实现了飞跃，内存数据库的实用性跨上了一个新台阶，这些技术进步共同作用的结果是类似的技术基本覆盖了TB级别的数据分析需求。 Hadoop以及相关大数据技术的出现提供了一个几近无限扩展的数据平台，在相关技术的支持下，各个应用的数据已突破了传统OLAP所能支持的容量上界。每天千万、数亿条的数据，提供若干维度的分析模型，大数据OLAP最迫切所要解决的问题就是大量实时运算导致的响应时间迟滞。

2. Apache Kylin 大数据下的Olap解决方案

Kylin的背景

Kylin 是一个Hadoop生态圈下的MOLAP系统，是ebay大数据部门从2014年开始研发的支持TB到PB级别数据量的分布式Olap分析引擎。其特点包括:

可扩展的超快的OLAP引擎
提供ANSI-SQL接口
交互式查询能力
MOLAP Cube 的概念
与BI工具可无缝整合

Kylin典型的应用场景如下：

      *用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据方式存取，数据量巨大，在500G以上*每天有数G甚至数十G的数据增量导入*有10个以内较为固定的分析维度

Kylin的核心思想是利用空间换时间，在数据ETL导入OLAP引擎时提前计算各维度的聚合结果并持久化保存，由于Kylin查询方面制定了多种灵活的策略，进一步提高空间的利用率，使得这样的平衡策略在应用中是值得采用的。

kylin的总体架构

Kylin 作为一个Olap引擎完成了从数据源抓取数据，ETL到自己的存储引擎，提供REST服务等一系列工作，其架构如图所示：

Kylin 的生态圈包括：

Kylin Core: Kylin 引擎的框架，查询、任务、以及存储引擎都集中于此，除此之外还包括一个REST 服务器来响应各种客户端请求。
扩展插件: 各种提供额外特性的插件，如安全认证、SSO等
完整性组件: Job管理器，ETL、监控以及报警
交互界面: 基于Kylin Core之上的用户交互界面
驱动: 提供了JDBC以及ODBC的连接方式

kylin Cube 多维数据的计算

Kylin的多维计算主要是体现在OLAP Cube的计算。Cube由多个Cuboid组合而成，Cuboid上的数据是原始数据聚合的数据，因此创建Cube可以看作是在原始数据导入时做的一个预计算预处理的过程。Kylin的强大之处在于充分利用了Hadoop的MapReduce并行处理的能力，高效处理导入的数据。

Kylin的数据来自于Hive，并作为一个Hive的加速器希望最终的查询SQL类似于直接在Hive上查询。因此Kylin在建立Cube的时候需要从Hive获取Hive表的元数据。虽然有建立Cube的过程，但是并不想对普通的查询用户暴露Cube的存在。

Kylin创建Cube的过程如下：

根据Cube定义的事实表以及维度表，利用Hive创建一张宽表
抽取事实表上的维度的distinct值，将事实表上的维度以字典树方式压缩编码成目录，将维度表以字典树的方式编码
利用MapReduce从第一步得到的宽表文件作为输入，创建 N－Dimension cuboid，然后每次根据前一步的结果串行生成 N-1 cuboid, N-2 cuboid ... 0-Cuboid
根据生成的Cuboid数据量计算HTable的Region分割策略，创建HTable，将HFile导入进来

Kylin与传统的OLAP一样，无法应对数据Update的情况（更新数据会导致Cube的失效，需要重建整个Cube）。面对每天甚至每两个小时这样固定周期的增量数据，Kylin使用了一种增量Cubing技术来进行快速响应。

Kylin的Cube可以根据时间段划分成多个Segment。在Cube第一次Build完成之后会有一个Segment，在每次增量Build后会产生一个新的Segment。增量Cubing依赖已有的Cube Segments和增量的原始数据。增量Cubing的步骤和新建 Cube的步骤类似，Segment之间以时间段进行区分。

增量Cubing所需要面对的原始数据量更小，因此增量Cubing的速度时非常快的。然而随着Cube Segments的数目增加，一定程度上会影响到查询的进行，所以在Segments数目到一定数量后可能需要进行Cube Segments的合并操作，合并是一个异步操作，并不会影响到正常的查询服务。合并操作步骤如下：

遍历指定的Cube Segment
合并维度字典目录和维度表快照
利用MapReduce合并他们的 N-Dimension cuboid
将cuboid转换成HFile，生成新的HTable，替代原有的多个HTable 实际上merge cube是合成了一个新的大的Cube Segment来替代，Merge操作是一个异步的在线操作，不会对前端的查询业务产生影响。。

Kylin对传统MOLAP的改进

Kylin Cube的存储代价以及计算代价都是比较大的，传统OLAP的维度爆炸的问题Kylin也一样会遇到。 Kylin提供给用户一些优化措施,包括减轻维度爆炸的问题，提高数据查询效率等：

Cube 建模优化：

Hierachy Dimension（层级维度）
Derived Dimension （衍生维度）
Group Dimensions （维度组）
Hierachy Dimension，一系列具有层次关系的Dimension组成一个Hierachy，比如年、月、日组成了一个Hierachy，在Cube中，如果不设置Hierarchy，会有年、月、日、年月、年日、月日 6个cuboid，但是设置了Hierarchy之后Cuboid增加了一个约束，希望低Level的Dimension一定要伴随高Level的Dimension 一起出现。设置了Hierachy Dimension 能使得需要计算的维度组合减少一半。
Derived Dimension, 如果在某张维度表上有多个维度，那么可以将其设置为Derived Dimension，在Kylin内部会将其统一用维度表的主键来替换，以此来达到降低维度组合的数目，当然在一定程度上Derived Dimension 会降低查询效率，在查询时，Kylin使用维度表主键进行聚合后，再通过主键和真正维度列的映射关系做一次转换，在Kylin内部再对结果集做一次聚合后返回给用户
Group Dimension，这是一个将维度进行分组，以求达到降低维度组合数目的手段。不同分组的维度之间不会进行组合计算。Group的优化措施与查询SQL紧密依赖，可以说是为了查询的定制优化。维度组合从2的（k+m+n）次幂降低到 2的k次幂加2的m次幂加2的n次幂。如果查询的维度是夸Group的，那么Kylin需要以较大的代价从N－Cuboid中聚合得到所需要的查询结果

数据压缩：

Kylin针对维度字典以及维度表快照采用了特殊的压缩算法，保证存储在Hbase以及内存中的数据尽可能的小。由于DataCube中会出现非常多的重复的维度值，因此直观的做法就是利用数据字典的方式将维度值映射成ID， Kylin中采用了Trie树的方式对维度值进行编码

distinct count聚合查询优化：

Kylin 采用了HypeLogLog的方式来计算Distinc Count。好处是速度快，缺点是结果是一个近似值，会有一定的误差。具体的算法可见Paper： http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf 本文不再赘述。

kylin SQL查询的实现

Kylin支持标准的ANSI SQL, Kylin的SQL语法解析依赖于另一个开源数据管理框架 Apache Calcite， Calcite即之前的Optiq，可以说是一个没有存储模块的数据库，即不管理数据存储、不包含数据处理的算法，不包含元信息的存储。因此它非常适合来做一个应用到存储引擎之间的中间层。在Calcite的基础之上只要为存储引擎写一个专用的适配器（Adapter）即可形成一个功能丰富的支持DML的“类数据库”。目前Calcite已在Hive、Drill、Phoenix项目中被使用。

Kylin完成了一个针对性的Calcite Adapter，在Calcite完成SQL解析，形成语法树（AST）之后，Kylin定义语法树各个节点的执行规则，以及查询优化准则。Calcite在遍历语法树节点后生成一个Kylin描述查询模型的SQL Digest， Kylin会为此Digest去判断是否有匹配的Cube。如果有与查询匹配的Cube，即选择一个查询代价最小的Cube进行查询（Kylin Cube的查询代价计算目前是一个开放接口，可以根据维度数目，可以根据数据量大小来计算Cost）

Kylin目前的多维数据存储引擎是HBase， Kylin利用了HBase的Coprocessor机制在HBase的Region Server完成部分聚合以及过滤操作，在Hbase Scan时提前进行计算，利用HBase多个Region Server的计算能力加速Kylin的SQL查询。

再看kylin 与 RTOLAP

Kylin 可以说是与市面上流行的RTOLAP走了一条完全不同的道路。 Kylin在如何快速求得预计算结果，以及优化查询解析使得更多的查询能用上预计算结果方面在优化，后续Kylin的版本会优化预计算速度，使得Kylin可以变成一个近似实时的分析引擎。然而其缺点就是SQL支持方面可能在一定程度上会有所牺牲，存储开销也会比较大，而像Presto，SparkSQL，Hawq等是着重于优化查询数据的过程环节，像一些其它的数据仓库一样，使用列存、压缩、并行查询等技术，优化查询。这种方案的好处就在于扩展性强、能适配更广泛的查询，然而由于每次的聚合计算是 On Fly的，因此性能上相较Kylin还是有所不如。

3. Kylin在网易

Kylin服务化

在网易，Kylin作为大数据平台的Olap查询模块，可以为公司的各种分析类需求以及应用提供服务。所有数据存在Hadoop Hive 上的数据都能够通过Kylin Olap 引擎进行加速查询。在公司内部Kylin作为一个统一平台，与各产品的数据仓库进行接驳。

目前Kylin的部署架构如下：

Kylin集群由多个查询节点以及控制节点组成。控制节点唯一，负责集群项目、任务调度与Cube增删查改。多个查询节点前用Nginx做负载均衡，后段节点可按需水平扩容。前端可同时支持JDBC与ODBC的客户端查询

Kylin性能表现

在Kylin上线前，我们针对NRPT的报表业务进行过性能对比，对比内容在相同的数据下、Kylin查询与Mondrian 结合Oracle的查询比较。我们选取了数据量较大的DataStream报表业务进行了测试：

再看Kylin的吞吐量，利用Haproxy进行请求转发后随着Kylin服务器的增加吞吐量的表现：

根据测试结果可见，Kylin OLAP在性能上能达到秒级，并且在查询吞吐量可以通过增加查询服务器来达到线性扩展的目的

网易对Kylin的改进

原生的Kylin 是需要部署在一个统一底层的Hadoop、Hive、HBase集群之上的。而网易内部的大数据平台由于各种原因，分为了多个Hadoop集群、各应用会在不同的Hadoop集群上建立Hive数据仓库。最原始而自然的想法就是在每一个Hadoop环境上部署一套Kylin服务来满足不同的需求，但是集群资源管理、计算资源调度、管理运维的复杂性都会是一个比较突出的问题。例如用户数据在A机房的Hive上，而A机房的Hadoop集群并没有足够的计算资源来保证Kylin Olap的高效运行。因此根据公司内部实际的大数据平台分布情况及机房建设情况，将Kylin打造成一个公司内统一的服务平台是一个更好的选择。Olap小组对开源版本的Kylin进行了二次开发，并将改进补丁提交了社区。目前的改进主要包括：

Kylin对Kerberos认证的支持
Kylin非Hadoop节点的部署支持
多数据源的支持

综合分析现实的场景之后，我们选择了公司内最大的hadoop集群作为Kylin Olap的计算引擎集群，保证有充足的存储以及计算资源。 HBase采用一个独立的集群，避免Hbase查询和Hadoop集群任务之间的互相干扰。数据源Hive允许用户自定义，目前已支持同Hadoop集群下不同Hive 以及不同Hadoop集群下的不同Hive节点使用Kylin Olap服务。根据用户数据仓库的实际配置情况可能会出现跨集群的数据源抽取计算，由于公司同城机房有专线网络，数据仓库Hive里的源数据量也远小于Kylin实际的聚合后的数据存储（存于Hbase，数据量大小一般为数据源Hive中的10倍以上），因此可认为这样的开销可以认为带来的影响不大，并且在我们的测试中得到了印证。

Kylin OLAP与猛犸以及有数的结合

为了让Kylin更快更好的融入到大数据平台中，OLAP小组已计划在不久之后全面与猛犸大数据平台进行打通和整合， Kylin Olap 将深度内嵌于猛犸，用户可以基于猛犸平台完成Kylin Olap的简化管理工作。猛犸平台对接控制节点，作为数据模型师的操作入口

Kylin将利用猛犸的用户管理功能
猛犸将接管用户项目的创建以及Cube的管理
猛犸将原有的Hive数据源彻底与Kylin打通，便于Kylin管理用户的数据源

网易有数会成为Kylin Olap的一个重要的分析师入口，有数将Kylin Olap作为一个单独的数据源进行支持。已有的以及潜在的Hive查询客户可以轻松的将报表迁移到Kylin Olap，使得大数据量下的交互式报表分析称为可能。

有数能基于在猛犸上创建的Cube创建报表
有数会主动识别Kylin Cube定义的维度和度量
用户在Kylin Olap允许的范围内自由操作，完成报表的编辑和查询。

AI时代的全链路监控，阿里工程师怎么做？

Sun, 09 Sep 2018 20:23:38 CST

阿里妹导读：全链路监控从业务的视角出发，监控整个业务流程的健康状况，无需多个系统切换，直观看到全局和上下游，方便快速发现、定位问题。今天，我们一起来看看阿里基础设施技术团队在这方面的实践经验。

背景

近年来，随着阿里新业务、新技术的快速发展，传统的业务总量“监控大盘”已经越来越不能满足监控需求，主要表现在以下几个方面：

缺乏全局视角：“监控大盘”主要反映的是单个业务或应用的运行状态，缺少全局的业务视角能反应整个“业务域”的上下游整体的运行情况。比如交易系统成功率下跌，想看看是不是优惠出问题了，但是不知道“优惠”的业务监控在哪里，只能依赖"优惠"的同学去排查，钉钉电话沟通，大家一起拼凑信息，上下游协调成本很高。

监控标准不统一：一直以来“业务监控”都是自定义的，依赖开发人员的个人经验，往往系统、业务监控混在一起，没有标准，业务之间不能比较；各系统监控能力参差不齐，很容易出现业务链路中的监控断层；业务监控缺少一套行之有效的方法论，新人或者新业务对于业务要怎么监控，不知道如何下手、不知道自己配的监控是否覆盖全面，只有等到故障发生以后才去补监控。

缺少业务视角：随着阿里业务飞速发展，特别是“大中台”的建设，使得传统的“总量”监控已经不能满足需求，比如一个“交易”中台业务就会有数十个“业务方”调用，单纯的总量监控会把小调用量的业务淹没，必须按每个业务方的“业务身份”进行监控。对于像“盒马”、“淘鲜达”这样的新零售业务，这样的问题更加突出，一家门店出现交易异常对于“交易总量”来说是微不足道的，但是对这件门店的客户体验来说是灾难性的。

监控配置成本高：“业务监控”一直都是由“开发人员”纯手工打造，需要经过日志埋点、监控配置、报警阈值设置，整个过程费时费力，缺乏自动化、智能化监控的手段，这也是造成各系统监控能力参差不齐的重要原因，一些新业务因为无力投入大量精力配置监控，导致业务监控能力缺失。

全景式监控

业务全链路监控从业务的视角出发，监控整个业务流程的健康状况，无需多个系统切换，直观看到全局和上下游，方便快速发现、定位问题。

建立了完整的“业务监控模型”，为业务建立起一个从“宏观”到“微观”的全景式业务监控体系，结束了业务监控没有标准，只能纯手工打造的历史。业务监控模型主要包括 3 部分：

业务域：一个完整的业务或产品称为“业务域”，如电商的“交易域”、“营销域”、“支付域”等。
业务活动：业务域中的的核心业务用例叫做“业务活动”，如交易域的“下单确认”、“创建订单”等，业务活动是整个监控模型的核心，每个业务活动都会有标准的【黄金指标】来反应自身的健康状况，业务活动之间建立上下游关系就形成了业务链路。
系统服务：业务活动中的依赖的关键方法称作“系统服务”，如“下单确认”包含：查询会员、查询商品、查询优惠等关键方法，每个系统服务也通过【黄金指标】来表示其健康状况。

监控流程

以“监控模型”为基础，我们总结出了一套如何做好“业务监控”的方法论，并将其沉淀到产品中。

梳理关键业务：业务方需要梳理出自己的核心业务是什么（业务活动），以及这些核心业务的关键依赖有哪些（系统服务）。
监控数据埋点：提供了无侵入的配置化监控 SDK，只要将“业务活动”和“系统服务”对应的方法填写到配置文件中即可，系统会自动收集，计算，上报监控数据。
监控链路：系统根据收集的数据自动生成业务链路，每个“业务活动”和“系统服务”节点都自动生成流量、耗时、成功率的黄金指标，同时每个‘节点’都可以通过钻取查看详细的监控数据，包括：不同机房、单元、分组的数据对比，每个业务身份的明细调用情况等。
异常检测：业务链路涉及节点众多，必须要有完善的异常检测机制来帮助用户自动发现问题，我们提供了“智能基线预警”和“专家规则预警”相结合的异常检测机制，无需用户逐个配置报警规则，自动发现异常节点，实时将这些节点“标红”，异常的详细信息也会同步显示，方便用户快速发现和定位问题。

通过业务全链路监控，可以做到对业务域的监控标准化和全覆盖，避免了自定义监控覆盖不全面、不标准、配置工作量大的问题，使得老板、PD、运营、监控值班等用户都可以快速了解业务是否有问题。

黄金指标

引入 Google 的黄金指标概念，改变了业务监控完全依赖自定义的现状，为业务监控树立了标准。

流量：业务在单位时间内的调用量，如：服务的 QPS、每秒订单笔数等。
耗时：业务的具体处理时长，需区分成功耗时和失败耗时。
错误：调用出错数量、成功率、错误码。
饱和度：应用已使用资源的占比。

由于饱和度更多反应的是应用的层面情况，所以业务监控使用流量、耗时、错误这三个指标就能很好的回答“业务”是否健康的问题，在“业务全链路监控”中每个业务活动和系统服务都会标配这三个监控指标。

除了黄金指标以外，还可以根据各自业务的不同特点，定义各种分维度的辅助指标，比如：按不同的业务身份，按商家、按门店分，不同的错误码等等，用于进一步细化和定位问题。

业务维度

传统的“总量”指标已经不能满足中台、盒马这样的业务监控需求了，通过可扩展的业务维度实现对业务身份、商家、门店的精细化监控。像“交易”这样的中台业务会被几十个业务方调用，总量没有异常并不代表具体的业务方没有问题，而是需要监控每一个业务方各自的调用情况，只要有一个出现异常就要预警。

横向业务维度：业务全链路监控提供了“横向业务维度”功能，能够方便的配置“业务身份”、“商家”、“门店”等特定的业务维度，可以对一个业务域中所有的“业务活动”和“系统服务”按一个维度过滤，比如可以对交易链路按“盒马”这个业务身份过滤，从而在链路上看到的是盒马的交易调用情况。

配置化埋点

监控 SDK 使用 AOP 切面技术实现了配置化埋点能力，业务系统引入监控 SDK 后，通过简单的一个配置文件即可完成监控埋点，自动完成数据的拦截、计算、上报，与业务代码完全解耦。

链路自动生成

自动生成应用核心链路、黄金指标、业务维度大盘，无需用户配置，用户还可以通过可视化编辑页面对链路进行调整。

智能基线预警

通过机器学习快速预测指标的合理范围，一旦超出边界就会自动触发报警，无需配置阈值。

智能基线预警已经在业务自定义监控中得到了验证（已经有超过 1200 指标接入），准确率和召回率相对于人工配置都有大幅提高，现在我们将该技术引入“业务全链路监控”，实现对业务活动的智能异常检测，全程无人参与。

实战

实战1-交易全局链路

交易域的全局业务链路，链路中列出交易的关键“业务活动”，省略了每个业务活动的“系统服务”等细节，主要用于全链路压测，大促投屏等需要关注全局状态的业务场景，已在 6.18 大促中得到实际应用。

实战2-交易核心链路

交易是整个电商的核心，我们通过“链路自动生成”能力生成了核心业务链路，其中绿色节点为“业务活动”，黄色节点为“业务活动”依赖的“系统服务”。

通过业务链路可以很方便了解交易活动的运行状况，一旦业务活动出现问题也可以更加直观的发现与下游依赖的关系。

实战3-POS 服务端链路

POS 是整个新零售场景线下支付场景的交易核心，下线支付场景对交易系统提出更加严格的可靠性要求，通过 POS 业务链路可以很好的监控 POS 交易各环节的运行情况，及时发现交易异常。

同时 POS 链路添加了“商家”、“门店”的业务维度，可以实时切换“盒马”，“大润发”等不同商家的 POS 交易情况，实现针对每个商家精细化监控。

关于我们

集团监控平台团队是阿里巴巴研发效能事业部下的监控开发团队，面向阿里庞大的应用生态与海量的服务器，致力于打造业内一流的智能化监控平台，保障阿里集团各业务的稳定运行。我们非常欢迎各位监控领域的产品或技术牛人加入我们团队。欢迎投递简历至：jingjie@taobao.com。

本文链接

从信息时代走向声誉时代

Mon, 19 Mar 2018 21:03:54 CST

在我们高度互联的自由民主社会里，未受到重视的知识悖论在其中扮演了一种关键角色：流通的信息量越多，我们越依赖于所谓的“声誉设备”去评估它。造成这种悖论的原因是，我们今天大量获取到的信息和知识并没有让我们具有认知上的自主。相反，它让我们更依赖于其他人对信息的评估和判断。我们与知识的关系正经历范式上的转变，我们从信息时代开始走向了声誉时代，信息只有在被其他人过滤、评估和评论之后才具有价值。由此看来，声誉成为了今天集体智慧的核心支柱。它是知识的看门人，而门的钥匙被他人掌握。知识权威的建立方式使得我们依赖于其他人不可避免的偏见判断上，而我们大多数人对此一无所知。以气候变化为例，你是否相信气候的变化会危及地球未来的生活，你提供的答案是否来自于你信任的信息源？

凯西·奥尼尔：盲目信仰大数据的时代必须结束 | 算法密码

Sat, 03 Feb 2018 09:16:04 CST

麦法兰中学是位于华盛顿的一所平民社区高中，拥有如茵的草坪、联排红墙教学楼和多种族学生。女教师莎拉·韦索奇2009年来到这里，她对教育非凡的热忱很快感染了同事和家长。

“她是我见过最好的老师之一。”麦法兰中学家长教师协会负责人布莱恩·多尔西说，他的女儿是莎拉的学生，“每次见她，她不是在辅导孩子，就是与他们谈心。”

学校2011年5月对莎拉的评估报告也佐证了这一点：“我们很欣慰看到这么一个教与学互动积极、运转高效的课堂。”莎拉还被推荐到其他学校分享经验。

然而仅两个月后，莎拉被解雇了。一套叫“IMPACT”的教师评价系统认为她相当失败，原因是她任教班级的阅读和数学成绩没有实现预期增长。

这次教学评价源自华盛顿特区自2007年推行的教育改革方案，时任教育局局长李洋姬将这里低迷的高中升学率归咎于教师的失职。这位作风凌厉的女士决心炒掉数百名表现差劲的教员。为了让落刀更加精准高效，她引入一套计算机算法系统，即“IMPACT”，它通过琳琅满目的指标和一个极其复杂的回归方程，组成一个“增值模型”，自动为每位教师打分并决定其命运。

纵使莎拉的其他指标非常优秀，但“增值模型”的得分却异常低。她很愤怒，写信质询教育局：“我想知道，这些数据是怎样计算出来的？”

没有人理会她。《华盛顿邮报》为此写了一个报道，标题充满黑色调侃和同情——《我激情，我创造，我被炒了》。很快，莎拉收到一封来自纽约的邮件，是凯西。

凯西被这个案例吸引，她给莎拉打电话，掌握更多细节，逐渐看清其中的猫腻。两位女士还共同查阅莎拉班上一些转学学生的过往成绩，发现他们在前一所学校的阅读分数都异常高，是所在学区平均分的五倍。

莎拉在实际教学中却发现相反的事实，这些学生连阅读简单句子都困难。凯西又查阅媒体，发现该学区涂改测验成绩的现象非常普遍。也就是有人作恶了，然后把这些虚高的成绩交到老实人莎拉手上，并通过算法让其受到不公惩罚。

莎拉将这一发现向管理部门举报，得到的回复是：必须明确指出作弊老师和学生的名字，还要有充足的证据反驳“IMPACT”的打分。这几乎是一个黑客级的难题，而莎拉只是一个社区中学五年级的老师。

随着研究的深入，凯西发现了“IMPACT”系统更多的底层逻辑漏洞。“学生的成绩受很多因素影响，要量化一个教师在其中的作用非常困难，也非常复杂。”她说，“而且仅凭二三十个学生的成绩来决定一个人的去留，在统计学上也是靠不住的。”

“IMPACT”系统最终解雇了两百多名教师，主导者却没有获得期望中的支持。当地工会的民意调查显示，民众对教师清洗行动“非常不满意”，一些教师协会也举行抗议，并帮助遭受不公对待的教师提出申诉。这最终影响了时任市长艾德里安·芬提的连任，教育局局长李洋姬也随之辞职。

无论如何，算法对莎拉的判决已无法挽回。但幸运的是，她仅失业了几天，在很多同行和家长的推荐下，很快在一个富裕社区学校找到教职，而且那里不再有机器给她打分。

“拜一个非常可疑的模型所赐，穷人的学校失去了一位好老师，富人的学校却得到了她。”凯西说，“未来，富人的事务会由人打理，平民的事情则交由机器。”

AI时代：推荐引擎正在塑造人类

Mon, 22 Jan 2018 00:00:00 CST

We shape our tools and afterwards our tools shape us. ——Marshall McLuhan

麦克卢汉说：“我们塑造了工具，反过来工具也在塑造我们。”

我本人不反感AI，也相信人工智能会开创一个伟大的时代，但是我们要思考一些东西，至少知道那是什么。本人旨在让你了解当前人工智能应用最普遍的智能推荐引擎（Intelligent Recommendation Engine），其背后的设计理念，以及一些更深度的思考。关于理念，它不像技术要求太多的基础，我尽量不使用专业术语，所以本文同样适合程序员以外群体。

从“分类”说起

以大家熟悉的分类信息网为例，像58同城、赶集网。网站把现实生活中的商品、服务进行分类进行展示，比如房产、二手车、家政服务等。这些内容即是现实世界对应的抽象，我们可以很容易的找到对应关系。

我们再以求职网站为例，像智联招聘、BOSS直聘。网站按照职业把人分类，比如程序员、厨师、设计师、数学家、物理学家等。

那么现在问题出现了，众所周知，人工智能的完美入门人才是具有数学和计算机双学位的硕士以上学历人才。那么，我们如何把这样的人分类呢？我们无法单一的将其归入到程序员或者数学家，我们无法为每一个这样的复合型人（slash）进行单独分类。

分类产生矛盾。

我们区分南方人、北方人，所以有地域歧视。我们区分亚洲人、欧洲人，所以有种族歧视。“分类”只是人类简化问题逻辑的手段，薛定谔的猫和罗素的理发师已经证明了“分类”并不正确。所以在大计算时代，我们引入“贴标签”的概念。

贴标签

AI时代是计算能力爆炸增长所带来的。在强大的计算能力面前，我们真的可以针对每个人进行“分类”，它的表现形式就是—贴标签。

30岁以下、程序员、屌丝、奶爸、熬夜、不爱运动、公众号叫caiyongji、格子衬衫、机械键盘、牛仔裤……这些可以是一个程序员的标签。换个角度，“类别”反转过来服务于单独的某个人，这是在计算能力短缺的时代所无法想象的。

传统的智能推荐引擎对用户进行多维度的数据采集、数据过滤、数据分析，然后建模，而人工智能时代的推荐引擎在建立模型步骤中加入Training the models（训练、测试、验证）。

最后，推荐引擎就可以根据用户标签的权重（可以理解为对标签的打分，表示侧重点），对用户进行精准推送了。

无关推荐(Non Relational Recommendation)

对于你从来都没思考过的事物，你可能永远都接触不到，因为你不知道求索的路径，所以有的人每个月都读与自己专业无关的书，来扩展自己的知识面。我们举个例子：

你可能会在网上搜索如何与女朋友和谐相处但你未必会搜索如何让女朋友们和谐相处，有人笑谈“贫穷限制了我的想象力”，其实不然，是你接收不到无关的推荐，你才被限制在特定的知识圈子里。

所以我提出无关推荐这个概念。

对程序员进行画像：

如图，当某个标签没有到达“程序员”的路径时，他可能永远无法触及那个标签。这时，我们推荐“无关”信息给用户，强制产生路径。

你可能会质疑，这是随机强制推荐垃圾信息吗？

其实不然，通过深度学习，我们可以进行大量的数据收集、数据分析和模型训练，我们是可以找到对某个个体无关，但会让其感兴趣信息的兴趣点。这种信息就是无关推荐的解。

最后

你每天接收到的“推荐”背后是各个团队经过心理学研究、行为学研究、大量计算设计的， 人们正在失去深度思考、自主判断的能力。对于进步青年、斜杠青年请保持思考。谨以此文献给希望进步的你，希望你有所收获和思考。

作者微信公众号： caiyongji

End.

转载请注明来自36大数据（36dsj.com)： 36大数据» AI时代：推荐引擎正在塑造人类

阿里携联发科合攻智能家居助IoT时代加速到来

Mon, 15 Jan 2018 14:36:46 CST

参考消息网1月15日报道台媒称，阿里巴巴人工智能实验室（A.I. Labs）与台湾联发科于美国当地时间9日在拉斯维加斯举行的2018国际消费电子展（CES）上签署策略合作协议，针对智能家居控制协定、物联网晶片订制、AI智能装置等领域展开长期密切合作，助力加速智能物联网（IoT）的发展。

据台湾《旺报》1月11日报道，2018国际消费电子展（CES）上，蓝牙技术联盟、阿里巴巴人工智能实验室、联发科共同参与发布了IoTConnect智联网开放连线协议。阿里与联发科将联手打造首款支持蓝牙mesh技术的Smartmesh无线连接方案，推进蓝牙mesh技术在智能家居的商用落地。

此前，阿里巴巴A.I.Labs与联发科已在智能音箱天猫精灵上进行合作，由联发科为天猫精灵订制专属高效能晶片。

Smartmesh方案支援蓝牙技术联盟（SIG）最新公布的蓝牙mesh技术及蓝牙5功能。联发科为阿里巴巴量身打造的客制蓝牙晶片MT7581及MT7583，具备蓝牙Smartmesh、自动配对、快速连接、超低功耗等特性。采用该方案的智能家庭设备，能够自动快速进行蓝牙配对和建立网络连线，将加速布局以天猫精灵为中心的智能家庭生态系统。

报道称，天猫精灵为使用者提供了一种全新的语音互动体验，自去年7月底发布以来，目前已有数以千种家庭设备透过天猫精灵互连互通，并在2017年“双11”天猫全球购物狂欢节期间实现了百万台的销售纪录。

联发科副总经理暨家庭娱乐产品事业群总经理游人杰表示，联发科与阿里人工智能实验室策略合作，共同推动围绕在语音互动的智能家庭生态圈。此次合作协议的达成正是基于双方在智能音箱天猫精灵合作上的成功。

游人杰进一步表示，随着各方面技术的进步，智能家居市场正进入快速发展期。联发科在连网技术及基频晶片、行动运算和多媒体等领域具有技术优势，而阿里巴巴在云端运算及人工智能等方面具有领先地位，双方联手将加速IoT时代的到来。

消费过剩时代

Sat, 13 Jan 2018 23:23:53 CST

在国际贸易相关的经济学理论里，中国是个奇葩的存在，一般经济学认为各个国家分工明确，各取所长，能够实现整体效率最优。这种观点一度是国际贸易的主流观点，但是中国的存在成为bug，中国制造业的蓬勃发展，短短二三十年，可以在几乎所有领域碾压其他国家，也就是说，中国几乎可以凭一国之力解决全球大部分品类消费品的生产制作（当然，仍然有少数领域，暂时例外），几乎在各个领域实现效率最优，真的是那句话，走自己的路，让别人无路可走。

这个bug带来了连锁反应，发达国家的制造业，实体经济全面萎缩，只好依赖金融行业，金融危机一爆发就原形毕露。中国政府又严控外汇市场，想薅羊毛补回去的路也没了。但这个问题又反噬过来，因为西方经济下滑，消费力下降，那么回过头来对中国的订单需求也就下降，再回头看，哎呦，中国生产已经显著过剩了，大量产能闲置，也就几年前的事情吧，这个问题对中国来说还是非常严重的。

自己的问题要自己解决，既然生产过剩，就要想办法消费掉，形成循环，经济才能继续前进，那么问题来了，怎么循环？

于是这几年有个口号，消费升级，让老百姓提升消费水准，提高消费能力，当然，消费升级还是解决了部分问题的，但根本问题，生产过剩的问题，却并不能简单依靠消费升级来解决，毕竟，消费升级要的是质，却并不能解决量的问题。所以，实际上，市场自己找到了一条出路，也就是今天要说的，消费过剩。

什么是消费过剩，我们每个人检查一下自己的房间，自己的衣柜，自己的抽屉，看看自己的淘宝记录，有多少东西买来后几乎没有用过，或者只用了一两次就再也不使用的。不说别人，我自己都很多了。

我以前喜欢看一些古文小说，比如三言两拍，小说家的描述很多都是当时社会真实生存环境的写照，那时候所谓家当很多是传家的，物资稀缺，各种破烂东西都要传给下一代。我们看西游记也是，猪八戒经常说分行李，要搁现在几个穷和尚的行李有啥可分的。

我的父母一代也是从物资紧缺的时代过来的，想象当年买什么都要凭票供应，我小时候是没有新衣服穿的，从来都是穿各个亲戚和兄长的旧衣服，所谓百家衣也差不多了，也不会觉得不妥，第一件属于自己的新衣服是高中的校服。

但现在，买一条裤子回来，妈的，太紧了，穿不下，（我就不承认自己又胖了！）扔柜子里就不理会了。买双鞋回来，走一天，脚磨破了，再也不穿了，似乎也不会说退货啊，浪费啊，反正也不贵，换一家再买一双就是了。（裤子么，假装相信自己以后会瘦下来。。。）

那么说消费过剩，其实目的不是谈论社会责任什么什么的，消费过剩衍生的商业环境变化和市场手段，是我们往往视而不见的。

说个最简单的例子，10块钱你买不了吃亏，10块钱你买不了上当。这词熟悉不熟悉。

你花一点钱，买个廉价的东西，不好用就不好用吧，随手丢掉，或者扔哪里不管了，这对于年轻人来说，已经习以为常。我女儿的房间里，各种手办和玩偶早就塞满了，还嫌家里房子太小，这个商品的所有体验几乎就只发生在挑选和购买的过程。

消费过剩年代出了一种新的经济模式，制造和包装廉价垃圾产品，然后用漂亮的宣传手段把产品卖出去。从经济上来说，似乎也是一种必然，这样上游原材料的生产过剩也有出口了，市场各个环节，包装，物流，营销，流量运营也都有了基本的收入保证，然后这些收入又回流到消费垃圾产品。

而在这个产业里，消费者的体验变成了，精心挑选，愉快购买，秀给朋友圈，然后不定时清理。

前段时间有人希望我讲讲一些消费降级的现象，其实没有消费降级，只有消费过剩。

我这个岁数的人越来越跟不上时代了，我最近总算搞明白了这个逻辑，但你说我会做什么，算了，也就说说而已。

网红经济，粉丝经济，微商，拼团，太多消费过剩的垃圾商品，当然，我不能说全部都是，但这里面有太多商品，只满足了挑选和购买愉悦的需求，完全不具备可长期使用的价值，有些甚至是负使用价值，从我们那个年代来说，这样的商业思路理应是不存在的，但今天，这已经成为很主流的商业逻辑，而其中佼佼者更早就是成功典范，商业奇才。

消费过剩是长期存在的，我买的衣服和鞋子浪费掉可能只是尺码问题，或者是因为一些其他特殊原因，本身商品到不见得有多大问题；这种消费过剩来自于经济条件的提升，但越来越多的商家和营销专业人士意识到，消费者的购物体验甚至大于使用体验，这就带来了各种衍生的玩法，充分满足你的购物愉悦，而产品体验，只要价格便宜，买不了吃亏，买不了上当，消费者不在意的。

前几天在首尔（前大汉真番郡）冻成狗，鼠标也不知道丢哪里去了，所以更新较慢。

本题图与内容无关，看着比较过瘾。

IT瘾时代推荐

AI造就 “默认为假”的时代 - 太隐

1、“默认为假”的时代

2、 传统好比人体免疫机制

3、可以入道

4、言语道断

5、王夫之谈史

6、毛泽东与《三垂冈》

7、王阳明没说过“父母即佛，心外无佛”

8、

9、洗脚注意事项

教育模式转变：AI时代的顶层学习法

成为超级个体：AI时代的研发人员编程技巧最佳实践 - Phodal | Phodal - A Growth Engineer

1. 生成式AI的能力与局限性

AI 体验的“曲折”过程

2. AI辅助编程工具的实用技巧

如何构建有效的提示词

3. 融入软件工程实践，降低校验成本

4. 重构开发流程：加速产出，优化知识转化

5. 面向未来：适应技能变化，放大专业能力

结语

面向GPT-4编程的时代来了：Github Copilot大升级，首次集成聊天功能

大数据时代下，如何识别垃圾信息？

一、如何识别垃圾信息？

1. 大话、空话；让人不知所云

2. 缺失的信息

3. 错把关联当因果

4. 小心平均值和中位数

5. 正确理解 p 值

6. 误导性坐标轴（misleading axes ）

7. 操作箱尺寸

8. 过度装饰

9. 科学的可复制和可重复性

二、最后

广汽曾庆洪：电池占车 60% 的成本，我们在给宁德时代打工

请暂时抛弃使用 eBPF 取代服务网格和 sidecar 模式的幻想

什么是 eBPF

eBPF 的局限性

eBPF 与服务网格的关系

每个主机一个代理的模式比 sidecar 更糟

总结

参考

平均三天一出手，宁德时代急眼了？

华语音乐的最后希望在宝岛，宝岛音乐的希望在年轻的乐团，分享一下我心中那些值得一听的新时代台湾乐团

前言

现在让我们开始分享吧

1 、美秀集团

2 、浅堤

3 、怕胖团

4 、热写生

5 、青虫 aoi

6 、当代电影大师

7 、Crispy 脆乐团

8 、好乐团 /Goodband

IoT物联网时代怎么挣钱？_阿朱=行业趋势+开发管理+架构-CSDN博客

海康威视：形成软件开发方法论，社会经济到了由商业需求拉动的时代

云原生时代 - 知乎

第一部分——云原生及CNCF基金会

第二部分——DevOps与CI/CD

第三部分——微服务、API管理与集成

第四部分——容器和Docker

第五部分——Kubernetes与容器编排之战

第六部分——机会与思考

RabbitMQ实现即时通讯居然如此简单！连后端代码都省得写了？

摘要

MQTT协议

MQTT相关概念

RabbitMQ启用MQTT功能

MQTT客户端

前端直接实现即时通讯

在SpringBoot中使用

总结

项目源码地址

全球印钞时代：钱，是如何印出来的？

日本新电影中的爱情：低欲望时代，激情与倦怠的二元对立 - 文化 - 新京报网

GitHub - cnlh/nps: 一款轻量级、功能强大的内网穿透代理服务器。支持tcp、udp流量转发，支持内网http代理、内网socks5代理，同时支持snappy压缩、站点保护、加密传输、多路复用、header修改等。支持web图形化管理，集成多用户模式。

nps

背景

目录

安装

2、传统好比人体免疫机制