微服务1-10

目录

• 1.微服务架构是什么样子的?
• 2.微服务，服务治理是怎么样的
• 3.grpc遵循什么协议？
• 4.grpc内部原理是什么？
• 5.http与rpc的区别
• 6.熔断与降级
• 7.限流器
• 8.断路器
• 9.微服务雪崩效应
• 10.服务发现/服务注册

1.微服务架构是什么样子的?

通常传统的项目体积庞大，需求、设计、开发、测试、部署流程固定。新功能需要在原项目上做修改。

但是微服务可以看做是对大项目的拆分，是在快速迭代更新上线的需求下产生的。新的功能模块会发布成新的服务组件，与其他已发布的服务组件一同协作。 服务内部有多个生产者和消费者，通常以http rest的方式调用，服务总体以一个（或几个）服务的形式呈现给客户使用。

微服务架构是一种思想对微服务架构我们没有一个明确的定义，但简单来说微服务架构是：
	采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。

2.微服务，服务治理是怎么样的

服务治理：在微服务架构下，出现了新的服务问题，从而需要对微服务进行服务治理。那微服务又有哪些问题需要治理？

1、服务注册与发现（网关层）
2、可观测性（监控，日志，调用追踪）
3、流量管理（网关流量转移20%至新版本接口）
4、安全（访问其他服务需要授权，网关层）
5、控制（服务流量分发，网关层）
6、服务配置（网关层，k8s的congfig配置中心）
7、服务熔断（一个服务的错误，引起整个服务的崩溃。当出现错误时，执行我们自定义的方法。避免崩溃。但是微服务已经隔离了，应该不会出现整个系统服务崩溃这种问题，最多单个服务不可用）
8、服务弹性伸缩（hpa自动扩容）
9、负载均衡（k8s,ingress->nginx自动均衡）
10.服务监控（Promethues，rancher）

3.grpc遵循什么协议？

grpc遵循HTTP/2协议，是一个二进制协议
grpc与http一样，底层都是tcp连接，遵循socket套接字

4.grpc内部原理是什么？

rpc客户端：发协议请求，接收响应
rpc服务端：接收协议请求，发送响应

5.http与rpc的区别

http本质上也是rpc，协议不同
http：是rpc实现的一种方式，基于http协议
rpc：可以基于tcp协议，也可以基于http协议

6.熔断与降级

要防止系统发生雪崩，就必须要有容错设计。如果遇到突增流量，一般的做法是对非核心业务功能采用熔断和服务降级的措施来保护核心业务功能正常服务，而对于核心功能服务，则需要采用限流的措施。
服务降级：当发生熔断的时候，让请求走事先配置的处理方法，这个方法就是降级逻辑

熔断原理：
  在微服务架构中，当调用链路中的某个微服务长时间不可用或者有延迟，响应过慢，系统就会熔断对该节点微服务的调用，快速返回错误信息。当监控到该微服务正常工作后，再次恢复该调用链路。

熔断和降级：
相似性：
  1.目的一致，保护系统，防止整个系统崩溃
  2.让用户体验到某些服务暂时不可用，默认的数据返回给用户
  3.粒度一致，都是服务级别的
不相似性：
  1.触发条件不同：
         熔断一般是某个服务故障引起的，一般下游服务。
         降级一般是整体负荷考虑
  2.管理目标的层次不同：
         熔断是针对框架级的处理，每一个服务都需要熔断措施。
         降级一般是针对业务流量的，一般从最外围的服务开始降级。比如网关挡住流量

熔断器：其中一个服务不可用，立即熔断，整个集群的其他服务还是可以用
实现方法：服务启动注册，健康状态存进redis，每次流量来的时候检查下是否健康，不健康则熔断

7.限流器

服务限流是指在一定时间段内限制服务的请求量以保护系统，主要用于防止突发流量而导致的服务崩溃，比如秒杀、抢购、双十一等场景，也可以用于安全目的，比如应对外部暴力攻击。

常用的限流算法有以下几种：
1.计数器算法
实现方法：
  在网关服务设置一个全局计数器，内部维护一个计数器，对一段时间的服务请求进行累计判断计数器是否达到预先设定的阈值。如果没有达到阈值，就允许请求通过，并且计数器加1；如果达到阈值，则拒绝服务，抛弃请求。进入下一个计时周期后，计数器清零，重新计数。

2.漏桶算法
 原理：漏桶算法的原理可以这样理解，将服务请求想象成流入漏桶的水，漏桶中的水以恒定的速率从桶底流出，当流入漏桶的水速度过快，超过了漏桶容量时，则直接溢出。所以，漏桶算法能够控制服务请求按照固定速率均匀输出，平滑突发流量，实现流量整形，为后续处理提供一个稳定的流量。但是，漏桶算法无法控制请求按照一定的速率均匀输入。
 实现方法1：
	redis里放一个分布式锁，数量100,进来一个请求数量-1，请求完了+1.当数量为0时，拒绝请求

