gRPC与云原生应用开发 云原生开源项目

android原生开源项目

随着使用容器开发应用程序的实践变得越来越流行， 云原生应用程序也在不断增长。 根据定义 ：

“云原生技术用于开发使用打包在容器中的服务构建的应用程序，将其部署为微服务，并通过敏捷的DevOps流程和连续交付工作流在弹性基础架构上进行管理。”

该描述包括四个对于云原生应用程序必不可少的元素：

1. 容器
2. 微服务
3. 开发运维
4. 持续集成和持续交付（CI / CD）

尽管这些技术有着截然不同的历史，但它们可以很好地互补，并且在短时间内导致了云原生应用程序和工具集的惊人增长。 此Cloud Native Computing Foundation （CNCF）信息图显示了当今云原生应用程序生态系统的规模和广度。

^{云原生计算基金会项目}

我的意思是，看看那！ 这仅仅是一个开始。 就像NodeJS的发明引发了无休止JavaScript工具的爆炸式增长一样，容器技术的普及也推动了云原生应用程序的指数级增长。

好消息是，有几个组织负责监督这些点并将它们连接在一起。 一个就是开放容器倡议（OCI） ，它是一个轻量级的，开放的治理结构（或项目），“是在Linux基金会的主持下成立的，其明确目的是围绕容器格式和运行时创建开放的行业标准。” 另一个是CNCF ，“致力于使云原生计算具有通用性和可持续性的开源软件基金会”。

除了通常围绕云原生应用程序构建社区之外，CNCF还帮助项目围绕其云原生应用程序建立结构化治理。 CNCF创建了成熟度级别的概念（沙盒，孵化或分级），与下图中的“创新者”，“早期采用者”和“早期多数”层相对应。

^{CNCF项目成熟度级别}

CNCF对每个成熟度级别都有详细的标准 （为方便读者，以下包括在内）。 要孵化或毕业的项目需要技术监督委员会（TOC）的三分之二多数。

沙箱舞台

要在沙盒中被接受，一个项目必须至少有两个TOC赞助商。 有关详细过程，请参见《 CNCF沙箱指南v1.0》。

孵化阶段

注意：孵化水平是我们期望对项目进行全面尽职调查的起点。

要被接受进入孵化阶段，项目必须满足沙盒阶段的要求，再加上：

• 证明至少有三个独立的最终用户已成功将其用于生产，根据TOC的判断，这些最终用户具有足够的质量和范围。
• 健康的提交者数量。 提交者定义为具有提交位的人。 即，可以接受对部分或全部项目的贡献的人。
• 展示大量正在进行的提交和合并的贡献。
• 由于这些指标可能会根据项目的类型，范围和大小而有很大差异，因此，TOC对足以满足这些条件的活动级别拥有最终判断权

毕业阶段

要从沙盒或孵化状态毕业，或者要使一个新项目作为已毕业的项目加入，项目必须满足孵化阶段的标准，再加上：

• 至少有两个组织的提交者。
• 已获得并维护了“核心基础设施计划最佳实践徽章”。
• 已经完成了独立的第三方安全审核，并发布了与以下示例类似的范围和质量的结果（包括已解决的关键漏洞）： https : //github.com/envoyproxy/envoy#security-audit，并且所有关键漏洞都必须在毕业前解决。
• 通过《 CNCF行为准则》。
• 明确定义项目治理和提交者过程。 最好将其布置在GOVERNANCE.md文件中，并引用OWNERS.md文件，其中显示了当前提交者和荣誉提交者。
• 至少有一个主要回购的项目采用者的公共列表（例如，ADOPTERS.md或项目网站上的徽标）。
• 获得TOC的多数票，进入毕业阶段。 如果项目能够证明足够的成熟度，则可以尝试直接从沙箱迁移到毕业。 项目可以无限期保持孵化状态，但是通常预计它们会在两年内毕业。

要考虑的9个项目

尽管不可能涵盖本文中的所有CNCF项目，但我将描述最有趣的9个“毕业和孵化”开源项目。

