转自：http://blog.csdn.net/xiaoyu411502/article/details/48129057
随着 微服务 的流行，相比较以前一个大型应用程序搞定所有需求，我们现在更倾向于把大型应用程序切分成多个微服务，服务之间通过 RPC 调用。微服务架构的好处非常多，例如稳定的服务变化较少，不会被非稳定服务所影响；不同的服务更方便交给不同的人管理；发布、扩容等操作也更加有针对性。不过这也不是没有代价的，额外的成本最主要的可能就是运维成本。
我们维护的一个产品，由 7 个微服务构成，它们各司其职，承担上行、下行、同步等各类职责，我非常喜欢这种架构，但也面临一个小小的烦恼。每次我们发布其中一个或者多个服务，就需要去验证服务的健康度，极限情况下，7 个服务 x （国内环境 + 国外环境）x （预发布环境 + 生产环境），总共需要验证 28 次！我希望有简单、标准、自动的方式去验证这些服务是否健康。当然，验证健康也不是跑一个完整的回归测试，那是在测试环境就需要完成的事情，健康检查基本只是关注环境是否 OK，最核心的一两个用例是否 OK。由于部署到预发布或者线上的代码，和线下测试的代码是一致的，因此就不需要重复验证各种功能了，关注点应该在环境上，这一点线上和线下是有明显区别的。至于环境区别，通常就是磁盘、数据库、其他分布式服务等等。
此外，我还希望所有服务的健康检查接口是完全一致的，没有人希望检查服务 A 的时候用 url /ok，检查服务 B 的时候用 url /good。
我曾尝试定义一个健康检查协议，让所有服务都暴露一个HTTP接口http://172.20.10.2/health.json ，返回的内容就包含这个这个服务的基本状态。
这几天看 Spring Boot ，发现它已经很好地集成了我想要的功能，而且看起来更简单，因此我就直接扔掉了自己定义的协议，改而使用 Spring Boot 的方式，Spring Boot 有一个称之为 endpoint 的概念，每个 endpoint 是一个非常简单的 HTTP 接口，用户可以通过 endpoint 监控 Spring Boot 应用，甚至与之交互。这其中，最简单的 endpoint 就是 health，只要加入必要的 Spring Boot 依赖，用户就能通过 health 查看 Spring Boot 应用的基本状态。
$ curl http://localhost:8080/health
{
"status":"UP"
}
这里我们看到服务的状态是 UP，不过也许这个检查太简单了，例如我的服务依赖其他外部服务，其中一个 Tair，一个是 TFS，这两个都是强依赖，如果它们有问题，我的服务就应该是 DOWN 的状态，在 Spring Boot 中，可以这么扩展：
@Component
public class MyHealth implements HealthIndicator {
@Override
public Health health() {
return new Health.Builder()
.withDetail("tair", "timeout") // some logic check tair
.withDetail("tfs", "ok") // some logic check tfs
.status("500")
.down()
.build();
}
}
只要加入一个 bean 实现 HealthIndicator 就能实现更加全面的检查，现在访问 health endpoint 是这样的：
$ curl http://localhost:8080/health
{
"status": "DOWN",
"tair": "timeout",
"tfs": "ok"
}
只要在每个服务稍微实现一些基本的环境检查，那我就可以用几行脚本快速地完成 7 个服务 x （国内环境 + 国外环境）x （预发布环境 + 生产环境）的健康检查，如果有哪个服务出问题了，定位环境问题也是非常方便的。
这种监控是实时的，这一点非常重要。在实际工作中我们其实有非常完善的系统监控平台，平台能提供 CPU、内存、磁盘、网络IO、JVM 等等各种各样非常全面的信息，这种平台的优势有历史趋势记录，有汇总，有比较，劣势就是不够实时，通常只能看到 5 分钟前的数据。因此，在发布服务，扩容的时候，等待这样的系统监控平台反馈就不够了。
除了 health endpoint 之外，Spring Boot 还提供了 其它10多个 endpoint ，它们都是针对运维设计的，例如可以用 shutdown endpoint 来关闭服务、用 beans endpoint 来查看所有的 Spring Bean，下面我想详细讲一下 metrics 这个 endpoint。
默认访问 metrics 我们能得到很多信息，包括 JVM 的线程数、内存、GC 数据等等……，这些都是系统级别的数据，但其实我们可以通过 metrics 收集实时的业务数据，例如每分钟用户登陆数量、每分钟文件同步数量、实时的缓存命中率……等等。
实现是这样的：
@Component
public class MyMetric {
private final CounterService counterService;
private final GaugeService gaugeService;
@Autowired
public MyMetric(CounterService counterService, GaugeService gaugeService) {
this.counterService = counterService;
this.gaugeService = gaugeService;
}
public void exampleCounterMethod() {
this.counterService.increment("login.count");
// reset each minute
}
public void exampleGaugeMethod() {
this.gaugeService.submit("cache.hit", 80.0);
}
}
Spring Boot 内置了两个 Service，CounterService 可以用来做简单的累加累减，GaugeService 可以用来存放简单的 double 值，数据都存放在内存中。
现在访问 metrics endpoint 的效果是这样的：
$ curl http://localhost:8080/metrics
{
"counter.login.count": 42,
"counter.status.200.beans": 1,
"counter.status.200.metrics": 9,
"counter.status.200.root": 4,
"gauge.cache.hit": 80.0,
"gauge.response.beans": 55,
"gauge.response.health": 12,
"gauge.response.metrics": 4,
...
}
Spring Boot 的 metrics endpoint 带了很多的信息，这里我们只关注自定义的数据。
如果所有服务的核心业务数据都通过 metrics 暴露，我们接下来要做的无非就是通过一些数据可视化的 JavaScript 组件访问这些数据，做成一个 Dashboard，那我们就能通过这样一个 Dashboard 查看系统的实时状态。
Spring Boot 的 Endpoints 带着强烈的 DevOps 色彩， “you build it, you run it” ，开发不仅要关心如何实现功能，还需要关心服务在线上运行的状态，如果缺乏实时监控，维护线上服务必然是一场噩梦。如果基于 Spring Boot 开发服务，那只需要稍作扩展，实时监控就足够用了，就算不使用 Spring Boot，类似的思路自己实现也并不复杂。
参考链接 http://docs.spring.io/spring-boot/docs/1.1.x/reference/htmlsingle/#production-ready-endpoints