2019架构师-年10月微软宣布开源使用二十余年库

CONTENTS|微软宣布开源使用二十余年的C++标准库理论派|亚马逊CTO的“中台论推荐文章|京东技术中台的Flutter实践如何将代码部署时间减少95%？我在Uber运营大型分布式系统三年经验谈Dropbox如何用四年完成400万行Python代码检观点|DockervsKubernetes，容器生态圈现2019年

提供反馈商务合作内容合作 卷首 作者，PerceptIn创始人，著有《第一本无人驾驶技术书我们已经拉开了全自动无人驾驶的序幕，在幕布之后的未来将如何？让我们先回顾一下硅谷的发展历史，再以此展望无人驾驶的未来。现代始于20世纪60年代，仙童电子和n通过硅晶体微处理器技术的创新开创了的新时代，这也是硅谷的。微处理器技术极大地提高了工业化生产力，推进了现代工业的发展。20世纪80年代随着XeoxAo、AppeLa及 indows等软件系统的图形界面被广泛应用，个人电脑的概念出现并开始普及，现代以此为基础普惠众人。21世纪初，在个人电脑逐步普及并被大规模应用的背景下，谷歌的出现通过互联网和搜索引擎的方式将人与浩瀚如星海的信息互联起来，至此，现代发展到了第三阶段。始于2004年的通过革新的社交网络模式将现代推进到了第四阶段。至此，人类的交往互联方式从线下扩展到了线上，人类社会在网上有了初始的迁移并逐步地成熟完善。随着互联网人口规模的膨胀，信息技术发展进入第五阶段Abnb与Uber等公司通过共享经济的思维把类社会的经济模式直接推广到了互联网社会，利用互联网+移动设备等直接连接不同用户的经济行为，取得了大范围的成功。每一阶段的发展及其随后驱动的革新，都极大地改变了人类对信息的需求和获取方式。尤其对后几个阶段而言，互联网是一个基础性条件，大多数的服务是通过互联网传达给终端用户的。现在，我们走到了发展的第六阶3架构师2019架构师2019年10月机器人开始作为服务的承载体出现，其中的一个具体事例就是无人驾驶的产品化。无人驾驶的场景特别复杂，技术特别大，它因此被称为AI技而AI技术只是无人驾驶众多中的一部分。而无人驾驶是一个系统工程，需要把众多的单点技术进行有效的整合，能否开发出一款好的无人驾驶产品取决于一个团队的全栈式工程能力与系统型整合能力，因此对整个无人驾驶架构的全面了解至关重要。4微软宣布开源使用二十余C++标准作者：StephanT.Lavavej译者20192019916日，微软C++团队博CppCon 可称为STL）。据了解，MSVCC++标准库开源之后，新的库地址为 /STL，其中包含了所有的产品源代码、新的CMake构建系统和信息的自述文件。微软C++团队正在努力将其迁移到中，目前虽然可以克隆和构建代码，但是在查看拉取请求之前，微软C++团队在博客中，也回答了几个大家都很关心的问题，微软C++团队：选择开源主要是因为以下的原因：开源之后，在中使用STL允许用户我们的开发，并可尝试使用更改同时还可以通过来帮助改进我们的拉取请求；随着C++标准化的加受开源贡献的主要功能是非常重要的，例如C++20的计时和格式库。另外，我们也希望能够通过主要功能的实现来回馈C++社区，例如C++13STL使用的是什么开源？是否会直接影响VisualStudio的客户？微软C++团队：MSVCSTL的开源为ApacheLicensev2.0LLVMExceptions，是由Clang/LLVM/libc++项目创建的。之所以会选择这个较为宽松的开源，是因为拥有libc++相同的能够使得库之间共享代码变得更容易。需要注意的是，MSVCSTL并没有与libc++合并，它们仍然是支持具有不同数据结构表示的不同平台的不同库，不过，如果libc++的者有从MSVC的STL中获取必担心。对于MSVCSTL的客户来说，可能会担心开源的问题，微软在开源中明确，客户使用MSVCSTL编译自己源代码生成目标代品发送给最终用户时，无需提供归属信息。这也是我们选择这个开源（附加说明：MSVC的STL中包含来自Boost的源代码，Math和Ryu可在BoostSoftwareLicensev1.0下使用。这是另一个开源，也包含对象代码的显式异常。我们派生的源代码是在ApacheLicensev2.0LLVMExceptions发布的。）是否有打算开源MSVC工具集中的其它工具吗微软C++团队：目前没有这样的计划，之所以开源STL，是因为它与其他MSVC库和编译器不同。具体而言，STL是由C++标准化快速发展和设计的，与其他MSVC库不同，由设计是开源的一个优势，这意味着我们不需要花费任何时间和精力进行功能设计，另外，实施和策略受到约束，因此更容易。STL与编译器不同，相对容易贡献，并且松耦合，也许，未来我们可能会开源STL支持库在开源过程中遇到了哪些难题微软C++团队：遇到了一个小问题，因为我们花费了一些时间来检测构建系统、测试基础架构和问题，因为关于C++20库功能的工作有些延迟了。不过，我们刚刚完成了所有C++17库的功能，所以C++20库应该不会是问题，我们能够更有效地处理STL，使得其更快地达到C20的完整性作者WernerVogels译者核子可作作者WernerVogels总结AWS这二十多年来，如何通的CTO，他撰写了一篇文应用程序架构、调整企业织架构等方式，让构建现代应用程序的客户“将时间花在定义务逻辑上，扩展系统以轻松满足期客户需求，提高敏捷性，同时调整为小团队并“赋予他们对应用程序内特定部分的操作权限”，不谋而合了。也可谓是亚马逊的“中台论”，虽然他们并没有使用个词创新一直是亚马逊公司DNA中的重要组成部分，但大约20年之前， 那个时候，亚马逊所服务的客户数量远不及当下。尽管如此，我们 算为客户提供新的功能或者产品例如流时，我们就必须在专为了从根本上解决这一难题，我们通过《分布式计算》建立起新的蓝图。这是一份描述新架构的文档。通过这份，我们开将自身应用程序通过众多被称为“服务”的小型基本单元加以重组，从而大幅提升对亚马逊整体业务的扩展能力。但是，应用程序架构只是故事的前一半。至于后一半……当时是1998年，亚马逊的各个开发团队都在使用相同的应用程序，因此每。为了支持这种新型架构，我们分解了功能层级结构，并将企业组织重新编排为小型自治团队 小到每次点餐只需要两份披萨 这“双披萨团队”委派到不同的特定产品、服务或者功能集上，赋予他们对应用程序内特定部分的操作权限这使得我们的开发成为产品所有者，并能够根据自己的决策迅速对个别产品产生影响。。 这就是2006年诞生的AWS。而我们，如今仍在坚持双披萨团队这一基本建制元或者说“微服务”，而且除此之外，现代应用程序的最佳实践还要求在改变设计与构建技术之余，重新考虑其管理方式适合自身的顺序采用以下五大元素：微服务、数据库、自动软件发布架构模式：微服像亚马逊这样的大多数企业最初都是以整体式应用程序作为业务基果应用程序中的某个进程遭遇需求，我们只能扩展整体架构才能实现单个进程的扩容。服务形式运行。服务将专为业务功能而构建，例如购物车，而且每项随着组织由整体式架构逐步转向微服务架构，很多开发也希望通过流水线管理各项服务中的依赖关系这就要求我们创造出新的方法以大家也可以使用容器或者WSLabda函数。容器是目前最受欢迎的代码打包选项，同时也是实现遗留应用程序现代化的最佳工具之一。容器技术，为我们带来出色的应用程序可移植性与设置灵活性。而利用Labd，大家则能够更轻松地获取所需功能利用代码编写出业务逻辑即可。微服务架构的另一大需求，在于须为之建立一种服务间的相通信方式。目前大部分应用程序都继续沿用API连接，但也有一些选择数据管理：数据以最适合自身需求的不同数据库类型。图数据库，例如AmazonNeptune。或者，如果您的应用程序需要实时数据，也可以选择AmazonElastiCache等内存内数据库，其常用于游戏以及物联网应用场景。一般来软件交付：自动发布流水虽然这种新方式消除了更新的开发与交付等协调性，但同时也给我们的解决方案采取双管齐下的方式：标准化加上自动化。首先，我资源的建模与配置提供标准。这些“基础设施即代码”模板能够帮助我们的不再依赖于手动过程。在亚马逊，这种作法确保了各个团队都能够根据我们的要求实现对流程与部署的配置第二点，我们开始利用自动化技术将手动流程从软件交付流水线中剔除出去。在自动化发布流水线的帮助下（包括持续集成与持续部署，简称CD），我们得以快速测试并发布大量代码，同时最大限度减少错误机率。通过CI，我们的团队会定期将代码变更整合至同一套库内。而后，我们会对其运行自动构建与测试，以确保能够尽早发现问题。而利用D，我们的团队每天可以多次提交变更，且无需任何人为干预即可将成果投入生产。起初，我们发现去掉人为干预只会带来相当糟糕的部署。但是，运营模式：尽可能采用无服务器模一项服务背后都对应着一套数据库外加一支负责不断发布新功能的团这些活动部件可以分为以下两类作为企业“独门绝技”的活动组件，负责保障业务成功，例如能够通常被我们称为“无差别承载性”活动组件，这些活动必须完成，但本身无法提供任何竞争优势。对于大多数企业来讲，此类任务包括服务器管理、负载均衡以及安全补丁应用等等。我们在2014年提出了“无服务器”概念，并同时发布了AWSLambda。AWSLambda是一种计算服务，能够帮助大家在无需配置或者管理服务器务交给AWS负责以帮助客户专注于优化自己的“独门绝技”。事实上，这放精力，将时间投入到真正的业务与众不同的方面例如产品亚马逊CTO的“中台论当我们说起“无服务器”时，我们指的是在无需分神于基础设施配置或按使用量计费的方式。无服务器不只有Labda，它是一套完整的应用程应用程序堆栈通常由以下三大要素组成像AWSFargate这样的计算服务，用于运行应用程序逻辑像MySQL以及PostgreSQL关系数据库这样的数据方案，也可以使用AmazonAurora等实现数据的持久驻留；类似于事件总线AmazonEventBridge这样的集成层，用于实现数安全性：每个人都有责过去，很多企业都把安全视为一种神奇的“调味料”在应用程序准土，因此组织必须采取新的安全方法，围绕整个应用程序构建起防火再是安全团队自己的责任相反，安全深深融入到开发生命周期的每个阶安全性将被整合至代码库、build管理程序乃至部署工具当中。这既使用无服务器服务的情况下，安全状态的难度更低，这是因为底层基础设施的安全运营工作包括系统版本更新、软件修复与等都现代化之 段推动云资源优化。Yelp等客户也采取了类似的现代化方式。对于以托管应用程序作为起点的客户，最常见的方法自然是重新托管，即“将应用程序直接迁移至云端”。在此之后，很多客户开始进一步探索云环境中的托管服务，尝试将数据库与API管理等任务迁移至WS，从而保证将自己的工作重心放在业务逻辑身上。确方法，因为在AWS平台上，各种各样的应用程序都能够以不同的状态够审视自身整体业务优势，特别是对时间与资源的优化分配。他们将时间花在定义业务逻辑上，扩展系统以轻松满足期客户需求，提高敏以向汽车买家提供车辆信息的 新功能的推出时间由六个月缩短至一周。初创企业Bynder公司也将产品而这，正是现代应用程序的力量所在如何将代码部署时间减95作者：EvanLimanto译者本本文作者所在的公司Plaid是一家金融科技公司，该公司搭建了司的发展，基础设施规模在不断扩大。目前，这家公司运行着20多个服务，每天在服务上部署50多个代码提交。因此，最小迅速进行Bug修复并运行平稳的连续部署系统。码的能力。工程师要花至少30分钟才能通过多个过渡环境和生产环境构虽然我们计划实现长期改进，比如将基于AmazonECS服务的基础设施迁移Kubernetes上，但是，为了在短期内提高迭代速度，有必要快速AmazonECS部署的高延我们的银行集成服务由4000个Node.js进程组成，这些进程运行在的Docker容器上，这些容器托管并部署在Amazon的容器编排服务ECS上。在分析了我们的部署过程之后，增加的部署延迟归结到三个不同的组件启动任务会导致延迟。除了应用程序启动时间之外，ECS健康检个过程的三个参数是interval、retry和startPeriod。如果没有对健康检查进行仔细调优，容器可能会卡在“启动”状态，即使它们已关闭任务会导致延迟。当我们运行ECS服务更新时，SIGTERM我们启动任务的速度限制了部署的并行性。尽管umPercent参数设置为200%，但是ECSstart-taskAPI调用的硬限制是每个调用只能执行10个任务，而且速度有限。我们需要调用400次才方法探我们考虑并试验了一些不同的潜在解决方案，以逐步实现总体目标通过修改健康检查参数来调整ECS配置。我们尝试通过减少neval和arPerod的值来加强健康检查，但是ECS在启动时将健康的容器错误地标记为不健康，导致我们的服务无法完全100%（ECS部署缓慢在ECS集群中启动实例，以便可以在部署期间同时启动小的修改，我们就能够在每个容器省大约5秒的时间。尽管这些更改将总体部署时间减少了几分钟，但是我们仍然需要将Noderequirecache是一个JavaScript对象，它根据需要缓存模块。这意味着多次执行er(f’或import*asfoofrom'foo’只会在第一次时请求foo模块。神奇的是，删除requirecache中的条目（我们可以使用全局require.cache对象）将迫使Node在下次导入模块时从磁盘重新读为了绕过ECS部署过程，我们尝试使用Node的requirecache在运行时执行应用程序代码的“热重载”。一旦接收到外部触发（其实现为银行集成服务上的gRPC端点），应用程序将新代码来替换现有的构我们能够消除ECS部署中存在的大部分延迟，优化整个部署过程。在Plaiderdays（我们的 组工程师聚在一起，为我们所谓的“快速部署”实现了一个端到端的概念新构建的Node代码也试图使失效缓存，那么器代码本身将如何重新加载就不清楚了。（有法可以解决这个问题，就是使用NodeEventEmitter，但是会给代码增加相当大的复杂性）。更重要的是，还存最终解决方案：重新加载了自己的进程封装器，它的名称非常贴切，叫做Bootloader。Bootloader的包含设置日志管道、转发信号和ECS元数据的逻辑。每个服务都是通过将应用程序可执行文件的路径以及一系列标志传递给我们没有清除Node的requirecache，而是在预期的部署构建后，使用特殊的退出代码来调用process.exit实现服务更新。我们还在Bootloader中实现了自定义逻辑，以触发使用此代码退出的任何子进程的进程重载。与“热重载”方法类似，这使我们能够绕过ECS部署的成本并速部署”逻辑允许其推广到在Plaid运行的任何其他服务。下面是最终解决方案Jenkins部署管道向银行集成服务的所有实例发送RPC请求，指示应用程序接收gRPC请求进行快速部署，并根据接收到的提交散列从AmazonS3构建好的压缩包。然后，它替换文件系统上的现有构建，并使用Bootloader识别的特殊退出代码退出。Bootloader看到应用程序使用这个特殊的R”退出代码退出，服务运行新的代码下面这简单说明了这个过程如何将代码部署时间减少95%结我们能够在3周内交付这个“快速部署”项目，并将90%生产容器的部署时间从30多分钟减少到1.5分钟。如何将代码部署时间减少95%的颜色）。如果注意下黄线，就可以看到它在12:15左右增长趋于平稳，这个项目极大提高了Plaid集成工作的速度，允许我们更快地发布特性及进行Bug修复，并将浪费在上下文切换和监视仪表板上的工程时间京东Flutter实践京东ARES多端技术在2019年，Flutter推出了多个正式版本，支持的终端越来越多，使越来越多的研发团队加入到Flutter的学习热潮中，京东作为互联网大厂之一也积极参与了Flutter的跨端方案研究。本文将介绍京东在Flutter上为什么考虑Flutter技术其实京东很早就开始研究并实践跨端的开发解决方案，最早使用的是HybdApp的技术方案，从2015年底开始逐步转向RN技术栈，目前应该是业内N技术平台应用最广泛、配套设施比较完善的公司之一。从2018年中开始，我们也关注到了Fuer技术，最吸引我们的特性是高性RN技术相对不足的地方。高性能指的是复杂场景和交互下的渲染性能，兼容性指的是不同终端平台上的布局和体验andod平台上尤其重要。Flutter随着2018年底正式发布了Flutter预览版本，京东也越来越多的研发团队有用Flutter进行开发业务的诉求。我们正式启动研发并发布了JDFlutter引擎。在Flutter引擎之上，我们做了额外的Flutter工程改造：对Flutter开发环境和dart代码管理进行优化，可以无APP中并支持自动化dart编译打包，便于开发和调试。路由及多页面管理：对原生页面和flutter页面实现了集中路由管理，扩展UI组件库：支持的Material和Cupertino样式不能满足需求，埋点等等基础能力的打通并提供了50+原生扩展API。Android端动态化支持：在Android端实现了动态化支持，可以线上热更新业务。iOS端暂不支持动态化。目前京东商城、京东、京东到家、京东物流、7Fresh等APP都有业务采用JDFlutter进行开发。JDFlutter框架设基础层：提供了Flutter的基础组件支持，包括组件管理，状态管业务层：即具体业务逻辑实现层，根据业务需要进行不同组件组合，实现业务页面的快速开发组动界面的改变，更有利于数据的持久化和保存，同时也有利于UI组件的HybridRouter：主要解决Flutter和Native之间交叉跳转的问题，减少内存开销，共享同一个FlutterEngine。编译发布：优化Flutter原有的编译逻辑，管理依赖Flutter原生依赖关联，打包Flutter和原生代码，实现自动化构建发布。资源管理：管理资源，将资源转换成Flutter类，便于资源的操作，类似Andorid的R类；模版代码生成：减少Flutter的代码编写，自动生成Flutter组件的JSON转换：将JSON数据转换成Fluttercode，并提供jsonJDFlutter业务开发实JDFlutter为业务研发团队提供了全流程的开发解决方案配置混合Flutter和原生混合开发有两种情况，其一，开发Flutter业务的同学，需要和原生做交互，因此需要有Flutter和原生的混合编译环境；其二，使用原生SDK开发业务的同学，需要和Flutter业务一起集成打包，此时需对Flutter透明，以减少对Flutter编译环境的依赖，并且，只依赖原生编译环境即可，此时Flutter编译成aar依赖，放入原生项目中即可。接下来，重点介绍Android和iOS的混合编译环境配置。Androidfluttercreate-tmodule--orgcom.example在原生根项目的settings.gradle加入如下配置信//include':app' //assumedexistingcontentsetBinding(newBinding([gradle:this])) //newevaluate(new // // //在原生App模块中加入flutter依dependenciesimplementation}这样就可以原生项目一起编译了具体可以参照文档 Flutter-to-existing-这样的方式虽可以满足混编需求，但还不是特别方便，开还需要去AndroidStudio项目中进行编译，比较麻烦，所以我们也可以把Flutter项目settings.gradle改造，在Flutter开发环境下直接运行包含原生//include":$projectName"project(":$projectName").projectDir=new这样改造之后即可在FlutterIDE中直接编译Flutter混合工程，并进需要注意Flutter中gradle编译环境和原生编译环境的一致性，如果不一iOS创建flutterfluttercreate-tmodule进入iOS工 ，初始化pod环境（如果项目工程已经使用Cocoapods，跳过此步骤pod##在Podfile文件添加的新代码flutter_application_path='/{fluttermodule eval(File.read(File.join(flutter_application_path,'.ios','Flutter','podhelper.rb')),binding)安装pod打开工程(***.xcworkspace)配置buildphase，为编译Dart代码添加打开iOS项目，选中项目的BuildPhases选项，点击左上角号按钮，选择NewRunScriptPhase，将下面的s添加到输入框中：ROOT/packages/flutter_tools/bin/xcode_backend.sh”embedFlutter开发中使用的组件，一般公司会采用共享的方式，以避免重复开发，而Flutter组件共享，即需要使用pub仓库。由于公司的业务组件不适合上传到pub仓库，因此，需要搭建仓库，以解决各个业务研发团队，对Flutter组件共享需要。感的同学可以研究下pub仓库的源码.org/，其对Cloud环境有很大的依赖，也可以基于.com/kahnsen/pub_server来搭建一个简易版本的仓库，以满足上传和功能，pub协议相对比较简单，我们可以在源码增加协议接口来实现运行$git $cd~/pub_server$pub~/pub_server$dartexample/example.dart-d/tmp/package-dbListeningonTomakethepubclientusethisrepositoryconfigureyours$exportPUB_HOSTED_URL=发布一个Flutter组件需要修改pubspec.yaml，增加以下内name:o_plugin//plugin名称descriptionAnewFlutterplugin.介绍version:0.0.1//版本号authorxxx homepage://组件的介绍页publish_to:仓库上传地上传时可以使用如下命令检查代码错误，并显示出上传 结pubpublish--dry-如果有不想上传的文件，可以在根增加一个.gitignore文件来忽Flutter组件的依赖配置，在项目的pubspec.yaml中dependencies下name:url:version:这样可以在公司实现Flutter组件共享，如果不想搭建自己的仓库，也可以采用git依赖，配置如 refdev-branchFlutter业务的开发与调在FlutterIDE中编译代码调试会很方便，直接点击debug按钮即可进行代码调试，如果是混合工Androidstudio或者xcode中运行的工程，将要调试的App安装到中（安装debug版本），连接电脑，执行如下命令，同步Flutter代码到设备的宿主App中$cd$flutter执行完命令后会进行等待设备连接状态，然后打开宿主App，进入Flutter页面，看到如下信息提示则表示同步成功。zbdeMacBook-Pro:examplezb$flutterattachWaitingforaconnectionfromFlutteronMI5X...SyncingfilestodeviceMI Tohotreloadchangeswhilerunning,press"r".Tohotrestart(andrebuildstate),press"R".AnObservatorydebuggerandprofileronMI5XisavailableForamoredetailedhelpmessage,press"h".Todetach,press"d";toquit,press"q".打开可以查看调试信息，代码改动可以按r来实时同步界面，如果改动没有实时生效可以按R重新启动Flutter应用JDFlutter热更新实大部分跨端框架，诸如ReactNative/Weex/H5等，基本都能做到随Flutter因其AOT的设计，预想会很难达到这种灵活度，但技术上仍具有一定的可行性，正如我们在之前的Flutter介绍文章中提到的，按照先有的API设计，是可以支持热修复的，但仅限于Android。的架构上已经支持了热修复架构，大家可以更新到1.2.1版本查看，但是的功能还比较弱，无法做到版本控制和回滚的灵活性，所以JDFlutter并没我们可以首先一起看一下热修复方案的设计原理Flutter1.2.1版本引入了DynamicPatch为了更清楚的了解热修复的原理和过程，我们需要首先深入了 的业务包结构和FlutterApp可以看到主体代码集中在 中，除此之外还有少量端的框架java代码及flutterso引擎库外Flutter包的初始化流 页面启动时是如何加载这些代码的呢？那就要从 的初化说起了，在页面启动前需要调用FlutterMain.startInitialization来做初始可以看到该初始化是要求在主线程完成的，另外主要完成了以下三点检查asset下Flutter包的完整性，主要是上面介绍的一些包，一致有些文件没有打包进去，然后会直接crash，就是在这里触发的，具体解压部分asset下的资源到data分区，以下是一些片段的代码，那为什么要解压呢？放在asset下也是可以通过assetManager的。这里应该是从性能角度要求解压的，因为频繁的使用assetManagerasset是很容易造成多线程阻塞的，一旦阻塞了将会导致整个Flutter业务全部无法渲染，所以需要解压一些的，而不是解压了所有的资源(例如就没有解压)从代码来看，先增加要解压的库 ，然后启动task从中解压库到data分区对应app数据下的app_flutter 其中res_timestamp文件用于标记一些时间戳，算法比较固定，根据客户端的安装时间及app的versioncode生成，也就是说当用户打开Flutter页面后这个值就是固定的，如果有任何修改引擎会默认有变化，删除现有app_flutter的包，重新解压。上面是对Flutter程序加载的分析，最终Flutter页面显示是需要呈现在原生组件FlutterView中的，这个组件会和底层FlutterNativeView进行绑定，并最终运行上面说到的data分区的Dart代码来渲染UI。如果使用的是FlutterActivity，则默认FlutterView是全屏显示，如需要定制页面，需要自己设计Activity。热修复实了解了这些，其实热修复方案已经呼之欲出，替换原有解压后的app_flutter包，杀进程，然后重新加载Flutter页面即可。这里我们可以做采用adb命令push一些修改过的并编译的dart代码到 先打开Flutter页面，默认会加载asset下的包，并解压到data分区修改一个Flutter工程，并编译代码，最终在工my_flutter/.android/Flutter/build/intermediates/flutter/release中看到打包这么文件中只有flutter_assets和isolate_snapshot_data文件是包含业务代码和的，其他部分基本不会变化，所以我们这里要替换的也就是这两个，大家可以使用adbpush命令将资源文件push到对应的data分区来做个实验。adbpushmy_flutter/.android/Flutter/build/intermediates/flutter/release/isolate_snapshot_data/data/data/app包名/app_flutter关闭Flutter页面，在Task中杀掉进程，回来后重新打开Flutter页面就能看到改动的效果，资源是存放在flutter_asset 放到这个 ，同样能更新际使用中替换还是有很多问题的。那是如何设计的呢？热修复设计热修复步FlutterSDK1.2.1中，提供了ResourceUpdater，用来做包的检在页面初始化时，检查固定的更新有没有业务升级包，从代码来看，必须在manifest中打开该功能，设置从逻辑上来看，只有在页面onResume或者App重新开启的时候会下载升级包，整体是通过http请求完成的，整体实现代码大家可以参考ResourceUpdater中DownloadTask的实现部分，这里就不细说了。每次init的时候都会触发检查data分区的app_flutter包，如果不存在就会从aaset解压出来，而升级包的替换就是在这步完成 解压，如果不存在还是从asset 是manifest.json文件，里面会包含buildNumber/baselineChecksum字段，同时也会对"isolate_snapshot_data","flutter_assets/isolate_snapshot_data"等文件做CRC32校升级后的版本时间戳是从配置的manifest.json文件中如何配置服务文章上部分介绍了怎么打开升级patch的功能，因升级涉及到服务端，那是怎么做到关联到服务器的呢？其实原理比较简单，需要配置客户端的manifest文件的meta属性，增加PatchServerURL，也就是我们服务的地址，以及模式PatchDownloadMode和加载模式PatchInstallMode，默认是ON_NEXT_RESTART（下次初始化时）存在的缺过于定制化，全部在引擎完成，很难适配一些特殊的需求定制不支持现在比较主流的升级流程，诸如灰度和白等功能版本号的维度不好控制，同时不能做版本回滚等操作JDFlutter如何实现热修JDFlutter的整体实现原理，其实和是一样的，目前来看不修改引擎的前提下，只有这种方案最简单，但是我们没有使用的这套升级架构，默认关闭了patch功能，并框架之外实现了替换包和加载的服务端根据客户端的唯一标识支持了白和灰度下发升级包优化和替换流程。Flutter的升级包一般有4-5M，而且从网络易产生UI阻塞或者包异常。接入JDFlutter的客户端包后，并不会直换文件，而是修改名称后解压到app_flutter，等待业务页面重新打开或者重新初始化时再修改成Flutter标准名同时并发运行的Flutter页面较多，需避免因为升级出现一些中间升级失败或者后业务包有问题，出现无法加载的情况或者文线上出现大量异常后，可以指定对应的Flutter业务执行降级策略，让该业务迅速降级到H5页面。热修复规Flutter业务包差量升级：现有的升级模式都是全量包覆盖，即使压缩后升级包还是很大，影响升级成功率及用户流量，后续会采用一些diff工具，对比生成差量的patch，通过服务端下发后，在客户端合并成完整包，升级后及时更新页面：现有方案（包括标准升级方案）没有办法做到业务包或者替换业务包后及时刷新页面，需要restart进程后未来展Flutter是非常出色的跨端开发技术，现在已经取得了长足的发展。社区生态和框架成熟度也正在快速追赶RN。相信不久的将来，Flutter+RN一定会成为跨端开发平台的绝代双骄。京东ARES跨端团队作为京东技术与数据中台的多端技术平台团队，聚焦于跨端开发技术框架和平台搭建，包括但不限于RN、Flutter、小程拼购等京东系App内，帮助业务团队低成本、快速开发自己的业务，Uber运营大型分布式系统三年经验作者：GergelyOrosz译者：足GergelyGergelyUber公司内负责支付系统的运营。他在这篇文章里本文翻译自“OperatingaLarge,DistributedSysteminaReliableWay:PracticesILearned”，翻译已获得原作者GergelyOrosz。在过去的几年中，我一直在构建和运营大型分布式系统：Uber的支高负荷高可用系统的构建和运营是多么富有性。就构建系统这件事来说，它本身是非常有趣的。要规划好当流量增加10倍/100倍时系统该如更是令开眼界的经历。系统越大，定律“可能出错的事终将出错”就越适用。对于频繁进的问题如硬件故障或不把有缺陷的代码发布到生产系统，到连接数这篇文章是我在Uber工作期间，关于如何可靠地运营一套大型分布 大多数情况下是这样的），还是运行在云端（Uber的系统有时候会扩展具体来说，我会谈到以下话题 值班、异常检测与告停服与事件管理流事后总结、事件回顾与持续改进的文故障切换演习、有计划的停机、容量规划与黑盒测SLO、SLA及相应的报独立的SRE团对可靠性做持续投深入阅读建要知道系统是否健康，我们就要回答问题：“系统在正常工作吗？”需要这事来就容易。基础设施健康：如果一或多台服务器、虚拟机负载过高，那分布式系统就会发生部分降级。服务要运行在服务器上，所以像CPU使用率、 做这样的的，而且支持自动扩展。Uber有个很大的 服务健康：流量、错误、延迟。“后端服务健康吗”？这个问题实健康提供着有价值的信息。我喜欢为它们各自设置专门的。构建新服务时，使用合适的HTTP响应，并相应的编码，这些都会提供很多关于系统状态的信息。比如在客户端出错时返回4XX编码，在服务端出错时返回5XX编码，这类很容易构建，也很容易解读。对系统延迟的值得多考虑一下。对于产品来说，目标就是让大多为平均延迟会掩盖一小部分高延迟的请求。因此就经验来说，监测P95、P99或P999（即95%、99%或99.9%的请求）的延迟指标会更好。监测这些指标得到的数字可以回答这样的问题：99%的人发出的请求会有多快得到响应（P99）？1000个人发出请求，最慢能怎样（P999）？如果有读者对这个话题感，可以进一步阅读文章latenciesprimer。上图展示的是平均、P95和P99的延迟指标。请注意，尽管平均延迟是低于1秒的，但有1%的请求花费了两秒或时间才完成，这样的事一是谷歌的书《SRE：运维》，另外是分布式系统的“四个黄金信号”。从中可以知道，如果你的面向用户的系统只想监测四个指标的话，那么关心流量、错误、延迟和饱和度就好了。喜欢吃快餐的话，可以读读CndySrdharan的《分布式系统可观测性》，里面到了其它一有用工具如与件日、指和有关最佳践。业务指标，但我们无法得知服务的行为是否符合预期，使得“业务可以照常进行”支付系统为例，一个关键问题就是：“人们用某种特别的支付方法，是不是已经足够可以完成一次旅行？”辨别出服务使能的业务事件，并对这些业务事件进行，这是最重要的步骤之一。们就得花很多心思，以Uber的可观测性技术栈为基础，努力地为自己定制这类。值班、异常检测与告值班就是一个更广的话题了：nceent杂志在这方面做得很棒，对值班问题进行了许多方面的探讨。我特别倾向于把值班做为“谁构建，谁负责我们团队就负责自己构建的支付服务的值班。因此不管什么时候发生了告警，值班工程师都会响应并对问题进行处理。我们该如何从得出警告从数据中发现异常，这是一个巨大的，也是机器学习的用武之地。有许多第服务可以提供异常检测功能。而且对于我们团队来说了适合Uber用例的解决方案。位于纽约的可观测性团队还就Uber如何做异常检测这个写过一篇很不错的文章。从我们团队的角度看，我们会把我们的数据推送到他们的管道中，并收到不同信任程度的告警，然调节告警系统非常重要。对告警信息进行检查，并标记是否需要采取相Uber的值班例子，由位于的Uber开发者体Uber位于的开发者工具团队开发了专门的值班工具，用于对告警进行注解，并对轮班进行可视化。我们团队每周都会对上一周的值班停服与事件管理流设想一下，这周由你值班。半夜里来了个告警，你就要一下对于小型系统来说，停服不算什么烦，值班工程师可以判断出发晰标准的故障广播和沟通就成了故障顺利解决的关键。曾经发生过好几个案例，告警看起来与我之前见过的似乎一点关联都没有，幸好起。事实上第二天回来上班再仔根本原因也未尝不可立刻恢复生产，事后原因处障我会“肾上腺素激增”，想要直接把问题当场解决掉。一般来说故障都是由某次新么做收益很小，损失却很大。因为新的修复代码必须尽快完成，那就只能在生产环境进试，这么做反而更加容易。事实上第二天回来上班再仔根本原因也未尝不可事后总结、事件回顾与持续改进的文这里讲的是一个团队如何进行故障的后续处理。他们会继续做次系统级的修剔的。Uber的事后总结模板已经随着时间的推移而演进好多个版本了，好的事后总结会对故障根本原因进行深入挖掘，得到改进措施来避免类似的故障发生，或者在下一次出现类似故障时可以快速检测和恢复。我说的深入挖掘，不是说浅尝辄止地知道“这次故障的原因是最近提交的代码引入的缺陷，在代码时没能发现出来”就可以了，用“五个为什么”的思考技巧去深入挖掘，最终得出一个更有意义的结论。比如下面的例子： >缺陷是由某次提交的有缺陷的 >代码者没注意到这 >因为 >因为没有测试账号的话，为什么我们没有测试账号？因为现在的系统不支持的工程师们进行，并对其中的关键点提出意见。公司级的技术管理层故障切换演习、有计划的停机、容量规划与黑盒测线稳定运行，这样的投入又是至关重要的。我加入Uber公司之后才第一历了几次之后观点慢慢发生了变化。我一直认为，设计健壮的分布式ServiceA和ServiceB，每个数据中心运行着几十上百个虚拟机，资源利用率是60%，告警的阈值是70%。现在我们做一次切换，把数据中心A的流量全都切到数据中心B去。在这种情况下假如不部署新的服务器，数据中心B肯定处理不了这些流量。部署新服务器可能会需要很长时间，后端压力所有可靠的分布式系统都需要具备在不对用户体验造成任何影响的情况下“应该”，因为这样的演习是检验分布式系统网络可靠性最有效的方法之一。户、已知依赖比较少的服务来说，做这样的练习相对简单。但关键系以Uber为例，一个很明显的黑盒测试用例就是在城市的范围内检测乘车者与的匹配是否正常。即在某个特定的城市里，乘车者通过Uber发起的请求是否能得到的响应，并完成一笔载客生意。当这个式系统的定义是指那些每个月要支出几万甚至几十万的计算与系并非难事。另外一件重要的事就是，要挑选供应商并锁住云服务提供商的折扣。如果你的服务支出很大，而你又忽略了容量规划，那你就SLO、SLA及相应的报SLO意味着服务等级目标（ServiceLevelObjective），是系统可用SLO，比如容量目标、延迟、准确度、可用性等。这些SLO可以用于触SLO500250050-p99500-业务级SLO或功能级SLO是对上面这些服务的抽象。它们会包括直接影响用户或业务的指标。比如一个业务级目标可以这么定义：希望99.99%的邮件可以在一分钟之内确认发送成功。这个SLO也可以与服务级SLO相对应（比如支付系统和邮件接收系统的延迟），也有可能会用服务等级协议（SLA，ServiceLevelAgreement）是服务提供者与服务“支付系统99.99%可用”可以做为一个SLA，它可以继续分解为各个支撑系统的特定SLO。定义了SLO之后，下一步就是对它们进量并报告。对SLA和SLO进行自动化的测量和报告，这是个复杂的目标，会与工程和业务团队的优先级相。工程团队不会感，因为他们已经有了各种不同级别的，可以实时地检测故障。业务团队也不会感，他们更希望把SRE团站点可靠性这个词大概在2003年出自谷歌，谷歌公司现在已经有了超过1500名SRE工程师。因为运营生产环境的任务越来越复杂，越来越快速成长的技术公司一般会比较早成立SRE团队，他们会有自己的演进路线。Uber的SRE团队成立于2015年，任务是对系统复杂度进行持续管理。别的公司在成立专门的SRE团队同时，也可能成立专门的基础设有了SRE团队，他们就会从运营的角度考虑，让运营大型分布式系统的工作变得更轻松。SRE团队可能会有标准的和告警工具。他们可能会或自己构建值班相关工具，可以为值班的最佳实践提供建议。他他们会驱动选择、定制和构建标准工具，来定义和测量SLO不同的公司需要SRE团队解决不同的痛点，所以不同公司的SRE团读书，想深入了解SRE的话可以读一下。把可靠性做为持续投组织，比如一家医院。要让一家医院运营良好，就要不断地做验证和检（、告警、黑盒测试等）。新员工和新设备会不断投入进来：对医院全职工作，对效率的测量和报告也变得很重要。因此大型医院就会有靠基础设施、SRE等支持团队。深入阅读建书《SRE：运维来自谷歌的非常棒而又免费的书。其“控分布式系统”一章的内容与本文密切相CindySridharan写的《分布式系统可观测性》：这是另一本非常棒的MartinKleppmann博士写的《设计数据密集型应用》：这是迄今为止资Increment杂志的值班话题：这是一系列的文章，内容聚焦于亚马 、谷歌和Netflix等公司的事件响应流程。点击这里查看HackerNews上对这篇贴子的留言Dropbox如何用400代码检作者：JukkaLehtosalo译者：核子可 Python的大用户之一Dropbox公了数百万Python代码，动态类型的存在让代码越来开始利mypy逐步将代码转换为静态类型。虽然效果得到了充分验证，但整个过程充满了各种错误和失败。本文，Dropbox公司完整输出了从项目研究到实践的Python静态检查全过程，以期对各位开者有所帮助事实上，Python已经成为Dropbox公司使用范围最广的语言，其广泛适用于后端服务与桌面客户端应用程序等（当然，Dropbox公司也在大量使用Go、TypeScript以及Rust等语言）。在Dropbox公司数以百万计的Python代码行中，动态类型的存在让代码越来越难以理解，并严重影响生产力水平。为了缓解这一问题，Dropbox公司一直在利用mypy逐步将代码转换为静态类型（顺带一提，mypy可能是目前Python当中最流行的独立类型检查器，属于开源项目，其开发团队来自于Dropbox。）。截至目前，Dropbox已经在成千上万个项目当中使用mypy，而且效果都得到了很好地验证。但对于此次全方位检查Python代码，DropboxDropbox将向大家Python静态检查之旅从最早的学术研究项目，到现在逐步让类型检查与类型提示成为Python社区中众多开发的常规操作。现在，已经有多种工具支持类型检查功能，包括各类IDE与代为什么要进行类型检查如果开发者只使用过动态类型的Python，当然有可能对静态类型以mypy感到陌生。甚至，不少开发者就是因为动态类型而喜欢上Python，往开发经验告诉我们，理解代码内容就成了保障开发工作效率的关键数，或者可能的返回值类型）就会成为一题。以下是几个在缺少类型注释时，开发难以回答的典型问题：这个函数能返回None吗这里的items参数是干什么用的id属性是什么类型：到底是int、str、抑或是自定义类型这个参数需要的是一份、一个元组还是一个组classResource:id:bytesdef

items:Sequence[str])->read_metadata并不会返回Noneitems参数代表一系列字符串，其不可能随意迭代id属性为字节字符完全信任其中的内容例如内容含糊不清或者不够准确，因此带来巨大的虽然Python在项目早期与中期阶段表现良好，但当项目发展到特阶段后，成功的项目与使用Python语言的企业可能一个关键性决定：类似mypy这样的类型检查器主要负责提供用于类型描述的形式语言，当然，除此之外，类型检查器还可带来其它助益类型检查器能够发现许多微妙（以及不那么微妙）的bug。其中的典型例子，就是开发者忘记处理的None值或者其它一些特殊条代码。我们不需要进行100% 即使是在大型项目中，mypy也能够在几分之一秒内完成完整的类型检查。运试通常需要几十秒或者几分钟。类型检查带来的脆弱且难以的单元测试，用以模拟及修复现有代码以获取快以PyCharm以及VisualStudioCode为代表的IDE和编辑器可利用检查工具。当然，像mypy这样的独立工具仍有助于保证注释与启动迁移：性能成为瓶在Dropbox，我们成立了一个三人小队，从2015年底开始研究mypy。成员分别是Guido、GregPrice以及DavidFisher。从那时起，工作开始快速推进。首先，在mypy采用面前的最大就是性能。在将其运行在CPython解释器上，这对于mypy这样的工具来说速度有点不够用。（作为包含JIT编译器的Python替代性方案，PyPy在这方面也幸运的是，我们实现了一系列算法层面的改进。我们采用的第一项都与mypy运行前的状态毫无区别，那我们完全可以使用前一次运行的缓mypy则在此基础上更进一步：如果模块的外部接口没有改变，mypy甚至往涉及mypy的大量迭代运行，用以处理陆续且逐渐细化的类型。最初的mypy运行仍然相当缓慢，这是因为它需要处理大量依赖项。为此，我们实现了缓存。如果mypy检测到本地缓存可能已经过期，mypy将从集中库整个代码库的缓存快照。在此之后，它会以到2016年底，Dropbox公司已经有大约42万行Python完成了类型注释。很多用户都热衷于类型检查，而mypy的使用则在Dropbox各团队期进行用户，借以找出痛点，并确定需要优先考虑的工作（这种直到今天也一直被保持下来）。其中，有两项请求始终最高：更大的类型检查覆盖范围以及更快的mypy运行速度。很明显，我们的性能性能提升方法一：使用mypy守护进增量构建虽然提升了mypy的速度，但仍然没有达到顶峰。大量增量运行可能需要一分钟的处理时长。对于任何面对大型Python代码库的用我们拥有数百个模块，模块相互间接导入。如果导入周期的任何文件发生变更，那么ypy此周期内导入该模块的所有其它模块。其中最臭名昭著的循环就是“纠结（tangle）”，它给Dropbox带来了很烦。其中一度包含有数百个模块，办法即使存在这种“纠结”，我们同样可以提升mypy速度。答案就是，使用mypy守护进程。守护进程是一项服务器进程，负责执行两项非常重首先，它将关于整体代码库的信息保存在内存中，这样每次mypy运函数与其构造之间的细粒度依赖关系。例如，如果函数foo调用函数bar，那么就存在一项从bar到foo的依赖关系。当文件发生变更时，守护外部可见变更，例如变更的函数签名。守护程序所采用的细粒度依赖理机制，能够确保只重新检查实际变更的那些函数换言之，只检查极实现上述目标当然是个巨大的，因为我们最初的mypy实现方案只适合一次处理一个文件。但在实际需求发生变化之后例如当某个类性能提升方法二：将Python配合之前提到的缓存，mypy守护进程几乎完全解决了增量类用性能表现仍然远未达到最佳状态。进行一次彻底的mypybuild可能需要在现有代码当中添加类型注释，因此情况每周都在。我们的用户渴望因此，我们决定延续mypy立项之初的重要想法将Python编译为C。遗憾的是，Cython（一款现成的Python到C编译器）并不能提供任何显著的加速效果，因此我们决定从零开始编写编译器。由于mypy代码库（使用Python编写）已经全面完成类型注释，因此利用这些注释来各类微基准测试中将性能提升了10倍以上。我们的想法是将Python模块编译为CPythonC扩展模块，并将类型注释转换为运行时类型检查（在运行时中通常被忽略的类型注释，类型检查器使用）。我们开始着手将mypy实现由Python迁移至真正的静态类型语言，这恰好与Python的迁移思路完全匹配。（这种跨语言迁移正成为新的常态，mypy最初由Alore编写，但后来则转换为Java/Python自定义语法的混合体。CPython扩展API的定位，是保持项目整体可管理性的关键所在。我们不需要实现虚拟机或者mypy所需要的任何库。此外，我们仍然可以利用一切原有Python生态系统与工具（例如pytest），并能够在开发期间继续使用经过解释的Python代码，从而实现极快的编辑测试周期且不必这款被我们命名为mypyc的编译器（因为它利用mypy作为前端来执约4倍的运行性能提升。mypyc项目的开发在小团队的推动之下用了大约4个月即告完成，团队成员包括MichaelSullivan、IvanLevkivskyi、HughHan和。很明显，这里的工作量远少于使用C++或者Go完全重写mypy，相关影响也要小得多。我们希望mypyc最终能够被交付至Dropbox的其他工程师手上，供他们编译并加速自己的代码。能工程方法。编译器可以利用快速、低级C构造实现众多操作的加速。例如，对某个已编译函数的调用会被翻译成C函数调用，而后者要比调的CPythonCAPI调用，从而略微提升编译时的调用速度。总而言之，我我们还进行了一系列分析工作，希望了解“慢速操作”中的普遍共性。ypyc为这些操作生成速度更快的C代码，或者利用更快的操作方式重写相关Pyhon代码（有时候确实没什么好办法，只能硬着头皮重写）：检查400万行在完成上述工作后，还一个重要（也是mypy用户中排以实现这项目标：从有机增长，到专注于mypy团队的手动调整，再到静结果就是，我们在最大的Python库（后端代码）中的注释行数在大约三年之内增长至近400万行，这些全都迁移成了静态类型代码。mypy现在支持多种覆盖报告，能够帮助我们轻松相关进度。具体来讲，我们可以报告各类不够明确的类型来源例如在注释中使用的显式、检查的类型，或者未进行类型注释的已导入第库等。为了在Dropbox当中改善类型检查精度，我们还在Python类型库中为不少流行的开源库提供经过针对性改进的类型定义（即stub文件）。我们实现了（并在后续PEP当中标准化了）新的类型系统，旨在为某些惯用的Python模式提供更精确的类型。其中一个典型例子正是TypeDict，其负责提供JSON类字典类型。字典当中包含一组固定的字符统，同时考虑改进对Python数字堆栈的支持能力。以下是Dropbox在提升注释覆盖率时，设定的工作要点补充注释的同时，在新的Python文件中使用类型注释。外展。我们与各团队就mypy进行交流，以帮助他们快速上手这。我们定期进行用户以找到最重要的痛点，并竭尽全力解决这些问题（甚至可以发明一种新的语言来加快mypy的速度性能。我们通过mypy守护程序与mypyc改进了mypy性能（p75获得高达44倍的性能提升），从而减少注释流程中的阻碍，并允编辑器集成。我们为Dropbox流行的各款编辑器提供了mypy运行集成，具体包括PyCharm、Vim以及VSCode等。这使得注第库支持。我们的不少代码都用到了SQLAlchemy，它使的很多动态Python函数无法由PEP484类型进行直接建模。为此，我们制作了一个PEP561stub文件包及一款开源mypy插件以提供经验总结检查400万行代码绝非易事，我们在整个过程中遇到不少挑战，当然也犯过错误。下面，总结经验教训，希望能给大家带来启示文件丢失。起步之初，我们的mypy版本只需处理少量或者说，从未接触过buid之外的一切。在添加第一条注释时，文件被隐式添加到bud当中。如果从bud外部的模块导入任何内容，则会获得Any精度大打折扣，并在迁移早期给我们带来了不少麻烦。虽然现在已经解决了，而且也算是一种典型做法，但在最糟糕的情况下，如果两个孤立的类型检查机制被合并起来，而这两种机制之间又互不兼容，那么我们就必须对注释进行大量更改！回想起来，我们应该尽早将基础库模块添加到ypyuild中。注释遗留代码。在刚刚开始时，我们面对着超过400万行的现有Python代码。很明显，对如此规模的代码进行注释是项浩大的工程。我们编写了一款名为PyAnnotate的工具，它能够在运试的同时收集类型，并根据类型结果类型注释但最终这款工具并没能得到广泛采用。整。我们也考虑过在每一次build测试时对一小部分实时网络请求自动运导入周期。导入周期（也就是「tangle」或者说纠结周期）的存在令mypy提速变得非常。我们还需要努力让mypy支持来自导入周期的各种。我们最近刚刚完成了一个重大项目的重新设计，最终解决了Alore语言。Alore的语法使得导入周期的处理变得更轻松。当然，我们也Python之所以很难搞定导入周期，是因为其语句当中可能指代多种事物。例如，赋值可能实际上定义了一个类型别名，而且mypy在大部分导入周结束从早期原型设计到如今对400万行代码进行类型检查，这是一段漫长的旅程。在过程当中，我们对Python的类型提示进行了标准化，建立起围绕Python类型检查发展出的新兴生态系统、为IDE与编辑器开发出类虽然在Dropbox公司，类型检查已经被视为一项必要工作，但我自己的大型Python项目中使用类型检查，那么现在就是最好的时机而言之，类型检查助Python成长为一款更适合大型项目的出色语言DockervsKubernetes，容器生态圈现状如作者作者对于近两年的容器圈，Kubernetes可以说是主角，其增长速度远超大家预期，毫无争议地赢得了容器化管理和协调的，容器生态圈基本已定。但是容器技术还有不成地方，Kubernetes在全方位上也还有一定难度；整个容器生态市场中，Docker公司的热度已经在慢慢消退，以往的老对手VMware也在进军容器市场，目前容器生态圈和容器技术态势如何，Kubernetes发展良好的趋势下还什么问题？InfoQ借此机会采访了老师为我们解读容器生态圈的现状。Docker前路如Kubernetes已经赢得了容器编排战，越来越多的提供商在拥抱Kubernetes。而2018年3月份，在Docker公司刚满五周岁的时候，创始人Solomon宣布离职，的人开始质疑Docker。但是了，Docker公司才是这些“拥抱Kubernetes的提供商”最具有分量的那位。更何况早在一年前，Solomon就已经开始不负责Docker公司的具体业务了，所以他的离任在公司层面不会产生太多影响。而Solomon此前在DockerCoreOS等竞争对手，也曾一度笼罩在Docker公司赌赢的中。即使到了最后，做出牺牲的只是Swarm等几个具体项目，Docker公司还是完成而另一方面，Docker公司一向擅长的开发者关系工作，依然保持着迫于形势Docker公司目前主要专注于企业服务等更加现实的业务上，一旦有某些公有云厂商回过神来，Docker公司的这部分价值会立即凸显出在技术层面上，containerd项目距离成为Kubernetes下一代默认容器运行时只差了一层窗户纸。LinuxKit项目则成功牵制了Unikernel的崛起势头，还进一步完成了DockeronMac和宿主操作系统封装的重要任务。如果说Docker公司的势头在2015年到2016年期间达到了巅峰，那么现Docker公司的巅峰，已经了现有任何基础设施领域开源公司所能达相比Kubernetes项目的强势崛起等因素，CoreOS公司提前被收购才是目前Docker公司的现实。作为Kubernetes社区的标杆玩家，CoreOS的收购案几乎划定了这一领域并购的天花板。在这样的背景下，Docker公司要突破这个天花板倒不算，但要重现当年微软40亿美金Kubernetes的技术作为基础设施领域的系统软件，工作层级太低是目前Kubernetes在更这就好比在，我们所熟知的基础软件如MapReduce，GFS，Dapper，BigTable，Spanner等都依赖于Borg的存在。Kubernetes的工作层次使得它在的过程中表现出来的侵入性非常强。很难去真正接管用户的基础设施体系来发挥出它的“容器化“能力。另一方面，很多团队（包括很多技术能力很强的团队）在Kubernetes项目的过程中也存在一些误区，比如依然试图按照“试点测试”、“定制开发”、“推广”的思路来在这个开源项目。而实际上，Kubernetes项目的乃在于它鼓励的并不是单纯的“用”，而是深入的“玩”。这也意味着，只有能“玩”好Kubenee，才能真正保证团队在这次容器技术的浪潮中站稳脚跟。事实上，无论 、RedHa、CoreOS，还是，都不是Kubenees的典型用户，但这并不妨碍他们成为这个领域数一数二的“玩家”。这其中的微妙差异，正体现了所谓的基础设施项目的“化”设计思路。Kubnees生态的体量来说，基本上不存在非常的状况。但是如何能够鼓励用户以“白盒”化的方式去“玩好”Kubernetes项目，改变目前用户Kubernetes项目的思路，则是一个非常值得深入探讨的话题。混合云环境不是目前Kubernetes项目的主旋虽然Kubernetes创始人CraigMcLuckie说Kubernetes促成了多云，VMware也已经和Pivotal还有Cloud合作推出了PKS(PivotalContainerService)，可以Kubernetes节点，适合多云环境，但是“跨混合云和多云环境”本质上是与公有云巨头，也就是Kubernetes和CNCF背所以不难理解，混合云的支持还不是当前Kubernetes项目在技术上需要关心的重点。当然，作为一个完全中立的Linux项目，生态参与者们如何将Kubernetes应用在混合云的环境中是一件完全自主的事情。这当然也是Craig为之背书的主要原因：Heptio的解决方案必然是没有厂商所以，在确保用户只vendorlock在