微服务

微服务的介绍

微服务是一种软件架构风格，其中软件系统被构建为一组小型、独立的服务单元，这些服务单元通过轻量级的通信机制相互协作。每个微服务都专注于单一的业务功能，并且可以独立部署、升级和扩展。微服务架构的核心理念是将复杂的单块应用拆分为更小、更易管理的部分，从而提高系统的灵活性、可维护性和可扩展性。
微服务架构通常具有以下特点：
模块化设计： 系统被分解为多个独立的服务单元，每个服务单元都拥有自己的数据存储、业务逻辑和用户界面。
自治性： 每个微服务都是自治的，即它们可以独立开发、部署和运行，不依赖于其他服务。
松耦合： 微服务之间通过轻量级的通信机制进行交互，通常使用HTTP/REST、消息队列或RPC等方式。这种松耦合的设计使得系统更容易扩展、更易于替换和维护。
技术多样性： 不同的微服务可以使用不同的编程语言、框架和数据存储技术，从而允许开发团队选择最适合其需求的技术栈。
弹性： 微服务架构使得系统更具弹性，可以更容易地处理部分失败，同时允许水平扩展和负载均衡。
可扩展性： 由于每个微服务都是独立的，因此可以根据需要对系统的特定部分进行水平或垂直扩展，而不影响其他部分。
尽管微服务架构提供了许多优点，但它也带来了一些挑战，如分布式系统的复杂性、服务治理、数据一致性等问题。因此，在采用微服务架构时，团队需要仔细考虑这些挑战，并采取适当的措施来解决它们。

微服务服务架构演变

单体服务（Monolithic Service）是一种传统的软件架构方式，将整个应用程序作为一个单一的、紧耦合的单元进行开发和部署。单体服务通常由多个模块组成，这些模块共享同一个数据库和代码库。然而，随着应用程序规模的增长，单体服务可能变得庞大且难以维护，且部署和扩展困难。

微服务顾名思义，是将一个单体的服务，划分成多个服务，每个服务职责更加单一，只负责某一重要的事件处理，且各个模块之间通过HTTP或者RPC服务进行调用，每个微服务都会统一注册到注册中心，来判断服务是否存活。

微服务网关

微服务网关是在微服务架构中常用的组件，用于提供统一的入口和访问点，对外暴露服务并处理相关的请求。

1.统一入口
微服务网关为整个微服务架构提供了统一的入口和访问点，客户端只需与网关进行通信，无需直接调用后端的多个微服务，简化了客户端的调用方式。
2.路由和负载均衡
微服务网关可以根据路由规则将请求分发到相应的微服务实例，通过配置路由规则，可以根据请求的路径、参数、标头等信息来决定请求应该转发到那个微服务。同时网关可以实现负载均衡，将请求均匀地分发到多个后端微服务实例上，提高系统的性能和可伸缩性。
3.安全认证和授权
微服务网关可以集中处理安全认证和授权的逻辑，它可以对请求进行身份验证、访问控制和权限校验，确保只有经过授权的请求能够访问后端的微服务，提供统一的安全策略。
4.日志和监控
微服务网关可以记录请求和响应的日志，并提供监控和分析功能，这样可以追踪和监控系统的运行情况，帮助进行故障排查和性能优化。

微服务的负载均衡

微服务负载均衡是在微服务架构中管理和分发请求的关键组成部分，确保各个微服务实例能够有效地分担负载并提供高可用性和性能。

1.轮询算法：轮询算法是最简单的负载均衡算法之一。它按照顺序将请求依次分配给每个后端服务器，循环往复。当请求到达时，负载均衡器按照事先定义的顺序选择下一个服务器。轮询算法适用于后端服务器具有相同的处理能力和性能的场景。
2.加权轮询算法：加权轮询算法在轮询算法的基础上增加了权重的概念。每个后端服务器都被赋予一个权重值，权重值越高，被选中的概率就越大。这样可以根据服务器的处理能力和性能调整请求的分配比例，使得性能较高的服务器能够处理更多的请求。
3.随机算法：随机算法将请求随机分配给后端服务器。每个后端服务器有相等的被选中概率，没有考虑服务器的实际负载情况。这种算法简单快速，适用于后端服务器性能相近且无需考虑请求处理能力的场景。
4.加权随机算法：加权随机算法在随机算法的基础上引入了权重的概念。每个后端服务器被赋予一个权重值，权重值越高，被选中的概率就越大。这样可以根据服务器的处理能力和性能调整请求的分配比例。
5.最少连接算法：最少连接算法会根据后端服务器当前的连接数来决定请求的分配。负载均衡器会选择当前连接数最少的服务器进行请求分配，以保证后端服务器的负载均衡。这种算法适用于后端服务器的处理能力不同或者请求的处理时间不同的场景。
6.哈希算法：哈希算法会根据请求的某个特定属性（如客户端IP地址、请求URL等）计算哈希值，然后根据哈希值选择相应的后端服务器。
常见的负载均衡器，比如Ribbion、Fegin等等，基本都支持这些负载均衡算法。

