容器在运行时会有进出流量,如何需要提供流量可视性检测,或者可以说在微服务架构中,当有服务不可用,如何快速确定影响,如何了解有哪些其他服务与不可以服务有关
收起如果是在微服务架构下,那么您提的问题是很容易被解决的。但是不同的微服务框架的解决方案可能会有所不同。
先说springcloud架构,一种传统的微服务架构,基于SDK的微服务通信机制。在这类的微服务架构中有一个必要的组件就是注册中心,注册中心用于注册和发现服务,同时有服务实例不可用也会迅速感知,并将该服务的实例隔离,分布式高可用的场景下,通常不会影响业务。如果是整个服务不可用,想要知道影响面,说白了就是想知道服务间依赖关系,一般都有APM组件做观测使用,绘制出的拓扑图可以直观的看到哪些服务不可用,并且关联到影响面。
再说Istio架构,是一种新型的微服务网格类架构,基于sidecar截流的通信机制。在这类网格类架构中,通常也有一个类似于注册中心的机制,比如Istio使用的k8s的服务发现机制,在服务通信中,k8s会检测到运行故障,通过销毁重置pod解决,Istio的连接池管理也会检测到服务的通信故障,通过熔断的机制将故障实例隔离。很少情况下会出现整个服务不可用,如果真的出现整个服务不可用的情况,与传统微服务的呈现方式一样,也是会有一个拓扑图或者服务地图来展示每个服务的运行情况,并展示其依赖关系。不同的是,传统的微服务可能需要APM,而Istio架构的会通过sidecar自行收集观测信息,并通过相应的dashboard展示。
其实只要做了微服务的运行观测平台,这些都是基础功能,都是在平台中可以直观看到的