微服务架构转型需要关注的运维监控的技术和建议
一、微服务架构带来的哪些变化
- 基础设施的升级，需要引入虚拟化（如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，到处运行。
微服务架构转型需要关注的运维监控的技术和建议相关推荐
- 东方证券首席架构师樊建：企业微服务架构转型实践
樊建 读完需要 27 分钟 速读仅需 9 分钟 作者:樊建.舒逸 首发:infoQ,经作者授权转载 微服务架构是近几年受到各行业广泛追捧的技术之一,微服务架构具有轻型化.便捷化.敏捷化等特点,不仅能够 ...
- 基于统一开发平台的微服务架构转型升级之路 | 某国有大型银行案例
分享某国有大型银行统一开发平台的建设历程,重点介绍其当前正在建设的微服务开发平台中的关键点和实践经验. 转载本文需注明出处:微信公众号EAWorld,违者必究. 引言: 某银行是一家国有大型银行,从2 ...
- 单体应用到微服务架构转型-实践过程总结
点击上方"猿芯",选择"设为星标" 后台回复"1024",有份惊喜送给面试的你 原文 https://www.toutiao.com/art ...
- EDAS 4.0 助力企业一站式实现微服务架构转型与 K8s 容器化升级
作者:安绍飞 审核&校对:营火 编辑&排版:雯燕 前言 近年来,企业的数字化随着互联网的普及发展越来越快,技术架构也是几经更迭,尤其是在线业务部分.最开始企业的需求就是将业务尽可能在线 ...
- 微服务架构案例(06)：通过业务、应用、技术、存储方面，聊聊架构
更新进度(共6节): 源码地址:GitHub·点这里 || GitEE·点这里 章节 文章标题 01 项目技术选型简介,架构图解说明 02 业务架构设计,系统分层管理 03 数据库选型,业务数据设计规 ...
- 微服务架构谈（6）：从监控到故障定位
六.服务调用跟踪 众所周知,trace架构基本都源自Google Dapper. 下图为高德在基于trace基础上做的场景应用,比如服务状态自我诊断.监控追溯等. 上图为支付宝app通过无线网关的tr ...
- 运维经验分享：关于系统运维监控的几点建议
目前很多企业信息化系统都有自己的监控平台和监控手段,无论是采用哪种手段去实现对系统的实时监控和故障告警,大多采用的方式也只有两种:集中式监控和分布式监控.本文作者根据自身公司监控存在的问题,总结了一些 ...
- 关于系统运维监控的几点建议
眼下非常多企业信息化系统都有自己的监控平台和监控手段,不管是採用哪种手段去实现对系统的实时监控和故障告警,大多採用的方式也仅仅有两种:集中式监控和分布式监控.本文作者依据自身公司监控存在的问题,总结了 ...
- 架构 | 微服务架构下如何解耦，对于已经紧耦合下如何重构？
点击上方"朱小厮的博客",选择"设为星标" 当当满200减40优惠码「J2KNAE」 来源:知乎 今天准备谈下微服务架构下各个微服务间如何解耦,以及对于已经紧耦 ...
最新文章
- EAST 自然场景文本检测
- Function类型
- 用db-RDA进行微生物环境因子分析-“ggvegan“介绍
- 【 Vivado 】Working with Sources in Non-Project Mode
- 95-140-110-源码-transform-算子keyBy
- java对象与json对象间的相互转换的方法
- 小米 10 年再创业，高端 5G 手机和 AIoT 有多少机会？
- linux fls函数,Linux学习笔记- find 命令详解
- 数据结构之线性表学习一
- Flutter之EdgeInsetsGeometry简析
- Notepad++安装NppFTP插件
- 初探线程之线程竞争及故障
- unity透明物体显示问题
- java计算机毕业设计网上书店管理系统源码+系统+数据库+lw文档+mybatis+运行部署
- 西门子TIA portal中如何安装FANUC机器人的GSD文件
- c# 模拟串口通信 SerialPort
- 门面担当——外观模式
- 熬夜读书最好吃什么东西补充能量类``
- 场景化分析rem布局原理
- Java线程的同步和异步的区别