从零开始了解云原生架构

大家好，我是欧二强，得到架构师，目前主要负责得到后端的架构和中间件服务。

很高兴可以站在这里与大家一起交流Cloud Native方面的知识，也感谢大家可以到来。

从幻灯片上可以看到今天的主题是"Cloud Native 的演进（—）--从零开始了解云原生架构"，这个Cloud Native系列的第一期，后面还会有第二期：Cloud Native 的演进（二）--得到在微服务与多IDC的实践。

现在我们来看一下大纲。主要分为三部分进行分享：

• Cloud-Native的演化
• Cloud-Native的组成
• Cloud-Native的未来

给出这个图是为了让更多第一次接触Cloud Native概念的同学后续学习的时候有一个知识网络。

第一部分：Cloud-Native的演化

我们进入第一部分：Cloud-Native的演化

Cloud-Native的演化历程

大家看到的这图走势图是Cloud Native这个词在Google的走势，可以看到从15年后它的热度不断攀升。也就是说关注它的人越来越多了。那我们就来看看Cloud Native如何从零到热门起来的。请出三位大神。

这位会吹箫的男人就是保罗了，2010年5月份在他的博客上提出Cloud-Native，因为保罗想了很久才想出这个词来描述他想表达的一种架构理念：

• 弹性：就是可伸可缩
• 多租户：用户隔离
• 自服务：这个需要说明一下，顾名思义就是用户自己服务自己。也就是说基础平台为用户提供了统一的操作平台，让用户可以自己操作服务满足自己的业务需求。
• *按需计量和计费：这个基本上都理解了，和家里用水电一样的，用多少给多少钱。
• 增量部署和灰度测试：支持各种的部署模式，比如蓝绿部署，金丝雀，滚动部署等。

这个会吹箫的男人保罗给了自己一个很牛逼的头衔：云原生计算概念之父。

现在到第二个男人出场了，这就是Netflix的钱架构师艾德里安，前面的保罗提出了Cloud Native理念，艾德里安实践了这个理念把netflix部署到了AWS上。为了实现这个目标艾德里安设定了4个目标：

• 可扩展性：代表着就是可伸可缩也就是前面说的弹性，也隐意着可以支持高并发；
• 高可用性：代表着稳定；
• 敏捷：代表着支持产品快速迭代，支持产品变更需求；
• 效率：分为两方面来看一个是研发效率，一个是应用耗时；

为了实现上面的4个目标艾德里安还定了5个架构原则：

• 不变性是指一旦创建了就不可更改，需要更改时候就删除重建；
• 关注点分离是领域驱动的设计方式，限定上下文，避免出现决策的瓶颈，每一个团队都可以对自身的服务做出决策；
• 反脆弱性是说失败不可避免，那么如何在设计时考虑处理这些失败。
• 高信任的组织和之前说的关注点分离有关联，是说相信每一个团队都可以做出正确的决策；
• 共享是说技术共享，文档共享，工具共享。

目标有了，原则也定下了，那么就差怎么做了，艾德里安又给出了8个措施：

• 公共云——可伸缩性、敏捷性、共享
• 微服务——关注点分离
• 非规范化数据——关注点分离
• 混沌引擎-抗脆弱的操作
• 默认开源——敏捷性，共享
• 持续部署——敏捷性，不变性
• devops ——高度信任的组织，共享
• 利用自己写的代码实现反脆弱性开发

Cloud-native的概念的提出者有了，实践落地者也有了，那么还差一个总结者，第三位男人马特出场了。Pivotal的CTO兼首席架构师Matt Stine写了一本书《Migrating to Cloud-Native Application Architectures》，这本书是免费的电子书，全书有58页左右，主要在阐述的一个中心——在单体应用向Cloud Native迁移中，需要组织架构、技术和团队文化共同变革。围绕着一下这几个内容：

• 十二因子
• 微服务
• 自服务敏捷基础设施
• 基于API的协作
• 反脆弱性

2017年10月在InfoQ采访是马特重新定义了Cloud Native architectures定义为具有六个特性：

• 模块化
• 可观测性
• 可部署性
• 可测试性
• 可处理性
• 可替换性

Cloud-Native兴起的原由

随着这三个男人的出场，我们也看到了Cloud Native的演进过程，但是我们还是没有看到为什么我们需要Cloud Native？

如果大家看过这一期分享的海报介绍的话，里面有一句话：从单体架构到云原生架构所带来的一系统技术变革，都是为了平衡业务快速变更产生的不确定性。

