hyper 虚拟机监控程序功能对于该用户来说不可用_Java大型互联网-不一样的微服务架构性能监控系统与日志收集实现...

本文探讨了微服务架构的性能监控和日志收集的挑战,包括黑盒与白盒监控、常用工具如Prometheus和InfluxDB,以及日志收集方案如Fluentd和Logstash。文章强调了容器化环境下监控和日志管理的特殊性,并提供了选择和优化建议。
摘要由CSDN通过智能技术生成

引言

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。

微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。

微服务的性能监控与日志收集实现

微服务的复杂性

微服务相对于单体应用,在灵活性、可扩展性上要高很多,但是它的高灵活性是有一定代价的,这个代价主要在它的复杂性上。

微服务的复杂性体现在多个方面,首先从软件管理上来说,要管理一个微服务架构的产品,比管理一个单体应用产品要复杂得多,因为你需要管理很大的一个团队,并且每个团队有着不同的架构。对此,很多时候我们需要让开发者有自主的管理权,让他们可以自己做运维做部署。除此之外,对于服务调试来说,微服务的调试也比单体调试复杂得多,一旦一个产品线上出现问题,就需要开发团队更好更默契地去协调团队与团队之间服务的划分和调试。

另一个微服务的复杂性,还体现在微服务的基础设施上。以前单体应用升级服务的时候,平台可以决定什么时候能部署,但是对于SOA甚至微服务的架构来说,从平台来看,它所认为的每一个服务的部署基本上是无序的,它无法预测一个服务在什么时候被部署、部署几个、需要多少资源等等

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值