怎样治白癜风 http://www.bdfyy999.com/如果你稍微留意观察就会发现，最近几年很多新锐公司其实都是“诞生在云上的公司”，这些公司也就是所谓的“云上原住民”。他们的技术和业务都是构建在云上，并借助云原生的优势快速成长。而这些业务就是由一个个的云原生应用组成的，因此要讲明白云原生，就得弄清楚什么是云原生应用（application）。
一句话来说，云原生应用的核心便是容器、函数和数据。
云原生应用首先是一个分布式系统，也就是说这些应用服务往往运行在不同的机器上，将计算任务分配到不同的机器，更加高效，可扩展。
分布式系统首要考虑的应当是网络间的通信，因为网络是不安全的，传输也是有成本的，并且存在延迟。
正如CAP定理指出，任何一个通过网络连接的、共享数据的分布式系统最多只能满足以下三个需求中的两个：
一致性：所有节点访问同一份最新的数据副本
可用性：系统系统的服务或数据必须一直处于可用状态
分区容错性：指系统遇到网络分区故障时，仍然能对外提供服务
现实情况，在分布式系统中，分区故障比较常见。我们设计应用时需要在追求一致性还是高可用之间做出取舍，例如很多NoSQL数据库会选择高可用，而关系型数据库会为了ACID原则追求一致性。
本文主要讲解云原生应用的原理、组成，以及如何去设计、构建和运维一个成功的云原生应用程序。
一、云原生原理和组成
容器
容器最初的想法是想将操作系统分割成几块互相不干扰，可以安全运行程序的区域。Linux内核空间就提供了命名空间（namespace）和控制组（controlgroup）来实现这个功能。
但是直接调用系统内核对于开发者来说并不方便，因此便引入了Linux容器技术（LXC）,它极大地简化了应用程序与系统内核交互的复杂性，也是现在人们所熟知的容器的底层技术。
而Docker正是将复杂的内核功能封装成了对开发者非常友好的组件，才使得容器真正流行开来。在Docker看来，容器是经过封装的，可以独立部署的一个组件，这个组件通过系统级别的虚拟技术使其可以作为一个独立的实例来运行并和其他实例共享一个系统内核。
容器使用写时复制（copy-on-write）的文件系统策略，允许多个容器共享数据，只有当容器需要修改或者写入新数据时，操作系统才会复制一个数据的副本。
从内存和空间使用上来看，容器是非常轻量级的，这也是为什么容器可以快速地启动。而快速启动非常适合需要横向扩容的场景，比如云原生应用。
容器隔离等级
容器是基于操作系统虚拟化技术，共享一个操作系统内核，尽管与虚拟机提供的基于硬件虚拟化技术的隔离相比还有一定差距，但是这种系统级别的隔离在大部分情况下已经足够了。
容器编排
动态地管理容器的生命周期需要一个容器编排工具，毫无疑问，Kubernetes是目前最流行的一款集群管理及容器编排工具，关于Kubernetes我们会专门详细介绍。
无服务架构
无服务器架构意味着服务的伸缩以及底层的基础架构都是由云服务提供商来管理的。所有管理和运维操作都被剥离了出来，交由云服务提供商来解决。
从开发者的角度来看，无服务器架构通常会伴随着事件驱动的编程模型，而从经济成本角度看，无服务器架构意味着你只需要按耗费的资源付费，比如消耗的CPU时间。
函数计算
函数计算通常指函数即服务产品，比如AWSLambda。一个函数就是一个可执行单元，这意味着这段代码有一个起始状态和一个结束状态。一个函数通常是由其他函数或平台服务发出的事件触发的。举个例子，当数据库或者事件服务增加了一条记录时可以触发一个函数。
微服务
微服务架构是一种面向服务的架构体系，其中应用程序按功能分解为小型的、松耦合的各种服务。其重点在于，单个服务被划分的足够小，相互间耦合度很低，并围绕业务功能进行分解。
微服务架构经常与巨石架构相比较。在巨石架构中，通常只有一份代码库，共享一个数据库和数据结构，而在微服务架构中，应用程序由多个较小的代码库组成，由独立团队开发和管理。
每个服务都专注于一个特定的任务，由一个小团队负责开发和运营。这些服务在独立的进程中运行，相互之间通过基于同步或异步消息的API进行通信。
每个服务都可以被视为一个独立的应用，有独立的团队、测试、开发、数据和部署。
二、云原生应用的设计
云原生应用从上层架构来看，包括精益运营、安全性、可靠性和可用性、可扩展性和成本这个五大支柱，我们主要从以下几个技术实现层面来讲讲。
API设计和版本控制
因为API是其他服务用来与你的服务进行通信的接口，因此正确地记录和版本化API至关重要
三种策略：
无版本
API只有一个版本，API的调用者永远只调用最新的API。当API接口发生更改时，所有使用者也需要跟着改。对于调用者而言，这是最昂贵的方法，因为每次发布新的API版本时，他们都必须升级。
点对点
所有版本的API都在正常运行，每个调用者都使用他们需要的版本。调用者可以根据需要迁移到新版本。与无版本相比，这对调用者来说是一个更好的策略，但是对于API开发人员而言，维护较旧的API版本成本很高。
兼容性版本控制
所有调用者都使用最新的API版本。旧版本的API会被舍弃，但是最新版本的API是向后兼容的。
研究结果表明，兼容性版本控制策略是最高效的。尽管对API的开发者而言，它确实会带来一些额外的工作，因为需要保持向后兼容性。
REST本身不提供任何特定的版本控制约定，但有三种方法来实现版本控制：全局版本控制、资源版本控制和基于mime的方法。这些方法中的每一种都有其优点和缺点，这里没有明确的最佳方法。
迄今为止，使用语义版本号几乎已经是一种标准做法了。语义版本号（major.minor.patch）可以清晰地告诉你应该增加版本号的哪一部分：
当你修改了API，使其不再向前兼容时，应该增加主版本号（major）。
当你用向后兼容的方式增加了一些功能时，应该增加次版本号（minor）。
当你用向后兼容的方式解决了几个Bug时，应该增加补丁版本号（patch）。
服务间通信
网络和服务通信是分布式系统最基础的话题，它们对一个应用的性能起着至关重要的作用。因此，理解各种服务间的通信方案对于你设计和构建云原生应用是非常有帮助的。从大致上来讲，你可以把服务间的通信分为两类，一类是外部服务通信，另一类是内部服务通信
通信协议
大多数情况下，HTTP协议会被用来作为客户端和云原生应用程序之间的通信协议。但是，它并不是性能最高的协议。
一个大型的微服务架构下的应用程序可能由数百甚至数千个微服务组成，服务越多，需要进行的通信和数据交换就越多。因此，所选择的协议成为影响性能的重要因素，并且更改生产环境下的服务通信协议的代价可能会相当大。
其中websocket、
