Record

区块链记录你的初心
营销地产创业创新求职面试Word技巧金融职场工作区块链Excel教程财经PPT教程产品运营
中国学生发现1000行Python代码脚本中的bug,或影响上百篇学术论文

中国学生发现1000行Python代码脚本中的bug,或影响上百篇学术论文

企业学术

《Nature》杂志 2014 年的一篇论文包含了一个 Python 脚本,其中有一个模块是根据文件的排序返回值,但 Python 并没有定义查询的文件顺序。这意味着在不同的操作系统上,该脚本返回的值是不同的。这个 bug 直到最近才被发现,而这篇论文被引用了 158 次,如果这些论文使用了相同的脚本那么文章的结果很可能是错误的。01 藏在《Nature》论文里的脚本 Bug《Nature》杂志 1869 年创刊于英国,是世界上最早的国际性科技期刊,涵盖生命科学、自然科学、临床医学、物理化学等领域。对于学者而言,论文能被《Nature》收录是一种荣耀。许多自然科学、物理化学等领域的学者,在论文创作中也会使用各种编程语言或工具进行数据收集、分析等工作。2014 年,《Nature》上发布了一篇名为《A guide to small-molecule structure assignment through computation of (1H and 13C) NMR chemical shifts》的化学论文,该论文试图找到对癌症有效的化合物。论文中包含了一个使用 Python 语言构建的脚本。最近,夏威夷大学的一位研究生 Yuheng Luo(中国人)发现该脚本中存在一个 Bug:脚本中有一个模块是根据文件的排序返回值,但 Python 并没有定义查询的文件顺序。他在导师 Rui Sun(中国人)的指导下使用该脚本验证结果,结果发现无法匹配论文作者的结果。在测试期间,他们发现在 Mac、Windows、Linux 等不同的操作系统上返回的结果是不同的。他将研究报告写成了论文,发布在了《Organic Letters》期刊上。5 年时间过去了,这篇包含错误脚本的《Nature》论文已经被引用了 158 次,这意味着如果这些论文使用了相同的脚本那么文章的结果很可能同样是错误的。对于学术论文来说,这是影响很严重的 Bug 了。Yuheng Luo 在论文中写道:原始脚本中这个简单的小错误对大量论文的结论造成了影响,这些论文涉及的话题非常广泛,很难从已发表的信息中得出结论,因为研究人员很少会提及其所使用的操作系统。使用这些脚本的作者当然应该再次检查他们的结果,以及使用 [补充资料] 中修改过的脚本得出的
为开发者铺路:解读华为昇腾AI战略布局

为开发者铺路:解读华为昇腾AI战略布局

华为AIai

11 月 11 日,华为技术沙龙昇腾专场来到深圳,由华为多位 AI 领域技术专家,围绕华为全栈全场景 AI 解决方案,通过 Atlas 人工智能计算平台与基于全栈开发工具链 Mind Studio 进行 AI 开发的实践案例,为现场开发者深度解读了 AI 开发的技术难点与行业解决方案应用。深圳湾科技发展有限公司董事长邱文、华为 Atlas 领域总裁许映童等领导也出席了本次沙龙,并做了开场致辞。许映童总裁表示:华为坚持战略投入,持续创新,通过解决世界级计算技术难题,为世界提供最强算力。借助本次沙龙,希望与大家共同探讨昇腾生态的合作机遇,并且跟深圳湾科技园区的企业代表和技术专家进一步开展深入交流。01 打造全栈全场景 AI 生态,赋能 AI 技术开发者随着计算产业的智能化升级,AI 已成为数据中心、边缘计算、终端的基础能力,预计到 2025 年,AI 算力将会占据数据中心算力的 80% 以上,AI 芯片 75% 部署在边缘,海量的 AI 算力需求将带动全球人工智能市场增长。从技术上来看,人工智能发展可划分为三个阶段: 弱人工智能,擅长单个方面的人工智能(如图像、语音、内容分析等); 强人工智能,具备认知和推理能力,能够比肩人类大脑; 超人工智能,具备感知和思想意识,几乎在所有领域都能超越人类,包括科学创新和社交等。 目前,人工智能应用还处在弱人工智能阶段,随着融合视频分析 / 语义理解、自行判断、自主决策等深度学习 / 强化学习算法的成熟完善,将推动各个行业向强人工智能阶段迈进。华为智能计算生态发展部总监区俊彦表示,计算产业生态的构建将非常关键且具有一定挑战性,目前,华为已经形成了以鲲鹏 + 昇腾为核心的双引擎计算战略,并打造出包括芯片、芯片使能、训练和推理框架以及应用使能在内的全堆栈解决方案。芯片上,基于昇腾 310 芯片的 Atlas 推理型行业场景解决方案已在 50+ 行业上应用,涉及安防、金融、电力、交通、互联网、运营商等,并从成熟的互联网、智慧城市,逐步融入到传统行业,成为传统行业智能化升级的引擎。随着昇腾 910 AI 处理器以及 Mi
在 80% 的丢包环境下还能保障视频流畅?背后的这群技术人太拼了

在 80% 的丢包环境下还能保障视频流畅?背后的这群技术人太拼了

5G

