云原生-Cloud-Native

以“云”为外围的软件研发思维，正逐渐成为所有开发者的默认选项。像 Kubernetes 等云原生技术正在成为技术人员的必修课，大量的工作岗位正在涌现进去。2020 年，云原生技术大规模遍及。这种背景下，“会 Kubernetes”曾经远远不够了，“懂 Kubernetes 如何落地”、“会云原生架构”的重要性正日益凸显进去。 2019年 4 月，阿里云联结 CNCF 公布了《CNCF X Alibaba 云原生技术公开课》，课程公布至今已可统计学习者 12万，在收到学习者“点赞”的同时，咱们也对学习者的学习需要以及痛点进行了调研和采访，简直课程学习者反馈的关键词都落在了“实际”这两个字上，具体有以下 3 个问题： 企业/传统企业如何实现 K8s 落地生产环境下，K8s 问题排查：比方网络问题心愿有以具体场景为切入点的实操课程（学习者对课程局部反馈截图） 作为云原生技术的忠实际行者，阿里巴巴是寰球多数大规模落地云原生架构的企业。在落地云原生的过程中，阿里巴巴积攒了许多贵重的实战经验。基于学习者的反馈和倡议，咱们决定重磅推出《云原生技术实际公开课》。 本课程集结 30+ 位实战经验丰盛的云原生技术专家。以具体场景为切入点，深度分析实在案例；设置可操作试验环境，让你疾速上手并在生产环境下实际 K8s。咱们心愿能以此帮忙每一位云时代的开发者和技术人员，把握到云原生时代的精华与实质，高效解决生产环境中遇到的难题。 课程亮点以具体场景为切入点解说 K8s 利用和落地难题分析最佳实际从零实际 K8s提供实在的企业级落地案例提供可入手操作的试验环境开始听课课程地址：https://developer.aliyun.com/learning/roadmap/cloudnative2020 适宜人群计算机科学、软件工程等畛域学生Kubernetes 运维工程师云原生应用程序开发人员企业架构师、CTO课程讲师张磊，阿里巴巴高级技术专家，CNCF 官网大使，CNCF 利用交付畛域 co-chair。Kubernetes 我的项目资深维护者。次要关注云原生利用管理体系与架构，容器运行时接口(CRI)、调度、资源管理等个性，独特负责 Kubernetes 上游和阿里团体大型集群管理系统的工程工作。 Andy Shi，阿里巴巴高级技术专家，阿里巴巴团体开发者布道师，长年在硅谷从事开源技术推广，在云平台应用和网络基础架构方面领有丰盛教训。 声东，阿里巴巴售后技术专家，阿里云云原生售后技术领头人，零碎技术专家；在软硬件技术，操作系统，云原生畛域有多年技术教训。 王夕宁，阿里巴巴高级技术专家，阿里云服务网格 ASM 技术负责人，关注 Kubernetes、云原生、服务网格等畛域，《Istio 服务网格技术解析与实际》作者。 莫源，阿里巴巴高级技术专家，次要负责阿里云容器服务产品的底层服务发现零碎、集群管理系统、弹性伸缩与监控的研发，从事容器的继续交付、继续集成的计划的设计与实现。在云计算、分布式系统、图像识别与虚拟现实方向有多年的开发实践经验。 王炳燊，阿里巴巴技术专家，次要负责容器服务 ACK 容器网络设计和研发；阿里云开源 CNI 插件Terway(github.com/AliyunContainerService/terway)我的项目维护者。 酒祝，阿里巴巴技术专家，OpenKruise maintainer，阿里团体云原生利用 workload 开发负责人，多年撑持阿里巴巴双十一超大规模容器集群教训。 孙健波，阿里巴巴技术专家，是 OAM 标准的次要制定者之一，致力于推动云原生利用标准化。同时也在阿里巴巴参加大规模云原生利用交付与利用治理相干工作。 课程纲要 互动福利8 月 14 日 11：00 前欢送在阿里巴巴云原生公众号留言区说出对于课程你还有哪些想听的内容： ...

作者 | 王夕宁  阿里巴巴高级技术专家 参加阿里巴巴云原生文末留言互动，即有机会取得赠书福利！ 在服务网格技术应用之前，为了更快更灵便地进行业务翻新, 咱们经常会把现有利用进行现代化革新, 把单体应用程序分拆为分布式的微服务架构。通常来说,  在微服务架构模式的变迁过程中, 最后都是面向代码库的模式。 对这些微服务治理的实现, 往往是以代码库的形式把这些服务治理的逻辑构建在应用程序自身中，这些代码库中包含了流量治理、熔断、重试、客户端负载平衡、平安以及可观测性等这样的一些性能。这些代码库随着性能的一直加强, 版本也随之变更，因为版本不同导致的抵触问题处处可见。此外，库的版本一旦变更，即便你的应用逻辑并没有任何变动，整个利用也要随之全副变更。由此可见, 随着利用的增长和团队数量的减少，跨服务统一地应用这些服务治理性能会变得非常复杂。 服务治理的能力 Sidecar 化通过把这些服务治理的能力 Sidecar 化，就可能把服务治理的能力与应用程序自身进行理解耦，能够较好地反对多种编程语言、同时这些 Sidecar 能力不须要依赖于某种特定技术框架。这就是咱们常说的面向 Sidecar proxy 的架构模式。 随着这些 Sidecar 代理性能的加强，本来须要在代码库中实现的服务治理性能被抽象化为一个个通用组件, 并被逐步地下沉到代理中。这些服务治理能力的标准化、统一化，能够解决简单零碎微服务实现中面临的差别大、短少共性的问题，能够很好地反对不同的编程语言、不同的框架。 通过把应用服务通信能力形象下沉到基础设施,   使得开发人员能够更加聚焦于业务利用自身开发,  而让基础设施来提供这些通用的能力。 与此同时， 容器编排技术的更加成熟，也减速了 Sidecar 代理的遍及与应用的便捷。Kubernetes 作为一个杰出的容器部署和治理平台、Istio 作为应用服务治理的平台，两者的联合成为了将这些应用服务通信能力下沉到基础设施的载体。 在云原生利用模型中，一个应用程序可能会蕴含数百个服务，每个服务又有数百个实例形成，那么这些成千盈百个应用程序的 Sidecar 代理如何对立治理，这就是服务网格中定义的管制立体局部要解决的问题。作为代理，Envoy 非常适合服务网格的场景，但要施展 Envoy 的最大价值，就须要使它很好地与底层基础设施或组件紧密配合。 这些 Sidecar 代理造成一个网状的数据立体，通过该数据立体解决和察看所有服务间的流量。数据立体表演了一个用来建设、爱护和管制通过网格的流量的角色。 负责数据立体如何执行的治理组件称为管制立体。管制立体是服务网格的大脑，并为网格应用人员提供公开 API，以便较容易地操纵网络行为。 启用服务网格之后,  开发人员、运维人员以及 SRE 团队将以对立的、申明的形式解决应用服务治理问题。   服务网格 ASM 产品架构作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就放弃了与社区、业界趋势的一致性，管制立体的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的管制面侧提供了用于撑持精细化的流量治理和平安治理的组件能力。通过托管模式，解耦了 Istio 组件与所治理的 K8s 集群的生命周期治理，使得架构更加灵便，晋升了零碎的可伸缩性。 ...

视频回顾链接：https://www.bilibili.com/video/BV1Dv411v7P4/ 本文整顿自 2020 年 7 月 22 日《基于 Kubernetes 与 OAM 构建对立、标准化的利用治理平台》主题线上网络研讨会。 关注公众号，回复 “0722” 即可下载 PPT 文章共分为高低两篇。上篇文章《灵魂拷问，上 Kubernetes 有什么业务价值？》，次要和大家介绍了上 Kubernetes 有什么业务价值，以及什么是“以利用为核心”的 Kubernetes。本文为下篇，将跟大家具体分享如何构建“以利用为核心”的 Kubernetes。 如何构建“以利用为核心”的 Kubernetes？ 构建这么一个以用户为核心的 Kubernetes，须要做几个层级的事件。 应用层驱动首先来看最外围的局部，上图中蓝色局部，也就是 Kubernetes。能够在 Kubernetes 之上定义一组 CRD 和 Controller。能够在 CRD 来做用户这一侧的 API，比如说 pipeline 就是一个 API，利用也是一个 API。像运维侧的扩容策略这些都是能够通过 CRD 的形式装置起来。  应用层形象所以咱们的须要解决第一个问题是利用形象。如果在 Kubernetes 去做应用层形象，就等同于定义 CRD 和 Controller，所以 Controller 能够叫做应用层的形象。自身能够是社区里的，比方 Tekton，istio 这些，能够作为你的利用驱动层。这是第一个问题，解决的是形象的问题。不是特地难。 插件能力治理很多性能不是 K8s 提供的，内置的 Controller 还是无限的，大部分能力来自于社区或者是本人开发的 Controller。这时我的集群外面就会装置好多好多插件。如果要构建以利用为核心的 Kubernetes，那我必须可能治理起来这些能力，否则整个集群就会脱管了。用户想要这么一个能力，我须要通知他有或者是没有。须要暴露出一个 API 来通知他，集群是否有他须要的能力。假如须要 istio 的流量切分，须要有个接口通知用户这个能力存不存在。不能指望用户去 get 一下 crd 合不适合，查看 Controller 是否运行。这不叫以利用为核心的 K8s，这叫裸 K8s。 ...

本文整顿自 2020 年 7 月 22 日《基于 Kubernetes 与 OAM 构建对立、标准化的利用治理平台》主题线上网络研讨会。文章共分为高低两篇，本文为上篇，次要和大家介绍上 Kubernetes 有什么业务价值，以及什么是“以利用为核心”的 Kubernetes。下篇将跟大家具体分享如何构建“以利用为核心”的 Kubernetes。 视频回顾链接：https://www.bilibili.com/video/BV1Dv411v7P4/ 关注阿里巴巴云原生公众号，回复 “0722” 即可下载 PPT 非常感谢大家来到 CNCF 的直播，我是张磊，阿里云的高级技术专家，Kubernetes 我的项目资深维护者。同时也是 CNCF 利用交付畛域 co-chair。我明天给大家带来的分享主题是《基于 Kubernetes 与 OAM 构建对立、标准化的利用治理平台》。在封面上有个钉钉群组二维码。大家能够通过这个二维码进入线上交换群。 上 Kubernetes 有什么业务价值？明天要演讲的主题是跟利用治理或者说是云原生利用交付是相干的。首先咱们想要先答复这么一个问题：为什么咱们要基于 Kubernetes 去构建一个利用治理平台？ 上图是一个实质的问题，咱们在落地 K8s 常常遇到的一个问题。尤其是咱们的业务方会问到这么一个问题，咱们上 Kubernetes 有什么业务价值？这时候作为咱们 K8s 工程师往往是很难答复的。起因在哪里呢？实际上这跟 K8s 的定位是相干的。K8s 这个我的项目呢，如果去做一个剖析的话，咱们会发现 K8s 不是一个 PaaS 或者利用治理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢？大家能够看一下下图。 实际上通过 Kubernetes 对用户裸露进去的是一组申明式 API，这些申明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个形象。比方 Pod 是对一组容器的形象，而 Deployment 是对一组 pod 的形象。而 Service 作为 Pod 的拜访入口，实际上是对集群基础设施：网络、网关、iptables 的一个形象。Node 是对宿主机的形象。Kubernetes 还提供了咱们叫做 CRD（也就是 Custom Resource）的自定义对象。让你本人可能自定义底层基础设施的一个形象。 ...

本文整顿自 2020 年 7 月 22 日《基于 Kubernetes 与 OAM 构建对立、标准化的利用治理平台》主题线上网络研讨会。文章共分为高低两篇，本文为上篇，次要和大家介绍上 Kubernetes 有什么业务价值，以及什么是“以利用为核心”的 Kubernetes。下篇将跟大家具体分享如何构建“以利用为核心”的 Kubernetes。 视频回顾链接：https://www.bilibili.com/video/BV1Dv411v7P4/ 关注阿里巴巴云原生公众号，回复 “0722” 即可下载 PPT 非常感谢大家来到 CNCF 的直播，我是张磊，阿里云的高级技术专家，Kubernetes 我的项目资深维护者。同时也是 CNCF 利用交付畛域 co-chair。我明天给大家带来的分享主题是《基于 Kubernetes 与 OAM 构建对立、标准化的利用治理平台》。在封面上有个钉钉群组二维码。大家能够通过这个二维码进入线上交换群。 上 Kubernetes 有什么业务价值？明天要演讲的主题是跟利用治理或者说是云原生利用交付是相干的。首先咱们想要先答复这么一个问题：为什么咱们要基于 Kubernetes 去构建一个利用治理平台？ 上图是一个实质的问题，咱们在落地 K8s 常常遇到的一个问题。尤其是咱们的业务方会问到这么一个问题，咱们上 Kubernetes 有什么业务价值？这时候作为咱们 K8s 工程师往往是很难答复的。起因在哪里呢？实际上这跟 K8s 的定位是相干的。K8s 这个我的项目呢，如果去做一个剖析的话，咱们会发现 K8s 不是一个 PaaS 或者利用治理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢？大家能够看一下下图。 实际上通过 Kubernetes 对用户裸露进去的是一组申明式 API，这些申明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个形象。比方 Pod 是对一组容器的形象，而 Deployment 是对一组 pod 的形象。而 Service 作为 Pod 的拜访入口，实际上是对集群基础设施：网络、网关、iptables 的一个形象。Node 是对宿主机的形象。Kubernetes 还提供了咱们叫做 CRD（也就是 Custom Resource）的自定义对象。让你本人可能自定义底层基础设施的一个形象。 ...

简介： 作为倒退最为迅猛的物流企业之一，申通快递始终积极探索技术创新赋能商业增长之路，以期达到降本提效目标。目前，申通快递日订单处理量已达千万量级，亿级别物流轨迹处理量，每天产生数据已达到 TB 级别，应用 1300+ 个计算节点来实时处理业务。 随着云计算的遍及与云原生的广泛应用，越来越多的从业者、决策者清晰地意识到「云原生化将成为 企业技术创新的要害因素，也是实现企业数字化转型的最短门路」。 因而，具备前瞻思维的互联网企业从利用诞生之初就扎根于云端，审慎稳重的新批发、政府、金融、医疗等畛域的企业与机构也逐步将业务利用迁徙上云，深度应用云原生技术与云原生架构。面对架构设计、开发方式到部署运维等不同业务场景，基于云原生架构的利用通常针对云的技术个性进行技术生命周期设计，最大限度利用云平台的弹性、分布式、自助、按需等产品劣势。 作为倒退最为迅猛的物流企业之一，申通快递始终积极探索技术创新赋能商业增长之路，以期达到降本提效目标。目前，申通快递日订单处理量已达千万量级，亿级别物流轨迹处理量，每天产生数据已达到 TB 级别，应用 1300+ 个计算节点来实时处理业务。 当业务飞速发展遭逢运维瓶颈过往申通快递的外围业务利用运行在 IDC 机房，原有 IDC 零碎帮忙申通安稳度过晚期业务疾速发展期。但随同着业务体量指数级增长，业务模式愈发多元化。原有零碎暴露出不少问题，传统 IOE 架构、各零碎架构的不标准、 稳定性、研发效率都限度了业务高速倒退的可能。软件交付周期过长，大促保障对资源的特殊要求难实现、零碎稳定性难以保障等业务问题逐步裸露。 在与阿里云进行屡次需要沟通与技术验证后，申通最终确定阿里云为惟一合作伙伴，采纳云原生技术和架构实现外围业务搬迁上阿里云。2019 年开始将业务逐渐从 IDC 迁徙至阿里云。目前，外围业务零碎曾经在阿里云上实现流量承接，为申通提供稳固而高效的计算能力。 全面革新云原生降级，助力业务倒退申通外围业务零碎原架构基于 Vmware+Oracle 数据库进行搭建。随着搬迁上阿里云，架构全面转型为基于 Kubernetes 的云原生架构体系。其中，引入云原生数据库并实现利用基于容器的微服务革新是整个应用服务架构重构的关键点。 引入云原生数据库通过引入 OLTP 跟 OLAP 型数据库，将在线数据与离线剖析逻辑拆分到两种数据库中，扭转此前齐全依赖 Oracle 数据库的现状。满足在解决历史数据查问场景下 Oracle 数据库所无奈反对的理论业务需要。 利用容器化随同着容器化技术的引进，通过利用容器化无效解决了环境不统一的问题，确保利用在开发、测试、生产环 境的一致性。与虚拟机相比，容器化提供了效率与速度的双重晋升，让利用更适宜微服务场景，无效晋升产研效率。 微服务革新因为过往很多业务是基于 Oracle 的存储过程及触发器实现的，零碎间的服务依赖也须要 Oracle 数据库 OGG 同步实现。这样带来的问题就是系统维护难度高且稳定性差。通过引入 Kubernetes 的服务发现，组建微服务解决方案，将业务按业务域进行拆分，让整个零碎更易于保护。 综合思考申通理论业务需要与技术特色，最终抉择了「阿里云 ACK+ 神龙 + 云数据库」的云原生解决方案，从而实现外围利用迁徙上阿里云。 1. 架构论述基础设施，全副计算资源取自阿里云的神龙裸金属服务器。相较于个别云服务器(ECS)，Kubernetes 搭配神龙服务器可能取得更优性能及更正当的资源利用率且云上资源按需取量，对于领有大促流动等短期大流量业务场景的申通而言极为重要。相较于线下自建机房、常备机器，云上资源随取随用。在大促流动完结后，云上资源应用结束后即可开释，治理与洽购老本更低，相应效率。 流量接入，阿里云提供两套流量接入，一套是面向公网申请，另外一套是服务外部调用。域名解析采纳云 DNS 及 PrivateZone。借助 Kubernetes 的 Ingress 能力实现对立的域名转发，以节俭公网 SLB 的数量，进步运维管理效率。 ...

摘要：欢送大家来到阿里云与 CNCF 独特推出的“云原生”技术公开课。本文整顿自“云原生”技术公开课的开篇：第一堂“云原生”课。在本文中，阿里巴巴高级技术专家、CNCF 官网大使张磊为大家介绍了“云原生”技术的倒退历程，本门课程的简介与准备常识以及“云原生”的定义和技术要点，精彩不容错过。 本节课程要点 云原生技术倒退历程（为什么要学习这门课）课程简介与准备常识（这门课到底教什么）云原生的定义与技术要点（本节正式内容）一、为什么要开设云原生技术公开课？云原生技术倒退简史首先从第一个问题进行分享，那就是“为什么要开设云原生技术公开课？”云原生、CNCF 都是目前十分热门的关键词，然而这些技术并不是十分陈腐的内容。 2004 年— 2007 年，Google 已在外部大规模地应用像 Cgroups 这样的容器技术；2008 年，Google 将 Cgroups 合并进入了 Linux 内核骨干；2013 年，Docker 我的项目正式公布。2014 年，Kubernetes 我的项目也正式公布。这样的起因也非常容易了解，因为有了容器和 Docker 之后，就须要有一种形式去帮忙大家不便、疾速、优雅地治理这些容器，这就是 Kubernetes 我的项目的初衷。在 Google 和 Redhat 公布了 Kubernetes 之后，这个我的项目的倒退速度十分之快。2015 年，由Google、Redhat 以及微软等大型云计算厂商以及一些开源公司独特牵头成立了 CNCF 云原生基金会。CNCF 成立之初，就有 22 个开创会员，而且 Kubernetes 也成为了 CNCF 托管的第一个开源我的项目。在这之后，CNCF 的倒退速度十分迅猛；2017 年，CNCF 达到 170 个成员和 14 个基金项目；2018 年，CNCF 成立三周年有了 195 个成员，19 个基金会我的项目和 11 个孵化我的项目，如此之快的倒退速度在整个云计算畛域都是十分常见的。云原生技术生态现状因而，现在咱们所探讨的云原生技术生态是一个宏大的技术汇合。CNCF 有一张云原生全景图（https://github.com/cncf/landscape），在这个全景图里曾经有 200 多个我的项目和产品了，这些我的项目和产品也都是和 CNCF 的观点所符合的。所以如果以这张全景图作为背景，加以思考就会发现，咱们明天所探讨的云原生其实次要议论了以下几点： 云原生基金会 —— CNCF；云原生技术社区，比方像 CNCF 目前正式托管的 20 多个我的项目独特形成了古代云计算生态的基石，其中像 Kubernetes 这样的我的项目曾经成为了世界第四沉闷的开源我的项目；除了后面两点之外，当初寰球各大公有云厂商都曾经反对了 Kubernetes。此外，还有 100 多家技术守业公司也在继续地进行投入。当初阿里巴巴也在谈全面上云，而且上云就要上云原生，这也是各大技术公司拥抱云原生的一个例子。咱们正处于时代的要害节点2019 年正是云原生时代的要害节点，为什么这么说？咱们这里就为大家简略梳理一下。 从 2013 年 Docker 我的项目公布开始说起，Docker 我的项目的公布使得全操作系统语义的沙盒技术唾手可得，使得用户可能更好地、更残缺地打包本人的利用，使得开发者能够轻而易举的取得了一个利用的最小可运行单位，而不须要依赖任何 PaaS 能力。这对经典 PaaS 产业其实是一个“降维打击”。 2014 年的时候，Kubernetes 我的项目公布，其意义在于 Google 将外部的 Borg/Omega 零碎思维借助开源社区实现了“新生”，并且提出了“容器设计模式”的思维。而 Google 之所以抉择间接开源 Kubernetes 而不是间接开源 Borg 我的项目，其实背地的起因也比拟容易了解：Borg/Omega 这样的零碎太简单了，是没方法提供给 Google 之外的人应用，然而 Borg/Omega 这样的设计思维却能够借助 Kubernetes 让大家接触到，这也是开源 Kubernetes 的重要背景。 这样到了 2015 年到 2016 年，就到了容器编排“三国争霸”的时代，过后 Docker、Swarm、Mesos、Kubernetes 都在容器编排畛域开展角逐，他们竞争的起因其实也比拟容易了解， 那就是 Docker 或者容器自身的价值尽管大，然而如果想要让其产生商业价值或者说对云的价值，那么就肯定须要在编排下面占据一个无利的地位。 Swarm 和 Mesos 的特点，那就是各自只在生态和技术方面比拟强，其中，Swarm 更偏差于生态，而 Mesos 技术更强一些。相比之下， Kubernetes 则兼具了两者劣势，最终在 2017 年“三国争霸”的场面中得以胜出，成为了过后直到现在的容器编排规范。这一过程的代表性事件就是 Docker 公司发表在外围产品中内置了 Kubernetes 服务，并且 Swarm 我的项目逐步进行保护。 到了 2018 年的时候，云原生技术理念开始逐步萌芽，这是因为此时 Kubernetes 以及容器都成为了云厂商的既定规范，以“云”为外围的软件研发思维逐步形成。 而到了 2019 年，状况仿佛又将产生一些变动。 2019 年——云原生技术遍及元年为什么说 2019 年很可能是一个要害节点呢？咱们认为 2019 年是云原生技术的遍及元年。 首先大家能够看到，在 2019 年，阿里巴巴发表要全面上云，而且“上云就要上云原生”。咱们还能够看到，以“云”为外围的软件研发思维，正逐渐成为所有开发者的默认选项。像 Kubernetes 等云原生技术正在成为技术人员的必修课，大量的工作岗位正在涌现进去。 这种背景下，“会 Kubernetes”曾经远远不够了，“懂 Kubernetes”、“会云原生架构”的重要性正日益凸显进去。 从 2019 年开始，云原生技术将会大规模遍及，这也是为什么大家都要在这个工夫点上学习和投资云原生技术的重要起因。 二、“云原生技术公开课”是一门怎么的课程？基于下面所提到的技术趋势，所以阿里巴巴和 CNCF 联结开设了云原生技术公开课。 那么这样的公开课到底在讲什么内容呢？ 公开课教学大纲第一期云原生公开课的教学大纲，次要以利用容器和 Kubernetes 为外围，在前面几期将会陆续上线 Service Mesh、Serverless 等相干课程。 在第一期公开课中，咱们首先将课程分为两局部——基础知识局部和进阶常识局部，总共有 17 个知识点。 首先，咱们心愿通过第一局部的课程解说帮忙大家夯实根底。而后，对于更高阶的内容开展更深刻的代码级别的分析。心愿通过这样循序渐进的形式帮忙大家学习云原生技术；其次，在每个课程前面咱们的讲师都会设置对应的课后自测考试题，这些考试题实际上是对本节课程最无效的演绎，咱们心愿可能通过课后评测的形式来帮忙大家总结知识点，打造出属于本人的云原生常识体系；最初，咱们的讲师在每个知识点的背地都设计了云端实际，所谓“实际出真知”，学习计算机相关的常识还是须要上手来理论地进行操作才能够。 因而在云端实际局部，讲师会提供具体的实际步骤供大家课后自我分割。并且在这个环节，阿里云还会赠送了定量的阿里云代金券帮忙大家更好地在云上进行实际。以上三个局部就形成了阿里云和 CNCF 联合推出的云原生技术公开课的教学内容。 公开课授课打算（第一期）在授课打算方面，初步这样安顿：第一堂课在 2019 年 4 月的第三周上线，尔后将会每周更新一课，对于局部比拟重要的知识点将会每周更新两次，总共 25 个课时。每个知识点前面都提供了课后自测和云端实际。 对于讲师阵容而言，也是本次公开课最引以为傲的局部。咱们的公开课将会次要由 CNCF 社区资深成员与我的项目维护者为大家解说，很多课程讲师都是阿里云容器平台团队的专家级工程师。同时，咱们也会邀请云原生社区的资深专家和内部讲师为大家解说局部内容。因而在课程进行过程中，咱们会不定期地安顿大咖直播、课程答疑和落地实际案例。 咱们心愿将这些内容都集成在一起，为大家出现一个中国最残缺、最权威、最具备影响力的云原生技术公开课。 课程准备常识大家可能存在这样的纳闷，就是想要学习云原生基础知识之前须要哪些准备常识呢？其实大抵须要三局部准备常识： Linux 操作系统常识：次要是一些通识性的根底，最好具备肯定的在 Linux 下开发的教训；计算机和程序设计的根底：这一点到入门工程师或者高年级本科生程度就足够了；容器的应用根底：心愿大家具备容器的简略应用教训，比方 docker run 以及 docker build 等，最好有肯定 Docker 化利用开发的教训。当然，咱们在课程中也会解说相干的基础知识。三、什么是“云原生”？云原生该怎么落地？在介绍完课程之后，咱们再来具体的聊一聊“云原生”：什么是“云原生”？云原生该怎么落地？这两个问题也是整个课程的核心内容。 云原生的定义很多人都会问“到底什么是云原生？” 实际上，云原生是一条最佳门路或者最佳实际。更具体的说，云原生为用户指定了一条低心智累赘的、麻利的、可能以可扩大、可复制的形式最大化地利用云的能力、施展云的价值的最佳门路。 因而，云原生其实是一套领导进行软件架构设计的思维。依照这样的思维而设计进去的软件：首先，人造就“生在云上，长在云上”；其次，可能最大化地施展云的能力，使得咱们开发的软件和“云”可能人造地集成在一起，施展出“云”的最大价值。 所以，云原生的最大价值和愿景，就是认为将来的软件，会从诞生起就成长在云上，并且遵循一种新的软件开发、公布和运维模式，从而使得软件可能最大化地施展云的能力。说到了这里，大家能够思考一下为什么容器技术具备革命性？ 其实，容器技术和集装箱技术的革命性十分相似，即：容器技术使得利用具备了一种“自蕴含”的定义形式。所以，这样的利用能力以麻利的、以可扩大可复制的形式公布在云上，施展出云的能力。这也就是容器技术对云施展出的革命性影响所在，所以说，容器技术正是云原生技术的外围底盘。 云原生的技术领域云原生的技术领域包含了以下几个方面： 第一局部是云利用定义与开发流程。这包含利用定义与镜像制作、配置 CI/CD、音讯和 Streaming 以及数据库等。第二局部是云利用的编排与治理流程。这也是 Kubernetes 比拟关注的一部分，包含了利用编排与调度、服务发现治理、近程调用、API 网关以及 Service Mesh。第三局部是监控与可观测性。这部分所强调的是云上利用如何进行监控、日志收集、Tracing 以及在云上如何实现破坏性测试，也就是混沌工程的概念。第四局部就是云原生的底层技术，比方容器运行时、云原生存储技术、云原生网络技术等。第五局部是云原生工具集，在后面的这些核心技术点之上，还有很多配套的生态或者周边的工具须要应用，比方流程自动化与配置管理、容器镜像仓库、云原生平安技术以及云端明码治理等。最初则是 Serverless。Serverless 是一种 PaaS 的非凡状态，它定义了一种更为“极其形象”的利用编写形式，蕴含了 FaaS 和 BaaS 这样的概念。而无论是 FaaS 还是 BaaS，其最为典型的特点就是按理论应用计费（Pay as you go），因而 Serverless 计费也是重要的常识和概念。云原生思维的两个实践在理解完云原生的技术领域之后你就会发现，其所蕴含的技术内容还是很多的，然而这些内容的技术实质却是相似的。云原生技术的实质是两个实践根底。 第一个实践根底是：不可变基础设施。这一点目前是通过容器镜像来实现的，其含意就是利用的基础设施应该是不可变的，是一个自蕴含、自描述能够齐全在不同环境中迁徙的货色；第二个实践根底就是：云利用编排实践。以后的实现形式就是 Google 所提出来的“容器设计模式”，这也是本系列课程中的 Kubernetes 局部所需次要解说的内容。基础设施向云演进的过程首先为大家介绍一下“不可变基础设施”的概念。其实，利用所依赖的基础设施也在经验一个向云演进的过程，举例而言，对于传统的利用基础设施而言，其实往往是可变的。 大家可能常常会干这样一件事件，比方须要公布或者更新一个软件，那么流程大抵是这样的，先通过 SSH 连到服务器，而后手动降级或者降级软件包，一一调整服务器上的配置文件，并且将新代码间接都部署到现有服务器上。因而，这套基础设施会一直地被调整和批改。 然而在云上，对“云”敌对的利用基础设施是不可变的。 这种场景下的上述更新过程会这么做：一旦利用部署实现之后，那么这套利用基础设施就不会再批改了。如果须要更新，那么须要现更改公共镜像来构建新服务间接替换旧服务。而咱们之所以可能实现间接替换，就是因为容器提供了自蕴含的环境（蕴含利用运行所需的所有依赖）。所以对于利用而言，齐全不须要关怀容器产生了什么变动，只须要把容器镜像自身批改掉就能够了。因而，对于云敌对的基础设施是随时能够替换和更换的，这就是因为容器具备麻利和一致性的能力，也就是云时代的利用基础设施。 所以，总结而言，云时代的基础设施就像是能够代替的“牲口”，能够随时替换；而传统的基础设施则是举世无双的“宠物”，须要仔细呵护，这就体现出了云时代不可变基础设施的长处。 基础设施向云演进的意义所以，像这样的基础设施向“不可变”演进的过程，为咱们提供了两个十分重要的长处。 1、基础设施的一致性和可靠性。同样一个镜像，无论是在美国关上，在中国关上，还是在印度关上都是一样的。并且其中的 OS 环境对于利用而言都是统一的。而对于利用而言，它就不须要关怀容器跑在哪里，这就是基础设施一致性十分重要的一个特色。2、这样的镜像自身就是自蕴含的，其蕴含了利用运行所须要的所有依赖，因而也能够漂移到云上的任何一个地位。此外，云原生的基础设施还提供了简略、可预测的部署和运维能力。因为当初有了镜像，利用还是自描述的，通过镜像运行起来的整个容器其实能够像 Kubernetes 的 Operator 技术一样将其做成自运维的，所以整个利用自身都是自蕴含的行为，使得其可能迁徙到云上任何一个地位。这也使得整个流程的自动化变得非常容易。 利用自身也能够更好地扩容，从 1 个实例变成 100 个实例，进而变成 1 万个实例，这个过程对于容器化后的利用没有任何非凡的。最初，咱们这时也可能通过不可变的基础设施来地疾速四周的管控零碎和撑持组件。因为，这些组件自身也是容器化的，是合乎不可变基础设施这样一套实践的组件。 以上就是不可变基础设施为用户带来的最大的长处。 云原生关键技术点当咱们回过头来看云原生关键技术点或者说它所依赖的技术实践的时候，能够看到次要有这样的四个方向： 如何构建自蕴含、可定制的利用镜像；能不能实现利用疾速部署与隔离能力；利用基础设施创立和销毁的自动化治理；可复制的管控零碎和撑持组件。这四个云原生关键技术点是落地实现云原生技术的四个次要路径，而这四个技术点也是本门课程的 17 个技术点所次要讲述的外围常识。 本节总结“云原生”具备着重要的意义，它是云时代技术人自我晋升的必备门路；“云原生”定义了一条云时代利用从开发到交付的最佳门路；“云原生”利用生在云上，长在云上，心愿可能将云的能力施展到极致。讲师点评：“将来的软件肯定是成长于云上的”这是云原生理念的最外围假如。而所谓“云原生”，实际上就是在定义一条可能让利用最大水平利用云的能力、施展云的价值的最佳门路。在这条门路上，脱离了“利用”这个载体，“云原生”就无从谈起；容器技术，则是将这个理念落地、将软件交付的反动继续进行上来的重要伎俩之一。 而本期云原生公开课重点解说的 Kubernetes 我的项目，则是整个“云原生”理念落地的外围与关键所在。它正在迅速成为连通“云”与“利用”的高速公路，以规范、高效的形式将“利用”疾速交付到世界上任何一个地位。现在”云原生利用交付“，曾经成为了 2019 年云计算市场上最热门的技术关键词之一。心愿学习课程的同学们可能学以致用，继续关注以 K8s 为根底进行“云原生利用治理与交付”的技术趋势。 ...

摘要：欢送大家来到阿里云与 CNCF 独特推出的“云原生”技术公开课。本文整顿自“云原生”技术公开课的开篇：第一堂“云原生”课。在本文中，阿里巴巴高级技术专家、CNCF 官网大使张磊为大家介绍了“云原生”技术的倒退历程，本门课程的简介与准备常识以及“云原生”的定义和技术要点，精彩不容错过。 本节课程要点 云原生技术倒退历程（为什么要学习这门课）课程简介与准备常识（这门课到底教什么）云原生的定义与技术要点（本节正式内容）一、为什么要开设云原生技术公开课？云原生技术倒退简史首先从第一个问题进行分享，那就是“为什么要开设云原生技术公开课？”云原生、CNCF 都是目前十分热门的关键词，然而这些技术并不是十分陈腐的内容。 2004 年— 2007 年，Google 已在外部大规模地应用像 Cgroups 这样的容器技术；2008 年，Google 将 Cgroups 合并进入了 Linux 内核骨干；2013 年，Docker 我的项目正式公布。2014 年，Kubernetes 我的项目也正式公布。这样的起因也非常容易了解，因为有了容器和 Docker 之后，就须要有一种形式去帮忙大家不便、疾速、优雅地治理这些容器，这就是 Kubernetes 我的项目的初衷。在 Google 和 Redhat 公布了 Kubernetes 之后，这个我的项目的倒退速度十分之快。2015 年，由Google、Redhat 以及微软等大型云计算厂商以及一些开源公司独特牵头成立了 CNCF 云原生基金会。CNCF 成立之初，就有 22 个开创会员，而且 Kubernetes 也成为了 CNCF 托管的第一个开源我的项目。在这之后，CNCF 的倒退速度十分迅猛；2017 年，CNCF 达到 170 个成员和 14 个基金项目；2018 年，CNCF 成立三周年有了 195 个成员，19 个基金会我的项目和 11 个孵化我的项目，如此之快的倒退速度在整个云计算畛域都是十分常见的。云原生技术生态现状因而，现在咱们所探讨的云原生技术生态是一个宏大的技术汇合。CNCF 有一张云原生全景图（https://github.com/cncf/landscape），在这个全景图里曾经有 200 多个我的项目和产品了，这些我的项目和产品也都是和 CNCF 的观点所符合的。所以如果以这张全景图作为背景，加以思考就会发现，咱们明天所探讨的云原生其实次要议论了以下几点： 云原生基金会 —— CNCF；云原生技术社区，比方像 CNCF 目前正式托管的 20 多个我的项目独特形成了古代云计算生态的基石，其中像 Kubernetes 这样的我的项目曾经成为了世界第四沉闷的开源我的项目；除了后面两点之外，当初寰球各大公有云厂商都曾经反对了 Kubernetes。此外，还有 100 多家技术守业公司也在继续地进行投入。当初阿里巴巴也在谈全面上云，而且上云就要上云原生，这也是各大技术公司拥抱云原生的一个例子。咱们正处于时代的要害节点2019 年正是云原生时代的要害节点，为什么这么说？咱们这里就为大家简略梳理一下。 从 2013 年 Docker 我的项目公布开始说起，Docker 我的项目的公布使得全操作系统语义的沙盒技术唾手可得，使得用户可能更好地、更残缺地打包本人的利用，使得开发者能够轻而易举的取得了一个利用的最小可运行单位，而不须要依赖任何 PaaS 能力。这对经典 PaaS 产业其实是一个“降维打击”。 2014 年的时候，Kubernetes 我的项目公布，其意义在于 Google 将外部的 Borg/Omega 零碎思维借助开源社区实现了“新生”，并且提出了“容器设计模式”的思维。而 Google 之所以抉择间接开源 Kubernetes 而不是间接开源 Borg 我的项目，其实背地的起因也比拟容易了解：Borg/Omega 这样的零碎太简单了，是没方法提供给 Google 之外的人应用，然而 Borg/Omega 这样的设计思维却能够借助 Kubernetes 让大家接触到，这也是开源 Kubernetes 的重要背景。 这样到了 2015 年到 2016 年，就到了容器编排“三国争霸”的时代，过后 Docker、Swarm、Mesos、Kubernetes 都在容器编排畛域开展角逐，他们竞争的起因其实也比拟容易了解， 那就是 Docker 或者容器自身的价值尽管大，然而如果想要让其产生商业价值或者说对云的价值，那么就肯定须要在编排下面占据一个无利的地位。 Swarm 和 Mesos 的特点，那就是各自只在生态和技术方面比拟强，其中，Swarm 更偏差于生态，而 Mesos 技术更强一些。相比之下， Kubernetes 则兼具了两者劣势，最终在 2017 年“三国争霸”的场面中得以胜出，成为了过后直到现在的容器编排规范。这一过程的代表性事件就是 Docker 公司发表在外围产品中内置了 Kubernetes 服务，并且 Swarm 我的项目逐步进行保护。 到了 2018 年的时候，云原生技术理念开始逐步萌芽，这是因为此时 Kubernetes 以及容器都成为了云厂商的既定规范，以“云”为外围的软件研发思维逐步形成。 而到了 2019 年，状况仿佛又将产生一些变动。 2019 年——云原生技术遍及元年为什么说 2019 年很可能是一个要害节点呢？咱们认为 2019 年是云原生技术的遍及元年。 首先大家能够看到，在 2019 年，阿里巴巴发表要全面上云，而且“上云就要上云原生”。咱们还能够看到，以“云”为外围的软件研发思维，正逐渐成为所有开发者的默认选项。像 Kubernetes 等云原生技术正在成为技术人员的必修课，大量的工作岗位正在涌现进去。 这种背景下，“会 Kubernetes”曾经远远不够了，“懂 Kubernetes”、“会云原生架构”的重要性正日益凸显进去。 从 2019 年开始，云原生技术将会大规模遍及，这也是为什么大家都要在这个工夫点上学习和投资云原生技术的重要起因。 二、“云原生技术公开课”是一门怎么的课程？基于下面所提到的技术趋势，所以阿里巴巴和 CNCF 联结开设了云原生技术公开课。 那么这样的公开课到底在讲什么内容呢？ 公开课教学大纲第一期云原生公开课的教学大纲，次要以利用容器和 Kubernetes 为外围，在前面几期将会陆续上线 Service Mesh、Serverless 等相干课程。 在第一期公开课中，咱们首先将课程分为两局部——基础知识局部和进阶常识局部，总共有 17 个知识点。 首先，咱们心愿通过第一局部的课程解说帮忙大家夯实根底。而后，对于更高阶的内容开展更深刻的代码级别的分析。心愿通过这样循序渐进的形式帮忙大家学习云原生技术；其次，在每个课程前面咱们的讲师都会设置对应的课后自测考试题，这些考试题实际上是对本节课程最无效的演绎，咱们心愿可能通过课后评测的形式来帮忙大家总结知识点，打造出属于本人的云原生常识体系；最初，咱们的讲师在每个知识点的背地都设计了云端实际，所谓“实际出真知”，学习计算机相关的常识还是须要上手来理论地进行操作才能够。 因而在云端实际局部，讲师会提供具体的实际步骤供大家课后自我分割。并且在这个环节，阿里云还会赠送了定量的阿里云代金券帮忙大家更好地在云上进行实际。以上三个局部就形成了阿里云和 CNCF 联合推出的云原生技术公开课的教学内容。 公开课授课打算（第一期）在授课打算方面，初步这样安顿：第一堂课在 2019 年 4 月的第三周上线，尔后将会每周更新一课，对于局部比拟重要的知识点将会每周更新两次，总共 25 个课时。每个知识点前面都提供了课后自测和云端实际。 对于讲师阵容而言，也是本次公开课最引以为傲的局部。咱们的公开课将会次要由 CNCF 社区资深成员与我的项目维护者为大家解说，很多课程讲师都是阿里云容器平台团队的专家级工程师。同时，咱们也会邀请云原生社区的资深专家和内部讲师为大家解说局部内容。因而在课程进行过程中，咱们会不定期地安顿大咖直播、课程答疑和落地实际案例。 咱们心愿将这些内容都集成在一起，为大家出现一个中国最残缺、最权威、最具备影响力的云原生技术公开课。 课程准备常识大家可能存在这样的纳闷，就是想要学习云原生基础知识之前须要哪些准备常识呢？其实大抵须要三局部准备常识： Linux 操作系统常识：次要是一些通识性的根底，最好具备肯定的在 Linux 下开发的教训；计算机和程序设计的根底：这一点到入门工程师或者高年级本科生程度就足够了；容器的应用根底：心愿大家具备容器的简略应用教训，比方 docker run 以及 docker build 等，最好有肯定 Docker 化利用开发的教训。当然，咱们在课程中也会解说相干的基础知识。三、什么是“云原生”？云原生该怎么落地？在介绍完课程之后，咱们再来具体的聊一聊“云原生”：什么是“云原生”？云原生该怎么落地？这两个问题也是整个课程的核心内容。 云原生的定义很多人都会问“到底什么是云原生？” 实际上，云原生是一条最佳门路或者最佳实际。更具体的说，云原生为用户指定了一条低心智累赘的、麻利的、可能以可扩大、可复制的形式最大化地利用云的能力、施展云的价值的最佳门路。 因而，云原生其实是一套领导进行软件架构设计的思维。依照这样的思维而设计进去的软件：首先，人造就“生在云上，长在云上”；其次，可能最大化地施展云的能力，使得咱们开发的软件和“云”可能人造地集成在一起，施展出“云”的最大价值。 所以，云原生的最大价值和愿景，就是认为将来的软件，会从诞生起就成长在云上，并且遵循一种新的软件开发、公布和运维模式，从而使得软件可能最大化地施展云的能力。说到了这里，大家能够思考一下为什么容器技术具备革命性？ 其实，容器技术和集装箱技术的革命性十分相似，即：容器技术使得利用具备了一种“自蕴含”的定义形式。所以，这样的利用能力以麻利的、以可扩大可复制的形式公布在云上，施展出云的能力。这也就是容器技术对云施展出的革命性影响所在，所以说，容器技术正是云原生技术的外围底盘。 云原生的技术领域云原生的技术领域包含了以下几个方面： 第一局部是云利用定义与开发流程。这包含利用定义与镜像制作、配置 CI/CD、音讯和 Streaming 以及数据库等。第二局部是云利用的编排与治理流程。这也是 Kubernetes 比拟关注的一部分，包含了利用编排与调度、服务发现治理、近程调用、API 网关以及 Service Mesh。第三局部是监控与可观测性。这部分所强调的是云上利用如何进行监控、日志收集、Tracing 以及在云上如何实现破坏性测试，也就是混沌工程的概念。第四局部就是云原生的底层技术，比方容器运行时、云原生存储技术、云原生网络技术等。第五局部是云原生工具集，在后面的这些核心技术点之上，还有很多配套的生态或者周边的工具须要应用，比方流程自动化与配置管理、容器镜像仓库、云原生平安技术以及云端明码治理等。最初则是 Serverless。Serverless 是一种 PaaS 的非凡状态，它定义了一种更为“极其形象”的利用编写形式，蕴含了 FaaS 和 BaaS 这样的概念。而无论是 FaaS 还是 BaaS，其最为典型的特点就是按理论应用计费（Pay as you go），因而 Serverless 计费也是重要的常识和概念。云原生思维的两个实践在理解完云原生的技术领域之后你就会发现，其所蕴含的技术内容还是很多的，然而这些内容的技术实质却是相似的。云原生技术的实质是两个实践根底。 第一个实践根底是：不可变基础设施。这一点目前是通过容器镜像来实现的，其含意就是利用的基础设施应该是不可变的，是一个自蕴含、自描述能够齐全在不同环境中迁徙的货色；第二个实践根底就是：云利用编排实践。以后的实现形式就是 Google 所提出来的“容器设计模式”，这也是本系列课程中的 Kubernetes 局部所需次要解说的内容。基础设施向云演进的过程首先为大家介绍一下“不可变基础设施”的概念。其实，利用所依赖的基础设施也在经验一个向云演进的过程，举例而言，对于传统的利用基础设施而言，其实往往是可变的。 大家可能常常会干这样一件事件，比方须要公布或者更新一个软件，那么流程大抵是这样的，先通过 SSH 连到服务器，而后手动降级或者降级软件包，一一调整服务器上的配置文件，并且将新代码间接都部署到现有服务器上。因而，这套基础设施会一直地被调整和批改。 然而在云上，对“云”敌对的利用基础设施是不可变的。 这种场景下的上述更新过程会这么做：一旦利用部署实现之后，那么这套利用基础设施就不会再批改了。如果须要更新，那么须要现更改公共镜像来构建新服务间接替换旧服务。而咱们之所以可能实现间接替换，就是因为容器提供了自蕴含的环境（蕴含利用运行所需的所有依赖）。所以对于利用而言，齐全不须要关怀容器产生了什么变动，只须要把容器镜像自身批改掉就能够了。因而，对于云敌对的基础设施是随时能够替换和更换的，这就是因为容器具备麻利和一致性的能力，也就是云时代的利用基础设施。 所以，总结而言，云时代的基础设施就像是能够代替的“牲口”，能够随时替换；而传统的基础设施则是举世无双的“宠物”，须要仔细呵护，这就体现出了云时代不可变基础设施的长处。 基础设施向云演进的意义所以，像这样的基础设施向“不可变”演进的过程，为咱们提供了两个十分重要的长处。 1、基础设施的一致性和可靠性。同样一个镜像，无论是在美国关上，在中国关上，还是在印度关上都是一样的。并且其中的 OS 环境对于利用而言都是统一的。而对于利用而言，它就不须要关怀容器跑在哪里，这就是基础设施一致性十分重要的一个特色。2、这样的镜像自身就是自蕴含的，其蕴含了利用运行所须要的所有依赖，因而也能够漂移到云上的任何一个地位。此外，云原生的基础设施还提供了简略、可预测的部署和运维能力。因为当初有了镜像，利用还是自描述的，通过镜像运行起来的整个容器其实能够像 Kubernetes 的 Operator 技术一样将其做成自运维的，所以整个利用自身都是自蕴含的行为，使得其可能迁徙到云上任何一个地位。这也使得整个流程的自动化变得非常容易。 利用自身也能够更好地扩容，从 1 个实例变成 100 个实例，进而变成 1 万个实例，这个过程对于容器化后的利用没有任何非凡的。最初，咱们这时也可能通过不可变的基础设施来地疾速四周的管控零碎和撑持组件。因为，这些组件自身也是容器化的，是合乎不可变基础设施这样一套实践的组件。 以上就是不可变基础设施为用户带来的最大的长处。 云原生关键技术点当咱们回过头来看云原生关键技术点或者说它所依赖的技术实践的时候，能够看到次要有这样的四个方向： 如何构建自蕴含、可定制的利用镜像；能不能实现利用疾速部署与隔离能力；利用基础设施创立和销毁的自动化治理；可复制的管控零碎和撑持组件。这四个云原生关键技术点是落地实现云原生技术的四个次要路径，而这四个技术点也是本门课程的 17 个技术点所次要讲述的外围常识。 本节总结“云原生”具备着重要的意义，它是云时代技术人自我晋升的必备门路；“云原生”定义了一条云时代利用从开发到交付的最佳门路；“云原生”利用生在云上，长在云上，心愿可能将云的能力施展到极致。讲师点评：“将来的软件肯定是成长于云上的”这是云原生理念的最外围假如。而所谓“云原生”，实际上就是在定义一条可能让利用最大水平利用云的能力、施展云的价值的最佳门路。在这条门路上，脱离了“利用”这个载体，“云原生”就无从谈起；容器技术，则是将这个理念落地、将软件交付的反动继续进行上来的重要伎俩之一。 而本期云原生公开课重点解说的 Kubernetes 我的项目，则是整个“云原生”理念落地的外围与关键所在。它正在迅速成为连通“云”与“利用”的高速公路，以规范、高效的形式将“利用”疾速交付到世界上任何一个地位。现在”云原生利用交付“，曾经成为了 2019 年云计算市场上最热门的技术关键词之一。心愿学习课程的同学们可能学以致用，继续关注以 K8s 为根底进行“云原生利用治理与交付”的技术趋势。 ...

作者 | 王思宇、汪萌海、李鹏 业界要闻阿里云引领云原生进化，智能、互联、可信三位一体阿里巴巴致力于为数字经济构建智能、互联、信赖三位一体的翻新基础设施，引领云原生进化新阶段。反观阿里云容器服务团队近期在 AI、边缘、秘密计算三个畛域的开源新动静，与智能、互联、信赖的方向一一对应。 Chaos Mesh 我的项目退出 CNCF sandboxChaos Mesh提供针对Kubernetes上简单零碎的故障注入办法，并涵盖了Pod，网络，文件系统甚至内核中的故障。 阿里云在 KubeCon 2020 峰会上展现什么大杀器？KubeCon 2020 中国站，阿里云容器服务负责人易立会在《云原生，数字经济技术创新基石》的演讲中，分享阿里云原生如何助力数字技术抗“疫”，论述阿里云对云原生操作系统的思考，同时详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 四款企业级容器新品。 上游重要停顿make cadvisor metrics set configurable in kubeletKubelet 反对可配置的 cadvisor metrics set。 Pod resource metrics为 Pod resource 减少更通用的 metrics 统计。 Add cronjob controller v2新增 CronJob 控制器 v2 版本。 Do not create StatefulSet pods when PVC is being deletedStatefulSet 在判断 PVC处于 terminating 状态时不创立 Pod。 解读 Knative 0.16.0 版本个性Knative 0.16.0 版本已于近期公布，针对 Knative v0.16.0 版本对这些新性能个性进行解读，让你疾速对新版本个性有所深刻理解。从 Knative 0.16.0 开始，K8s 最小反对版本为 1.16。 ...

随着云计算的遍及与云原生的广泛应用，越来越多的从业者、决策者清晰地意识到「云原生化将成为 企业技术创新的要害因素，也是实现企业数字化转型的最短门路」。 因而，具备前瞻思维的互联网企业从利用诞生之初就扎根于云端，审慎稳重的新批发、政府、金融、医疗等畛域的企业与机构也逐步将业务利用迁徙上云，深度应用云原生技术与云原生架构。面对架构设计、开发方式到部署运维等不同业务场景，基于云原生架构的利用通常针对云的技术个性进行技术生命周期设计，最大限度利用云平台的弹性、分布式、自助、按需等产品劣势。 作为倒退最为迅猛的物流企业之一，申通快递始终积极探索技术创新赋能商业增长之路，以期达到降本提效目标。目前，申通快递日订单处理量已达千万量级，亿级别物流轨迹处理量，每天产生数据已达到 TB 级别，应用 1300+ 个计算节点来实时处理业务。 当业务飞速发展遭逢运维瓶颈过往申通快递的外围业务利用运行在 IDC 机房，原有 IDC 零碎帮忙申通安稳度过晚期业务疾速发展期。但随同着业务体量指数级增长，业务模式愈发多元化。原有零碎暴露出不少问题，传统 IOE 架构、各零碎架构的不标准、 稳定性、研发效率都限度了业务高速倒退的可能。软件交付周期过长，大促保障对资源的特殊要求难实现、零碎稳定性难以保障等业务问题逐步裸露。 在与阿里云进行屡次需要沟通与技术验证后，申通最终确定阿里云为惟一合作伙伴，采纳云原生技术和架构实现外围业务搬迁上阿里云。2019 年开始将业务逐渐从 IDC 迁徙至阿里云。目前，外围业务零碎曾经在阿里云上实现流量承接，为申通提供稳固而高效的计算能力。 全面革新云原生降级，助力业务倒退申通外围业务零碎原架构基于 Vmware+Oracle 数据库进行搭建。随着搬迁上阿里云，架构全面转型为基于 Kubernetes 的云原生架构体系。其中，引入云原生数据库并实现利用基于容器的微服务革新是整个应用服务架构重构的关键点。 引入云原生数据库通过引入 OLTP 跟 OLAP 型数据库，将在线数据与离线剖析逻辑拆分到两种数据库中，扭转此前齐全依赖 Oracle 数据库的现状。满足在解决历史数据查问场景下 Oracle 数据库所无奈反对的理论业务需要。 利用容器化随同着容器化技术的引进，通过利用容器化无效解决了环境不统一的问题，确保利用在开发、测试、生产环 境的一致性。与虚拟机相比，容器化提供了效率与速度的双重晋升，让利用更适宜微服务场景，无效晋升产研效率。 微服务革新因为过往很多业务是基于 Oracle 的存储过程及触发器实现的，零碎间的服务依赖也须要 Oracle 数据库 OGG 同步实现。这样带来的问题就是系统维护难度高且稳定性差。通过引入 Kubernetes 的服务发现，组建微服务解决方案，将业务按业务域进行拆分，让整个零碎更易于保护。 综合思考申通理论业务需要与技术特色，最终抉择了「阿里云 ACK+ 神龙 + 云数据库」的云原生解决方案，从而实现外围利用迁徙上阿里云。 1. 架构论述基础设施，全副计算资源取自阿里云的神龙裸金属服务器。相较于个别云服务器(ECS)，Kubernetes 搭配神龙服务器可能取得更优性能及更正当的资源利用率且云上资源按需取量，对于领有大促流动等短期大流量业务场景的申通而言极为重要。相较于线下自建机房、常备机器，云上资源随取随用。在大促流动完结后，云上资源应用结束后即可开释，治理与洽购老本更低，相应效率。 流量接入，阿里云提供两套流量接入，一套是面向公网申请，另外一套是服务外部调用。域名解析采纳云 DNS 及 PrivateZone。借助 Kubernetes 的 Ingress 能力实现对立的域名转发，以节俭公网 SLB 的数量，进步运维管理效率。 2. 平台层基于 Kubernetes 打造的云原生 PaaS 平台劣势显著突出。 ...

简介： 云原生技术岂但能够最大化云的弹性，帮忙企业实现降本提效，而且还有着更多翻新的设想空间。云原生将和 AI、边缘计算、秘密计算等新技术相结合，进入新的进化阶段，为数字经济构建智能、互联、信赖三位一体的翻新基础设施。 云原生技术岂但能够最大化云的弹性，帮忙企业实现降本提效，而且还有着更多翻新的设想空间。云原生将和 AI、边缘计算、秘密计算等新技术相结合，进入新的进化阶段，为数字经济构建智能、互联、信赖三位一体的翻新基础设施。 首届 KubeCon 2020 线上峰会圆满结束，阿里云作为 CNCF 最重要的云原生布道搭档，此次携 37 位云原生专家与宽广开发者分享了 27 场演讲，云原生话题丰盛度在本场流动中位居首位。作为峰会的压轴主题演讲，CNCF 理事会成员、阿里云容器服务负责人易立发表演讲《云原生，数字经济技术创新基石》 ，重点介绍了阿里云如何通过开源云原生技术与凋谢云原生产品，帮忙企业晋升面向疫情的应变能力，拥抱数字经济倒退的新机遇。与此同时，与大家分享了阿里云对云原生技术普惠和云原生操作系统的思考，并详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 等四款企业级容器新品。 相干文章举荐： 提前剧透｜KubeCon 2020 峰会上阿里云要展现什么大杀器？疫情以后，云原生为数字经济按下快进键2020 年，疫情突发之后，政府、企业和学校对在线合作的需要猛增。 “下班用钉钉，上学云课堂，出门衰弱码，订菜送到家”成了咱们日常生活的一部分，数字经济发展势头空前低落。这背地是一系列云计算、云原生技术撑持的业务翻新，云原生正在买通数字化落地的“最初一公里”。 钉钉扛住了有史以来最大的流量洪峰。春节后第一天停工，钉钉霎时迎来了近程办公流量顶峰：阿里云 2 小时内撑持了钉钉业务 1 万台云主机的扩容需要。基于云服务器和容器化的利用部署计划，让利用公布扩容效率大大晋升，为全国用户提供线上工作的晦涩体验。 希沃课堂顺利积攒超过 30 万老师开设 200 万节课程。面对指数级增长的流量，希沃课堂通过容器服务 ACK 高效治理神龙裸金属服务器和 Serverless 弹性容器实例，整个平台兼具高性能、高弹性、低成本、免保护的劣势。整体业务性能晋升 30%，运维老本升高 50%，给全国老师和学生提供了更好服务。 支付宝 3 天实现三省精准防控全笼罩。支付宝减速研发全国对立的疫情防控衰弱信息码，短短 3 天工夫，浙江、四川、海南三省陆续实现衰弱码全笼罩。云原生大数据平台提供了弱小的数据对立、会集和计算能力。基于云原生利用架构的码引擎零碎反对了业务需要的疾速迭代，具备弹性、韧性和平安的特点，安稳撑持每日亿次调用，成为宽广市民日常非亲非故的“衰弱通行证”。 盒马全程保障疫情期间居民日常供给。这背地是盒马整个数字化的供应链体系施展了重要作用。基于阿里云边缘容器服务 ACK@Edge 底座，盒马团队疾速构建了人、货、场数字化全链路交融，云、边、端一体化协同的天眼 AI 零碎。联合了云原生技术体系良好的资源调度和利用治理能力，与边缘计算就近拜访，实时处理的劣势，轻松实现全方位的降本提效，门店计算资源老本节俭 50%，新店开服效率晋升 70%。 三位一体 阿里云打下数字时代新基建的“底色”云原生架构与技术肯定是凋谢的，须要全行业独特定义与建设。阿里巴巴作为云原生畛域的先行者、实践者，基于本身累积多年的最佳实际，继续对社区赋能，为企业提供普惠的云原生产品服务，与开发者共建云原生生态，帮忙更多用户分享时代技术红利。 阿里巴巴致力于为数字经济构建智能、互联、信赖三位一体的翻新基础设施，引领云原生进化新阶段。反观阿里云容器服务团队近期在 AI、边缘、秘密计算三个畛域的开源新动静，与智能、互联、信赖的方向一一对应。 1. AI-智能企业在 IT 转型的大潮中对数字化和智能化的诉求越来越强烈，最突出的需要是如何能疾速、精准地从海量业务数据中开掘出新的商业机会和模式翻新，能力更好应答多变、不确定性的业务挑战。 阿里云提供云原生 AI 解决方案从底层异构计算资源，到下层计算框架进行全栈优化。次要个性有对立资源管理、高效共享隔离、对立调度器架构、分布式数据缓存、全生命周期赋能。同时阿里云也将这些成绩分享到社区，目前已有来自苹果、IBM、微博等贡献者和咱们在开源社区单干共建。 2. 边缘-互联阿里云公布边缘容器服务 ACK@Edge，短短一年内，曾经利用于音视频直播、云游戏、工业互联网、交通物流、城市大脑等利用场景中，并服务于盒马、优酷、阿里视频云和泛滥互联网、新批发企业。近期，阿里巴巴正式对外发表将其外围能力开源，并向社区奉献残缺的云原生边缘计算我的项目——OpenYurt。它深度开掘了“边缘计算+云原生落地施行”诉求。 ...

作者 | 氐宿  阿里云高级前端技术专家 导读：在业务团队做事的工程师摸爬滚打了一段时间后，肯定会有所疑难。团队同学在最后的一段时间都提出这样的纳闷：如何在业务中发现有技术价值的问题？发现问题后如何思考和发动再到解决？最初的技术后果跟业务后果如何连接？很多时候咱们听他人说“思考是不够的/要多思考”，其实都是在说这几点。接下来，阿里高级前端技术专家氐宿谈一谈遇到这三个问题时，他是如何解决的？ 如何在业务中发现有技术价值的问题？一位科学家毕生可用于钻研的工夫极其无限，然而，世界上的钻研主题却多得数不清。如果只因为略微感觉乏味就选为钻研主题，将在还没来得及做真正重要的事时，毕生就完结了。——利根川进其实要解答这个问题之前，咱们要了解一个概念，什么是有价值的问题？议题度高和解答质高的问题我了解就是有价值的问题，比拟艰深的了解就是这个问题是否存在，以后要解决这个问题的必要性够不够，问题对应的解决方案可行性高不高。如果要在业务里发现这种问题，首先要了解业务策略、打法和定位。那如何能力把这个前置信息做好，对工程师来说是一个比拟大的挑战。 首先工程师其实大多数都是从事一线开发，对业务了解可能仅限于本人在做的事件。很多信息都是他人过滤了五六手之后的信息，失去的可能就是一个工作和为什么做这个工作。绝对比之下必定不如制订策略的人懂得策略背地的意义，信息也是不对等的。所以首先咱们要收集信息，而后整顿演绎，最初剖析问题。 1. 先来说说收集信息其实有点像信息科学里的情报学。收集信息最好的形式就是加入所处业务老大的 KO 会，各种 KO 会会把策略上的拆解和背地的思考整体梳理之后宣讲传播给 BU 或部门的同学，尽管咱们没有亲自参加到脑暴过程，然而也会对背地的思考有肯定的了解，切记，肯定要记得划重点记笔记。 获取第一手信息之后，咱们要通过简略梳理开始收集内部信息，整顿整体的常识脉络，这里我常常用的就是阿里学习（业务宝库阿里学习，技术宝库 ATA，注：阿里外部两个学习平台），能够获取不少业务相干的分享，当然很多内部渠道也同样能够收集到。比方材料《飞猪“新旅行联盟”赋能商家能讲出什么新故事？》就是内部收集到的，能够得出几个关键词，数字技术赋能旅行行业、咱们不是 OTA，这些都要整顿到本人收集的信息池里。当然以上我提到的都是信息获取源的一种。具体收集信息的释义能够查一下百科，能够依照百科上的方法论学习一遍，以便找到适宜本人的办法。总之这里咱们要像产品经理一样去收集这些信息。这里也激励跟不同畛域不同BU的同学多交换，不限于线下扯淡式的交换和线上问问题的形式（这里倡议先看下知乎里这个答复对于学会问问题以及如何进行无效社交。 2. 剖析问题咱们通过不同信息源获取到的信息是散落的，如何通过加工融入本人的思考体系呢？首先信息不能是简略的重叠，咱们要通过不同的入口理出脉络。能够应用 MECE 法令进行思考拆解，通过无脱漏无反复地分类来把握整体，列出脑图和逻辑树，最初将逻辑树的信息匹配需要场景，能够尝试通过 C 端和 B 端不同入口去还原需要场景。这两头能够联合肯定的方法论（演绎推理和归纳推理），去把问题和挑战细化进去，帮忙咱们了解 BU 的策略，同时咱们也能从本身登程把策略拆解到对应的我的项目。举例来说去年我集体剖析飞猪在整个 C 端面临的次要问题之一还是流量格局过于繁多，B 端供应链的成熟度不够导致无奈给到商家更本质的体验服务，飞猪的类目穿插不够背地是各垂直业务存在业务隔离。 发现问题到执行该如何连接？拿到这三个问题咱们不能马上就开干，咱们还要提炼这个问题带来的外围价值。否则很容易就会呈现投入了微小工作之后，最初的技术产出和业务后果连接不上，所以说思考不要用蛮力，工作不只靠膂力。要去看外面跟本人角色相干的工作在什么中央？ 以端侧来说，有劣势的一点是凑近产品侧凑近用户侧，所以根本展示模式都能够通过产品原型进行形象，造成体系化。以流量体系建设举例咱们要对用户进行分层，比拟正当的形式能够用到几个经典模型RFM、AIPL、AARRR及其变种，以便积淀出承接的技术平台或产品。如流量体系建设咱们在思考分层过后，把用户按心智划分之后，又从所属域分为散落在阿里域外的用户和阿里域内的外部用户，从而针对性的设计出两个平台产品。 1. 见龙在田，利见小孩儿作为我的项目发起者，咱们要关注每一个环节。所以首先咱们要找到对应的业务方去“售卖”咱们的思考。要找到指标统一的人一起做事，这里首先须要晓得的是你要分明你的业务方都是谁？他们都负责什么？我的办法比较简单，间接看经营在职能上的划分，要分明本人对的人负责的方向以及他所负责的 KPI。另外切记，肯定要和对口 PD 一起去找，通常来说最间接的合作方是能帮你解决业务和技术连接的那个人。 上下游的人都找到后，要开始筹备 KO，理出需要排出优先级。因为在资源无限的状况下，咱们到底该先做哪些？不重要的要放在前面去做，优先思考你产品最外围的性能。通常平台产品最优先的是经营应用的性能，所以要跟合作方确认哪些性能他们认为最重要。 2. 站在伟人的肩膀上做翻新阿里巴巴曾经十分大了，咱们置信每一个想法都会有人想过，所以尽量不要走反复的路踩同一个坑，同理小公司利用开源技术亦是如此。那么在我的项目开始做的时候，如果是平台，咱们须要先拆出外围性能，这个外围性能要去看团体是否曾经有人在做了或是有成熟计划，防止反复造轮子，同时也能最快最间接的解决你最紧急外围的问题。这其中最简略间接办法就是搜寻 ATA（阿里外部技术论坛）和语雀（外部同学通常有常识记录的习惯），拆关键词找到做事件的要害人。你要置信你绝不是第一个想到该问题的人，一些通用问题肯定在团体内曾经有通用的服务提供进去，即便没有也会有比拟成熟的计划。 如果团体外部就是没有成型计划，这个方向也属于工业界比拟前沿的畛域。遇到相似这种问题，能够先看看是否有绕开的可能性，如果的确绕不开能够试试找到适宜解决该问题的根底团队一起单干和共建。内部是否有付费计划能够购买和借鉴，总之要保障业务先赢。因为业务工程师要思考的是你给业务能带来怎么的价值，你的外围价值不是解决非常复杂的技术问题，而是用你的技术能给业务带来怎么的价值增量。同样的利用某种技术或模型模式解决了非常复杂的业务问题，并且是具备普适价值的技术，这也是业务端工程师带给业务带来的价值。 3. 立足当下，放眼将来知几，其神乎！ 要看当下更要看将来，不光技术要看将来，行业也要看将来。站在当下思考能解决业务目前遇到的最大的问题，思考将来能为业务带来弯道超车的机会。比方飞猪如果在行业里要追赶同行业的竞品，在资源投入方面没方法跟对方的体量比拟的状况下，咱们做到最初，最好的后果可能也只是追平对手。所以咱们亟须找到将来行业争胜的要害按钮，把工夫和精力聚焦在要害节点，用寰球Fun策略解围。所以飞猪也要为国际化做好筹备，这个畛域里同样有前人探寻的技术教训供咱们借鉴。所以为了让咱们能更聚焦业务，能够说去年的平台化是为业务做了十分好的铺垫。 最初的技术后果跟业务后果如何连接？其实这个小标题有点伪命题的意思，如果一开始咱们就把业务了解的很分明，执行没有偏离航道比拟专一指标的话，不大可能会呈现拿不到业务后果的状况，最初只剩下一个问题：拿到业务后果的同时技术价值如何体现？ 从我本身登程，也经常有同学问我，在业务做开发，反复造轮子会被人挑战，但事件都有人干了咱们的价值在哪？我之前始终都会答复，“搞根底技术的团队始终在根底工程/技术畛域深耕，他们也须要关注从技术价值到业务价值的转变和连接，实质上短少业务场景，如果咱们与他们单干就造成了互补，既拿到了业务后果同时也能从本身技术成长上失去肯定历练”。 但之后我回忆这段对话，是有很多问题在外面的。从业务工程师角度登程，咱们要关注的外围就是保障业务先赢，如果没有达到这个指标就容易变成工程师自嗨。所以咱们在业务端须要的是有技术视线能看到团体其余团队或者内部团队在做的事，能被动交换让这件事变成共赢，如果没有其他人在搞，咱们去搞要有人站进去看这个投入产出比是否正当？也就是咱们在开篇说的议题度和解答质都高的有价值的问题。这个问题在团体其余团队是否存在共性，咱们解决了是否为他们带来价值？当然联合咱们在后面讲到的在业务中发现有技术价值的问题，其实这里就有一个比拟明确的答案，重中之重就是做之前把 Why 思考的分明清晰，做最正确的事。只有做到这点，解决这个问题带来的业务价值就自然而然十分清晰的定位进去。所以说最好的工程师必须要懂产品。 也写给将来小聊一下题外话，组里有同学会问我业务前端将来是否会被淘汰？因为咱们在做的 lowcode/nocode 是在革本人的命。其实产生这种想法首先就是没有站在团体将来倒退的角度去思考也就是常说的屁股太小，其次是没有站在整个前端畛域去回顾前端倒退历程导致的乐观和担心。 从目前在做的方向上来说，还是要思考如何解决低质量代码建设和低效的反复工作占用工程师大部分精力，将工程师的能量解放出来晋升团体整体的研发效力。另一层面从前端以往在零碎分层里的地位始终都属于应用层，就是最上层的表象/展示/渲染，应用层在过来几十年间通过了一直的变动和演进，职业也从最早的 GUI 工程师演进到之后的 web 前端/客户端研发工程师，这两头也经验过 flash 工程师的时代，在此期间应用层/展示层始终都在变动，所以前端同学总感觉状态是始终在学习新常识。但这个倒退历程其实是有法则可循的，所谓万变不离其宗，应用层尽管在一直变动但无非都是朝着两个大方向在倒退，一个是工程效率晋升（工程角度登程），一个是图形图像钻研（用户角度登程）。这两个大方向上目前也有非常复杂宏大的树状常识体系，并且还在一直延长。同时随着机器学习畛域的衰亡和硬件性能、网络带宽的晋升以及人们在视觉出现设施上的降级，带来的可能又是新一轮的技术洗牌，而后在两个方向上再来一次。所以从这个视角登程将来前端是不会沦亡的可能只是会换一种模式存在，然而不学习的工程师是会沦亡的。 最初最初我想说的是来到一个新业务不要焦急的去拿这两个后果（业务和技术），所谓“潜龙勿用”。要先去看业务在团体所处的地位，怎么和其余业务产生关联的，要去收集信息和问题，带着问题深刻去做事件，通过跟其他人的信息交换补全业务痛点。先收集问题，边做边思考，先沉下心做业务我的项目。要有导弹型思维，就是不管三七二十一，先干起来再说。在口头中实现智能导航，锁定并跟踪目标，依据理论状况修改本身门路，直至击中目标。 其实写了比拟多，也是对我做事件的方法论做了一遍梳理和总结，也是说最好不要让业务推着你走，而是最终要做到你带着业务走。这个“带”可能最后是了解业务打法之后的一种业务朝着你了解的方向去走的体感，但通过长期训练，这部分其实能够做实，最初真的是你通过技术创新引领行业改革最初驱动业务向前推动。当然这些是我来阿里三年的领会，尽管在来之前也曾经工作了七八年，但在阿里成长的速度远远超过之前的成长，并且也才刚刚三年还是个“新人”，所以在这里也给本人个寄语，心愿五年、十年之后我的思考又会升华到一个档次。同时也欢送大家拍砖/评论， 原来我都是战战兢兢发文跟大家说轻拍，须要激励，但之后也是发现激励是最不容易发现问题，这会导致发现不了本身思考上的盲点和盲区，短少成长路上的经验值，所以这里激励大家一起多交换。 ...

导读：云原生操作系统进化，详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 等四款企业级容器新品。KubeCon 2020 中国站，阿里云容器服务负责人易立会在《云原生，数字经济技术创新基石》的演讲中，分享阿里云原生如何助力数字技术抗‘疫’，论述阿里云对云原生操作系统的思考，同时详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 四款企业级容器新品。 容器服务 ACK Pro，为企业级大规模生产环境提供加强的可靠性安全性，以及与可赔付规范 SLA，现已开启公测。同时还有三款产品商业化：服务网格 ASM，对立精准管控容器化微服务利用流量；容器镜像服务企业版 ACR EE，公共云首个独享实例状态的容器镜像仓库产品，是撑持阿里巴巴经济体的双十一起款利器，具备如下能力：多维度平安保障、寰球镜像散发减速、DevSecOps 交付提效特点，保障企业客户云原生制品的平安托管及高效散发；边缘容器 ACK@Edge 采纳非侵入形式加强，提供边缘自治、边缘单元、边缘流量治理、原生运维 API 反对等能力，以原生形式反对边缘计算场景下的利用对立生命周期治理和对立资源调度。 疫情期间，争分夺秒的云原生云计算是数字时代新基建，而 2020 疫情也为数字化生存按下了快进键。“下班用钉钉，上学云课堂，出门衰弱码，订菜送到家”成为了日常生活一部分，这背地是一系列云计算、云原生技术撑持的业务翻新。 2 小时内撑持了钉钉业务 1 万台云主机的扩容需要，基于阿里云服务器和容器化的利用部署计划，钉钉利用公布扩容效率大大晋升，顺利扛住有史以来最大的流量洪峰，为全国用户提供线上工作的晦涩体验。 复课不停学，希沃课堂整体业务性能晋升 30%、运维老本升高 50%，洋葱学院系统资源利用率晋升 60%。 衰弱码基于云原生大数据平台具备弹性、韧性和平安的特点，安稳撑持每日亿次调用。 盒马通过阿里云边缘容器服务 ACK@Edge，疾速构建人、货、场数字化全链路交融，云、边、端一体化协同的天眼 AI 零碎。联合了云原生技术体系良好的资源调度和利用治理能力，与边缘计算就近拜访，实时处理的劣势，轻松实现全方位的『降本提效』，门店计算资源老本节俭 50%，新店开服效率晋升 70%。 云原生操作系统的诞生与进化容器技术的倒退揭开了云原生计算的尾声，在易立看来， Kubernetes 为根底的云原生计算也曾经成为新的操作系统，云原生操作系统的雏形被越来越多的行业和企业驳回并因而受害：容器利用化、容器编排零碎和 Istio 服务网格等技术顺次解耦了利用与运行环境、资源编排调度与底层基础设施、服务实现与服务治理等传统架构的依赖关系。 阿里云为用户提供了怎么的云原生操作系统？这个云原生操作系统又有哪些突出特点呢？ 首先基础设施层是弱小的 IaaS 资源，基于第三代神龙架构的计算资源能够更弹性的扩大，以更加优化的老本提供更高的性能；云原生的分布式文件系统，为容器长久化数据而生；云原生网络减速利用交付能力，提供应用型负载平衡与容器网络基础设施。 其次在容器编排层，阿里云容器服务自 2015 年上线来，随同数千家企业客户，独特实际过各行各业大量生产级场景。越来越多的客户以云原生的形式架构其大部分甚至全量利用，随着业务深刻倒退，为了满足大中型企业对可靠性、安全性的强烈需要，阿里云推出新品可供赔付 SLA 的容器服务企业版 ACK Pro。 容器服务企业版 ACK Pro 横空出世：全面平安、高性能，反对新一代神龙架构，SLA 可赔付容器服务企业版 ACK Pro，是在原容器服务 ACK 托管版集群的根底上倒退而来，其继承了原托管版集群的所有劣势，例如 Master 节点托管和高可用等。同时，相比原托管版进一步晋升了集群的可靠性、安全性和调度性能，并且反对赔付规范的 SLA，高达 99.95%，单集群可反对 5000 节点。ACK Pro 非常适合生产环境下有着大规模业务、对稳定性和安全性有高要求的企业客户。 ...

随着云计算技术的日趋成熟，越来越多的企业意识到云计算利用的重要性。作为云计算畛域的一个新兴概念，云原生进入人们的视线当中，被云计算服务商宽泛承受，逐步成为云计算畛域中重要的技术发展趋势。云原生利用的遍及在为企业带来高效、便捷的应用体验的同时，也带来了传统平安伎俩无奈应答的新型攻打门路和平安问题；如何将平安防护能力与云原生利用相结合，成为了以后热门的研究课题。 在腾讯平安和技术媒体CSDN联结发动的「产业平安公开课 · 云原生平安专场」中，来自腾讯平安的七位专家别离就主机平安、平安经营核心、明码技术利用、数据安全、DDoS防护、Web利用防火墙以及云防火墙等平安防护能力与云原生的联合进行解读，同时也分享了他们对云原生平安的了解和实践经验。 01 企业上云，如何保障主机平安 从云计算的广泛应用到云原生的减速布局，虚拟机、云主机、容器技术等技术的落地和倒退一方面促成了企业数据资产和业务管理的效率，另一方面则突破了传统的平安边界，为主机带来了更多元的危险和挑战——虚拟机逃逸、主机防护规模几何级增长、镜像净化、跨云管控等云上问题，亟需企业基于云原生平安视角进行主机平安防护的部署，配置具备检测能力、响应能力、架构适配能力、满足合规要求的云平安防护体系。 腾讯平安主机平安产品负责人谢奕智具体介绍了企业面临的云上主机平安挑战、痛点、需要以及腾讯平安的解决方案，并从根本技术和应用服务等维度分享了云原生平安架构下的主机平安产品发展趋势。 02 如何构建云时代的云原生平安经营核心 越来越多的业务迁徙上云。面对更加弹性的云环境，企业平安人员不仅要面对成倍增加的平安告警，频繁变更的资产动静盘点也让运维疲于奔命，而云平安配置管理、自动化响应机制等新平安挑战间接关系到整个企业的数据安全，企业的传统平安体系和经营思路已无奈应答新环境下产生的平安威逼。如何帮忙运维人员更加简洁明了地认知和构建企业的云原生平安经营体系，从事前全预防、事中威逼检测到预先响应处理实现全生命周期防护，对于企业信息安全而言至关重要。 腾讯平安高级工程师耿琛从云时代给平安行业带来的挑战切入，以腾讯平安为银行搭建云原生生态学院钻研管理中心为例，具体阐释了云原生平安经营体系该当如何构建，让用户更加直观地感触到云原生平安经营核心是如何满足不同行业的平安诉求。 03云原生数据安全中台解决方案分享 明码是网络空间平安包装和信赖机制构建的核心技术和根底撑持。云原生时代，企业如何应用与云平台自身无缝联合的形式来实现数据加密、如何优化调用数据的配置流程，成为企业用户重点关注的问题。事实上，在构建数据全生命周期平安防护体系的过程中，充分利用云原生数据安全中台的数据加密软硬件零碎、密钥管理系统、凭据管理系统以及云数据加密代理网关等技术，可能无效帮忙企业应答云上数据安全问题。 腾讯平安云鼎实验室专家姬生利聚焦云原生数据安全中台利用，具体介绍了云原生数据中台的挑战、数据安全爱护策略模型以及解决方案，为企业提前躲避在资源隔离、数据存储、数据传输、数据共享、虚拟化等方面可能存在的业务危险提供帮忙。 04 摸索轻量而齐备的云原生数据安全 5G、AI、云计算等新技术的落地和利用，为数据与信息的生产和传输打造更加平坦宽敞的传输通道。数据利用得越宽泛，数据安全工作越重要；尤其在云畛域，数据利用正在疾速倒退，各企业都在踊跃谋求数据单干、减速数据流动效率，此时云原生数据的平安运维构架可能为产业云化降级中的信息安全反抗提供全面的撑持。 腾讯平安数据安全专家周京川围绕如何保障云上数据的全生命周期平安，从数据安全产品如何从云原生架构登程、无缝嵌入云原生环境，向用户具体阐释了数据安全云原生的摸索。 05云时代，如何防备TB级DDoS攻打 以后的DDoS攻打局势仍旧严厉，大流量攻打突出，百G以上攻打次数较往年继续减少，Tb级攻打时代曾经到来。依据Forrester考察显示，寰球四分之一的企业平安决策者示意蒙受过DDoS攻打。随着云计算的疾速倒退，企业面临的DDoS攻防局势更加严厉，云上DDoS攻防演化成全方位的反抗，从云平台到云上业务，从网络层、应用层、主机层到数据层都须要进行卓有成效的抗D防护。 腾讯平安网络安全专家王超力具体介绍了腾讯平安DDoS防护体系如何防备大流量攻打，并分享了腾讯的DDoS平安防护系统在各个行业的落地和利用。 06如何基于云原生平安打造全新一代WAF 随着攻打技术、破绽披露等伎俩的愈发成熟，针对Web平安相干破绽的利用也日趋产业化。云WAF作为一种部署简略、保护成本低，无需装置任何软件或者部署任何硬件设施的解决方案，成为大量中小型企业以及集体网站的新抉择。云原生架构下的云WAF防护规定处于云端，企业能够利用云原生的根本平安能力和最新平安技术能力构建主动防御体系，搭建更合乎云上利用的平安经营零碎。 腾讯平安WAF负责人刘吉赟梳理了web利用平安的倒退，并从利用平安防护的架构和翻新方面列举了相干胜利案例，同时对腾讯云利用平安防护的将来布局进行了相干介绍。 07云原生平安云防火墙外围能力与最佳实际 在云端混合环境、挪动拜访及在线应用程序迅速发展趋势下，攻击面裸露过多、云端流量拜访与管控、安全漏洞及平安日志审查等根底平安问题逐步裸露，企业须要更具细粒度的平安技术解决上述问题，全面晋升企业云上业务和资产的平安爱护能力。云原生利用所需的防火墙，应反对云环境下的SaaS化一键部署，性能可弹性扩大，并基于流量嵌入多种平安能力，保障企业云上资产与业务平安。 腾讯平安云防火墙产品负责人周荃从外围能力与用户价值登程，向用户充沛展现云防火墙的产品细节，并具体介绍了如何通过云防火墙帮忙用户实现业务上云，从而打造云原生平安体系、实现平面防护。 云原生作为企业数字化转型和继续翻新的加速器，随着技术倒退和产品迭代正在逐步深刻企业的外部流程和业务场景之中。云原生平安经营的根本特点，是基于云原生利用的平安需要对各平安模块进行对立治理，突破各个平安产品间互相孤立的场面，打造平安能力互相协同、最终造成残缺平安闭环。腾讯平安将继续关注并输入云原生平安的技术与利用价值，深刻摸索企业上云的平安之道。

随着云计算技术的日趋成熟，越来越多的企业意识到云计算利用的重要性。作为云计算畛域的一个新兴概念，云原生进入人们的视线当中，被云计算服务商宽泛承受，逐步成为云计算畛域中重要的技术发展趋势。云原生利用的遍及在为企业带来高效、便捷的应用体验的同时，也带来了传统平安伎俩无奈应答的新型攻打门路和平安问题；如何将平安防护能力与云原生利用相结合，成为了以后热门的研究课题。 在腾讯平安和技术媒体CSDN联结发动的「产业平安公开课 · 云原生平安专场」中，来自腾讯平安的七位专家别离就主机平安、平安经营核心、明码技术利用、数据安全、DDoS防护、Web利用防火墙以及云防火墙等平安防护能力与云原生的联合进行解读，同时也分享了他们对云原生平安的了解和实践经验。 01 企业上云，如何保障主机平安 从云计算的广泛应用到云原生的减速布局，虚拟机、云主机、容器技术等技术的落地和倒退一方面促成了企业数据资产和业务管理的效率，另一方面则突破了传统的平安边界，为主机带来了更多元的危险和挑战——虚拟机逃逸、主机防护规模几何级增长、镜像净化、跨云管控等云上问题，亟需企业基于云原生平安视角进行主机平安防护的部署，配置具备检测能力、响应能力、架构适配能力、满足合规要求的云平安防护体系。 腾讯平安主机平安产品负责人谢奕智具体介绍了企业面临的云上主机平安挑战、痛点、需要以及腾讯平安的解决方案，并从根本技术和应用服务等维度分享了云原生平安架构下的主机平安产品发展趋势。 02 如何构建云时代的云原生平安经营核心 越来越多的业务迁徙上云。面对更加弹性的云环境，企业平安人员不仅要面对成倍增加的平安告警，频繁变更的资产动静盘点也让运维疲于奔命，而云平安配置管理、自动化响应机制等新平安挑战间接关系到整个企业的数据安全，企业的传统平安体系和经营思路已无奈应答新环境下产生的平安威逼。如何帮忙运维人员更加简洁明了地认知和构建企业的云原生平安经营体系，从事前全预防、事中威逼检测到预先响应处理实现全生命周期防护，对于企业信息安全而言至关重要。 腾讯平安高级工程师耿琛从云时代给平安行业带来的挑战切入，以腾讯平安为银行搭建云原生生态学院钻研管理中心为例，具体阐释了云原生平安经营体系该当如何构建，让用户更加直观地感触到云原生平安经营核心是如何满足不同行业的平安诉求。 03云原生数据安全中台解决方案分享 明码是网络空间平安包装和信赖机制构建的核心技术和根底撑持。云原生时代，企业如何应用与云平台自身无缝联合的形式来实现数据加密、如何优化调用数据的配置流程，成为企业用户重点关注的问题。事实上，在构建数据全生命周期平安防护体系的过程中，充分利用云原生数据安全中台的数据加密软硬件零碎、密钥管理系统、凭据管理系统以及云数据加密代理网关等技术，可能无效帮忙企业应答云上数据安全问题。 腾讯平安云鼎实验室专家姬生利聚焦云原生数据安全中台利用，具体介绍了云原生数据中台的挑战、数据安全爱护策略模型以及解决方案，为企业提前躲避在资源隔离、数据存储、数据传输、数据共享、虚拟化等方面可能存在的业务危险提供帮忙。 04 摸索轻量而齐备的云原生数据安全 5G、AI、云计算等新技术的落地和利用，为数据与信息的生产和传输打造更加平坦宽敞的传输通道。数据利用得越宽泛，数据安全工作越重要；尤其在云畛域，数据利用正在疾速倒退，各企业都在踊跃谋求数据单干、减速数据流动效率，此时云原生数据的平安运维构架可能为产业云化降级中的信息安全反抗提供全面的撑持。 腾讯平安数据安全专家周京川围绕如何保障云上数据的全生命周期平安，从数据安全产品如何从云原生架构登程、无缝嵌入云原生环境，向用户具体阐释了数据安全云原生的摸索。 05云时代，如何防备TB级DDoS攻打 以后的DDoS攻打局势仍旧严厉，大流量攻打突出，百G以上攻打次数较往年继续减少，Tb级攻打时代曾经到来。依据Forrester考察显示，寰球四分之一的企业平安决策者示意蒙受过DDoS攻打。随着云计算的疾速倒退，企业面临的DDoS攻防局势更加严厉，云上DDoS攻防演化成全方位的反抗，从云平台到云上业务，从网络层、应用层、主机层到数据层都须要进行卓有成效的抗D防护。 腾讯平安网络安全专家王超力具体介绍了腾讯平安DDoS防护体系如何防备大流量攻打，并分享了腾讯的DDoS平安防护系统在各个行业的落地和利用。 06如何基于云原生平安打造全新一代WAF 随着攻打技术、破绽披露等伎俩的愈发成熟，针对Web平安相干破绽的利用也日趋产业化。云WAF作为一种部署简略、保护成本低，无需装置任何软件或者部署任何硬件设施的解决方案，成为大量中小型企业以及集体网站的新抉择。云原生架构下的云WAF防护规定处于云端，企业能够利用云原生的根本平安能力和最新平安技术能力构建主动防御体系，搭建更合乎云上利用的平安经营零碎。 腾讯平安WAF负责人刘吉赟梳理了web利用平安的倒退，并从利用平安防护的架构和翻新方面列举了相干胜利案例，同时对腾讯云利用平安防护的将来布局进行了相干介绍。 07云原生平安云防火墙外围能力与最佳实际 在云端混合环境、挪动拜访及在线应用程序迅速发展趋势下，攻击面裸露过多、云端流量拜访与管控、安全漏洞及平安日志审查等根底平安问题逐步裸露，企业须要更具细粒度的平安技术解决上述问题，全面晋升企业云上业务和资产的平安爱护能力。云原生利用所需的防火墙，应反对云环境下的SaaS化一键部署，性能可弹性扩大，并基于流量嵌入多种平安能力，保障企业云上资产与业务平安。 腾讯平安云防火墙产品负责人周荃从外围能力与用户价值登程，向用户充沛展现云防火墙的产品细节，并具体介绍了如何通过云防火墙帮忙用户实现业务上云，从而打造云原生平安体系、实现平面防护。 云原生作为企业数字化转型和继续翻新的加速器，随着技术倒退和产品迭代正在逐步深刻企业的外部流程和业务场景之中。云原生平安经营的根本特点，是基于云原生利用的平安需要对各平安模块进行对立治理，突破各个平安产品间互相孤立的场面，打造平安能力互相协同、最终造成残缺平安闭环。腾讯平安将继续关注并输入云原生平安的技术与利用价值，深刻摸索企业上云的平安之道。

-点击支付《云原生架构白皮书》- 导语： 有幸作为阿里云MVP提前取得了阿里云云原生团队编写的《云原生架构白皮书》，心愿通过本人对于云原生的了解为开发者提供一篇观后感或者是可能参考的博文。 1 云原生与分布式系统架构的关系1.1 云原生架构的定义《云原生架构白皮书》中对于云原生架构的定义为“基于云原生技术的一组架构准则和设计模式的汇合，旨在将云利用中的非业务代码局部进行最大化的剥离，从而让云设施接管利用中原有的大量非性能个性（如弹性、韧性、平安、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、麻利、高度自动化的特点。” 1.2 分布式系统架构的定义此处定义参考百度百科为“在一个分布式系统中，一组独立的计算机展示给用户的是一个对立的整体，就如同是一个零碎似的。零碎领有多种通用的物理和逻辑资源，能够动静的分配任务，扩散的物理和逻辑资源通过计算机网络实现信息替换。零碎中存在一个以全局的形式治理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件负责实现这个模型。” 1.3 云原生与分布式系统架构的关系分布式架构的重点在于解决计算力的保障问题以及为了进步计算力并同时确保零碎的可靠性、可用性和安全性而产生的诸如弹性伸缩、负载平衡、分布式存储等问题，其指标是在于构建一个分布式的安全可靠的计算力根底平台。通常来说，对于信息系统的架构形式的进化和扭转即是随同着接入数据和所提供的业务由少变多的过程，目前为止信息系统的架构经验了单机架构、集群架构、分布式架构、分布式多活数据中心架构几个阶段，同时随同着业务零碎架构一起演变的还有各种外围零碎和存储系统，比方关系数据库的分库分表革新、从本地缓存过渡到分布式缓存等。 要理清分布式架构和云原生的关系，先来演绎一下分布式架构与云之间的关系，云个别指的是一个提供资源的平台，云计算的实质是按需分配资源和弹性计算，而针对目前数据井喷并随着物联网利用的推动依然接入量在呈指数回升的现状下，分布式架构是最可能满足构建一个合格的云平台所应具备特质的架构形式。云原生利用即专门为在云平台部署和运行而设计的利用，采纳云原生的设计模式能够优化和改良传统利用模式，使利用更加适宜在云平台上运行，因而云原生倒退的实质需要来自于SAAS层面设计理念的改良，因为SAAS层的设计理念的改良而进一步从北向往南向推动了PAAS层特地是中间件的降级从而确保整个云平台的架构可能更好的服务于云原生架构的扭转。 因而，云原生和分布式架构的降级和迭代是一个滚动的过程，为了更好的施展云平台的特点而有了云原生的需要和设计模式扭转，而在这个过程中云原生也反过来促成了上层架构的降级。这个迭代的过程充沛的反馈了互联网或者说数据时代开发理念的特色，即滚动而非单向。 1.3 《云原生架构白皮书》章节导读通过《云原生架构白皮书》的第1章和第2章内容能够充沛的了解云原生的实质和云原生架构的特点，在浏览这两章的内容时举荐参考分布式架构的相干书籍，因为云原生和分布式架构密切相关，然而降级迭代的着力点又有所区别，所以可能联合在一起进行浏览是最好的。 2 云原生次要架构准则和技术剖析2.1 微服务和小零碎服务微服务架构，从宏观上来看，无非就是细化了服务拆分过程中的粒度，粒度越细，业务耦合越小，容错性就越好，并且前期扩大也会越容易。然而颗粒度过细，又会带来另外一些麻烦比方晋升了保护老本、影响排查问题时的效率、业务开发人员很难梳理分明服务之间的依赖关系等。 因而《云原生架构白皮书》在微服务相干章节中又提到了小零碎服务的概念，即是一个颗粒度的中间状态，其实外围就是一个服务拆分颗粒度的问题，白皮书中的第3章中有专门章节对于云原生微服务特地是微服务设计过程中的束缚做了具体介绍，基本目标就是使微服务的倒退处于一个受约束的状态，而不是因为有了微服务的理念就是服务拆分的颗粒度越细越好。 2.2 容器技术与云原生的关系 从白皮书中提供的比照图能够分明的发现，云原生在代码方面，对于代码通常所蕴含的三局部：业务代码、三方软件和解决非性能个性的代码进行剥离，最终想实现的现实状态是把所有非功能性代码（即除业务代码局部）从SAAS层剥离到PAAS层和IAAS层中去，当然目前还是没有齐全做到。剥离非性能代码依然是一个设计模式理念的变动，而在这个理念的落地过程中容器技术成为了最好的工具。 在白皮书中这张比照图的根底上，依据其余一些公开材料可能更清晰的反映出容器技术利用之后，云原生架构所产生的变动。 （单机架构） 注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师2.0》高翔龙著 电子工业出版社 （集群架构） 注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师2.0》高翔龙著 电子工业出版社 （服务化架构） 注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师2.0》高翔龙著 电子工业出版社 在这种架构形式下以被广泛应用的Kubernetes为例，K8S中的大部分概念如Node（除了集群管制节点Master外K8S集群中的其余机器）、Pod（容器）等能够被看作资源对象，简直所有资源对象都能够通过K8S提供的kubectl工具执行增、删、改、查等操作并将其保留在etcd中长久化存储，也就是说容器服务包含DOCKER、K8S等的全新设计模式天生就适宜于分布式服务架构。当然相比集群架构来说，在开发运维自动化程度的要求上也天然较高以确保对于容器可能进行有序而全局化的治理避免零碎呈现不可管制的状态。 2.2 《云原生架构白皮书》章节导读白皮书的第3章和第4章次要介绍的就是次要的云原生技术和阿里云原生架构设计的内容，其实外围的技术就是容器技术，在这个根底上包含微服务的理念、Serverless和Service Mesh等才可能被顺利的付诸于实际，而在容器技术中自动化程度又是一个重中之重，所以白皮书中数次提到的所有过程自动化准则就是是否施展云原生技术劣势的外围因素。 3 小结：云原生的将来倒退方向云原生毕竟是一个很大的概念，实践上所有从设计和开发之始就以部署在云上的设计理念都可能称为云原生，而微服务则是云原生在服务维度典型的表现形式，而容器服务即是可能将微服务胜利落地的核心技术。Serverless是一个技术也能够从字面意思了解为将来的倒退方向，核心理念依然是将非业务局部的性能下沉至基础设施，从这点上来说，现实中的Serverless甚至不用蕴含目前K8S中的集群容量布局、平安保护和故障诊断等性能，将这些集中思考为云基础设施所应该具备的性能，而功能模块只需思考本身的业务，充分体现出的是轻量，通过事件驱动将轻量的服务和服务间以及轻量服务和云平台之间连接起来，整个体系相比集群化部署来说，与其说是一个零碎，不如说是云基础设施根底上各类微服务造成的生态。 作者简介朱祺国内电气电子工程师协会IEEE高级会员、阿里云寰球MVP

-点击支付《云原生架构白皮书》- 导语： 有幸作为阿里云MVP提前取得了阿里云云原生团队编写的《云原生架构白皮书》，心愿通过本人对于云原生的了解为开发者提供一篇观后感或者是可能参考的博文。 1 云原生与分布式系统架构的关系1.1 云原生架构的定义《云原生架构白皮书》中对于云原生架构的定义为“基于云原生技术的一组架构准则和设计模式的汇合，旨在将云利用中的非业务代码局部进行最大化的剥离，从而让云设施接管利用中原有的大量非性能个性（如弹性、韧性、平安、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、麻利、高度自动化的特点。” 1.2 分布式系统架构的定义此处定义参考百度百科为“在一个分布式系统中，一组独立的计算机展示给用户的是一个对立的整体，就如同是一个零碎似的。零碎领有多种通用的物理和逻辑资源，能够动静的分配任务，扩散的物理和逻辑资源通过计算机网络实现信息替换。零碎中存在一个以全局的形式治理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件负责实现这个模型。” 1.3 云原生与分布式系统架构的关系分布式架构的重点在于解决计算力的保障问题以及为了进步计算力并同时确保零碎的可靠性、可用性和安全性而产生的诸如弹性伸缩、负载平衡、分布式存储等问题，其指标是在于构建一个分布式的安全可靠的计算力根底平台。通常来说，对于信息系统的架构形式的进化和扭转即是随同着接入数据和所提供的业务由少变多的过程，目前为止信息系统的架构经验了单机架构、集群架构、分布式架构、分布式多活数据中心架构几个阶段，同时随同着业务零碎架构一起演变的还有各种外围零碎和存储系统，比方关系数据库的分库分表革新、从本地缓存过渡到分布式缓存等。 要理清分布式架构和云原生的关系，先来演绎一下分布式架构与云之间的关系，云个别指的是一个提供资源的平台，云计算的实质是按需分配资源和弹性计算，而针对目前数据井喷并随着物联网利用的推动依然接入量在呈指数回升的现状下，分布式架构是最可能满足构建一个合格的云平台所应具备特质的架构形式。云原生利用即专门为在云平台部署和运行而设计的利用，采纳云原生的设计模式能够优化和改良传统利用模式，使利用更加适宜在云平台上运行，因而云原生倒退的实质需要来自于SAAS层面设计理念的改良，因为SAAS层的设计理念的改良而进一步从北向往南向推动了PAAS层特地是中间件的降级从而确保整个云平台的架构可能更好的服务于云原生架构的扭转。 因而，云原生和分布式架构的降级和迭代是一个滚动的过程，为了更好的施展云平台的特点而有了云原生的需要和设计模式扭转，而在这个过程中云原生也反过来促成了上层架构的降级。这个迭代的过程充沛的反馈了互联网或者说数据时代开发理念的特色，即滚动而非单向。 1.3 《云原生架构白皮书》章节导读通过《云原生架构白皮书》的第1章和第2章内容能够充沛的了解云原生的实质和云原生架构的特点，在浏览这两章的内容时举荐参考分布式架构的相干书籍，因为云原生和分布式架构密切相关，然而降级迭代的着力点又有所区别，所以可能联合在一起进行浏览是最好的。 2 云原生次要架构准则和技术剖析2.1 微服务和小零碎服务微服务架构，从宏观上来看，无非就是细化了服务拆分过程中的粒度，粒度越细，业务耦合越小，容错性就越好，并且前期扩大也会越容易。然而颗粒度过细，又会带来另外一些麻烦比方晋升了保护老本、影响排查问题时的效率、业务开发人员很难梳理分明服务之间的依赖关系等。 因而《云原生架构白皮书》在微服务相干章节中又提到了小零碎服务的概念，即是一个颗粒度的中间状态，其实外围就是一个服务拆分颗粒度的问题，白皮书中的第3章中有专门章节对于云原生微服务特地是微服务设计过程中的束缚做了具体介绍，基本目标就是使微服务的倒退处于一个受约束的状态，而不是因为有了微服务的理念就是服务拆分的颗粒度越细越好。 2.2 容器技术与云原生的关系 从白皮书中提供的比照图能够分明的发现，云原生在代码方面，对于代码通常所蕴含的三局部：业务代码、三方软件和解决非性能个性的代码进行剥离，最终想实现的现实状态是把所有非功能性代码（即除业务代码局部）从SAAS层剥离到PAAS层和IAAS层中去，当然目前还是没有齐全做到。剥离非性能代码依然是一个设计模式理念的变动，而在这个理念的落地过程中容器技术成为了最好的工具。 在白皮书中这张比照图的根底上，依据其余一些公开材料可能更清晰的反映出容器技术利用之后，云原生架构所产生的变动。 （单机架构） 注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师2.0》高翔龙著 电子工业出版社 （集群架构） 注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师2.0》高翔龙著 电子工业出版社 （服务化架构） 注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师2.0》高翔龙著 电子工业出版社 在这种架构形式下以被广泛应用的Kubernetes为例，K8S中的大部分概念如Node（除了集群管制节点Master外K8S集群中的其余机器）、Pod（容器）等能够被看作资源对象，简直所有资源对象都能够通过K8S提供的kubectl工具执行增、删、改、查等操作并将其保留在etcd中长久化存储，也就是说容器服务包含DOCKER、K8S等的全新设计模式天生就适宜于分布式服务架构。当然相比集群架构来说，在开发运维自动化程度的要求上也天然较高以确保对于容器可能进行有序而全局化的治理避免零碎呈现不可管制的状态。 2.2 《云原生架构白皮书》章节导读白皮书的第3章和第4章次要介绍的就是次要的云原生技术和阿里云原生架构设计的内容，其实外围的技术就是容器技术，在这个根底上包含微服务的理念、Serverless和Service Mesh等才可能被顺利的付诸于实际，而在容器技术中自动化程度又是一个重中之重，所以白皮书中数次提到的所有过程自动化准则就是是否施展云原生技术劣势的外围因素。 3 小结：云原生的将来倒退方向云原生毕竟是一个很大的概念，实践上所有从设计和开发之始就以部署在云上的设计理念都可能称为云原生，而微服务则是云原生在服务维度典型的表现形式，而容器服务即是可能将微服务胜利落地的核心技术。Serverless是一个技术也能够从字面意思了解为将来的倒退方向，核心理念依然是将非业务局部的性能下沉至基础设施，从这点上来说，现实中的Serverless甚至不用蕴含目前K8S中的集群容量布局、平安保护和故障诊断等性能，将这些集中思考为云基础设施所应该具备的性能，而功能模块只需思考本身的业务，充分体现出的是轻量，通过事件驱动将轻量的服务和服务间以及轻量服务和云平台之间连接起来，整个体系相比集群化部署来说，与其说是一个零碎，不如说是云基础设施根底上各类微服务造成的生态。 作者简介朱祺国内电气电子工程师协会IEEE高级会员、阿里云寰球MVP

为了让更多开发者开始用上 Arthas 这个Java 诊断神器，3 月 26 日，咱们联结 JetBrains 推出第一期 Arthas 有奖征文活动：聊聊这些年你和 Arthas 之间的那些事儿。 一石激起千层浪，在前三期流动期间咱们失去了泛滥开发者的积极响应，闻讯赶来投稿的同学川流不息，截止到当初，第三期征文活动已完结，通过层层筛选与评估，以下为第三期征文活动的获奖状况： 汪小哥冯富杰奖品阐明：以上同学将在 Arthas Most Valuable User 福袋（蕴含淘公仔、Arthas 贴纸、JetBrains 周边礼包）的根底上另送出蓝牙音响一台； 注：所有礼品将于开奖后 7 个工作日内收回，请急躁期待！ 举荐应用 Arthas形式一：举荐应用 IDEA 插件下载 Cloud Toolkit 来应用 ArthasCloud Toolkit 是阿里云公布的收费本地 IDE 插件，帮忙开发者更高效地开发、测试、诊断并部署利用。通过插件，能够将本地利用一键部署到任意服务器，甚至云端（ECS、EDAS、ACK、ACR 和 小程序云等）；并且还内置了 Arthas 诊断、Dubbo工具、Terminal 终端、文件上传、函数计算 和 MySQL 执行器等工具。不仅仅有 IntelliJ IDEA 支流版本，还有 Eclipse、Pycharm、Maven 等其余版本。 形式二：间接下载第四期征文活动开启第四期征文活动将于 7 月 28 日 - 8 月 28 日举办，后续征文活动将继续至 2020 年 12 月。参加即可拿奖，欢送大家持续踊跃投稿！ 3 步提交征文间接应用 Arthas 或通过 Cloud Tookit 体验 Arthas；将你的体验整顿成文章公布在掘金社区；按要求填写表单：http://alibabacloud.mikecrm.com/9khcRrs投稿文章要求字数 1000 字以上，文章层次结构及行文逻辑清晰；文章必须是原创；禁止公布广告类内容信息；禁止公布涉政、暴恐、违禁等敏感内容。你将取得的礼物凡提交满足投稿要求文章的同学，将取得 Arthas Most Valuable User 福袋一份（礼品随机），蕴含淘公仔、Arthas 贴纸、JetBrains 周边礼包；第四期最受欢迎的 top3 文章，将在福袋根底上另外取得蓝牙音响一台；年度 top 20 文章，将有机会取得 cherry 键盘及 JetBrains 提供的包含 Coupon 等周边礼包 。你将取得的荣誉除了实物处分之外，你还会取得： ...

为了让更多开发者开始用上 Arthas 这个Java 诊断神器，3 月 26 日，咱们联结 JetBrains 推出第一期 Arthas 有奖征文活动：聊聊这些年你和 Arthas 之间的那些事儿。 一石激起千层浪，在前三期流动期间咱们失去了泛滥开发者的积极响应，闻讯赶来投稿的同学川流不息，截止到当初，第三期征文活动已完结，通过层层筛选与评估，以下为第三期征文活动的获奖状况： 汪小哥冯富杰奖品阐明：以上同学将在 Arthas Most Valuable User 福袋（蕴含淘公仔、Arthas 贴纸、JetBrains 周边礼包）的根底上另送出蓝牙音响一台； 注：所有礼品将于开奖后 7 个工作日内收回，请急躁期待！ 举荐应用 Arthas形式一：举荐应用 IDEA 插件下载 Cloud Toolkit 来应用 ArthasCloud Toolkit 是阿里云公布的收费本地 IDE 插件，帮忙开发者更高效地开发、测试、诊断并部署利用。通过插件，能够将本地利用一键部署到任意服务器，甚至云端（ECS、EDAS、ACK、ACR 和 小程序云等）；并且还内置了 Arthas 诊断、Dubbo工具、Terminal 终端、文件上传、函数计算 和 MySQL 执行器等工具。不仅仅有 IntelliJ IDEA 支流版本，还有 Eclipse、Pycharm、Maven 等其余版本。 形式二：间接下载第四期征文活动开启第四期征文活动将于 7 月 28 日 - 8 月 28 日举办，后续征文活动将继续至 2020 年 12 月。参加即可拿奖，欢送大家持续踊跃投稿！ 3 步提交征文间接应用 Arthas 或通过 Cloud Tookit 体验 Arthas；将你的体验整顿成文章公布在掘金社区；按要求填写表单：http://alibabacloud.mikecrm.com/9khcRrs投稿文章要求字数 1000 字以上，文章层次结构及行文逻辑清晰；文章必须是原创；禁止公布广告类内容信息；禁止公布涉政、暴恐、违禁等敏感内容。你将取得的礼物凡提交满足投稿要求文章的同学，将取得 Arthas Most Valuable User 福袋一份（礼品随机），蕴含淘公仔、Arthas 贴纸、JetBrains 周边礼包；第四期最受欢迎的 top3 文章，将在福袋根底上另外取得蓝牙音响一台；年度 top 20 文章，将有机会取得 cherry 键盘及 JetBrains 提供的包含 Coupon 等周边礼包 。你将取得的荣誉除了实物处分之外，你还会取得： ...

简介： 请收下这份宝藏参会指南，肯定让你不虚此行！ 作为云原生畛域的顶级盛会，KubeCon 2020 线上峰会将于 7 月 30 日 - 8 月 1 日举办，汇集寰球当先开源社区和云原生社区的使用者和技术大咖，独特探讨云原生计算的将来和方向。自 2018 年 CNCF 于国内举办 KubeCon 以来，因 CNCF 生态广大，峰会亮点颇多，每年都会吸引来自寰球的上万名参会者，往年更是首次采纳全线上峰会的形式，全凋谢的高质量议题满天飞，是不是曾经看花眼了？ 如何疾速锁定云原生话题亮点？如何领先获知云原生技术趋势？如何玩转本届 KubeCon ？请收下这份宝藏参会指南，肯定让你不虚此行！ 第一步：锁定峰会入口，话题丰盛哪家强？为回馈宽广开发者，阿里云全程转播 KubeCon 2020 线上峰会的同时，首开“阿里巴巴云原生专场”，设立“Kubernetes 技术与实际论坛”、“微服务技术与实际论坛”、“Serverless 技术与实际论坛”，减少 AI 、边缘容器、Serverless 、Service Mesh、Spring Cloud、Knative、Nacos、运维、调度等云原生时下热门产品和技术，话题丰盛度名列前茅。 阿里云专场流动全天直播，27 个议题，37 位云原生专家，超过 780 分钟干货分享最新云原生热点话题！ 【KubeCon 2020 线上峰会-阿里云原生专场入口】：https://developer.aliyun.com/topic/alibabacloudnative/kubecon2020 第二步：预约前排席位，具体议程高深莫测话题太丰盛，热点满天飞，目迷五色的你如何疾速找到感兴趣的干货？在阿里云原生专场进行预约报名的同学，不仅能够参加抽奖，还可提前知悉阿里云全副具体议程。 第三步：课堂实战两不误，能入手才是真播种听的云里雾里，不如零碎学习；看的心潮澎湃，不如入手实际。 为了让宽广开发者失去“真播种”，阿里云原生专场上线公开课系列：《CNCF x Alibaba 云原生技术公开课》、《Serverless 技术公开课》、《微服务实战公开课》，入手实际系列：5分钟计算极速上手Serverless、容器镜像治理入门、3 分钟开发一个 Todo list、基于函数计算搭建线上商城，带你实现最佳学习实际。 第四步：三人行必有我师，与技术大咖同“群”竞技良师益友，是咱们成长途程中的最大助力。 为促成开发者互相学习与交换，阿里云上线了专属参会者的钉钉交换群，并邀请当日阿里云所有演讲者入群，与大家切磋技能，为大家实时答疑，并在会后持续保护成为阿里云原生与宽广开发者的交换窗口。 第五步：娱乐休息室，有礼有料更好玩有张有弛，学有所获，大略是最现实的学习气氛了。 流动之余咱们筹备了有料的福利，预约报名即可参加抽取阿里云定制马克杯，打卡游园支付优酷 VIP，关注阿里巴巴云原生公众号并发送“门票”即得福利门票！ 好玩又得好礼，轻松学有所获，阿里云心愿带给你一个满载而归的 KubeCon 2020！ ...

简介： 一项新技术或者一套新的技术理念，之所以能被宽泛承受和疾速倒退，是因为有违心置信并真正去落地实际的公司，是他们在为整个时代摸索着云计算更大的技术价值！正是因为这些创新者们违心接收一些新的扭转，并以此去撬动更大的设想空间，咱们才经验了一个如此蓬勃和充斥可能的时代。他们才是真的乘风破浪！ 作者：禾易 1、在线教育将成为常态化利用“还要扩容吗？” “先扩容 10 倍再说” 这曾经不是李诺（洋葱学院联结创始人兼 CTO）第一次提到扩容了。受到疫情影响，往年全国学校广泛延期开学。“复课不停学”，线下教育停摆，教育行业转阵线上。流量忽然暴涨，扩容成了“常态”，而且每次的流量还是远远超过预期。 李诺去找杨临风（洋葱学院联结创始人兼 CEO）探讨工作的时候，碰巧杨临风正在写一封给用户的公开信。这次疫情让洋葱学院受到了极大的关注，但比起流量价值，杨临风更想以本人的亲身经历通知用户：“在家自主地学习，是每个学生都要面对的战斗。” 李诺心里分明，在超高流量的冲击下要放弃服务器安稳、用户体验不受影响，这何尝不是一场属于洋葱学院的战斗。 2013 年 12 月，杨临风、朱若辰和李诺独特创建了洋葱数学（现已更名为洋葱学院），这家K12在线教育公司从初中数学课程切入，逐渐倒退到全学科，主攻人机交互学习的在线教育平台开发。他们从国家课标和教材着手，开始系统地构建在线课程体系，对课本上每一个知识点进行更加精密的教研和设计，并一一制作成5-8分钟的动画视频课程，围绕这些外围课程为学生打造个性化的学习体验。 人机交互学习的教育模式不要说在当年，即使是当初也很前卫。不仅如此，洋葱的开创团队在公司成立之初还做出了一个意识超前的决定：整套业务零碎均基于阿里云搭建。 洋葱学院的倒退速度在互联网教育公司里并不算快，李诺说，团队把大部分的精力都花在了课程的研发和学习体验的优化上，以初中数学为例，足足花了4年才实现课程的打磨。当然，洋葱学院对教育的这份保持，也让其在业界立下了一席之地。疫情影响下，短时间激烈增长的市场需求把在线教育推到了“快车道”。以前是在线教育企业本人致力，当初是全社会一起推动他们“品质在线”。 往年 1 月 28 日，洋葱学院对外颁布了针对疫情期间的课程捐献计划，把过来六年积攒制作的 2650 节外围课程全副收费凋谢，但流量的威力还是超过了他们的设想。据易观千帆的公开数据显示，洋葱学院 2020 年 2 月的沉闷用户规模达到了 795.92 万，同比增幅 151%。 面对大流量、高并发拜访需要，洋葱学院为了确保业务稳定性，在阿里云技术专家的倡议下，采纳了阿里云容器服务。容器服务能够依据不同模块的配置所需，资源分配更加正当，依照定义规定主动弹性伸缩防止了简单的调度保护。 阿里云容器服务能够在几分钟内裁减底层资源，满足疾速部署数千个利用实例的需要。为了更加从容地应答十倍扩容，洋葱学院还进一步优化了整体的 ECS 服务器配置，将大量的小规格 ECS 服务器更换成 30 至 50 核大规格 ECS，革新后运维管控也更加便捷。应用云容器之后，零碎在资源利用率上晋升了约60%，呈现问题后可疾速隔离，当面对急剧增长的业务量，也能够在短 工夫内扩容进行业务撑持。为了及早发现故障并疾速做出响应，洋葱学院也采纳了阿里云原生监控系列产品，能够笼罩到各类监控报警问题，极大地缩短问题发现工夫。 从2013年决定全面上云，到当初拥抱云原生新趋势，洋葱学院以一贯的超前意识，表白着这个时代互联网公司该有的态度。 2、全面应用开源技术、云服务构建软件服务的时代曾经到来云原生在近几年的倒退用“乘风破浪”来形容一点也不为过。 利用上云曾经是不可逆转的趋势。回顾近年来商业世界的发展趋势，数字化转型的呈现使得企业中越来越多的业务演变成数字化业务，数字化对于业务渠道、竞争格局、用户体验等诸多方面都提出更加严苛的要求，这就要求技术具备更快的迭代速度。 为了实现这样的速度，就须要充分利用云的弱小能力，从云技术中取得更高的可用性与可扩大能力，利用云来晋升公布和运维的效率。而要做到这些，不仅仅是基础设施和平台的变动，利用也须要做出扭转，摈弃传统的土办法，在架构设计、开发方式、部署保护等各个阶段和方面都基于云的特点来从新设计，从而建设全新的云化利用，即云原生利用。 2019 年，Gartner 已经公布报告示意云原生时代曾经到来，在将来三年中将有 75%的全球化企业将在生产中应用容器化的利用。云原生相干技术不仅仅能用于云计算，即使是和云计算既对抗又协同的边缘计算，微服务、容器、Kubernetes 仍然是事实上的杀手利用和规范。 2019 年，Gartner 已经公布报告示意云原生时代曾经到来，在将来三年中将有 75%的全球化企业将在生产中应用容器化的利用。云原生相干技术不仅仅能用于云计算，即使是和云计算既对抗又协同的边缘计算，微服务、容器、Kubernetes 仍然是事实上的杀手利用和规范。 以前一家企业想应用云原生的技术或产品，须要破费大量的精力钻研一些开源我的项目，本人做运维和治理，还须要思考集成、稳定性保障等问题，这样能力建设一个云原生平台。明天，为了不便企业和开发者更容易地应用云原生的技术和产品，更好地承受云原生的理念，并解决企业担心的可靠性、性能、连续性等问题，阿里云为大家提供了一整套云原生产品家族，提供了十分强的 SLA 保障。 阿里云在帮忙国内企业理解云原生、应用云原生上做了很多工作。一方面是在外部尝试去应用这些技术，阿里巴巴外部有十分丰盛的、大规模的应用场景，通过这些场景能够充沛打磨云原生技术。在技术成熟当前，将这些技术回馈到社区，帮忙云原生社区进步技术品质和倒退程度。 3、因为置信，所以看见着云计算的遍及与云原生的广泛应用，越来越多的从业者、决策者清晰地意识到「云原生化将成为企业技术创新的要害因素，也是实现企业数字化转型的最短门路」。因而，具备前瞻思维的互联网企业从利用诞生之初就扎根于云端，审慎的新批发、政府、金融、医疗等畛域的企业与机构也逐步将业务利用迁徙上云，深度应用云原生技术与云原生架构。 畅捷通是中国当先的小型微型企业治理云服务与软件提供商，为400多万小微企业提供智能云治理服务。随着业务的疾速倒退，为了适应互联网大型利用疾速迭代以及频繁公布的需要，畅捷通IT团队对原有的IT零碎进行了大量的微服务化革新，这是畅捷通进行云原生实际迈出的第一步。 紧接着，畅捷通开始迎接下一步挑战：SaaS化企业治理云服务，具备用户量大、业务简单、调用链路长、与第三方利用零碎深度集成等特点，给微服务化革新工作带来了十分大的挑战。特地是在新版本的公布过程中，如果不能保障整个流程平滑、可控，就很容易因为单个利用的更新而造成整个零碎的解体。 ...

联席作者：吴毅挺 任浩军 张彬彬 廖梦鸽 张金星 胡振建 郑重鸣谢：Nacos - 彦林，Spring Cloud Alibab - 小马哥、落夜，Nacos 社区 - 张龙（pader）、春少（chuntaojun） 前言在高速倒退的时候，公司规模越来越大，老师人数越来越多，这时候公司不能铺太多人去做经营与服务，必须进步每个人效，这就须要技术驱动。因而掌门教育转变成一家技术驱动型的公司，如果被迫成为一家靠资金驱动的公司就活不下去了。 -- 张翼（掌门教育创始人兼 CEO）掌门教育自 2014 年正式转型在线教育以来，秉承“让教育共享智能，让学习高效高兴”的主旨和愿景，经验云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ，始终保持用科技赋能教育。掌门教育的业务近几年失去了疾速倒退，特地是往年的疫情，使在线教育成为了新的风口，也给掌门教育新的时机。 随着业务规模进一步扩充，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采纳的注册核心 Eureka 不堪重负，同时 Spring Cloud 体系曾经演进到第二代，第一代的 Eureka 注册核心曾经不大适宜当初的业务逻辑和规模，同时它目前被 Spring Cloud 官网置于保护模式，将不再向前倒退。如何抉择一个更为优良和实用的注册核心，这个课题就摆在了掌门人的背后。通过对 Alibaba Nacos 、HashiCorp Consul 等开源注册核心做了深刻的调研和比拟，最终选定 Alibaba Nacos 做微服务体系 Solar 中的新注册核心。 背景故事1. 掌门教育微服务面临的挑战1）第一次生产事变2020 年疫情暴发后的几个月后，掌门教育的微服务实例数比去年猛增 40% ，基础架构部乐观的认为注册核心 Eureka 服务器能够抗住该数量级的实例数规模， Eureka 服务器在阿里云 PROD 环境上执行三台 8C16G 普通型机器三角结构型对等部署，运行了好几年都始终很稳固，但劫难还是在2020年3月某天早晨来临，当天早晨大略 9 点 30 分左右，其中两台 Eureka 服务器无征兆的 CPU 占用迅速回升到100%，同时大量业务服务掉线，告警零碎被触发，钉钉机器人告警和邮件告警铺天盖地而来。基础架构部和运维部紧急重启 Eureka 服务器，但没多久，CPU 仍旧没抗住，而且更加来势凶猛，关上的文件描述符数霎时达到 8000+ ，TCP 连贯达到 1 万+ ，业务服务和 Eureka 服务器的通信产生大面积的 TCP CLOSE_WAIT 事件，且伴有大量 Broken pipe 异样。 ...

作者 | 磊之 不愿沟通是执著，不会沟通是傻瓜，不敢沟通是奴隶。——德拉蒙德 工作中，你是否常常看到他人在会上谈笑自若、纵横捭阖，但本人却气宇轩昂，不敢表白观点？即使鼓起勇气发言却不被器重，常常被人打断？生存中，你提出个很好的家庭布局，却没人反对你？奉劝本人的亲友却被误会，最初以吵架开场？ 当你的敌人指出你的问题可能在“沟通”能力上时，你却轻蔑一笑：“沟通这么简略事件，我会不懂？” 要晓得许多巨匠花了一辈子钻研“沟通”，最终感觉本人只能驾驭一些类型的沟通。 互联网时代的信息媒介很发达，但十分碎片化，你可能听过很多情理，但未必无意识地组织过，人脑对于没有体系化的观点，总会选择性忘记。 所以，对于沟通，你可能须要从新思考。 真谛的世界如同泥泽地个别充斥了陷阱。建立一个清晰的“概念”好比在这片泥泽地里打桩，建立一个“实践”好比在这些木桩上架桥。 PART 1：沟通的定义？ 街头的大妈们家长里短地唠嗑，能不能叫“沟通”？大学课堂上传授缄口结舌，滔滔不绝地讲课，能不能叫沟通？ 沟通是“有目标的多向信息交换”。大妈聊天漫无目的，最多是“多向信息交换”，不是“沟通”；传授解说虽有目标，但如果没有与学生互动，则也不算是“沟通”。 “沟通的形式肯定是谈话么”？不是，能交流信息即可，不拘泥于模式。沟通齐全能够借助文字、图片、音乐......比方写信、发邮件，甚至眼神交换也算，宋词中“执手相看泪眼，竟无语凝噎”，这里的“执手相看泪眼”，就是“为了表白感情的双向信息交换”，也是一种沟通。 之所以肯定要死板地界定沟通的意义，是因为这太重要了。在沟通过程中要时刻无意识地揭示本人： 沟通是有目标的：你的初衷是什么？你当初的行为和语言有没有障碍你实现你的初衷？沟通是多向信息交换：你有让对方get到你的实在想法么？你get到对方的实在想法了么？一次胜利的沟通，有什么样的特点呢？ 从情绪体验和信息匹配的维度上，能够把沟通划分成四个区域：  刺激区：刺激区的情绪体验好，但信息统一度不高。这可能是沟通的启动状态，或者沟通外表谐和，但大家相互打哈哈，没在深层次上达成共识；目标区：这是冀望达到的状态；毁坏区：十分蹩脚的情景，没达成任何共识，且局面非常不谐和：争吵强烈，或者罗唆缄默、冷暴力；危险区：共识达成，但人际关系变差的情景。尽管达成了共识但最终因团队无奈齐心合作而难以执行。看看本人的沟通在哪个区域散布最多，就能够给本人的沟通能力打分了。 PART 2：沟通的作用 人类是社会动物，人与人、人与群体通过“沟通”传递信息和情感。沟通的作用有如下几点： 获取或传递信息和常识促成统一观点或协定情感治理这种分类并不合乎“mece”法令，而是互有穿插的，也即一次沟通的作用可能有多条。 Eg：你跟一个女孩一起喝咖啡，碰巧被你女朋友晓得了。你筹备找她沟通，修复关系。在这次沟通中，你要获取信息（她看到了什么？她当初什么想法？），你也要向女友传递信息（女孩是谁？为什么与你约会？），之后你要情感治理（表白你对女友的真心，并冀望失去他的体谅），最初你们也可能达成一些“独特观点和协定”（独特观点：与女孩喝咖啡是为了聊工作，没有劈腿。或者独特协定：当前跟其余女生独自约会要报备......）。 PART 3：沟通的办法 这里提供两个方法论，第一个“周哈里窗”模型。第二个“螺旋推动”模型。  “周哈里窗”模型偏重强调信息的共享的重要性，并用图示的办法清晰的表白这种偏向；“螺旋推动”模型偏重沟通的流程，是一个齐备的沟通框架。 “周哈里窗”依据信息是否被“我”晓得，以及是否被“对方”晓得，分成四个区域： 公众区：我晓得且对方也晓得的信息比方上述例子中信息“我与女孩喝咖啡”，这个信息我晓得，我女朋友也晓得，属于“公众区”。 隐私区：我晓得的但对方不晓得的信息上述例子中信息“女孩是我共事，我正与她交接工作”，则可看成是隐衷区的信息。 盲点区：我不晓得但对方晓得的信息上述例子中如果“女友看到了十分怄气，联想到我这个星期微信聊天对她有点淡漠，十分不开心”，那么这个信息女友晓得，我不晓得，属于“盲点区”的信息。 黑洞区：我跟对方都不晓得的信息如果“喝咖啡的女孩始终暗恋我”。这个信息我与女朋友都不晓得，则属于“黑洞区”。 ok，咱们界定分明了基本概念，那么这个“周哈里窗”到底有啥用呢？ 周哈里窗模型认为沟通的要害是要“拓展公众区的信息”。比方，事件产生了，男生肯定要把隐衷区的信息“女孩是我共事，我正与她交接工作”向女友传播分明，并使她置信，而女生也要把盲点区的信息“看到了十分怄气，联想到我这个星期微信聊天对她有点淡漠，十分不开心”这个信息传递给我，这样咱们才可能打消误会。说来简略，但之后的情节可能是这样的：  我没解释清这个女孩只是与我交接工作，女友暴跳如雷......女友没有通知她怄气还因为“这个星期微信聊天我对她有点淡漠”，那么我即使解释分明喝咖啡的事件也是徒劳的......哎，坑好多。光靠这个窗还不行啊。因为周哈里窗只通知你要做到什么，但没通知你具体怎么做到啊。 一个能够领导咱们沟通流程的框架——“螺旋推动”模型，是时候出场了。 是不是有点纳闷？ “平安气氛”是什么，咱大老爷们还提“平安”，丢不丢人？“监控器”指的难道是要我装个摄像探头？“共识线”、“情感线”，是两根什么“线”？ “平安气氛”，指的是要让整个沟通过程中你与对方都领有“安全感”，这是沟通的前提条件。为此你要体现出对对方足够的尊重，并让对方感觉你是一个值得信赖的人，当你开始沟通时，你会无意识揭示本人留神气氛，但一旦聊到正题局部，你就很难时刻放弃对“平安气氛”的感知和把控。 比方，因为你一个继续 0.5 秒的“不屑的眼神”，对方霎时感到：“你方才体现进去对我的尊重都是装的，你心田看不起我。”他很可能失去了“安全感”，进入“戒备状态”...... 所以，“时刻放弃对你们沟通的监控”十分重要。怎么造成这种意识呢？这里就要说到神奇的“监控器”了。 “监控器”不是要你真装一个摄像头，这么说齐全是为了帮忙了解。试着设想一下，如果有一个十分牛逼的监控器在全程监控你们的沟通，你们的沟通遇到问题进行不上来时，你能够随时暂停沟通，通过监控器看到从开始沟通到当下你与对方沟通的所有情景（包含语言、表情和动作），置信你肯定会有新的思路： 当你感觉对方冥顽不灵而感到非常愤恨，且马上要发生的时候，监控器“BBBB”发出声响，从监控器中你看到一个气急败坏，马上要暴发的本人，你忽然意识到：“沟通是有目标的，局面一旦失控，就 game over了”。当对方曾经屡次回避你的问题，顾左右而言他时，监控器持续“BBBB”发出声响，从监控器中你看到对方“眼神闪动，眼光游离，欲言又止的情景”时，你意识到方才才讲的沟通要“多向信息交换”，他显然没敞开心扉交换啊，我应该先想方法让他放下警戒，说出本人的实在想法，能力推动胜利的小船驶向后方啊。当然，监控器是一个只存在你脑海里的假想物，它给了你一个上帝视角，让你主观、全局地扫视“你们的这次沟通”，沟通问题的端倪呈现时，你能第一工夫发现，而不是等到“局面失控”“对方回绝沟通”的状况产生时才意识到。 “共识线”“情感线”是存在于沟通过程中的两条推动线路，胜利的沟通必然让这两条线路共存，无论是“共识线”还是“情感线”产生问题时，都要用“螺旋推动”的形式，解决问题，而不是二愣子一样拼命往前冲。 基本概念理分明了，那么“螺旋推动”模型具体步骤是什么呢? 咱们解读一下，“螺旋推动”共有5个步骤：构建平安气氛、构建独特指标、剖析以后问题、交换解决方案、最初协定。 1. 构建平安气氛如前文所言，平安气氛是沟通的前提，沟通前先要确保单方平心静气，违心敞开心扉。如果你有问题在先，对方很可能处于消极反抗的状态，此时不要焦急跟对方解释，也不要抱怨对方，而是先让 ta 置信：你很在意 ta 的想法，这次沟通你是带着非常的诚意来的，不会敷衍了事。待 ta 心绪平静下来时，再往下推动。 2. 构建独特指标这时要让 ta 感觉“你们有独特的指标，沟通胜利对单方都无利”。以下列举了一些雷区： 雷区 1：越过第二步，间接进入第三步剖析问题，这会让对方对你的动机产生狐疑，剖析问题时，他就会有所保留，并在过程中一直试探你的实在动机。如果从“周哈里窗”模型的角度看，此时你无奈获取“盲点区”的信息（对方晓得而你不晓得的信息），“公众区”无奈更多地被拓展，沟通短少品质。 ...

作者 | 禾易 在第十五届“开源中国开源世界”高峰论坛上，阿里云资深技术专家、etcd 创始人、CNCF TOC 李响荣获 2020 中国开源杰出人物贡献奖。祝贺李响！ 去年，寰球顶级开源社区云原生计算基金会 CNCF 正式发表其技术监督委员会席位改选后果。阿里云资深技术专家李响入选，成为该委员会有史以来首张中国脸孔。 李响是 CoreOS 最晚期的工程师之一，参加创立了 etcd、operator framework、rkt 等开源我的项目。而在开源社区中，李响作为 etcd 作者被开发者所熟知，etcd 是国内出名且被最为宽泛应用的分布式一致性存储系统，被阿里巴巴、腾讯、华为、腾讯、微软、谷歌、VMWare 等企业在生产环境和客户产品中应用，用来解决分布式系统中重要元信息存储、治理和备份的问题，以及分布式系统组件一致性协调的问题。 在退出阿里云后，李响始终在推动云原生畛域自动化运维相干理念、Operator 概念、OAM 规范的建设。Operator 给予开发和运维人员在云原生平台构建无状态和简单利用运维的实践规范和实际根底，大幅度提高了云原生运维平台的覆盖度，在开源生态中涌现出了超过 500 个 Operator 具体实现，笼罩了简直所有的支流云原生软件的运维，其中蕴含 RocketMQ、Kafka、ZooKeeper、Consul、Argo、Kubeflow 等。这些理念深度影响了云原生畛域的倒退。 在第十五届“开源中国开源世界”高峰论坛上，阿里云资深技术专家、etcd 创始人、CNCF TOC 李响荣获 2020 中国开源杰出人物贡献奖。 对于国内外开源的停顿以及云原生实际的倒退，咱们找李响聊了聊他的认识。 开源，从“应用”到“融入”开源在近些年的热度始终居高不下。所谓开源，就是将软件的源代码公开，容许所社区成员对其进行修改、改良和翻新，并将其成绩与社区内的所有成员共享。除了开发者以集体的身份参加开源之外，企业也在加大力度参加开源软件的研发。 李响提到，开源的融入应该是一个循环：应用 - 发现问题/做了新性能 - 提交代码给我的项目 - 更多人用。 目前国内开源的倒退更多停留在应用阶段，在适合的场景应用开源技术来解决一些业务问题。一个比拟好的趋势是，国内对于开源技术的认可度逐步进步，参加开源的企业和开发者也逐年减少。阿里巴巴也在踊跃推动一些先进的开源理念的落地，比方云原生。李响提到，如果国内一些思想前卫的开发者违心花工夫与精力去实际云原生，并一直与国外的技术思维去碰撞，那么咱们就可能对云原生社区的倒退产生一些影响力，从而有资格来引领云原生技术的倒退方向。“其实中国的开发者齐全有能力参加到开源我的项目的过程中，并且去影响开源我的项目。” 还有一种趋势是，国内一些基于开源技术去构建技术体系的厂商越来越多。这些厂商不单单是像以前一样售卖开源技术，而是本人构建或者尝试去构建开源生态，并在国内和国外去推广。以前在 OpenStack 刚进去的时候，有很多厂商基于 OpenStack 这项技术进行包装、集成、售卖。国内一些 to B 的厂商也采纳了类似的思路，比方倒退较好的 PingCAP。此外，一些初创公司也无意识地去打造开源技术并推广开源技术，这也是国内对于开源态度的一个转变。 当然，国内开源的倒退还有一些须要晋升的中央。李响提到，一方面，国内的开发者应该更踊跃地参加到整个开源社区的建设中，不仅仅是技术建设，有时候思维碰撞也很重要。咱们要做的不仅是给开源我的项目提一些短期的问题，或者帮忙开源我的项目修复Bug，而是要为更长线的工作做筹备。只有融入到社区中，能力给到社区更具体明确的需要，帮忙开源社区的倒退，甚至影响开源社区的将来方向。 对于参加开源的企业而言，不论是守业公司，还是云厂商，可能从 0 到 1 去做一些开源我的项目，并尝试去做一些创新性的、先进性的我的项目，把国内在开源社区和先进生产力上的影响力发扬光大，甚至去打造一些国内出名的开源品牌，能力真正融入到开源的倒退过程中。 当然，开源的世界里也有一套本人的玩法。 ...

2020 年 7 月 21 日，由阿里云 20+ 位云原生技术专家独特编撰的《云原生架构白皮书》正式对外公布。作为业界首本全方位构建云原生架构布局与实际全景图的白皮书，本书在具体论述云原生架构定义的同时，残缺展现云原生架构利用所需的演进门路与设计规定，旨在帮忙企业更好地了解与利用云原生架构，助力企业数字化转型降级。 <关注阿里巴巴云原生公众号，回复 白皮书 即可下载本书> 阿里云智能根底产品事业部高级研究员蒋江伟示意，“阿里云原生架构教训来自于过来数年理论场景的积攒，这些教训能够帮忙不同企业系统化解决所面挑战，在本书的加持下，企业能够更大幅度的晋升架构灵活性，升高大流量型业务的研发老本和技术门槛，也让架构具备更高的可用性。”面对“如何将云技术更好地跟各行业业务相结合”这一难题，阿里云在总结本身实践经验的同时，踊跃与各行业架构师、开发者独特探讨、提炼更加贴合行业场景，满足业务所需的云原生架构。 在本书筹备期间，阿里云发动“独特定义”云原生架构的倡导，收集了诸多架构师、开发者眼中的云原生及云原生架构的定义与思考，将之提炼并融入书中。本书涵盖了云原生架构的产生原因、阿里云对于云原生架构的定义、目前行业当先的云原生技术、阿里巴巴的云原生架构设计、云原生架构的实际案例、云原生架构将来发展趋势等内容。心愿这本与架构师、开发者独特定义的《云原生架构白皮书》，可能帮忙公众进一步了解云原生及云原生架构，找到适宜本身业务的最佳云原生路线。 从“压迫感”到“掌控感”的力量转变 在云计算高速倒退的时代背景下，领会到数字化业务竞争所带来的强烈“压迫感”后，大量企业纷纷走上数字化转型之路。数字化转型使企业中大量原有业务不得不开始数字化演进。然而，数字化转型对业务构造、技术储备、用户体验等都有更为严苛的要求，要求技术具备更快的迭代速度与更灵便的敏捷性，业务上线速度从按周计时，缩短到小时级别；每个月上线业务量从“几十个/月”晋升到“几百个/天”。 云时代下，企业须要新技术架构，使之更好地利用云计算劣势，让业务更麻利、老本更低、可伸缩性更强。而云原生架构的利用意义正在于此。数据显示，2020 年，超过 50% 的寰球组织在生产环境中运行容器化应用程序，到 2022 年将超过 75% 。在中国，截止到 2018 年底，已有 96% 的IT企业在生产环境部署容器化利用。云原生正逐渐成为企业数字化转型的“最短门路”。 以后，不同企业在不同技术倒退阶段对于云原生架构的认知不尽相同，这导致企业建设云原生架构的摸索老本不同水平的减少，甚至数字化转型的早夭。明天，阿里云依据本身积攒多年的云原生技术、产品和上云实际，提出残缺云原生架构的设计准则、解决方案以及最佳实际，帮忙企业找到数字化转型“最短门路”，实现从“压迫感”到“掌控感”的主被动力量转变，减速实现 IT 能力晋升，打好降本增效组合拳。 多维度评估业务云原生架构成熟度 为了扭转行业/企业在云时代利用落地过程中蒙眼摸索的场面。阿里云在本书中明确了云原生架构定义：从技术的角度，云原生架构作为基于云原生技术的架构准则与设计模式的汇合，旨在将云利用中的非业务代码局部进行最大化剥离，让云设施接管利用中原有的大量非性能个性（如弹性、韧性、平安、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、麻利、高度自动化的个性。 值得一提的是，为了进一步帮忙企业落地云原生架构，阿里云以本身实际以及大量客户服务教训为外围，造成独有的云原生架构设计办法——ACNA（Alibaba Cloud Native Architecting）。ACNA 作为 「4+1 」架构设计流程，「 4」 代表架构设计要害视角，包含企业策略视角、业务倒退视角、组织能力视角和云原生技术架构视角；「1」 代表云原生架构继续演进闭环，并提出云原生架构成熟度模型帮忙企业评估业务段云原生成熟度。 ACNA将云原生化宰割成服务化能力（Service）、弹性能力（Elasticity）、无服务器化水平（Serverless）、可观测行（Observability）、韧性能力（Resilience）、自动化程度（Automation）六个不同维度（SESORA），每个评估维度设立ASNA-1至ASNA-4 四个不同等级并顺次计作0至3分，同时设立零级、根底级、倒退级、成熟级四个不同成熟等级。云原生架构成熟度模型的提出，对企业云原生化现状、能力和倒退门路不清晰等问题, 给出评估与优化方向，帮忙企业走上数字化转型“最短门路”。 可参考、可落地的云原生解决方案 云计算从概念产生到落地利用，已走过 15 个年头，大量利用的“用云”形式仍停滞在传统IDC时代，但“能用”和“好用”有着天壤之别，越来越多企业投身大量精力于云原生化，以寻求“好用”办法，开释技术红利。基于云原生架构的利用，从架构设计、开发方式到部署运维的整个软件生命周期都基于云的特点设计，最大限度用好云平台的弹性、分布式、自助、按需等劣势。很多互联网企业从利用诞生之初就成长在云端，新批发、政府、金融、医疗等畛域的企业和机构也逐步将业务利用迁徙上云，深度应用云原生技术和云原生架构。 白皮书通过几个典型实际案例，展现了企业如何通过云原生架构及相干利用解决交付周期长、资源利用率低等常见运维问题。比方，借助阿里云实现外围业务零碎云原生化的申通快递，全面实现对千万级订单量、数亿级物理物流轨迹、每日上T级数据量的全力支持；采纳阿里云原生利用稳定性解决方案的完满日记，无效确保“双11”电商大促、“双12”购物节的微商城零碎稳定性，极大进步用户购物体验；采纳了阿里云原生PaaS平台的中国联通号卡利用，开卡业务效率晋升了10倍，需要响应工夫缩短了50%，撑持访问量由1000万回升至1.1亿等等。 从 IT 基础设施云化到零碎架构云原生化，是云计算的终极演进方向。将来，企业应用将都会打上“Made in Cloud ”的出厂标签，云原生利用也将会成为企业打造外围竞争力的重要抓手。阿里云智能根底产品事业部研究员丁宇示意，“将来十年，云计算将无处不在，像水电煤 一样成为数字经济时代的基础设施，云原生让 云计算变得规范、凋谢、简略高效、触手可及。 如何更好地拥抱云计算、拥抱云原生架构、用 技术减速翻新，将成为企业数字化转型升级成 功的要害。” 点击中转云原生架构白皮书详情页 “阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际，做最懂云原生开发者的公众号。”

作者 | 不瞋 阿里云高级技术专家 导读：用户需要和云的倒退两条线推动了云原生技术的衰亡、倒退和大规模利用。本文将次要探讨什么是云原生利用，形成云原生利用的因素是什么，什么是 Serverless 计算，以及 Serverless 如何简化技术复杂度，帮忙用户应答疾速变动的需要，实现弹性、高可用的服务，并通过具体的案例和场景进行阐明。 现在，各行各业都在谈数字化转型，尤其是新批发、传媒、交通等行业。数字化的商业状态曾经成为支流，逐步代替了传统的商业状态。在另外一些行业里（如工业制作），尽管企业的商业状态并非以数字化的模式体现，然而在数字孪生理念下，充分利用数据科技进行生产经营优化也正在成为钻研热点和行业共识。 企业进行数字化转型，从生产资料、生产关系、战略规划、增长曲线四个层面来看： 生产资料：数据成为最重要的生产资料，需要/危险随时变动，企业面临微小的不确定性；生产关系：数据为核心，非基于流程和规定的固定生产关系，网络效应令生产关系逾越时空限度，多连贯形式催生新的业务和物种；战略规划：基于数据决策，疾速应答不确定的商业环境；增长曲线：数字化技术带来触达海量用户的能力，可带来突破性的增长。从云服务商的角度来看云的演进趋势，在 Cloud 1.0 时代，基础设施的云化是其主题，采纳云托管模式，云上云下的利用放弃兼容，传统的利用能够间接迁徙到云上，这种形式的外围价值在于资源的弹性和老本的低廉；在基础设施提供了海量算力之后，怎么帮忙用户更好地利用算力，减速企业翻新的速度，就成为云的外围能力。 如果仍在服务器上构建根底利用，那么研发老本就会很高，治理难度也很大，因而有了 Cloud 2.0，也就是云原生时代。在云原生时代，云服务商提供了丰盛的托管服务，助力企业数字化转型和翻新，用户能够像搭积木一样基于各种云服务来构建利用，大大降低了研发老本。 云原生利用因素云原生利用有三个十分要害的因素：微服务架构，利用容器化和 Serverless 化，麻利的软件交付流程。 1. 微服务架构单体架构和微服务架构各有各的特点，其次要特点对比方下图所示。总的来说，单体架构上手快，然而保护难，微服务架构部署较难，然而独立性和敏捷性更好，更适宜云原生利用。 单体架构 VS 微服务架构 2. 利用容器化和 Serverless 化容器是以后最风行的代码封装形式，借助 K8s 及其生态的能力，大大降低了整个基础设施的治理难度，而且容器在程序的撑持性方面提供十分杰出的灵活性和可移植性，越来越多的用户开始应用容器来封装整个利用。 Serverless 计算是另外一种状态，做了大量的端到端整合和云服务的集成，大大提高了研发效率，然而对传统利用的兼容性没有容器那么灵便，然而也带来了很大的整洁性，用户只须要专一于业务逻辑的编码，聚焦于业务逻辑的翻新即可。 3. 麻利的利用交付流程麻利的利用交付流程是十分重要的一个因素，次要包含流程自动化，专一于性能开发，疾速发现问题，疾速公布上线。 Serverless 计算1. 阿里云函数计算Serverless 是一个新的概念，然而其外延早就曾经存在。阿里云或者 AWS 的第一个云服务都是对象存储，对象贮存实际上就是一个存储畛域的 Serverless 服务；另外，Serverless 指的是一个产品体系，而不是单个产品。以后业界云服务商推出的新性能或者新产品绝大多数都是 Serverless 状态的。阿里云 Serverless 产品体系包含计算、存储、API、剖析和中间件等，目前云的产品体系正在 Serverless 化。 阿里云 Serverless 计算平台函数计算，有 4 个特点： 和云端无缝集成：通过事件驱动的形式将云端的各种服务与函数计算无缝集成，用户只须要关注函数的开发，事件的触发等均由服务商来实现；实时弹性伸缩：由零碎主动实现函数计算的弹性伸缩，且速度十分快，用户能够将这种能力用在在线利用上；次秒级计量：次秒级的计量形式提供了一种齐全的按需计量形式，资源利用率能达到百分之百；高可用：函数计算平台做了大量工作帮忙用户构建高可用的利用。那么，阿里云函数计算是如何做到以上 4 点呢？阿里云函数计算的产品能力大图如下图所示，首先函数计算产品是建设在阿里巴巴的基础设施服务之上的产品，对在其之上的计算层进行了大量优化。接着在应用层开发了大量能力和工具，基于以上产品能力，为用户提供多种场景下残缺的解决方案，才有了整个优良的函数计算产品。函数计算是阿里云的一个十分根底的云产品，阿里云的许多产品和性能均是建设在函数计算的根底上。目前阿里云函数计算曾经在寰球 19 个区域提供服务。 阿里云函数计算产品能力大图 2. Serverless 帮忙用户简化云原生利用高可用设计、施行的复杂度云原生利用的高可用是一个零碎的工程，包含泛滥方面，残缺的高可用体系构建须要很多工夫和精力。那么 Serverless 计算是如何帮忙用户简化云原生利用高可用设计、施行的复杂度呢？ 如下图所示，高可用体系建设要思考的点包含基础设施层、运行时层、数据层以及应用层，且每一层都有大量的工作要做才能够实现高可用。函数计算次要是从容错、弹性、流控、监控四方面做了大量工作来实现高可用，下图中蓝色虚线框所对应的性能均由平台来实现，用户是不须要思考的。蓝色实线框尽管平台做了一些工作来简化用户的工作难度，然而仍须要用户来进行关注，而橘红色的实线框代表须要用户去负责的局部性能。联合平台提供的性能和用户的局部精力投入，能够极大地加重用户进行高可用体系建设的难度。 ...

简介： 去年，寰球顶级开源社区云原生计算基金会CNCF正式发表其技术监督委员会席位改选后果。阿里云资深技术专家李响入选，成为该委员会有史以来首张中国脸孔。 李响是 CoreOS 最晚期的工程师之一，参加创立了 etcd、operator framework、rkt 等开源我的项目。而在开源社区中，李响作为 etcd 作者被开发者所熟知，etcd 是国内出名且被最为宽泛应用的分布式一致性存储系统，被阿里巴巴、腾讯、华为、腾讯、微软、谷歌、VMWare 等企业在生产环境和客户产品中应用，用来解决分布式系统中重要元信息存储、治理和备份的问题，以及分布式系统组件一致性协调的问题。 在退出阿里云后，李响始终在推动云原生畛域自动化运维相干理念、Operator概念、OAM 规范的建设。Operator 给予开发和运维人员在云原生平台构建无状态和简单利用运维的实践规范和实际根底，大幅度提高了云原生运维平台的覆盖度，在开源生态中涌现出了超过500个 Operator 具体实现，笼罩了简直所有的支流云原生软件的运维，其中蕴含 RocketMQ、Kafka、ZooKeeper、Consul、Argo、Kubeflow等。这些理念深度影响了云原生畛域的倒退。 对于国内外开源的停顿以及云原生实际的倒退，咱们找李响聊了聊他的认识。 一、开源，从“应用”到“融入”开源在近些年的热度始终居高不下。所谓“开源”（Open Source），就是将软件的源代码公开，容许所社区成员对其进行修改、改良和翻新，并将其成绩与社区内的所有成员共享。除了开发者以集体的身份参加开源之外，企业也在加大力度参加开源软件的研发。 李响提到，开源的融入应该是一个循环：应用 - 发现问题/做了新性能 - 提交代码给我的项目 - 更多人用。 目前国内开源的倒退更多停留在应用阶段，在适合的场景应用开源技术来解决一些业务问题。一个比拟好的趋势是，国内对于开源技术的认可度逐步进步，参加开源的企业和开发者也逐年减少。阿里巴巴也在踊跃推动一些先进的开源理念的落地，比方云原生。李响提到，当一些思想前卫的开发者违心花工夫与精力去实际云原生，并一直与国外的技术思维去碰撞，那么咱们就可能对云原生社区的倒退产生一些影响力，进而去引领云原生技术的倒退方向。“其实中国的开发者齐全有能力参加到开源我的项目的过程中，并且去影响开源我的项目。” 还有一种趋势是，国内一些基于开源技术去构建技术体系的厂商越来越多。这些厂商不单单是像以前一样售卖开源技术，而是本人构建或者尝试去构建开源生态，并在国内或国外去推广。以前在OpenStack刚进去的时候，有很多厂商基于OpenStack这项技术进行包装、集成、售卖。国内一些to B的厂商也采纳了类似的思路，比方倒退较好的PingCAP。此外，一些初创公司开始去打造开源的技术和推广开源技术，这也是国内对于开源态度的一个转变。 当然，国内开源的倒退还有一些须要晋升的中央。李响提到，一方面，国内的开发者应该更踊跃地参加到整个开源社区的建设中，不仅仅是技术建设，有时候思维碰撞也很重要。咱们要做的不仅是给开源我的项目提一些短期的问题，或者帮忙开源我的项目修复Bug，而是要为更长线的工作做筹备。只有融入到社区中，能力给到社区更具体明确的需要，帮忙开源社区的倒退，甚至影响开源社区的将来方向。 对于参加开源的企业而言，不论是守业公司，还是云厂商，可能从0到1去做一些开源我的项目，并尝试去做一些创新性的、先进性的我的项目，把国内在开源社区和先进生产力上的影响力发扬光大，甚至去打造一些国内出名的开源品牌，能力真正融入到开源的倒退过程中。 当然，开源的世界里也有一套本人的玩法。 二、对于开源治理前段时间，谷歌将Istio我的项目商标的所有权正式移交至Open Usage Commons（OUC）。承受Istio后，OUC将与我的项目领导委员会独特制订商标使用指南，不便社区对立应用Istio我的项目商标。此举引发了业界强烈的探讨，作为CNCF TOC，李响谈了谈他对这一事件的了解。 开源能够从三个局部来了解，第一局部是代码的凋谢，就是让大家能够看到并且批改代码。这是任何一家公司开源我的项目要做的最根底的事件。第二局部是开源工作中波及的品牌和专利，把这部分工作凋谢，让品牌从属于一个中立的组织，这样其余厂商或者用户应用的时候，不会受到专利的限度，也没有品牌的担心。 第三局部是治理模型的凋谢，治理模型的凋谢意味着每一个我的项目都有一个治理组织，对开源我的项目做出肯定奉献或者达到某种规范，就被容许退出到治理组织中，对开源我的项目的将来倒退领有肯定的话语权和决策权。举个例子，阿里巴巴明天开源了一个我的项目X，最开始参加投票的5集体都来自于阿里巴巴，假如有一天阿里巴巴的奉献缩小了，B公司的奉献减少了，那么B公司就有权力去推动这个开源我的项目的治理，进而管制它的走向。比方Redis我的项目近期放弃之前的独裁管理模式，转而采纳新的“社区自治模式”。这意味着 Redis 我的项目的将来命运将由整个社区决定，而不再单纯把握在 Sanfilippo（Redis之父） 一个人手中。 谷歌把品牌和专利移交给OUC，让品牌从属于一个中立的组织，就意味着在凋谢代码的根底之上，将代码相干的品牌和专利变成中立了，这样每一个参加我的项目的人都能够来应用Istio的品牌，人人平等。 从开源我的项目的使用者来看，咱们必定心愿开源的我的项目能够做到下面所说的三局部（代码、品牌、治理模型）都可能凋谢，从长期来看，这是对用户最无利的场面，这样开源我的项目就能够依照社区的需要导向来倒退，而不是依照参加的某一家公司的动向来倒退。 然而谷歌并没有把治理模型凋谢进去，一是因为Istio我的项目还处于倒退晚期阶段，如果凋谢治理模型，会导致很多人参加到Istio晚期过程中，决裂的话语权对于一个晚期尚不成熟的我的项目而言是不利的。从商业化的角度来看，如果谷歌领有对于开源我的项目的治理权力，那么，对于该项目标将来走向是有肯定的把控能力，这对于谷歌将来布局产品线有肯定的先发劣势，这也是谷歌没有凋谢治理模型的一层思考。 Istio 之所以成为“香饽饽”，因为它是目前 Service Mesh 社区最引人注目的开源我的项目，而 Service Mesh 也是当下云原生畛域最被看好的发展趋势。 三，云原生：企业的顾虑与不可抵御的行业趋势近年来，云原生的理念越来越受到业界的器重，李响作为云原生畛域的创新者，也在推动国内云原生的技术布道，包含深度参加阿里云原生架构白皮书的撰写、参加设计云原生实际课程等。云原生理念对于国内企业而言，还处于一个晚期倒退的阶段，无论是技术、产品、规范等，都还处于疾速迭代的过程中。企业在利用云原生的技术和产品时，不免有所顾虑。 Q：国内外云原生的倒退，有多大的差距？ 李响：总体来看，国内外云原生技术理念的倒退没有太大的差距。然而因为云原生理念的衰亡是在北美，所以社区生态的倒退核心还是在硅谷这里，一些新的技术理念或者架构利用、翻新场景等，也是须要一些工夫能力缓缓引入到国内。 区别比拟大的是国内企业跟国外企业对于云计算的接受度。咱们提到云，最先想到的肯定是节约资源、弹性、老本升高、技术红利这些大家关怀的点。北美企业的人力老本广泛较高，所以他们会违心为云上的软件服务付费，尽可能节约人力老本。国内很多企业不短少研发人员，整体研发能力也很强，在云服务提供附加值无限的状况下很多企业会本人研发一些定制化的能力。 阿里是国内较早开始践行云原生理念的公司之一，通过在外部实际成熟之后，开始对外影响更多的企业。咱们十分看重如何通过云原生为企业带来更多的附加值，并且这个附加值肯定要超过企业本人定制开发带来的价值，只有这样，企业才会违心拥抱云原生。将来阿里也会研发出一些更有竞争力的产品，提供更具价值的服务，并去影响海内的用户，让国内的云原生倒退与国内接轨。 Q：云上的服务将来会以什么样的状态存在？ 李响：将来的云肯定不是资源，对于云厂商而言，重心不是售卖这些根底的资源，而是在云上建设一个服务体系和生态，让企业更便捷和不便的应用云上的服务。随着云服务规模化的倒退，一个云服务能够交付给很多用户，因为边际效应，每个云服务的老本会大幅升高，对于企业而言更划算。但这对于阿里云而言也提出了一个挑战，如何把云服务更好地规模化，让每个服务更精密也更通用化，进而帮忙企业解决更多常见的问题。 Q：选用云原生技术时，企业对云原生技术栈进行大规模利用时的安全性、可靠性、性能、连续性存在疑虑。这个问题如何解决？ 李响：对于云原生有顾虑其实能够了解，毕竟云原生还处于晚期倒退的阶段。阿里云在帮忙国内企业理解云原生、应用云原生上做了很多工作。对于云原生技术栈的可靠性、性能、连续性这方面的顾虑，咱们从两个方面来解决，一方面是在外部尝试去应用这些技术，阿里巴巴外部有十分丰盛的、大规模的应用场景，通过这些场景能够打磨云原生技术。在技术成熟当前，咱们将这些技术回馈到社区，帮忙云原生社区进步技术品质和倒退程度。 另一方面，阿里云上提供了丰盛的云原生产品服务、云原生产品家族。以前一家企业想应用云原生的技术或产品，须要破费大量的精力钻研一些开源我的项目，本人做运维和治理，还须要思考集成、稳定性保障等问题，这样能力建设一个云原生平台。明天，为了不便企业和开发者更容易地应用云原生的技术和产品，更好地承受云原生的理念，并解决企业担心的可靠性、性能、连续性等问题，阿里云大家了一整套云原生产品家族，提供了十分强的SLA保障。 另外，对于云原生的安全性问题，2019 年，阿里云平安沙箱技术商用上线，反对 ECI、ACK、SAE 边缘计算等多种业务。蚂蚁金服也收买Hyper ，独特打造安全可靠的容器运行环境。阿里云平安沙箱是基于 MicroVM 构建的平安容器 Runtime。首先它是一个基于硬件虚拟化技术的 MicroVM，采纳了深度定制优化 hypervisor，极简的虚拟机设施模型。其次阿里云平安沙箱也是一个容器 Runtime，提供镜像散发、镜像治理、容器网络、容器存储，齐全兼容 OCI 和 CRI 标准。此外基于软硬一体设计的秘密计算容器开始展露头角，阿里云和蚂蚁团队独特推出了面向秘密计算场景的开源容器运行时技术栈inclavare-containers 。它基于Intel SGX等秘密计算技术，反对蚂蚁的Occlum，开源社区的Graphene Libary OS，极大升高了秘密计算利用的开发、交付和治理。 ...

简介： 原来繁多的技术环境开始走向分布式、分层的多组件技术架构，越来越多的组件使得保障业务稳固运行的工作也越来越艰巨。本文从容灾、容量、线上防护、演练四个维度全方位解说如何构建一个真正的高可用体系。 随同着互联网业务的高速倒退，越来越多的线下场景须要转移到线上，而线上业务的量级也在飞速增长，给互联网业务的技术架构带来了严厉的挑战，原来的“一体机+数据库”的形式曾经不适用于以后的支流业务，越来越来的业务开始向分布式架构和云原生架构演进。同时，原来繁多的技术环境开始走向分布式、分层的多组件技术架构，越来越多的组件使得保障业务稳固运行的工作也越来越艰巨。 一、容灾航空零碎的容灾体系做得十分优良。航空零碎的容灾体系从人、飞机和环境三个维度来思考，能力构建一套优良的容灾计划。 从人的维度，以防万分之一的紧急情况呈现的可能，每年要进行屡次的模拟机训练或者实景演练。一架飞机上都会装备至多两名飞行员，二者相互合作的同时也要互相监督。 从飞机的维度，每一个航段前，光是一个绕机查看可能就有几十个我的项目须要查看。机查看是由高空机务人员和航行机组别离实现，同样也是为了更认真的查看，升高错误率。每架飞机还有短期全面检查和长期全面查看，飞机上的每一个设施都是独立的双系统在工作。 从环境的维度，气象雷达能够让飞行员感知到几十甚至几百海里范畴内的天气情况。飞机防撞零碎能够让航行导航显示仪上显示正在靠近的可能存在威逼的飞机。盲降零碎是由高空发射的两束无线电信号实现航向道和下滑道指引，飞机通过机载接管设施，进行起飞。 从航空业的容灾体系构建中咱们能够发现，容灾的核心思想是基于隔离的冗余。在零碎设计中，其实也常常用到冗余的机制，比方机器常常是多台、数据是多备份等。容灾的评估指标次要有两个： 一是RPO（Recovery Point Objective），即数据恢复点指标，以工夫为单位，即在劫难产生时，零碎和数据必须复原的工夫点要求。 二是RTO（Recovery Time Objective），即复原工夫指标，以工夫为单位，即在劫难产生后，信息系统或业务性能从进行到必须复原的工夫要求。RTO标记着零碎可能容忍的服务进行的最长工夫，零碎服务的紧迫性要求越高，RTO的值越小。 1. 业界支流容灾计划如下图所示，业内支流的容灾计划最早是异地冷备的形式，起初演进到同城双活形式，最初倒退成为“两地三核心”。 业界支流容灾计划 2. 阿里AHAS阿里AHAS容灾计划应用的是比“两地三核心”更前沿的“异地多活”计划，在所有的数据中心都能提供服务的同时，RPO和RTO能做到分钟级甚至秒级。下图是阿里AHAS的产品状态。AHAS在2013年之后就开始大规模在阿里外部应用，并且作为高可用平台的一个外围模块，开始服务内部客户。AHAS通过异地多活，可能真正做到对于宏观架构的容灾，并抵挡大规模的失败场景。比方一个城市的机房出了故障，能够很轻易地把流量实时切换到另外一个机房。 AHAS异地多活的产品状态 二、容量在互联网业务下，流量的不确定性非常明显，常常会呈现流量顶峰事件，比方微博的热点、阿里的双11、12306的火车票放购等事件。在这种场景下，如何做好容量布局就变得至关重要。 1. 压测传统的压力测试通常关注的是性能的好坏，这是一个绝对含糊的概念，不须要很精准。然而在互联网的状况下， 咱们须要精准地获取到一个零碎的实时吞吐量，以便更好地应答突发事件。在这种状况下，压测要尽可能地模仿一个实在的环境，而不能像以往一样，在一个额定的环境去测试。压测时在流量规模、流量模型、零碎环境上都须要一个尽可能实在的环境，这样能力精准做好容量布局。 传统的压测工具尽管仍在发挥作用，然而随着互联网的倒退，曾经越来越不能去适应互联网技术的迭代。互联网的压测有几个显著的特点： 强调流量的真实性； 压测规模要足够大； 必须简略易用，交互式压测。 当下互联网压测曾经变成了一个实时的产品，不便进行实时的调控。基于这样的背景，阿里构建了基于PTS的流量引擎，大家能够在阿里云上间接应用，其特点如下： 流量实在。流量来源于全国上百城市，笼罩各运营商（可拓展至海内），实在模仿最终用户的流量起源，相应的报表、数据更靠近用户实在体感；发现端到端更多更全面的问题，压测即是模拟考。 压测规模弱小，可反对3kW QPS。 简略易用，门槛低。简单场景的全可视化编排，反对自定义编排能力、指令、管制、函数等相干能力，笼罩95%以上的HTTP压测场景，和JMeter构建能力不相伯仲，同时免去简单的了解学习老本；除了本身丰盛的客户侧监控数据，还可集成云监控和ARMS监控。压测过程提供日志明细查问，配套有申请瀑布模型，压测之后的报告和问题定位更不便。联合AHAS可额定提供流量吞吐控制能力、容量水位治理、熔断降级爱护性能。除了弱小的自研性能，对于开源JMeter的反对也很敌对，反对JMeter脚本转化为PTS压测，同样反对原生JMeter引擎进行压测。 2. 全链路压测在实践中发现，单零碎单利用的压测与实在场景之间的误差十分大，因为在压测的时候无奈验证整个零碎的方方面面，而且很多问题只有在真正的大流量场景下才会裸露，所以要进行全链路压测，其外围是心愿将来的事件可能提前到在以后工夫内产生，可能用最实在的场景来端对端的验证零碎的能力和稳定性。 为了实现更好地进行全链路压测，阿里云提出了基于PTS的全链路压测解决方案，其架构如下图所示。 基于PTS的全链路压测 从压测环境、压测根底数据、压测流量（模型、数据）、流量发动和问题定位对基于PTS的全链路压测解决方案总结如下： 压测环境：对应实在的线上环境，压测后果和问题裸露都是最实在的状况，可通过压测流量全局辨认、透传（影子表），或者等比隔离环境，或复用生产库（压测应用测试数据），业务挡板。 压测根底数据：结构满足大促场景的外围根底相干数据（如买家、卖家、商品信息），以线上数据为数据源，进行采样、过滤和脱敏，放弃和线上一个量级。 压测流量（模型、数据）：链路范畴、拜访量级、参数汇合、根底数据的个性一起结构压测的业务模型，和实在业务状况保持一致。 流量发动：模仿全国各地实在的用户申请拜访，探测站点能力。 问题定位：发动侧多维度的监控和报表，服务端可通过其余生态产品帮助定位。 三、线上防护线上防护对于零碎高可用来说是一个十分重要的环节。随着分布式技术的利用，节点越来越多，技术越来越简单，出错的机会也绝对增大。同时，在互联网的条件下，业务的公布也越来越频繁。在互联网的环境下，零碎随时面临一些不确定事件、流量冲击等，不能奢望每次呈现故障的时候都有人工来干涉，而是须要零碎本身有肯定的防护能力，可能让本身在任何环境下都能有最佳的工作状态。 1. AHAS流量防护阿里云将流量防护广泛应用于各种场景，比方双11峰值流量、秒杀流动、物流、订单解决、商品查问、付款等。同时，阿里云也胜利地将流量防护能力交融到了云产品AHAS（Application High Availability Service，利用高可用服务）中。AHAS涵盖了阿里巴巴多年来在利用高可用服务畛域的技术积淀，包含架构感知、流量防护、故障演练和性能开关四大独立的功能模块。如下图所示，AHAS构建了一个从入口到最初端的一个残缺的防护体系。 AHAS经典流量防护布局 2. AHAS针对大流量场景的保护措施流量防护首先须要思考的是对大流量场景的爱护，比方url、服务提供方、重点业务等，忽然呈现超乎预期的大流量，基于AHAS能够做如下防护措施： （1）如果有性能压测，能够精准设置QPS阈值。有了QPS阈值，能够用来限流，避免出现超负载的流量。 （2）如果没有性能压测，也能够通过秒级监控，实时设置阈值。 （3）反对高阶性能：流控模式反对间接、关联、链路，流控形式反对疾速失败、Warm UP、排队期待。 3. AHAS针对不同场景的措施——异样隔离在特定未知的场景下，可能呈现不稳固的因素，如慢SQL，甚至死锁，导致整个利用越来越慢，甚至整个利用没有响应，这时候要对异样流量进行隔离，免得影响到失常的流量。 4. AHAS针对不同场景的措施——零碎防护在某些场景下，比方零碎的负载CPU飙升，零碎没有反馈，无奈确认具体哪个接口导致问题的呈现，这时AHAS提供了一个终极大招：零碎爱护。零碎爱护就是当零碎负载比拟高的时候，会主动依据入口流量和零碎的负载获得一个动静的均衡，保证系统不会好转的同时，也能解决最大的入口申请。在这种状况下，系统对各种流量都是平等的，无奈设置流量的优先级。 四、演练很多故障是一个小概率事件，然而一旦产生，所造成的损失是不可估量的，比方巴黎圣母院的火灾。互联网业务也是一样，小概率的故障也可能带来不可挽回的经济损失，甚至是法律危险。因而，故障演练是一个齐备的容灾体系所必须进行的一步。 1. 企业为什么须要做故障演练？如果一个业务零碎的流量很小且趋于稳定，就没有必要进行故障演练。然而如果一个企业处于高速倒退中，业务倒退快，有大量的稳定性技术债，其业务零碎一直的变动，甚至明天的状态跟昨天的状态都不统一，架构也日益简单，那么故障演练就是十分必要且必须的。因为每个环节的不确定因子都是累积的，如果不进行故障演练，最初一旦产生故障，极大可能会对系统造成严重破坏。故障演练还能够造就企业人员的故障解决教训，加强人员的应急能力。 ...

引子随着云原生技术的遍及，越来越多的企业应用Kubernetes来治理利用，并且集群规模也呈爆发式增长，企业也亟需应答随集群规模增长而带来的各种挑战。同时，为了更好地提供高可用、弹性伸缩的利用，企业也对容器混合云解决方案产生了极大的趣味。 纵观容器混合云市场，次要的云服务提供商纷纷推出了自家的解决方案，例如华为云的MCP、Google的Anthos、Vmware的 Tanzu、IBM的 Cloud Pak、Red Hat的ACM for K8s等等。能够说，以后容器混合云市场纷纷嘈杂、百家争鸣，只管各厂商不遗余力地宣扬自家解决方案，但有个不争的事实是在容器混合云畛域暂未呈现领军产品。 混合云市场的乱象源于两点，一是各厂商均嗅到了商机，发现了这一广大的蓝海市场，急于在这场竞争中抢占先机C位出道；二是开源界暂无对立的事实标准。依据历史法则，后者是解决这一乱象的关键所在，正像Kubernetes终结容器编排畛域的纷争截然不同。 在开源畛域，致力于混合云畛域的我的项目数量与广大的市场相比，显得极不相称。目前只有Rancher的Fleet、SAP公司力推的Gardener、以及Kubernetes社区的Kubefed。Fleet和Gardener要么不足翻新，要么格局较低，难成大气，最有可能造成规范的便是被寄予厚望的、也是以后Kubernetes社区惟一的官网我的项目Kubefed。 K8s多集群历史Kubernetes社区早在2015年便公布了集群联邦技术白皮书，并成立了“SIG-Federation”（后更名为SIG-Multicluster）特地兴趣小组致力于多集群畛域的钻研，该兴趣小组由华为领衔，同时也吸引了包含Google、Redhat在内的一线大厂。 SIG-Federation于2016年正式推出官网我的项目Federation，并在此基础上倒退出了Kubefed我的项目，而且技术架构也产生了较大的变动，因而Federation我的项目经常被称为Federation V1，而Kubefed则被称为Federation V2。 Federation V1架构第一代架构中，引入了Federated API Server，用于减少集群相干API，屏蔽集群差别，对立申请入口，同时提供一个Cluster Controller用于治理多个集群状态、集群级别对象创立，并且Service Controller用来实现跨集群服务发现。整体架构如下图所示： V1架构兼容K8S原生API，从单集群到多集群演进能够变得很天然，但它也有几个不得不面对的缺点。 • 集群信息嵌入原生API的Annotation中（如下图所示），会导致原生API体积收缩而俊俏； • 没有集群生命周期治理特有API，导致其生命周期治理能力无奈扩大； • 无奈提供API对象版本控制，比方Deployment在K8S为GA，但在Federation中可能仍是Beta； Federation V2架构在第二代架构中，利用CRD来提供独立的API对象，新的API来封装K8S原生对象，同时也能够不便的对新增API提供版本治理。 整体架构如下图所示： 随架构降级，Federation我的项目也更名为Kubefed。在新的架构中，Kubefed提供两种配置类型： • Type configuration（类型配置）： 定义Kubefed接管的K8S的资源类型 • Cluster configuration（集群配置）： 定义Kubefed接管的K8S集群 在类型配置中有三个要害的概念，用于管制资源向拖管集群散发策略： • Templates（模版）：定义一个原生的K8S资源类型； • Placement（安置）：定义资源将散发的集群； • Overrides（修改）：针对集群自在修改资源； 一个典型的Secret配置如下图所示： apiVersion: types.kubefed.io/v1beta1kind: FederatedSecretmetadata: name: test-secret namespace: test-namespacespec: template: data: A: YWxhIG1hIGtvdGE= type: Opaque placement: clusters: - name: cluster2 - name: cluster1 overrides: - clusterName: cluster2 clusterOverrides: - path: /data value: A: null上述配置中，通过template指定原生资源属性，通过placement指定资源将散发到cluster1 和 cluster2集群，最初overrides批示了散发到cluster2集群时，打消Secret的data信息。 ...

作者 | 孤弋  阿里云高级技术专家，负责 EDAS 的开发和用户体验优化工作。 导读：在上一篇文章《SpringCloud 利用在 Kubernetes 上的云上实际 - 开发篇》中讲到能够通过两个工具，轻松地将一个 SpringCloud 利用从初始化到本地运行。本篇文章，咱们将介绍如何将上一篇文章中提到的利用在云上跑起来。初始化集群为了将利用运行在云端，首先咱们须要一个 Kubernetes 集群，在 EDAS 中应用 Kubernetes 集群目前最快的形式，是将一个阿里云容器集群中的 Kubernetes 集群( ACK 集群 )，导入到 EDAS 中来。 如果还没有ACK集群的话，您能够通过以下两种形式来创立一个： 间接进入容器服务的控制台进行创立；如果您曾经有一个在云上建好的集群，或者有一个在其余 IDC 或友商中有的集群，也能够在容器服务这边通过“注册已有集群”的形式，导入到容器服务中来。等到 Kubernetes 集群就绪之后，在 EDAS 上须要进行一次集群“导入”，导入形式如下图所示： 在导入集群时，EDAS 会做以下操作： 初始化 EDAS 的集群控制器和相干资源，次要蕴含：基于凋谢云原生利用规范的 OAM Controller、日志采集的 Agent、监控链路中的 Arms 环境信息等；其中大部分控制器运行时不会占用用户集群的资源，而会运行在 EDAS 托管的一个管控集群中，由 EDAS 来负责保护；依据用户的布局，划分好此集群与 EDAS 中命名空间的关系。EDAS 中的命名空间是用来隔离服务与配置的，简略的能够了解成开发、测试、线上这样的日常研发中的环境。集群导入的同时也确定了该 Kubernetes 集群是用于哪套环境。初始化利用在筹备好集群之后，咱们须要初始化一个云端的利用，进入 EDAS 中的创立利用的向导之后，抉择刚刚创立的集群进行利用创立，在须要抉择的利用利用运行环境处，会看到有 "自定义"、"Java" 、"Tomcat"、"EDAS Container" 四类，如下图所示： 这里须要非凡阐明一下，因为一个利用一旦一开始确定了部署类型，当前将不能被批改，其中： Java/Tomcat/EDAS Container 类型的的环境：如果抉择这中运行环境，文件上传之后，EDAS 将把文件与相应的根底镜像一起打成利用的镜像应用；自定义环境：抉择镜像的运行环境之后，意味着每一次的部署均通过指定的自定义镜像进行部署，其中，自定义镜像须要满足肯定的标准，具体内容能够参考阿里云帮忙文档《制作利用容器 Docker 镜像》。其中外围的内容是以下两行代码：# 继承 EDAS 的官网镜像FROM apaas/edas# 将文件下载至 /home/admin/app 中ADD http://your.domain.com/file/location.jar /home/admin/app/注：EDAS 中的利用，运行时就是被 OAM 控制器管控下的 Kubernetes 的 Deployment，因而除了通过上述形式创立 EDAS 利用之外，EDAS 也能将集群中的 Deployment 读取进去，您能够将这些Deployment间接转成一个 EDAS 利用。这里如果有敌人对 EDAS 利用 与 Deployment 之间的转换感兴趣的话，咱们在专门的章节中细讲。通过 IDE 插件间接部署 Kubernetes 利用在初始化好利用之后，咱们就能在开发时通过 IDE 将利用打包并间接部署下来了。和抉择的 运行环境 无关，在插件中进行部署时，咱们也会有相应的选项，如图： ...

【Arthas 官网社区正在举办征文活动，加入即有奖品拿~点击投稿】 前言疫情期间，在家办公，每天都是 007，感觉本人曾经降级为熊猫特工了，心累，身材疲乏！！！ 明天终于有工夫劳动一下，而后记录一下在家办公期间 Arthas 的简略应用。 下载安装形式一：举荐应用 IDEA 插件下载 Cloud Toolkit 来应用 ArthasCloud Toolkit 是阿里云公布的收费本地 IDE 插件，帮忙开发者更高效地开发、测试、诊断并部署利用。通过插件，能够将本地利用一键部署到任意服务器，甚至云端（ECS、EDAS、ACK、ACR 和 小程序云等）；并且还内置了 Arthas 诊断、Dubbo工具、Terminal 终端、文件上传、函数计算 和 MySQL 执行器等工具。不仅仅有 IntelliJ IDEA 支流版本，还有 Eclipse、Pycharm、Maven 等其余版本。 形式二：间接下载启动：java -jar arthas-boot.jar这里须要重点阐明一下：必须应用和指标过程雷同的用户，否则启动不胜利。 问题背景自己前天刚上线一个工作。因为某产品手误，误操作了线上数据，要求帮忙把数据删除了。这尼玛的真坑啊，显著是坑老子。 还好有先见之明，没次做工作的时候多多少少都会写几个后门工具（不是为了删库跑路，而是这些后门在特定状况下真能应急应用，求人不如求己）。然而这次后门工具还有革新一下才行，大半夜的又找不到人来帮你上线，本人又没有权限。这时候想起了 Arthas 这个工具能够热加载。 重点来了jad 反编译代码jad --source-only com.xxx.xxx.service.aggregate.AggregateNoRoomService > /tmp/AggregateNoRoomService.java复制代码这里有窃密协定限度，包门路曾经打码，小伙伴们间接看过程就能够了。vim 批改反编译进去的代码public AggregateNoRoom getAggregateNoRoom(String agentHotelId) { List<AggregateNoRoom> aggregateNoRooms = aggregateNoRoomDao.selectList(agentId); if (CollectionUtils.isEmpty(aggregateNoRooms)) { return null; } //新减少的逻辑 for (AggregateNoRoom room : aggregateNoRooms) { aggregateNoRoomDao.delete(room.getId()) } return aggregateNoRooms.get(0);}复制代码将这个类从新编译成 class 文件这里就不过阐明了，简略的程序间接javac x x x x.java就能够了，然而我这个类外面还依赖了其余的类型，所以我是用maven间接编译的整个Java我的项目，而后然而把这个新的class文件copy进去而后上传到服务器的。失常来说是应该应用Arthas的mc命令来从新编译这个批改后文件。然而我在服务器上始终没有编译胜利，谬误起因当前在钻研。 ...

现在，云原生被企业和开发者奉为一种规范，并被认为是云计算的将来。 严格来说，云原生并不是一个产品的名称，而是一套技术体系和一套方法论，它包含 DevOps、继续交付、微服务、容器、麻利基础设施等内容。云原生（Cloud Native）概念在 2013 年被首次提出，在云原生技术全面暴发之前，咱们开发的利用能够被称为非云原生利用，非云原生利用并没有思考到利用的弹性和规模性，甚至很多都不具备扩展性，当业务规模扩充时，特地依赖硬件的降级，进而带来了很多问题。 京东在每年的 618、11.11 都会面临海量数据和流量增长，从前端网站、订单、结算、领取、搜寻、举荐，到后端的仓储、配送、客服、售后各种业务零碎都面临着前所未有的挑战。因而，京东天然须要一个灵便的、有弹性的、可规模化扩大的平台，这也决定了京东从很早开始就拥抱云原生。京东目前经营着寰球最大规模的 Docker 集群、Kubernetes 集群，以及最简单的 Vitess 集群之一，根本实现了“All in Containers”，是目前寰球容器化最彻底的互联网企业之一。 京东作为容器技术先行者，早在 2014 年，就率先将 Docker 容器技术大规模利用至生产环境。在 2016 年初开始实际 Kubernetes，在2017年初基于 Vitess 构建起弹性数据库，并且自研京东“阿基米德”调度零碎。京东批发基础架构团队继续建设“阿基米德”平台，作为撑持京东万亿 GMV 的技术基础设施，阿基米德由大规模容器集群调度、数据库与存储技术平台、组件化微服务平台、商品图片技术平台、异地多活与智能运维、边缘计算平台形成。其中容器技术是所有平台服务的基石。在此过程中，采纳容器最大化资源利用，节俭数据中心数亿元洽购老本。大促之前加机器的历史一去不复返。 同样在 2016 年，京东须要云原生的 Registry 用来保护其镜像地方存储库。在考查了包含Docker原生注册表在内的多个解决方案之后，京东抉择了 Harbor。从那时起，京东就开始成为 Harbor 的忠诚用户。Harbor 操作简略、运行稳固，为京东节俭了大概 60% 的镜像地方存储库保护工夫。 随着业务量的增长，存储镜像的数据会变得越来越宏大，京东须要一个稳固、牢靠、高性能的存储计划。ChubaoFS 是京东开发的一款为云原生利用提供分布式文件存储服务的开源我的项目，在所有分布式文件系统中，ChubaoFS 最适宜反对云原生工作负载，这得益于其简直有限的可伸缩性和散布在多个节点工作内存中的强壮元数据子系统。京东抉择其作为 Harbor 后端存储计划，多个 Harbor 实例能够同时应用 ChubaoFS 共享容器镜像，它给 Harbor 提供了稳固的，可弹性扩大的，高性能的分布式存储服务。 对于曾经服务于京东 100 多个利用以及在线业务的 ChubaoFS 来说，一个优良高效的监控零碎是非常重要的。Prometheus 我的项目是由前 Google 员工公布的新一代云原生监控零碎，2016 年 5 月正式退出 CNCF 基金会的我的项目，是第二个 CNCF 的毕业我的项目，Prometheus 具备人造的 K8S 生态劣势，而京东基础设施都部署在 Kubernetes 集群中，应用 Prometheus 能够更好地将监控利用于生产环境。Prometheus 提供了一种更便捷、高效的资源组织和应用形式，让部署和保护变得更简略，便于资源的动静伸缩及牢靠服务，大大晋升了开发、交付、运维系列流程效率，让咱们在软件开发中更关注应用逻辑自身，从而让开发更加高效。 ...

简介： 还记得去年 双11 外围利用 100% 上云吗？没错咱们就是主导的团队！ 咱们在找谁？毕业工夫为 2020 年 11 月- 2021-10 月海内外高校的全日制本科、硕士、博士。 计算机、数学、电子工程、通信等相干业余；具备扎实的数据结构和计算机系统根底，精通一种开发语言；对根底软件充满热情，具备较好的入手能力和技术激情，有胜利的研究型或实战型我的项目技术成绩落地者优先；关注开源技术，有开源贡献者优先。上面跟你说说阿里云那么多团队，为什么你要来云原生团队。 这里，有你据说过的大佬 这里，有你据说过的我的项目 云原生团队诞生了 Apache RocketMQ、Apache Dubbo、Spring Cloud Alibaba、Nacos、Seata、Arthas 等开源我的项目。 Apache 顶级我的项目就有两个！ 2020 年阿里巴巴开源编程之夏 20 个参加我的项目，其中有 10 个来自云原生团队！ 咱们每年都会举办中间件技术挑战赛，邀请业界各路大牛切磋技能，往年有 1 万个开发者参加！ 这里是阿里“技术中台”的发源地，咱们服务了许多阿里以外的出名互联网企业，咱们为许多龙头企业提供了微服务相干的最佳实际和解决方案，帮忙许多传统企业实现了数字化转型。 在这里，你可能全面晋升你的集体技术影响力、沟通能力和行业知名度。 这里，有举世无双的场景作为阿里外围的技术部门之一，咱们是整个团体技术的“底座”，咱们的产品向上撑持了淘宝、天猫、盒马、菜鸟、高德等简直所有阿里巴巴团体的外围业务，向下整合存储、计算、网络等阿里云基础设施，是历年来阿里巴巴技术架构降级，618 / 双十一 / 双十二等大促流动的核心技术部门。 还记得去年 双11 外围利用 100% 上云吗？没错咱们就是主导的团队！ 简历投递邮件题目：云原生-应聘岗位邮箱地址：yaowei.cyw@alibaba-inc.com，你的简历会间接到技术大佬手里如果你对面试有任何问题，欢送加 weixin 交换群，云原生小助手后续会在群里公布面试秘籍。 增加小助手 weixin：alibabass88，回复 校招 手动拉你进群。 详情可点击查看：https://mp.weixin.qq.com/s/aMGMme2-p296798wlGQQfQ。

作者 | 江建明  阿里巴巴高级无线开发专家 导读：精英人数的增长速度继续放慢后，很多人开始焦虑，我也焦虑，深知要走出焦虑不容易，我想把走出焦虑疾速成长的认知和办法写成文章分享给更多人，做成【技术人成长系列】文章给更多人面对面分享，该系列总共三篇，别离是《实现本人的认知降级》、《自我成长的办法》、《学会自我造就或造就别人》。本文是疾速成长第一篇：“实现本人的认知降级”，内容偏长但值得仔细阅读。 如何浏览本文？ 找一个固定不被打搅工夫仔细阅读在碎片化的工夫中，每次读完一段内容最重要的是每次做到只字不差的浏览，而后停下，带着批判性思维从本文中提取出你感觉对的思考形式，并把思考形式关联和迁徙到本人身上，通过实际内化成本人的认知，就是十分胜利的一次浏览。 开始意识“认知降级”第一次：从文章中看到认知降级，认为认知降级是洗脑，是鸡汤，我对此等闲视之，情理谁都懂，大部分人还不是过得一样，没啥区别。 第二次：从会场里听到认知降级，一个活人站在那里讲认知降级，感觉认知降级有点意思，开始缓缓去了解认知降级，但还是不懂认知降级的价值。 第三次：从实际中觉知认知降级，发现“鸡汤谁都懂，但仍然过不好这毕生”，还有另外一个版本“用好喝鸡汤的工具：汤勺，能够把这毕生过得很好”，最简略的开始就是从工夫治理认知降级开始，感触到认知降级的弱小力量。自从换了一种工夫治理思考形式之后，本人逐步变得自律，变得有思考，成长复利缓缓变厚，感触到认知降级的价值，但还是没能力定义认知降级。 第四次：从利 TA 中定义认知降级，开始做认知降级的 PPT 给团队，给别人分享认知降级，发现一部分人的行为、工作、思考等在缓缓发生变化，这些发生变化的同学，将来必定会超出本人的冀望，变得更加优良，此时我想我可能比拟清晰地定义认知降级。 我对认知降级的定义：认知降级是连贯，连贯优良的思维形式，连贯解决问题的最短门路，连贯所有优良的办法。比方：说到工夫治理立马连贯到“找到不被打搅的工夫用于投资本人”、说到执行力立马连贯到“先想明确，而后一步步做上来”、说到扭转习惯立马连贯到“在触发条件产生进入下一个行为时，做对选择题”。通过认知的扭转，会激发本人做出思考，做出行为的扭转，从而影响咱们的判断，晋升咱们的能力，确切地说认知降级颠覆了本人的思考习惯，让咱们超过本能思考，解脱了旧有的直觉和教训，建设起了新的直觉和教训。 上面 10 个主题的认知分享是从我的认知升级库中挑出来的一部分我认为最重要的认知，对我的帮忙和扭转十分大，我置信对其他人同样有价值，大道至简，保持这 10 个简略的认知就能够大大晋升咱们的成长速度，而且随着自我一直进化的同时，会一直降级和丰盛本人的认知库，一直晋升本人的认知降级能力。 1. 思考脑与反射脑听精彩的演讲不止精力上会有即时的霎时享受和满足感，更重要的是总会有那么几个关键词刺激咱们的神经，让咱们产生霎时记忆，做出进一步的思考，这也是我为什么爱听牛人演讲，不是想听他开办企业的精彩故事，而是因为他演讲的内容中走漏出的智慧，走漏出的超时代的远见，走漏出系统性的逻辑，听他的演讲总会给人一种醍醐灌顶的感觉，而所有这些演讲过程中走漏出的智慧、远见，并不是在台上立马想到，是台下无数个思考最终形象提炼进去的观点。台上演讲是反射，台下筹备是逻辑是思考，所谓台上一分钟，台下 10 年功，反射和思考是什么关系呢？开始第一个认知：思考脑和反射脑。 欧洲工商管理学院传授特奥-康普诺利的《慢思考》这本书中把大脑分为反射脑、直觉脑、存储脑。简略来说：思考脑管理性，反射脑管直觉，存储脑管记忆，直觉依赖习惯，用直觉做出反馈，疾速，但未必正确；思考脑管理性，感性依赖逻辑，迟缓，但更加正确。 有科学家通过钻研，发现一个人一天的行为中，5% 是非习惯性的，用思考脑的逻辑驱动，95% 是习惯性的，用反射脑的直觉驱动，决定咱们毕生的，永远是 95% 的反射脑（习惯），而不是 5% 的思考脑（逻辑）。回忆本人的一天，大部分的判断和观点是不是都是靠直觉，靠习惯的，什么状况下才会用思考脑？是不是一个人的时候用思考脑比拟多，而在多人对话场景中要快只能靠直觉和反射，而给他人好与不好的印象往往是在对话场景中建设起来的，可想而知，反射进去的观点或行为对咱们而言是如许重要。 以学游泳举例，当在水里的那一刻，进入正念（正念：有目标，无意识的，关注和发觉当下的所有），将大脑的指令和手脚的动作关联上，大脑下达手脚标准化动作指令，手脚执行标准化动作指令，过程中大脑始终在关注和发觉手脚的动作，同时做出判断和调整，这是一个逻辑思考和强化训练的过程，把逻辑思考的过程强化成反射的过程，一旦学会，就无需进一步思考，游泳已成为天然。 放在学习和成长上也是一样，借用正念的概念，有目标无意识地关注和发觉学习时的所有，特地是在输出和输入过程中的逻辑思考过程，我特地倡议做好 2 件事： 专一输出：做到只字不差地浏览，只字不差地听只字不差地浏览、只字不差地听的过程中，咱们会继续地深刻了解作者文字和语言背地的逻辑，会产生本人的逻辑思考，会产生逻辑和观点的碰撞，本人的逻辑和作者的逻辑差别和共同之处在哪里，这是重复训练逻辑思考的必经之路，短少这一步，导致的后果就是中国填鸭式教育的后果，大部分时候晓得后果然而不晓得原理。 专一输入：定期做 PPT 进行分享定期做 PPT 进行分享，这是读书学习过程中无奈代替的高质量逻辑训练形式，是一种更高要求的逻辑形象的训练，同时通过输入检测学习和成长品质，训练的次数多了，书上的逻辑就变成了本人直觉反射，丰盛了本人 95% 区域里无效的结构化常识。 所以对咱们来说，想要没有焦虑，想要人生变得虚浮，把泛读变成精细化的逻辑训练，把 95% 中的低质量习惯反射，训练成逻辑后的高质量习惯反射，训练过程会苦楚，然而一旦训练成直觉，会变得十分天然。 划重点：所谓直觉反射就是通过大量的逻辑重复训练，晋升本人的直觉准确性，从狭隘的 5% 进入广大的 95%。 2. 司空见惯把 95% 中的低质量习惯反射，训练成逻辑后的高质量习惯反射须要有很多的工夫保障。然而对处于挪动互联网时代的咱们，电子设备对人类生存出行带来了很好的便利性，与此同时人类对其依赖水平曾经到了寸步不离的境地，甚至上厕所短短几分钟，手机也是寸步不离。 手机曾经成为一种生存形式，一种习惯形式，眼不离机是咱们的习惯，因为手机产生了十分大的变动并固定了下来，空了玩手机、陪家人时玩手机、忍住不睡玩手机，咱们的生存因而少了学习，少了浏览，少了交换，少了陪伴。 已经，我也始终被困在电子设备这个囚笼里，好长时间无奈扭转这个习惯模式，难扭转是因为一旦进入习惯模式，大脑的沉闷水平急剧下降，不再参加决策，进入休眠状态，此时咱们的行为由习惯摆布。我对这种现代化的生存形式最大的感触：浏览信息的工夫多了，本人思考和推敲的工夫少了，专一在有效事件上的工夫多了，专一在自我成长上的工夫少了。 当本人觉知到重度应用手机进行浏览和娱乐的不好习惯后，天然就产生了想扭转的想法，也就是说，如果可能有一种扭转习惯的无效办法，帮忙本人扭转重度应用手机的习惯后，意味着每天能够节俭很多的工夫，节俭很多的注意力，节省下来的工夫和注意力能够放在更重要的成长能力的迭代上。侥幸的是，司空见惯的认知进入到我的认知零碎中，成为我的第二个认知降级。 我对习惯的认知，关键在于换种说法：“把扭转玩手机的习惯，用另外一句话来代替，把学习变成司空见惯的生存形式”。要解决的对象变了，后面聚焦于扭转习惯，前面聚焦于把学习变成司空见惯，当咱们要求他人或本人扭转习惯，会有压力，关键在于“扭转”这个词，命令式，给人一种不盲目镇压的心里暗示；但若把学习变成司空见惯，心里累赘会少很多，仿佛是很天然的事件。 ...

作者 | 李响、张磊 Kubernetes 自身并不间接产生商业价值，你不会花钱去购买 Kubernetes 。这就跟安卓一样，你不会间接掏钱去买一个安卓零碎。Kubernetes 真正产生价值的中央也在于它的下层利用生态。 “将来的软件肯定是成长于云上的”，这是云原生理念的最外围假如。而所谓“云原生”，实际上就是在定义一条可能让利用最大水平利用云的能力、施展云的价值的最佳门路。因而，云原生其实是一套领导软件架构设计的思维。依照这样的思维而设计进去的软件：首先，人造就“生在云上，长在云上”；其次，可能最大化地施展云的能力，使得咱们开发的软件和“云”可能人造地集成在一起，施展出“云”的最大价值。 云原生的概念大家并不生疏，很多企业也曾经基于云原生的架构和技术理念落地相干实际。那么，这么多企业和开发者热衷和推崇的云原生，将来的发展趋势如何？如何能力适应云原生的支流方向去倒退？  咱们邀请到阿里云资深技术专家、CNCF 技术监督委员会代表，etcd 作者李响和阿里云高级技术专家、CNCF 利用交付畛域 co-chair 张磊分享云原生的理念、倒退以及将来趋势，为大家关上新的思路和眼界。 以下内容共享给大家。 Kubernetes 我的项目的安卓化云原生里有一个十分要害的我的项目，就是 Kubernetes。Kubernetes 的倒退十分迅速，它是整个云原生体系倒退的基石。明天咱们来察看 Kubernetes 我的项目的倒退特点，首先，Kubernetes 无处不在，无论是在云上，还是用户自建的数据中心里，甚至一些咱们设想不到的场景里，都有 Kubernetes 的存在。 第二，所有云原生的用户应用 Kubernetes 的目标，都是为了交付和治理利用。当然这个利用是一个泛化的概念，能够是一个网站，也能够是淘宝这样十分宏大的电商主站，或者是 AI 作业、计算工作、函数、甚至虚拟机等，这些都是用户能够应用 Kubernetes 去交付和治理的利用类型。 第三，明天咱们来看 Kubernetes 所处的地位，实际上是承前启后。Kubernetes 对上裸露基础设施能力的格式化数据抽象，比方 Service、Ingress、Pod、Deployment，这些都是 Kubernetes 自身原生 API 给用户裸露进去的能力。而对下，Kubernetes 提供的是基础设施能力接入的标准接口，比如说 CNI、CSI、DevicePlugin、CRD，让云可能作为一个能力提供商，以一个标准化的形式把能力接入到 Kubernetes 的体系中。 这一点其实跟安卓十分相似，安卓尽管装在你的设施里，然而它可能让你的硬件、手机、电视、汽车等都能接入到一个平台里。对上则裸露对立的一套利用治理接口，让你可能基于安卓零碎来编写利用，去拜访或者享受到这些基础设施能力，这也是 Kubernetes 和安卓的相似之处。 最初， Kubernetes 自身并不间接产生商业价值，你不会花钱去购买 Kubernetes。这就跟安卓一样，你不会间接掏钱去买一个安卓零碎。Kubernetes 真正产生价值的中央也在于它的下层利用生态。对安卓来说，它明天曾经具备了一个宏大的挪动端或设施端利用的开发生态，而对于 Kubernetes 来说也是相似的，只不过当初还在于比拟早的阶段。但咱们曾经可能看到，明天在 Kubernetes 上构建的商业层很多是垂直解决方案，是面向用户、面向利用这一侧真正可能产生商业价值的货色，而不是 Kubernetes 自身这一层。这就是为什么我说 Kubernetes 倒退跟安卓很像，当然这可能也是谷歌比拟善于的一个“打法”：全力地去收费推广一个“操作系统”，真正获取商业价值的形式则是是去“收割”操作系统下层的生态价值而不是操作系统自身。 基于这些景象，咱们将 Kubernetes 的发展趋势概括为以下几点： 1. 云的价值回归到利用自身用户应用 Kubernetes 的实质目标是去交付和治理利用。从这个景象来看，如果 Kubernetes 倒退上来，那么世界上所有的数据中心和基础设施下面都会有一层 Kubernetes ，自然而然用户就会开始以 Kubernetes 为根底去编写和交付以及治理其利用，就跟当初咱们会以安卓这样一个操作系统为根底去编写挪动利用是相似的。 ...

随着 Kubernetes 的广泛应用，越来越多的开发人员尝试应用 Kubernetes 运行和治理 Web 利用和微服务以外的工作负载。典型场景包含深度学习工作，高性能计算作业，基因计算工作流，甚至是传统的大数据处理工作。 围绕 Kubernetes 容器平台，对立治理各种异构算力资源，高效调度AI、大数据、高性能计算工作，未然成为云原生技术带来改革的畛域之一。 阿里云容器服务团队联合多年 Kubernetes 产品与客户反对教训，基于 Kubernetes scheduling framework 对调度器进行了大量扩大和改良，使其在多种场景下仍然能稳固、高效地调度简单工作负载类型，为用户应用 Kubernetes 同时治理在线利用和离线工作提供了根底技术撑持。 2020 年 7 月 15 日上午 10：00，《阿里巴巴如何扩大 K8s 调度器反对 AI 和大数据工作？》主题线上网络研讨会行将召开。 2020 年 7 月 15 日网研会邀你加入题目：阿里巴巴如何扩大 K8s 调度器反对 AI 和大数据工作？工夫：2020 年 7 月 15 日(10:00 AM)语言：中文 议题介绍本次研讨会将介绍 Kubernetes Scheduling Framework 的倒退现状，以及阿里云 Kubernetes 服务反对调度 AI、大数据等简单工作负载和 GPU 等异构计算资源的实践经验。还将具体介绍如何实现 Coscheduling／Gang Scheduling、Capacity Scheduling 等工作级调度个性。 问题聚焦理解 Kubernetes Scheduling Framework 以后停顿与将来倒退方向理解阿里云扩大 Scheduling Framework 反对工作级调度的开发教训尝试构建本人的 Scheduling Framework 插件报名形式点击即可报名 ...

简介： Kubernetes 自身并不间接产生商业价值，你不会花钱去购买 Kubernetes 。这就跟安卓一样，你不会间接掏钱去买一个安卓零碎。Kubernetes 真正产生价值的中央也在于它的下层利用生态。 “将来的软件肯定是成长于云上的”，这是云原生理念的最外围假如。而所谓“云原生”，实际上就是在定义一条可能让利用最大水平利用云的能力、施展云的价值的最佳门路。因而，云原生其实是一套领导软件架构设计的思维。依照这样的思维而设计进去的软件：首先，人造就“生在云上，长在云上”；其次，可能最大化地施展云的能力，使得咱们开发的软件和“云”可能人造地集成在一起，施展出“云”的最大价值。 云原生的概念大家并不生疏，很多企业也曾经基于云原生的架构和技术理念落地相干实际。那么，这么多企业和开发者热衷和推崇的云原生，将来的发展趋势如何？如何能力适应云原生的支流方向去倒退？怎么在云原生时代“乘风破浪”？ 咱们邀请到阿里云原生资深技术专家、CNCF技术监督委员会代表，etcd作者李响和阿里云高级技术专家、CNCF 利用交付畛域联席主席张磊分享云原生的理念、倒退以及将来趋势，为大家关上新的思路和眼界。 以下内容共享给大家。 一、Kubernetes我的项目的安卓化云原生里有一个十分要害的我的项目，就是Kubernetes。Kubernetes的倒退十分迅速，它是整个云原生体系倒退的基石。明天咱们来察看Kubernetes我的项目的倒退特点，首先，Kubernetes无处不在，无论是在云上，还是用户自建的数据中心里，甚至一些咱们设想不到的场景里，都有Kubernetes的存在。 第二，所有云原生的用户应用Kubernetes的目标，都是为了交付和治理利用。当然这个利用是一个泛化的概念，能够是一个网站，也能够是淘宝这样十分宏大的电商主站，或者是AI作业、计算工作、函数，甚至虚拟机等，这些都是用户能够应用Kubernetes去交付和治理的利用类型。 第三，明天咱们来看Kubernetes所处的地位，实际上是承前启后。Kubernetes对上裸露基础设施能力的格式化数据抽象，比方Service、Ingress、Pod、Deployment，这些都是Kubernetes自身原生API给用户裸露进去的能力。而对下，Kubernetes提供的是基础设施能力接入的标准接口，比如说CNI、CSI、DevicePlugin、CRD，让云可能作为一个能力提供商，以一个标准化的形式把能力接入到Kubernetes的体系中。 这一点其实跟安卓十分相似，安卓尽管装在你的设施里，然而它可能让你的硬件、手机、电视、汽车等都能接入到一个平台里。对上则裸露对立的一套利用治理接口，让你可能基于安卓零碎来编写利用，去拜访或者享受到这些基础设施能力，这也是Kubernetes和安卓的相似之处。 最初，Kubernetes自身并不间接产生商业价值，你不会花钱去购买Kubernetes。这就跟安卓一样，你不会间接掏钱去买一个安卓零碎。而相似的，Kubernetes真正产生价值的中央也在于它的下层利用生态。对安卓来说，它明天曾经具备了一个宏大的挪动端或设施端利用的开发生态，而对于Kubernetes来说也是相似的，只不过当初还在于比拟早的阶段。但咱们曾经可能看到，明天在Kubernetes上构建的商业层很多是垂直解决方案，是面向用户、面向利用这一侧真正可能产生商业价值的货色，而不是Kubernetes自身这一层。这就是为什么我说Kubernetes倒退跟安卓很像，当然这可能也是谷歌比拟善于的一个“打法”：全力地去收费推广一个“操作系统”，真正获取商业价值的形式则是是去“收割”操作系统下层的生态价值而不是操作系统自身。 基于这些景象，咱们将Kubernetes的发展趋势概括为以下几点： 1、云的价值回归到利用自身用户应用Kubernetes的实质目标是去交付和治理利用。从这个景象来看，如果Kubernetes 倒退上来，那么世界上所有的数据中心和基础设施下面都会有一层Kubernetes，自然而然用户就会开始以Kubernetes为根底去编写和交付以及治理其利用，就跟当初咱们会以安卓这样一个操作系统为根底去编写挪动利用是相似的。 这就会导致云上的大多数软件和云产品都是第三方开发的。第三方开发是指所有人都能够面向一个规范界面去开发和交付软件，这个软件自身既能够是本人的软件，也能够是一个云产品。将来，越来越多的第三方开源我的项目，如MongoDB、Elasticsearch等，都会以云原生理念去开发、部署和运维，最初间接演进成为一种云服务。 2、云端“豌豆荚”的呈现有了Kubernetes这样一个规范，开发者面对的就是一个相似于操作系统的界面。因为有更多的利用是面向Kubernetes诞生的，或者说面向Kubernetes去交付的，那么就须要有一个相似于“豌豆荚”的产品，来作为云上的利用商店或者云上的利用散发零碎，它的要害能力在于把利用无差别地交付给全世界任何一个Kubernetes下面，就跟用豌豆荚把任何一个安卓利用交付在任何一个安卓设施上的原理是一样的。 其实明天谷歌曾经在做这类产品的尝试了，比方Anthos（面向混合云的利用交付平台），尽管是一款混合云产品，但它实质上是把谷歌云的服务，比方数据库服务、大数据服务，去间接交付于任何一个基于Kubernetes的混合云环境外面去，其实就相当于一款云端的“豌豆荚”。 3、基于Kubernetes可扩大能力的凋谢利用平台会取代PaaS成为支流因为将来整个利用生态会面向Kubernetes去构建，那么基于Kubernetes可扩大能力的凋谢利用平台会逐步取代传统PaaS 而成为支流。基于Kubernetes可扩大能力去构建一个凋谢的利用平台，其能力是可插拔的，可能去交付和治理的利用类型是多样化的，这才更合乎Kubernetes所构建的趋势和生态，所以一些真正高可扩大的平台层我的项目会大量产生。 另外，明天咱们看到的Kubernetes，跟“现实”中的云原生利用生态之间其实还有很多路要走，这也是阿里云原生团队始终在做的事件，基于Kubernetes在应用层构建更丰盛的利用生态，帮忙用户实现多样化的需要。 二、利用与能力的“Operator化”纵观云原生时代利用或者云的能力的倒退方向，你会发现另一个趋势，就是Operator化。Operator是Kubernetes的一个概念，是指Kubernetes交付的一个实体，这个实体有一个根底模型存在，这个模型分为两局部：一部分是Kubernetes的 API 对象（CRD），另一部分是一个控制器（Controller），如下图所示。 这里要辨别两个概念，自定义和自动化。很多人会说 Operator 能够帮忙我做自定义，因为很多人都会感觉Kubernetes内置的能力是不够用的，所以用户会利用它的可扩大能力去写一个Controller，从而实现跟多自定义的需要。但自定义只是Operator 中很小的一部分价值，咱们明天对利用和能力做Operator化的外围能源在于其实是为了实现自动化，而且只有自动化了，咱们能力讲云原生。 这是因为，云原生带来的最大的红利是能够让咱们最大限度、最高效地应用云的能力，二这种最高效、最大化的形式肯定没方法通过人工来实现的。换句话说，只有通过自动化的形式去开发、运维利用以及与云进行交互，能力真正把云原生的价值施展进去。 而如果要通过自动化的形式跟云进行交互，那么在云原生生态里，必须有一个相似于Controller或者Operator这样的插件的存在。明天阿里巴巴在云上交付的PolarDB、OceanBase等，其实都有一个跟Kubernetes连接的Controller的存在。通过Controller与基础设施、云进行交互，把云的能力输出到产品外面去。 在将来，会有大量的云上的利用和对应的运维能力、治理能力都会以Kubernetes Operator 的形式交付。在这个背景下，Kubernetes真正表演的一个角色就是能力的接入层和规范界面。如下图所示，这是一个十分典型的用户侧Kubernetes集群的样子。 一个用户的Kubernetes只有红框外面这部分是Kubernetes原生提供的API，而大量的能力都是以插件化或者说Operator化的形式存在。就比方上图左边所有这些自定义的资源和能力全副来自于第三方开发，通过Operator 这样一个规范的状态开发进去的能力来服务最终用户的。这就意味着在将来云原生的生态外面，基于CRD Operator的而非Kubernetes原生API的利用和能力会占到绝大多数。 随着这个趋势的一直演进，越来越多的软件和能力通过Kubernetes Operator去形容和定义，云产品也会开始默认以Kubernetes为底座，基于Operator进行交付。 正是因为越来越多的Operator的呈现，这里就会逐渐须要一个中心化的形式去解决Operator潜在的稳定性、可发现性和性能问题，也就是说在将来很可能会有一个横向的Operator治理平台呈现，对所有基于Kubernetes Operator开发的利用和能力进行对立治理，从而更好、更业余地服务用户。 此外，因为将来每一个能力、每一个利用都须要去编写Operator，所以说对开发者敌对的Operator编写框架也是将来一个很重要的趋势。这个编写框架能够反对不同语言，如Go、Java、C、Rust语言等，并且编写过程是专一于运维逻辑和利用的治理、能力的治理，而不是专一在Kubernetes的语义和细节下面。 最初，随着云原生生态的遍及，云服务也将实现Operator化，并且面向多集群/混合云场景呈现面向应用层的云服务标准化定义与形象，并在云原生畛域逐步取代IaC我的项目（比方 Terraform 等）成为云服治理与生产的支流形式。 三、利用中间件能力进一步下沉随着云原生以及整个生态的倒退，咱们看到利用中间件畛域也随之产生了很多扭转。从原先最开始的中心化ESB，到起初的胖客户端，逐渐演变到明天咱们常常提到的Service Mesh这样一种Sidecar化的形式。 其实明天你会发现，无论是云的能力还是基础设施的能力，都在不断丰富，很多原先只能通过中间件做的事件，当初能够很容易通过云服务来实现。利用中间件不再是能力的提供方，而是能力接入的规范界面，并且这个规范界面的构建不再基于胖客户端，而是通过十分一般的HTTP协定、gRPC协定去做，而后通过Sidecar形式把整个服务的接入层跟利用业务逻辑做一个解耦，这其实就是Service Mesh的思维。 目前Service Mesh只做了传统中间件外面的流量治理、路由策略、访问控制这一层的事件。而实际上，Sidecar 这个模型能够利用到所有中间件的场景里，实现中间件逻辑跟利用业务逻辑齐全解耦，让利用中间件能力“下沉”，变成Kubernetes能力的一部分。这样利用自身会更加专一化，更多的关注业务逻辑自身。 随同着这个趋势，在Kubernetes这一层还会有另外一个趋势呈现，就是Sidecar的自动化的、规模化的运维能力会成为一个必选项。因为Sidecar的数量会极其宏大，利用中间件很可能会演化成Sidecar集群，那么这些Sidecar的治理和规模化的运维能力，会是集群或者云产品的一个必备选项。 四、下一代DevOps模型与体系随着云原生生态的一直倒退，云原生理念的一直遍及，DevOps的思维很可能也会产生一个实质的变动，即下一代DevOps模型与体系。随着Kubernetes的能力越来越多、越来越弱小，基础设施也会变得越来越简单，那么基于这样一个弱小的基础设施去构建一个利用平台就会非常简单，并且这个利用平台最终会取代传统的PaaS平台。 咱们当初之所以在用DevOps这一套思维，实际上是因为基础设施自身不够弱小，不够标准化，不够好用，所以咱们须要在业务研发侧做一套工具去黏合研发人员和基础设施。例如，基础设施提供的能力是一个虚拟机，怎么能让虚拟机变成研发侧想要的蓝绿公布或者一个渐进式的利用交付零碎呢？这就须要一系列的DevOps的工具、CI/CD的流水线来实现。 然而当初的状况曾经产生了变动。基于Kubernetes的基础设施自身的能力曾经十分丰盛，像蓝绿公布这些能力自身就是Kubernetes能够提供的能力。在这样的背景下，DevOps的发展趋势也会产生很大的扭转： 1、关注点拆散在 Kubernetes 的背景下，“软件”不再是一个由利用Owner掌控的繁多交付物，而是多个Kubernetes对象的汇合，而这一堆Kubernetes外面的对象只有很少一部分其实才跟研发无关，所以说有很多对象会不在利用Owner的认知范畴内，这就导致平台必须去做关注点拆散，研发侧的关注点和运维侧、零碎侧的关注点是齐全不一样的货色。也就是研发不必再思考运维方面的细节，比方蓝绿公布怎么做，程度扩容什么策略，只有把业务代码写完交付就好。 随同着 Kubernetes和基础设施越来越简单，概念越来越多，作为平台层是不大可能让研发理解所有的概念，因而将来云原生生态肯定会做形象和分层。每一层的角色只跟属于本人的数据抽象去交互，研发侧有一套本人的申明式API对象，运维侧有一套本人的申明式API对象，每一层的关注点也是不一样的，这会是将来整个DevOps体系里倒退的一个重要的背景。 ...

随着产业互联网的倒退，越来越多的企业将业务上云，云环境复杂度一直蔓延，催生出新的利用架构，并一直向轻量化、无服务化演进。云原生已成为云计算畛域的重要技术发展趋势。 如何依靠云原生搭建平安体系，构建从被动进攻到被动布局的平安闭环，从根本上晋升企业平安水位？腾讯平安联结CSDN独特发动《产业平安公开课 · 云原生平安专场》，邀请7位腾讯平安专家分享其对云原生平安的技术了解、利用落地和实践经验，涵盖主机平安、平安经营核心、明码技术利用、数据安全、DDoS防护、Web利用防火墙、云防火墙等重要云上平安场景。 课程前瞻 ▼ 企业上云，如何保障主机平安 云计算的广泛应用，在推动虚拟机、云主机、容器等技术相继落地的同时，也为主机带来了更加多元化的平安危险和建设挑战：防护一两台主机与防护百万台主机相比，背地波及的平安体系建设和理念齐全不同。进入云原生时代，作为企业承载数据资产和业务管理的基础设施，主机亟需配置具备检测能力、响应能力、架构适配能力、满足合规要求的云平安防护体系。 上云过程中，面对日益严厉的破绽、挖矿木马、勒索病毒以及数据隐患，主机平安服务应如何应答？主机平安将来的发展趋势如何？7月14日晚19点30分，腾讯平安主机平安产品负责人谢奕智，将为大家解说腾讯云主机平安是如何为百万主机平安保驾护航，分享主机平安畛域的最佳实际和教训。 如何构建云时代的云原生平安经营核心 产业互联网时代，私有云凭借便当、高效服务、老本低廉等劣势，被越来越多的企业选为实现数字化转型的平台。然而在业务迁徙至云端后，企业的传统平安体系和经营思路已无奈应答新环境下产生的平安威逼，资产动静盘点、云平安配置管理及自动化响应机制等基本功能的缺失也成为威逼企业平安的隐患。 7月15日晚19点30分，腾讯平安高级工程师耿琛将基于云原生平安思路，深刻分析企业上云之后所遭逢的痛点和挑战，并联合平安经营核心为例，为用户展现如何构建云原生平安经营体系。 云原生数据安全中台解决方案分享 越来越多的企业开始应用更具可靠性和扩展性、更加易于保护的云原生利用。为了适配云原生利用的新构架，构建全新的云上数据全生命周期平安防护体系对于企业平安愈发重要，帮忙企业提前躲避在资源隔离、数据存储、数据传输、数据共享、虚拟化等方面可能存在的业务危险。在这个过程中，如何利用明码技术建设云上数据的爱护机制成为企业用户关怀的一大问题。 7月16日晚19点30分，腾讯平安云鼎实验室专家姬生利将腾讯云原生数据安全中台解决方案为例，围绕加密软硬件、密钥/凭据治理、云平安拜访代理三大要害能力，帮忙企业构建云上数据全生命周期平安爱护架构，达到晋升云上业务开发及业务数据安全性的指标。 摸索轻量而齐备的云原生数据安全 随着数据的暴发增长和贬值，让数据安全爱护成为了制约企业倒退的平安挑战。数据安全不仅仅要围绕数据动态资产的爱护，更重要的是针对整个数据流动过程的各个解决环节提供一整套平安解决方案。如何让残缺的数据安全解决方案，兼顾产品构造的轻量化、部署的高效化且可能匹配不同企业、不同业务的重点保护指标，是各企业抉择云原生数据安全产品的要害指标。 7月20日晚19点30分，腾讯平安数据安全专家彭思翔将解读以后数据安全的行业痛点，向用户分享云原生数据安全产品爱护云上业务数据安全的实现门路以及云原生数据安全解决方案的实践经验。 云时代，如何防备TB级DDoS攻打 在数字化浪潮下，越来越多的集体服务器、电脑、挪动终端、IoT设施等沦为黑客用于施行攻打的工具。攻击面的增大意味着攻打流量TB级时代的到来，DDoS这种简略粗犷的攻击方式正在严重威胁云上企业的业务倒退和声誉。云上DDoS攻防是全方位的反抗，从云平台到云上业务，从网络层、应用层、主机层到数据层都须要进行卓有成效的抗D防护。 7月21日晚19点30分，腾讯平安网络安全负责人高毅将会分享云时代下DDoS攻打的次要攻打伎俩和特点，并通过腾讯DDoS平安防护系统的实践经验，向企业用户介绍如何搭建云原生DDoS防护体系，防备TB级的流量攻打。 如何基于云原生平安打造全新一代WAF Web或APP服务是目前大多数企业外围业务的载体，Web利用攻打已成为企业面临的次要平安问题之一。尤其是随着攻打技术、破绽披露等日趋成熟，针对Web平安相干破绽的利用日趋产业化，企业须要更加器重如何在平安经营中进行疾速响应，构建与之适应的平安经营体系。 7月22日晚19点30分，腾讯平安WAF负责人刘吉赟将直播开课畅聊WAF，分享如何基于云原生的理念联合最新的平安技术能力打造全新一代Web利用防火墙，构建区别于传统利用平安防护的云原生利用平安防护体系。 云原生平安云防火墙外围能力 随同着企业外围业务大量上云，在云端混合环境、挪动拜访及在线应用程序迅速发展趋势下，攻击面裸露过多、云端流量拜访与管控、安全漏洞及平安日志审查等根底平安问题逐步裸露，企业须要更具细粒度的平安技术解决上述问题，全面晋升企业云上业务和资产的平安爱护能力。 腾讯平安云防火墙产品负责人周荃将在7月23日晚19点30分准时开课，通过向用户介绍腾讯平安云防火墙的理论案例，剖析在云上环境中企业该如何构建云原生平安体系，并介绍流量检测、威逼情报、漏洞补丁、访问控制等产品外围平安能力的性能及利用场景。 扫码预约报名 云原生平安将作为云时代下企业构建平安防护体系的根底撑持，并随着技术倒退和产品迭代，逐步深刻企业的外部流程和业务场景之中，进一步晋升云上企业的整体平安程度。立刻报名观看公开课，和专家一起探讨云原生平安的搭建和倒退。 产业平安公开课 腾讯平安联结生态合作伙伴独特发动「产业平安公开课」，定期邀请平安专家以线上视频直播的模式，解读产业数字化转型中最受关注的平安问题，分享积攒多年的平安教训、饱经实战测验的解决方案与最佳实际，面向金融、批发、政务、泛互、交通、民航等各行各业，提供针对性的实用防护倡议，助力企业赢在产业转型的起跑线。

作者 | 王庆璨（阿里云技术专家）、张凯（阿里云高级技术专家） 导读：阿里云容器服务团队结合多年 Kubernetes 产品与客户支持经验，对 Kube-scheduler 进行了大量优化和扩展，逐步使其在不同场景下依然能稳定、高效地调度各种类型的复杂工作负载。《进击的 Kubernetes 调度系统》系列文章将把我们的经验、技术思考和实现细节全面地展现给 Kubernetes 用户和开发者，期望帮助大家更好地了解 Kubernetes 调度系统的强大能力和未来发展方向。 前言Kubernetes 已经成为目前事实标准上的容器集群管理平台。它为容器化应用提供了自动化部署、运维、资源调度等全生命周期管理功能。经过 3 年多的快速发展，Kubernetes 在稳定性、扩展性和规模化方面都有了长足进步。尤其是 Kubernetes 控制平面的核心组件日臻成熟。而作为决定容器能否在集群中运行的调度器 Kube-scheduler，更是由于长久以来表现稳定，且已能满足大部分 Pod 调度场景，逐渐不被开发人员特别关注。 伴随着 Kubernetes 在公有云以及企业内部 IT 系统中广泛应用，越来越多的开发人员尝试使用 Kubernetes 运行和管理 Web 应用和微服务以外的工作负载。典型场景包括机器学习和深度学习训练任务，高性能计算作业，基因计算工作流，甚至是传统的大数据处理任务。此外，Kubernetes 集群所管理的资源类型也愈加丰富，不仅有 GPU，TPU 和 FPGA，RDMA 高性能网络，还有针对领域任务的各种定制加速器，比如各种 AI 芯片，NPU，视频编解码器等。开发人员希望在 Kubernetes 集群中能像使用 CPU 内存那样简单地声明和使用各种异构设备。 总的来说，围绕 Kubernetes 构建一个容器服务平台，统一管理各种新算力资源，弹性运行多种类型应用，最终把服务按需交付到各种运行环境（包括公共云、数据中心、边缘节点，甚至是终端设备），已然成为云原生技术的发展趋势。 早期方案首先，让我们来了解一下 Kubernetes 社区都有过哪些提升调度器扩展能力的方案。 要统一管理和调度异构资源与更多复杂工作负载类型，首先面对挑战的就是 Kube-scheduler。在 Kubernetes 社区里关于提升调度器扩展能力的讨论一直不断。sig-scheduling 给出的判断是，越多功能加入，使得调度器代码量庞大，逻辑复杂，导致维护的难度越来越大，很多 bug 难以发现、处理。而对于使用了自定义调度的用户来说，跟上每一次调度器功能更新，都充满挑战。 在阿里云，我们的用户遇到了同样的挑战。Kubernetes 原生调度器循环处理单个 Pod 容器的固定调度逻辑，无法及时的支持不同用户在不同场景的需求。所以针对特定的场景，我们会基于原生的 Kube-scheduler 扩展自己场景的调度策略。 最初对于 Kube-scheduler 进行扩展的方式主要有两种，一种是调度器扩展（Scheduler Extender）， 另外一种是多调度器（Multiple schedulers）。接下来我们对这两种方式分别进行介绍和对比。 ...

作者 | 右京  阿里云交付专家 导读：云原生是什么？相信不同的人有不同的认识和解读。本文结合大家的各种讨论及项目实践经验，从交付的角度，分享阿里交付专家对云原生的理解，阐述如何构建云原生应用，云原生有哪些关键技术，以及关于云原生落地的思考。 前言Internet 改变了人们生活、工作、学习和娱乐的方式。技术发展日新月异，云计算市场风起“云”涌，从最初的物理机到虚拟机（裸金属） ，再到容器（Container），而互联网架构也从集中式架构到分布式架构 ，再到云原生架构。如今 “云原生” 被企业和开发者奉为一种标准，并被认为是云计算的未来，让我想到一句话：“未来已来，只是分布不均”。 伴随着 “云原生” 技术（架构）越来越火，火得一塌糊涂，每个人对它的理解都各不相同，网上和阿里内部关于 Cloud Native 的相关文章和讨论也非常多。不过，我发现大家对于云原生的定义、理解及实践还处于探索阶段，还没有一个非常明确或者顶层设计的标准化定义。 最近参与了一个上云项目，里面用到很多云原生的技术，借此机会结合大家的各种讨论，以及项目中的实践，聊一下个人对于云原生的一些粗浅思考。 追本溯源在正式讨论之前，我们不妨先来看看几位网红主播是怎么定义云原生的。 1. Pivotal 的定义Pivotal 公司是敏捷开发领域的领导者（曾经 Google 也是其客户），出生名门（EMC、VMware等投资），是标准的富二代。它推出了 Pivotal Cloud Foundry（2011 ~ 2013 PAAS 界网红） 和 Spring 生态系列框架，也是云原生的先驱者和探路者（开山鼻祖）。云原生具体定义如下图： Pivotal 公司的 Matt Stine 于 2013 年首次提出云原生（Cloud Native）的概念。2015 年，云原生推广时，Matt Stine 在《迁移到云原生架构》的小册子中定义了符合云原生架构的几个特征：12 因素应用、微服务架构、自敏捷架构、基于 API 协作、抗脆弱性。到了 2017 年，Matt Stine 改了口风，将云原生架构归纳为：模块化、可观测性、可部署性、可测试性、可处理性、可替换性等 6 大特征。而 Pivotal 最新官网对云原生概括为 4 个要点：DevOps、持续交付、微服务、容器。 2. CNCF 的定义CNCF（Cloud Native Computing Foundation，云原生基金会）相信大家已经非常熟悉。它是由开源基础设施界的翘楚 Google、RedHat 等公司共同牵头发起的一个基金会组织，其目的非常明确，就是为了对抗当时大红大紫的 Docker 公司在容器圈一家独大的局面，具体情况（有很多故事）不在这边细说了。CNCF 通过 Kubernetes 项目在开源社区编排领域一骑绝尘，之后就扛起了云原生定义和推广的大旗，风光无限。云原生具体定义如下： ...

根据 IDC 报告显示：2019 年国内容器基础架构软件市场规模约为 7340 万美元，其所带来的容器相关市场的收入将达到 4-5 亿美元，未来 5 年容器基础架构软件市场将以 56.1% 的复合增长率呈爆发式增长，并渗透到更多垂直行业。 我们发现容器逐渐成为了企业数字化转型的标配，这在 Sysdig 的 2019 年容器使用报告中也得到了验证，50% 以上的用户的容器规模超过了 250 个，9% 用户管理的容器数量超过了 5000，单个主机中容器的数量比去年增加了一倍，单个节点的最大密度是 250 个容器。 目前国内的容器厂商大致可以范围四类：一是独立软件厂商，它们将容器作为重点拓展的新领域，例如 RedHat、IBM、VMware 等；二是传统 IT 厂商，拥有基于 OpenStack 云系统软件，云解决方案从 IaaS 层向基于容器的 PaaS 层拓展，落地了容器 /PaaS 平台；三是公有云厂商，几乎所有的公有云厂商都会提供容器服务；四是以容器为重心的创业公司。 这其中有一家公司比较特殊，它既是传统 IT 厂商，同时也提供公有云容器服务，它就是华为云。本文将为大家解读华为云在容器领域的战略布局，并探讨云计算新方式：容器 + 裸金属会是未来的新趋势吗？ 为什么华为云容器服务的关键词是全栈式？相信细心的读者都发现了，华为云容器服务中最常出现的关键词就是“全栈式”。这个“全栈式”到底应该如何理解？又对应了华为云的哪些产品和服务呢？ 华为云容器域总经理方璞表示：“全栈式容器的渊源大致可以追溯到 5 年前，那时大家普遍认为容器是和 Docker 划等号，用了 Docker 就是用了容器；3 年前，容器编排系统逐渐崛起，大家又把容器和 Kubernetes 画上了等号。而我们从一开始就认为容器是全栈式的，无论是 Docker 还是 Kubernetes 都是容器技术的一部分。” 具体来看，华为云全栈容器服务大致可以分成三层：基础设施层、容器相关衍生技术以及适合领域解决方案和产品。 基础设施层主要指的是托管式 Kubernetes。华为云提供了四大产品：云容器引擎（Cloud Container Engine）提供高度可扩展的、高性能的企业级 Kubernetes 集群，支持运行 Docker 容器；云容器实例（Cloud Container Instance）提供基于 Kubernetes 的 Serverless 容器服务，兼容 K8s 和 Docker 原生接口；以及面向混合云客户的 CCE@华为云 Stack 和面向边缘计算的智能边缘平台 IEF。 ...

作者 | 新胜  阿里云技术专家 导读：OpenYurt 开源两周以来，以非侵入式的架构设计融合云原生和边缘计算两大领域，引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt，一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区，另一方面也希望加速云计算向边缘延伸的进程，并和社区共同探讨未来云原生边缘计算架构的统一标准。为了更好地向社区和用户介绍 OpenYurt，我们特地推出【深度解读OpenYurt】系列文章，本文为系列文章的第三篇，一一介绍了 OpenYurt 中组件 YurtHub 的扩展能力。 系列文章推荐： OpenYurt 开箱测评 | 一键让原生 K8s 集群具备边缘计算能力深度解读 OpenYurt ：边缘自治能力设计解析OpenYurt 介绍阿里云边缘容器服务上线 1 年后，正式开源了云原生边缘计算解决方案 OpenYurt，跟其他开源的容器化边缘计算方案的区别在于：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，对 Kubernetes 系统零修改，并提供一键式转换原生 Kubernetes 为 openyurt，让原生 K8s 集群具备边缘集群能力。 同时随着 OpenYurt 的持续演进，也一定会继续保持如下发展理念： 非侵入式增强 K8s保持和云原生社区主流技术同步演进YurtHub 架构说明在上篇文章中，我们介绍了 OpenYurt 的边缘自治能力，重点解读了其中的组件 YurtHub。其架构图如下： 同时在介绍 YurtHub 的优势中我们提到 与 Kubernetes 设计理念契合，YurtHub 非常容易扩展出更多的能力。具体在 YurtHub 扩展出了什么能力呢？接下来我们将一一展开介绍。 YurtHub 的扩展能力1. 边缘网络自治首先介绍一下何谓边缘网络自治：即在边缘和云端网络断连时，不管时业务容器重启，或是边缘节点重启等，边缘业务的跨节点通信可以持续工作或是自动恢复。 在 OpenYurt 中，实现边缘网络自治需要解决如下的问题（以 flannel vxlan overlay 网络为例）： ...

作者 | 高相林、陈俊 业界要闻update TLDR for 1.19 to reflect deadline changes受疫情影响，Kubernetes 1.19 release 的发版延期了 3 周，调整到 August 25th。 修复 kube-controller-manager SSRF 相关漏洞公告kube-controller-manager 组件中存在 SSRF 漏洞 CVE-2020-8555。通过认证鉴权的攻击者可以通过控制节点（Master Node）网络向未经认证鉴权保护接口发起攻击，获取集群的任意信息。下列版本均在此 CVE 影响范围： kube-controller-manager v1.16.0~v1.16.8kube-controller-manager<v1.15.11Introducing CloneSet: Production-Grade Kubernetes Deployment CRDopenkruise 重磅推出生产级CRD - CloneSet：这个CRD将着重于解决无状态pod的各种使用中的问题。 CNCF 宣布首个中国原创项目 Harbor 毕业长期致力于云原生软件生态构建的云原生计算基金会 ( CNCF ) 今天宣布，Harbor 成为第 11 个毕业的项目。从孵化（ incubation ）级别晋升为毕业（ graduation ）级别的过程中，Harbor 展现了其使用率的不断提高、开放的治理流程、完整功能成熟度以及对社区持续性和包容性的坚定承诺。 上游重要进展Resetting managed fields and fieldtype解决老版本客户端发起的update/patch请求中 metadata.managedFields 字段回退的问题。 kubelet, kube-proxy: unmark packets before masquerading themkubelet, kube-proxy:  在做 masquerading 之前，先 unmark 所有的包。可以改善一些基于 VXLAN 网络插件的延时。 ...

作者 | Hongqi  阿里云高级技术专家 本文整理自《Serverless 技术公开课》，关注“Serverless”公众号，回复 入门 ，即可获取 Serverless 系列文章 PPT。 什么是 Serverless 架构？按照 CNCF 对 Serverless 计算的定义，Serverless 架构应该是采用 FaaS（函数即服务）和 BaaS（后端服务）服务来解决问题的一种设计。这个定义让我们对 Serverless 的理解稍显清晰，同时可能也造成了一些困扰和争论。 随着需求和技术的发展，业界出现了一些 FaaS 以外的其它形态的 Serverless 计算服务，比如 Google Cloud Run，阿里云推出的面向应用的 Serverless 应用引擎服务以及 Serverless K8s，这些服务也提供了弹性伸缩能力和按使用计费的收费模式，具备 Serverless 服务的形态，可以说进一步扩大了 Serverless 计算的阵营；为了消除冷启动影响，FaaS 类服务如阿里云的函数计算和 AWS 的 Lambda 相继推出了预留功能，变得不那么“按使用付费”了；一些基于服务器（Serverful）的后端服务也推出了 Serverless 形态产品，比如 AWS Serverless Aurora，阿里云 Serverless HBase 服务。这样看来，Serverless 的界线是有些模糊的，诸多云服务都向着 Serverless 方向演进。一个模糊的东西如何指导我们解决业务问题呢？Serverless 有一个根本的理念是一直没有改变的，即让用户最大化地专注业务逻辑，其它的特征如不关心服务器、自动弹性、按使用计费等，都是为了实现这个理念而服务。 著名的 Serverless 实践者 Ben Kehoe 这样描述 Serverless 原生心智，当我们在业务中考虑做什么时可以体会一下这种心智： 我的业务是什么？做这件事情能不能让我的业务出类拔萃？如果不能，我为什么要做这件事情而不是让别人来解决这个问题？在解决业务问题之前没有必要解决技术问题。在实践 Serverless 架构时，最重要的心智不是选择哪些流行服务和技术，攻克哪些技术难题，而是时刻将专注业务逻辑铭记在心，这样更容易让我们选择合适的技术和服务，明确如何设计应用架构。人的精力是有限的，组织的资源是有限的，Serverless 的理念可以让我们更好地用有限的资源解决真正需要解决的问题，正是因为我们少做了一些事情，转而让别人做这些事情，我们才可以在业务上做的更多。 ...

作者 | 承风 阿里巴巴高级前端技术专家 导读：建立结构化的思维，以结构化的模式驱动工作，以结构化的体系构建自身的能力，小到写 PPT、大到为业务提供更大价值，都是非常值得我们使用的模式。阿里巴巴数字供应链事业部高级前端技术专家 - 承风，将会在本文中和大家分享他在建立和践行结构化思维过程中的方法论。 引言在每年自评、汇报、工作中总会感受到一些结构化带来的问题： 老板问我当前做的事情怎么样了，我讲了合作中的难点、视觉风格问题、业务情况、代码质量······工作的进展，说了半小时，老板还是 get 不到我做的事情的情况和价值，是老板不在意这件事、还是我语言表达能力不行？我这一年做了很多事情，都有一定产出，但是跳出细节来看，发现对业务、对团队价值都不大，是我做得不好、还是运气不好做的事情不好？最近流行 codeless，我打算研究下可视化搭建；团队业务涉及到流程编排，我打算研究下 TMF······一年下来折腾了不少成果出来，似乎老板也没有很认可，是我不讨老板喜欢还是做的事情没价值？这些问题，根据我自己工作经验的总结，认为大都是对结构化认知不足和践行不佳导致的。 第一个问题：对事情的认知和表述结构化方面存在问题 - 结构化的思维相关问题；第二个问题：做事儿多而杂不成体系 - 结构化的工作模式问题；第三个问题：学习和成长缺乏重点 - 结构化的能力建设的问题。关于结构化Structured：建立中心（问题、目标）。以中心的核心要素对中心进行分解，形成分类子结构。以一定的范式、流程顺序进行分类子结构的合理分类、减少非关键分类结构；对关键分类子结构进行分析，寻找对策，制订行动计划。 同理，逆向的顺序，对多种杂乱的内容，进行分类、剪枝、归纳汇总成一个中心。我认为也是结构化。 有很多相关的书籍： 领导者之剑：成功人士的 5 大突破思维技巧、金字塔原理、极简思考：来自世界顶尖咨询公司的高效工作法······ 也可以参看很多结构化的应用方式：结构化面试、结构化金融产品设计、结构化系统开发方法······从多行业多领域的使用可以反思和加深自己的认知。 在工作中认知和践行结构化结构化的理论是简单清晰的（道的层面总是比较简洁），但实际应用中如何进行结构化、最有效的使用结构化却有很多经验（术的层面总是多变的）。在此结合我个人的经验给出一些建议： 1. 建立中心当我们接手一个业务需求、面对一项挑战的时候，应当先思考这个需求的核心目标是干嘛的。 1）结构化的建立中心思考的过程也是结构化的，我通常会分解为两个子结构进行： 这个业务需求当前的目标是什么（事的维度）：1. 目标是快速完成上线试一试业务效果：目标事的维度为高效稳定上线；2. 目标是建立后续业务铺开的基础方案：目标事的维度是强架构设计下的核心与功能拆分方案；为什么需要我来做（人的维度）：1. 是因为我工作量还有 buffer 所有承担这部分：目标人的维度是完成职能范畴内的工作；2. 是因为我在这方面技术比较擅长：目标人的维度是利用事情强化自身能力和使用能力把事儿做好。2）沿中心上行对单个业务需求而言，从事、人两个维度建立起的中心即其核心，是最主要部分，建立一颗结构树的基础。但我们不应当停止于此，还应当向上推导：这个需求在整个业务的范畴内，是在哪一层次，哪一分类的。即应当更高层面、或整体业务和行业发展，对这方面业务是怎样的期许。（价值的维度） 一个团队接手某项业务或需求，其背后都会有思考：我们是期望借着这个业务打造一个平台，提升整体行业的表现；还是突击这个业务方向，占领局部的商业蓝海······接到一个需求时一定要思考更大层面这事的价值，才能更好的判断优先级、做事模式。例如：我们做采购系统，当前需求是，提供采购单列表，按总价范畴搜索单据的能力。按结构化的中心建立，它是：高效稳定上线（事）、我职能范围内的工作（人）。 如果止步于单个需求建立的中心，我们后续的分解应当是如何快速搞定、如何更稳定······如果我们继续向上构建树，我们可以和产品、使用者深度沟通下为什么要做价格搜索：1. 管理员期望能看到高价订单的情况。那么这个需求的上一个中心节点应当是：管理提效；2. 继续向上，是基于什么原因需要做管理提效？因为防止贪腐、提高工作效率。那么上一个中心节点应当是：降低成本；3. 依次向上，直到抵达整个业务的目标。比如总结觉得，我们的业务是构建一个集成高效的集团采购系统；再以此反思：1. 降低成本是不是当前工作的重点？团队是否有足够的架构设计和人员组织来支撑？2. 下一步到到管理提效层面，订单的搜索是否真的是当前最佳的提效工具，因为用户如何定义高价格？他执行这种搜索式查阅工作是否真的是有效不遗漏的？查阅到了订单有问题他能做什么？······我们会发现这个需求背后更多的问题。我们也可以沿着更大的中心树，去思考是否构建更好的方案可以更根本的解决这个问题；  再回过头来看当前的任务，是否真的是高效稳定上线（事）、我职能范围内的工作（人）。或者当前最紧急的部分（用户直接需求嘛）是高效稳定上线（事）、我职能范围内的工作（人），但后续更要做更多的其他的根本性解决方案。 沿当前的中心向上建立更大的结构化的认知体系： 会让我们对当前事情的判断（中心）更加清晰，也有更好的认知基础，极有利于与合作方的沟通碰撞和内容创新；建立更大结构化认知体系的过程，也是深入业务、扩展认知力的过程。一定要多和老板、业务方交流，从各自认知的差异性上提升自身的认知能力。此外，构建更大认知体系，对个人和团队发展也是有价值的。 很多时候我们忙于业务实现，都没有花时间去思考业务的价值。一部分是因为忙，一部分是因为懒，一部分是因为不懂，一部分是因为我们是来做事拿工资的，而不是带着愿景想把事做好的。这都不是真正能把事情做好的方式；作为团队的一员，我们不应当只做“花时间、生鸡蛋”的极低人效、技术外包的母鸡模式，而应当积极的尝试做“建机器、铺厂房、出产品”的工厂模式。这对业务和个人的发展才是积极的作用。2. 中心的分解建立完成中心后，有多种对中心进行分解的方式。其目标在于将中心拆解为多个内聚的子部分。整体思想是 MECE（Mutually Exclusive Collectively Exhaustive）原则，即相互独立，完全穷尽不重叠、不遗漏的分类。够借此有效把握问题的核心，并成为有效解决问题的方法。 下文是一些分解方案的简介。1）SWOTSWOT 分析方法又称态势分析法：即 Strengths（优势）、Weaknesses（劣势）、Opportunities（机会）、Threats（威胁）四类。最早用于进行企业竞争态势分析，对个人而言用于分析自身的竞争态势也是极佳的。 （对团队数据可视化能力建设的 SWOT 分析示例） SWOT 分析法四个象限可以分别分类四大独立的方面，而其中 SW 部分 - 优势劣势一般用于分析内部条件；OT 部分 - 机会威胁一般用于分析外部情况。又形成了两个独立而全覆盖的大类分隔。非常有助于看清楚当前的情况。 此外，SWOT 形成的象限又可以结合跨大类进行组合分析： ...

作者 | 孔德慧（夏莞）  阿里云函数计算开发工程师 本文整理自《Serverless 技术公开课》，关注 Serverless 公众号，回复“入门”，即可获取 Serverless 系列文章 PPT。 什么是函数计算？大家都了解，Serverless 并不是没有服务器，而是开发者不再需要关心服务器。下图是一个应用从开发到上线的对比图： 在传统 Serverful 架构下，部署一个应用需要购买服务器，部署操作系统，搭建开发环境，编写代码，构建应用，部署应用，配置负载均衡机制，搭建日志分析与监控系统，应用上线后，继续监控应用的运行情况。而在 Serverless 架构下，开发者只需要关注应用的开发构建和部署，无需关心服务器相关操作与运维，在函数计算架构下，开发者只需要编写业务代码并监控业务运行情况。这将开发者从繁重的运维工作中解放出来，把精力投入到更有意义的业务开发上。 上图展示了函数计算的使用方式。从用户角度，他需要做的只是编码，然后把代码上传到函数计算中。上传代码就意味着应用部署。当有高并发请求涌入时，开发者也无需手动扩容，函数计算会根据请求量毫秒级自动扩容，弹性可靠地运行任务，并内置日志查询、性能监控、报警等功能帮助开发者发现问题并定位问题。 函数计算核心优势 1. 敏捷开发使用函数计算时，用户只需聚焦于业务逻辑的开发，编写最重要的 “核心代码”；不再需要关心服务器购买、负载均衡、自动伸缩等运维操作；极大地降低了服务搭建的复杂性，有效提升开发和迭代的速度。2. 弹性扩容函数计算根据请求量自动进行弹性扩容，无需任何手动配置；毫秒级调度计算资源，轻松应对业务洪峰。3. 稳定高可用函数计算分布式集群化部署，支持多可用区；如果某个可用区因自然灾害或电力故障导致瘫痪，函数计算会迅速切换到同区域其他可用区的基础设施运行函数，确保服务高可用。4. 有竞争力的成本函数计算提供了丰富的计量模式，帮助您在不同场景获得显著成本优势；后付费模型按实际使用计算资源计费，不占用计算资源则不计费，资源利用率高达 100% ；预付费模型根据业务负载估算提前预购计算力，单价更低，组合使用后付费和预付费方式将有效降低成本。函数计算使用场景 从使用场景来说，主要有三类： Web 应用：可以是各种语言写的，这种可以是使用 Serverless 框架新编写的程序，也可以是已有的应用。比如可能是小程序后端，也可能是 Web API；对计算能力有很强的弹性诉求的应用：比如 AI 推理、音视频处理、图文转换等；事件驱动型的应用：比如通过其他阿里云产品驱动的场景，Web Hook、定时任务等。函数计算已经与很多产品进行了打通，比如对象存储、表格存储、定时器、CDN、日志服务、云监控等十几个产品，可以非常快速地组装出一些业务逻辑。 函数计算工作原理1. 函数计算调用链路 上图展示了函数计算完整的请求和调用链路。函数计算是事件驱动的无服务器应用，事件驱动是说可以通过事件源自动触发函数执行，比如当有对象上传至 OSS 中时，自动触发函数，对新上传的图片进行处理。函数计算支持丰富的事件源类型，包括日志服务、对象存储、表格存储、消息服务、API 网关、CDN 等。 除了事件触发外，也可以直接通过 API/SDK 直接调用函数。调用可以分为同步调用与异步调用，当请求到达函数计算后，函数计算会为请求分配执行环境，如果是异步调用，函数计算会将请求事件存入队列中，等待消费。 2. 函数计算调用方式 同步调用的特性是，客户端期待服务端立即返回计算结果。请求到达函数计算时，会立即分配执行环境执行函数。 以 API 网关为例，API 网关同步触发函数计算，客户端会一直等待服务端的执行结果，如果执行过程中遇到错误， 函数计算会将错误直接返回，而不会对错误进行重试。这种情况下，需要客户端添加重试机制来做错误处理。 异步调用的特性是，客户端不急于立即知道函数结果，函数计算将请求丢入队列中即可返回成功，而不会等待到函数调用结束。 函数计算会逐渐消费队列中的请求，分配执行环境，执行函数。如果执行过程中遇到错误，函数计算会对错误的请求进行重试，对函数错误重试三次，系统错误会以指数退避方式无限重试，直至成功。 异步调用适用于数据的处理，比如 OSS 触发器触发函数处理音视频，日志触发器触发函数清洗日志，都是对延时不敏感，又需要尽可能保证任务执行成功的场景。如果用户需要了解失败的请求并对请求做自定义处理，可以使用 Destination 功能。 ...

作者 | Andy Shi（阿里云高级技术专家）、天元（阿里云技术专家） 今年 5 月，阿里云和微软云共同宣布，Open Application Model （OAM） 社区携手知名混合云管理项目 Crossplane 社区，联合发布了 OAM 在 Kubernetes 平台上的标准实现与核心依赖库。本次合作达成后，OAM 社区成功的将标准应用定义和标准化的云服务管理能力统一起来，迈出了实现真正意义上的无差别云端应用交付的关键一步 。 去年 10 月 ，阿里云和微软共同推出了 OAM 项目，旨在构建围绕 Kubernetes 的云原生应用规范。OAM 描述了一个模型 —— 开发人员可以在其中定义应用程序组件；应用程序操作员负责创建这些组件的实例并为它们分配应用程序配置；基础架构运营商负责定义、安装和维护平台上可用的基础服务。  本次合作是阿里云、微软与 Crossplane 社区的三方技术合作，主要围绕 OAM 在 Kubernetes 上的标准实现以及 Crossplane 项目的 OAM 化展开。因为 Kubernetes 社区在落地 OAM 模型的过程中，提出了关于 OAM 标准实现的诉求。所以这次合作的一个重点，就是三方工程师使用 Go 语言开发了一个 OAM Kubernetes 核心依赖库。这个项目的名字叫做 oam-kubernetes-runtime。OAM Kubernetes Runtime 将会成为 OAM 社区官方维护的基础组件，目标是在 Kubernetes 上提供稳定且统一的 OAM 核心插件。  为进一步了解本次合作的细节以及 OAM 项目的现状，阿里云高级技术专家 Andy Shi 以及阿里云技术专家孙健波（花名：天元）接受开源中国的专访，共同探讨了 OAM 项目存在的意义。 ...

导读：在 2020 阿里云合作伙伴峰会上，阿里巴巴合伙人、阿里云智能基础产品事业部高级研究员蒋江伟发表了《深耕“被集成”，共建新生态》主题演讲，他在演讲中提到，阿里云将继续深耕“被集成”战略，做强生态，未来一年投入 20 亿专项资金，启动“云原生合作伙伴计划”，优选扶持 100 家头部合作伙伴，赋能 10000 家合作伙伴和 50 万开发者，共同服务百万云上客户，帮助合作伙伴实现云原生技术升级，合力加速百行千业实现数字化转型。 企业上云已经成为一种必然趋势。疫情之下，虽然各行各业都受到了不同程度的影响，但那些数字化能力健全的企业抵御风险的能力更强。经过此次疫情，越来越多的企业坚定了上云和实现数字化转型的信念和步伐，而云原生技术则是实现数字化转型的最短路径。 阿里云在全球领域内是云原生技术的定义者和领导者。目前，阿里云原生推出的技术栈已经覆盖了容器服务、Serverless 应用引擎、函数计算等技术，并结合自身在电商业务的生产实践进行了落地。借助阿里云原生产品，包括企业级分布式应用服务 EDAS、消息队列 MQ、性能测试 PTS、容器服务 ACK/ASK、Serverless 工作流、无服务器应用引擎 SAE 等云原生产品，可以加速企业数字化转型，享受云原生时代的技术红利。 “云原生合作伙伴计划”可以为企业带来哪些价值？「伯俊」成立于 1999 年，从成立之初就一直致力于零售相关的 IT 服务，并在零售行业有很深的积累，是规模最大、客户最多、口碑最好、技术最强的信息化建设服务商之一。伯俊软件 CEO 孙一晖曾表示，过去 20 年，伯俊积累了 3000 多个品牌客户，几乎所有的客户都在天猫上面做零售，所以伯俊和阿里巴巴的合作时间很长，但是和阿里云的合作，是始于 2017 年。在那一年，伯俊软件与阿里云全线展开深度合作，并提出了“All in 阿里云”的发展战略，与阿里云合作研发了 8 款联合解决方案，助力数千家零售企业以更低成本向数字化方向推进。其中，伯俊软件已成功交付的 20 多家企业级互联网中台客户，100% 基于阿里云。 伯俊软件为百丽国际打造的数字化营销解决方案，正是基于与阿里云合作开发的 CDP 数字化营销解决方案，可满足零售企业在顾客运营全链路覆盖、多渠道消费者数字信息的高效的 OneID 解决方案、自动化的精准营销活动等方面的需求，以支持企业在不断变化的市场需求中，进行数字化、精准化的营销。目前，该项目一期已经上线，百丽国际旗下滔搏运动已开始运作 CDP 并获得了显著成效。 日前，伯俊软件获得了阿里云原生合作伙伴认证授牌，双方将开展云原生技术的深度合作。成为阿里云云原生合作伙伴后，伯俊软件将基于阿里云丰富的云原生产品、高可用的基础架构支撑能力以及强大的安全服务，助力更多企业运用云原生技术加速数字化转型，快速落地“新基建”，实现业绩增长。 孙一晖表示，在这些项目中，不是阿里云签了合同然后再分给合作伙伴，而是阿里云找到合作伙伴联合研发产品，并一起向市场推出产品，这种合作思路给予了他们更大的空间。 「企加云」是另一家获得阿里云原生合作伙伴认证的公司。企加云消费者运营中台创立于 2017 年，专注在“消费者运营中台”领域，为企业提供“轻咨询+技术+运营”端到端方案。疫情以来，线上企业迎来业务快速增长，企业需要对市场做出快速响应，占领制高点，企加云基于云原生架构打造的消费者运营中台技术，帮助全时云会议、烨辉医药等企业实现按周迭代，系统快速支持亿级客户行为数据，在这一波市场红利中占得先机。 企加云一直是云原生架构的倡导者。通过加入阿里云原生合作计划，企加云将和阿里云深度携手，围绕阿里云原生技术栈的系列产品（EDAS、SAE、MQ、Kafka、MQTT、AMQP、ARMS、AHAS、PTS、函数计算、容器服务、Serverless 工作流等），展开销售、架构、开发、交付，运营等全方位合作。 正如企加云合伙人兼 CTO 罗义所言：“企加云将更加紧密的拥抱阿里云原生技术栈，在阿里云强大和深厚的技术加持下，不断深化云原生最佳实践，与阿里云一起，帮助更多的企业在数字化时代构建更加弹性、敏捷、稳定的系统。” 原“中间件合作伙伴计划”升级为“阿里云原生合作伙伴计划”，助力企业落地新基建据阿里云原生生态负责人宁晓民介绍，这次“阿里云原生合作伙伴计划”是原来“中间件合作伙伴计划”的一次重大升级，主要是包括三方面内容： 产品范围升级：在云原生技术浪潮之下，阿里云原生合作伙伴计划在技术先进性和产品定位上做了重大升级，从中间件技术向云原生技术的转变，从中间件驱动的阿里多年 双11 技术实践到云原生技术驱动 2019 年阿里集团核心系统 100% 上云，这充分证明了阿里云原生技术、产品体系的成熟。阿里云也希望通过云原生普惠的技术和产品帮助合作伙伴释放技术生产力。除了阿里中间件产品外，本次“阿里云原生合作伙伴计划”也覆盖了容器、微服务、Serverless、函数计算等众多产品；合作方式升级：在阿里云“做强生态”的战略指引下，以产品和解决方案“被集成”为核心，以帮助合作伙伴自身核心竞争力的成长为目标，阿里云原生合作伙伴计划从原来分销伙伴转变为解决方案伙伴，通过云原生技术和产品帮助伙伴的产品和解决方案技术换代，架构升级，让伙伴更加聚焦于自身业务优势，更好的发挥“长板效应”；合作权益升级：今年阿里云生态隆重推出“云聚计划”，投入 20 亿人民币，打造产品、技术、商务、交付的生态体系，阿里云原生合作伙伴计划对合作权益做了重点升级，计划重点扶持 100 家头部伙伴，赋能 10000 家伙伴，50 万开发者，在产品、技术、商务、交付等方面全方位地帮助伙伴能力成长。在这次峰会上，阿里云除了发布“云原生合作伙伴计划”之外，还发布了基础产品“企业工作台”合作计划。“企业工作台”以阿里云控制台为统一底座，提供丰富的阿里云 OpenAPI 能力，同时对外开放 CMDB、资源管理、身份管理、权限管理、审计合规的能力，生态伙伴可以在之上集成丰富多样的企业开发、运维、管控类工具软件。在传统模式下，一个 30 人的软件研发团队，基于企业工作台只需要 5 个人就足够了。同时企业工作台还把工具软件的权限管控统一收敛，用户不再需要把账号密码给到伙伴就能完成授权，最大程度地解决客户账号安全的问题。 ...

简介： 如果说，快递行业上半场的竞争拼的是规模、服务乃至价格，进入下半场，快递企业们还需要比拼硬核的技术实力。——周金龙（遥方） 随着云计算的快速发展和成熟，越来越多的企业正在把自己的核心系统向云上迁移，从而享受云计算带来的技术红利。IDC发布的《全球云计算IT基础设施市场预测报告》显示：2019年全球云上的IT基础设施占比超过传统数据中心，成为市场主导者。在技术层面，云计算在成本、稳定、安全和效率层面已经远超传统IT。对于企业而言，上云后综合成本下降一半，稳定性有10倍以上提升，安全性更是提升50倍。这些信号都在标志着以云计算为基础的数字化时代全面到来。 申通快递创建于1993年，是国内较早经营快递业务的民营快递品牌。与很多同行一样，早期的信息系统建设也采用外包承接的方式运作。2016年年底，申通快递正式登陆深交所。作为快递行业巨头之一，申通上市的目的，除了要把业务规模做大外，很重要的一点是要在技术上下功夫，打造公司核心的竞争力，构建行业的高生态壁垒，抵抗“外敌”入侵。 2019年年底，申通选择全面迁移至阿里云，也因此成为业内首个全面上云的快递企业。这次全面上云，不只是变革基础架构，更是对研发模式的一次重要变革。今年6月，申通通用云原生计算平台被云原生开源产业联盟、CNCF基金会联合选为“2020年度云原生应用十大优秀案例”之一。以下是关于申通快递核心业务系统云原生化上云的详解， 1、为什么要用云原生应用架构？快递公司是非常典型的云边一体架构，实操环节很重。大量的业务逻辑下沉到边缘，所以申通在上云改造过程中，也在尝试做云边一体化的架构升级。 通过云边一体，可以让开发在同一个平台上面完成云上业务及边缘侧的业务开发。同时快递公司还有典型的大数据处理场景，全网每天会新增几亿条扫描数据，需要对这些数据进行实时分析，对数据的处理要求非常高。 申通以前使用线下机房作为计算及数据存储平台，随着业务量的快速增长，原有的IT系统遇到了一些瓶颈，比如软件交付周期过长，大促保障对资源的要求高、系统稳定性差等。从申通内部看，基于传统IOE架构构建的系统无法支撑业务高速增长后的数据量膨胀，受限于容量订单系统，只能保留3~6个月的信息查询，且无法对历史包裹进行在线搜索，相关应用都会受阻。从外部看，包裹流转如何借助数据技术和IoT等技术来提升效率日益成为快递行业的竞争焦点。 云原生技术天然适合解决传统应用升级缓慢、架构臃肿、不能快速迭代等问题。具体来看，云原生有四点优势是企业迫切需要的，一是速度快，通过云原生技术可以做到业务快速上线部署，这就在市场需求多变的竞争中抢得了先机；另外，在业务爆发式增长的时候，云原生可以对资源的需求做到开箱即用。 二是提升业务的稳定性。通过监控埋点、业务日志收集、链路监控等手段可以保证业务系统在快速迭代过程中保持稳定性。依赖Kubernetes为核心的数据中心，通过应用编排、业务故障自愈的能力让整个系统更稳定。 三是节省资源。通过对计算资源的水位监测，结合业务的峰值情况，当发现资源利用率偏低时，采用降配规格及数量，降低整个资源的费用。相比于一次性投入租建机房及相应的维护费用，使用公有云成本投入更低。利用公有云低成本的硬件、无需关注基础设施、零交付周期的优势，结合容器技术可以做到业务实时按需动态伸缩资源。 四是采用微服务架构，将之前臃肿的架构进行合理拆分，再结合容器编排的能力做到持续交付，可以让企业成功转型成为一家Devops驱动的公司。 正是看中了云原生技术为企业带来的优势，最终申通选择核心系统以云原生化的方式上云。 2、申通云原生应用架构设计路线申通原来的IT架构是基于VMware+Oracle数据库的架构，与阿里云原生团队沟通后，决定采用基于Kubernetes的云原生架构体系。对应用服务架构进行，主要做了程序代码改造升级和引入云原生数据库。 程序代码改造升级申通程序代码改造升级主要两部分升级，一是应用容器化，跟虚拟机比起来，容器可以同时提升效率和速度，让其更适合微服务场景。引入容器技术，解决了环境不一致的问题，保证应用在开发、测试、生产环境的一致性。二是微服务改造，原来，申通的很多业务是基于Oracle的存储过程及触发器完成，系统之间的服务依赖也是依靠数据库OGG同步完成。这么做带来的问题就是系统维护非常困难，稳定性非常差。通过引入Kubernetes的服务发现来做微服务方案，按业务域进行拆分，使整个系统更易于维护。 引入云原生数据库方案通过引入OLTP和OLAP型数据库，将在线数据与离线分析逻辑拆到两种数据库中，不再完全依赖Oracle。这就解决了在历史数据查询场景下Oracle支持不了的业务需求。综合考虑申通业务和技术特点，最终选择了阿里云ACK+神龙+云数据库的云原生解决方案，实现核心应用搬迁上阿里云。申通云原生应用技术框架如下图所示。 在基础设施层面，全部的计算资源取自阿里云的神龙裸金属服务器，相比于ECS，Kubernetes搭配神龙服务器能够获得更佳的性能及更合理的资源利用率。特别适合大促场景，云上资源可以按量付费，大促结束之后资源使用完就释放。相比于线下自建机房和常备机器，云上资源操作更方便，管理成本也更低。 在流量接入层面，共有2套流量接入，一套是面向公网请求，另外一套是服务内部调用。域名解析采用云DNS及PrivateZone。借助Kubernetes的Ingress能力来做统一的域名转发，这样可以节省公网SLB的数量便于运维管理。 在平台层，申通基于Kubernetes打造的云原生PaaS平台如下图所示。 该平台的特点如下： • 测试、集成、预发、生产统一环境，打通DevOps闭环。 • 天生资源隔离，机器资源利用率高。 • 流量接入可实现精细化管理。 • 集成了日志、链路诊断、Metrics平台。 • 统一ApiServer接口和扩展，天生支持多云跟混合云部署 在应用服务层，每个应用都在Kubernetes上面创建单独的一个Namespace，应用跟应用之间资源隔离。通过定义各个应用的配置YAML模板，当应用在部署的时候直接编辑其中的镜像版本即可快速完成版本升级，当需要回滚的时候直接在本地启动历史版本的镜像就能快速回滚。 在运维管理上，线上Kubernetes集群都是采用了阿里云托管版容器服务，免去了运维Master节点的工作，只需要制定Worker节点上线及下线流程即可。同时上面跑的业务系统均通过PaaS平台完成业务日志搜索，按照业务需求投交扩容任务，系统自动完成扩容操作，降低了直接操作Kubernetes集群带来的风险。 云原生应用服务特点1、 API接口化API接口化应用场景主要有两个，一是封装Kubernetes管控API：包括创建StatefulSet，修改资源属性，创建Service资源等，通过封装这些管控API，可以通过一站式的PaaS平台来管理在线应用。二是云原生业务系统，云上的业务系统封装了各类云资源的API，如封装SLS的API，将在线数据写入SLS再跟Maxcompute或Flink集成。封装OSS的API，方便在应用程序中将文件上传。 2、应用和数据迁移云上的业务系统及业务中间件都是通过镜像的方式部署，应用的服务通过Service发现，全部的在线应用（300+）对应的Pod及Service配置均保存在PaaS平台里面，每个应用历史版本对应的镜像版本都保存到系统中，可以基于这份配置快速构建一套业务生产环境。数据迁移如下图所示。 通过DTS工具将业务系统的数据从IDC存储及增量迁移到云上。在线数据稳定地存储在云原生的数据库上面，如OLTP类型的RDS、PolarDB支撑高并发的实时处理，OLAP类型的ADB支持海量数据分析。同时对于小文件存储保存在OSS上面。引入NAS做共享存储介质，通过Volume直接挂载到神龙节点来实现应用数据共享。 3、服务集成云原生PaaS服务集成如下图所示。 持续集成通过Git做版本控制，利用云效的持续集成功能实现了云原生应用的构建、编译及镜像上传，全部的业务镜像均保存在云端的镜像服务仓库，底层是Kubernetes集群作为整个业务的计算资源。其他集成的服务包括： • 日志服务，通过集成日志服务方便研发人员方便定位业务及异常日志。 • 云监控，通过集成监控能力，方便运维研发人员快速发现故障。 • 服务接入，通过集成统一的接入，整个应用流量可做到精细化管理。 • 弹性伸缩，借助ESS的能力对资源进行动态编排，结合业务高低峰值做到资源利用率最大化。 4、服务高可用ACK集群多层级高可用示意如下图所示。 架构说明： • 支持多可用区部署架构，由用户自定义分配比例。 • 容器集群内故障迁移。 • AZ故障整体容器迁移。 Kubernetes集群通过控制应用的副本数来保证集群的高可用。当某个Pod节点出现宕机故障时，通过副本数的保持可以快速在其他Worker节点上再启新的Pod。通过引入监控体系主动发现业务问题，快速解决故障。监控采集示意如下图所示。 在同一个Pod里面部署了两个容器，一个是业务容器，一个是Logtail容器。应用只需要按照运维定的目录将业务日志打进去，即可完成监控数据采集。 技术创新点1、从虚拟机到Kubernetes相比于通过虚拟机来运维应用，Kubernetes可以将各类资源定义成描述文件，整个应用环境通过容器的方式统一，避免环境不一致的风险。通过修改副本数即可轻松完成应用容器的扩缩容操作。Kubernetes提供了一个非常容易的机制来帮助用户打包应用，并且能快速部署到任意一个环境中，实现快速扩容、缩容的目的。 2、从单体应用到微服务单体架构，系统与系统之间是紧耦合模式。随着代码库的不断加大，添加或者改变单体应用程序的功能就变得越来越复杂。而微服务架构是松耦合状态，每一个团队做一个服务，每个服务执行一个功能，系统与系统之间是相互独立的状态，可以让不同的团队开发不同的服务，通过轻量级的API调用来实现服务与服务之间的串联。对某个服务进行扩展，只扩展单个系统就能实现，修改代码也不影响其他应用。 3、基于Terway让Pod和ECS网络处于同等地位优势：不依赖VPC路由表，就能打通网络，节点规模不受路由表Quota限制；不需要额外为Pod规划Overlay的网段；混合云专线打通也无需额外配置路由；可以直接将POD挂到SLB后端；性能高，相比于社区的Flannel提升至少10%。 4、定义三套接入环境及三套业务环境定义三套环境主要是为了解决研发环境的问题，定义日常、预发、生产环境，方便研发做测试回归；定义三套业务环境主要是为了网络接入方便，这样内部应用可以走内部接入，从网络隔离上面保护系统。 三套接入环境包括公网接入、办公网接入、内网接入。 公网接入：适合于跟外部客户对接，通过统一的证书卸载，收敛公网IP。 办公网接入：适合于有敏感接口的对接，只允许指定源IP的请求，通过网络ACL让整个应用访问更安全。 内网接入：适合于业务之间及混合云架构下IDC的业务调用云上应用，内部调用性能更高也更安全。 三套业务环境包括测试环境、预发环境、生产环境。 测试环境：全部的云资源都是给测试环境使用，可以采用低配资源来满足功能回归测试。 预发环境：准上线环境，连接生产环境的资源进行发布前最后一次功能验证。 生产环境：实际运行环境，接收真实流量处理业务请求。 ...

作者 | 不瞋  阿里云高级技术专家 导读：Serverless 是如何产生的？当前有哪些落地场景？Serverless 的未来又将如何？本文分享了阿里云高级技术专家不瞋对于 Serverless 的看法，回顾其发展历程，并对 Serverless 的发展趋势做出预测。 源起回望整个计算机技术发展史，我们会发现 “抽象、解耦、集成” 的主题贯穿其中。产业每一次的抽象、解耦、集成，都将创新推向新的高度，也催生出庞大的市场和新的商业模式。 大型机时代，硬件和软件都是定制化的，使用专有的硬件、操作系统和应用软件。 PC 时代，硬件被抽象解耦成 CPU、内存、硬盘、主板、USB 设备等标准化的部件，不同厂商生产的部件可以自由组合，组装成整机。软件被抽象解耦为操作系统、库等可复用组件。硬件和软件的抽象解耦，创造了新的商业模式，释放了生产力，造就了 PC 时代的繁荣。 云的时代，硬件软件化和软件服务化成为最显著的两个趋势。 硬件软件化的核心在于硬件功能中越来越多的部分由软件来呈现，从而在迭代效率、成本等方面获得显著优势。以软件定义存储（Software Defined Storage，SDS）为例，SDS 是位于物理存储和数据请求之间的一个软件层，允许用户操控数据的存储方式和存储位置。通过硬件与软件解耦，SDS 可运行于行业标准系统或者 X86 系统上，意味着用户可以无差别的使用任何标准的商用服务器来满足不断增长的存储需求。硬件与软件解耦也让 SDS 能够横向扩展，消除容量规划，成本管理等方面的复杂性。 云时代的另一趋势是软件服务化。应用软件的功能通过网络以远程调用的模式被海量用户使用。服务成为应用构建的基础，API 被实现为服务提供给开发者，微服务架构获得广泛的成功。服务也成为云产品的基本形态。过去 10 年，云已经证明了它的成功。用户只需要通过调用 API 就能获取服务器，而无需自己建设数据中心。算力以前所未有简洁的方式提供给用户。 还记得 Google 那篇著名的 “Datacenter as a computer “ 论文吗？如果我们把云看作是 DT 时代的计算机，那么一个很自然的问题是：随着云的 API（全托管服务）越来越丰富，什么才是适合于云的编程模型？我们应当以何种 “抽象、解耦、集成” 的方式构建基于云的应用？ 在回答上述问题之前，让我们首先将目光转向 SaaS 领域。Salesforce 是 SaaS 领域的明星企业，在平台化能力建设方面的布局为我们提供了一个绝佳的案例。早期的 SaaS 产品采用标准化的交付模式，通过开放 API 接口实现被集成的能力。随着 Salesforce 产品越来越丰富，客户规模日益增长，企业开始面临新的挑战： 如何更快地推出新产品，加强产品间的整合和协同？客户迅速增长，需求多样。如何高效地满足客户的定制化需求，增加客户粘性？如何提高产品被集成的能力，更好的衔接上下游资源？当产品能力和 API 完整度到达一定水准后，如何让开发者快速整合 API，围绕 Salesforce 能力便捷地开发应用？如何设计好的商业模式，让客户、企业和开发者共赢？Salesforce 的策略是让整个业务、技术和组织平台化。平台放大了企业的价值，让企业、客户、开发者三方受益。通过不断提升平台的应用交付能力，对内大幅提高产品的研发效率，加强产品的集成和整合；对外则大幅提高了产品的被集成能力，建立开发者生态。 ...

伴随云计算的滚滚浪潮，云原生(CloudNative)的概念应运而生，云原生很火，火得一塌糊涂，都0202年了，如果你还不懂云原生，那真的out了。 大家言必称云原生，却鲜少有人告诉你到底什么是云原生，若是找资料来看，读完大多会感觉云绕雾罩，一知半解，总之虚得很；甚至会让你一度怀疑自己的智商，不过我对于读不懂的文章，一律归因于写文章的人太蠢，当然这不一定是事实，但这样的思考方式能让我避免陷入自我怀疑的负面情绪。 云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。 何谓云原生？技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。 Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。 2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。 可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，真是乱的一匹，搞得鄙人非常晕菜，我的应对很简单，选一个我最容易记住和理解的定义：DevOps+持续交付+微服务+容器。 总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。 云原生构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩。优点不一而足，缺点微乎其微；秒杀传统Web框架，吊打祖传IT模式，实在是保命**、评优晋级不可多得的终极绝密武器。 云元素的四要素微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，很玄乎，凡是能称为理论定律的都简单明白不了，不然就忒没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无关系。 微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。 容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌搞的，Docker和K8S都采用Go编写，都是好东西。 DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。 持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。 如何云原生？首先，云原生借了云计算的东风，没有云计算，自然没有云原生，云计算是云原生的基础。 随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。 云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。 1.本地部署的传统应用往往采用c/c++、企业级java编写，而云原生应用则需要用以网络为中心的go、node.js等新兴语言编写。 2.本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。 3.本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。 4.本地部署的传统应用对网络资源，比如ip、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。 5.本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。 6.本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。 7.本地部署的传统应用有些是单体(巨石)应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。 可见，要转向云原生应用需要以新的云原生方法开展工作，云原生包括很多方面：基础架构服务、虚拟化、容器化、容器编排、微服务。幸运的是，开源社区在云原生应用方面做出了大量卓有成效的工作，很多开源的框架和设施可以通过拿来主义直接用，2013年Docker推出并很快成为容器事实标准，随后围绕容器编排的混战中，2017年诞生的k8s很快脱颖而出，而这些技术极大的降低了开发云原生应用的技术门槛。 虽说云原生的推介文档有引导之嫌，但面对它列举的优点，作为杠精的我亦是无可辩驳。这么说的话，云原生也忒好了吧，应用是不是要立刻马上切换到云原生架构？我的观点是：理想很丰满，现实经常很骨感，需从应用的实际需要出发，目前的问题是否真的影响到业务发展，而推倒重来的代价能否承受得来。 技术的趋势和影响软件设计有两个关键目标：高内聚、低耦合，围绕这2个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则。 软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。 但后来，人们发现有更多的诉求，希望开发软件变得更简单、更快捷，程序员希望更少编写代码，非专业人员也希望能开发程序，于是，更多的更傻瓜的编程语言被发明出来，更多的编程技术和编程思想被发明出来，比如库、组件、云基础设施。 于是很多技术变成了屠龙之技，比如汇编，时代变了，建国后动物不能成精了，没有龙可以宰了，然后很多软件工程师摇身一变成了调参工程师、Call API砖家、用库包能手、拼组件达人，这是效率分工的结果，也是技术发展的使然。 纵观近二十年的科技互联网发展历程，大的趋势是技术下沉，特别是近些年，随着云计算的发展和普及，基础设施越来越厚实，业务开发变得越来越容易，也越来越没有技术含量，而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不禁让互联网行业的油腻大叔们噤若寒蝉，仿佛分分钟就要被卷入历史洪流而万劫不复。 虽然不可否认技术的重要性在降低，但也还不至于那么悲观。遥想PC时代，当VB、Delphi、MFC出现的时候，也有类似论调，所见即所得，点点鼠标，就可以开发PC桌面程序，是不是很高端？那时候码农的担心相比现在恐怕是只多不少吧，但后来随着互联网兴起，出现了后端开发这个工种，码农很快找到了新的战场，网络、分布式、数据库、海量服务、容灾防错，于是又玩出一堆新花样。 如果说PC时代的基础设施是控件库，互联网时代的基础实施是云，那AI时代基础设施是什么？又会有什么高端玩法？ 点击关注，第一时间了解华为云新鲜技术~

作者 | 阚俊宝 阿里云技术专家 导读：云原生存储详解系列文章将从云原生存储服务的概念、特点、需求、原理、使用及案例等方面，和大家一起探讨云原生存储技术新的机遇与挑战。本文为该系列文章的第二篇，会对容器存储的相关概念进行讲述，欢迎大家在留言区参与讨论。相关文章推荐： 云原生存储详解：云原生应用的基石云原生存储详解：容器存储与 K8s 存储卷云原生存储的两个关键领域：Docker 存储卷、K8s 存储卷； Docker 存储卷：容器服务在单节点的存储组织形式，关注数据存储、容器运行时的相关技术；K8s 存储卷：关注容器集群的存储编排，从应用使用存储的角度关注存储服务。Docker 存储容器服务之所以如此流行，一大优势即来自于运行容器时容器镜像的组织形式。容器通过复用容器镜像的技术，实现在相同节点上多个容器共享一个镜像资源（更细一点说是共享某一个镜像层），避免了每次启动容器时都拷贝、加载镜像文件，这种方式既节省了主机的存储空间，又提高了容器启动效率。 1. 容器读写层为了提高节点存储的使用效率，容器不光在不同运行的容器之间共享镜像资源，而且还实现了在不同镜像之间共享数据。共享镜像数据的实现原理：镜像是分层组合而成的，即一个完整的镜像会包含多个数据层，每层数据相互叠加、覆盖组成了最终的完整镜像。 为了实现多个容器间共享镜像数据，容器镜像每一层都是只读的。而通过实践我们得知，使用镜像启动一个容器的时候，其实是可以在容器里随意读写的，这是如何实现的呢？ 容器使用镜像时，在多个镜像分层的最上面还添加了一个读写层。每一个容器在运行时，都会基于当前镜像在其最上层挂载一个读写层，用户针对容器的所有操作都在读写层中完成。一旦容器销毁，这个读写层也随之销毁。 如上图所示例子，一个节点上共有 3 个容器，分别基于 2 个镜像运行。 镜像存储层说明如下： 该节点上共包含 6 个镜像层：Layer 1~6。 镜像 1 由：Layer 1、3、4、5 组成；镜像 2 由：Layer 2、3、5、6 组成。所以两个镜像共享了 Layer 3、5 两个镜像层； 容器存储说明： 容器 1：使用镜像 1 启动容器 2：使用镜像 1 启动容器 3：使用镜像 2 启动容器 1 和容器 2 共享镜像 1，且每个容器有自己的可写层；容器 1（2）和容器 3 共享镜像 2 个层（Layer3、5）； 通过上述例子可以看到，通过容器镜像分层实现数据共享可以大幅减少容器服务对主机存储的资源需求。 上面给出了容器读写层结构，而读写的原则： 对于读：容器由这么多层的数据组合而成，当不同层次的数据重复时，读取的原则是上层数据覆盖下层数据；对于写：容器修改某个文件时，都是在最上层的读写层进行。主要实现技术有：写时复制、用时配置。1）写时复制写时复制（CoW：copy-on-write），表示只在需要写时才去复制，是针对已有文件的修改场景。CoW 技术可以让所有的容器共享 image 的文件系统，所有数据都从 image 中读取，只有当要对文件进行写操作时，才从 image 里把要写的文件复制到最上面的读写层进行修改。所以无论有多少个容器共享同一个 image，所做的写操作都是对从 image 中复制后在复本上进行，并不会修改 image 的源文件，且多个容器操作同一个文件，会在每个容器的文件系统里生成一个复本，每个容器修改的都是自己的复本，相互隔离，相互不影响。 ...

作者 | 陈洁、高相林 业界要闻Kubernetes 文档增加反种族歧视声明所有 Kubernetes 相关的文档统一加上了反种族歧视的声明 Header，以表达社区坚决反对种族歧视的立场。此外，golang/kubernetes 均已将代码中的 whitelist/blacklist，master/slave 等关键词进行替换。 K8s 1.19.0-beta.1 将 code freezeKubernetes 1.19.0-beta.1 将于 6 月 25 日 code freeze，并开始进行 release 以及测试。 Linkerd 2.8 正式发布Linkerd 2.8 新增了多集群的功能支持，可以跨多个 Kubernetes 集群建立连接，并提供安全、透明以及独立于网络拓扑的 service。 上游重要进展CertificateSigningRequest v1 API增加了对 CertificateSigningRequest v1 API 的支持，包括 controller、client-go、kubectl 等。同时相比 CertificateSigningRequest v1beta1，CertificateSigningRequest v1 在 spec.signerName、spec.usages、status.conditions 等字段上有调整。 Support kubectl create deployment with replicaskubectl/client-go 支持显示/返回 server 端的告警。 Remove log message causing significant overhead on Preemption evaluationgeneric scheduler 删除了一部分日志输出，优化了 preemption evaluation 过程的性能。 ...

作者 | 周正喜  阿里云技术专家  爱好云原生，深度参与 OAM 社区 大家都知道，应用开放模型 Open Application Model（OAM） 将应用的工作负载（Workload）分为三种 —— 核心型、标准型和扩展型，这三者的主要区别在于一个 OAM 平台对于具体某一类工作负载进行实现的自由度不同。其中，OAM 社区中目前唯一一个核心工作负载是 Containerized Workload，它用来描述一个基于容器的工作负载，可以理解为是 Kubernetes Deployment 的简化版（去掉了 PodSecurityPolicy 等大量与业务研发无关的字段）。 不过，很多读者可能会有疑问：对于 Kubernetes 内置的工作负载 OAM 是否还能直接支持呢？ 答案当然是肯定的，而且这是 OAM 作为 Kubernetes 原生的应用定义模型的默认能力。 下面，本文就以 Deployment 为例，介绍如何使用 OAM 基于 Kubernetes 的内置工作负载来定义和管理云原生应用。 示例准备基于 GitHub FoodTrucks （旧金山美味街边小吃地图应用）项目，构建镜像  zzxwill/foodtrucks-web:0.1.1，加上依赖的 Elasticsearch 镜像，在默认情况下，它的 Deployment 描述文件  food-truck-deployment.yaml 如下所示： apiVersion: apps/v1kind: Deploymentmetadata: name: food-trucks-deployment labels: app: food-trucksspec: selector: matchLabels: app: food-trucks template: metadata: labels: app: food-trucks spec: containers: - name: food-trucks-web image: zzxwill/foodtrucks-web:0.1.1 env: - name: discovery.type value: single-node ports: - containerPort: 5000 - name: es image: docker.elastic.co/elasticsearch/elasticsearch:6.3.2 ports: - containerPort: 9200 - containerPort: 9300如果将上述 yaml 文件提交到 Kubernetes 集群，通过 port-forward 可以通过浏览器查看效果： ...

作者 | 王思宇（酒祝）  阿里云技术专家 参与阿里巴巴云原生文末留言互动，即有机会获得赠书福利及作者答疑！ 概念介绍原地升级一词中，“升级”不难理解，是将应用实例的版本由旧版替换为新版。那么如何结合 Kubernetes 环境来理解“原地”呢？ 我们先来看看 K8s 原生 workload 的发布方式。这里假设我们需要部署一个应用，包括 foo、bar 两个容器在 Pod 中。其中，foo 容器第一次部署时用的镜像版本是 v1，我们需要将其升级为 v2 版本镜像，该怎么做呢？ 如果这个应用使用 Deployment 部署，那么升级过程中 Deployment 会触发新版本 ReplicaSet 创建 Pod，并删除旧版本 Pod。如下图所示： 在本次升级过程中，原 Pod 对象被删除，一个新 Pod 对象被创建。新 Pod 被调度到另一个 Node 上，分配到一个新的 IP，并把 foo、bar 两个容器在这个 Node 上重新拉取镜像、启动容器。 如果这个应该使用 StatefulSet 部署，那么升级过程中 StatefulSet 会先删除旧 Pod 对象，等删除完成后用同样的名字在创建一个新的 Pod 对象。如下图所示： 值得注意的是，尽管新旧两个 Pod 名字都叫 pod-0，但其实是两个完全不同的 Pod 对象（uid也变了）。StatefulSet 等到原先的 pod-0 对象完全从 Kubernetes 集群中被删除后，才会提交创建一个新的 pod-0 对象。而这个新的 Pod 也会被重新调度、分配IP、拉镜像、启动容器。 ...

技术编辑：徐九丨发自 SegmentFault 思否 开源，一直是科技产业发展的一大驱动力，尤其是在 AI、大数据、云计算等新兴信息技术领域，协助企业实现快速创新和产品迭代。日前，明势资本举办了“Open Source Summit 2020”线上主题活动，聚集中外十余家开源领域新兴企业，畅谈开源软件的发展历程。SegmentFault 思否受邀成为本次会议的媒体支持伙伴。 会议中，Chris Aniszczyk 作为 Cloud Native Computing Foundation 的 CTO 和 COO，以《Cloud Native 2020 and Beyond》为题讲述了他对于开源软件发展的一些思路。他认为多云将变得更加跨云，中国化开源软件将会快速发展，越来越多的中国发起的标准化解决方案应运而生。 以下为本次会议的文字版本回放，有部分删改： 很高兴今天有机会与大家交谈，我很荣幸能在这里谈一谈CNCF、云原生技术以及我们在2020年及以后的发展方向。对于我演讲主题的简短议程，我想在回答一些大家稍后可能会提出的问题之前，先和大家谈一下云原生的兴起、发展和一些观点。 先为诸位介绍一下我个人的背景，我有幸作为执行董事与人共同创立了云原生计算基金会(CNCF)，现在担任首席技术官和首席运营官。我过去在Linux基金会中积极并深度参与了各种形式的活动。在过去的日子里，我担任各类开源项目的维护人员，hack进入Linux发行版 Fedora。因此，我从开源的维护者，到创始人，再到投资顾问，最后成为一个真正全领域运营开源基金会的人。 对于那些不了解Linux基金会的人们来说，CNCF是Linux基金会(LF)最大的组成部分之一，而LF本身就是一个世界性的基金会联盟。这可能是世界上最大的共享技术投资，取决于你如何计算。我们在全球40个国家拥有1600多名会员，《财富》榜100强里的科技和电信公司全部都是我们的会员。我们有300多个开放源码项目，横跨云计算到汽车、区块链到人工智能等各大细分领域。 我们主办了RISC-V基金会;我们拥有世界上最大的证书颁发机构：为2亿家网站提供TLS证书的非盈利性证书颁发机构-Let’s Encrypt.org。从美国、欧盟，再到中国北京，我们在全球各地都有设立国际化办公室。我们构建可持续开放源代码生态系统的模式真正关注的是围绕着托管开源项目形成一个循环，这些项目本质上是我们的会员组织生产的产品，最终通过雇用开发人员等方式将利润重新投资于项目社区。 因此，我们整个组织的建立使命就是为了实现这一良性的生命周期，我们认为这是将开源商业化和长期保持开源的最好方式。我们不仅在 Linux社区、Kubernetes，和我们在 Linux基金会运营的许多其他垂直行业都看到了这些验证，及喜出望外的成功。 正如诸位可能已经注意到的，自CNCF创建以来的这5年来，云原生的版图发生了令人难以置信的快速变化。就拿Kubernetes的发展趋势来说，它起初从一个当时被谷歌主导管理的“爱好者的测试项目”，快速演变成为一个真正专业的全行业平台，如今已被北美、欧洲和亚太地区的每一家主要云供应商所采用。如果你回过头来看，在当时其实有非常多不同的解决方案。我个人认为，像Kubernetes这样迅猛的行业变化和发展是相当罕见和令人兴奋的。 正如我刚才提及的，作为首席技术官和首席运营官来管理CNCF，这本事就是非常有趣的职位；更令人振奋的是，今年年底CNCF将迎来他的五岁生日。我们已经在全球有500名会员，其中50名会员来自中国，包括所有的云供应商在内，这使我们成为中国最大的开源组织之一；我们的一些开源项目就诞生于中国。 我们是一个相当大的开源组织——深入这个生态系统内去观察，我们拥有的为Kubernetes和云生态系统提供技术支持或产品的公司其数量是巨大而可观的，这其中的100家公司分布在世界各个角落，使我们的生态系统像蜘蛛网般庞大和紧密。对于我们的组织来说，另一个非常重要的独特之处是，我们是一个终端用户驱动的开源生态系统——不仅是供应商们在推动着创新，所有终端用户也都参与到组织的方方面面中去，这也将是我将讨论的关于开源的一个重要变化。 对于新加入的用户，我们已经开发了多种多样有趣的工具，我们很乐意与我们的社区共同分享。对于投资者/风险投资人来说，基于我们创立提供的云原生的版图，他们可以很容易地看到哪个项目正在募资，并预览这些项目在生态系统中千变万化的发展。在这里你就可以看到那些在我们的生态系统中正在融资的公司。 2020年的云原生和开源——我看到了什么？是的，如你所见，我们正真实的生活在一个令人无比兴奋的时代。开源的反周期性特性，使得其不论在困难时期或经济衰退期都能产生增长。我们见证着对开源的使用需求每一天都在增长。我们的Linux基金会丝毫没有放慢发展的速度。最近一次调查的数据显示，非常多的公司在疫情期间加大了对云资源的投资。这种趋势看上去有点违反人们的直觉，但我预测人们很快就会在云原生和开源领域看到惊人的增长。 另一件正在发生的事情——我们将看到云原生空间的整合加速。就在最近，企业网络安全服务提供商 Venafi 宣布收购 Jetstack，这只是整个CNCF生态系统中一个特定的整合并购案例。我们预期这种整合并购在变幻莫测、高速发展的云原生和开源体系内将愈加频繁。 Kubernetes和云原生生态系统正在向数据中心之外开疆扩土般扩展。我认为这之中不可忽略的一个重点是，Kubernetes是为跨多个数据中心、云等扩展软件而构建的。我们现在看到的是与Linux相似的发展趋势——Linux一开始只是一个爱好者操作系统，最终接管了服务器市场和 Android的嵌入式市场等等。 Kubernetes正在经历一个非常相似的生命周期，在这个生命周期中，始终是终端用户在边缘计算、电信、物联网等领域不停驱动。在我们的生态系统中有几个项目正在引领这一潮流——华为的KubeEdge，这是一个处理基于边缘部署的社区指导法，而Rancher的K3，我相信Sheng在这里会展开这一点探讨——这是我们在非常成功的大规模开源项目中看到的模式。就像Linux一样，终端用户将把开源项目推向更先进的、更新鲜有趣的各种垂直领域。 另一个重要趋势是终端用户驱动的开源。开源不仅仅来自于庞大的云端，很多公司要么已经对现有的解决方案不满意，要么自己直接构建一些东西来帮助他们扩展，这种趋势正如雨后春笋般迅速蔓延。 一个经典案例是，Lyft搭建的Envoy本身源于他们对Nginx的不满，所以他们决定建立自己的反向代理服务器，这已经真切发生在现实中。Uber已经构建了多元化技术方案，比如M3DB。你将看到越来越多类似的例子，因为传统意义上从供应商那里采购软件的终端用户公司已经越来越多得开始尝试自己开发并使用开源软件，量身定制并能快速直接地为自己解决问题，并与世界分享这些经验。 我们在Linux基金会做的研究表明，越来越多的公司不仅愿意使用开源软件，并且同时愿意为上游做出贡献自己进行开发。我认为这种情形终将持续下去。归根到底，许多终端用户往往无意于从自己开发的软件中盈利。拿Capital One举例，这家银行如果能将他们所使用的许多软件进行开源并得到其他人的帮助，为什么不呢? 随着云原生和CNCF的成熟，一个巨大的挑战是企业一直面临着一种进退两难的境地：每当一个相对新的软件被广泛部署的时候，公司就会不得不面对并处理与安全相关的事情和文化变迁的问题。各公司正忙着应对在云原生领域中围绕安全、存储等等产生的挑战。我们会看到更多这样的公司将不得不去解决这类复杂的情形，最痛苦的会是终端用户。 另一个现状是，多云的趋势已经变得更加真实了。从各种研究看来，许多大型组织正在使用来自不同云的服务，不管是来自知名的三大云还是全球其他各种云服务。跨云相关的部署模型正在普遍化发展——很多项目利用Kubernetes在每个主要的公共/私有云上都可部署的优势，通过公共应用程序界面（API）去构建非常先进并多元化的多云和跨云技术。 我最喜欢的一个例子是，一家名为Upbound的公司开发了一个名叫Crossplane.io的项目，该允许使用者横跨不同的云提供商去抽象化类似于S3服务的东西，并允许使用者根据自己的需求选择一个定制化服务。在我看来，Kubernetes API实际上已经成为云的可移植操作系统接口（POSIX），这决定着在不久的将来，人们将在多云和跨云领域看到更多这样令人激动的创新。 在我们的云原生世界中，另一件事情也在加速发展，我们在美国硅谷和其他公司身上也看到了这一点——工程师们开发出令人惊叹的可扩展的软件，先将其开源，然后围绕它建立公司。典型的例子有Netflix/Spinnaker/Armory, Airbnb with Superset/Preet。我们将持续看到这种加速，特别是在我们生活的这个新鲜有趣的时代。 ...

背景蚂蚁金服业务自定义监控是蚂蚁金服监控产品中的一个重要功能，主要是通过自定义日志数据源并配置大盘的方式来解决蚂蚁金服业务实时监控的需求。在产品功能上，用户可以通过对一系列日志数据源的创建、组织、管理及表单配置化的方式，简单、快速组织出一个多维监控大盘。这项能力在当时是一个具有创新性的能力，从功能到产品体验上很好解决了当时蚂蚁金服复杂业务监控的痛点。 但是，随着蚂蚁金服监控产品的不断迭代更新，以及云原生可观测性对于监控大盘的高要求，大家对自定义监控的体验诉求也越来越多，包括更便捷的交互方式、更丰富的图表、更丰富的数据源、更多扩展点等，因此对监控大盘的升级也势在必行。 本文将介绍蚂蚁金服监控产品在监控大盘方面的创新设计与尝试，新版自定义监控大盘 Barad-Dur 目标成为业界体验最优秀的自定义监控大盘，在交互、体验与设计理念上有诸多创新点，同时将以模块的形式发布，支持二次开发，可以同时为蚂蚁金服内外监控系统服务。 产品体验WYSIWYG当前优秀的监控大盘产品都标配一个“所见即所得（WYSIWYG）”编辑器，这方面能力是蚂蚁金服监控产品一直缺失的。在蚂蚁金服监控产品中配置大盘还是通过传统的表单方式，对用户非常不友好、学习曲线陡峭、配置效率不高。导致用户经常将配置大盘作为一项需求提给监控团队，由监控团队的“大盘配置专家”来进行配置，不仅存在较高的沟通成本，也给监控团队增加了很大的负担。 在新版监控大盘 Barad-Dur 中，对 WYSIWYG 编辑器的交互体验进行了大量工作，力求做到市面上最优秀的编辑体验。 体验1：缩放Barad-Dur 的缩放是可以在四周以及四角上进行的，而市面上常见的大盘产品只支持右下角的缩放。由于坐标系统一般采用的是 (left, top, width, height) 来定义一个矩形，最容易实现的就是右下角缩放，只需要变动 width 和 height 两个参数即可。最难实现的是左上角的缩放，四个参数需要同时变动，且关系比较复杂。特别是在引入网格布局后，缩放时要自动“吸附”临近的网格点，难上加难。 体验2：拖动Barad-Dur 的图表拖动可以实现图表位置的一步交换，而市面上常见的大盘产品需要进行多次拖动才能实现两个图表的交换。且在拖动过程中，图表的整体布局会被打乱，而 Barad-Dur 不会存在这样的问题。 体验3：自动重布局Barad-Dur 的自动重布局功能非常强大，可以支持实时布局预览（当然市面上常见的大盘产品也支持），同时大盘的布局调整会根据具体操作（缩放、拖动）的方向进行。而市面上常见的大盘产品只能在垂直方向上进行布局调整，因为所用的算法非常简单，只是粗暴地把所有图表向页面上“推”。 体验4：任意位置Barad-Dur 的布局支持图表在任意位置摆放，而市面上常见的大盘产品由于上述的简陋算法，不支持此功能，所有的图表必须堆叠在页面的顶部。 体验5：布局复位Barad-Dur 的自动重布局能够在对单个图表进行调整时将其他图表“推开”，然后更强大的是可以再将被推开的图表复位。这里找到了市面上常见的大盘产品直接拿来用的开源布局框架进行对比。该框架其实提供了上述的任意位置功能，然而由于没有布局复位的功能，导致该功能一旦启用，会令整个大盘在编辑过程中布局被扰乱，对用户起不到任何帮助，所以市面上常见的大盘产品没有启用这个功能。 体验6：文字编辑Barad-Dur 支持在大盘中添加静态文字以及对于文字的编辑。静态文字可用于公告、标题、说明等一些常见的大盘场景。 功能对比 Barad-Dur市面上常见的大盘产品任意拖动✔︎✔︎任意缩放✔︎✘多样图表✔︎✔︎图表实时编辑✔︎✔︎图表导入导出✔︎✔︎任意布局✔︎✘添加文字✔︎✘综上对比，可以看出 Barad-Dur 的 WYSIWYG 编辑器在各项功能上已经领先于市面上常见的大盘产品。 控制器大盘，即 Dashboard (in an automobile or similar vehicle) a panel beneath the front window having various gauges and accessories for the use of the driver; instrument panel。其本意是指汽车上的仪表板，这里的仪表板包括了两类组成部分：监视器、控制器。在仪表板上不仅能看到汽车的当前状态，也能对汽车进行各种控制。这是大盘的本意，但是就目前看来，市面上所有的监控大盘产品都缺失了控制器这个重要的组成部分，导致监控大盘其实只是监视大盘。如果只是用来监视的，那大盘独立存在就没有意义，就像汽车的仪表板上只有转速表、时速表、里程表，却没有油门、刹车、换挡杆。 ...

简介：云原生是什么？相信不同的人有不同的认识和解读。本文结合大家的各种讨论及项目实践经验，从交付的角度，分享阿里交付专家对云原生的理解，阐述如何构建云原生应用，云原生有哪些关键技术，以及关于云原生落地的思考。 前言Internet 改变了人们生活、工作、学习和娱乐的方式。技术发展日新月异，云计算市场风起“云”涌，从最初的物理机到虚拟机（裸金属） ，再到容器（Container），而互联网架构也从集中式架构到分布式架构 ，再到云原生架构。如今 “云原生” 被企业和开发者奉为一种标准，并被认为是云计算的未来，让我想到一句话：“未来已来，只是分布不均”。 伴随着 “云原生” 技术（架构）越来越火，火得一塌糊涂，每个人对它的理解都各不相同，网上和阿里内部关于 Cloud Native 的相关文章和讨论也非常多。不过，我发现大家对于云原生的定义、理解及实践还处于探索阶段，还没有一个非常明确或者顶层设计的标准化定义。 最近参与了一个上云项目，里面用到很多云原生的技术，借此机会结合大家的各种讨论，以及项目中的实践，聊一下个人对于云原生的一些粗浅思考。 追本溯源在正式讨论之前，我们不妨先来看看几位网红主播是怎么定义云原生的。 Pivotal 的定义Pivotal 公司是敏捷开发领域的领导者（曾经 Google 也是其客户），出生名门（EMC、VMware等投资），是标准的富二代。它推出了 Pivotal Cloud Foundry（2011 ~ 2013 PAAS 界网红） 和 Spring 生态系列框架，也是云原生的先驱者和探路者（开山鼻祖）。云原生具体定义如下图： Pivotal 公司的 Matt Stine 于 2013 年首次提出云原生（Cloud Native）的概念。2015 年，云原生推广时，Matt Stine 在《迁移到云原生架构》的小册子中定义了符合云原生架构的几个特征：12 因素应用、微服务架构、自敏捷架构、基于 API 协作、抗脆弱性。到了 2017 年，Matt Stine 改了口风，将云原生架构归纳为：模块化、可观测性、可部署性、可测试性、可处理性、可替换性等 6 大特征。而 Pivotal 最新官网对云原生概括为 4 个要点：DevOps、持续交付、微服务、容器。 CNCF 的定义CNCF（Cloud Native Computing Foundation，云原生基金会）相信大家已经非常熟悉。它是由开源基础设施界的翘楚 Google、RedHat 等公司共同牵头发起的一个基金会组织，其目的非常明确，就是为了对抗当时大红大紫的 Docker 公司在容器圈一家独大的局面，具体情况（有很多故事）不在这边细说了。CNCF 通过 Kubernetes 项目在开源社区编排领域一骑绝尘，之后就扛起了云原生定义和推广的大旗，风光无限。云原生具体定义如下： ...

作者 | 丁宇（叔同） 阿里云智能容器平台负责人 云计算、大数据、人工智能等新技术正迅速的改变着我们所处的时代，其巨大的影响力已经从量变到质变，数字化转型成为企业发展的必然选择。 据IDC报告，全球前1000的大企业中，67％的企业已将数字化转型变成企业级战略，企业数字化转型也正成为许多中国企业的核心战略。随着企业上云成为业界趋势，全面使用开源技术和云产品构建软件服务的时代已经到来。如何更好地拥抱云计算、拥抱云原生、用技术加速创新，将成为企业数字化转型升级成功的关键。 如何在数字化时代实现弯道超车？云原生开辟了一条捷径阿里云原生应用平台研究员丁宇（叔同）在2020阿里云线上峰会上也提到了“以容器为代表的云原生技术，已经成为释放云价值的最短路径，云原生助力企业全面拥抱云计算”。在他看来，很多企业在数字化转型的过程中，付出了不少的努力与时间，但因为对云原生缺乏了解和实践经验，加之没有好的技术与产品来支撑，导致走了不少弯路。 我们知道，传统的开发模式在迭代速度、频率以及运维方式都难以满足市场快速变化的需求，而云原生追求的就是最大化地利用其技术模式，充分发挥云计算的生产力，使得应用从设计、开发、交付、到管理的思维方式与最佳实践有机结合，从而让这个应用可以最快地创造价值，也就是丁宇所说的“最短路径”。以容器技术为例，容器就是在虚拟化的基础上向上封装了一层，作为云平台与客户交互的新界面之一，应用的构建、分发和交付在容器层面实现标准化，对于企业而言，可以大幅降低 IT 实施和运维成本，从而提升业务创新的效率。 叔同提到：“阿里云的核心优势之一就是阿里巴巴的核心业务运行在云上，形成最好的创新土壤，最先进的技术首先会在阿里巴巴自己的业务体系中进行尝试，得到了大规模的运用，证明其技术的普适性与价值后再开放给客户。” 从2011年迈进容器大门算起，阿里的云原生之路已经走了十年。这期间经历了十年双11的历练，例如2015年全面容器化帮助双11大促实现快速弹性扩容。由于业务的超大规模使得其复杂程度非常高，这也为容器技术带来了更大的挑战。例如在容器镜像分发过程中，一次发布分发几万个镜像，这样巨大的流量是一个不小的挑战。为实现效率的极致要求，阿里云利用P2P技术，实现大规模大批量的快速分发，实现10秒内完成跨机房镜像下载容器启动。 容器技术对于双11的显著影响还包括在具体的混部技术实施中，通过混部技术，阿里巴巴集团范围内能够节省30%左右的IT成本支出，在双11这个特殊时间段里，将每万笔交易成本下降超过75%。 Gartner今年4月发布2020年容器公有云竞争格局报告，阿里云再度成为国内唯一入选厂商。报告显示，阿里云容器服务在中国市场表现强劲，产品形态丰富，在如Serverless容器、服务网格、安全沙箱容器、混合云和边缘等领域，具备良好的技术发展策略。而在今年3月，Gartner第二次公开《竞争格局：公共云容器服务》年度调研报告，报告针对Serverless、Kubernetes、服务网格、容器镜像等十项功能维度进行对比，阿里云和AWS覆盖九项产品能力，产品丰富度领先Google、微软、IBM和Oracle四家厂商。 云原生裸金属，挑战性能极致，全新升级最短路径过去几年，容器服务被各行业企业广泛接受，而阿里云凭借业界最丰富的容器产品家族和容器服务，已经连续数年以超400%的规模高速增长。在2020阿里云线上峰会上，阿里云智能基础产品事业部高级研究员蒋江伟重磅发布了云原生裸金属方案。 新一代容器服务 ACK，可以将最新神龙弹性裸金属实例的强大性能发挥得淋漓尽致，具备极致性能、高效调度、全面安全的特点： 新一代神龙架构具备业界第一的 I/O 转发能力，提供最高 100G 网络带宽；阿里云高速 Terway 容器网络通过网卡直通和数据平面加速，延迟下降 30%。第 7 代实例最大支持 192 个 vCPU。ACK 智能 CPU 调度可以轻松释放强大算力，无需应用调整可以实现 QPS 20~30% 提升；结合 ENI 网卡密度提升，可以缩减 50% 的计算成本。弹性裸金属实例支持阿里云安全容器，提升端到端安全隔离能力，与开源方案相比性能提升 30%，也支持阿里云首发机密计算容器，基于软硬一体技术有效保护数据隐私。 在阿里巴巴内部，容器+神龙裸金属方案以超高性能支撑钉钉抗住有史以来最大的流量洪峰。以前，钉钉100% 部署在普通物理机上，疫情突发之后，政府、企业和学校对在线协作的需求猛增。通过云上神龙裸金属+容器弹性部署方案，快速地实现了钉钉业务应用 10 万核扩容需求。 在外部，尤其是在这次疫情影响下，很多企业面临快速扩容的压力，如在线教育行业，短时间内爆发式的需求，对于任何一家在线教育企业既是机遇，更是挑战。据百家云CEO李钢江透露，疫情期间百家云的业务量在短时间内增长了数十倍，要满足如此迅速的扩容需要，还要在客户无感知的情况下完成扩容，其难度不亚于交付一个新系统。 幸运的是，在这场流量战役之前，百家云已经在阿里云团队的帮助下，优化了自身容器集群架构与规划，通过阿里云容器服务ACK、基于神龙架构的弹性裸金属实例的核心方案，足以从容应对流量洪峰。相比之下，一些没有使用容器的在线教育企业，面对突增的用户量和流量，只能成倍的堆积机器，导致部署时间拉长，业务成本急剧上涨，用户体验也不佳。 为什么要采用神龙裸金属+容器弹性部署方案？因为百家云的需求是三天扩容数十倍，并且百家云的K8s集群对性能要求极高，而“容器+弹性裸金属”的解决方案非常契合这种大流量、高并发的场景。首先，阿里云弹性裸金属服务器规格较高，可以帮助百家云显著提升单个节点的容量。 其次，基于容器化构建方式，可以满足业务快速发放和弹性的要求。神龙服务器完全消除了虚拟化损耗，提升了8%的计算性能，其类物理机特性，可进行二次虚拟化。神龙的性能，加上容器的弹性，形成了天作之合。数据显示，容器运行在云上神龙反而比非云物理机的性能要好10%-15%。主要是因为虚拟化开销已经offload到MOC卡上，神龙的CPU/Mem是无虚拟化开销的，而上云后运行在神龙上的每个容器都独享ENI弹性网卡，能提升13%的网络吞吐量。 第三，神龙服务器的存储带宽和计算带宽分离，能满足百家云业务场景的大量读写需求。使用神龙服务器之后，计算能力大增。并且，百家云通过使用阿里云的高性能NAS服务，并通过水平扩展为4个集群，解决了I/O的瓶颈。 基于以上方案，借助自身的大规模集群管理能力，在短短几天之内，阿里云团队帮助百家云团队有效升级了原有的架构方案，实现了数十倍的扩容，大幅提升了其性能与稳定性，并拥有了应对爆发性规模的能力，用户毫无察觉。 丰富的云原生产品和解决方案背后，阿里云用四个最来践行最短路径阿里云在云原生领域的投入广泛而深入，在容器、服务网格和Serverless均有丰富的产品服务，目前阿里云已经拥有国内最丰富的云原生产品家族、最全面的云原生开源贡献、最大规模的云原生应用实践、最大的云原生客户群体。其产品体系覆盖八大类别20余款产品，涵盖底层基础设施、数据智能、分布式应用等，可以满足不同行业场景的需求。 阿里云是国内在云原生领域的开源贡献最全面的科技公司，涵盖编排调度、作业管理、无服务器框架等，主导维护etcd、containerd、dragonfly等多个CNCF明星项目的发展，已有超过10个项目进入CNCF landscape。去年1月，阿里云资深技术专家李响成为首个入选全球顶级开源社区CNCF技术监督委员会的中国工程师，致力于推动云原生技术的落地。今年5月，阿里巴巴开源首个边缘计算云原生项目OpenYurt，推动社区在云原生和边缘计算交叉领域的协同发展。 近日，云计算开源产业联盟在OSCAR开源先锋日云原生专场活动上公布了“云原生应用十大优秀案例”评选结果，由阿里云提供技术服务的申通通用云原生计算平台和中国民生银行的场景化数据服务中台双双入选，这次评选的四大标准是：面向传统行业数字化转型，规模化应用云原生技术，提升企业资源利用率及研发效率，助力企业业务创新发展。申通和民生银行两大案例因为在云原生和数据服务中台的技术实践中表现出色，最终脱颖而出。 以申通为例，原有IDC系统帮助申通早期业务快速发展，但也暴露了不少问题，传统IOE架构，各系统架构的不规范，稳定性，研发效率等都限制了业务发展需求。在跟阿里云多次技术交流之后最终确定阿里云为唯一合作伙伴，为申通提供稳定的计算，数据处理平台。 申通原架构是基于VMware+Oracle数据库的架构，通过上阿里云，全面转型基于Kubernetes的云原生架构体系。主要有两点： 应用容器化。跟虚拟机比起来，容器能同时提供效率和速度的提升，让其更适合微服务场景。通过应用容器化解决了环境不一致的问题，保证应用在开发、测试、生产环境的一致性。微服务改造。原先很多业务是基于Oracle的存储过程及触发器完成的，系统之间的服务依赖也是通过数据库OGG同步完成。存在的问题是系统非常难维护，也非常不稳定。通过引入Kubernetes的服务发现来做微服务方案，按业务域进行拆分，让整个系统更易于维护。目前申通核心业务系统已经在云上完成流量承接，每天处理订单量在千万级别，处理物流轨迹在亿级别，每天产生的数据量在1T，使用1300+个计算节点来实时处理业务。正如申通上云总负责人提到的，“申通通过阿里云进行全面转型，基于Kubernetes的云原生架构体系，在成本、稳定性、效率、赋能业务四个维度获得显著成效，这些云原生技术带来的价值，是申通转为使用公有云作为主要计算资源的核心驱动力。” 在容器技术上，阿里云的目标是构筑新基石、新算力、新生态。帮助企业更好地支撑混合云、云边一体的分布式架构和全球化的应用交付。据 Gartner 分析，未来 80% 以上的企业都会采用混合云的架构，打造混合云和云边一体的方案也是阿里云一直在关注的方向。未来云的架构是动态、混合的架构——云边端一体，公共云能力向边缘设备端拓展，需将计算能力、AI推进到边缘，容器提供一致化的方式对云边端进行统一的应用部署和交付。基于云原生软硬一体化的创新技术，通过阿里云提供的强大算力来加速企业的智能化升级：容器服务结合神龙架构发挥性能和弹性，支持含光800芯片的调度、共享，极致优化深度学习场景的效率、成本。 容器、Kubernetes、云原生正在成为云时代的技术新标准，重塑整个软件生命周期，阿里云通过云原生正在帮助企业客户和开发者最大化利用云的能力，最大化发挥云的价值。 ...

近期，由DOIT百易传媒联合学术界和云原生行业专家联合编撰的《行业云原生应用报告指南》正式发布。博云参与本次白皮书联合编纂，运用多年云原生技术落地实践经验帮助传统企业了解、运用云原生技术实现数字化转型提供建议。 《行业云原生应用报告指南》介绍了微服务、DevOps、Kbuernetes、容器、分布式应用等各个技术领域的主要技术以及对于云原生的重要性，也大致介绍了如何运用这些技术和产品解决方案在行业中付诸实践，提升企业的云原生能力，改变被动的局面，立足从用户角度出发的解读，为企业用户的云原生之路提供分析和指导。 报告中表明，当前传统行业云计算应用已进入到 PaaS 平台阶段——以平台为基础的云原生化开发，实现对传统应用逐步改造。从技术上看，基于容器 + 新型 PaaS 平台具有敏捷部署、弹性伸缩、灵活调度的优点，结合、 DevOps 和微服务三驾马车，企业可以快速走上云原生转型之路。白皮书也强调：构建平台是起点，不是目的，是手段、工具，但不是业务应用，用好容器 + 新型 PaaS 平台加快云原生化部署才是当务之急。 作为国内专注服务企业级用户的PaaS服务商，博云凭借对客户需求的深入理解，对云原生技术持续跟踪与投入，形成了以自主研发的PaaS技术中台和多云管理为核心的产品布局。 博云通过容器、微服务和DevOps等产品的PaaS产品体系，已帮助中国农业银行、民生银行、华泰证券、东方证券、江苏银行、苏州农商行、中国移动、中国联通、中国石油、安信证券、中国人寿保险、吉利汽车、海信集团等银行、证券、保险、互联网金融、能源、政务、制造、运营商等行业的200多家中大型企业实现传统IT架构向云原生架构转型，帮助企业从业务架构、技术架构、研发流程、组织架构等多方面帮助企业进行云原生体系建设。近期，由博云提供产品及服务的“中国民生银行信用卡中心——营销魔方”及“广东电网——研发运维一体化平台”两个项目获得云计算开源产业联盟评选的十大云原生应用优秀案例。  博云积极参与云原生相关技术标准制定，以自身丰富实践经验和深厚的技术能力，推动云原生技术在各行业的深化应用。未来，博云将继续对云原生技术加大研发投入，通过云原生技术帮助企业实现数字化转型，为云原生技术及产业生态在国内成熟发展贡献力量。 扫描下方二维码下载 《行业云原生报告指南》

作者 | Agentd Arthas watch 命令使用指南Arthas 是我很喜欢的一款 Java 领域的开发调试工具。 每次测试遇到问题的时候，当别人为了加一条日志而重发代码，我都会欣慰地拿出我的 Arthas 并且告诉他们：少年，你不用再为了加日志就重发代码而烦恼了。Arthas，你值得拥有。 这次我要介绍的是我使用最多的一个功能：watch。Arthas 功能虽多，但我最喜欢的还是这一个。使用 watch 之后，我再也不用为了观察函数调用而加日志了。 Arthas 是什么Arthas 官网是这么介绍自己的： Arthas 是 Alibaba 开源的 Java 诊断工具，深受开发者喜爱。 当你遇到以下类似问题而束手无策时，Arthas 可以帮助你解决： 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！是否有一个全局视角来查看系统的运行状况？有什么办法可以监控到 JVM 的实时运行状态？怎么快速定位应用的热点，生成火焰图？一键安装并启动 Arthas方式一：通过 Cloud Toolkit 实现 Arthas 一键远程诊断Cloud Toolkit 是阿里云发布的免费本地 IDE 插件，帮助开发者更高效地开发、测试、诊断并部署应用。通过插件，可以将本地应用一键部署到任意服务器，甚至云端（ECS、EDAS、ACK、ACR 和 小程序云等）；并且还内置了 Arthas 诊断、Dubbo工具、Terminal 终端、文件上传、函数计算 和 MySQL 执行器等工具。不仅仅有 IntelliJ IDEA 主流版本，还有 Eclipse、Pycharm、Maven 等其他版本。 推荐使用 IDEA 插件下载 Cloud Toolkit 来使用 Arthas：http://t.tb.cn/2A5CbHWveOXzI7sFakaCw8  ...

作者 | 阿里云原生 在 6 月 9 日 2020 阿里云线上峰会上，阿里云智能基础产品事业部高级研究员蒋江伟重磅发布了云原生裸金属方案。 新一代容器服务 ACK，可以将最新神龙弹性裸金属实例的强大性能发挥得淋漓尽致，具备极致性能、高效调度、全面安全的特点： 新一代神龙架构具备业界第一的 I/O 转发能力，提供最高 100G 网络带宽；阿里云高速 Terway 容器网络通过网卡直通和数据平面加速，延迟下降 30%；第 7 代实例最大支持 192 个 vCPU。ACK 智能 CPU 调度可以轻松释放强大算力，无需应用调整可以实现 QPS 20~30% 提升；结合 ENI 网卡密度提升，可以缩减 50% 的计算成本；弹性裸金属实例支持阿里云安全容器，提升端到端安全隔离能力，与开源方案相比性能提升 30%，也支持阿里云首发机密计算容器，基于软硬一体技术有效保护数据隐私。 在阿里巴巴内部，神龙架构已大规模应用于淘宝、天猫、菜鸟等业务，解决了高峰值下的业务性能和稳定性问题。在外部，尤其是在这次疫情影响下，很多企业面临快速扩容的压力，如在线教育行业，通过阿里云容器+神龙方案，企业可以从容应对流量突增的难题。 视源股份（CVTE）的希沃系列教育平稳应对疫情期间指数级增长的课堂流量，视源电子运维负责人许坤丰称，“疫情之下，希沃课堂作为教育信息化应用和服务工具提供商，免费向全国师生开放希沃云课堂在线直播方案。不久前，全国超过 30 万教师使用希沃云课堂开课，共开设超过 200 万节课程。面对指数级增长的流量，我们在阿里云容器服务 ACK 上使用神龙服务器和 ECI，顺利完成扩容，让系统得以正常运行。ECI 的简单易用，海量节点的特性加上神龙服务器高性能，零抖动的特点，极大缓解了扩容的压力，让我们把更多精力放在产品本身，给全国老师和学生提供更好的服务。” 云计算开源产业联盟上周公布了“云原生应用十大优秀案例”评选结果，阿里云支持的申通通用云原生计算平台顺利入选。申通基于云原生裸金属方案完成迁云，实现了围绕快递包裹生命周期的高效管理，平稳度过 双11 业务高峰。 云计算开源产业联盟对申通通用云原生计算平台评价称“该平台解决了传统应用升级缓慢、架构臃肿、不能快速迭代等问题，通过云原生架构体系，在成本、稳定性、效率、赋能业务等四个维度获得显著成效。目前核心业务系统已经在云上完成流量承接，每天处理订单量在千万级别，处理物流轨迹在亿级别，每天产生的数据量在 1T，使用 1300+ 个计算节点来实时处理业务。” 神龙架构是容器的最佳载体2017 年 10 月，阿里云在全球率先推出了同时融合物理机和虚拟机特性的“跨界”云服务器——弹性裸金属服务器神龙 X-Dragon，它采用了自主研发的虚拟化 2.0 技术，兼具“虚拟机的心脏”和“物理机的肌肉”，被认为是云计算领域的新物种。从 2017 年发布第一代神龙架构开始，历经了软件虚拟化、通用硬件虚拟化、专用硬件芯片虚拟化三个阶段后，第三代神龙架构实现了裸金属服务器、ECS 虚拟机，弹性容器实例 ECI 等多种计算平台的架构统一和全面优化。 ...

简介： 新一代容器服务ACK，可以将最新神龙弹性裸金属实例的强大性能发挥得淋漓尽致，具备极致性能、高效调度、全面安全的特点。 在6月9日 2020 阿里云线上峰会上，阿里云智能基础产品事业部高级研究员蒋江伟重磅发布了云原生裸金属方案。 新一代容器服务ACK，可以将最新神龙弹性裸金属实例的强大性能发挥得淋漓尽致，具备极致性能、高效调度、全面安全的特点： 新一代神龙架构具备业界第一的I/O转发能力，提供最高100G网络带宽；阿里云高速Terway容器网络通过网卡直通和数据平面加速，延迟下降30%。第7代实例最大支持192个vCPU。ACK智能CPU调度可以轻松释放强大算力，无需应用调整可以实现QPS 20~30%提升；结合ENI网卡密度提升，可以缩减50%的计算成本。弹性裸金属实例支持阿里云安全容器，提升端到端安全隔离能力，与开源方案相比性能提升 30%。也支持阿里云首发机密计算容器，基于软硬一体技术有效保护数据隐私。在阿里巴巴内部，神龙架构已大规模应用于淘宝、天猫、菜鸟等业务，解决了高峰值下的业务性能和稳定性问题。在外部，尤其是在这次疫情影响下，很多企业面临快速扩容的压力，如在线教育行业，通过阿里云容器+神龙方案，企业可以从容应对流量突增的难题。 视源股份(CVTE)的希沃系列教育平稳应对疫情期间指数级增长的课堂流量，视源电子运维负责人许坤丰称，“疫情之下，希沃课堂作为教育信息化应用和服务工具提供商，免费向全国师生开放希沃云课堂在线直播方案。不久前，全国超过30万教师使用希沃云课堂开课，共开设超过200万节课程。面对指数级增长的流量，我们在阿里云容器服务ACK上使用神龙服务器和ECI，顺利完成扩容，让系统得以正常运行。ECI的简单易用，海量节点的特性加上神龙服务器高性能，零抖动的特点，极大缓解了扩容的压力，让我们把更多精力放在产品本身，给全国老师和学生提供更好的服务。” 云计算开源产业联盟上周公布了“云原生应用十大优秀案例”评选结果，阿里云支持的申通通用云原生计算平台顺利入选。申通基于云原生裸金属方案完成迁云，实现了围绕快递包裹生命周期的高效管理，平稳度过双11业务高峰。 云计算开源产业联盟对申通通用云原生计算平台评价称“该平台解决了传统应用升级缓慢、架构臃肿、不能快速迭代等问题，通过云原生架构体系，在成本、稳定性、效率、赋能业务等四个维度获得显著成效。目前核心业务系统已经在云上完成流量承接，每天处理订单量在千万级别，处理物流轨迹在亿级别，每天产生的数据量在1T，使用1300+个计算节点来实时处理业务。” 神龙架构是容器的最佳载体2017年10月，阿里云在全球率先推出了同时融合物理机和虚拟机特性的“跨界”云服务器——弹性裸金属服务器神龙X-Dragon，它采用了自主研发的虚拟化2.0技术，兼具“虚拟机的心脏”和“物理机的肌肉”，被认为是云计算领域的新物种。从2017年发布第一代神龙架构开始，历经了软件虚拟化、通用硬件虚拟化、专用硬件芯片虚拟化三个阶段后，第三代神龙架构实现了裸金属服务器、ECS虚拟机，弹性容器实例ECI等多种计算平台的架构统一和全面优化。 蒋江伟在演讲中也提到，客户普遍有个共识，那就是容器与物理服务器的结合是最佳搭档。但是普通物理服务器天然具有一些缺陷，比如运维复杂度高，缺乏弹性。而以神龙架构为基础的裸金属服务器，搭配容器服务ACK，不仅提供非常好的性能，同时具备虚拟机的运维灵活性，正好弥补了物理服务器的弹性缺陷，对于构建容器环境而言，裸金属是更好的选择。据蒋江伟介绍，云原生裸金属具备极致的弹性、高效的调度能力和更全面的安全能力。在普通的应用场景下，基于神龙架构的容器服务ACK与自建容器相比，可以实现QPS提升30%，计算成本下降50%，容器安全性能提升30%。 对于线下传统物理机服务器，企业客户最大的痛点就是缺乏弹性，运维复杂，无法应对快速发展的业务需求。神龙裸金属服务器，具备虚拟机的体验，物理机的性能。扩容交付周期几周缩短到分钟，与虚拟机相比性能“零损耗”、“零抖动”，与传统物理机相比性价比提升20% ，是用户上云的最佳选择。 钉钉以前100%部署在普通物理机上，疫情突发之后，政府、企业和学校对在线协作的需求猛增。通过云上神龙裸金属+容器弹性部署方案，快速地实现了钉钉业务应用10万核扩容需求；借助神龙+容器的超高性能支撑钉钉扛住了有史以来最大的流量洪峰。 此外，社区版本K8s容器调度技术存在一定局限，无法充分使用神龙裸金属服务器强大的算力。应用在多CPU核心场景下，可能会引起资源争抢、CPU频繁切换等情况。通过开启容器服务ACK的智能CPU调度，可以提升缓存的命中率、减少CPU中断和切换次数，有效提升性能，在不增加硬件资源的情况下性能提升20%，QPS从25万提升到30万。 容器服务ACK不但支持对CPU的高效调度，还新增了对业界最强算力AI芯片 - 含光800的多核调度支持，可以成倍提升AI业务资源利用率和性价比。阿里自研的含光800芯片具备强大的应用算力，在淘宝的拍立淘场景中，对商品库每天新增10亿商品图片，使用传统GPU算力识别需要1小时，使用含光800后可缩减至5分钟。对于强大的含光NPU芯片，阿里云容器服务ACK独创了面向容器的虚拟化和共享能力，充分发挥含光 800 多核资源，把多种业务精确调度到同一含光800芯片，充分利用计算资源，显著降低计算成本！ 传统企业，尤其是一些大型企业，对从私有数据中心迁移到公有云上并不放心。其中数据安全问题是首要关切，需要独享使用物理机才会有安全感。云原生裸金属方案，结合阿里云安全沙箱容器技术，提供从基础设施到应用运行时端到端安全，非常适合对隐私和隔离要求较高的应用场景，而且与开源方案相比性能提升 30%。阿里云此次首发机密计算容器，基于软硬一体技术实现全链路加密，有效解决数据泄露、非法数据访问等问题，可以应用在区块链、金融交易、基因计算等业务场景中。 云计算的下一站，是云原生神龙是面向云原生设计的新一代云基础设施架构，同时支持裸金属服务器、ECS虚拟机，ECI弹性容器实例等多种计算形态。神龙架构采用软硬一体设计，可以将网络和存储的转发任务卸载到神龙芯片上，避免了底层资源争抢而导致的ECS虚拟机性能波动。第三代神龙架构还引入硬件级别QoS能力，为客户关键业务带来更强的保障。基于神龙架构的ECI弹性容器实例，性能优于虚拟机中运行的相同规格Docker容器；具备极致的弹性能力，可以在一分钟内扩容1000业务容器实例。 客户可以在一个ACK K8s集群中划分不同节点池统一管理弹性裸金属实例，ECS虚拟机实例和弹性容器实例。根据应用负载特性，可以充分优化计算效率、提升资源利用率、降低计算成本。对于需要极致性能和强安全隔离场景，用户可以采用裸金属实例；对于存在明显业务峰谷的场景，虚拟机实例可以提供更灵活的弹性。而弹性容器实例可以更好应对突发业务流量，提供免运维的用户体验。 容器服务ACK已经成为企业云原生操作系统，与EDAS微服务架构，ARMS端到端可观测能力全面集成，全面提升IT敏捷性，为企业数字化转型提速。

一场突如其来的疫情加深了企业对数字化转型升级的渴望，作为新兴数字化业务的基础，云原生技术的价值日益凸显。当前，越来越多的企业逐步引入容器、微服务/Service Mesh 技术改造业务，实现数据库、PaaS 中间件的云原生化，探索 Serverless 的落地应用，以提升应用交付能力，促进业务创新，并提升资源利用率，降低开发运维成本；另一方面，云原生开源社区的核心框架也在不断迭代，使之更符合开发运维需求。 网易杭研举办本次“问道一线专家，探秘云原生实践”系列在线技术沙龙活动，邀请 Envoy 社区 Core Maintainer 及网易杭研、美团、微博等知名互联网公司一线专家联袂分享，解读云原生技术演进趋势，介绍云原生落地应用的经验心得，实践过程中遇到的典型问题及解决之道。 基本信息议题：Service Mesh 技术在美团的落地和挑战讲师：刘世朋，美团基础架构部开发工程师时间： 6月11日 19:00-20:00地点：在线直播讲师简介刘世朋，就职于美团基础架构部服务治理中心，目前负责 OCTO2.0（Service Mesh）项目的建设。技术兴趣集中在云原生相关的领域，包括容器、K8s、Service Mesh等方面。 议题摘要美团相对具有较为完善的服务治理系统，业务开发语言以 Java 为主且内部技术栈较为统一，OCTO 服务治理系统的接入覆盖率很高。本次主要介绍 Service Mesh 理念在美团的实践和落地。具体包括与美团已有服务治理系统的融合、与容器基础设施平台的融合、性能优化指标、运维监控实践和低成本业务接入等几个方面的工作。 议题大纲美团服务治理系统现状现有服务治理系统的融合Service Mesh 功能建设运维监控建设业务可控、灰度接入等听众收益了解美团服务治理技术体系了解 Service Mesh 大规模落地实践报名：扫图中二维码报名即可完成直播预约

简介：首届云原生编程挑战赛正在报名中，初赛共有三个赛道，本文主要针对赛道三题目做出剖析，帮助选手更高效的解题。 首届云原生编程挑战赛正在报名中，初赛共有三个赛道，题目如下： 赛道一：实现一个分布式统计和过滤的链路追踪 赛道二：实现规模化容器静态布局和动态迁移 赛道三：服务网格控制面分治体系构建 立即报名（报名时间即日起至06/29）：https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition 本文主要针对赛道三题目做出剖析，帮助选手更高效的解题。 背景知识“服务网格” 是近年来非常火热的技术，其全托管的思维非常适合云原生场景。“服务网格” 核心分为控制面与数据面：数据面主要是一个名为 Sidecar 的代理组件，它通过接收控制面发送的路由与控制信息来定向转发或处理数据。这样一些坐落在服务网格里的应用就将整个分布式逻辑交给了底层，自己不用关心了。一旦与底层解耦，灵活性大大增加，更符合云原生的标准。 题目解析本题的核心考查点还是如何让服务网格的控制面支撑大规模的 Sidecar 实例。为什么会产生这个问题呢？因为在目前服务网格影响最广的实现 Istio 架构中，控制平面 Pilot 负责整个系统的路由转译工作，也就是说所有服务的实例信息都需要通过 Pilot 下发给每一个 Sidecar，当然用户可以通过 SidecarScope 来设置个别 Sidecar 对于系统服务的可见性，但这只会影响到 Sidecar 接受到的数据而已，Pilot 仍然是全量从注册中心同步（例如 Consul，K8s 的 CoreDNS 等），如此一来随着接入应用的增加，Pilot 不能横向扩容，很快便会成为性能瓶颈（内存不够用啊）。 题目提出了分治的解法，而选手们的任务就是优化分治逻辑，使整体负载均衡。为了理解题目，我们首先需要弄清楚什么是分治。所谓的分治就是将负载分成一个个独立的子系统，然后分别处理他们，这样就将问题化小了，比如我们常见的合并排序，就是分治的典型应用。按题目的解释，控制面的分治是按应用维度进行划分的，也就说坐落在服务网格中的应用将被划分到不同的子系统中。 上图中，就被划分成了左右两个子系统。应用之间存在相互依赖即服务依赖，在本题中一个应用只提供一个服务，因此应用所连接的 Pilot 需要加载的数据就是其依服务。由于分治的存在，每个 Pilot 不需要加载所有的服务了，这样当更多的应用接入时，我们就可以进行横向扩容解决容量问题。 上图中为什么每个分治组加载的数据不是完全隔离的呢？这里的原因是应用的依赖是错综复杂的，如果我们把每个应用一个点表示，依赖用一条线表示，那么实际生产中，几乎是不可能形成孤岛的，原因是：每个应用依赖的服务是有重叠的，而且很多。 这样我们便不能随意地划分应用，因为如果我们将依赖相似度很高的应用划分到不同的 Pilot 上，会导致同样的依赖在多个 Pilot 上加载，造成内存消耗增加。反过来，如果将所有应用都挂到同一个 Pilot 上，那么加载的内存总量是最少的，不过连接就极度不均匀了。 所以本题要求选手优化分治逻辑，让分治系统均匀承压。我们先来看看一评分的公式： 公式也不复杂，分为三个评分项： Pilot 实际加载内存与理想内存的占比，上文提到，不同应用之间依赖的服务可能会有重叠，因此最理想的状态就是所有服务依赖在整个 Pilot 系统中只加载一次，简单来说就是将有相似依赖的应用都划分到同一个 Pilot 中；Pilot 的内存标准差，这个就比较直白了，就是让 Pilot 加载的服务尽量均衡，不要出现一个 Pilot 加载很多数据，另一个空闲的状态；Pilot 连接的标准差，这个与上面的类似，就是要求 Pilot 连接的 Sidecar 尽量均衡。由于实际加载的内存肯定是大于等于理想状态内存，因此最左边的分子式始终于大于 1 的，也就是说，这是一个倍率；而标准差是大于等于 0 的，显然想要两个标准差同时为 0 不现实。因此选手的任务就是分配应用，让 ...

作者 | 张磊  阿里云高级技术专家、CNCF 官方大使，CNCF 应用交付领域 co-chair，Kubernetes 项目资深维护者 美国西部时间 2020 年 5 月 27 日，阿里云和微软云共同宣布，Open Application Model （OAM） 社区携手知名混合云管理项目 Crossplane，联合发布了 OAM  在 Kubernetes 平台上的标准实现与核心依赖库项目。新版的 OAM 核心依赖库以 Go 语言编写，由来自阿里、微软和 Crossplane 三方的工程师共同维护，能够以 Kubernetes 插件或者 Go 语言依赖库的方式被社区所使用。在内置了 OAM 核心依赖库之后，Crossplane 项目也实现了“华丽升级”，从原先的混合云管理项目一跃成为了一个能够面向所有云环境、提供“应用 + 云服务”一站式管理与交付体验的 OAM 标准实现平台。 OAM 核心依赖库项目：https://github.com/crossplane/oam-kubernetes-runtimeCrossplane 项目：https://github.com/crossplane/crossplaneOAM 是阿里云与微软云在 2019 年末联合推出的标准化云原生应用管理模型。相比于传统 PaaS 封闭、不能同“以 Operator 为基础的云原生生态”衔接的现状，基于 OAM 和 Kubernetes 构建的现代云原生应用管理平台，本质上是一个“以应用为中心”的  Kubernetes ，保证了这个应用平台在能够无缝接入整个云原生生态。同时，OAM 可以进一步屏蔽掉容器基础设施的复杂性和差异性，为平台的使用者带来低心智负担的、标准化的、一致的应用管理与交付体验。 OAM 项目：https://github.com/oam-dev/spec “Cloud 2.0”时代的应用定义模型应用容器技术自诞生开始，就以“彻底改变了软件打包与分发方式”的魅力迅速征服了几乎所有的云厂商与数据中心。 不过，软件打包与分发方式的革新，并没有能够让软件本身的定义与描述发生本质的变化，基于 K8s 的应用管理体验，也没有让业务研发与运维的工作变得更简单。 实际上，Kubernetes 带来的云原生技术革命，在于实现了基础设施层的标准化和抽象，但这一层抽象距离业务研发与运维还是太过遥远了。一个最典型的例子，直到今天，Kubernetes 里面始终都没有“应用”这个概念，它提供的是更细粒度的“工作负载”原语，比如 Deployment 或者 DaemonSet。而在实际环境中，一个应用往往是由一系列独立组件的组合，比如一个“PHP 应用容器”和一个“数据库实例”组成的电商网站；一个“参数服务节点”和一个“工作节点”组成的机器学习训练任务；一个由“Deployment + StatefulSet + HPA + Service + Ingress”组成的 Kubernetes 应用。 ...

简介：Kubernetes 集群中，业务通常采用 Deployment + LoadBalancer 类型 Service 的方式对外提供服务。这种架构部署和运维都十分简单方便，但是在应用更新或者升级时可能会存在服务中断，引发线上问题。今天我们来详细分析下这种架构为何在更新应用时会发生服务中断以及如何避免服务中断。 作者 | 子白（阿里云开发工程师）、溪恒（阿里云技术专家） <关注阿里巴巴云原生公众号，回复 排查 即可下载电子书> 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！ Kubernetes 集群中，业务通常采用 Deployment + LoadBalancer 类型 Service 的方式对外提供服务，其典型部署架构如图 1 所示。这种架构部署和运维都十分简单方便，但是在应用更新或者升级时可能会存在服务中断，引发线上问题。今天我们来详细分析下这种架构为何在更新应用时会发生服务中断以及如何避免服务中断。 图1 业务部署图 为何会发生服务中断Deployment 滚动更新时会先创建新 pod，等待新 pod running 后再删除旧 pod。 新建 Pod图 2 服务中断示意图 中断原因：Pod running 后被加入到 Endpoint 后端，容器服务监控到 Endpoint 变更后将 Node 加入到 SLB 后端。此时请求从 SLB 转发到 Pod 中，但是 Pod 业务代码还未初始化完毕，无法处理请求，导致服务中断，如图 2 所示。 解决方法：为 pod 配置就绪检测，等待业务代码初始化完毕后后再将 node 加入到 SLB 后端。 删除 Pod在删除旧 pod 过程中需要对多个对象（如 Endpoint、ipvs/iptables、SLB）进行状态同步，并且这些同步操作是异步执行的，整体同步流程如图 3 所示。 图 3 Deployment 更新时序图 Podpod 状态变更：将 Pod 设置为 Terminating 状态，并从所有 Service 的 Endpoints 列表中删除。此时，Pod 停止获得新的流量，但在 Pod 中运行的容器不会受到影响；执行 preStop Hook：Pod 删除时会触发 preStop Hook，preStop Hook 支持 bash 脚本、TCP 或 HTTP 请求；发送 SIGTERM 信号：向 Pod 中的容器发送 SIGTERM 信号；等待指定的时间：terminationGracePeriodSeconds 字段用于控制等待时间，默认值为 30 秒。该步骤与 preStop Hook 同时执行，因此 terminationGracePeriodSeconds 需要大于 preStop 的时间，否则会出现 preStop 未执行完毕，pod 就被 kill 的情况；发送 SIGKILL 信号：等待指定时间后，向 pod 中的容器发送 SIGKILL 信号，删除 pod。中断原因：上述 1、2、3、4步骤同时进行，因此有可能存在 Pod 收到 SIGTERM 信号并且停止工作后，还未从 Endpoints 中移除的情况。此时，请求从 slb 转发到 pod 中，而 Pod 已经停止工作，因此会出现服务中断，如图 4 所示。 图 4 服务中断示意图 解决方法：为 pod 配置 preStop Hook，使 Pod 收到 SIGTERM 时 sleep 一段时间而不是立刻停止工作，从而确保从 SLB 转发的流量还可以继续被 Pod 处理。 iptables/ipvs中断原因：当 pod 变为 termintaing 状态时，会从所有 service 的 endpoint 中移除该 pod。kube-proxy 会清理对应的 iptables/ipvs 条目。而容器服务 watch 到 endpoint 变化后，会调用 slb openapi 移除后端，此操作会耗费几秒。由于这两个操作是同时进行，因此有可能存在节点上的 iptables/ipvs 条目已经被清理，但是节点还未从 slb 移除的情况。此时，流量从 slb 流入，而节点上已经没有对应的 iptables/ipvs 规则导致服务中断，如图 5 所示。 图 5 服务中断示意图 解决方法： Cluster 模式：Cluster 模式下 kube-proxy 会把所有业务 Pod 写入 Node 的 iptables/ipvs 中，如果当前 Node 没有业务 pod，则该请求会被转发给其他 Node，因此不会存在服务中断，如 6 所示；图 6 Cluster 模式请求转发示意图 Local 模式：Local 模式下，kube-proxy 仅会把 Node 上的 pod 写入 iptables/ipvs。当 Node 上只有一个 pod 且状态变为 terminating 时，iptables/ipvs 会将该 pod 记录移除。此时请求转发到这个 node 时，无对应的 iptables/ipvs 记录，导致请求失败。这个问题可以通过原地升级来避免，即保证更新过程中 Node 上至少有一个 Running Pod。原地升级可以保障 Node 的 iptables/ipvs 中总会有一条业务 pod 记录，因此不会产生服务中断，如图 7 所示；图 7 Local 模式原地升级时请求转发示意图 ENI 模式 Service：ENI 模式绕过 kube-proxy，将 Pod 直接挂载到 SLB 后端，因此不存在因为 iptables/ipvs 导致的服务中断。图 8  ENI 模式请求转发示意图 SLB图 9  服务中断示意图 中断原因：容器服务监控到 Endpoints 变化后，会将 Node 从 slb 后端移除。当节点从 slb 后端移除后，SLB 对于继续发往该节点的长连接会直接断开，导致服务中断。 解决方法：为 SLB 设置长链接优雅中断（依赖具体云厂商）。 ...

【摘要】云原生应用所影响的领域正逐渐从互联网走向非互联网，从传统应用升级走向云原生。当下，云原生技术的成熟正极大地影响着个人、企业乃至整个社会的生产生活方式。“未来的软件一定是生长于云上的” 云原生时代的应用云原生时代，随着容器技术、微服务架构思想、产品研发运营模式不断地推陈出新和迅速发展，应用的设计和开发落地门槛已经降低到了历史低点。根据国际知名数据咨询公司IDC（国际数据公司）的调查研究表明，从2018年到2023年将有超过500,000,000个应用被创建，这个数字是过去40年所有创建应用的总和。 另外，在IDC于2020年2月发布的《IDC FutureScape: 全球云计算2020 年预测——中国启示》中显示，云原生应用所影响的领域正逐渐从互联网走向非互联网，从传统应用升级走向云原生。当下，云原生技术的成熟正极大地影响着个人、企业乃至整个社会的生产生活方式。 下面是几条与云原生应用强相关的预测内容： 分布式云：到2021年，中国90%以上的企业将依赖于本地/专属私有云、多个公有云和遗留平台的组合，以满足其基础设施需求。API生态：到2023年，90%的新数字服务将使用公有云和内部API提供的服务构建复合型应用程序；其中一半将利用人工智能（AI）和机器学习（ML）。多云管理：到2022年，50%的企业将部署统一的VMs、Kubernetes和多云管理流程和工具，以支持跨本地和公有云部署的多云管理和治理。云堆栈扩展：到2024年，10%的企业内部工作负载将由公有云服务商数据中心以外的、位于客户数据中心和边缘位置的公有云堆栈提供支持。超敏捷APP：到2023年，50%的中国企业应用将部署在容器化的混合云/多云环境中，以提供敏捷的，无缝的部署和管理体验。在这场应用的变革中，越来越多的应用所有方会将应用基础设施交由更加专业的公有云/混合云服务商进行管理，通过API的方式对基础设施进行管理，由服务商提供更加敏捷和无缝的部署管理功能。如此，应用所有方可以将更多的投资及人力投入聚焦到应用本身的业务逻辑设计、开发、运维和体验优化，大大减少了产品上市的时间并得到了更高的可伸缩性，使应用开发的ROI（投资回报率）最大化。 使用微服务架构构建云原生应用云原生应用的定义有多种版本，最早为2015年pivital提出了云原生应用的定义，随后CNCF在2015年也对云原生应用进行了定义，2018年进行了重定义，具体定义可以参考kubernetes-handbook。可以发现自从云原生的概念出现，微服务架构就是云原生应用中浓墨重彩的一部分。 这一节里会讲到微服务架构使用场景，微服务应用在整个应用技术栈中的位置，和开发一个微服务你需要做的事情。 使用微服务的场景 构建云原生应用，首先一定是企业或者个人想要最大程度将自己的时间和精力从复杂的底层依赖开发维护中解放出来，集中在业务场景的设计和实现上，并且能够独立解耦的自动化完成应用各个模块的开发落地。这意味着独立开发的某一模块或负责某一单独业务的开发者，会最大程度的利用云厂商提供地DevOps工具链完成整个应用开发运维的共同目标，这样大家可以轻松地将应用作为一个松耦合的服务集合快速发布和更新，降低成本的同时也更容易避免单点故障。 微服务应用在技术栈中的位置 假设应用所有者已经做好了微服务的业务设计，我们来看看在落地阶段，微服务应用在产品研发和运行中的位置： 红色部分为微服务应用的核心模块，是由应用所有者开发和维护地运行时微服务应用。随着业务的增长，受系统能力影响，为了提高微服务的高可用、可靠性以及韧性，需要对微服务进行治理。常见的治理手段有：负载均衡、熔断、限流、降级、容错和隔离等，篇幅有限这里不加赘述。 黄色部分从左到右代表从Dev到Ops的技术栈。首先，应用开发者需要根据应用类型，选择依赖的微服务开发框架（chassis），使用框架时可以通过添加注解的方式，处理微服务运行时面临的横切面问题（crosscutting concern），比如：日志框架（log4j/logback）、健康检查、metrics、分布式追踪等。其次，编码完成后，可使用云服务厂商提供的DevOps工具链能力实现代码的归档、编译构建、发布部署等能力，将微服务部署在运行环境中。最后，还可以利用云服务厂商提供的运维能力对微服务进行运维监控。一般来说，云服务厂商提供的应用平台能力也是独立而解耦的，应用所有者可根据自己的需求和预算来自定义选择自己需要的服务。 紫色部分是运行时技术栈，蓝色箭头代表流量的流向。当微服务部署运行起来后，流量会从各种客户端首先连接到入口（比如服务网关/ELB），同时，流量在这里会根据请求特征分发到各个对应的业务处理微服务，随后对请求进行一系列的处理，返回结果。微服务的运行还依赖了很多中间件，比如：缓存、消息等；还有一些微服务的功能特性，比如：服务网格、服务注册发现等，这些中间件或特性也都由框架或者云服务厂商提供。微服务和中间件等其实都是上层服务部署在基础设施上，比如：虚机、容器或CCI实例。 综上所述，一个应用的落地其实涉及到很多技术和场景，使用微服务架构开发应用可以最大程度的简化应用所有者对底层设施和中间件的管理运维，通过自定义使用云服务厂商提供地全场景、端到端的应用平台能力，将资源聚焦在业务创新和落地上（红框部分）。 实践 - 一元体验all above最后，华为云CSE微服务平台提供了以ServiceComb开源框架拖底的配置中心和服务中心，提供动态配置和可靠的服务中心服务。ServiceComb服务中心在华为内部的大规模生产实践（支撑华为商城运行），支撑起数十万级别的tps的服务集群，可靠性得到了充分的验证。 开发者可以在云上享受开箱即用的微服务中间件，通过CSE微服务平台既可以学习实践又能作为生产实践，学习微服务可以跟进当下最新技术潮流。 华为云回馈活动指路↓ 一元体验原价500元包周期引擎（100实例），快点击这里体验吧！ 点击关注，第一时间了解华为云新鲜技术~

作者 | 子白（阿里云开发工程师）、溪恒（阿里云技术专家） <关注阿里巴巴云原生公众号，回复 排查 即可下载电子书> 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！ Kubernetes 集群中，业务通常采用 Deployment + LoadBalancer 类型 Service 的方式对外提供服务，其典型部署架构如图 1 所示。这种架构部署和运维都十分简单方便，但是在应用更新或者升级时可能会存在服务中断，引发线上问题。今天我们来详细分析下这种架构为何在更新应用时会发生服务中断以及如何避免服务中断。 图1 业务部署图 为何会发生服务中断Deployment 滚动更新时会先创建新 pod，等待新 pod running 后再删除旧 pod。 新建 Pod图 2 服务中断示意图 中断原因：Pod running 后被加入到 Endpoint 后端，容器服务监控到 Endpoint 变更后将 Node 加入到 SLB 后端。此时请求从 SLB 转发到 Pod 中，但是 Pod 业务代码还未初始化完毕，无法处理请求，导致服务中断，如图 2 所示。解决方法：为 pod 配置就绪检测，等待业务代码初始化完毕后后再将 node 加入到 SLB 后端。 删除 Pod在删除旧 pod 过程中需要对多个对象（如 Endpoint、ipvs/iptables、SLB）进行状态同步，并且这些同步操作是异步执行的，整体同步流程如图 3 所示。 图 3 Deployment 更新时序图 Podpod 状态变更：将 Pod 设置为 Terminating 状态，并从所有 Service 的 Endpoints 列表中删除。此时，Pod 停止获得新的流量，但在 Pod 中运行的容器不会受到影响；执行 preStop Hook：Pod 删除时会触发 preStop Hook，preStop Hook 支持 bash 脚本、TCP 或 HTTP 请求；发送 SIGTERM 信号：向 Pod 中的容器发送 SIGTERM 信号；等待指定的时间：terminationGracePeriodSeconds 字段用于控制等待时间，默认值为 30 秒。该步骤与 preStop Hook 同时执行，因此 terminationGracePeriodSeconds 需要大于 preStop 的时间，否则会出现 preStop 未执行完毕，pod 就被 kill 的情况；发送 SIGKILL 信号：等待指定时间后，向 pod 中的容器发送 SIGKILL 信号，删除 pod。中断原因：上述 1、2、3、4步骤同时进行，因此有可能存在 Pod 收到 SIGTERM 信号并且停止工作后，还未从 Endpoints 中移除的情况。此时，请求从 slb 转发到 pod 中，而 Pod 已经停止工作，因此会出现服务中断，如图 4 所示。 图 4 服务中断示意图 解决方法：为 pod 配置 preStop Hook，使 Pod 收到 SIGTERM 时 sleep 一段时间而不是立刻停止工作，从而确保从 SLB 转发的流量还可以继续被 Pod 处理。 iptables/ipvs中断原因：当 pod 变为 termintaing 状态时，会从所有 service 的 endpoint 中移除该 pod。kube-proxy 会清理对应的 iptables/ipvs 条目。而容器服务 watch 到 endpoint 变化后，会调用 slb openapi 移除后端，此操作会耗费几秒。由于这两个操作是同时进行，因此有可能存在节点上的 iptables/ipvs 条目已经被清理，但是节点还未从 slb 移除的情况。此时，流量从 slb 流入，而节点上已经没有对应的 iptables/ipvs 规则导致服务中断，如图 5 所示。 图 5 服务中断示意图 解决方法： Cluster 模式：Cluster 模式下 kube-proxy 会把所有业务 Pod 写入 Node 的 iptables/ipvs 中，如果当前 Node 没有业务 pod，则该请求会被转发给其他 Node，因此不会存在服务中断，如 6 所示；图 6 Cluster 模式请求转发示意图 Local 模式：Local 模式下，kube-proxy 仅会把 Node 上的 pod 写入 iptables/ipvs。当 Node 上只有一个 pod 且状态变为 terminating 时，iptables/ipvs 会将该 pod 记录移除。此时请求转发到这个 node 时，无对应的 iptables/ipvs 记录，导致请求失败。这个问题可以通过原地升级来避免，即保证更新过程中 Node 上至少有一个 Running Pod。原地升级可以保障 Node 的 iptables/ipvs 中总会有一条业务 pod 记录，因此不会产生服务中断，如图 7 所示；图 7 Local 模式原地升级时请求转发示意图 ENI 模式 Service：ENI 模式绕过 kube-proxy，将 Pod 直接挂载到 SLB 后端，因此不存在因为 iptables/ipvs 导致的服务中断。图 8  ENI 模式请求转发示意图 SLB图 9  服务中断示意图 中断原因：容器服务监控到 Endpoints 变化后，会将 Node 从 slb 后端移除。当节点从 slb 后端移除后，SLB 对于继续发往该节点的长连接会直接断开，导致服务中断。解决方法：为 SLB 设置长链接优雅中断（依赖具体云厂商）。 如何避免服务中断避免服务中断可以从 Pod 和 Service 两类资源入手，接下来将针对上述中断原因介绍相应的配置方法。 Pod 配置apiVersion: v1kind: Podmetadata: name: nginx namespace: defaultspec: containers: - name: nginx image: nginx # 存活检测 livenessProbe: failureThreshold: 3 initialDelaySeconds: 30 periodSeconds: 30 successThreshold: 1 tcpSocket: port: 5084 timeoutSeconds: 1 # 就绪检测 readinessProbe: failureThreshold: 3 initialDelaySeconds: 30 periodSeconds: 30 successThreshold: 1 tcpSocket: port: 5084 timeoutSeconds: 1 # 优雅退出 lifecycle: preStop: exec: command: - sleep - 30 terminationGracePeriodSeconds: 60注意：需要合理设置就绪检测（readinessProbe）的探测频率、延时时间、不健康阈值等数据，部分应用启动时间本身较长，如果设置的时间过短，会导致 POD 反复重启。 ...

作者 | 汪萌海、孙健波、宋净超 业界要闻1. 重磅！阿里巴巴开源首个边缘计算云原生项目 OpenYurt 北京时间 5 月 29 日，在阿里云容器服务 ACK@Edge（边缘集群托管服务） 发布一周年之际，阿里巴巴正式对外宣布将其核心能力开源，并向社区贡献完整的边缘计算云原生项目 —— OpenYurt。OpenYurt 是阿里巴巴首个边缘计算云原生开源项目，汇聚了阿里巴巴众多边缘计算业务团队的深厚技术积累，深度挖掘了“边缘计算 + 云原生落地实施“诉求。 2.Istio 1.6 正式 release 将 1.15 没有合并到 Istiod 的模块（Citadel，sidecar 注入，Galley）合并，支持 Istio 控制面上原地升级和金丝雀发布，提供了更丰富的 metric 输出，新增了 WorkloadEntry API 简化虚拟机支持等。 3.gke 引入容器安全风险检测的能力 gke 引入容器安全风险检测的能力（beta 阶段），目前包括二进制文件、lib 文件以及脚本文件的安全风险检测。 4.containerd 1.4.0-beta.0 发布 这是 containerd 的第 5 个大版本（预发布版本），此版本中包含了大量的新特性和漏洞修复。在 CRI 方面，同样也做了不少的变更：添加 Windows 容器进程的隔离；添加 CGroups v2 的支持；当监听到文件变化事件发生时，重启 CNI 网络配置等。 5.大规模秘钥管理（KES）介绍 作为云平台服务商的 KMS 系统和应用系统之间的桥梁，屏蔽多个云平台厂商的 KMSapi 的差异，KES 从 KMS 获取根秘钥信息等存储在内存中，用于代理 KMS处理无状态的加密和解密操作，减轻 KMS 的压力。 ...

作者 | 郭飞（阿里云资深技术专家）、徙远（阿里云高级技术专家）、新胜（阿里云技术专家） 导读：北京时间 5 月 29 日，在阿里云容器服务 ACK@Edge（边缘集群托管服务） 上线一周年之际，阿里巴巴正式宣布将其核心能力开源，并向社区贡献完整的边缘计算云原生项目 -- OpenYurt。边缘云计算是基于云计算技术的核心和边缘计算的能力，构筑在边缘基础设施之上的新型计算平台，并正在成为行业的新焦点。OpenYurt 作为阿里巴巴首个边缘计算云原生开源项目，汇聚了阿里巴巴众多边缘计算业务团队的深厚技术积累，深度挖掘了边缘计算 + 云原生落地实施诉求。 两年前，OpenYurt 作为公共云服务 ACK@Edge 的核心框架，就已经应用于 CDN、音视频直播、物联网、物流、工业大脑、城市大脑等实际应用场景中，并服务于阿里云 LinkEdge、盒马、优酷、视频云（视频点播、视频直播、实时通信、视频监控、智能视觉）等多个业务或项目中。 阿里巴巴云原生开源负责人、云原生应用平台资深技术专家李响表示：“随着边缘计算的场景和需求不断增加，‘云边协同’、‘边缘云原生’正在逐渐成为新的技术焦点。OpenYurt 开源项目实践‘云边一体化’概念，依托原生 Kubernetes 强大的容器编排、调度能力，实现完全边缘计算云原生基础设施架构，帮助开发者轻松完成在海量边、端资源上的大规模应用的交付、运维、管控。我们希望 OpenYurt 开源能推动社区在云原生和边缘计算交叉领域的协同发展。” 什么是 OpenYurt 使用 OpenYurt（Yurt，/jrt/，蒙古包）作为本次开源项目名称，期望以其“形”来表示边缘计算侧重于创建一个集中管理但物理分布的基础设施，并支持自动/自治运行操作的含义。 OpenYurt 主打“云边一体化”概念，依托原生 Kubernetes 强大的容器编排、调度能力，通过众多边缘计算应用场景锤炼，实现了一整套对原生 Kubernetes“零”侵入的边缘云原生方案，提供诸如边缘自治、高效运维通道、边缘单元化管理、边缘流量拓扑管理，安全容器、边缘 Serverless/FaaS、异构资源支持等能力。OpenYurt 能帮用户解决在海量边、端资源上完成大规模应用交付、运维、管控的问题，并提供中心服务下沉通道，实现和边缘计算应用的无缝对接。 1. OpenYurt 诞生背景时间倒回两年前，伴随当时的行业发展，边缘计算正在成为云计算的新焦点，而规模和复杂度的日益提升对边缘计算的效率、可靠性及资源利用率等一系列能力提出了更高的要求。从 2017 年底开始，阿里云物联网（IoT）和 CDN 服务作为典型的边缘计算业务正面临着产品规模的爆发式增长、运维复杂度急剧攀升、运维效率不高的“三难”境地，因此引入云原生理念、全面转型边缘应用的运维管理模式成为亟需解决的问题。 正是在这样的背景下，OpenYurt 诞生于阿里云容器服务团队，并在接下来的两年多时间内，作为公共云服务 ACK@Edge 的核心框架被广泛应用于 CDN、音视频直播、物联网、物流、工业大脑、城市大脑等实际应用场景中，并正在服务于阿里云 LinkEdge、盒马、优酷、视频云（视频点播，视频直播，实时通信，视频监控，智能视觉）等多个业务或项目中。 2. OpenYurt 技术特点OpenYurt 沿用了目前业界流行的“中心管控、边缘自治”的边缘应用管理架构，将“云边端一体化协同”作为目标，赋能云原生能力向边缘端拓展。在技术实现上，OpenYurt 贯彻了“Extending your native Kubernetes to  Edge”的核心设计理念，其技术方案有如下特点： 对原生 Kubernetes“零”侵入，保证对原生 K8s API 的完全兼容。不改动 Kubernetes 核心组件，并不意味着 OpenYurt 是一个简单的 Kubernetes Addon。OpenYurt 通过 proxy node network traffic，对 Kubernetes 节点应用生命周期管理加了一层新的封装，提供边缘计算所需要的核心管控能力；无缝转换，OpenYurt 提供了工具将原生 Kubernetes“一键式”转换成支持边缘计算能力的 Kubernetes 集群；低 Overhead，OpenYurt 参考了大量边缘计算场景的实际需求，在保证功能和可靠性的基础上，本着最小化，最简化的设计理念，严格限制新增组件的资源诉求。以上技术特点使得 OpenYurt 能够： ...

作者 | 酒祝  阿里云技术专家、墨封  阿里云开发工程师 直播完整视频回顾：https://www.bilibili.com/video/BV1mK4y1t7WS/ 关注“阿里巴巴云原生”公众号，后台回复 “528” 即可下载 PPT 5 月 28 日，我们发起了第 3 期 SIG Cloud-Provider-Alibaba 网研会直播。本次直播主要介绍了阿里经济体大规模应用上云过程中遇到的核心部署问题、采取的对应解决方案，以及这些方案沉淀为通用化能力输出开源后，如何帮助阿里云上的用户提升应用部署发布的效率与稳定性。 本文汇集了此次直播完整视频回顾及资料下载，并整理了直播过程中收集的问题和解答，希望能够对大家有所帮助~ 前言随着近年来 Kubernetes 逐渐成为事实标准和大量应用的云原生化，我们往往发现 Kubernetes 的原生 workload 对大规模化应用的支持并不十分“友好”。如何在 Kubernetes 上为应用提供更加完善、高效、灵活的部署发布能力，成为了我们探索的目标。 本文将会介绍在阿里经济体全面接入云原生的过程中，我们在应用部署方面所做的改进优化、实现功能更加完备的增强版 workload、并将其开源到社区，使得现在每一位 Kubernetes 开发者和阿里云上的用户都能很便捷地使用上阿里巴巴内部云原生应用所统一使用的部署发布能力。 第一期网研会回顾：Kubernetes SIG-Cloud-Provider-Alibaba 首次网研会（含 PPT 下载）第二期网研会回顾：在生产环境中，阿里云如何构建高性能云原生容器网络？（含 PPT 下载）阿里应用场景与原生 workloads阿里巴巴容器化道路的起步在国内外都是比较领先的。容器这个技术概念虽然出现得很早，但一直到 2013 年 Docker 产品出现后才逐渐为人所熟知。而阿里巴巴早在 2011 年就开始发展了基于 LXC 的容器技术，经过了几代的系统演进，如今阿里巴巴有着超过百万的容器体量，这个规模在世界范围内都是顶尖的。 随着云技术发展和云原生应用的兴起，我们近两年间逐步将过去的容器迁到了基于 Kubernetes 的云原生环境中。而在这其中，我们遇到了不少应用部署方面的问题。首先对于应用开发者来说，他们对迁移到云原生环境的期望是： 面向丰富业务场景的策略功能极致的部署发布效率运行时的稳定性和容错能力阿里的应用场景非常复杂，基于 Kubernetes 之上生长着很多不同的 PaaS 二层，比如服务于电商业务的运维中台、规模化运维、中间件、Serverless、函数计算等，而每个平台都对部署、发布要求各有不同。 我们再来看一下 Kubernete 原生所提供的两种常用 workload 的能力： 简单来说，Deployment 和 StatefulSet 在一些小规模的场景下是可以 work 的；但到了阿里巴巴这种应用和容器的规模下，如果全量使用原生 workload 则是完全不现实的。目前阿里内部容器集群上的应用数量超过十万、容器数量达到百万，有部分重点核心应用甚至单个应用下就有上万的容器。再结合上图的问题，我们会发现不仅针对单个应用的发布功能不足，而且当发布高峰期大量应用同时在升级时，超大规模的 Pod 重建也成为一种“灾难”。 ...

作者 | 徐靖峰  阿里云高级开发工程师 前言Dubbo 线程池满异常应该是大多数 Dubbo 用户都遇到过的一个问题，本文以 Arthas 3.1.7 版本为例，介绍如何针对该异常进行诊断，主要使用到 dashboard / thread 两个指令。 推荐使用 Arthas方式一：推荐使用 IDEA 插件下载 Cloud Toolkit 来使用 ArthasCloud Toolkit 是阿里云发布的免费本地 IDE 插件，帮助开发者更高效地开发、测试、诊断并部署应用。通过插件，可以将本地应用一键部署到任意服务器，甚至云端（ECS、EDAS、ACK、ACR 和 小程序云等）；并且还内置了 Arthas 诊断、Dubbo工具、Terminal 终端、文件上传、函数计算 和 MySQL 执行器等工具。不仅仅有 IntelliJ IDEA 主流版本，还有 Eclipse、Pycharm、Maven 等其他版本。 方式二：直接下载Dubbo 线程池满异常介绍理解线程池满异常需要首先了解 Dubbo 线程模型，官方文档：http://dubbo.apache.org/zh-cn/docs/user/demos/thread-model.html。 简单概括下 Dubbo 默认的线程模型：Dubbo 服务端每次接收到一个 Dubbo 请求，便交给一个线程池处理，该线程池默认有 200 个线程，如果 200 个线程都不处于空闲状态，则客户端会报出如下异常： Caused by: java.util.concurrent.ExecutionException: org.apache.dubbo.remoting.RemotingException: Server side(192.168.1.101,20880) threadpool is exhausted ...服务端会打印 WARN 级别的日志： [DUBBO] Thread pool is EXHAUSTED!引发该异常的原因主要有以下几点： ...

作者 | 声东  阿里云售后技术专家 <关注阿里巴巴云原生公众号，回复 排查 即可下载电子书> 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！ Istio is the future！基本上，我相信对云原生技术趋势有些微判断的同学，都会有这个觉悟。其背后的逻辑其实是比较简单的：当容器集群，特别是 Kubernetes 成为事实上的标准之后，应用必然会不断的复杂化，服务治理肯定会成为强需求。 Istio 的现状是，聊的人很多，用的人其实很少。所以导致我们能看到的文章，讲道理的很多，讲实际踩坑经验的极少。阿里云售后团队作为一线踩坑团队，分享问题排查经验，我们责无旁贷。这篇文章，我就跟大家聊一个简单 Istio 问题的排查过程，权当抛砖。 二分之一活的微服务问题是这样的，用户在自己的测试集群里安装了 Istio，并依照官方文档部署 bookinfo 应用来上手 Istio。部署之后，用户执行 kubectl get pods 命令，发现所有的 Pod 都只有二分之一个容器是 READY 的。 # kubectl get podsNAME READY STATUS RESTARTS AGEdetails-v1-68868454f5-94hzd 1/2 Running 0 1mproductpage-v1-5cb458d74f-28nlz 1/2 Running 0 1mratings-v1-76f4c9765f-gjjsc 1/2 Running 0 1mreviews-v1-56f6855586-dplsf 1/2 Running 0 1mreviews-v2-65c9df47f8-zdgbw 1/2 Running 0 1mreviews-v3-6cf47594fd-cvrtf 1/2 Running 0 1m如果从来都没有注意过 READY 这一列的话，我们大概会有两个疑惑：2 在这里是什么意思，以及 1/2 到底意味着什么。 ...

2013年，Pivotal公司率先提出云原生（Cloud Native）概念。 云原生以容器化、微服务、可持续交付性，帮助企业构建和运行可弹性扩展的应用。由于云原生应用构建简便快捷，部署轻松自如，运行按需伸缩等特点，近年来受到越来越多企业的欢迎。 随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势，云原生（Cloud Native）的概念应运而生，更是火得一塌糊涂。 在过去的一个月里，我们开启了《六周玩转云原生》系列技术公开课，主要包括容器入门，kubernetes的介绍，DevOps与持续交付 ，监控与日志，微服务架构服务的治理体系以及Serverless 架构设计与落地应用等基本要素。 在整个课程中，我们的技术专家为开发者不仅介绍了云原生具体技术概念和理论，还加入了具体应用案例分析让开发者对云原生技术有更深入认识。同时，考虑到开发者理解云原生需要技术理论与实践应用结合，他们还详细介绍了每一种技术应用和上手实践方法。 由于这一系列内容真的是我们的“心头肉”，我们特将此次的内容做了一个整理合集分享给大家。 第一周：容器入门，Docker、Pod初探容器是云原生概念的重要组成部分，作为一种计算单元，容器可以以更加轻量化、更小开销的方式来运行；而作为一种应用的包装形式，容器则赋予了应用独立和便携的能力。随着Docker、Kubernetes技术的成熟，容器也成为了时下最火的开发理念。 根据Gartner的预计，2022年有75%的全球化企业将在生产中使用容器化的应用（当前约为30%）、50%的应用软件将容器化适应超融合环境（目前约为20%）。Docker和Kubernetes将从成为成为跨环境的新标准。因此，了解容器、Docker的基本概念，是玩转云原生开发的基础。 京东云与 AI 云产品研发部专家架构师刘俊辉，从容器的基本构成出发，深入浅出地勾勒出容器的基本情况，包括容器的结构、基本使用方式等。不仅如此，还将引出 Docker 这一重要概念，为开发者们拨开容器应用的迷雾。此外，刘俊辉还会着重讲解 POD、了解 POD 的构成和基本应用，帮助开发者对容器有更深入理解。 开发者_@baddytimothy_体验后称，本次探索容器实现的常用工具体验课很有收获，对Docker运行环境及运行，管理容器的基本操作，Linux系统工具都有了初步详细的了解，并对容器和POD的基本结构有了一定认识。而在动手操作上，通过基于京东智联云控制台对原生容器的创建，及对容器的基本操作，使得对容器有了更清晰的了解，也明白了原生容器与Docker容器的异同，为其学习打下了不错的基础。 视频回放 动手实操练习：https://developer.jdcloud.com/article/904 第二周：走近kubernetes，从概念到基础应用尽管以敏捷和高性能而著称的容器，已经成为了许多企业的首选方案。但如何解决大量容器的管理和部署，以及对容器化应用进行编排却是一个复杂的问题。针对这些问题，Google和Red Hat在2014年提出了Kubernetes解决方案。 近几年中，Kubernetes已经成为了数不多的，使自己成为所属领域的行业标准的新技术之一，是学习容器技术中不可忽视的存在，也是开发者及运维人员中最流行的开发工具。 不过，Kubernetes本身的复杂程度非常高，用户熟悉起来非常困难。 在容器入门课程之后，第二节课程继续由刘俊辉担任讲师，主要分享Kubernetes的主要组成部分和基本应用，以及POD、Deployment、Service等主要的Kubernetes资源，Kubernetes可以处理几乎任何类型的容器负载，Kubernetes的作用可以贯穿整个应用开发的生命周期。了解Kubernetes可以将帮助你更深入地理解软件的基础设施的运作。最后，他还就京东智联云Kubernetes的集群服务进行介绍。 为了让开发者对Kubernetes有更深的理解，刘俊辉还通过动手实操环节体验Kubernetes集群服务的基础功能。 开发者_@Suave_称，通过本次课程易懂，简单部署，他在Kubernetes上部署了简单应用，创建一个Master节点和一个Nodes节点，Master节点是kubernetes的管理中心，Nodes节点是实际运行服务的劳动者。视频回放 动手实操练习：https://developer.jdcloud.com/article/914 第三周：云原生下的DevOps与持续交付众所周知，Kubernetes + Docker 是 Dev 和 Ops 融合的一个桥梁。近几年，我们看到应用在开发流程和生产运维流程中的变化。在过去，开发团队的任务是创建应用、并交付给运维团队，然后运维团队部署应用并使它运行。 但是现在，公司都意识到，让同一个团队参与应用的开发、部署和运维会更好，这意味着开发者、QA和运维团队彼此之间的合作需要贯穿整个流程，这种实践被称为DevOps（Development和Operations的组合词，是一组过程、方法与系统的统称，用于促进开发）。 在《六周玩转云原生》的第三期课程上，井亮亮老师对DevOps与持续交付的基础支持进行了全面讲解，开发者们学到了关于DevOps与持续交付的基础支持，以及京东智联云在这方面的实践与应用。 开发者_@colin-jdcloud_学习后指出，本次课程为其普及了DevOps和持续交付的理念，而随着课程逐步深入，他对京东智联云的操作也越来越熟练，实践操作得很顺利。视频回放 动手实操练习：https://developer.jdcloud.com/article/922?mid=12 第四周：走近监控与日志，云原生基石探秘作为云原生的基石之一，监控和日志的重要性自是不言而喻。 云原生应用具有分布与动态的特性，而所有此类应用通常都会用到容器和无服务器函数等临时技术来予以部署。 在管理这些云原生应用的时候，能够在任何给定的时间内提供端到端的可视性就显得尤为重要。与此同时，由于云原生系统具有海量的数据流和抽象的复杂性，因此我们必须建立强大的监控和日志记录，以管控各种不可预知的中断或宕机。 没有监控，就无法知晓服务的运行情况，也没有办法知道集群中有没有Down机、机器的CPU使用率和负载是否正常、网站的Traffic是否正常、服务的出错率是不是在可容忍范围内。而日志则详尽记录着系统运行情况，每一次Service的调用，每一次数据库的访问，都应该写进日志，特别是当系统出现问题时。 为了让开发者学习到更多干货，高云川老师分享了云原生下的可观测性，Prometheus监控方案和EFK的日志方案，以及京东智联云在云原生监控&日志的落地实践，并与开发者们讨论在记录和监控云原生应用时各种值得借鉴和遵循的优秀实践与标准。 最后，他还邀请开发者们动手实践，深入参与并体验云原生监控体验。 视频回放 动手实操练习：https://developer.jdcloud.com/article/935?mid=12 第五周：微服务架构下，服务治理体系的演进历程随着微服务已成为构建现代云应用的主导模式，“大平台、微服务”已成为一个典型技术特征。 当然，微服务架构下，服务之间的调用关系变得更加复杂，以往的开发、测试、运维模式会不可避免的要进行重构或调整，为保证服务更好的运行，就需要对这些服务进行监控和管理，这已成为令许多工程师头疼的问题。 提到微服务，当下最火热微服务治理的框架无疑就是Spring Cloud，它基于 Spring Boot 可实现快速集成，开发效率极高的特性，堪称中小型互联网公司的福音。而Service Mesh则以轻量级的网络代理的方式与应用代码部署在一起，用于保证服务与服务之间调用的可靠性，开发者更应了解其技术发展路径。 张俊峰老师讲述了服务治理理念演变史，由浅入深讲解Spring Cloud微服务架构特点、Service Mesh技术以及京东智联云在微服务方面的探索。 ...