Zoom的“冰与火之歌”

2020 年 4 月 19 日

Zoom的“冰与火之歌”

谁也没想到一场疫情让 Zoom 在短短两个月内市值翻了一倍,而更没想到仅仅在一周内,因为安全问题引发的舆情让 CEO 袁征频繁出面道歉,股价又从最高点重挫近 30%。


前有 Marc Benioff 离开老东家 Oracle Siebel 创立了 Salesforce,后有袁征离开 Cisco Webex 创立了正处于“冰与火”之中的 Zoom。


回顾视频会议技术的发展史,不得不让人惊叹于历史的相似与轮回。


2003 年同样是一场我们熟知的非典疫情,成就了一家现在已被大多数人忘却的远程会议方案公司——Polycom(宝利通);


2020 年这场可能连病源都与十七年前相似的灾难,再一次成就了以 Zoom 为代表的新一代视频会议技术公司。


再过十几年,我们还会看到 Zoom 吗?


想起巴菲特常说的一句话:


我只想知道将来我会死在什么地方,这样我就不去那儿了”。


在下文里,我将用三条小学公式诠释视频会议技术的更迭;再通过三家代表性公司解析商业背后的成败。


只有借前车之鉴,才能解锁 Zoom 之未来。


视频会议的鼻祖:视频电话


关键词:一对一、编解码、协议标准


视频电话,更准确地说是“一对一”视频通话。


让我们回到上世纪 30 年代——1930 年,一款叫做“Iconophone”的双向可视电话原型机诞生于著名的贝尔实验室,“双向连通”奠定了这种“图像式电话”走向商用的基础。



而视频电话真正得到普及是在上世纪 90 年代,为什么呢?我们先了解一下打一通视频电话需要的设备:


  • 输入设备:摄像头、麦克风;

  • 输出设备:从可视电话到后来的专用设备、PC等;

  • 数据网络:电话拨号专用网、卫星线路、LAN(局域网)或广域网等;

  • 计算设备:通信协议解析、数字信号编解码处理等。


整个过程如下图,记住里面的五组词你也可以在朋友圈装装极客了!



首先,传输过程中最关键的是数据传输的 实时性,一般来说发生超过 300 毫秒以上的延迟,用户就会明显感到图像模糊或卡顿等现象。


其次,由于视频电话包含了声音和图像,在传输时两种信号必须同时打包处理,以保证两者的 同步性


而视频电话能真正传播开来是因为具备了以下三个条件:


  • 数字图像及高效的编解码技术(俗称“打包工具”):将压缩比提升到1:500以上;

  • 终端通信协议终于达成国际统一标准:以前终端的编码器必须来自同一厂商,现在基于一套国际标准即可实现不同设备和系统间互通;

  • 网络基础设施和集成电路的飞速发展:在这个诞生了雅虎、亚马逊、eBay的年代,不管是网络传输设备还是CPU处理能力都得到显著提升,带宽成本也快速下降。


从用户角度,当时对音视频的质量要求并不高,因为那时候通话设备本身清晰度就比较低。


也是在这个互联网的黄金时代,一系列视频会议技术公司相继成立。老规矩,先上时间轴。



前前后后二十年时间,见证了第一代技术和商业的更迭:


  • 首先,牢记视频会议技术的“四大才子”——Polycom、Radvison、Tandberg和Webex;

  • Webex与前三家技术路线不同,早期产品经过几次调整,最终通过提供基于微软NetMeeting的企业级视频会议方案而成功上市;

  • 最终,“四大才子”都以被并购或退市收场,只是收场时的姿态各异;


如今又过了快十年,Cisco、Avaya 和微软等当年的巨头,现在似乎又遭遇了新一代技术公司的挑战。


我们走进 90 年代。


视频会议 1.0:从电话到网络会议


关键词:多对多、MCU、Polycom、木桶效应


如果一通电话是“一对一”,一场会议则是“多对多”,而一套视频网络会议方案就是要管理 N 个并行的多对多视频会话。