作者丨关贺宇嘉宾丨钟声,声网 Agora 首席科学家我们是全世界在行业里面第一家真正把实时音视频能力做成简单易用的 API,开放给开发者和合作公司来使用,在很长时间里也是唯一的一家。我们在这方面所做的努力,也在过去每一年的 RTC 大会里逐步辐射给互联网和实时互联网行业的参与者,给大家提供更多的服务。这是声网 Agora CEO 赵斌在 10 月 24 日声网品牌发布会上的一句话。而这句话的底气正是来自整个声网技术团队对实时音视频技术 6 年的坚持。RTC 大会的第五年圆满落幕,随着 AI、5G 等新技术的兴起,有更多的未知和挑战在触动技术人的心弦。InfoQ 记者在 RTC 大会期间采访到声网首席科学家钟声,听他讲述实时音视频技术背后的故事。实时交互是我们与生俱来的本能和需求钟声提到,RTC 的核心就是把用户的体验做到最好,其中最关键的是用先进的算法实现音视频处理和传输不卡不糊不延时。所以,算法的先进性是核心竞争力。声网近一年来在研发下一代实时编码传输技术,其中部分已经完成,一些客户已经开始试用。下一代实时传输技术可以让视频在极端网络条件下,甚至在 80% 丢包的情况下,还能实现低延时下比较流畅地传输,全面提升视频传输在各种网络条件下的鲁棒性。随着视频业务的增长,越来越多的客户或用户在享用高清、甚至 4K 的内容和服务。这对网络带宽的压力非常大,导致经常会出现拥堵的问题。那么,如何在保证视频质量的情况下,还可以取得额外 30% 甚至更多的压缩?钟声提到,在视频编码和传输的过程中,在低延时的情况下,有效对抗 80% 的网络丢包率十分考验公司的技术实力。声网新一代技术可以做到在 80% 的丢包环境下保障视频流畅。在提升视频图像质量和编码效率方面,利用人工智能的深度学习算法可以取得额外 30% 的编码效率的提升,而不牺牲视频质量。声网 1.0声网 2.0钟声提到,我是 2017 年年底来到声网,主要任务就是把实时音视频技术从 1.0 提升到 2.0。以视频技术为例,当一个图象采集进来之后,首先要做前处理,比如降噪、美颜、加贴纸、风格转换等操作,这是第一步。接下来要做压缩和编码,就是将原始的视频数据压缩后上传至网上。压缩的诉求就是把数据压得越小越好,同时还需要让画质的损失控制在人们可接受的程度,并且对传输友好。互联网是有带宽制约的,端到端各节点上也会出现不理想的条件,因此经常会出现拥堵或丢包的情况,这就要求编码和传输的技术能对抗丢包,对抗网络拥堵。要做到这一点,需要传输算法和编码算法的结合。在数据传输到云端的过程中,要找到一条路径可以快速稳定地传输到另一方,这是基本诉求。在接收端接收到信息后,要做解码和后处理,后处理就需要考虑到图像质量的提升,以及一些丢包隐藏技术的使用,最终呈现出让用户感觉很舒适的视频。声网的第一代算法相对比较朴素,搭建
GitHub标星2400,Netflix开源笔记本工具Polynote:Scala、Python和SQL等多语言操作

GitHub标星2400,Netflix开源笔记本工具Polynote:Scala、Python和SQL等多语言操作

多语言

作者丨Netflix Technology Blog译者丨姚佳灵策划丨赵钰莹Polynote 是一个新的多语言笔记本,具有一流的 Scala 支持、Apache Spark 集成,包括 Scala、Python 和 SQL 在内的多语言操作性,以及键入时自动完成等功能。最近,Netflix 宣布开源 Polynote,该笔记本环境给数据科学家和机器学习研究人员提供了一个机会,允许他们自由地无缝整合基于 JVM 的机器学习平台(该平台大量使用 Scala)和 Python 生态系统内的主流机器学习和可视化库。目前,该项目已经得到 Netflix 的个性化及推荐团队的广泛采用,现在正在研究与平台的其他部分进行集成。01 功能特性可重复性Polynote 的两大指导原则是可重复性和可见性。为了进一步实现这些目标,Netflix 最早的设计决策之一是从头构建 Polynote 的代码解释,而不是像传统笔记本一样依赖 REPL。Netflix 觉得,尽管 REPL 总体上很好,但是根本不适合笔记本模式。为了理解 REPL 和笔记本的问题,可以看一个典型的笔记本环境设计。笔记本是有序的单元格集合,每个单元格都可以存放代码或文本。每个单元格的内容可以独立修改和执行。单元格可重新安排、插入及删除,这也取决于笔记本中其他单元的输出。把这个与 REPL 环境进行比较会发现,在 REPL 会话中,用户把表达式一次一个地输入提示符。一旦求完值,表达式和其求值的结果不可变,求值结果被附加到全局状态提供给下个表达式。不幸的是,这两个模式之间的脱节意味着一个典型的笔记本环境(使用 REPL 会话对单元格代码求值)会随着用户与笔记本的交互而导致隐藏状态的积累。单元格可以按任何顺序执行,从而改变这种全局隐藏状态,进而影响其他单元格的执行。通常情况下,笔记本无法从顶部可靠地重新运行,这使得它们难以重复及与他人共享,该隐藏状态还使得用户难以推断笔记本上发生的事情。在其他笔记本中,隐藏状态意味着一个变量在其单元格被删除后仍然可用。在 Polynote 笔记本中,没有隐藏状态,被删除的单元格变量不再可用。从头开始编写 Polynote 的代码解释允许消除这种全局、可变的状态。通过跟踪每个单元格中定义的变量,Polynote 基于运行于其上的单元格,为给定的单元格构建输入状态。让单元格的位置在其执行语义中变得重要,加强了最小惊奇原则,允许用户从上到下地阅读笔记本。它通过使笔记本持续地工作,让这更可能确保可重复性。更好的编辑面对现实,对于某些习惯使用 IDE 的开发者来说,在笔记本中编写大量代码就像回到了几十年前。我们已经看到更喜欢在 IDE 中编写代码的用户把代码粘贴到笔记本中运行。尽管提供一个成熟的现代 IDE 的所有功能不是 Netflix 的目标,但是,有一些提高生活质量的代码编辑功能对提高可用性很有帮助。Polynote 中的代码编辑集成了 Monaco 编辑器以提供交互式自动完成功能。Polynote 高亮显示代码中的错误以帮助用户快速找出问题所在。Polynote 为文本单元格提供了一个富文本编辑器。这个富文本编辑器允许用户轻松地插入 LaTeX 方程。可见性正如之前提到的,可见性是 Polynote 的指导原则之一。Netflix 希望可以轻松查看在任何给定时间,内核在做的事情,而不需要去查看日志。为此,Polynote 提供各种 UI 处理,以让开发者知道在发生的事情。这是某些代码执行过程中,Polynote 的一个屏幕快照。只要看一眼 UI,开发者就能得到相当多的信息。首先,很清楚,从笔记本视图和任务列表中都可以看到 Cell 1 正在运行,还可以看到
京东云监控系统设计及落地之路