名称	执照	这是什么
Kubernetes	阿帕奇2.0	容器编排平台
Prometheus	阿帕奇2.0	系统和服务监控工具
Envoy	阿帕奇2.0	边缘和服务代理
rkt	阿帕奇2.0	本地容器引擎
Jaeger	阿帕奇2.0	分布式跟踪系统
Linkerd	阿帕奇2.0	透明服务网
Helm	阿帕奇2.0	Kubernetes包管理器
Etcd	阿帕奇2.0	分布式键值存储
CRI-O	阿帕奇2.0	Kubernetes的轻量级运行时

我还创建了此视频教程来完成这些项目。

毕业项目

被许多组织采用的已毕业项目被认为是成熟的，并且必须遵守CNCF的准则。 以下是三个最受欢迎的开源CNCF毕业项目。 （请注意，其中一些描述已从项目的网站改编并重新使用。）

Kubernetes

啊，Kubernetes。 我们如何在不提及Kubernetes的情况下谈论云原生应用程序？ Kubernetes无疑是Google发明的，它是最著名的基于容器的应用程序的容器编排平台，它还是一个开源工具。

什么是容器编排平台？ 基本上，一个容器引擎本身可以管理几个容器。 但是，当您谈论数千个容器和数百个服务时，管理这些容器变得非常复杂。 这就是容器引擎的用武之地。容器编排引擎通过自动化容器的部署，管理，网络和可用性来帮助扩展容器。

Docker Swarm和Mesosphere Marathon是其他容器编排引擎，但可以肯定地说Kubernetes赢得了比赛（至少现在是这样）。 Kubernetes还诞生了诸如OKD之类的容器即服务（CaaS）平台，该平台是为Red Hat OpenShift提供支持的Kubernetes的Origin社区发行版。

首先，请访问Kubernetes GitHub存储库 ，并从Kubernetes文档页面访问其文档和学习资源。

普罗米修斯

Prometheus是2012年在SoundCloud上构建的一个开源系统监视和警报工具包。此后，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。 现在，它是一个独立于公司的独立开源项目。

^{普罗米修斯的建筑}

考虑Prometheus的最简单方法是可视化一个生产系统，该系统每年需要一天24小时，每天365天都可以正常运行。 没有一个系统是完美的，并且有减少故障的技术（称为容错系统）。 但是，如果发生问题，最重要的是尽快识别它。 这就是像Prometheus这样的监视工具派上用场的地方。 Prometheus不仅仅是容器监视工具，而且在云原生应用程序公司中最受欢迎。 此外，包括Grafana在内的其他开源监视工具也使用Prometheus。

开始使用Prometheus的最佳方法是查看其GitHub存储库 。 在本地运行Prometheus很容易，但是您需要安装容器引擎。 您可以访问Prometheus网站上的详细文档。

使者

Envoy（或Envoy代理）是专为云原生应用程序设计的开源边缘和服务代理。 Envoy由Lyft创建，是为单一服务和应用程序而设计的高性能C ++分布式代理，以及为大型微服务服务网格体系结构而设计的通信总线和通用数据平面。 基于对Nginx，HAProxy，硬件负载平衡器和云负载平衡器等解决方案的了解，Envoy与每个应用程序一起运行，并通过与平台无关的方式提供通用功能来抽象化网络。

当基础架构中的所有服务流量都流经Envoy网格时，可以通过一致的可观察性可视化问题区域，调整整体性能，并在单个位置添加基板功能，变得很容易。 基本上，Envoy代理是一种服务网格工具，可帮助组织为生产环境构建容错系统。

服务网格应用程序有很多替代方案，例如Uber的Linkerd （在下面讨论）和Istio 。 Istio通过部署为Sidecar并利用Mixer配置模型来扩展Envoy Proxy。 特使的主要功能是：

• 包括所有“桌面赌注”功能（与控制平面（例如Istio）配对时）
• 在负载下运行时，比例延迟低至99％
• 充当L3 / L4过滤器的核心，提供许多开箱即用的L7过滤器
• 支持gRPC和HTTP / 2（上游/下游）
• 它由API驱动，并支持动态配置和热重载
• 重点关注指标收集，跟踪和整体可观察性

