Consul vs. ZooKeeper, doozerd, etcd

ZooKeeper、Doozerd、Etcd在架构上都非常相似，它们都有服务节点（server node），而这些服务节点的操作都要求达到节点的仲裁数（通常，节点的仲裁数遵循的是简单多数原则）。此外，它们都是强一致性的，并且提供各种原语。通过应用程序内部的客户端lib库，这些原语可以用来构建复杂的分布式系统。

在一个单一的数据中心内部，Consul同样使用多个服务节点。在每个数据中心中，为了Consule能够运行，并且保持强一致性，Consul服务端需要仲裁。然而，Consul原生支持多数据中心，就像一个丰富gossip系统连接服务器节点和客户端一样。

当提供K/V存储的时候，这些系统具有大致相同的语义，读操作是强一致性的，并且在面对网络分区的时候，为了保证读操作的强一致性，牺牲了可用性。然而，当系统应用于复杂情况时，这种差异会变得更加明显。

这些系统提供的语义对构建服务发现系统的开发人员很有吸引力，但更重要的是，它们强制开发人员自己构建这些特性。ZooKeeper只提供一个原始的K/V存储，并要求开发人员构建他们自己的系统来提供服务发现功能。相反的是，Consul提供了一个坚固的框架，这不仅仅是为了提供服务发现功能，也是为了减少推测工作和开发工作量。客户端只需简单地完成服务注册工作，然后使用一个DNS接口或者HTTP接口就可以执行工作了，而其他系统则需要你定制自己的解决方案。

一个令人信服的服务发现框架必须包含健康检测功能，并且考虑失败的可能性。要是节点失败或者服务故障了，即使开发人员知道节点A提供Foo服务也是没用的。Navie系统利用心跳检测，周期性的更新服务或结点的TTL值。这种模式会导致检测工作随着结点的数目的增加而线性增加，并且限制了服务器的数量。此外，故障检测窗口的存活时间至少要和TTL一样长。

ZooKeeper提供了临时节点，这些临时节点就是K/V条目，当客户端断开连接时，这些条目会被删除。虽然这些临时节点比一个心跳系统更高级，但仍存在固有的扩展性问题，并且会增加客户端的复杂性。与ZooKeeper服务器端连接时，客户端必须保持活跃，并且去做持续性连接。此外，ZooKeeper还需要胖客户端，而胖客户端是很难编写，并且胖客户端会经常导致调试质询。

Consul使用一个完全不同的架构进行结点的健康检测。这个架构中不仅仅只有Consul服务结点，集群中的每一个节点上都会运行一个Consul客户端。这些Consul客户端属于一个gossip pool，gossip pool提供了一些功能，包括分布式健康检测。gossip协议提供了一个高效的故障检测工具，这个故障检测工具可以应用到任意规模的集群，而不仅仅是作用于特定的服务器组。同时，这个故障检测工具也支持在本地进行多种健康检测。与此相反，ZooKeeper的临时节点只是一个非常原始的活跃度检测。因为有了Consul，客户端可以检测web服务器是否正在返回200状态码，内存利用率是否达到临界点，是否有足够的数据存储盘等。此外，ZooKeeper会暴露系统的复杂性给客户端，为了避免ZooKeeper出现的这种情况，Consul只提供一个简单HTTP接口。

Consul为服务发现、健康检测、K/V存储和多数据中心提供了一流的支持。为了支持任意存储，而不仅仅是简单的K/V存储，其它系统都要求工具和lib库要率先建立。然而，通过使用客户端节点，Consul提供了一个简单的API，这个API的开发只需要瘦客户端就可以了， 而且通过使用配置文件和DNS接口，开发人员可以建立完整的服务发现解决方案，最终，达到避免开发API的目的。

前言

该文章翻译自 https://www.consul.io/intro/index.html

这篇文章的目标是对Consul进行一个简单的介绍。包括Consul是什么，它解决了什么问题，它有哪些功能。通过这篇文章能让你对Consul能有一个大致的了解，和基本的使用。