现在在幻灯片上看到的：

• 更快的上线速度
• 细致的故障探测和发现
• 故障时能自动隔离
• 故障时能够自动恢复
• 方便的水平扩容

这些说法大家看的时候觉得不是常规说法吗？要快，要安全，要性能好，还要省钱，也要敏捷！！！

那我们深入分析一下，快与可用性就是矛盾，多样性与安全就是矛盾；分布式与一致性又是矛盾；Cloud Native的兴起就是中和这些矛盾，达到一个平衡点。

Cloud-Native的定义

我们现在来到了Cloud Native的定义，目前为止也没有一个特别权威全面的定义，而且Cloud Native的定义还在变化中，下面我们先来了解一个。

16年的论文《Understanding cloud-native applications after 10 years of cloud computing 》给出的定义是

A  cloud-native  application  (CNA)  is  a  distributed,  elastic  and horizontal scalable system composed of (micro)services which isolates state in a minimum of stateful components. The application and each self-contained deployment unit of that application is designed according to cloud-focused design patterns and operated on a self-service elastic platform.

中文翻译：

cloud-native application (CNA)是一个分布式、弹性和水平可伸缩的系统，由(微)服务组成，将状态隔离在最少的有状态组件中。应用程序和该应用程序的每个自包含部署单元都是根据以云为中心的模式设计，并在一个自助服务弹性平台上运行。

第二个定义是之前说的马特的InfoQ中的采访时候一个叫做posta的大神给出的：

"Cloud native" is an adjective that describes the applications, architectures, platforms/infrastructure, and processes, that together make it *economical* to work in a way that allows us to improve our ability to quickly respond to change and reduce unpredictability. This includes things like services architectures, self-service infrastructure, automation, continuous integration/delivery pipelines, observability tools, freedom/responsibility to experiment, teams held to outcomes not output, etc.

中文翻译：

“云原生”是一个形容词，用于描述应用程序、体系结构、平台/基础设施和流程，这些应用程序、体系结构、平台/基础设施和流程一起使工作变得“经济”，从而使我们能够提高快速响应变化和减少不可预测性的能力。这包括服务体系结构、自助服务基础设施、自动化、持续集成/交付管道、可观察性工具、实验的自由/责任、坚持结果而不是输出的团队等等。

第三个定义那就是重磅的了著名的CNCF在2018年给出的定义：

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

中文翻译：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

上面的三个定义都是严格的标准化的定义，让人看起来云里雾里，不明所以。

我有时候就在想Cloud Native application为什么翻译成了云原生应用或者说为什么取这个名字呢？这个字面看起来不是很好理解，我也看了很就很久也不理解，我想起了有人说过《西游记》应该反着看，首先是西天如来在众徒里挑选了唐僧几人，乘小白龙一同去大唐弘扬天书佛法，唐僧几人欣然受命。可是没有想到前路坎坷，不仅有各路妖魔祸害人间，还有众多魑魅精怪打唐僧的主意。这一路都是步步惊心，时时危急。更让师徒们难以接受的是，这些妖魔鬼怪都有背景和后台，他们作恶多端却可以不受惩罚，逍遥法外。师徒们心灰意冷，对现实充满失望，深感黑暗。于是八戒躲进高老庄,沙僧钻进流沙河,而意志坚定的悟空不愿意放弃，始终坚信邪不压正。一路叱咤群害，斩妖除魔，和唐僧惺惺相惜，东去传教。而那些下凡祸害百姓作恶人间的妖魔鬼怪们被悟空乱棍打死，天庭就不能接受了，毕竟那是他们的亲信家属。于是天庭从中作梗，于是就有了白龙马重伤坠崖，悟空被压五指山下。而作为师傅的唐三藏却抛弃徒弟，一人抵达长安传教，被大唐皇帝封为御弟，坐享荣华富贵，安然度过一生。

那我们也把这个几个单词反着看，application native cloud，这就是应用原生云，应用需要以原生形态来设计，以充分发挥云的优势，解决我们之前说到的“我们处在一个业务快速增长，产品需要更快的迭代交付时代”所产生的一系列矛盾。

它是一个思想的集合，既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。

