为什么要用微服务

小项目发展到大项目过程中，出于维护、稳定性等考虑，将一个整体项目分为多个微小服务。

为什么说做好微服务很难

要想做好微服务，我们需要理解和掌握的知识点非常多，从几个维度上来说：

基本功能层面

  1. 并发控制&限流，避免服务被突发流量击垮
  2. 服务注册与服务发现，确保能够动态侦测增减的节点
  3. 负载均衡，需要根据节点承受能力分发流量
  4. 超时控制，避免对已超时请求做无用功
  5. 熔断设计，快速失败，保障故障节点的恢复能力

高阶功能层面

  1. 请求认证，确保每个用户只能访问自己的数据
  2. 链路追踪，用于理解整个系统和快速定位特定请求的问题
  3. 日志，用于数据收集和问题定位
  4. 可观测性，没有度量就没有优化

微服务系统如何拆分

  • 先粗后细，切忌过细，切忌一个请求一个服务
  • 横向拆分，而非纵向，我们一般不会超过三层
  • 单向调用，严禁循环调用
  • 禁止接口类型透传，如 model 层的一个结构体，三个微服务都用到了，这样会导致代码耦合
  • 没有依赖关系的串行调用改为并行调用

微服务网关

微服务网关的作用是在用户第一个网关服务器，你按照业务服务相关需求，给网关分流，相比云主机厂商提供的负载均衡器，强大在于你可以根据自己业务去分流，同时还以可以实现鉴权、校验、聚合、缓存等自定义服务，而云主机的负载均衡器只是一个简单按照流量给你负载均衡请求，不具有自定义编程性质。

简单实现流程：

  1. 启动一个微服务网关，用于注册和发现服务，提供统一的对外域名和端口，如 127.0.0.1:80
  2. 将大项目拆分成多个微小服务，如商城订单服务、商城商品服务，每个服务对应 『不同域名』或『相同域名不同端口』，如 127.0.0.1:81 和 127.0.0.1:82
  3. 前端调用后端接口时，直接请求微服务网关（如 127.0.0.1:80），然后微服务网关再根据路由归属，将请求转发到对应微服务模块的 域名+端口 下
  4. 最后前端的请求会在对应微服务模块下处理后，将响应结果转发到微服务网关，再由微服务网关返回响应结果给前端

如果不用微服务网关，则另有两种选择：

  1. 选择一： 不同的服务，使用不同的域名访问 （前端需要对接多个域名）
  2. 选择二： 不同的服务使用不同的路由前缀，使用 nginx 来定向 （前端需要改很多个接口）

微服务的事务处理怎么实现好

  • 2PC，两阶段提交
  • TCC，Try-Confirm-Cancel
  • 消息队列，最大尝试
  • 人工补偿