DNS：

A——IP地址

CName ——主机名

PTR——与A相反

SRV——DNS SRV是DNS记录中一种，用来指定服务地址。与常见的A记录、cname不同的是，SRV中除了记录服务器的地址，还记录了服务的端口，并且可以设置每个服务地址的优先级和权重。访问服务的时候，本地的DNS resolver从DNS服务器查询到一个地址列表，根据优先级和权重，从中选取一个地址作为本次请求的目标地址。

我们都知道 CAP 是 Eric Brewer 提出的分布式系统三要素：
强一致性 (Consistency)
可用性 (Availability)
分区容忍性 (Partition Tolerance)

几乎所有的服务发现和注册方案都是 CP 系统，也就是说满足了在同一个数据有多个副本的情况下，对于数据的更新操作达到最终的效果和操作一份数据是一样的，但是在出现网络分区（分区间的节点无法进行网络通信）这样的故障的时候，在节点之间恢复通信并且同步数据之前，一些节点将会无法提供服务（一些系统在节点丢失的情况下支持 stale reads ）。

服务发现之 Etcd VS Consul

值得注意的是，分布式系统中的数据分为控制数据和应用数据。使用etcd的场景默认处理的数据都是控制数据，对于应用数据，只推荐数据量很小，但是更新访问频繁的情况。

抄自这里

************************************************************************************************

网上找来找去都是zk和etcd的比较，和consul的比较很少，这个感觉还算靠谱，也在别的地方看到过对consul的吐槽，记录下

************************************************************************************************

导语

在分布式微服务架构中，一个应用可能由一组职责单一化的服务组成。这时候就需要一个注册服务的机制，注册某个服务或者某个节点是可用的，还需要一个发现服务的机制来找到哪些服务或者哪些节点还在提供服务。

在实际应用中，通常还都需要一个配置文件告诉我们一些配置信息，比如数据连接的地址，redis 的地址等等。但很多时候，我们想要动态地在不修改代码的情况下得到这些信息，并且能很好地管理它们。

有了这些需求，于是发展出了一系列的开源框架，比如 ZooKeeper, Etcd, Consul 等等。

这些框架一般会提供这样的服务：

服务注册
主机名，端口号，版本号，或者一些环境信息。

服务发现
可以让客户端拿到服务端地址。

一个分布式的通用 k/v 存储系统
基于 Paxos 算法或者 Raft 算法

领导者选举 (Leader Election)

其它一些例子：
分布式锁 (Distributed locking)
原子广播 (Atomic broadcast)
序列号 (Sequence numbers)
…

我们都知道 CAP 是 Eric Brewer 提出的分布式系统三要素：
强一致性 (Consistency)
可用性 (Availability)
分区容忍性 (Partition Tolerance)

几乎所有的服务发现和注册方案都是 CP 系统，也就是说满足了在同一个数据有多个副本的情况下，对于数据的更新操作达到最终的效果和操作一份数据是一样的，但是在出现网络分区（分区间的节点无法进行网络通信）这样的故障的时候，在节点之间恢复通信并且同步数据之前，一些节点将会无法提供服务（一些系统在节点丢失的情况下支持 stale reads ）。

ZooKeeper 作为这类框架中历史最悠久的之一，是由 Java 编写。Java 在许多方面非常伟大，然而对于这种类型的工作还是显得有些沉重，也正因为其复杂性和对新鲜事物的向往，我们第一时间就放弃了选择它。

本文将从协议和应用层来比较 Etcd 和 Consul，并最终给出了笔者的偏好。

Etcd

Etcd 是一个使用 go 语言写的分布式 k/v 存储系统。考虑到它是 coreos 公司的项目，以及在 GitHub 上的 star 数量 (9000+)，Google 著名的容器管理工具 Kuberbetes 就是基于 Etcd 的。我们最先考虑的就是它。

在介绍 Etcd 之前，我们需要了解一些基本的概念。我们知道在单台服务器单个进程中维护一个状态是很容易的，读写的时候不会产生冲突。即便在多进程或者多线程环境中，使用锁机制或者协程（coroutine）也可以让读写有序地进行。但是在分布式系统中，情况就会复杂很多，服务器可能崩溃，节点间的机器可能网络不通等等。所以一致性协议就是用来在一个集群里的多台机器中维护一个一致的状态。