刚开始用得起视频会议的都是不差钱的金主,如 银行、运营商或政府机构,一般小企业打个电话就行了。在金主面前,各家公司比拼的都是使用体验和设备性能,例如:


  • 是否支持高清图像,背后包含编解码、降噪处理等技术;

  • 支持多少方同时加入并保证相同体验;

  • 主持人邀请、点名等会议管理功能。


最后为了将体验做到极致,业界引入了一种新的设备叫 MCU (Multipoint Control Unit,多点控制单元)


我们可以把 MCU 理解成一台多媒体信息(后称“媒体流”)交换机,信息包括但不限于声音、图像和文本等数据。主要职责为:


  • 媒体流的信号处理及编解码;

  • 并行多对多的线路切换、路径管理;

  • 还需具备数据加密、稳定传输等功能。



如上图这个例子,A、B、C 参加视频会议,


  • 首先,A、B和C必须将自己的媒体流 全部传给MCU

  • MCU把收到的音视频包根据相关格式协议进行分解;

  • 然后根据各方请求,MCU将音视频分别合成并打包;

  • 最后由MCU传送给终端,整个过程称之为“混音混屏”。


公式一:视频会议 1.0 = 视频终端 + MCU,其中 MCU = CPU + 固化算法。



图中是这次 G20 欧盟分会场,这位大佬除了能看到全体参会人员的集合画面,还增加了一个只显示自己的屏幕,也就是前面例子中 C 这个场景。MCU 确保参会者和线上会议室的对应关系,也就是路径管理。


视频会议 1.0 时代就是建立在以 MCU 硬件为基础的中心化处理架构上。


但是,这里便出现一个问题:中心化处理的优点是保证了所有参会者体验的一致性。但这就要求所有终端的性能和网速都要保持在一个水准,否则就会极大影响体验,因为混合的过程受制于音画质最差的那个终端,也就是“木桶效应”


所以,当时为了满足高清、超高清到网真级别(即 1080P)的画质,终端设备都走上了定制和专业化,同时相应的编解码器也被集成到终端上,最终各公司都推出了价格昂贵的端到端专业视频会议方案(Dedicated video conferencing solution)。


公式二:专业视频会议方案 = 专业设备 + MCU + 专用网络。


谈到这就不得不重点说说 90 年代的第一大才子,而后却被两次“贱卖”的 Polycom。


Polycom 成立于 1990 年,曾经也是加州车库初创公司的代表。最早从电话会议系统起步,1996 年成功登陆纳斯达克,十年后 2007 年全年营收突破 10 亿美金,其中整个会议系统产品占当时全球市场份额达到惊人的 60%。



(即便没听过 Polycom,你也肯定见过“八爪鱼”)


而让 Polycom 彻底打开中国市场,就是因为 2003 年的那场疫情危机——SARS 非典


根据 2015 年哈佛商业评论对当时时任 Polycom 大中华区总裁李钢的采访:


2003 年‘非典’疫情席卷中国,给中国医疗系统带来前所未有的挑战。最急迫的问题是,许多医疗机构分散在全国的疫苗中心和研究所,人员无法出差,因为一旦出差就要被隔离。医疗机构的远程携作需求瞬间爆发,而远程携作正是 Polycom 视频通讯的核心业务,包括 流调系统、专家系统和政府指挥系统 在内的三大系统都使用了 Polycom 的视频通讯技术。


当时除了 Polycom 之外,还有几家国内外厂商包括 华为、中兴、Tandberg 以及 Radvision 也在竞争这个机会。”(是不是都是熟悉的名字?)


神州数码是当时 Polycom 中国区的总代,在 2005 年一次对神码企业系统事业部应用网络部总经理的采访中得知,“非典”期间一个季度的销售额就比往年全年的销售额还多。据悉 Polycom 当年在中国的销售额同比增长达 70%。


同期受益的是整个远程会议市场,2003 年也成为了中国视频会议市场的“元年”。



