构建企业级云服务生态指南---CNCF云原生生态系统大览

构建企业级云服务生态指南—-CNCF云原生生态系统大览(CNCF Cloud Native Interactive Landscape)

现在企业越来越多的用容器来部署自己的服务 , 有点企业早就架构了微服务 , 有的还在慢慢转向微服务 , 而到底用什么软件来部署 , 用什么软件比较好, 大家都是一头混乱 , 因为现在市面上的软件很多 , 也很繁杂 , 一天一个样子 , 学什么 , 怎么做 , 没有一个方向 , 也没有一个大纲来管理的企业架构 , 所以呆在树林里是看到到森林的 , 一定要高屋建瓴的去学 , 整体有个框架, 有一份云原生生态系统的地图 , 所以我整理了CNCF Cloud Native Interactive Landscape , 大部分都是比较出名的软件 , 学技术的都或多或少听过 , 下面我就来汇总介绍 , 有些没有用过 , 我们就简单介绍了 , 能有个了解即可 , 到时候再学也不迟 .

下面的东西看起来多, 很难的样子 , 其实就是CNCF官网的图的介绍而已 ,而且github上有托管资料 , 花点时间了解就能搞清楚了

CNCF致力于云原生应用推广和普及 , 它在github上有个托管 , 汇总了比较流行的云原生技术 , 并加以分类 , 希望企业在构建云原生技术的时候能够有所参考 , 其github上的地址是: https://github.com/cncf/landscape

CNCF项目的成熟度分级

CNCF旗下的项目都有成熟度分级 , 包括三种

• sandbox（初级）
• incubating（孵化中）
• graduated（毕业）

现在毕业的项目有3个 , 分别是:

• Kubernetes kubernetes2018年快年底刚刚GA的 , 2019年相信很多企业就开始部署kubernetes到生产了)
• Prometheus
• Envoy

下图是CNCF官网的项目全景图

CNCF全景图说明

• 最上层是App Definition and Development,是容器平台上的应用层，类似于手机的 app store，图中分为数据库和数据分析、流处理、SCM 工具、CI/CD 和应用定义几类，每个公司根据业务需求会有不同的应用体系
• 第二层是容器编排和管理, 负责容器集群的调度、服务发现和资源管理
• 第三层是runtime 负责容器的计算、存储、网络
• 往下是基础设施和配置管理，作为容器底层的基石。容器可以运行在各种系统上，包括公有云、私有云、物理机等；容器还依赖自动化部署工具、容器镜像工具、安全工具等运维系统才能工作。
• 右边有两块：平台和观察分析。平台是指基于容器技术提供的平台级的服务，比如常见的 Paas 服务，和 Serverless 服务。观察分析是容器平台的运维，从日志和监控方面给出容器集群当前的运行情况，方便分析和 debug

下面是一一介绍:

App Definition and Development (顶层应用程序和开发工具)

是容器平台上的应用层，类似于手机的 app store，图中分为数据库和数据分析、流处理、SCM 工具、CI/CD 和应用定义几类，每个公司根据业务需求会有不同的应用体系

Database(数据库)

生态图如下:

首先是数据库类 , 除了传统的mysql等数据库类, 还出现了为这些数据库服务的其他软件 , 比如

• 数据库集群工具vitess ,
• SQL 数据库连接池工具 druid ,
• KV 数据库 redis、couchbase,
• 文档类数据库MongoDB、rethinkDB、ravenDB
• 列式关系数据库Cassandra、Hbase、vertica,
• column 数据库scylla（kvm 之父的作品，旨在成为下一代的 Cassandra 数据库）
• bigchainDB：区块链数据库
• carbondata：面向大数据平台的列数据文件存储格式，由国内的华为公司贡献给 Apache 基金会
• crate.io：基于 elasticsearch 的分布式 SQL 数据库，适用于需要快速搜索和聚合的查询场景
• MEMSQL：从名字也能看出来，这是一款内存数据库，特点自然是性能高，
• Noms：采用 git 思想的支持版本控制、fork和同步的数据库
• pachyderm：旨在成为一个更现代的大数据处理平台，资源调度基于 docker 和 kubernetes，底层是自己的分布式存储系统
• iguazio 和 Qubole：自动化数据分析公司
• SQL data warehouse：Azure SQL 数据库产品

Streaming & Messaging

生态图如下:

