百易传媒（DOIT）：2020行业云原生应用白皮书（59页）.pdf

《百易传媒（DOIT）：2020行业云原生应用白皮书（59页）.pdf》由会员分享，可在线阅读，更多相关《百易传媒（DOIT）：2020行业云原生应用白皮书（59页）.pdf（59页珍藏版）》请在三个皮匠报告上搜索。

1、 特此鸣谢参加本次白皮书的编纂的行业和企业专家。 谢长生 华中科技大学武汉光电研究中心教授 吴 非 华中科技大学光电国家研究中心研究员、博导 许 渊 Intel 数据中心产品架构师 吴 栋 浪潮集团云计算高级架构师 林小引 戴尔科技集团售前系统工程部解决方案架构师 张利俊 戴尔科技集团企业技术战略架构师 傅纯一 VMware 大中华区高级产品经理 郦 达 联想凌拓数据与云架构顾问 李 云（至简） 阿里云云原生高级技术专家 刘 尧 百度智能云云原生和区块链产品负责人 陈一苇 腾讯云云原生高级技术专家 彭德华 金山云云原生解决方案总经理 朱 琅 京东智联云 PaaS 产品负责人 吴 涛 华云数据标

2、准总监 李 鲁 网易云资深解决方案架构师 贺洪龙 灵雀云资深解决方案架构师 康 洋 博云解决方案架构师 梁 胜（西瓜哥） 高端存储知识 CHO 薛 浩 亚信科技平台产品研发与交付中心总监 Grace Shen 青藤云安全容器安全技术专家 苗远强 时速云解决方案架构师 庄怀轩 大连华信技术总监（ 原 Portworx 亚太区首席架构师） 周 磊 云徙科技 i-DP 产品总监 邵国健 XSKY 系统架构师 王鹏飞 焱融科技首席技术官 黄雨婷 才云科技智能容器云数字营销经理 俞仁杰 蚂蚁金服金融云产品专家 花 瑞 杉岩数据存储专家 于 爽 KubeSphere 容器平台产品经理 叶理灯 UCloud

3、 私有云及容器产品线负责人 侯亚辉 云途腾容器产品总监 宋家雨 百易传媒（DOIT）编辑部 谢世诚 百易传媒（DOIT）编辑部 朱朋博 百易传媒（DOIT）编辑部 崔欢欢 百易传媒（DOIT）编辑部 张妮娜 百易传媒（DOIT）编辑部 目录 一、 前言- 二、 云原生化是 “新基建” 和 “互联网+” 的技术表达- 2.1传统行业面临的挑战- 2.1.1传统行业/企业被互联网无情 “碾压” - 2.1.2MadeinInternet （新零售、 新制造、 新能源、 新技术、 新物流） - 2.2 云原生（CloudNative）实现 - 2.3云原生与企业竞争力塑造 - 2.4 云原生与企业管

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 应用微服务化拆分的一般原则 - 01 04 05 05

5、 05 06 06 07 09 10 10 10 11 14 15 16 16 17 17 17 18 19 19 四、 云原生应用对数据基础设施的影响- 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 安全

6、结论 - 六、 总结和展望- 21 22 22 23 24 24 25 25 27 28 28 28 29 29 30 31 32 七、 附录：容器云原生技术产品和服务- 博云- 戴尔科技集团 - 联想凌拓 - 英特尔 - KubeSphere开源容器平台- XSKY- 中兴通讯 - 34 35 37 43 46 47 49 50 有数据显示：2018 年我国云计算整体市场规模达 962.8 亿元，增速为 39.2%。预计未来几 年复合增速在 30% 左右，到 2022 年我国云计算整体市场规模接近 3000 亿元。 国外知名分析机构 Gartner 的数据显示：云计算渗透率将大幅提升，201

7、9 年云计算的市场 渗透率将首次突破 10%，达到 11.3%；到 2021 年全球云计算市场渗透率将达到 15.3%。 数据是冰冷的，会有分类和统计上差异，如云计算渗透率专指公有云吗？包括私有云在内 吗？尽管如此，并不影响我们对整体趋势的判断。 传统行业 / 企业应用需要迁移到云平台，过程不是一蹴而就的，而是遵循演进阶段的划分， 大致可以分为如下 4 个阶段： 既然如此，问题来了！ 如今，中国传统行业 / 企业业务云化已经发展到了哪个阶段？ 本白皮书观点表明，传统行业 / 企业云计算应用如今已经进入到了第三阶段的 PaaS 平台 阶段， 这里PaaS平台技术非常明确， 以平台为基础的云原生化

