一、微服务架构带来的哪些变化
- 基础设施的升级,需要引入虚拟化(如Docker+K8S),现存基础设施也需要与之进行适配,统一部署产品,并实例化不同需求的镜像,通过客户的需求建立模型,方便回收,下载和管理;
- 系统架构的升级,需要引入服务注册(如Consul,入门见:https://www.jianshu.com/p/7d20dc58c9fc),服务间的交互方式也需要与之进行适配;
- 运维平台的升级,建议引入日志收集(如Fluentd,入门见:https://www.jianshu.com/p/09cbd7fb369a),分布式跟踪(如Zipkin,入门见:https://www.jianshu.com/p/f177a5e2917f)和仪表盘(如Vizceral/Grafana)等;
运维效率和自动化水平的提升也迫在眉睫,否则无法应对实例数量,变更频率,系统复杂度的快速增长;
二、微服务架构下用户面临的监控问题
首先,监控配置的维护成本增加。以前我们做的电商系统大概有100个模块,每个模块都需要添加端口监控,进程监控,日志监控和自定义监控;不同服务的监控指标,聚合指标,报警阈值,报警依赖,报警接收人,策略级别,处理预案和备注说明也不完全相同;如此多的内容,如何确保是否有效,是否生效,是否完整无遗漏。
当前针对维护成本,业界常用的几种方法有:
-
通过变量的方式尽量减少人工输入
-
通过监控配置文件解析做一些可标准化的校验
-
通过故障演练验证报警是否符合预期
其次,第三方依赖越来越多。例如Docker的可靠性很大程度上取决于宿主机状态,如果所在的宿主机发生资源争用,网络异常,硬件故障,修改内核参数,操作系统补丁升级等,都可能会让Docker莫名其妙地中招。
第三,服务故障的定位成本增加。假设故障是因为特定服务处理耗时增大导致的,那么如何快速从上百个服务以及众多的第三方依赖中把它找出来,进一步,又如何确认是这个服务的单个实例还是部分实例的异常,这些都让故障定位变得更复杂。
在微服务架构下,提高故障定位效率的常用方法有:基于各类日志分析,通过仪表盘展示核心指标:数据流,异常的监控策略,变更内容,线上登录和操作记录,文件修改等内容,对于文件的修改,是一个必不可少的需要观察的因素,因为目前很多客户私有环境去修改产品的标准的时候,记录需要监控。
三、微服务监控的难点及解决思路
在微服务架构下,监控系统在报警时效性不可改变的前提下,采集的指标数量是传统监控的三倍以上,如果是万台以上的规模,监控系统整体都面临非常大的压力,在监控方面的挑战主要来源于:
首先,存储功能的写入压力和可用性都面临巨大挑战。每秒写入几十万采集项并且需要保证99.99%的可用性,对于任何存储软件来讲,都不是一件轻松的事情。
对于写入和可用性的压力,业界常见的解决思路主要是基于如下方式的组合:
集群基于各种维度进行拆分(如地域维度、功能维度和产品维度等);
增加缓存服务来降低Hbase的读写压力;
调整使用频率较低指标的采集周期;
通过批量写入降低Hbase的写入压力;
通过写入两套Hbase避免数据丢失并做到故障后快速切换。
其次,监控的生效速度也面临巨大挑战。微服务架构下,基于弹性伸缩的加持,从服务扩容或者迁移完毕到接入流量的耗时降低到1Min左右,且每时每刻都在不断发生着。对于复杂监控系统来讲,支持这样的变更频率绝非易事,而且实例变更如此频繁,对监控系统自身来讲,也会面临可用性的风险。
常见的提高监控生效速度的思路主要有如下的几种方式:
实时热加载服务注册信息;
对监控配置的合规性进行强校验;
增加实例数量的阈值保护;
支持配置的快速回滚。
其次,基础设施的故障可能导致报警风暴的发生。基础设施如IDC故障,可能会在瞬时产生海量报警,进而导致短信网关拥塞较长时间。
解决这类问题的思路主要是如下方式:
-
基于报警接收人通过延时发送进行合并;
-
报警策略添加依赖关系;
-
优先发送严重故障的报警短信;
-
增加多种报警通知方式如电话、IM等。
四、解决产品部署的问题
主流产品有无数模块,对客户而言,针对不同的需求即可从产品列表中下载相应的模块,通过私有化环境配置设置,拉取需要的镜像环境并达到一键部署的目的;这样大大方便了运维部署成本;
其中因素及可解决策略:
- 客户在选择产品版本的同时,往往会忽略其他因素,这个时候需要服务扩展,再去拉取相应的模块或者功能,使用一段时间,需要增加服务模块,如何保证服务相接?(实际上K8S-Kebernetes就可以解决)
- 对于部署k8s可以更快的更新新版本,打包应用,更新的时候可以做到不用中断服务,服务器故障不用停机,从开发环境到测试环境到生产环境的迁移极其方便,一个配置文件搞定,一次生成image,到处运行。