海量数据的实时采集、计算和查询 , 需要流处理与批处理对应 , 用来尽可能快得对数据进行分析，从而做出决策

• Kinesis是亚马逊官方的流数据处理平台，是其云计算产品的一部分
• cloud dataflow是 google 的流处理产品
• Apex是 apache 旗下开源的新型实时数据处理平台
• heron 是 twitter 开源的数据处理平台，是 apache storm 的继承者
• park 和 flink 支持流处理的同时也支持批处理操作，两者定位非常相似，但内部实现的差距挺大
• pulsar是比kafka和Flink更优秀的设计 , 是下一代数据处理的新星 , 而且早早就获得了apache的顶级支持 , 更是在2018击败了kafka , 成了一颗冉冉的新星

Image Build

生态图如下:

容器构建从而实现应用自动化运行在任何地方

• apache brooklyn：应用管理平台，可以通过简单的操作把应用部署到常用的云平台
• docker compose：定义多个容器的运行关系，docker compose 可以自动化管理这些容器的构建、生命周期、和网络连通等问题
• habitat：应用自动化管理平台，可以定义应用，并且提供 Supervisor 来保证应用的正确运行
• kubeVirt：用于 kubernetes 的虚拟机运行时标准接口
• Packer：通过一个 yaml 文件，生成各种虚拟化平台的镜像
• OPEN API：标准化的 API 接口，规范化应用和服务之间的调用

Continuous Integration & Delivery(CI/CD)

生态图如下:

持续集成和持续部署主要用于自动化地处理所有的 ops 的工作，包括从代码提交一直到应用部署到线上的整个过程的自动化。CI 侧重于构建和测试，CD 侧重于部署

• jenkins 算是这个领域的翘楚，非常经典的一款软件，功能强大稳定，拥有很丰富的插件，算是开源界使用比较广泛的工具
• travis CI 为开源的 github 项目免费，对私有项目收费，因此很多 github 上项目能看到它的身影
• circleCI、 codeship、shippable、semaphore 都是 PaaS 产品，提供在线的 CI、CD 服务，一般提供免费和企业收费两种版本
• Bamboo 是 Atlassian 公司（开发了著名的 jira 和 confluence）旗下的产品，当然也是商业化的，需要付费才能使用
• drone：原生支持 docker 的 CI 开源产品，使用 go 编写，整个工作流都是基于 docker 的，最终也会自动化构建 docker 镜像，push 到 registry 上
• gitlab runner：gitlab 提供的 CI 工具，gitlab CI 和 gitlab runner 一起工作，前者做控制，后者实际执行任务
• spinnaker：开源的 CI 软件，可以在多个云平台运行构建和部署过程

Orchestration & Management（编排和管理）

当业务越来越复杂的时候, 容器在主机上也多了起来 , 这个时候需要有个工具能够提供资源管理、容器调度和服务发现等功能，保证多主机容器能够正常工作

Scheduling & Orchestration(调度和编排)

调度和集群管理一直是容器技术的热点领域，竞争也非常激烈。由于容器引擎已经有了标准化 , 非docker一家独占了 , 容器引擎终归是个可替换的部件 , 如何编排这些容器才是关键

集群管理竞争很激烈 , 目前来说 google 公司的 kubernetes 处于绝对的领先状态，也是目前社区发展最快的平台，随着 docker 官方支持 kubernetes，以及 azure 和 aws 。目前社区三个主流的容器调度平台是：

• kubernetes：起源于 google 内部的 Borg 系统，率先提出 pod 的概念，提供自动化管理、服务发现、服务升级、有状态服务等等特性
• docker swarm：docker 公司官方的容器管理平台，最大的特点是和 docker 兼容的 API 和操作命令
• mesos：apache 旗下的任务调度平台，后来应用于容器调度

对于公有云上的容器服务，各大云服务商也有对应的产品：

• Amazon ECS：亚马逊推出的容器服务，特点是虚拟机收费，容器免费
• Azure Service Fabric：微软 Azure 的容器服务调度平台
• Nomad：hashicorp 旗下的数据中心调度平台，同时支持服务和任务两种 Job，也已经支持 docker 容器
• Google Cloud , google自家推出的云平台 ,各种资源也倾向于它

Coordination & Service Discovery(集群状态存储和服务发现)

