首先服务如果容器化的话，目前 k8s 是一个编排容器的工具，是管理应用的全生命周期的一个服务，从创建应用，应用的部署，应用提供服务，扩容缩容应用，应用更新，都非常的方便，而且可以做到故障自愈。非常强大。
这里【奕秋平台】仅用于管理物理部署（如服务器全为统一系统的虚拟机）范围，如果服务容器化的话可以使用 k8s
另外，此项目仅供学习和探索，主要是记录一些想法，非投产项目
可以看到云计算五个基本特征如上，作为一个平台，虽然面向用户群不一样，个人觉得也应该符合如下特征
- 自助服务
- 资源池化
- 计费服务
仅供参考的应用部署运行模式变迁
物理机模式 ------> 虚拟机模式 ------> 云原生模式
+--------------+ +-------+-------+ +-------+-------+
| | | VM | VM | | Docker| Docker|
| +---+ +---+ | | +---+ | +---+ | | +---+ | +---+ |
| |APP| |APP| | | |APP| | |APP| | | |APP| | |APP| |
| +---+ +---+ | | +---+ | +---+ | | +---+ | +---+ |
|+------------+| +-------+-------+ +-------+-------+
|| Physical || +---------------+ +---------------+
|+------------+| | OPENSTACK | | K8s |
+--------------+ +---------------+ +---------------+
云原生概括为 4 个要点：DevOps+ 持续交付 + 微服务 + 容器
采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps 支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
将服务标准化，以达到“You build it，you run it.”的目的
一般情况下，nginx 或者 web server（不包含 MySQL) 自身都是不需要保存数据的，对于 web server, 数据会保存在专门做持久化的节点上。所以这些节点可以随意扩容或者缩容，只要简单的增加或减少副本的数量就可以。
但是很多有状态的程序都需要集群式的部署，意味着节点需要形成群组关系，每个节点需要一个唯一的 ID（例如 Kafka BrokerId, Zookeeper myid) 来作为集群内部每个成员的标识，集群内节点之间进行内部通信时需要用到这些标识。
通过平台解决各服务运维的共性问题并统一服务运维方式
假如一个集群服务有 4 个组件，组件间有依赖关系（组件间通常是有向无环图），每个组件有多个实例
从整体上可以分为三层
- Cluster
- Service 组件
- Unit 组件中的实际实例
关联关系即 service 上下游的依赖关系
一般情况下，对集群中服务的配置文件的变更主要涉及两类
- 服务本身的配置，如 redis 是否开持久化，持久化的方式，maxmemory 的大小等等
- 服务依赖某个下游，如果下游有实例变动，则需要更新配置文件中下游的访问地址
而这的关联关系就是服务对下游的依赖描述
将此块描述放到部署包中，依托平台达到当下游实例变更时，上游配置自动更新，以达到“You build it，you run it.”的目的
这里的上游自动更新会根据关联关系自动增加 / 删除变动的下游实例
ps: 讨论下
(1) 下游的实例变更时，也可以由某个中控节点自动更新上游的配置，
缺点：此种方式集群服务的组件需要有中控模块，下游实例需要向中控节点进行注册等操作，依赖中控模块程度高
优点：当下游服务为有状态服务时，对上游服务的配置进行更新时容易定制
(2) 上游访问下游组件时也可以是个 VIP，如 k8s 中的 Service（定义了外界访问一组 Pod 的方式）
+---------------------+ +---------------------+
| platform1 | | platform2 | 平台功能层 (paas)
+---------------------+ +---------------------+
--------------------------------------------------------------------------------
+------------------------------------------------+
| IAAS |
| +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ |
| +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | （实例）------ 资源平台层 (iaas)
| +--------+ +--------+ +--------+ +--------+ |
| |service1| |service2| |service3| |service*| |
| +--------+ +--------+ +--------+ +--------+ |
|__.__.__.__.__.__.__.__.__.__.__.__.__.__.__.__.|
| +-----------+ +-----------+ +-----------+ |
| | pool.bj01 | | pool.bj02 | | pool.nj0* | | <---+ （资源池）
| +-----------+ +-----------+ +-----------+ | |
| | +--------- 机器管理层 (iaas)
| +-----------------------------------------+ | |
| | Machine | | <---+ （物理机）
| +-----------------------------------------+ |
+------------------------------------------------+
整体分为
- 平台功能层 (paas):
- 资源层 (iaas) : 资源平台对服务平台不进行暴露机器，资源虚拟化服务，管理 Container 容器的资源分配
- 机器层 (iaas) : 需要维护集群和机器的关系，并提供机器初始化、故障检测及监控报警等功能
加强抽象，避免在不同的服务 paas 平台做重复工作，使服务 paas 层面更加专注于对服务的描述和支持。
对 paas 屏蔽机器细节，便于实现【机器管理的变更】、【paas 平台之间的混部】等功能。
更加直接的资源管理流程。
主要管理 池 - 机器 之间的关系，并维护机器在 IaaS 系统中的生命周期（状态轮转）
提供机器初始化标准程序 / 机器维修 / 机器硬件故障检测 / 机器故障通知几项服务。
机器管理层呈现给资源平台层的是个资源池，管理的对象是机器
机器管理层服务
resource_pool : 资源池
resource_machine: 物理机
机器状态机
| resource_pool
|
+---------+ | +--------------------------------------------------+
|m_outside| <--+---| OFFLINE |
+---------+ | +--------------------------------------------------+
| ^ ^
| |(offline) | (offline)
| | | (backup)
+---------+ | | +-----+ (init) +------+ <---------- +-----+
|m_outside| ---------|--------->| NEW |---------------------->|INITED| (online) |READY|
+---------+ | | +-----+ +------+ ----------> +-----+
| | ^ | |
| | | | |
| | |(repair) | (abnormal) | (abnormal)
| | | | |
| | | v v
| +-------------------+ (migrate_unit) +--------------------------+
| | ERROR | <-------------------| ERROR_DETECTED |
| +-------------------+ +--------------------------+
状态说明
NEW : 新机器，刚刚被添加到系统中，此状态代表机器正在按照我们要求的系统模板和初始化策略被重装系统和初始化系统环境
INITED : 此状态代表机器已经初始化完成，随时可以上线部署业务（从 READY 状态可以转为 INITED, 不会在此机器上分配新实例，此机器上可能还有线上实例）
READY : 此状态代表机器已经正常在线上工作（新创建实例只会处于 READY 状态的机器）
ERROR_DETECTED : 此状态代表机器管理系统发现机器有故障，并通知上层平台需要迁移服务
ERROR : 此状态代表上层平台已经确认将服务迁移至其他机器，并进入了维修程序
OFFLINE : 此状态代表机器完成软件卸载，也离开了机器故障检测的范围，不再受机器管理系统的管理
机器初始化策略组管理，主要配置机器安装的系统，内核版本以及初始化策略的信息。
机器管理中发现的单机故障，会统一通知到上层资源平台，进行实例迁移操作，然后进行维修机器
资源平台服务
resource_service: 服务（与特定镜像及套餐进行绑定）
resource_container: 服务下的实例
资源分配，需要描述 container 所需的资源容量, 存储在 resource_service ，同时 resource_service 记录着与 resource_pool 关系
服务平台层需要做的是对服务的全生命周期管理
实例的状态机
// 待完善
服务平台管理的服务
program: 类似于镜像
relation: service 与 service 之间的关系（拓扑），不同的 paas 平台对服务间的拓扑的抽象不一样
service_config: service 的配置（配置管理）
...
PS: 各个服务平台因为镜像的格式不统一，导致的重复性工作也比较多
- 需要有个组件进行部署 yiqiu agent
- yiqiu-agent 用于管理 program,program 是服务标准化的抽象
- 因为是物理部署，所以需满足以下条件：
- 启动 yiqiu-agent 需要为绝对路径启动
- 部署路径使用
服务_port, 允许同一个服务启动多个实例
+--------------------------------------------------------+
| +---------------------------------------+ |
| | service_deploy | |
| +-------+-------------------------------+ |
| | |
| | 1 |
| +-------V-------------------------------+ |
| | +xingqiao_plugin+ +----------------+ | | yiqiu-server
| | |unit_deploy | |command_from_mq | | Control 模块 |
| | |unit_command | | | | |
| | +-------------- + +--/-------------+ | |
| +-------|------------/--------|---------+ |
| | / | |
| | 2 / 3 | 4 |
| | / | |
| +------V----V--+ | |
| | mq | | |
| +--------------+ | |
+-------------------------------|------------------------+
|
|
|
V
+--------------------------------------------------------+
| +---------+ +---------+ +---------+ +---------+ |
| | agent | | agent | | agent | | agent | | yiqiu-agent
| +---------+ +---------+ +---------+ +---------+ |
+--------------------------------------------------------+
如上图，unit_deploy 和 unit_command 皆为 butterfly【星桥】插件
unit_deploy 重点是管理一个实例的部署流程, 实际命令都是 command_from_mq handler 进行执行
unit_deploy
|
+---------------------/yiqiu/command_from_mq install(部署)
|
+---------------------/yiqiu/command_from_mq config-changed(配置变更)
|
+---------------------/yiqiu/command_from_mq start(启动)
|
+---------------------/yiqiu/command_from_mq relation-changed(关联上下游关系)
unit_command 重点是给 agent 发送命令，可对多个实例进行操作
unit_command
|
+---------------------/yiqiu/command_from_mq command
|
+---------------------/yiqiu/command_from_mq command
|
+---------------------...
OpenStack 要部署在几百台物理机器上，假设需要管理的服务是 OpenStack 的计算服务
我们面对的是服务 Paas 平台
资源 Paas 平台管理物理机并形成池
- 服务 Pass 平台上触发创建 service 服务：会在池中创建控制节点 service, 计算节点 service , 创建 service 时需要配比套餐和 Program 包
- 服务 Pass 平台上触发添加实例 : 服务 Paas 平台向资源 Paas 平台发起
- 服务 Pass 平台上的 Program 包中会有服务的上下游描述，添加完的实例会根据描述自动更新配置和上下游（拓扑）
数据模型不应该以服务名来建表，应该以服务模型来进行分层
ps:redis 集群例子，如果按照如下集群，如果按照如下方式进行，如果按照如下方式建表的话，不方便扩展
> redis
> proxy
> shard
> cluster
redis 与 proxy 应该属于同一层即 service 层
you build it，you run it 出处 ------- 亚马逊高效研发的秘密
- 在 GitHub 上
fork到自己的仓库，然后clone到本地，并设置用户信息。
$ git clone https://github.com/meetbill/yiqiu.git
$ cd yiqiu
$ git config user.name "yourname"
$ git config user.email "your email"
- 修改代码后提交，并推送到自己的仓库。
$ #do some change on the content
$ git commit -am "Fix issue #1: change helo to hello"
$ git push
- 在 GitHub 网站上提交 pull request。
- 定期使用项目仓库内容更新自己仓库内容。
$ git remote add upstream https://github.com/meetbill/yiqiu.git
$ git fetch upstream
$ git checkout master
$ git rebase upstream/master
$ git push -f origin master