点击上方“程序猿技术大咖”,关注并选择“设为星标”
回复“加群”获取入群讨论资格!
导读
微服务架构挑战
软件架构的演进历程
首先我们先来看下软件架构的演进历程:
所谓平均故障间隔时间是指相邻两次故障之间的平均工作时间,也称为平均故障间隔。平均修复时间是从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。
MTBF:即平均故障间隔时间,英文全称是“Mean Time Between Failure”。是衡量一个产品(尤其是电器产品)的可靠性指标。单位为“小时”。
MTTR:全称是 Mean Time To Repair,即平均修复时间。是指可修复产品的平均修复时间,就是从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。
异步解耦:
在微服务应用中通过引入消息中间件将上游组合服务对下游多个微服务的同步调用进行异步解耦,基于消息的可靠投递能力快速响应用户请求,能够大幅提升服务并发访问性能及用户体验,并通过数据补偿手段保障数据最终一致性。
-
全局限流:基于简单计数、令牌桶算法,通过引入中间件如redis,针对整个集群流量进行全局控制。
从下图中可以看出,当 关入口的服务请求下游的单一服务接口,当服务B接口异常将导致入口请求夯住,占用 关请求资源,导致整体业务异常。
单元化架构部署
单元化架构是一种高级的高可用架构设计模式,通过对核心业务数据分片,应用服务无状态设计将相同领域的业务服务划分为一个个独立的部署单元,单元内整体业务闭环。通过单元化部署架构能够有效满足弹性伸缩,故障隔离,异地容灾等高可用建设要求。此外基于单元化部署可以实现以部署单元为基准,构建灵活的发布策略。
单元化架构产品能力:
-
关业务单元路由标签
-
支持跨单元横向调用
-
单元内服务容错兜底
弹性伸缩
通过配置动态伸缩规则,TSF中控服务基于agent上 的监控数据实现实时统计,满足流量激增自动扩容或流量低峰自动缩容能力,有效保障服务高效稳定及资源利用率提升。
服务熔断
TSF服务熔断能力支持服务、实例、API多维度的熔断隔离级别,提供控制台可视化配置及熔断事件展示,满足熔断配置热生效需求。
熔断器状态转换:
-
熔断器开始处于closed状态,一旦检测到错误(或慢响应)达到一定阈值,便转为open状态,此时不再调用下游目标服务。
-
一段时间后转化为half open状态,尝试放行一部分请求到下游服务。
-
一旦检测到响应成功,回归到closed状态,也即恢复服务;否则回到open状态。
健康检查与注册中心联动流程
健康检查分为存活检查及就绪检查;存活检查主要作用是确定进程存活状态,判断是否需要进行实例重启。就绪检查主要作用是确定服务实例能否支持对外服务,将健康检查结果与注册中心状态联动避免流量接入异常节点。
健康检查与注册中心联动流程
1.就绪检查,检查实例状态是否ready
2.如果就绪检查ready则更新实例注册状态为passing,反之则检查状态为cirtical
3.监听注册中心服务提供方实例状态变更
4.存在状态变更更新缓存及本地文件
5.发起服务调用
健康检查产品能力:
-
存活检查
-
就绪检查
-
多种探测方式:http,tcp,执行命令
-
支持虚机&容器部署
应用性能管理能力
最后我们从一个问题排查流程全局展示tsf应用性能管理能力:
-
用户收到监控平台发送的告警信息,确定异常基本信息。
-
通过服务依赖拓扑确定异常服务的上下游依赖关系,进行全局视图分析。
-
接下来可以服务接口调用情况确定是全局接口异常或是单一接口异常。
-
如果是全局接口异常说明服务提供方服务实例存在异常问题,找到对应的异常实例通过日志检索或JVM监控分析排查具体问题;如果是单一接口异常说明提供方接口逻辑处理,通过日志检索可排查具体问题。
-
当然也可以在全局视图分析后通过对直接服务进行调用链分析排查单笔请求的调用链路,通过调用链与日志联动排查具体异常。
感谢您的阅读,也欢迎您发表关于这篇文章的任何建议,关注我,技术不迷茫!
喜欢就点个”在看”呗,留言、转发朋友圈
文章知识点与官方知识档案匹配,可进一步学习相关知识Java技能树首页概览92921 人正在系统学习中
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!