很多的分布式系统都会采用 Paxos 协议，但是 Paxos 协议难以理解，并且在实际实现中差别比较大。所以 Etcd 选择了 Raft 作为它的一致性协议。Raft 是 Diego Ongaro 和 John Ousterhout 在 ‘In Search of an Understandable Consensus Algorithm’ 中提出的。它在牺牲很少可用性，达到相似功能的情况下，对 Paxos 做了很大的优化，并且比 Paxos 简单易懂很多。

它主要集中在解决两个问题：

领导者选举(Leader Election)
Raft 先通过领导选举选出一个 Leader，后续的一致性维护都由 Leader 来完成，这就简化了一致性的问题。Raft 会保证一个时间下只会有一个 Leader，并且在超过一半节点投票的情况下才会被选为 Leader。当 Leader 挂掉的时候，新的 Leader 将会被选出来。

日志复制 (Log Replication)
为了维护状态，系统会记录下来所有的操作命令日志。Leader 在收到客户端操作命令后，会追加到日志的尾部。然后 Leader 会向集群里所有其它节点发送 AppendEntries RPC 请求，每个节点都通过两阶段提交来复制命令，这保证了大部分的节点都能完成。

在实际的应用中，一般 Etcd 集群以 5 个或者 7 个为宜，可以忍受 2 个或者 3 个节点挂掉，为什么不是越多越好呢？是出于性能的考虑，因为节点多了以后，日志的复制会导致 CPU 和网络都出现瓶颈。

Etcd 的 API 比较简单，可以对一个目录或者一个 key 进行 GET，PUT，DELETE 操作，是基于 HTTP 的。Etcd 提供 watch 某个目录或者某个 key 的功能，客户端和 Etcd 集群之间保持着长连接 (long polling)。基于这个长连接，一旦数据发生改变，客户端马上就会收到通知，并且返回的结果是改变后的值和改变前的值，这一点在实际应用中会很有用（这也是后面的 Consul 的槽点之一）。

Etcd 的 watch 和在一般情况下不会漏掉任何的变更。因为 Etcd 不仅存储了当前的键值对，还存储了最近的变更记录，所以如果一个落后于当前状态的 watch 还是可以通过遍历历史变更记录来获取到所有的更新。Etcd 还支持 CompareAndSwap 这个原子操作，首先对一个 key 进行值比较，只有结果一致才会进行下一步的赋值操作。利用这个特性就像利用 x86 的 CAS 实现锁一样可以实现分布式锁。

在 Etcd 中有个 proxy 的概念，它其实是个转发服务器，启动的时候需要指定集群的地址，然后就可以转发客户端的请求到集群，它本身不存储数据。一般来说，在每个服务节点都会启动一个 proxy，所以这个 proxy 也是一个本地 proxy，这样服务节点就不需要知道 Etcd 集群的具体地址，只需要请求本地 proxy。之前提到过一个 k/v 系统还应该支持 leader election，Etcd 可以通过 TTL (time to live) key 来实现。

Consul

Consul 和 Etcd 一样也有两种节点，一种叫 client (和 Etcd 的 proxy 一样) 只负责转发请求，另一种是 server，是真正存储和处理事务的节点。

Consul 使用基于 Serf 实现的 gossip 协议来管理从属关系，失败检测，事件广播等等。gossip 协议是一个神奇的一致性协议，之所以取名叫 gossip 是因为这个协议是模拟人类中传播谣言的行为而来。要传播谣言就要有种子节点，种子节点每秒都会随机向其它节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。这个协议的神奇就在于它从设计开始就没想要信息一定要传递给所有的节点，但是随着时间的增长，在最终的某一时刻，全网会得到相同的信息。当然这个时刻可能仅仅存在于理论，永远不可达。

Consul 使用了两个不同的 gossip pool，分别叫做 LAN 和 WAN，这是因为 Consul 原生支持多数据中心。在一个数据中心内部，LAN gossip pool 包含了这个数据中心所有的节点，包括 proxy 和 servers。WAN pool 是全局唯一的，所有数据中心的 servers 都在这个 pool 中。这两个 pool 的区别就是 LAN 处理的是数据中心内部的失败检测，事件广播等等，而 WAN 关心的是跨数据中心的。除了 gossip 协议之外，Consul 还使用了 Raft 协议来进行 leader election，选出 leader 之后复制日志的过程和 Etcd 基本一致。

