微服务编排与容器调度

微服务 容器 Docker Kubernetes

1. 微服务需要编排吗？

1.1 什么是微服务

• 一个微服务一般完成某个特定的功能，比如订单管理、客户管理等等
• 每一个微服务都有自己的业务逻辑和适配器
• 一些微服务还会发布 API 给其他微服务和应用客户端使用

1.2 编制与编排

编制(Orchestration)：

• 面向可执行的流程
• 通过一个可执行的流程来协同内部及外部的服务交互
• 通过中心流程来控制总体的目标、涉及的操作、服务调用顺序

编排(Choreography)：

• 面向合作
• 通过消息的交互序列来控制各个部分资源的交互
• 参与交互的资源都是对等的，没有集中的控制

编排(Choreography)的难点：

• 编排难调试
• 由于没有预定义流程，所以很难事前保证流程正确性，基本靠事后分析数据来判断
• 业务流程的维护比较困难

2. 微服务编排的流程

2.1 图形化的编排

• 采用图形化的编排，可以屏蔽代码细节处理，让整个流程一目了然
• 原子服务可以提供 REST 接口或者监听事件，可以通过流程编排这些原子服务来实现一个新的复杂服务

2.2 编排的模型

编排的模型包括：

• 活动模型：赋值、invoke(调用)、空
• 控制模型：顺序、分支、循环、异常抛出、异常捕获、并行

编排框架还提供了例如本地调用、REST 调用、同步/异步调用等活动，从而在使用上更加方便。

2.3 服务雪崩、降级与熔断

在调用的时候我们知道有同步和异步的区别：
- 同步实现起来比较简单
- 但是在多级级联编排的时候要避免因为某个服务的不可用导致雪崩效应
- 一般可以通过设置合理的超时时间限流和服务熔断策略来避免

当Service A调用Service B，失败次数达到一定阈值时，Service A就不会再去调用Service B，而是降级去执行本地的方法。

2.4 服务参数的适配

• 流程编排完成之后，我们还需要给每个被编的服务提供正确的参数，是一个适配的过程
• 一个编排服务 (abcd) 由 a、b、c、d 服务编排而成
• 每个服务都会有自己的出参入参
• 适配的过程就是从上下文中给入参赋值以及将出参的结果写入到上下文中

• 编排服务执行到不同阶段，组成上下文的模型也是不一样的
• 从最初服务的开始执行的时候，上下文中只有系统级的参数和入参（请求报文）
• 到执行完一个被编服务后上下问就会增加这个被编服务的出参（响应报文）
• 执行上下文是一个不断增大的过程
• 适配不仅仅存在与编排服务的入参和被编服务的入参之间，还存在于被编服务和在其之前的服务出参之间

3. 微服务基础架构

3.1 核心模块

微服务基础架构的核心模块包括：

• 服务框架
• 运行时支撑服务
• 后台服务
• 服务安全
• 服务容错
• 服务监控
• 服务部署平台

3.2 微服务架构总体技术体系

3.3 微服务 vs K8s

• 在微服务设计的十个要点中，我们会发现 Kubernetes 都能够有相应的组件和概念，提供相应的支持
• 其中最后的一块拼图就是服务发现，与熔断限流降级

4. 企业案例

4.1 网易公有云容器平台

K8s 的架构本身就是微服务，支持定制化与横向扩展：

在 K8s 中几乎所有的组件都是无状态化的，状态都保存在统一的 etcd 里，扩展性很好，组件之间异步完成自己的任务，将结果放在 etcd 里面，互相不耦合：

网易云对容器创建流程进行了定制化。由于大促和非大促期间，节点的数目相差比较大，因而不能采用事先全部创建好节点的方式，这样会造成资源的浪费，因而中间添加了网易云自己的模块 Controller 和 IaaS 的管理层，使得当创建容器资源不足的时候，动态调用 IaaS 的接口，动态的创建资源。这一切对于客户端和 kubelet 无感知：

K8s 的每个组件都可进行独立的优化，互不影响：

1. 通过优化 Scheduler 解决并行调度的问题

• 大的资源池的调度也是一个很大的问题，因为同样一个资源只能被一个任务使用
• 如果并行调度，则存在两个并行的调度器同时认为某个资源空闲，于是同时将两个任务调度到同一台机器的竞争情况
• 为了租户隔离，不同租户之间是不共享虚拟机的，这样不同的组合是可以参考 Mesos 机制进行并行调度的。每个租户仅在属于自己的有限节点中进行调度，大大提高了调度策略的并发性
• 并且通过预过滤无空闲资源的 Node，调整 predicate 算法进行预过滤，进一步减少调度规模