(当时 Polycom 的“爆款”:VXS 7000 系列) 总之,Polycom 在初期通过不断基础研发和大手笔并购,掌握了音视频编解码、回声抑制等方面的核心 IP。在网络环境有保证的情况下,视频会议的效果达到业界顶尖。


然而在 2016 年,加拿大移动通信公司 Mitel 宣布以 19.6 亿现金和股票收购 Polycom,Mitel 当时的市值甚至略低于 Polycom,此番“小鱼吞大鱼”的戏码让市场一片哗然。


同年在中国,身为当时全球副总裁兼中国区总经理的袁文辉,与中国研发技术中心的早期成员也离开老东家,创立了小鱼易连。他们号称“摒弃传统视频会议厂家的专线专网”,采用云视频技术,保证与专线相似的音视频体验。


两年后,耳机制造商 Plantronics 宣布以 20 亿美金再次收购 Polycom,一大才子短短时间内竟被两次倒卖!


可见 2016 年的并购退市事件成为了 Polycom 由盛转衰的标志。



(来源:IDC)


在 2018 年 IDC 发表的“全球企业级视频会议供应商评估报告(《IDC MarketScape:Worldwide Enterprise Videoconferencing 2018 Vendor Assessment》)”里也能看到,Cisco 和微软(通过收购 Skype)牢牢占据了领先者象限,Polycom 已退居二线。


同时在主流玩家(Major players)象限中,新一代技术公司早已出现,加速了 Polycom 的衰退,有一家我们必须记住——Vidyo。


了解 Vidyo 的兴,也就明白了 Polycom 的衰。


视频会议 2.0:从中心化到分布式


关键词:路由器、SVC、Vidyo、分布式


专业视频会议方案固然性能好、效果佳,但部署一套方案的成本也居高不下,这不仅把许多中小企业挡在门外,还大大损害了客户采购终端设备的灵活性


这时一名以色列人看到了商机,他曾是上文提到的 Radvision 初创团队的骨干,2004 年从 Radvision 辞职后,次年成立了 Vidyo。


Vidyo 采用了一个全新架构,去掉昂贵的 MCU,摆脱之前方案对专业设备和专网的依赖,将视频会议技术带入 2.0 分布式时代:


公式三:视频会议 2.0 = 各类设备 + 路由器 + 公共网络(即互联网)。


这个架构带来了一个重要变革:将过去对媒体流的中心化处理变为分布式传输:


首先,终端上实现所有编解码:由于摩尔定律带来计算能力的提升,编解码已能通过软件形式安装在终端,由终端的通用 CPU 统一处理;


其次,路由器实现路径管理:普通路由器的功能就是读取数据包中的地址然后决定如何送到下个目的地,这里就变成读取媒体流中的基本信息如目的地 IP 地址后建立点对点连接。


例如 A、B、C 开会,路由器把 B 和 C 的地址告诉 A,让 A 直接通过公网把媒体流打包好后送至 B 和 C,不再需要经过昂贵的 MCU 了


最后,SVC 编码技术实现音画质自适应:前面讲过,由于中心化架构和“木桶效应,音画质效果在不稳定的网络环境下无法得到保障。这时候,Vidyo 首次将一个全新的视频压缩标准应用到了网络传输上—— SVC(Scalable Video Coding, 可伸缩视频编码)


该技术将音视频信号分成“基本层和多个高解析层”进行分层编码:当带宽不足时,只对基本层的信号流进行传输和解码,这时解码后的视频质量尽管不高,但对简单终端如手机的屏幕来说已经适用;当带宽变大时,就可以解码高解析层来提高视频质量。



(来源:Vidyo、bloggeek.me)


回到 A、B、C 开会的例子,假设 A 的网络情况不好,B 和 C 相对较好,会议依然正常启动。


  • 首先,ABC都向路由器发送会议基本信息;

  • 路由器收到消息后,分别通知A、B、C和自己开会的对象以及对方的IP地址;

  • 然后ABC之间直接基于SVC建立连接,媒体流的速率则根据终端配置不同进行自适应;

  • 最后,每个终端会收到三个媒体流,通过自带软件进行解码和还原。