微服务的容灾机制

服务崩溃

在了解服务容灾之前，我们先连接服务崩溃，在微服务中，假如一个或者多个服务出现故障，如果这时候，依赖的服务还在不断发起请求，或者重试，那么这些请求的压力会不断在下游堆积，导致下游服务的负载急剧增加。不断累计之下，可能会导致故障的进一步加剧，可能会导致级联式的失败，甚至导致整个系统崩溃，这就叫服务雪崩。

服务容灾机制

在微服务架构中，容灾是确保系统在面对各种灾难性事件时能够继续提供服务的重要方面。以下是一些常见的微服务容灾策略：
1.服务实例的多副本部署：为每个微服务部署多个实例，并将它们分布在不同的物理服务器、虚拟机或容器中。这样可以确保即使某个实例发生故障，其他实例仍然可以继续提供服务。
2.健康检查和自动恢复：实现对微服务实例的健康检查机制，定期检查实例的健康状态。当某个实例被检测到不健康时，自动从负载均衡器中移除，并尝试恢复或替换该实例。
3.服务治理和容错机制：通过服务治理框架（如Netflix的Hystrix）实现容错机制，包括超时控制、断路器模式、降级处理等。这些机制可以在服务出现故障或延迟时提供备用方案或快速失败，从而保护系统免受级联故障的影响。
4.多数据中心部署：在不同的地理位置或数据中心部署微服务的副本，以提供地域性容灾。当一个数据中心发生故障时，流量可以自动转移到其他数据中心上，确保系统的可用性。
5.数据备份和复原：对于需要持久化数据的微服务，实施定期的数据备份和恢复策略。确保数据能够在灾难事件中快速恢复，减少数据丢失和业务中断的风险。
6.灾难恢复演练：定期进行灾难恢复演练，测试容灾方案的有效性，并发现和解决潜在的问题。这有助于提高团队对灾难事件的应对能力，确保系统在面对实际灾难时能够做出及时和有效的响应。

微服务熔断机制

微服务熔断机制是一种用于提高微服务系统稳定性和可用性的重要技术，它可以在面对服务故障或延迟时，通过快速失败和降级处理来保护系统免受级联故障的影响。以下是微服务熔断机制的核心概念和原理：
1.断路器模式：
熔断机制通常采用断路器模式实现，类似于电路中的断路器。断路器监控对某个服务的调用，当连续失败的次数达到阈值时，断路器会打开，阻止对该服务的调用。
打开断路器后，所有请求将立即失败，而无需等待超时。这可以避免对不可用的服务发起大量的请求，从而减轻系统负担，并使服务有更多的时间来恢复正常状态。
2.熔断器状态：
断路器通常有三个状态：关闭（Closed）、打开（Open）和半开（Half-Open）。
当服务调用成功时，断路器保持关闭状态；当连续失败的次数达到阈值时，断路器切换到打开状态；在打开一段时间后，断路器进入半开状态，允许部分请求通过以检测服务的可用性。
3.熔断器参数：
熔断器通常配置有以下参数：
失败阈值：连续失败的次数达到该阈值时打开断路器。
超时时间：等待服务响应的最大时间。
半开状态持续时间：在打开断路器后等待多久进入半开状态。
4.降级处理：
当服务熔断打开时，Hystrix可以提供一个备用的降级方法或返回默认值，以保证系统继续正常运行。开发者可以定义降级逻辑，例如返回缓存数据、执行简化的逻辑或调用其他可靠的服务，以提供有限但可用的功能。
5.健康检查和自动恢复：
在断路器打开后，可以定期进行健康检查，以检测服务是否已经恢复正常。当服务恢复正常时，断路器会逐渐关闭，恢复对该服务的调用。
微服务熔断机制通过断路器模式和降级处理，有效地保护系统免受不可用服务的影响，并提高了系统的稳定性和可用性。

微服务限流