京东云监控系统设计及落地之路

京东云监控

策划丨王利莹监控是运维的生命线,监控系统的目标是通过快速发现问题、定位问题、解决问题来达到缩短异常出现的 MTTR,在这方面,京东云定义了一套统一的监控标准:即监控需要覆盖基础 - 存活 - 性能 - 业务四个层面,从而保证采集数据的全面,进而避免监控遗漏。谈运维为什么离不开监控?典型监控系统一般是如何设计的?业务驱动的高可用监控系统又有何不同?作为巨头之一的电商平台京东, 其基于京东云的监控系统是否有值得借鉴的地方?本文将解答这些问题。本文整理自 10 月 30 日由京东云开发者社区和英特尔联合举办的在线公开课,京东云工具产品研发部专家架构师颜志杰的在线课程演讲业务驱动监控系统设计与落地。01 为什么需要做监控世上没有百分百可靠的系统,程序、机器、网络都可能在运行中出现问题,进而导致服务异常, 带来金钱及品牌的损失,所以监控目标就是降低损失,通过发现、定位、解决问题,期望缩短异常出现的 MTTR (平均修复时间)。要达到这个目标,监控对象必须具备可观测性,即通过数据描述是否出现异常,这些数据包括指标监控 Metric、日志 log 和 Trace 数据。为了实现缩短 MTTR 的目标,监控系统应该具有这些能力: 数据采集能力,获取可观测的数据 数据能够方便加工,比如把相关的数据汇聚起来,得到我们需要关注的数据 对这些关注的数据,做异常检测,及时产生告警 收到告警后,通过 Dashbord 查图定位,最好有专家推荐,加速定位 定位问题后,通过预案平台进行快速止损 整个监控系统需要做到高可用,监控就是为了发现异常,如果由于异常导致自身不可用,肯定是减分的 02 从功能模块来分解监控系统典型监控系统从功能模块分为采集、计算、存储、告警、算法、业务端等。从下往上来看,首先是抽象层,包含 CMDB(配置管理数据库),抽象了我们对监控对象的定义,比如定义了应用、机器、域名、网络等,比如确定监控系统里面机器到底是用 IP 还是 Hostname。采集层包含众多采集手段,包括机器、容器、进程、日志、端口等,可以通过 Agent 数据传输,或者外部探测点定期拉取,也可以用户直接通过 API 推送进行数据采集。数据采集后,分为三条数据流处理:计算、存储、告警,计算即进行数据加工,如聚合计算把 10 台 Nginx 的 PV 累加起来;数据存储便于 Dashbord 能够查看;报警通路进行异常检测,快速发出报警。上层计算平台基于智能算法对异常或者故障的根因进行分析,进行根因推荐,输出专家辅助定位。最终到达用户层,提供用户常见的监控功能点:监控配置维护、告警处理、预案管理等。03 从数据的视角来分解监控系统从数据视角去理解,监控系统就是一个数据处理系统,便于我们简化系统设计以及更好理解监控系统。从数据的视角来分解监控系统,同样分为四层,上图尝试用不同颜色、形状的图形去说明采集、计算、存储、告警等模块在数据视角的功能。打比方说:数据抽象层,即把监控数据被抽象成是各种形状、各种颜色的模块,数据采集就是标准化过程,把各种形状颜色的数据用统一的方式表示,比如上图用一个云的形状把各种图形框起来;聚合计算就是对同一标签的数据做聚合处理,比如上图按照颜色来聚合,存储流把相同的形状颜色顺序摆好,告警则是挑选出有红色框的数据(上图表示异常数据点)。所以,无论是采集、聚合、存储、告警还是查看 Dashbord,本质上都是对数据的一些处理、变换操作。举个例子,用户 Dashbord 筛选耗时 2s 的曲线、和告警模块筛选出 2s 告警,对应数据视角是一致的,都是做一些数据计算过滤等。所以,如果我们把
Kubernetes 正变得“无聊”,云原生是云计算领域的开源运动

