2.编排管理

此层为容器平台上编排管理相关的部分，主要分为等容器编排与调度、协作与服务发现，RPC 远程调用、服务代理、API 网关与服务网格等六个方面进行展开。这一层主要是聚集了与容器的编排管理的通用的架构、工具以提供相关能力。结合 CNCF 孵化项目，可以考虑使用 Kubernetes 做相关的容器编排服务，使用 CoreDNS 和 etcd 做服务发现，使用 gRPC 做远程调用，envoy 进行服务代理，使用 LINKERD 用于构建服务网格。

而在实际的项目，显然 Kubernetes 已然是容器编排的标准选择，目前的阶段即使选择 MESOS/SWARM 等框架，实际上这些也都已经转向于支持 Kubernetes 了，可谓所向披靡，一敌难求。

另外，CoreDNS 和 etcd 也算是 Kubernetes 的标准组成部分了，但是在实际的项目中，早期的使用 ZooKeeper 进行服务发现的仍有不少，国产使用 NACOS 的也逐渐增多，另外剩余的基本都在使用 NETFLIX 的 Eureka。

而远程调用，在目前 CNCF 所给选项中 gRPC 确实是一个重要的选型。

而在服务代理方面 envoy 虽然是 CNCF 为数不多的毕业的项目之一，显然它并不能像毕业的 Kubernetes 那样有影响力，相反而言，硬件方式的 F5 是土豪们的最爱，基于 Nginx 的 OPENRESTY 或者 Nginx 本身即使很多务实的开发者的选择，HAPROXY 和 traefix 也有不少的用户再进行使用，所以在微服务的路上想要一统天下，还需要看后续的服务网格的部分。

在 API 网关部分，CNCF 没有相关的孵化中或者已毕业的项目，根据实际的使用情况务实的开发者可能会直接使用 Kong，Kong 本身也是在 Nginx 上产生的一个框架，难能可贵的是已经形成了一部分生态。

而服务网格 Service Mesh 显然是后续的重头戏，相较于孵化中的 LINKERD，显然 Istio 后来居上，俨然有成为微服务管控的集大成者之势，而在实际的项目中反而比 LINKERD 和 envoy 更具竞争性，而对于新型的微服务架构希望进行尝试的用户也有很多直接一面导向了 Istio，而 NETFLIX 的 spring cloud 相关的组件仍然继续不温不火，慢慢地错失良机。

.业务流程和管理层

一旦按照安全性和合规性标准（设置层）自动执行基础结构设置并设置了应用程序需要运行的工具（运行时层），工程师就必须弄清楚如何编排和管理其应用程序。编排和管理层处理所有容器化服务（应用程序组件）如何作为一个组进行管理。他们需要确定其他服务，相互通信并进行协调。云本机应用程序具有固有的可扩展性，它依赖于此层启用的自动化和弹性。

在这一层中，您将找到：

（1）编排和调度以部署和管理容器集群，以确保它们具有弹性，松散耦合和可伸缩性。实际上，在大多数情况下，编排工具Kubernetes就是通过管理容器和操作环境构成集群的。

（2）协调和服务发现，因此服务（应用程序组件）可以相互定位和通信。

（3）远程过程调用（RPC），一种使一个节点上的服务与通过网络连接的不同节点上的服务进行通信的技术。

（4）服务代理是放置在服务之间的中介，通过它们进行通信。代理的唯一目的是对服务通信施加更多控制，它不会对通信本身添加任何内容。这些代理对于下面提到的服务网格至关重要。

（5）API网关，一个抽象层，外部应用程序可以通过它进行通信。

（6）服务网格在某种程度上类似于API网关，它是应用程序通过其进行通信的专用基础结构层，但是它提供了策略驱动的内部服务到服务的通信。此外，它可能包括从流量加密到服务发现到应用程序可观察性的所有内容。