微服务架构

• 旧的3层架构

  • 负载均衡层
  • web层
    • 承担太多，既要处理请求，又要处理业务
  • 数据库层

• 更优的架构

  • 从web层中，拆分出一个应用层(也叫平台层)
  • 好处
    • 能单独扩展应用层，独立加机器，或换专用机器
    • 可以由多个web项目复用
    • 解耦后更有利于专业团队开发
  • 挑战
    • 应用层内部，如何划分职责(模块)，如何协同工作(通信)
    • 于是有了下面的微服务架构

• 微服务架构

  • 提倡把应用程序设计成一系列 松耦合的 细粒度服务，并通过轻量级的通信协议组织起来
  • 好处
    • 服务都能独立部署和扩展
    • 有稳固的模块边界
    • 甚至允许用不同的语言编写
    • 多个服务各自运行在 不同机器的 不同进程中
  • 挑战
    • 如果微服务只运行在单台机器上
      • 可以通过 静态配置表 找到其他服务，经由服务间通信完成协作
    • 但是，1个微服务通常部署在多台机器上，并且需要动态伸缩
      • 所以需要一种 服务注册查询机制(discovery service)，使其可以互相通信

• 服务发现

  • 实现方式1——客户端发现(不推荐)

    • 客户端 自己维护一个 服务注册表，通过请求得到目标服务的一系列地址，并根据负载均衡策略，从中选择一个发起请求
    • 例子
      • Netflix Eureka 提供了 REST API 实现
    • 服务注册表
      • 存放所有可用的服务实例，提供管理功能(注册/注销)和查询接口
      • 在一个服务实例启动时，向注册表添加其位置，服务停止时，请求移除记录，运行期间，通过心跳机制周期性刷新注册信息
      • 比如

  • 实现方式2——服务端发现

    • 客户端 经由服务端的负载均衡器请求目标服务，负载均衡器查注册表得到一组可用实例，并根据负载均衡策略，从中选择一个发起请求
    • 例子
      • AWS Elastic Load Balancer (ELB)

• 两种注册模式

  • 自注册(不推荐)
    • 服务实例 自己到服务注册表中登记，以及从中注销，必要的话还要发送心跳保持活跃
    • 相对简单，但 服务实例 和 注册机制 产生了耦合
  • 第三方注册
    • 服务实例不再负责 登记和注销，而是交由登记员来处理
    • 解除了耦合关系，登记员通过 轮询或订阅 跟踪服务实例的运行状态
      • 发现新服务实例，就注册上去
      • 发现服务实例停掉，就注销掉