定义

微服务是一种开发软件的架构和组织方法。其中软件由通过明确定义的 API 来通信的小型独立服务组成。简而言之，微服务架构是一种将单个应用程序拆分为一组小型服务的方法，每个小型服务都在自己的独立进程中运行并与轻量级机制（通常是 HTTP 资源 API）进行通信。 这些服务围绕业务功能构建，并且可以由全自动部署机制独立部署。

微服务 & SOA

微服务和 SOA 本质上是两种不同的架构设计理念，只在“服务”这点上有交集。

服务粒度

• SOA
  • 粒度大（系统级：人事系统、运营管理系统……）
• 微服务
  • 粒度小（服务级：人事系统再拆分（员工信息服务、员工考勤服务……））

服务通信

• SOA
  • ESB：重量级实现（各种协议转换、消息转换、路由等）
• 微服务
  • RESTFul、RPC：轻量级实现（仅做消息传递）

服务交付

• SOA
  • 仅考虑兼容已有系统
• 微服务
  • 快速交付（需要自动化测试、持续集成、持续部署等实践）

应用场景

• SOA
  • 适用于庞大、复杂、异构的企业级系统（特征：发展多年、采用不同的企业级技术；有的内部开发、有的外部购买）
• 微服务
  • 适合快速、轻量级、基于 Web 的互联网系统（特征：业务变化快、需求快速尝试、快速交付）

微服务陷阱

1. 划分过细
   • 服务间关系复杂
   • 服务数量过多
     • 团队效率急剧下降（需要管理多个工程）
2. 调用链太长
   • 性能下降（多次调用）
   • 问题定位困难
     • 用户请求可能需要多个服务协同工作，每个环节都有可能出问题
3. 自动化支撑不够
   • 无法快速交付
4. 没有服务治理
   • 服务数量多了之后管理困难
     • 服务路由
     • 故障隔离
     • 服务注册和发现

微服务最佳实践

服务拆分

团队足够完善的情况下，拆分数量可以遵循“三个火枪手”原则，即一个微服务三个人负责开发。

拆分方法

1. 基于业务逻辑拆分
   • 方法
     a. 将系统中的业务按照职责范围（较难确定）识别出来
     b. 每个当独的业务模块拆分为一个独立的服务
2. 基于可扩展性拆分
   • 方法
     a. 将系统中的业务按照稳定性排序
     b. 将已经成熟、改动不大的拆分为稳定服务
     c. 将经常变化和迭代的服务拆分为变动服务
   • 优势
     • 提升项目迭代速度
     • 避免开发的时候影响已有的成熟功能
3. 基于可靠性拆分
   • 方法
     a. 将系统中的业务按照优先级排序
     b. 将可靠性要求高的服务和不高的服务拆分开
     c. 重点保障可靠性要求高的服务
   • 优势
     • 避免非核心服务故障影响核心服务
     • 核心服务高可用方法可以更简单
     • 降低高可用成本
4. 基于性能拆分
   • 方法
     a. 将系统中的业务按照性能压力排序
     b. 将高性能要求和非高性能要求的服务拆分
   • 优势
     • 避免高性能要求服务影响其它服务

基础设施

并不是每个基础设施都是必须的。可以根据系统业务发展阶段进行补充。

优先级

1. 服务发现，服务路由，服务容错
   • 基本服务
2. 接口框架，API 网关
   • 接口框架：提升内部开发效率
   • API 网关：提升外部对接效率
3. 自动化部署、测试，配置中心
   • 提升测试、运维效率
4. 服务监控，服务跟踪，服务安全
   • 进一步提升运维效率

3 和 4 的重要性随节点数增加而越来越重要，在少的时候，可以人肉支撑。

单元

服务发现

• 需求
  • 人功维护服务地址困难（服务数量变多、部署节点变化）
• 核心功能
  • 服务注册表
    • 提供注册服务（记录服务节点配置、状态）
    • 提供查询服务
• 实现
  1. 自理式
     • 原理：每个微服务自己完成服务发现
     • 优点
       • 实现简单（一次开发、多次使用）
       • 服务发现压力小（分散到每个微服务中）
  2. 代理式
     • 原理：每个微服务之间有一个负载均衡系统（由负载均衡实现服务发现）
     • 优点
       • 服务更简单
     • 缺点
       • 可用性风险（负载均衡本身的可用性难保证）
       • 性能风险（所有微服务的服务发现都走负载均衡，导致负载均衡压力大）

服务路由

• 需求
  • 在服务调用时，需要充符合条件的可用微服务中选取一个进行处理
• 核心功能
  • 路由算法
    • 随机路由
    • 轮询路由
    • 最小压力路由
    • 最小连接数路由
• 实现（通常跟服务发现在一个系统中）
  1. 自理式（微服务内部实现）
  2. 代理式（负载均衡实现）

服务容错

• 需求
  • 服务增多，故障概率增大；需要在服务故障的情况下，不影响其他服务
• 核心功能
  • 容错方式
    • 请求重试
    • 流控
    • 服务隔离
• 实现（通常跟服务发现、路由一起实现）

接口框架

• 需求
  • 需要统一的接口协议和数据格式
• 实现（非独立系统，通常以库或者包的形式提供给微服务调用）

API 网关

• 需求
  • 微服务被外部访问时，外部不需要知道服务的具体职责、边界等（不需要知道什么服务由哪个微服务提供）；外部访问访问微服务还有权限等安全问题
• 核心功能
  • 接入鉴权
  • 权限控制
  • 传输加密
  • 请求路由
  • 流量控制
• 实现（独立实现）

自动化部署

• 需求
  • 服务数量众多、迭代快，人工部署压力大、易出错
• 核心功能
  • 版本管理
  • 资源管理（机器管理，虚拟机管理）
  • 部署操作
  • 回退操作
• 实现（独立系统）

自动化测试

• 需求
  • 服务数量众多、迭代快，人工（回归）测试效率低、工作量大
• 核心功能
  • 代码级单元测试
  • 系统级集成测试
  • 系统间接口测试（重点关注）
• 实现

配置中心

• 需求
  • 节点多，人工登录每台节点部署、修改配置工作量大、效率低、易出错、多节点统一即时生效困难
• 核心功能
  • 配置版本管理
  • 配置增删改查
  • 节点管理
  • 配置同步
  • 配置推送
• 实现（独立系统）

服务监控

• 需求
  • 服务故障快速定位
• 核心功能
  • 实时搜集信息并分析
  • 故障预警
• 实现（独立系统）

服务跟踪

• 需求
  • 跟踪请求的完整路径
• 核心功能
  • 记录某次请求发起时间、响应时间、响应错误码、请求参数、返回结果等信息
• 实现（？）

服务安全

• 需求
  • 敏感数据不允许所有服务访问（只能部分服务访问）
• 核心功能
  • 接入安全
  • 数据安全
  • 传输安全
• 实现（通常集成到配置中心系统，配置中心提供策略配置；调用策略封装成包、库提供给微服务调用）