微服务实践三: 服务编排
物理机部署
传统发布流程（以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和内存利用率升高，通过水平拓展，增加服务节点；服务压力减少后，逐渐减少服务节点数量