有了容器管理工具 , 主机上的容器服务越来越多 , 遇到的一个问题就是这么让这些容器互相发现对方 , 做服务发现, 因为容器是不断变化的 , 不停的创建和销毁 , ip也在变 . 如何能够保存这些集群状态, 并保证不会发生错误和冲突

生态图如下:

集群的状态会保存在一个分布式键值存储系统中 , 保证数据的一致性 , 目前来说流行三款:

• Zookeeper：Hadoop 的一个子项目，本来是作为 Hadoop 集群管理的数据存储，目前也被应用到容器领域，开发语言是 Java。一个缺点是使用和维护比较复杂
• Consul：HashiCorp 开发的分布式服务发现和配置管理工具，docker swarm 集群之前默认使用的就是这个
• Etcd：CoreOS 旗下的键值存储工具，是 kubernetes 默认的选择，因此使用范围很广

有了分布式键值存储保证一致性，还需要工具把集群数据自动写入到里面，并且需要格式化地读取和解析数据 . 工具有：

• Registrator：自动监控 docker 容器，把每个容器的信息（IP、端口等）写入到键值存储中，支持 etcd、Consul
• SkyDNS：基于 etcd 中的数据，对外提供 DNS 数据查询，是对 etcd 的一层封装。因为使用 etcd，所以 DNS 查询是实时的，避免了缓存导致的问题
• CoreDNS：SkyDNS 继承者，主要特点是插件系统能完成各种各样的功能
• ContainerPilot：Joyent 开源的容器服务发现工具，作为容器的 init 系统运行，通过定义一个 json 文件，它会把容器相关的信息更新到 consul 中、进行健康检查、运行用户定义的代码等

除外，还有两个公司开源的服务发现工具要提一下：

• SmartStack：Airbnb 开源的服务发现工具，由 nerve 和 synapse 组成，安装和运维相对复杂了些
• netflix OSS Eureka：netflix 开源的用于 AWS 的服务发现工具

总的来说，这些工具保证这个集群的动态信息能统一保存，并保证一致性，这样每个节点和容器就能正确地获取到集群当前的信息。

Service Proxy (服务代理)

对于负载均衡来说，HAProxy、nginx 和 F5 都是常用的方案，Traefik 是后起之秀，专门为微服务设计；RPC 框架用来在微服务内部进行通信，因为比 HTTP API 效率高而被大量使用，常用的用 Google 开源的 GRPC 、apache 旗下的 thrift 框架、Netflix 开源的自带负载均衡的 ribbon 和 avra 数据序列化框架

API Gateway(API 代理)

微服务 gateway 是统一化管理 API 注册接入、权限认证、限速、日志等功能，是微服务对外的接口。

• Kong：Mashape 开源的项目，基于 openrestry（Nginx + Lua） 的微服务网关，以插件为中心组织功能
• Netflix Zuul：Netflix 微服务网关，使用 Java 开发，因此适用于 Java 应用，需要添加代码来使用 Zuul 提供的功能
• Nginx：Nginx Plus 产品为企业提供负载均衡、代理、微服务网关的各种功能
• 3scale：红帽公司的 API 网关工具

这个领域也有一些公司在提供产品，比如 datawire 就专门为 kubernetes 应用提供 API gateway 和自动化源码部署的工具。

微服务开发框架 Hystrix 是 Netflix 开源的项目，能够帮助程序处理微服务交互的超时处理和容错的问题，提供熔断、隔离、降级等功能，但是只能用于 Java 语言项目，需要在程序中修改代码。

Service Mesh

是把微服务通用的功能单独抽象为一层，部署在容器管理平台中，对应用透明，并且通过简单自动化的接口来控制整个微服务的连通、灰度访问、升级、降级等功能

• linkerd：开源的网络代理服务，使用 scala 语言编写，最早提出了 service mesh 的概念
• envoy：C++ 编写的网络代理工具，和 linkerd 的定位相同，turbine labs 公司专门提供 envoy 的部署和管理工作
• Istio：Google、IBM 和 Lyft 联合发布的微服务管理、配置和监控框架，使用 envoy 或者 linkerd 作为内部 worker，控制层面负责配置和管理，深度集成到 kubernetes 平台

service mesh 相较于之前微服务框架的最大优势是它对业务是透明的，不需要像 Netflix 提供的很多微服务工具那样对应用有侵入性，因此就不再和任何语言绑定，可以看做整个网络栈的另一个抽象层。