2. 通过优化 Controller 加快新任务的调度速度

• K8s 采用的是微服务常使用的基于事件的编程模型
• 但基于事件模型的一个缺点是，总是通过 delta 进行事件触发，过了一段时间，就不知道是否同步了，因而需要周期性地 Resync 一下，保证全量的同步之后，然后再进行增量的事件处理
• 然而问题来了，当 Resync 时，正好遇到一个新容器的创建，则所有的事件在一个队列里面，拖慢了新创建容器的速度
• 通过保持多个队列，并且队列的优先级 ADD 优于 Update 优于 Delete 优于 Sync，保证相应的实时性

4.2 网易云轻舟微服务

1. 产品全景

2. 产品功能

4.3 新浪微博混合云 DCP

1. 容器编排

• 容器编排是跨主机去管理多个集群 Container 的一种行为，随着 Docker 的发展，生态圈越来越完善，比较常见的 Kubernetes，Mesos + Mathon，甚至 DCOS 等都属于此类范畴
• 容量编排是为了将资源利用率最大化，同时均衡系统因容错需要不断变化的需求

2. 容器编排需要解决的问题

1. 服务定义：一般以 IP + port 唯一标识一个服务，这里端口的分配与管理会成为重点
2. 资源管理：一个服务要运行，需要相应的资源，一般是 CPU/MEM/DISK/NET 等，怎么获取到这些资源，并合理分配是资源管理需要关注的部分，一般采用池化处理（资源池）。这也是编排的核心
3. 容器调度：有了资源，怎么合理的选择资源节点，采取什么策略，怎么做容错处理等等，这些是容器调度需要关注的
4. 服务检测：服务在起来后，要对外提供，需要验证其正确性，这里一般会做端口及业务检测
5. 服务发现：验证通过的服务，如果真正对外提供服务，需要引入流量，也就是自动挂到 LB 上，这也是一种 WEB 类的服务发现

3. 分层的编排

新浪混合云系统 DCP 在设计之初遇到了一个很明显的问题：很难用单一的 IaaS，PaaS 或 CaaS 去定义我们的场景：
- 于是选择了混合云的模式
- 系统采用分层设计的方法去适应业务场景

不同的层是存在不同的编排方法的：

• IaaS 的编排核心重点在计算资源
• PaaS 的编排核心在于应用
• CaaS 的编排核心在于容器即服务

对于新浪混合云 DCP，主要有以下两大方面：

• 服务的编排：重在弹性，比如扩容，缩容，容器迁移，容错处理，服务发现等
• 资源的编排：重在资源，对于私有云主要是物理机的管理与分配；对于公有云主要是标准化的 VM

4. 微博混合云 DCP 架构设计

微博目前开发的 DCP 主要包含三层：

• 资源管理层：分为内网主机和阿里云 ECS，目标是对上层业务提供统一、不可变的基础环境
• 容器调度层：根据资源区调度并启动容器，提供各种原子性的操作，例如基于任务模式的容器起、停、删、重启、服务注册、服务反注册、服务检测等等
• 业务编排层：基于调度层的 API，去串起整个业务的常见操作，比如服务部署、扩容、缩容、容器迁移等等

5. DCP 的功能模块

参考文章

1. 微服务编排之道 | 掘金
2. 微服务核心研究之编排 | 简书
3. 编排的艺术：K8S 中的容器编排和应用编排 - Kuberneteschina | 知乎专栏
4. 几种常见的微服务编排模式 | Neohope's Blog
5. kubernetes 容器编排系统介绍 | 腾讯云+社区
6. 容器编排的作用和要实现的内容 | CSDN
7. 从 kubernetes 看如何设计超大规模资源调度系统 | CSDN
8. 编排管理成容器云关键 Kubernetes（K8s）和Swarm对比分析 | kubernetes 中文社区
9. 云编排技术：探索您的选择 | IBM Developer
10. Netflix Conductor: A microservices orchestrator | Medium.com
11. Kubernetes 容器编排的三大支柱 | 51CTO
12. 深入 kubernetes 调度之原理分析 | 腾讯云+社区