
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在前几期的文章中给大家简单介绍了微服务架构的一些基础知识等内容,而今天我们就通过案例分析来了解一下,微服务架构服务监控与测试方法分享。
服务监控和应急手段
服务监控,主要包括:日志监控、调用链跟踪、度量指标这几块构成,其中的每一块都是一个非常值得深入研究的领域。
大型分布式系统通常由成百上千的应用组成,机器数量也是动辄上千台,是不可能像很早以前一样ssh登录到服务器去执行tail、less的。我们先需要日志格式统一,日志路径统一,然后对日志进行采集、上报、快速分析、展示和预警。
前面讲“依赖治理”的时候已经了解到分布式系统间依赖的复杂性,调用链错综复杂,已经不可能依赖个人经验了。当发生故障或者性能问题的时候,我们需要能够“一目了然”、“顺藤摸瓜”,从而达到快速定位故障或者性能瓶颈的目的。
从应用视角,我们需要了解服务的调用量、成功率/错误率、响应时间等指标。同时,我们也关注线程池、慢查询、连接数等等。从业务方视角,我们需要关注**“当前订单数”、“下单总金额”**等类似的业务指标数据。这些指标数据都是跟时间维度相关的,我们需要将这些指标数据保存到时序数据库中,做聚合统计、排名然后展示或者预警;
限流,主要包括:页面限流、接口限流,访问来源或IP限流、单机限流、集群限流、网关限流、热点参数限流,自定义限流等;北京地铁口早晚高峰期的控制,就是的“限流”(通常分“匀速排队”和“快速失败”);
降级,从触发条件上可分为:手动降级和自动降级。从场景上又可以分为:一致性降级、完整性降级、用户体验降级、读写降级等;电商在高峰期资源紧张时关闭商品评论服务和推荐服务,这就是一种的“弃车保帅”的降级手段。此外,接口的自动熔断也是一种的降级手段;
关于依赖治理、容量规划、限流,降级等后面我会在后续稳定性保障体系的章节中展开仔细讲解
服务测试
服务发布上去之后怎么知道是不是OK的?如果有一个ops控制台,我可以选择服务后直接输入参数、轻松点击就能验证服务通畅是不是很爽?如果在开发联调,或者进行单元测试时,对方没有实现,双方只是确定了服务契约,那我们就需要可以轻松mock数据。在传统的测试体系中,我们通常分为:单元测试、集成测试、组件测试、端到端测试等,形成了的“测试金字塔模型”。
到了微服务时代,我们在“集成测试”时不同服务间的调用便成为了重点,于是引入了“契约测试”来保证服务提供者和消费者双方符合规范
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。