构建企业级云服务生态指南

构建企业级云服务生态指南—-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,底层是自己的分布式存储系统

  • iguazioQubole:自动化数据分析公司

  • SQL data warehouse:Azure SQL 数据库产品


Streaming & Messaging

生态图如下:

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

  • Kinesis是亚马逊官方的流数据处理平台,是其云计算产品的一部分
  • cloud dataflow是 google 的流处理产品
  • Apex是 apache 旗下开源的新型实时数据处理平台
  • heron 是 twitter 开源的数据处理平台,是 apache storm 的继承者
  • parkflink 支持流处理的同时也支持批处理操作,两者定位非常相似,但内部实现的差距挺大
  • 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、此外 Quayproject atomicJFrog Artifactory 也是比较著名的容器镜像服务提供商

Security & Compliance

容器安全

  • notarytuf(the update framework) 是 CNCF 旗下的两个项目,tuf 是开源的安全和验证标准,notary 是它的一个实现,notary 可以用来验证镜像的安全性,也可以用来安全地发布软件包。

  • clair:coreOS 开源的容器安全性分析工具

  • twistlock 是云原生系统的安全性平台

  • NeuVector 是网络安全分析工具

  • aqua 也是容器安全平台,提供镜像、容器、用户认证、网络流量限制等多种安全功能

  • anchore 提供了一系列容器环境安全分析、审查和扫描工具


Key Management

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

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

spiffespire 是一对的,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:专门为容器和微服务优化的监控平台
  • Nagiosgraphite 是另外两个经典的监控工具
  • 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