Runtime (运行时)

容器运行时这块是容器核心的技术，关注的是主机容器的技术模块，分为计算、存储、网络三块。

Cloud-Native Storage (网络存储)

因为容器存活时间很短的特点，容器的状态（存储的数据）必须独立于容器的生命周期，也因为此，容器的存储变得非常重要 , 下面是几种

• Ceph：分布式存储系统，同时支持块存储、文件存储和对象存储，发展时间很久，稳定性也得到了验证。之前在 openstack 社区被广泛使用，目前在容器社区也是很好的选项。
• GlusterFS：RedHat 旗下的产品，部署简单，扩展性强，
• Hadoop HDFS：Apache 基金会下的开源文件系统项目，在大数据领域广泛使用，基于 GFS 理念的开源版本。主节点保存元数据，并负责数据分布、复制、备份决策，工作节点存储数据，每个数据会有多个副本，保存在不同的工作节点
• SheepDog：起源于日本的块存储开源项目，设计之初是为了用于虚拟化平台 QEMU
• Swift：openstack 项目提供的对象存储工具
• LeoFS：高可用、分布式的对象存储系统，海量数据支持比较好，提供 HTTP、S3、NFS 等接口访问
• minio：开源的对象存储软件，提供和 AWS S3 兼容的接口，简单易用

除了这些开源的存储技术之外，还有很多容器存储圈的技术公司：

• DELL EMC：商业存储的典范，提供企业级各种需求的存储解决方案，作为商业存储的大哥，自然也会在容器存储上发力
• NetApp：致力于混合云的存储方案，是一家老牌的公司，在存储行业深耕多年
• Datera：一家存储创业公司，主要产品是 EDF(Elastic Data Fabric)，提供 API 优先的企业级存储方案，有纯软件和一体机两种不同的版本
• Diamanti：Diamanti 一家超融合基础设施初创公司，主要为企业数据中心提供基于容器的硬件及软件支持服务
• Hedvig：为私有云和混合云提供统一的数据存储服务，为虚拟机和容器提供软件定义存储
• Infinit：开源的软件定义存储公司，之前是做文件跨平台传输的。产品也是统一的存储平台，为各种计算平台提供块存储、对象存储和文件存储等接口。已经被 docker 收购
• Pure Storage：一家明星存储创业公司，最大的特定是对闪存的支持
• StorageOS：为容器提供分布式存储的统一视图，对上层提供 API 实现存储的自动化管理，作为容器部署。产品也分为免费版和收费版
• Quobyte：数据中心文件系统，被 kubernetes volume 插件直接支持

因为不同用户对存储需求不同，采取的存储方案也不同，不管是开源方案、商业方案还是自研方案，或者是文件存储、对象存储还是块存储，怎么把这些技术用到容器平台，以及保证标准化和统一化的接口，是非常有挑战性的事情，目前也有很多努力：

• CSI（Container Storage Interface）：定义云应用调度平台和各种存储服务接口的项目，核心的目标就是存储 provider 只需要编写一个 driver，就能集成到任何的容器平台上
• libStorage：EMC 旗下研发的一个存储开发框架，旨在开发与容器平台无关的存储框架，大致的思想是 libstorage 来处理和容器平台的交互，存储框架只需要接入到该框架就行
• REX-Ray：基于 libStorage 实现的存储管理平台，支持大部分的存储提供商，也能运行在大多数操作系统上
• openSDS：开放的软件定义存储标准，集合各大存储厂商，提供统一管理的存储标准，隶属于 Linux 基金会
• rook：基于 ceph 作为后台存储技术，深度集成到 kubernetes 容器平台的容器项目，因为选择了 ceph 和 kubernetes 这两个都很热门的技术，并且提供自动部署、管理、扩展、升级、迁移、灾备和监控等功能，所以很受关注
• portworx：针对容器技术打造的，把每个节点的存储资源组成一个存储池，每个数据自动进行备份，并通过和容器平台调度深度集成保证数据高可用。分为免费版和商业版

Container Runtime(容器运行时)

严格来说其实容器技术早在Linux的时候就有了 , 之后docker一家独大 , 有垄断之势 , 而且还推出了收费版, 社区反对激烈, 后来google等公司为了对抗 , 推出了rkt , 在一番激烈角逐后, docker公司退缩 , 愿意和google等公司联合推出标准 , 成立了OCI（Open Container Initiative）