8、开发， 实现对传统应用逐步改造。 从技术上看，基于容器 + 新型 PaaS 平台具有敏捷部署、弹性伸缩、灵活调度的优点，结合、 DevOps 和微服务三驾马车，企业可以快速走上云原生转型之路。有数据显示，在美国，容器 化部署占到了生产应用部署的 48%，2020 年，超过 50% 的全球组织将在生产环境中运行容器 化应用程序，到 2022 年将超过 75%。在中国，截止到 2018 年底，已有 96% 的 IT 企业在生产 环境部署容器化应用。 阶段 1：虚拟化整合 +IaaS 阶段：这个阶段以 IaaS 基础设施虚拟化应用为主。 阶段 2：IaaS+ 简单 SaaS 应用阶段：在虚拟化资源基

9、础上，开始对外提交简单 SaaS 服务。在这个阶段，传统行业 / 企业用户部分业务部门，会脱离开 IT 部门的纳管， 尝试公有云服务，尝试局部业务的创新。 阶段 3：丰富 SaaS 应用 +PaaS 平台阶段：为了能够提供统一的 IT 服务，增强对于 IT 基础设施的把控能力，更多传统行业 / 企业通过构建私有云，对于 SaaS 服务进行集中 管理，开始构建符合行业企业发展需要的 PaaS 平台。 阶段 4：全面云化、自动化管理和服务的阶段。 02 白皮书也强调：构建平台是起点，不是目的，是手段、工具，但不是业务应用，用好容器 + 新型 PaaS 平台加快云原生化部署才是当务之急。与此同时，传

10、统行业 / 企业用户可以直接选 用云厂商提供的云原生服务，也可以通过 ISV 等合作伙伴继续沿用服务外包方式，依靠第三方 服务商的产品和技术力量，不必事事亲力亲为。 按照白皮书的判断，行业 / 企业传统应用向云上的迁移基本完成，解决了传统应用在云环 境下的使用问题，也能够享有 IaaS 基础设施的资源弹性和易部署的红利，但效果是有限的，与 类似“双十一”的互联网业务支撑系统存在明显差距。如果说，传统应用上云解决“能用”的 问题；云原生化改造要解决的就是“好用”的问题。 业界经常用“稳态”和“敏态”来概括行业 / 企业应用的特征，但这种概括是相对意义上的， 是暂时的，因为并不存在绝对意义上的“稳

11、态”，业务创新要打破的就是“稳态”，使其走向“敏 态”，走向云原生化应用。 毫不夸张地说，云原生化改造会成为传统行业 / 企业新的分水岭，将决定传统行业 / 企业 在未来市场上的“生”与 “死”，依靠政策壁垒，也许传统行业 / 企业还能够生存，但也仅仅 是生存，甚至“生不如死”，终究会被时代洪流所吞没。 传统行业 / 企业需要有足够的危机意识！ 03 2.1 传统行业面临的挑战 2.1.1 传统行业 / 企业被互联网无情“碾压” 2.1.2 Made in Internet（新零售、新制造、新能源、新技术、新物流） 传统行业 / 企业面临互联网企业无情碾压，这已经是铁一样的事实，也是传统行业

12、/ 企业 每个从业者的真实感受；新动能替代旧动能，“互联网 +”或者“+ 互联网”已是传统行业 / 企 业新课题。 遗憾的是，几年时间过去了，很多传统行业 / 企业仍然没有找到“互联网 +”的节奏。从 金融行业的 Open Banking，到电信运营商避免被“ 管道化”，从新能源、新制造到新零售， 传统行业 / 企业仍然在摸索。新基建部署也提出了新的需求。 传统行业/企业相比互联网企业的业务特点不同， 传统行业/企业注重ROI， 强调投入产出比。 相比互联网企业的特点是投入大， 风险大， 收益量化有不确定性。 但是从技术需求上， “互联网+” 实质是数字化转型的问题，是在 “数据 + 算法”

