微服务本身并没有一个严格的定义，不过从很多人的反馈来看，大家都达成了这样一个共识：微服务是一种简单的应用，大概有10到100行代码。我知道使用代码行数来比较实现其实很不靠谱，因此你能理解这个意思就行，不必过分拘泥于细节。不过有一点需要注意，那就是微服务通常都是很小的，甚至是微型的。这意味着你不会在大型框架上看到很多小服务，这是不切实际的。简单与轻量级是当今的主流。诸如Sinatra、Webbit、Finagle与Connect等小型框架在将你的代码包装到一个薄薄的通信层这方面做得刚刚好。

微服务架构带来的变化

微服务架构给IT系统和团队带来了以下显著的变化：

• 基础设施的升级，需要引入虚拟化(如Docker)，现存基础设施也需要与之进行适配;
• 系统架构的升级，需要引入服务注册(如Consul)，服务间的交互方式也需要与之进行适配;
• 运维平台的升级，建议引入日志收集(如Fluentd)，分布式跟踪(如Zipkin)和仪表盘(如Vizceral/Grafana)等;
• 运维效率和自动化水平的提升也迫在眉睫，否则无法应对实例数量，变更频率，系统复杂度的快速增长;
• 观念的转变，基础设施，系统架构和运维平台等的大幅升级，犹如小米加步枪换成飞机大炮，相应的战略战术也需要与之相适配才行。

微服务架构下用户面临的监控问题

在转型到微服务架构以后，用户在监控方面主要会面临以下问题。

首先，监控配置的维护成本增加。某个在线系统大概有106个模块，每个模块都需要添加端口监控，进程监控，日志监控和自定义监控;不同服务的监控指标，聚合指标，报警阈值，报警依赖，报警接收人，策略级别，处理预案和备注说明也不完全相同;如此多的内容，如何确保是否有效，是否生效，是否完整无遗漏。

当前针对维护成本，业界常用的几种方法有：

• 通过变量的方式尽量减少人工输入
• 通过监控配置文件解析做一些可标准化的校验
• 通过故障演练验证报警是否符合预期

其次，第三方依赖越来越多。例如Docker的可靠性很大程度上取决于宿主机，如果所在的宿主机发生资源争用，网络异常，硬件故障，修改内核参数，操作系统补丁升级等，都可能会让Docker莫名其妙地中招。

第三，服务故障的定位成本增加。假设故障是因为特定服务处理耗时增大导致的，那么如何快速从106个服务以及众多的第三方依赖中把它找出来，进一步，又如何确认是这个服务的单个实例还是部分实例的异常，这些都让故障定位变得更复杂。

在微服务架构下，提高故障定位效率的常用方法有：基于各类日志分析，通过仪表盘展示核心指标：数据流，异常的监控策略，变更内容，线上登录和操作记录，文件修改等内容。

微服务监控的难点及解决思路

在微服务架构下，监控系统在报警时效性不可改变的前提下，采集的指标数量是传统监控的三倍以上，如果是万台以上的规模，监控系统整体都面临非常大的压力，在监控方面的挑战主要来源于：

首先，存储功能的写入压力和可用性都面临巨大挑战。每秒写入几十万采集项并且需要保证99.99%的可用性，对于任何存储软件来讲，都不是一件轻松的事情。

对于写入和可用性的压力，业界常见的解决思路主要是基于如下方式的组合：

• 集群基于各种维度进行拆分(如地域维度、功能维度和产品维度等);
• 增加缓存服务来降低Hbase的读写压力;
• 调整使用频率较低指标的采集周期;
• 通过批量写入降低Hbase的写入压力;
• 通过写入两套Hbase避免数据丢失并做到故障后快速切换。

其次，监控的生效速度也面临巨大挑战。微服务架构下，基于弹性伸缩的加持，从服务扩容或者迁移完毕到接入流量的耗时降低到1Min左右，且每时每刻都在不断发生着。对于复杂监控系统来讲，支持这样的变更频率绝非易事，而且实例变更如此频繁，对监控系统自身来讲，也会面临可用性的风险。

