您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
聊聊微服务治理那些事
 
  4868  次浏览      15
 2019-8-8
 
编辑推荐:

本文来自产品大牛,本文主要介绍了微服务"治理"的目标到底是什么以及通过原生 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导出

动态服务依赖图

收录更多非敏感信息

监控加强和整合

审计信息

   
4868 次浏览       15
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践