云帮平台的设计架构详解

云帮社区版自8月31日开放免费下载以来，已经有不少小伙伴开始体验了我们的云帮产品，但真正了解云帮运行机制以及产品设计思想的朋友并不多，本篇文档从云帮的产品设计思路开始，逐步介绍云帮的技术架构以及各个特性的技术实现，后续会介绍一些应用实战的内容，希望能够帮助大家深刻的理解云帮，并借助云帮为您的工作提供便利。

云帮简介

云帮是一款基于容器技术的应用管理平台，借助它您可以实现：

企业级的Docker管理平台
开发、测试环境的CI/CD平台
生产环境的运维平台

一、设计思想

概述

云帮可以创建符合 12要素的云原生应用。平台使用Docker作为基本的计算单元来封装应用，利用Kubernetes对应用进行编排和容器调度。好雨将Kubernetes 与 Docker 进行了深度整合，并针对企业级服务特性自主研发了应用引擎、运维平台、持续交付引擎、自动化运维、云应用市场等功能模块，底层的分布式存储、SDN、日志收集、实时统计则采用了扩展性极强的插件式设计，增强了平台的灵活性和扩展性。

12要素应用

符合12要素原则（实践方法）构建的应用可以在分布式系统中灵活的伸缩与迁移。

12要素的贡献者参与过数以百计的应用程序的开发和部署，并通过 Heroku 平台见证了数十万应用程序的开发，运作以及扩展的过程。

云帮的设计完全兼容了12要素原则，可以实现云原生应用的高可用、弹性伸缩，灵活迁移等特性。

平台集成环境自动构建功能，不但支持Dockerfile构建应用，还提供了源代码级别的应用构建，您无需了解Docker，也不需要写Dockerfile，平台可以将您的源代码自动构建成应用并运行起来。

应用

云帮平台提到最多的名词就是应用，云帮中可操作的对象也是应用，这里的应用指的是可独立提供服务的单元，请不要与手机应用，APP混淆。

应用可以通过下列三种形式来创建/获取：

Git仓库中的源代码
Git仓库中Dockerfile文件以及相关的源代码
应用市场或云市中通过 “一键部署” 安装

应用可以有不同的类型，不同应用有各自的属性和行为，如：Web应用的属性包含应用名称，默认域名，开放端口，行为包含绑定域名、扩容节点、启动、关闭等。 MySQL应用的属性和行为都是针对MySQL服务所特有的，如备份恢复，数据库管理等等。

构建、发布与运行

构建阶段

构建组件处理来自git push的请求，或者用户触发构建（一键部署）操作。

如果您提交的是源代码，构建组件会进行源代码的构建操作，检查代码语言，利用语言的包管理工具安装相关环境依赖和代码库依赖。源代码构建程序还会将本次源码语言的类型、包依赖关系存入应用属性中。

如果构建模块发现您的代码中包含一个 Dockerfile 文件，会按照Docker标准的镜像构建的方式解析Dockerfile，生成Docker 镜像并推送的内部私有的镜像仓库中。

发布阶段

发布阶段由应用引擎来完成，它负责将本次构建的应用注册为一个新的版本，并将源码、Dockerfile在构建阶段识别出来的属性存储下来。为应用存储版本信息是为了上线后方便回滚，存储构建信息是为了下次构建时缓存状态。

运行阶段

运行阶段主要由应用引擎和 Kubernetes 来完成，首先由应用引擎初始化租户网络（如果租户网络已经存在，该步骤跳过），然后应用引擎调用Kubernetes的控制器服务部署租户应用，应用的属性信息由应用引擎设定。容器创建成功后，会将信息写入到etcd服务中，应用层负载均衡的自动发现机制感应变化后更新负载均衡节点信息。

后端服务

云帮将所有持久化存储服务如：数据库、缓存、存储、消息系统等均看成是应用的附加资源，这些服务与应用是分开的，我们不建议将应用和后端服务放到一个应用中，这样做违背了12要素的设计原则。

应用程序通过环境变量的形式与后端服务进行关联。这样做是为了将应用与后端服务解耦，无论是应用还是后端服务都可以实现独立的灵活伸缩。

二、技术架构

云帮是按照面向服务的架构来设计的。目前大多数集群组件都是通过容器镜像的形式发布和运行的。后续我们会将所有的组件都容器化，通过Kubernetes集群保障组件的高可用。

