结语

我们正在一步步更快地向微服务架构的世界迈进，与此同时，越来越多的开源项目涌现，以期为那些真正想要做到“云原生”的组织及个人服务。CNCF 有大量优秀却未必广为人知的项目，本文只涵盖了其中一部分，建议您也可以多了解其他的项目，为未来储备。

RKT


最后一个值得关注的项目是 rkt （也称为 Rocket ），一个容器运行时。尽管 Docker 的 containerd 运行时可能是以推广容器概念的容器为目的的运行时，但是 Docker 仍然是编排生态系统中常用的运行时，因此我们相信 RKT 在后期会变得越来越受欢迎。

两者之间的差异也是显而易见的。虽然 Docker 已经选择了在集群中打包，并由一个守护进程和通过 REST API 与保护进程通信的可执行程序组成，但是 rkt 要简单得多。它由一个简单的命令行工具组成，当给定一个镜像、一个规范格式和一个镜像发现机制时，rkt 就能运行一个容器。

使用 RKT，用户可以在配置容器运行时时避免像 systemd 这样的问题。此外，rkt 不仅可以运行 App Container format 中的镜像，还可以运行标准的 Docker 镜像。

GPRC



到目前为止，我们已经知道了如何部署、调度和了解云中的微服务。但是他们之间的交流方式是什么呢?

让我们来看看“远程程序调用（ RPC ）”。

远程程序调用的概念已经存在了一段时间了，它指的是一种模式，在这种模式中，函数被称为远程调用，通常在系统中使用，而不是基于 RESTful 服务的 CRUD 模型。

但是，gRPC 指的是谷歌实现的远程程序调用，它利用了 http/2 和协议缓冲区。与基于 jsf 的 RPC 相比，gRPC 已经被证明在数量级上更快，这使得它成为大型分布式平台的优秀选择。事实上，etcd （来自 CoreOS 的流行键值存储）和谷歌自己的 BigTable 都是 gRPC ！

OPENTRACING



值得关注的第三个项目是分布式跟踪。随着单体应用程序被分解为各种更小的服务，自然会有越来越多的数据在服务中传输，从前端传输到后端，从一个服务传输到另一个服务。但是，当一个具有各种依赖关系的公共应用程序突然出现延迟时，会发生什么情况呢？这就是分布式跟踪的由来。其核心在于，跟踪是通过不同的请求调用、线程和流程来传播元数据，并最终基于此元数据构建一个图表。

OpenTracing 是一种跟踪标准，它是为响应分布式跟踪领域长期存在的问题而创建的——即，当一个公司的堆栈可能由大量第三方软件、操作系统和自定义应用程序组成的时候，如何协调跟踪？

OpenTracing，一种标准化的跟踪程式，就是这一难题的解决方案。该项目为跨越（即定时操作）管理和进程间传播，提供了的设备 API 的标准化服务。因此，用户可以轻松地切换到跟踪库或集中式跟踪系统（如 Zipkin、Dapper 等），无须复杂的配置，免去了很多麻烦。

FLUENTD



度量只是微服务应用程序可见性难题的一个方面。集中化的日志则是另一个。

随着应用程序的数量和公司规模的增长（尤其是越来越多的服务被容器化），在一个地方收集、分析和查询结构化日志是非常重要的。

这就是 Fluentd 的初衷。Fluentd 是一个日志收集器（类似于 logstorage ），通过它可以对日志进行过滤、净化和路由到各种目的地。与其他日志收集器一样，Fluentd 可以与各种核心和第三方输入及输出插件（如 Elasticsearch 插件、S3 插件等）一起使用。

Fluentd 还具有一定的内存存储和可靠性。从多个主机到 Fluentd、接着到 Elasticsearch 集群的 rsyslog 文件的日志路径极其简洁，这一简单的例子也充分证明了使用 Fluentd 的益处所在。

LINKERD



第一个是 Linkerd，一个基于微服务的原生云应用程序的开源“服务网格（ service mesh ）”项目。

Linkerd 背后的想法是：微服务固然很好，但是只有当你有一个好方法来连接它们、形成完整的应用程序时，微服务的好处才能够体现。如若不然，你的微服务应用程序就会变成一个笨重的移动部件，它们彼此也不能很好地结合在一起。

Linkerd 是一个开源项目，旨在通过提供开发人员所说的“服务网格”来解决上述挑战。Linkerd 的服务网格提供了一个方便可靠的接口，不同的服务可以交互运行。除了通过为连接服务提供简单的方式和一致的抽象层来简化程序员的工作之外，Linkerd 还具备可伸缩性、高可用性和安全性等特点。该项目由 Buoyant 监管，于 2017 年初加入 CNCF。