要了解Envoy，证明其功能并实现其全部利益，就需要在运行生产级环境方面拥有丰富的经验。 您可以在其详细文档和访问其GitHub存储库中了解更多信息。

孵化项目

以下是六个最受欢迎的开源CNCF孵化项目。

t

rkt，发音为“ rocket”，是Pod原生容器引擎。 它具有用于在Linux上运行容器的命令行界面（CLI）。 从某种意义上说，它类似于Podman ，Docker和CRI-O等其他容器。

rkt最初是由CoreOS（后来被Red Hat收购）开发的，您可以在其网站上找到详细的文档 ，并在GitHub上访问源代码。

积家

Jaeger是面向云原生应用程序的开源，端到端分布式跟踪系统。 在某种程度上，它是像Prometheus这样的监视解决方案。 但它有所不同，因为其用例扩展到：

• 分布式交易监控
• 性能和延迟优化
• 根本原因分析
• 服务依赖性分析
• 分布式上下文传播

Jaeger是Uber建立的开放原始码技术。 您可以在其网站上找到详细的文档 ，并在GitHub上找到其源代码 。

Linkerd

像Lyft和Envoy Proxy一样，Uber开发了Linkerd作为开源解决方案，以将其服务维持在生产级别。 在某些方面，Linkerd就像Envoy，因为两者都是服务网格工具，旨在提供平台范围的可观察性，可靠性和安全性，而无需进行配置或代码更改。

但是，两者之间存在一些细微的差异。 尽管Envoy和Linkerd充当代理并可以报告所连接的服务，但是Envoy并不像Linkerd那样被设计为Kubernetes Ingress控制器。 Linkerd的显着功能包括：

• 支持多种平台（Docker，Kubernetes，DC / OS，Amazon ECS或任何独立计算机）
• 内置服务发现抽象以联合多个系统
• 支持gRPC，HTTP / 2和HTTP / 1.x请求以及所有TCP流量

您可以在Linkerd的网站上阅读有关它的更多信息，并在GitHub上访问其源代码。

舵

Helm基本上是Kubernetes的软件包经理。 如果您使用过Apache Maven，Maven Nexus或类似的服务，您将了解Helm的用途。 Helm可帮助您管理Kubernetes应用程序。 它使用“头盔图”来定义，安装和升级最复杂的Kubernetes应用程序。 头盔不是唯一的方法。 另一个流行的概念是Kubernetes运算符 ，它由Red Hat OpenShift 4使用。

您可以按照其文档中的快速入门指南或GitHub指南来尝试Helm。

等

Etcd是用于分布式系统中最关键数据的分布式，可靠的键值存储。 其主要特点是：

• 定义明确，面向用户的API（gRPC）
• 具有可选客户端证书身份验证的自动TLS
• 速度（基准为每秒10,000次写入）
• 可靠性（使用Raft分发）

Etcd用作Kubernetes和许多其他技术的内置默认数据存储。 也就是说，它很少独立运行或作为单独的服务运行； 相反，它利用了集成到Kubernetes，OKD / OpenShift或其他服务中的一个。 还有一个etcd操作员来管理其生命周期并解锁其API管理功能：

您可以在etcd的文档中了解更多信息，并在GitHub上访问其源代码 。

CRI-O

CRI-O是Kubernetes运行时接口的符合开放容器倡议（OCI）的实现。 CRI-O用于各种功能，包括：

• 使用runc（或任何OCI运行时规范实现）和OCI运行时工具的运行时
• 使用容器/图像进行图像管理
• 使用容器/存储来存储和管理图像层
• 通过容器网络接口（CNI）的网络支持

CRI-O提供了大量文档 ，包括指南，教程，文章，甚至播客，您还可以访问其GitHub页面 。

---

我是否错过了一个有趣的开源云原生项目？ 请在评论中让我知道。

翻译自: https://opensource.com/article/19/8/cloud-native-projects

android原生开源项目