OCI（Open Container Initiative）是一个促进容器标准化的组织，主要工作是容器 runtime 和镜像的标准化协议

• containerd：docker 公司从原来的 docker 引擎中剥离出来的容器核心功能，具有镜像管理和容器隔离两大功能，底层使用 runc
• rkt：CoreOS 公司提出的容器引擎技术，一直作为 docker 的直接竞争对手存在，对于促进容器标准化贡献很大
• lxd：基于 linux 老牌容器管理工具 lxc，旨在提供更好用的接口，最大的特色是使用容器技术提供类似虚拟机的服务
• runv：以兼容 OCI 接口的方式管理虚拟机，支持 kvm、Xen、QEMU 等虚拟化技术。换句话说，可以直接把虚拟机作为 runtime 运行在容器集群管理平台上
• Intel Clear Containers：Intel 公司推出的容器技术
• CRI-O 是 kubernetes 推出的东西，它是 kubelet 和 OCI runtime 之间的桥梁，它内部采用 OCI 标准，因此可以兼容各种 runtime（比如 runc、Clear Container等），对上它提供 CRI 接口供 kubelet 调用。这样的话，CRI-O 的存在能够让 kubelet 使用任何 OCI 兼容的 runtime，从而绕过 docker、rkt 这种完整容器管理工具。

Cloud-Native Network (云原生网络)

网络最重要的功能是提供不同计算资源的连通，随着虚拟化和容器技术的发展，传统的网络方案已经无法满足云计算快速增长、不断变化的网络需求。不同用户对网络的要求也越来越高：

• 安全性：保证私有和公有云网络的安全，网络流量能够加密，不被窃听和修改
• 多租户：云计算需要同时为多个租户提供网络服务，不同租户之间互相独立而且隔离
• 快速响应：容器的生命周期大大缩短，集群的网络在实时动态变化，网络方案需要感知网络的变化，并快速提供服务
• 网络迁移：虚拟机和容器会在集群上迁移和调度，网络方案需要支持计算资源跨主机迁移后的连通
• 监控和调试：云上的网络环境，让整个网络的流量变得更加复杂，我们需要新的工具让网络可视化，并做到自动化运维
• ……

因此，在云计算和容器这块涌现出很多网络解决方案和厂商，试图解决这些问题：

• cni（Container Network Interface）：kubernetes 和 CoreOS 提出的容器网络接口标准，旨在为容器平台提供统一的网络访问模式，目前很多网络方案都已经集成进来
• calico：基于 BGP 的纯三层网络方案，性能很高，并且提供强大的网络防火墙功能，以满足用户对安全性的需求
• canal：基于 flannel 和 calico 提供 kubernetes pod 之间网络防火墙的项目
• contiv：思科推出的网络方案，支持 vxlan 和 vlan 方案，提供了多租户和主机访问控制策略功能
• cilium：利用 Linux 原生技术提供的网络方案，支持 L7 和 L3、L4 层的访问策略
• flannel：CoreOS 主要的容器网络项目，主要用于 kubernetes 平台提供 pod 之间的连通性，提供多种连网方案，部署和管理简单
• midokura：日本 SDN 网络公司，主要产品是开源的 MidoNet，之前广泛用于 openstack 中，目前有很多把它应用到容器领域的尝试
• openContrail：Juniper 收购的开源网络虚拟化平台，目前已经加入 linux 基金会。OpenContrail 是一个可扩展的网络虚拟化控制层，提供了丰富的软件定义网络功能和安全性
• Open vSwitch：linux 平台的虚拟交换机软件，除了提供和 Linux 虚拟网桥类似功能外，还支持 openflow 协议
• weave net：Weaveworks 公司开源的 docker 跨主机网络方案，安装和使用都比较简单，内部也是通过 overlay 网络实现的
• romana：Panic Networks 推出的网络开源方案，基于 L3 实现的网络连通，因此没有 overlay 网络带来的性能损耗，但是只能通过 IP 网段规划来实现租户划分，不够灵活
• tigera：网络方案初创公司，主推的方案是把 flannel 和 calico 集成到一起的 canal，应用Calico的网络策略到 Flannel 中

也有很多的商业公司为企业提供网络解决方案：