13、定义的世界中，以智能数据服务的流动，化解 复杂系统的不确定性，优化资源配置效率，构建企业新型竞争优势。 补足云原生应用上的短板，是传统行业 / 企业应对互联网冲击的首要课题。 新基建和“互联网 +”或者说“+ 互联网”从概念上并不难理解，就是利用先进的技术对 传统产业进行改造，方向就是所谓新零售、新制造、新能源、新技术、新物流，也就是“Made in Internet ”。 “Made in Internet”应该怎么实现呢？在“天猫”、“京东”、“淘宝”、“拼多多”上 开个网店，通过互联网接受订单，利用支付宝、微信支付等电子支持手段结算，这算不算“互 联网 +”呢？ 答案当然算，但不高级。

14、对于传统行业 / 企业来说，电商、网店就是一种新销售渠道，因其信息更加透明、物流配 送方便，导致销售占比不断提高，如今新旧渠道并存是一个基本现状。但传统行业 / 企业也应 该意识到无论是电商渠道， 还是传统分销渠道， 无形中都割裂了企业和最终消费者间的信息传递。 这种“互联网 +“仅仅触及了传统行业 / 企业销售这一个环节，更何况，传统渠道也在积 极探索电商新渠道，因此并不高级。“Made in Internet”要改变的是从研发、市场、制造、销 售到服务的全部环节。按照理想化的设计，“Made in Internet”并不需要电商渠道，全部业务 流程应该完全构建在互联网平台上，这才是真正的“

15、互联网 +”，云原生化应用是首要待解决 的问题。 05 06 2.2 云原生（Cloud Native）实现 2.3 云原生与企业竞争力塑造 互联网企业应用生来就是云原生化，相比传统行业 / 企业应按照 Client/Server 或者 Browser/Server 的模式构建，本质是一种集中式计算，没有办法支持高并发，也没有办法支持 快速迭代。 传统集中式系统，版本更新以年为单位计算，主要依赖传统 IT 产品供应商，二者之间是一 种 IT 服务外包方式。相比以分布式为特征的云原生应用，使用微服务化的架构，模块之间呈现 一种松耦合的模式。 其中， 局部修改并不引发全局， 让软件开发以 “迭代”

16、 方式呈现， 以此为依托， 创新业务以持续“试错”的方式，完成与消费和使用者的磨合。 在迭代模式下，消费者既是使用者，也是新需求和服务的贡献者，软件开发人员根据消费 者的需求不断修改，迭代式创新服务，而不是传统研发人员的单向驱动，这种新型消费伙伴关 系是传统模型无法比拟的。 以迭代为结果的微服务化云原生应用开发，将涉及研发体系和结构的变化，从单体结构走 向微服务化。容器是目前使用最为普遍的开发技术，Kubernetes 是最为普遍的容器编排和管理 平台，是笑到最后的技术，事实上的市场标准。目前容器可以部署在物理机，也可以部署在虚 拟机上。 与虚拟机相比，容器部署的数量更多，颗粒度更细。微服务化

17、、DevOps、容器带来了云原 生应用研发和管理新方法，让传统行业 / 企业能够更好与开源社区最新的软件技术进行结合， 支持业务创新和迭代。 业内流传着这样一句话：所有企业都是软件企业，实际上，间接回答了云原生与企业竞争 力关系的问题。 为什么都是软件企业？ 因硬件产品趋于工业标准化， 更能够体现企业差别的应该是软件的能力， 以互联网厂商为例， 他们就是通过充分使用开源技术，重新塑造了软件能力。 传统行业 / 企业多采用购买商业软件套件，采用 IT 服务外包的模式，传统模式的特点是初 始购买成本高， 软件版本更新迭代缓慢。 相比， 互联网企业初始购买成本低， 软件版本更新速度快， 几乎每天都有

