微服务实践三: 服务编排

物理机部署

传统发布流程(以Java spring boot为例)

  • 编译jar包
  • 分发到服务器A,B,C
  • 服务启动,监听到指定端口
  • 配置负载均衡到已启动服务端口
  • 服务发布成功

关于服务更新,为了实现滚动更新,可以让LB绑定的服务逐渐更新

传统更新流程

  • 编译jar包
  • 分发到服务器A,B,C
  • 将服务器A从LB上解绑,更新服务器A上的服务
  • 启动服务,通过健康检查和QA之后,将服务器A绑定到LB上
  • 继续更新服务器B和C
  • 服务完全更新成功

拓容流程

  • 新增机器节点
  • 启动jar包
  • 将新节点注册到LB上

特点

  • 单机端口有限,同一个服务如果在同一个服务器更新,需要不同的端口
  • 动态更新LB
  • 拓容成本高

服务化部署(这里以kubernetes为例)

k8s发布流程

  • 构建docker镜像
  • 创建deployment和service,可以限制服务的CPU、Memory等资源,k8s寻找空闲节点启动服务
  • 更新iptables将物理机上指定端口路由到VIP(虚拟服务IP)
  • 绑定物理机端口到LB

k8s更新流程

  • 构建docker镜像
  • 更新deployment和service,k8s更新某个pod
  • 轮流更新pod,直到所有pod更新完成

k8s拓容

  • 寻找空闲节点启动服务,直到达到指定数量

特点

  • 几乎无物理端口限制(k8s需要物理端口作为转发,默认为30000+,数量有限)
  • 服务间通信,可以使用serviceName或者服务的VIP进行访问,内网访问更方便
  • 虚拟化物理机资源,隔离物理资源的细节,资源控制如拓容、服务资源限制方便

Kubernetes vs Docker swarm

  • 稳定性上,k8s上基于iptables的网络路由比docker swarm的网络更加稳定
  • 配置性上,k8s比docker swarm要复杂,swarm采用manager-worker架构,由manager调度worker,docker 1.12以上对于swarm原生支持,方便启动集群,不过k8s在新版本之后也越来越易于配置
  • 管理系统上,swarm比k8s的UI界面更友好,操作性更强

微服务架构下的应用

  • 外部访问可以暴露gateway到LB上,外部通过访问LB进行访问
  • 使用k8s或者swarm,服务间通信可以使用serviceName进行访问,也可以利用容器的IP,使用服务注册进行服务查询
  • 自动拓容,当检测到服务的CPU和内存利用率升高,通过水平拓展,增加服务节点;服务压力减少后,逐渐减少服务节点数量
posted @ 2017-04-14 15:50  Srggggg  阅读(...)  评论(...编辑  收藏