1. 性能优化面对的挑战以下是整个PaaS平台的架构其中主要包括这些子系统：微服务治理框架：为应用提供自动注册、发现、治理、隔离、调用分析等一系列分布式/微服务治理能力，屏蔽分布式系统的复杂度。应用调度与资源管理框架：打通从应用建模、编排部署到资源调度、弹性伸缩、监控自愈的生命周期管理自动化。应用开发流水线框架：打通从编写代码提交到自动编译打包、持续集成、自动部署上线的一系列CI/CD全流程自动化。云中间件服务：应用云化所需的数据库、大数据、通信和应用中间件服务；通过服务集成管控可集成传统非云化的中间件能力。面对一个如此复杂的系统，性能优化工作是一个非常艰巨的挑战，这里有这么一些痛点：源代码及开发组件多，100+ git repo，整体构建超过1天运行架构复杂，全套安装完需要30+VM，200+进程软件栈深，网络平面复杂集群规模大，5k — 10k节点环境搭建非常困难系统操作会经过分布式的多个组件，无法通过单一组件诊断发现系统瓶颈无法追踪上千个处于不同层次的API的时延和吞吐大部分开发人员专注于功能开发，无法意识到自己的代码可能造成性能问题2. 优化分析那么，对于这么一个大的、复杂的系统，从方法论的角度来讲，应该怎么去优化呢？基本思路就是做拆分，把一个大的问题分解为多个互相不耦合的维度，进行各个击破。从大的维度来讲，一个PaaS容器集群，可以分为3个大的子系统。控制子系统：控制指令的下发和运行(k8s)，例如创建pod业务流量子系统：容器网络(flannel)、负载均衡(ELB/kube-proxy)监控子系统：监控告警数据的采集(kafka, Hadoop)这个看起来仅仅是一个架构上的划分，那么如何和具体的业务场景对应起来呢？我们可以考虑如下一个场景，在PaaS平台上大批量的部署应用。看看在部署应用的过程中，会对各个子系统产生什么压力。应用软件包大小：400M应用模板大小：10M1000个节点，每个节点一个POD，一个实例10种类型的软件包，依赖长度为3，10GB 网络调度及资源管理 3VM这是一个典型的部署应用的一些规格，那么对于这样的一个输入，我们可以按照架构把压力分解到每个子系统上，这样得出的子系统需要支撑的指标是：控制子系统： kubernetes调度速度 > 50 pods/s，仓库支持300并发下载，>40M/s数据子系统：overlay容器网络TCP收发性能损耗 <5%监控子系统：在上面这个场景中不涉及，但可以从别的场景大致告警处理能力100条/秒这里的业务场景：架构分析：子系统指标，这三者是m:1:n的，也就是说在不同场景下对不同的组件的性能要求不同，最后每个组件需要取自己指标的最大值。指标决定了后续怎么进行实验测试，而测试是要花较大时间成本的，所以在指标的选取上要求少求精，尽量力图用2-3个指标衡量子系统。3. 优化测试 & 工具上面讲的还是偏纸上的推演和分析，接下来进入实战阶段对于服务器后端的程序来讲，推荐使用Promtheus这个工具来做指标的定义和采集。Promtheus的基本工作原理是：后端程序引入Promtheus的SDK，自定义所有需要的测量的指标，然后开启一个http的页面，定期刷新数据。Promtheus服务器会定期抓取这个页面上的数据，并存在内部的时间序列数据库内。这种抓而非推的方式减少了对被测试程序的压力，避免了被测程序要频繁往外发送大量数据，导致自身性能反而变差而导致测量不准确。Promtheus支持这几种数据类型：计数(对应收集器初始化方法NewCounter、NewCounterFunc、NewCounterVec，单一数值，数值一直递增，适合请求数量统计等)测量(对应收集器初始化方法NewGauge、NewGaugeFunc、NewGaugeVec，单一数值，数值增减变动，适合CPU、Mem等的统计)直方图测量(对应收集器初始化方法NewHistogram、NewHistogramVec，比较适合时长等的统计)概要测量(对应收集器初始化方法NewSummary、NewSummaryVec，比较适合请求时延等的统计)我们可以看看在kubernetes项目里面是怎么用的：var ( // TODO(a-robinson): Add unit tests for the handling of these metrics once // the upstream library supports it. requestCounter = prometheus.NewCounterVec( prometheus.CounterOpts{ Name: "apiserver_request_count", Help: "Counter of apiserver requests broken out for each verb, API resource, client, and HTTP response contentType and code.", }, []string{"verb", "resource", "client", "contentType", "code"}, ) requestLatencies = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: "apiserver_request_latencies", Help: "Response latency distribution in microseconds for each verb, resource and client.", // Use buckets ranging from 125 ms to 8 seconds. Buckets: prometheus.ExponentialBuckets(125000, 2.0, 7), }, []string{"verb", "resource"}, ) requestLatenciesSummary = prometheus.NewSummaryVec( prometheus.SummaryOpts{ Name: "apiserver_request_latencies_summary", Help: "Response latency summary in microseconds for each verb and resource.",// Make the sliding window of 1h. MaxAge: time.Hour, }, []string{"verb", "resource"}, ) )在这里，一个http请求被分为verb, resource, client, contentType, code这五个维度，那么后面在PromDash上就能图形化的画出这些请求的数量。 从而分析哪种类型的请求是最多，对系统造成最大压力的，如图除了Promtheus，还可以引入其他的测量手段，对系统进行分析。在kubernetes调度过程中，各个状态Pod的数量，看哪一步是最卡的go pprof分析，哪些函数是最耗CPU的4. 优化开发发现了瓶颈之后，下一步就是解决瓶颈，和具体业务逻辑有关，本文在这里就不做过多的阐释。需要对相关代码非常熟悉，在不改变功能的情况下增强性能，基本思路为并发/缓存/去除无用步骤等。5. 优化成果这是我们在kubernetes项目上控制面优化的成果控制面指标华为分支数据社区版数据Master节点数量5无明确数据Node节点(kubemark模拟)数量10000节点5000节点部署吞吐率>100 pod/s约为50 pod/sPod端到端延时<2s<5sAPI延时<79.321ms<1s这里仅仅显示了控制子系统的指标，其他子系统还没有支持那么大的集群，尤其在网络方面，不同用户的网络架构差别很大。所以数据仅供参考。6. 优化的优化在上面的优化过程当中，基本上工程师要做几百次优化的测试和开发。这里会产生一个循环：测试寻找瓶颈点修改代码突破这个瓶颈点重新测试验证这段代码是否有效，是否需要改优化思路这就是一个完整的优化的迭代过程，在这个过程当中，大部分时间被浪费在构建代码、搭建环境、输出报告上。开发人员真正思考和写代码的时间比较短。为了解决这个问题，就需要做很多自动化的工作。在kubernetes优化的过程中，有这么几项方法可以节省时间：kubemark模拟器 ：社区项目，使用容器模拟虚拟机，在测试中模拟比达到1：20，也就是一台虚拟机可以模拟20台虚拟机对apiserver产生的压力。在测试过程当中，我们使用了500台虚拟机，模拟了10000节点的控制面行为。CI集成：提交PR后自动拉性能优化分支并开始快速构建CD集成：使用I层的快照机制，快速搭建集群并执行测试案例输出测试报告以上都是在实践过程中总结的一些点，对于不同的项目工程应该有很多点可以做进一步的优化，提升迭代效率。在搭建完这套系统后，我们发现这个系统可以从源头上预防降低系统性能的代码合入主线。如果一项特性代码造成了性能下降，在CI的过程当中，功能开发者就能收到性能报告，这样开发者就能自助式的去查找自己代码的性能问题所在，减少性能工程师的介入。

什么是“容器”和“虚拟机”容器和虚拟机它们的目的很相似：即将应用程序和它的依赖放到一个可以在任何环境运行的自足单元中。此外，容器和虚拟机消除了对物理硬件的需求，从而在能源消耗和成本效益方面能让我们更有效地使用计算资源，容器和虚拟机的主要区别在于它们的架构方式。让我们继续深入了解。虚拟机虚拟机在本质上是对现实中计算机的仿真，它会像真实的计算机一样执行程序。使用 “hypervisor” 可以将虚拟机运行于物理机上。hypervisor 可以在主机运行，也可以在“裸机”上运行。让我们来揭开这些术语的面纱：hypervisor（之后都以虚拟机管理程序称呼）是能让虚拟机在其上运行的软件，固件或者硬件。虚拟机管理程序本身会在物理计算机上运行，称为**“主机”**。主机为虚拟机提供资源，包括 RAM 和 CPU。这些资源在虚拟机之间被划分并且可以根据需要进行分配。所以如果一个虚拟机上运行了资源占用更大的应用程序，相较于其它运行在同一个主机的虚拟机你可以给其分配更多的资源。运行在主机上的虚拟机（再次说明，通过使用虚拟机管理程序）通常也被叫做“访客机”。访客机包含了应用以及运行这个应用所需要的全部依赖（比如：系统二进制文件和库）。它还带有一个自己的完整虚拟化硬件栈，包括虚拟化的网络适配器，储存和 CPU-这意味着它还拥有自己成熟的整个访客操作系统。从虚拟机内部来看，访客机的操作都认为其使用的都是自己的专用资源。从外部来看，我们知道它是一个虚拟机-和其它虚拟机一起共享主机提供的资源。就像前面所提到的，访客机既可以运行在托管的虚拟机管理程序上，也可以运行在裸机虚拟机管理程序上。它们之间存在一些重要的差别。首先，托管的虚拟化管理程序是在主机的操作系统上运行。比如说，可以在一台运行 OSX 操作系统的计算机的系统上安装虚拟机（例如：VirtualBox 或者 VMware Workstation 8）。虚拟机无法直接访问硬件，因此必须通过主机上运行的操作系统访问（在我们的例子中，也就是 Mac 的 OSX 操作系统）。托管虚拟机管理程序的好处是底层硬件并不那么重要。主机的操作系统会负责硬件的驱动而不需要管理程序参与。因此这种方式被认为具备更好的“硬件兼容性”。在另一方面，在硬件和管理程序之间这个额外的附加层会产生更多的资源开销，这会降低虚拟机的性能。裸机虚拟机管理程序通过直接在主机硬件上安装和运行来解决这个性能问题。因为它直接面对底层的硬件，所以并不需要运行在主机的操作系统之上。在这种情况下，安装在主机上第一个作为操作系统运行的就是这个裸机虚拟机管理程序。与托管虚拟机管理程序不同，它有自己的设备驱动直接与每个组件交互，以执行任何 I/O，处理或特定于操作系统的任务。这样可以获得更好的性能，可伸缩性和稳定性。这里的权衡在于其对硬件的兼容性有限，因为裸机虚拟机管理程序内置的设备驱动只有那么多。在讨论了虚拟机管理程序之后，你可能想知道为什么我们需要在虚拟机和主机之间这个额外的“虚拟机管理程序”层。好吧，虚拟机管理程序在其中确实发挥了重要的作用，由于虚拟机拥有自己的虚拟操作系统，管理程序为虚拟机管理和执行访客操作系统提供了一个平台。它允许主机与作为客户端运行的虚拟机之间共享其资源。虚拟机图示正如你可以在图示中所看到的，VMS 会为每个新的虚拟机打包虚拟硬件，一个内核（即操作系统）和用户空间。容器与提供硬件虚拟化的虚拟机不同，容器通过抽象“用户空间”来提供操作系统级别的虚拟化。当我们详解容器这个术语的时候你就会明白我的意思。从所有的意图和目的来看，容器看起来就像一个虚拟机。比如说，它们有执行进程的私有空间，可以使用 root 权限执行命令，具有专有的网络接口和 IP 地址，允许自定义路由和 iptable 规则，可以挂载文件系统等。容器和虚拟机之间的一个重要区别在于容器和其它容器共享主机系统的内核。容器图示这图表明容器只会打包用户空间，而不是像虚拟机那样打包内核或虚拟硬件。每个容器都有自己独立的用户空间从而可以让多个容器在单个主机上运行。我们可以看到所有操作系统级别的体系架构是所有容器共享的。要从头开始创建的部分只有 bins 和 libs 目录。这就是容器如此轻巧的原因。Docker 是从哪来的？Docker 是基于 Linux 容器技术的开源项目。它使用 Luinux 的内核功能（如命名空间和控制组）在操作系统上创建容器。容器已经远远不是一个新技术：Google 已经使用他们自己的容器技术好多年了。其它的容器技术包括 Solaris Zones、BSD jails 和 LXC 也已经存在好多年。那么为啥 Docker 会突然取得成功呢？使用简单：Docker 使得任何人（开发人员，运维，架构师和其他人）都可以更轻松的利用容器的优势来快速构建和测试可移植的应用程序。它可以让任何人在他们的笔记本电脑上打包应用程序，不需要任何修改就可以让应用运行在公有云，私有云甚至裸机上。Docker 的口头禅是：“一次构建，处处运行”。速度：Docker 容器非常轻量级和快速。因为容器只是运行在内核上的沙盒环境，因此它们占用的资源更少。与可能需要更多时间来创建的虚拟机相比，你可以在几秒钟内创建一个 Docker 容器，因为虚拟机每次都必须启动一个完整的操作系统。Docker Hub：Docker 用户也可以从日益丰富的 Docker Hub 生态中受益，你可以把 Docker Hub 看作是 “Docker 镜像的应用商店”。Docker Hub 拥有数万个由社区构建的公共镜像，这些镜像都是随时可用的。在其中搜索符合你需求的镜像非常容易，你只需要准备拉取镜像而且几乎不需要任何修改。模块化和可扩展性：Docker 可以让你轻松地把应用程序按功能拆分为单个独立的容器。比如说，你的 Postgre 数据库可以运行在一个容器中，Redis 服务运行在另一个容器中，而 Node.js 应用运行在另一个容器中。使用 Docker，将这个容器链接在一起以创建你的应用程序将会变得更简单，同时在将来可以很轻松地扩展和更新单独的组件。最后但并不重要的是，有谁不喜欢 Docker 的鲸鱼（Docker 的标志）呢？：）

KubeEdge v0.2发布KubeEdge在18年11月24日的上海KubeCon上宣布开源的一个开源项目，旨在依托K8S的容器编排和调度能力，实现云边协同、计算下沉、海量设备的平滑接入。KubeEdge脱胎于华为云IEF服务，是第一个具备在生产环境部署能力的边缘计算领域开源项目。前几天K8S IOT/Edge工作组发布了关于边缘计算的白皮书，并将KubeEdge作为K8S在IOT/Edge场景下的参考架构。KubeEdge架构上包含两部分，分别是云端和边缘侧。云端负责应用和配置的下发，边缘侧则负责运行边缘应用和管理接入设备。在v0.2版本中，KubeEdge团队决定开放云端代码，这样KubeEdge v0.1和v0.2的发布分别创造了两个记录：全球首个开源的支持容器部署的边缘计算平台；全球首个开放云边协同能力的边缘计算平台；KubeEdge v0.2 的发布意味着任何人都可以在自己的环境中部署一个完整的涵盖云、边、设备的边缘计算解决方案。另外本次更新还在 v0.1 的基础上新增了云上两个重要组件，分别是：CloudHub和EdgeController，架构如下所示：其中：Cloudhub负责接收EdgeHub同步到云端的信息；EdgeController用于控制K8S API Server与边缘的节点、应用和配置的状态同步；用户可以直接通过kubectl命令行在云端管理边缘节点、设备和应用，使用习惯与K8S原生的完全一致，无需重新适应。Rancher发布轻量级Kubernetes发行版 K3s近期，容器管理软件提供商 Rancher Labs宣布推出轻量级的 Kubernetes 发行版 K3s，这款产品专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计。根据Rancher描述，为了减少运行Kubernetes所需内存，k3s主要专注于以下三个方向的变化：删除旧的、非必须的代码整合正在运行的打包进程使用 containerd 代替 Docker 作为运行时的容器引擎除了 etcd 之外，引入 SQLite 作为可选的数据存储k3s官方描述的主要使用场景为：边缘计算与应用程序绑定使用嵌入式设备整体来看，k3s相当于kubernetes针对边缘计算等特殊场景的裁剪和优化，而并非专门专门边缘计算场景的解决方案，未来可能还需要长足的演进和适配过程。阿里宣布开源 Flutter 应用框架 Fish Redux3 月 5 日，闲鱼宣布在 GitHub 上开源 Fish Redux，Fish Redux 是一个基于 Redux 数据管理的组装式 flutter 应用框架， 特别适用于构建中大型的复杂应用，它最显著的特征是 函数式的编程模型、可预测的状态管理、可插拔的组件体系、最佳的性能表现。Redux 是来自前端社区的一个用来做 可预测易调试 的数据管理的框架，所有对数据的增删改查等操作都由 Redux 来集中负责。Redux 核心仅仅关心数据管理，不关心具体什么场景来使用它，这是它的优点同时也是它的缺点。在实际使用 Redux 中可能面临两个具体问题：Redux 的集中和 Component 的分治之间的矛盾；Redux 的 Reducer 需要一层层手动组装，带来的繁琐性和易错性；Fish Redux 通过 Redux 做集中化的可观察的数据管理，并且针对传统 Redux 在使用层面上的缺点，在面向端侧 flutter 页面纬度开发的场景中，通过更好更高的抽象，做了改良。开源之后，闲鱼打算通过以下方式来维护 Fish Redux：通过后续的一系列的对外宣传，吸引更多的开发者加入或者使用。配合后续的一系列的闲鱼 Flutter 移动中间件矩阵做开源；进一步提供，一系列的配套的开发辅助调试工具，提升上层 Flutter 开发效率和体验；又现云平台宕机企业应如何尽量避免损失北京时间2019年3月2日23:55分左右开始，监控发现华北2地域部分ECS实例及部分EMR、RDS on ECS、DTS、DBS实例及服务状态异常，事后于3月3日阿里云工程师紧急排查处理，并且逐步恢复异常实例。细数这两年，国际主流云厂商在安全性和可靠性层面做了不少努力，但所有服务都不可能百分百稳定，尽管云平台会发生故障，但企业对云的信赖度依然很高。Gartner 研究主管 Sid Nag 曾表示，云服务市场的增长速度比几乎所有 IT 市场都要快，其中大部分增长是以传统非云服务为代价，尤其是基于云计算的 IaaS 需求在继续增长，预计将在未来 5 年呈现最快增长趋势。在云计算出现之前，企业内部自建数据中心依旧会出现很多问题，不少问题甚至是致命的。上云之后，公有云厂商至少可以帮助技术能力有限的企业进行合理范围内的监控、预警和备份。不可否认，云的出现确实解决了现阶段企业在计算、存储等方面的很多问题。但作为企业而言，完全依靠云计算厂商提供安全性的做法是不可取的。云环境的同城双活、异地灾备等方案基本就绪，尽量在经济和人员条件可行的情况下使用这些分散风险的方法。如果故障只出在一个服务器集群，采用异地灾备方案可以在最快时间切换到另一个集群，从而保持系统可用。虽然还是会有中断，但是可以最快时间恢复。按照此模式，云下系统做云上灾备也是防范传统环境出现可用性问题的一种重要手段。作为企业的 IT 人员，日常做到以下四点可以尽可能避免云故障带来的损失。•备份、备份，还是备份，要异机异地；•数据容灾；•业务双活；•定期对灾备和双活进行演练。从统计上看，中小企业的运维水平远低于主流云平台，故障概率要高得多，损失更不可控。因此，不必对云服务故障抱有恐惧，只需要保持正常的认知和高度灾备意识即可。

ServiceComb的rest支持两个通道：transport-rest-vertxtransport-rest-servlet一般来说，只需要使用其中一个，但是也有可能同时使用，当通过maven将它们同时引入依赖时，初始化策略如下：先尝试transport-rest-servlet如果servicecomb.rest.address指定的端口，已经被监听了，则认为端口被servlet容器监听了（实际不一定，还可能是其他进程，这里不再做识别），需要启用transport-rest-servlet如果端口未被监听，则说明servicecomb.rest.address配置的端口与servlet容器不同，不需要启用transport-rest-servlet再尝试transport-rest-vertx如果servicecomb.rest.address指定的端口未被监听，则说明需要启用transport-rest-vertx，否则不需要启用如果所有两个通道，都判定为不需要启用，则说明肯定不是期望的结果，此时会报“all transport named rest refused to init”注：  当只引入一个依赖时，其实也是按上面的逻辑判定，只不过引入哪个依赖，就按哪个依赖的逻辑运行  如果最终无法启用，则一样会报这个错误

 本次课程希望能够帮助您深入理解华为云镜像服务，包括私有镜像与公共镜像之间的区别，探讨当前华为云镜像服务的各种功能。 简单的说，镜像就好像是克隆体，它可以把一个已有的云主机操作系统和应用服务，快速的复制到您的云主机中，省时又省力。   温馨小提示：还没有华为云账户来体验本节课程的操作吗？戳这里，免费注册华为云账户！有账户没有云服务器？戳这里，免费试用4核8G高速云服务器！ 镜像是一个包含了软件及必要配置的云服务器模版，包含操作系统或业务数据，还可以包含应用软件（例如，数据库软件）和私有软件。 选择使用的镜像类型创建弹性云服务器时，在选择完规格后接下来就是选择镜像。华为云支持使用公共镜像、私有镜像、共享镜像、市场镜像创建云服务器。知识拓展：什么是镜像服务？镜像的常见格式有哪些？ 选择“公共镜像”：云平台提供的公共镜像，包括操作系统以及预装的公共应用，所有用户可见，请根据您的实际情况自助配置应用环境或相关软件。当前云平台所有支持的操作系统均在下拉列表中可见。 使用公共镜像创建的云服务器可以提供官网OS的技术支持。 同时，公共镜像预装了Cloudbase-Init/Cloud-Init工具、PV driver、UVP VMTools等常用工具，免去了用户自定义安装配置。 我本次购买选择的是Ubuntu 24.0的公共镜像。可以在后期云服务器购买完成后检查是否已经安装了上述工具。 知识拓展：Cloud-Init可以对新创建的云服务器中指定的自定义信息（主机名、密钥和用户数据等）进行初始化配置。点击获取：如何检查云服务器是否已经安装Cloud-init工具？云服务器的正常运行依赖于XEN Guest OS driver（PV driver）和KVM Guest OS driver（UVP VMTools），为了同时支持XEN虚拟化和KVM虚拟化，需要确保镜像安装了PV driver和UVP VMTools。点击获取：如何查看Windows操作系统云服务器虚拟化类型？、如何查看Linux操作系统云服务器器虚拟化类型？选择“私有镜像”：用户自己制作的， 包含操作系统或业务数据，预装了用户的私有应用的镜像，仅用户自己可见。 我们可以在镜像服务的列表页面详细查看当前区域下可用的私有镜像。 注意：在创建私有镜像时需自行安装Cloud-init，最近镜像服务新增“采用源码编译安装方法”，Cloud-init配置的相关内容已在源码包编译完成，采用源码编译安装方法安装Cloud-init后无需执行Cloud-init配置操作，创建私有镜像时推荐大家使用源码编译方法安装Cloud-init。 知识拓展：如需指定云服务器的镜像，请提前使用指定云服务器创建私有镜像：使用Windows云服务器创建私有镜像。如需使用本地的镜像文件，请提前将镜像文件导入并注册为云平台的私有镜像：如何将外部镜像文件注册为华为云平台私有镜像。如需使用其他区域的私有镜像，请提前复制镜像：跨区域复制镜像。选择“共享镜像”：其他用户共享的私有镜像，作为自己的镜像进行使用、可以用来创建云服务器、裸金属服务器和云硬盘。 如果需要使用其他账号的私有镜像，请提前完成镜像共享。我们可以在镜像服务的列表页面详细查看当前区域下可用的共享镜像。 知识拓展：当前镜像共享的范围只能在区域内。如需跨区域共享镜像可以和镜像服务当前的跨区域复制镜像功能相互结合，先跨区域复制镜像至同一区域，然后再共享镜像。选择“市场镜像”：第三方提供的预装操作系统、应用环境和各类软件的优质镜像。 市场镜像的优势在于提供预装操作系统、应用环境和各类软件的优质第三方镜像。 按照市场镜像的协议购买后，即可享受第三方的服务支持，无需配置，可一键部署，满足建站、应用开发、可视化管理等个性化需求。当前很多基础功能的市场镜像是免费的，只需支付云服务器的按需/包年包月的费用。 知识拓展：使用市场镜像部署WordPress（Windows）使用市场镜像部署Windows环境趣味课堂：镜像服务针对各种类型的镜像制作一张精美问云图说，可以快速了解公共镜像、私有镜像、共享镜像、市场镜像与弹性云服务器之间的关系，推荐大家点击查看。镜像服务最新推出的整机镜像功能支持使用弹性云服务器携带其挂载的数据盘一起创建整机镜像，创建的整机镜像包含用户的业务数据，可用于快速发放包含用户业务数据的弹性云服务器。         -  使用云服务器创建整机镜像         -  使用云服务器备份创建整机镜像随堂小测当前华为云镜像服务仅支持在同一区域内共享镜像，如果用户小A想要将华北-北京1的私有镜像共享至用户小B的华南-深圳区域，应该怎样实现呢？ 随堂小测奖励规则：1、通过直接回帖的方式回答小测，我们会根据回答正确答案的先后顺序打分：2、回答正确的前十名朋友可以获得分数，即：第一个回答正确得10分，第二个回答正确得9分……以此类推；3、每五次随堂小测一汇总，得分最高的朋友将得到实物奖励（荣耀手环一个）； 希望大家踊跃回答，更多奖励等你来拿哦~~~~   【往期回顾】 【第一课】我该怎么选择云主机的规格？

镜像交付流水线ContainerOps是华为云容器镜像服务（SWR）推出的面向从源代码到生产上线全流程服务，提供镜像仓库、镜像构建、版本管理、交付流水线等一系列服务，助力企业落地容器DevOps最佳实践。镜像交付流水线ContainerOps正在公测中，点此立即体验：https://console.huaweicloud.com/swr?c_yuntu  ContainerOps帮助中心文档，请参见https://support.huaweicloud.com/usermanual-swr/swr_01_0034.html更多产品信息请点击：https://www.huaweicloud.com/product/cce.html0元起体验云原生之旅：https://activity.huaweicloud.com/cloudnative.html?ggw_hd更多免费体验请点击：https://www.huawei.com/audience/answer.do?u=1664982欢迎关注官方公众号了解更多云原生内容：

之前给大家讲了构建镜像的原理，那么有了镜像之后，我们怎么样能将它快速的部署到kuberentes集群上呢？ 早期，大家都习惯于使用kubernetes接口，或者cli命令行来完成这些操作，但是yaml文件语法的复杂性、大量容器和kuernetes的概念，让人难以理解，无疑成为容器化交付路上的又不障碍。为了解决这些问题，华为云容器服务推出了向导式镜像部署，通过一步步引导、对复杂概念的屏蔽或抽象，在一定程度上降低了用户首次部署镜像的难度，但是灵活度相对较差，对于经常变更版本的场景，还是需要使用原生接口进行操作，使得整体研发交付流程的复杂度并未降低太多。鉴于此现状华为云容器团队又推出了一款易用性更好、自动化程度更高的服务产品——容器交付流水线，它以容器技术为基础，践行DevOps的理念，围绕容器业务端到端场景提供持续集成和持续交付能力，包括代码编译、镜像构建与交付、自动化部署、升级回滚等能力，并提供全量能力接口，便于与企业已有流程相结合，同时接口屏蔽底层容器概念，对接口进行了二次封装，接口定义更贴近于CI/CD业务概念，使得熟悉CI/CD流程的用户能快速切换。发布组件作为该产品的一个重要组成部分，其直接影响了整个发布周期，我们今天就跟大家一起聊聊该部件的一些实现原理。01Kubernetes DeploymentKubernetes Deployment提供了官方的用于更新Pod和ReplicaSet（下一代的Replication Controller）的方法，我们可以在Deployment对象中填写我们需要用到的配置和版本信息，Deployment控制器将现在的实际状态转换成我们所期望的状态，例如，将nginx:v1.0升级成nginx:v2.0，我们只需创建一个Deployment，Kubernetes会按照Deployment自动进行升级。而随着Kubernetes的迭代更新，目前云容器引擎服务提供了几个版本的集群，那么如何使得部署组件支持不同的集群版本呢？由于我们的CI/CD的工具提供了deployment的yaml页面编辑，部署组件会根据deployment中apiversion即：apps/v1, apps/v1beta1, extensions/v1beta1。提供不同版本的API接口。自行封装接口使得发布组件自主能动性强，免于受制于第三方库。02如何判断发布成功？解决了版本问题，还有一个最重要的问题，是如何判断组件发布结果呢？对于一个CI/CD工具，我们判断工作负载运行成功的标准并不仅仅是Pod处于running状态又或者工作负载处于可用状态。我们需要保证的是工作负载运行的镜像或者配置是新版本的。因此我们判断成功的标志应该是新起的pod处于running状态，那如何找到这些新起的pod呢？下图展示了Deployment，ReplicaSet和Pod之间的关系，以无状态工作负载为例，我们通过查询deployment中Annotations的"deployment.kubernetes.io/revision"，根据这个revision寻找Deployment控制的ReplicaSet。最后根据ReplicaSet的label去寻找这些新起的pod。我们已经找到这些新起的Pod了，那么现在就需要对pod的状态进行分析了。在K8s源码中PodPhase字段表示了pod的不同阶段：Pending: k8s已经接受创建pod的请求，但是容器并没有启动成功，这个阶段包括调度之前的，下载镜像等。 Running: pod已经绑定到node节点，并且所有的容器已经启动成功，或者至少有一个容器在运行，或者在重启中。 Succeeded: pod中的所有的容器已经正常的自行退出，并且k8s永远不会自动重启这些容器。 Failed: pod中的所有容器已经终止，并且至少有一个容器已经终止于失败（退出非零退出代码或被系统停止）。 Unknown: 由于一些未知的原因，无法获得pod的状态，通常是因为pod的主机通信错误。而以上四个阶段只是一个粗略状态阶段。而对于每一个阶段都有更详细的pod conditions信息，podcondition数组的元素都包含了类型和状态字段，这个类型分为以下四种:"Ready"：Pod能够提供服务"PodScheduled"：pod正处于调度中"Unschedulable"：调度程序现在无法调度Pod，例如由于缺乏资源或其他限制;"Initialized"：所有pod的容器初始化已经完成。"ContainersReady"：pod中的容器都已准备好。其中状态字段用"true" 表示处于,"false"表示不处于，我们发现当阶段为Running, condition中Ready状态为True时， 即表示pod中的容器可以提供服务了。因此，我们现在就可以依次判断新起的pod是否升级成功了。03如何判断发布失败？现在我们能够判断成功了，下一步就需要对失败的状态进行一个判断，其实理论上负载的成功或者失败不是一个确定性的东西，k8s本身具有重试机制，也存在概率性调度失败的情况。所以一开始我们考虑的是通过一个超时机制来判断发布失败的情况。但后面分析考虑到，发布作为一个重要的组件，需要第一时间知道问题所在，以致可以快速进行版本回退等操作。对于容器的状态，pod中的containerstatus包含了更详细的当前容器的状态。其state字段表示容器当前的状态，state分为三种状态：等待中，运行中和已终止，对应三种不同类型的结构体。等待中的结构体包含了处于非运行状态的原因和信息。其他结构体就不在此一一赘述。结合podphase、podcondition、以及containerstatus，我们总结了如下几个升级异常状态（如有不全，欢迎补充）：PodPhase == FailedPodPhase == SucceededContainerStatuses 中有一项为state.waiting 并且 waiting 的原因不是ContainerCreating 或者 PodInitializing(ContainerCreating表示容器创建中，PodInitializing表示pod初始化中)ContainerStatuses 中有一项为state.running 并且 containerStatuses.ready == falseConditions中存在一项的type为Ready且status为False且Containerstatues存在Conditions中存在一项的type为PodScheduled且status为False：调度失败由于pod的状态是动态变化的，为了保证发布结果的准确性，我们选择pod超过3次时置为失败状态，即发布失败。看完上面这些原理解析，您是不是有什么收获，或者有什么想法与我们交流呢？请在下方留下您宝贵意见和建议吧？说不定下个版本，您的创意就会出现在我们的产品里。相关服务请访问https://www.huaweicloud.com/product/swr.html?cce_helpcenter_2019

Istio利用k8s的探针对service进行流量健康检查，有两种探针可供选择，分别是liveness和readiness:liveness探针用来侦测什么时候需要重启容器。比如说当liveness探针捕获到程序运行时出现的一个死锁，这种情况下重启容器可以让程序更容易可用。readiness探针用来使容器准备好接收流量。当所有容器都ready时被视为pod此时ready。比如说用这种信号来控制一个后端服务，当pod没有到ready状态时，服务会从负载均衡被移除。使用场景：liveness探针被用来移除异常的pod，不重启pod就无法恢复的应用常使用liveness探针。比如前文提到的死锁，进程会一直处于活跃状态，k8s会认为正常并继续发送流量。但使用liveness探针之后会发现应用已经不再处理请求，继而重启异常pod。readiness探针被用来控制流量进入pod。比如应用程序需要加载一个大的文件或者需要启动后进行一些配置。但默认只要容器进程启动完成就会有流量发送过来。使用readiness探针会一直等待直到完成所有加载或配置再让流量进入。两种探针的配置相似，区别在于使用livenessProbe还是readinessProbe字段探针配置参数：探针有以下几个参数：initialDelaySeconds：容器启动之后到启动探针之间的时延periodSeconds：探针的循环执行时间，最小单位为1秒timeoutSeconds：探针超时时间，默认值1秒successThreshold: 成功阈值数，失败之后最小的连续成功信号数，liveness必须是1failureThreshold：失败阈值数，当探针失败之后，在放弃之前k8s尝试重新执行探针次数,如果是liveness探针放弃意味着重启容器，readiness探针意味着pod标记为unready，默认值为3次。HTTP探针还有以下额外的参数：host: 所连接主机名，默认值是pod IPscheme: HTTP或者HTTPSpath： 访问HTTP 服务器的路径httpHeaders: 访问HTTP的报头port:访问容器的端口探针可以进行三种操作：命令行：在容器中执命令行操作，exit 0为成功状态HTTP请求：向容器发送HTTP GET请求，如果返回值为200-400之间为成功状态TCP 请求：向指定端口发送TCP请求，如果该端口开放监听，则为成功下面我们来演示以下健康检查的操作：命令行操作首先准备busybox镜像，设置如下的yaml配置文件：在配置文件中我们设置了一个liveness探针，在容器启动之后的5s,每隔5s去执行一下访问/tmp/healthy这个文件的操作，如果操作成功返回0，则为容器健康，如果返回值不为0， 会重启容器。当容器启动之后会执行：touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600前30s会建立/tmp/healthy文件，30s之后删除，此时访问会返回错误.使用kubectl create -f ./your-exec-liveness.yaml建立pod在30s之内通过kubectl describe pod liveness-exec来查看pod状态，为健康：在30s之后查看pod的状态，发现无法访问文件，返回不健康：之后查看pod的状态，pod的重启次数为1，此时通过liveness探针检测到不健康状态已经重启pod。如果使用readiness探针，需要修改上文your-exec-liveness.yaml的红框字段：通过与上文相同的方法，在30s之前查看pod的状态，为ready:在30s之后查看pod状态，readiness探针将应用容器置为unready, ready的容器是istio-proxy：可以看到readiness探针并不会重启容器。HTTP请求另一种使用liveness探针的方法是HTTP GET请求，可以用来监测网页的运行状态，我们用google liveness镜像来进行演示：这里我们让HTTP的服务器/healthz路径前10s返回200 的OK状态，10s之后返回状态500。设置如下的配置文件：liveness探针会向容器的8080端口发送请求访问/healthz， 在容器启动3s之后每隔3s发送一次。我们建立pod并查看pod的运行状态kubectl describe pod liveness-http：会发现10s之后 liveness探针监测到了返回值是500，状态标记为不健康。TCP请求两种探针还可以共同使用，下面以TCP请求为例，TCP和HTTP连接类似。使用google的goproxy镜像，该镜像会在8080端口开放TCP socket连接，使用如下的配置文件：我们用探针去访问8000端口查看pod状态；此时理论上应该无法连接：可以看到readiness探针会每隔10s监测，无法访问时会将pod置于unready状态，liveness探针20s监测，无法成功则重启pod。 通过以上演示我们了解了如何配置两种探针和执行三种操作。通过合理的探针配置，可以实时监控Istio各个pod的运行状态，提供方便的应用治理手段。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

华为开源镜像站体验第一次作为体验官体验华为的产品， 要输出报告。本次报告输出体验报告内容要求要涵盖部分内容，再加一点个人的体会吧。操作体验是否能顺畅的找到自己所需要的组件镜像，并加入到自己的项目中。首页图片， 标语是` 华为开源镜像站由华为云DevCloud团队开发及维护，DevCloud致力于打造让软件开发更简单的一站式DevOps工具云服务`其实这行可以更大一点， 竟然比登陆注册的文字都要小。从导航条能看出来提供了语言类，工具类，操作系统类，容器类等几个大类别， 还有华为SDK。系统类这个页面进来之后感觉稍微有点问题， 默认的排序方式是首字母， 作为展示推荐的功能， 默认按照热度排序召回会更好些。然后点了按照热度这个界面好，每个卡片标注了类别， 但看了之后第一反应是我要找ubuntu的镜像， 按照系统类筛选下。点了操作系统类之后， 怎么又跳回默认的字母排序了。这Ubuntu按说也算是常用源，但是按照字母排序，妥妥的排在倒数。再回看刚才那个图，发现热度排序首页也已经有了， 只是屏幕小，在最下面，没注意到。Ubuntu在系统类排序中排名第四。建议1. 这个建议做两级筛选， 排序方式和类别筛选分开做。 1. 搜索条可以更大点，挺好用的。容器类提供了Docker的镜像，虽然官方国内也能访问。性能构建过程，加载组件的速度。Ubuntu界面指引这个里面点赞是可以水的，不停的点就可以。使用说明觉得也还OK了下载了下Docker，一分钟左右吧，还可以Docker容器镜像和系统类的还不太一样，标题点不了，还没来得及融合的更好。和原镜像对比了下centos的镜像下载，还是， 挺慢的。但是在华为云的服务器上， 速度还是很快的，可以感受下对比下。功能特性k8s阿里云有提供镜像， 华为云没有。满意度及推荐度如果服务器在HWC的话，还是蛮推荐用的， 速度很快。就Docker来讲， 本地速度似乎没有优势。采用华为的云生态DevOps的话，这个开源站无疑很棒， 速度各方面都有保证。从初心上来讲， OK了。` 华为开源镜像站由华为云DevCloud团队开发及维护，DevCloud致力于打造让软件开发更简单的一站式DevOps工具云服务`这个活动也蛮好， 之前还没太关注镜像站。

微服务为我们带来了快速开发部署的优秀特性，而如何降低开发和变更的风险成为了一个问题。Istio的流量镜像，也称为影子流量，是将生产流量镜像拷贝到测试集群或者新的版本中，在引导实时流量之前进行测试，可以有效地降低版本变更风险。流量镜像有以下优点：1.当流量镜像到不同的服务时，会发生在请求的关键路径之外，这样流量镜像产生的任何问题都不会影响到生产；2.忽略对任何镜像流量的响应; 流量被视为“即发即忘”，这样就不会干扰到正常的生产流量的响应；3.当流量被镜像时，请求将通过其主机/授权报头发送到镜像服务附上 –shadow，用以区分流量从何处被镜像到何处；4.利用实时生产用例和流量可以有更真实的测试服务环境，有效降低了部署的风险；下面介绍几种典型的使用场景可以发挥流量镜像的优势：1.用于测试：测试集群的测试可以使用生产实例真实流量，不会影响正常生产的关键路径。2.用于新版本校验：可以实时对比生产流量和镜像流量的输出结果。3.用于协作服务版本回退:当用到镜像流量的服务需要修改协作服务时，因为镜像模式添加了-shadow标记, 所以可以正常处理镜像请求，并在提交之前回滚。不会让镜像版本的更改影响生产版本。4.隔离测试数据库：与数据处理相关的业务，可以使用空的数据存储并加载测试数据，针对该数据进行镜像流量操作，实现测试数据的隔离。下面通过实例来演示一下，先让所有流量都到v1版本，然后使用规则将流量镜像到v2版本：环境准备：需要httpbin和tutum/curl两个应用镜像步骤一(配置并启动服务)：首先部署两个版本的httpbin服务：httpbin-v1:httpbin-v2:部署sleep服务，为curl来提供负载：当完成以上的配置文件后，就可以用kubectl create –f ./yourconfig.yaml来启动服务，用kubectl get pod 来查看服务的运行状态：启动httpbin service:先通过kubectl get svc 查看是否有httpbin service。如果已创建service, 需要用kubectl delete service httpbin 删除，并通过下图所示yaml 新建service：步骤二（创建路由策略）：1.使用kubectl delete virtualservice httpbin，kubectl delete destinationrule httpbin删除已有httpbin策略，并通过下图yaml来创建新的路由策略，将全部的流量导入到v1版本：通过kubectl create –f ./yourrules.yaml生效：2.现在服务已经搭建好了，我们向服务发送一些流量：3.分别查看httpbin的v1,v2的pod中的日志：我们可以发现v1 pod中有刚才流量访问的记录，而v2的pod中日志为空，说明流量并没有进入到v2的pod中，这与我们全部流量导入到v1中的策略相匹配。步骤三（镜像流量）：1. 修改路由规则将流量镜像到v2服务：删除之前部署的virtualservice规则，将上图的yaml用kubectl create –f 部署，其中mirror字段将流量镜像指定到v2服务。2.发送流量：通过指令kubectl exec -it $SLEEP_POD -c sleep -- sh -c 'curl  http://httpbin:8080/headers' | python -m json.tool 发送流量：3.查看v1和v2的访问日志:通过对比记录的时间戳我们可以发现在更改策略后，v1的流量被镜像到了v2。日志中的v2报文比v1大是流量被标记为影子流量所致。步骤四（清除）：1.清除路由规则：kubectl delete virtualservice httpbinkubectl delete destinationrule httpbin2.关闭httpbin/sleep服务：kubectl delete deploy httpbin-v1 httpbin-v2 sleepkubectl delete svc httpbin通过以上步骤我们知道了如何设置路由规则来引入流量镜像。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

虽然docker、kubernetes的命令集并非十分复杂，后台操作也比较快捷，但是对于大多数徘徊在容器化门口的企业和个人用户来说，仍旧是一块心病，docker or not docker， that's a question，SWR服务通过提供界面化的操作，屏蔽原生命令行，简化用户操作和技术门槛，为企业和个人用户提供极简的容器化交付平台，我们接下来会通过一系列的文章，向大家介绍SWR的这些功能特性。今天要为大家介绍的是用户0命令行，通过WEB界面实现镜像的上传及实现原理剖析。 我们从这个最为常用并极为简单的docker push功能开始讲，为什么呢？由于我们在与客户交流过程中发现，大多数都未接触过容器化管理系统，甚至镜像，对后端操作不熟悉的他们，对页面操作是有一定需求的。目前主流的PaaS平台基本都支持通过页面操作构建镜像、创建集群、创建应用等等，它们都在不断地封装底层集群管理系统（如kubernetes）的接口，设计一款对于云下用户友好的前端页面，让尽可能多的后端复杂操作可以通过鼠标的几次点击完成。我们可以将这个趋势解释为，用户的业务云化的成本（包括金钱成本和时间成本）越低，上云的倾向也就越大。如今，我们支持用户在页面上完成构建、部署等操作，如果可以实现镜像上传下载都在页面上完成，用户就可以在尝试云化的早期尽可能避开后端操作，将尽可能多的时间成本花在业务调试上，普通运维人员不需要熟悉docker命令，也可以从内网或者第三方镜像仓库下载镜像，上传并完成升级操作。接下来，我们从镜像上传逻辑和镜像结构开始讲起，阐述如何去实现页面上传镜像的功能。后端上传镜像流程分析我们的目的是实现另一种镜像上传方式，首先要了解原生的镜像上传流程是怎样的。上传镜像层docker push时，最先被上传的是镜像层文件。如下面的busybox，每一行的short ID都表示着一个镜像层的sha256值，它有两个镜像层：上传元数据文件由于层之间有顺序依赖关系，我们可以想到，上传的层文件是不足以完备地描述整个镜像的。除了镜像层文件外，docker push的时候还额外会上传一个镜像的元数据文件。该文件主要保存了镜像的环境变量、层结构、构建信息等等，并且它的sha256值就是镜像的ID。由于字段太多，在此不详细列出各字段的含义，感兴趣的朋友可以使用docker inspect命令查看，参阅docker官方文档了解一下。上传manifest你们是否注意到，每个镜像在上传结束之后，屏幕上都会多一行`xxx: digest: xxx size: xxx`，最后一行信息的打印，标识着镜像最后一部分数据上传完成，这部分数据就是manifest，而digest后面的长ID，就是manifest的sha256值。manifest主要是负责关联镜像的元数据文件和镜像层。在所有层都上传结束后，它才被传到仓库端的，用于校验是否所有实体文件都上传完成。通过抓包或者查阅官方文档，我们可以得知，manifest的结构是这样的：由上述分析可知，要完备地描述一个镜像，需要存储如下数据：镜像层元数据文件Manifest我们接下来分析一下，从docker save生成的镜像包里，我们是否能获取到这些数据。镜像压缩包结构分析通过docker save保存镜像压缩包，解压开之后，可以发现，它的文件结构是比较有序的。根目录下有这三个文件：此外，包内还有多个以长ID命名的目录，每个目录下均有如下三个文件：这里，有两个较为普遍的误区需要澄清一下：误区一：manifest.json就是manifestmanifest里描述的是元数据文件名称，以及各个层的sha256值，此外，还有它们的大小。而manifest.json里存放的不是完整的manifest信息，它仅仅记录了元数据文件的全路径名称，以及各个镜像层的全路径名称，没有记录各个层的sha256值和大小。误区二：各个层所在的目录名就是镜像层的sha256值其实目录名是用各个层的链ID（chain ID）和关联父层的链ID联合计算出来的一个特殊sha256值。这个特殊的sha256值，我们可以称之为v1 ID，它被设计于兼容较早版本(1.10之前)的docker镜像，早期版本，一个镜像中可能存在多个sha256值相同的层（如空层）。顺带提一下，上面的链ID是docker daemon使用递归的方式将每一层与依赖的所有父层联合算出sha256得到的，它可以有效解决层相同导致目录重名的问题，具体计算方式在此就不赘述了。明白了这两点之后，我们可以发现，镜像压缩包里是可以获取到与docker push同样完备的镜像数据的。其中，镜像层和元数据文件可以通过解压直接获取，而manifest则需要我们通过补充manifest.json获得。接下来我们看一看华为云容器镜像服务是怎么实现这一过程的。页面上传是怎么实现的解压并校验镜像压缩包传至后端时，先对压缩包里的文件类型校验（普通文件、软链接、目录），确认无误之后，解压至临时目录并进行大小校验（前端上传目前有大小限制）。此外，有一类镜像需要被过滤：通过`docker save image_id > image.tar`命令生成的镜像包。这类镜像是没有有效的镜像仓库和版本号信息的，我们无法判断要将其归于哪个仓库下，因此，这样的镜像可以认为是不合法的。对于页面上传而言，合法的镜像压缩包里必须有镜像仓库和版本号信息(如使用`docker save repository:tag > image.tar`的方式生成的镜像)。保存实体文件接下来，通过临时目录下的manifest.json，找到对应的元数据文件xxxx.json和各个目录下的镜像层文件进行存储。保存之前，通过元数据文件xxxx.json中各个层的sha256值，对实际镜像文件进行校验，保存过程中，我们在manifest.json的基础上，补充各个镜像层和元数据文件的sha256值、大小等信息，得到manifest。在这里有个需要注意的地方，层文件一般都是普通文件，但是个别情况下（如docker1.10之前的版本），层文件可能是软链接，指向同镜像压缩包里的的另一个层文件，如果要兼容老版本，需要识别出这一部分特殊文件，跳过实体文件的保存。保存元数据最后，将镜像层元数据列表和manifest元数据在同一事务里存进数据库，保证镜像元数据的存储是一个原子操作，则镜像所有数据保存完成。该镜像可以通过docker pull的方式正常下载。这只是华为云容器镜像服务基于优化用户体验的目的而开发的特性之一，我们一直致力于降低云容器技术的槛和使用成本，推进软件行业容器化的进程，希望有兴趣的朋友可以来体验一下，并提供你们宝贵的意见。除此之外，我们最近还新上线了容器持续交付的工具，可以将您的源码快速编译、构建成镜像，省去本地编写Dockerfile、镜像制作、发布和部署的繁琐过程，后面文章我们将详细为您介绍。

ContainerOps12月16日，OSChina在深圳举办的”源创会年终盛典”上，华为云容器服务技术总监发表了名为《DevOps On Kubernetes》的主题演讲，演讲就如何将DevOps理念与容器技术相结合，实现容器化场景下的快速交付进行介绍，并重点介绍了华为云容器服务提供的持续交付工具——容器交付流水线（ContainerOps）。DevOps作为一种形而上的理念，其落地实施必然离不开CI/CD等一系列工具的支撑，CI/CD工具的出现大大提升了企业的软件行业的效率，可以称得上是软件工程领域的工业革命，但容器化的大浪潮到来时，企业现有的CI/CD工具， 以及围绕着这些工具所构建的集成和交付体系，因为与企业IT流程耦合深，升级难度大，正慢慢成为企业容器化转型路上的绊脚石，阻碍企业的容器化进程，主要体现在：因为新技术引入，需要对老的CI/CD脚本进行大量改造，以支持Docker构建并对接Kubernetes。镜像的外部依赖如何管理？已有的仓库如maven，仅能解决软件自身的依赖，无法支持镜像管理。基础镜像都在海外仓库，下载速度慢，甚至被拦截。大量的CI/CD工具，功能各有千秋，但没有统一的标准，切换或集成都很困难。缺乏针对容器应用的运维管理平台。以上这些问题都严重影响了企业进行容器化改造的决心，也延缓了企业容器化的进程。要解决这些问题必须有一种更适合于容器化业务流程的工具来支撑DevOps的践行。新DevOps工具产品至少要解决如下几个问题：兼容企业已有的CI/CD流程：容器化的过程不可能一蹴而就，肯定会有一个较长的混合部署期，需要新老流程并存，且不能冲突。降低容器化过程的技术门槛：需要降低企业已流程改造的技术成本，提供的方案能基于已有知识体系快速上手、集成，缩短。提供完善的镜像管理方案，镜像的存储、海外镜像的获取和加速。降低容器化后的运维复杂度：容器作为一种运行态，容器应用的升级、回滚、监控等责任更多的落在了运维团队身上，要让运维团队接受，必须有更优于现有业务的运维体验。为解决这些问题，华为云容器镜像服务推出了容器交付流水线（ContainerOps），流水线功能围绕容器镜像的全生成周期管理展开，提供包括：镜像构建、部署、灰度发布等容器化过程中的关键能力，并且能与企业已有IT系统及华为软件开发云（DevCloud）集成。与市面上其它开源及商业化的流水线相比，其优势在于：开箱即用，内置标准化流程模板简化使用      ContainerOps内置多种典型场景的流水线，      不需要写额外编写shell脚本或者Dockerfile，      开通服务即可直接使用，大大降低容器化的技      术门槛。支持alpha-beta-gamma多环境端到端敏捷交付       支持跨流水线协同工作，完美支持alpha-beta-       gamma跨环境的自动化升级部署，极大的简化       了研发和运维流程。灰度发布和一键式回滚       基于Istio的服务治理，轻松实现服务的发布管理，       以及一键式回滚功能，让应用的运维管理更简单。开放式架构，易于与企业已有系统集成       ContainerOps北向开放API，可以对接企业       已有的CI/CD流水线，南向还支持异构CI/CD       系统的对接，确保企业已有资源最大化复用，       减少对企业现有工具、流程、软件的修改。无缝对接华为软件开发云，支持虚机+容器混合部署，覆盖DevOps全流程场景       ContainerOps还能对接华为软件开发云       DevCloud，实现DevOps流程能力覆盖，解决       企业在容器化过程中，虚机 + 容器混合部署难       的问题。海外镜像加速，解决各类行业场景问题        全球构建节点智能调度，提供镜像构建的效率，        解决海外镜像获取难的问题。目前容器交流水线已在华为云正式商用，您可以访问以下地址进行体验：https://www.huaweicloud.com/product/swr.html

  在java内部已有内置的观察者模式，如类 java.util.Observable和类java.util.Observer，即是被观察者和观察者。在 java.util.Observable 中，存储观察者对象的容器是Vector，此容器支持动态扩展和同步性，用法与ArrayList类似。Observable内部方法如下所示：      一对一直播源码，Java观察者模式案例简析观察者模式的内在原理：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己。即：通过将一组对象实例存储在一个数组容器中，在某一时刻遍历数组并调用数组内的对象方法完成更新。被观察者Observable内部的核心方法：1 public void notifyObservers(Object arg) {2 /*3 * a temporary array buffer, used as a snapshot of the state of4 * current Observers.5 */6 Object[] arrLocal;7 8 synchronized (this) {9 if (!changed)10 return;11 arrLocal = obs.toArray();12 clearChanged();13 }14 15 for (int i = arrLocal.length-1; i>=0; i--)16 ((Observer)arrLocal).update(this, arg);17 }加同步锁synchronized可避免线程并发问题，设置changed状态可监听更新。for循环遍历执行观察者Observer内部的方法update()。                                                                                                                                     被观察者继承Observable类，动态发布消息通知观察者更新。如：复制代码1 /**2 * 被观察者类3 *4 * @author jinzifu5 * @create 2018/2/22 15:366 */7 public class ObservableClass extends Observable {8 private String message;9 10 public String getMessage() {11 return message;12 }13 14 public void setMessage(String message) {15 this.message = message;16 //被观察者数据发生变化时，通过以下两行代码通知所有的观察者17 this.setChanged();18 this.notifyObservers(message);19 }20 }复制代码观察者实现了Observer接口，支持扩展。如：                                                                                                                               复制代码1 /**2 * 观察者类3 *4 * @author jinzifu5 * @create 2018/2/22 15:146 */7 public class ObserverClass implements Observer {8 private String name;9 10 public ObserverClass(String name) {11 this.name = name;12 }13 14 @Override15 public void update(Observable o, Object arg) {16 System.out.println(name + ":" + arg);17 }18 }复制代码外部测试如   复制代码1 /**2 * @author jinzifu3 */4 public class Main {5 6 public static void main(String[] args) {7 8 ObservableClass observableClass = new ObservableClass();9 ObserverClass observerClass1 = new ObserverClass("observerClass1");10 ObserverClass observerClass2 = new ObserverClass("observerClass2");11 ObserverClass observerClass3 = new ObserverClass("observerClass3");12 ObserverClass observerClass4 = new ObserverClass("observerClass4");13 14 observableClass.addObserver(observerClass1);15 observableClass.addObserver(observerClass2);16 observableClass.addObserver(observerClass3);17 observableClass.addObserver(observerClass4);18 19 observableClass.setMessage("收到通知，完成更新。");20 }21 }                                   

【摘要】 华为云的云容器引擎（Cloud Container Engine，简称CCE）可以提供高可靠高性能的企业级容器应用管理服务，CCE.Cluster、CCE.NodePool用于部署华为云PaaS层的kubernetes集群资源。我们在已创建虚拟私有云和子网的模板中，加入创建一个容器集群（包含一个节点）。目前容器是非常热门的一项技术，是Cloud2.0时代的技术标准。华为云的云容器引擎（Cloud Container Engine，简称CCE）可以提供高可靠高性能的企业级容器应用管理服务，CCE.Cluster、CCE.NodePool用于部署华为云PaaS层的kubernetes集群资源。通过CCE.Cluster资源可以为用户提供编排用户应用功能。通过创建CCE.NodePool资源，方便用户将华为云上资源编排在节点上，提供更加强大优质的功能。我们在已创建虚拟私有云和子网的模板中，加入创建一个容器集群（包含一个节点）：tosca_definitions_version: huaweicloud_tosca_version_1_0node_templates:  mysubnet:    type: HuaweiCloud.VPC.Subnet    properties:      cidr: '192.168.1.0/24'      dhcpEnable: true      gateway: 192.168.1.1      name: my-subnet      vpcId:        get_reference: myvpc    requirements:      - vpcId:          node: myvpc  myvpc:    type: HuaweiCloud.VPC.VPC    properties:      cidr: '192.168.0.0/16'      name: my-vpc  mycluster:    type: HuaweiCloud.CCE.Cluster    properties:      subnetId:        get_reference: mysubnet      flavor: cce.s1.small      vpcId:        get_reference: myvpc    requirements:      - subnetId:          node: mysubnet      - vpcId:          node: myvpc  mynode:    type: HuaweiCloud.CCE.NodePool    properties:      dataVolumes:        - volumeType: SATA          size: 100      instances: 1      rootVolume:        volumeType: SATA        size: 40      sshKeyName: KeyPair-ac70      flavor: s3.small.1      clusterId:        get_reference: mycluster    requirements:      - clusterId:          node: myclustermy-cluster是一个容器集群对象，用于部署华为云PaaS层的kubernetes集群资源。其中参数flavor表示集群规格，可在CCE创建集群页面查询可使用的集群规格名称。my-node是CCE.NodePool对象，用于部署华为云PaaS层kubernetes节点资源。my-node有如下几个参数：    1.         dataVolumes：创建节点的数据盘模型。    2.         instances：创建节点的数量。    3.         rootVolume：创建节点的系统盘模型。    4.         sshKeyName：创建节点登录时使用的密钥对，需要在ECS服务界面提前创建。    5.         flavor：容器节点的规格。    6.         clusterId：资源所属的集群ID，模板中设置为刚创建的集群my-cluster。容器集群创建成功：

Istio是什么？Istio是Google继Kubernetes之后的又一开源力作，主要参与的公司包括Google，IBM，Lyft等公司。它提供了完整的非侵入式的微服务治理解决方案，包含微服务的管理、网络连接以及安全管理等关键能力，无需修改任何代码就能够实现微服务的负载均衡，服务与服务之间的认证授权以及监控。从整个基础设施角度上看，可以将它理解为PaaS平台上的一个面向微服务管理平台的补充。Istio架构示意图Istio与KubernetesKubernetes提供了部署、升级和有限的运行流量管理能力；利用service的机制来做服务注册和发现，转发，通过kubeproxy有一定的转发和负载均衡能力。但并不具备上层如熔断、限流降级、调用链治理等能力.Istio则很好的补齐了k8s在微服务治理上的这部分能力，同时是基于k8s构建的，但不是像SpringCloud Netflix等完全重新做一套。Istio是谷歌微服务治理上的非常关键的一环。Istio与k8s紧密结合，包括：Sicecar 运行在k8s pod里，作为一个proxy和业务容器部署在一起，部署过程对用户透明。Mesh中要求业务程序的运行感知不到sidecar的存在，基于k8sd的pod的设计这部分做的更彻底，对用户更透明，用户甚至感知不到部署sidecar的这个过程。试想如果是通过VM上部署一个agent，不会有这么方便。Pilot中包含一个controller，通过list/watch kube-apiserver自动发现K8S中的services、endpoints。它通过在Kubernetes里面注册一个controller来监听事件，从而获取Service和Kubernetes的Endpoint以及Pod的关系，但是在转发层面，不再使用kube-proxy转发了，而是将这些映射关系转换成为pilot自己的转发模型，下发到envoy进行转发。K8s编排容器服务已经成为一种事实上的标准；因为微服务与容器在轻量、快速部署运维等特征的匹配，微服务运行在容器中也正成为一种标准实践；对于云原生应用，采用Kubernetes构建微服务部署和集群管理能力，采用Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。            自行管理Istio与CCE上使用Istio服务网格的对比华为云 · 云容器引擎CCE(Cloud Container Engine)提供高可靠高性能的企业级容器应用管理服务，支持Kubernetes社区原生应用和工具，简化云上自动化容器运行环境搭建：Ø  简单易用：自动化创建容器集群，一站式部署/运维容器应用，一键式滚动升级；Ø  高性能：自研高性能容器网络，秒级自动弹性伸缩，支持高性能裸金属容器私有集群；Ø  企业级：集群控制面HA和跨AZ高可用，容器应用优雅伸缩，安全下线，保障业务不掉线；Ø  开放兼容：兼容Kubernetes/Docker社区原生版本，CNCF认证的Kubernetes服务提供商，社区的主要贡献者；下列从安装、运行管理和监控多维度对比自建Istio和华为云CCE上使用Istio的差别：自建华为云CCEIstio包管理用户自行下载和管理用户不感知运行配置用户自行配置运行环境和依赖用户不感知Istio安装用户自行探索和安装用户不需要关注具体细节，创建集群时按需启用。Sidecar注入用户自行探索和开发、配置用户不感知Istio升级用户自行探索、开发不影响业务的升级方案提供完整解决方案，按需进行控制面和数据面的升级操作应用调用链用户自行探索、开发和安装、配置对接华为云APM/AOM服务，提供请求调用链跟踪查看能力应用拓扑用户自行探索、开发和安装、配置对接华为云APM/AOM服务，提供查看应用拓扑能力性能监控用户自行探索、开发和安装、配置对接华为云APM/AOM服务，提供请求响应时延的实时性能状态监控云原生应用在CCE上的部署、管理实践云原生应用、云平台与微服务架构云原生应用，是指原生为在云平台上部署运行而设计开发的应用。公平的说，大多数传统的应用，不做任何改动，都是可以在云平台运行起来的，只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式，仅仅是把虚拟机当物理机一样使用，不能够真正利用起来云平台的能力。云计算平台的核心能力就是提供按需分配资源和弹性计算的能力，而云原生应用的设计理念就是让部署到云平台的应用能够利用云平台的能力实现按需使用计算资源和弹性伸缩。微服务架构是实现企业分布式系统的一种架构模式，即将一个复杂的单体应用按照业务的限定上下文，分解成多个独立部署的组件。这些独立部署的组件，就称为微服务。而在谈论云原生应用与微服务架构关系的时候，根据上下文不同可以从两个角度去看。1） 宏观的云原生应用，即将整个分布式系统看作一个应用，这个角度下，微服务架构是实现云原生应用的一种架构模式；2） 微观的云原生应用，即每个微服务是一个应用，这种语境下，每个微服务要按照云原生应用的设计理念去设计(如我们所熟知的云原生12要素），才能真正实现微服务架构所要达到的目的，即让分布式系统具备按需使用计算资源和弹性伸缩的能力。在华为云CCE容器服务中，我们将宏观的云原生应用，称之为“应用”，而将微观层面的云原生应用，称之为“组件“，用这两个概念来对分布式应用进行管理：图：应用、组件与工作负载的关系在CCE上进行云原生应用管理的实践创建Kubernetes集群            在创建应用前，需要准备好一个Kubernetes集群（1.9及以上版本），并启用Istio服务网格治理。登录CCE控制台，在左侧导航栏中单击“资源管理 > 虚拟机集群”，在“虚拟机集群”界面，单击“创建Kubernetes集群”，按照向导式逐步配置：图1：创建Kubernetes集群图2：使能服务网格，一键式安装Istio并自动使能应用sidecar注入：其他集群创建步骤、配置与已有CCE上创建虚拟机集群一致.创建云原生应用这里我们以Istio开源社区的bookinfo样例应用为例，其包含ProductPage、Reviews、Details、Ratings这4个微服务，拓扑结构以及网络访问信息如下：在CCE左侧导航栏中选择“应用管理”，单击“创建应用”，选择“向导式创建” （后续将支持通过helm模板一键式创建微服务应用以及其流量策略配置，更方便管理），分三大块配置：应用基本信息、网格内组件定义、对外放开路由配置。1、 首先定义应用的基本信息：名称、选择所在集群和namespace：2、 第二步，点击添加组件，按照上方的应用拓扑和网络设计，把组件加入到服务网格：A、添加ratings微服务组件（容器内监听端口为9080，开放至service mesh内部访问端口也配置为9080，后者可根据客户端配置自行调整）1）配置组件基本信息：2）选择负载镜像，并配置版本号为v13） 点击“下一步”，负载高级配置中可以选择配置升级策略、缩容策略、自定义监控等，我们这里不做配置，点击“添加“：可以看到我们为bookinfo添加了一个微服务组件进网格B、 添加reviews微服务组件参考上述添加ratings的步骤，添加reviews：C、 添加details微服务组件参考上述添加组件步骤，添加details微服务组件：D、                添加productpage微服务组件3、 最后，配置应用对外开放的访问路由，从上方拓扑设计可知，productpage作为访问入口：A、点击“添加应用访问方式“B、选择开放至外部访问的组件，并配置开放端口配置后的访问方式信息如下所示：最后点击右下角“创建”，启动应用，在应用列表中可以看到新建的分布式微服务应用bookinfo及其包含的微服务组件：通过应用开放的访问入口访问productpage：在CCE上使用Istio进行灰度发布的实践一键式在集群上启用Istio服务网格集群下应用如果需要做微服务治理，只需要在创建集群时点击启用服务网格即可，不需要自行进行Istio镜像下载、yaml配置、安装、升级等与应用业务无关的复杂基础设施构建工作：开发打包新版本下方我们以开发了一个新版本reviews微服务为例（初始容器镜像版本号为1.5.0），新版本镜像版本号为1.5.0-v2，并且已在本地开发机通过docker push上传至华为云容器镜像服务（SWR）：新版本在现在版本基础上增加对ratings微服务的调用，支持评分星星级别展示.发布灰度版本并配置灰度策略现在我们计划通过灰度发布的方式，平滑的在现网升级，在应用列表页面，展开bookinfo下的组件信息，选择reviews微服务组件的“添加灰度版本”：启动灰度版本：配置灰度版本号v2，确认好镜像版本（系统会默认选择最新版本的镜像），点击“启动负载”即可启动灰度版本，容器高级配置已默认继承已有版本观察灰度版本运行状态并配置灰度策略：按照比例分配灰度版本流量比例（这里以20%为例），观察负载启动成功后，点击“提交策略”：回到组件列表可以看到，review微服务已处于灰度发布状态：对review服务进行灰度发布前后的流量对比如下所示：初始版本：灰度状态：如图示，review v2版本调用ratings服务获取星级评价，并将20%流量分流至本版本上访问productpage，可以看到部分请求可以显示星级评价，部分请求仍然是老版本的显示效果（即没有评星这个新特性），并且出现的比例接近1:4.部分访问结果为原有的页面：部分访问结果为带有星级评价特性的页面：持续观测灰度版本运转状态，并进行流量切换接下来，我们会持续观测灰度版本的运行状态，在确认业务处理、性能满足要求后，我们可以选择逐步调大灰度版本的流量比例，而后进一步将流量全部导流至灰度版本上：Ø  观察健康与性能状态：点击CCE左侧导航栏“运维中心”进入AOM服务：选择“指标”->“应用”菜单，持续观察review服务灰度版本v2的健康状态与性能状态：Ø   观察调用链以及请求响应时延：在CCE应用管理中，点击bookinfo应用，查看详情，可以看到CCE服务提供了请求调用链跟踪能力，能够实现分布式异常请求的快速定位（当前提供开源zipkin和grafana能力，后续将对接至华为云AOM服务提供相应能力）可以看到V2版本运转正常，那么下一步我们将逐步扩大流量比，最后将流量全部导至灰度版本，在cce服务中，点击组件名称，进入组件详情页面，点击“接管所有流量”：系统提示会将接管原有版本的所有流量，点击“确定“按钮：现在所有访问reviews的流量都导向v2版本：访问productpage，所有的请求都会呈现星级评价特性：最后，我们将原有老版本（V1）从平台移除：点击确认后，可以看到该微服务只剩下v2版本在运转：通过Istioctl工具进行更多微服务流量治理在上述规则的基础上，cce Istio服务网格还提供了Istioctl命令行工具，实现更全面的流量治理能力，如限流、熔断、连接池管理、会话保持等。进入”资源管理“->“虚拟机集群“，点击所要管理的集群，可以看到Istio命令行的下载和使用指导：  总结华为云CCE容器引擎 + Istio + AOM/APM + SWR服务，提供了完整的云原生应用从开发、部署、上线、监控的完整生命周期管理全栈服务，让企业上云更简单，运行更高效。目前Istio服务网格能力已开放公测，可通过下方链接，快速申请公测，华为云容器服务的专家将全力为您服务，为您的成功保驾护航.申请链接：https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/Istio/meshList