在微服务架构中，当有服务不可用，如何快速确定影响，如何了解有哪些其他服务与不可以服务有关？

可以尝试使用微服务管理平台，一般都包含服务治理及全面数据化运营等功能，应该能满足您的需求。
服务治理：提供异构服务间的服务注册与发现/服务鉴权/服务路由/服务限流/分布式事务/分布式配置/分布式消息等基础微服务治理能力。
全面数据化运营:完整的资源、应用、服务数据跟踪，为企业提供完整数据化运营能力。数据与运维监控统一集成。构成完整监控、预警、问题跟踪分析可视化视图。
仅供参考。

你好，看了下你的问题，我说下我的看法，不知道理解得对不对：

CNI网络插件

云环境下，容器之间的网络通讯借助于云环境下的CNI插件，而目前的CNI可选的方案很多，比如Calico、flannel、Cilium、Terway、Weave Net以及Contiv。如果仅仅是想可视化容器的进出流量，目前的CNI方案中就有可选的方案，比如Cilium。Cilium使用了ebpf的特性，使得其可以在不修改linux内核源码的情况下，增加很多特性。目前Cilium可以可视化容器的进出流量，以及服务间的调用关系，不过cilium使用的ebpf特性要求linux内核最好在4.8.0以上，所以可能会存在兼容性的问题。

服务网格

当然，我理解你的问题应该是想在云环境下快速定位出问题的服务，以及对出问题的服务进行处理，比如熔断降级，那么现有的CNI方案肯定不满足你的需求。对于你的需求，可以借助于服务网格实现。那么什么是服务网格？服务网格是处理服务之间通信的基础设施层。简单理解，其在每个应用实例上面注入一个边车(sidecar)代理，这个边车接管了该服务的流量，即应用实例发出以及接收的流量都会被边车代理拦截到，由代理进行相关服务治理之后，再转发出去。如下图：

Istio目前支持链路追踪，主要借助于zipkin、Jaeger等开源方案，开启链路追踪的功能之后，就可以在网格上面跟踪相关的请求。不过目前的链路追踪的功能是侵入式的，这个需要应用进行配置，传送相关的链路追踪的字段即可。Istio不仅仅支持链路追踪，对应的边车代理也对接了prometheus，每个边车代理都会记录当前边车代理进出流量的请求（请求来源和请求去向），这样就可以借助prometheus+grafana监控整个网格上的服务，如果某个时间点的某个服务不可用，可以直接在监控上面看出，然后借助与Istio的服务治理的功能处理问题，比如设置断路器或者流量重定向等。

赞同服务网格ASM

由于开源的服务网格Istio功能上不大满足我们公司的需求，所以我们公司自己基于开源Istio服务网格上做深层定制自己的网格ASM（赞同服务网格），研发了自己的轻量级边车代理，不仅仅是支持了Istio的所有服务治理的功能，还增添了其他特性：

1. 支持Skywalking

不仅仅支持zipkin、Jaeger，还支持Skywalking，可以根据实际情况自由选择接入的链路追踪的方案。目前赞同服务网格ASM默认使用Skywalking。对于Skywalking，不仅仅可以看到相应的链路追踪的信息，也可以查看相关的服务拓扑图。当然对于链路追踪来说，并非是无侵入式的，需要应用帮忙传递相关链路追踪的字段。

2. 流控

开源的Istio的流控功能相对较弱，而ASM可以在QPS和并发数两个维度进行流量控制，并且可以根据请求的特性，比如path、header等，配置特定的流控策略。

3. 熔断

开源的Istio的断路器功能，不是真正意义上的熔断。而ASM提供了真正的熔断的功能，可根据异常数/异常比例/响应时间等情况进行配置相关的熔断策略，还可以直接配置强制熔断。强制熔断对于服务不可用的场景很有用，可以直接强制熔断掉不可用的服务，避免服务雪崩。

4. 协议适配/报文适配

赞同服务网格ASM不仅仅提供了大量的服务治理功能，还提供了协议/报文适配的功能，这解决了业务系统集成所面临的通信领域各种问题以及需求，帮助存量异构系统快速接入企业统一的云平台。

目前赞同服务网格ASM支持的功能不仅限于上面几点，由于篇幅原因这里不做过多介绍，主要是回答了你的疑问。

      使用微服务进行系统建设的时候，一般都会使用微服务框架，例如现在用的比较多的是使用SpringCloud，在部署微服务的时候，会进行服务调用链路跟踪，监控哪些服务是不可用的；SpringCloud的特点是现在使用人较多，但相应的组件比较多，且只能基于Java；目前下一代的容器化、微服务治理运行架构是基于ISTIO的Service Mesh方案，基本原理是容器化SideCar进行服务网格管理，例如Openshift上的ServiceMesh，可以对服务进行全链路跟踪，可以快速定位哪些服务不可用。

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