结果就是,网络状况较好的 B 和 C 自行建连接,还原出较好的音画质,并不受到 A 端网络质量的影响。但 B 和 C 看 A 的画面,就会比较模糊。


回想一下,我们现在用钉钉的时候(为什么钉钉“躺枪”,留个伏笔),会经常出现对某个参与者说“你的画面不清晰,会卡顿,要不你重新连接一下”诸如此类的情况。


就这样,分布式路由与 SVC 技术的结合破解了“木桶效应”问题。名声大噪的 Vidyo 也自此走上融资的快车道。


时间轮次融资金额
2005.10Seed未知
2007.6B
2009Q1B+未知
2010.4C$25M
2012.5D$22.5M
2013.4E$17.1M
2019.5被收购$40M


(来源:公开信息整理)


Vidyo 的产品形态主要有三类:


  • VidyoConnect/Vidyo Cloud:面向大型客户提供专业视频会议系统,如金融、医疗、政府等领域,对标Cisco。云视频服务商兴起后转向云端发展,对标Zoom;

  • VidyoEngage:面向呼叫中心提供低成本的嵌入式视频会议方案,对标Avaya的呼叫中心系统;

  • Vidyo.io:这是Vidyo最特别的产品,面向开发者提供技术支持如SDK开发包,以便第三方二次开发并部署到其他应用或终端上。


伏笔揭晓,2016 年 4 月,跪求小学生手下留情的“钉钉”便宣布与 Vidyo 建立深度合作,成为钉钉嵌入式高清画质和点击入会的视频会议合作伙伴,即向钉钉开放 SDK。小米手机也是 Vidyo 的客户。



(来源:Vidyo、bloggeek.me)


然而细心看前面的融资历史,你们可能已经发现了,在成立十四年后,Vidyo 依然逃不过被收购的命运。并且按照被收购的对价和之前的融资金额,肯定又是一次跟 Polycom 相似的“贱卖”。


Polycom 和 Vidyo,同样拥有核心技术却最后黯淡退场的背后到底是什么原因?让我先把技术发展史讲完。


随着 2006 年 SVC 技术和分布式架构的出现,同年亚马逊推出了举世瞩目的 AWS(亚马逊云服务),将路由器功能搬到云端并取代高成本的本地部署,就是自然而然的事情了。


Webex 在刚开始推出的并不是完整的多方视频会议方案,而是“Webinar(网络讲座)”。主要形式为一个主持人主讲并可以共享屏幕,其他参与者之间几乎无互动,也就是基本没有媒体流的传输。


在 2007 年被 Cisco 收购后,Webex 也推出了云视频会议方案。但由于产品线之间的竞争,而高端设备一直是 Cisco 的主要利润来源,因此多数时候 Webex 只能成为传统远程会议系统的“云补充”。


在服务了千家企业后,一位 Webex 的资深工程师发现“没有一家客户对 Webex 的产品满意”,而老东家也无心投入到一个新方案的开发上。于是在 2011 年,这位工程师带着四十五位来自原 Webex 团队的兄弟,成立了一家新公司,叫 SaaSbee,用他的原话说,


“既然 Cisco 不肯做,这就是最好的时机由我来解决。”


一年后 SaaSbee 改名为 Zoom,再之后的故事就被大家熟知了。



(视频会议技术更迭的四个时期)


前车之鉴,后事之师


关键词:木桶效应、PMF、利基市场


回顾历史的多次重演,让我首先对过去由兴转衰的公司展开了反思。


为什么 Polycom 会衰落?


我认为有两个层面:


技术层面,简单把 MCU 设备“软件化”或搬上云,本质上并没有改变“中心化”网络架构,因而无法解决“木桶效应”问题。


这不仅对于 Polycom,还包括 Cisco、华为在内的传统方案厂商来说,都是巨大的挑战。而 Cisco 之所以仍能保持竞争力,是由多方面因素支撑的。