CNCF的定义中有一个关键词——声明式API。我刚开始看到这个声明式API的时候，我就在想这是什么东西？不是所有的API都是先定义想什么的吗？有声明式API，那是不是也有命令式API？它们有什么区别呢？大家如果看过k8s的介绍都会看到这个名词，声明式API。**声明式API定义一个理想的最终状态，让服务自驱地往最终状态，而不需要一个一个地向服务发送命令。**命令式API是指直接发出服务要执行的命令，如果不正确，则会发送更多指令和命令以执行其他操作。虽然这种方法多年来运作良好，但它有其缺陷 - 首先是它作为人类使用来指挥服务。插入人的元素带来了许多风险 - 人类犯错误，需要人类时间。 声明式API天然具有幂等性，不论操作多少次，最终效果都是一样的。 命令式API可就不是这样了。

给大家举一个例子，比如我要给某个面试候选者发邮件邀请，那我就要告诉他地址吧。命令式方式是这样的：你乘坐1号线到了大望路，先别出站，从1号线上来后走往14号线这边的F口出站。出来了地铁口就会看到SKP，向北走30m，看到华贸商业街，向东走150m进入看到华贸中心入口后向北走150m看到一座小黄楼，2层就是罗辑思维。这是导航地图思维的必要模式。使用声明模型，我可以说“我的地址是华贸中心20号楼; 将其输入GPS应用程序 - 它将使用最佳路线导航您。“

命令式和声明式的一个最大的区别点就是人工的介入程度，命令式需要人工一步步的去操作，引入了更多不确定性。

Cloud与Cloud-Native的不同

大家知道这三个云概念的区别点吗？就一句话——IaaS是包硬不包软，面对集成商，PaaS是包硬包软不包工，面对开发者，SaaS是包硬包软包工不包服务，面对消费者。

Cloud Native有很多组成部分，这里说的是技术部分是在传统Cloud的三层（IaaS、PaaS、SaaS）概念之上的：

• 敏捷基础设施对应IaaS部分。
• 微服务则可以对应PaaS和SaaS部分。

当然，Cloud Native比传统Cloud 多研发文化DevOps和组织结构。

Cloud Native从技术上更强调敏捷基础设施和微服务的概念，这并不意味着它是抛开IaaS、PaaS、SaaS而另起炉灶的。技术和服务模式的变革不是简单推翻过往，而是在上一轮技术的基础上，能让企业的运营效率更高，企业的商业价值更好。

第二部分 Cloud-Native的组成

Cloud-Native有哪些东西？

我们以软件开发的组成与Cloud Native组成进行对比：

1. 架构对应着微服务，以云和微服务为基础构建系统。
2. 研发流程对应着DevOps，拆除独立组织，构建共享的工具集、词汇表和通信结构，以服务于一个专注于单一目标的文化:快速安全地交付价值。
3. 团队文化对应着康威团队，
   • 采用逆康威策略组建团队。
   • 团队就有自主决策权利，掌握应用程序从开发到运营的整个生命周期。

康威定律：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。什么样的团队结构，就会设计出怎么样的系统架构。

第一定律：组织沟通方式会通过系统设计体现； 第二定律：时间再多，一件事也不可能做到完美，但总有时间做完一件事。 第三定律：线型系统和线型组织架构间有潜在的异质同态特性； 第四定律：大的系统组织总是比小系统更倾向于分解；

每一层都跨越多个业务能力领域，因此很难独立于其他业务功能创新和部署新功能。寻求迁移到云本地架构(如按业务能力划分的微服务)的公司，常常采用Thoughtworks所称的逆康威策略。

他们没有建立一个与其组织结构图相匹配的架构，而是决定了他们想要的架构，并重组组织以匹配该架构。按照Conway的说法，如果你这样做，你想要的架构最终会出现。

Cloud-Native设计原则

对于Cloud Native的设计原则或者说是设计理念吧，目前有两套主流的说法，我都罗列出来给大家做参考。

对左边的设计原则进行一下解释：