18、软件更新，可以随时引入新技术，产品技术创新能力强。 07 未来，企业的核心竞争能力更多体现在软件能力上。 依据企业中企业应用的不同特征，有些专业分析机构和企业将其区分为“稳态”和“敏态”， 划分的主要依据是软件使用者数量的划分，“稳态”业务没有海量并发访问的需求，举例如 ERP，主要局限在生产线相关人员使用，这些业务以往是部署在小型机环境中，强调系统的可 靠性和稳定性；“敏态”业务，类似“双十一”这样的促销活动，预计会有波峰、波谷的剧烈 变动，要求系统具有足够的弹性、敏捷性和灵活性。有人习惯上将传统业务应用称为“稳态”， 而将互联网创新业务应用称为“敏态”。 这样的业务划分有一定的现实意义。

19、但是站在云原生业务应用的角度上，需要注意到所谓“稳态”和“敏态”只是一个相对的 概念， 并非是一成不变的。 以新制造为例， 与标准工业化、 流程化为特点的传统批量化制造相比， 新制造更加强调个性化， 从批量化被动的使用者， 要变成为个性化产品制造的创造者和参与者， 消费者需要参与到产品制造过程中。从技术的角度，意味着传统 ERP 的各个环节需要面向最终 消费者开放，消费者希望了解共享物料、设计、制造以及物流等各个环节信息。 在新制造的环境下，业务需求的变化，也将带来新的需求，对于系统来说意味着海量的并 发访问，从某种意义说，新制造就是要打破四平八稳“稳态”的格局，所谓不破不立。互联网 企业能够

20、走通的路，传统企业没有走不通的理由，这恐怕也是“互联网 +”希望传递的信息。 从单体结构到微服务化到业务应用创新，软件更新迭代快，一天 72 变，意味着没有办法一 次性购买终身免疫，云原生能力获得需要方方面面的改变。传统行业 / 企业以往所采用的 IT 服 务外包模式没有办法应对随时出现的调整和变化，没有办法更多从“开源”技术的世界中吸取 能量，为业务创新所使用。 从根本上说，云原生应用的本质不是产品 / 方案，而是一种管理开发体系的改变，是对行 业 / 企业研发体系的重构。 为了实现重构， 传统行业/企业可以像互联网一样， 公开招聘， 广纳人才， 以金融、 电信为例， 他们的研发队伍规模、实

21、力并不逊色于互联网厂商，但对于政府、能源、制造、医疗等行业而言， 其技术队伍的规模、实力比较薄弱，在“全民软件、全民研发”的大环境条件下，面对面真金 白银去抢人，对于传统行业 / 企业难度不小。 传统行业 / 企业可以继续沿用传统的 IT 服务外包的方式，但是应该探索新型合作伙伴关系， 以满足和适应云原生化转型和变化的需要。新型合作伙伴关系，需要新的服务和付费方式。对 2.4 云原生与企业管理 但是企业管理问题也是一个系统庞杂的问题， 类似 “一把手” 工程， 需要企业管理者运筹帷幄。 将云原生应用上升到企业管理的高度是恰当的，应该有这样一个全局高度的把握，然而过度强 调“一把手”工程也会束缚

22、云原生化应用推动的步伐。 目前，公有云、ICT 产品供应商、创新企业等都提供了很多云原生应用技术产品和服务， 可以帮助传统行业实现业务创新，从而让云原生化的问题变得没有那么复杂。 不要被企业管理束缚住手脚。这也是白皮书希望阐述的观点之一。 在中国，企业发展问题都可以归结为现代化企业管理，加之云原生应用牵涉企业应用开发 管理体系的重建，因而应该从企业管理的高度重新审视云原生应用和业务创新的问题。 于现有 IT 人员也提出了更高的要求，需要随时把握开源技术最新动向，并能够与业务创新加以 结合，需要协调合作伙伴技术力量，构建新的管理和付费方式。 08 10 云原生应用起源应该追溯到 2006 年谷歌

23、 cgroups 容器技术，也有观点认为这个概念是 Pivotal 公司的 Matt Stine 于 2013 年首次提出的，2013 年 Docker 正式发布让更多人看到了容 器， 类似于集装箱技术对运输业革命， 没有容器就没有云原生应用， 容器技术催化了云原生应用， 但是云原生并不等于容器（详情参见 3.2 容器和微服务化）。 容器应用自带环境， 可将一致容器化应用运行在各种环境中， 它便于调试、 开发、 部署、 运维、 迁移、 扩容， 从而造福程序员自己。 容器这些特性与云弹性能力相结合， 可最大化发挥云的效能， 发挥云的价值。 云原生的软件应用生于云上，迭代成长在云上，在云上工作，最