• aviatrix：混合云网络解决方案提供商，集成 AWS、Azure、Google 等公有云网络，在同一平台管理公司混合云网络
• Big Switch：下一代数据中心网络公司，提供 SDN 可编程的网络方案，主要有 Big Cloud Fabric 和 Big Monitoring Fabric 两种产品方案
• vmware NSX：虚拟化厂商 vmware 提供虚拟化网络方案
• cumulus：主要产品是 cumulus 操作系统，继承了众多的网络软件，提供丰富的网络功能。能够解除数据中心网络设备硬件和软件锁定的局面，为网络硬件带来软件的灵活特性
• nuagenetworks：致力于数据中心 SDN 网络的公司，提供解决方案

Provisioning（部署）

有了物理机和虚拟机，在运行容器服务之前，我们还需要为容器准备标准化的基础环境，以及保证基础设施的自动化，Iaas 和这部分共同组成了容器平台的地基

Automation & Configuration

自动化配置工具，保证容器运行的系统配置的一致性，并提供升级、补丁等功能，一般也可以用来 bootstrap 容器服务

• ansible 比较简洁，用 ssh 来自动化部署，使用 python 编写
• cfEngine 是这个领域非常老的工具，可以说是配置管理的元老，用 C 编写，因此性能会更好，但是学习曲线也更曲折
• chef 用 ruby 编写，而且配置文件格式也是 ruby DSL，因此对于 ruby 程序员非常亲切友好
• saltstack采用 zeroMQ 作为消息队列，实现 master-salve 模式，兼具性能和灵活性，但同时整个系统也更加复杂
• puppet 是这个领域的老大哥，以成熟稳定著称，社区文档也更丰富
• Bosh：CloudFoundry 旗下的产品
• Cloudify：云应用编排系统，能够让用户定义软件，然后部署到不同的云环境中
• CloudFormation：AWS 提供的基础配置服务，能够通过配置文件定义要创建的各种 AWS 服务，然后一键完成集群或者系统的搭建
• Ubuntu Juju：Ubuntu 提供的管理工具，能够自动化把几百种服务部署到不同的平台
• Terraform：HashiCorp 旗下的基础设施配置工具，通过定义一份配置文件，Terraform 能够在不同云提供商运行服务，是 Infrastructure as Code 的信奉者
• Manage IQ：统一管理云主机、容器、网络、存储的 IT 平台
• kubicorn：管理多个 kubernetes 集群的工具，集群可以在不同的云上
• Helm：kubernetes 软件包安装工具，能够安装多个 kubernetes 资源，类似于 ubuntu 的 apt 工具

Container Registries

容器仓库是容器平台的基础, 用来存放镜像 , 有许多厂商提供了仓库 , 不过国内公司都是喜欢自建仓库

• Harbor 是开源的企业级容器镜像管理平台
• Portus 专门为 Docker registry 提供授权服务
• registry docker 官方的镜像仓库
• ECR（Elastic Container Registry） 是亚马逊的, Azure 和 Google 云 registry、此外 Quay、project atomic、JFrog Artifactory 也是比较著名的容器镜像服务提供商

Security & Compliance

容器安全

• notary 和 tuf（the update framework） 是 CNCF 旗下的两个项目，tuf 是开源的安全和验证标准，notary 是它的一个实现，notary 可以用来验证镜像的安全性，也可以用来安全地发布软件包。
• clair：coreOS 开源的容器安全性分析工具
• twistlock 是云原生系统的安全性平台
• NeuVector 是网络安全分析工具
• aqua 也是容器安全平台，提供镜像、容器、用户认证、网络流量限制等多种安全功能
• anchore 提供了一系列容器环境安全分析、审查和扫描工具

Key Management

和安全相关的另一个问题是机密信息，包括密码数据、密钥等。

Keywhiz、pinterest 开源的 knox、lyft 开源的密码存储工具 confidant 和 HashiCorp 开源的 vault想要解决机密信息的存储，它们通过加密的方式把内容保存到后端存储中，而且提供了 auditing 等额外功能。

spiffe 和 spire 是一对的，spiffe 定义了服务的认证标准和认证信息的标准，spire 是它的一个实现，但是目前还没有达到生产可用。

Public

公有云提供商 , 如下图:

Platform（平台）

Certified Kubernetes - Distribution

其中数rancher最为活跃和强大 , 可以直接创建kubernetes集群, 相当于要自己部署复杂的kubernetes , rancher显然是更简单一点, 而且集成了许多功能 , 目前稳定版已经2.0 , openshift是redhat旗下的 ,而且国内大厂也有许多做的 , 比如阿里, 京东 , 华为, 七牛云等