Kubernetes 正变得“无聊”,云原生是云计算领域的开源运动

Kubernetes云原生

作者丨赵钰莹云原生是现在的热门技术趋势,很多开发者都对由此而兴起的一众技术十分追捧,但推及到落地实践环节,大部分企业还都处于探索阶段。云原生发展到现在已经不是普及的问题,而是落地的问题了。本文,InfoQ 有幸采访到了灵雀云 CTO 陈恺,听他分享对云原生各项技术发展现状和趋势的想法。01 云原生不是普及问题,更多是落地问题单就某一种技术的概念普及来说,可能并没有什么难点。在科技发展的过往数十年中,技术本身历经了数次更迭,开发者对新兴技术的接受度还是比较高的。随着 CNCF 社区的发展,开发者对于云原生这一概念基本达成了理解和共识,普及并不是非常难的事情,而难点在于落地。采访中,陈恺表示,不同技术的落地难度也不一样,容器是相对来说比较简单的,对应用进行容器化并运行在 Kubernetes 上就可以了,目前 Kubernetes 的核心部分已经趋于成熟,从去年年底,很多开发者就开始说 Kubernetes 正在变得 boring 。这有几层意思:第一,核心的技术变更开始变慢,这是向好的迹象,一方面表明技术已经成熟,另一方面定位和边界非常清晰,哪些东西放在核心里面,哪些东西通过扩展去做非常明确;第二,创新仍在持续,但创新会转移到技术栈的更上层;第三,Kubernetes 会变得无处不在,人们会对它习以为常。Kubernetes 核心社区主要致力于三个主要目标:第一,持续提升核心技术栈的稳定性、易用性、可扩展性;第二,将更多的技术集成到以 Kubernetes 为核心的 云原生技术栈;第三,将云原生技术栈 扩展到更广泛的应用场景。此外,CNCF 社区正在将更多的技术集成到 Kubernetes 的生态,越来越多的应用场景和技术会被推到 Kubernetes 中,虚拟机可以用 K8s 管,数据中心里面承载的内容可以用 K8s 管,Serverless 基于 K8s 实现等。但是,DevOps 和微服务改造都不是那么容易。具体来说,DevOps 涉及文化、组织架构等与人相关的因素。微服务架构改造则涉及重新开发、重构、重写等问题,如果是核心业务改造,风险又会非常大。陈恺补充道,微服务架构本质上是以运维的复杂度为代价去换取敏捷性,这时候要考虑企业是否真的有敏捷性需求,如果答案是否定的,就不要引入更多的复杂度。如果答案是肯定的,需要引入复杂度,那么如何管理多出来的复杂度,就是我们一直讨论微服务治理的原因。微服务治理不只是 Service Mesh 或者 Spring Cloud,它需要一个完整的基础设施去支撑。微服务最大的挑战是引入运维的复杂度,所以自动化运维非常重要,尤其是可观测性。在微服务后面需要各种后端数据服务,如何管理后端的数据服务,把这些服务暴露给应用,是要考虑的问题。最后,聚焦到微服务内部,服务和服务之间的连接和通讯治理,这是狭义上的微服务治理。这个问题的解决方案现在有一个很时髦的名词叫 Service Mesh,微服务治理进入到后 Kubernetes 时代。早期,微服务作为一个需求、一个用例在推动容器和 Kubernetes 的发展,当 Kubernetes 变成标准之后,它会反过来驱动,重新定义微服务治理的最佳实践。在陈恺看来,如今的云原生已经在业界达成共识:如果基于 Kubernetes 平台做微服务治理,ServiceMesh 就是最佳实践。在数据层面,Envoy 差不多是一个标准,各种选型包括 API 等都会倾向于使用 Envoy,因为其对标准的支持力度最大。在控制层面,虽然还没有形成所谓的标准,但 Istio 也是目前唯一的选择,未来是不是会出现更多方案是值得期待的。总体来说,如果需要调整业务代码和架构,改造过程就会比较困难。因此,陈恺建议对于新技术有必要先想清楚再挑一部分慢慢沉淀,直接大刀阔斧的改革不是很有必要。02 Serverless 的标准化问题自从伯克利犀利断言:Serverless 计算将会成为云时代默认的计算范式,并取代 Serverful (传统云)计算模式,因此也就意味着服务器 - 客户端模式的终结,这一技术的发展动态时刻被关注,但在过去一年,这项
蚂蚁金服 Service Mesh 深度实践

蚂蚁金服 Service Mesh 深度实践

蚂蚁金服ServiceMesh