24、后也销毁在云上。为了高 效管理容器，2014 年，Kubernetes 项目开源。2015 年，谷歌和红帽牵头成立了 CNCF 基金会， 并将 Kubernetes 捐献给了 CNCF。Kubernetes 让容器技术生态迅速成型，云原生由此进入原 子弹爆炸的状态。 从以往单体应用到微服务架构应用，部署和管理应用的复杂性大大增加，在 2013 年 Docker 镜像出现以后，容器变成了黑盒子，使用者只会关心它能做什么，需要一个服务的时候， 启动一个或者若干容器即可。 容器可以提供很多不一样的服务，也可以提供很多一样的服务，也就是横向扩展，提供控 制系统的弹性伸缩。容器化解决了效率问题，如应用开

25、发、测试、部署、迭代等都发生了天翻 地覆的变化。以互联网企业为代表，开发人员普遍采用了容器化手段和开发方法。 3.1 云原生应用的技术内涵 3.1.1 容器化 传统行业 / 企业用户的数字化转型也应该采用容器化的技术，传统应用需要进行容器化改 造。容器技术有共享内核和独立内核两种技术，默认都是共享物理机内核，独立内核的比如 Kata Container。 3.1.2 容器化与虚拟化 容器化需要首先部署虚拟化吗？ 这个问题始终存在争论。有舆论认为，容器化替代虚拟化，容器化是虚拟化的大敌。 虚拟化早于容器化，以 VMware vSphere、微软 HyperV、开源 KVM 等软件为代表，传统 行

26、业 / 企业普遍采用虚拟化技术。虚拟化技术重点解决了 CPU 计算资源利用率不高的问题，通 过构建虚拟机，提高计算资源的利用效率。虚拟化技术是云计算技术的基础，这也是为什么云 计算初期被称为虚拟化的原因。 在 Intel 处理器支持下，CPU 芯片直接部署虚拟化，虚拟化虚拟物理设备，所谓虚拟机， 其上安装操作系统，部署应用。 11 3.1.3 微服务：单体化应用和微服务架构的变化 容器化和虚拟化在功能上存在一定程度重合，本意都是屏蔽 CPU 资源调度技术的复杂性和 差异性。 从目前的情况看，容器可以直接部署在物理主机上，也可以部署在虚拟机上，特别对于传 统行业 / 企业用户而言，虚拟化技术普遍

27、采用，因此需要同时管理容器和虚拟化，相互之间存 在交集，虽然虚拟化和容器本质上都是一种计算资源隔离技术，但在隔离程度上，虚拟化更高， 安全程度也更高。 云原生应用可以直接部署物理硬件的操作系统中，由于没有虚拟化的开销，更加具有成本 效率，它们凭借 Kubernetes 平台对集群中的容器进行管理，这也是有舆论认为容器化将取代 虚拟化的动议来源。 但是这种开销也并非绝对。以虚拟化为例，虚拟化内核与跟 Kubernetes 紧密结合在一起， 也就是说，在虚拟化就有对容器调度的 mini 资源嵌入。如此部署容器应用的时候，根本不用考 虑是部署在虚拟机上，还是部署在物理服务器上，根本不用关心底层的基础

28、设施。 有厂商数据显示：超过 80% 的容器部署是运行在虚拟机上，其余部署在物理服务器上，很 多用户希望物理服务器资源的调配管理能够通过容器编排软件实现。也有第三方的测试显示： 借助新的平台对虚拟机和 Kubernetes 进行管理，相比物理机裸机设备部署有 8% 的性能提升， 这主要得益于虚拟化对于物理资源的高效调配。很多企业已经基于虚拟化技术建立了整套的运 维管理流程，为容器应用建立一套基于物理服务器的运维流程是他们轻易不肯尝试的，这也是 他们继续选择在虚拟化技术平台上运行容器应用的原因。 微服务是相对于大型单体应用而言的。 传统的应用开发模式下，随着用户对应用陆陆续续提交新的需求，开发人