• 为失败设计：`Cloud Native 采用的是微服务架构，这个场景中常常出现的是服务数量多，依赖越来越复杂，出现问题的概率就越大，问题的定位也是越来越困难。这就会导致服务失败的时间越来越长。所以设计中我们就需要预测并解决这个故障，设计中对异常故障考虑越充分，故障的影响就会小得多。也就是之前说的反脆弱性。
• 不变性：基础设施中的每一个服务、组件都可以自动安装，部署，不需要人工干预。
• 去中心化：中心节往往是瓶颈，有技术上的瓶颈也有管理上的瓶颈。而且去中心化意味着关注点分离，让团队具有更多的决策权。
• 标准化：这个比较好理解了，标准化了自动化管理更加容易。
• 速度优先：这个也好理解，为什么要做微服务，为什么有Cloud Native就是天下武功唯快不破。
• 简化设计：现在都在流行极简风格，Cloud Native也不例外。目的就是为了减少失误，越是底层服务越需要简化设计，简化运维。
• 自动化驱动：自动化是我们的理想，就是为了减少人工参与，降低不确定性。目前为止，我没有从别的公开渠道看到哪家公司做到了全自动化驱动的，最多是半自动化吧。比如我们时常听到的CI/CD，目前常见的落地只有CI，很少见到CD。
• 演进式驱动：我们时常听到一句话：架构是演进出来的。的确是这样，没有最好的们只要合适现状那就是最好的。

对右边的设计原则进行一下解释：

• 面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
• 面向配置设计（Configuration）：一个镜像，多个环境配置；
• 面向韧性设计（Resistancy）：故障容忍和自愈；
• 面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
• 面向交付设计（Delivery）：自动拉起，缩短交付时间；
• 面向性能设计（Performance）：响应式，并发和资源高效利用；
• 面向自动化设计（Automation）：自动化的 DevOps；
• 面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
• 面向安全性设计（Security）：安全端点、API Gateway、端到端加密；

Cloud Native的十二因子

十二因子主要是SaaS架构的最佳实践和方法论，它可以指导我们关注哪些技术点，因为有的因子很简单比较好理解，我就挑选一些来说明：

• 基准代码：一份基准代码，多份部署；
• 依赖：依赖这里有两个含义，一个是服务之间的依赖，另一个是应用的包管理。
• 配置：代码与配置是分离的，在不同的环境中代码一样，但是配置大相径庭。这里说的配置不是应用的内部配置，而是类似数据库连接这样的配置。给了常用的两种解决方式：一个是配置放在环境变量，一个是放在配置中心；
• 后端服务：是指程序运行所需要通过网络调用的各种服务，如数据库，MQ，缓存等，不需要刻意区分本地服务和第三方服务，所有的服务都作为后端服务运行，强调后端服务是服务，不是中间件。是服务就需要服务团队运维服务的什么周期。
• 编译/发布/运行：严格分离构建和运行，严禁在线上调式bug。
• 过程是无状态：无状态才好管理。
• 端口绑定： 应用都走向服务化，所谓的服务化就是相互之间都在提供接口。
• 并发：这是是指应用服务内的进程并发为主，虽然提高了编程的复杂度，但是更节省资源了。
• 可处置性：服务出现问题的时候，可以进行快速的处理和恢复，那怕是关掉服务，重新启动一个新的服务。
• 环境一致性：统一研发和生产环境，因为只有在这样的前提下，我们的开发和运维的协作才更加畅通。
• 日志：日志看作是流，而不是文件。
• 管理进程：管理的应用和调度任务。

超越十二因子

看了上面的十二因子了，觉得很多吧，但是大神们觉得还不够，一个叫做Kevin的光头男，新加了三个因子，总共十五因子:

• API优先
• 监控
• 认证与授权

Cloud-Native十二因子作用

十二因子的的功能从OOP设计原则来说主要有：

• 单一职责原则
• 接口隔离原则
• 依赖倒置原则

对应用服务的生命周期有着指导性作用，通过强调声明性配置、无状态/无共享的水平扩展流程和与部署环境的整体松散耦合，关注速度、安全性和可伸缩性。十二因子的作用体现：

十二因子的作用：

• 符合十二因子的特性非常适合快速部署应用程序，因为应用程序很少甚至不需要关注部署它们环境的差异。
• 符合十二因子的特性很好地支持了“短暂性”的概念，即我们可以以极低的成本“抛弃”的应用程序。
• 可处置性让底层平台能够非常快速地将应用程序从故障中自动恢复
• 日志作为事件流处理，极大地支持在运行时查看应用程序的底层行为
• 环境之间强制的一致性、配置机制的一致性和支持服务管理使云平台能够对应用程序运行时结构的所有方面提供丰富的可见性和安全性。

度量Cloud-Native级别

假设我们已经实行Cloud-Native已经一段时间了，我们都想知道我们做到了哪一步。这是大神们给出来的标准，我们可以对照标准和自身的实现来定级。

第三部分 Cloud-Nativ的未来

鸿沟理论看Cloud Native发展

1991年杰弗里摩尔同志提出了了鸿沟理论，他有一本书《跨越鸿沟—颠覆性产品营销》。大家从图中可以看到鸿沟理论是一个正态分布图。分为了5个阶段，从左到右：创新者，早期采用者，早期大众，后期大众，落后者。其中创新者，早期采用者属于早期市场，主要是追求新事物新技术的人群；早期大众，后期大众，落后者属于主流市场，主要面向想要完整解决方案和便利的人群。

我举一个例子来大家说说上面5类人群的特点，假设明天某家汽车厂商推出了一辆完全可以无人自动驾驶的汽车，注意了是完全无人自动驾驶的L4甚至L5级别的。听听这位大哥的说法："等到海枯石烂的时候才会购买这辆车。"这就是典型的落后者。再来另一类人的说法："等我看到这辆无人驾驶汽车的功能和安全性都得到证明了，无人驾驶的技术真的可以解决我出门不需要自己开车的痛点了，我就会购买"，这是非常典型的实用主义者，也就是早期大众。还有另一种说法："等到别人都证明了这辆无人驾驶汽车真的比人开的安全，而且很方便那我再购买"，这是典型的后期大众，也是保守主义者。最后一种说法："第一款可以批量生产的无人驾驶汽车要出来了，我要去买一辆来体验一下"，这就是早期采用者或者是创新者。

分类我们解释过了，我们看看图。这张图中大家很容易关注到早期采用者和早期大众阶段之间的大鸿沟，却忘却了每一个阶段之间都存在沟壑，只是没有鸿沟那么大而已。按照鸿沟理论来说：，每个新技术都会经历鸿沟，大多数失败的产品也都是在鸿沟里结束了其整个生命周期，能否顺利跨越“鸿沟”，决定了创新性技术的成败。

说了这么多，大家很关注的就是cloud-native处于什么阶段？我个人观点目前处于第二阶段也就是早期采用者阶段。也就是说colud-native想要成为业界标准，那么就得跨越这个鸿沟。不过cloud-native相关的容器化，微服务，CI/CD都已经处在了第三阶段的早期大众阶段了，这是一个好现象，也是我看好cloud-native的原因之一。

再看看区块链最初的创造者与使用者，都是技术圈的人。他们用这个技术创造出来了“比特币”等各种产品。从2008年起用了七年的时间形成了少部分人的共识价值，但却不知道如何使用。然后黑色交易发现了这些产品的价值，而“勒索病毒”则把比特币推向了大众的视野。于是，这两年，越来越多的人参与了进来，少数机构利用这种技术的提升效率，而更多的人把它当成了金融产品去炒作。这样说来，“区块链”现阶段就是处在创新者阶段。

时间维度看Cloud Native未来

Cloud Native目前可以看到的两个方向分别是Service Mesh和Serverless。

Service Mesh是一个基础设施层,用于处理服务间通信。现代云原生应用有着复杂的服务扑结构,服务网格负责在这些拓扑结构中实现请求的可靠传递。在实践中,服务网格通常被实现为一组轻量级网络代理,它们与应用程序部在一起,对应用程序是透明的。

Serverless目前是没有权威的定义，按照亚马逊的说法：serverless架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如AWS Lambda服务），客户端逻辑和服务托管远程过程调用的组合。

Serverless就算后续发展起来了，我觉得还是主要在一些低流量短时间运行的领域使用，比如：

• 发消息如发邮件，发短信，发推送，访问频次不高，实时性要求不高的；
• 定时任务
• 文件处理，如果图片缩略；
• 事件上报

使用Serverless相当于我们租车，使用ecs就是我们买车，使用物理机就是我们开4s店了，可以卖车了。

FaaS是Serverless架构的一种实现，天然无状态，实现自动水平扩展。FaaS就是一种胶水，连接云端上各种服务，可用于构建业务系统，实现高可用，丰富云端的业务功能。

总结

世上没有免费的午餐，虽然有些技术或实践能够在某些方面带来一些改进，但很可能会让其它方面变得更加复杂。以上所谈到的新趋势大多还不具备成熟的工具。软件企业应当始终对新兴技术的权衡做到充分理解，通过在实际应用中的概念验证，对这些技术进行持续地测试、探索与学习。

参考文献

• 《Migrating to Cloud-Native Application Architectures》
• https://www.infoq.com/articles/cloud-native-panel
• 《Understanding cloud-native applications after 10 years of cloud computing》
• http://yowconference.com.au/slides/yow2013/Cockcroft-CloudNativeArchitectureNetflix.pdf
• https://github.com/cncf/toc/blob/master/DEFINITION.md
• https://www.infoq.cn/article/hv5DFt_bGjdFpQONgZqX
• 《持续演进的Cloud Native：云原生架构下微服务最佳实践》