What is Consul?

Consul 有许多组件，但是作为一个整理来看，它为你的基础设施提供了服务发现和统一配置功能。它提供如下的主要的功能：

背景

在Java中查询底层CAS实现时，了解到CPU总线仲裁的概念。Google后找到如下的文章。

what-is-bus-arbitration-explain-any-two-techniques

什么是Java的Instrumentation ?

JDK™5.0中引入包java.lang.instrument。 该包提供了一个Java编程API，可以用来开发增强Java应用程序的工具，例如监视它们或收集性能信息。 使用 Instrumentation，开发者可以构建一个独立于应用程序的代理程序（Agent），用来监测和协助运行在 JVM 上的程序，甚至能够替换和修改某些类的定义。有了这样的功能，开发者就可以实现更为灵活的运行时虚拟机监控和 Java 类操作了，这样的特性实际上提供了一种虚拟机级别支持的 AOP 实现方式，使得开发者无需对 JDK 做任何升级和改动，就可以实现某些 AOP 的功能了。

在 Java SE 6 里面，instrumentation 包被赋予了更强大的功能：启动后的 instrument、本地代码（native code）instrument，以及动态改变 classpath 等等。这些改变，意味着 Java 具有了更强的动态控制、解释能力，它使得 Java 语言变得更加灵活多变。

背景

要对系统进行压测，而系统依赖的消息中间件是Apache ActiveMQ。 在压测中需要衡量队列的堆积和消费情况。ActiveMQ自己的console不够友好，直观，需要不停的F5才能看到队列的堆积情况，而且只能反映瞬时的值，不能够知道整个压测过程过ActiveMQ的状态。

背景

在测试环境执行命令crontab -l，系统提示找不到该命令。很奇怪？印象中这中情况是第一次遇到。Google了一下了解到不是所有系统或某个发行版的所有版本都会默认安装该命令。

前言

什么是callback hell呢？看下图

有过Node.js开发经验的人，一定程度上都被各种回调嵌套折磨过。过去和现在有很多针对Node.js异步回调嵌套处理的解决办法，这里就不讨论了。感兴趣的可以Google。

Vert.x号称JVM上的Node.js 肯定也会有遇到各种回调嵌套的问题。总结这些回调嵌套处理方式对我们使用Vert.x是非常有帮助的。

前言

在Java中Future表示一个异步计算的结果，提供了许多方法来获取结果，取消计算等。在Vert.x中Future表示一个动作的结果，该结果可能出现也可能没有出现。二者有许多相似之处。

Vert.x中Future的继承层次如下：

vert.x 集群简介

在 Vert.x 中，集群化与高可用均是开箱即用的。Vert.x 通过可插拔的集群管理器（cluster manager）来实现集群管理。在 Vert.x 中，采用 Hazelcast 作为默认的集群管理器。

vert.x 集群器管理的作用

在 Vert.x 中，集群管理器可用于各种功能，包括：

• 对集群中 Vert.x结点进行分组，服务注册和发现
• 维护集群范围中的主题订阅者列表（所以我们可知道哪些节点对哪个Event Bus地址感兴趣）
• 分布式Map的支持
• 分布式锁
• 分布式计数器

集群管理器不处理Event Bus节点之间的传输，这是由 Vert.x 直接通过TCP连接完成。

本文翻译自：http://microservices.io/patterns/apigateway.html

API Gateway / Backend for Front-End

背景

想象一下，你使用微服务架构构建了一个在线商城并且你在实现一个商品详情页功能。你需要开发不同版本的详情页服务接口：

• 利用HTML5和JavaScript开发的针对PC浏览器和手机浏览器。HTML页面是由后端的web服务生成的。
• 原生 Android 和 iPhone 客户端 - 这些客户端通过REST API和服务端进行通信。

此外，在线商城的商品详情页服务必须通过 REST API 暴露给第三方应用程序。

一个商品详情页页面需要展示的商品信息是非常多的。例如：Amazon.com 上的一本书的商品详情页：POJOs in Action需要展示的信息如下：