物理机部署
传统发布流程(以Java spring boot为例)
- 编译jar包
- 分发到服务器A,B,C
- 服务启动,监听到指定端口
- 配置负载均衡到已启动服务端口
- 服务发布成功
关于服务更新,为了实现滚动更新,能够让LB绑定的服务逐渐更新java
传统更新流程
- 编译jar包
- 分发到服务器A,B,C
- 将服务器A从LB上解绑,更新服务器A上的服务
- 启动服务,经过健康检查和QA以后,将服务器A绑定到LB上
- 继续更新服务器B和C
- 服务彻底更新成功
拓容流程
特色
- 单机端口有限,同一个服务若是在同一个服务器更新,须要不一样的端口
- 动态更新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和内存利用率升高,经过水平拓展,增长服务节点;服务压力减小后,逐渐减小服务节点数量