一、背景介绍如今，在微服务架构盛行的互联网时代，微服务架构下模块（本文指可独立部署的服务）之间的关系错综复杂（哪怕是避免模块之间的直接循环依赖都很变得困难），评估一整套业务系统（集群）的容量已经不像评估单机系统那样容易，而系统的容量评估，是稳定性建设的核心内容之一，是我们绕不开的主题。有了系统容量评估，配合今年的业务目标，我们才知道应该申请多少预算、什么时候需要扩容、系统瓶颈在哪、哪些服务...

1、背景我们知道Spring Boot是为了解决Spring使用成本高的问题，Spring Cloud是为了解决分布式系统开发成本高的问题，而在分布式系统中，服务治理又是绕不开的话题，注册中心又是核心中心的核心。而Consul就是为了在云原生上构建注册中心而准备的，尽管这样定义Consul不够全面（Consul还有很多其他能力），但Consul提供的服务发现和注册的能力才是本文的重点。如你所知，C

上篇文章大致讲述了同步消费者和异步消费者接收消息的异同（详见《ActiveMQ中消费者是如何接收消息的（一）》http://manzhizhen.iteye.com/blog/2094130 ），但我们还未讲到消息是在什么时候放入消费者ActiveMQMessageConsumer类的“消息容器”unconsumedMessages中的，这很关键，因为为了解耦，消费者类不需要知道你ActiveMQ

       2010年谷歌发表了其内部使用的分布式跟踪系统Dapper的论文（http://static.googleusercontent.com/media/research.google.com/zh-CN//archive/papers/dapper-2010-1.pdf，译文地址：http://bigbully.github.io/Dapper-translation/），讲述了Dap

楼主所在的团队全面拥抱了Spring Cloud体系，但由于历史原因，以及使用了腾讯云TSF的老版本，加上开发自维护的基础工具包一掺和，所有项目使用的Spring Cloud都停留在 2.1.2.RELEASE 版本，所以Spring Cloud Gateway（后面简称SCG）使用的是 2.1.2.RELEASE 版本。