阿里云

2018 财年初为了应答闲鱼业务和技术疾速倒退。闲鱼技术团队在云效核心麻利教练的领导下闲鱼客户端的泳道研发撑持我的项目 kickoff。 确定了端侧的研发模式从“小瀑布模式”到“泳道”继续集成的转变。 确定了端侧2-1-1的外围愿景指标。因为端侧依赖打包，适配验证等必要环节。 指标设置为2-1-7。 即：“2"指的2周的交付周期，85%以上的需要能够在2周内交付；第一个“1”指的是1周的开发周期，85%以上的需要能够在1周内开发实现；第二个“7”指的是7小时的公布前置工夫 - -拉集成代码后能够在7小时内实现公布。确定外围指标很要害，但执行和撑持也同样重要。 咱们做了哪些事件？外围指标 ：“2-1-7” 施行的成果如何呢？下文次要从几个方面介绍： 一、建能力背景：团体 AONE（云效）零碎针对服务端做了比拟多继续集成的撑持，但短少撑持端侧继续集成的撑持零碎，咱们建设了两个平台 fishci，fishgurad。 fishci 次要实现了端代码监控，我的项目打包，测试件触发的能力。fishguard 次要 建设了 测试包，测试机，测试工作和告诉治理的能力。两个平台的设计思路是： - 低投入，围绕外围性能开展，做性能最小汇合。 - 充沛复用已有团体已有中台平台能力。研发无人化理念建设：测试件主动构建，触发运行自动化串联零碎   由此建设了 1 次代码提交（commit，push，merge request ）到实时出端骨干回归测试后果继续集成能力。 同时积淀了整个端侧研发效力和品质的过程数据。 二、建度量指标达成，度量很要害，度量决定了咱们做的事件在指标大方向上是否偏离，间隔指标还有多远。所以对 2-1-7 外围指标做度量之外，咱们还须要合成过程指标。 fishci 和 fishguard 两个平台撑持了端侧的代码变更，编译打包，触发数据，测试件运行数据，积淀在平台的这些数据就具备了版本经营的能力。 技术 PM,PTM，TL 能够通过数据关注版本运行状态，跟踪和做继续的改良。 三、改过程泳道集成研发过程整体图：   研发分支治理：需要关联分支，develop 分支，develop 和 release 治理，合入代码评审卡口。端开发：端架构降级。测试技术：端侧 UI 测试件主动构建和回归，端性能测试自动化，端侧 monkey 自动化触发。流程卡口：需要 aone（云效）治理，新建代码 review 卡口，新建集成品质卡口，发版质量标准，新建性能测试集成卡口。四、版本研发度量数据：（度量数据更新到 3 月份底）1、发版效力和需要吞吐量：发版准时率度量：20/21= 96% 需要吞吐量（按月）： 论断：需要吞度量逐渐晋升。3 月底需要吞吐量达到历史最高。 ---应用合入 develop 分支的分支数度量（每一个分支对应一个 aone（云效）需要编号）     研发耗时： 需要“端”到“端”接手开发到开发测试（自测）工夫即效力数据，（2-1-7）中的 1度量数据：应用泳道第一次 push 代码的工夫---合入 develop 的工夫做度量。 ...

“10个月、15亿营收”，这是路歌网络在新业务卡加优选[1]上获得的问题。反对这一业务开发的是由6名技术和1名产品组成的全新团队，他们与业务人员严密合作，从布局新业务、组建团队，到累计实现15亿销售额，只用了10个月[2]。 依据尼尔森[3]每年公布的冲破翻新报告，统计2012年到2016年寰球上市的2万多种翻新产品，其中只有92个在第一年内销售达到5000万美元（约3.5亿人民币）且次年还能继续。产品从0到1，“10个月，15亿”， 即使放眼寰球这也是一个奇观。 图1：路歌在卡加优选实现了微小的业务胜利 然而，在发展此次业务前，他们正遭逢产品交付和翻新的双重瓶颈。每一到两个月公布一次正式版本，速度、准时性、品质都受到强烈挑战；更蹩脚的是，交付内容满足不了用户和业务的须要，产品研发和业务团队之间互相质疑成为常态，商业化也一再受挫。社会意义微小的公益产品“卡友地带”[4]随时可能被迫敞开，团队前景一片黯淡。 从那时起，我先后以集体和阿里云征询参谋的身份，帮忙路歌设计和施行精益产品交付和翻新体系，并以 Teambition [5] 为工具承载了这一体系。“卡加优选”是它结出的第一个果实。 本篇将讲述“精益交付”的具体实际和落地过程。产品交付和业务翻新都遇到瓶颈时，应该从哪里破局？在路歌，咱们的抉择是：从晋升交付能力开始。因为没有高效交付的反对，再好的业务翻新也难以落地。晋升交付能力也是改善业务和技术团队合作的突破口。 1、交付能力改良从扭转认知开始团队当然晓得晋升交付能力的重要性，为此也做过很多致力，但成果总不现实或者不可继续。这一次不同的是：咱们决定从扭转认知开始，先建设独特的认知，再落地配套的实际。咱们将介绍其中的两个外围认知的扭转。 1.1 认知1：突破效率竖井，从谋求资源效率到优化流动效率产品交付是一个系统工程，须要前后职能的合作，如：业务、产品、开发、运维等合作；同时也须要平行部门的合作，如：前端、后端、中台等的协同。传统产品开发方法，更多关注各个职能和部门的独立改良。 图2：效率竖井是交付效力低改良艰难的深层次起因 上图反映了路歌过后的产品交付情况。每个部门看上去都很忙碌，认为本人的效率很高。它们各自从本人的角度优化。然而，适度的局部优化反而会侵害整体效率。 图中下方的折线反映一个典型需要的交付工夫历程。绿色短线示意需要正在被解决，红色长线示意需要在期待中。后果，理论工作不到两天，交付周期却超过1个月。 这就引出对待效率的两种不同视角。从组织的视角看，各个部门关注本人的 “资源效率”——如资源的使用率、本环节的产出等。从用户和业务的视角，咱们更应该关怀的是价值的 “流动效率”—— 需要的流动过程是否顺畅，需要从输出到交付的过程是否足够快。 在上述情况中，各个部门看上去都很忙碌，资源效率很高；但用户或业务感知到的却是另一回事，需要响应却非常缓慢，流动效率很低。咱们称这一悖论为“效率竖井”。 效率竖井：由适度强调和优化部分的资源效率导致，体现为：各个环节和部门忙碌而“高效”，业务响应速度却很低。 “效率竖井”缩短了交付周期，侵害业务响应能力。更重要的是，它覆盖系统性的问题，妨碍交付效力的改良。事实中，侵害交付效力的往往都是系统性问题，如：公共环境的保护、跨职能的协同、集成和公布的效率、接口的对齐、品质改良等。系统性的问题须要系统性的解决方案，不能靠部分视角和信息来解决。事实上，最固执的问题都不在部分。 “效率竖井”是组织效力低和改良艰难的独特起因。突破效率竖井，是交付效力改良的要害。要想突破效率竖井，咱们就必须转换思路——从谋求“资源效率”，转化以“流动效率”外围，晋升团队继续交付价值的能力。 聚焦流动效率，帮忙组织即时裸露妨碍顺畅流动的问题，如：组织的协同、流程制度、继续交付工程能力、技术和利用架构等，这些往往都波及系统性和深层次的起因。也只有解决深层次的问题，能力真正晋升交付效力。 1.2 认知2：单位工夫无效尝试的次数是业务翻新的“黄金指标”路歌是一家产业互联网公司，主业是支线物流服务。产业的特色决定其产品比纯互联网利用简单；互联网和产业联合的全新模式，决定其不确定性比传统产业高很多。 面对简单和不确定的环境，产品研发团队要具备怎么的能力，能力反对业务翻新呢？咱们认为：“单位工夫内能够进行的无效业务尝试的次数”，这是掂量产品交付对业务翻新反对的黄金指标。 “无效尝试”指通过交付产品失去（Earn）价值或从中学习（Learn）——如：学习用户的实在诉求，学习事实中可行的业务逻辑。咱们称其为Earn or Learn——失去或学到。这才是无效尝试的规范，要让尝试无效，就必须当时定义需要要达成的指标，明确需要设计背地的假如。产品交付后，则要剖析这些指标与假如，即时调整产品设计或商业模式。 创新能力的黄金指标：“单位工夫内能够进行无效业务尝试的次数”，这是掂量产品交付对翻新反对水平的黄金指标，而失去或学到是定义“无效”的规范。 从“单位工夫内的无效尝试的次数”这一指标看，路歌过来的产品交付是有问题的。首先，能尝试的次数太少。一到两个月的版本周期，一年能够尝试的次数不超过10次，对于创始全新商业模式，这是不够的。 相比尝试的次数，有效性问题更大。路歌过来的产品开发模式，更多聚焦性能交付，确定一个商业模式后，就一直的增加性能。两头会有调整，但不足被动和刻意的学习，胜利极大依赖于初始商业模式和产品的设计。 面对高度不确定的业务，再好的翻新想法也必须通过一直迭代能力胜利落地。疏忽这一点，是卡加优选商业化受挫的重要起因。减少“单位工夫无效尝试次数”能力晋升找到成功之路的机会，这是产品技术团队反对业务翻新的必由之路。 2、 团队赋能实际建设独特的认知很重要。但，停留在口头的认知，不会扭转任何货色。要害是如何把它们落地为具体的实际。通过零碎的赋能实际和工具，团队将认知转化为了口头。接下来将介绍其中最外围的3个赋能实际。 2.1 赋能实际1 —— 可视化并治理端到端的价值流动过程“以流动效率为外围，晋升团队的继续交付能力”。为了做到这一点，首先要让团队看到需要的流动过程。 图3：基于 Teambition，可视化端到端产品和业务价值流 咱们做的第一步是可视化价值交付过程，上图是基于 Teambition 工具的可视后果，咱们称之为价值流看板。它与常见的工作看板不同，工作看板更多从资源视角登程，关注每个人在做什么，优化的指标次要是“资源效率”。而价值流看板关注的是端到端的价值流动，优化的指标是“流动效率”。 端到端的价值流可视化必须做到： 价值驱动——每一个流动单元（看板上的卡片）都是体现残缺用户价值的业务需要；前后拉通——可视化的指标是 “端到端”的价值流，前一个端指：从用户问题（或业务构想）的提出开始；后一个端指：到用户问题被解决完结。始于用户、终于用户。 图4：基于 Teambition，可视化端到端产品和业务价值流（放大图） 上图是放大后的 Teambition 截图，它拉通和可视化了端到端的价值流，让团队看到价值流动的整个过程，以及其中的期待、妨碍和积压。有了这一根底，团队能够关注整个流动过程的全局，即时处理过程中的问题。通过全局和零碎的优化，来缩短交付周期和进步价值流动效率。 价值驱动，前后拉通：为改良流动效率，团队首先要可视化端到端的价值过程。其外围是要做到价值驱动——可视化用户价值的流动，前后拉通——可视化从用户问题提出，到解决用户问题的端到端过程。价值驱动，前后拉通，是零碎改良的根底。 团队的业务布局、过程治理和业务反馈等，都是基于价值流发展的。对于具体的操作细节，本文不再开展。感兴趣的同学能够浏览我2017年出版的图书《精益产品开发：准则、办法和施行》[6]。也举荐你点击文末“浏览原文”，看咱们精心制作的《研发效力晋升和麻利施行36计》系列视频[7]。 2.2 赋能实际2 ——管制并行，减速业务需要交付接下来咱们要做的是减速团队交付。 路歌有多条产品线，每个产品线对应3到5个交付团队。交付团队都是全功能的，个别在10人以内，有本人的开发、测试和产品负责人，能够实现端到端的需要交付，包含需要剖析、开发、测试和交付。 图5：从产品线看板到交付看板的分层治理 上图是咱们设计的基于 Teambition 的分层看板机制，它由产品和交付两个档次形成。 ...

导语 忙不完的事件，解不完的bug，每次发版都得个体熬个大通宵。干得多，后果还不好。阿里外部某研发团队就正处在这样的漩涡之中。 在这样的背景下，阿里云效麻利教练团队受邀，和该研发团队一起，通过4个迭代的继续改良，研发效率和品质获得了显著晋升： ·       大幅缩短了需要开发工夫，从一个月变为一周；·       从无可用测试环境到具备稳固的测试环境·       从无自动化测试用例到50%的模块实现测试自动化·       从手工部署到自动化部署 这所有是如何做到的呢？阿里云效麻利教练蔡春华将在本文为你一一道来。 作者介绍： 蔡春华（花名古茹），阿里云效团队麻利教练，阿里百年技术讲师，曾反对阿里平安、阿里中台等多个阿里事业部麻利转型。 浏览本文大略须要10min,倡议珍藏细读。  研发窘境首先咱们理解了该团队的组织构造以及各人员的工作内容。如下图所示。 能够看到，产品、前端 、后盾、测试属于不同的职能部门。这是一个十分广泛的组织模式——职能型组织。 在这样的组织模式中，通常会存在以下问题： ·       工作之间相互依赖，彼此期待；·       职能团队之间的指标不统一；·       需要变动沟通不及时；·       工作实现规范不统一。 其次，集中批量集成公布，工夫紧、效率低。团队的迭代周期个别是一个月，需要从筹备开发到待测试的周期是4周，测试工夫要花掉1天，公布个别都安顿在周五早晨，大概第二天天黑能力发完，整个公布过程齐全靠工程师手工实现。咱们发现测试和公布的工夫绝对集中，工夫紧，而且是齐全手工操作，出错的可能性很高。 最初，测试守护单薄，无奈做到有信念公布。因为产品须要公布到公共云，目前团体没有相应的工具能够帮忙公共云的公布；并且，产品的构建部署过程均无工具反对，须要手工打包和部署。在测试守护方面，有一些遗留的单元测试，然而这些单元测试基本就无奈运行起来；而集成测试的运行的用例数根本为零，尽管有同学致力在加新的用例，但目前这些用例还无奈运行，整个测试守护过程十分单薄。 这么多的问题，该从哪里动手解决呢？上面分享一下咱们的4个迭代措施。 迭代 1 ：可视化研发工作，寻找问题的关键点通过跟团队的沟通，咱们发现团队同学其实曾经或多或少地意识到了这些问题，并且他们也做了一些改良的尝试，然而因为各种起因没有继续下去，导致团队当初对扭转没有什么信念。 在这样的状况下，须要在尽量少扭转团队现状的状况下，去获得一个比拟好的成果。 要解决问题，必须让大家可能站在全局的视角来剖析现状，从而找到外围问题。因而，咱们通过可视化物理板以及站会，把研发团队的工作进行了可视化。 1.1 利用可视化物理板与站会，通明团队工作初期的可视化板，次要是展现出团队以后迭代要做的工作以及每天呈现的问题。过程中对物理板的规定并未做太多束缚，次要起到可视化的作用。这样一方面升高了可视化工作的门槛，让大家违心应用，另一方面，能把大家最实在的工作情况给反映进去，如下图所示：  物理板展现的同时，配置了每日固定站会，工夫管制15分钟，要求产品、前端、后端开发、测试一起参加。每人轮流对所有人通明每天实现的工作、接下来要实现的工作、遇到的问题。 1.2 通过可视化物理板，裸露团队的测试瓶颈物理板与每日站会，很清晰地展示了以后迭代须要实现的工作，团队在须要实现的指标基本上达成统一。并且在每日站会的过程中，因为每日一直须要沟通的需要，团队能及时调整并更明确研发流程布局。 同时咱们发现，在我的项目初始阶段，简直所有的需要在同一期间投入到了开发中；大概在中期时，有很多工作缓缓地移到了自测阶段，但并没有需要能够移到待测试阶段；直到邻近发版前1-2天，大部份需要才一起移到了待测试。整个过程中，测试同学除了理解以后筹备开始的工作以及筹备测试用例外，始终在期待测试工作中。如下图所示。   为什么测试同学每天都在期待承受新的工作需要，但总没有需要能够提测呢？在离发版的前1天，研发才提测。对测试来说，测试工夫很紧迫，验证进去的bug也来不及修，这就会造成上线后依然须要有一周工夫来修复bug。 通过可视化物理板，研发团队很快明确了测试瓶颈的起因——咱们是不是能够尽快让测试参加工作呢？ 迭代 2 ：正当拆分需要，让需要变小、独立、可测试如何让测试尽快参加工作呢？咱们发现，需要之所以无奈进行测试，是因为需要的各个子工作与其余需要之间的子工作相互依赖造成的，多个需要之间耦合在一起，互相期待。其后果就是，所有需要都得一起开发实现能力测试。为什么它们会耦合在一起呢？ 咱们发现，以后的需要拆分形式是以组件或模块来进行拆分的。例如，一个需要，首先从实现的角度，把它按模块拆分成多个需要，对模块的实现，再对该模块需要拆分成若干个工作。 然而，从测试的角度来看，需要应该是端到端可测的，这样拆分进去的模块需要不能独立测试，它仅局限在这个模块的范畴。 那么如何无效地来拆分需要呢？ 2.1 从业务指标登程，由外而内逐渐拆分需要什么是无效的需要拆分呢？需要拆分完之后，它必须还是需要，它必须要： ·       足够小：这样能力做到可继续交付；·       端到端：这样能力保障交付有意义的价值；·       独立性：便于继续集成和灵便安顿；·       整体性：拆分完仍能看到整体的构造。 要做到无效的需要拆分，须要： 1.廓清指标：需要相干方要独特了解需要的背景，为什么要做需要的起因； 2.梳理需要上下文及用户的应用场景； 3.列出用户操作及操作步骤。 咱们能够从一个具体的例子来理解整个拆分的过程。 需要形容：组件商业化 需要背景：某组件须要接入到E产品,以按量计费的模式提供服务，并通过阿里云对立按流量免费；组件接入到E产品后，用户通过拜访产品页面开明/暂停/应用组件 如果咱们依照下面形容的办法进行拆分的话，应该： （1）廓清指标 组件要从收费的模式转变为按量计费的模式。组件要用对立的接入形式；用户在产品页面上能够看到曾经接入的组件，在页面上开明/暂停组件，产生的费用，通过阿里云来进行计费并反馈给用户。当用户欠费时，该组件间接暂停应用，提醒用户进行缴费。 （2）列出上下文及用户应用场景 （3）列出用户操作及操作步骤   （4）按用户端到端的应用拆分为4个需要： ·       组件胜利接入到产品，能在产品上展现；·       用户能通过产品查看曾经接入的组件；·       用户能应用组件性能，能依据应用数据提醒已应用金额；·       用户如已欠费，无奈应用组件性能。 其中，组件胜利接入到产品须要依赖组件方技术改造，也是后续几个需要的依赖，因而这个需要为其余需要的依赖，须要最高优先级需要。 在整个拆分的过程，其实是需要从指标登程，逐层廓清剖析的过程，需要拆分并不间接产生价值，产生价值的是需要剖析自身，而需要拆分是需要剖析的副产品。 当需要拆分实现之后，如何让需要顺畅流动起来，继续开发呢？ 2.2 欠缺看板规定，前后职能拉通，工作左右对齐需要除了是交付的单元，同样也是沟通的载体。在整个端到端的交付过程中，通过无效拆分的需要，能够更便捷地进行合作，与此同时，看板的设计也须要做出相应的调整。 （1）明确需要准入规定 进入开发就绪前，必须进行需要拆分，并且明确验收规范，否则不能进入开发。每个需要拆分后的工作量大小不应超过1周，对应需要的每个工作工作量不应超过1天。 （2）前后职能拉通，工作左右对齐 通过看板，出现需要端到端的交付过程，各职能以需要顺畅流动为独特指标，从需要层面拉通各职能之间的合作。同样，在需要的开发阶段，分解成不同的工作列，同一需要的各工作被安顿在同一泳道（行）上，做到工作在需要层面的对齐。如下图所示。    采纳新实际的团队，需要做到了无效拆分，提前一周实现了所有需要的开发以及测试验证工作，上线后缺点比以往显著缩小。而未做扭转的团队，在公布前一天，依然有代码未合并。 正当的需要拆分，使得继续测试成为可能。当初因为测试工作变得日常化，基本上迭代开始一周后就有需要进入提测，而这时，却没有一个与线上相一致的测试环境。那么环境就成为了以后团队的一个重要瓶颈。 迭代 3 ：构建测试环境，复原端到端继续测试要做到继续测试，须要与之相匹配的测试环境。咱们发现测试环境次要存在以下这些问题： ·       测试环境中，服务组件之间的依赖多，筹备一套环境让这些组件全副跑通不容易；·       某些内部依赖无奈搭建线下环境；·       整个构建部署全由研发手动操作，短少环境监控的无效伎俩；·       测试环境服务器部在售卖区，与阿里外部不能互通拜访。  ...

编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实际指南》，扫描上方二维码或返回：https://developer.aliyun.com/...，下载完整版电子书，理解阿里十年DevOps实践经验。 阿里巴巴的运维团队致力于打造无人值守的运维平台，用智能化推动高效率、低成本的利用运维。智能运维是运维平台实现信息化和数字化之后的天然倒退，利用扎实的技术根底，把机器学习、优化算法和各个业余畛域方面的常识完满联合起来，针对具体运维场景提供令人满意的解决方案。 智能运维（ AIOps ）是依靠于阿里巴巴 DevOps 教训积淀而来的智能化运维平台，通过运维大数据的积攒，以及算法团队多种算法的校对，咱们将运维晋升到新的高度，通过 AI 来帮咱们查看数据、判断异样、决策运维操作，造成监、管、控一体化的运维平台。 运维体系面临的挑战DevOps 运维时代，阿里巴巴运维体系面临如下挑战： 第一，规模化。阿里巴巴的基础设施规模呈指数级增长，在服务器数量是千级别、万级别的时候还勉强能够通过人为操作来运维，但倒退到百万级别的时候，任何一个步骤依赖纯人为操作都是不事实的。服务器规模百万级的时候，如何保障整体运维平安、高效的进行是第一个挑战。 第二，高简单。阿里巴巴业务的多样性及高速倒退也对系统稳定性提出了更高的要求，对运维体系带来更大的挑战。已经咱们考核零碎可用率 7 个 9，存储方面达到 6 个 9 就很好，然而盒马鲜生这样的业务是要求 100%可用。作为线下业务，在盒马店有半小时不能领取是无奈承受。咱们要从全链路视角登程，关注每个环节的稳定性建设。 第三，老本优化。老本是门槛，做不到肯定的门槛，进入这个市场的机会都没有。除了固定资产投入，经营老本也是很重要的一部分。利用技术进行流程优化，升高各个局部的老本，是进步业务的外围竞争力的要害。 第四，平安。云计算最关怀的是平安。零碎越来越大，变动越来越快，所面临的外部和内部的危险也越来越大。每天有数变更降级同时进行，如何在零碎变更时保持稳定，是须要面对的另一个微小挑战。 阿里巴巴基础设施的体量和复杂性，显然都超过了人脑的解决能力，须要从新的视角，利用机器智能来解决这些简单的问题。 智能运维实际基于下面的挑战，咱们在阿里巴巴团体各个业务场景落地了无人值守公布、无人染指运维的解决方案。 无人值守公布 (Unmanned Deploy)全新一代公布平台反对滚动、蓝绿、金丝雀等多种公布模式。通过算法，机器学习办法对利用公布过程进行异样检测，从而防止因为代码变更导致的故障。基于大量监控数据、日志数据的积攒，并有算法的加持，咱们推出了无人值守公布零碎。 无人值守公布 riskfree 零碎上线以来，从摸索到实现再到优化经验了将近三年的工夫。目前业务范围定义在利用公布时故障预防。接入无人值守公布的利用在提交公布单后，零碎会对整个公布过程中的监控数据进行剖析，如果有异样会主动暂停公布，并提醒异样指标和拦挡起因，开发确认有问题则能够抉择敞开或回滚，没有问题则持续公布。 线上公布之痛 以往线上公布的时候，工程师们个别做了如下“精心”工作： 公布前测试人员对代码进行全方位的单元测试、集成测试，如果发现 Bug，会让开发人员返工。这里有两个问题：第一，有些业务团队因为人员问题，基本就没有测试人员，本人既是开发也是测试；第二，不是所有的 Bug 都能通过测试发现，不免有漏网之鱼。公布中进行预发、灰度、分批公布、金丝雀公布。在每一个环境迟缓公布过程中，要到监控平台，查看各个监控，甚至登录到机器上“刷”日志，通过本人的“火眼金睛”，冀望能在泛滥的日志中，找到某个非凡模式的异样日志；另外，如果是多方依赖的利用，还要查看上下游的利用监控有没有问题。公布后检查一下利用的机器是否都失常启动，将失败的机器下线或者置换掉，看看故障零碎有没有报警，看看上下游团队有没有“叫”起来，如果有，得马上回滚。总之，这个过程是既耗时又耗力，而且还不能保障没有漏掉一处细节，并且不同公布人员的教训不一样，生手和老手对一个公布的稳定性保障水平有微小差异。咱们的解法 咱们设计了一套无人值守公布零碎 零碎分为两大部分： 在线剖析，无人值守公布零碎会对系统监控、业务监控、日志监控、调用链路等维度进行异样检测，检测到异样后，会对公布单进行拦挡或回滚。当用户认为无异样时，会进行反馈，持续公布。离线剖析，在第一步中用户反馈后，这个反馈数据对咱们的算法十分有用，能够对咱们的算法进行主动的调整。当反馈数据积攒一段时间之后，异样检测的准确率就十分高。算法平台 在公布的过程中，零碎会采集各个监控源的数据，对数据的采集、荡涤、存储要求很高，咱们设计了算法平台来承接各个平台的数据源、算法检测、算法验证、算法上线等流程，零碎架构如下图所示。 次要蕴含三大部分： 数据采集存储：对各个监控数据源的数据进行采集，蕴含系统监控、业务监控、中间件监控、日志监控、数据库监控、云监控等。数据采集后，依据不同数据的个性，存在时序数据库或者关系数据库中。算法后果存储：对于每次检测的后果都会进行存储，以不便后果排查和成果评估。数据打标：对每次异样检测后果，都能够打标，利用打标数据来从新训练算法，造成正向循环，检测的后果也能够通过邮件、钉钉实时告诉给发布者，且能够主动对接后面介绍的运维编排自愈流程，比方，将异样的机器间接主动置换掉。 智能算法 在下面的算法平台中，咱们设计了泛滥异样检测算法。异样检测在无人值守公布零碎中有着无足轻重的位置，次要分为三个局部： 数据采集：咱们综合了各个维度的监控数据、调用链路剖析等，在观测的广度上是人工盯屏所不能相比的。异样检测：咱们精心调校的异样检测算法，齐全不依赖于传统的基于阈值、3Sigma 等检测算法，全副主动断定，泛化能力好，反对单指标检测、多指标检测、前后比照检测、已公布未公布比照检测等多种模式，检测算法蕴含 ArimaKSigma、BoxplotDetect 办法（Tukey 办法）、GrubbsTest 办法、Donat 等。排除失常稳定：通过历史数据、用户反馈数据，精准过滤失常的稳定，让用户失去精准的异样检测后果，示意图如下： 实际成果 无人值守公布自上线以来，笼罩了阿里巴巴团体所有的利用公布过程，为公布的平安稳固保驾护航，异样检测后果如下图所示： 至此，接入无人值守公布后，开发能够在点击公布后专一别的事件，不须要时时关注公布过程。如果公布过程出现异常，零碎会通过钉钉音讯、邮件告诉到开发，再染指即可，如果过程是机器异样则主动替换异样机器，开发无需人工染指，公布将持续。 简略总结一下，无人值守公布是一个智能化变更故障检测和异样举荐零碎。通过对变更执行过程中的多维度监控数据进行剖析，判断以后变更是否会造成故障，在公布出现异常的状况下进行拦挡和智能举荐。 无人染指运维-ChatOps (Unmanned Operations)日常运维有很多类别，目前咱们专一于其中两类运维工作的“无人染指”：1. 用户接到告警或事件而发动的运维操作；2. 日常运维答疑或征询。 针对第一种状况，通过“运维诊断”，给利用来一次 360 度全方位“体检”，找到异样点并一键修复；针对第二种状况咱们公布了 ChatOps 机器人来增强 DevOps 之间沟通与单干，帮忙研发实现一些“脏活”、“累活”、“机械式”工作，指标是达到“0”人工染指的征询和答疑。 ...

编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实际指南》，扫描上方二维码或返回：https://developer.aliyun.com/...，下载完整版电子书，理解阿里十年DevOps实践经验。 DevOps 谋求更短的迭代周期、更高频的公布。但公布的次数越多，引入故障的可能性就越大。更多的故障将会升高服务的可用性，进而影响到客户体验。所以，为了保障服务质量，守好公布这个最初一道关，阿里逐渐倒退出了适应 DevOps 要求的公布策略。 在开始讲述阿里的实际之前，咱们先简略介绍下几种常见公布策略, 以及它们实用的场景和优缺点。 常见公布策略停机公布停机发布会在公布以前敞开服务，进行用户拜访，而后一次性的降级所有服务。这种公布策略的公布频率往往比拟低，且须要在公布之前做好短缺的测试。 停机公布的特点有： 所有须要降级的组件被整合到一次公布中一个我的项目中的大部分利用都会被更新公布之前的研发流程和测试流程往往须要花很长的工夫公布时如果呈现问题, 修复和回滚的老本很高实现一次停机公布, 须要破费很久的工夫, 且须要很多团队在一起能力实现往往须要客户端和服务器端同步降级停机公布并不适宜互联网公司，因为两次公布的距离很久，从性能个性提出到进入市场的工夫太长，对市场反馈不敏感，会在充沛竞争的市场里处于下风。每次公布因为要停机，也会带来经济损失。劣势： 简略, 不太须要思考新旧版本共存时的兼容性问题 劣势： 公布过程中，服务不可用只能在业务低峰期 (往往是夜间)公布，并且须要很多团队在一起工作呈现故障后很难回滚 适宜场景： 开发测试环境非关键利用，用户影响面小兼容性比拟难管控的场景金丝雀公布金丝雀公布这个术语源自 20 世纪初期，过后英国的煤矿工人在下井采矿之前，会把笼养的金丝雀携带到矿井中，如果矿井中一氧化碳等有毒气体的浓度过高，在影响矿工之前，金丝雀相比人类体现的更加敏感疾速，金丝雀中毒之后，煤矿工人就晓得该立即撤退。金丝雀公布是在将整个软件的新版本公布给所有用户之前，先公布给局部用户，用实在的客户流量来测试，以保障软件不会呈现重大问题，升高公布危险。 在实践中，金丝雀公布个别会先公布到一个小比例的机器，比方 2% 的服务器做流量验证，而后从中疾速取得反馈，依据反馈决定是扩充公布还是回滚。金丝雀公布通常会联合监控零碎，通过监控指标，察看金丝雀机器的健康状况。如果金丝雀测试通过，则把残余的机器全副升级成新版本，否者回滚代码。 劣势： 对用户体验影响较小，在金丝雀公布过程中，只有大量用户会受影响公布平安可能失去保障劣势： 金丝雀的机器数量比拟少, 有一些问题并不可能裸露进去实用场景： 监控比拟齐备且与公布系统集成灰度/滚动公布灰度公布是金丝雀公布的延长，是将公布分成不同的阶段/批次，每个阶段/批次的用户数量逐级减少。如果新版本在以后阶段没有发现问题，就再减少用户数量进入下一个阶段，直至扩大到全副用户。 灰度公布能够减小公布危险, 是一种零宕机工夫的公布策略。它通过切换线上并存版本之间的路由权重，逐渐从一个版本切换为另一个版本。整个公布过程会继续比拟长的工夫, 在这段时间内, 新旧代码共存, 所以在开发过程中, 须要思考版本之间的兼容性, 新旧代码共存不能影响性能可用性和用户体验。当新版本代码呈现问题时, 灰度公布可能比拟快的回滚到老版本的代码上。 联合个性开关等技术，灰度公布能够实现更简单灵便的公布策略。 劣势： 用户体验影响比拟小, 不须要停机公布可能管制公布危险劣势： 公布工夫会比拟长须要简单的公布零碎和负载均衡器须要思考新旧版本共存时的兼容性实用场景： 适宜可用性较高的生产环境公布蓝绿公布蓝绿部署是指有两个完全相同的、相互独立的生产环境，一个叫做“蓝环境”，一个叫做“绿环境”。其中，绿环境是用户正在应用的生产环境。当要部署一个新版本的时候，先把这个新版本部署到蓝环境中，而后在蓝环境中运行冒烟测试，以查看新版本是否失常工作。如果测试通过，公布零碎更新路由配置，将用户流量从绿环境导向蓝环境，蓝环境就变成了生产环境。这种切换通常在一秒钟之内就能搞定。如果出了问题，把路由切回到绿环境上，再在蓝环境中调试，找到问题的起因。因而，蓝绿部署能够做到仅仅一次切换，立即就向所有用户推出新版本，新性能对所有用户立即失效可见。 劣势： 降级切换和回退速度十分快零停机工夫有余： 一次性的全量切换, 如果公布呈现问题, 会对用户产生比拟大的影响须要两倍的机器资源须要中间件和利用本身反对热备集群的流量切换实用场景： 机器资源比拟充裕或者按需分配 (背靠云厂商)A/B 测试A/B 测试和灰度公布十分像，能够从公布的目标上进行辨别。AB 测试偏重的是依据 A 版本和 B 版本的差别进行决策，最终抉择一个版本进行部署。和灰度公布相比，AB 测试更偏向于去决策，和金丝雀公布相比，AB 测试在权重和流量的切换上更灵便。 举个例子，某性能有两个实现版本 A 和 B，通过细粒度的流量管制，把 50% 的用户总是疏导到 A 实现上，把剩下的 50% 用户总是疏导到 B 实现上，通过比拟 A 实现和 B 实现的转化率，最终抉择转化率较高的 A 实现作为性能的最终版本。 ...

编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实际指南》，扫描上方二维码或返回：https://developer.aliyun.com/...，下载完整版电子书，理解阿里十年DevOps实践经验。 让咱们进入到阿里巴巴在交付阶段的一些实际，包含： 以利用和变更为外围的交付流程基于变更的查看项和卡点针对利用特征选择研发模式利用与变更进入到具体的实际之前，咱们先介绍下阿里巴巴的利用和变更模型。 利用，是研发流动的载体，包含了代码库、部署环境、配置项、变更治理、公布流水线、运维等一系列因素。整个需要的开发交付过程都能够在利用中实现。利用上能够设置不同的角色，这些角色信息在研发的各个环节中会起到作用。比方谁能公布线上环境，谁有权限批改测试配置等。 变更，作为利用的重要组成部分，是一个形象的概念。所有对线上的行为的批改都能够称之为变更，变更属于某一个利用。变更中能够蕴含一个或者多个不同类型的变更内容，最常见的变更内容类型就是代码变更。 变更有相应的生命周期，一个典型的变更生命周期为：开发中->公布中->实现。当一个利用有多个变更同时在开发和公布时，须要有肯定的协调机制，比方是在一个长期的集成分支上进行集成，还是在一个常驻的 develop 分支上进行集成。咱们称这种分支合作模式为“研发模式”。 创立变更通常是为了实现需求和修复缺点。一个需要可能须要批改多个利用，也就是须要在多个利用上创立变更，而简略的缺点修复可能批改一个利用就能够解决问题，也就是一个变更。所以工作项（需要和 bug）和变更是一对多的关系。 咱们从两个视角来看一下： 利用部署视角：每次利用部署上线会蕴含一个或者多个该利用的变更，可能波及多个工作项。工作项公布视角：一个工作项的公布可能须要多个利用的先后部署。这两个视角是有穿插的。作为平台和工具，应该更关注哪个视角呢？如果偏利用，则要实现一个工作项的公布，开发团队须要自行协调多个利用的部署程序，会产生肯定的沟通老本。如果偏工作项，则会呈现一个工作项的一组变更在部署某个验收环境，其余的工作项的变更须要期待，影响了整体交付吞吐率。如果想要兼顾这两个视角，则不可避免的须要应用大版本制，或者叫火车制，拉长了单工作项的交付周期。阿里巴巴的 DevOps 工具抉择偏利用的视角，次要保障单个利用的部署上线流程和品质，将部署的节奏交给开发团队灵便安顿。 比方一个工作项的公布波及三个利用的三个变更，这个工作项的开发能够抉择在周一部署第一个变更，周二部署第二个变更，而这两个变更不会造成任何线上可见的批改；到了周四，产品心愿该性能上线时，再部署第三个变更，需要正式公布。这种将部署利用行为与公布性能行为拆散的模式，能够升高集中部署带来的危险。当然可能这样做的前提是须要有比较完善的自动化品质保障及卡点机制。 基于变更的查看项和卡点变更是交付的载体，因而能够通过在变更上承载查看项来保障交付品质。最常见的查看项包含： 是否通过代码评审是否通过平安扫描是否通过单元测试/UI 测试基于这些查看项会进行品质卡点，个别在如下的生命周期节点上： 从开发中进入公布中：须要满足肯定的质量标准（比方单元测试通过率，覆盖率等）之后，才容许进入到公布中的状态，能进入测试环境进行验证。公布到某个环境上：这时变更曾经进入了集成流水线，实现了构建等，但如果要持续部署到某个环境，须要满足更多的验证条件。比方平安审核须要通过，能力公布正式等。至于在哪些节点设置哪些卡点，利用负责人能够自行决定。多个查看项倡议尽早同时开始，以提高效率。 从另一个角度来看，公布平台也能够对所有利用进行全局的卡点设置，针对某些卡点主动开启，且不容许勾销。比方扫描到你的代码中依赖了有平安问题的 JAR 包，则要求必须进行修复，否则无奈部署上线。这样就能够管制一些全局性的危险。 变更和利用中的公布流水线，提供了一个进行检查和卡点的框架。具体的查看工作由其它的专门的平台提供，比方测试平台、平安扫描平台、与特定业务相干的合规扫描等。 研发模式如前文提到，为了可能让一个利用的多个变更协同开发和公布，咱们须要采纳不同的研发模式。研发模式的次要差异在分支合并策略，目前阿里巴巴次要采纳上面三种研发模式： 骨干模式Aone-Flow 分支模式Git Flow 模式利用有大有小，在其上进行需要开发的并行度也不雷同。 阿里巴巴有大量的的利用没有并行进行的变更公布。这类利用适宜应用骨干模式或者 Git Flow 模式。也有一些利用变更的并发度比拟高，会呈现一些公布节奏不同的问题。业界个别应用性能开关的形式解决这个问题。阿里外部采纳名为 Aone-Flow 的分支模式来解决。 在 Aone-Flow 的分支模式下，开发人员的典型工作流程为： 提交变更，Aone-Flow 会创立一个集成分支，或者复用已有分支，主动将你的变更合并到这个集成分支。当你发现你的变更有问题不能公布，能够“退出公布”，Aone-Flow 会主动创立一个新的集成分支，把残余的须要持续公布的变更再合并进去。当集成分支实现正式部署之后，会合并到 master 骨干上。这个集成分支上的变更都会被标记“已实现”，并打上 Git Tag。当须要回滚时，能够依据零碎的记录同时将线上的版本和代码一起回滚掉（git revert）。避免出现无心把有问题的 master 代码公布上线的状况。 对于 Aone-Flow 的详细描述能够参看：https://www.infoq.cn/article/EaC4c6yiJrzZ_Gtaf9Ne 这里仅就骨干模式和 Aone-Flow 进行一个简略的比照。 能够看到骨干模式和 Aone-Flow 各有利弊。在阿里巴巴，为了可能更加疾速独立的交付个性，有一多半的团队采纳了 Aone-Flow。 总结理解了上述的过程，以 Aone-Flow 为例，咱们对一个需要的上线过程要通过的阶段进行一个图解： 这里只画了日常、预发和正式三个环境，在理论的流程中，还会有灰度，平安生产环境等，来尽量避免呈现线上问题和故障。 另外在变更的开发阶段，阿里外部还采纳了一些隔离测试环境的技术来帮忙开发者进行个性级别的隔离测试联调，详见前序的隔离测试环境章节。通过上述的管控和流程，咱们就失去一个比拟平安的需要交付流程。 【对于云效】 ...

编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实际指南》，扫描上方二维码或返回：https://developer.aliyun.com/...，下载完整版电子书，理解阿里十年DevOps实践经验。 为保障软件交付的品质，咱们对交付物有性能和性能上的要求。这些要求体现在交付过程中产生的数据上，包含：代码评审数据、平安扫描数据、回归测试后果等。这些数据以交付物（制品）为载体。咱们把这些数据称作制品的元数据。 什么是元数据?元数据指一经产生就不会变动的数据。元数据是由零碎产生，具备不可篡改和可回溯的特点，因此成为公布过程中的必要根底数据。 元数据为何重要?为阐明元数据的重要性，先举个例子。阿里中台利用在架构上依赖很多业务团队的二方包，这些二方包品质往往难以把控。那怎么来解决呢? 一种改良办法就是从单个利用维度，到利用依赖树维度更”全景”更”平面”展现数据。以代码评审为例，在中台利用的制品中，蕴含很多业务团队开发的二方包。而在评审中台利用时，只会看到 pom 文件中的二方包的版本号变了，看不到具体的代码变动。对于评审者，须要看到这些版本号背地的代码变动，以及与这些代码变动相干的信息，如相干的需要、有没有通过代码检测、单元测试后果等。 一个利用运行时的依赖大部分在构建时就决定了。运行时问题很多是由依赖引起的。让构建依赖(树)产生新价值，从而实现危险左移。 元数据次要有哪些?除了在构建阶段取到的依赖树，咱们还有其它数据，如测试产生的品质数据，平安扫描产生的平安数据。这些数据咱们都会寄存到"元数据中心"，再通过"管控策略核心"，利用这些数据对交付过程做自动化的卡点。这一流程通常包含可见、可控、可信三个阶段。 "可见"是给用户展示元数据中心的数据，给用户透出交付过程的危险与瓶颈。"可控"是给用户依据看到的问题后，再设置规定来实现自动化检测与门禁。"可信"则是联合"合规平安扫描服务"与"制品仓库"能力，实现数据与规定的交融，实现交付平安。从可见到可控，再到可信，最初达到晋升交付效率的指标。与此同时，元数据与规定一直演进，缓缓积淀成知识库，成为公司最重要的资产之一。 上图展现了可信公布的架构，能够看到可信公布以元数据为核心，基于制品，继续生产和生产元数据，配合各类自动化的门禁规定，做到继续、牢靠、平安地公布。 元数据分为两类：包自身的元数据、包的血缘关系数据。 包自身的元数据包自身的元数据包含包的根本信息，如：构建信息、品质数据、平安扫描数据等。除了这些根本信息外，还包含通过元数据协定写入的三方数据。 评分体系一个制品，如一本书或一部电影一样，能够评分。以二方库 jar 包为例，评分能够领导 jar 包的"应用方"援用最佳品质版本的 jar 包。 评分包含：1. 零碎评分，2. 用户评分。评分是针对制品的某个版本的。 其中，零碎评分满分 10 分，次要依据以下几点来判断： 是否合乎代码规约，每有一条不满足就扣一分;是否合乎外围指标，每有一条不满足就扣一分;是否通过官网平台公布，如不是，间接扣分；是否有安全漏洞，如有，则扣分；运行时的动静指标，如启动耗时，启动时内存耗费等；业务测试用例指标，如单元测试覆盖率/成功率；被援用数，肯定时间段被越多的利用应用，会加分。用户评分是开发者对这个制品的评估，某些制品零碎评分很高，然而接口设计不合理，依赖多，应用方能够给较低的用户评分，推动制品的继续改良。 血缘关系的元数据一个大制品，是由多个小制品组成的。制品与制品存在依赖与组合等多种关系。制品的血缘关系，也就是制品的依赖数，评分高的依赖版本会被举荐应用。 元数据如何无效应用?元数据除了在交付流程中用于各节点的准入与准出外，还能够帮忙进行制品治理。制品治理基于元数据的“洞察”和“态势”两大能力。 洞察：通知团队主管如何治理，帮忙团队主管找到哪些制品，或哪些本人的子团队须要优先治理。态势：通过治理后，制品品质的趋势是什么样的，帮忙团队主管看治理力度与治理成果。以 jar 包(二方包)治理为例。 洞察二方包外围指标包含：依赖深度，依赖总数，版本总数。团队主管能够在"洞察报表"中抉择本人的团队，找到最须要优化的二方包，进行针对性重点优化。 如何抉择"三高"对象重点治理对象个别是"三高"对象，即依赖深度等级过高，依赖总数等级过高，版本总数等级过高的二方包。如下图中，"com.taod:feent"是典型的三高对象，须要优先，重点治理。 如何找到"首恶"因依赖深度，依赖总数是对 GA 最初一个 release 版本且有被利用依赖的二方包，所以要抉择合乎这条件的二方包版本，如下图: 接下来，咱们查看"依赖树详情"，再剖析，因为有可能本人的二方包也是因为援用了一个"三高"二方包，而导致本人"三高"的，在"依赖树详情"中，就能够找到它，而它可能就是"首恶"。 在找到"首恶"后，个别这样解决: 分割"首恶"二方包的负责同学，进行优化。先去掉它的一些没应用到的间接依赖。 态势态势报表次要体现以下两个方面: 如对制品没治理，那包含危险等品质问题会如何好转? 如对制品进行了治理，那治理的成果如何。如成果不好，则再引申出是治理的办法有问题，还是治理的力度不够? 元数据在继续交付流程中的利用咱们会依据历史呈现过的故障，及平安、测试品质等要求，对一次公布中的制品及它的依赖进行扫描。并基于制品的元数据分析，将公布的危险进行分类，并提醒用户如何修复。 危险等级危险依照重大等级分为高危、中危和低危，其中高危和中危须要重点关注。等级定义如下： 高危 本地公布的 snapshot 更新release 版本号升高新增的 release 包有依赖 snapshot  蕴含有 x86 的 so 的 jar 包用于非 x86 的服务器上中危 ...

编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实际指南》，扫描上方二维码或返回：https://developer.aliyun.com/...，下载完整版电子书，理解阿里十年DevOps实践经验。 构建是将源码变成制品的过程。构建包含编译，但不等同于编译。即便对于不须要编译的解释型语言，也要构建成一个压缩包或 Docker 镜像再去部署。无论是在开发阶段还是 CICD 阶段，都离不开构建过程，构建的品质和效率对继续交付影响很大。影响构建效率的因素，包含源码以及构建的依赖。 背景在阿里巴巴，Java 是被最多人应用的编程语言。在 Java 的构建工具中，因为迁徙老本，生态等起因，Maven 始终是服务端利用的最次要构建工具。 Maven 构建性能问题次要有二方面起因。一是外因，从利用角度看，一些 Java 利用历史悠久，依赖一直减少，并因为清理有危险导致累积太多，典型利用有 3000 个 Jar 包依赖，而且这些利用研发人员多，且是跨团队的，导致依赖治理老本高，依赖变得复杂凌乱。二是内因，从 Maven 自身来看，它对简单依赖的解决思考欠妥。 对于外因，须要业务团队建设依赖梳理管理机制。针对内因，咱们对 Maven 进行了从新实现，推出了 AMaven。 另一方面，阿里巴巴有 15%的 C/C++利用。C/C++利用与 Java 的最大区别是：Java 利用构建次数频繁，但每次构建工夫短；C/C++利用构建次数少，但一次构建工夫长。如某些软件的构建长达 10 多个小时。所以C/C++开发同学的痛点，除了构建慢外，最不能忍耐的还是等了 10 多个小时，最初几分钟竟然构建失败了。 那为什么 C/C++构建慢且容易失败呢? 起因次要有两个： 现有框架无奈保障 C/C++编译和链接的严谨性，导致编译后果不确定，运行时也不稳固。举个例子，在编译阶段，同名的头文件在不同工夫或不同机器上会可能内容不同，所以编译容易失败。公司内编译框架泛滥，有 scons，cmake 等，造成团队之间业务转接老本高，编译问题排查老本高。从平台角度看，也无奈触达用户真正的编译逻辑，无奈对立性能调优，更进一步无奈对立降级底层编译器 gcc，即无奈享受新技术红利。所以构建慢。相比 AMaven 是从新实现底层构建工具的 Maven，在 C/C++畛域咱们次要是建设下层的编译框架，推出了 Alimake，因为底层的 make 曾经很优良了。 接下来，咱们具体来看看 AMaven 和 Alimake。 计划AMavenMaven 构建带来的性能问题，会重大影响继续交付的效率。次要体现在以下几点： 在 idea 中同步工夫长，如典型利用须要 10 分钟左右。单次编译工夫长，如典型利用也须要 10 分钟左右。构建步骤多，在一次交付过程中，不同环境都要构建。在同一环境中往往会构建屡次。同时，构建性能问题也影响了开发同学的成就感。只写了几行代码，但一刷新工程，一本地编译，就一个上午过来了。一天下来，写代码的工夫没等编译的工夫多。 一线研发同学，他的研发工作远不止体现在研发协同平台上的操作，在一个分支能进入集成前，有大部分研发工作都是在线下本地实现的。所以线下本地的提效也很重要。从新的 Java 构建工具 AMaven 开始，咱们也将提效的视角范畴从线上研发协同平台延长到了一线研发本地。 ...

简介：阿里云EMR自2020年推出Remote Shuffle Service(RSS)以来，帮忙了诸多客户解决Spark作业的性能、稳定性问题，并使得存算拆散架构得以施行，与此同时RSS也在跟合作方小米的共建下一直演进。本文将介绍RSS的最新架构，在小米的实际，以及开源。 作者 | 一锤、明济、紫槿起源 | 阿里技术公众号 阿里云EMR自2020年推出Remote Shuffle Service(RSS)以来，帮忙了诸多客户解决Spark作业的性能、稳定性问题，并使得存算拆散架构得以施行，与此同时RSS也在跟合作方小米的共建下一直演进。本文将介绍RSS的最新架构，在小米的实际，以及开源。 一 问题回顾Shuffle是大数据计算中最为重要的算子。首先，覆盖率高，超过50%的作业都蕴含至多一个Shuffle[2]。其次，资源耗费大，阿里外部平台Shuffle的CPU占比超过20%，LinkedIn外部Shuffle Read导致的资源节约高达15%[1]，单Shuffle数据量超100T[2]。第三，不稳固，硬件资源的稳定性CPU>内存>磁盘≈网络，而Shuffle的资源耗费是倒序。OutOfMemory和Fetch Failure可能是Spark作业最常见的两种谬误，前者能够通过调参解决，而后者须要系统性重构Shuffle。 传统Shuffle如下图所示，Mapper把Shuffle数据按PartitionId排序写盘后交给External Shuffle Service(ESS)治理，Reducer从每个Mapper Output中读取属于本人的Block。 传统Shuffle存在以下问题。 本地盘依赖限度了存算拆散。存算拆散是近年来衰亡的新型架构，它解耦了计算和存储，能够更灵便地做机型设计：计算节点强CPU弱磁盘，存储节点强磁盘强网络弱CPU。计算节点无状态，可依据负载弹性伸缩。存储端，随着对象存储(OSS, S3)+数据湖格局(Delta, Iceberg, Hudi)+本地/近地缓存等计划的成熟，可当作容量有限的存储服务。用户通过计算弹性+存储按量付费取得老本节约。然而，Shuffle对本地盘的依赖限度了存算拆散。写放大。当Mapper Output数据量超过内存时触发外排，从而引入额定磁盘IO。大量随机读。Mapper Output属于某个Reducer的数据量很小，如Output 128M，Reducer并发2000，则每个Reducer只读64K，从而导致大量小粒度随机读。对于HDD，随机读性能极差；对于SSD，会疾速耗费SSD寿命。高网络连接数，导致线程池耗费过多CPU，带来性能和稳定性问题。Shuffle数据单正本，大规模集群场景坏盘/坏节点很广泛，Shuffle数据失落引发的Stage重算带来性能和稳定性问题。二 RSS倒退历程针对Shuffle的问题，工业界尝试了各种办法，近两年逐步收敛到Push Shuffle的计划。 1 Sailfish Sailfish3最早提出Push Shuffle + Partition数据聚合的办法，对大作业有20%-5倍的性能晋升。Sailfish魔改了分布式文件系统KFS[4]，不反对多正本。 2 Dataflow Goolge BigQuery和Cloud Dataflow5实现了Shuffle跟计算的解耦，采纳多层存储(内存+磁盘)，除此之外没有披露更多技术细节。 3 Riffle Facebook Riffle2采纳了在Mapper端Merge的办法，物理节点上部署的Riffle服务负责把此节点上的Shuffle数据依照PartitionId做Merge，从而肯定水平把小粒度的随机读合并成较大粒度。 4 Cosco Facebook Cosco[6]7采纳了Sailfish的办法并做了重设计，保留了Push Shuffle + Parititon数据聚合的外围办法，但应用了独立服务。服务端采纳Master-Worker架构，应用内存两正本，用DFS做长久化。Cosco基本上定义了RSS的规范架构，但受到DFS的连累，性能上并没有显著晋升。 5 Zeus Uber Zeus[8]9同样采纳了去中心化的服务架构，但没有相似etcd的角色保护Worker状态，因而难以做状态治理。Zeus通过Client双推的形式做多正本，采纳本地存储。 6 RPMP Intel RPMP10依附RDMA和PMEM的新硬件来减速Shuffle，并没有做数据聚合。 7 Magnet LinkedIn Magnet1交融了本地Shuffle+Push Shuffle，其设计哲学是"尽力而为"，Mapper的Output写完本地后，Push线程会把数据推给远端的ESS做聚合，且不保障所有数据都会聚合。受害于本地Shuffle，Magnet在容错和AE的反对上的体现更好(间接Fallback到传统Shuffle)。Magnet的局限包含依赖本地盘，不反对存算拆散；数据合并依赖ESS，对NodeManager造成额定压力；Shuffle Write同时写本地和远端，性能达不到最优。Magnet计划曾经被Apache Spark接收，成为默认的开源计划。 8 FireStorm ...

国内权威数据公司IDC公布《中国视频云市场跟踪（2021 上半年）》报告：阿里云间断四年稳居中国视频云整体市场份额第一，整体市场份额占比达25.9%。 四年NO.1领跑视频云赛道近日，国内权威数据公司IDC公布的《中国视频云市场跟踪（2021上半年）》报告显示，2021上半年中国视频云市场规模达到43.7亿美元，同比增长达到38.7%。尽管整个视频云市场在短期内面临些许变数，但中国视频云市场仍处于高速增长中，倒退态势仍然强劲。 数据显示，2021年上半年阿里云视频云市场占比高达25.9%，稳步放弃整体市场份额第一的地位，亦是IDC自2018年跟踪中国视频云市场以来，阿里云间断第四年放弃领先者的角色。同时，在视频CDN份额、视频私有云/公有云/混合云等市场细分畛域，阿里云也仍然继续高居市场份额第一，全笼罩式领跑中国视频云赛道。 同时，阿里云视频云基础设施份额占比高达27.9%，凸显音视频基于云底座的弱小算力撑持，由此促成了各类视频编解码计划、算法和智能模型的迭代降级，从而实现视频内容丰盛水平的极速晋升。 云上视频的演进与发轫针对视频云赛道，IDC指出，2021年上半年，互联网音视频点播、互动娱乐直播、电商直播、新媒体点播等场景依然是市场的核心内容；同时，视频内容高清化趋势日益清晰，对视频带宽、视频云存储、视频云转码等各类资源和产品提出更高需要，奠定了市场持续增长的根底。 IDC数据显示，2021上半年的视频云解决方案市场规模达到8.2亿美元，在传统直播、点播转码产品外，各类智能化视频内容生产工具、AI审核计划等正在成为视频云解决方案市场重要的增长引擎。阿里云视频云就曾在2021年7月与艾瑞征询联结公布《2021中国视频云场景利用洞察白皮书》，从视频云的全链路演进和技术的场景实际，洞察视频云技术的极致化、交互的多重体验化、AI赋能的全域全链化、低代码音视频开发趋势化。 同时，阿里云视频云也在多视角发轫赛道，引领增长： 首先，聚焦于互联网时代下的大视频产业，一直极致化演进视频云技术：通过顶尖画质、空间音频、智能交互，打造多端时代的超高清极致体验；通过RTC“零解决”能力，降级挪动实时交互的新境界；通过云端一体的超精密算力和智能算法，实现端到端智能直播的沉迷体验；通过AI驱动，打造全流程的智能媒体生产平台。 平行而向，扩延视频云在传统音视频产业的云化与智能化降级，重塑大传媒行业的内容生产力，助力人民日报、新华社等媒体行业智能降级下的高效流传，也胜利助力东京奥运会，实现50亿观众的云上奥运，并以全面而突破性的技术支持行将揭幕的北京冬奥会，为百年奥运发明云上惊喜。 再者，着力研发推出全新的低代码音视频产品vPaaS，让音视频技术真正普惠式地浸透笼罩更宽泛的企业用户，不管传统行业的音视频化摸索翻新，还是非传统行业的音视频深入发明，都可因而开启一个“极速智造、万象空间”的新世界。同时，针对低代码音视频，阿里云视频云翻新而前瞻地打造并交融了云原生音视频平台、MXDP多重体验开发平台、音视频场景AI智能平台，以及音视频场景利用工厂，突破技术壁垒，普惠更多行业，发明万象可能。 面对视频云赛道的倒退态势，IDC中国行业云服务钻研经理魏云峰示意，视频云正在减速解脱传输管道位置，体现出更丰盛的外延，极致高清、极致交互与极致沉迷的视频能力，以及交融了AI技术的全链路视频优化与解决计划，曾经成为互联网视频客户晋升视频品质、拓展视频状态、丰盛视频玩法的必须能力，甚至是撑持将来各种元宇宙构想的重要基石。这也正是阿里云视频云在极致进化与谋求的落地方向。 数字化之上的新世界这是一个产业数字化、数字产业化的时代，无处不在的云，也让音视频技术关上了更大的数字新视界。 咱们晓得，在并不漫长的IT技术史中，每一次边际效应的递加都是下一次产业延展的开始。真正的数字化翻新才刚刚开始，且肯定是对业务场景与技术场景深度了解和交融之后开始熟稔。将来成熟的音视频业务，肯定是基于数智化根底上的，它充沛实现云网端交融化和AI的一体化，一直冲破音视频技术自身的极限，以诞生新的物种。 而长期以来，任何一种技术都会经验从热词到成为后盾撑持的隐形巨擘，只有那些越厚重的底层、越轻薄易用的平台，才是技术实力的外围体现。正如”视频化“作为热词沸腾的当下，视频云技术与产品正在逐步成为大视频产业的技术底座和松软平台，并以其包容性成就更大的生态，以其演进力成就更强的能量。IDC预测显示，中国视频云市场仍然会放弃较高速的增长，预计2025年将达到318亿美元。 已经，4G商业化和Covid-19为互联网视频利用的胜利奠定了根底，带来了视频云市场的两次增长低潮。将来，广电传媒、批发、医疗、金融等传统行业的各种视频化摸索与翻新，以及新的元宇宙构想，亦可能成就视频云市场的下一次凋敝。而将来的视频云技术，也正是开启元宇宙的大门，以开展一个新的世界。 2021年云栖大会上，阿里云智能总裁张建锋曾以“云深处，新世界”为主题，诠释了一个全新的云上世界，他认为“一个以云为外围的新型计算体系结构正在造成，随着云网端技术进一步交融，将来无论企业或集体，计算将进一步向云上迁徙。”，而阿里云视频云恰是基于这样的云网端深度交融，加持前瞻的音视频技术，助力实现这个全民共享的云上新世界。 「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云产品技术交换群，和业内大咖一起探讨音视频技术，获取更多行业最新信息。

作者：林帆（花名金戟），阿里巴巴研发效力部技术专家 相干浏览：在阿里，咱们如何治理代码分支 阿里的许多实际看似简略，背地却蕴涵着许多思考，譬如测试环境的治理。 互联网产品的服务通常是由Web利用、中间件、数据库和许多后盾业务程序组成的，一套运行环境就是一个自成一体的小生态。最根本的运行环境是线上环境，部署产品的正式公布版本，为用户提供继续牢靠的服务。 除此以外，还有许多不对外部用户凋谢的运行环境，用于产品团队日常的开发和验证，统称为测试环境。正式环境的稳定性，除去软件本身的品质因素，次要与运行的主机、网络等基础设施相干，而测试环境的稳定性则更多受到人为因素影响。因为频繁的版本变更，以及部署未经充沛验证的代码，测试环境出故障的状况不足为奇。 良好的代码提交习惯、适当的变更前查看有助于缩小故障的产生，但无奈彻底杜绝后患。减少多套测试环境正本可能无效管制故障的影响范畴，然而企业的资源终归无限，升高测试环境老本和进步测试环境稳定性成为了矛盾的两面。 在这个畛域里，步人后尘的阿里研发效力团队设计了一种服务级复用的虚拟化技术，称为“个性环境”，其奇妙的思路令人赞叹。本文将围绕测试环境治理的话题，聊聊这种具备阿里特色的工作形式。 测试环境治理的困局测试环境的用处很宽泛，常见的测试环境譬如系统集成测试环境、用户验收测试环境、预公布测试环境、灰度测试环境等，它们体现了产品的交付生命周期，也间接反映出整个团队的组织构造。 小作坊型产品团队的测试环境治理起来非常简略，每个工程师本地就能启动全套软件组件进行调试，假使不释怀，再加上一个公共的集成测试环境也就足够。 随着产品规模扩充，本地启动所有服务组件逐步变得既费时又麻烦，工程师们只能在本地运行一部分待调试的组件，而后利用公共测试环境上的其余组件组成残缺零碎。 与此同时，团队规模的扩张，使得每个团队成员的职责进一步细分，新的子团队被划分进去，这意味着我的项目的沟通成本增加，公共测试环境的稳定性开始变得难以管制。在这个过程中，测试环境治理复杂性带来的影响，不仅体现在服务联调变得繁琐，更间接反映在交付流程和资源老本的变动上。 在交付流程方面，一个显著的变动是测试环境品种增多。出于不同的用处和目标，工程师们设计出了各式各样的专用测试环境。这些测试环境的组合造成了各个企业独具特色的交付流程。下图展现了一种用于大型项目的简单交付流程。 从独自服务的角度来看，环境与环境之间是由流水线相连的，再加上自动化测试或手工审批操作组成关卡，实现环境之间的传递。通常越高级别环境的部署频率越低，因而绝对稳定性也越高。与之相同，在级别较低的环境上，就随时可能存在新的部署，会打搅正在应用该环境的其他人。有时为了复现某些非凡的问题场景，一些开发者不得不间接登录到服务器下面去“搞事件”，进一步影响环境的稳定性和可用性。 面对随时可能解体的测试环境，小企业会试着去“堵”：束缚服务变更工夫、设立严格的变更标准，大企业则长于用“疏”：减少测试环境正本，隔离故障影响范畴。显然，不堪重负的测试环境肯定越“堵”越“漏”，千年以前大禹治水的故事早就揭示了的情理，刻意的管控援救不了软弱的测试环境。 近年来，DevOps文化的衰亡，端到端解放了开发者的双手，这对于测试环境的治理而言却是一把双刃剑。一方面，DevOps激励开发人员参加运维，理解产品的残缺生命周期，有助于缩小不必要的低级运维事变；另一方面，DevOps让更多的手伸向测试环境，更多的变更、更多的Hotfix呈现了。这些实际从全局来看利大于弊，然而并不能缓解测试环境的动荡。单纯的流程畅通同样援救不了软弱的测试环境。 那么该投入的还得投入。将不同团队所用的低级别测试环境各自独立，此时每个团队看到的都是线性流水线，从整体上察看，则会程现出河流汇聚的形态。 由此推广，现实状况下，每位开发者都应该失去独占且稳固的测试环境，各自不受烦扰的实现工作。然而因为老本因素，事实中在团队内往往只能共享无限的测试资源，不同成员在测试环境互相烦扰成为影响软件开发品质的隐患。减少测试环境正本数实质上是一种进步老本换取效率的办法，然而许多试图在老本和效率之间寻找最优均衡的探索者们，仿佛都在同一条不归路上越行越远。 因为主观的规模和体量，上述这些测试环境治理的麻烦事儿，阿里的产品团队都无奈幸免。 首先是测试环境品种的治理。在阿里外部，同样有非常丰盛的测试环境辨别。各种测试环境的命名与其作用非亲非故，尽管业界有些罕用的名称，但都未造成权威的规范。实际上，环境的名称只是一种模式，要害还在于各种测试环境该当别离适配于特定利用场景，且场景之间该当或多或少存在一些差别。 这种差别有些在于运行的服务品种，譬如性能测试环境很可能只须要运行与压力测试相干的那局部访问量最大的要害业务服务，其余服务运行了也是浪费资源。有些差别在于接入数据的起源，譬如开发自测的环境的数据源与正式环境必定不一样，这样测试应用的假数据就不会净化线上用户的申请；预公布环境（或用户验收测试环境）会用与正式环境统一的数据源（或正式数据源的拷贝），以便反映新性能在实在数据上运行的状况；自动化测试相干的环境会有独自的一套测试数据库，以避测试运行过程中受到其他人为操作的烦扰。 还有些差别在于使用者的不同，譬如灰度和预公布环境都应用正式的数据源，但灰度环境的使用者是一小撮实在的内部用户，而预公布环境的使用者都是内部人员。总之，没必要为一个不存在业务特殊性的测试场景专门创造一种测试环境。 在团体层面，阿里对流水线模式的束缚绝对宽松。主观的讲，只有在一线的开发团队晓得最适宜团队的交付流程应该是什么样子。阿里的开发平台只是标准了一些举荐的流水线模板，开发者可在此基础上进行施展。列举几个典型的模板例子： 这里呈现了几种外界不太常见的环境类型名称，稍后会具体介绍。 其次是测试环境老本的治理。 老本治理的问题非常辣手且非常值得深究。与测试环境相干的老本次要包含治理环境所需的“人工成本”和购买基础设施所需的“资产老本”。通过自动化以及自服务化的工具能够无效升高人工相干的老本，自动化又是个很大的话题，宜另起一篇文章探讨，此处暂且收住。 资产购买老本的升高依赖技术的改进和提高（排除规模化洽购带来的价格变动因素），而基础设施技术的发展史包含两大畛域：硬件和软件。硬件倒退带来的老本大幅降落，通常来自于新的资料、新的生产工艺、以及新的硬件设计思路；软件倒退带来的基础设施老本大幅降落，目前看来，大多来自于虚拟化（即资源隔离复用）技术的冲破。 最早的虚拟化技术是虚拟机，早在20世纪50年代，IBM就开始利用这种硬件级的虚拟化办法取得成倍的资源利用率晋升。虚拟机上的不同隔离环境之间各自运行残缺操作系统，具备很好的隔离性，通用性强，但对于运行业务服务的场景，显得略为轻便。2000年后，KVM、XEN等开源我的项目使得硬件级虚拟化宽泛遍及。 与此同时，另一种更轻量的虚拟化技术呈现了，以OpenVZ、LXC为代表的晚期容器技术，实现了建设于操作系统内核之上的运行环境虚拟化，缩小了独立操作系统的资源耗费，以就义肯定隔离性为代价，取得更高的资源利用率。 之后诞生的Docker以其镜像封装和单过程容器的理念，将这种内核级虚拟化技术推上百万人追捧的高度。阿里紧随技术后退的步调，早早的就用上了虚拟机和容器，在2017年双十一时，在线业务服务的容器化比例曾经达到100%。然而，接下来的挑战是，基础设施资源利用率还能做得更高吗？ 甩掉了虚拟机的硬件指令转换和操作系统开销，运行在容器中的程序与一般程序之间只有一层薄薄的内核Namespace隔离，齐全没有运行时性能损耗，虚拟化在这个方向上仿佛曾经倒退到了极限。惟一的可能是，抛开通用场景，专一到测试环境治理的特定场景上，持续寻找冲破。终于，阿里在这个畛域里发现了新的宝藏：服务级虚拟化。 所谓服务级虚拟化，实质上是基于音讯路由的管制，实现集群中局部服务的复用。在服务级虚拟化形式下，许多表面宏大的独立测试环境理论只须要耗费极小的额定基础设施资源，即便给每个开发者装备一套专用的测试环境集群都不再是吹牛。 具体来说，在阿里的交付流程上，蕴含两种非凡类型的测试环境：“公共根底环境”和“个性环境”，它们造成了具备阿里特色的测试环境应用办法。公共根底环境是一个全套的服务运行环境，它通常运行一个绝对稳固的服务版本，也有些团队将始终部署各服务的最新版本的低级别环境（称为“日常环境”）作为公共根底环境。 个性环境是这套办法中最有意思的中央，它是虚构的环境。从外表上看，每个个性环境都是一套独立残缺的测试环境，由一系列服务组成集群，而实际上，除了个别以后使用者想要测试的服务，其余服务都是通过路由零碎和消息中间件虚构进去的，指向公共根底环境的相应服务。因为在阿里通常的开发流程中，开发工作须要通过个性分支、公布分支和诸多相干环节最初公布上线，大多数环境都从公布分支部署，唯独这种开发者自用的虚拟环境部署来自代码个性分支的版本，故可称为“个性环境”（阿里外部叫“我的项目环境”）。 举个具体例子，某交易系统的残缺部署须要由鉴权服务、交易服务、订单服务、结算服务等十几种小零碎以及相应的数据库、缓存池、消息中间件等组成，那么它的公共根底环境就是这样一套具备所有服务和周边组件的残缺环境。假如此时有两套个性环境在运行，一套只启动了交易服务，另一套启动了交易服务、订单服务和结算服务。对于第一套个性环境的使用者而言，尽管除交易服务外的所有服务实际上都由公共根底环境代理，但在应用时就像是本人独占一整套残缺环境：能够随便部署和更新环境中交易服务的版本，并对它进行调试，不必放心会影响其余用户。对于第二套个性环境的使用者，则能够对部署在该环境中的三个服务进行联调和验证，假使在场景中应用到了鉴权服务，则由公共根底环境的鉴权服务来响应。 咋看起来，这不就是动静批改域名对应的路由地址、或者音讯主题对应的投递地址么？实事并没那么简略，因为不能为了某个个性环境而批改公共根底环境的路由，所以单靠正统路由机制只能实现单向指标管制，即个性环境里的服务被动发动调用可能正确路由，若申请的发起方在公共根底环境上，就无奈晓得该将申请发给哪个个性环境了。对于HTTP类型的申请甚至很难解决回调的状况，当处于公共根底环境的服务进行回调时，域名解析会将指标指向公共根底环境上的同名服务。 如何能力实现数据双向的正确路由和投递呢？无妨先回到这个问题的实质上来：申请应该进入哪个个性环境，是与申请的发起人相干的。因而实现双向绑定的关键在于，辨认申请发起人所处的个性环境和进行端到端的路由管制。这个过程与“灰度公布”很有几分类似，可采纳相似的思路解决。 得益于阿里在中间件畛域的技术积攒，和鹰眼等路由追踪工具的宽泛应用，辨认申请发起人和追溯回调链路都不算难事。如此一来，路由管制也就瓜熟蒂落了。当应用个性环境时，用户须要“退出”到该环境，这个操作会将用户标识（如IP地址或用户ID）与指定的个性环境关联起来，每个用户只能同时属于一个个性环境。当数据申请通过路由中间件（音讯队列、音讯网关、HTTP网关等），一旦辨认到申请的发起人以后处在个性环境中，就会尝试把申请路由给该环境中的服务，若该环境没有与指标统一的服务，才路由或投递到公共根底环境上。 个性环境并不是孤立存在的，它能够建设在容器技术之上，从而取得更大的灵活性。正如将容器建设在虚拟机之上失去基础设施获取的便利性一样，在个性环境中，通过容器疾速而动静的部署服务，意味着用户能够随时向个性环境中减少一个须要批改或调试的服务，也能够将环境中的某个服务随时销毁，让公共根底环境的主动接替它。 还有一个问题是服务集群调试。配合AoneFlow的个性分支工作形式，假使将几个服务的不同个性分支部署到同一个个性环境，就能够进行多个性的即时联调，从而将个性环境用于集成测试。不过，即便个性环境的创立老本很低，毕竟服务是部署在测试集群上的。这意味着每次批改代码都须要期待流水线的构建和部署，节约了空间开销，却没有缩短工夫开销。 为了进一步的降低成本、提高效率，阿里团队又捣鼓出了一种开脑洞的玩法：将本地开发机退出个性环境。在团体外部，因为开发机和测试环境都应用内网IP地址，稍加变通其实不难将特定的测试环境申请间接路由到开发机。这意味着，在个性环境的用户即便拜访一个理论来自公共根底环境的服务，在后续解决链路上的一部分服务也能够来自个性环境，甚至来自本地环境。当初，调试集群中的服务变得非常简单，再也不必期待漫长的流水线构建，就像整个测试环境都运行在本地一样。 DIY体验个性环境感觉服务级虚拟化太小众，离一般开发者很远？实事并非如此，咱们当初就能够入手DIY个体验版的个性环境来玩。 阿里的个性环境实现了包含HTTP调用、RPC调用、音讯队列、音讯告诉等各类罕用服务通信形式的双向路由服务级虚拟化。要实现这样的功能齐全的测试环境有点吃力，从通用性角度思考，咱无妨从最合乎公众口味的HTTP协定开始，做个反对单向路由的繁难款。 为了便于管理环境，最好得有一个能跑容器的集群，在开源社区里，功能齐全的Kubernetes是个不错的抉择。在Kubernetes中有些与路由管制无关的概念，它们都以资源对象的模式展示给用户。 简略介绍一下，Namespace对象能隔离服务的路由域（与容器隔离应用的内核Namespace不是一个货色，勿混同），Service对象用来指定服务的路由指标和名称，Deployment对象对应实在部署的服务。类型是ClusterIP（以及NodePort和LoadBalancer类型，暂且疏忽它们）的Service对象可路由雷同Namespace内的一个实在服务，类型是ExternalName的Service对象则可作为内部服务在以后Namespace的路由代理。这些资源对象的治理都能够应用YAML格局的文件来形容，大抵理解完这些，就能够开始动工了。 基础设施和Kubernetes集群搭建的过程略过，上面间接进正题。先得筹备路由兜底的公共根底环境，这是一个全量测试环境，包含被测系统里的所有服务和其余基础设施。暂不思考对外拜访，公共根底环境中的所有服务相应的Service对象都能够应用ClusterIP类型，假如它们对应的Namespace名称为pub-base-env。这样一来，Kubernetes会为此环境中的每个服务主动赋予Namespace内可用的域名“服务名.svc.cluster”和集群全局域名“服务名.pub-base-env.svc.cluster”。有了兜底的保障后，就能够开始创立个性环境了，最简略的个性环境能够只蕴含一个实在服务（例如trade-service），其余服务全副用ExternalName类型的Service对象代理到公共根底环境上。假如它应用名称为feature-env-1的Namespace，其形容的YAML如下（省略了非关键字段的信息）： kind: Namespacemetadata: name: feature-env-1---kind: Servicemetadata: name: trade-service namespace: feature-env-1spec: type: ClusterIP ...---kind: Deploymentmetadata: name: trade-service namespace: feature-env-1spec: ...---kind: Servicemetadata: name: order-service namespace: feature-env-1spec: type: ExternalName externalName: order-service.pub-base-env.svc.cluster ...---kind: Service...留神其中的order-service服务，它在以后个性环境Namespace中能够应用部分域名order-service.svc.cluster拜访，申请会路由到它配置的全局域名order-service.pub-base-env.svc.cluster，即公共根底环境的同名服务上解决。处于该Namespace中的其它服务感知不到这个差别，而是会感觉这个Namespace中部署了所有相干的服务。 ...

随着云原生正在成为数字经济翻新基石，企业的云原生利用逐步呈现出类型更加丰盛、场景更加简单的特点。这时，构建于核心云上的能力将越来越难以撑持企业架构麻利、业务灵便翻新等需要。  为了进一步拓展云的边界，让企业能够在任何须要云的中央取得统一的容器基础设施服务体验，近期，阿里云容器服务向 ACK Anywhere 全面降级，并针对异构 IaaS 环境推出 Kubernetes 发行版（以下简称 ACK Distro），使企业在自有基础设施上也能享受到与公共云同源的技术能力。  在 2022 年 1 月 11 举办的阿里云云原生实战峰会上，阿里云研究员、云原生利用平台负责人丁宇发表 ACK Distro 正式凋谢收费下载，以更好地满足客户对于容器产品丰盛度以及数据管控的诉求。 ACK Distro 的外围能力包含：  安全可靠： 外围组件来自阿里云 ACK 服务，并放弃同步更新。这些外围组件经验了数十万商业用户和阿里团体外围业务场景的严苛生产验证，安全性与可靠性通过实际测验，达到业界领先水平麻利易用： ACK Distro 深度联合阿里开源的集群利用打包交付工具 Sealer，分钟级实现集群的自动化部署、扩缩容、降级等集群生命周期治理性能统一体验： ACK Distro 集群能够被私有云 ACK 平滑地治理，实现资源管理统一、策略合规统一、流量管控统一、利用部署统一；同时，私有云 ACK 所反对的利用解决方案也能无差别的部署在 ACK Distro 集群内多样兼容： 外围组件同时支特 X86 和 ARM 硬件架构，同时 ACK Distro 蕴含的高性能网络插件 Hybridnet，又使得网络环境的多样性成为可能，最终确保 ACK Distro 可能丝滑运行于多样化的基础设施之上通过 ACK Distro，企业在决定将业务迁徙至私有云前，就能够在自有基础设施上享受到和阿里云容器服务 ACK 一样的平安、牢靠的企业级 Kubernetes 集群，并通过阿里云分布式容器云平台 ACK One 体验对立的云原生能力。具备肯定技术能力的企业，也能够间接应用 ACK Distro 麻利易用的集群自动化治理和利用打包交付工具，自主创立云原生利用集群。  阿里云容器服务发行版 ACK Distro 的构建资源和文档已在 GitHub 开源，欢送大家收费下载、自在扩大和应用，用 ACK Distro 为企业上云按下减速键，让翻新触手可及。 ...

作者：白玙 作为寰球出名职业培训平台服务商，伟东云教育以教育利用为外围，提供面向职业教育、高等教育的资源、产品与服务，打造“数字化人才倒退平台”。为寰球 25 个国家及国内 25 个省级行政区的政府、院校、企业、机构提供相干人才培养服务，深耕家政、应急、交通运输、退役军人待业守业培训、人工智能等多个畛域。弥合区域数字鸿沟，助力教育信息化建设，为推动寰球教育事业平衡倒退贡献力量。 作为教育行业独角兽，面对全国乃至寰球不同地区 ToB 客户及泛滥 ToC 终端用户，如何保障终端体验与平台可用性成为要害。在服务过程中，伟东云服务团队遭逢以下问题。 发现问题在为某地建设教育信息化平台过程中，时常呈现当地用户拜访异常现象。为解决这一问题，伟东云服务团队针对网站性能及网络链路的各环节进行逐个排查。确认平台可用性没问题后，伟东云服务团队将关注点聚焦于网络环境。 （图片来自网络，仅作示意） 虽最终与运营商解决上述问题，造成异样的根因是受到当地网络环境的限度，从而造成用户拜访异样。但伟东云服务团队在近程测试时查看失常，导致无奈更疾速定位问题地位，使得故障复原时长被拉长。面对这样的问题，如何确保全国乃至寰球不同地区用户的可用性，全面把握当地实在网络环境以及网站性能各个指标，尽可能压缩故障复原时长，成为伟东云教育服务团队的重要痛点。  在服务东北某地某客户的过程中，伟东云服务团队收到某地区用户上报，在浏览平台网站时会跳转到非法赌博平台，存在造成用户资产损失危险。在进行近程测试及通过 VPN 代理进行相干测试时，伟东云服务团队也无奈复现相干问题。 （图片来自网络，仅作示意） 随着故障排查的深刻，在针对上报异样的用户进行调研访谈时，伟东云服务团队发现上报异样的用户都应用了了当地某个小型网络运营商的宽带。经测试，发现的确是因为该运营商造成了劫持。 解决方案尽管已有各种监控伎俩，但如何更加全面的进行监控去查漏补全。如何保障日常服务的稳定性与安全性，成为伟东云服务团队的重要议题。在理解上述问题之后，阿里云与伟东云服务团队进行沟通，统一认为具备寰球海量监测节点以及非侵入式的「云拨测」解决问题的最佳产品。 重点城市城市可用性被动监控： 通过配置网络监控工作，抉择次要几个重点城市 IDC 监测点，对指标网站的重点页面进行网络连通性监控，同时配置较快的监测频率，一旦呈现可用性问题，告警会及时告诉进去。IDC 监测点绝对应 LastMile 监测点来说更稳固，能够缩小误报的概率。  页面拜访性能剖析： 网页关上速度也是伟东云教育须要重点关注点问题，对于他们的客户来说网页速度间接影响他们的客户在线教育的品质。针对网页关上速度，伟东云抉择了全副次要省份城市的 LastMile 监测点，并配置了浏览工作对网站首页和重点页面进行性能剖析，重点会关注网络连接延时、页面申请元素的总数及 CDN 解析对品质，定位问题根因后会推动相干供应商或外部研发团队进行优化。 最终成果借助云拨测，伟东云教育服务团队进一步欠缺监控体系。利用最低老本全面把握全国乃至寰球不同地区终端用户的理论拜访体验状况。缩短故障复原时长 20% 以上，大幅提高故障响应效率以及用户满意度。 对于云拨测云拨测作为面向业务的非侵入式云原生监测产品，成为最佳的抉择。通过阿里云遍布寰球的服务网络，模仿实在用户行为，全天候继续监测网站及其网络、服务、API 端口可用性与性能。实现页面元素级、网络申请级、网络链路级细颗粒度问题定位。丰盛的监测关联项与分析模型，帮忙企业及时发现与定位性能瓶颈与体验暗点，压降经营危险，晋升服务体验与效力。 寰球监测节点笼罩寰球超过 20 万 LM，500 余个 IDC 终端监测节点，海内外 400+ 运营商以及数十万量级注册会员，确保监测规模满足日益宏大的业务规模。 无需嵌码，开箱即用零侵入式监测，只需输出 URL 并进行简略配置即可，无需研发反对。数分钟即可取得残缺的网站性能数据分析报告。资源包&按量付费多种购买模式，满足运维测试需要。 面向业务，预置多种分析模型监测周期精密至分钟级别，7 大类 20 余项监测关联参数设置、反对多种支流协定，为站点和业务端口等提供 7×24 小时细颗粒度故障实时监测、告警及性能剖析服务。以最终客户视角，通过地区、运营商等多维度组合分析，下钻剖析单样本详情，利用丰盛的指标体系与图表类型，直观定位问题、受影响范畴及其根因，压降剖析工夫，晋升运维效率。真正做到精细化监测。 智能告警，精准定位针对首屏用时、整体性能、可用性实现实时告警，丰盛的告警策略设置，与阿里云告警核心深度集成，无效缩短 MTTR。反对发现页面元素级谬误，问题归因精准定位至单次网络申请过程，晋升问题定位效率。 为了满足更多企业与独立站长的拨测需要，云拨测上线公布不同规格的月资源包，并发展限时优惠活动。点击浏览原文，产看更多优惠！  往期举荐双十一行将到来，你的网站真的筹备好了吗？ 拒做背锅侠！如何利用网站性能优化驱动产品体验晋升 Facebook宕机背地，咱们该如何及时发现DNS问题 理解更多相干信息，请扫描下方二维码或搜寻微信号（AlibabaCloud888）增加云原生小助手！获取更多相干资讯！

作者：智云 为什么要做压测的问题定位？性能测试 PTS（Performance Testing Service）是具备弱小的分布式压测能力的 SaaS 压测平台，可模仿海量用户的实在业务场景，全方位验证业务站点的性能、容量和稳定性。 在一直的对被压服务端水位进行摸高的过程中，咱们能够从压测视图或者压测报告中看到较为全面的压测指标，例如 QPS、RT、TPS 等，然而单纯从这些指标上，是不能很快的定位到服务端具体问题所在的，例如，咱们从全场景谬误信息中心能够看到错误码对应的接口的响应体，然而具体在上游的哪一环节出错，以及谬误的堆栈是什么，这里单纯从报告中是看不到的，而接口上游具体是哪里出错，谬误堆栈是什么，正是用户所关怀的问题。 借助问题诊断，咱们能够明确被压接口的上下游的调用状况，同时，从链路视图上，咱们能够看到整条链路所通过的音讯组件(Kafka、RocketMQ 等)、缓存(Redis、MongoDB 等)、数据库(MySQL、Oracle 等)、RPC 调用(Feign、Dubbo、HttpClient 等)，例如，某个接口呈现状态码异样或者其余的谬误，那么，咱们能够从调用链上看到到底是 Rpc 调用呈现问题，还是数据库读写呈现问题，并且可能从调用链上看到对应的报错堆栈，在这些信息的根底上，问题应该去哪里定位也就比拟明确了。 问题诊断根本介绍和外围劣势根本介绍谈到问题诊断，用户次要关怀接入问题诊断是否须要对利用侧代码做一系列的革新，是否须要进行繁冗的配置等等。PTS 提供的问题诊断是基于 JavaAgent 的，无需用户侧做业务代码革新，对于基于 Tomcat 的部署形式，用户只需在启动脚本中增加一些必要的参数即可接入问题诊断；对于 Kubernetes 用户，用户只需在 Yaml 配置文件中增加一些必要的注解即可接入问题诊断。对于链路的采集规定，PTS 会提供默认的配置，用户也可依据本人的须要自行更改。 PTS 集成的问题诊断在压测过程中，针对每条申请，会在施压引擎端生成 TraceId，通过 TraceId 将该条申请所波及到的上下游链路关联起来，用户能够看到从该条申请作为入口到本条申请完结所波及到的残缺调用链，同时，问题诊断会针对该调用链生成相应的利用拓扑视图，能够让用户清晰地看到利用之间的调用关系。 针对异样的接口，咱们能够在调用链中看出对应的谬误起因，同时，用户能够依据具体的报错堆栈对服务端的问题进行排查和优化。压测过程中用户能够实时的查看指定申请的调用链，同时，压测完结之后，也能够从压测报告中对问题进行回溯。 外围劣势1、零代码侵入： 针对 Java 类型的服务，用户侧无需进行业务侧代码革新即可实现问题诊断的探针接入。 2、集成度高： 压测、监控、问题诊断，集成在同一控制台，用户了解和操作老本绝对较低。 3、监控指标全： 在压测过程中，除了较为根底的监控指标外，同时针对每个服务，提供接口、机器、利用级别的监控。  4、门槛低： 仅须要简略配置参数即可实现问题诊断探针接入，同时该探针还具备多协定 Mock、全链路压测等性能。 疾速玩转问题诊断接入问题诊断的根本流程图如下所示： 接入探针，并查看是否接入胜利首先，咱们将被压场景所波及到的利用梳理进去，将波及到的所有利用依照【问题诊断】->【探针接入 [1] 】文档中的步骤进行问题诊断探针接入。咱们能够在 PTS 控制台的利用配置或者利用监控、接口监控、机器监控中任选一个来查看利用探针是否接入胜利。咱们本次演示的压测场景波及到五个利用，别离是 petstore-web、petstore-user、petstore-order、petstore-catalog、petstore-cart，这以利用监控举例来查看利用是否胜利接入。顺次点击 PTS 控制台的【问题诊断】->【利用监控 [2] 】->抉择咱们配置的 Region 以及 Namespace，如果看到压测场景波及到的所有利用均在该页面，则代表利用接入胜利。 在压测场景中关上问题诊断开关而后，咱们在 PTS 控制台的【压测核心】->【创立场景 [3] 】中创立压测场景，这里能够抉择 PTS 场景或者 JMeter 场景等，这里以 PTS 场景为例，因为本次演示次要是验证问题诊断的能力，所以须要在场景配置中的【高级设置】中关上问题诊断开关。具体的监控采集规定，PTS 会为用户推送默认采集开关关上的配置，同时，将采样率设置为千分之一，用户也可依据本人的须要进行自定义。 ...

近些年DevOps火遍全国，仿佛不说DevOps研发效率就是低下的，技能就是掉队的。然而真是这样么？为了让大家更好的理解DevOps文化，3月27日《云效说码》分享特地邀请了阿里巴巴资深技术专家陈鑫（花名：神秀）进行视频直播分享，聊聊他对DevOps的了解以及阿里巴巴的DevOps文化落地要诀。 DevOps倒退的三个阶段首先咱们简略看一下什么是DevOps，这个词从何而来。我在这里把DevOps倒退历史分为三个阶段：诞生期、定义期和落地期。 DevOps的“祖师爷”是比利时一名独立IT咨询师Patrick Debois。2007年，他负责一个大型项目的测试和验证工作，一边和开发对接测试代码，一边和运维对接“发版”。他发现项目组里的开发和运维两个角色的思维形式差别微小，一边心愿“快快快”，一边心愿“稳稳稳”，这让他有点解体。 在2008 Agile Conference大会上，Patrick遇到了Andrew，两个人一拍即合，开始推敲如何扭转这种Dev和Ops水火不容的现状。 2009 年 10月，Patrick 通过 Twitter 招集开发工程师和运维工程师在比利时根特市举办了首届“DevOpsDays”大会，开始大规模探讨Dev和Ops的合作话题。起初为了便于流传“DevOpsDays”被缩写为“DevOps”。 在2009年当前，DevOps开始火遍寰球。2010 年，The Agile Admin博客发表文章《What is DevOps 》 ，具体论述了DevOps的定义，包含一系列价值观、准则、办法、实际以及对应的工具。 同样是2010 年，《继续交付》的作者Jez Humble缺席第二届的 DevOpsDays 大会，并做了 “继续交付”的演讲。这是十分重要的里程碑，能够说《继续交付》这本书就是DevOps的最佳实际，以至于国内搞研发效力的同学人手一本。也正是这本书，减速了业界对DevOps的了解以及落地。 但我认为业界真正开始大规模落地DevOps，还是不能来到容器化技术的功绩。“Docker”起到了决定性作用，通过编写Dockerfile，第一次能够让开发者轻松定义软件运行环境，并且能通过CI/CD标准化流程去交付它。不过这么多容器运维起来依然麻烦，于是google在2014年开源“k8s”（Kubernetes）；2015年CNCF（Cloud Native Computing Foundation 云原生计算基金会）成立，正式将“k8s”作为外围，建设了一个微小的生态系统。有了“docker”和“k8s”技术上助力，减速了开发和运维角色的交融，于是DevOps不再是海市蜃楼。 我间隔DevOps有多远 回顾完历史，咱们对照下本身，通过三个小问题来看看本人的团队是不是曾经是“DevOps”了。1、我每次写完代码都能够部署生产环境，不须要他人帮忙。2、有很多监控、运维工具能够任我应用，轻松解决线上各种问题和故障。3、我间接为线上用户的体验负责，不论是代码缺点还是运维故障，本人搞的本人背锅。 以上我三个问题，其实别离波及到了DevOps最重要的三个方面，做法、工具、文化，这三者缺一不可。 什么是好的DevOps团队 什么是高效能研发团队呢？咱们能够参考《2018 DevOps现状报告》里这张表格：能做到每小时1次或者每天1次部署，1天或1周可能上线1个版本，服务复原工夫小于1天，变更失败率小于15%。不过这个数字其实并不难看，以咱们本人举例，阿里巴巴研发平台团队，能够轻松做到1天屡次公布生产，可用性99.95%，变更失败率小于5%。 这些要求在阿里巴巴看起来稠密平时，那阿里是怎么一步一步走过去的，咱们其余企业应该如何复制这些教训。让咱们进入下一节，阿里巴巴的DevOps文化落地要诀。 阿里巴巴DevOps的倒退阶段DevOps的倒退永远离不开技术的改革，在2008年的时候，淘宝启动了服务化革新的历程，发明了Dubbo、Apache Alibaba RocketMQ、TDDL（Taobao Distributed Data Layer）等业界出名的中间件。同时淘宝的巨型利用被拆分，变成了下单、会员、优惠等一系列利用，而围绕各个子业务场景更是诞生了成千盈百个前台利用。大家能够设想一下过后的开发是怎么的，每周一个固定公布窗口，几百位工程师在邻近公布时提交代码、批改bug、提交测试。在公布日早晨开始依照程序进行一一公布，如果公布后呈现重大bug，要么当场Hotfix（修补程序），要么回滚，宣告公布失败。所有人都被公布日搞的精疲力竭。第一代自动化公布工具的呈现，将公布能力交还给了开发者，同时也迫使开发者去解耦利用依赖，做到独立公布，业务交付速度失去了质的晋升。起初大家给它起了一个名字，就是“微服务”。 没过两年，随着研发人员越来越多，呈现了各种简单研发标准、各种简单脚本、各种 “挖坑”“踩坑”等状况，让研发工程师苦不堪言。“这所有必须标准起来”， 2013年时咱们建设了对立构建部署平台，将阿里巴巴团体从代码变更到线上公布环节齐全对立起来，进行严管控。 在2016年咱们又遇到了新问题，过后线上操作须要运维同学对立来做，而运维同学人造不想去做变更。能够了解，什么都不改的状况下服务是最稳固的。可这在某种程度上限度了开发者的翻新，而且明确的职责分工也限度了开发者去关注本人利用的线上状态。这种状况，导致研发过程中呈现显著瓶颈，这也是为什么阿里巴巴要做DevOps的根本原因。随着“容器化”的浪潮降临，咱们研发平台再一次降级，将线上容器定义、运维监控责任全副交给了开发者，利用运维岗位不复存在。 而明天随着云原生技术的逐渐成熟，上云曾经变成企业标配，围绕云原生去定义下一代研发平台成为必然。 综上，技术的推动、组织的变动和研发工具的建设，这三者的有机联合才促成了咱们阿里巴巴DevOps一步步走向成熟。 阿里巴巴DevOps落地的工具后面介绍了宏观上技术和平台的倒退，具体来看有以下几个工具对阿里巴巴DevOps落地以及研发效力晋升施展了重大作用。 首先是DevOps平台“云效”，大家常见的开源软件Gitlab、Jenkins、Jira这些平台也已经是阿里巴巴的一个抉择，然而起初咱们发现，纯工具类型的软件只能解决一些单点自动化问题，比方代码治理、构建打包等等。其实在理论开发过程中还有很多工作无奈自动化，比方需要流转的规定，分支治理的规定，开发、测试、运维沟通的模式等。这些工作咱们能够统称为“合作”。 要做好“合作能力”须要的是对人和流程以及效率有粗浅的了解，并且将这些了解形象成办法，最终做成产品。阿里巴巴通过数年积攒，产出了泛滥独特的研发治理办法，比方Aone-flow代码管理模式、测试环境管理模式、 AGit-Flow代码管理模式、双十一分层项目管理模式等等。咱们把这些研发治理办法都落地在云效平台上，最初作用在人身上，耳濡目染的影响着开发者合作的文化，也能够说是DevOps文化。 第二个是流量回放测试技术。这项技术的翻新给测试团队带来了很大影响，通过线上流量复制到线下，低成本的解决了测试回归的问题，将传统通过编写用例进行测试，简化为编排数据进行测试。第二层是Mock技术的利用，将一个分布式系统问题，转化为单机问题，能够在几秒钟实现上千个用例运行。有了这两个根底技术后，在下层能够倒退测试平台，通过算法的伎俩去辨认无效流量，去自动化解决数据，去辨认异样流量背地的缺点。通过这三层面的改革，能够说让阿里巴巴测试效率有了质的变动。 第三个是全链路压测技术（对应阿里云上的产品叫PTS）。双11大家之所以能释怀剁手，一年比一年顺滑，外围就是这项技术在每次大促前帮忙开发者发现危险。发现当前就须要疾速的响应，通过DevOps工具去解决线上问题。每次压测都是一次练兵，有点相似于军事演习，疾速发现问题，疾速解决，一直锻炼团队DevOps能力，也能够这样说阿里巴巴的DevOps能力正是一次一次“双11”给练进去的。 阿里巴巴DevOps核心理念：松管控和强卡点当开发开始定义运维，接手运维的时候。咱们管理者会不会有些担心，比方会不会开发任意操作导致线上故障，随便公布导致稳定性问题等等。 阿里巴巴DevOps有一个核心理念是松管控和强卡点。 先看“松”在哪里？“松”是指咱们有多种流水线能够供开发抉择，利用Owner能够残缺定义这个利用的各种规定，比方如何公布，如何测试，如何进行资源、环境配置等。咱们有通用构建和自定义构建，能够给用户最大自由度。最初是“轻公布，重复原”。在每一个利用维度，开发能够随时应用流水线来交付代码，而并不需要特地的限度，仅仅须要思考的是如果出问题，咱们应该如何疾速复原。 在足够的自由度下，咱们必须要设置一些“卡点”。比方代码审核和品质红线；代码安全检查、规约查看；公布、封网窗口等。还有所谓“变更三板斧”：可灰度、可监控、可回滚。这些卡点是为了保障阿里巴巴团体所有开发工程师步调对立，交付合格的产品。 总结：DevOps外围是疾速交付价值，给与开发最大自由度，负责开发和运维全副过程。在监控、故障防控工具，性能开关的配合下，能够在保障用户体验和疾速交付价值之间找到平衡点。 阿里巴巴DevOps核心理念：以利用为核心阿里巴巴是怎么疾速落地DevOps的？这里我要重点提的是：以利用为核心的DevOps理念。利用信息其实能够演绎为CMDB中的一种数据。它对于研发人员人造是亲切的，它能够间接对应一个服务，一个代码库。以代码为终点，咱们又能够串联流水线、环境、测试、资源。最外围是工具链：监控、DB、运维、中间件等等。 ...

简介：近日，TPC Benchmark Express-BigBench(简称TPCx-BB)颁布了最新的世界排名，阿里云自主研发的神龙大数据减速引擎取得了TPCx-BB SF3000排名第一的问题。TPCx-BB测试分为性能与性价比两个维度。其中，在性能维度，在本次排名中，阿里云当先第二名高达41.6％，达到了2187.42 BBQpm，性价比当先第二名40％，升高到346.53 USD/BBQpm。 作者 | 神龙减速计算团队起源 | 阿里技术公众号 一 背景介绍近日，TPC Benchmark Express-BigBench(简称TPCx-BB)颁布了最新的世界排名，阿里云自主研发的神龙大数据减速引擎取得了TPCx-BB SF3000排名第一的问题。 TPCx-BB测试分为性能与性价比两个维度。其中，在性能维度，在本次排名中，阿里云当先第二名高达41.6％，达到了2187.42 BBQpm，性价比当先第二名40％，升高到346.53 USD/BBQpm。 （TPCx-BB SF3000性能维度排行） （TPCx-BB SF3000性价比维度排行） 借这个机会跟大家分享一下这个第一背地的技术历程。 二 神龙大数据减速引擎MRACC概述阿里云自研的神龙大数据减速引擎MRACC（Apasara Compute MapReduce Accelerator）是这次获得优异成绩的杀手锏。 在数据处理需要激增的明天，许多企业会应用开源Spark、Hadoop组件或HDP、CDH等罕用套件，自建开源大数据集群，解决数据量从TB到PB级，集群规模从几台到几千台。MRACC神龙大数据减速引擎，针对客户自建场景，依靠神龙底座，提供罕用组件减速能力，如Spark、Hadoop、Alluxio等。 联合阿里云神龙架构的个性，MRACC进行了软硬一体化优化，造成举世无双的性能劣势，最终，使简单SQL查问场景性能相比社区版Spark晋升2-3倍，应用eRDMA减速Spark性能晋升30%。在神龙大数据减速引擎的加持下，企业应用阿里云ECS云服务器运行大数据集群，将取得更高的性能和性价比。 图1 MRACC神龙大数据减速引擎架构 三 MRACC-Spark介绍Spark自从2010年面世，到2020年曾经通过十年的倒退，当初曾经倒退为大数据批计算的首选引擎。针对大数据最罕用的Spark引擎，MRACC进行了重点优化。具体来说，针对大数据工作重IO个性，MRACC在网络和存储方面联合云上的架构劣势进行软硬件减速，包含软件的SQL引擎优化，应用缓存、文件裁剪、索引等优化伎俩，并尝试将压缩等运算卸载到异构器件；还应用eRDMA进行网络减速，将shuffle阶段的数据交换运行在eRDMA网络，使得延时升高、CPU利用率大幅晋升。 图2 MRACC-Spark架构 四 Spark SQL引擎优化从Spark2当前，Spark SQL, DataFrames and Datasets接口逐步取代根底RDD API成为Spark的支流编程模型。社区对Spark SQL进行了大量投入，据统计Spark3.0版本公布将其中靠近一半的优化都集中在Spark SQL上。应用 SparkSQL 代替 Hive 执行离线工作已成为不少企业的支流抉择。 针对SQL引擎的anlyzer、optimizer、planner、Query execution几个阶段，咱们都做了一些优化。Spark3.0对SQL引擎进行了大刀阔斧的革新和优化，其中AQE和DP机制广受关注。但目前开源Spark的AE机制目前仅反对分区裁剪，对于非分区键和subquery裁剪不反对，咱们针对这块做了优化，反对subquery的动态数据裁剪，能大幅缩小参加计算的数据量。 在物理打算执行阶段，咱们反对了window topn排序，使得蕴含limit的sql语句性能大幅晋升，并反对了parquet rowgroup裁剪、bloom filter join等高级个性。SPAKR SQL的CBO机制能较好的进步SQL执行效率，然而在cbo阶段，join table过多会导致的cbo搜寻开销暴增，咱们反对了遗传算法搜寻，解决了 join table过多导致的开销暴增的状况。此外，还反对了去重下推、join外键打消、完整性束缚等性能，并联合deltalake反对了数据的增删改操作。 图3 MRACC-Spark的SQL引擎优化 五 近网络RDMA优化2021年杭州云栖大会上，阿里云公布第四代神龙架构，提供业界首个大规模弹性RDMA减速能力。RDMA是一种高性能网络传输技术，提供间接内存拜访的形式，数据传输bypass Kernel，从而能缩小CPU的开销，提供低时延的高性能网络。在分布式计算中，shuffle过程必不可少，且耗费较多的计算和网络资源，是大数据分布式计算的优化重点。针对Spark 内存计算在shuffle阶段数据交换特点，可将shuffle数据交换变为memory-network-memory的模式，充分利用RDMA用户态内存间接交互、低延时、低cpu耗费的特点，最终在tpcxhs等端到端benchmark上取得了30%的性能晋升。 ...

作者：汤长征、十眠 MSE 服务治理帮忙咱们零碎以很低的老本无侵入的形式疾速实现了全链路灰度能力，进一步晋升了咱们零碎的稳定性，让咱们新需要的迭代上线更加地安心。 —复电科技架构师 汤长征 复电科技自 2014 年起开始进入共享充电畛域，定义并创始了行业，属于行业内最早的共享充电企业。次要业务笼罩充电宝自助租赁、定制商场导航机开发、广告展现设施及广告流传等服务。复电科技领有业内立体化产品线，大中小机柜以及桌面型，目前全国超过 90% 的城市实现业务服务落地，注册用户超2亿人，实现全场景用户需要。 复电科技的业务场景丰盛且零碎泛滥，在技术架构上已实现容器化以及微服务化革新，微服务框架应用的是 Spring Cloud 与 Dubbo。随着近年来的高速倒退，充电宝设施节点以及业务量都在疾速减少。复电科技的整体利用架构也随着业务的高速倒退，继续一直地进化。微服务治理是微服务化深刻的必经之路，明天我来和大家分享一下复电科技在微服务化深刻过程中摸索的这一历程：缘起： 回顾复电科技过后的业务、架构现状和痛点。初见： 分享在技术选型之路上咱们为什么抉择 阿里云微服务引擎 MSE（Microservices Engine，全文以下简称 MSE） 。落地： 咱们是怎么一步步落地、在短时间内低成本落地全链路灰度能力以及无损高低线等能力。 瞻望： MSE 与复电科技携手进一步深入微服务化之路。 缘起复电科技外部技术趋势满足如下三点 微服务全面落地全面接入 K8s疾速迭代，稳固公布的诉求复电科技在 2019 年 10 月开始，服务开始全面进行微服务革新，容器化革新实现；在 20 年 12 月，此时复电科技曾经全面微服务化，全面接入 K8s。 能够看到随着复电微服务化过程的逐步深刻，在这个微服务深入的过程中，咱们逐渐会面临一系列的挑战，总的而言，咱们讲这些挑战分为三个大的层面，他们别离是效率，稳固和老本。咱们进行微服务化，自身的使命是让业务的迭代更加高效，但当咱们的微服务数量逐渐增多，链路越来越长，如果不进行进一步的治理，那么引发的效率问题可能会大于微服务架构自身带来的架构红利。 因而在 2021 年 6 月，复电科技对微服务进行了可观测建设；21 年 9 月开始进行微服务治理能力构建。 全面容器化的劣势容器化总结来说有以下这些劣势 部署不便，公布效率大大晋升弹性扩缩容大大节约服务器老本运维老本升高简略讲一下全面容器化给复电科技零碎带来的益处，首先就是利用部署变得十分不便，同时因为 K8s 的标准化使得 CI/CD 也变得简略，整体的公布效率大大晋升；同时部署在 K8s 上的利用人造具备弹性扩缩容的能力，能够有效应对流量洪峰；同时因为上了 K8s 后，服务按需应用资源，相比原先依照峰值长期固定保有服务器，资源利用率绝对比拟低，当初能够大大节约服务器老本。相比传统集群运维十分繁琐，同时对运维人员技能要求也十分高：既要精通 lua /ansible 脚本等，又要懂云产品网络配置和监控运维。零碎的运维老本十分高，阿里云容器服务 ACK 的标准化界面能很好解决高密部署以及零碎运维的问题，极大降低成本。 稳固公布三板斧的诉求日常公布中，咱们经常会有如下一些谬误的想法： 这次改变的内容比拟小，而且上线要求比拟急，就不须要测试间接公布上线好了公布不须要走灰度流程，疾速公布上线即可灰度公布没有什么用，就是一个流程而已，公布完就间接公布线上，不必期待察看尽管灰度公布很重要，然而灰度环境很难搭建，耗时耗力优先级并不高这些想法都可能让咱们进行一次谬误的公布。 阿里巴巴外部有平安生产三板斧概念: 可灰度、可观测、可回滚。所有研发同学必须要把握公布零碎的灰度、观测和回滚性能如何应用。 互联网频繁公布是常态，对于复电科技来说也是如此，零碎具备灰度、观测、回滚的能力是微服务零碎必须具备的能力，灰度能够说是公布之前的必备流程，也是晋升线上稳定性的关键因素。当服务有新版本要公布上线时，通过引流一小部分流量到新版本，能够及时发现程序问题，无效阻止大面积故障的产生。业界上曾经有比拟成熟的服务公布策略，比方蓝绿公布、A/B 测试以及金丝雀公布，这些公布策略次要专一于如何对单个服务进行公布。 ...

小明的研发团队要公布一个版本，这个版本蕴含了多个性能个性，每个不同的个性之间有较强的独立性。不同的个性由不同的开发人员或开发小组分工实现。 他们在不同的个性分支上开发，彼此互相独立、互不影响。 一个个性开发实现后就提交测试，这个过程不影响其余个性的失常开发，全副已实现的个性全副合并进行测试和公布。在提交测试，集成合并时碰到了这样的问题： 对于某个公共模块的批改呈现了合并抵触因为一个个性分支的集成，导致整个版本集成失败版本公布工夫在即，为不影响整体停顿，须要疾速拆散影响了整个集成的那个个性分支。 如果你是小明，这时你会怎么做？ 小明的研发团队又要公布一个版本，整个版本有 A、B、C、D 四个性能个性一起合并集成，别离在分支 A、B、C、D 上开发。邻近公布前，市场侧告诉因为某种原因性能个性 B 不能公布，也就是这次公布须要剔除分支 B。依照严格的集成公布策略，A、C、D 这 3 个个性分支须要从新构建，别离再通过集成测试、预发验证，而后到生产公布。然而，这样做是有老本的。 如果你是小明，在效率和品质之间你会怎么选？ 这两个情景遇到的问题，在多分支并行开发集成公布中很常见，如何疾速、灵便、高效又实用地解决这类问题，成为泛滥小明的刚需。 阿里巴巴团体外部经验并仍在经验着大量多分支集成公布的实际，这些实际被提炼成了一套阿里的分支策略，造成了阿里分支模式，并通过公共云产品云效 Flow 对外部研发用户输入。 当应用云效Flow 分支模式时，小明的两个场景问题将能够失去灵便高效地解决。 场景一：如何疾速拆散影响整个集成的那个个性分支 小明能够间接在再次运行分支时，删除已集成分支，执行流水线时将会主动进行以下操作： 基于分支管理器中设置的根底分支（如 master），创立新的 release 分支除了该个性分支外的其余在云效配置中的其余分支合并到 release 分支基于 release 分支的最新内容运行流水线场景二：公布在即需要被砍，如何均衡效率和品质？ 小明发现云效分支能够按环境/流程，自在地集成，思考到本次上线的工夫对后续我的项目进度十分要害，小明抉择了跳过两头的测试阶段、预发阶段间接部署到正式环境，为了最大水平防止品质危险，小明还应用了云效Flow的公布前人工审核卡点能力，最终变更没有耽搁失常发版，也未呈现任何危险。 云效 Flow 这套灵便高效的分支模式能够让用户只关怀集成和公布哪些个性分支，而对公布分支创立和治理、分支间合并等一系列工作，托付给云效实现。 上面具体介绍云效分支模式原理及实际。 云效 Flow 分支标准master 代表最新公布版本个别状况下，master分支代表最新公布版本。当须要最新公布版本的内容时，间接取分支末端即可。 不管其余哪类分支，都倡议个别从 master 分支创立，并且常常从 master 分支合并，以便跟上“潮流”，缩小未来集成时的各种问题，比方代码合并抵触。 每当软件正式公布前，零碎会确保它基于 master 最新。 每当软件正式公布后，零碎会把相应内容合并回 master，以便让 master 分支始终代表最新公布版本。 一般来说，使用者不要间接“写”货色到master分支。把“写”的工作交给零碎适时主动实现。 在各 feature 分支上开发一条 feature 分支（又称变更分支、开发分支），通常用来承载一个缺点的修复，或者一个需要（如果不是很大的话）的开发，或者工作合成后一个工作的开发。 一般来讲，基于 master 分支最新版本创立 feature 分支。而后在 feature 分支上开发、测试，直到这个 feature 性能实现，品质 OK，筹备好去集成和公布。 ...

简介：阿里云实时数仓Hologres年度公布，解读数仓新趋势。 1月7日，阿里云实时数仓Hologres公布最新版本，在老本、可用性、在线高可用等多方面进行了能力降级，行存吞吐晋升100%，列存吞吐晋升30%，反对行列共存，反对更加丰盛的OLAP剖析场景，反对Binlog全链路事件驱动加工，原生JSON数据类型和索引，进一步升高开发和运维老本，加强Hologres高并发的在线服务能力。 Hologres是一站式实时数据仓库引擎，反对海量数据实时写入、实时更新、更新及剖析、实时剖析，反对PB级数据多维分析与即席剖析以及高并发低提早的在线数据服务等，与MaxCompute、Flink、DataWorks深度交融，提供离在线一体化全栈数仓解决方案。 阿里云资深技术专家果贝示意：“随着企业数字化转型的加剧，实时数仓技术开始逐步从幕后走到台前，被越来越多的企业作为生产零碎撑持多种业务场景，一站式、在线化、麻利化成为实时数仓新的发展趋势”。 数仓建设过程中，开发、运维老本和在线高可用始终是难点和痛点。大数据场景上，解决的数据量和复杂度远高于数据库场景，传统数仓通常是用不同的产品去实用不同的场景，比方ClickHouse罕用于OLAP剖析，HBase罕用于服务场景，无奈用一个产品满足所有需要，多套零碎非常容易造成架构冗余，运维简单等问题，导致老本只增不减。同时，随着实时数仓被作为生产零碎的宽泛应用，业务对系统的可用性和稳定性都提出了更高更严苛的要求，但实时数仓技术要实现生产高可用也须要面临肯定的取舍和挑战，比方高性能的同时资源隔离、宕机时的疾速恢复能力等，以满足不同场景的SLA。 基于以上问题，Hologres在老本、可用性、在线高可用等多方面进行了能力降级，进一步升高开发和运维老本，加强Hologres高并发的在线服务能力，行存吞吐晋升100%，列存吞吐晋升30%，反对行列共存，反对更加丰盛的OLAP剖析场景，反对Binlog全链路事件驱动加工，原生JSON数据类型和索引，减速半构造数据的检索，保持一个零碎解决大数据问题的准则，降本增效，助力服务剖析一体化建设。 在生产高可用方面，Hologres重磅公布不同档次的隔离与高可用部署，反对单实例内资源组隔离，实现多租户的计算资源隔离，反对多实例高可用部署（共享存储），实现读写拆散和故障隔离，并联合Hologres底层外围调度等能力，实现不同场景生产高可用。此外，Hologres在可用性、生态兼容、企业级运维能力上一直摸索和更新，帮忙企业实现新一代一站式实时数仓。 据理解，Hologres还屡次反对了阿里巴巴双11等大促流动，在2021年阿里巴巴双11期间，禁受住了每秒11.2亿条的高速写入，和每秒1.1亿次的查问峰值（蕴含点查和OLAP查问），创历史记录。 除此之外，Hologres除了反对阿里巴巴的GMV实时大屏等业务外，还反对了实时搜寻举荐、菜鸟智能物流、达摩院无人车配送等外围业务场景，这意味着实时数仓技术开始在阿里巴巴外围业务锋芒毕露，并在性能、生产稳定性等方面禁受住了严格的生产考验。 原文链接本文为阿里云原创内容，未经容许不得转载。

对于阿里云音讯队列更多新性能新个性及具体介绍，欢送大家查阅官网各产品“新性能公布记录”： [1]  RocketMQ： https://help.aliyun.com/document_detail/167894.html [2]  Kafka： https://help.aliyun.com/document_detail/162716.html [3]  RabbitMQ： https://help.aliyun.com/document_detail/153186.html [4]  EventBridge： https://help.aliyun.com/document_detail/176667.html [5]  MQTT： https://help.aliyun.com/document_detail/162828.html

本期效力举荐：近年，研发效力特地火，不少企业的CTO都把研发效力晋升作为部门的年度重点。然而，大家都心愿晋升研发效力，很多却不晓得从何开始。咱们精心盘点了2018-2021间断3年来，云效团队在研发效力晋升方面输入的所有干货，心愿对大家有所帮忙。 立刻查看 【效力案例】本期举荐：中和农信 举荐理由：在越来越多越简单服务研发过程中，怎么进一步整体晋升开发的品质和继续集成的效率，稳固生产的服务能力；组织规模和我的项目越来越大，怎么通过优化研发工具来晋升研发组织整体协同效率，感知每个团队的研发效力和项目风险；减速服务农村最初一百米，中和农信云原生DevOps转型之路。 立刻查看 每期一个案例，更多案例点击 云效客户案例； 【效力产品动静】我的项目合作Projex 新性能 ● 反对钉钉文档集成：在Projex中反对企业级、我的项目级、工作级与钉钉文档买通，企业能够更好的将文档协同、我的项目资产治理落地在云效中。● 反对API接口：为了更好的撑持用户在Projex的自定义合作场景，咱们提供了全新的一套API接 本次更新了获取我的项目相干信息的两个接口，更多接口正在开发中，敬请期待。 ● 反对层级字段的应用和分组查看。● 修改迭代工时计算逻辑为父项+子项工时总和。● 关联工作项反对工作项编号检索。● 需要内容模板反对markdown。● 工作项详情抽屉反对切换高低条操作。● 【自动化规定】反对字段值清空。● 【自动化规定】反对工夫字段抉择动静工夫 详情请参见：钉钉文档协同详情请参见：API应用阐明 修复 ● 布局迭代页面，负责人信息未展现。● 需要珍藏后归档，勾销归档。工作项珍藏里无此需要。● 企业角色删除提醒删除失败，未明确失败起因。● 看板模式下，子项卡片的“打算实现工夫”展现不正确。● 字段模版删除字段后工作流必填字段未同步删除，导致状态无奈流转。 【效力答疑】Q：如何通过指定java小版本去构建我的项目，是须要引入本人的集群吗？ A：应用自定义镜像构建环境，具体能够参考https://help.aliyun.com/docum... Q：云效流水线能够间接把git代码上传oss吗？ A：能够有oss上传的组件 【效力小课堂】7招！实现平安高效的流水线治理，云效团队多年来为阿里巴巴外部（Aone）和云上企业用户（云效）别离提供研发运维工具，并致力于打造企业级一站式的 DevOps 平台，更多关注不同类型的企业用户在应用过程中的治理与合作场景，本文将重点介绍高效平安治理云效流水线的7招。 立刻查看 【效力调研】 为了更好理解您的实在效力诉求，晋升云效效力周刊服务质量，1分钟立刻填写，退出云效云大使，还能支付价值188元的云效周边大礼包！（钉钉群：33523652） 立刻填写：https://survey.taobao.com/app...

作者：溪洋 在云原生浪潮的推动下，容器和 Kubernetes 技术和利用倒退迅猛。最近，云原生计算基金会 CNCF 公布了与 SlashData 联手撰写的 最新版《云原生开发现状报告》，该报告显示，“Kubernetes 在过来的 12 个月获得了令人瞩目的增长——明天，寰球共有 560 万开发人员在应用 Kubernetes。对于那些领有 500 多名员工的大型组织而言，Kubernetes 和容器的采用率猛增，这意味着 Kubernetes 曾经齐全满足企业的需要。很多时候，开发人员甚至在没有意识到 Kubernetes 的状况下就在应用它。” 云原生曾经成为数字经济技术的翻新基石，与此同时，容器正在成为企业应用云的新界面，为企业的计算基础设施、利用架构、组织文化和研发流程带来新一轮改革。最近，阿里云容器服务团队几位核心成员在一次访谈中，分享了他们对企业级容器利用市场的变动和 2022 年容器技术重点倒退方向的趋势察看。本文心愿联合 2021 年阿里云云原生容器服务的重点事件，帮忙大家梳理云原生容器畛域的外围倒退脉络，把握技术趋势走向。 盘点：2021 阿里云云原生容器服务大事记  1. 全面降级，让云的边界拓展至企业须要的每个场景 2021 年 9 月，阿里云容器服务发表全面降级为 ACK Anywhere，并公布 ACK 发行版、ACK 麻利版、ACK ONE 分布式云容器平台；以及面向异构计算撑持、资源调度、网络、云原生 AI、智能化运维、云原生制品散发等六大方向的优化降级。降级后的 ACK Anywhere 领有“统一体验、弹性算力、能力下沉、简化容灾”四大外围能力，使企业在任何业务场景下应用容器服务时，都能实现对立集群治理、对立资源调度、对立数据容灾和对立利用交付。 2. 开掘潜能，撑持新一代容器架构降级 随着企业对容器的拥抱更加踊跃，对容器核心技术的启动效率、资源开销、调度效率都有了更高的要求，阿里云容器团队也反对了新一代的容器架构降级，通过对容器、裸金属、操作系统等全栈优化，继续开掘容器的潜能。 高效调度：全新降级 Cybernetes 调度器，反对对多架构神龙的 NUMA 负载感知、拓扑调度和细粒度的资源隔离和混部，晋升利用性能 30%。此外，在调度器上做了大量端到端优化，在 1000 节点规模集群中，能够提供 20000Pods／min 以上的调度速度，确保在线服务和离线工作都能高效地运行在 Kubernetes 上；高性能容器网络：最新一代的阿里云容器网络 Terway 3.0，一方面通过神龙芯片 offload 虚拟化网络开销，一方面在 OS 内核中通过 eBPF 实现容器 Service 转发和网络策略，真正实现零损耗，高性能。容器优化 OS：面向容器场景，推出轻量、疾速、平安、镜像原子治理的容器优化操作系统 LifseaOS，相比传统操作系统软件包数量缩小 60%，镜像大小缩小 70%，OS 首次启动从传统 OS 的 1min 以上降落到了 2s 左右。反对镜像只读和 ostree 技术，将 OS 镜像版本化治理，更新操作系统上的软件包、或者固化的配置时，以整个镜像为粒度进行更新。高密部署极致弹性：基于阿里云平安沙箱容器 2.0，优化沙箱容器内的资源开销，最小可达 30M 左右，实现了在繁多物理机上的 2000 实例的高密服务能力。同时通过管控链路的缩短以及组件的精简，并辅以对沙箱内存调配流程、host cgroup 治理流程和 IO 链路的优化，实现了 Serverless 场景的 6 秒 3000 弹性容器实例的弹性能力。3. 行业引领，技术成熟度与产品丰盛度持续保持寰球当先4 月，Gartner 公布 2021 年容器竞争格局报告，阿里云成为国内惟一间断三年入选的中国企业，产品丰盛度与成熟度持续保持寰球领先水平。与今年相比，在 Kubernetes 反对、容器镜像、Serverless 容器、服务网格等传统维度根底上，本次报告新增了集群部署状态和管控立体两个维度，阿里云容器产品再次取得国内高度认可。5月，在 2021 云原生产业大会中，阿里云容器服务 ACK/Serverless Kubernetes (ASK + ECI）、阿里云服务网格 ASM 解决方案被中国信通院评为 2021 年度云原生技术创新解决方案/产品。6 月，阿里云边缘容器服务 ACK@Edge 通过信通院 33 项测评，取得“2021 云边协同能力认证”，基于 ACK@Edge 实现的申通快递 IoT 云边端架构，入选“2021 分布式云与云边协同十佳实际案例”。7 月，在 2021 年可信云大会中，中国信通院颁布了多项可信云认证的评估后果。其中申通基于阿里云边缘容器 ACK@Edge 的 IoT 云边端架构获可信云用户最佳实际（申通-阿里云边缘容器），包含 Serverless 容器服务 ASK 在内的无服务器架构、阿里云服务网格 ASM  取得专项首批先进级认证。8 月，容器服务 ACK 作为阿里云上最优的容器执行环境、容器镜像服务 ACR 作为最优的容器利用散发基础设施，通过高效稳固、极致弹性、平安智能等能力的输入 ，推动国内赛事以云原生的形式减速向数字化演进倒退。11 月，对立调度技术胜利反对 2021 年双 11 大促，实现了从容器调度到快上快下全流程的全面降级和优化，帮忙阿里双 11 大促成本升高 50%，生产环境常态化 CPU 利用率 65%。12 月，阿里云边缘云原生一体机通过信通院 67 项测评，取得“边缘一体机能力要求认证”。4. 开源凋谢，携生态搭档构筑边缘、AI、平安、多集群等场景下容器能力幅员1 月，OpenYurt 凭借业界首个开源非侵入式边缘计算云原生平台的技术劣势，入选边缘计算社区评比的“ 2020 年边缘计算畛域十大热门开源我的项目”。 3 月，阿里云与 GitHub 联结公布了疾速部署至阿里云 ACK 的 GitHub Action Workflow。开发者无需自建部署保护 CI/CD 工具，基于开箱即用的 GitHub Action 及阿里云部署模板，即可实现 GitHub 代码变更后，主动利用打包构建上传阿里云容器镜像服务 ACR、疾速部署至阿里云容器服务 ACK 的流程。4 月，由阿里云容器团队与南京大学、Alluxio 社区联结开源的开源的云原生数据编排和减速零碎 Fluid 正式进入 CNCF Sandbox；9月，该我的项目在由中国信息通信研究院、中国通信标准化协会联结主办的“2021 OSCAR 开源产业大会”上荣获“ OSCAR 尖峰开源我的项目和开源社区”奖。5 月，在2021 阿里云开发者大会“云原生技术与最佳实际”论坛现场，阿里云容器服务负责人易立、VMware 中国研发核心研发总监路广联结发表达成单方在“云原生边缘计算”畛域的技术策略单干，心愿将来依靠开源社区力量，减速边缘云原生生态系统的构建，独特推动云边交融过程，帮忙更多企业全面拥抱数智化转型降级。8 月，阿里云云原生团队联结 Linux 开源软件学园在 GOTC 2021 “云原生人才倒退”分论坛联结公布“阿里云云原生人才打算 2.0”，打造面向 CKA、ACA 专业人才双认证能力的课程体系，推动业界造就云原生和 Kubernetes 专业人才。9 月，由阿里云操作系统平安团队和云原生容器平台团队独特发动的开源我的项目 Inclavare Containers 进入 CNCF Sandbox，这是业界首个面向秘密计算场景的开源容器运行时我的项目。11 月，间隔正式发表开源仅 3 个多月后，由来自阿里云容器团队、蚂蚁金服和红帽的工程师独特发动并开源的多集群治理平台 OpenClusterManagement（OCM）我的项目正式进入 CNCF Sandbox。察看：企业级容器化利用形式和需要变动 1. 容器化利用向边缘业务场景延长随着 5G、IoT、音视频、直播、CDN 等行业和业务的倒退，咱们看到一个行业景象：企业开始将更多的算力和业务下沉到间隔数据源或者终端用户更近的中央，从而来取得很好的响应工夫和降低成本。CNCF 最新公布的《云原生开发现状报告》显示，在边缘开发人员当中，Kubernetes 的采用率减少了 11 个百分点，达到 63%。边缘开发人员应用容器的比例为 76%。 ...

作者：智妍（郑妍）、浣碧（何颖） 什么是混沌工程，云原生大潮下的混沌工程特点通过应用云计算厂商如阿里云、AWS 等提供的服务，古代服务提供者得以用更低廉的老本，更稳固地进行丰盛的软件服务提供。然而真的所有如此轻而易举吗？支流云计算厂商在 SLA 承诺的范畴内，都各自呈现过一些历史故障，可参见这份血淋淋的 github 上的报告列表 [1] 。另一方面，各个云产品提供给了用户应用的一些高可用能力，常常仍然是须要用正确的姿态来配置和应用的。 混沌工程能够帮忙业务零碎服务提供者通过创立破坏性事件、察看零碎和人员响应形式、针对优化改良这 3 个步骤来发现生产服务中软弱的环节，并依据预期的 SLA 指标进行施行改良。除了指出须要改良的零碎组件设计问题之外，混沌工程还可帮忙发现须要监控和告警上的盲点、发现人员对系统了解、应急响应 SOP、排查能力上的有余，进而使得业务零碎及其研发、运维人员整体的高可用能力水位大大上浮。因而 Netflix 提出此概念后，各大软件厂商纷纷进行了对内实际和对外产品提供。 云原生在传统云计算根底上，提供了更快更低成本的弹性，更好的软硬一体化灵活性，曾经成为云计算倒退最快的技术方向。云原生帮忙开发者大幅度降低资源老本和交付老本，从而更快更好地博得市场。同时，云原生也给传统运维、研发形式带来了彻底的改革，这就使得传统的混沌工程伎俩须要追随演进。 云原生背景下，其上的应用服务的混沌工程施行和传统有什么不同呢？从咱们在阿里电商、中间件云原生化的大量实际中，总结出以下次要差别： 在这样差别的背景下，用云原生的伎俩，施行更加针对植根于云原生利用的场景的混沌工程，是更加恰到好处，可能提供更多能力晋升的。 混沌工程施行模式的阶段和倒退既然混沌工程能带来如此多的益处，一个基于云原生的应用服务或体系想要实际，要如何落地呢？ 从演练工具和落地施行来看，一个组织的故障演练常常分为几个倒退阶段：手工演练，流程工具自动化演练，常态化无人值守演练，生产突袭演练。 这几个阶段的施行难度是从低到高，当然相应的收益也是从低到高。一个组织（云用户）能够随着本人业务应用服务体量的增大、复杂化和高可用能力的增高的历程，依据理论状况须要抉择本人适合的阶段，而后随之进行降级和倒退。即便从最简便的手工演练开始做起施行，常常也能带来相当显著且久远的高可用能力系统性晋升。 那么每个阶段别离有什么特点，又该如何抉择呢 手工演练： 个别在高可用能力建设初期阶段，或者一次性验收的状况下手工注入故障实现。通过人为查看告警是否失效，零碎复原状况来进行演练。在这个阶段只须要一些故障注入的小工具或者脚本，不便后续应用即可。自动化演练： 高可用能力建设到肯定阶段后，往往会有定期检查高可用能力是否进化的需要，自动化演练开始排上日程。自动化演练步骤个别包含：环境筹备 -> 故障注入 -> 查看 -> 环境复原。在每个步骤中配置相应的脚本来造成演练流程，下一次就能够一键点击自动化执行了。常态化执行： 演练进行到下一阶段，咱们会有更高的要求，心愿演练能够自主混沌化执行，以无人值守的形式进行，这又对系统的高可用能力有了新的挑战。这要求零碎有不仅有监控告警能够发现故障，也有对应的预案模块来负责复原，而要做到无人值守，须要零碎进行更智能准确的判断故障状况，主动执行相应预案。 生产突袭： 以上演练大多在灰度环境进行，不会影响到业务，生产突袭则要求零碎有能力在生产环境管制爆炸半径的前提下进行故障演练，以期发现一些业务相干、规模相干、配置相干、应急响应相干的，在灰度环境脱漏的局部，生产环境的演练对系统的要求较高，须要有一套执行标准，对系统的隔离能力也有较高要求。大多数的工作，能力建设都在灰度环境实现验证，但生产突袭仍作为一个无效且必要的演练伎俩，用更实在的场景给研发体感，让其实在执行预案，也锤炼了应急能力，对系统有更多信念和认知。如何进行一次残缺的故障演练施行当利用首次应用 Kubernetes 进行利用部署和扩容时，最先关注的更多是性能是否可用，故障演练则是更高级别的要求，咱们假如以后的零碎曾经初步通过了性能验收，但对于一些故障状况下零碎的体现还未知的前提下，来开始咱们的故障演练之旅。故障演练自身作为一种破坏性的操作，须要循序渐进，遵循肯定的标准和流程来落地。上面咱们从环境建设、零碎能力剖析、高可用能力建设、演练施行倡议几个方面来介绍一下，一个首次在 Kubernetes 中部署起来的利用应该如何循序渐进的施行故障演练。 Step 1：隔离环境建设故障演练，特地是首次执行之前，咱们须要明确好以后注入故障的环境状况，是否可能影响到业务流量，是否会造成无法弥补的损失，在阿里外部，咱们有简单的环境隔离和变更管控，以防故障注入影响到业务流量。 在环境类别上，咱们会辨别为以下几类： 业务测试环境：用来进行 e2e 测试，全面的性能验收，这个环境和有业务流量的生产网络是隔离的，从网络上防止了流量谬误进入到其余环境，因而能够在这个环境上纵情的进行各种容错性测试。金丝雀环境：能够了解为是一种全面的链路灰度环境，这个环境有以后零碎的所有组件，个别用来做上下游联调，零碎外部的链路灰度应用，这个环境是没有理论业务流量的；平安生产灰度环境：这个环境咱们会引入 1% 的生产流量，并提前建设了切流能力，一旦这个环境呈现问题，能够把流量迅速切换到生产环境中，该环境个别用来联合用户流量做一段时间的灰度，免得全量公布导致的不可控；生产环境：实在用户流量的环境，这个环境的任何运维动作都须要进行严格的变更审核和前几个环境的灰度通过能力变更；故障演练个别会开始在金丝雀环境引入，能够在全链路、无实在流量的环境中做一些高可用能力的建设和验收，常态执行的演练，在这个环境演练屡次的场景，可定期在灰度环境和生产环境中、管制爆炸半径的前提下进行实在突袭，作为能力的验收。 个别状况下，思考到老本投入和零碎复杂度，业务利用可能不会建设 4 个隔离环境来循序渐进的推动，但咱们举荐利用应该至多有两个环境来辨别用户流量，环境上至多有一个和生产隔离的灰度环境，至多初期必须如此。环境建设中须要关注的问题如下： 隔离性：灰度环境和生产环境尽量做到隔离，包含但不限于网络隔离，权限隔离，数据隔离等，思考到一些容灾的能力，还能够将两个集群建设在不同地区的 Kubernetes 集群中。真实性：灰度环境和生产环境尽量保持一致，比方内部依赖，组件版本。环境建设达标后，才具备了演练的准入条件。 Step 2：故障场景剖析在剖析零碎的高可用能力时，往往没有一个对立的答案，每个零碎的薄弱点，瓶颈都不尽相同，但整顿零碎高可用能力时，咱们能够提供一些通用的思路。 历史故障：历史故障通常是疾速理解一个零碎单薄能力的教科书，通过剖析历史故障，进行分类，能够疾速得出以后零碎那些组件更容易呈现问题。 比方零碎能力须要进行疾速的弹性伸缩，伸缩失败可能影响业务流量，能够推断出它强依赖 Kubernetes 的扩缩容能力，须要监控关注此能力的可用性；比方零碎数据读写频繁，历史呈现过数据不统一问题，则能够思考在数据层面进行稳定性建设，减少备份能力，回滚能力等。 架构剖析零碎的架构在肯定水平上决定了这个零碎的瓶颈，通过剖析零碎的依赖也能够更理解零碎的边界，也更便于进行运维上的优化。 比方一个利用的部署形式是主备模式的，那必须要查看的能力就是主备切换是否顺畅，切换过程是否影响到业务流量；比方一个利用强依赖底层存储，一旦存储挂掉，业务会大面积故障，则在整顿高可用能力的时候就须要想到存储挂掉后是否有降级计划，存储问题是否能够提前预警。 社区教训：很多零碎的架构都是大同小异的，参考社区或友商的教训就像提前看了模仿考题，总会有意想不到的播种。咱们总会在业界爆出一些故障时进行自我反思和重新整理，屡次发现了本身的一些问题。网线被挖断、删库跑路等贵重的教训库，都在咱们定期演练的列表中。 在阿里云原生的架构上，咱们整顿了如下所示的演练模型供参考，在这个高可用能力模型中，咱们依据零碎架构依照管控层组件、元集群组件、扩大组件，数据存储，节点层，整体集群进行辨别，在每个模块中有一些通用的故障能够相互借鉴。 Step 3：零碎高可用能力建设在理论进行故障注入前，咱们还须要问本人几个问题。根据上述曾经剖析到的咱们想让零碎领有的高可用能力列表，零碎是否具备当这些故障来长期有麻利的发现能力，人员有迅速的响应能力，零碎自身是否具备自愈的能力或一些可用来在故障过程中应用疾速复原零碎的工具呢？上面咱们从发现能力和恢复能力两个方面来给一些通用的倡议。 ...

作者：徐葛 大家好，我是阿里云云原生 ARMS 产品经理徐葛，明天给大家带来可观测系列课程的第三节课 -《业务&数字化体验治理场景解读》。本文次要分为三局部，第一局部是数字化体验的必要性，从数字化体验治理对业务的影响和数字化体验治理对企业的价值两个方面来介绍其必要性；第二局部，ARMS 在数字化体验治理上的产品能力介绍；第三局部，联合客户案例进行最佳实际分享。 数字化体验治理的必要性为什么咱们须要数字化体验治理呢？国外调研报告显示，70% 用户反馈网页关上速度会间接影响用户在线上网站进行购物的志愿。亚马逊也发现网站加载速度每减少 100 毫秒，整体销售额将缩小 1%。 总的来看，用户体验将会间接影响到业务体现。那么数字化体验对于企业来说，会带来哪些价值？咱们认为数字化体验的价值体现在三个方面： 第一个就是量化，置信大家都可能听过一句话 --「如果说你不可能量化它，你也没方法优化它」因而，把主观的用户体验量化成具体指标，同时提供可视化的剖析能力，来帮忙企业理解整体用户终端的体验程度与存在的问题。同时除了可能量化咱们本身产品的用户体验指标，咱们也能够取得所在行业的基准指标，甚至是竞品体验指标。有了量化数据，咱们能够通过数字化体验工具实现对数据的洞察与利用。比如说，对可用性和页面性能的问题定位，对问题影响面的定界，去剖析这个问题到底是地区问题、运营商问题，还是说设施问题造成的。最初，有了这些洞察论断当前，ARMS 用户体验交互工具也会对体验问题提供优化倡议，帮忙咱们去针对性的修复问题。更快的发现问题，缩小业务影响，同时升高整体故障修复工夫。  因为数字化体验对企业来说是如此重要， ARMS 在数字化体验场景提供了比拟全方位的工具，针对数字化体验个别有两种形式，一种叫合成观测，咱们比拟熟知的概念叫拨测。另外一种叫实在流量观测。针对于合成 ARMS 这边提供了云拨测产品，针对于实在流量，ARMS 这边提供了前端性能剖析与 APP 性能剖析两款产品。 简略来说，云拨测就是通过事后建设好的不同地区、不同运营商、不同设施和不同类型的检测点，对指标网址进行主动式模仿拜访，获知可用性以及性能相干指标。同时，得益于云拨测的黑盒模式，还能够对竞品的体验指标进行采集和剖析。在实在流量观测方面，ARMS 分为针对于 web 的前端性能剖析和针对于 APP 的性能剖析。针对 web 前端观测，ARMS 反对对网站、H5、小程序进行治理，第一是提供经营相干的剖析能力，包含 PV/UV 等数据以及页面性能相干的剖析，另外还能够针对于 API 申请联合 ARMS 利用性能剖析提供端到端的链路关联剖析能力。在挪动端上，APP 性能剖析可针对于 iOS 利用和 Android 利用实现解体剖析、性能剖析、近程日志拉取，以及不同设施、不同运营商、不同网络的多维分析能力。  那么这两者有什么区别，它们别离适宜于哪些场景呢？这里简略总结一下： 首先，从流量角度来看，云拨测其实不是实在流量，它是模仿拜访流量。前端性能剖析和 APP 性能剖析基于实在流量进行性能剖析，所以，从这里能够看出云拨测不须要流量，也能实现对网站或 API 接口进行性能治理。前端性能剖析与 APP 性能剖析，须要有实在流量才可能实现数字化体验治理。  其次，从模式上看，云拨测是被动伎俩，它会被动对网站或者是 APP 的提供商进行拜访，更快、更早的发现体验或其余相干问题，可能在用户之前去解决和修复这些问题。前端性能剖析与 APP 性能剖析更多的是被动式伎俩，有了用户拜访流量当前，才可能获知相干指标，从而实现对应剖析。  最初，从数据量来看，云拨测拜访频率和拜访次数都是可能设定好，当时可控的，数据量相对来说较少。而前端性能剖析和 APP 性能剖析，因为采集的是实在流量数据，所以网站及 APP 上的交互事件都会产生对应指标、日志，这都将产生大量数据。  总结来看，云拨测更多实用于获取基准体验指标，例如某地区如果没有用户流量的话，通过云拨测对网站进行拨测，获知这个地区整体性体验指标。同时，还能够对行业竞争对手网站进行拨测，获取到行业基准体验指标。而前端性能剖析和 APP 性能剖析因为基于实在流量，获取的都是网站或者 APP 的实在体验指标。比方针对某新版本公布当前，验证整体体验是否达到了预期成果。另外，云拨测适宜诊断及短期关注的体验问题，前端性能剖析和 APP 性能剖析适宜长期跟踪 APP 或网站性能，并辨认出潜在问题。也就是说云拨测可能帮忙咱们答复的是已知问题的答案，比如说这个网站到底是可不可用？然而没方法答复潜在的问题，也就是说当你还不晓得问题出在哪里的时候，这种场景比拟适宜实在流量性能剖析。 ...

客户简介斯凯奇（SKECHERS）1992 年诞生于美国加州，现在已遍布寰球 170 多个国家地区。在美国是仅次于耐克的第二大鞋类品牌。2020 年 11 月斯凯奇发表与阿里云达成单干，减速数字化降级。引入阿里云中台后，进一步推动全渠道优化，晋升经营效率和供应链治理能力。  客户需要斯凯奇的全渠道业务中台通过对立接入网关提供 API 接口供内部调用。因为斯凯奇业务场景丰盛且零碎泛滥，近年来因为业务高速倒退，双 11 大促等流动的流量顶峰对以后零碎的性能和稳定性提出更多的挑战。而内部渠道、外部老零碎、第三方服务须要与业务中台互通或者由中台提供能力，因为接入零碎形态各异，急需丰盛的平安认证伎俩并进行对立治理。新一代云原生网关能够提供微服务实例主动发现、路由转发、金丝雀公布及细粒度可观测等能力，可优化服务凋谢的开发效率和运维老本。  解决方案斯凯奇选用阿里云 MSE 云原生网关作为业务中台的对立接入层，间接买通了已有的微服务注册核心，直连后端服务，疾速实现微服务之间的互通互访和对立治理。通过多种路由规定实现的灰度公布，能轻松满足大促前业务疾速迭代上线的需要；相比 Spring Cloud Gateway 等微服务网关，MSE 云原生网关性能更好，同时其负载平衡、流量控制能力可加强后端服务的可用性，确保中台零碎顺利应答双 11 流量洪峰；云原生网关集成了认证登录零碎，利用 JWT 认证性能和黑白名单，让业务疾速构建平安屏障；云原生网关提供了丰盛的可观测数据，包含流量全局看板、日志检索、业务 TOP 榜、提早/失败率/错误码等多种响应指标等，并辅以报警治理，使运维人员对服务的整体状态及异常情况尽在把握，加重大促期间的工作累赘  技术架构图 利用架构图 上云价值MSE 云原生网关给斯凯奇提供了对立的微服务路由、流控、平安治理等能力，不便内外部多零碎间的集成，极大进步了中台服务凋谢的开发效率，并升高运维老本。 关联产品：MSE、EDAS、MQ、ARMS、ACK、AHAS、DRDS 点击此处，返回 MSE 官网查看更多！

作者：冯泳，孙健波 大家好，很快乐能在 KubeCon 中国峰会给大家做分享，明天的主题是“以统一的体验构建和治理多集群利用”，配角是 KubeVela 和 OCM，这两个都是 CNCF 的开源我的项目。整个演讲大抵分为三局部，首先介绍云原生利用交付和治理的挑战，而后介绍这背地的 KubeVela 和 OCM 技术原理，最初是整体的最佳实际，以及一个残缺的 Demo。 背景随着云原生生态的凋敝，Kubernetes 逐步成为了基础设施的规范集成界面，越来越多的基础设施能力变成了开箱即用的申明式 API，CRD Operator [1 ] 的遍及也让运维能力也逐步趋向于申明式和自动化。如图 1 所示，从底层基础设施到下层利用开发，现在的 CNCF 生态 [2 ] 中有上千个我的项目。 图 1. CNCF landscape 生态 - 摘自 2021.12 然而泛滥的抉择是礼物，也是研发工程师的懊恼。不同的利用架构波及到的不同开发语言、技术框架、打包形式、制品状态、云资源、以及运维形式各不相同。软件生命周期中，开发、测试、预发灰度、生产部署对应的环境和利用交付部署体验也存在很大的不统一。研发人员切换到云原生技术栈就波及大量简单的新常识须要学习，这就好比对着大量操作系统底层的 API 写程序，不足了编程框架和规范库，让利用开发事倍功半。 如何用好云原生凋敝的技术生态，又能让业务的研发人员取得统一的低门槛体验，同时安全可靠的交付利用，是业界面临的微小挑战。 业界的典型做法与挑战为了解决利用交付的这最初一公里问题，业界的典型做法次要分为两大类。 第一类是在针对本身的业务场景基于 Kubernetes 构建外部的 PaaS 平台，暗藏 Kubernetes 平台接口，提供本身平台 API。这种模式通常在规模较大的公司，须要有对 Kubernetes 和业务都比拟精通的团队撑持。然而随着工夫的推移，业务场景变得复杂、需要逐步减少，外部自建的 PaaS 都会面临扩大能力有余、难以保护，最初不得不颠覆重做的窘境，这个问题在阿里晚期的利用云原生化革新的实际过程中尤为显著。另一方面，规模较大的公司通常会有不同的业务团队，因为顶层设计有余，不同团队各自构建的 PaaS 平台很容易成为相互独立的烟囱，大量类似的能力只能反复建设、无奈复用，更无奈对立治理。每个不同场景的不同平台又给更下层的业务团队带来了新的概念和学习累赘。 针对第一类场景存在的问题，业界逐步偏向于容器平台层原汁原味透出 K8s 原生 API，负责提供稳固的云原生生态能力，同时不影响灵活性和扩展性。利用交付通过相似 Jenkins/Gitlab 这样的 Pipeline ，将利用制品打包（如 Helm Chart 等），而后间接部署到容器平台中，这就延长出第二类做法。基于传统 CI 生态工具间接对接容器平台的模式，如图 2 所示，这类做法的外围是通过脚本、配置等形式构建形象体系来简化应用门槛。这个形式目前是业内较为风行的解决方案，其益处分工较为明确，容器平台层作为 Infra/SRE 团队保护基础设施能力，利用交付则充分利用企业内现有的 CI 体系，不须要建设平台。 ...

近日，云效一站式DevOps工具链再添新成员——钉钉文档。 应用云效新版我的项目合作Projex的企业，在工作台找到钉钉文档利用，实现钉钉企业绑定后，即可在云效内不便地应用钉钉文档。 文档是产品研发过程中十分重要的合作工具。产品研发过程中的诸多资料，如产品同学的需要文档、开发同学的技术调研、测试同学的测试报告等是用文档的形式承载。 钉钉文档有着良好的编辑体验、欠缺的分享链路，能够帮忙企业晋升合作效率、积淀常识资产。 本次云效对钉钉文档的集成，是对云效一站式DevOps解决方案能力的进一步加强。自2017年对外提供服务到当初，云效始终专一于产研合作场景。目前云效DevOps产品矩阵已十分丰盛（如下图所示），提供从需要-开发-测试-公布-运维全链路的研发合作工具。 “云钉一体”是阿里云的大策略。早在去年，云效就已实现与钉钉的集成，企业在云效内绑定钉钉后，能够不便地同步钉钉组织架构和成员，以及钉钉音讯触发告诉。 往年，云效与钉钉的集成还将进一步深刻，更多能力将陆续上线，敬请期待！ 点击下方链接返回云效，立刻体验钉钉文档能力吧~ https://help.aliyun.com/docum...

概述传统流水线 Pipeline 工具，包含 Jenkins、Teamcity、Travis CI 等产品，作为企业 DevOps 中继续集成/继续交付的外围工具，从外围性能上来说通常能够概括为以下4点： 1、自动化测试： 提供代码扫描、平安扫描、单元测试等自动化测试工具，确保代码在集成前曾经通过充沛测试验证。 2、集成构建： 提供各种语言、框架的利用编译打包性能，将源码自动化转化为能够运行的理论代码，比方装置依赖、配置资源等。 3、公布部署： 反对多种资源（虚拟主机、K8S等）的公布形式，反对通过灰度公布、分批公布等各种策略，保障业务交付的稳固。随着各种云计算的逐步遍及，呈现各种各样的 Iaas/Paas 产品，CI/CD 工具如何反对各种模式的公布场景成为了一大外围价值。 4、流程编排： 通过对不同工具和工作的流程编排能力，实现不同 CI/CD 流程把控。通常来说，流水线工具岂但反对串联本身提供的测试、构建、部署性能，还会反对企业买通自有的其余工具（比方 git 仓库、自动化测试零碎等）。 以上几点，作为 CI/CD 提供的根底性能，本文不做赘述。 云效团队多年来为阿里巴巴外部（Aone）和云上企业用户（云效）别离提供研发运维工具，并致力于打造企业级一站式的 DevOps 平台，更多关注不同类型的企业用户在应用过程中的治理与合作场景，本文将重点介绍高效平安治理云效流水线的7招： 第1招：基于业务个性分组治理流水线第2招：预置流水线模板/工作组/步骤第3招：一键批量降级流水线第4招：设置通用变量组，随调随用第5招：精密治理主机/集群资源第6招：灵便治理公有构建集群第7招：自定义企业maven配置 第1招：基于业务个性分组治理流水线随着企业业务规模和团队规模的逐渐倒退，流水线和企业成员的数量越来越多。如何让成员疾速定位到本人的流水线，防止成员吞没在一堆与本人无关的内容中，同时保障业务倒退的安全性，成为了企业的独特诉求。 云效反对企业管理员能够在单条流水线上设置不同成员的查看、运行、编辑等流水线权限。同时也反对对流水线进行分组，并基于分组对多条流水线批量受权。 分组反对间接依照部门设置权限，这样的益处是部门成员产生变动后，流水线权限也主动发生变化。企业成员入职、到职的变动导致的权限变更能够做到自动化解决。 第2招：预置流水线模板/工作组/步骤在云效流水线 Flow 中，流水线是依照 流水线 -> 工作组 -> 步骤组成的，流水线能够由多个工作组编排组成，而每个工作组能够由多个步骤编排而成。 为了不便用户疾速创立流水线，云效流水线 Flow 预置了局部流水线模板、工作组、步骤。 为了反对企业用户更加个性化地配置本人的流水线，云效流水线 Flow 中的流水线模板、工作组、步骤均反对企业自定义创立。可在企业设置中的流水线模板治理-工作组治理-步骤治理中，创立属于企业个性化的内容，企业成员能够在编辑流水线的过程中应用此局部自定义内容。 此外，在流水线模板治理-工作组治理-步骤治理中，企业管理员能够敞开企业不须要的内容以防止造成烦扰。 第3招：一键批量降级流水线尽管随着业务规模的增长，企业外部流水线工作越来越多，但因为企业内技术栈根本对立，会呈现不同流水线之间只有局部配置（如代码源、虚拟主机组等）存在差别，而大部分配置基本相同的状况。 当企业流水线的某些配置（比方构建脚本、人工卡点的审核人员）须要更改时，批改流水线会导致大量的反复工作。 因而，云效提供了通过工作组实现流水线批量降级的性能。 反对在企业设置中增加工作组时，开启“反对批量降级”性能。 企业成员在配置流水线过程中，能够抉择曾经创立的工作组。尔后，企业管理员编辑批改工作组后，会对关联流水线中的工作节点进行降级。 第4招：设置通用变量组，随调随用定义环境变量是实现流水线过程定制化的一种常见办法，能够在执行过程的任何阶段应用这些变量，云效流水线反对在每条流水线中设置其独有的环境变量。 然而有些变量其实是十分通用的变量，企业内大部分流水线都会用到，这时如果独自在流水线中进行设置，可导致大量反复工作。因而，云效提供了企业级治理变量的通用变量组性能。 反对在企业设置中增加变量组，每个变量组可设置多个变量，且变量均可设置为私密变量，局部敏感参数，如 username、password 等，设置成私密变量后，能够大幅升高平安危险。 流水线管理者，只须要在流水线中关联变量组，就可在流水线工作中应用该变量。 ...

云原生浪潮下，Serverless 正在全面落地。继「云原生 Serverless 技术实际营」广州站炽热收官，2022 年，阿里云 Serverless 团队开年巨献，把 “沉迷式”技术实际营带到南京。 此次实际营将面向企业技术人员，与到场诸位分享 Serverless 的落地实际，进行多视角技术观点碰撞，全程实时弹幕互动答疑，一起摸索 Serverless 企业落地的更多可能性。1 月 13 日（周四），江苏南京—新城科技园，采取报名审核制，仅限 50 人。 扫描下方二维码或点击浏览原文报名 **https://survey.aliyun.com/apps/zhiliao/n6_465qFF 沉迷式参会体验： 想听就听，企业生产业务 Serverless 化分享圆桌探讨，多视角分析 Serverless想玩就玩，手把手体验万人打磨生产级场景想问就问，实时弹幕互动挑战答题，验证学习效果、赢大奖参加在左、留念在右，颁发技术实际营结业证书海报详情 点击此处，即可报名！

云原生利用自动化治理套件、CNCF Sandbox 我的项目 -- OpenKruise，近期公布了 v1.0 大版本。 OpenKruise [1]  是针对 Kubernetes 的加强能力套件，聚焦于云原生利用的部署、降级、运维、稳定性防护等畛域。所有的性能都通过 CRD 等规范形式扩大，能够实用于 1.16 以上版本的任意 Kubernetes 集群。单条 helm 命令即可实现 Kruise 的一键部署，无需更多配置。 总得来看，目前 OpenKruise 提供的能力分为几个畛域： 利用工作负载： 面向无状态、有状态、daemon 等多种类型利用的高级部署公布策略，例如原地降级、灰度流式公布等。Sidecar 容器治理： 反对独立定义 sidecar 容器，实现动静注入、独立原地降级、热降级等性能。加强运维能力： 包含容器原地重启、镜像预拉取、容器启动程序保障等。利用分区治理： 治理利用在多个分区（可用区、不同机型等）上的部署比例、程序、优先级等。利用平安防护： 帮忙利用在 Kubernetes 之上取得更高的安全性保障与可用性防护。版本解析在 v1.0 大版本中，OpenKruise 带来了多种新的个性，同时也对不少已有性能做了加强与优化。 首先要说的是，从 v1.0 开始 OpenKruise 将 CRD/WehhookConfiguration 等资源配置的版本从 v1beta1 降级到 v1 ，因而能够反对 Kubernetes v1.22 及以上版本的集群，但同时也要求 Kubernetes 的版本不能低于 v1.16。 以下对 v1.0 的局部性能做简要介绍，具体的 ChangeLog 列表请查看 OpenKruise Github 上的 release 阐明以及官网文档。 反对环境变量原地降级Author: @FillZpp [2] OpenKruise 从晚期版本开始就反对了 “原地降级” 性能，次要利用于 CloneSet 与 Advanced StatefulSet 两种工作负载上。简略来说，原地降级使得利用在降级的过程中，不须要删除、新建 Pod 对象，而是通过对 Pod 中容器配置的批改来达到降级的目标。 ...

作者：李欣 近十年来互联网技术失去了飞速的倒退，越来越多的行业退出到了互联网的矩阵，由此带来了更为丰盛且简单的业务场景需要，这对于数据利用零碎的性能无疑是微小的挑战。 关系型数据库 MySQL 是利用零碎中最宽泛应用的数据库产品，领有弱小的数据查问和强事务处理能力。在现在的云时代，利用零碎逐步演进到基于云原生 Serverless 架构去进行搭建，因为它具备低成本、高弹性的劣势。但基于 MySQL 的数据存储在 Serverless 架构体系下仍存在一些显著的有余： 弹性扩大能力差。Serverless 场景中一个重要特点是利用负载具备显著的波峰波谷。当面临流量洪峰时，DBA 又须要手动对集群进行扩容以防止集群被打爆；而适逢流量低谷时，则须要对集群进行缩容以节省成本。运维复杂度高。MySQL 搭建须要进行购买集群、装置服务、治理连贯。业务上线后还要关注数据安全、服务可用性、响应工夫等等，用于集群运维的工夫占比会变高，无奈把更多的精力专一于业务研发上。老本高。通常 DBA 须要预估业务规模来当时设定数据库初始容量，当业务申请量未达到预估值时，集群中的资源会始终处于闲置状态，造成资源节约。Serverless DataBaseMySQL 反对的关系模型和其强事务的个性，使其在利用零碎中有十分重要的地位，是目前不可齐全代替的存储组件之一。但若一味地依赖 MySQL 又会使得利用零碎无奈齐全 Serverless 化，不能享受 Serverless 带来的极致弹性。 在阿里外部咱们有一些新的架构实际，那些须要强事务处理的数据仍旧应用关系表存储，而对于非强事务表数据存储，咱们则设计出了一款领有极致弹性的 Serverless 表存储。 对于 Serverless 数据库产品，咱们的设计要求是必须具备以下几个特色： 齐全弹性。 可依据利用负载主动弹性扩缩容，这一个性可为用户带来更经济的计费模式和更丝滑的体验。按量计费。 Serverless 数据库的应用老本次要来自于计算成本和存储老本。用户只需为业务理论产生的存储单元和响应单元付费，节省成本。零运维。 即开即用，无需治理容量、水位、软件降级、内核优化等运维事项，真正让研发专一于业务开发。Serverless 架构在诸多业务场景中都有宽泛的利用实际。例如世纪联华团体在其外围的电商业务中，针对自建 IDC 机房遇到的资源难以估算、零碎部署艰难等痛点问题，将业务实现全面上云并逐渐革新为全 Serverless 架构的中台模式。 世纪联华团体采纳了函数计算+ API 网关+ Tablestore 计划，轻松撑持起了 6.18、双 11 等大促流动。其中，表格存储 Tablestore 作为世纪联华电商零碎的云上 Serverlesss 架构中的外围存储，具备极致弹性、免运维、成本低等劣势。 表格存储 Tablestore 简介表格存储 Tablestore 于 2009 年阿里云成立之初便立项研发，基于底层飞天平台从零开始构建，是一款多模型、多引擎的 Serverless 表存储。在公共云上输入了国内外 30 多个区域，领有 1.5 万服务器规模和 200PB 存储规模，是阿里云泛滥商业化产品的底层外围存储。 同时在线下已输入到金融、能源、电力、物流、医疗、政企等行业，服务于公共云 1000+ 企业客户和 500+ 线下我的项目。 ...

最近几天对于很多开发者而言，只能用争分夺秒与胆战心惊来形容。而造成这所有的源头，来自于被颁布的 Apache Log4j2 近程代码执行破绽（CNVD-2021-95914）。以后简直所有技术巨头都在应用该开源组件，其危害将带来一连串连锁反应。据行业机构不齐全统计，该破绽影响 6w+ 风行开源软件，影响 70% 以上的企业线上业务零碎！破绽波及面、危害水平均堪比 2017 年的让数百万台主机面临被勒索病毒攻打的危险的“永恒之蓝”破绽。 破绽解析Apache Log4j RCE 破绽造成如此大影响的起因，不仅在于其易于利用，更在于其微小的潜在危害性。此次危机由 Lookup 性能引发，Log4j2 在默认状况下会开启 Lookup 性能，提供给客户另一种增加非凡值到日志中的形式。此性能中也蕴含了对于 JNDI 的 Lookup，但因为 Lookup 对于加载的 JNDI 内容未做任何限度，使得攻击者能够通过 JNDI 注入实现近程加载歹意类到利用中，从而造成 RCE。 据悉，Apache Log4j 2.x <= 2.14.1 版本均回会受到影响。可能的受影响利用包含但不限于：Spring-Boot-strater-log4j2、Apache Struts2、Apache Solr、Apache Flink、Apache Druid、Elasticsearch、Flume、Dubbo、Redis、Logstash、Kafka 等。间接利用了 Log4j-core 的依赖中，就蕴含了 SpringBoot、JBoss、Solr 等风行框架。破绽简直影响所有应用 Log4j2 2.15.0 的用户，蕴含 2.15.0-rc1 也曾经有绕过手法流出。 仅需四步，借助阿里云 ARMS 利用平安，全面拦挡 Log4j2 破绽攻打此次 Log4j2 破绽，作为一款日志框架，相比起记录日志等类型的失常行为，进行命令注入、执行，自身就是显著异样行为。 RASP 在默认规定下，会拦挡掉所有因反序列、JNDI 注入导致的命令执行、任意文件读取、歹意文件上传等危险行为。不同于传统基于流量特色的进攻形式，RASP（Runtime Application Self-Protection）基于行为和利用运行时上下文，不会陷入特色穷举并更加关注「失常基线」。即利用的失常应用行为有哪些，如果这个行为（如命令执行）不属于该性能的失常操作，则会进行拦挡。 此次破绽，系 Log4j2 的 JNDI 性能造成的命令执行破绽，处在 RASP 笼罩场景之中，无需新增规定也能默认进攻。因而，ARMS 利用平安基于阿里云 RASP 技术针对上述破绽进行攻打防护。 ...

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区Epel 镜像简介EPEL (Extra Packages for Enterprise Linux), 是由 Fedora Special Interest Group 保护的 Enterprise Linux（RHEL、CentOS）中常常用到的包。 下载地址：阿里云开源镜像站资源目录 epel镜像-epel下载地址-epel装置教程-阿里巴巴开源镜像站 配置办法1. 备份(如有配置其余epel源)mv /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.backupmv /etc/yum.repos.d/epel-testing.repo /etc/yum.repos.d/epel-testing.repo.backup 2. 下载新repo 到/etc/yum.repos.d/ 装置 epel 配置包yum install -y https://mirrors.aliyun.com/epel/epel-release-latest-8.noarch.rpm 将 repo 配置中的地址替换为阿里云镜像站地址 sed -i 's|^#baseurl=https://download.example/pub|baseurl=https://mirrors.aliyun.com|' /etc/yum.repos.d/epel*sed -i 's|^metalink|#metalink|' /etc/yum.repos.d/epel* \

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区mysql镜像简介MySQL Database Service is a fully managed database service to deploy cloud-native applications. HeatWave, an integrated, high-performance analytics engine accelerates MySQL performance by 400x. MySQL数据库服务是一种齐全托管的数据库服务，用于部署云原生应用程序。HeatWave是一个集成的高性能剖析引擎，可将MySQL性能进步400倍。 本文在CentOS零碎中进行装置。 [root@localhost ~]# wget http://repo.mysql.com//mysql57-community-release-el7-7.noarch.rpm--2021-12-24 20:24:00-- http://repo.mysql.com//mysql57-community-release-el7-7.noarch.rpmResolving repo.mysql.com (repo.mysql.com)... 184.50.240.231Connecting to repo.mysql.com (repo.mysql.com)|184.50.240.231|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 8984 (8.8K) [application/x-redhat-package-manager]Saving to: ‘mysql57-community-release-el7-7.noarch.rpm’100%[=============================================>] 8,984 3.15KB/s in 6.9s 2021-12-24 20:24:10 (1.27 KB/s) - ‘mysql57-community-release-el7-7.noarch.rpm’ saved [8984/8984] [root@localhost ~]# rpm -ivh mysql57-community-release-el7-7.noarch.rpmwarning: mysql57-community-release-el7-7.noarch.rpm: Header V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEYPreparing... ################################# [100%]Updating / installing... 1:mysql57-community-release-el7-7 ################################# [100%] ...

\ MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 利用提供可扩大的高性能数据存储解决方案。[]() 下载地址: 阿里云开源镜像站资源目录 配置办法装置（应用yum源装置）\在/etc/yum.repos.d 创立一个mongodb-org.repo源文件 vi /etc/yum.repos.d/mongodb-org.repo 增加内容如下：（配置偶数版本，奇数版不适宜生产应用） [mongodb-org] name = MongoDB Repositorybaseurl = https://mirrors.aliyun.com/mongodb/yum/redhat/$releasever/mongodb-org/3.6/x86_64/gpgcheck = 1 enabled = 1 gpgkey = https：// www.mongodb.org/static/pgp/server-3.6.asc 执行如下命令 cat /etc/yum.repos.d/mongodb-org.repo （查看版本信息命令 hostnamectl）  最初执行命令装置MongoDB  yum install mongodb-org   \

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 咱们在零碎装置软件时都会遇到各种小问题，导致软件装置效率低、老本高，那么如何能力进步咱们在云服务器上的软件装置效率呢？接下来就为大家具体介绍下如何在 CentOS 环境下通过 yum 命令疾速装置软件。 在 CentOS 环境下，咱们能够通过 yum 命令疾速装置软件。对于 yum 下载源，咱们不须要增加任何软件源，就能够间接装置软件包。 yum install 软件名称 在装置软件的过程中，零碎将主动搜寻相干的软件包和依赖关系，并在界面中提醒用户确认搜寻到的软件包是否适合。在这里咱们将以 PHP 为例，进行具体阐明。 更新yum源（默认yum源中无php） rpm -Uvh http://mirror.webtatic.com/yu... 执行 yum -y install php 命令，装置 PHP 后，界面显示如下图：  查看php装置了那些拓展模块 php -m 你也能够执行以下命令，查看软件包的版本信息 rpm -q 软件名 比方执行 rpm -q php ，如下图所示： \

咱们邀请到了阿里云混合云监控平台(Sunfire)团队负责人王肇刚来给咱们剖析下阿里背地的数字化业务运维安全工程规范及解决方案。 本次分享涵盖了全新公布的数字化业务运维安全工程规范、平安生产解决方案，以及全新降级的产品能力：包含了全栈对立运维、全景监控和全周期安全工程相干产品能力的介绍，也蕴含了对产品解决方案在客户侧落地的最佳实际分享。 混合云新一代运维混合云新一代业务运维：数字化业务运维系统工程 在数字化转型的时代背景下，企业在将来5年内将会产生3个变动：业务规模变大、技术变简单、组织职能变得更加标准化。 规模会越来越大，从单个业务上云到多个业务上云，云上资源从百台到千台。这些变动带来的挑战是技术危险导致的影响面扩充、范畴变广、修复老本变高。如果企业外围业务的稳定性呈现了稳定乃至呈现故障，轻则影响体验、口碑并带来客户投入，重则导致微小经济损失，甚至威逼企业的生存。 企业的技术栈越来越简单，从单云到多云，从专有云到混合云；从传统开发到应用新技术开；企业IT零碎的基础架构也是多云环境、多技术栈并存；不同企业的数据的剖析、治理、存储和展示能力也存在差别。这些复杂性带来的挑战是：故障多、定位难、稳定性不可控。已知故障报警量多、未知故障潜伏期长，定界定位慢、响应慢、复原慢，故障无奈铲除。而故障的反复产生会进一步导致影响工夫、范畴和产生频率不可控。 企业组织架构越来越标准化，组织分工标准化，即职责权定义清晰；人员能力标准化，即业余运维常识能力、操作能力、决策能力；协同标准化，即上下级、同级、内外合作标准化；决策架构标准化，即决策架构变动不会的导致技术运维能力的变动。对于刚进入数字化企业来说，组织齐全没有达到这个规范能力，带来的挑战就是：协同难，扯皮多、定非难；山头文化，跨组织跨团队合作难；出问题，找不到责任人；责任不清，问题无人解决。 面向这些变动与挑战，在将来5年里，企业云上业务的“可靠性”和“连续性”成为企业倒退决定性因素。为了助力企业上云、用云过程中应答这些变动和挑战，阿里云混合云平台推出了混合云新一代运维规范：数字化业务运维系统工程，即“全栈对立运维”、“全景可观测”、“全周期安全工程” 三大能力，系统性保障数字化业务安全可靠。 混合云一体化平安生产（安全工程）解决方案 咱们的解决方案涵盖了从监控和预警，到应急解决，到日常继续改良的全过程闭环。即产品能力和服务能力从防、监、管、控四个方面进行构建，全方位保障数字化业务的连续性和可靠性。 防-全周期安全工程， 辨认故障危险， 构建故障主动防御体系；从代码源头开始，严控代码品质和上线规范，通过主动防御型策略、专家知识库、智能危险检测、歹意辨认、危险审计、高危拦挡、集中统一管控、高可用架构等构建被动且齐备的事先防护体系，将业务故障拦于门外。监-全景可观测能力， 建设从业务-利用-云资源全链路监控的能力，发现并定界异样，秒级预警；咱们的产品提供全景监控（业务/利用/云平台）能力。全面反对混合云状态下的客户侧监控需要；提供智能监控（智能基线、黄金指标异样检测等）能力，精准高效地发现故障、并迅速断定故障的级别和影响面，并对故障起因作出定界。同时，咱们也提供报警解决和监控运维联动能力，智能化地收敛与分级报警，并联动运维平台触发故障自愈和利用弹性扩/缩容。管-全栈对立运维， 构建数字化对立业务治理能力；面向双态的业务利用运维，提供业务中台运维、资源调度、作业撑持、集中集成能力，解决企业运维看、管、控的需要，并实现日常运维数字化、智能化。咱们利用利用生命周期中产生的海量数据（零碎，监控，日志，调用链路等数据），通过平台大数据分析以及机器学习，被动探测发现零碎存在的危险，并且提供主动疾速应答能力。能够大幅晋升企业整体运维效率。控-全周期安全工程，疾速解决问题，及时应急复原止损。产品化反对故障复盘与改良打算落地，加固事先主动防御和能力验证；通过应急控制能力，疾速解决问题，及时应急复原止损，管制故障影响面。并对起因复查改良，加固事先主动防御，并常态进行常态化有效性验证（演练、压力测试），从而造成一直迭代，继续晋升的平安生产能力。数字化智能监控运维平安产品性能矩阵 如图所示，平安生产解决方案须要十分多的产品能力反对，图上显示了反对解决方案背地的产品能力。这是若干年来反对阿里巴巴双十一的产品能力，也经验了多年双十一和日志技术危险战火的洗礼，目前也从属于阿里云云效监控运维畛域的产品序列，提供给各位企业客户应用。 云效监控运维域产品能力降级继续可观测系统化：Sunfire2.0智能全景监控平台 监控是零碎的眼睛，咱们通过眼睛看到问题能力做定界和解决。咱们监控平台的设计理念是智能化全景监控平台，是围绕阿里巴巴平台技术危险体系中的1-5-10理念来设计的。咱们通过业务监控发现问题并触发应急响应，这和传统运维理念中对系统资源的监控是有差别的。阿里团体的应急响应不会是因为某一个CPU温度过高、某一个磁盘使用率过高或者IO过高导致的零碎级指标告警引起的。阿里团体有千万级别的线上容器和主机，也有千万级别的监控项和报警。阿里团体监控是以业务监控触发为外围，即业务监控触发报警当前，须要有高效的事件处理核心产品能力，把零碎级指标报警、利用级报警和业务级报警有机关联归集起来，把业务报警进行断定和降级送入咱们的故障台，故障台向团体发应急通告，整个闭环是从发现到解决到故障降级。产生故障之后，咱们能够马上进行问题的定界并复原，全景监控能够把问题锁定到某一个环节执行预案，再通过运维平台发动预案执行让零碎复原稳固，这个故障就被毁灭在萌芽阶段了。 业务监控能力降级 在业务指标监控畛域，咱们有一个超级武器，秒级监控。做过监控的同学都有体感，监控零碎的数据迟延在秒级粒度时，监控曲线往往会有很多抖动。因而，秒级监控必须有智能化的监控策略作为辅助，否则会造成大量误报。把之前的智能基线能力全新降级为黄金指标异样检测能力后，零碎会帮咱们简便的自动化配出黄金指标，能监控业务的量、率和耗时以及相应的组合策略，不须要配置人工预制，通过机器学习的算法就能自动化通过监控发现业务问题。 往年的阿里巴巴双十一预售曾经开始，消费者的热情高涨，特地是薇娅和李佳琪两个大V做的直播给咱们的零碎带来了很大的流量冲击，淘宝的外围业务指标也的确呈现了一个渺小的稳定。咱们的秒级监控和智能报警的策略耗时47秒，从事件的产生到最初全局预警通告只花了47秒，触发了咱们零碎的快恢，这个故障还没有到故障级别就被毁灭在无形之中，以至于很多消费者都来不及感知。 咱们的监控能力会尽可能先于用户发现业务的问题。咱们在业务链路的形容上和在大屏的展现上都有全新的能力降级，这背地是自研的大规模、分布式监控施行的引擎和智能化工程策略框架的反对。 利用和云资源监控能力降级 业务监控发现问题后做定界，这时就要看运行业务的利用和云资源的状态。咱们全新降级利用的发现能力、利用链追踪的能力和云资源监控能力后能够监控客户利用、从业务指标到业务状态、云资源的状态，利用调用其余利用、其余中间件的状态、剖析链路、智能化发现利用、第三方组件云资源的关联。 在云原生的理念下，企业采纳K8S作为本人PAAS层的运维形式，可能被开源的Prometheus监控的对象能够间接被Sunfire平台监控并享受到Sunfire智能化的策略和弱小的监控计算及存储能力。 报告（事件）和故障治理能力降级 发现问题后须要高效解决，而高效的应急解决须要事件核心和故障台一起联动，让事件无效被治理升高误报缩小工夫损耗，也能够通过故障台进行高效的应急和响应。通过故障台治理后，很多故障处理过程从开始的零乱不堪到最初参差高效解决，处理过程由不见变成可察看可度量。 云效监控运维域产品能力降级100%IT运维数字化：Normandy智能运维平台产品架构 上图是Normandy平台的全新降级，面向混合云客户做到反对跨云治理的先进架构，自动化运维公布、自动化治理、扩缩容能力，也反对了阿里双十一海量利用运维的挑战。 智能化运维能力降级 运维平台在智能化层面做了三大降级：一是弹性扩缩容能力。利用级智能的弹性扩缩容，依据应用程序的状态领导扩缩容是运维过程中最优的抉择，咱们Normandy平台就能提供这样的能力。针对公布过程中的危险，咱们提出无人值守公布的理念，在公布过程中监控发现潜在问题。咱们在灰度公布进行到很小范畴的时候就能够发现问题，进行拦挡防止问题扩大化。真正呈现问题的时候平台能够执行原子的自愈能力和凋谢的能力扩大，做到跟客户的场景相结合，实现客户场景下的快恢操作。 经营指挥大屏 有时须要对于业务和利用做全局态势的感知，咱们有运行指挥大屏的能力，对运行零碎的数据、工单数据和报警数据做展示，联合客户场梳理到全局态势的感知。在大型流动保障时做经营指挥顾问，这跟阿里巴巴双十一指挥大屏的理念是统一的。 数字化业务安全工程平台—护城河 大家会在新闻中看到，“删库跑路”这类新闻。阐明咱们的在运维平安层面面临了很大的危险，安全工程平台反对多云平台下运维操作集中管控和平安审计、危险的管制。咱们称其为“护城河”，它是咱们的外围能力，能够集中管控运维的治理和通路并且符合国家平安等保的规范。 白屏/黑屏化平安防护能力 咱们护城河体系能够同时反对白屏化和黑屏化场景，进行平安防护。无论是资源管理受权对立管控、基于多终端运维形式，还是对于多协定运维搀扶下保障客户实现平安防护。咱们反对在指定的窗口下进行身份认证躲避危险。阿里巴巴团体有数万名技术员工通过操作咱们的线上零碎，护城河体系实现了整个的危险管控，也为阿里技术体系解决了运维操作的危险管制问题。当初，咱们也把它放到云效监控运维的产品体系中提供给企业客户应用。咱们平安审计的能是符合国家等保要求的。通过对过程对立管控记录运维操作的状况发现外面的危险隐患。护城河平台基于智能化的能力做到了基于动静智能化发现潜在危险能力。案例分享Sunfire在能源行业的案例 上图是和咱们和国家电网做的策略单干。国家电网的营销零碎1.0的传统架构迁徙到2.0面向混合云的架构，大家在日常生活中交电费、查电费、充值电费等都能够通过小程序在云端运行了。国网营销2.0零碎在云上是由全景监控平台Sunfire对数百个利用、数千个业务指标进行全面的监控。国网营销2.0零碎的报警解决机制以业务监控为入口，疾速定界和解决的模式。这种模式使日常的报警质变少了，比方几个月前呈现了线上的危险，咱们高效的发现触发应急解决问题，国网领导也给咱们平台发了感谢信，是对咱们很好的必定和反对。 经营指挥核心在证券行业案例 上图是咱们跟证券的头部企业进行单干的利用指挥的案例。这实现了证券指挥大屏在运行企业的落地。在大屏上有证券企业的外围业务流程，从整体的业务看到了利用和资源，线上交易呈现问题能够通过多维下算的形式找到问题呈现的细分业务畛域，能看到经营的状态和云资源利用的状态。 我和客户共建大屏时，首先对客户侧所有的场景进行梳理形象出业务场景散发到大屏、中屏上，让客户进行不同的问题定位，设计成千上万的业务指标汇聚在经营大屏上，背地是依据客户异构的数据源，不同实效性的数据做主动归置和对齐，这种高效实时的解决机制是咱们在证券行业十分好的落地。 本次内容就到这里，咱们也心愿在咱们的新一代运维安全工程规范指引下，咱们的平安生产解决方案和产品能力可能反对和服务更多的企业客户，一起让企业的云上业务运维**更加高效、更加牢靠、更加稳固！ 点击下方链接，查看AIOps智能监控解决方案！ https://www.aliyun.com/solution/aiops/index?spm=a2c6h.12873639.0.0.1e507128bimM3a 对于咱们理解更多对于云效DevOps的最新动静，可微信搜寻关注【云效】公众号； 彩蛋：公众号后盾回复【指南】，可取得《阿里巴巴DevOps实际指南》&《10倍研发效力晋升案例集》； 看完感觉对您有所帮忙别忘记点赞、珍藏和关注呦；

无论从开发运维还是产品经营的角度来看，任何一次上线都是有危险的。从最根本的利用进行导致流量失落、服务不可用、服务QPS水位降落，到步骤的脱漏、流程的不标准、开发过程中引入的bug，以及新产品/新性能上线导致用户体验的变动，都会导致线上危险。在日常和用户交换过程中，咱们也常常会被用户问到对于公布的问题，比方不同职能团队之间应该如何配合、公布的最佳实际应该是什么样子的等等。明天咱们就来聊聊常见利用公布形式的抉择，以及每种公布模式适宜什么样的场景。 平滑降级：滚动公布分批公布通常指取出一例或多例利用实例，将其进行服务、降级到新版本；周而复始地反复这一过程，直到所有实例都降级到新版本。应用滚动公布，能够最大水平地防止因公布导致的流量失落和服务不可用问题；这一模式也是Kubernetes利用部署应用的缺省模式。 针对部署规模较小、畛域边界较清晰，同时面临业务疾速倒退变动的微服务利用，滚动公布流程繁难且可靠性较高。不过因为通常状况下不足强干涉伎俩，公布的可逆水平较差；一旦在公布过程中觉察到问题，往往须要进行全量回滚。 一般来说，滚动公布实用于合乎如下条件的场景： 利用部署规模较小、启动和回滚的速度较快；利用所关注的业务畛域范畴绝对小、边界较清晰，且易于进行线上回归验证；公布人员充沛了解、把握平台所提供的滚动公布策略；新版本引入的变更，具备向下兼容性。上面咱们别离以ECS和Kubernetes为例，展现如何在云效平台上进行滚动公布。 面向ECS的滚动公布在云效中，咱们能够应用主机部署工作进行滚动公布。如图所示，假如须要对以下由2台ECS形成的主机组进行滚动公布，每次滚动更新1台主机： 在流水线中，配置主机部署工作： 设置“暂停形式”为“不暂停”、“分批数量”为2，即可实现滚动公布。 在进行ECS滚动公布时须要留神一点：通常状况下，滚动公布中的主机无奈对外提供服务，这意味着集群整体服务水位（如可承接的QPS）会升高——例如在下面2台主机分2批公布的过程中，集群始终只有1台主机能够响应申请，整体QPS水位降落了50%。公布人员须要认真评估“因为公布而导致服务主机不可用”对服务水位的影响，并抉择适合的工夫（如业务低峰期）进行公布。 原生反对：Kubernetes YAML滚动公布YAML公布是咱们在应用Kubernetes时最间接的利用部署形式。在继续交付流水线中，咱们个别将这些用于形容Kubernetes资源的YAML文件通过Git进行对立版本治理，通过云效CI/CD平台监听代码库的变更事件，并通过流水线将这些YAML变更同步到集群当中。 例如上面的app.yaml： apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: ${IMAGE} ports: - containerPort: 80因为没有申明公布策略，Kubernetes会缺省指定RollingUpdate策略，也即滚动公布。 YAML文件中的占位符${IMAGE}是为云效流水线专门留出的替换变量，公布时会被替换成具体的镜像。 如下图所示，咱们能够通过“Kubernetes公布”工作实现上述Deployment的滚动公布： 具体的公布进度，能够参考公布单中的展现： 极简体验：Kubernetes镜像降级在一些开发团队与运维团队分工较为明确的场景中，开发团队可能心愿够尽可能少地了解Kubernetes相干概念，由专职的运维团队负责实现应用环境的部署和初始化；开发团队只负责实现代码开发，并通过流水线自动化实现利用镜像构建，并应用该镜像对集群中已有的利用进行降级。 如下图所示，在云效流水线中，咱们监听利用代码库的变动，并构建出相应的Docker镜像；公布阶段只须要指定对集群中实例并关联前序工作产生的镜像，即可实现利用的降级公布。与YAML公布雷同，缺省状况下，镜像降级也应用了滚动公布模式： 如上所述，该场景实用于： 开发和运维拆散：运维团队充沛了解Kubernetes的原生公布策略，开发团队只负责产出代码以及利用镜像，由运维团队负责集群中利用的理论运维治理过程可控：分批公布分批公布通常指取出一批利用实例，将其进行服务、降级到新版本；人工察看实际效果合乎冀望后，再取出下一批；周而复始地反复这一过程，直到所有实例都降级到新版本。在滚动过程中，新旧版本共存且等同地承受流量、提供服务；公布人员基于对服务质量（如申请成功率、响应工夫等根底指标，或特定的业务成功率等业务指标）进行察看，决定是否进一步扩充新版本部署比例，或是放弃公布进行回滚。 分批公布的基本模式与滚动公布类似，次要差别则在于容许人工控制新版本上线、老版本下线的过程。因为新版本的部署比例可控，公布人员能够事后制订批次部署打算，在大量部署的新版本上，基于生产环境流量进行小规模线上验证；若利用本身规模较大或逻辑较简单，维持一段时间的小规模验证也能起到线上回归测试的作用。另一方面，人工控制部署批次使得公布整体具备较好的可逆性：一旦在小规模验证中发现问题，能够疾速回滚曾经公布的新版本。 分批公布通常适宜： 利用在业务链路中较为要害，部署规模较大，业务逻辑较简单；进行线上验证时，难以圈定灰度流量，须要应用较少比例的新版本部署进行验证，以期管制危险影响面；新版本引入的变更，具备向下兼容性。面向ECS的分批公布在云效中，主机部署工作也能够被配置为分批公布模式，如下图所示： 咱们能够通过指定“第一批暂停”或“每批暂停”，实现分批管制： 若指定“每批暂停”，则每一批公布实现后，都须要人工确认前方可公布下一批。这种模式适宜须要全程管制公布节奏的场景，通过逐渐察看线上指标，逐渐确认新版本的正确性；或是有明确的公布打算，如“先部署1批（占比10%）、夜间业务低峰期+次日9-11点业务高峰期察看无问题后，按30%、50%、80%、100%实例数递进部署，每批进展不少于30分钟，期间察看线上指标，若呈现问题则回滚”。若指定“第一批暂停”，则只有第一批公布完结后，会期待公布人员确认；一经确认，尔后的各批次将主动部署，与滚动公布相似。这种模式联合了滚动公布的简便性，以及分批公布的小规模验证、疾速回滚能力，通常实用于“先进行一批小规模线上验证，验证通过后即可全量公布”的场景。公布人员可依据利用的部署规模、重要水平及逻辑的复杂程度，选用不同的分批暂停模式。 面向Kubernetes的分批公布云效的分批公布中，咱们以Service为最小公布单元，在公布开始阶段咱们将基于新版镜像创立出利用的版本V2，并依据以后利用的正本总数以及分批数量，对新旧两个版本的利用实例别离进行缩容和扩容，来管制理论进入到新版利用的流量比例，从而能够实现小规模的公布验证，在对公布进行充沛验证后，再逐渐齐全下线老版利用。 与ECS部署相似，批次之间反对暂停和手动复原，用以对公布过程进行管制。 该模式实用于：采纳Kubernetes原生的服务发现机制，并心愿取得相比于原生Kubernetes公布更好过程控制性以及安全性的用户。 流量可控：灰度公布较之滚动/分批公布，灰度公布增强了对线上验证影响范畴的管制：通常须要以同样的实例数，部署新/老版本两套服务；再通过流量散发管制伎俩，将特定的线上流量导入新版本、其余流量依然流入老版本；线上验证通过后，所有流量都将导入新版本实例，而老版本实例则可用作下一次公布的模板。 常见的流量散发管制伎俩如： ...

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) pouch镜像-pouch下载地址-pouch装置教程-阿里巴巴开源镜像站 (aliyun.com) 二、pouch镜像简介阿里巴巴正式开源了基于Apache 2.0协定的容器技术Pouch。Pouch是一款轻量级的容器技术，领有疾速高效、可移植性高、资源占用少等个性，次要帮忙阿里更快的做到外部业务的交付，同时进步超大规模下数据中心的物理资源利用率。阿里巴巴正式开源自研容器技术Pouch-阿里云开发者社区 (aliyun.com) 三、pouch镜像配置办法（基于CentOS 7系统配置）1、查看主机名[root@centos ~]# hostnamectl Static hostname: centos Icon name: computer-vm Chassis: vm Machine ID: f6fc8fb7991c4c518238af7c75f16046 Boot ID: a5342490e7fd4891978ea3b2e7e0aaf1 Virtualization: vmware Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-1160.el7.x86_64 Architecture: x86-64[root@centos ~]#2、增加镜像文件[root@centos ~]# vim /etc/yum.repos.d/pouch-centos7.repo[root@centos ~]# cat /etc/yum.repos.d/pouch-centos7.repo[pouch-stable]name=Pouch Stable - $basearchbaseurl=http://mirrors.aliyun.com/opsx/pouch/linux/centos/7/$basearch/stableenabled=1gpgcheck=1gpgkey=http://mirrors.aliyun.com/opsx/pouch/linux/centos/gpg[pouch-test]name=Pouch Test - $basearchbaseurl=http://mirrors.aliyun.com/opsx/pouch/linux/centos/7/$basearch/testenabled=0gpgcheck=1gpgkey=http://mirrors.aliyun.com/opsx/pouch/linux/centos/gpg[root@centos ~]#3、更新YUM源将软件包信息提前在本地索引缓存 ，用来进步搜寻装置软件的速度,倡议执行这个命令能够晋升yum装置的速度[root@centos ~]# yum clean allLoaded plugins: fastestmirrorCleaning repos: base extras pouch-stable updatesCleaning up list of fastest mirrorsOther repos take up 145 M of disk space (use --verbose for details)[root@centos ~]# yum makecacheLoaded plugins: fastestmirrorDetermining fastest mirrors * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.combase | 3.6 kB 00:00:00 extras | 2.9 kB 00:00:00 pouch-stable | 2.9 kB 00:00:00 updates | 2.9 kB 00:00:00 (1/13): base/7/x86_64/group_gz | 153 kB 00:00:00 (2/13): base/7/x86_64/filelists_db | 7.2 MB 00:00:01 (3/13): extras/7/x86_64/primary_db | 243 kB 00:00:00 (4/13): extras/7/x86_64/filelists_db | 259 kB 00:00:00 (5/13): pouch-stable/x86_64/primary_db | 8.0 kB 00:00:00 (6/13): extras/7/x86_64/other_db | 145 kB 00:00:00 (7/13): pouch-stable/x86_64/other_db | 1.4 kB 00:00:00 (8/13): pouch-stable/x86_64/filelists_db | 3.1 kB 00:00:00 (9/13): base/7/x86_64/other_db | 2.6 MB 00:00:00 (10/13): base/7/x86_64/primary_db | 6.1 MB 00:00:02 (11/13): updates/7/x86_64/filelists_db | 7.0 MB 00:00:01 (12/13): updates/7/x86_64/other_db | 903 kB 00:00:00 (13/13): updates/7/x86_64/primary_db | 13 MB 00:00:02 Metadata Cache Created[root@centos ~]#4、装置pouch[root@centos ~]# yum install pouchLoaded plugins: fastestmirrorLoading mirror speeds from cached hostfile * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.comResolving Dependencies--> Running transaction check---> Package pouch.x86_64 0:1.3.0-1.el7 will be installed--> Processing Dependency: pam-devel for package: pouch-1.3.0-1.el7.x86_64--> Processing Dependency: fuse-devel for package: pouch-1.3.0-1.el7.x86_64--> Running transaction check---> Package fuse-devel.x86_64 0:2.9.2-11.el7 will be installed---> Package pam-devel.x86_64 0:1.1.8-23.el7 will be installed--> Finished Dependency ResolutionDependencies Resolved======================================================================================================================== Package Arch Version Repository Size========================================================================================================================Installing: pouch x86_64 1.3.0-1.el7 pouch-stable 44 MInstalling for dependencies: fuse-devel x86_64 2.9.2-11.el7 base 37 k pam-devel x86_64 1.1.8-23.el7 base 185 kTransaction Summary========================================================================================================================Install 1 Package (+2 Dependent packages)Total download size: 45 MInstalled size: 146 MIs this ok [y/d/N]: yDownloading packages:(1/3): fuse-devel-2.9.2-11.el7.x86_64.rpm | 37 kB 00:00:00 (2/3): pam-devel-1.1.8-23.el7.x86_64.rpm | 185 kB 00:00:00 warning: /var/cache/yum/x86_64/7/pouch-stable/packages/pouch-1.3.0-1.el7.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID 439ae9ec: NOKEYPublic key for pouch-1.3.0-1.el7.x86_64.rpm is not installed(3/3): pouch-1.3.0-1.el7.x86_64.rpm | 44 MB 00:00:07 ------------------------------------------------------------------------------------------------------------------------Total 5.7 MB/s | 45 MB 00:00:07 Retrieving key from http://mirrors.aliyun.com/opsx/pouch/linux/centos/gpgImporting GPG key 0x439AE9EC: Userid : "Pouch Release <pouch-dev@list.alibaba-inc.com>" Fingerprint: b615 ddd7 90c7 0912 582d dc2d d7ae a5ed 439a e9ec From : http://mirrors.aliyun.com/opsx/pouch/linux/centos/gpgIs this ok [y/N]:y``````装置过程省略``````Installed: pouch.x86_64 0:1.3.0-1.el7 Dependency Installed: fuse-devel.x86_64 0:2.9.2-11.el7 pam-devel.x86_64 0:1.1.8-23.el7 Complete![root@centos ~]# rpm -qa | grep pouchpouch-1.3.0-1.el7.x86_64[root@centos ~]# ...

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 1、什么是NTP服务NTP是网络工夫协定(Network Time Protocol)，它是用来同步网络中各个计算机的工夫的协定。 2、Liunx罕用工夫命令查看零碎工夫date查看硬件工夫hwclock 3、装置配置NTP服务（1） 查看是否装置NTP服务 rpm -qa|grep ntp （2） 若没有装置，执行如下命令装置NTP服务 yum install -y ntp 配置阿里云NTP服务1关上open terminal 2执行命令sudo vi /etc/ntp.conf关上并编辑NTP服务配置文件。 3找到server ntp 服务器 iburst的信息后，输出i开始编辑文件，给您临时不须要的NTP服务器句首加上#暗藏起来。 新增加一行NTP服务器信息，格局为：server 您须要增加的NTP服务器 iburst。实现编辑后按下Esc键退出输出:wq保留退出。 执行命令sudo service ntpd start启动自定义的NTP服务。 执行命令chkconfig ntpd on设置开机自启动NTP服务。 执行命令ntpstat查看是否启动了NTP服务。   执行命令systemctl status ntpd查看ntp服务是否失常

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) mysql镜像-mysql下载地址-mysql装置教程-阿里巴巴开源镜像站 (aliyun.com) 二、MySQL简介MySQL数据库服务是一种齐全托管的数据库服务，用于部署云原生应用程序。HeatWave是一个集成的高性能剖析引擎，可将MySQL性能进步400倍。下载地址：https://mirrors.aliyun.com/my... 三、MySQL装置# 下载安装mysql的repo源（基于CentOS零碎下）[root@centos ~]# wget http://repo.mysql.com//mysql57-community-release-el7-7.noarch.rpm--2021-12-24 20:47:58-- http://repo.mysql.com//mysql57-community-release-el7-7.noarch.rpmResolving repo.mysql.com (repo.mysql.com)... 23.58.112.230Connecting to repo.mysql.com (repo.mysql.com)|23.58.112.230|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 8984 (8.8K) [application/x-redhat-package-manager]Saving to: 鈥榤ysql57-community-release-el7-7.noarch.rpm鈥?100%[==============================================================================>] 8,984 --.-K/s in 0s2021-12-24 20:47:58 (80.1 MB/s) - 鈥榤ysql57-community-release-el7-7.noarch.rpm鈥?saved [8984/8984]# 装置mysql的repo源[root@centos ~]# rpm -ivh mysql57-community-release-el7-7.noarch.rpmwarning: mysql57-community-release-el7-7.noarch.rpm: Header V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEYPreparing... ################################# [100%]Updating / installing... 1:mysql57-community-release-el7-7 ################################# [100%][root@centos ~]#装置MySQL [root@centos ~]# yum install -y mysql-server mysql-devel mysql[root@centos ~]# rpm -qa | grep mysqlmysql-community-server-5.7.36-1.el7.x86_64mysql57-community-release-el7-7.noarchmysql-community-common-5.7.36-1.el7.x86_64mysql-community-client-5.7.36-1.el7.x86_64mysql-community-devel-5.7.36-1.el7.x86_64mysql-community-libs-5.7.36-1.el7.x86_64mysql-community-libs-compat-5.7.36-1.el7.x86_64[root@centos ~]# ...

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区Centos7 默认是没有图形化界面的，但咱们很多人在习惯了 Windows 的图形化界面之后，总是心愿有一个图形化界面从而不便咱们应用，这里介绍一下 装置完CentOS７镜像后，装置图形化桌面零碎的办法。 1进入 root 模式因为权限限度，所以咱们须要进入 root 模式，开机应用 root 登陆或者零碎运行中切换为 root 用户均可。   2装置  X 窗口零碎1、首先装置X(X Window System)，命令为 yum groupinstall "X Window System" 留神有引号  而后零碎会主动寻找最近的网络进行相干文件的下载  抉择 y，开始进行装置 当呈现 Complete！阐明这里装置胜利了。 在这里检查一下咱们曾经装置的软件以及能够装置的软件，命令为 yum grouplist  再输出 yum groupinstall "GNOME Desktop" yum groupinstall "Graphical Administration Tools" 当呈现进展时按 y 特地留神！名称必须对应， 否则会呈现No packages in any requested group available to install or update 的谬误 。 这是因为不同版本的CentOS的软件名可能不同（其余 Linux 零碎也是相似的） 最初期待装置实现。 ...

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区在VM虚拟机下进行装置，虚拟机装置比拟容易，上一篇文章已具体说，须要留神的是，如果在虚拟机下装置举荐应用网络桥接模式，让其自动识别物理网络IP，这样会更加不便，装置实现后，默认禁用了网卡设施，在桥接模式下，能够进入到指定配置文件批改参数实现配置。 须要留神，凡是更改配置信息，都必须为root用户操作。普通用户没有权限，须要先获取root权限， 1:登录root用户， 2获取权限后，本机还是无奈连贯外网下载任何文件的。当初须要在root管理员权限下\(1)输出 ip addr 查看网卡名字 如下网卡名字是ens33 （也能够先ping一个公网ip 如114.114.114.114，如果能Ping通则能够连贯外网，如果ping不通会提醒 Unreachable。或者 Network is unreachable）  (2)批改网络信息配置文件 输出\vi /etc/sysconfig/network-scripts/ifcfg-ens33\将ONBOOT=NO改成ONBOOT=yes 按i键呈现Insert 批改，esc退出批改，:wq 保留退出。  3通过上一步你的centos应该就能够连贯外网了。 \

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) golang镜像-golang下载地址-golang装置教程-阿里巴巴开源镜像站 (aliyun.com) GO语言装置以及国内镜像 - DbWong_0918 - 博客园 (cnblogs.com) 二、Go介绍Golang(又称Go)是Google公司开发的一种动态强类型、编译型、并发型，并具备垃圾回收性能的编程语言。下载地址：https://mirrors.aliyun.com/go... 三、下载Go安装包https://mirrors.aliyun.com/go... 四、Windows零碎下装置Go 装置Go实现后，在CMD中输出go，输入如下信息，则装置胜利。 ✅ Microsoft Windows [版本 10.0.19042.1237](c) Microsoft Corporation。保留所有权力。C:\Users\xyb>goGo is a tool for managing Go source code.Usage: go <command> [arguments]The commands are: bug start a bug report build compile packages and dependencies clean remove object files and cached files doc show documentation for package or symbol env print Go environment information fix update packages to use new APIs fmt gofmt (reformat) package sources generate generate Go files by processing source get add dependencies to current module and install them install compile and install packages and dependencies list list packages or modules mod module maintenance run compile and run Go program test test packages tool run specified go tool version print Go version vet report likely mistakes in packagesUse "go help <command>" for more information about a command.Additional help topics: buildconstraint build constraints buildmode build modes c calling between Go and C cache build and test caching environment environment variables filetype file types go.mod the go.mod file gopath GOPATH environment variable gopath-get legacy GOPATH go get goproxy module proxy protocol importpath import path syntax modules modules, module versions, and more module-get module-aware go get module-auth module authentication using go.sum packages package lists and patterns private configuration for downloading non-public code testflag testing flags testfunc testing functions vcs controlling version control with GOVCSUse "go help <topic>" for more information about that topic.C:\Users\xyb>输出go version 查看版本信息。 ...

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) zabbix镜像-zabbix下载地址-zabbix装置教程-阿里巴巴开源镜像站 (aliyun.com) 二、Zabbix简介Zabbix 是一个基于 WEB 界面的提供分布式系统监督以及网络监督性能的企业级的开源解决方案。它能监督各种网络参数，保障服务器零碎的平安经营；并提供灵便的告诉机制以让系统管理员疾速定位/解决存在的各种问题。下载地址：https://mirrors.aliyun.com/za... 三、Zabbix监控平台装置步骤1、登录centos零碎C:\Users\xybdiy>ssh root@192.168.200.50root@192.168.200.50's password:Last login: Fri Dec 24 22:31:27 2021[root@centos ~]# hostnamectl Static hostname: centos Icon name: computer-vm Chassis: vm Machine ID: f6fc8fb7991c4c518238af7c75f16046 Boot ID: daae3878cb56458bac0b89acff8aa851 Virtualization: vmware Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-1160.el7.x86_64 Architecture: x86-64[root@centos ~]#2、敞开防火墙和SELINUX平安模式# 敞开防火墙[root@centos ~]# systemctl stop firewalld[root@centos ~]# systemctl disable firewalld# 敞开SELINUX平安模式（重启失效）[root@centos ~]# setenforce 0[root@centos ~]# cat /etc/selinux/config# This file controls the state of SELinux on the system.# SELINUX= can take one of these three values:# enforcing - SELinux security policy is enforced.# permissive - SELinux prints warnings instead of enforcing.# disabled - No SELinux policy is loaded.SELINUX=disabled# SELINUXTYPE= can take one of three values:# targeted - Targeted processes are protected,# minimum - Modification of targeted policy. Only selected processes are protected.# mls - Multi Level Security protection.SELINUXTYPE=targeted[root@centos ~]#reboot[root@centos ~]# getenforceDisabled3、更新YUM源为阿里云镜像源[root@centos ~]# yum clean allLoaded plugins: fastestmirrorRepodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fastCleaning repos: base extras updatesCleaning up list of fastest mirrors[root@centos ~]# yum makecacheLoaded plugins: fastestmirrorDetermining fastest mirrors * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.combase | 3.6 kB 00:00:00extras | 2.9 kB 00:00:00updates | 2.9 kB 00:00:00(1/10): base/7/x86_64/group_gz | 153 kB 00:00:00(2/10): base/7/x86_64/filelists_db | 7.2 MB 00:00:01(3/10): extras/7/x86_64/filelists_db | 259 kB 00:00:00(4/10): extras/7/x86_64/primary_db | 243 kB 00:00:00(5/10): extras/7/x86_64/other_db | 145 kB 00:00:00(6/10): base/7/x86_64/other_db | 2.6 MB 00:00:00(7/10): base/7/x86_64/primary_db | 6.1 MB 00:00:02(8/10): updates/7/x86_64/filelists_db | 7.0 MB 00:00:01(9/10): updates/7/x86_64/other_db | 903 kB 00:00:00(10/10): updates/7/x86_64/primary_db | 13 MB 00:00:02Metadata Cache Created[root@centos ~]#4、装置LNMP环境[root@centos ~]# yum install httpd httpd-devel mariadb mariadb-server mariadb-devel php-common php-gd php-mbstring php-xml php-bcmath php-mysql php-cli php-devel php-pear -y ...

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区Pouch 镜像简介PouchContainer is a highly reliable container engine open sourced by Alibaba. It is an excellent software layer to fill up gap between business applications and underlying infrastructure. The strong-isolation ability and rich container are its representitive features. 下载地址：阿里云开源镜像站资源目录 配置办法OS反对pouch 的二进制安装包目前曾经反对在 centos7 和 ubuntu (16.04 和 14.04)上的装置, 您能够参考以下配置手册从 opsx 站点疾速的获取安装包。 Centos 7增加文件 /etc/yum.repos.d/pouch-centos7.repo 内容如下： [pouch-stable]name=Pouch Stable - $basearchbaseurl=http://mirrors.aliyun.com/opsx/pouch/linux/centos/7/$basearch/stableenabled=1gpgcheck=1gpgkey=http://mirrors.aliyun.com/opsx/pouch/linux/centos/gpg[pouch-test]name=Pouch Test - $basearchbaseurl=http://mirrors.aliyun.com/opsx/pouch/linux/centos/7/$basearch/testenabled=0gpgcheck=1gpgkey=http://mirrors.aliyun.com/opsx/pouch/linux/centos/gpg 而后执行 yum makecacheyum install pouch 即可装置 pouch 了。 ...

  阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区CentOS 镜像简介CentOS，是基于 Red Hat Linux 提供的可自在应用源代码的企业级 Linux 发行版本；是一个稳固，可预测，可治理和可复制的收费企业级计算平台。 下载地址: 阿里云开源镜像站资源目录\阿里云开源镜像站资源目录 配置办法1. 备份mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup 2. 下载新的 CentOS-Base.repo 到 /etc/yum.repos.d/CentOS 7 wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo 3. 运行 yum makecache 生成缓存 4. 其余非阿里云ECS用户会呈现 Couldn't resolve host 'mirrors.cloud.aliyuncs.com' 信息，不影响应用。用户也可自行批改相干配置: eg: sed -i -e '/mirrors.cloud.aliyuncs.com/d' -e '/mirrors.aliyuncs.com/d' /etc/yum.repos.d/CentOS-Base.repo

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 CentOS，是基于 Red Hat Linux 提供的可自在应用源代码的企业级 Linux 发行版本；是一个稳固，可预测，可治理和可复制的收费企业级计算平台。 下载地址: 阿里云开源镜像站资源目录\阿里云开源镜像站资源目录 虚拟机硬件配置好之后，接下来正式装置操作系统。 镜像文件：CentOS-7-x86_64-bin-DVD1.iso 1点击 「编辑虚拟机设置」 2在弹出的菜单里，从右边抉择 「CD/DVD(SATA)」 ，而后在左边抉择「应用ISO镜像文件」，再点击浏览，找到镜像。  3之后点击确定，再点击「开启虚拟机」 。  4 进入CentOS装置界面。   --抉择第一项 Install CentOS 7  5WELCOME TO CENTOS 7.        设置语言--中文--点击持续  6开始装置。 7设置ROOT明码 接下来能够创立用户（此处能够不进行创立，装置实现后进入root也能够从新创立）  8 centos 7装置实现--点击重启应用

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) packman镜像-packman下载地址-packman装置教程-阿里巴巴开源镜像站 (aliyun.com) 二、PackMan 镜像介绍Packman 是 OpenSUSE 最大的第三方软件源，次要为 OpenSUSE 提供额定的软件包，包含音视频解码器、多媒体利用、游戏等。下载地址：https://mirrors.aliyun.com/packman/ Packman 和 openSUSE 的关系 _ Packman 不隶属于任何 openSUSE 官网，是独立于 openSUSE 社区之外的社区，只是基于 openSUSE 打给 openSUSE 用的软件包。留神 openSUSE 社区也是官网，同样有在专利法最为严苛的美国和欧洲注册，这也是为什么 OBS 不能打包专利软件的起因，另一个起因是 OBS 的服务器坐落于德国诺伦堡。 _ 参考链接：Packman - openSUSE Wiki 三、PackMan 镜像配置办法1、登录OpenSUSE平台 2、更新软件源以openSUSE Leap 15.3为例 localhost:~ # hostnamectl Static hostname: n/aTransient hostname: localhost Icon name: computer-vm Chassis: vm Machine ID: 456345e7fb8a44d6964f2a5ca582aeda Boot ID: ca9865d0f9ac4c918d218418be34d843 Virtualization: vmware Operating System: openSUSE Leap 15.3 CPE OS Name: cpe:/o:opensuse:leap:15.3 Kernel: Linux 5.3.18-59.10-default Architecture: x86-64localhost:~ #（1）应用命令增加packman源✨localhost:~ # zypper ar https://mirrors.aliyun.com/packman/suse/openSUSE_Leap_15.3/ PackmanAdding repository 'Packman' ......................................................................................[done]Repository 'Packman' successfully addedURI : https://mirrors.aliyun.com/packman/suse/openSUSE_Leap_15.3/Enabled : YesGPG Check : YesAutorefresh : NoPriority : 99 (default priority)Repository priorities are without effect. All enabled repositories share the same priority. ...

近日，工信部公布通报，阿里云公司发现 Apache Log4j2 组件重大安全漏洞隐患后，未及时向电信主管部门报告，未无效撑持工信部发展网络安全威逼和破绽治理。经钻研，暂停阿里云公司作为上述单干单位 6 个月。暂停期满后，依据阿里云公司整改状况，钻研复原其上述单干单位。 阿里云官网今日回应称，因在晚期未意识到该破绽的严重性，未及时共享破绽信息。阿里云将强化破绽治理、晋升合规意识，踊跃协同各方做好网络安全危险防备工作。 12月23日，阿里云通过其官网微信公众号公布《对于开源社区Apache Log4j2破绽状况的阐明》。 Log4j2 是开源社区阿帕奇（Apache）旗下的开源日志组件，被全世界企业和组织广泛应用于各种业务零碎开发。 近日，阿里云一名研发工程师发现Log4j2 组件的一个平安bug，遂按业界常规以邮件形式向软件开发方Apache开源社区报告这一问题申请帮忙。Apache开源社区确认这是一个安全漏洞，并向寰球公布修复补丁。随后，该破绽被外界证实为一个全球性的重大破绽。 阿里云因在晚期未意识到该破绽的严重性，未及时共享破绽信息。阿里云将强化破绽报告治理、晋升合规意识，踊跃协同各方做好网络安全危险防备工作。 相干浏览：阿里云被暂停工信部网络安全单干单位 6 个月，因未及时报告 Apache Log4j2 高危破绽

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 Linux 疾速设置 1.您必须是管理员root或者具备管理员权限 2.sudo vim /etc/resolv.conf 3.退出：（此处IPv4和IPv6略有不同） IPv4：nameserver 223.5.5.5/nameserver 223.6.6.6IPv6：nameserver 2400:3200::1/nameserver 2400:3200:baba::14.保留退出，而后应用dig验证 5.这一步，IPv4和IPv6略有不同： IPv4：dig www.taobao.com +short 若呈现后果则示意失常。 IPv6：dig alidns.com 若返回后果的server为阿里公共DNS（2400:3200::1或2400:3200:baba::1）则配置胜利。 如果你的零碎是ubuntu，那么能够尝试应用脚本进行设置： 1.关上终端，在终端输出上面的命令设置DNS. wget http://www.alidns.com/public/soft/SetAliDNS.sh -O SetAliDNS.sh %26%26 chmod +x SetAliDNS.sh %26%26 sudo ./SetAliDNS.sh 2.设置后如何勾销阿里公共DNS： sudo ./SetAliDNS.sh restore \

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 Ubuntu 镜像简介Ubuntu，是一款基于 Debian Linux 的以桌面利用为主的操作系统，内容涵盖文字处理、电子邮件、软件开发工具和 Web 服务等，可供用户收费下载、应用和分享。 下载地址: 阿里云开源镜像站资源目录 配置办法域名阐明对于阿里云ECS用户，能够间接应用外部域名拜访，而对于非云用户则须要应用公网域名 mirrors.aliyun.com 来拜访。 手动更改用你相熟的编辑器关上： /etc/apt/sources.list 替换默认的 http://archive.ubuntu.com/ 为 mirrors.aliyun.com 以ubuntu 18.04(bionic)为例，最初的成果如下： ubuntu 18.04(bionic) 配置如下deb http://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu/ bionic-proposed main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ bionic-proposed main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiverse ...

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 本文以 ubuntu-18.04.6-desktop-amd64 为例，虚拟机硬件须要提前配置， 上面正式装置Ubuntu操作系统。 点击 编辑虚拟机设置， 在弹出的菜单里，从右边抉择 「CD/DVD(SATA)」 ，而后在左边抉择「应用ISO镜像文件」，再点击浏览，找到Ubuntu镜像。 之后点击确定，再点击「开启虚拟机」 。  4. 虚拟机开启之后，抉择 「Install Ubuntu」 。右边的语言选择，是指零碎语言。 接下来这步抉择的是键盘布局。咱们这边所应用的布局是美国规范的，所以都抉择英语(美国)。  6. 接下来这一步间接默认：  7. 在 「装置类型」 里也是默认即可，间接点击 「当初装置」，之后的弹出窗口里点击 「持续」：   在 「你在什么中央?」 地图里点默认即可，而后点击 「持续」，  9. 在 「你是谁?」 填入集体根本信息，而后点击 「持续」，接下来就进入了下载安装的过程，整个过程大略须要20分钟。    10 装置结束之后抉择 「当初重启」，重启虚拟机。至此，虚拟机及Linux零碎均曾经装置实现。   \

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) repoforge镜像-repoforge下载地址-repoforge装置教程-阿里巴巴开源镜像站 (aliyun.com) 二、RepoForge 镜像介绍Repoforge 是 RHEL 零碎下的软件仓库，领有 10000 多个软件包，被认为是最平安、最稳固的一个软件仓库。下载地址：https://mirrors.aliyun.com/re... 三、RepoForge 镜像配置1、运行uname 获取 OS 版本号（如 EL6, EL7 等）[root@centos ~]# uname -aLinux centos 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux2、向零碎中增加 Repoforge 的 GPG 公钥[root@centos ~]# rpm --import https://mirrors.aliyun.com/repoforge/RPM-GPG-KEY.dag.txt[root@centos ~]#3、运行下列命令(以 OS 版本 7 为例)：sudo cat > /etc/yum.repos.d/rpmforge.repo << EOF[rpmforge]name = RHEL $releasever - RPMforge.net - dagbaseurl = https://mirrors.aliyun.com/repoforge/redhat/el7/en/$basearch/rpmforgemirrorlist = http://mirrorlist.repoforge.org/el7/mirrors-rpmforgeenabled = 1protect = 0gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-daggpgcheck = 1[rpmforge-extras]name = RHEL $releasever - RPMforge.net - extrasbaseurl = https://mirrors.aliyun.com/repoforge/redhat/el7/en/$basearch/extrasmirrorlist = http://mirrorlist.repoforge.org/el7/mirrors-rpmforge-extrasenabled = 0protect = 0gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-daggpgcheck = 1[rpmforge-testing]name = RHEL $releasever - RPMforge.net - testingbaseurl = https://mirrors.aliyun.com/repoforge/redhat/el7/en/$basearch/testingmirrorlist = http://mirrorlist.repoforge.org/el7/mirrors-rpmforge-testingenabled = 0protect = 0gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-daggpgcheck = 1EOF ...

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) ovirt镜像-ovirt下载地址-ovirt装置教程-阿里巴巴开源镜像站 (aliyun.com) 二、oVirt介绍oVirt是一款收费开源虚拟化软件，是RedHat商业版本虚拟化软件RHEV的开源版本。 oVirt基于kvm，并整合应用了libvirt、gluster、patternfly、ansible等一系列优良的开源软件，oVirt的定位是代替vmware vsphere，oVirt目前曾经成为了企业虚拟化环境可选的解决方案，另外相比OpenStack的宏大和简单，oVirt在企业公有云建设中具备部署和保护应用简略的劣势。 三、部署oVirt操作本试验应用VM虚拟机模仿演示操作 基于CentOS7.9版本进行操作 1、查看零碎版本信息[root@centos-ovirt ~]# hostnamectl Static hostname: centos-ovirt Icon name: computer-vm Chassis: vm Machine ID: f6fc8fb7991c4c518238af7c75f16046 Boot ID: 3028618b95f346e7a096c234f351ff7c Virtualization: vmware Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-1160.el7.x86_64 Architecture: x86-64[root@centos-ovirt ~]# uname -aLinux centos-ovirt 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux[root@centos-ovirt ~]# cat /etc/redhat-releaseCentOS Linux release 7.9.2009 (Core)[root@centos-ovirt ~]#2、装置ovirt-engine组件失败[root@centos-ovirt ~]# yum install -y ovirt-engineLoaded plugins: fastestmirrorLoading mirror speeds from cached hostfile * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.comNo package ovirt-engine available.Error: Nothing to do3、更新阿里云YUM源[root@centos-ovirt ~]# yum clean allLoaded plugins: fastestmirrorCleaning repos: base extras updatesCleaning up list of fastest mirrors[root@centos-ovirt ~]# yum repolistLoaded plugins: fastestmirrorDetermining fastest mirrors * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.combase | 3.6 kB 00:00:00 extras | 2.9 kB 00:00:00 updates | 2.9 kB 00:00:00 (1/4): base/7/x86_64/group_gz | 153 kB 00:00:00 (2/4): extras/7/x86_64/primary_db | 243 kB 00:00:00 (3/4): base/7/x86_64/primary_db | 6.1 MB 00:00:01 (4/4): updates/7/x86_64/primary_db | 13 MB 00:00:02 repo id repo name statusbase/7/x86_64 CentOS-7 - Base - mirrors.aliyun.com 10,072extras/7/x86_64 CentOS-7 - Extras - mirrors.aliyun.com 500updates/7/x86_64 CentOS-7 - Updates - mirrors.aliyun.com 3,242repolist: 13,814[root@centos-ovirt ~]## 更新YUM源[root@centos-ovirt ~]# yum install -y https://mirrors.aliyun.com/ovirt/yum-repo/ovirt-release42.rpmLoaded plugins: fastestmirrorovirt-release42.rpm | 12 kB 00:00:00 Examining /var/tmp/yum-root-47iGoT/ovirt-release42.rpm: ovirt-release42-4.2.8-1.el7.noarchMarking /var/tmp/yum-root-47iGoT/ovirt-release42.rpm to be installedResolving Dependencies--> Running transaction check---> Package ovirt-release42.noarch 0:4.2.8-1.el7 will be installed--> Finished Dependency ResolutionDependencies Resolved======================================================================================================================== Package Arch Version Repository Size========================================================================================================================Installing: ovirt-release42 noarch 4.2.8-1.el7 /ovirt-release42 11 kTransaction Summary========================================================================================================================Install 1 PackageTotal size: 11 kInstalled size: 11 kDownloading packages:Running transaction checkRunning transaction testTransaction test succeededRunning transactionInstalling : ovirt-release42-4.2.8-1.el7.noarch 1/1 Verifying : ovirt-release42-4.2.8-1.el7.noarch 1/1 Installed: ovirt-release42.noarch 0:4.2.8-1.el7 Complete![root@centos-ovirt ~]#[root@centos-ovirt ~]# cd /etc/yum.repos.d/[root@centos-ovirt yum.repos.d]# lltotal 52-rw-r--r--. 1 root root 2523 Nov 28 18:12 CentOS-Base.repo-rw-r--r--. 1 root root 1664 Oct 23 2020 CentOS-Base.repo.backup-rw-r--r--. 1 root root 1309 Oct 23 2020 CentOS-CR.repo-rw-r--r--. 1 root root 649 Oct 23 2020 CentOS-Debuginfo.repo-rw-r--r--. 1 root root 314 Oct 23 2020 CentOS-fasttrack.repo-rw-r--r--. 1 root root 630 Oct 23 2020 CentOS-Media.repo-rw-r--r--. 1 root root 1331 Oct 23 2020 CentOS-Sources.repo-rw-r--r--. 1 root root 8515 Oct 23 2020 CentOS-Vault.repo-rw-r--r--. 1 root root 616 Oct 23 2020 CentOS-x86_64-kernel.repo-rw-r--r-- 1 root root 1991 Dec 23 22:51 ovirt-4.2-dependencies.repo-rw-r--r-- 1 root root 289 Dec 23 22:51 ovirt-4.2.repo[root@centos-ovirt yum.repos.d]# ...

【阿里云镜像】装置编译Apache环境一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) apache镜像-apache下载地址-apache装置教程-阿里巴巴开源镜像站 (aliyun.com) Apache（Web服务器软件）_百度百科 (baidu.com) 编译装置_Apache中文文档 (apachehttpd.com) 二、Apache 简介Apache(音译为阿帕奇)是世界应用排名第一的Web服务器软件。它能够运行在简直所有宽泛应用的计算机平台上，因为其跨平台和安全性被宽泛应用，是最风行的Web服务器端软件之一。它疾速、牢靠并且可通过简略的API裁减，将Perl/Python等解释器编译到服务器中。下载地址：https://mirrors.aliyun.com/apache/ 三、Apache编译装置（基于CentOS零碎）1、登录CentOS零碎 2、装置依赖包编译装置Apache HTTP Server，目前最新的版本为2.4.52，将apr，apr-util，pcre等相干依赖包编译装置好即可。 若上述安装包已全副装置实现，能够间接进行Apache装置。 apr装置下载链接：https://mirrors.aliyun.com/ap... # 测试YUM源是否可能失常[root@centos apache]# yum clean all[root@centos apache]# yum repolist# 下载压缩包[root@centos apache]# wget https://mirrors.aliyun.com/apache/apr/apr-1.7.0.tar.gz# 查看apr-1.7.0.tar.gz[root@centos apache]# lltotal 1072-rw-r--r-- 1 root root 1093896 Jul 6 2020 apr-1.7.0.tar.gz#解压压缩包[root@centos apache]# tar -zxvf apr-1.7.0.tar.gz[root@centos apache]# lltotal 1076drwxr-xr-x 27 1001 1001 4096 Apr 2 2019 apr-1.7.0-rw-r--r-- 1 root root 1093896 Jul 6 2020 apr-1.7.0.tar.gz# 进入解压后的文件夹[root@centos apache]# cd apr-1.7.0# 创立apr装置目录文件夹[root@centos apr-1.7.0]# mkdir -p /usr/local/apr/apr# 装置配置[root@centos apr-1.7.0]# ./configure --prefix=/usr/local/apr/apr/# 编译[root@centos apr-1.7.0]# make#装置[root@centos apr-1.7.0]# make install局部装置过程截图如下： ...

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) kaos镜像-kaos下载地址-kaos装置教程-阿里巴巴开源镜像站 (aliyun.com) https://kaosx.us/ KaiOS_百度百科 (baidu.com) 二、KaOS 简介KaiOS是一个2017年诞生的挪动操作系统，并在一年工夫外在印度市场实现遍及，成为印度仅次于安卓零碎的第二大挪动操作系统。其特色在于最新版本的KDE桌面环境及其他风行的应用Qt工具包的软件程序。 下载地址：https://mirrors.aliyun.com/KaOS/ 三、KaOS 下载下载链接：https://mirrors.aliyun.com/Ka... 四、KaOS 装置 进入欢送页面（须要联网装置） 抉择时区 抉择键盘 抉择最小化装置 擦除硬盘须要抉择KaOS的装置办法。为获得最佳成果，请抉择"擦除磁盘"，而后抉择"替换（休眠）"。如果您精通Linux，请随时抉择其余选项。实现后单击"下一步"持续。 设置用户名明码 确认信息 开始装置 装置实现，抉择重启零碎 登录零碎 装置并登录实现

 阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区NTP简介NTP 是网络工夫协定 (Network Time Protocol)，它是用来同步网络中各个计算机的工夫的协定。 时区和工夫一致性对于云服务器ECS十分重要，有时会间接影响到工作执行的后果。例如，您在更新数据库或者剖析日志时，工夫程序对后果有很大影响。为防止在ECS实例上运行业务时呈现逻辑凌乱和网络申请谬误等问题，您须要对立相干ECS实例的时区设置。另外，您还能够通过NTP服务同步各网络中ECS实例的本地工夫。 上面介绍如何开启和配置Windows NTP服务，保障实例本地工夫准确同步。 Windows Server操作系统默认开启Windows Time服务。为了保障NTP服务配置胜利后能失常同步工夫，实例中必须开启NTP服务。 1 右击开始图标 而后单击运行，在运行对话框中执行命令services.msc。 2 在服务对话框中，找到并双击Windows Time服务。 3 在Windows Time的属性（本地计算机）对话框中，执行以下操作： 将启动类型设置为主动。确认服务状态为正在运行。如果不是，单击启动。单击利用，并单击确定。 批改默认NTP服务器地址Windows Server操作系统默认配置微软NTP服务器（time.windows.com），然而可能常常同步出错。应用阿里云ECS实例时，您能够将默认NTP服务器更换成阿里云提供的内网NTP服务器。请按以下步骤批改默认NTP服务器地址。 1 在任务栏的告诉区域，右击日期和工夫，抉择调整日期和工夫。    2 点击 附件时钟， 3 在日期和工夫对话框里，单击Internet 工夫选项卡，并单击更改设置。 在Internet 工夫设置对话框里，抉择与Internet工夫服务器同步，填写一个阿里云内网NTP服务器地址ntp.aliyun.com，并单击立刻更新，确定。 \

阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) pypi镜像-pypi下载地址-pypi装置教程-阿里巴巴开源镜像站 (aliyun.com) 简介PyPI (Python Package Index) 是 Python 编程语言的软件存储库。开发者能够通过 PyPI 查找和装置由 Python 社区开发和共享的软件，也能够将本人开发的库上传至 PyPI 。 下载地址：https://mirrors.aliyun.com/pypi/ 配置办法a. 找到下列文件 ~/.pip/pip.confb. 在上述文件中增加或批改: [global]index-url = https://mirrors.aliyun.com/pypi/simple/[install]trusted-host=mirrors.aliyun.com相干链接官方主页：https://pypi.org/软件包预警背景Python库的官网仓库pypi容许开发者自在上传软件包，这会导致某些攻击者利用这点结构歹意包进行供应链攻打，在用户安装包或者引入包时触发歹意行为。目前国内镜像源与官网镜像源往往并不是完全一致，国内源广泛采纳的是增量更新机制，也就是官网删除的歹意包国内不会同步删除。而这一部分歹意包可能会在很长一段时间内对国内用户造成影响。 阿里云平安-薪火实验室联合自建检测引擎-伏魔引擎长期对供应链歹意样本进行监控和预警，爱护阿里pypi源平安。 删除包列表以下具备平安威逼的软件包阿里pypi源已对应删除，开发者可通过 pip list 命令对于机器上曾经装置的pypi包进行自查，如发现装置有以下具备平安危险的包，倡议尽快删除修复。 歹意包备注maratlib歹意后门maratlib1歹意后门matplatlib-plus歹意后门mllearnlib歹意后门mplatlib歹意后门learninglib歹意后门importantpackage反弹shellimportant-package反弹shellpptest反弹shellipboards反弹shellowlmoon反弹shelldiscordsafety反弹shelltrrfab反弹shell10cent10反弹shell10cent11反弹shellyandex-yt反弹shellyiffparty反弹shellgiganigga反弹shelltrrfab反弹shellrbperf歹意后门osxframeworks歹意后门caldavtester歹意后门kubectl-testing2获取敏感信息nflx-kragle-scripts获取敏感信息dbattery-python-api获取敏感信息portal-api获取敏感信息csitools获取敏感信息eaa-commons获取敏感信息yow-utils获取敏感信息ipboards获取敏感信息eyesearch歹意后门backdoorxrat歹意后门amazon-freertos-ble-ios-sdk获取敏感信息aws-lambda-dotnet获取敏感信息uber-sdk获取敏感信息aws-xray-sdk-dotnet获取敏感信息python-bigquery-connection获取敏感信息constructs-go获取敏感信息google-auth-library-oauthlib获取敏感信息runtimeconfig获取敏感信息amazon-states-language-service获取敏感信息exeggutor获取敏感信息proto-plus-python获取敏感信息cta获取敏感信息aws-sdk-ruby获取敏感信息python-dataproc获取敏感信息amazon-chime-sdk-js获取敏感信息homebrew-aws获取敏感信息gax-python获取敏感信息google-auth-library-httplib2获取敏感信息amazon-ecs-init获取敏感信息aws-xray获取敏感信息game-servers获取敏感信息amazon-ec2-utils获取敏感信息aws-encryption-sdk-python获取敏感信息aws-glue-databrew-jupyter-extension获取敏感信息aws-sigv4-auth-cassandra-gocql-driver-plugin获取敏感信息aws-ssm-data-protection-provider-for-aspnet获取敏感信息aws-greengrass-core-sdk-java获取敏感信息aws-lambda-runtime-interface-client获取敏感信息datalabeling获取敏感信息aws-lambda-java-libs获取敏感信息amazon-freertos-ble-ios-sdk获取敏感信息python-storage获取敏感信息aws-appsync-community获取敏感信息amazon-braket-ocean-plugin-python获取敏感信息python-service-directory获取敏感信息aws-greengrass-core-sdk-js获取敏感信息aws-step-functions-data-science-sdk获取敏感信息aws-dax-go获取敏感信息aws-encryption-sdk-c获取敏感信息python-bigquery-storage获取敏感信息python-trace获取敏感信息python-phishingprotection获取敏感信息amazon-neptune-sparql-java-sigv4获取敏感信息python-policy-troubleshooter获取敏感信息aws-swf-build-tools获取敏感信息azure-api获取敏感信息jumpbox获取敏感信息bluh获取敏感信息aws-lambda-nodejs-runtime-interface-client获取敏感信息yelp-pack获取敏感信息aws-ec2-instance-connect-config获取敏感信息aws-sdk-js获取敏感信息aws-nitro-enclaves-cli获取敏感信息python-network-connectivity获取敏感信息python-bigquery-reservation获取敏感信息aws-iot-device-sdk获取敏感信息yelp-profiling获取敏感信息aws-cdk-rfcs获取敏感信息vscode-test获取敏感信息yelp-batch获取敏感信息aws-app-mesh-controller-for-k8s获取敏感信息cloud-core获取敏感信息python-analytics-data获取敏感信息yelppack获取敏感信息aws-sdk-php-zf2获取敏感信息aws-xray-sdk-ruby获取敏感信息amazon-ecs-cni-plugins获取敏感信息aws-eb-python-dockerfiles获取敏感信息python-recaptcha-enterprise获取敏感信息replication-delay-client获取敏感信息pythonlibtest获取敏感信息eks-distro-prow-jobs获取敏感信息access-context-manager获取敏感信息policy-troubleshooter获取敏感信息amazon-elastic-inference-tools获取敏感信息trusted-advisor-tools获取敏感信息aws-ofi-nccl获取敏感信息aws-sdk-java-archetype获取敏感信息google-cloudevents获取敏感信息jsii-runtime-go获取敏感信息aws-sessionstore-dynamodb-ruby获取敏感信息yelp-ips获取敏感信息python-aiplatform获取敏感信息nflx-cloudsol-python-libs获取敏感信息amazon-ecs-agent获取敏感信息aws-php-sns-message-validator获取敏感信息python-runtimeconfig获取敏感信息aws-dotnet-extensions-configuration获取敏感信息yourapplication获取敏感信息aws-kinesisanalytics-runtime获取敏感信息python-access-approval获取敏感信息amazon-neptune-csv-to-rdf-converter获取敏感信息python-cloudbuild获取敏感信息aws-sdk-unity-net获取敏感信息aws-step-functions-data-science-sdk-python获取敏感信息amazon-ecs-shim-loggers-for-containerd获取敏感信息aws-lambda-ruby-runtime-interface-client获取敏感信息python-video-transcoder获取敏感信息amazon-ec2-hibinit-agent获取敏感信息aws-iot-device-sdk-js-v2获取敏感信息aws-sigv4-auth-cassandra-python-driver-plugin获取敏感信息aws-toolkit-jetbrains获取敏感信息aws-aspnet-cognito-identity-provider获取敏感信息base64io-python获取敏感信息containers-roadmap获取敏感信息amazon-cognito-sync-manager-net获取敏感信息aws-sdk-java获取敏感信息python-documentai获取敏感信息hashing-lib获取敏感信息yelp-lib获取敏感信息airbnb-sdk获取敏感信息aws-neuron-driver获取敏感信息python-datacatalog获取敏感信息aws-sdk-php-v3-bridge获取敏感信息aws-xray-sdk-python获取敏感信息aws-tools-for-powershell获取敏感信息sagemaker-sdk获取敏感信息aws-nitro-enclaves-samples获取敏感信息python-webrisk获取敏感信息aws-sdk-ruby-release-tools获取敏感信息yelp-servlib获取敏感信息paypal-python-sdk获取敏感信息aws-iot-device-sdk-v2获取敏感信息aws-cdk获取敏感信息videointelligence获取敏感信息aws-sdk-php获取敏感信息python-api-common-protos获取敏感信息iot-atlas获取敏感信息json2jsii获取敏感信息yelpcorp获取敏感信息python-language获取敏感信息billingbudgets获取敏感信息ebay-sdk获取敏感信息aws-lambda-python-runtime-interface-client获取敏感信息aws-lambda-runtime-interface-emulator获取敏感信息bigquery-sqlalchemy获取敏感信息aws-toolkit-eclipse获取敏感信息aws-sdk-rails获取敏感信息grpc-sdk获取敏感信息paypalsdk获取敏感信息eks-distro获取敏感信息amazon-ec2-metadata-mock获取敏感信息python-pubsublite获取敏感信息aws-sdk-unity-net获取敏感信息python-cloudbuild获取敏感信息containeranalysis获取敏感信息aws-xray-daemon获取敏感信息bigquery-storage获取敏感信息org-policy获取敏感信息aws-sdk-cpp获取敏感信息jsii-runtime-go获取敏感信息google-cloudevents获取敏感信息aws-xray-sdk-dotnet获取敏感信息aws-lambda-nodejs-runtime-interface-client获取敏感信息aws-ec2-instance-connect-config获取敏感信息base64io-python获取敏感信息aws-toolkit-jetbrains获取敏感信息aws-sigv4-auth-cassandra-python-driver-plugin获取敏感信息python-notebooks获取敏感信息python-channel获取敏感信息aws-sigv4-auth-cassandra-nodejs-driver-plugin获取敏感信息aws-iot-device-sdk-python-v2获取敏感信息analytics-admin获取敏感信息python-logging获取敏感信息recommendations-ai获取敏感信息python-speech获取敏感信息websecurityscanner获取敏感信息aws-ops-wheel获取敏感信息access-approval获取敏感信息amazon-kinesis-streams-for-fluent-bit获取敏感信息aws-sdk-net-extensions-cognito获取敏感信息aws-cdi-sdk获取敏感信息aws-ofi-nccl获取敏感信息aws-nitro-enclaves-cli获取敏感信息aws-iot-device-sdk获取敏感信息amazon-ssm-agent获取敏感信息python-tasks获取敏感信息codelyzer获取敏感信息amazon-eks-diag获取敏感信息amazon-braket-pennylane-plugin-python获取敏感信息aws-iot-device获取敏感信息aws-iot-device-sdk-embedded-c获取敏感信息ec2-macos-system-monitor获取敏感信息python-compute获取敏感信息awsui-documentation获取敏感信息aws-dynamodb-encryption-java获取敏感信息eks-distro获取敏感信息aws-k8s-tester获取敏感信息amazon-ec2-metadata-mock获取敏感信息aws-toolkit-eclipse获取敏感信息bigquery-sqlalchemy获取敏感信息aws-sdk-rails获取敏感信息aws-lambda-runtime-interface-emulator获取敏感信息billingbudgets获取敏感信息aws-lambda-python-runtime-interface-client获取敏感信息json2jsii获取敏感信息iot-atlas获取敏感信息python-language获取敏感信息game-servers获取敏感信息amazon-ec2-utils获取敏感信息amazon-ecs-init获取敏感信息google-auth-library-httplib2获取敏感信息aws-greengrass-core-sdk-java获取敏感信息aws-sigv4-auth-cassandra-gocql-driver-plugin获取敏感信息aws-glue-databrew-jupyter-extension获取敏感信息homebrew-aws获取敏感信息gax-python获取敏感信息python-dataproc获取敏感信息aws-xray-sdk-java获取敏感信息amazon-chime-sdk-js获取敏感信息amazon-states-language-service获取敏感信息aws-refcocog-adv获取敏感信息python-analytics-admin获取敏感信息aws-northstar获取敏感信息binary-authorization获取敏感信息aws-secretsmanager-caching-java获取敏感信息aws-cdk-rfcs获取敏感信息python-bigquery-reservation获取敏感信息aws-xray-sdk-ruby获取敏感信息aws-sdk-java-archetype获取敏感信息trusted-advisor-tools获取敏感信息amazon-elastic-inference-tools获取敏感信息aws-sdk-js获取敏感信息aws-toolkit-visual-studio获取敏感信息ec2-macos-init获取敏感信息amazon-sagemaker-examples获取敏感信息python-texttospeech获取敏感信息jobs-for-aws-iot-embedded-sdk获取敏感信息python-gke-hub获取敏感信息elastic-beanstalk-roadmap获取敏感信息amazon-sagemaker-operator-for-k8s获取敏感信息python-container获取敏感信息aws-proton-public-roadmap获取敏感信息python-videointelligence获取敏感信息ec2-hibernate-linux-agent获取敏感信息gax获取敏感信息aws-eks-best-practices获取敏感信息aws-iot-device-sdk-java获取敏感信息ec2-image-builder-roadmap获取敏感信息aws-lambda-go获取敏感信息aws-auto-scaling-custom-resource获取敏感信息network-connectivity获取敏感信息aws-swf-flow-library获取敏感信息python-media-translation获取敏感信息data-qna获取敏感信息aws-sdk-ruby-record获取敏感信息python-irm获取敏感信息python-workflows获取敏感信息aws-xray-java-agent获取敏感信息aws-for-fluent-bit获取敏感信息aws-iot-device-sdk-arduino-yun获取敏感信息google-cloud-python获取敏感信息aws-health-tools获取敏感信息aws-graviton-getting-started获取敏感信息assured-workloads获取敏感信息aws-app-mesh-controller-for-k8s获取敏感信息python-api-common-protos获取敏感信息amazon-ec2-hibinit-agent获取敏感信息aws-sdk-php获取敏感信息videointelligence获取敏感信息python-webrisk获取敏感信息aws-sdk-ruby-release-tools获取敏感信息aws-greengrass-core-sdk获取敏感信息sagemaker-sdk获取敏感信息aws-xray-sdk-python获取敏感信息python-datacatalog获取敏感信息aws-nitro-enclaves-samples获取敏感信息aws-tools-for-powershell获取敏感信息aws-sdk-js-v3获取敏感信息python-error-reporting获取敏感信息python-firestore获取敏感信息python-binary-authorization获取敏感信息google-auth-library-python-httplib2获取敏感信息aws-secretsmanager-caching-net获取敏感信息python-dns获取敏感信息aws-extensions-for-dotnet-cli获取敏感信息texttospeech获取敏感信息aws-emr-containers-best-practices获取敏感信息python-area120-tables获取敏感信息python-websecurityscanner获取敏感信息aws-parallelcluster-cookbook获取敏感信息python-audit-log获取敏感信息aws-sdk-php-laravel获取敏感信息aws-step-functions-data-science获取敏感信息aws-kinesisanalytics-flink-connectors获取敏感信息aws-toolkit-vscode获取敏感信息python-bigquery-datatransfer获取敏感信息aws-sdk-js-crypto-helpers获取敏感信息aws-xray-sdk-go获取敏感信息python-api-core获取敏感信息documentai获取敏感信息aws-dotnet-deploy获取敏感信息python-security-private-ca获取敏感信息eks-charts获取敏感信息python-crc32c获取敏感信息service-management获取敏感信息aws-greengrass-core-sdk-python获取敏感信息amazon-neptune-gremlin-java-sigv4获取敏感信息monitoring-dashboards获取敏感信息device-shadow-for-aws-iot-embedded-sdk获取敏感信息aws-sigv4-auth-cassandra-driver-plugin获取敏感信息aws-iot-device-sdk-java-v2获取敏感信息amazon-chime-sdk-ios获取敏感信息python-functions获取敏感信息phishingprotection获取敏感信息aiplatform获取敏感信息python-bigquery获取敏感信息deep-learning-containers获取敏感信息aws-dynamodb-encryption-python获取敏感信息crypto-tools获取敏感信息python-os-config获取敏感信息retail获取敏感信息python-dialogflow获取敏感信息irm获取敏感信息device-defender-for-aws-iot-embedded-sdk获取敏感信息python-spanner获取敏感信息aws-sdk-php-symfony获取敏感信息ec2-hibernate-windows-agent获取敏感信息amazon-eks-pod-identity-webhook获取敏感信息amazon-codeguru-profiler-python-agent获取敏感信息python-artifact-registry获取敏感信息aws-lambda-base-images获取敏感信息eks-distro-build-tooling获取敏感信息amazon-keyspaces-cql-to-cfn-converter获取敏感信息python-talent获取敏感信息dcv-color-primitives获取敏感信息python-spanner-django获取敏感信息ec2-spot-instances-integrations-roadmap获取敏感信息bigquery-datatransfer获取敏感信息amazon-freertos-ble-ios-sdk获取敏感信息python-aiplatform获取敏感信息aws-lambda-java-libs获取敏感信息datalabeling获取敏感信息aws-ssm-data-protection-provider-for-aspnet获取敏感信息aws-lambda-runtime-interface-client获取敏感信息aws-sdk-mobile-analytics-js获取敏感信息aws-encryption-sdk-python获取敏感信息aws-xray获取敏感信息aws-xray-sdk-node获取敏感信息dialogflow-cx获取敏感信息pubsublite获取敏感信息google-auth-library-python获取敏感信息aws-iot-device-sdk-js获取敏感信息python-recommendations-ai获取敏感信息google-resumable-media-python获取敏感信息aws-logging-dotnet获取敏感信息aws-sdk-php-silex获取敏感信息constructs-go获取敏感信息aws-sdk-ruby获取敏感信息aws-encryption-sdk-c获取敏感信息python-trace获取敏感信息aws-dax-go获取敏感信息python-bigquery-storage获取敏感信息aws-step-functions-data-science-sdk获取敏感信息aws-greengrass-core-sdk-js获取敏感信息google-auth-library-oauthlib获取敏感信息aws-sessionstore-dynamodb-ruby获取敏感信息aws-greengrass-core-sdk-c获取敏感信息policy-troubleshooter获取敏感信息http-desync-guardian获取敏感信息access-context-manager获取敏感信息eks-distro-prow-jobs获取敏感信息aws-codebuild-docker-images获取敏感信息python-oslogin获取敏感信息python-recaptcha-enterprise获取敏感信息aws-toolkit-azure-devops获取敏感信息python-network-connectivity获取敏感信息aws-eb-python-dockerfiles获取敏感信息aws-nitro-enclaves-sdk-bootstrap获取敏感信息amazon-braket-schemas-python获取敏感信息amazon-sagemaker-clarify获取敏感信息aws-nitro-enclaves-sdk-c获取敏感信息python-bigquery-sqlalchemy获取敏感信息amazon-ec2-net-utils获取敏感信息amazon-ec2-instance-selector获取敏感信息aws-sdk-java-v2获取敏感信息python-secret-manager获取敏感信息aws-iot-device-sdk-js-v2获取敏感信息python-video-transcoder获取敏感信息aws-lambda-ruby-runtime-interface-client获取敏感信息amazon-ecs-shim-loggers-for-containerd获取敏感信息python-access-approval获取敏感信息aws-step-functions-data-science-sdk-python获取敏感信息amazon-neptune-csv-to-rdf-converter获取敏感信息aws-dotnet-extensions-configuration获取敏感信息aws-kinesisanalytics-runtime获取敏感信息python-service-directory获取敏感信息python-phishingprotection获取敏感信息aws-swf-build-tools获取敏感信息aws-nitro-enclaves-acm获取敏感信息amazon-braket-ocean-plugin-python获取敏感信息python-storage获取敏感信息aws-ec2-instance-connect-cli获取敏感信息aws-iot-device-sdk-v2获取敏感信息aws-sdk-go-v2获取敏感信息aws-iot-device-sdk-cpp获取敏感信息amazon-chime-sdk-component-library-react获取敏感信息amazon-kinesis-firehose-for-fluent-bit获取敏感信息amazon-chime-sdk-android获取敏感信息aws-toolkit-common获取敏感信息gke-hub获取敏感信息aws-sdk-net获取敏感信息aws-sam-build-images获取敏感信息python-bigtable获取敏感信息recaptcha-enterprise获取敏感信息aws-eb-glassfish-dockerfiles获取敏感信息cloud-core获取敏感信息python-monitoring-dashboards获取敏感信息amazon-ssm-document-language-service获取敏感信息aws-dynamodb-encryption获取敏感信息copilot-cli获取敏感信息aws-elastic-beanstalk-cli获取敏感信息efs-utils获取敏感信息python-resource-manager获取敏感信息amazon-cloudwatch-logs-for-fluent-bit获取敏感信息runtimeconfig获取敏感信息homebrew-tap获取敏感信息python-bigquery-connection获取敏感信息proto-plus-python获取敏感信息cta获取敏感信息aws-neuron-runtime-proto获取敏感信息amazon-cloudwatch-agent获取敏感信息aws-app-mesh-roadmap获取敏感信息aws-secretsmanager-caching-python获取敏感信息amazon-redshift-driver获取敏感信息python-billingbudgets获取敏感信息python-api-gateway获取敏感信息python-game-servers获取敏感信息aws-elastic-beanstalk-cli-setup获取敏感信息amazon-braket-examples获取敏感信息aws-neuron-tensorflow获取敏感信息python-service-management获取敏感信息connect-rtc-js获取敏感信息amazon-redshift-jdbc-driver获取敏感信息python-datastore获取敏感信息amazon-cognito-dotnet获取敏感信息amazon-freertos获取敏感信息aws-sdk-php-v3-bridge获取敏感信息aws-neuron-driver获取敏感信息python-documentai获取敏感信息amazon-cognito-sync-manager-net获取敏感信息aws-sdk-java获取敏感信息amazon-ecs-agent获取敏感信息aws-php-sns-message-validator获取敏感信息containers-roadmap获取敏感信息python-runtimeconfig获取敏感信息aws-aspnet-cognito-identity-provider获取敏感信息aws-dotnet-session-provider获取敏感信息python-containeranalysis获取敏感信息aws-node-termination-handler获取敏感信息aws-iot-device-sdk-python获取敏感信息google-cloud-irm获取敏感信息python-managed-identities获取敏感信息google-auth-library获取敏感信息jsii-release获取敏感信息error-reporting获取敏感信息python-retail获取敏感信息aws-eb-dockerfiles获取敏感信息python-dlp获取敏感信息aws-sdk-js-dist-tools获取敏感信息oslogin获取敏感信息compute获取敏感信息amazon-freertos-ble-android-sdk获取敏感信息bigtable获取敏感信息python-test-utils获取敏感信息aws-codedeploy-agent获取敏感信息aws-sdk-go获取敏感信息amazon-ecs-logs-collector获取敏感信息python-pubsublite获取敏感信息google-cloud-python-happybase获取敏感信息aws-iot-device-sdk-cpp-v2获取敏感信息amazon-neptune-sigv4-signer获取敏感信息aws-cdk-go获取敏感信息python-cloud-core获取敏感信息aws-nitro-enclaves-nsm-api获取敏感信息python-grafeas获取敏感信息bigquery-reservation获取敏感信息python-org-policy获取敏感信息aws-sam-cli-app-templates获取敏感信息bigquery-connection获取敏感信息python-ndb获取敏感信息amazon-braket-sdk-python获取敏感信息python-datalabeling获取敏感信息amazon-neptune-sparql-java-sigv4获取敏感信息aws-mobile-analytics-manager-net获取敏感信息python-policy-troubleshooter获取敏感信息aws-lambda-dotnet获取敏感信息aws-appsync-community获取敏感信息area120-tables获取敏感信息python-iot获取敏感信息security-private-ca获取敏感信息python-dataproc-metastore获取敏感信息python-securitycenter获取敏感信息audit-log获取敏感信息google-auth-library-python-oauthlib获取敏感信息amazon-redshift-python-driver获取敏感信息amazon-vpc-cni-k8s获取敏感信息amazon-ecs-cli获取敏感信息python-access-context-manager获取敏感信息python-dialogflow-cx获取敏感信息python-data-qna获取敏感信息amazon-vpc-cni-plugins获取敏感信息dataproc-metastore获取敏感信息aws-xray-dotnet-agent获取敏感信息amazon-s3-encryption-client-dotnet获取敏感信息python-billing获取敏感信息aws-greengrass-core获取敏感信息analytics-data获取敏感信息gapic-generator-python获取敏感信息aws-deep-learning-containers-utils获取敏感信息aws-iot-device-v2获取敏感信息aws-encryption-sdk-java获取敏感信息jsii-docgen获取敏感信息python-vision获取敏感信息python-asset获取敏感信息aws-secretsmanager-caching-go获取敏感信息python-recommender获取敏感信息python-automl获取敏感信息managed-identities获取敏感信息aws-js-sns-message-validator获取敏感信息amazon-vpc-resource-controller-k8s获取敏感信息aws-sigv4-auth-cassandra-java-driver-plugin获取敏感信息google-cloudevents-python获取敏感信息aws-sdk-php-zf2获取敏感信息python-assured-workloads获取敏感信息python-kms获取敏感信息amazon-ecs-cni-plugins获取敏感信息python-monitoring获取敏感信息aws-dotnet-trace-listener获取敏感信息python-analytics-data获取敏感信息amazon-kinesis-video-streams-parser-library获取敏感信息aws-encryption-sdk-javascript获取敏感信息cloudbuild获取敏感信息video-transcoder获取敏感信息aws-cloudtrail-processing-library获取敏感信息webrisk获取敏感信息aws-app-mesh-examples获取敏感信息artifact-registry获取敏感信息media-translation获取敏感信息jsii-srcmak获取敏感信息aws-fpga获取敏感信息aws-neuron-sdk获取敏感信息amazon-codeguru-profiler-agent获取敏感信息api-common-protos获取敏感信息python-memcache获取敏感信息spanner-django获取敏感信息amazon-ecs-cluster-state-service获取敏感信息uberrides获取敏感信息yelp-aws获取敏感信息yelp-crypto获取敏感信息yelp-markupsafe获取敏感信息google-sdk获取敏感信息gglib歹意后门gethttpanand获取敏感信息guzzlehttp歹意后门yelp-xenial获取敏感信息googlesdk获取敏感信息tesla-sdk获取敏感信息yelpaws获取敏感信息groupon获取敏感信息google-cloud-sdk获取敏感信息aws-api获取敏感信息brawlslib歹意后门yelp-dataset获取敏感信息yelp-email获取敏感信息teslaapi获取敏感信息google-grpc获取敏感信息zoom-api获取敏感信息airbnb-api获取敏感信息zoom-sdk获取敏感信息static-completion获取敏感信息youtube-comment-auto-liker获取敏感信息osxframeworks歹意后门rbperf歹意后门caldavtester歹意后门guzzlehttp获取敏感信息歹意类型解释歹意后门：恶意程序能够在用户不知情的状况下间接装置启动运行，后盾开启非凡接口，不便黑客再次进入受害者计算机，通常会增加非法的启动项，服务等用于长期驻留 反弹shell：黑客在获取执行权限后，能够通过在受害者机器上建设shell会话连贯至黑客计算机，黑客能够通过shell会话间接下发命令管制受害者计算机。 获取敏感信息：非法窃取受害者计算机相关敏感信息，比方零碎、软件账号密码、配置，零碎截屏，私密文件内容，钱包信息等，并将这些信息通过各种伎俩泄露给黑客服务器。 近程命令执行：恶意程序启动会获取黑客服务器信息，并依据近程数据，执行可被黑客管制的近程代码，用于管制受害者机器，执行黑客下发的指令等。 挖矿木马：木马在用户不知情的状况下，应用计算机算力对各类数字货币进行挖矿获利，占用机器大量CPU、GPU资源，重大影响其余利用执行。 篡改剪贴板加密货币地址：恶意程序会监督机器剪贴板，一旦发现用户复制加密货币钱包地址，便将剪贴板中地址替换成黑客指定的钱包地址，用户便可能在不知情中向攻击者转账数字货币。 参考https://heimdalsecurity.com/b...https://thehackernews.com/202...https://github.com/rsc-dev/py...https://www.helpnetsecurity.c...https://snyk.io/blog/maliciou...https://www.nbu.gov.sk/skcsir...https://www.itsfoss.net/malic...https://www.freebuf.com/artic...https://security.bytedance.co...https://bytedance.feishu.cn/s...https://paper.seebug.org/1562/https://security.tencent.comhttps://nakedsecurity.sophos....http://www.djbh.net/webdev/we...https://security.snyk.io/https://github.com/pypa/pypi-...

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) mxlinux镜像-mxlinux下载地址-mxlinux装置教程-阿里巴巴开源镜像站 (aliyun.com) 二、MX Linux 镜像简介MX Linux是一个中量级的GNU/Linux发行版。其基于Debian稳固版本开发，应用了antiX的外围组件，并可装置MX社区开发或打包的软件。MX Linux是antiX和早前的MEPIS社区合作开发的产物，旨在应用各自零碎中最优良的工具和软件。下载地址：https://mirrors.aliyun.com/mx... 三、MX Linux 镜像配置办法1、备份 /etc/apt/sources.list.d/ 上面所有的索引文件 sudo cp /etc/apt/sources.list.d/antix.list /etc/apt/sources.list.d/antix.list.baksudo cp /etc/apt/sources.list.d/mx.list /etc/apt/sources.list.d/mx.list.baksudo cp /etc/apt/sources.list.d/debian.list /etc/apt/sources.list.d/debian.list.baksudo cp /etc/apt/sources.list.d/debian-stable-updates.list /etc/apt/sources.list.d/debian-stable-updates.list.bak 2、批改所有索引文件的下载源地址，能够参考如下命令 sed -i "s@http://la.mxrepo.com/mx/repo/@https://mirrors.aliyun.com/mxlinux/mx/repo/@g" /etc/apt/sources.list.d/mx.listsed -i "s@http://ftp.us.debian.org/debian/@https://mirrors.aliyun.com/debian/@g" /etc/apt/sources.list.d/debian-stable-updates.listsed -i "s@http://ftp.us.debian.org/debian/@https://mirrors.aliyun.com/debian/@g" /etc/apt/sources.list.d/debian.list3、执行 apt-get update 命令更新索引文件 sudo apt-get update

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) manjaro镜像-manjaro下载地址-manjaro装置教程-阿里巴巴开源镜像站 (aliyun.com) Manjaro Linux 乐于简略 | Arch优良衍生版、世界排名前2 二、Manjaro 镜像简介Manjaro Linux是基于Arch Linux 的 Linux 发行版，应用 Xfce 和 KDE Plasma 作为默认桌面环境，和 Arch 一样，采纳滚动更新。其指标是为PC 提供易于应用的自在的操作系统。 Xfce是一个用于类UNIX操作系统的轻量级桌面环境。 它的指标是疾速和系统资源低耗，同时依然放弃视觉上的吸引力和对用户敌对的个性。 Xfce体现了传统的UNIX模块化和可复用性的理念。 它由许多组件组成，这些组件提供了古代桌面环境所冀望的全副性能。 它们独自包装，您能够在可用的包中筛选，以创立最佳的集体工作环境。 下载地址：http://mirrors.aliyun.com/manjaro/ 三、Manjaro 镜像配置办法生成可用中国镜像站列表 sudo pacman-mirrors -i -c China -m rank勾选 http://mirrors.aliyun.com/man...，而后按OK键两次。 ==此处临时未能找到阿里云镜像，用其余镜像做演示== 最初刷新缓存 sudo pacman -Syy

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) mongodb镜像-mongodb下载地址-mongodb装置教程-阿里巴巴开源镜像站 (aliyun.com) centOs装置并应用mongodb 【国内镜像版】_SWEENEY_HE的博客-CSDN博客_mongodb国内镜像 二、MongoDB 镜像简介MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 利用提供可扩大的高性能数据存储解决方案。下载地址: https://mirrors.aliyun.com/mongodb/ 三、MongoDB 镜像配置办法1、配置CentOS零碎的YUM源（基于Linux零碎）查看零碎版本信息 Kernel 3.10.0-1160.el7.x86_64 on an x86_64centos login: rootPassword:Last login: Wed Dec 22 13:42:01 on tty1[root@centos ~]# hostnamectl Static hostname: centos Icon name: computer-vm Chassis: vm Machine ID: f6fc8fb7991c4c518238af7c75f16046 Boot ID: 870af0bae5394857882a0baa5fa4c8e0 Virtualization: vmware Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-1160.el7.x86_64 Architecture: x86-64[root@centos ~]#革除并更新YUM源 [root@centos ~]# yum clean all[root@centos ~]# yum repolist ...

阿里云官网镜像站：阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 简介 域名零碎（服务）协定（DNS）是一种分布式网络目录服务，次要用于域名与 IP 地址的互相转换，以及管制因特网的电子邮件的发送。 阿里云公共DNS，是阿里云面向所有互联网用户的寰球公共递归域名解析服务，作为国内互联网基础设施的一部分，聚焦终端设备的互联网拜访第一跳能力，提供疾速、平安、稳固、智能的DNS递归解析服务。 Chrome配置办法 第一步：关上Chrome浏览器，从 Firefox 菜单栏中点击 【设置】选项。    第二步：在搜寻框中输出“DNS”，在下方的检索后果中，点击【平安】右侧的开展箭头。    第三步：页面下拉到最下方，在【高级】选项中，开明“应用平安DNS”性能，并在【应用】-【自定义】框中输出“ https://dns.alidns.com/dns-query ”即可实现配置。  阿里云公共DNS 会是你最佳抉择 疾速公共DNS(递归解析) + 云解析DNS(权威解析),一站式DNS解析闭环;动静缓存技术,缩小层层递归，减速解析响应. 稳固寰球数百台服务器组成的集群，短缺的带宽资源；多年来公共DNS经营教训，提供高质量，稳固的接入服务. 平安反对用户ECS扩大技术，智能解析；反对DoT/DoH协定，爱护用户隐衷，平安防劫持.

近日，阿里云公司发现 Apache Log4j2 组件重大安全漏洞隐患后，未及时向电信主管部门报告，未无效撑持工信部发展网络安全威逼和破绽治理。经钻研，现暂停阿里云公司作为工信部网络安全威逼信息共享平台单干单位6个月。暂停期满后，依据阿里云公司整改状况，钻研复原其上述单干单位。 据理解，Apache Log4j2 的破绽由阿里云团队发现。11月24日，阿里云平安团队曾向Apache官网报告了 Apache Log4j2 近程代码执行破绽。因为 Log4j2 组件在处理程序日志记录时存在JNDI 注入缺点，未经受权的攻击者利用该破绽，可向指标服务器发送精心结构的歹意数据，触发Log4j2 组件解析缺点，实现目标服务器的任意代码执行，取得指标服务器权限。 不过，直到 12 月 9 日，工信部网络安全威逼和破绽信息共享平台才收到无关网络安全业余机构报告，组织应答策略并对外颁布危险。12 月17 日，工信部通报称，该破绽可能导致设施近程受控，进而引发敏感信息窃取、设施服务中断等严重危害，属于高危破绽。目前，Apache 官网已公布补丁。 据理解，自该破绽公开以来，很多网站如百度等都是此次执行破绽的受害者，很多互联网企业也都连夜做了应急措施。 除本次暂停单干外，往年 11 月，工业和信息化部网络安全管理局、公安部刑事侦查局也曾联结约谈阿里云、百度云两家企业相干负责人，通报了近期两家企业在防备治理电信网络欺骗工作中存在的接入涉诈网站数量居高不下等问题。

采访嘉宾：张军（游骥） 随着新技术的不断涌现，企业在数字化转型的落地过程中会面临诸多技术难题，对此，阿里云公布业界首款云原生技术中台产品——云原生 Stack（简称 CNStack）。与常听到的业务中台、数据中台等概念相比，云原生技术中台概念如何了解？它将怎么具体帮忙企业解决企业数字化转型难题？ 11 月 24 日，InfoQ 大咖说栏目邀请到了阿里云云原生 PaaS 团队负责人、资深技术专家张军，花名游骥，来做相干问题分享。游骥从云原生技术的倒退聊到云原生技术中台产品的布局以及它的落地实际案例。 游骥主导设计和建设了阿里团体和阿里云泛滥高可用技术产品体系，也是双 11 稳定性保障根底技术外围缔造者，目前负责云原生 PaaS 平台的建设。以下内容节选自当天的分享，InfoQ 做了不扭转原意的编辑： InfoQ：首先，请游骥来和大家打个招呼，简略做个自我介绍。 游骥： 大家好，我叫张军，花名游骥。我在 2011 年退出阿里巴巴，过后是负责阿里中间件和高可用相干根底技术，起初也负责过阿里云 SRE 团队，过来十年都在中间件和根底技术相干畛域深耕。我所负责的高可用技术跟双十一的稳定性是严密相干的，当初我次要负责云原生 PaaS 平台的构建，也就是基于云原生技术去打造云原生时代的 PaaS 平台。 \ 云原生技术定义及倒退过程 InfoQ：请游骥来和咱们整体介绍下云原生的定义以及它的倒退过程，在您看来目前云原生处于怎么的阶段呢？ 游骥： 云原生其实是近些年十分火的一个词，但同时它的含意也十分宽泛。从它的提出到明天，其定义和技术外延都在一直变动，咱们援用云原生计算基金会来为它做一个规范定义。 云原生其实是一套架构方法论和技术的汇合，首先它有一个先决条件，咱们的利用都是构建于云上的，而后基于云去构建易于治理、可弹性扩大、容错性好、更加松耦合的利用零碎。 其实云原生不仅定义了所构建利用零碎的状态，还提供了相应的技术汇合，比方咱们十分相熟的容器、微服务、DevOps 以及 Serverless 、服务网格，包含 申明式 API 和不可变基础设施。它不仅提供了一个方法论和理念，同时提供了相应的技术集。在这个技术体制上，云原生的一个标志性事件是 2015 年 CNCF 的成立。CNCF 对于云原生做了一个标准化定义，同时它是比拟中立的一个组织，承接起云原生的推广。CNCF 也提供了方才提到的一系列技术集，在技术集之上提供了整个云原生大图 Landscape，包含相应的技术、工具以及平台，最终去构建经营、治理、可扩大、有更好容错性的业务利用，同时这些业务利用能运行在公共云、公有云以及混合云等不同环境中，这就是云原生的定义和目前的倒退状态。 从云原生诞生，到 CNCF 成立之后，整个云原生技术开始疾速倒退，目前无论是在社区还是在企业，云原生都失去了疾速的落地。 InfoQ：云原生技术倒退到目前的阶段，对于企业来说，带来了哪些益处？同时又带来了哪些挑战？ 游骥： 它的益处其实是不言而喻的。 首先，云原生向下封装整个基础设施的复杂性。它基于 K8s 和容器，曾经看不到上层基础设施的复杂性，并且可能屏蔽底层架构的差异性。明天在云原生的架构和根底上，K8s 和容器曾经变成了基础设施的新界面。 第二，云原生对上可能撑持多种工作负载和分布式架构，不论是咱们的业务利用也好，还是其余设施也好，都能用云原生技术做对立托管。同时它具备人造的分布式能力、微服务能力，可能最大化利用好云的能力，比方弹性、容灾能力、稳定性能力，能最大限度施展云的劣势，这是它的益处。 然而，云原生对于企业落地来说也存在一些挑战。第一，我不晓得大家有没有看过 CNCF 的 Landscape，那是一张非常复杂的技术大图，下面有很多技术组件，这个理念是好的，但其实不太好去把它用起来，这意味着好的理念不肯定可能真正带来好的价值转化。因为技术太多之后，反而不晓得怎么去用好它，怎么的用法是最佳实际，其实是七嘴八舌，没有一个规范说法的。 第二，不足对立的布局和一体化计划。当初很多利用云原生技术的公司，其实都是以组件化的形式在使用，比方用 K8s、容器、微服务、DevOps 或者 Service Mesh，但其实都是以组件化的形式在去用。 以组件化的形式用的话，其实相对来说技术还是比拟割裂，没有一体化的计划，效率也会比拟低，同时组件化的利用带来另外一个问题，就是组件自身也是有复杂性的。尽管在云原生场景下，屏蔽掉了利用和基础设施的复杂性，然而把云原生技术关上，按组件化的形式应用，这自身也有运维老本，并且它的组件生态也十分丰盛，在经营老本的压力下，也会带来一系列稳定性、可用性的问题，这就是对于云原生技术来说的一些挑战。 ...

作者 ：史明伟（世如）阿里云高级技术专家 随着云原生技术的遍及和落地，企业在构建业务零碎时，往往须要依赖多个云产品和服务，产品互联、零碎协同的需要越来越强。事件驱动架构将事件利用于解耦服务之间的触发和交互， 可能帮忙用户很好实现产品、零碎之间的互联互动。函数计算作为事件驱动架构的最佳抉择，须要为用户提供丰盛的事件源触发能力。 对于函数计算而言，事件源接入须要清晰地理解上游每一个事件源的诸多细节和鉴权要求，同时事件处理和零碎谬误追踪变得越加艰难，集成效率成为妨碍产品能力的最大阻碍。为了减速事件源集成的效率，函数计算须要找到一种统一标准的事件源接入形式，基于通用的接入层进行根底能力和可观测性的建设，为客户提供丰盛的事件源触发抉择。 在这样的背景和需要下，阿里云函数计算（Function Compute）和阿里云事件总线（EventBridge）产品实现全面深度集成。 这意味着函数计算和阿里云生态各产品及业务 SaaS 零碎有了统一标准的接入形式，意味着函数计算将具备接入 EventBridge 所有事件源的触发能力，Serverless 函数计算将实现触达阿里云全系产品服务的“最初一公里”，为基于阿里云生态产品提供重要的架构扩大能力。 为什么是 EventBridge？阿里云事件总线（EventBridge）是一种无服务器事件总线，反对将用户的应用程序、第三方软件即服务（SaaS）数据和阿里云服务的数据通过事件的形式轻松的连贯到一起，这里汇聚了来自云产品及 SaaS 服务的丰盛事件，EventBridge 具备事件标准化和接入标准化的能力： 事件标准化：EventBridge 遵循业界规范的 CloudEvent 事件标准，汇聚了来自阿里云生态和 EventBridge 合作伙伴丰盛事件源的各种事件，同时提供了欠缺的事件投递机制和生产策略，整个零碎事件流转遵循对立的事件格局；接入标准化：函数计算抉择和 EventBridge 集成，无论是产品服务类型泛滥的阿里云官网事件源，还是第三方 SaaS 零碎，EventBridge 都可能为函数计算和其它系统集成提供对立的集成界面，函数计算无需关注上游事件源的具体实现细节，只须要专一于事件处理，将事件的集成和投递全副交给 EventBridge 来解决；EventBridge  + Function Compute 的联合让事件驱动型应用程序的构建变得简略，因为它能够为您实现事件摄取和交付、平安保障、受权以及错误处理工作。容许您构建涣散耦合和散布的事件驱动型架构，帮忙进步开发人员敏捷性和应用程序弹性。函数计算零碎提供了欠缺的函数创立， 公布和运行体系，灵便的构建能力联合极致的运行时弹性能力将帮忙业务构建云原生时代最富显著特色的事件驱动型架构。 同时，EventBridge 可能提供来自事件源（例如 MQ、OSS、RDB等）的实时数据流，并将该数据路由到阿里云函数计算作为指标。您能够设置路由规定来确定发送数据的目的地，以便构建可能实时响应所有数据源的应用程序架构。 函数计算 + EventBridge 带来的变动？提供 90+ 事件源接入在和 EventBridge 集成之前， 函数计算曾经实现了和阿里云局部外围零碎的集成，随着函数计算 EventBridge 的深度集成，阿里云生态大量服务实现了和函数计算集成， 这些服务或产品的事件将作为事件源触发函数；目前函数计算触发器类型曾经从原来的 15+ 减少到 90+，并随着 EventBridge 上游接入零碎的减少而不断丰富； 控制台享受一站式服务EventBridge 和函数计算控制台数据互通，用户在 EventBridge 控制台可能以事件为主体选择函数计算作为事件处理指标，在 EventBridge 控制台享受一站式服务；同样在函数计算控制台，用户可能依据不同触发器类型依据对应的事件类型编写函数；用户无需在函数计算控制台和事件总线控制台来回跳转； 保证数据一致性和稳定性用户无论是在函数计算管制台上通过创立触发器的形式解决指定事件源的事件；还是在 EventBridge 控制台应用函数计算作为事件处理指标，提供对立的资源视图；同时在底层零碎实现上，因为后端系统 API 的深度集成，可能保障下层业务逻辑采纳对立的 API 及解决逻辑，从技术层面确保了多个入口性能实现的一致性，为客户零碎稳固运行奠定松软的根底； 简化数据生产投递的复杂度对于数据生产场景，EventBridge 负责了上游零碎的对接和数据生产，用户无需关怀事件源零碎数据具体生产形式，这部分工作对立由 EventBridge 实现；对于函数计算用户，只须要思考数据投递的逻辑；用户能够间接抉择 EventBridge 提供的上游 Target 实现数据投递，也能够在代码层面仅应用 EventBridge 提供的 SDK 实现数据的投递，大大简化了数据投递的复杂度。 ...

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) pypi镜像-pypi下载地址-pypi装置教程-阿里巴巴开源镜像站 (aliyun.com) https://pypi.org/ 二、PyPI 镜像简介PyPI (Python Package Index) 是 Python 编程语言的软件存储库。开发者能够通过 PyPI 查找和装置由 Python 社区开发和共享的软件，也能够将本人开发的库上传至 PyPI 。下载地址：https://mirrors.aliyun.com/pypi/ 三、PyPI 镜像配置办法默认状况下 pip 应用的是国外的镜像，在下载的时候速度十分慢，本文咱们介绍应用阿里云的镜像源源，地址为：https://mirrors.aliyun.com/pypi/ Windows零碎下应用1️ 关上运行框，输出：==%APPDATA%== 2️ 按回车跳转进入此目录，并新建一个名为pip文件夹 3️ 在pip文件夹内创立pip.ini文件 4️在pip.ini文件夹内填写以下配置信息 [global]index-url = https://mirrors.aliyun.com/pypi/simple/[install]trusted-host=mirrors.aliyun.com 5️ 测试应用 C:\Users\xybdiy>pip install some-packageDefaulting to user installation because normal site-packages is not writeableLooking in indexes: https://mirrors.aliyun.com/pypi/simple/Collecting some-package Downloading https://mirrors.aliyun.com/pypi/packages/e7/a2/d318a685319c3801db1ae0002fc8e095663a55546c62a6e30d9d0fc3289b/some-package-0.1.zip (2.8 kB) Preparing metadata (setup.py) ... doneUsing legacy 'setup.py install' for some-package, since package 'wheel' is not installed.Installing collected packages: some-package Running setup.py install for some-package ... doneSuccessfully installed some-package-0.1C:\Users\xybdiy>pip listPackage Version--------------- -------cffi 1.15.0cycler 0.11.0fonttools 4.28.3kiwisolver 1.3.2numpy 1.21.4packaging 21.3Pillow 8.4.0pip 21.3.1pycparser 2.21pyparsing 3.0.6python-dateutil 2.8.2scapy 2.4.5setuptools 57.4.0setuptools-scm 6.3.2six 1.16.0some-package 0.1tomli 1.2.2C:\Users\xybdiy> ...

服务信息服务列表以接口为维度展现出所提供的服务信息，并依照注册起源接口级/利用级进行辨别。 服务详情页面展现接口的提供者与消费者信息和接口的办法等信息。 动静路由条件路由条件路由能够编写一些自定义路由规定实现一些服务治理的需要比方黑白名单、读写拆散等。条件路由能够在接口级别和消费者利用级别创立规定。 创立条件路由规定须要填写 interface、version、group 信息（version、group无则不填），下图展现一个简略的黑名单配置，=> 右边代表消费者匹配条件，左边代表provider匹配条件（无代表没有匹配）具体规定详情参考官网（具体请见文末相干链接）。所以配置的含意为consumer ip 为 192.168.1.3 的消费者没有 provider 提供服务。 标签路由标签路由通过将某一个或多个服务的提供者划分到同一个分组，束缚流量只在指定分组中流转，从而实现流量隔离的目标，能够作为蓝绿公布、灰度公布等场景的能力根底。在 provider 利用级别上创立规定，对于的动态打标为： dubbo.provider.tag=tag1@DubboService(tag = "tag2") Mesh 路由Mesh 路由是 3.0 版本推出的新的流量管理策略，反对更多的条件匹配和组合能够轻松实现各种路由性能。将整个流量治理分成 VirtualService 和 DestinationRule 两局部，VirtualService 匹配入口流量，DestinationRule 匹配进口流量。具体规定参考文档（具体请见文末相干链接）。 案例一个接口 org.test.apache.dubbo.interfaces.HelloService#hi(Integer number) 参数 number 为 Integer 类型，下述规定示意当 number 为偶数匹配 label 为 v1 的 provider （即 url 参数带有 test-version = v1 的服务），当为奇数匹配 label 为 v2 的 provider （即 url 参数带有 test-version = v2 的服务），能够通过 dubbo.application.parameters.test-version = v1 给服务打标，实现一个简略的灰度性能。 apiVersion: service.dubbo.apache.org/v1alpha1kind: VirtualServicemetadata: name: demo/oddEvenRouterspec: dubbo: - routedetail: - match: - method: argc: 1 args: - index: 0 num_value: oneof: - exact: 0.0 mod: 2.0 type: int name_match: exact: hi name: even-route route: - destination: host: demo subset: v1 - match: - method: argc: 1 args: - index: 0 num_value: oneof: - exact: 1.0 mod: 2.0 type: int name_match: exact: hi name: odd-route route: - destination: host: demo2 subset: v2 services: - exact: org.test.apache.dubbo.interfaces.HelloService ---apiVersion: service.dubbo.apache.org/v1alpha1kind: DestinationRulemetadata: name: test-routespec: host: demo subsets: - name: v1 labels: test-version: v1 - name: v2 labels: test-version: v2动静配置动静配置提供了毋庸重启能够动静调整 RPC 调用行为的一种能力。比方批改超时工夫、权重、负载平衡策略调整等。作用在接口级别和利用级别。下图含意为将超时工夫调整为 6000ms，作用在 conusmer 侧的所有节点。 ...

2021 年 12 月 9 日至 10 日，KubeCon + CloudNativeCon + OpenSourceSummit China 2021 在线上举办。阿里云资深技术专家、容器服务研发负责人易立在大会主论坛进行了主题为 “云将来，新可能” 的演讲，分享了阿里云基于大规模云原生实际下的技术趋势判断和技术创新停顿。 以下为分享全文实录。 易立，阿里云资深技术专家、容器服务研发负责人 大家好，我是阿里云易立，目前负责容器服务产品线，也是 CNCF governing board 的成员。这是第二次在 KubeCon 与大家在线上交换。明天，我会分享阿里云在云原生畛域的实际和思考，以及咱们对将来的一些判断。 云原生 - 数字经济技术创新基石2020 年以来，新冠疫情扭转了寰球经济的运行与人们的生存。数字化的生产与生存形式成为后疫情时代的新常态。明天，云计算曾经成为社会的数字经济基础设施，而云原生技术正在粗浅地扭转企业上云和用云的形式。 阿里云对云原生的定义是应云而生的软件、硬件和架构，帮忙企业最大化取得云价值。具体来说，云原生技术给企业带来 3 个外围的业务价值： 麻利高效 - 更好反对 DevOps 晋升利用研发和交付效率，晋升弹性和资源利用率。帮忙企业能够更好应答环境变动，升高计算成本。增强韧性 - 利用容器技术能够简化业务上云，更好撑持微服务利用架构；进一步增强 IT 企业基础设施和利用架构韧性，保障企业业务连续性。交融翻新 - 5G，AIoT，AR/VR 等新技术疾速倒退，云原生技术让计算无处不在，能够更好地反对的新的交融计算状态。如果说云原生代表了云计算的明天，那么云计算的将来会是什么样？ 云将来，新可能数据中心作为数字经济的能源引擎，其能耗增长已成为云计算倒退中不可疏忽的问题。据报道，2020 年数据中心耗电量超过国内总用电量的 2.3%。而且占比将逐年减少。阿里云在事必躬亲地推动绿色计算，比方利用浸没式液冷服务器来升高数据中心 PUE。除此之外，咱们看到数据中心的计算效率也有很大晋升空间，据统计，寰球数据中心的均匀资源利用率不到 20%，这是微小资源和能源节约。 而云计算的实质，就是把离散的算力，聚合成更大的资源池，通过优化的资源调度，充沛削峰填谷，提供极致的能效比。 新一代对立资源调度助力绿色计算在阿里团体实现了全面上云之后，咱们启动了一个新的打算——利用云原生技术，对阿里团体散布在寰球数十个地区的数千万核的服务器资源，进行对立资源调度，全面晋升利用率。通过阿里团体、阿里云泛滥团队的致力，往年双 11，对立调度我的项目交出了一份闪亮的答卷！ 基于 Kubernetes 和阿里自研的对立调度器 Cybernetes，通过一套调度协定、一套零碎架构，对底层的计算资源进行智能化调度，向上撑持多种工作负载的混合部署，在保障利用 SLO 的前提下，晋升资源利用率。让电商的微服务、中间件等利用，搜推广、MaxCompute 的大数据和 AI 业务，全副运行在对立的容器平台根底之上。为阿里团体每年能够缩小数万台服务器算力的洽购，带来数以亿计的资源老本优化。 其中单集群规模超过上万节点、百万核。任务调度效率达到每秒 2 万个，满足搜寻、大数据、AI 等高吞吐、低提早业务调度编排需要，性能卓越。对立调度帮忙阿里双 11 大促成本升高 50%，生产环境常态化 CPU 利用率 65%。 ...

近日，由中国信通院和混沌工程实验室联结举办的混沌工程技术沙龙--金融行业精品专场顺利召开，并公布金融级产品稳定性测评成绩。在分布式系统稳定性评估体系获奖名单中，阿里云分布式音讯队列服务成为通过首批音讯队列服务稳定性认证，荣获最高级别 “先进级” 认证的音讯队列服务。依据混沌测试报告显示，阿里云分布式音讯队列服务 RocketMQ版、Kafka 版已通过单项故障注入测试（服务器宕机、服务发现故障、服务暂停、网络故障、CPU 负载高、内存负载高）和综合故障注入等多项测试，服务 SLA 达到可信云音讯队列服务稳定性先进级能力要求。 这项认证必定了阿里云分布式音讯队列服务在数据安全性、零碎稳定性上的产品能力和技术实力。信通院混沌工程评测，推动了音讯产品的可靠性的晋升，为音讯畛域倒退做出了巨大贡献，同时感谢信通院对阿里云音讯队列 RocketMQ 版，Kafka 版本的认可。 RocketMQ 作为支流的分布式消息中间件，于 2012 年开源，并在 2017 年正式成为 Apache 顶级我的项目。2017 年 2 月 20 日，RocketMQ 正式公布 4.0 版本。 RocketMQ 从设计之初立足于在线交易链路，并利用在大型在线零碎的异步化解决环节，这其中包含：电商物流的交易系统、在线教育课程零碎、大型游戏信令零碎、银行交易系统等不同行业场景。各行各业的企业借助 RocketMQ 进行异步解耦和削峰填谷；同时在非在线业务场景中，泛滥车联网、电商企业基于 RocketMQ 实现 IoT 边缘数据以及 C 端用户行为数据采集传输和集成。 在往年，咱们也终于等来了 5.0 版本。随同着云原生时代的到来以及实时计算的衰亡， 生于云、长于云的 RocketMQ 5.0 应运而生，全新降级为云原生音讯、事件、流交融解决平台，帮忙用户更容易地构建下一代事件驱动和流解决利用。RocketMQ 5.0 专一于音讯基础架构的云原生化演进，聚焦在音讯畛域的后处理场景，反对音讯的流式解决和轻计算，帮忙用户实现音讯的就近计算和剖析，并全面拥抱 Serverless 和 EDA。音讯队列RocketMQ版作为阿里云基于Apache RocketMQ构建的低提早、高并发、高可用、高牢靠的分布式消息中间件，具备以下个性： 稳定性阿里巴巴双十一官网指定音讯产品，撑持阿里巴巴团体所有的音讯服务，历经十余年高可用与高牢靠的严苛考验，是阿里巴巴交易链路的外围产品，服务可用性 99.95%，数据可靠性 99.99999999%。 高性能历年双 11 购物狂欢节零点千万级 TPS、万亿级数据洪峰，发明了寰球最大的业务音讯并发以及流转纪录（日志类音讯除外）；在始终保障高性能前提下，反对亿级音讯沉积，不影响集群的失常服务。 丰盛的音讯类型提供丰盛的音讯类型，满足各种严苛场景下的高级个性需要，以后反对的音讯类型涵盖一般音讯、程序音讯（全局程序 / 分区程序）、分布式事务音讯、定时音讯/延时音讯。 平安访问控制以音讯主题、订阅组的粒度，对每一条音讯的收、发申请都进行严格的访问控制，确保音讯的安全性；全面反对阿里云 RAM 奴才账号、黑白名单、STS 等性能，反对 TLS 传输加密协议、阿里云 VPC 拜访等。 ...

作者：穹谷｜阿里云技术专家，ChaosBlade 社区以及商业化产品的 Founder 和 Maintainer ，乐于参加混沌工程布道。 2021 年 12 月 7 日，由信通院主办、混沌工程实验室承办的“混沌工程技术沙龙-金融行业精品专场”沙龙在北京举办，来自阿里云的技术专家穹谷分享“从甲方到乙方，如何做好混沌工程的行业化落地”。混沌工程逐渐成为企业晋升稳定性的重要伎俩企业零碎云原生化，带动利用公布迭代速度越来越快，但分布式系统的复杂性也越来越高，从而导致故障频发，如 Google Cloud 服务器因为外部存储配额问题造成身份验证零碎中断、AWS 解决流媒体数据服务呈现问题，云服务宕机 5 小时等故障，都造成了重大影响。 因为零碎不可预测的行为危险增多，云上简单零碎的稳定性难以保障，所以混沌工程逐渐成为企业寻求业务连续性的重要计划。企业希图通过混沌工程用来保障生产环境的分布式系统在面对失控条件的时候依然具备较强的韧性。 同时行业也在一直加强混沌工程畛域的规范制订，信通院通过公布《混沌工程平台能力要求》、《混沌工程成熟度模型》、《混沌工程稳定性度量模型》等标准规范推动混沌工程畛域倒退，同时联结各企业成立混沌工程实验室，促成了混沌工程在国内疾速倒退。 甲乙双方的需要和供应不同，造成混沌工程的行业化落地窘境自混沌工程准则提出，国内外头部互联网、云厂商等公司开始涌现一批初具状态的混沌工程平台服务，互联网的公司的特点使平台倒退路线关注在产品化、生产环境、试验摸索、云原生等方面。依据信通院联结各企业公布的《中国混沌工程调查报告》显示，在混沌工程开发技术上，甲方和乙方对技术产品有不同的抉择。乙方（服务供应侧）更偏向于采纳自研平台为辅助，而甲方（服务需要侧）更偏向于采纳商业化平台作为辅助，在抉择商业化平台时更加关注产品欠缺度、行业案例、平安、技术可控等能力，面对的问题如场景如何梳理、施行环境如何建设、稳定性如何评估、影响范畴如何管制、试验流程如何制订、组织如何协同、落地价值如何体现、行业个性笼罩、运维体系如何集成等问题，所以不仅须要技术，还须要服务，融入行业个性联合实际模式来落地混沌工程。那如何去做呢？阿里巴巴联合外部混沌工程的演进，包含团体、商业化、开源等方向全方位提供混沌工程能力，联合行业化客户面临落地混沌工程的艰难，提供了一套成熟的混沌工程行业化落地解决方案。 阿里巴巴混沌工程行业化解决方案提供社区版和企业版阿里巴巴混沌工程行业化的解决方案蕴含平台技术和服务两局部，平台技术局部蕴含混沌工程平台社区版和混沌工程平台企业版本。社区版本是代码全副开源，由社区开发保护的版本。企业版本是提供私有云 SaaS和专有云部署的版本，相比于社区版本，提供更合乎企业级规模化、场景化、平安可控等平台需要。 混沌工程平台社区版混沌工程平台社区版是开源的，面向多集群、多环境、多语言的通用混沌工程平台，目标是解决用户开始着手启动混沌工程的问题。在平台上能够配置多个环境实现资源隔离，在每个环境中反对多主机、多集群、多容器资源管理和故障注入，还反对运行在这些资源上的 Java、Golang、C++ 等多语言利用；同时还反对托管业内支流的混沌工程试验工具如 chaosblade、chaos mesh 和 litmuschaos，能够在平台上实现一键部署；并且对立了试验界面，能够间接在平台上应用这些工具提供的试验场景。除工具托管性能外，还提供场景治理、多维演练、流程编排、稳态检测、演练防护、演练报告、多租户等能力，提供 OpenAPI 可供内部集成。社区版和 CNCF 生态严密关联，如 Prometheus、HELM 等我的项目。 混沌工程平台企业版混沌工程平台企业版定位是提供规模化、场景化、自动化、平安的产品能力，笼罩 IaaS、PaaS、SaaS 全栈场景。采纳社区版内核能力，可提供社区版往企业版一键降级的能力，同时针对行业化客户已有的运维零碎，如全链路压测系统、环境技术、单元化容灾平台、预案零碎、可观测等进行适配集成，通过与这些平台集成，能够很好的解决爆炸半径、稳态评估、自动化运行试验等问题。 行业化客户利用架构个别具备多语言、多平台、异构云、多供应商架构等特点，混沌工程企业版能够很好的适配集成，不便实现混沌工程一体化平台。除了适配集成外，企业版相比如社区版平台的能力更丰盛，可从四个方面来看： 丰盛的演练场景：企业版反对 200 多个故障场景、反对云服务、同时兼容 Windows 平台，反对预检、断网、复原、复盘一站式的容灾断网演练，和服务级别的微服务演练。多样化的演练模式：反对自定义演练机器、场景，能够将试验积淀为教训库或者间接创立教训模板一键演练，简略便捷。提供高阶的演练计划，按需配置。反对可视化演练，在架构拓扑图上一键发动演练，能够很无效的查看演练状态和保障半径。易用的演练平台：业务零革新即可应用企业版平台，反对架构自动化感知，实现主动梳理架构拓扑、演练可视化等。反对一键从社区版降级至企业版，满足企业级的须要。平安的演练保障：提供多种演练复原策略，如通过配置业务指标阈值来管制演练状态，平安可控。提供细粒度的权限管控等。 通用混沌工程实际模式阿里巴巴混沌工程实际模式是一套建设在阿里外部多年混沌工程实际、社区开源探讨和多个企业我的项目案例的根底上，形象出的一套通用混沌工程实际模式。通过此实际模式，能够大幅度降低企业在混沌工程课题引入、指标设定、组织设计等，确保有目的性的混沌工程落地。实际模式一共分为三类，业务导向型混沌实际、架构导向型混沌实际和组织导向型混沌实际： 业务导向型混沌实际，是一种以业务为视角的实际办法，通过模式模板，能够疾速演练裸露业务架构设计的问题，升高突发故障对业务带来的影响。实际模式蕴含服务间的强弱依赖模式，波及到金融、资金类的资损防控模式，波及用户应用体验类的用户体验模式和客户端类终端容灾模式，典型的利用场景如手机银行、交易结算。架构导向型混沌实际，是一种以基础设施为视角的实际办法，通过模式模板，从基础设施的使用者和运维者角度发现问题、度量稳定性，缩短故障复原工夫。实际模式蕴含验证监控覆盖度和有效性的可观测模式，通过对 SLI 演练验证对外提供 SLA 的服务等级协定模式，验证同城双活异地多活劫难恢复模式、验证服务自愈的故障恢复模式。应用场景有外围架构分布式革新、外围业务上云等。组织导向型混沌工程实际，是一种全局视角度量和晋升稳定性的实际办法，通过组织经营，能够大幅度晋升混沌工程气氛，促成团队的组织协同，晋升故障应急效率。实际模式蕴含计划性的故障演习模式、在特定工夫组织红蓝军反抗的红蓝攻防模式、对生产环境发动的奇袭攻打模式。典型的应用场景有针对故障应急 1-5-10 的达标率考核、大型稳定性我的项目推动等。 三种落地交付模式通过咨询服务总结出一套混沌工程实际模式，能够更加聚焦的解决混沌工程层次化落地实际问题。在理论的客户交付中，依据客户阶段，逐渐衍生出三种交付模式，即：社区版加可行性评估模式、企业版加规模化落地模式、企业版加行业深度共建3种模式。 模式1 ：社区版+可行性评估模式（轻征询） ，次要是通过开源的混沌工程平台加混沌工程专家教训，疾速在企业中落地施行混沌工程，进行后续混沌工程全面铺开的可行性评估。模式2 ：企业版+规模化落地模式，通过私有云或专有云部署，借助此平台的企业级性能个性，能够实现在企业中规模化落地。模式3：企业版+行业深度共建模式，通过专有云部署，通过专有云版本集成与被集成的能力，联合客户已有零碎，进行深度共建，实现平台一体化。 社区版 + 可行性评估（轻征询）的交付模式借助混沌工程社区版和阿里巴巴多年在团体和客户积淀的落地教训，切实解决客户面对混沌工程无从下手的困境，疾速落地混沌工程，实现混沌工程在企业落地的可行性评估。 这个模式的典型客户的案例如上，客户背景是为满足主机下移，对系统进行了分布式架构革新，自研分布式框架须要验证其高可用能力，但没有混沌工程相干教训，想借此我的项目在企业中落地混沌工程。客户目标也很明确，要求提供混沌工程技术方法论并教会相干测试人员如何做场景剖析、部署混沌工程工具平台并教会测试人员如何基于 ChaosBlade 扩大故障场景、率领落地施行混沌工程，教会测试人员整个混沌工程施行流程。 针对客户的背景和指标，先对客户技术架构、业务架构、部署架构、稳定性保障等现状进行调研，产出稳定性剖析报告，提出稳定性问题危险点，提供混沌工程技术培训，剖析故障场景剖析案例，率领客户基于客户自研的分布式框架做故障场景剖析；同时领导客户基于 ChaosBlade 做自研故障场景开发，提供混沌工程整体技术计划和落地实施规划： ...

一、参考链接OpenSSH 阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) openssh镜像-openssh下载地址-openssh装置教程-阿里巴巴开源镜像站 (aliyun.com) OpenSSH8.6装置教程_wqww_1的博客-CSDN博客_openssh8.6安装包 二、OpenSSH简介OpenSSH（OpenBSD Secure Shell）是应用SSH透过计算机网络加密通信的实现。它是取代由SSH Communications Security所提供的商用版本的凋谢源代码计划。目前OpenSSH是OpenBSD的子项目。 OpenSSH经常被误认认为与OpenSSL有关系，但实际上这两个我的项目有不同的目标，不同的倒退团队，名称相近只是因为两者有同样的软件倒退指标──提供凋谢源代码的加密通信软件。 起源：维基百科 三、OpenSSH安装操作1、革除缓存并更新YUM源[root@centos ~]# yum clean allLoaded plugins: fastestmirrorCleaning repos: base extras updatesCleaning up list of fastest mirrors[root@centos ~]# yum repolistLoaded plugins: fastestmirrorLoading mirror speeds from cached hostfile * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.comrepo id repo name statusbase/7/x86_64 CentOS-7 - Base - mirrors.aliyun.com 10,072extras/7/x86_64 CentOS-7 - Extras - mirrors.aliyun.com 500updates/7/x86_64 CentOS-7 - Updates - mirrors.aliyun.com 3,190repolist: 13,7622、查看原来SSH版本信息并卸载[root@centos ~]# rpm -qa | grep sshopenssh-clients-7.4p1-21.el7.x86_64openssh-7.4p1-21.el7.x86_64openssh-server-7.4p1-21.el7.x86_64libssh2-1.8.0-4.el7.x86_64[root@centos ~]# ssh -VOpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017[root@centos ~]# rpm -qa | grep openssh | xargs rpm -e --nodeps[root@centos ~]# rpm -qa | grep openssh[root@centos ~]#3、本地下载OpenSSH镜像包并上传至Linux零碎（或者采纳步骤4，二者取其一即可） ...

一、参考链接阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) opensuse镜像-opensuse下载地址-opensuse装置教程-阿里巴巴开源镜像站 (aliyun.com) https://mirrors.aliyun.com/op... 二、OpenSUSE全新装置1、抉择“Installon”装置 期待加载实现 2、点击“Next” 3、点击“下一步” 4、网络设置 5、抉择装置零碎角色 6、分区 7、时钟和时区 8、创立用户名和明码 9、开始装置 10、确认装置 11、期待装置实现 12、装置实现 13、关上XTerm，配置并测试网络连通性 xyb@localhost:~> vi /etc/sysconfig/network/ifcfg-eth0xyb@localhost:~> vi /etc/sysconfig/network/routesxyb@localhost:~> vi /etc/resolv.confxyb@localhost:~> ping qq.comPING qq.com (58.250.137.36) 56(84) bytes of data.64 bytes from 58.250.137.36 (58.250.137.36): icmp_seq=1 ttl=53 time=35.9 ms64 bytes from 58.250.137.36 (58.250.137.36): icmp_seq=2 ttl=53 time=35.7 ms64 bytes from 58.250.137.36 (58.250.137.36): icmp_seq=3 ttl=53 time=35.4 ms^C--- qq.com ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 2004msrtt min/avg/max/mdev = 35.457/35.723/35.965/0.259 msxyb@localhost:~>14、SSH近程连贯OpenSUSE ...

作者 |：西流（阿里云函数计算专家） Spring Boot 是基于 Java Spring 框架的套件，它预装了 Spring 一系列的组件，开发者只须要很少的配置即可创立独立运行的应用程序。 在云原生体系中，有大量的平台都能够运行 Spring Boot 利用，例如虚拟机、容器等。但其中最有吸引力的，是以 Serverless 的形式运行 Spring Boot 利用。我将通过《Spring Boot Serverless 实战》系列文章，从架构，部署，监控、性能、平安等 5 个篇章来剖析 Serverless 平台运行 SpringBoot 利用的优劣。 为了让剖析更有代表性，我抉择了 Github 上 star 数超过 50k 的电商利用 Mall 作为示例。这是该系列文章的第一篇，本文会从架构角度对 Spring Boot 利用的 Serverless 化进行剖析。 Mall 架构简介Mall 是一套电商零碎，包含前台商城零碎及后盾管理系统，基于 Spring Boot + MyBatis 实现。前台商城零碎蕴含首页门户、商品举荐、商品搜寻、商品展现、购物车、订单流程、会员中心、客户服务、帮忙核心等模块。后盾管理系统蕴含商品治理、订单治理、会员治理、促销治理、经营治理、内容治理、统计报表、财务管理、权限治理、设置等模块。 Mall 的架构如下图所示，分为网关层，应用层，数据存储层。申请首先通过网关达到 Spring Boot 应用服务。网关实现负载平衡，流量管制等性能。应用层蕴含 3 个 Spring Boot 利用和1个前端利用： mall-admin：后盾商城管理系统mall-portal：前台商城零碎mall-search：于Elasticsearch的商品搜寻零碎Mall-admin-web：mall-admin 的前端展现，基于 Vue+Element 实现Mall 应用了 MySQL，Redis，MongoDB，ElaisticSearch 等多种数据库。次要业务数据存储在 MySQL，缓存数据存储在 Redis，用户行为剖析数据存储在 MongoDB，搜寻数据存储在 ElasticSearch 中。Spring Boot 应用服务间应用 RabbitMQ 实现异步通信。 ...

Apache Log4j2 近程代码执行破绽已暴发一周，平安厂商提供各类进攻计划和检测工具，甲方团队连夜应急。 影响继续至今，网上流传的各种利用和绕过姿态还在层出不穷，影响面继续扩充。所有平安人都开始反思一个问题：以后的进攻是否无效？针对这样的 0day 再次发生，什么是无效的伎俩？ 阿里云平安团队此次参加了诸多客户应急，并从云平台本身进攻总结经验，尝试抛出一些观点以供探讨。 首先，咱们先来从技术层面剖析一下为什么这次 Log4j2 这么难搞。 Apache Log4j2 破绽们的特质此次 Log4j2 破绽有两个很辣手的特质： 能够实现任意近程代码执行“懂规矩”的破绽，危险大的利用门槛高，利用门槛低的危害小，还算合乎自然规律。这个破绽并不按惯例出牌，岂但影响面广，利用门槛低，危害还极大。三个因素重叠，到处被冠上“史诗级”的头衔。 Java 的利用极其宽泛且生态宏大，而 Log4j 作为日志解决的根底组件被简直所有应用程序所应用。 通过 JNDI 注入的伎俩，能够实现任意近程代码执行，意味着攻击者能够在存在破绽的服务器上随心所欲。 即便在内网环境中 JNDI 外联无奈胜利，攻击者也能够联合 lookup 个性去读取很多敏感信息（如数据库明码、JAVA 环境变量等），再通过 DNS 协定把敏感信息带出内网。 流量特色荫蔽某些场景下简直没有能够跟失常申请辨别开来的强特色。 本次破绽 PoC 结构非常简单，破绽触发的点宽泛而灵便，配合各种变量和协定的嵌套绕过形式，导致流量特色非常复杂和荫蔽。Log4j2 的 lookup 性能反对一些非凡的写法来对字符做二次解决，如 ${lower:j}Ndi、${upper:JN}di、${aaa:vv:cc:-j}ndi 等写法，都能突破字符串的连续性，造成利用时候的流量特色极为不显著。 这是对所有基于流量特色平安防护产品的微小挑战。 当流量特色不够显著时，基于流量特色的规定陷入难堪：要么笼罩不到，要么产生重大误报。只能继续一直补充规定，在绕过和被绕过中周而复始。这种进攻伎俩，能在 0day 暴发初期十分无效的为破绽修复争取时间。但随着各种利用伎俩的变动越来越多，则很难保障没有被绕过或误报。 与 Log4j2 破绽的某些“弱特色”甚至“0 特色”利用形式相似的场景，还有加密流量、内存马等，这些伎俩都曾在大型攻防演练中大放异彩，难以检测的原理是相似的。 所以，有没有一种技术，能够忽视破绽利用手法在流量特色上的各种变动或暗藏，进攻的更人造，甚至不依赖规定更新就能够进攻这类 0day？ RASP 在此次事件中重回视线RASP（Runtime Application Self-Protection），运行时利用自我防护，平安行业其实对其并不生疏，却因为传统印象而驳回不多。 这类技术的劣势在于，以疫情类比，传统的边界进攻类产品，相似口罩/防护服，而 RASP 则相似疫苗，会将本人注入到利用当中，随同利用一起运行，通过 hook 要害函数实时检测利用执行的高危行为。 RASP 是哪一类 0day 的天敌不同于基于流量特色的检测，RASP 外围关注利用行为，而非流量自身。 当 RASP 发现一个利用，做了它失常不应该做的事件时，大概率意味着以后利用曾经被攻击者利用破绽攻陷并做了一些高危操作（比方命令执行、文件读取、文件上传、SSRF 等）。 其第一个劣势是：但凡被 RASP 进攻的行为，都曾经是真正能够被胜利利用的攻击行为。 ...

作者：西杰 & 白玙 可观测的前生今世零碎的可观测与故障可剖析作为零碎运维中重要的衡量标准，随着零碎在架构、资源单位、资源获取形式、通信形式演进过程，遇到了微小挑战。而这些挑战，也在倒逼着运维相干技术倒退。在正式开始明天的内容前，咱们来讲讲可观测的前世今生，纵观整个运维监控倒退历程，监控与可观测曾经倒退了近 30 年。 上世纪 90 年代末，随着计算从大机（mainframe）逐步转移到桌面电脑，client-server 架构的利用开始流行，大家开始关注网络性能和主机资源。为了更好的监控这种 CS 的利用，第一代 APM 软件诞生。运维团队在这一时期看重与网络性能、主机性能，因为此时的利用架构还非常简单。此时，咱们还称这些工具为监控工具。 进入到 2000 年，互联网飞速发展，浏览器成为新的用户界面。利用演进成为基于浏览器的 Browser-App-DB 的三层架构，同时 Java 作为企业级软件的第一编程语言开始流行，编写一次、到处运行（write once，run anywhere）的理念，极大的晋升了代码的生产力，然而 Java 虚拟机也屏蔽了代码运行的细节，使得调优排错变得更加艰难， 所以对于代码级的跟踪诊断和数据库的调优成为新的关注点，从而诞生了新一代的监控工具 APM（利用性能监控）。 2005 年之后，分布式应用成为很多企业的第一抉择，像基于 SOA 架构、ESB 的利用大行其道。同时，虚拟化技术逐步流行，传统服务器这个物理单位逐步淡化，变成了看不见、摸不到的虚构资源模式。像音讯队列、缓存这样的三方组件也开始利用在生产环境中。在这样的技术环境下，催生出新一代 APM 软件，企业开始须要进行全链路追踪，同时监控虚构资源和三方组件监控，这样就衍生出了新一代 APM 的外围能力。 到了 2010 年之后，随着云原生架构开始落地实际，利用架构开始从单体零碎逐渐转变为微服务，其中的业务逻辑随之变成微服务之间的调用与申请。同时虚拟化更加彻底，容器治理平台被越来越多企业承受，三方组件也逐步演变成云服务，整个利用架构成为云原生架构。服务的调用门路变长，使得流量的走向变得不可控，故障排查的难度增大，须要一种全新的可观测能力，通过笼罩全栈的各种可观测数据（指标，日志，链路，事件）在开发测试运维的全利用生命流程进行继续的剖析。 能够看到，可观测能力成为云原生的基础设施。整个可观测能力从单纯的运维态开始向测试开发态演进。可观测的目标也从撑持业务失常运行进一步扩大到减速业务翻新，让业务疾速迭代起来。 监控 & APM & 可观测的认知同异从上述历程，咱们能够看到从监控到 APM 到可观测是个一直演进的过程。接下来，咱们讲讲这三者之间的具体关系。为了更好的解说，这里先引入一个经典认知模型。对于世界万物，咱们通常会依照“知不知道”（awareness）以及“理不了解”（understanding）两个维度进行划分，即“感知”与“了解”。 那么，首先对于咱们晓得且能了解的事件，咱们称之为事实。落到方才探讨的话题中，这一部分对应的就是监控。比方进行运维工作时，一开始时候就会设计去监控服务器的 CPU 利用率，这个利用率不论是 80% 还是 90%，都是一个客观事实。这就是监控解决的事件，即基于晓得要监控什么，制订采集相应指标，并建设监控大盘。 接下来，就是咱们晓得但不了解的事件。比方监控到 CPU 利用率达到 90%，然而为什么会到这么高，是起因什么导致的，这就是一个查证的过程。通过APM能够采集并剖析主机上的利用性能，发现在利用链路调用过程中某个高延时的 log 框架，从而引起了主机上的 CPU 利用率飙升。这就是借助 APM 通过应用层剖析去发现 CPU 利用率高的背地起因。 而后，就是咱们了解但不晓得的事件。仍旧是 CPU 利用率高这个场景案例，如果通过学习历史数据和关联事件预测到将来的某个时刻会呈现 CPU 利用率飙升，就能够实现预警。 ...

作者：涯海 链路追踪的 “第三种玩法” 提起链路追踪，大家会很天然的想到应用调用链排查单次申请的异样，或应用预聚合的链路统计指标进行服务监控与告警。其实，链路追踪还有第三种玩法：相比调用链，它可能更快的定界问题；相比预聚合的监控图表，它能够更灵便的实现自定义诊断。那就是基于明细链路数据的后聚合剖析，简称链路剖析。 链路剖析是基于已存储的全量链路明细数据，自由组合筛选条件与聚合维度进行实时剖析，能够满足不同场景的自定义诊断需要。 比方，查看耗时大于 3 秒的慢调用时序散布，查看谬误申请在不同机器上的散布，查看 VIP 客户的流量变动等。接下来本文将介绍如何通过链路剖析疾速定位五种经典线上问题，更直观的理解链路剖析的用法与价值。 链路剖析 K.O “五大经典问题”基于后聚合的链路剖析用法非常灵活，本文仅列举五种最典型的案例场景，其余场景欢送大家一起摸索分享。 【流量不均】负载平衡配置谬误，导致大量申请打到大量机器，造成“热点”影响服务可用性，怎么办？流量不均导致的“热点击穿”问题，很容易造成服务不可用，在生产环境中呈现过多起这样的案例。比方负载平衡配置谬误，注册核心异样导致重启节点的服务无奈上线，DHT 哈希因子异样等等。 流量不均最大危险在于是否及时发现“热点”景象，它的问题表象更多是服务响应变慢或报错，传统监控无奈直观反映热点景象，所以大部分同学都不会第一工夫思考这个因素，从而节约了贵重的应急解决工夫，造成故障影响面一直扩散。 通过链路剖析按 IP 分组统计链路数据，疾速理解调用申请散布在哪些机器上，特地是问题产生前后的流量散布变动，如果大量申请忽然集中在一台或大量机器，很可能是流量不均导致的热点问题。再联合问题产生点的变更事件，疾速定位造成故障的谬误变更，及时回滚。 【单机故障】网卡损坏/CPU 超卖/磁盘打满等单机故障，导致局部申请失败或超时，如何排查？单机故障每时每刻都在频繁产生，特地是外围集群因为节点数量比拟多，从统计概率来看简直是一种“必然”事件。单机故障不会造成服务大面积不可用，但会造成大量用户申请失败或超时，继续影响用户体验，并造成肯定答疑老本，因而须要及时处理这类问题。 单机故障能够分为宿主机故障和容器故障两类（在 K8s 环境能够分为 Node 和 Pod）。比方 CPU 超卖、硬件故障等都是宿主机级别，会影响所有容器；而磁盘打满，内存溢出等故障仅影响单个容器。因而，在排查单机故障时，能够依据宿主机 IP 和容器 IP 两个维度别离进行剖析。 面对这类问题，能够通过链路剖析先筛选出异样或超时申请，依据宿主机 IP 或容器 IP 进行聚合剖析，疾速判断是否存在单机故障。如果异样申请集中在单台机器，能够尝试替换机器进行疾速复原，或者排查该机器的各项零碎参数：比方磁盘空间是否已满、CPU steal time 是否过低等。如果异样申请扩散在多台机器，那大概率能够排除单机故障因素，能够重点剖析上游依赖服务或程序逻辑是否异样。 【慢接口治理】新利用上线或大促前性能优化，如何疾速梳理慢接口列表，解决性能瓶颈？新利用上线或大促备战时通常须要做一次系统性的性能调优。第一步就是剖析以后零碎存在哪些性能瓶颈，梳理出慢接口的列表和呈现频率。 此时，能够通过链路剖析筛选出耗时大于肯定阈值的调用，再依据接口名称进行分组统计，这样就能够疾速定位慢接口的列表与法则，而后对呈现频率最高的慢接口逐个进行治理。 找到慢接口后，能够联合相干的调用链、办法栈和线程池等数据定位慢调用根因，常见起因包含以下几类： 数据库/微服务连接池过小， 大量申请处于获取连贯状态，能够调大连接池最大线程数解决。N+1 问题， 比方一次内部申请外部调用了上百次的数据库调用，能够将碎片化的申请进行合并，升高网络传输耗时。单次申请数据过大， 导致网络传输和反序列化工夫过长且容易导致 FGC。能够将全量查问改为分页查问，防止一次申请过多数据。日志框架“热锁”， 能够将日志同步输入改为异步输入。 【业务流量统计】如何剖析重保客户/渠道的流量变动和服务质量？在理论生产环境中，服务通常是标准化的，但业务却须要分类分级。同样的订单服务，咱们须要依照类目、渠道、用户等维度进行分类统计，实现精细化经营。比方，对于线下批发渠道而言，每一笔订单、每一个 POS 机的稳定性都可能会触发舆情，线下渠道的 SLA 要求要远高于线上渠道。那么，咱们如何在通用的电商服务体系中，精准的监控线下批发链路的流量状态和服务质量呢？ 在这里，能够应用链路剖析的自定义 Attributes 过滤和统计实现低成本的业务链路剖析。比方，咱们在入口服务针对线下订单打上一个 {"attributes.channel": "offline"} 的标签，而后再针对不同门店、用户客群和商品类目别离打标。最初，通过对 attributes.channel = offline 进行过滤，再对不同的业务标签进行 group by 分组统计调用次数、耗时或错误率等指标，就能够疾速的剖析出每一类业务场景的流量趋势与服务质量。 ...

作者：董善东 & 白玙 对于大部分人来说，信息是一个十分形象的概念。人们经常说信息很多或信息较少，但却很难说分明信息到底有多少。比方一份帮忙文档或一篇文章到底有多少信息量。直到 1948 年，C.E.Shannon（香农）提出了“信息熵”的概念，才解决了对信息的量化度量问题。信息熵这个词是香农从热力学中借鉴而来来的。热力学中的热熵是示意分子状态凌乱水平的物理量。而香农用信息熵的概念来形容信源的不确定度。 香农的信息熵实质上是对咱们司空见惯的 “不确定景象” 的数学化度量。譬如说，如果天气预报说 “今天下午下雨的可能性是 60%” ，咱们就会不谋而合想到出门带伞；如果预报说 “有 60% 的可能性下雨” ，咱们就会犹豫是否带伞，因为雨伞无用时确是累赘之物。显然，第一则天气预报中，下雨这件事的不确定性水平较小，而第二则对于下雨的不确定度就大多了。 作为数学中颇为形象的概念，咱们能够把信息熵了解成某种特定信息的呈现概率。而信息熵和热力学熵是严密相干的。依据 Charles H. Bennett 对 Maxwell's Demon 的从新解释，对信息的销毁是一个不可逆过程，所以销毁信息是合乎热力学第二定律的。而产生信息，则是为零碎引入负（热力学）熵的过程。当一种信息呈现概率更高时，表明被流传得更宽泛，或者说被援用的水平更高。咱们能够认为从信息流传角度来看，信息熵能够示意信息的价值，这样子咱们就有一个掂量信息价值高下的规范。 再具体到咱们日常运维工作场景中，各类的告警事件作为最典型的一种信息，在面对每天海量高警事件咱们该如何评估告警的信息价值成为了一个重要问题。 各大监控平台/工具个别有两种形式去辨认指标异样并触发告警事件。第一种是常见的通过设定阈值/动静阈值的形式。第二种就是设定默认规定，触发零碎预设规定事件，例如：机器重启等。 与此同时，运维团队往往不会依赖繁多的监控工具，常常须要在各种不同档次工具中都设定对应的监控告警。 在这样的背景下，监控源多元化与监控工具类别多样化，往往导致雷同故障起因在不同监控工具、不同监控规定下，触发出大量反复、冗余的告警事件。甚至在产生大范畴故障时造成告警风暴。运维人员很难从这些海量告警中疾速无效的辨认到底哪些告警事件是重要且精确的信息，这也往往导致无效告警被吞没。因而，对于运维团队和告警产品来说，存在以下几个痛点： 多处监控告警源以及频繁误报导致大量反复、冗余、低效事件，重要事件吞没在其中，无奈无效辨认；大范畴故障导致的告警风暴；测试事件等脏数据混在事件中。什么是 ARMS 智能降噪ARMS 智能降噪性能依靠于 NLP 算法和信息熵实践建设模型，从大量历史告警事件中去开掘这些事件的模式法则。当实时事件触发后，实时为每一条事件打上信息熵值与乐音辨认的标签，帮忙用户疾速辨认事件重要性。  智能降噪的实现原理介绍事件核心中大量的历史事件沉积，很难人工实现从这些大量历史事件中形象出事件模式与价值。利用实时监控服务 ARMS ITSM 产品智能降噪功对不同告警源收归到对立平台进行告警事件处理，将这些历史事件进行模式识别，开掘外在关联，建设基于信息熵的机器学习模型辅助用户进行事件重要性的辨认，模型外围步骤包含：  step 1：基于自然语言解决和畛域词汇库， 实现事件内容的词向量化，实现事件最小粒度的度量；step 2：基于信息论中信息熵的概念， 联合 tfidf 模型，构建词向量的信息熵值和重要性度量模型；step 3：利用 sigmod，实现事件的非线性和归一化 “信息熵” 度量；step 4：联合历史事件的解决记录和反馈， 构建模型迭代训练与验证。利用自然语言解决算法，基于信息论中的信息量和信息熵概念来表征事件重要性，帮忙用户利用大量历史事件训练迭代出辨认事件重要性的模型。当新实时事件触发时，疾速辨认事件重要性。同时，联合信息熵阈值设定，来实现乐音事件过滤与屏蔽。并依据工夫演进以及事件类型与内容变动，模型通过自适应定期实现迭代式更新（更新频率为每周一次），无需用户进行任何操作，即可保障模型准确性。  智能降噪业务价值业务价值一：智能化辨认反复、低效事件，开掘离奇事件（1）大量反复、类似事件的辨认对于大量反复、类似事件，该类事件继续大量呈现在事件告警中，模型对于这类事件的信息熵值会继续给予升高的信息熵，即：这类事件的信息熵值会越来越低，直到最初靠近为 0。这是因为模型期待对于重要的事件，用户能够更多关注响应， 而如果事件始终反复、大量触发，往往阐明这类事件用户基本不关怀，从业务逻辑上也辅证了模型机理。  （2）开掘离奇事件对于在历史事件中未曾呈现、比拟少呈现的事件，模型则会重点关注，认定该类事件为离奇事件，给予以后事件较大的信息熵值，以期待用户更多的关注该类事件。因而，ARMS 智能降噪模型还具备帮忙用户辨认重要事件的性能。  业务价值二：定制化需要反对设定对于一些用户测试事件或特定字段事件，咱们经常心愿对这类事件进行定制化解决，例如：测试事件只触发查看整个流程，但不须要去点击做任何解决。再比方，有些事件中蕴含了特地重要字段信息，对于这类事件须要优先解决。  业务价值三: 模型具备高成长性对于历史事件数量较少的用户（事件数量<1000）， 个别不举荐关上该性能，这是因为历史事件数量过少的状况下，模型很难充沛训练，辨认其内在模式和法则。然而在开启后， 模型每周会在本周新产生的事件根底上，进行模型迭代训练。在用户无需关怀的前提下，模型一方面自适应追踪事件模式变动，另外一方面对于原有事件数量不短缺的模型， 也在继续进行充沛迭代。  最佳实际应用流程阐明step 0：入口 step 1：开启 当感觉事件量过多， 反复事件，低效/有效事件过多时， 能够抉择开启智能降噪。 ...

作者：拂衣 引言“压测脚本在我压测环境上跑的好好的，成功率、RT 都很失常，放到本地跑怎么体现就不一样了？” 大家压测时是否都遇到过上述问题？ 除了陈词滥调的硬件配置起因，流量散布因素往往容易被疏忽。 为什么要模仿实在用户流量压测是为了模仿一定量的实在用户对系统进行拜访。实在的用户量能够通过设置并发线程数（虚构用户数）来模仿；用户的起源散布，具体说是流量散布，也是重要的模仿条件。 辅助全局容量布局用户量较大的利用，个别会采纳异地多活的部署形式。出于老本思考，各核心部署规格不肯定雷同，当地用户越多，核心实例数越多，规格越高。大促压测就是要依照实在用户散布比例，来模仿流量。测试出哪些核心容量水位过高，会造成当地用户响应提早甚至服务解体；哪些核心容量水位又过低，能够适当降级，将多余的实例额度正当调配进来。实现从全局层面布局容量，在撑住大促流量的同时，也正当管制老本。 测试出实在相映提早数据表明，对于电商业务外围接口，响应工夫每减少 100ms，营收额对应降落 1%。如果施压机和服务器在同一机房，测试出的申请响应时长（RT）会比真实情况要低，因为用户是全国散布的。对响应提早误判低出的零点几秒，就可能会造成对大促成交额的谬误预期。 通过下图能够直观的看出问题： 如何模仿实在流量传统计划大部分业务的用户并不是按地区均分的，相同，往往很不平均。要模仿实在流量散布，施压机须要在各地扩散部署，并且反对按地区、按量调配，在压测时，还要反对实时的对立调度。如果施压机都散布在一个 Region，甚至是一个可用区内，那是无奈模拟出来自寰球用户申请的。 这样就须要在国内和海内部署大量的施压机，如果压测频率并不很高，那机器的闲置老本可想而知。而按地区、按量调配的调度零碎，也须要肯定的保护老本。 阿里云 PTS 计划应用阿里云性能测试服务（PTS）压测时，开启流量地区定制性能，即可指定施压机的地区散布，目前反对寰球 22 个 Region 的地区定制。阿里云 PTS 作为大促压测重武器，“威力”不减，上手更轻量化。 反对地区见表格： 无论选用哪种计划，最终都要达到施压机地区散布和用户散布统一。 操作指南1、创立一个压测场景，参考 PTS 领导文档（具体请见文末相干链接）； 2、在施压配置中，关上流量地区配置，按业务需要调配流量比例，右侧能够看到流量散布的饼图： 3、开始压测，在压测概览页，能够查看流量地区散布： 总结压测时，压力流量起源是一个很容易被疏忽的因素，要保障压测后果真实可信，就须要依照实在用户的地区散布来筹备施压机。阿里云 PTS 提供了流量地区定制性能，即压即用，反对寰球 22 个 Region，9.9￥体验版资源包即可应用。 相干链接1）阿里云PTS： https://pts.console.aliyun.com/#/overviewpage 2）开明PTS体验版资源包 https://common-buy.aliyun.com/?commodityCode=ptsbag#/buy 3）PTS 领导文档https://help.aliyun.com/document_detail/90887.html

云原生时代，混合云曾经成为企业上云新常态。为了帮忙企业全面构建平安、规范、现代化的云原生 IT 架构，阿里云面向混合云/多集群/分布式计算等场景推出分布式云容器平台，使企业更轻松地连贯并治理用户任何地区/任何基础设施上的多个 Kubernetes 集群，享受到对立治理、对立弹性、对立利用交付、对立容灾的能力。 12 月 8 日 下午 14:00 分布式容器平台正式凋谢公测，3 位阿里云专家将带你解读阿里云容器服务全面降级的背景下，企业如何更轻松地构建云原生分布式的业务零碎，如何更便捷地构建本人的混合云平台，如何更高效地晋升企业线下集群计算资源的弹性能力。 当初进入发布会直播间，领先申请阿里云分布式云容器平台公测名额！ 发布会亮点速递阿里云容器服务全面降级的背景下，用户如何依据本人的业务散布和数据管控需要，在更适宜的地位抉择凋谢、统一的云能力？如何帮忙企业实现跨集群、跨地区、混合云的数据容灾架构，充沛晋升业务数据的整体稳定性？如何疾速晋升企业线下集群计算资源的弹性能力，在业务高峰期实现云端疾速扩容，云上云下独特承当业务流量？对于多集群作业负载的主动散发，如何提供高效的调度、优先级、资源配额？企业外部如何便捷、高效地治理多个云上的资源？如何升高企业混合云治理的门槛，不便企业更加便捷地构建本人的混合云平台？点击此处，阿里云新品公布直播间回放将带给你答案！

作者 | 朱鹏，阿里云 Serverless 技术专家 基于 ECS 的 FaaS在阿里云传统架构，用户通过互联网进入到负载平衡零碎中，再通过负载平衡把零碎的申请调度到不同的机器下来。这种传统的架构带来的问题比拟多，一方面是多利用配比比例容易失衡，造成资源节约；另一方面是镜像降级比拟繁琐，整个过程的开机速度在分钟级，扩容速度也绝对较慢。 架构设计基于 ECS 的 FaaS 架构设计同样也是通过互联网进入，落到 SLB 负载平衡上。SLB 负载平衡这个零碎是部署在阿里云外部的，次要用于抵御 DDoS 攻打及申请平衡到多台 api server 上。api server 再发动函数的 CRUD 操作，并向 Scheduler 申请容器。Scheduler 治理容器在 worker 的搁置，申请落在容器上的调度散发。用户所在 worker 就是咱们称之为的计算节点，如果须要拜访用户的 VPC 环境则在计算节点上通过 ENI 网卡买通到用户 VPC 环境。 多租户多利用部署的反对namespace 是 linux 前几年推出的一个资源隔离计划，能够在内核层面做一些设置指定一部分过程固定。并且能够在 cgroup 的这一套设置计划里设置，管制资源的拜访。在 namespace、cgroup 整套计划下，衍生出了 container，社区中罕用的的 Docker 计划把镜像操作系统中的很多细节包装成一个计划，用户看到了一个绝对比拟残缺的操作系统，把用户当成一个单个用户搁置在虚拟机当中。这就是一个 vm，相当于说一台 ECS，这里就是操作系统层面，把整个 cpu、memory、包含设施全副给屏蔽掉，在下面用 cgroup 封一层，对应的就是 Docker 容器。 利用搁置策略包含用户独占虚拟机、同 VPC 独占虚拟机、资源拜访权限统一的 APP 混部在同机器。把两个不同的用户混在一个 vm 下，也就是 ECS 下面，对于用户之间来说是存在危险的。为了屏蔽掉共用 kernel 带来的危险，ECS 上的实现，咱们单个 ECS 只有一个租户，这样解决也存在一些问题，最突出的就是对于低频调用函数资源使用率低。 ...

12月2日，由阿里云 Serverless 团队主办的「云原生 Serverless 技术实际营」在广州顺利举办，本次流动面向所有企业技术人员，主打“沉迷式沙龙体验，6 小时搞定 Serverless 企业落地。” 流动当天 5 位阿里云技术讲师别离从技术、产品、架构和开发者工具的视角围绕 Serverless 的发展趋势、落地实际与参会者零距离分享最佳实际心得，全程弹幕互动答疑，和到场的开发者独特探讨交换 Serverless 企业落地的更多可能性。此次实际营共有来自互联网、区域线、文化传媒、金融、新批发、电销和生态行业等 80+ 企业，100+ 位开发者来到现场，上面就让咱们带你一图理解流动详情！

Dubbo3 提供了 Triple(Dubbo3)、Dubbo2 协定，这是 Dubbo 框架的原生协定。除此之外，Dubbo3 也对泛滥第三方协定进行了集成，并将它们纳入 Dubbo 的编程与服务治理体系， 包含 gRPC、Thrift、JsonRPC、Hessian2、REST 等。以下重点介绍 Triple 与 Dubbo2 协定。 下一代 RPC 协定 - TripleTriple 协定是 Dubbo3 推出的主力协定。Triple 意为第三代，通过 Dubbo1.0/ Dubbo2.0 两代协定的演进，以及云原生带来的技术标准化浪潮，Dubbo3 新协定 Triple 应运而生。 RPC 协定简介协定是 RPC 的外围，它标准了数据在网络中的传输内容和格局。除必须的申请、响应数据外，通常还会蕴含额定控制数据，如单次申请的序列化形式、超时工夫、压缩形式和鉴权信息等。 协定的内容蕴含三局部： 数据交换格局：定义 RPC 的申请和响应对象在网络传输中的字节流内容，也叫作序列化形式；协定构造：定义蕴含字段列表和各字段语义以及不同字段的排列形式；协定通过定义规定、格局和语义来约定数据如何在网络间传输。一次胜利的 RPC 须要通信的两端都可能依照协定约定进行网络字节流的读写和对象转换。如果两端对应用的协定不能达成统一，就会呈现鸡同鸭讲，无奈满足近程通信的需要。 RPC 协定的设计须要思考以下内容： 通用性：对立的二进制格局，跨语言、跨平台、多传输层协定反对扩展性：协定减少字段、降级、反对用户扩大和附加业务元数据性能：As fast as it can be穿透性：可能被各种终端设备辨认和转发：网关、代理服务器等 通用性和高性能通常无奈同时达到，须要协定设计者进行肯定的取舍HTTP/1.1比于间接构建于 TCP 传输层的公有 RPC 协定，构建于 HTTP 之上的近程调用解决方案会有更好的通用性，如WebServices 或 REST 架构，应用 HTTP + JSON 能够说是一个事实标准的解决方案。 抉择构建在 HTTP 之上，有两个最大的劣势： HTTP 的语义和可扩展性能很好的满足 RPC 调用需要。通用性，HTTP 协定简直被网络上的所有设施所反对，具备很好的协定穿透性。但也存在比拟显著的问题： ...

本次流动 PPT 可到【阿里巴巴云原生】公众号后盾回复 “SZ” 取得~ 12月04日下午「Serverless Developer Meetup」在深圳阿里核心召开，此次流动由阿里云 Serverless 团队和阿里云开发者 ACE 联结主办，特邀阿里云、1688、开源中国等 Serverless 技术领域专家来到现场，深度解析 Serverless 最新倒退动静，分享了最实用的落地实际案例！并在现场庆贺了 Serverless Devs 生日快乐！ 2020 年11月阿里巴巴正式发表开源其首个 Serverless 开发者平台「Serverless Devs」。流动当天开发者们纷纷献上了对 Serverless Devs 一周年的祝愿；现场还为四位优良的 Serverless Devs 贡献者颁发了证书及礼包。 扫描下方金句海报二维码或点击浏览原文即可回看此次流动现场直播。 流动回顾Serverless 正过后本次演讲围绕 Serverless 开展，从 Serverless 的诞生背景、倒退动静、落地行业案例与实际。让各位开发者理解到Serverless目前倒退到了什么阶段；研发团队采纳 FC 的机会是何时；以及应该如何利用 Serverless 技术享受降本提效的红利。 FaaS 在简单业务场景下的提效实际1688 Serverless & 工程效力负责人远岩，在现场从四个局部介绍了 1688 作为阿里团体最早开始落地实际 Serverless 体系的部门之一，是如何在多个简单业务场景中通过联合 FaaS 能力实现研发效力晋升的。与各位开发者深度分享怎么通过 FaaS 及 Serverless 能力来实现 “Only Focus on Business” 的研发体验。 如何定制一套 Serverless 利用部署流程Serverless Devs 研发负责人寒斜在现场介绍了弹幕利用部署流程和 Serverless 开发者工具模型（SDM）；从弹幕利用设计到落地原理解析进行抛砖引玉，引申出定制 Serverless 利用的部署流程。 ...

作为诞生于云计算时代的新技术理念，云原生领有传统 IT 无法比拟的劣势，能从技术理念、外围架构、最佳实际等方面，帮忙企业 IT 平滑、疾速、渐进式地落地上云之路。越来越多的开发者热衷于应用云原生技术，越来越多的企业开始摸索云原生架构如何落地。 此前，阿里云提出“做强生态”，联结生态的力量，基于云原生技术底座，帮忙各行各业做利用开发，实现业务翻新。继去年公布云原生合作伙伴打算之后，阿里云正式启动云原生加速器，输入阿里云云原生技术和产品能力，链接初创企业和资本市场，携手优质生态搭档，独特减速云原生落地过程。 启动云原生加速器，模式翻新、共塑价值随着企业对云原生的技术需要越来越细粒度，对行业属性的要求也越来越高，满足多样化需要的产品技术体系或解决方案，成为数字时代助力企业客户业务疾速倒退的“刚需”。为此，阿里云公布云原生加速器，旨在开掘云原生畛域内的优良企业，通过阿里云弱小的业务整合能力，助力生态企业疾速倒退，在阿里云上造成百花齐放的云原生生态体系。 第一期云原生加速器面向云原生利用、云原生 PaaS、云原生根底技术三大方向开启招募，由出名投资人、阿里云顶级技术专家、业务专家、阿里云战投等组成业余的评委团队，最终抉择出 30 家企业入围首期云原生加速器，助力云原生畛域生态搭档的倒退。 招募方向： 云原生利用： 通用和垂直行业 SaaS、工具类 SaaS 等；云原生 PaaS： 中间件、边缘计算、AI、物联网、低/无代码、行业 PaaS、iPaaS、低碳等；云原生根底技术： 容器、微服务、可观测、DevOps、Serverless、容器存储、容器平安等。在一年期减速成长打算中，阿里云云原生加速器将通过 2 次集结，提供 N 次业务对接，凋谢阿里云生态和业务资源，提供技术和产品反对，打造企业生态“朋友圈”，帮忙加速器搭档成长。通过集结的模式，与入选企业一起进行技术交换、业务单干、生态共建，减速云原生我的项目成长，促成云原生产业倒退。 技术支持： 阿里云云原生加速器将整合阿里云云原生技术产品线，与成员进行产品和解决方案共创，将为成员提供更高效、易用的平台和服务。入选成员还有机会成为阿里云云原生 MVP，助力成员取得更多资源与倒退机会。 业务反对： 阿里云云原生加速器将协同不同行业及区域业务线，基于成员理论需要提供多元的单干模式与商业机会，独特拓展云原生利用场景。 资本反对： 阿里云云原生加速器将协同阿里体系投资机构为成员深度连贯海量投资机构与业余的财务顾问，帮忙成员疾速、精准取得投资，全链条赋能企业融资。 “内功”反对： 阿里云云原生加速器将为成员解读行业政策与产业趋势，扩充品牌势能与市场规模，从战略规划与施行、人才组织与团队治理等全方面帮忙成员实现能力降级。 阿里云智能云原生利用平台总经理丁宇示意，阿里巴巴领有十五年云原生实践经验，随着云原生技术的成熟，咱们看到了更多的市场机会。云原生合作伙伴打算通过一年的建设，曾经获得了十分丰硕的成绩。往年公布的云原生加速器，将与更多搭档实现能力交融，价值共塑，为客户提供更加残缺、更具竞争力的产品、解决方案、客户服务体系，独特促成云原生产业生态凋敝。 报名申请 云原生加速器讲师分享阿里云云原生生态负责人冯天豪分享《云原生减速企业数字翻新，助力产业生态蓬勃发展》，具体解说了阿里云云原生产品技术倒退历程，以及生态布局，并分享了云原生加速器经营打算等内容，帮忙大家更好地了解云原生加速器。 点击此处，查看直播回放。 点击浏览原文，返回阿里云云原生减速器官网查看更多相干详情！

作者：陈裘凯（ 求索） 前言KubeDL 是阿里开源的基于 Kubernetes 的 AI 工作负载治理框架，取自"Kubernetes-Deep-Learning"的缩写，心愿可能依靠阿里巴巴的场景，将大规模机器学习作业调度与治理的教训反哺社区。目前 KubeDL 曾经进入 CNCF Sandbox 我的项目孵化，咱们会一直摸索云原生 AI 场景中的最佳实际，助力算法科学家们简略高效地实现翻新落地。 在最新的 KubeDL Release 0.4.0 版本中，咱们带来了模型版本治理（ModelVersion）的能力，AI 科学家们能够像治理镜像一样轻松地对模型版本进行追踪，打标及存储。更重要的是，在经典的机器学习流水线中，“训练”与“推理”两个阶段绝对独立，算法科学家视角中的“训练->模型->推理”流水线不足断层，而“模型”作为两者的两头产物正好可能充当那个“承前启后”的角色。 Github：https://github.com/kubedl-io/kubedl 网站：https://kubedl.io/model/intro/ 模型治理现状模型文件是分布式训练的产物，是通过充沛迭代与搜寻后保留的算法精髓，在工业界算法模型曾经成为了贵重的数字资产。通常不同的分布式框架会输入不同格局的模型文件，如 Tensorflow 训练作业通常输入 CheckPoint(.ckpt)、GraphDef(.pb)、SavedModel 等格局，而 PyTorch 则通常以 .pth 后缀，不同的框架会在加载模型时解析其中承载的运行时的数据流图、运行参数及其权重等信息，对于文件系统来说，它们都是一个（或一组）非凡格局的文件，就像 JPEG 和 PNG 格局的图像文件一样。 因而典型的治理形式就是把它们当作文件，托管在对立的对象存储中（如阿里云 OSS 和AWS S3），每个租户/团队调配一个目录，各自成员再把模型文件存储在本人对应的子目录中，由 SRE 来对立进行读写权限的管控： 这种治理形式的优缺点都很显著： 益处是保留了用户的 API 应用习惯，在训练代码中将本人的目录指定为输入门路，之后将云存储的对应目录 mount 到推理服务的容器内加载模型即可；但这对 SRE 提出了较高的要求，不合理的读写权限受权及误操作，可能造成文件权限泄露，甚至大面积的误删除；同时基于文件的治理形式不易实现模型的版本治理，通常要求用户本身依据文件名来标记，或是下层平台本人承当版本治理的复杂度；此外，模型文件与算法代码/训练参数的对应关系也无奈间接映射，甚至同个文件在屡次训练中会被屡次覆写，难以追溯历史；基于以上现状，KubeDL 充沛联合了 Docker 镜像治理的劣势，引入了一套 Image-Based 的镜像治理 API，让分布式训练和推理服务联合得更严密天然，同时也极大简化了模型治理的复杂度。 从镜像登程镜像（Image）是 Docker 的灵魂，也是容器时代的外围基础设施。镜像自身即分层的不可变文件系统，模型文件人造地能够作为其中的一个独立镜像层，两者联合的还会迸发出其余火花： 用户不必再面向文件治理模型，而是间接应用 KubeDL 提供的 ModelVersion API 即可，训练与推理服务之间通过 ModelVersion API 桥接；与镜像一样，能够对模型打 Tag 实现版本追溯，并推送到对立的镜像 Registry 存储，通过 Registry 进行鉴权，同时镜像 Registry 的存储后端还能够替换成用户本人的 OSS/S3，用户能够平滑过渡；模型镜像一旦构建结束，即成为只读的模板，无奈再被笼罩及篡写，践行 Serverless “不可变基础设施” 的理念；镜像层（Layer）通过压缩算法及哈希去重，缩小模型文件存储的老本并放慢了散发的效率；在“模型镜像化”的根底上，还能够充沛联合开源的镜像治理组件，最大化镜像带来的劣势： ...

作者：肯梦 对于日志剖析大家可能并不生疏，在分布式计算、大数据处理和 Spark 等开源剖析框架的反对下，每天能够对潜在的数百万日志进行剖析。 事件剖析则和日志剖析是两个齐全不同的畛域，事件剖析对实时性的要求更高，须要磨平事件畛域中从半结构化到结构化的音讯转换管道，实现查问检索，可视化等性能。然而目前针对流式的事件做剖析的可用工具非常少，这对于冀望应用Serverless架构或 EDA（事件驱动）架构的开发者会十分不便。（更多 EDA 架构介绍参考 ：https://developer.aliyun.com/...） 基于事件的特色，无奈追溯事件内容，无奈跟踪事件流转，无奈对事件做可视化剖析成为了事件驱动架构演进的绊脚石。为了解决事件畛域中针对流式事件做剖析的难题，EventBridge 近日公布了针对事件/音讯畛域的全新剖析工具--EventBridge 实时事件剖析平台。上面简要对 EventBridge 实时事件剖析平台的内容进行介绍。 EventBridge 实时事件剖析平台简介EventBridge 实时事件剖析平台依靠基于事件的实时处理引擎，提供数值检索、可视化剖析、多组态剖析、事件轨迹、事件溯源和 Schema 治理等能力。EventBridge 实时事件剖析平台具备无入侵、无需数据上报，低成本，操作快捷等特点，通过简略的疏导式交互，即可疾速实现基于事件的流式查问与剖析。 EventBridge 实时事件剖析平台依靠基于事件的实时处理引擎，提供数值检索，可视化剖析，多组态剖析，事件轨迹，事件溯源，Schema 治理等能力。EventBridge 实时事件具备无入侵，无需数据上报，低成本，操作快捷等特点，通过简略的疏导式交互，即可疾速实现基于事件的流式查问与剖析。 外围性能多场景反对 目前市面上比拟风行的是事件查问平台，然而剖析和查问还是有些本质区别，剖析基于查问，然而查问并不是剖析的全副。 EventBridge 构建了一套残缺的事件工具链，帮忙开发，运维，甚至经营团队更高效的应用剖析工具，对立在一个剖析平台上无缝整合全副事件，提供高效、牢靠、通用的事件剖析能力。 Serverless 畛域：得益于 Serverless 架构的推广，事件驱动被更多用在企业外围链路。无服务器的定义是不用治理任何基础设施，然而无服务器的不通明且难以调试却是整个架构必须解决的痛点，当咱们配置完触发器后不会晓得什么数据在什么时刻触发了函数，触发链路是否异样。EventBridge 事件剖析能力将彻底解决 Serverless触发数据黑箱的问题，让所有事件触发都清晰可见。微服务畛域：微服务在古代开发架构中比拟常见，该架构由小型、松耦合、可独立部署的服务汇合而成，这导致微服务架构很难调试，零碎中某一部分的小故障可能会导致大规模服务解体。很多时候不得不跳过某些失常服务来调试单个申请。EventBridge 事件剖析可将全副链路微服务音讯通过事件 ID 染色做无效追踪与排障，帮忙微服务做可视化排障。音讯畛域：在传统音讯畛域，音讯 Schema 治理、音讯内容检索始终是无奈解决的难题，大部分状况下须要减少订阅者来对音讯做离线剖析。EventBridge 事件剖析平台提供音讯 Schema 治理与音讯内容查问能力，为音讯可视化提供更齐全的解决方案。云产品畛域：云产品在极大水平升高了企业对基础设施建设的复杂性，但同样带来了诸多问题，以 ECS 为例，很多状况会因零碎谬误或云盘性能受损而触发故障类事件，这类事件通常会波及到周边产品（比方 ACK 等），捕捉全副云上事件做根底排障的挑战性比拟大。EventBridge 反对全副云服务事件无缝接入，更大程度升高由云产品变更导致的运维故障。EventBridge 提供更高效、通用的事件剖析平台，基于该平台能够解决大部分场景对事件剖析、事件查问、事件轨迹的诉求。 开箱即用反对提供 Schema 治理，数值检索，可视化剖析，多组态剖析，事件轨迹，事件溯源等外围能力，无需额定部署，即开即用。 数值检索：提供根底数值检索能力，反对键入 key，value ，= ，!= , exists ，AND，OR 等参数，满足事件检索场景的根本诉求。 可视化剖析：提供 GROUP BY，ORDER BY 等可视化剖析能力，反对多组态，多图表，多维度剖析能力。 链路追踪：提供事件轨迹能力，还原事件整体链路状态。帮忙开发者疾速排障，疾速定位链路问题。  低成本接入 EventBridge 反对以事件总线（EventBus）模式接入，分为云服务事件总线和自定义事件总线。云服务总线反对简直全副阿里云产品事件，无缝反对云服务事件接入事件剖析平台；自定义事件总线反对 RocketMQ、Kafka 或其余自定义事件接入（以后版本仅反对大量云服务事件）。 ...

作者：扬少 当服务有新版本要公布上线时，通过引流一小部分流量到新版本，能够及时发现程序问题，无效阻止大面积故障的产生。业界上曾经有比拟成熟的服务公布策略，比方蓝绿公布、A/B 测试以及金丝雀公布，这些公布策略次要专一于如何对单个服务进行公布。在微服务体系架构中，服务之间的依赖关系盘根错节，有时某个性能发版依赖多个服务同时降级上线。咱们心愿能够对这些服务的新版本同时进行小流量灰度验证，这就是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。 本文将会揭开全链路灰度的神秘面纱，深刻分析全链路灰度技术底细，引出两种不同的实现计划，并对实现计划的技术细节进行深入探讨，最初通过实际环节来展现全链路灰度在理论业务中的应用场景。 微服务架构带来的挑战为了满足业务的迭代速度，开发者开始对原来的单体架构进行细粒度的拆分，将单体利用中的服务模块拆分成一个个独立部署运行的微服务，并且这些微服务的生命周期由对应的业务团队单独负责，无效的解决了单体架构中存在的敏捷性有余、灵活性不强的问题。常见的做法是依据业务域或者功能域进行服务拆分，如下图： 其中，流量网关是四层代理，次要性能有负载平衡、TLS 卸载以及一些平安防护性能；微服务网关是七层代理，次要用来裸露后端服务、流量治理、访问控制和流量监控。以"高内聚、低耦合"作为设计理念的微服务架构为开发者带来了前所未有的开发体验，每个业务团队专一于本身业务的代码逻辑，并通过 API 模式对外公布。服务依赖方只需引入服务提供方的 API 定义，即可实现服务之间通信，无需关怀服务提供方的部署状态和外部实现。 但任何架构都不是银弹，在解决旧问题同时势必会引入一些新的问题。微服务体系中最令人头疼的问题，是如何对泛滥微服务进行高效、便捷的治理，次要体现在可见性、连接性和安全性这三个方面。进一步细化，微服务架构带来了以下的挑战： 本文的重点次要关注服务公布这一子畛域，如何保障微服务体系中服务新版本升级过程中平滑无损，以及如何低成本的为多个微服务构建流量隔离环境，不便开发者同时对多个服务新版本进行充沛的灰度验证，防止故障的产生。 什么是全链路灰度单体架构下的服务公布首先，咱们先看一下在单体架构中，如何对利用中某个服务模块进行新版本公布。如下图，利用中的 Cart 服务模块有新版本迭代： 因为 Cart 服务是利用的一部分，所以新版本上线时须要对整个利用进行编译、打包以及部署。服务级别公布问题变成了利用级别的公布问题，咱们须要对利用的新版本而不是服务来施行无效的公布策略。 目前，业界曾经有十分成熟的服务公布计划，例如蓝绿公布和灰度公布。蓝绿公布须要对服务的新版本进行冗余部署，个别新版本的机器规格和数量与旧版本保持一致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进行版本升级时，咱们只需将流量全副切换到新版本即可，旧版本作为热备。咱们的例子应用蓝绿公布的示意图如下，流量切换基于四层代理的流量网关即可实现。 在蓝绿公布中，因为存在流量整体切换，所以须要依照原服务占用的机器规模为新版本克隆一套环境，相当于要求原来1倍的机器资源。灰度公布的核心思想是依据申请内容或者申请流量的比例将线上流量的一小部分转发至新版本，待灰度验证通过后，逐渐调大新版本的申请流量，是一种循序渐进的公布形式。咱们的例子应用灰度公布的示意图如下，基于内容或比例的流量管制须要借助于一个七层代理的微服务网关来实现。 其中，Traffic Routing 是基于内容的灰度形式，比方申请中含有头部 stag=gray 的流量路由到利用 v2 版本；Traffic Shifting 是基于比例的灰度形式，以无差别的形式对线上流量按比重进行分流。相比蓝绿公布，灰度公布在机器资源老本以及流量控制能力上更胜一筹，但毛病就是公布周期过长，对运维基础设施要求较高。 微服务架构下的服务公布在散布式微服务架构中，利用中被拆分进去的子服务都是独立部署、运行和迭代的。单个服务新版本上线时，咱们再也不须要对利用整体进行发版，只需关注每个微服务本身的公布流程即可，如下： 为了验证服务 Cart 的新版本，流量在整个调用链路上可能通过某种形式有抉择的路由到 Cart 的灰度版本，这属于微服务治理畛域中流量治理问题。常见的治理策略包含基于 Provider 和基于 Consumer 的形式。 基于 Provider 的治理策略。配置 Cart 的流量流入规定，User 路由到 Cart 时应用 Cart 的流量流入规定。基于 Consumer 的治理策略。配置 User 的流量流出规定， User 路由到 Cart 时应用 User 的流量流出规定。此外，应用这些治理策略时能够联合下面介绍的蓝绿公布和灰度公布计划来施行真正的服务级别的版本公布。 全链路灰度持续思考下面微服务体系中对服务 Cart 进行公布的场景，如果此时服务 Order 也须要公布新版本，因为本次新性能波及到服务 Cart 和 Order 的独特变动，所以要求在灰度验证时可能使得灰度流量同时通过服务 Cart 和 Order 的灰度版本。如下图： ...

作者：洛浩 小迈于 2015 年 1 月成立，是一家致力以数字化当先为劣势，实现业务高质量自增长的挪动互联网科技公司。始终保持以用户价值为核心，以数据为驱动，为用户开发丰盛的工具利用、休闲游戏、益智、静止等系列的挪动利用。累计开发 400 余款产品，累计用户下载安装量破七亿。而在将来三年内，小迈以成为寰球当先开发者增长服务平台为愿景及使命，心愿通过标准化的产品和服务赋能，为开发者提供全链路解决方案，以技术+服务全方位保驾护航，助燃产品持续增长，帮忙工具和休闲游戏的开发者晋升产品的成功率。 在小迈外部，履行扁平化的治理格调，每个业务团队都能够独立抉择采纳更适宜本人的技术栈和基础架构，因而外部呈现了 ECS，K8s，SAE（Serverless 利用引擎）三种不同计算平台共存的场面，而且都在跑微服务架构，不同的计算平台都有本人独特的劣势和价值，而同样也会面临各自的挑战，目前次要在应用 SAE 平台的次要是游戏团队。 为什么抉择 SAE对于大部分休闲类游戏来讲，首先游戏自身存在本人的生命周期，而在生命周期内，游戏自身会呈现十分大的波峰波谷。比方，白天比早晨流量大的多，白天流量又集中在几个工夫点，而早晨 8 点是业务的最高峰，凌晨 2 点到 6 点简直没有流量，然而又不能停服。另外，在游戏刚上线的时候，每次经营流动又会拉来大量的新客户涌入，就须要后盾服务可能疾速响应流量的变动，所以业务方就冀望能有一种主动弹性伸缩的计算平台。其次，大部分休闲类游戏都是无状态的，还能够拆分成不同的服务模块来晋升服务性能和品质，如聊天、红包、背包、降级、用户数据获取、视频解决、广告投放等，因而就能够采纳微服务架构来部署。最初游戏在上线期间，也会迭代减少很多新的功能模块，须要频繁的公布降级。所以业务方在选型的时候，就会综合思考： 零碎的稳定性和容灾能力平台的主动弹性伸缩能力对微服务架构的反对便捷的公布回滚能力，甚至是不停服降级这些能力，其实通过 ECS 或者 K8s 自建也都能实现，然而会给业务团队带来大量的运维老本，而且很难均衡老本的投入。尤其是在弹性方面，自建弹性效率很难满足流量的疾速变动，往往还是须要冗余大量的资源。而 SAE 能够十分好的满足以上 4 个需要。其实小迈的游戏团队早在 SAE 公测期间，就开始关注试用 SAE 了。截止到目前，在 SAE 上累计曾经部署了 50 多个服务和利用，波及十几款游戏，比方爱上猜成语、成语最强答人、我找茬贼快、答多多、欢畅找找茬、多多短视频等，感兴趣的话能够下载 APP 试玩下。 SAE 落地实际Serverless 利用引擎 SAE 定位是容器之上的一站式利用托管平台，外围价值是给用户提供全利用生命周期治理、微服务治理、弹性免运维的 K8s 运行环境。实质上，用户的代码最终还是运行在容器里，只是这个容器不必去保护治理。因而对于存量的游戏服务来讲，能够零革新间接迁徙部署到 SAE 上。而且 SAE 针对 JAVA 利用，还提供了 JAR 包间接部署的模式，省去了小迈打镜像的步骤，和原有应用 ECS 的模式十分靠近，然而应用体验上会更加简略，大略的比照如下： SAE 比拟外围的能力就是高可用和主动弹性，对于小迈的游戏团队，在部署 JAR 包的时候能够勾选多可用区，就能达到跨可用区的容灾。SAE 底层其实是会提供多个散布在不同可用区的 K8s 集群，承载业务的容器实例能够在多可用区主动调度。对于弹性的配置同样也非常简单，能够基于 CPU、内存、QPS、RT 等指标来进行设置，对于小迈的线上游戏，次要还是通过CPU和内存的使用率来触发扩缩，同时还能指定最大实例数和最小实例数，十分的便捷。而且目前定时弹性和监控指标弹性还能够混用，那么对于有经营流动时，就能够通过两种弹性形式独特应用的形式，来确保资源的弹性。然而这里须要留神的是监控指标的阈值，须要依据业务的理论状况来配置，倡议上线前，通过压测来明确。 另外通过利用监控，也能十分不便的查看到服务接口的调用状况，这些能力都曾经默认集成到了 SAE 的平台上，对业务排障很有帮忙。 ...

阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) 简介： 用CNPM/淘宝源的开发者们请留神，淘宝NPM 镜像站喊你切换新域名啦。新的Web 站点：https://npmmirror.com，Registry Endpoint：https://registry.npmmirror.com。随着新的域名曾经正式启用，老 http://npm.taobao.org 和 http://registry.npm.taobao.org 域名将于 2022 年 05 月 31 日零时起进行服务。（望周知，求转发） 源起淘宝 NPM 镜像站（npm.taobao.org）自 2014 年 正式对外服务，一开始只是想简略地做 NPM 的中国镜像站点，回馈国内前端社区，人不知;鬼不觉居然始终运行到当初。当年参考 Ruby Gems 淘宝镜像 的形式，跟阿里开源组织申请了 taobao.org 的二级域名，镜像站点名称也自然而然地取名为 淘宝 NPM 镜像站 （下称 CNPM）。 图片起源：https://time.graphics/line/57... 如上图，从 2014 年 CNPM 正式提供服务到明天，NPM 包从 10 万 → 178 万，CNPM 的包下载回源量从 1 亿 → 200 亿，这还只是 CDN 回源站的量，算实在下载量就更多了。 能够毫不虚心的说， CNPM 见证了国内前端蓬勃发展的这 8 年，将来咱们心愿持续陪伴中国的前端开发者继续走上来。 PS：尽管外围参与者大部分来自国内大厂，不过 CNPM 自身是一个中立的公益我的项目，日常微小的运维费用均来自社区捐献。 新的起航随着前端的蓬勃发展， NPM 包数据量和内容复杂度仍在一直地减速增长，CNPM 当年的架构曾经很难满足当今的局势。 ...

简介：本文翻译自 Altinity 针对 ClickHouse 的系列技术文章。面向联机剖析解决（OLAP）的开源剖析引擎 ClickHouse，因其低劣的查问性能，PB级的数据规模，简略的架构，被国内外公司宽泛采纳。本系列技术文章，将具体开展介绍 ClickHouse。 前言本文翻译自 Altinity 针对 ClickHouse 的系列技术文章。面向联机剖析解决（OLAP）的开源剖析引擎 ClickHouse，因其低劣的查问性能，PB 级的数据规模，简略的架构，被国内外公司宽泛采纳。 阿里云 EMR-OLAP 团队，基于开源 ClickHouse 进行了系列优化，提供了开源 OLAP 剖析引擎 ClickHouse 的云上托管服务。EMR ClickHouse 齐全兼容开源版本的产品个性，同时提供集群疾速部署、集群治理、扩容、缩容和监控告警等云上产品性能，并且在开源的根底上优化了 ClickHouse 的读写性能，晋升了 ClickHouse 与 EMR 其余组件疾速集成的能力。拜访 https://help.aliyun.com/docum... 理解详情。 译者：何源（荆杭），阿里云计算平台事业部高级产品专家 （图源Altinity，侵删） 在 ClickHouse 中解决实时更新目录ClickHouse 更新的简短历史用例实现更新论断后续在 OLAP 数据库中，可变数据通常不受欢迎。ClickHouse 也不欢送可变数据。像其余一些 OLAP 产品一样，ClickHouse 最后甚至不反对更新。起初增加了更新性能，然而像其余许多性能一样，都是以“ClickHouse 形式”增加的。 即便是当初，ClickHouse 更新也是异步的，因而很难在交互式应用程序中应用。尽管如此，在许多用例中，用户须要对现有数据进行批改，并冀望立刻看到成果。ClickHouse 能做到吗？当然能够。 ClickHouse 更新的简短历史早在 2016 年，ClickHouse 团队就公布了一篇题为“如何在 ClickHouse 中更新数据”的文章。过后 ClickHouse 并不反对数据批改，只能应用非凡的插入构造来模仿更新，并且数据必须按分区抛弃。 为满足 GDPR 的要求，ClickHouse 团队在 2018 年提供了 UPDATE 和 DELETE。后续文章ClickHouse 中的更新和删除目前依然是 Altinity 博客中浏览量最多的文章之一。这种异步、非原子性的更新以 ALTER TABLE UPDATE 语句的模式实现，并且可能会打乱大量数据。这对于批量操作和不频繁的更新是很有用的，因为它们不须要即时的后果。只管“失常”的 SQL 更新每年都妥妥地呈现在路线图中，但仍然没能在 ClickHouse 中实现。如果须要实时更新行为，咱们必须应用其余办法。让咱们思考一个理论的用例，并比拟在 ClickHouse 中的不同实现办法。 ...

阿里巴巴开源镜像站-OPSX镜像站-阿里云开发者社区 (aliyun.com) Rocky Linux镜像在阿里云镜像站首发上线-阿里云开发者社区 (aliyun.com) Rocky Linux简介Rocky Linux 是一个社区化的企业级操作系统。其设计为的是与美国顶级企业 Linux 发行版实现 100％ Bug 级兼容，而起因是后者的上游合作伙伴转移了倒退方向。目前社区正在集中力量倒退无关设施。Rocky Linux 由 CentOS 我的项目的创始人 Gregory Kurtzer 领导。目前曾经公布了首个正式版。 Rocky Linux 的指标是像 CentOS 以前那样作为一个上游构建版本，在被上游供应商纳入包更新之后（而不是之前）构建发行。 新个性以下参考 CentOS 8 新个性。 CentOS 8 新个性DNF 成为了默认的软件包管理器，同时 yum 依然是可用的（yum 是 dnf 的链接）应用网络管理器（nmcli 和 nmtui）进行网络配置，移除了网络脚本应用 Podman 进行容器治理引入了两个新的包仓库：BaseOS 和 AppStream应用 Cockpit 作为默认的系统管理工具默认应用 Wayland 作为显示服务器iptables 将被 nftables 取代应用 Linux 内核 4.18动静编程语言、Web 和数据库服务器Python 3.6 是默认的 Python 环境，无限反对 Python 2.7Node.js 是在 RHEL 最新蕴含的，其余动静语言更新包含: PHP 7.2 , Ruby 2.5 , Perl 5.26 , SWIG 3.0RHEL 8 提供的数据库服务包含：MariaDB 10.3 , MySQL 8.0 , PostgreSQL 10 , PostgreSQL 9.6 , 和 Redis 5RHEL 8 提供 Apache HTTP Server 2.4 以及首次引入的, nginx 1.14Squid 版本升级到 4.4 ，同时也首次提供 Varnish Cache 6.0配置执行以下命令替换默认源 ...

阿里巴巴开源镜像站：阿里巴巴开源镜像站 简介： 阿里云服务器操作系统如何抉择？阿里云有哪些相干镜像： 阿里云操作系统镜像有哪些？阿里云操作系统镜像能够分为两大类，即Windows类和Linux类（阿里云提供的操作系统均为正版受权）： Windows操作系统：Windows Version1909数据中心版、2019数据中心版、2016数据中心版、2012数据中心、2008企业版、2012标准版等；Linux操作系统：CentOS、Ubuntu、Aliyun Linux、Red Hat、Debian、SUSE Linux、Open SUSE、CoreOS、FreeBSD；CoreOS、FreeBSD。公共镜像、自定义镜像、共享镜像及镜像市场的区别零碎镜像品种操作系统镜像阐明公共镜像公共镜像是由阿里云官网或第三方单干商家提供的零碎根底镜像，仅包含初始操作系统环境自定义镜像自定义镜像是基于用户零碎快照生成的，包含初始零碎环境、应用环境和相干软件配置，用户能够应用自定义镜像穿件云服务器，节省时间共享镜像共享镜像其余阿里云账号共享的镜像，镜像危险自行承当镜像市场镜像市场的镜像经阿里云严格审核的优质镜像，预装操作系统、应用环境和各类软件，无需配置，可一键部署云服务器对于镜像市场和公共镜像能够参考：镜像市场中的镜像与公共镜像的区别 综上，公共镜像是阿里云官网或第三方提供的，正版受权，公共镜像是污浊的操作系统镜像，用户须要自行装置运行环境；自定义镜像是用户本人创立的镜像；共享镜像是其余阿里云账号分享过去的镜像；镜像市场是第三方提供的，通过阿里云严格审核的优质镜像，镜像品种丰盛。 阿里云零碎镜像能够更换吗？阿里云ECS云服务器操作系统镜像能够收费更换吗？如果用户购买的是中国大陆地区的云服务器是能够收费更换的，如果是中国香港地区或者其余海内地区请往下看： 更换操作系统教程：更换操作系统 - 阿里云 中国大陆地区的云服务器操作系统能够收费更换\中国大陆地区是指华北1、华北2、华北3、华北5、华东1、华东2、华南1、华南2及东北1等，这些地区的云服务器操作系统是能够收费更换的，Linux类的操作系统和Windows类的操作系统也能够调换。非中国大陆地区的云服务器（中国香港或者其余海内国家和地区）\非中国大陆地区的云服务器暂不反对 Linux 和 Windows 零碎相互更换，请谨慎抉择。只是不反对Linux和Windows零碎调换，如果是Linux类和Linux类的零碎更换是能够的，Windows类和Windows类的零碎是能够调换的。非中国大陆地区包含：中国香港、新加坡、澳大利亚（悉尼）、马来西亚（吉隆坡）、印度尼西亚（雅加达）及日本（东京）等。比方：中国香港地区的云服务器，购买时操作系统抉择的是CentOS，那么能够将镜像更换为Ubuntu，但不能够更换为Windows零碎。 所以，如果购买中国香港地区或者其余海内地区，操作系统镜像肯定要选好，因为不反对Linux和Windows零碎相互更换。 抉择Windows还是Linux操作系统？抉择Windows类操作系统还是Linux类操作系统？次要还是看利用类型，老手站长网以Web网站开发来说说： ASP、.NET、HTML、数据库ACCESS、SQL Server倡议抉择Windows；PHP、PERL、CGI、数据库MySQL、SQLite倡议抉择Linux。 镜像零碎抉择64位还是32位？Windows类操作系统和Linux类操作系统都有32位和64位，32位和64位有什么区别？32位零碎是指CPU一次性能够解决32位数据，64位是指CPU一次性可解决64位数据，实践上64位更快一些，然而理论速度更多的是依赖内存的大小。曾经2021年了，倡议大家抉择64位的操作系统。 原文章链接 阿里云服务器操作系统如何抉择？阿里云有哪些相干镜像-阿里云开发者社区 (aliyun.com)

阿里巴巴开源镜像站：阿里巴巴开源镜像站 简介：  AlmaLinux镜像详情地址：https://developer.aliyun.com/...简介作为一个开源且永恒收费的企业 Linux 发行版，AlmaLinux OS 由社区治理和驱动，专一于长期稳定性和弱小的生产平台利用。 其最大特点，是实现了与红帽企业版（RHEL）二进制文件的 1：1 兼容，且由成熟的 CloudLinux OS 幕后团队创建。 AlmaLinux个性稳固、生产就绪、基于 AlmaLinuxAlmaLinux OS 是一个企业级服务器操作系统和一个稳固的 Linux 发行版，定期公布，反对窗口很长。您能够依附 AlmaLinux OS 来运行任何要害工作负载。 CentOS 替代品和准确的 AlmaLinux 克隆生产就绪且稳固，匹配 AlmaLinux 性能 1:1与 AlmaLinux 同步公布的稳固版本和更新的可预测性从 CentOS 轻松迁徙切换发行版通常既低廉又耗时，但从 CentOS 切换到 AlmaLinux 操作系统时并非如此。切换很容易，简直是霎时的。 从 CentOS 轻松过渡，只需起码的投资且无需更改软件从 CentOS 过渡到 AlmaLinux 操作系统的简略迁徙脚本。零迁徙停机工夫。即时迁徙甚至大型服务器群齐全反对，永远收费AlmaLinux OS 基金会成员、赞助商和合作伙伴通过投资和长期反对承诺反对 AlmaLinux OS，以确保散发不受限制、费用和免费。 永远收费和开源：没有许可证，没有应用限度。可自在从新散发依附社区领有和治理的我的项目8.x 公布到 2029 年的反对承诺 AlmaLinux 8.4 更新的亮点：平安启动：最受社区欢送的头等性能，现已迎来全面反对。OpenSCAP 平安配置文件：现已反对在生产环境中的工作负载。整合上游散发中未蕴含的额定内容，以及开发者在构建时所依赖的存储库。蕴含新的模块流（module streams）和编译器更新。Almalinux-部署要将您的 EL8 操作系统转换为 AlmaLinux，请执行以下操作： 1.对系统进行备份。咱们没有测试所有可能的状况，因而存在呈现问题的危险。在这种状况下，您将领有一个还原点。\ 下载almalinux-deploy.sh脚本：$ curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh3.运行脚本并查看其输入是否有谬误： $ sudo bash almalinux-deploy.sh ... Migration to AlmaLinux is completed4.确保您的零碎已胜利转换： ...

作者：不瞋，阿里云 Serverless 技术负责人 “刚刚过来的 2021 年天猫双 11，阿里云函数计算与阿里巴巴运维体系全面实现标准化对接，买通研发的最初一公里，首次实现了业务全链路“ FaaS + BaaS ”的 Serverless 体系化研发，笼罩淘特、淘系、阿里妈妈、1688、高德、飞猪等业务场景，撑持场景数量同比增加 2 倍，峰值流量总数同比增加 3 倍，实现了百万 QPS 的冲破，人效晋升 40%。” 前段时间，我与 InfoQ 大咖说单干了一期直播，跟开发者们聊了聊我眼中的 Serverless。大家对于 Serverless 激情很高，然而顾虑依然存在，这也是我写作本文的起因。作为这一技术浪潮的见证者，我想跟大家一起思考 Serverless 诞生的起因，阿里云 Serverless 技术和产品的演进历程，以及我对 Serverless 将来趋势的判断。 云产品体系的 Serverless 化尽管 Serverless 对很多人来说，依然比拟陈腐，但其实 Serverless 这种状态早已有之。 2010 年我刚退出阿里云，参加飞天操作系统研发，飞天操作系统最后是通过治理数千台的机器来执行大数据处理的。用户的编程界面是 MapReduce 工作，通过 SQL 语句等来解决海量数据，这就是晚期的 Serverless 状态。 阿里云的第一个云服务对象存储 OSS，亚马逊云科技的第一个云服务 S3，它们其实也都是 Serverless 状态的存储服务。用户不须要关怀数据如何被分片存储到不同的服务器上来实现负载平衡，也不须要思考如何做到在服务器宕机或者交换机故障时，保证数据的高可靠性和高可用性，他们只须要用简略的 API 就能够实现海量数据的牢靠存储。他们都屏蔽了 Server 的复杂度，让用户有一个十分简洁的 Serverless 体验，这些都是 Serverless 状态。 2012 年，Serverless 概念被首次提出，到亚马逊云科技正式商用 Lambda，Serverless 开始风行并逐步走红。近 10 年工夫，这样的演进过程并不偶尔、也非欲速不达，反而是带着宿命般的偶然性，其背地起因是云的产品体系始终都在向 Serverless 化演进。 ...

一、简介Ubuntu，是一款基于 Debian Linux 的以桌面利用为主的操作系统，内容涵盖文字处理、电子邮件、软件开发工具和 Web 服务等，可供用户收费下载、应用和分享。二、配置办法1、图形化界面配置操作图形化Ubuntu操作系统装置步骤参考链接：Ubuntu 20.04装置过程 如果装置图形化界面的Ubuntu零碎的话，举荐应用此办法。 应用图形界面配置操作步骤：零碎设置 -> 软件和更新 抉择下载服务器 -> "mirrors.aliyun.com" ### （1）关上Ubuntu零碎。 ### （2）右击抉择"设置"。 ### （3）抉择”对于“，点击"软件更新"。如图所示。 ### （4）抉择"其余站点"。 （5）抉择"mirrors.aliyun.com"，点击“抉择服务器”。 （6）切换实现。 （7）从新载入镜像。期待更新实现即可。 2、终端界面配置操作参考链接：阿里云 ubuntu镜像 采纳批改配置文件的形式进行切换。 （1）备份源文件。抉择"在终端中关上"。 root@xyb-virtual-machine:~# cp /etc/apt/sources.list /etc/apt/sources.list.backup （2）手动批改源文件。用相熟的编辑器关上：/etc/apt/sources.list替换默认的http://archive.ubuntu.com/为mirrors.aliyun.com root@xyb-virtual-machine:~# vi /etc/apt/sources.listubuntu 20.04(focal) 配置如下 deb http://mirrors.aliyun.com/ubuntu/ focal main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ focal main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu/ focal-security main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ focal-security main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu/ focal-updates main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ focal-updates main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu/ focal-proposed main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ focal-proposed main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu/ focal-backports main restricted universe multiversedeb-src http://mirrors.aliyun.com/ubuntu/ focal-backports main restricted universe multiverse ...

一、参考链接阿里巴巴开源镜像站：阿里巴巴开源镜像站 DNS装置教程：DNS装置教程 二、DNS简介域名零碎（服务）协定（DNS）是一种分布式网络目录服务，次要用于域名与 IP 地址的互相转换，以及管制因特网的电子邮件的发送。三、配置办法Linux 疾速配置ipv4编辑文件 "/etc/resolv.conf"，依据状况批改文件内容。 只须要增加以下两行 nameserver 223.5.5.5nameserver 223.6.6.6 [root@ecs-kunpeng ~]# vim /etc/resolv.conf[root@ecs-kunpeng ~]# cat /etc/resolv.conf# Generated by NetworkManagersearch openstacklocal#nameserver 100.125.1.250#nameserver 100.125.129.250options timeout:1 single-request-reopennameserver 223.5.5.5nameserver 223.6.6.6[root@ecs-kunpeng ~]# Linux 疾速配置ipv6编辑文件 "/etc/resolv.conf"，依据状况批改文件内容。 只须要增加以下两行 nameserver 2400:3200::1nameserver 2400:3200:baba::1 [root@ecs-kunpeng ~]# vim /etc/resolv.conf[root@ecs-kunpeng ~]# cat /etc/resolv.conf# Generated by NetworkManagersearch openstacklocal#nameserver 100.125.1.250#nameserver 100.125.129.250options timeout:1 single-request-reopennameserver 223.5.5.5nameserver 223.6.6.6nameserver 2400:3200::1nameserver 2400:3200:baba::1保留退出，而后应用 dig 验证： 若显示以下错误信息 [root@ecs-kunpeng ~]# dig alidns.com-bash: dig: command not found[root@ecs-kunpeng ~]#[root@ecs-kunpeng ~]# yum provides digbind-utils-32:9.11.26-4.el8_4.aarch64 : Utilities for querying DNS name serversRepo : AppStreamMatched from:Filename : /usr/bin/dig应用yum源装置bind-utils-32:9.11.26-4.el8_4.aarch64组件 ...

一、参考链接阿里巴巴开源镜像站：阿里巴巴开源镜像站 阿里镜像站—Kubernetes 镜像：Kubernetes 镜像 二、Kubernetes 镜像简介Kubernetes 是一个开源零碎，用于容器化利用的主动部署、扩缩和治理。它将形成利用的容器按逻辑单位进行分组以便于管理和发现。下载地址：https://mirrors.aliyun.com/kubernetes/ 三、Kubernetes 镜像配置办法基于CentOS / RHEL / Fedora系统配置办法（1）查看零碎版本信息[root@centos ~]# hostnamectl Static hostname: centos Icon name: computer-vm Chassis: vm Machine ID: f6fc8fb7991c4c518238af7c75f16046 Boot ID: baa5dae1c7614a0790ac9c3b5c0a9b7b Virtualization: vmware Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-1160.el7.x86_64 Architecture: x86-64（2）增加并查看 Kubernetes.repo YUM源[root@centos ~]# cat <<EOF > /etc/yum.repos.d/kubernetes.repo> [kubernetes]> name=Kubernetes> baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/> enabled=1> gpgcheck=1> repo_gpgcheck=1> gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg> EOF[root@centos ~]# cat /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg[root@centos ~]#PS：因为官网未凋谢同步形式, 可能会有索引gpg查看失败的状况, 这时请用 yum install -y --nogpgcheck kubelet kubeadm kubectl 装置（3）敞开或容许SELINUX平安模式① 执行setenforce 0命令，临时容许SELINUX平安模式放行通过。重启生效。 ...

　当初云计算云服务是互联网技术倒退的一个重要方向，也是很热门的待业畛域，吸引了很多年轻人踊跃投身参加进去。同时，该畛域门槛比拟高，想要进入须要有较强的专业知识和技术能力，并通过专门测试考取资格证。因而社会上也呈现了各类acp、ace等培训。为了帮忙感兴趣的敌人能理解什么是acp认证，明天就先简要说说阿里云acp全称，并分享阿里云acp认证的学习领导和倡议。 阿里云大数据分析ACP认证全套认证题库1、分析师王明将一个分析程序命名为01_WM_ABC_Data_Extraction.sql。“01”指的是程序运行的程序，“WM”是姓名的缩写，“ABC”是项目名称的缩写，“Data_Extraction”是程序的性能。从程序命名标准的角度看，以下对于程序命名的评论是正确的____。（ A ）A.程序的命名有意义 B.不能用数字“01” C.不应该蕴含代表分析师姓名缩写的“WM” D.不应该用""_""特符号 2、某公司的大数据工程师小李在设计数据库时,将所有数值类型的数据列设为浮点数,这样能够施单不便地满足所有数类型的数据定义要求,然而，该公司的大数据分析师小张调用数据时发现,这种设置同样也可能造成相应的问题。如设计计算精度、存储空间、运行速度以及数值类型约定。小张在应用数据时不须要放心这些问题中的哪个?(A)A.浮点的度较低,不能满足计算准确率的要求 B.对于整数数据来说,将其定义为浮点数会占用大存空 C.提取数据时,多余的浮点数长度会导致程序运行速度变慢