回到应用层面上来说，Consul 更像是一个 full stack 的解决方案，它不仅提供了一致性 k/v 存储，还封装了服务发现，健康检查，内置了 DNS server 等等。这看上去非常美好，简直可以开箱即用。于是，我们初步选定了 Consul 作为我们的服务发现和动态配置的框架。但现实往往是冰冷的，在深入研究它的 API 之后发现了比较多的坑，可能设计者有他自己的考虑。

在使用获取所有 services 的 API 的时候返回的只是所有服务的名字和 tag，如果想要每个服务的具体信息，你还需要挨个去请求。这在客户端就会十分不方便，因为在笔者看来，获取所有服务的列表以及具体信息应该是一个很常见的需求，并且请求的次数越少越好。

如果 watch 服务是否有变化，当值发生改变的时候，返回的结果居然是相当于重新读取所有 services，没有能够体现出服务信息的变化，这会导致客户端很难进行更新操作。

健康检查是 Consul 的内置功能，在注册一个服务的时候可以加上自定义的健康检查，这听上去很不错。但是如果你忘记给你某个服务加上健康检查，那它在各种 API 的返回结果中变得难以预料。
…

结语

在折腾了数天之后，最终我们决定回归 Etcd，事实证明这个决定是正确的。我们基于 Etcd 实现了稳定的服务发现和动态配置功能，当然还有一些比较细节的问题没有在文中阐述，欢迎一起探讨。

传输层安全 (TLS) 是 SSL 的继承协议。TLS 是 SSL 的升级版。其工作方式与 SSL 极为相似，都是通过加密来保护数据和信息的传输。尽管 SSL 的应用仍然非常广泛，在业内这两个术语通常可以互换使用。

隧道协议（Tunneling Protocol）是一类网络协议，它是一种数据包封装技术，它是将原始IP包（其报头包含原始发送者和最终目的地）封装在另一个数据包（称为封装的IP包）的数据净荷中进行传输。使用隧道的原因是在不兼容的网络上传输数据，或在不安全网络上提供一个安全路径。隧道协议通常（但并非总是）在一个比负载协议还高的层级，或同一层。

--------------------- 

备注：说白了，通过网络隧道技术，使隧道两端的网络组合成一个更大的内部网络。

终止协议意味着客户端使用期望的协议连接代理服务器，比如TLS或HTTP/2，然后代理服务器再去连接应用服务器、数据库服务器等，但不需要使用相同的协议，如下图所示。

https://box.kancloud.cn/2015-11-13_56455e89a4a1f.png

使用独立的服务器终止协议意味着使用多服务器架构。多服务器可能是多个物理服务器、多个虚拟服务器，或者AWS这样的云环境中的多个虚拟服务器实例。多服务器就比单服务器复杂，或者比应用服务器/数据库服务器的组合复杂。不过，多服务器架构有很多好处，而且很多流量大的网站也必须用这种架构。

配置了服务器或者虚拟服务器之后，很多事情都成为可能。新服务器可以分担其他服务器的负载，可用于负载平衡、静态文件缓存和其他用途。另外，也可以让添加和替换应用服务器或其他服务器更容易。

NGINX和NGINX Plus经常被用来终止TLS和HTTP/2协议、负载平衡。已有环境不必改动，除非要把NGINX服务器挪到前端。

Service 实现了基于 iptables 的分布式负载均衡

iptables 是 Linux 防火墙工作在用户空间的管理工具，是 netfilter/iptables IP 信息包过滤系统是一部分，用来设置、维护和检查 Linux 内核的 IP 数据包过滤规则。

iptables 可以检测、修改、转发、重定向和丢弃 IP 数据包。其代码已经内置于内核中，并且按照不同的目的被组织成表（table）的集合。表由一组预先定义的链 (chain) 组成，链包含遍历顺序规则。每一条规则包含条件匹配和相应的动作（称为目标），如果条件匹配为真，该动作会被执行。

Dapper：小型ORM之王

pinpoint分布式性能监控工具(docker安装)

在做性能压测的时候，你是不是有只能看到测试报告？

在做性能压测的时候，你是不是想知道每一个方法执行了多长时间？

Pinpoint几乎可以帮助你查看你想看到的每一个细节。

Pinpoint是什么？