作者丨敖小剑2019 年,蚂蚁金服在 Service Mesh 领域继续高歌猛进,进入大规模落地的深水区。本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会(上海站)2019 上的演讲,他介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考,以及大规模落地时遇到的困难和解决方案,助你了解 Service Mesh 的未来发展方向和前景。前言大家好,我是敖小剑,来自蚂蚁金服中间件团队,今天带来的主题是诗和远方:蚂蚁金服 Service Mesh 深度实践。在过去两年,我先后在 QCon 做过两次 Service Mesh 的演讲: 2017 年,当时 Service Mesh 在国内还属于蛮荒时代,我当时做了一个名为Service Mesh: 下一代微服务的演讲,开始在国内布道 Service Mesh 技术; 2018 年,做了名为长路漫漫踏歌而行:蚂蚁金服 Service Mesh 实践探索的演讲,介绍蚂蚁金服在 Service Mesh 领域的探索性的实践,当时蚂蚁金服刚开始在 Service Mesh 探索。 今天,有幸第三次来到 QCon,给大家带来的依然是蚂蚁金服在 Service Mesh 领域的实践分享。和去年不同的是,今年蚂蚁金服进入了 Service Mesh 落地的深水区,规模巨大,而且即将迎来双十一大促考验。备注:现场做了一个调研,了解听众对 Servicve Mesh 的了解程度,结果不太理想:在此之前对 Service Mesh 有了解的同学目测只有 10% 多点(肯定不到 20%)。Service Mesh 的技术布道,依然任重道远。今天给大家带来的内容主要有三块: 蚂蚁金服落地情况介绍:包括大家最关心的双十一落地情况; 大规模落地的困难和挑战:分享一下我们过去一年中在大规模落地上遇到的问题; 是否采用 Service Mesh 的建议:这个问题经常被人问起,所以借这个机会给出一些中肯的建议供大家参考; 蚂蚁金服落地情况介绍发展历程和落地规模Service Mesh 技术在蚂蚁金服的落地,先后经历过如下几个阶段:技术预研 阶段:2017 年底开始调研并探索 Service Mesh 技术,并确定为未来发展方向;技术探索 阶段:2018 年初开始用 Golang 开发 Sidecar SOFAMosn,年中开源基于 Istio 的 SOFAMesh;小规模落地 阶段:2018 年开始内部落地,第一批场景是替代 Java 语言之外的其他语言的客户端 SDK,之后开始内部小范围试点;规模落地 阶段:2019 年上半年,作为蚂蚁金融级云原生架构升级的主要内容之一,逐渐铺开到蚂蚁金服内部的业务应用,并平稳支撑了 618 大促;全面大规模落地 阶段:2019 年下半年,在蚂蚁金服内部的业务中全面铺开,落地规模非常庞大,而且准备迎接双十一大促;目前 ServiceMesh 正在蚂蚁金服内部大面积铺开,我这里给出的数据是前段时间(大概 9 月中)在云栖大会上公布的数据:应用数百个,容器数量(pod 数)超过 10 万。当然目前落地的 pod 数量已经远超过 10 万,这已经是目前全球最大的 Service Mesh 集群,但这仅仅是一个开始,这个集群的规模后续会继续扩大,明年蚂蚁金服会有更多的应用迁移到 Service Mesh。主要落地场景目前 Service Mesh 在蚂蚁金服内部大量落地,包括支付宝的部分核心链路,落地的主要场景有:多语言支持:目前除了支持 Java 之外,还支持 Golang,Python,C++,NodeJS 等语言的相互通信和服务治理;应用无感知的升级:关于这一点我们后面会有特别的说明;流量控制:经典的 Istio 精准细粒度流量控制;RPC 协议支持:和 Istio 不同,我们内部使用的主要是 RPC 协议;可观测性;Service Mesh 的实际性能数据之前和一些朋友、客户交流过,目前在 Service Mesh 方面大家最关心的是 Service Mesh 的性能表现,包括对于这次蚂蚁金服 Service Mesh 上双十一,大家最想看到的也是性能指标。为什么大家对性能这么关注?因为在 Service Mesh 工作原理的各种介绍中,都会提到 Service Mesh 是将原来的一次远程调用,改为走 Sidecar(而且像 Istio 是客户端和服务器端两次 Sidecar,如上图所示),这样一次远程调用就会变成三次远程调用,对性能的担忧也就自然而然的产生了:一次远程调用变三次远程调用,性能会下降多少?延迟会增加多少?下图是我们内部的大促压测数据,对比带 SOFAMosn 和不带 SOFAMosn 的情况(实现相同的功能)。其中 SOFAMosn 是我们蚂蚁金服自行开发的基于 Golang 的 Sidecar/ 数据平面,我们用它替代了 Envoy,在去年的演讲中我有做过详细的介绍。SOFAMosn:https://github.com/sofastack/sofa-mosn CPU:CPU 使用在峰值情况下增加 8%,均值约增加 2%。在最新的一次压测中,CPU 已经优化到基本持平(低于 1%); 内存:带 SOFAMosn 的节点比不带 SOFAMosn 的节点内存占用平均多 15M; 延迟:延迟增加平均约 0.2ms。部分场景带 SOFAMosn 比不带 SOFAMosn RT 增加约 5%,但是有部分特殊场景带 SOFAMosn 比不带 SOFAMosn RT 反而降低 7.5%; 这个性能表现,和前面一次远程调用变三次远程调用的背景和担忧相比有很大的反差。尤其是上面延迟的这个特殊场景,居然出现带 SOFAMosn(三次远程调用)比不带 SOFAMosn(一次远程调用) 延迟反而降低的情况。是不是感觉不科学?Service Mesh 的基本思路我们来快速回顾一下 Service Mesh 实现的基本思路:在基于 SDK 的方案中,应用既有业务逻辑,也有各种非业务功能。虽然通过 SDK 实现了代码重用,但是在部署时,这些功能还是混合在一个进程内的。在 Service Mesh 中,我们将 SDK 客户端的功能从应用中剥离出来,拆解为独立进程,以 Sidecar 的模式部署,让业务进程专注于业务逻辑:业务进程:专注业务实现,无需感知 Mesh;Sidecar 进程:专注服务间通讯和相关能力,与业务逻辑无关;我们称之为关注点分离:业务开发团队可以专注于业务逻辑,而底层的中间件团队(或者基础设施团队)可以专注于业务逻辑之外的各种通用功能。通过 Sidecar 拆分为两个独立进程之后,业务应用和 Sidecar 就可以实现独立维护:我们可以单独更新 / 升级业务应用或者 Sidecar。性能数据背后的情景分析我们回到前面的蚂蚁金服 Service Mesh 落地后的性能对比数据:从原理上说,Sidecar 拆分之后,原来 SDK 中的各种功能只是拆分到 Sidecar 中。整体上并没有增减,因此理论上说 SDK 和 Sidecar 性能表现是一致的。由于增加了应用和 Sidecar 之间的远程调用,性能不可避免的肯定要受到影响。首先我们来解释第一个问题:为什么性能损失那么小,和一次远程调用变三次远程调用的直觉不符?所谓的直觉,是将关注点都集中到了远程调用开销上,下意识的忽略了其他开销,比如 SDK 的开销、业务逻辑处理的开销,因此:推导出来的结果就是有 3 倍的开销,性能自然会有非常大的影响。但是,真实世界中的应用不是这样: 业务逻辑的占比很高:Sidecar 转发的资源消耗相比之下要低很多,通常是十倍百倍甚至千倍的差异; SDK 也是有消耗的:即使不考虑各种复杂的功能特性,仅仅就报文(尤其是 Body)序列化的编解码开销也是不低的。而且,客户端和服务器端原有的编解码过程是需要处理 Body 的,而在 Sidecar 中,通常都只是读取 Header 而透传 Body,因此在编解码上要快很多。另外应用和 Sidecar 的两次远程通讯,都是走的 Localhost 而不是真实的网络,速度也要快非常多; 因此,在真实世界中,我们假定业务逻辑百倍于 Sidecar 的开销,而 SDK 十倍于 Sidecar 的开销,则:推导出来的结果,性能开销从 111 增加到 113,大约增加 2%。这也就解释了为什么我们实际给出的 Service Mesh 的 CPU 和延迟的性能损失都不大的原因。当然,这里我是刻意选择了 100 和 10 这两个系数来拼凑出 2% 这个估算结果,以迎合我们前面给出均值约增加 2%的数据。这不是准确数值,只是用来模拟。情理当中的意外惊喜前面的分析可以解释性能开销增加不多的情景,但是,还记得我们的数据中有一个不科学的地方吗:部分特殊场景带 SOFAMosn 比不带 SOFAMosn RT 反而降低 7.5%。理论上,无论业务逻辑和 SDK 的开销比 Sidecar 的开销大多少,也就是不管我们怎么优化 Sidecar 的性能,其结果也只能接近零。无论如何不可能出现多两个 Sidecar,CPU 消耗和延迟反而降低的情况。这个不科学是怎么出现的?我们继续来回顾这个 Service Mesh 的实现原理图:出现性能大幅提升的主要的原因,是我们在 SOFAMosn 上做了大量的优化,特别是路由的缓存。在蚂蚁金服内部,服务路由的计算和处理是一个异常复杂的逻辑,非常耗资源。而在最近的优化中,我们为服务路由增加了缓存,从而使得服务路由的性能得到了大幅提升。因此:备注:这里我依然是刻意拼凑出 -7% 这个估算结果,请注意这不是准确数值,只是用来模拟示意。也许有同学会说,这个结果不公平:这是优化了的服务路由实现在 PK 没有优化的服务路由实现。的确,理论上说,在 Sidecar 中做的任何性能优化,在 SDK 里面同样可以实现。但是,在 SDK 上做的优化需要等整个调用链路上的应用全部升级到优化后的 SDK 之后才能完全显现。而在传统 SDK 方案中,SDK 的升级是需要应用配合,这通常是一个漫长的等待过程。很可能代码优化和发版一周搞定,但是让全站所有应用都升级到新版本的 SDK 要花费数月甚至一年。此时 Service Mesh 的优点就凸显出来了:Service Mesh 下,业务应用和 Sidecar 可以独立维护 ,我们可以很方便的在业务应用无感知的情况下升级 Sidecar。因此,任何 Sidecar 的优化结果,都可以非常快速的获取收益,从而推动我们对 Sidecar 进行持续不断的升级。前面这个延迟降低 7% 的例子,就是一个非常经典的故事:在中秋节前后,我们开发团队的同学,不辞辛苦加班加点的进行压测和性能调优,在一周之内连续做了多次性能优化,连发了多个性能优化的小版本,以小步快跑的方式,最后拿到了这个令大家都非常开心的结果。总结:持续不断的优化 + 无感知升级 = 快速获得收益。这是一个意外惊喜,但又在情理之中:这是 SDK 下沉到基础设施并具备独立升级能力后带来的红利。也希望这个例子,能够让大家更深刻的理解 Service Mesh 的基本原理和优势。大规模落地的困难和挑战当 Service Mesh 遇到蚂蚁金服的规模,困难和挑战也随之而来:当规模达到一定程度时,很多原本很小的问题都会急剧放大。后面我将在性能、容量、稳定性、可维护性和应用迁移几个方面给大家介绍我们遇到的挑战和实践。数据平面的优化在数据平面上,蚂蚁金服采用了自行研发的基于 Golang 的方案:SOFAMosn。关于为什么选择全新开发 SOFAMosn,而不是直接使用 Envoy 的原因,在去年 QCon 的演讲中我有过详细的介绍,有兴趣可以了解。前面我们给出的性能数据,实际上主要是数据平面的性能,也就是作为 Sidecar 部署的 SOFAMosn 的性能表现。从数据上看 SOFAMosn 目前的性能表现还是很不错的,这背后是我们在 SOFAMosn 上做了非常多的性能优化。CPU 优化:在 SOFAMosn 中我们进行了 Golang 的 writev 优化,将多个包拼装一次写以
三分钟说透“商业模式”的本质