微服务限流是指在微服务架构中对服务的访问进行限制，以确保系统在高负载情况下依然能够正常运行。限流的目的是防止某个服务被过度请求而导致其它服务无法正常工作，或者是防止某些请求对系统造成过大的压力，导致系统性能下降或崩溃。
有几种常见的微服务限流策略：
1.基于并发数的限流：限制同时对某个服务的并发请求数量。这可以通过使用信号量、线程池或类似的机制来实现。
2.基于请求速率的限流：限制每个时间窗口内的请求速率。例如，可以限制每秒钟对某个服务的请求数量。
3.基于资源消耗的限流：限制某个服务在一段时间内所消耗的资源，如CPU、内存或网络带宽。
4.基于用户或客户端的限流：针对特定用户、客户端或IP地址的请求进行限制，以防止恶意行为或异常情况。
5.动态限流：根据系统当前的负载情况自动调整限流策略，以适应不同的工作负载。
实施微服务限流需要根据具体的业务场景和系统特点来选择合适的策略，并结合监控和告警系统进行动态调整和管理。

Sentinel怎么实现限流

Sentinel通过动态管理限流规则，根据定义的规则对请求进行限流控制。具体实现步骤如下：
1.通过注解
@SentinelResource定义资源：在Sentinel中，资源可以是URL、方法等，用于标识需要进行限流的请求。

// 原本的业务方法.
@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");
}

@SentinelResource 注解属性说明：
value：资源名称，必需项（不能为空）。
entryType：资源调用的流量类型：入口流量（EntryType.IN）和出口流量（EntryType.OUT），注意系统规则只对 IN 生效。
blockHandler/blockHandlerClass: 限流和熔断时执行 BlockException 所对应的方法名。
fallback/fallbackClass：非 BlockException 时，其他非限流、非熔断时异常对应的方法。
exceptionsToIgnore：用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。
2.通过代码定义资源实现限流规则：
可以通过代码的的方式 SphU.entry(“resourceName”) 来定义资源，具体实现代码如下：

@RequestMapping("/getUser")
public String getUser() {
    try (Entry entry = SphU.entry("getUser")) {
        // 被保护逻辑
        return "VO";
    } catch (Exception e) {
        // 限流之后的业务逻辑
        return "此接口被限流了";
    }
}

2.配置限流规则：在Sentinel的配置文件中定义资源的限流规则。规则可以包括资源名称、限流阈值、限流模式（令牌桶或漏桶）等。

private static void initFlowQpsRule() {
    List<FlowRule> rules = new ArrayList<>();
    FlowRule rule1 = new FlowRule();
    rule1.setResource(resource);//资源名称
    // Set max qps to 20
    rule1.setCount(20);//限制的QPS阈值（每秒钟只允许20个请求）
    rule1.setGrade(RuleConstant.FLOW_GRADE_QPS);//根据QPS限流
    rule1.setLimitApp("default");//流控效果
    rule1.setStrtegy(RuleConstant.STRATEGY_DIRECT);//调用关系限流策略，非必须设置
    rule1.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); // 流控效果【非必须设置】
    rule1.setClusterMode(false);//是否设置集群限流（非必须设置，默认为非集群）
    rules.add(rule1);
    FlowRuleManager.loadRules(rules);
}

setStrategy：设置调用关系限流策略，包含的值有：
直接（RuleConstant.STRATEGY_DIRECT）【默认值】
链路（RuleConstant.STRATEGY_RELATE）
关联（RuleConstant.STRATEGY_CHAIN）
setControlBehavior：设置流控效果，包含的值有：
直接拒绝（RuleConstant.CONTROL_BEHAVIOR_DEFAULT）【默认值】
冷启动（RuleConstant.CONTROL_BEHAVIOR_WARM_UP）
匀速启动（RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER）
冷启动+匀速启动（RuleConstant.CONTROL_BEHAVIOR_WARM_UP_RATE_LIMITER）

微服务限流算法

1.令牌桶算法