首先,远程会议业务收入占 Cisco 整体营收不到 10%,不构成重要影响;其次,在金融和政府等领域各业务线间能共享客户和渠道资源;最后,Webex 在被收购后,尽管沦为“云补充”,但仍能凭借 Cisco 的品牌和服务在中小企业抢夺一定份额,对 Zoom 形成压制。


反过来看,在一些专业或特殊场合,如这次的 G20 会谈,同步性和音画质依然是用户的首选,而不是价格。这时候中心化网络架构就是基础,而在这些市场里 Cisco 和 Polycom 仍占据重要位置,只是后者已然失去了当年的风光。



(来源:Synergy Research)


商业层面,既然在技术上没有革命性改变,就无法从商业角度服务“长尾”客户,也就决定了产品的 PMF(Product-market fit,产品/市场契合点)是失败的。


Polycom 在后期尝试通过与微软等软件厂商合作,向中小企业售卖一套软硬组合方案。很显然,这跟 Zoom 等 SaaS 厂商相比,没有任何吸引力。


展开一下,当年投资者看到 SaaS 鼻祖 Salesforce 的价值,本质在于以年付费的订阅模式给企业创造了一笔省心省力的“递延收入(Deferred revenue)”,大大提高了当年收入的确定性。


而 SaaS 进入以 Zoom 和 Slack 为首的“自助(Self-serve)时代”,在更灵活的收费模式下,留存和增购成为了更核心的指标,根本原因来自 个人软件的网络效应以及员工对企业 IT 采购的影响力提升


因此,必须先确定你的客户和他们的痛点,再去定义产品。至于以什么形式来提供,是由时代背景和许多不同因素所决定的。


更关键的是,真正面对“危机”,传统企业有没有革自己命的决心?


为什么 Vidyo 会失败?


第一个教训:找到你的利基市场。利基市场指的是在较大的市场中具有相似需求的一小群客户及占有的市场空间,例如亚马逊刚开始选择的图书市场。Vidyo 一开始不是没有聚焦,但选择的是与传统厂商相似的金融和医疗市场,主打对多种高清和普通终端设备的兼容性。


这是一个高风险的策略,因为对于大型客户而言,最终选择一个供应商背后的因素非常复杂,而价格绝对不是首选,安全、口碑和服务都排在前面,那么对于初创公司来说,顶级的技术或许能带你入门,却不一定能带你上道。


其次,以 API、SDK 等形式做技术支持而不提供端到端解决方案,对于技术型初创公司来说,需要非常慎重,很可能是一种讨巧却无法形成足够壁垒的战术失败。这里的确有例外,有机会我们再详细讨论。


最终,仓促上线的多产品线又导致在竞争上腹背受敌,只能靠不断融资续命。


第二个教训:选择最优的商业模式。“作嫁衣裳”的产品思路我向来认为需要十分谨慎。这件事情不是不能做,如果你是 Google,当年开源实时通信项目 WebRTC(我们常用的 QQ、Skype 等一对一通话都采用了这个技术),意在让更多开发者能够直接在浏览器中创建视频或语音聊天,免费的背后依旧带着强烈的商业目的。


尤其对于拥有创新技术的软件公司来说,真正的商业价值仍在于能否解决客户的一揽子问题。这让我想到了 SaaS 模式对于开源商业化的意义,重要的并不是第一个“S(Software,软件)”,而是第二个“S(Service,服务)”


如果你还在犹豫甚至尝试同时发力多条产品线,那不妨先思考第一个问题:如何先“打透”利基市场。


总之,如果 Polycom 的衰落是在 PMF 出现了偏差,那么 Vidyo 则是太执着于 Technology-product fit(技术与产品匹配),而完全忽略了商业的本质和战略。


Zoom 的危机与野心


关键词:安全、端到端、远程会议、开源


要解析 Zoom 的未来,不妨先了解它所面对的危机。


在近期 Citizen Lab 和华盛顿邮报相继爆出产品存在重要安全漏洞后,Zoom 官方承认了在应对近几周流量激增的时候,平台“错误地”让两个在中国的数据中心接受了在非中国区的“通话(Accept calls)”,作为网络拥堵时的备选。CEO 袁征随后解释道:


“在正常情况下,Zoom 的客户端会优先向附近的首级数据中心发送请求,如果因为网络拥挤导致多次请求失败,客户端会再连接两个二级数据中心。在任何情况下,Zoom 的客户端都只会与本地区内合适的数据中心进行连接。”


然而事实并不是这样,Zoom 确实犯了一个错误。


但是,当我们回看公式三(视频会议 2.0 = 各类设备 + 路由器 + 公共网络),便会发现这几件事:


向数据中心传输的只是会议基本信息,不包含用户的视频等敏感信息。“上云”只是将路径和参会者信息上传到云端服务器或 IDC(数据中心)上进行处理,真正的媒体流仍在公网上进行点对点传输,再由终端设备进行编解码。


众所周知,公网环境和云服务器通常是不受 Zoom 管控的。当然这并不能说明 Zoom 没有责任提醒用户并做相关保护性措施;


Zoom 所面对的安全性问题实际上是无可避免的,要做到外界期望的“端到端”加密是一次关于 技术、投入回报和舆论的博弈


根据 Zoom 在 4 月 1 号官方博客上的解释,目前做法是对每段传输的内容进行加密,而密钥管理在云端,因此引发了外界对相关风险敞口的推测。


而给出的解决方案是用户可以选择将密钥管理部署在本地,这确实是当下相对合理的办法,但多余的成本自然由用户买单。


所以说到底,这背后是经济账。就像袁征说的那样,Zoom 从一开始就不是为个人通信设计的,而是用于团队远程会议与协同。个人通信应用 WhatsApp 就使用的是端到端加密,但只能最多支持四方视频聊天。


但是,Zoom 却在网站和营销材料上宣称产品使用了“端到端加密”,所以第二个争议点就落在了诚信问题上。这个问题可大可小,放在中概股连续爆雷的当下,难免会挑动更多人的神经。



在我看来,真正的解决方案不是不断添加补丁,而是从产品线源头推出全新解决方案。其实在上市前后,Zoom 就祭出了两大杀手锏:


  • 面向大型企业和政府的 Zoom Meeting:通过一个连接器(Connector)将Cisco、Polycom等传统设备整合进Zoom平台,与其他使用Zoom客户端的用户打通,因此连接器的功能包含了解析并整合不同通信协议、加密等功能;

  • 面向传统交换机业务的 Zoom Phone:将电话会议系统整合进统一通信(Unified communication)业务中,主要是为那些想要在无法视频的情况下用电话接入的用户设计。你可以从最近的财报电话会上听出袁征对统一通信业务的期望。


这宣告了 Zoom 全面进军整个企业级远程会议市场。


杀回老东家 Cisco 的大本营,不再局限于视频会议。毕竟在这个金融和政府客户收入贡献占近一半的市场,Zoom 要持续仰攻并不容易。


再回看 Vidyo,两家公司的技术路线和产品看似殊途同归,但结局却大相径庭,实在让人唏嘘。


最后,对 Zoom 来说接下来要解决的远不止安全问题。


仍然拿这次 G20 会议举例,在如此高规格的场合下,除了极高的安全和保密性外,音画质和稳定性依旧是关键。


技术上主要包括:能否适配不同类型的高清视频设备,以及能稳定地支撑多少方的网真级别会议,毕竟“川建国”的任何一个微表情都可能被其他国家元首所津津乐道。



(来源:公开信息)


其次,从商业角度,Polycom 当年在中国的成功靠的是慷慨与代理商一起“分蛋糕”的销售体系。而 Zoom 的核心产品本身非常标准且价格透明,留给代理商的“肉”并不多。


这也是新一代自助模式下 SaaS 厂商的困境,我们会看到 Zoom 在财报中一直强调收入贡献超过 10 万美金客户的数量和比例。


因此,Meeting 和 Phone 系列便试图通过对传统设备的向前兼容,留给集成商一块蛋糕。包括后来的“App Marketplace(应用商店)”也是寄希望让公司从会议管理平台升级为一个协同办公平台,然而生态建立的实际效果仍需要时间来验证。