三分钟说透“商业模式”的本质

产品商业模式

2003年,苹果公司推出iPod与iTunes音乐商店。这场便携式娱乐设备的革命,创造了一个新市场,并使苹果公司成功转型。短短三年内,iPod-iTunes组合为苹果公司赢得了近100亿美元,几乎占到公司总收入的一半。苹果公司的股票市值一路飙升,从2003年的50亿美元左右,升至2007年的1500多亿美元。苹果公司的成功众所周知,但很多人却不知道,苹果并非第一家把数字音乐播放器推向市场的公司。1998年,一家名为钻石多媒体(Diamond Multimedia)的公司推出MP3随身听Rio。2000年,另一家叫Best Data的公司推出了Cabo 64。这两款产品均性能优良,既可随身携带,又时尚新颖。但最后获得成功的为什么是iPod,而不是Rio或Cabo 64?这是因为苹果公司不仅仅为新技术提供了时尚的设计,而是把新技术与卓越的商业模式结合起来;而且,苹果公司真正的创新是让数字音乐下载变得简单便捷。为此,公司打造了一个全新的商业模式,集硬件、软件和服务于一体。这一模式的运行原理与吉列公司著名的刀片+剃刀(blades-and-razor)模式正好相反:吉列公司是利用低利润的剃须刀来带动高利润刀片的销售,苹果公司却是靠发放刀片(低利润的iTunes音乐)来带动剃刀(高利润iPod)的销售。这一模式以全新方式对产品价值进行了定义,并为客户提供了前所未有的便捷性。商业模式创新改变了很多行业的整个格局,让价值数十亿元的市场重新洗牌。不过在老牌企业中,像苹果一样进行商业模式创新的公司却是凤毛麟角。人们对过去10年间发生的重大创新进行了分析,发现与商业模式相关的创新成果屈指可数。美国管理协会(American Management Association)近期的一项研究也表明,全球化企业在新商业模式开发上的投入,在创新总投资中的占比不到10%。令企业高管们感到很气馁的问题是,通过商业模式创新实现增长为何如此难?我们在研究中发现了两个问题。第一,缺乏相关的定义:有关商业模式发展动态和进程的正式研究极少;第二,很少有企业充分了解自身现有的商业模式发展这种模式的前提是什么?有哪些自然的互依性?有哪些优势和限制?因此,这些企业并不知道何时可以发挥核心业务优势、何时需要通过新的商业模式来获得成功。要想让大家透过表象,看到新商业模式能够带来的前景,企业就需要一幅前行的地图。 我们的做法分为以下简单的三步: 要认识到,成功的起点根本不是去考虑商业模式,而是考虑面临的机遇,即如何才能满足客户的需求,让他们得以完成工作; 制定计划,说明公司将如何以赢利的方式来满足客户需求; 将新模式与公司现有的模式进行比较,确定为了抓住机遇要进行多大程度的变革。当你完成了这3步后,你就可以知道公司是可以利用现有的商业模式与组织结构,还是需要设立一个新的业务单元,来实施新的商业模式。每个成功的 企业,都在通过有效的商业模式来满足客户的需求不管它们是否清楚地理解了自己的商业模式。什么是商业模式我们认为,商业模式由4个密切相关的要素构成,这4个要素互为作用时能够创造与实现价值,目前来说其中最重要的是创造价值。客户价值主张凡是成功的公司都能够找到一种为客户创造价值的方法即帮助客户完成某项重要工作。在此,工作的含义是指在特定情境下需要解决的一个关键问题。只要理解了工作的含义以及工作的各个维度,包括如何完成工作的整个过程,我们就可以设计给客户的解决方案了。客户工作的重要性越高,客户对现有方案的满意度越低,而你提供的解决方案比其他可选方案越好(当然还有价格越低),你的客户价值主张就越优秀。我们发现,提出客户价值主张的最佳时机是:其他可选产品和服务的设计并未考虑到客户真正的需求,而你此时却可以完全针对客户的工作设计出圆满的解决方案。赢利模式赢利模式是对公司如何既为客户提供价值、又为自己创造价值的详细计
累计融资1.27亿美元的keep用小程序赋能运动社交价值

