认识达内从这里开始

微服务架构对于程序员来说是需要掌握的新型技术之一，而其受到追捧的原因就是符合互联网的发展以及其便捷性。今天我们就一起来了解一下，微服务架构带来的变化。

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

基础设施的升级，需要引入虚拟化(如Docker)，现存基础设施也需要与之进行适配;

系统架构的升级，需要引入服务注册(如Consul)，服务间的交互方式也需要与之进行适配;

运维平台的升级，建议引入日志收集(如Fluentd)，分布式跟踪(如Zipkin)和仪表盘(如Vizceral/Grafana)等;

运维效率和自动化水平的提升也迫在眉睫，否则无法应对实例数量，变更频率，系统复杂度的快速增长;

观念的转变，基础设施，系统架构和运维平台等的大幅升级，犹如小米加步枪换成飞机大炮，相应的战略战术也需要与之相适配才行。

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

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

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

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

通过变量的方式尽量减少人工输入;

通过监控配置文件解析做一些可标准化的校验;

通过故障演练验证报警是否符合预期;

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

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

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

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

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

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

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

集群基于各种维度进行拆分(如地域维度、功能维度和产品维度等);

增加缓存服务来降低Hbase的读写压力;

调整使用频率较低指标的采集周期;

通过批量写入降低Hbase的写入压力;

通过写入两套Hbase避免数据丢失并做到故障后快速切换。

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

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

实时热加载服务注册信息;

对监控配置的合规性进行强校验;

增加实例数量的阈值保护;

支持配置的快速回滚。

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

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

基于报警接收人通过延时发送进行合并;

报警策略添加依赖关系;

优先发送严重故障的报警短信;

增加多种报警通知方式如电话，IM等。

作者：张婵

节选：infoq

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。