微服务 Spring Cloud 10,如何追踪微服务调用?服务治理的常见手段
作者:mmseoamin日期:2023-12-25

微服务 Spring Cloud 10,如何追踪微服务调用?服务治理的常见手段,在这里插入图片描述,第1张

目录

    • 一、服务追踪的作用
      • 1、优化系统瓶颈
      • 2、优化链路调用
      • 3、故障排查
      • 4、性能优化
      • 5、生成网络拓扑图
      • 4、透明传输数据
      • 二、节点管理
        • 1、服务调用失败一般有两类原因造成:
        • 2、服务调用失败的解决方式:
        • 3、服务调用失败的具体解决方式:
        • 三、负载均衡
          • 1、随机算法
          • 2、轮询算法
          • 3、最少活跃调用算法
          • 4、一致性Hash算法
          • 5、自适应最优选择算法
          • 四、如何选择负载均衡算法
            • 1、系统的特点和需求
            • 2、节点的性能和配置
            • 3、算法的复杂度和性能
            • 4、算法的可扩展性和可维护性
            • 五、服务路由
              • 1、灰度发布
              • 2、多机房就近访问
              • 3、服务路由如何配置
              • 六、服务路由的应用场景
                • 1、分组调用
                • 2、灰度发布
                • 3、流量切换
                • 4、读写分离
                • 七、服务容错
                  • 1、FailOver,失败自动切换
                  • 2、FailBack,失败通知
                  • 3、FailCache,失败缓存
                  • 4、FailFast,快速失败
                  • 八、总结
                  • 微服务 Spring Cloud系列

                    大家好,我是哪吒。

                    在微服务架构下,由于进行了服务拆分,一次请求往往需要涉及多个服务,每个服务可能是由不同的团队开发,使用了不同的编程语言,还有可能部署在不同的机器上,分布在不同的数据中心。

                    如果有一个系统,可以跟踪记录一次用户请求都发起了哪些调用,经过哪些服务处理,并且记录每一次调用所涉及的服务的详细信息,这时候如果发生调用失败,你就可以通过这个日志快速定位是在哪个环节出了问题,这个系统就是今天我要讲解的服务追踪系统。

                    一、服务追踪的作用

                    1、优化系统瓶颈

                    通过记录调用经过的每一条链路上的耗时,可以快速定位整个系统的瓶颈点在哪里。这些耗时数据可以帮助发现系统中的性能问题、错误和异常,从而针对性地进行优化。

                    2、优化链路调用

                    通过服务追踪可以分析调用所经过的路径,然后评估是否合理。比如一个服务调用下游依赖了多个服务,通过调用链分析,可以评估是否每个依赖都是必要的,是否可以通过业务优化来减少服务依赖。

                    一般情况下,为了容灾,会有双活数据中中心,数据中心一般会部署在相距较远的位置,之间的访问肯定比较耗时。

                    通过链路分析,可以分析出是否有数据中心A调用了数据中心B的某服务,而没有调用自家数据中心的该服务。

                    3、故障排查

                    当系统出现故障时,通过服务追踪可以快速定位到问题所在,帮助开发人员迅速解决问题。

                    4、性能优化

                    通过服务追踪可以分析系统的性能瓶颈,从而针对性地进行优化。比如可以对数据库进行优化、对网络连接进行优化等。

                    5、生成网络拓扑图

                    服务追踪可以生成网络拓扑图,帮助开发人员更好地了解系统中的服务调用关系和链路性能。这些拓扑图可以展示服务之间的依赖关系、调用路径、调用频次等信息,从而帮助开发人员快速定位问题、优化系统性能和稳定性。

                    在生成网络拓扑图时,需要收集系统中各个服务之间的调用信息,包括调用时间、调用方和被调用方的IP地址、端口号等信息。这些信息可以通过在服务调用中添加追踪信息或者使用专门的追踪工具来收集。然后,将收集到的信息进行处理和分析,并生成网络拓扑图。

                    在生成的拓扑图中,可以标注出各个服务节点的名称、位置、状态等信息,同时也可以展示出服务之间的调用关系、调用频次、响应时间等信息。开发人员可以通过观察拓扑图来快速了解整个系统的运行情况,定位问题所在,针对性地进行优化。

                    服务追踪生成的拓扑图是一种非常有用的工具,可以帮助开发人员更好地了解系统中的服务调用关系和链路性能,优化系统性能和稳定性。

                    4、透明传输数据

                    服务追踪的透明传输数据是指在不改变现有系统架构和数据格式的情况下,通过在数据传输过程中添加追踪信息,实现对系统调用的跟踪和监控。

                    具体来说,服务追踪系统可以在数据传输过程中,将一些额外的追踪信息(如traceId、spanId等)添加到数据包中,以标识一次请求的完整调用链路。这些追踪信息可以在服务调用中传递,并被服务追踪系统收集和分析,从而实现对系统调用的透明监控。

                    通过透明传输数据,服务追踪系统可以实现对系统调用的详细跟踪和监控,帮助开发人员快速定位问题、优化系统性能和稳定性。同时,透明传输数据也不会改变现有系统的数据格式和架构,不会对系统的正常运行产生影响。

                    服务追踪的透明传输数据是一种非常实用的技术,可以帮助开发人员更好地了解系统中的服务调用关系和链路性能,优化系统性能和稳定性。同时,它也不会改变现有系统的数据格式和架构,不会对系统的正常运行产生影响。

                    二、节点管理

                    1、服务调用失败一般有两类原因造成:

                    1. 服务提供者自身出现问题,如服务器宕机、进程意外退出等;
                    2. 网络问题,服务提供者、注册中心、服务消费者之间出现了网络问题;

                    2、服务调用失败的解决方式:

                    (1)注册中心主动移除

                    服务提供者定时的向注册中心发送心跳,如果心跳间隔超时,就认为服务提供者出现了问题,将其在注册中心中移除,并把可用的节点发送给服务调用者。

                    (2)服务消费者移除

                    也可以在服务消费者调用失败时,将该节点从注册中心中移除。

                    3、服务调用失败的具体解决方式:

                    (1)了解失败原因

                    处理失败的服务接口调用,首先要了解失败的原因。这可以通过检查显示的错误消息或检查服务器日志来完成。错误消息可能会提供关于失败原因的详细信息,例如网络问题或服务器过载。

                    (2)重试调用

                    如果服务接口调用失败,首先要做的是重试调用。有时,故障可能是由临时问题引起的,例如网络中断或服务器过载。通过重试调用,问题可能会得到解决,应用程序可能会正常运行。

                    (3)实施错误处理

                    处理失败的服务接口调用的重要步骤是实施错误处理。错误处理涉及设计应用程序以优雅地处理错误,而不是简单地崩溃或向用户显示错误消息。错误处理可以包括重试调用、向用户显示错误消息或回滚错误之前所做的任何更改。

                    (4)检查网络连接

                    如果服务接口调用失败,可能是由于网络连接问题。检查网络连接性涉及验证客户端和服务器是否连接到同一网络、网络是否正常运行以及是否没有防火墙或其他网络限制阻止连接。

                    (5)联系技术支持

                    如果上述步骤未能解决问题,可能需要联系技术支持。技术支持可以协助诊断和解决与服务器接口调用相关的问题。联系技术支持时,请务必提供尽可能多的有关错误的信息,包括任何错误消息、日志或在错误发生之前采取的步骤。

                    三、负载均衡

                    一般情况下,服务提供者节点都不是唯一的,会以集群的方式存在,其性能也不尽相同,性能好的机器承担的业务多一点,这样才能物尽其用。

                    如何实现呢?答案自然是负载均衡。常见的负载均衡算法有以下集中:

                    1、随机算法

                    简单来说,就是随机调用可用的服务提供者。

                    在服务节点足够多的情况下,每个节点被访问的概率大致是相同的。

                    随机算法通常使用随机数方式实现,比如一共有10个节点,那么就会生成一个1~10之间的随机数,假如生成了7,就会调用编号为7的节点。

                    2、轮询算法

                    根据机器的性能或者网络因素,对每个服务提供者添加一个权重值,如果每台机器的权重是一样的,则每台机器的调用次数也是差不多的。

                    比如某些机器性能比较给力,权重大一点,提高整体调用的性能。

                    轮询算法通常会将可用节点放到一个数组中,然后按照数组编号,进行逐一访问。

                    加权轮询算法,如果添加了权重,就会根据每个节点的权重进行逐一访问,比如1节点每访问1次,2节点可能就要访问2次,次数根据权重而定。

                    3、最少活跃调用算法

                    负载均衡的最少活跃调用算法(LeastActiveLoadBalance)是一种策略,它将请求分配给当前活跃调用数最少的服务器。这种策略在一定程度上可以避免系统的某些节点过载,同时保证系统的整体性能。

                    具体实现过程可能如下:

                    1. 收集各个节点的当前活跃调用数。
                    2. 从所有节点中选择当前活跃调用数最少的节点。
                    3. 将新的请求发送到选择的节点。

                    这种策略的优点在于,它可以动态地平衡各个节点的负载,避免某些节点过载,提高系统的整体性能。同时,由于它考虑了各个节点的当前活跃调用数,因此可以更好地应对突发流量,保证系统的稳定性和可用性。

                    然而,这种策略也存在一些缺点。首先,它需要实时收集和更新各个节点的活跃调用数,增加了系统的开销。其次,在极端情况下,如果所有节点的活跃调用数都相同,可能会导致负载分布不均。此外,这种策略可能不适用于所有场景,例如在某些需要保证请求顺序的场景中,可能需要其他类型的负载均衡策略。

                    负载均衡的最少活跃调用算法是一种有效的策略,可以在一定程度上平衡系统的负载,提高系统的整体性能。然而,在实际应用中,需要根据具体的场景和需求选择合适的负载均衡策略。

                    4、一致性Hash算法

                    负载均衡的一致性哈希算法(Consistent Hashing)是一种负载均衡算法,它通过使用哈希函数将服务节点映射到一个环形的空间,然后根据请求的键值(key)在该环形空间中找到一个节点,将请求发送到该节点进行处理。

                    一致性哈希算法的优点在于,当增加或减少节点时,只会影响到相邻节点,而不会影响到整个系统的负载均衡。这使得一致性哈希算法在动态调整节点数量时具有较好的性能。

                    具体实现过程可能如下:

                    1. 使用哈希函数将每个服务节点的名称或ID映射到一个环形空间。
                    2. 当有新的请求到达时,使用同样的哈希函数将请求的键值(key)映射到环形空间。
                    3. 找到离请求键值最近的节点,将请求发送到该节点进行处理。

                    一致性哈希算法的优点在于,它可以较好地平衡系统的负载,同时可以动态地调整节点数量而不会影响到整个系统的性能。此外,一致性哈希算法还可以处理节点的失效情况,通过将失效的节点从环形空间中删除,然后将新的请求重定向到其他节点,以保证系统的可用性和稳定性。

                    然而,一致性哈希算法也存在一些缺点。

                    • 首先,它对节点的名称或ID的哈希函数的选择比较敏感,如果选择的哈希函数不好,可能会导致节点在环形空间中的分布不均。
                    • 其次,一致性哈希算法对于大规模的节点数量的处理能力有限,如果节点数量过大,可能会导致环形空间溢出。

                      负载均衡的一致性哈希算法是一种有效的负载均衡策略,可以较好地平衡系统的负载,同时可以动态地调整节点数量而不会影响到整个系统的性能。然而,在实际应用中,需要根据具体的场景和需求选择合适的负载均衡策略。

                      5、自适应最优选择算法

                      在客户端本地维护一份每一个服务节点的性能统计快照,并且每隔一段时间去更新这个快照。

                      在发起请求时,根据二八原则,找出响应最慢的那20%,然后降低其权重,实现动态变更权重,从而可以提高服务性能。

                      自适应最优选择算法是对加权轮询算法的改良,可以看作动态加权轮询算法,它的实现核心是:

                      1. 每隔一段时间获取每个服务节点的平均性能统计,间隔时间不宜太长,时效性不好;也不宜太短,会因为网络抖动不断更新;间隔时间设置为1分钟最为合适;
                      2. 按照性能统计进行排序,对排在最后的那20%赋予一个较低的权重,其余的节点权重不变,降低标准 = 降低其权重为其余的50%最为合适。

                      四、如何选择负载均衡算法

                      1、系统的特点和需求

                      不同的系统有不同的特点和需求,需要根据实际情况选择合适的负载均衡算法。例如,对于需要处理大量并发请求的系统,可以选择轮询法或随机法;对于需要保证请求顺序的系统,可以选择最少活跃调用算法。

                      2、节点的性能和配置

                      节点的性能和配置也会影响到负载均衡的效果。例如,对于配置较低的节点,可以选择加权轮询法或随机法来减轻其系统负载。

                      3、算法的复杂度和性能

                      负载均衡算法的复杂度和性能也会影响到系统的性能和稳定性。因此,在选择算法时,需要考虑其复杂度和性能是否适合系统的需求。

                      4、算法的可扩展性和可维护性

                      负载均衡算法的可扩展性和可维护性也是需要考虑的因素。如果系统需要扩展或维护,算法是否易于扩展和维护也是需要考虑的因素。

                      选择负载均衡算法需要考虑多种因素,包括系统的特点和需求、节点的性能和配置、算法的复杂度和性能以及可扩展性和可维护性等。在实际应用中,需要根据具体情况选择最合适的负载均衡算法。

                      五、服务路由

                      对于服务消费者而言,在内存中的可用服务节点列表中选择哪个节点不仅由负载均衡算法决定,还由路由规则确定。

                      所谓的路由规则,就是通过一定的规则如条件表达式或者正则表达式来限定服务节点的选择范围。

                      为什么要制定路由规则呢?主要有两个原因。

                      1、灰度发布

                      服务提供者做了功能变更,但希望先只让部分人群使用,然后根据这部分人群的使用反馈,再来决定是否做全量发布。

                      服务路由的灰度发布是一种应用的发布方式,它可以在现存旧版本应用的基础上,启动一个新版本应用,这个新版本应用并不会直接让用户访问,而是提供给测试人员测试使用,若测试通过才会将真实的用户流量逐步导入到新版本应用中。

                      灰度发布的好处是可以降低上线可能导致的风险,通过持续对新版本应用的运行状态进行监控,直至全部切换完成,这就是所谓的A/B测试。过程中,也可以招募部分灰度用户,为他们设置独有的灰度标示(如:Cookie,Header等),使这部分用户能够访问到新版本应用。如果切换过程中出现问题,也能够迅速地将流量切换回旧版本的应用,时间版本回滚。

                      2、多机房就近访问

                      服务路由的多机房就近访问是指在进行服务调用时,根据请求的来源和目标服务的位置,选择最近的机房进行访问。这种策略可以减少网络延迟,提高服务的响应速度和用户体验。

                      实现多机房就近访问的关键在于对服务提供者的部署和路由策略的设计。一般来说,可以采用以下步骤:

                      1. 部署多个机房:在多个地理位置分别部署不同的机房,每个机房内部存储着相同的数据副本。
                      2. 就近路由策略:在服务消费者和服务提供者之间建立路由规则,优先选择最近的服务提供者进行调用。
                      3. 负载均衡:在每个机房内部,可以采用负载均衡技术,将请求分散到多个服务提供者上,以实现负载均衡和容错处理。
                      4. 跨机房调用:当某个机房发生故障或负载过重时,可以通过跨机房调用其他机房的服务提供者来保证服务的可用性和稳定性。

                      实现多机房就近访问需要综合考虑网络延迟、数据同步、负载均衡等多个方面的问题。在设计和实施过程中,需要结合具体的业务场景和需求进行综合考虑和调整。

                      3、服务路由如何配置

                      服务路由的配置可以根据不同的路由策略和实际需求进行调整。以下是一些常见的服务路由配置方法:

                      (1)基于URL路径的路由

                      这种方法通过配置不同的URL路径来将请求转发到不同的服务实例。例如,可以将特定URL路径的请求转发到某个服务实例,而其他URL路径的请求则转发到其他服务实例。

                      (2)基于请求头的路由

                      这种方法通过检查请求头中的特定字段来决定将请求转发到哪个服务实例。例如,可以根据请求头中的User-Agent字段来决定将请求转发到哪个服务实例。

                      (3)基于负载均衡的路由

                      这种方法使用负载均衡器来将请求转发到不同的服务实例。负载均衡器可以根据不同的负载均衡算法(如轮询、随机等)来选择服务实例,并将请求转发到该服务实例。

                      (4)基于客户端IP的路由

                      这种方法根据客户端IP地址来决定将请求转发到哪个服务实例。例如,可以将特定IP范围的请求转发到某个服务实例,而其他IP范围的请求则转发到其他服务实例。

                      在进行服务路由配置时,需要根据实际需求和业务场景选择合适的路由策略,并进行相应的配置。同时,还需要考虑负载均衡、容错处理、安全性和性能等方面的问题,以确保服务的可用性和稳定性。

                      六、服务路由的应用场景

                      1、分组调用

                      服务路由的分组调用是指将服务节点按照不同的数据中心分成不同的分组,每个分组包含一组服务节点。对于服务消费者来说,选择哪个分组调用取决于其使用的路由规则。这种分组调用方式有助于将负载分散到不同的服务节点上,提高系统的可扩展性和性能。

                      2、灰度发布

                      服务路由的灰度发布是一种应用的发布方式,它可以在现存旧版本应用的基础上,启动一个新版本应用,这个新版本应用并不会直接让用户访问,而是提供给测试人员测试使用,若测试通过才会将真实的用户流量逐步导入到新版本应用中。

                      在服务路由中,灰度发布可以通过路由策略的组合使用来实现。比如,可以使用RPC路由策略,通过定点调用、黑白名单等一些高级服务治理功能,让请求按照设定的规则发送到目标节点上,从而实现流量隔离的效果。

                      灰度发布的好处是可以降低上线可能导致的风险,通过持续对新版本应用的运行状态进行监控,直至全部切换完成,这就是所谓的A/B测试。过程中,也可以招募部分灰度用户,为他们设置独有的灰度标示(如:Cookie,Header等),使这部分用户能够访问到新版本应用。如果切换过程中出现问题,也能够迅速地将流量切换回旧版本的应用,实现时间版本回滚。

                      3、流量切换

                      服务路由的流量切换是指当业务故障发生时,能够按照某个指令将原来调用这个机房服务的流量切换到其他正常的机房。这种切换可以在业务线上运行过程中遇到一些不可抗力因素导致业务故障时,如某个机房的光缆被挖断,或者发生着火等事故导致整个机房的服务都不可用。通过流量切换,可以保证服务的稳定性和可用性。

                      4、读写分离

                      服务路由的读写分离是指将数据库的读操作与写操作分别分配到不同的服务节点上,以实现负载均衡和性能优化。读操作通常包括查询、列表、获取、判断等操作,而写操作则包括插入、更新、删除等操作。通过读写分离,可以提高系统的访问性能、稳定性和可用性。

                      在实现读写分离时,可以将读操作路由到一组服务节点上,而将写操作路由到另一组服务节点上。这样可以使得读操作和写操作在不同的服务节点上处理,避免因为单点故障或性能瓶颈而影响整个系统的性能。同时,通过负载均衡技术,可以使得每个服务节点的负载相对均衡,进一步提高系统的性能和稳定性。

                      需要注意的是,读写分离虽然可以提高系统的性能和稳定性,但也需要注意数据一致性的问题。因为读操作和写操作在不同的服务节点上处理,如果数据同步不及时或者出现故障,就可能导致数据不一致的情况发生。因此,在实现读写分离时,需要保证数据同步的及时性和可靠性。

                      七、服务容错

                      上面提到,服务调用不总是成功的,可能因为服务宕机、网络问题造成服务调用失败。

                      如何解决?

                      1、FailOver,失败自动切换

                      服务消费者在调用失败或者超时时,自动从其它可用的节点中选取一个,再次调用,也就是重试的效果。

                      这种策略要求每次调用的操作必须是幂等的,也就是说不管啥时候调用,返回结果都是一致的,一般适合读操作。

                      2、FailBack,失败通知

                      服务消费者在调用失败或者超时时,不再重试,而是根据失败的详细信息,决定后续操作。

                      对于非幂等的调用场景,如果调用失败了,不能简单的重试,而是应该查询服务器的状态,看调用是否已经生效,如果生效了就不能重试了,如果未生效,则可以重试。

                      3、FailCache,失败缓存

                      服务消费者在调用失败或者超时时,不再重试,而是等待一定时间再重试。

                      比如服务接口可能一段时间都存在问题,你不断的重试,反而会加剧问题,隔一段时间,再重试,效果会更好。

                      4、FailFast,快速失败

                      服务消费者在调用失败或者超时时,不再重试,记录失败日志即可。

                      • 对于幂等接口,一般可以采用失败自动切换或失败缓存;
                      • 对于非幂等接口,可以采用失败通知或快速失败;

                        八、总结

                        上面提到了如何追踪微服务的调用和服务治理的常见手段。

                        1. 节点管理是从服务节点健康状态角度来考虑;
                        2. 负载均衡和服务路由是从服务节点访问优先级角度来考虑;
                        3. 服务容错是从调用的健康状态角度考虑;

                        微服务 Spring Cloud系列

                        微服务 Spring Cloud 1,服务如何拆分?使用微服务的注意事项?

                        微服务 Spring Cloud 2,一文讲透微服务核心架构(注册中心、服务通信、服务监控、服务追踪、服务治理)

                        微服务 Spring Cloud 3,如何对微服务进行有效的监控?

                        微服务 Spring Cloud 4,分布式系统如何进行数据分区

                        微服务 Spring Cloud 5,一图说透Spring Cloud微服务架构

                        微服务 Spring Cloud 6,用了这么多年Docker容器,殊不知你还有这么多弯弯绕

                        微服务 Spring Cloud 7,Nacos配置中心的Pull原理,附源码

                        微服务 Spring Cloud 8,开源RPC框架如何选型?

                        微服务 Spring Cloud 9,RPC框架,客户端和服务端如何建立网络连接?

                        🏆哪吒多年工作总结:Java学习路线总结,搬砖工逆袭Java架构师。

                        华为OD机试 2023B卷题库疯狂收录中,刷题点这里

                        刷的越多,抽中的概率越大,每一题都有详细的答题思路、详细的代码注释、样例测试,发现新题目,随时更新,全天CSDN在线答疑。