http://blog.csdn.net/xiaoyu411502/article/details/48129057

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

微服务 的流行，相比较以前一个大型应用程序搞定所有需求，我们现在更倾向于把大型应用程序切分成多个微服务，服务之间通过 RPC 调用。微服务架构的好处非常多，例如稳定的服务变化较少，不会被非稳定服务所影响；不同的服务更方便交给不同的人管理；发布、扩容等操作也更加有针对性。不过这也不是没有代价的，额外的成本最主要的可能就是运维成本。

测试，那是在测试环境就需要完成的事情，健康检查基本只是关注环境是否 OK，最核心的一两个用例是否 OK。由于部署到预发布或者线上的代码，和线下测试的代码是一致的，因此就不需要重复验证各种功能了，关注点应该在环境上，这一点线上和线下是有明显区别的。至于环境区别，通常就是磁盘、数据库、其他分布式服务等等。

我曾尝试定义一个健康检查协议，让所有服务都暴露一个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 应用的基本状态。

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(); } } 

只要在每个服务稍微实现一些基本的环境检查，那我就可以用几行脚本快速地完成 7 个服务 x （国内环境 + 国外环境）x （预发布环境 + 生产环境）的健康检查，如果有哪个服务出问题了，定位环境问题也是非常方便的。

除了 health endpoint 之外，Spring Boot 还提供了 其它10多个 endpoint ，它们都是针对运维设计的，例如可以用 shutdown endpoint 来关闭服务、用 beans endpoint 来查看所有的 Spring Bean，下面我想详细讲一下 metrics 这个 endpoint。

实现是这样的：

现在访问 metrics endpoint 的效果是这样的：

如果所有服务的核心业务数据都通过 metrics 暴露，我们接下来要做的无非就是通过一些数据可视化的 JavaScript 组件访问这些数据，做成一个 Dashboard，那我们就能通过这样一个 Dashboard 查看系统的实时状态。

“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