累计融资1.27亿美元的keep用小程序赋能运动社交价值 付费

健身社交小程序打卡

使用健身APP/小程序,或者App/小程序开发中,这几个问题你遇到过吗:1.仅用921天,就突破1亿用户的keep为什么还要开发小程序?2. keep小程序拥有哪些社交功能,如何激励用户?3. APP与小程序的如何相辅相成?要解开这些困扰你已久的问题的答案,得先看看今天介绍的这篇文《Keep打卡助手小程序上线,赋能运动社交价值》来源:小众云商以下为要点精编:1.如果在大街上同时收到2份传单,一个是保险的,一个是健身的,你会看哪一个?随着消费观念的升级,越来越多的人认为身体健康才是最大的炫耀本钱,而身体活力及优美体态也逐渐成为一个人品牌的象征。2.我们都知道健身很重要,却苦于各种理由,把健身计划一直往后拖。确实,健身是一件重要但不紧急的事情。如果有一款小程序能够帮助我们拒绝各种理由,实现梦想中的好身材,相信谁都愿意尝试。3.作为国内健身视频的拓荒者,keep以内容起家用4年时间积累了1.4亿用户,成为国内用户最大的健身APP。就在去年如此成功的APP也开发了小程序【keep打卡助手】开始赋能运动社交价值。4.【Keep打卡助手】,用户可在「运动打卡群」和「跑步打卡群」两种模式下进行选择,之后将其分享到微信群中,成员可通过账号登陆,同步Keep AP
付费¥1.00可阅读完整文章
新氧金星:“仔细想想,其实整形让这世界更公平了”