令牌桶算法是一种流量控制算法，用于限制在任意时间单位内通过的请求速率。它基于令牌桶的概念，具有固定的容量，其中以固定的速率往桶中添加令牌。当一个请求到达时，需要从桶中获取一个令牌，如果桶中有足够的令牌，则请求被允许通过；否则，请求被拒绝或者延迟处理。
令牌桶算法的基本原理和步骤：
1.令牌桶：算法维护一个固定容量的令牌桶，其中以固定的速率向桶中添加令牌。
2.令牌生成：桶中以恒定的速率生成令牌，通常每隔固定时间生成一个令牌，或者以固定的速率生成令牌。
3.请求处理：当一个请求到达时，需要从令牌桶中获取一个令牌。如果桶中有足够的令牌，则将一个令牌移出桶，并处理该请求；否则，请求被拒绝或者延迟处理。
4.令牌补充：如果请求未被拒绝，则在处理请求后，可以选择将一个新的令牌放入桶中，以确保下一个请求可以及时被处理。
令牌桶算法的优点包括：
允许短时间内的突发流量，因为如果令牌桶中有足够的令牌，请求可以立即被处理。
允许动态调整请求处理的速率，只需调整令牌生成的速率即可。
简单且高效，适用于各种场景下的流量控制。
然而，令牌桶算法也有一些缺点，比如对于突发流量的处理可能不够灵活，因为令牌桶中的令牌数量是固定的。

2.漏斗桶算法

漏斗算法是一种用于流量控制的算法，类似于令牌桶算法。它基于一个类比：将请求想象成水流，桶就像是一个漏斗，而请求则是水滴。漏斗以固定的速率流水，当水满了漏斗则会溢出。在漏斗算法中，漏斗以固定的速率处理请求，如果请求到达速率超过漏斗处理的速率，则请求会被拒绝或延迟处理。
漏斗算法的基本原理和步骤：
漏斗：算法维护一个固定容量的漏斗，类似于一个定时漏水的容器。
漏水速率：漏斗以固定的速率处理请求，类比为漏斗定时地漏水。
请求处理：当一个请求到达时，漏斗会处理请求，类比为漏斗装满水。如果请求到达速率超过漏斗的处理速率，则漏斗会溢出，表示请求被拒绝或者延迟处理。
漏斗空出：当漏斗溢出时，表示系统无法处理更多的请求，需要等待一段时间，直到漏斗空出了一些空间。
漏斗算法的优点包括：
允许短时间内的突发流量，因为如果漏斗尚未溢出，则请求可以立即被处理。
允许动态调整请求处理的速率，只需调整漏水的速率即可。
简单且高效，适用于各种场景下的流量控制。
然而，与令牌桶算法相比，漏斗算法在某些情况下可能表现得更为宽松，因为漏斗的处理速率是固定的，无法动态调整，可能会导致系统对于突发流量的处理不够灵活。

服务监控

我们使用Prometheus和Grafana来实现整个微服务集群的监控和告警：
Prometheus：Prometheus 是一个开源的监控系统，具有灵活的数据模型和强大的查询语言，能够收集和存储时间序列数据。它可以通过HTTP协议定期拉取微服务的指标数据，并提供可扩展的存储和查询功能。

Grafana：Grafana 是一个开源的可视化仪表板工具，可以与 Prometheus 结合使用，创建实时和历史数据的仪表板。Grafana 提供了丰富的图表和可视化选项，可以帮助用户更好地理解和分析微服务的性能和状态。

日志收集

日志收集有很多种方案，我们用的是ELK：

Elasticsearch：Elasticsearch是一个分布式搜索和分析引擎，用于存储和索引大量的日志数据。它提供了快速的搜索和聚合功能，可以高效地处理大规模的日志数据。
Logstash：Logstash是一个用于收集、过滤和转发日志数据的工具。它可以从各种来源（如文件、网络、消息队列等）收集日志数据，并对数据进行处理和转换，然后将其发送到Elasticsearch进行存储和索引。
Kibana：Kibana是一个用于日志数据可视化和分析的工具。它提供了丰富的图表、仪表盘和搜索功能，可以帮助用户实时监控和分析日志数据，发现潜在的问题和趋势。
简单说，这三者里Elasticsearch提供数据存储和检索能力，Logstash负责将日志收集到ES，Kibana负责日志数据的可视化分析。
使用ELK进行微服务日志收集的一般流程如下：

（1）通过FileBeat采集服务器上的日志，然后将采集好的日志推送到Kafka中。此时为什么不直接将采集的日志推送到Logstash呢？因为logstash在并发量很大的时候容易丢失数据，所以为了保证数据不丢失我们采用Kafka将流量消峰然后把数据推送给Logstash消费。
（2）kafka将队列中的日志数据给Logstash消费，Logstash将数据做定制化处理，处理好数据后再推送到ES指定的索引中。
（3）ES收到Logstash推送的数据之后存储对于索引的分片中，由于ES自身的特性，针对海量数据处理能力还是很优秀的。
（4）开发人员或运维人员通过Kinaba可视化平台查询ES中的数据。