前面的文章介绍过：云原生应用的定义和部署。今天主要介绍云原生编排及管理。云原生—应用定义及部署
目录
一、Orchestration & Management 编排及管理
二、Scheduling & Orchestration编排和调度
三、Coordination & Service Discovery 协调和服务发现
四、Remote Procedure Call 远程过程调用RPC
一、Orchestration & Management 编排及管理
前面已经讲解了关于云原生应用定义和及部署，我们现在可以深入研究编排和管理流程。
本节内容里面，你可以找到用于处理运行和连接云原生应用程序的工具。
另外，本节内容也涵盖了从 Kubernetes 本身到负责应用程序间和外部通信的基础设施层的所有内容。
本质上来看，可扩展的云原生应用程序依赖于这些工具所支持的自动化和弹性化。
这一层主要负责容器平台的编排和调度工作。包括服务的发现治理、远程调用、服务代理、微服务治理等组件。
编排和管理的基本结构如下，
二、Scheduling & Orchestration编排和调度
编排和调度是指跨集群运行和管理容器。集群是一组通过网络连接的物理或虚拟机器。
容器编排器（和调度器）有点类似于笔记本电脑上的操作系统。
操作系统管理您的所有应用程序，例如 Microsoft Office、微信和QQ等；操作系统会执行它们，并安排每个应用程序何时使用笔记本电脑的硬件资源，如 CPU、内存和存储等。
虽然在一台机器上运行一切在管理层面看是最好不过的，但今天的大多数应用程序实际上所处理的数据可能都比一台计算机要大得多。
例如，目前像很京东、淘宝这种大型的电商平台。他们拥有非常庞大的应用程序并分布在数万台不同的机器上，形成了一个分布式集群。
目前，大多数应用程序都是以这种方式构建的，因此，我们需要一个能够管理在这些不同机器上运行的所有组件的一款软件——“集群操作系统”。
这个工具就是容器编排器。
我们所熟知的K8S就行当下很火的容器编排器。K8S供了这些容器的强大管理能力。而且容器和K8S都是云原生架构的核心组件。
所解决的问题
在云原生架构中，应用程序被分解为许多小的组件或服务，每个组件或服务都放置在一个独立容器中。这些被切分后的组件或者服务就被称为微服务。
与传统的单体应用相比，现在一般企业动辄则拥有数十个甚至数百个服务。如果出现问题，这些服务中的每一个都需要资源、监控和修复。
如果仅针对单个服务手动完成资源分配、监控和修复是有可能的，但如果是处理多个服务时，这种情形下仍以手动方式逐一维护就显得捉襟见肘了。
这是就需要引入集群容器编排器来管理整个集群应用。
引入云原生的意义
我们知道，K8S是名副其实的容器编排器。
K8S架构和组件工作原则利用了 “期望状态” 。也就是说，你定义了组件的期望状态，而 K8S 要将它们始终调整到你所期望的这个状态。
例如，服务的10个实例在3个节点上运行，可以访问数据库等，K8S不断与实际状态进行比较。如果期望和实际状态不匹配，K8S通过创建或销毁对象来协调它们。如果一个容器崩溃，那么K8S就会启动一个新容器。
总之，K8S可以将整个集群视为“一台计算机”。它只关注环境应该是什么样子，并为您处理具体的实现细节。
另外，开发人员可以使用这种核心控制器模式来扩展 K8S。操作员模式允许人们为自定义资源编写自定义控制器，并将任意逻辑和自动化构建到 K8S中。
三、Coordination & Service Discovery 协调和服务发现
业务应用程序中，一般是由多个单独的服务组合而成，这些应用之间需要很好的协作才能为用户提供有效的价值。
为了协作，服务之间通过网络进行通信，为了实现通信这一机制，应用之间必须首先找到对方。那服务发现组件就是来解决这一问题的。
解决的问题
我们知道，云原生架构的特点就是动态性，这也意味着云原生架构内部的服务组织形式也在不断发生变化。
当一个容器在一个节点上崩溃时，会在另一个节点上启动一个新容器来替换它。然后应用程序会部署在新的容器中并需要及时为外界提供服务。那在整个集群环境中，如何快速跟踪网络中新的服务并发现它，以便在需要时能快速访问到这台机器。
这个问题就需要由我们的协调和发现组件来解决。
引入云原生意义
服务发现工具通过提供一个公共场所来查找和潜在地识别单个服务来解决这个问题。解决此类问题基本上有两种类型的工具：
1）服务发现引擎
服务发现引起，类似与数据库的工具，用于存储所有服务的信息以及如何定位它们。
2）名称解析工具
名称解析工具，主要接收服务位置请求并返回网络地址信息的一种工具。
在K8S中，为了使 pod可访问，引入了一个名为“服务”的新抽象层。服务为一组动态变化的 Pod 提供一个稳定的地址。这个“服务”通常是指放置在容器和 pod 中的服务。它是实际应用程序中具有特定功能的应用程序组件或微服务，比如手机上安装的人脸识别应用等。
随着分布式系统变得越来越普遍，传统的 DNS 流程和传统的负载均衡器往往无法跟上不断变化的端点信息。为了弥补这些缺点，服务发现工具可以处理各个应用程序实例的快速注册和注销。
分布式计算中很重要的一点就是各个服务之间的协同以及服务发现，从Zookeeper到近年来在很多互联网厂商和应用中流行的Consul，都可以用于分布式服务的发现和配置，Kubernetes默认使用的则是CoreOS旗下的Etcd。
四、Remote Procedure Call 远程过程调用RPC
远程过程调用 (RPC) 是一种使应用程序能够相互通信的特殊技术。这是构建应用程序通信的一种方式。
解决的问题
现代应用程序由许多单独的服务组成，这些服务必须进行通信才能进行协作。RPC 是处理应用程序之间通信的一种选择。
引入云原生的意义
RPC 提供了一种紧密耦合的方式来处理服务之间的通信， 它可以支持多种编程语言支持，比如C++，C＃，Java，JavaScript，Python等。
RPC有很多潜在的好处：它使编码连接更容易，它允许非常有效地使用网络层和服务之间结构良好的通信。RPC 还因创建脆弱的连接点和迫使用户对多个服务进行协调升级而受到批评。gRPC 是一种特别流行的 RPC 实现，已被 CNCF 采用。
微服务间进行通信，通常有两种方式，其一为HTTP REST-JSON的方式，另一种为RPC方式，相比起来RPC方式效率更高。常用的包括 Google开源的 GRPC 、Apache旗下的Thrift 框架、Netflix 开源的自带负载均衡的 Ribbon 和 Avra 数据序列化框架。
五、Service Proxy 服务代理
服务代理是一种工具，类似于中间人的身份。它的主要作用就行间拦截进出服务流量，收集有关网络流量的信息，并对其应用请求做一些特殊逻辑处理，最后将该流量转发到其他服务上。
这个工具既有点类似于我们日常所说的负载平衡器一样简单，也可以像与处理所有互连代理网格一样复杂。
虽然服务代理本身很有用，特别是在将流量从更广泛的网络驱动到K8S集群时，服务代理也是其他系统的构建模块，例如后面讲提到的API网关和服务网格。
解决的问题
应用程序应以受控方式发送和接收网络流量。为了跟踪流量并可能对其进行转换或重定向，我们需要收集数据。传统上，支持数据收集和网络流量管理的代码嵌入在每个应用程序中。
而服务代理，则是将此功能“外部化”。它不再必须存在于应用程序中。相反，它嵌入在应用程序运行所运行的平台层。
这样便能允许开发人员，完全专注于编写应用程序代码，同时，允许处理流量的通用任务由平台团队统一管理。在应用领域层面分工更加明确。
引入云原生的意义
代理充当用户和服务之间或不同服务之间的守护者。
凭借这种独特的定位，代理服务可以快速洞察出正在发生的通信类型，然后确定将特定请求发送到那个服务上，或者完全拒绝某个请求等。
代理服务主要收集一些关键数据，比如管理路由（在服务之间平均分配流量或在某些服务出现故障时重新路由）、加密连接和缓存内容（减少资源消耗）等。
六、API Gateway API网关
网关属于一种软件术语，如果两个相互独立的局域网之间通过路由器进行通信，那么中间的这个路由层就被称之为“网关”。
任何一个应用系统如果需要被其他系统调用，就需要暴露 API，这些 API 代表着一个一个的功能点。
如果两个系统中间通信，在系统之间加上一个中介者协助 API 的调用，这个中介者就是 API 网关。
API 网关允许组织将关键功能，比如授权或限制应用程序之间的请求数量等移动到集中管理的位置。它还用作外部API使用者的通用接口。
解决的问题
虽然大多数容器和核心应用程序都有一个 API，但 API 网关不仅仅是一个 API。API 网关简化了组织管理和应用规则到所有交互的方式。
API 网关允许开发人员编写和维护更少的自定义代码。也能够查看和控制应用程序用户与应用程序本身之间的交互等。
引入云原生的意义
API 网关位于用户和应用程序之间。它充当中间人的角色，从用户那里获取请求并将它们转发到适当的服务。但在发出请求之前，它会评估是否允许用户做他们想做的事情，并记录有关谁提出请求以及他们提出了多少请求的详细信息。
简而言之，API 网关为应用程序用户提供了一个带有通用用户界面的单一入口点。它还能够将在应用程序中实现的任务移交给网关，从而节省开发人员的时间和金钱。
七、Service Mesh 服务网格
网格服务定义了一组接口，这些接口的定义明确并遵守特定的惯例，用于解决：服务器发现、动态服务创建、服务生命周期管理、通知等与服务生命周期有关的问题。
服务网格主要用于管理服务之间的流量通信。它们使平台团队能够在集群内运行的所有服务中统一添加可靠性、可观察性和安全性功能，而无需更改任何代码。
本质上，服务网格是一个基础设施层，它通过向服务代理网络（网格）提供命令和控制信号来管理服务间通信。它的强大之处在于它能够提供关键系统功能而无需修改应用程序。
与K8S一起，服务网格已成为云原生堆栈中一些最关键的基础设施组件。
解决的问题
在云原生世界中，我们正在处理多个需要通信的服务。这意味着更多的流量在本质上不可靠且通常很慢的网络上来回传输。为了应对这一系列新挑战，工程师必须实施额外的功能。在服务网格之前，必须将该功能编码到每个应用程序中。这种自定义代码经常成为应用架构变形或代码难以维护的根源，并为失败或漏洞提供了新的可能途径。
引入云原生的意义
服务网格在平台层上的所有服务中统一添加可靠性、可观察性和安全性功能，而无需触及应用程序代码。它们与任何编程语言兼容，允许开发团队专注于编写业务逻辑。
服务网格通过服务代理将集群上运行的所有服务绑定在一起，创建服务网格，因此服务网格。这些通过服务网格控制平面进行管理和控制。服务网格允许平台所有者在应用程序上执行常见操作或收集数据，而无需开发人员编写自定义逻辑。
服务网格提供了许多有用的功能，包括显示详细指标的能力、加密所有流量、限制哪些服务授权的操作、为其他工具提供额外的插件等等。有关更多详细信息，请查看 服务网格接口规范。
总结：本节内容主要介绍了容器的编排和管理的概念。从中我们也了解到了K8S与容器在整个云原生架构中的重要性。初次之外，也了解了API网格、服务代理以及服务网格这些基础层工具来如何解耦及高效管理我们的应用和请求流量。
下一节：云原生的运行环境。
关注公众号 + 输入[面试题] + 免费领取面试资料(面试大纲+面试答案)!