29、员需要在原来的 应用上不断添加新的功能，这就相当于在一个船上不断修修补补的过程，它的功能越多，也就 意味着下次改动需要注意的地方越多，一次改动可能会带来很大的影响。简单说，这是一种紧 密耦合的架构。 12 微服务架构与此前的垂直架构、SOA 架构的一脉相承。 通俗地说，微服务是将单体应用拆分为多个组件，如用户界面、消息队列、数据库访问等， 以电商交易为例，拆分为在线支付、订单生成、订单跟踪等多个微服务，其中，每个微服务也 可以进一步拆分，微服务之间通过接口进行调用，如此，就构建成了松耦合的架构。 微服务彼此独立，修改、更新、迭代不会牵涉到其他微服务的模块。 从开发效率来讲，传统单体应用开发模式

30、下，许多人共同面向一个大的应用，就像一群工 人围在一起组装一台汽车一样，工序之间相互影响，相互干扰，效率不高。 微服务化则把汽车生产变成了工业流水线，一个工人只负责其中一部分，每个工人只需要 熟悉自己负责的那部分就好，每一部分可被独立完成，独立部署和更新。 微服务之间通过 RESTful API 进行连接。由于微服务之间以及微服务与客户端之间的连接 要很快速，而且消耗要尽可能的低，REST API 就非常合适。 Service Mesh 也是如今谈论和使用最多的技术，Service Mesh 是用于处理服务间通信的基 础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。 Servic

31、e Mesh 与传统基础设施层不同之处在于，它形成了一个分布式的互联代理网络，以 sidecar 形式部署在服务两侧，服务对于代理无感知。 13 目 前 发 部 分 Service Mesh 只 是 开 源 项 目， 比 较 知 名 的 项 目 有：Linkerd、Istio 和 HashiCorp Consul 等。 Linkerd：2016 年发布，是这些项目中最早的。Linkerd 是从 Twitter 开发的 library 中 分离出来的。在这一领域另一位重量型选手Conduit，已经进入了 Linkerd 项目并构成了 Linkerd 2.0 的基础。 Envoy：由 Lyft 创

32、建，为了能够提供完整的 service mesh 功能，Envoy 占据“数据平面” 的部分，与其进行匹配。 Istio：由 Lyft、IBM 与谷歌联合开发，Istio 可以在不修改微服务源代码的情况下，轻松 为其加上如负载均衡、身份验证等功能，通过控制 Envoy 等代理服务来控制所有的流量。此外， Istio 提供容错、金丝雀部署、A/B 测试、监控等功能，并且支持自定义的组件和集成。 Rancher 2.3 Preview2 版本上开始支持 Istio，用户可以直接在 UI 界面中启动 Istio 并且可 以为每个命名空间注入自动 sidecar。Rancher 内置了一个支持 Kia

33、li 的仪表盘，简化 Istio 的 安装和配置。这一切让部署和管理 Istio 变得简单而快速。 HashiCorp Consul：与 Consul 1.2 一起推出了一项名为 Connect 的功能，为 HashiCorp 的分布式系统添加了服务加密和基于身份的授权，可用于服务发现和配置。 这里重点说说 Istio，它被视为 Service Mesh 最流行的实践，Istio 一些关键性功能包括： 帮助微服务之间建立连接， 帮助研发团队更好的管理与监控微服务， 并使得系统架构更加安全。 Istio 帮助微服务分层解耦，解耦后的 proxy 层能够更加专注于提供服务发现、负载均衡、 故障恢复

34、、服务度量、服务监控、A/B 测试、灰度发布、限流限速、访问控制等基础架构的能力。 使用微服务需要治理平台支撑， 经过微服务化拆分之后， 服务从本地调用变为远程方法调用， 各种不确定因素变多了，必须有微服务治理平台来应对，常见的有 Spring Cloud 、Apache Dubbo、Spring Cloud Alibaba、Apache Service Comb 等等，其中包括服务发现、服务订阅、 服务监控、服务追踪、服务日志等。 在选择微服务框架时需要有几个简单的考虑原则：工具栈丰富度（微服务技术栈的深度和 广度）、通用性（社区活跃程度、使用比例等）、开放性（与其他开源系统的兼容性和互操作