Pinpoint是一款全链路分析工具，提供了无侵入式的调用链监控、方法执行详情查看、应用状态信息监控等功能。基于GoogleDapper论文进行的实现，与另一款开源的全链路分析工具Zipkin类似，但相比Zipkin提供了无侵入式、代码维度的监控等更多的特性。 Pinpoint支持的功能比较丰富，可以支持如下几种功能：

• 服务拓扑图：对整个系统中应用的调用关系进行了可视化的展示，单击某个服务节点，可以显示该节点的详细信息，比如当前节点状态、请求数量等
• 实时活跃线程图：监控应用内活跃线程的执行情况，对应用的线程执行性能可以有比较直观的了解
• 请求响应散点图：以时间维度进行请求计数和响应时间的展示，拖过拖动图表可以选择对应的请求查看执行的详细情况
• 请求调用栈查看：对分布式环境中每个请求提供了代码维度的可见性，可以在页面中查看请求针对到代码维度的执行详情，帮助查找请求的瓶颈和故障原因。
• 应用状态、机器状态检查：通过这个功能可以查看相关应用程序的其他的一些详细信息，比如CPU使用情况，内存状态、垃圾收集状态，TPS和JVM信息等参数。

Java在1.5引入java.lang.instrument，你可以由此实现一个Java agent,通过此agent来修改类的字节码即改变一个类。

Pinpoint是一个分析大型分布式系统的平台，提供解决方案来处理海量跟踪数据。

Pinpoint, 2012年七月开始开发，在2015年1月作为一个开源项目启动, 是一个为大型分布式系统服务的n层架构跟踪平台。 Pinpoint的特点如下:

• 分布式事务跟踪，跟踪跨分布式应用的消息
• 自动检测应用拓扑，帮助你搞清楚应用的架构
• 水平扩展以便支持大规模服务器集群
• 提供代码级别的可见性以便轻松定位失败点和瓶颈
• 使用字节码增强技术，添加新功能而无需修改代码

无法识别从Node1发送的第N个消息和Node2接收到的N'消息之间的关系——Google dapper实现了一个简单的解决方案来解决这个问题。这个解决方案通过在发送消息时添加应用级别的标签作为消息之间的关联。例如，在HTTP请求中的HTTP header中为消息添加一个标签信息并使用这个标签跟踪消息。

Pinpoint中的数据结构

Pinpoint中，核心数据结构由Span, Trace, 和 TraceId组成。

• Span: RPC (远程过程调用/remote procedure call)跟踪的基本单元; 当一个RPC调用到达时指示工作已经处理完成并包含跟踪数据。为了确保代码级别的可见性，Span拥有带SpanEvent标签的子结构作为数据结构。每个Span包含一个TraceId。
• Trace: 多个Span的集合; 由关联的RPC (Spans)组成. 在同一个trace中的span共享相同的TransactionId。Trace通过SpanId和ParentSpanId整理为继承树结构.
• TraceId: 由 TransactionId, SpanId, 和 ParentSpanId 组成的key的集合. TransactionId 指明消息ID，而SpanId 和 ParentSpanId 表示RPC的父-子关系。
  • TransactionId (TxId): 在分布式系统间单个事务发送/接收的消息的ID; 必须跨整个服务器集群做到全局唯一.
  • SpanId: 当收到RPC消息时处理的工作的ID; 在RPC请求到达节点时生成。
  • ParentSpanId (pSpanId): 发起RPC调用的父span的SpanId. 如果节点是事务的起点，这里将没有父span - 对于这种情况， 使用值-1来表示这个span是事务的根span。

Google Dapper 和 NAVER Pinpoint在术语上的不同

Pinpoint中的术语"TransactionId"和google dapper中的术语"TraceId"有相同的含义。而Pinpoint中的术语"TraceId"引用到多个key的集合。

作者：小清新同学
链接：https://www.jianshu.com/p/a803571cd570
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

Dapper 和 Zipkin, Twitter的一个分布式系统跟踪平台, 生成随机TraceIds (Pinpoint是TransactionIds) 并将冲突情况视为正常。然而, 在Pinpiont中我们想避免冲突的可能，因此实现了上面描述的系统。有两种选择：一是数据量小但是冲突的可能性高，二是数据量大但是冲突的可能性低。我们选择了第二种。

AgentId：64位长度整型

