2020年行业云原生应用白皮书.pdf

一、前言-二、云原生化是“新基建”和“互联网+”的技术表达-2.1传统行业面临的挑战-2.1.1传统行业/企业被互联网无情“碾压”-2.1.2MadeinInternet（新零售、新制造、新能源、新技术、新物流）-2.2 云原生（CloudNative）实现-2.3云原生与企业竞争力塑造-2.4 云原生与企业管理-三、容器云原生技术基础（企业云原生转型的技术实施）-3.1云原生应用的技术内涵-3.1.1容器化-3.1.2容器化与虚拟化-3.1.3微服务：单体化应用和微服务架构的变化-3.1.4DevOps-3.1.5持续交付、频繁交付、快速交付、降低发布风险CI/CD-3.2容器和微服务化-3.3容器和 Kubernetes-3.4技术应用热点-3.5云原生应用有关思考-3.5.1 从 Web 访问接入开始更加稳妥吗？-3.5.2数据库原生化改造-3.5.3选SaaS服务，还是自建？-3.5.4 应用微服务化拆分的一般原则-0104050505060607091010101114151616171717181919四、云原生应用对数据基础设施的影响-4.1存储的变化-4.1.1容器数据持久化-4.1.2CSI 和容器存储-4.1.3容器存储可视化和管理-4.1.4 海量数据和容灾备份-4.1.5 存储趋势变化促进容器发展-4.2计算、网络的变化-五、云原生化应用安全的话题-5.1 安全风险与挑战-5.1.1镜像风险-5.1.2 镜像仓库风险-5.1.3Kubernetes安全风险-5.1.4容器风险-5.1.5 主机操作系统风险-5.2 安全结论-六、总结和展望-2122222324242525272828282929303132七、附录：容器云原生技术产品和服务-博云-戴尔科技集团-联想凌拓-英特尔-KubeSphere开源容器平台-XSKY-中兴通讯-3435374346474950有数据显示：2018 年我国云计算整体市场规模达 962.8 亿元，增速为 39.2%。预计未来几年复合增速在 30%左右，到 2022 年我国云计算整体市场规模接近 3000 亿元。国外知名分析机构 Gartner 的数据显示：云计算渗透率将大幅提升，2019 年云计算的市场渗透率将首次突破 10%，达到 11.3%；到 2021 年全球云计算市场渗透率将达到 15.3%。数据是冰冷的，会有分类和统计上差异，如云计算渗透率专指公有云吗？包括私有云在内吗？尽管如此，并不影响我们对整体趋势的判断。传统行业/企业应用需要迁移到云平台，过程不是一蹴而就的，而是遵循演进阶段的划分，大致可以分为如下 4 个阶段：既然如此，问题来了！如今，中国传统行业/企业业务云化已经发展到了哪个阶段？本白皮书观点表明，传统行业/企业云计算应用如今已经进入到了第三阶段的 PaaS 平台阶段，这里PaaS平台技术非常明确，以平台为基础的云原生化开发，实现对传统应用逐步改造。从技术上看，基于容器+新型 PaaS 平台具有敏捷部署、弹性伸缩、灵活调度的优点，结合、DevOps 和微服务三驾马车，企业可以快速走上云原生转型之路。有数据显示，在美国，容器化部署占到了生产应用部署的 48%，2020 年，超过 50%的全球组织将在生产环境中运行容器化应用程序，到 2022 年将超过 75%。在中国，截止到 2018 年底，已有 96%的 IT 企业在生产环境部署容器化应用。阶段 1：虚拟化整合+IaaS 阶段：这个阶段以 IaaS 基础设施虚拟化应用为主。阶段 2：IaaS+简单 SaaS 应用阶段：在虚拟化资源基础上，开始对外提交简单SaaS 服务。在这个阶段，传统行业/企业用户部分业务部门，会脱离开 IT 部门的纳管，尝试公有云服务，尝试局部业务的创新。阶段 3：丰富 SaaS 应用+PaaS 平台阶段：为了能够提供统一的 IT 服务，增强对于IT 基础设施的把控能力，更多传统行业/企业通过构建私有云，对于 SaaS 服务进行集中管理，开始构建符合行业企业发展需要的 PaaS 平台。阶段 4：全面云化、自动化管理和服务的阶段。02白皮书也强调：构建平台是起点，不是目的，是手段、工具，但不是业务应用，用好容器+新型 PaaS 平台加快云原生化部署才是当务之急。与此同时，传统行业/企业用户可以直接选用云厂商提供的云原生服务，也可以通过 ISV 等合作伙伴继续沿用服务外包方式，依靠第三方服务商的产品和技术力量，不必事事亲力亲为。按照白皮书的判断，行业/企业传统应用向云上的迁移基本完成，解决了传统应用在云环境下的使用问题，也能够享有 IaaS 基础设施的资源弹性和易部署的红利，但效果是有限的，与类似“双十一”的互联网业务支撑系统存在明显差距。如果说，传统应用上云解决“能用”的问题；云原生化改造要解决的就是“好用”的问题。业界经常用“稳态”和“敏态”来概括行业/企业应用的特征，但这种概括是相对意义上的，是暂时的，因为并不存在绝对意义上的“稳态”，业务创新要打破的就是“稳态”，使其走向“敏态”，走向云原生化应用。毫不夸张地说，云原生化改造会成为传统行业/企业新的分水岭，将决定传统行业/企业在未来市场上的“生”与“死”，依靠政策壁垒，也许传统行业/企业还能够生存，但也仅仅是生存，甚至“生不如死”，终究会被时代洪流所吞没。传统行业/企业需要有足够的危机意识！032.1 传统行业面临的挑战2.1.1 传统行业/企业被互联网无情“碾压”2.1.2 Made in Internet（新零售、新制造、新能源、新技术、新物流）传统行业/企业面临互联网企业无情碾压，这已经是铁一样的事实，也是传统行业/企业每个从业者的真实感受；新动能替代旧动能，“互联网+”或者“+互联网”已是传统行业/企业新课题。遗憾的是，几年时间过去了，很多传统行业/企业仍然没有找到“互联网+”的节奏。从金融行业的 Open Banking，到电信运营商避免被“管道化”，从新能源、新制造到新零售，传统行业/企业仍然在摸索。新基建部署也提出了新的需求。传统行业/企业相比互联网企业的业务特点不同，传统行业/企业注重ROI，强调投入产出比。相比互联网企业的特点是投入大，风险大，收益量化有不确定性。但是从技术需求上，“互联网+”实质是数字化转型的问题，是在“数据+算法”定义的世界中，以智能数据服务的流动，化解复杂系统的不确定性，优化资源配置效率，构建企业新型竞争优势。补足云原生应用上的短板，是传统行业/企业应对互联网冲击的首要课题。新基建和“互联网+”或者说“+互联网”从概念上并不难理解，就是利用先进的技术对传统产业进行改造，方向就是所谓新零售、新制造、新能源、新技术、新物流，也就是“Made in Internet”。“Made in Internet”应该怎么实现呢？在“天猫”、“京东”、“淘宝”、“拼多多”上开个网店，通过互联网接受订单，利用支付宝、微信支付等电子支持手段结算，这算不算“互联网+”呢？答案当然算，但不高级。对于传统行业/企业来说，电商、网店就是一种新销售渠道，因其信息更加透明、物流配送方便，导致销售占比不断提高，如今新旧渠道并存是一个基本现状。但传统行业/企业也应该意识到无论是电商渠道，还是传统分销渠道，无形中都割裂了企业和最终消费者间的信息传递。这种“互联网+“仅仅触及了传统行业/企业销售这一个环节，更何况，传统渠道也在积极探索电商新渠道，因此并不高级。“Made in Internet”要改变的是从研发、市场、制造、销售到服务的全部环节。按照理想化的设计，“Made in Internet”并不需要电商渠道，全部业务流程应该完全构建在互联网平台上，这才是真正的“互联网+”，云原生化应用是首要待解决的问题。05062.2 云原生（Cloud Native）实现2.3 云原生与企业竞争力塑造互联网企业应用生来就是云原生化，相比传统行业/企业应按照 Client/Server 或者Browser/Server 的模式构建，本质是一种集中式计算，没有办法支持高并发，也没有办法支持快速迭代。传统集中式系统，版本更新以年为单位计算，主要依赖传统 IT 产品供应商，二者之间是一种 IT 服务外包方式。相比以分布式为特征的云原生应用，使用微服务化的架构，模块之间呈现一种松耦合的模式。其中，局部修改并不引发全局，让软件开发以“迭代”方式呈现，以此为依托，创新业务以持续“试错”的方式，完成与消费和使用者的磨合。在迭代模式下，消费者既是使用者，也是新需求和服务的贡献者，软件开发人员根据消费者的需求不断修改，迭代式创新服务，而不是传统研发人员的单向驱动，这种新型消费伙伴关系是传统模型无法比拟的。以迭代为结果的微服务化云原生应用开发，将涉及研发体系和结构的变化，从单体结构走向微服务化。容器是目前使用最为普遍的开发技术，Kubernetes 是最为普遍的容器编排和管理平台，是笑到最后的技术，事实上的市场标准。目前容器可以部署在物理机，也可以部署在虚拟机上。与虚拟机相比，容器部署的数量更多，颗粒度更细。微服务化、DevOps、容器带来了云原生应用研发和管理新方法，让传统行业/企业能够更好与开源社区最新的软件技术进行结合，支持业务创新和迭代。业内流传着这样一句话：所有企业都是软件企业，实际上，间接回答了云原生与企业竞争力关系的问题。为什么都是软件企业？因硬件产品趋于工业标准化，更能够体现企业差别的应该是软件的能力，以互联网厂商为例，他们就是通过充分使用开源技术，重新塑造了软件能力。传统行业/企业多采用购买商业软件套件，采用 IT 服务外包的模式，传统模式的特点是初始购买成本高，软件版本更新迭代缓慢。相比，互联网企业初始购买成本低，软件版本更新速度快，几乎每天都有软件更新，可以随时引入新技术，产品技术创新能力强。07未来，企业的核心竞争能力更多体现在软件能力上。依据企业中企业应用的不同特征，有些专业分析机构和企业将其区分为“稳态”和“敏态”，划分的主要依据是软件使用者数量的划分，“稳态”业务没有海量并发访问的需求，举例如ERP，主要局限在生产线相关人员使用，这些业务以往是部署在小型机环境中，强调系统的可靠性和稳定性；“敏态”业务，类似“双十一”这样的促销活动，预计会有波峰、波谷的剧烈变动，要求系统具有足够的弹性、敏捷性和灵活性。有人习惯上将传统业务应用称为“稳态”，而将互联网创新业务应用称为“敏态”。这样的业务划分有一定的现实意义。但是站在云原生业务应用的角度上，需要注意到所谓“稳态”和“敏态”只是一个相对的概念，并非是一成不变的。以新制造为例，与标准工业化、流程化为特点的传统批量化制造相比，新制造更加强调个性化，从批量化被动的使用者，要变成为个性化产品制造的创造者和参与者，消费者需要参与到产品制造过程中。从技术的角度，意味着传统 ERP 的各个环节需要面向最终消费者开放，消费者希望了解共享物料、设计、制造以及物流等各个环节信息。在新制造的环境下，业务需求的变化，也将带来新的需求，对于系统来说意味着海量的并发访问，从某种意义说，新制造就是要打破四平八稳“稳态”的格局，所谓不破不立。互联网企业能够走通的路，传统企业没有走不通的理由，这恐怕也是“互联网+”希望传递的信息。从单体结构到微服务化到业务应用创新，软件更新迭代快，一天 72 变，意味着没有办法一次性购买终身免疫，云原生能力获得需要方方面面的改变。传统行业/企业以往所采用的 IT 服务外包模式没有办法应对随时出现的调整和变化，没有办法更多从“开源”技术的世界中吸取能量，为业务创新所使用。从根本上说，云原生应用的本质不是产品/方案，而是一种管理开发体系的改变，是对行业/企业研发体系的重构。为了实现重构，传统行业/企业可以像互联网一样，公开招聘，广纳人才，以金融、电信为例，他们的研发队伍规模、实力并不逊色于互联网厂商，但对于政府、能源、制造、医疗等行业而言，其技术队伍的规模、实力比较薄弱，在“全民软件、全民研发”的大环境条件下，面对面真金白银去抢人，对于传统行业/企业难度不小。传统行业/企业可以继续沿用传统的 IT 服务外包的方式，但是应该探索新型合作伙伴关系，以满足和适应云原生化转型和变化的需要。新型合作伙伴关系，需要新的服务和付费方式。对2.4 云原生与企业管理但是企业管理问题也是一个系统庞杂的问题，类似“一把手”工程，需要企业管理者运筹帷幄。将云原生应用上升到企业管理的高度是恰当的，应该有这样一个全局高度的把握，然而过度强调“一把手”工程也会束缚云原生化应用推动的步伐。目前，公有云、ICT 产品供应商、创新企业等都提供了很多云原生应用技术产品和服务，可以帮助传统行业实现业务创新，从而让云原生化的问题变得没有那么复杂。不要被企业管理束缚住手脚。这也是白皮书希望阐述的观点之一。在中国，企业发展问题都可以归结为现代化企业管理，加之云原生应用牵涉企业应用开发管理体系的重建，因而应该从企业管理的高度重新审视云原生应用和业务创新的问题。于现有 IT 人员也提出了更高的要求，需要随时把握开源技术最新动向，并能够与业务创新加以结合，需要协调合作伙伴技术力量，构建新的管理和付费方式。08 10云原生应用起源应该追溯到 2006 年谷歌 cgroups 容器技术，也有观点认为这个概念是 Pivotal 公司的 Matt Stine 于 2013 年首次提出的，2013 年 Docker 正式发布让更多人看到了容器，类似于集装箱技术对运输业革命，没有容器就没有云原生应用，容器技术催化了云原生应用，但是云原生并不等于容器（详情参见 3.2 容器和微服务化）。容器应用自带环境，可将一致容器化应用运行在各种环境中，它便于调试、开发、部署、运维、迁移、扩容，从而造福程序员自己。容器这些特性与云弹性能力相结合，可最大化发挥云的效能，发挥云的价值。云原生的软件应用生于云上，迭代成长在云上，在云上工作，最后也销毁在云上。为了高效管理容器，2014 年，Kubernetes 项目开源。2015 年，谷歌和红帽牵头成立了 CNCF 基金会，并将 Kubernetes 捐献给了 CNCF。Kubernetes 让容器技术生态迅速成型，云原生由此进入原子弹爆炸的状态。从以往单体应用到微服务架构应用，部署和管理应用的复杂性大大增加，在 2013 年Docker 镜像出现以后，容器变成了黑盒子，使用者只会关心它能做什么，需要一个服务的时候，启动一个或者若干容器即可。容器可以提供很多不一样的服务，也可以提供很多一样的服务，也就是横向扩展，提供控制系统的弹性伸缩。容器化解决了效率问题，如应用开发、测试、部署、迭代等都发生了天翻地覆的变化。以互联网企业为代表，开发人员普遍采用了容器化手段和开发方法。3.1 云原生应用的技术内涵3.1.1 容器化传统行业/企业用户的数字化转型也应该采用容器化的技术，传统应用需要进行容器化改造。容器技术有共享内核和独立内核两种技术，默认都是共享物理机内核，独立内核的比如Kata Container。3.1.2 容器化与虚拟化容器化需要首先部署虚拟化吗？这个问题始终存在争论。有舆论认为，容器化替代虚拟化，容器化是虚拟化的大敌。虚拟化早于容器化，以 VMware vSphere、微软 HyperV、开源 KVM 等软件为代表，传统行业/企业普遍采用虚拟化技术。虚拟化技术重点解决了 CPU 计算资源利用率不高的问题，通过构建虚拟机，提高计算资源的利用效率。虚拟化技术是云计算技术的基础，这也是为什么云计算初期被称为虚拟化的原因。在 Intel 处理器支持下，CPU 芯片直接部署虚拟化，虚拟化虚拟物理设备，所谓虚拟机，其上安装操作系统，部署应用。113.1.3 微服务：单体化应用和微服务架构的变化容器化和虚拟化在功能上存在一定程度重合，本意都是屏蔽 CPU 资源调度技术的复杂性和差异性。从目前的情况看，容器可以直接部署在物理主机上，也可以部署在虚拟机上，特别对于传统行业/企业用户而言，虚拟化技术普遍采用，因此需要同时管理容器和虚拟化，相互之间存在交集，虽然虚拟化和容器本质上都是一种计算资源隔离技术，但在隔离程度上，虚拟化更高，安全程度也更高。云原生应用可以直接部署物理硬件的操作系统中，由于没有虚拟化的开销，更加具有成本效率，它们凭借 Kubernetes 平台对集群中的容器进行管理，这也是有舆论认为容器化将取代虚拟化的动议来源。但是这种开销也并非绝对。以虚拟化为例，虚拟化内核与跟 Kubernetes 紧密结合在一起，也就是说，在虚拟化就有对容器调度的 mini 资源嵌入。如此部署容器应用的时候，根本不用考虑是部署在虚拟机上，还是部署在物理服务器上，根本不用关心底层的基础设施。有厂商数据显示：超过 80%的容器部署是运行在虚拟机上，其余部署在物理服务器上，很多用户希望物理服务器资源的调配管理能够通过容器编排软件实现。也有第三方的测试显示：借助新的平台对虚拟机和 Kubernetes 进行管理，相比物理机裸机设备部署有 8%的性能提升，这主要得益于虚拟化对于物理资源的高效调配。很多企业已经基于虚拟化技术建立了整套的运维管理流程，为容器应用建立一套基于物理服务器的运维流程是他们轻易不肯尝试的，这也是他们继续选择在虚拟化技术平台上运行容器应用的原因。微服务是相对于大型单体应用而言的。传统的应用开发模式下，随着用户对应用陆陆续续提交新的需求，开发人员需要在原来的应用上不断添加新的功能，这就相当于在一个船上不断修修补补的过程，它的功能越多，也就意味着下次改动需要注意的地方越多，一次改动可能会带来很大的影响。简单说，这是一种紧密耦合的架构。12微服务架构与此前的垂直架构、SOA 架构的一脉相承。通俗地说，微服务是将单体应用拆分为多个组件，如用户界面、消息队列、数据库访问等，以电商交易为例，拆分为在线支付、订单生成、订单跟踪等多个微服务，其中，每个微服务也可以进一步拆分，微服务之间通过接口进行调用，如此，就构建成了松耦合的架构。微服务彼此独立，修改、更新、迭代不会牵涉到其他微服务的模块。从开发效率来讲，传统单体应用开发模式下，许多人共同面向一个大的应用，就像一群工人围在一起组装一台汽车一样，工序之间相互影响，相互干扰，效率不高。微服务化则把汽车生产变成了工业流水线，一个工人只负责其中一部分，每个工人只需要熟悉自己负责的那部分就好，每一部分可被独立完成，独立部署和更新。微服务之间通过 RESTful API 进行连接。由于微服务之间以及微服务与客户端之间的连接要很快速，而且消耗要尽可能的低，REST API 就非常合适。Service Mesh 也是如今谈论和使用最多的技术，Service Mesh 是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。Service Mesh 与传统基础设施层不同之处在于，它形成了一个分布式的互联代理网络，以sidecar 形式部署在服务两侧，服务对于代理无感知。13目 前 发 部 分 Service Mesh 只 是 开 源 项 目，比 较 知 名 的 项 目 有：Linkerd、Istio和 HashiCorp Consul 等。Linkerd：2016 年发布，是这些项目中最早的。Linkerd 是从 Twitter 开发的 library 中分离出来的。在这一领域另一位重量型选手Conduit，已经进入了 Linkerd 项目并构成了Linkerd 2.0 的基础。Envoy：由 Lyft 创建，为了能够提供完整的 service mesh 功能，Envoy 占据“数据平面”的部分，与其进行匹配。Istio：由 Lyft、IBM 与谷歌联合开发，Istio 可以在不修改微服务源代码的情况下，轻松为其加上如负载均衡、身份验证等功能，通过控制 Envoy 等代理服务来控制所有的流量。此外，Istio 提供容错、金丝雀部署、A/B 测试、监控等功能，并且支持自定义的组件和集成。Rancher 2.3 Preview2 版本上开始支持 Istio，用户可以直接在 UI 界面中启动 Istio 并且可以为每个命名空间注入自动 sidecar。Rancher 内置了一个支持 Kiali 的仪表盘，简化 Istio 的安装和配置。这一切让部署和管理 Istio 变得简单而快速。HashiCorp Consul：与 Consul 1.2 一起推出了一项名为 Connect 的功能，为 HashiCorp的分布式系统添加了服务加密和基于身份的授权，可用于服务发现和配置。这里重点说说 Istio，它被视为 Service Mesh 最流行的实践，Istio 一些关键性功能包括：帮助微服务之间建立连接，帮助研发团队更好的管理与监控微服务，并使得系统架构更加安全。Istio 帮助微服务分层解耦，解耦后的 proxy 层能够更加专注于提供服务发现、负载均衡、故障恢复、服务度量、服务监控、A/B 测试、灰度发布、限流限速、访问控制等基础架构的能力。使用微服务需要治理平台支撑，经过微服务化拆分之后，服务从本地调用变为远程方法调用，各种不确定因素变多了，必须有微服务治理平台来应对，常见的有 Spring Cloud、Apache Dubbo、Spring Cloud Alibaba、Apache Service Comb 等等，其中包括服务发现、服务订阅、服务监控、服务追踪、服务日志等。在选择微服务框架时需要有几个简单的考虑原则：工具栈丰富度（微服务技术栈的深度和广度）、通用性（社区活跃程度、使用比例等）、开放性（与其他开源系统的兼容性和互操作性）和可移植性（业务代码无侵入或低侵入）等。当一切就绪，平台上发布了成百上千个服务，每个服务或微服务相互连接成网状，如何让这个网络有序、有逻辑便非常重要，一来便于修改和维护，二来保证稳定和性能。如何让网络变得有序有逻辑呢？143.1.4 DevOps DevOps 是 Development（开发）和 Operations（运维）的组合词，DevOps 是一组过程、方法与系统的统称，通过一系列自动化流程能使构建、测试、发布变得更加快捷、频繁和可靠，可用于促进软件开发、技术运营和质量保障（QA）部门之间的沟通和协作，最终为软件产品和服务的及时交付提供保障。DevOps 领域最明显可见的在工具层面，常用的工具包括：监控工具 Prometheus、Zabbix、Nagios，性能分析/APM 工具 Newrelic、Oneapm、Pinpoint、Zipkin，批量+自动化运维工具 Puppet、Ansible、Chef、Saltstack，日志分析工具 Graylog、Nagios、Elastic Stack、LOGalyze、Fluentd，持续集成/发布工具 Jenkins,中国自己的开源工具 Cyclone。AWS 对 DevOps 的定义是：DevOps 集文化理念、实践和工具于一身。可以提高组织交付应用程序和服务的能力。与使用传统软件和基础设施管理流程相比，能够帮助组织更快地发展治理平台首先梳理系统对外开放的服务化接口、服务分组以及动态路由等等，然后对拆散的服务进行归类、界定，确定服务领域和服务边界，最后通过服务迁移、切换，对同一领域的服务接口进行服务整合，提供统一的服务出口，实现服务编排。领域驱动设计（Domain-Driven Design，DDD）是软件行业最新的方法，当拿到一个需求的时候，DDD 强调应该首先考虑要解决什么问题，它的问题域是什么，而不是先考虑用哪种技术去实现。这里出现了域的概念，域可以简单地理解为微服务化拆分后的又一个整合，域是同类功能或者问题的一个集合。从领域驱动设计的角度来看，探讨需求首先应该从问题域出发，探讨关于业务边界的事情，梳理要实现哪些功能和需求。下一阶段拓展到工作边界，探讨如何分工协作，确定团队合作的方式。最后，到达应用边界，即技术实现的解决问题领域。微服务也是对大数据、AI、物联网的有效支撑。开发运营平台收集处理数据，用包括数据库、数据仓库、数据湖的方式存储海量数据，采用各种先进的大数据和人工智能 AI 技术对数据进行挖掘，从数据中心获取洞察力，为产品优化，降本增效提供支撑。大数据、AI、物联网等都需要各种不同的运算、存储以及网络传输能力，而基于Kubernetes 提供容器微服务可以动态提供资源和平台支撑，微服务在可管理性上、成本、提升效率和质量上都有明显优势。另一方面业务架构的微服务化打破了数据孤岛，更方便获取业务数据用于大数据分析。15和改进产品。这种速度使组织更好地服务其客户，并在市场上高效地参与竞争。DevOps追求的是一种理想化的协作状态，涉及开发、测试、产品、项目管理、运维人员等等，在 DevOps 中，开发人员专注于业务应用的生命周期管理，运维人员专注于自动化环境资源的维护，QA 人员专注于自动化业务运行环境的供给和质量跟踪保证。许多人认为，所有能在保持质量的前提下提高交付效率的方法和方法论都属于 DevOps 的范畴。无论国内还是国外，行业内还没有一个能广为接受的 DevOps 实践模型来作为参考，DevOps 本身有很高的实践性和灵活性的特点，在实践中，很多企业也确实从 DevOps 中获益良多，但对于更多企业来说，没有成熟的参考模式做起来就会比较困难，这要求企业能提供试错的空间，也就意味着会出现意料之外的成本。一个比较容易接受的路径是，由实际的业务来驱动，当企业开发一些新兴业务的时候，就以 DevOps 来进行，一味的对原有系统进行改造是得不偿失的。那么如何构建业务流程梳理与度量体系完善 DevOps 呢？通过职责梳理。确定流程与职责的对应关系，在实践中，通过对照制度发现各个部门在职责方面的问题，做出弥补和修正。通过流程诊断实现流程优化。依据制度对流程进行审核，发现流程与制度之间的不一致后，要识别改进或优化。流程的跨部门审核、各种管理制度审查完善，结合控制要求进行流程诊断，3.1.5 持续交付、频繁交付、快速交付、降低发布风险 CI/CDDevOps 度量体系可以帮助负责人了解团队的生产力，可以帮助了解目前应用的状况，可以回答三天后能否上线的问题，而不是“大概”“可能”这类回答，帮助团队认清并提升团队的生产力。度量体系中的引领性指标定义了一些达成目标关系最为重要的行动，在可以驱动的指标事情上倾斜资源，为实现滞后性指标提供支撑。引领性指标关注目标如何完成，而滞后性指标关注目标是否完成，滞后性指标的数据比较容易获得。根据诊断结果完成流程优化工作。流程优化工作，要在整个架构的框架下审视流程，既要保证流程完整顺畅又要关注流程之间工作步骤的衔接关系。CI 的英文名称是 Continuous Integration（持续集成）。CI 中，开发人员将会频繁地向分支提交代码，提交的代码在经过编译和自动化测试后，最终合并到主干。持续集成的目标是快速确保提交的修改是不是好的，确定新代码能不能和原有代码集成起来。CD 可 以 是 指 持 续 交 付 Continuous Delivery，也 可 以 是 在 说 持 续 部 署 Continuous Deployment。16因为容器作为基础设施为微服务提供了很大便利，我们知道微服务是应用软件架构设计模式，推崇单一职责、服务自治、轻量通信和接口明确等原则，而容器由于其 Build Once，Run Everywhere 的特性，使得微服务易于开发和维护、按需伸缩等。其次，Kubernetes 的编排调度能力，使得管理为数众多的微服务不再痛苦，特别是 CRD的引入，让 Kubernetes 具备了理解和管理各种类型的业务架构的能力。如今越来越多的技术开发人员都通过容器打包应用，使用 Kubernetes 平台部署和管理微服务。如果说微服务化是目标，那容器和 Kubernetes 则是实现这一目标的手段和方法，这样的说法未必严谨，但确实是当下的现实。Kubernetes 是什么？Kubernetes 是一个跨主机集群的、开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作，提供以容器为中心的基础架构。简而言之，Kubernetes 具有强大的容器编排能力，如果没有 Kubernetes，容器面对大规模容器时完全无能为力。3.3 容器和 Kubernetes持续交付：持续交付负责将 CI 之后的代码发布到存储库，持续交付维护了一个可随时部署到生产环境的代码库，可供终端用户使用。持续部署是将持续交付的代码自动发布到生产环境。持续交付表示的是一种能力，而持续部署表示的则一种方式。持续部署是持续交付的最高阶段，上文提到，所有能在保持质量的前提下提高交付效率的方法和方法论都属于 DevOps 的范畴，所以，CI/CD 是 DevOps 的必不可少的部分。在实践中，Jenkins 是最为常见的 CI/CD 工具。微服务对系统的扰动很小，每次改动也很小，如果做一个比喻的话，单体应用就好比射箭，需要远距离瞄准发射，开弓没有回头箭，射出去的箭很难再调整方位，而微服务则像近身肉搏，拳脚都可以快速出击，而且可以随时调整出拳的方位和力道。同样的，应用代码通过持续频繁快速的交付，可以降低发布的风险。了解了微服务化，也了解了容器，微服务化和容器之间是什么关系呢？可以说，微服务与容器没有直接关系，没有容器其实也可以有微服务。那么，为什么人们将微服务和容器化放在一起谈呢？3.2 容器和微服务化17Kubernetes 是谷歌在 2014 年开源的，2017 年，Kubernetes 战胜 Docker Swarm 和 Apache Mesos，成为容器管理与调度编排领域的首选平台和事实标准，Kubernetes 被称为云计算时代的 Linux 操作系统，是全球顶级开源项目。Kubernetes 无论是技术还是生态都获得了各方支持，几乎所有的公有云服务商都提供了Kubernetes 方案，允许在云上快速构建 Kubernetes 集群，进行各种配置和管理。所有的私有云以及混合云提供商也都在以各种方式对容器应用提供支撑，容器化的趋势是真正的大势所趋。TensorFlow、Jenkins、ElasticSearch、WordPress、Spark、MySQL 等这些经常见诸报端的词汇，也是互联企业经常使用的技术，它们也让云原生世界更加富于技术的色彩，让世界变得精彩。对于行业企业来说，什么时候会使用到这些技术呢？最好的办法就是了解这些的概念和内涵，根据需要加以选择和使用。TensorFlow：是一个采用数据流图(data flow graphs)，用于数值计算的开源软件库，简单点说，就是一个机器学习框架，可以用它来训练模型并推理模型。类似的，国内有百度paddlepaddle。TensorFlow 有个针对 Kubernetes 和云原生的对标开源项目 Kubeflow。3.4 技术应用热点Jenkins：是一款开源 CI&CD 软件，用于自动化各种任务，包括构建、测试和部署软件。Jenkins 是使用的最为普遍的软件之一。ElasticSearch：是一种流行的企业级搜索引擎，基于 Lucene，它提供了一个分布式多租户能力的全文搜索引擎，具有搜索、分析和探索的能力，可以用于搜索各种文档。Spark：Apache Spark 是为大规模数据处理而设计的快速通用的计算引擎。Spark 拥有Hadoop MapReduce 的优点，但有所不同，与 Hadoop 相比，在某些工作负载方面表现得更加优越，算是对 Hadoop 的补充。MySQL：MySQL 是非常著名的开源关系型数据库管理系统，是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL 是最好的关系数据库管理系统应用软件之一。WordPress：是一个开源的内容管理系统（CMS），可以用来搭建个人博客或者新闻网站，安装简单易用，WordPress 有丰富的插件和模版，有强大的生态支持和用户群体。3.5 云原生应用有关思考3.5.1 从 Web 访问接入开始更加稳妥吗？从谨慎的角度出发，传统行业用户习惯从边缘业务入手，采取农村包围城市的策略。这样的方法有助于熟悉技术、锻炼队伍，也是很多用户乐于采用的。在云原生应用问题上是否应该也采取类似的策略呢？类似于公有云应用中出现过的现象：有些业务部门会绕开 IT 部门采购公有云服务，特别一些创新业务，很容易上手，有立竿见影的作用。但是对于 IT 部门来说，这些应用脱离了监管，给行业合规管理带来了风险。对于云原生应用来说，如果从访问端开始入手，着重解决并发访问的问题，对于改善用户体验会有一定的帮助，同时也可以锻炼队伍，但是缺点也是显而易见的，核心访问数据库仍然是瓶颈，没有从根本上解决问题。从接入端入手，给人的感觉是头痛医头，脚痛医脚，没有从战略高度，统筹规划业务进程。前面说过，云原生业务改造和创新，并不仅仅是引入新技术方案，而是涉及到研发体系到企业管理，以及业务创新管理的大问题，对此，需要从战略高度审视问题。针对高并发访问，传统数据库也提供了分库、分表等解决方案，有数据显示，Oracle 18c数据库的极致性能每秒可以支持523202笔交易，这几乎就是“双11”的峰值交易量。换句话说，18c 也可以支持“双 11”交易的需要。18c 自治数据库也采用了松耦合的模式，由数据层面和3.5.2 数据库原生化改造 管理层面构成，用于应对以往紧耦合带来的问题。如今也有很多用户开始尝试开源数据库。对于用户来说，历来视数据库为核心业务，更加强调稳态业务应用，牵一发动全身，用户通常不愿涉险。从互联网厂商的实践来看，通过并行化、分布式部署，实现了对“双 11”规模交易的处理，取得了云原生化改造的成功。除了MySQL等各种开源数据库之外，华为、金山云、青云、蚂蚁金服、AWS 等也推出了新的数据库产品，支持海量并发访问的需要。技术上，分布式数据库存在 CAP 定理又称 CAP 原则，指的是在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），最多只能同时具备三个特性中的两个，三者不可兼得。由于 CAP 原则存在，仅从技术角度解决问题是不可行的，还需要从业务角度进行拆分，以银行的转账交易为例，就可以将集中模式下的“同一数据库本地事务”拆分为分布式模式下的分库模式，将扣款、收款不用数据库来完成，如此就会带来扣款/收款数据不一致的风险，对此，可以借助冲正和对账等业务手段解决问题。1819此外，