3.令牌桶算法
 原理：令牌桶算法是速率限制（Rate Limiting）和流量整形（Traffic Shaping）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送
 实现方法：
 redis里放一个分布式锁，数量初始100,每秒+1，如果大于100则令牌益处，不+。来一个请求取一个令牌，数量-1.当令牌数=0时，拒绝请求。
 所以，令牌桶算法既可以控制请求均匀输入的速度，又可以控制请求的均匀输出速率。

限流器：当系统的处理能力不能应对外部请求的突增流量时，为了不让系统崩溃，必须采取限流的措施。
限流指标：TPS(吞吐量),HPS(每秒请求数),QPS(服务端每秒能响应的请求数)
限流方法：
1.流量计数器:比如限制每秒请求数100，超过100拒绝掉
2.滑动时间窗口:滑动时间窗口算法是目前比较流行的限流算法
3.漏桶算法
4.令牌桶
5.线程池限流

8.断路器

断路器就是服务熔断和服务降级

9.微服务雪崩效应

微服务雪崩效应：某一个服务单点故障，很多接口都依赖于此服务。那么就会产生一系列服务被进一步拖垮称为雪崩。
解决方法：做熔断

10.服务发现/服务注册

通过zookeeper
服务端:服务端启动时，在zookeeper中创建临时有序节点，服务关闭时，临时节点自动删除了(zookeeper临时节点机制)
客户端:监听节点的变化

在微服务架构中，服务发现是一个关键的组件，用于帮助服务实例找到和连接到其他服务实例。下面是一种常见的方法来实现微服务的服务发现：
注册服务：当一个服务实例启动时，它会向服务注册中心注册自己的信息，包括 IP 地址、端口号和服务标识等。服务注册中心可以是一个独立的组件，如 Consul、Eureka 或 ZooKeeper，也可以是云平台提供的服务，如 AWS 的 Elastic Load Balancer。
发现服务：当一个服务实例需要调用其他服务时，它向服务注册中心发起查询请求，根据服务标识获取该服务的 IP 地址和端口号等信息。服务注册中心返回可用的服务实例列表。
负载均衡：在获取到服务实例列表后，调用方可以使用负载均衡算法（如轮询、随机或基于权重）选择其中一个服务实例进行通信。负载均衡算法可以确保请求在多个服务实例之间进行平衡分发，提高系统的可伸缩性和容错能力。
定期更新：服务注册中心会定期检查和更新服务实例的健康状态。如果某个服务实例发生故障或下线，服务注册中心会将其从可用服务列表中移除，并通知其他服务实例。
动态扩容与缩容：当负载增加时，可以通过自动扩容机制增加服务实例；当负载减少时，可以通过自动缩容机制减少服务实例。这种动态的增删服务实例的能力可以根据系统负载的变化来优化资源利用率和性能。
需要注意的是，以上是一种简化的描述，实际的微服务架构中可能会使用更复杂的技术和工具来实现服务发现。在选择服务发现方案时，可以根据具体需求和技术栈考虑不同的选项，并结合实际情况做出适当的决策。

k8s服务发现：
创建服务：首先，在 Kubernetes 中创建一个 Service 资源来定义你的应用程序或服务。Service 是一个抽象层，它提供了一个稳定的入口点，以便其他服务可以通过该入口点与之通信。你可以使用 Kubernetes 的 YAML 或命令行工具（如 kubectl）来创建 Service。
选择 Service 类型：Kubernetes 提供不同类型的 Service，包括 ClusterIP、NodePort 和 LoadBalancer。你可以根据需求选择适合的类型。
ClusterIP：默认类型。仅在集群内部可用，其他服务可以通过 ClusterIP 访问它。这种类型适合于在集群内进行服务间通信。
NodePort：将 Service 暴露到集群中每个节点的某个端口上。可以通过节点的 IP 地址和指定的端口来访问 Service。
LoadBalancer：在云环境中，可以使用云提供商的负载均衡器将外部流量转发到 Service。负载均衡器会自动分配一个外部 IP 地址，并将流量转发到 Service 的后端实例。
连接到服务：其他服务或应用程序可以通过 K8s 的 DNS 解析功能来连接到服务。你可以使用 Service 名称作为主机名，Kubernetes 会将其解析为相应的后端 Pod IP 地址。同时，你也可以使用 Service 的 ClusterIP 或 NodePort 来进行连接。
DNS 解析：在 Kubernetes 集群内部，可以使用 Service 名称（如 my-service）作为主机名进行 DNS 解析。例如，将 http://my-service 用作其他服务或应用程序的地址。
NodePort 或 LoadBalancer：如果你的 Service 类型是 NodePort 或 LoadBalancer，可以使用节点的 IP 地址和指定的端口来访问 Service。例如，http://node-ip:node-port。
自动负载均衡：Kubernetes 会自动监视后端 Pod 的健康状态，并根据需要动态更新 Service 的负载均衡配置。当有新的 Pod 加入或旧的 Pod 下线时，Kubernetes 会相应地更新负载均衡器配置，确保请求被均衡地分发到可用的 Pod 上。
总结来说，在 Kubernetes 中实现服务发现非常简单。创建 Service 资源，选择适当的类型，并使用 Service 名称或 IP 地址与其他服务进行通信即可。Kubernetes 会自动处理负载均衡和后端 Pod 的变化。