新氧金星:“仔细想想,其实整形让这世界更公平了”

互联网医美新氧

凭什么健身、减肥,身材变好了,人们会夸奖。但通过医美手段,让自己变漂亮了,就要受到歧视?互联网医美服务平台新氧于今日登陆纳斯达克。新氧上市,对中国医美行业具有里程碑意义,也让国际上更多人注意到中国医美市场。但如果要用一句话描述创始人金星和他为之奋斗的事业,那会是为了心目中更好的自己而改变,这样的努力当然值得被嘉许。新氧创始人金星是位70后,他是一个铁血军事迷,也常笑称自己是小镇青年,却比绝大多数中国人更早理解了整形这件仍颇具争议的事情。新氧创始人兼CEO金星我妈妈是整容科医生,我姐姐的双眼皮是我妈妈亲自动手做的,我姐姐这也算身体发肤,受之父母了。金星说。当正式决定进入这个行业时,他毫不犹豫地拿自己开刀,躺上了瘦脸针注射床。对经常做医美的人来讲,瘦脸针是特别特别小的一个东西,就像家常便饭。但我第一次做,紧张得要命。我请了一位医生,他足足给我解释了一个小时,说这个瘦脸针到底是什么,它的原理是什么,它为什么能瘦脸。金星回忆。如果不从事医美行业,他也许永远不会做整形项目。体验整形项目,是为了更好地理解医美用户的复杂心境。在瘦脸针后,他又陆续尝试了玻尿酸注射、埋线、植发、光电类项目。新氧创立早期,他还在新氧上写了多篇整形日记,拥有47万粉丝,那时粉丝们都知道他是新氧创始人。创业纪录片《燃点》就记录了金星某次手术过程的一个片段无影灯下的手术室,医生一边在他侧脸上埋线,一边轻声鼓励。镜头移下来,他手中攥着两个减压球。这种不安、紧张是对手术过程的恐惧和手术效果的担忧,但这只是1.5%下定决心整形的人才会遇到的问题。如果一个人只是动了动整形的念头,一个更普遍、也更难解的问题就会摆在面前:这样做真的能被理解和接纳吗?为整形正名金星自然能时时感到主流观念的不宽容:大概没有男孩子不想要一个漂亮的女朋友,但是大多数男孩子都不愿意自己的女朋友去整容。凭什么健身、减肥,身材变好了,人们会夸奖。但通过医美手段,让自己变漂亮了,就要受到歧视?因此,为整形正名成了这份事业中至关重要的一部分。它关乎一家医美服务平台公司存在的正当性,也影响着中国医美市场规模的进化速度。金星抓住一切面向公众发声的机会,表达他对于社会审美和整形的看法。审美应该更多元,不唯颜值论,但对美的追求没有错,只有让变美变得更安全、更简单、更低成本,才能彻底解决这个问题。2018年7月,金星在腾讯视频主办的名人演讲主题活动星空演讲现场说。后天美肯定好过先天丑。在一个流传甚广视频里,一名接受采访的女孩说。2018年,腾讯新闻推出了一档名为《和陌生人说话》的节目,号称在脸上花费400万的新氧达人吴晓辰和剑桥学霸王诺诺就外在美和内在美进行了对话,所引发的关注和争议也表明,中国的年轻一代对自我认知这个命题的思考。2018年腾讯视频《和陌生人说话》截图 左为王诺诺 右为吴晓辰我们从不鼓动用户做医美项目,但如果用户要做,我们会提供透明、可靠的信息,帮助她们安心便捷地变美。 这是一个浸入这家公司血液里的理念。六年前,金星看到了信息不对称、价格不透明是这个行业最大痛点,创办新氧,从社区切入,为潜在的整形用户提供信息咨询和线上医美预约服务。六年后,新氧成为互联网医美第一股,某种程度上肯定了金星重塑社会观念、改造医美行