Hosted

有许多云厂商也提供kubernetes等云原生的支持 , 详细看下面图片:

Installer

PaaS/Container Service

flynn 是基于 docker 容器技术的开源 PaaS 软件 ,hyper.sh 以容器接口来提供虚拟机服务

Observability & Analysis（观察和分析）

平台建立以来,我们还得知道服务运行的情况, 需要监控服务的状态 , 提早发现问题, 便于出现问题可以排查问题

Monitoring(监控)

监控一般都是监控主机的cpu , 内存 ,硬盘 , io等等 , 容器的出现, 就有涌现了许多监控容器的健康状态的

• zabbix 是老牌的监控工具，功能强大
• Prometheus：时序数据库，提供了工具能读取 HTTP 接口暴露的数据保存起来，提供了丰富的查询接口以及一个 web 界面
• coscale：专门为容器和微服务优化的监控平台
• Nagios 和 graphite 是另外两个经典的监控工具
• datadag也是非常好的监控工具 , 监控网络状态主机信息等
• sensu是新兴的监控工具
• grafana是图形化的监控工具 , 能够用图表表达
• influxdb 和 openTSDB 都是时序数据库，后者是基于 HBase 的。
• AWS CloudWatch 是AWS 自家的监控工具，当然是负责 AWS 云上的服务监控
• Azure Log Analytics 是微软家日志监控工具
• sentry：业务日志监控工具 , 错误收集工具，能够集中式地查看应用的 crash report 和 traceback 信息
• server density：专注于服务监控的 SaaS 服务平台
• statsD：etsy 开源的数据统计信息，可以把数据继续发到后端的监控平台，比如 graphite
• sysdig：容器和 kubernetes 监控工具，同时提供了付费的监控服务

Logging

日志可以提供监控功能 , 也能进行错误调试 , 便于找出错误

• fluented 是一个开源的基于数据流（stream）的日志收集框架
• graylog 是另外一个开源的选择，它们的思想都是把日志从系统各处收集起来进行统一分析、过滤和管理
• elastic 提供 ELK（Elasticsearch、Logstash、Kibana） 技术栈负责日志收集，也提供在线的企业级 Saas 服务。
• loggly 是一个在线的日志分析服务，需要付费使用
• logz.io 提供管理的 ELK 在线服务，提供 ELK as a service，并且可以基于 AI 对数据进行分析；另外一家声称支持 AI 分析的日志服务公司是 loom systems
• splunk 这家公司也提供日志分析服务
• papertrail、sematext、sumologic 也都提供类似的日志分析服务。

Tracing(服务调用追踪)

对于微服务来说，我们需要知道一个请求到底经过了哪些组件，每个组件耗费了多少时间，错误发生在中间的哪个步骤，每次调用的网络延迟是多少等等。对于使用不同语言、开发框架、数据库、和系统的微服务，我们需要有统一的跟踪标准，这就是 tracing 要做的事情。分布式的 tracing，一般都受到 google Daper 系统的设计影响

这些 tracing 工具都需要在应用中编写对应的代码，和 logging 和 metrics 类似，用户可以自定义要 tracing 代码块的范围和父子关系。此外，也有很多工具会自动化嵌入服务组件之间的 tracing 数据，比如之前讲过的 Istio。

tracing 可以和 metrics 结合一起使用，tracing 负责组件和微服务之间的数据分析，metrics 负责单个组件内的性能数据监控

• opentracing是一个开放的 tracing 接口标准和文档，提供了各种语言客户端的实现
• jaeger是Uber开源的分布式追踪系统 , 有着图形化的web界面 , 多用在kubernetes中 , 后端也用cassandra和ES等存储数据
• Zipkin是根据Google Dapper的论文设计的全链路监控系统，由Twitter公司开发。 Zipkin 以Trace 结构表示对一次请求的追踪，又把每个Trace 拆分为若干个有依赖关系的Span
• Spring Cloud为开发者提供了在分布式系统(如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、全局锁、决策竞选、分布式会话和集群状态)操作的开发工具。使用SpringCloud开发者可以快速实现上述这些模式

Chaos Engineering

serverless

Tools(工具)

Framework (框架)

Platform

Hosted Platform

Installable Platform

Security