可能有更好的方式来处理transaction。我们起先有一个想法，通过中央key服务器来生成key。如果实现这个模式，可能导致性能问题和网络错误。因此，大量生成key被考虑作为备选。后面这个方法可能被开发。现在采用简单方法。在pinpoint中，TransactionId被当成可变数据来对待。

使用字节码增强技术，我们就不必担心暴露跟踪API而可以持续改进设计，不用考虑依赖关系。

——就是可以瞎JB变了撒

针对 PinPoint 的扩展和改造：

- 通信机制异步化调整；

- 探针引导程序 premain 改造；

- gRPC 探针；

DDD领域驱动／CQRS读写分离／ES事件溯源 这些前沿的时髦的技术理念汇聚在一次，落地到一套完整实现方案。这就是Axon

Command执行过程：

• Command通过org.axonframework.commandhandling.CommandBus分发，其中DistributedCommandBus实现了分布式的派发，它可以适配SpringCloud. 主要逻辑是通过
  AggregateIdentifier做一致性HASH。确保次对同一个聚合根发到同一台机器，这样保证了缓存的命中。Aggregate本质上在应用内缓存了当前状态，如果该服务宕机。另一台机器会通过事件溯源重新构造出当前状态。
• Command的事务处理：Axon通过UnitofWork控制一致性，其中嵌入了JDBC事务。并且在回滚时会清除Aggregate缓存，下次会重新加载。
• 当然对于远程的子事务无法保证一致性。这是个大的隐患

Saga最终一致性，补偿机制。

• Saga的理念没问题，当是实现起来问题很大。
• 一个是每个command都要创建event非常繁琐，并且saga来来回回非常多
• 另一个是没有考虑到幂等，本地宕机，状态，分布事务等细节的处理。自己实现也不灵活
• 确保分布式事务一致性是个非常繁琐的事情，请参考转账交易这件小事，是如何被程序员玩坏的.

说说其他实现困难的情况

• 如果Aggregate存在继承关系，或者实现一些通用的行为接口。框架并不支持
• 无法实现延迟触发的功能
• 对大量聚合实现批量操作不太容易
• 几乎所有的操作都要靠command触发，然后转成event,非常繁琐。

取其思想，寻找替代

在交易中的订单模型，本质上就是ES中的Event. 账户余额是用订单累加出来的。只不过订单不止记录事件。还用来记录更新审核状态，系统状态，事务状态等，不那么纯粹。通过订单回溯账户状态是个人工过程而不是自动的。

• 在这方面，Axon对事件的存储采用统一的表，事件序列化到表中，并不有利于数据库的查看。需要额外的记录一个查询视图
• 快照模型也在交易对账中有所体现。每日对账后生成当日的一个快照，第二天的交易从快照开始累计

Command模型配合只insert没有update的操作，可以在高并发下实现无锁处理。这个可以通过Kafka。或者数据库先插入，后异步读取处理的方式来实现。

充血模型是Axon的一个特色。不过并不难实现。通过自定义一个SpringCloud LoadBalancer Rule 实现哈希一致也可以实现。另外传统的失血模型使用无状态服务更简单，它可以在数据库层面通过一致性hash来存储数据，比如mongodb。对于订单这样的单一记录低频操作完全可以处理。对于同一记录的高频处理Axon也是有其优势的，不过Akka可能也是不错的选择

Saga异常难写，在网络异常，幂等，重试方面并不友好

总结：DDD领域驱动／CQRS读写分离／ES事件溯源，这些思想都很棒，但是并不用拘泥于特定的实现。Axon对于学习这些概念具有非常大的帮助，但是在实践的过程中并不高效、灵活

作者：黄大海
链接：https://www.jianshu.com/p/4a7854e4b8f2
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

Reveno是一个全新的无锁事务处理框架，它支持JVM平台，并基于CQRS及事件溯源模式实现。虽然它只是一个简单而强大的工具，但在性能方面也毫不逊色。所有事务都被持久化为只读的日志，并且可以通过按顺序重演事件的方式恢复领域模型的最新状态。所有的运行时操作都是在内存中执行的，从而使其吞吐量可达到每秒种几百万次事务的数量级，平均延迟时间则限制在微秒级。虽然Reveno的功能如此强大，但它仍然是一个通用目的的框架，涵盖了大量不同种类的用例，并提供了丰富的引擎配置选项。举例来说，你可以调整它的持久性配置，在极其随意（为了提高系统吞吐量）与高度受限（对于数据丢失的情况具有较低的容忍度）之间进行选择。

