校招后端面经——服务框架
校招后端面经--服务框架
- 1. 如何容错容灾
- 2. 如何进行过载保护
- 3. 如何实现负载均衡
- 4. 微服务框架有哪些
- 5. RPC远程调用
- 组成：
- RPC 结构拆解
- 连接方式
- 对比web服务器：
1. 如何容错容灾
-
在多个机器多个机房部署服务节点和公共节点
-
名字服务排除和Client主动屏蔽。
名字服务排除：业务服务主动上报心跳给名字服务，使名字服务知道服务部署的节点存活情况，当服务的某节点故障时，名字服务不再返回故障节点的地址给Client，达到排除故障节点的目标。
Client主动屏蔽：当client调用某个svr出现调用连续超时，或者调用的超时比率超过一定百分比，client会对此svr进行屏蔽，让流量分发到正常的节点上去。对屏蔽的svr节点，每隔一定时间进行重连，如果正常，则进行正常的流量分发。
2. 如何进行过载保护
其一，限定最大连接数，
其二，限定最大能够同时处理的请求量。
实现请求队列，服务调用通过非阻塞方式实现异步系统，从而达到提升系统处理能力的目的。并且对队列的长度进行监控，当超过某个阀值，则拒绝新的请求。对请求设置超时时间，当请求包从队列里读取出来是判断请求是否超时，如果超时则不做处理。
3. 如何实现负载均衡
节点的负载如何衡量：根据不同类型的系统应用，通常会定义不同的度量方式，如：CPU资源、内存资源、当前进程数、吞吐量、成功率、响应时间等指标都可以作为负载度量的指标，各个指标的重要程度根据实际情况有所不同。
除了基于客户端方式，其他架构上实际上都是引入一个均衡服务器做控制或代理，或是返回请求的调度结果，亦或是直接对请求做转发。 结合TAF的设计理念和架构做思考，负载均衡器其实可以放到主控侧来实现，但是我认为由于负载均衡策略的复杂性，单是对调度决策数据分析已经非常繁重，因此负载均衡通常还是单独引入一个接入层（统一接入网关）来实现
根据前面对Client调用的分析可知，客户端会采用选定的负载均衡策略选择一个Invoker，对请求进行路由分发。 目前支持的负载均衡策略有Round-Robin轮询、带权重轮询、Hash、带权重Hash、一致性Hash ：
轮询（RoundRobin）将请求顺序循环地发到每个服务器。当其中某个服务器发生故障，均衡服务器就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。
比率（Ratio）：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。当其中某个服务器发生故障，AX就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
优先权（Priority）：给所有服务器分组，给每个组定义优先权，将用户的请求分配给优先级最高的服务器组（在同一组内，采用预先设定的轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器或者指定数量的服务器出现故障，AX将把请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。
哈希算法( hash): 将客户端的源地址，端口进行哈希运算，根据运算的结果转发给一台服务器进行处理，当其中某个服务器发生故障，就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
4. 微服务框架有哪些
Spring Cloud ：java
Docker Swarm
Dubbo ：java
5. RPC远程调用
（RPC）远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
组成：
序列化层：序列化主要作用是将结构化对象转为字节流以便于通过网络进行传输或写入持久存储，在RPC框架中，它主要用于将用户请求中的参数或者应答转化成字节流以便跨机器传输。常用的序列化方式有xml，json，hessian，pb等。
函数调用层：函数调用层主要功能是定位要调用的函数并执行该函数，可以采用Java反射机制与动态代理实现函数调用。（JAVA反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意方法和属性；这种动态获取信息以及动态调用对象方法的功能称为java语言的反射机制。 ）
网络传输层：网络传输层描述了Client与Server之间消息传输的方式。
服务器端处理框架：服务器端处理框架可被抽象为网络I/O模型，它描述了客户端与服务器端间信息交互方式，它的设计直接决定着服务器端的并发处理能力，常见的网络I/O模型有阻塞式I/O、非阻塞式I/O、事件驱动I/O等，而Hadoop RPC采用了基于Reactor设计模式的事件驱动I/O模型。
RPC 结构拆解
如下图所示。
RPC 服务方通过 RpcServer 去导出（export）远程接口方法，而客户方通过 RpcClient 去引入（import）远程接口方法。 客户方像调用本地方法一样去调用远程接口方法，RPC 框架提供接口的代理实现，实际的调用将委托给代理 RpcProxy 。 代理封装调用信息并转交给 RpcInvoker 去实际执行。 在客户端的 RpcInvoker 通过连接器 RpcConnector 去维持与服务端的通道 RpcChannel， 并使用 RpcProtocol 执行协议编码（encode）并将编码后的请求消息通过通道发送给服务方。
RPC 服务端接收器 RpcAcceptor 接收客户端的调用请求，同样使用 RpcProtocol 执行协议解码（decode）。 解码后的调用信息传递给 RpcProcessor 去控制处理调用过程，最后再委托调用给 RpcInvoker 去实际执行并返回调用结果。
连接方式
长连接的TCP协议
对比web服务器：
- 从使用方面看，Http接口只关注服务提供方（服务端），对于客户端怎么调用，调用方式怎样并不关心，通常情况下，客户端使用Http方式进行调用时，只要将内容进行传输即可，这样客户端在使用时，需要更关注网络方面的传输，比较不适用于业务方面的开发；而RPC服务则需要客户端接口与服务端保持一致，服务端提供一个方法，客户端通过接口直接发起调用，业务开发人员仅需要关注业务方法的调用即可，不再关注网络传输的细节，在开发上更为高效。（RPC是服务端提供好方法给客户端调用。定位到类，然后通过类去调用方法。）
- 从性能角度看，使用Http时，Http本身提供了丰富的状态功能与扩展功能，但也正由于Http提供的功能过多，导致在网络传输时，需要携带的信息更多，从性能角度上讲，较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据，传输数据更小，性能更高。
- 从运维角度看，使用Http接口时，常常使用一个前端代理，来进行Http转发代理请求的操作，需要进行扩容时，则需要去修改代理服务器的配置，较为繁琐，也容易出错。而使用RPC方式的微服务，则只要增加一个服务节点即可，注册中心可自动感知到节点的变化，通知调用客户端进行负载的动态控制，更为智能，省去运维的操作。