- 容器化包装：软件应用的进程应该包装在容器中独立运行。
- 动态管理：通过集中式的编排调度系统来动态的管理和调度。
- 微服务化：明确服务间的依赖，互相解耦。
image
https://dzone.com/articles/cloud-native-seeing-through-the-hype
image
什么是云原生？
云原生准确来说是一种文化，更是一种潮流，它是云计算的一个必然导向。意义在于让云成为云化战略成功的基石，而不是障碍。
image
云原生之前
image
云原生
image
image
Service Mesh 的思路，体现在将 SDK 客户端的功能剥离出来，放到 Sidecar 中。通过这种方式，实现应用的轻量化。此时绝大部分的功能都在剥离，应用中只留下一个轻量级的客户端。这个轻量级客户端中还保留有少数功能和信息，比如目标服务的标识（指出要调用的目标），序列化的实现。
image
image
云原生简介
Cloud Native 翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。
Cloud Native是更好的工具、自我修复系统、和自动化系统的集合，可以让应用和基础设施的部署和故障修复更加快速和敏捷，极大的降低企业在云计算方面的部署成本。
目前业界公认的云原生主要包括以下几个层面的内容。
image
容器，服务网格，微服务，不可变的基础设施，公开的API都接近云原生相关概念。
云原生技术可以让系统松耦合，支持弹性伸缩、可管理的、清晰的。通过整合健壮且有效的自动化，工程师可以用很少的劳动来完成频繁的、预期中的高危代码修改。
微服务
微服务解决的是我们软件开发中一直追求的低耦合 高内聚，记得有一次我们系统的接口出了问题，结果影响了用户的前台操作，于是黎叔拍案而起，灵魂发问：“为啥这两个会互相影响？！”
微服务可以解决这个问题，微服务的本质是把一块大饼分成若干块低耦合的小饼，比如一块小饼专门负责接收外部的数据，一块小饼专门负责响应前台的操作，小饼可以进一步拆分，比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼，这样每个小饼出问题了，其它小饼还能正常对外提供服务。
随着微服务化架构的优势展现和快速发展，2013年，MartinFlower对微服务概念进行了比较系统的理论阐述，总结了相关的技术特征。首先，微服务是一种架构风格，也是一种服务；其次，微服务的颗粒比较小，一个大型复杂软件应用由多个微服务组成，比如Netflix目前由500多个的微服务组成；最后，它采用UNIX设计的哲学，每种服务只做一件事，是一种松耦合的能够被独立开发和部署的无状态化服务（独立扩展、升级和可替换）。微服务架构如图1-8所示。
image
图： 微服务架构示例
由微服务的定义分析可知，一个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发，甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。根据业务的需求，不同的服务可以根据业务特性进行不同的技术选型，是计算密集型还是I/O密集型应用都可以依赖不同的语言编程模型，各团队可以根据本身的特色独自运作。服务在压力较大时，也可以有更多容错或限流服务。
微服务架构确实有很多吸引人的地方，然而它的引入也是有成本的，它并不是银弹，使用它会引入更多技术挑战，比如性能延迟、分布式事务、集成测试、故障诊断等方面，企业需要根据业务的不同的阶段进行合理的引入，不能完全为了微服务而“微服务”
DevOps
DevOps的意思就是开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。我们现在开发和运维已经是一个团队了，但是运维方面的知识和经验还需要持续提高。
DevOps如果从字面上来理解只是Dev（开发人员） Ops（运维人员），实际上，它是一组过程、方法与系统的统称，其概念从2009年首次提出发展到现在，内容也非常丰富，有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面。首先，组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。其次，自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。总之，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。如图所示，
image
图 DevOps强调组织的沟通与协作
image
持续交付
持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，要做到这点非常非常难。我们现在两周一个版本，每次上线之后都会给不同的用户造成不同程度的影响。
它更多是代表一种软件交付的能力，过程示例请参考图：
image
图 持续交付流程
容器化
容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护，现在比较流行的工具是docker和k8s。
image
基于虚拟机技术，陆续出现了 IaaS/PaaS/FaaS 等形态，以及他们的开源版本。
image
2013 年 docker 出现，容器技术成熟，然后围绕容器编排一场大战，最后在 2017 年底，kubernetes 胜出。2015 年 CNCF 成立，并在近年形成了 cloud native 生态。
image
云原生的发展历程
云原生（Cloud Native）最初来描述云上应用的典型架构与特性，随着容器、kubernetes、Serverless、FaaS技术的演进，CNCF（Cloud Native Computing Foundation ，云原生计算基金会）把云原生的概念更广泛地定义为“让应用更有弹性、容错性、观测性的基础技术，让应用更容易部署、管理的基础软件、让应用更容易编写、编排的运行框架等”，希望能够让开发者最好的利用云的资源、产品和交付能力。
下边大致梳理一下云原生的发展过程。
2004 年 ~ 2007 年，Google 已在内部大规模地使用像 Cgroups 这样的容器技术； 2008 年，Google 将 Cgroups 合并进入了 Linux 内核主干。 2013 年，Docker 项目正式发布。 2014 年，Kubernetes 项目也正式发布。 2015 年，CNCF 成立。 2017 年，CNCF 达到 170 个成员和 14 个基金项目。 2018 年，CNCF 成立三周年有了 195 个成员，19 个基金会项目和 11 个孵化项目，如此之快的发展速度在整个云计算领域都是非常罕见的。
2014 年 Kubernetes 项目发布的原因也非常容易理解，因为有了容器和 Docker 之后，就需要有一种方式去帮助大家方便、快速、优雅地管理这些容器，这就是 Kubernetes 项目的初衷。在 Google 和 Redhat 发布了 Kubernetes 之后，这个项目的发展速度非常之快。
2015 年由 Google、Redhat 以及微软等大型云计算厂商以及一些开源公司共同牵头成立了 CNCF 云原生基金会。CNCF 成立之初，就有 22 个创始会员，而且 Kubernetes 也成为了 CNCF 托管的第一个开源项目。在这之后，CNCF 的发展速度非常迅猛。
云原生技术生态现状
因此，如今我们所讨论的云原生技术生态是一个庞大的技术集合。CNCF 有一张云原生全景图（https://github.com/cncf/landscape），在这个全景图里已经有 200 多个项目和产品了，这些项目和产品也都是和 CNCF 的观点所契合的。所以如果以这张全景图作为背景，加以思考就会发现，我们今天所讨论的云原生其实主要谈论了以下几点：
云原生基金会 —— CNCF
CNCF 是目前云计算领域最成功的开源基金会之一，是 Kubernetes、 etcd、Envoy 等知名开源项目的托管基金会。
云原生技术社区
云原生技术社区，比如像 CNCF 目前正式托管的 20 多个项目共同构成了现代云计算生态的基石，其中像 Kubernetes 这样的项目已经成为了世界第四活跃的开源项目；目前从 CNCF 毕业的项目以及有 6 个，分别是 Kubernetes 、Prometheus、Envoy、CoreDNS、containerd、Fluentd 。
云原生技术产业
除了前面两点之外，现在全球各大公有云厂商都已经支持了 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 技术更强一些。相比之下， Kubernetes 则兼具了两者优势，最终在 2017 年“三国争霸”的局面中得以胜出，成为了当时直到现在的容器编排标准。这一过程的代表性事件就是 Docker 公司宣布在核心产品中内置了 Kubernetes 服务，并且 Swarm 项目逐渐停止维护。
到了 2018 年的时候，云原生技术理念开始逐渐萌芽，这是因为此时 Kubernetes 以及容器都成为了云厂商的既定标准，以“云”为核心的软件研发思想逐步形成。
而到了 2019 年，情况似乎又将发生一些变化。
2019 年，云原生技术普及元年
为什么说 2019 年很可能是一个关键节点呢？我们认为 2019 年是云原生技术的普及元年。
首先大家可以看到，在 2019 年，阿里巴巴宣布要全面上云，而且“上云就要上云原生”。我们还可以看到，以“云”为核心的软件研发思想，正逐步成为所有开发者的默认选项。像 Kubernetes 等云原生技术正在成为技术人员的必修课，大量的工作岗位正在涌现出来。
这种背景下，“会 Kubernetes” 已经远远不够了，“懂 Kubernetes”、“会云原生架构” 的重要性正日益凸显出来。 从 2019 年开始，云原生技术将会大规模普及，这也是为什么大家都要在这个时间点上学习和投资云原生技术的重要原因。
云原生代表技术
image
“12要素”
“12要素”英文全称是The Twelve-Factor App，最初由Heroku的工程师整理起步，是集体贡献总结的智慧，如图所示。
image
图：12要素
根据基于云的软件开发模式，12要素比较贴切地描述了软件应用的原型，并诠释了使用原生云应用架构的原因。比如，一个优雅的互联网应用在设计过程中，需要遵循的一些基本原则和云原生有异曲同工之处。通过强化详细配置和规范，类似Rails的基于“约定优于配置”（convention over configuration）的原则，特别在大规模的软件生产实践中，这些约定非常重要，从无状态共享到水平扩展的过程，从松耦合架构关系到部署环境。基于12要素的上下文关联，软件生产就变成了一个个单一的部署单元；多个联合部署的单元组成一个应用，多个应用之间的关系就可以组成一个复杂的分布式系统应用。
下面简要介绍图1-9中的这些原则。相信很多开发者在实际开发工作中已经很好地应用了其中的一些原则，只是没有意识到概念本身。对这些原则比较陌生的开发者，如果想了解更多的操作过程，请参阅《云原生时代下的12要素（12-Factor）应用与实践》一文。
基准代码
每一个部署的应用都在版本控制代码库中被追踪。在多个部署环境中，会有多种部署实例，单个应用只有一份代码库，多份部署相当于运行了该应用的多个实例，比如开发环境一个实例，测试环境、生产环境都有一个实例。
实际上，在云计算架构中，所有的基础设施都是代码配置，即Infrastructure as Code（IaC），整个应用通过配置文件就可以编排出来，而不再需要手工的干预，做到基础服务也是可以追踪的。
依赖
应用程序不会隐式依赖系统级的类库，通过依赖清单声明所有依赖项，通过依赖隔离工具确保程序不会调用系统中存在，但清单中未声明依赖项，并统一应用到生产和开发环境。比如通过合适的工具（例如Maven、Bundler、NPM），应用可以很清晰地对部署环境公开和隔绝依赖性，而不是模糊地对部署环境产生依赖性。
在容器应用中，所有应用的依赖和安装都是通过DockerFile来完成声明的，通过配置能明确把依赖关系，包括版本都明确地图形化展示出来，不存在黑盒。
配置
环境变量是一种清楚、容易理解和标准化的配置方法，将应用的配置存储于环境变量中，保证配置排除在代码之外，或者其他可能在部署环境（例如研发、展示、生产）之间区别的任何代码，可以通过操作系统级的环境变量来注入。
实例根据不同的环境配置运行在不同的环境中，此外，实现配置即代码，在云环境中，无论是统一的配置中心还是分布式的配置中心都有好的实践方式，比如Docker的环境变量使用。
后端服务
不用区别对待本地或第三方服务，统一把依赖的后端作为一种服务来对待，例如数据库或者消息代理，作为附加资源，同等地在各种环境中被消耗。比如在云架构的基础服务中，计算、网络、存储资源都可以看作是一种服务去对待使用即可，不用区分是远程还是本地的。
构建、发布、运行
应用严格区分构建、发布、运行这3个阶段。3个阶段是严格分开的，一个阶段对应做一件事情，每个阶段有很明确的实现功能。云原生应用的构建流程可以把发布配置挪到开发阶段，包括实际的代码构建和运行应用所需的生产环境配置。在云原生应用中，基于容器的Build-Ship-Run和这3个阶段完全吻合，也是Docker对本原则的最佳实践。
进程
进程必须无状态且无共享，即云应用以一个或多个无状态不共享的程序运行。任何必要状态都被服务化到后端服务中（缓存、对象存储等）。
所有的应用在设计时就认为随时随地会失败，面向失败而设计，因此进程可能会被随时拉起或消失，特别是在弹性扩容的阶段。
端口绑定
不依赖于任何网络服务器就可以创建一个面向网络的服务，每个应用的功能都很齐全，通过端口绑定对外提供所有服务，比如Web应用通过端口绑定（Port binding）来提供服务，并监听发送至该端口的请求（包括HTTP）。
在容器应用中，应用统一通过暴露端口来服务，尽量避免通过本地文件或进程来通信，每种服务通过服务发现而服务。
并发
进程可以看作一等公民，并发性即可以依靠水平扩展应用程序来实现，通过进程模型进行扩展，并且具备无共享、水平分区的特性。
在互联网的服务中，业务的爆发性随时可能发生，因此不太可能通过硬件扩容来随时提供扩容服务，需要依赖横向扩展能力进行扩容。
易处理
所有应用的架构设计都需要支持能随时销毁的特点，和状态的无关性保持一致，允许系统快速弹性扩展、改变部署及故障恢复等。
在云环境中，由于业务的高低峰值经常需要能实现快速灵活、弹性的伸缩应用，以及不可控的硬件因素等，应用可能随时会发生故障，因此应用在架构设计上需要尽可能无状态，应用能随时随地拉起，也能随时随地销毁，同时保证进程最小启动时间和架构的可弃性，也可以提供更敏捷的发布及扩展过程。
环境等价
必须缩小本地与线上差异，确保环境的一致性，保持研发、测试和生产环境尽可能相似，这样可以提供应用的持续交付和部署服务。
在容器化应用中，通过文件构建的环境运行能做到版本化，因此保证各个不同环境的差异性，同时还能大大减少环境不同带来的排错等成本沟通问题。
日志
每一个运行的进程都会直接标准输出（stdout）和错误输出（stderr）事件流，还可以将日志当作事件流作为数据源，通过集中服务，执行环境收集、聚合、索引和分析这些事件。
日志是系统运行状态的部分体现，无论在系统诊断、业务跟踪还是后续大数据服务的必要条件中，Docker提供标准的日志服务，用户可以根据需求做自定义的插件开发来处理日志。
管理进程
管理或维护应用的运行状态是软件维护的基础部分，比如数据库迁移、健康检查、安全巡检等，在与应用长期运行的程序相同环境中，作为一次性程序运行。
在应用架构模式中，比如Kubernetes里面的Pod资源或者dockerexec，可以随着其他的应用程序一起发布或在出现异常诊断时能通过相关的程序去管理其状态。
云原生应用的逻辑依赖关系
云原生的内容非常广泛，目前没有系统的说明和完整的定义，上文介绍了云原生应用的基础组件和相关特点，可能读者对云原生应用的逻辑还存在一些困惑。为了更清楚地进行说明，我们总结了其依赖关系，如图所示。
image
首先，为了抓住商业机会，业务需要快速迭代，不断试错，因此，企业需要依赖拥有持续交付的能力，这些不仅包括技术需求还包括产品的需求，如何能拥有持续交付的能力，大而全的架构因为效率低下，显然是不合适的。于是演变出微服务架构来满足需求，通过把系统划分出一个个独立的个体，每个个体服务的设计依赖需要通过12要素的原则来规范完成。同样，如果系统被分成了几十个甚至几百个服务组件，则需要借助DevOps才能很好地满足业务协作和发布等流程。最后，DevOps的有效实施需要依赖一定的土壤，即敏捷的基础设施服务，现实只有云计算的模式才能满足整体要求。通过上述梳理，我们总结出面向云原生应用的3个不同层次的特点。
高可用设计（Design for Availability），依据应用业务需求，高可用分为不同级别，比如不同区域、不同机房（跨城或同城）、不同机柜、不同服务器和不同进程的高可用，云原生应用应该根据业务的可用性要求设计不同级别的架构支持。
可扩展设计（Design for Scale），所有应用的设计是无状态的，使得业务天生具有扩展性，在业务流量高峰和低峰时期，依赖云的特性自动弹性扩容，满足业务需求。
快速失败设计（Design for Failure），即包括系统间依赖的调用随时可能会失败，也包括硬件基础设施服务随时可能宕机，还有后端有状态服务的系统能力可能有瓶颈，总之在发生异常时能够快速失败，然后快速恢复，以保证业务永远在线，不能让业务半死不活地僵持着。
通过上面的基本描述及云原生应用的组成或特点，与容器技术相比可以得知，容器的特性天生就是按这些原则进行设计的。随着互联网业务的架构不断演进，从单体应用到分布式应用，甚至微服务架构应用中，12要素较好地为构建互联网化应用提供了统一的方法论和标准化，具有强大的生命力，每一条原则都是应用开发的珠玑。当然，在实践过程中，每一个原则也不是一成不变的，随着新的理念和技术出现，原有的因素会得到延伸和发展，会出现新的原则和应用，这套理论也适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序，因此也作为云原生架构应用的基本指导原则之一.
技术的趋势和影响
软件设计有两个关键目标：高内聚、低耦合，围绕这2个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则。
软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。
但后来，人们发现有更多的诉求，希望开发软件变得更简单、更快捷，程序员希望更少编写代码，非专业人员也希望能开发程序，于是，更多的更傻瓜的编程语言被发明出来，更多的编程技术和编程思想被发明出来，比如库、组件、云基础设施。
于是很多技术变成了屠龙之技，比如汇编，时代变了，建国后动物不能成精了，没有龙可以宰了，然后很多软件工程师摇身一变成了调参工程师、Call API砖家、用库包能手、拼组件达人，这是效率分工的结果，也是技术发展的使然。
纵观近二十年的科技互联网发展历程，大的趋势是技术下沉，特别是近些年，随着云计算的发展和普及，基础设施越来越厚实，业务开发变得越来越容易，也越来越没有技术含量，而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不禁让互联网行业的油腻大叔们噤若寒蝉，仿佛分分钟就要被卷入历史洪流而万劫不复。
虽然不可否认技术的重要性在降低，但也还不至于那么悲观。遥想PC时代，当VB、Delphi、MFC出现的时候，也有类似论调，所见即所得，点点鼠标，就可以开发PC桌面程序，是不是很高端？
那时候码农的担心相比现在恐怕是只多不少吧，但后来随着互联网兴起，出现了后端开发这个工种，码农很快找到了新的战场，网络、分布式、数据库、海量服务、容灾防错，于是又玩出一堆新花样。
如果说PC时代的基础设施是控件库，互联网时代的基础实施是云，那AI时代基础设施是什么？又有什么高端玩法？
Kubernetes是容器编排系统的事实标准
在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势，而对于容器的编排管理，Swarm、Mesos和Kubernetes的大战已经基本宣告技术，kubernetes成为了无可争议的赢家。下面这张图是Kubernetes的架构图，其中显示了组件之间交互的接口CNI、CRI、OCI等，这些将Kubernetes与某款具体产品解耦，给用户最大的定制程度，使得Kubernetes有机会成为跨云的真正的云原生应用的操作系统。
image
Kuberentes架构
随着Kubernetes的日趋成熟，“Kubernetes is becoming boring”，基于该“操作系统”之上构建的适用于不同场景的应用将成为新的发展方向，就像我们将石油开采出来后，提炼出汽油、柴油、沥青等等，所有的材料都将找到自己的用途，Kubernetes也是，毕竟我们谁也不是为了部署和管理容器而用Kubernetes，承载其上的应用才是价值之所在。
云原生的核心目标
image
Cloud Native Core target
云已经可以为我们提供稳定的可以唾手可得的基础设施，但是业务上云成了一个难题。Kubernetes的出现与其说是从最初的容器编排解决方案，倒不如说是为了解决应用上云（即云原生应用）这个难题。包括微服务和FaaS/Serverless架构，都可以作为云原生应用的架构。
image
FaaS Landscape
但就2017年为止，kubernetes的主要使用场景也主要作为应用开发测试环境、CI/CD和运行Web应用这几个领域，如下图TheNewStack的Kubernetes生态状况调查报告所示。
image
Workloads running on Kubernetes
另外基于Kubernetes的构建PaaS平台和Serverless也处于爆发的准备阶段，如下图中Gartner的报告中所示：
image
当前各大公有云如Google GKE、微软Azure ACS、亚马逊EKS（2018年上线）、VmWare、Pivotal、腾讯云、阿里云等都提供了Kuberentes服务。
微服务
微服务——Cloud Native的应用架构
下图是Bilgin Ibryam给出的微服务中应该关心的主题，图片来自RedHat Developers。
image
Microservices concerns
微服务带给我们很多开发和部署上的灵活性和技术多样性，但是也增加了服务调用的开销、分布式系统管理、调试与服务治理方面的难题。
当前最成熟最完整的微服务框架可以说非Spring莫属，而Spring又仅限于Java语言开发，其架构本身又跟Kubernetes存在很多重合的部分，如何探索将Kubernetes作为微服务架构平台就成为一个热点话题。
就拿微服务中最基础的服务注册发现功能来说，其方式分为客户端服务发现和服务端服务发现两种，Java应用中常用的方式是使用Eureka和Ribbon做服务注册发现和负载均衡，这属于客户端服务发现，而在Kubernetes中则可以使用DNS、Service和Ingress来实现，不需要修改应用代码，直接从网络层面来实现。
image
两种服务发现方式
Cloud Native
DevOps——通向云原生的云梯
image
CNCF（云原生计算基金会）给出了云原生应用的三大特征：
- 容器化包装：软件应用的进程应该包装在容器中独立运行。
- 动态管理：通过集中式的编排调度系统来动态的管理和调度。
- 微服务化：明确服务间的依赖，互相解耦。
软件生命周期维度看云原生
image
微软的 Azure 计算服务架构
image
Microsoft Azure Compute Service Categories
- Virtual Machines - An Infrastructure as a Service (IaaS) offering that provides maximum control over the hosting environment and support for legacy workloads. Consumers are responsible for operational activities such as server patching and monitoring.
- Virtual Machine Scale Sets - Provides services on top of Virtual Machines where you need to deploy large numbers of identical servers with load balancing and auto-scale, reducing some operational overhead.
- Containers - Provides traditional container orchestrators (Docker, Kubernetes, Mesos) as well as Microsoft’s Service Fabric for building managed microservices applications that are resilient and scalable, and support Linux and Windows platforms.
- App Services - A fully managed and scalable Platform as a Service (PaaS) offering for Web, Mobile and API applications, which removes a lot of the management overhead, yet provides flexibility with support for multiple platforms (Windows/Linux) and languages (.NET, Node.js, PHP, Java, Python).
- Serverless - Provides an on-demand and scalable execution model for coded functions in multiple programming languages, so that you pay only for the time the code is executing, from the point at which it is triggered to completion.
image
Figure 2 Azure Cloud-Native Application Framework
Completing the picture
In addition to the compute services already described, Azure offers a range of other managed services to enable development of end-to-end applications.
- Storage - Managed storage for logs, document and media files (e.g. Blobs and SMB File services).
- Data - Relational and NoSQL databases, caching and search services (e.g. SQL Azure, Cosmos DB, Redis Cache, Azure Search).
- Messaging - Queues and subscriptions (e.g. Azure Service Bus).
- Security - Authentication services (e.g. Azure AD).
- Network - Traffic management, content delivery, load balancing and network virtual appliances.
Specialised or more advanced apps can make use of additional services for Artificial Intelligence, Analytics and Event driven architectures (such as IoT) and integration for hybrid scenarios.
Putting all of this together, figure 2 shows a framework for building cloud-native applications on Azure. Other cloud platforms do provide similar offerings. If you are not using Azure, hopefully this article has given you some things to look out for on your cloud platform to build cloud-native apps that respond to change and enable you to work at the pace your business demands.