对于不同的用例来说，其需求也是千差万别的。作为一个通用框架，它需要考虑所有不同的可能性。在本文中，我将通过示例为读者展现如何使用Reveno框架开发一个简单的交易系统。

首先让我们来了解一下Reveno如何处理你的领域模型。作为一个基于CQRS的框架，Reveno会将你的领域切分为 事务模型与查询模型 。对这两个模型的定义没有任何限制，你无需使用任何强制性的注解、基类，甚至不需要实现Serializable接口，只需使用最简单的POJO就可以完成任务。

没有任何一种单一的途径能够应对所有不同的用例，因此应用程序的设计者需要决定如何处理事务模型的回滚操作。Reveno为实现模型对象提供了两种主要方式：可变与不可变模型。这两种方式各有不同的底层处理机制，并且各有其优缺点。在Java中，不可变对象的开销很低，并且无需进行同步操作，这种方式目前 非常流行 。Reveno能够非常高效地处理不可变对象，但每种使用不可变类型的领域都会产生额外的垃圾对象，Reveno也不例外。因此，如果你能够接受一些额外的GC开销，那么就应当将这种方式作为默认的选择。反之，如果使用可变模型，那么在进行事务运行时，就要为已使用的对象生成额外的序列化快照，而这将影响到你的性能。幸运的是，如果你坚持使用可变模型，并且仍需要保证性能的最大化及GC影响的最小化，那么你可以选择一种额外的可变模型特性，“补偿行为”（Compensating Actions）。简单来说，补偿行为是指在实现常规的事务处理函数时，一并实现的一种手动回滚行为。如果读者想了解这方面的更多细节，请参考 Reveno的官方文档页面 。

Kubernetes之Taints与Tolerations 污点和容忍

作者：Flywithmeto 2018-04-10 来源：51CTO

        NodeAffinity节点亲和性，是Pod上定义的一种属性，使Pod能够按我们的要求调度到某个Node上，而Taints则恰恰相反，它可以让Node拒绝运行Pod，甚至驱逐Pod。

        Taints(污点)是Node的一个属性，设置了Taints(污点)后，因为有了污点，所以Kubernetes是不会将Pod调度到这个Node上的，

       于是Kubernetes就给Pod设置了个属性Tolerations(容忍)，只要Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去。

        因此 Taints(污点)通常与Tolerations(容忍)配合使用。

一般准则

• 分离构建和运行环境

• 使用dumb-int等避免僵尸进程

• 不推荐直接使用Pod，而是推荐使用Deployment/DaemonSet等

• 不推荐在容器中使用后台进程，而是推荐将进程前台运行，并使用探针保证服务确实在运行中

• 推荐容器中应用日志打到stdout和stderr，方便日志插件的处理

• 由于容器采用了COW，大量数据写入有可能会有性能问题，推荐将数据写入到Volume中

• 不推荐生产环境镜像使用latest标签，但开发环境推荐使用并设置imagePullPolicy为Always

• 推荐使用Readiness探针检测服务是否真正运行起来了

• 使用activeDeadlineSeconds避免快速失败的Job无限重启

• 引入Sidecar处理代理、请求速率控制和连接控制等问题

分离构建和运行环境

注意分离构建和运行环境，直接通过Dockerfile构建的镜像不仅体积大，包含了很多运行时不必要的包，并且还容易引入安全隐患，如包含了应用的源代码。

可以使用Docker多阶段构建来简化这个步骤。

什么是Prometheus?

Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。
2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。
Prometheus目前在开源社区相当活跃。
Prometheus和Heapster(Heapster是K8S的一个子项目，用于获取集群的性能数据。)相比功能更完善、更全面。Prometheus性能也足够支撑上万台规模的集群。

Prometheus的特点

• 多维度数据模型。
• 灵活的查询语言。
• 不依赖分布式存储，单个服务器节点是自主的。
• 通过基于HTTP的pull方式采集时序数据。
• 可以通过中间网关进行时序列数据推送。
• 通过服务发现或者静态配置来发现目标服务对象。
• 支持多种多样的图表和界面展示，比如Grafana等。

官网地址：https://prometheus.io/