在 3 月 30 号面对福布斯的专访,袁征说如果未来不能把 Zoom 打造成“全世界最安全的平台”,那么他愿意“把 Zoom 开源,与其他人一起尝试”。


我认为这绝不只是出于公关和安抚舆论的目的。在近三个月收获了 1.9 亿用户后,Zoom 的确被迫进入了一个“完全不同的赛场(Different game)”,所幸 Vidyo 的前车之鉴及庞大的用户基础都可以成为袁征在做战略选择时的底气。


不过,企业级客户的需求总是复杂的,而安全性是相对的。有时候“开后门”反而是一种“安全”措施,你们细品。


不管怎么说,如果真的到了 Zoom 已经不再属于公司本身,而是“属于全世界”的那天,也许我们会习惯一种新的说法:


“Let’s Zoom!(让我们 Zoom 一下!)”。


参考资料



原文链接


https://mp.weixin.qq.com/s/0OCF99C8VJyy8xt6GAdDuA


2020 年 4 月 19 日 10:001795

评论

发布
暂无评论
发现更多内容

程序员的晚餐 | 7 月 3 日 好久没做饭

清远

美食

ARTS Week6

时之虫

ARTS 打卡计划

一个简单的技术选型心得

i风语

Java 架构

面试细节: i = i++和 i = ++i

Java小咖秀

JVM Java 面试 经验分享

为什么建议项目中统一线程池类?

张挺

cms项目系列(一)——SSM框架搭建

程序员的时光

spring

阿里技术官:这样带你学Spring全家桶,其实没你想的那么难

小吴选手

spring Spring Cloud Spring Boot

深入理解编译优化之循环展开和粗化锁

程序那些事

JIT 编译优化 循环展开 粗化锁

java架构-一些设计上的基本常识

猿灯塔

Java

Go: 字符串和转换优化

陈思敏捷

go golang string 字符串

Week5命题作业

星河寒水

极客大学架构师训练营

我是如何解决邮件焦虑的

vinkyqy

效率 职场 邮件

18个Java8日期处理的实践,太有用了建议收藏

码哥小胖

MySQL SQL语法 sql查询

简直了!顶级架构师分享心得,如何在项目中兼容多种数据库

犬来八荒

Java MySQL 数据库 面试

编程核心能力之组合

顿晓

Java 学习 pipe

逆袭之路,普通二本的八年开发码农如何进阿里拿年薪百万

小谈

Java 面试

六月我在工作中蜕变,勤奋小人打架终于赢了

程序员小跃

效率工具 加班 沟通 复盘

计算机操作系统基础(十一)---线程同步之互斥量

书旅

php laravel 线程 操作系统 进程

什么时候不要用微服务?以 Istio 为例

无予且行

Java 微服务 后端

太牛 了!快码住!GitHub上标星75k!超牛的《Java面试突击版》

犬来八荒

Java git Linux 面试 Java 面试

为什么我建议你读一读历史?

Phoenix

历史 中国历史

农产品电商平台的S曲线分析

石云升

增长 S型曲线 破局点

高承实:区块链在新基建中的作用和未来发展

CECBC区块链专委会

新基建 政策扶持 技术特征 链上数据 产业场景

Android架构组件-App架构指南,你还不收藏嘛

小吴选手

架构 架构师 架构总结 架构要素 P7架构师

锦囊篇|一文摸懂SharedPreferences和MMKV(二)

ClericYi

架构师训练营 第 5 周作业

Lingjun

极客大学架构师训练营

1.2w字 | 初中级前端 JavaScript 自测清单 - 1

pingan8787

Java 前端 Web

分布式缓存

Arthur

第四周

仪轩

程序员阿里、京东、美团面试整理的面试题,测试一下你都会了吗?

小谈

Java 阿里巴巴 面试

Redis系列(五):你要的Redis集群搭建来了,实践与否你自己选!

z小赵

Java redis 分布式 高并发

Zoom的“冰与火之歌”-InfoQ