目录
文章目录
- 目录
- 日志与审计
- 监控与告警
- 配置中心
- 文档中心
日志与审计
日志分析组件应该在微服务兴起之前就被广泛使用了。即使单体应用架构，当访问数变大、或服务器规模增多时，日志文件的大小会膨胀到难以用文本编辑器进行访问，更糟的是它们分散在多台服务器上面。排查一个问题，需要登录到各台服务器去获取日志文件，一个一个地查找（而且打开、查找都很慢）想要的日志信息。如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。
因此，在应用规模变大时，我们需要一个日志搜索引擎，以便于能准确的找到想要的日志。另外，数据源一侧还需要收集日志的组件和展示结果的 UI 组件。
ELK（Elasticsearch、Logstash 和 Kibana）是目前使用最广泛的日志搜索引擎解决方案：
- Elasticsearch：搜索引擎，同时也是日志的存储。
- Logstash：日志采集器，它接收日志输入，对日志进行一些预处理，然后输出到 Elasticsearch。
- Kibana：UI 组件，通过 Elasticsearch 的 API 查找数据并展示给用户。
监控与告警
微服务架构中组件繁多，各个组件所需要监控的指标不同。比如：Redis 缓存一般监控占用内存值、网络流量，数据库监控连接数、磁盘空间，业务服务监控并发数、响应延迟、错误率等。因此如果做一个大而全的监控系统来监控各个组件是不大现实的，而且扩展性会很差。一般的做法是让各个组件提供报告自己当前状态的接口（metrics 接口），这个接口输出的数据格式应该是一致的。然后部署一个指标采集器组件，定时从这些接口获取并保持组件状态，同时提供查询服务。最后还需要一个 UI，从指标采集器查询各项指标，绘制监控界面或者根据阈值发出告警。
Prometheus 就是微服务架构中指标收集器的标准，而 Grafana 则用于监控界面和邮件告警，这样一套微服务监控系统就搭建起来了。微服务框架一方面要记录重要的框架层日志、metrics 和调用链数据，还要将日志、metrics 等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。
配置中心
配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。
文档中心
文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用 API 的开发和测试人员带来极大便利。Swagger 就是一种流行的 RESTful API 文档方案。
