微服务

微服务 §

微服务与SOA的区别 §

技巧💡

SOA，是将多个系统整合
微服务，是将单个系统拆开

典型观点:

• 微服务是 SOA 的实现方式
  • 这种观点认为 SOA 是一种架构理念，而微服务是 SOA 理念的一种具体实现方法。例如，“微服务就是使用 HTTP RESTful 协议来实现 ESB 的 SOA”“使用 SOA 来构建单个系统就是微服务”和“微服务就是更细粒度的 SOA”
• 微服务是去掉 ESB 后的 SOA
  • 这种观点认为传统 SOA 架构最广为人诟病的就是庞大、复杂、低效的 ESB，因此将 ESB 去掉，改为轻量级的 HTTP 实现，就是微服务
• 微服务是一种和 SOA 相似但本质上不同的架构理念
  • 这种观点认为微服务和 SOA 只是有点类似，但本质上是不同的架构设计理念。相似点在于下图中交叉的地方，就是两者都关注“服务”，都是通过服务的拆分来解决可扩展性问题。本质上不同的地方在于几个核心理念的差异：是否有 ESB、服务的粒度、架构设计的目标

	SOP	微服务
服务颗粒度	粗，如 员工管理系统是一个服务	细，如员工管理系统，可能会拆成 员工信息管理,员工考勤管理
服务通信	ESB,重量级	轻量级，如Restful, rpc
服务交付	慢	快速
应用场景	庞大、复杂、异构的企业级系统	互联网，快速交付

微服务的陷阱 §

1. 服务划分过细，服务间关系复杂。
2. 服务数量太多，团队效率急剧下降。
3. 服务调用链长，性能下降。
4. 调用链太长，问题定位困难。链路追踪系统
5. 没有自动化支撑，无法快速交付
6. 没有服务治理，微服务数量多了后管理混乱
   1. 服务路由
   2. 服务注册与发现
   3. 服务隔离，熔断，降级，限流。避免雪崩

微服务最佳实践 §

1. 服务不是越多越好，应该要有服务拆分的方法论。可以按照有多少人拆多少系统。
2. 微服务的搭建，需要配套基础服务设施。不然使用起来，会很难受。效率底下。

微服务最佳实践(服务拆分) §

服务颗粒度 §

• 三个火枪手, 一个微服务三个人负责开发。主要应用于微服务设计和开发阶段，而不是偏维护性质的维护期。
• 根据多少人来决定系统怎么拆分: 康威定理

服务拆分 §

技巧💡

拆分的方法可以多个组合。比如 按业务逻辑，分成订单服务。 订单服务下，还可以按照是否黄金流程拆分。

1. 基于业务逻辑拆分，如用户服务，订单服务，支付服务
2. 基于重要程度拆分，如黄金流程，普通流程
   1. 避免非核心服务故障影响核心服务
   2. 核心服务高可用方案可以更简单
3. 基于可扩展性拆分，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。
4. 基于性能拆分，

微服务最佳实践(基础服务设施) §

• 功能篇

  • 服务注册发现: 自动管理服务进行自动注册和发现
  • 服务路由:(调用哪个具体的服务实例)常见的有随机路由、轮训路由、最小压力路由、最小连接数路由
  • 服务容错（请求重试、流控、服务隔离、熔断等): 调用报错了，怎么处理。一般服务容错会集成到服务发现和服务路由系统中
  • API网关(鉴权，传输加密、请求路由、流量控制)
  • 配置中心(动态生效，重启生效)，一个地方改了，不用所有服务通知
  • 服务安全: 分接入、数据、传输三个部分，一般集成到配置中心实现安全策略
  • 接口框架: 约定接口返回规范等

• 运维篇

  • 服务监控： 宏观实时采集信息并分析，故障预警能力，一般作为独立系统建设
  • 服务跟踪: 微观实时采集记录服务调用的链路信息，记录完整的服务链路路径，后置定位使用
  • 自动化测试: 代码级单元测试、单系统级集成测试、系统间的接口测试、精准测试等自动化测试.
  • 自动化部署: 包含微服务版本管理、资源管理（机器、虚拟机）、部署操作、回退操作等功能
    建设优先级

• 业务运行的基础建设

  • 配置中心
  • 服务发现
  • 服务路由
  • 接口框架
  • API网关

• 业务运行的体验建设

  • 服务容错
  • 服务监控
  • 服务跟踪
  • 服务安全

• 业务可持续维护的建设

  • 自动化测试
  • 自动化部署

资料 §

• 深入理解微服务架构
• 极客时间-微服务架构最佳实践
• 极客时间-微服务架构最佳实践 - 基础设施篇