常见的提高监控生效速度的思路主要有如下的几种方式：

• 实时热加载服务注册信息;
• 对监控配置的合规性进行强校验;
• 增加实例数量的阈值保护;
• 支持配置的快速回滚。

第三，基础设施的故障可能导致报警风暴的发生。基础设施如IDC故障，可能会在瞬时产生海量报警，进而导致短信网关拥塞较长时间。

解决这类问题的思路主要是如下方式：

• 基于报警接收人通过延时发送进行合并;
• 报警策略添加依赖关系;
• 优先发送严重故障的报警短信;
• 增加多种报警通知方式如电话、IM等。

微服务监控原则

对于采用微服务的团队，建议在做监控时可以参考Google SRE的理论，结合长期的运维实践经验，我们总结了几点可以参考的原则：

• 首先，所有系统和第三方依赖的核心功能必须添加黑盒监控;
• 第二，所有模块必须添加白盒监控的四个黄金指标(饱和度，错误，流量和延时);
• 第三，所有的变更都需要进行采集，包括但不限于程序，配置，数据，网络，硬件，操作系统以及各类基础设施。

另外，我们也给大家提供了一些黑盒监控的实施经验：

首先，应该监控哪些功能?建议将系统接入层的访问日志，TOP-10的URL添加黑盒监控。那TOP-9的URL是否一定需要监控?TOP-11的URL是否一定不需要监控?这取决于其访问量是否和前面的URL在一个数量级以及人工评估其接口的重要性程度，这里提供的更多是一个思路，而非可量化的方法。

第二，应该使用多少个样本/节点对一个功能进行黑盒监控?建议样本应该覆盖到对应模块的所有实例，这样也能发现由少数实例导致的小规模故障。

微服务架构下的理想监控系统

从用户的角度看，Prometheus的整体架构设计参考了Google BorgMon，系统具有高度的灵活性，围绕其开放性现在也慢慢形成了一个生态系统。具体来说，Prometheus 使用的是 Pull 模型，Prometheus Server 通过 HTTP 的 Pull 方式到各个目标拉取监控数据。HTTP协议的支持能够更加方便的进行定制化开发，服务注册、信息采集和数据展示均支持多种形式/开源软件。

结合目前国内正在兴起的智能运维，也许不久的将来，上面提到的监控的各种问题也就迎刃而解了。监控策略不在需要人工定义，转由机器学习负责，诸如策略添加，阈值设定，异常检测，故障定位，自动止损等逐步由系统负责，运维人员不再是“救火队长”。

京东云监控响应实践

京东云运维平台为数万台机器提供监控，部署，机器管理，权限管理，安全管理，审计和运营分析等功能，为京东云所有的业务在各类异构网络环境下提供标准和统一的运维支撑能力。

基于产品所处的发展阶段，用户规模的不同，报警频率也不尽相同。理想情况下，报警频率应该等同于故障频率，这里面体现了报警的准确度和召回率两个指标，如果每个报警都对应一个服务故障，则准确度为100%，同理，如果每次服务故障均有报警产生，则召回率为100%。大家可以基于上述两个指标，来衡量自己团队的现状，并针对性的制定提升计划即可。

对于响应流程，京东云有几个做的好的地方可以给大家参考：

首先，所有核心报警均有可靠的应对预案和处理机制，并通过定期的破坏演练持续进行完善。

其次，公司的监控中心会7x24值守，他们也会和业务线运维同学一样，接收所有影响核心系统稳定性的报警，收到报警后会进行通报，确保核心报警在发生后第一时间内有人处理并在规定的时间内处理完毕。如果未在规定的时间内处理完毕，监控中心会进行报警升级，通报该系统的管理人员，从而确保该报警可以得到更高的重视度和支持力度。

总结

对于监控系统的未来发展，长期来看，依托于Kubernetes的发展，在基础设施的各个领域，都会从百花齐放到几家独大，从而将标准化落地到基础设施的各个领域，进而促进整个生态的繁荣。

链接: https://www.fly63.com/article/detial/3348