编辑推荐: |
本文来自产品大牛,本文主要介绍了微服务"治理"的目标到底是什么以及通过原生
spring boot actuator 和 自定义扩展接口 对服务进行监控和治理。 |
|
前言
这几年微服务深入人心,大家都默契地达成了共识:"微服务是正确的"。那些老旧单一的大系统变成了洪水猛兽,再也不招人待见。多数人沉浸于用上了微服务的喜悦之中,却对微实施服务本身带来的成本和挑战避而不谈。我们稍加思索就能列举出用上微服务的团队已经或者即将遇到挑战:
1.如何正确地拆分服务,颗粒度设计跟业务密不可分
2.服务之间如何寻址,服务注册和发现
3.分布式,复杂度上升
4.一致性问题如何解决,放弃强一致性,追求最终一致性
5.独立部署更灵活,但部署次数指数上升
6.如何进行服务管理和监控
每一块都是难啃的骨头,今天我们就最后一条 - 如何进行服务管理和监控 展开聊聊。
作为资深老员工,我脑中经常浮现这样的场景:老板插着腰想着几百个微服务,喜形于色同时嘴角又有一丝失落夹杂着无奈
-- 美好的江山该如何治理。老板有诉求,我们就要定目标,可是微服务"治理"的目标到底是什么呢?
先定个小目标
基于买单侠实际情况,我们从不同角度思考和制定微服务"治理"的目标:
符合公司技术栈 - 微服务使用公司的微服务框架,公司的微服务框架本身扩展自 spring boot,并使用
eureka 进行注册和发现
要看得见也要摸得着 - 不能只有监控(读)能力,必须要有远程操控(写)能力
使用统一入口进行管理,并支持域账号登入以及权限控制
符合公司技术路线图 - 公司系统按颗粒度被分为 层>应用>服务>实例
实例:以java进程形式存在,一个服务可以有多个实例
服务:每个服务可以对应到代码仓库的一个项目,包含多个实例
应用:每个应用是一组相关服务的逻辑分组,包含多个服务
层:系统最粗颗粒度的维度,每个层包含多个应用
最后,样式别太丑
着手实施
google "spring boot 服务治理" 可以很快发现 spring
boot admin(以下简称sba)这个开源项目:
[图片摘自sba官网]
用一句话概括就是:通过UI集中化管理 spring boot 项目。
来张截图感受下:
[图片摘自sba官网]
主要功能有:
显示实例build-info
显示实例健康状态
显示实例详情,包括jvm/内存/线程指标
显示计数/计量指标,如数据库、缓存指标
显示和下载日志
显示环境变量配置,并支持刷新
动态调整日志级别
管理jmx beans
查看hystrix限流降级整合
实例状态变更通知
sba和实例连接有两种模式:
直连 - 顾名思义就是实例(需加入 sba client 依赖)和 sba server 直接通讯连接
通过spring cloud(如eureka、zookeeper、consul)连接 - 实例注册到
eureka,sba server 从 eureka 拉取实例信息(图中 uniconsole 是公司基于sba二次开发的服务,下同)
1 服务注册到 eureka
2 uniconsole 定期调用 eureka 获取服务列表
3 uniconsole 定期调用服务暴露的监控/治理接口
很显然,sba 大方向上满足我们的要求,并且非常方便扩展。
sba基本功能介绍
服务列表页
展示服务列表和快速搜索
服务版本号,git信息
通过health(健康状况)反应实例状态(UNKNOW,UP,DOWN,OFFLINE)
实例页
展示 实例 信息,并提供诸如 details,metrics,environment,logging,jmx
等信息。
自动根据实例情况获取内容,通过 actuator 接口获取
detail
详情信息,包括详细健康检查结果、JVM、内存等
metrics
指标信息
log
使用文件输出日志时,可以在这里远程查看
environment
服务当前所有环境变量(包含发布配置)
metadata信息红色高亮显示
配置文件中使用正则表达式配置需要匹配的敏感信息,被匹配的敏感信息将被屏蔽,使用 **** 代替
logging
通过JMX动态切换日志级别
JMX
JMX功能,通过jolokia动态更新当前MBean
*多数原生JMX操作麻烦,会以更容易理解和操作的方式单独暴露,如logging和服务治理
threads
当前线程信息
sba定制部分
作为统一入口
(图中 uniconsole 是公司基于sba二次开发的服务,下同)
服务列表页增强
展示服务列表和信息
热重启:框架调用指定实例的某个接口,重新加载class
冷重启就是调用运维的脚本,重启指定的服务下的所有实例
下拉框提供服务级别的disconf,zipkin,swagger,阿里日志等跳转界面
灰度按钮提供服务级别的灰度设置(只有当前服务是api gateway才会出现灰度按钮)
按公司系统特性定制层>应用>服务>实例
监控告警和治理
通过原生 spring boot actuator 和 自定义扩展接口 对服务进行监控和治理,并基于事件和可扩展规则,基于钉钉进行告警
集成LDAP和权限系统
正常情况下公司都有域控,我们也不例外,所以给sba加上域控变得理所应当。sba支持 spring security
并且自带了登入界面,基于此进行扩展
使用权限服务 用户/角色/权限 进行授权。权限包括前端和后端,按每个功能划分。
鉴权时使用两种角色(用户类型、应用)组合的方式,决定 当前用户(属于某类用户) 拥有 某个应用 的
某类操作权限。
角色(用户类型)决定 某类用户 拥有 某类操作权限,设定:运维(管理员),测试,开发
角色(应用)设定:按实际应用配置应用角色
举例:
配置 '开发角色',绑定权限 '查看disconf'
配置 '应用A角色'
配置 '用户B' 同时绑定 '开发角色' 和 'A应用角色'
则 '用户B' 拥有 '应用A' 的 '查看disconf' 权限
服务治理
服务端限流和降级
概述:别人的server不会把我们调死,我们的server不会因为自己慢把别人的server拖死。
背景:多次因访问量过大导致jetty线程池被打满引发整个系统不可用的事故。
技术:服务降级目前没有适用我们技术栈(jetty+jersey+resttemplate+jerseyclient)的开源产品,所以自行开发。
需求:提供一套服务端降级策略。
目标:通过配置文件,uniconsole的jmx界面,等方式来动态调节降级策略。
实现:通过增加jersey拦截器和springmvc拦截器的方式实现,在满足触发条件的情况下,执行降级策略。(该拦截器优先于其他mvc拦截器,但落后于jetty拦截器)
范围:针对jersey或springmvc接口级别
列表页
维护页
客户端限流和降级
概述:我们的server不会把别人的server调死,别人的server太慢不会把我们的server拖死。
背景:公司规范要求通过resttemplate或者jerseyclient发起restful请求,目前都没有提供方便的熔断机制,比如目标服务响应时间很慢,导致本服务jetty线程池全部等待,引发雪崩。
需求:套用hystrix,不想使用hystrix自带的注解aop方式,希望通过resttemplate或jerseyclient自身来提供熔断。
目标:通过简单的配置方式,使resttemplate套用hystrix,类似于LoadBalanced注解,以及配置方式对jerseyclient进行套用。
实现:通过给目标resttemplate增加httpclient拦截器方式,以及给jerseyclient增加jdk代理方式来实现。
列表页
维护页
客户端负载均衡
服务于服务之间采用客户端的负载均衡策略,包括下列:
"RoundRobinRule":"轮训(默认)"
"BestAvailableRule":"选择一个最小的并发请求的server"
"AvailabilityFilteringRule":"过滤掉那些因为一直连接失败的被标记为circuit
tripped的后端server,并过滤掉那些高并发的server"
"ZoneAvoidanceRule":"复合判断server所在区域的性能和server的可用性选择server"
"RandomRule":"随机选择"
"RetryRule":"对其他的负载均衡策略机上重试机制,默认重试3次"
"WeightedResponseTimeRule":"根据响应时间分配一个权重,响应时间越长,权重越小,被选中的可能性越低"
"ConsistentHashRule":"hash一致性规则,如果http请求的header中存在一个key['rest_consistent_key'],则按它的value进行一致性hash选择相同的那个server,如果不存在,则使用
网关灰度
买单侠使用ff4j(feature toggle)进行灰度管理,该功能针对灰度发布的ff4j.xml进行配置
disconf
买单侠使用disconf对服务运行时配置进行管理,该功能代理服务级别的disconf配置,支持多版本和三种不同类型的配置方式(key/value,property,file)
链路健康检查
服务级健康检查
目的:
只监控服务自身的健康状况,不关心其他服务。针对单个REST API调用
定义:
非常轻量的健康检查
测服务进程是否存活
轻量的的健康检查
检测到数据库和第三方(公司提供的) 服务的链路是否健康
系统级健康检查
目的:
监控系统内多个服务之间的交互情况,不关心其他系统。多个REST API调用
定义:
通过REST API调用,模拟系统的某些核心(只读)业务操作。
产品级健康检查
目的:
监控产品内多个系统 之间的交互情况。 多个REST API调用
定义:
通过REST API调用,模拟产品的某些核 心(只读)业务操作
依赖图
显示依赖图
工具服务索引页
增加索引页,将现有工具和服务分组展示
sba定制部分(待扩展)
服务metadata导出
动态服务依赖图
收录更多非敏感信息
监控加强和整合
审计信息 |