微服务110

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.管理目标的层次不同：
         熔断是针对框架级的处理，每一个服务都需要熔断措施。
         降级一般是针对业务流量的，一般从最外围的服务开始降级。比如网关挡住流量

7.限流器

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

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

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

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

8.断路器

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

9.微服务雪崩效应

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

10.服务发现/服务注册

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