35、性） 和可移植性（业务代码无侵入或低侵入）等。 当一切就绪，平台上发布了成百上千个服务，每个服务或微服务相互连接成网状，如何让 这个网络有序、有逻辑便非常重要，一来便于修改和维护，二来保证稳定和性能。 如何让网络变得有序有逻辑呢？ 14 3.1.4 DevOps DevOps 是 Development（开发）和 Operations（运维）的组合词，DevOps 是一组过程、 方法与系统的统称，通过一系列自动化流程能使构建、测试、发布变得更加快捷、频繁和可靠， 可用于促进软件开发、技术运营和质量保障（QA）部门之间的沟通和协作，最终为软件产品和 服务的及时交付提供保障。 DevOps 领域最

36、明显可见的在工具层面，常用的工具包括：监控工具 Prometheus、 Zabbix、Nagios，性能分析 / APM 工具 Newrelic、Oneapm、Pinpoint、Zipkin，批量 + 自 动化运维工具 Puppet、Ansible、Chef、Saltstack，日志分析工具 Graylog、Nagios、Elastic Stack、LOGalyze、Fluentd，持续集成 / 发布工具 Jenkins, 中国自己的开源工具 Cyclone。 AWS 对 DevOps 的定义是：DevOps 集文化理念、实践和工具于一身。可以提高组织交付 应用程序和服务的能力。与使用传统软件

37、和基础设施管理流程相比，能够帮助组织更快地发展 治理平台首先梳理系统对外开放的服务化接口、服务分组以及动态路由等等，然后对拆散 的服务进行归类、界定，确定服务领域和服务边界，最后通过服务迁移、切换，对同一领域的 服务接口进行服务整合，提供统一的服务出口，实现服务编排。 领域驱动设计（Domain-Driven Design，DDD）是软件行业最新的方法，当拿到一个需求 的时候，DDD 强调应该首先考虑要解决什么问题，它的问题域是什么，而不是先考虑用哪种技 术去实现。这里出现了域的概念，域可以简单地理解为微服务化拆分后的又一个整合，域是同 类功能或者问题的一个集合。 从领域驱动设计的角度来看，

38、探讨需求首先应该从问题域出发， 探讨关于业务边界的事情， 梳理要实现哪些功能和需求。下一阶段拓展到工作边界，探讨如何分工协作，确定团队合作的 方式。最后，到达应用边界，即技术实现的解决问题领域。 微服务也是对大数据、AI、物联网的有效支撑。 开发运营平台收集处理数据，用包括数据库、数据仓库、数据湖的方式存储海量数据，采 用各种先进的大数据和人工智能 AI 技术对数据进行挖掘，从数据中心获取洞察力，为产品优化， 降本增效提供支撑。 大数据、AI、物联网等都需要各种不同的运算、存储以及网络传输能力，而基于 Kubernetes 提供容器微服务可以动态提供资源和平台支撑，微服务在可管理性上、成本、提

39、升 效率和质量上都有明显优势。另一方面业务架构的微服务化打破了数据孤岛，更方便获取业务 数据用于大数据分析。 15 和改进产品。这种速度使组织更好地服务其客户，并在市场上高效地参与竞争。 DevOps追求的是一种理想化的协作状态， 涉及开发、 测试、 产品、 项目管理、 运维人员等等， 在 DevOps 中，开发人员专注于业务应用的生命周期管理，运维人员专注于自动化环境资源的 维护，QA 人员专注于自动化业务运行环境的供给和质量跟踪保证。许多人认为，所有能在保持 质量的前提下提高交付效率的方法和方法论都属于 DevOps 的范畴。 无论国内还是国外，行业内还没有一个能广为接受的 DevOps 实践模型来作为参考， DevOps 本身有很高的实践性和灵活性的特点，在实践中，很多企业也确实从 DevOps 中获益 良多，但对于更多企业来说，没有成熟的参考模式做起来就会比较困难，这要求企业能提供试 错的空间，也就意味着会出现意料之外的成本。 一个比较容易接受的路径是，由实际的业务来驱动，当企业开发一些新兴业务的时候，就 以 DevOps 来进行，一味的对原有系统进行改造是得不偿失的。 那么如何构建业务流程梳理与度量体系完善 DevOps 呢？ 通过职责梳理。确定流程与职责的对应关系，在实践中，通过对照制度发现各个部