微服务

1. 前后端分离具体如何实现

现主流前后端分离多数为：

前端：Vue/Angular/React

中间件：Nodejs

后端：Java/Go

前后端交互基于Nodejs作为中间层，不再直接进行交互。

2. 微服务哪些框架

SpringBoot

SpringCloud

3. 如何理解RPC框架

RPC：Remote Procedure Call 远程过程调用。RPC被用来作为远程调用的框架，主要用于公司内部服务直接的互相调用，具有性能消耗低、传输效率高、服务治理方便等特点。

HTTP：RPC底层协议可以像HTTP一样基于TCP协议，也可以直接基于HTTP协议。HTTP主要用于对外的异构环境。

4. RPC的实现原理

RPC框架需要三个角色：

• Server：服务提供方。
• Register：服务注册与发现的中心。
• Client：服务调用方。

场景：

​ 人民群众有事拨打110电话，110指挥中心根据沟通获取人民群众的位置，派出就近的民警前往现场。

如上这就是一个RPC框架的场景，

人民群众就是 服务调用方，需要就近的民警出警；

110指挥中心就是 服务注册与发现的中心，对各地警力具有实时的掌握以及调度权限；

就近民警就是 服务提供方，能够及时的为人民群众排忧解难。

服务提供方在启动后需要向 服务注册与发现中心注册当前服务IP、端口、服务列表等信息；服务调用方在需要调用时向 服务注册与发现中心获取当前可提供服务的ip、端口、服务接口等信息，通过HTTP等协议进行通信。

5. 说说Dubbo/Spring Cloud的实现原理

• Dubbo

  https://segmentfault.com/a/1190000042674690

• Spring Cloud

​ SpringCloud有五大核心组件，基于这五大组件构成了分布式微服务架构的解决方案。

https://blog.csdn.net/qq_36986510/article/details/127324912

6. 如何理解RESTful

REST：Representational State Transfer，表象状态转移。

RESTful是一种架构的规范与约束，目的是：统一接口。

REST要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。

7. 如何设计一个良好的API

满足：标准化、兼容性、抽象性、简单性、高性能。

• 标准化：尽可能少的创建自定义规范和机制，使用共同遵守业内标准。
• 兼容性：通过版本号解决多版本兼容性的问题。
• 抽象性：定义清晰的问题领域模型，尽可能屏蔽具体的业务实现细节。
• 简单性：相对的，遵循最少知识原则，让调用方尽可能少的知道内部调用细节。
• 高性能：业务组合复杂性以及入参。

8. 如何理解RESTful的幂等性

接口幂等性：指调用某个接口1次或者n次，对访问资源产生的影响的结果都是一样的。

接口符合幂等性可以降低系统实现的复杂性，并能够保证资源状态的一致性。

9. 如何保证接口的幂等性

• 分布式锁
• 数据库唯一索引
• 乐观锁

10. 说说CAP定理、BASE理论

• CAP定理

  分布式系统最多只能满足CAP理论中的2项

  • C：Consistency 一致性，这里指的是数据一致性，也就是同一时间所有数据是一致的。（弱一致性、抢一致性、最终一致性）
  • A：Availability 可用性，这里指的是服务一直可用。
  • P：Partition tolerance 分区容错性，这里指分布式系统在某个节点故障时，仍能够对外提供服务。

• BASE理论

  ​ 是对CAP理论的延伸，核心思想是：无法满足强一致性，也可以采用适合的方式达到最终一致性。

  • B A：Basically Available 基本可用，这里是指分布式系统出现故障后，允许损失部分可用性，保证核心可用。
  • S E：Soft State 软状态，指允许系统存在中间状态，这个状态不会影响系统可用性。

11. 怎么考虑数据一致性问题

按架构区分：单体架构、分布式架构

• 单体架构

  单体架构的数据一致性可以通过同一个数据库事务进行处理，数据库事务能够保证全部成功或全部回退。

• 分布式架构

  分布式架构下，已无法满足 同一个数据库事务的前提，此时 分布式事务是解决分布式架构下数据一致性的方案。

  现如今分布式事务有多种实现方案：2PC、3PC、TCC、本地消息表等解决方案，具体方案参考：Java面试题-分布式事务

12. 说说最终一致性的实现方案

常见TCC实现最终一致性：

TCC：Try-Confirm-Cancel ，两阶段提交的变种；先尝试执行业务，执行成功则更新成功状态；执行失败则更新失败状态。

Try：尝试联通服务并冻结所需要的资源。

Confirm：所有的Try都可行，则执行Confirm逻辑。

Cancel：当有服务宕机或资源无法满足冻结，则执行Cancel逻辑。

13. 如何看待微服务

微服务的目的就是：有效拆分应用，实现敏捷开发和独立部署。

现在大数据时代下，PC、手机都能够发起请求，此时微服务对于一个系统而言，能够极大的降低系统的耦合度，适用于任何一个分布式系统。

14. 微服务与SOA的区别

SOA：面向服务的架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。

这两其实是差不多的，SOA关注的是服务重用，微服务在SOA的基础上，也关注业务划分。

15. 如何拆分服务

纵向拆分：基于业务逻辑拆分，根据不同业务进行服务拆分。

横向拆分：从公共且功能独立的维度进行拆分。

16. 微服务如何进行数据库管理

根据业务场景进行实际分析；对于没有强一致性要求的业务和强一致性要求的业务对数据库的要求是不一样的。

微服务如何进行数据库管理

17. 如何应对微服务链式调用异常

一般情况下，每个微服务之间是独立的，如果某个服务宕机，只会影响到当前服务，而不会对整个业务系统产生影响。但是，服务端可能会在多个微服务之间产生一条链式调用，并把整合后的信息返回给客户端。在调用过程中，如果某个服务宕机或者网络不稳定可能造成整个请求失败。

因此，为了应对微服务的链式调用异常，我们需要在设计微服务调用链时不宜过长，以免客户端长时间等待，以及中间环节出现错误造成整个请求失败。

此外，可以考虑使用消息队列进行业务解耦，并且使用缓存避免微服务的链式调用从而提高该接口的可用性。

18. 对于快速追踪与定位问题

在微服务复杂的链式调用中，我们会比单体架构更难以追踪与定位问题。因此，在设计的时候，需要特别注意。

一种比较好的方案是，当 RESTful API 接口出现非 2xx 的 HTTP 错误码响应时，采用全局的异常结构响应信息。

19. 微服务的安全

• 单点登录：微服务多的场景下，带来大量重复的网络流量。
• 分布式会话：用户认证信息存储在共享存储（Redis）中，通过对共享存储的读取获取用户认证信息。
• 客户端Token：客户端生成，服务器签名；每个请求携带该Token，通过短期令牌和定期检查令牌有效性。
• 网关+客户端Token：所有客户请求经由网关处理，网关增加一层过滤器进行Token的过滤。

微服务安全