大家好,我是老三,面渣逆袭系列继续,这期给大家带来微服务相关的面试题。
微服务(Microservices)是一种软件架构风格,将一个大型应用程序划分为一组小型、自治且松耦合的服务。每个微服务负责执行特定的业务功能,并通过轻量级通信机制(如HTTP)相互协作。每个微服务可以独立开发、部署和扩展,使得应用程序更加灵活、可伸缩和可维护。
在微服务的架构演进中,一般可能会存在这样的演进方向:单体式-->服务化-->微服务。
单体服务一般是所有项目最开始的样子:
后来,单体服务过大,维护困难,渐渐演变到了分布式的SOA:
需要注意的是,微服务是一种特定的架构风格,而SOA是一种设计原则。微服务可以看作是对SOA思想的一种具体实践方式,但并不等同于SOA。
架构演进简图微服务与单体服务的区别在于规模和部署方式。微服务将应用程序拆分为更小的、自治的服务单元,每个服务都有自己的数据库和代码库,可以独立开发、测试、部署和扩展,带来了更大的灵活性、可维护性、可扩展性和容错性。
微服务架构不是万金油,尽它有很多优点,但是对于是否采用微服务架构,是否将原来的单体服务进行拆分,还是要考虑到服务拆分后可能带来的一些挑战和问题:
微服务带来的挑战1. 系统复杂性增加:一个服务拆成了多个服务,整体系统的复杂性增加,需要处理服务之间的通信、部署、监控和维护等方面的复杂性。
2. 服务间通信开销:微服务之间通过网络进行通信,传递数据需要额外的网络开销和序列化开销,可能导致性能瓶颈和增加系统延迟。
3. 数据一致性和事务管理:每个微服务都有自己的数据存储,数据一致性和跨服务的事务管理变得更加复杂,需要额外解决分布式事务和数据同步的问题。
4. 部署和运维复杂性:微服务架构涉及多个独立部署的服务,对于部署、监控和容错机制的要求更高,需要建立适当的部署管道和自动化工具,以简化部署和运维过程。
5. 团队沟通和协作成本:每个微服务都由专门的团队负责,可能增加团队之间的沟通和协作成本。需要有效的沟通渠道和协作机制,确保服务之间的协调和一致性。
6. 服务治理和版本管理:随着微服务数量的增加,服务的治理和版本管理变得更加复杂。需要考虑服务的注册发现、负载均衡、监控和故障处理等方面,以确保整个系统的可靠性和稳定性。
7. 分布式系统的复杂性:微服务架构涉及构建和管理分布式系统,而分布式系统本身具有一些固有的挑战,如网络延迟、分布式一致性和容错性。
简单说,采用微服务需要权衡这些问题和挑战,根据实际的需求来选择对应的技术方案,很多时候单体能搞定的也可以用单体,不能为了微服务而微服务。
目前最主流的微服务开源解决方案有三种:
Dubbo工作原理图-来源官网
三种方案的区别:
特点DubboSpring Cloud NetflixSpring Cloud Alibaba开发语言JavaJavaJava服务治理提供完整的服务治理功能提供部分服务治理功能提供完整的服务治理功能服务注册与发现ZooKeeper/NacosEureka/ConsulNacos负载均衡自带负载均衡策略RibbonRibbon\Dubbo负载均衡策略服务调用RPC方式RestTemplate/FeignFeign/RestTemplate/Dubbo熔断器SentinelHystrixSentinel/Resilience4j配置中心ApolloSpring Cloud ConfigNacos ConfigAPI网关Higress/APISIXZuul/GatewaySpring Cloud Gateway分布式事务Seata不支持分布式事务Seata限流和降级SentinelHystrixSentinel分布式追踪和监控SkywalkingSpring Cloud Sleuth + ZipkinSkyWalking或Sentinel Dashboard微服务网格Dubbo Mesh不支持微服务网格Service Mesh(Nacos+Dubbo Mesh)社区活跃度相对较高目前较低相对较高孵化和成熟度孵化较早,成熟度较高成熟度较高孵化较新,但迅速发展
在面试中,微服务一般主要讨论的是Spring Cloud Netflix,其次是Spring Cloud Alibaba,Dubbo更多的是作为一个RPC框架来问。
微服务给系统开发带来了一些问题和挑战,如服务调用的复杂性、分布式事务的处理、服务的动态管理等。为了更好地解决这些问题和挑战,各种微服务治理的组件应运而生,充当微服务架构的基石和支撑。
微服务组件示意图微服务的各个组件和常见实现:
注册中心是用来管理和维护分布式系统中各个服务的地址和元数据的组件。它主要用于实现服务发现
和服务注册
功能。
注册中心示意图总结一下注册中心的作用:
SpringCloud可以与多种注册中心进行集成,常见的注册中心包括:
特性EurekaZooKeeperNacos开发公司NetflixApache 基金会阿里巴巴CAPAP(可用性和分区容忍性)CP(一致性和分区容忍性)既支持AP,也支持CP功能服务注册与发现分布式协调、配置管理、分布式锁服务注册与发现、配置管理、服务管理定位适用于构建基于 HTTP 的微服务架构通用的分布式协调服务框架适用于微服务和云原生应用访问协议HTTPTCPHTTP/DNS自我保护支持-支持数据存储内嵌数据库、多个实例形成集群ACID 特性的分布式文件系统 ZAB 协议内嵌数据库、MySQL 等健康检查Client BeatKeep AliveTCP/HTTP/MYSQL/Client Beat特点简单易用、自我保护机制高性能、强一致性动态配置管理、流量管理、灰度发布等可以看到Eureka和ZooKeeper的最大区别是一个支持AP
,一个支持CP
,Nacos既支持既支持AP
,也支持CP
。
Eureka原理示意图Eureka的实现原理,大概可以从这几个方面来看:
其它的注册中心,如Nacos、Consul等等,在服务注册和发现上,实现原理都是大同小异。
Eureka Server保证高可用,主要通过这三个方面来实现:
Eureka Server1. 多实例部署: 通过将多个Eureka Server实例部署在不同的节点上,可以实现高可用性。当其中一个实例发生故障时,其他实例仍然可以提供服务,并保持注册信息的一致性。
2. 服务注册信息的复制: 当一个服务实例向Eureka Server注册时,每个Eureka Server实例都会复制其他实例的注册信息,以保持数据的一致性。当某个Eureka Server实例发生故障时,其他实例可以接管其工作,保证整个系统的正常运行。
3. 自我保护机制: Eureka还具有自我保护机制。当Eureka Server节点在一定时间内没有接收到心跳时,它会进入自我保护模式。在自我保护模式下,Eureka Server不再剔除注册表中的服务实例,以保护现有的注册信息。这样可以防止由于网络抖动或其他原因导致的误剔除,进一步提高系统的稳定性。
微服务架构中的每个服务通常都需要一些配置信息,例如数据库连接地址、服务端口、日志级别等。这些配置可能因为不同环境、不同部署实例或者动态运行时需要进行调整和管理。
微服务的实例一般非常多,如果每个实例都需要一个个地去做这些配置,那么运维成本将会非常大,这时候就需要一个集中化的配置中心,去管理这些配置。
和注册中心一样,SpringCloud也支持对多种配置中心的集成。常见的配置中心选型包括:
配置中心,说白了就是一句话:配置信息的CRUD。
配置中心具体的实现大概可以分成这么几个部分:
一般来说客户端和服务端的交互分为两种:推(Push)
和拉(Pull)
,Nacos在Pull
的基础上,采用了长轮询来进行配置的动态刷新。
在长轮询模式下,客户端定时向服务端发起请求,检查配置信息是否发生变更。如果没有变更,服务端会"hold"住这个请求,即暂时不返回结果,直到配置发生变化或达到一定的超时时间。
具体的实现过程如下:
Nacos长轮询1. 客户端发起Pull请求,服务端检查配置是否有变更。如果没有变更,则设置一个定时任务,在一段时间后执行,并将当前的客户端连接加入到等待队列中。
2. 在等待期间,如果配置发生变更,服务端会立即返回结果给客户端,完成一次"推送"操作。
3. 如果在等待期间没有配置变更,等待时间达到预设的超时时间后,服务端会自动返回结果给客户端,即使配置没有变更。
4. 如果在等待期间,通过Nacos Dashboard或API对配置进行了修改,会触发一个事件机制,服务端会遍历等待队列,找到发生变更的配置项对应的客户端连接,并将变更的数据通过连接返回,完成一次"推送"操作。
通过长轮询的方式,Nacos客户端能够实时感知配置的变化,并及时获取最新的配置信息。同时,这种方式也降低了服务端的压力,避免了大量的长连接占用内存资源。
严格来讲,HTTP和不是一个层面的东西:
HTTP和RPC- HTTP(Hypertext Transfer Protocol)是一种应用层协议,主要强调的是网络通信;
一些RPC框架比如gRPC,底层传输协议其实也是用的HTTP2,包括Dubbo3,也兼容了gRPC,使用了HTTP2作为传输层的一层协议。
如果硬要说区别的话,如下:
HTTPRPC 定义HTTP(超文本传输协议)是一种用于传输超文本的协议。RPC(远程过程调用)是一种用于实现分布式系统中不同节点之间通信的协议。通信方式基于请求-响应模型,客户端发送请求,服务器返回响应。基于方法调用模型,客户端调用远程方法并等待结果。传输协议基于TCP协议,可使用其他传输层协议如TLS/SSL进行安全加密。可以使用多种传输协议,如TCP、UDP等。数据格式基于文本,常用的数据格式有JSON、XML等。可以使用各种数据格式,如二进制、JSON、Protocol Buffers等。接口定义使用RESTful风格的接口进行定义,常用的方法有GET、POST、PUT、DELETE等。使用IDL(接口定义语言)进行接口定义,如Protocol Buffers、Thrift等。跨语言性支持跨语言通信,可以使用HTTP作为通信协议实现不同语言之间的通信。支持跨语言通信,可以使用IDL生成不同语言的客户端和服务端代码。灵活性更加灵活,适用于不同类型的应用场景,如Web开发、API调用等。更加高效,适用于需要高性能和低延迟的分布式系统。在微服务体系里,基于HTTP风格的远程调用通常使用框架如Feign来实现,基于RPC的远程调用通常使用框架如Dubbo来实现。
这两个才是适合拿来比较的东西:
FeignDubbo定义Feign是一个声明式的Web服务客户端,用于简化HTTP API的调用。Dubbo是一个分布式服务框架,用于构建面向服务的微服务架构。通信方式基于HTTP协议,使用RESTful风格的接口进行定义和调用。基于RPC协议,支持多种序列化协议如gRPC、Hessian等。服务发现通常结合服务注册中心(如Eureka、Consul)进行服务发现和负载均衡。通过ZooKeeper、Nacos等进行服务注册和发现,并提供负载均衡功能。服务治理不直接提供服务治理功能,需要结合其他组件或框架进行服务治理。提供服务注册与发现、负载均衡、容错机制、服务降级等服务治理功能。跨语言性支持跨语言通信,可以使用HTTP作为通信协议实现不同语言之间的通信。支持跨语言通信,通过Dubbo的IDL生成不同语言的客户端和服务端代码。生态系统集成了Spring Cloud生态系统,与Spring Boot无缝集成。拥有完整的生态系统,包括注册中心、配置中心、监控中心等组件。适用场景适用于构建RESTful风格的微服务架构,特别适合基于HTTP的微服务调用。适用于构建面向服务的微服务架构,提供更全面的服务治理和容错机制。需要注意的是,Feign和Dubbo并不是互斥的关系。实际上,Dubbo可以使用HTTP协议作为通信方式,而Feign也可以集成RPC协议进行远程调用。选择使用哪种远程调用方式取决于具体的业务需求和技术栈的选择。
Feign是一个声明式的Web服务客户端,它简化了使用基于HTTP的远程服务的开发。
Feign是在RestTemplate 和 Ribbon的基础上进一步封装,使用RestTemplate实现Http调用,使用Ribbon实现负载均衡。
Feign封装Feign的主要特点和功能包括:
@FeignClient(name = "example", url = "https://api.example.com")
public interface ExampleService {
@GetMapping("/endpoint")
String getEndpointData();
}
主要原因是由于Ribbon的懒加载机制,当第一次调用发生时,Feign会触发Ribbon的加载过程,包括从服务注册中心获取服务列表、建立连接池等操作,这个加载过程会增加首次调用的耗时。
ribbon:
eager-load:
enabled: true
clients: service-1
那怎么解决这个问题呢?
可以在应用启动时预热Feign客户端,自动触发一次无关紧要的调用,来提前加载Ribbon和其他相关组件。这样,就相当于提前进行了第一次调用。
比较常见的一个做法是,使用拦截器传递认证信息
。可以通过实现RequestInterceptor
接口来定义拦截器,在拦截器里,把认证信息添加到请求头中,然后将其注册到Feign的配置中。
@Configuration
public class FeignClientConfig {
@Bean
public RequestInterceptor requestInterceptor() {
return new RequestInterceptor() {
@Override
public void apply(RequestTemplate template) {
// 添加认证信息到请求头中
template.header("Authorization", "Bearer " + getToken());
}
};
}
private String getToken() {
// 获取认证信息的逻辑,可以从SecurityContext或其他地方获取
// 返回认证信息的字符串形式
return "your_token";
}
}
在Feign中,负载均衡是通过集成Ribbon来实现的。
Ribbon是Netflix开源的一个客户端负载均衡器,可以与Feign无缝集成,为Feign提供负载均衡的能力。
Ribbon通过从服务注册中心获取可用服务列表,并通过负载均衡算法选择合适的服务实例进行请求转发,实现客户端的负载均衡。
常见的负载均衡算法包含以下几种:
常见负载均衡算法1. 轮询算法(Round Robin):轮询算法是最简单的负载均衡算法之一。它按照顺序将请求依次分配给每个后端服务器,循环往复。当请求到达时,负载均衡器按照事先定义的顺序选择下一个服务器。轮询算法适用于后端服务器具有相同的处理能力和性能的场景。
2. 加权轮询算法(Weighted Round Robin):加权轮询算法在轮询算法的基础上增加了权重的概念。每个后端服务器都被赋予一个权重值,权重值越高,被选中的概率就越大。这样可以根据服务器的处理能力和性能调整请求的分配比例,使得性能较高的服务器能够处理更多的请求。
3. 随机算法(Random):随机算法将请求随机分配给后端服务器。每个后端服务器有相等的被选中概率,没有考虑服务器的实际负载情况。这种算法简单快速,适用于后端服务器性能相近且无需考虑请求处理能力的场景。
4. 加权随机算法(Weighted Random):加权随机算法在随机算法的基础上引入了权重的概念。每个后端服务器被赋予一个权重值,权重值越高,被选中的概率就越大。这样可以根据服务器的处理能力和性能调整请求的分配比例。
5. 最少连接算法(Least Connection):最少连接算法会根据后端服务器当前的连接数来决定请求的分配。负载均衡器会选择当前连接数最少的服务器进行请求分配,以保证后端服务器的负载均衡。这种算法适用于后端服务器的处理能力不同或者请求的处理时间不同的场景。
6. 哈希算法(Hash):哈希算法会根据请求的某个特定属性(如客户端IP地址、请求URL等)计算哈希值,然后根据哈希值选择相应的后端服务器。
常见的负载均衡器,比如Ribbion、Gateway等等,基本都支持这些负载均衡算法。
关于Dubbo,后面会单独出一期。
在微服务中,假如一个或者多个服务出现故障,如果这时候,依赖的服务还在不断发起请求,或者重试,那么这些请求的压力会不断在下游堆积,导致下游服务的负载急剧增加。不断累计之下,可能会导致故障的进一步加剧,可能会导致级联式的失败,甚至导致整个系统崩溃,这就叫服务雪崩。
服务雪崩一般,为了防止服务雪崩,可以采用这些措施:
服务熔断是微服务架构中的容错机制,用于保护系统免受服务故障或异常的影响。当某个服务出现故障或异常时,服务熔断可以快速隔离该服务,确保系统稳定可用。
它通过监控服务的调用情况,当错误率或响应时间超过阈值时,触发熔断机制,后续请求将返回默认值或错误信息,避免资源浪费和系统崩溃。
服务熔断还支持自动恢复,重新尝试对故障服务的请求,确保服务恢复正常后继续使用。
服务降级是也是一种微服务架构中的容错机制,用于在系统资源紧张或服务故障时保证核心功能的可用性。
当系统出现异常情况时,服务降级会主动屏蔽一些非核心或可选的功能,而只提供最基本的功能,以确保系统的稳定运行。通过减少对资源的依赖,服务降级可以保证系统的可用性和性能。
它可以根据业务需求和系统状况来制定策略,例如替换耗时操作、返回默认响应、返回静态错误页面等。
目前常见的服务熔断降级实现方案有这么几种:
框架实现方案特点Spring CloudNetflix Hystrix- 提供线程隔离、服务降级、请求缓存、请求合并等功能
尽管已经不再更新,但是Hystrix是非常经典的服务容错开源库,它提供了多种机制来保护系统:
Hystrix服务容错六大机制1. 服务熔断(Circuit Breaker):Hystrix通过设置阈值来监控服务的错误率或响应时间。当错误率或响应时间超过预设的阈值时,熔断器将会打开,后续的请求将不再发送到实际的服务提供方,而是返回预设的默认值或错误信息。这样可以快速隔离故障服务,防止故障扩散,提高系统的稳定性和可用性。
2. 服务降级(Fallback):当服务熔断打开时,Hystrix可以提供一个备用的降级方法或返回默认值,以保证系统继续正常运行。开发者可以定义降级逻辑,例如返回缓存数据、执行简化的逻辑或调用其他可靠的服务,以提供有限但可用的功能。
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
/**
* 服务降级示例
**/
@Service
public class MyService {
@HystrixCommand(fallbackMethod = "fallbackMethod")
public String myServiceMethod() {
// 实际的服务调用逻辑
// ...
}
public String fallbackMethod() {
// 降级方法的逻辑,当服务调用失败时会执行此方法
// 可以返回默认值或执行其他备用逻辑
// ...
}
}
Sentinel通过动态管理限流规则,根据定义的规则对请求进行限流控制。具体实现步骤如下:
// 原本的业务方法.
@SentinelResource(blockHandler = "blockHandlerForGetUser")
public User getUserById(String id) {
throw new RuntimeException("getUserById command failed");
}
// blockHandler 函数,原方法调用被限流/降级/系统保护的时候调用
public User blockHandlerForGetUser(String id, BlockException ex) {
return new User("admin");
}
private static void initFlowQpsRule() {
List<FlowRule> rules = new ArrayList<>();
FlowRule rule1 = new FlowRule();
rule1.setResource(resource);
// Set max qps to 20
rule1.setCount(20);
rule1.setGrade(RuleConstant.FLOW_GRADE_QPS);
rule1.setLimitApp("default");
rules.add(rule1);
FlowRuleManager.loadRules(rules);
}
Sentinel控制台4. 限流控制:当请求到达时,Sentinel会根据资源的限流规则判断是否需要进行限流控制。如果请求超过了限流阈值,则可以进行限制、拒绝或进行其他降级处理。
Sentinel总体框架-来源官网
Sentinel使用滑动窗口限流算法来实现限流。
滑动窗口限流算法是一种基于时间窗口的限流算法。它将一段时间划分为多个时间窗口,并在每个时间窗口内统计请求的数量。通过动态地调整时间窗口的大小和滑动步长,可以更精确地控制请求的通过速率。
滑动窗口限流可以查看前面的分布式篇。
Sentinel利用了Token Server和Token Client的机制来实现集群限流。
开启集群限流后,Client向Token Server发送请求,Token Server根据配置的规则决定是否限流。T
Token Server和Client
API网关(API Gateway)是一种中间层服务器,用于集中管理、保护和路由对后端服务的访问。它充当了客户端与后端服务之间的入口点,提供了一组统一的接口来管理和控制API的访问。
网关示意图API网关的主要功能包括:
……
通过使用API网关,可以简化前端与后端服务的交互,提供统一的接口和安全性保障,同时也方便了服务治理和监控。它是构建微服务架构和实现API管理的重要组件之一。
使用SpringCloud开发,可以采用以下的API网关选型:
……
Gateway原理在Spring Cloud Gateway里,有三个关键组件:
我们再来看下Spring Cloud Gateway的具体工作流程:
SpringCloud工作流程图-来源官方文档又有两个比较重要的概念:
在微服务中,有的山下游可能有十几个服务,如果某一环出了问题,排查起来非常困难,所以,就需要进行链路追踪,来帮助排查问题。
SkyWalking界面通过链路追踪,可以可视化地追踪请求从一个微服务到另一个微服务的调用情况。除了排查问题,链路追踪黑还可以帮助优化性能,可视化依赖关系、服务监控和告警。
Spring Cloud提供了多种选择的微服务链路追踪方案。以下是一些常用的方案:
Zipkin界面2. Jaeger:Jaeger 是 Uber 开源的分布式追踪系统,也被纳入了 CNCF(云原生计算基金会)的维护。通过使用 Spring Cloud Sleuth 和 Jaeger 客户端库,可以将追踪信息发送到 Jaeger 并进行可视化展示和查询。
3. SkyWalking:Apache SkyWalking 是一款开源的应用性能监控与分析系统,提供了对 Java、.NET 和 Node.js 等语言的支持。它可以与 Spring Cloud Sleuth 集成,将追踪数据发送到 SkyWalking 服务器进行可视化展示和分析。
SkyWalking示例界面4. Pinpoint:Pinpoint 是 Naver 开源的分布式应用性能监控系统,支持 Java 和 .NET。它提供了与 Spring Cloud Sleuth 的集成,可以将追踪数据发送到 Pinpoint 服务器,并通过其 UI 进行分析和监控。
Pinpoint示意图这些方案都可以与 Spring Cloud Sleuth 进行集成,Spring Cloud Sleuth 是 Spring Cloud 中的一个组件,提供了在微服务调用时生成追踪信息的能力。
分布式事务可以查看前面的分布式基础篇。
Seata以下几种模式的分布式事务:
AT模式示意图2. TCC(Try-Confirm-Cancel)模式:TCC模式是一种基于补偿机制的分布式事务模式。在TCC模式中,业务逻辑需要实现Try、Confirm和Cancel三个阶段的操作。Seata通过调用业务代码中的Try、Confirm和Cancel方法,并在每个阶段记录相关的操作日志,来实现分布式事务的一致性。
Seata TCC模式3. SAGA模式:SAGA模式是一种基于事件驱动的分布式事务模式。在SAGA模式中,每个服务都可以发布和订阅事件,通过事件的传递和处理来实现分布式事务的一致性。Seata提供了与SAGA模式兼容的Saga框架,用于管理和协调分布式事务的各个阶段。
SAGA模式状态机引擎4. XA模式:XA模式是一种基于两阶段提交(Two-Phase Commit)协议的分布式事务模式。在XA模式中,Seata通过与数据库的XA事务协议进行交互,实现对分布式事务的管理和协调。XA模式需要数据库本身支持XA事务,并且需要在应用程序中配置相应的XA数据源。
Seata的实现原理主要包括三个核心组件:事务协调器(Transaction Coordinator)、事务管理器(Transaction Manager)和资源管理器(Resource Manager)。
Seata领域模型Seata的实现原理基于两阶段提交(Two-Phase Commit)协议,具体的机制如下:
Seata事务的执行流程可以简要概括为以下几个步骤:
全局事务ID和分支事务ID在分布式事务中通过上下文传递的方式进行传递。常见的传递方式包括参数传递、线程上下文传递和消息中间件传递。具体的传递方式可以根据业务场景和技术选型进行选择和调整。
事务日志记录Seata的事务回滚是通过回滚日志实现的。每个参与者在执行本地事务期间生成回滚日志,记录了对数据的修改操作。
当需要回滚事务时,事务协调器向参与者发送回滚请求,参与者根据回滚日志中的信息执行撤销操作,将数据恢复到事务开始前的状态。
回滚日志的管理和存储是Seata的核心机制,可以选择将日志存储在不同的介质中。通过回滚日志的持久化和恢复,Seata确保了事务的一致性和恢复性。
我们使用Prometheus和Grafana来实现整个微服务集群的监控和告警:
日志收集有很多种方案,我们用的是ELK
:
简单说,这三者里Elasticsearch提供数据存储和检索能力,Logstash负责将日志收集到ES,Kibana负责日志数据的可视化分析。
使用ELK进行微服务日志收集的一般流程如下:
ELK流程1. 在每个微服务中配置日志输出:将微服务的日志输出到标准输出(stdout)或日志文件。
2. 使用Logstash收集日志:配置Logstash收集器,通过配置输入插件(如文件输入、网络输入等)监听微服务的日志输出,并进行过滤和处理。
3. 将日志数据发送到Elasticsearch:配置Logstash的输出插件,将经过处理的日志数据发送到Elasticsearch进行存储和索引。
4. 使用Kibana进行可视化和分析:通过Kibana连接到Elasticsearch,创建仪表盘、图表和搜索查询,实时监控和分析微服务的日志数据。
除了应用最广泛的ELK,还有一些其它的方案比如Fluentd
、Graylog
、Loki
、Filebeat
,一些云厂商也提供了付费方案,比如阿里云的sls
。
参考:
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8