总览

Kubernetes负责容器的编排和调度，它的所有行为都是由应用引擎发起的。应用引擎将容器相关的操作都进行了封装，云帮通过抽象出了一个应用的概念来屏蔽底层所有与技术（容器、调度、网络……）相关的概念。用户通过对应用进行属性和行为的设置来操作应用，通过应用与应用直接的依赖关系来进行微服务架构的设计。

技术架构

云帮所有的对外服务都配置在负载均衡上，平台使用者、最终用户、开发者都是通过负载均衡转发到对应的应用与服务：
开发者除了可以通过Web控制台管理应用，还可以通过平台API来完成所有Web控制台的操作。详情参见：云帮API手册
运维人员可以在系统层面维护平台服务，也可以通过云帮的管理后台来管理计算资源，维护平台服务。

路由层

用户可以访问到的应用都是配置在路由层服务中，它主要由负载均衡组成，通过路由规则分离不同的应用与访问域名。控制层的服务根据容器的服务状态维护负载均衡中的节点。

控制层

控制层服务是平台最核心的功能模块，其内部包含了多个子模块：

应用管理平台：通常也称之为控制台，是用户操作和管理应用的web端程序。
应用中心：云帮内部的应用市场，包含了常用的应用，当然用户也可以在云市安装更多的应用。
自动构建：基于源代码和Dockerfile的自动构建模块。
应用引擎：云帮核心子模块，负责将各种容器操作命令发送到后端服务，同时也将应用、容器状态保存到后端的etcd服务中。
Git仓库：选装模块，可以使用外部或内部的Git服务

计算层

计算层负责容器的运行、监控以及收集汇总容器中的日志。容器的启动与关闭由控制层发起，容器运行后会将状态注册到路由层。

后端服务

后端服务云帮集群的核心服务，包括Kubernetes、etcd、数据存储、日志处理、监控等。

部署结构

负载均衡

负载均衡组件通常部署在计算节点上，推荐至少使用3个计算节点作为负载均衡的最小集群规模。
计算节点

计算节点是实际跑容器的主机，每一个团队账号（租户）的容器可以跨主机运行，团队账号中可以有多个应用，每个应用由1～n个容器组成，应用的多个容器运行在不同的主机中。
管理节点

云帮集群的管理服务都运行在管理节点的机器中，包括自动构建服务、容器调度、SDN网络管理、应用引擎、日志汇总与实时处理等等……
分布式存储

存放应用持久化数据以及自动化构建所需要的公共文件。

三、核心组件介绍

自动构建组件

云帮支持2种类型的自动构建：
1. 源代码构建
2. Dockerfile构建

两种构建方式分别走2套构建流程，其中Dockerfile的构建流程与Docker官方构建镜像的步骤一致。这里不再赘述，咱们重点介绍基于源代码的自动构建。

源代码构建背后的理论是：代码即环境 ，什么类型的代码从根本上来说已经决定了它的环境，比如说 PHP代码，已经决定它的环境是WebServer＋PHP，而不应该是Python的环境。代码即环境实际上就是在这个基础之上在代码中添加一些环境的标示而已，当源代码提交到平台后，平台的自动构建程序检测环境描述文件，然后根据需求自动构建环境。

应用引擎组件

应用引擎是好雨自主研发的分布式，多数据中心的应用管理引擎。其主要功能不仅衔接各个功能组件，而且还实现了原生高可用、性能分析、业务监控等诸多业界首创功能特性。

逻辑结构

SDN组件

目前我们为云帮设计了2套SDN组件，分别是基于Calico的三层网络组件和基于OVS自己研发的一套二层网络组件——GoodNet。他们所实现的目的是一样的：
1. 为了隔离租户间的网络
2. 保证同租户不同宿主机之间的网络可以互通。

不同之处在于网络组件的应用场景：
1. Calico 适用于私有云
2. Goodnet适用于公有云

Calico 网络结构

GoodNet 网络结构

同一租户下的容器通过统一的租户路由器上链到Provider Router,通过Provider Router做外网路由集中转发，并且租户路由器上是在宿主机上虚拟出一个路由器，同一租户下的容器互通通过租户路由器做gre/vxlan封装和转发。

云帮讨论群

QQ群：477016432(1群)
微信群