这是一个创建于 2800 天前的主题，其中的信息可能已经有所发展或是发生改变。
QingCloud 大数据平台负责人周小四，在 GIAC 全球互联网架构大会上的演讲，他认为是公有云、私有云或混合云，还是 IaaS 、 PaaS 或 SaaS ，越来越多的企业和个人已经在使用云上提供的各类丰富服务，云计算的常态化在全世界已成为不可逆转的趋势，青云 QingCloud AppCenter 2.0 志在建立一个学习使用成本低的高度标准化平台。
青云 QingCloud 大数据平台负责人周小四
以下为分享正文：
云计算常态化意味着云应用的常态化
相信大家都听过这句话，叫做“云计算常态化”。
在三年前，云计算在中国还只是一个概念，近年来，这个火热的概念转为实际，我们也帮助越来越多如银行、保险、证券这样的大型企业客户实现云计算项目的真实落地。如此来看，云计算已经常态化了。
云计算常态化，就意味着云应用要常态化。
在我们跟企业客户交流时发现，客户希望我们能 把中间件都搞定，让他们不用操心安装和运维问题，从而能把更多的精力投入应用。如果我们像过去一样只提供云主机和网络，已经远远不能满足用户的需求了。而青云的愿景是云计算要像水电一样服务于大众，所以我们要去解决水电运输问题，让用户只需要关心电器。
云应用常态化，意味着云化应用是一个极低的门槛。云化应用门槛如果太高，那么成为常态化就不是一件容易的事情。
降低门槛，也意味着要有标准化的平台，企业的应用云化过程才能变得简单。
关于架构的演变，我们在过去两年切身体会到很多内容，可以分为以下三个阶段：
初级阶段，每个应用在开发的时候完全是孤立的，每个研发组独立开发项目。目前，很多业内几乎都是处在这个阶段的。
第二阶段，底层的应用实现框架化，并将相同的模块抽象出来共用。
但每个应用还是单独开发的，主要原因是应用之间千差万别，体系架构各不相同。比如说应用配置文件的定义都不一样，所以每个应用都需要单独开发。
第三阶段，也是青云近一年来一直在探索的，一个端到端的标准云化平台—— AppCenter 2.0 。
在这个标准云化平台上，企业开发云应用的时候，不用关心需要什么样的技术，同时可以简单、快速地云化应用。它的特征是高度抽象，高度标准化。简单地说，企业在云化应用的时候，可按照标准批量生产各类云应用。以后云技术就不再是企业核心了，而应用本身才是核心。
这会使得最终竞争的是应用本身，而不是云计算平台。这里的含义是，如果青云的工程师和青云的合作伙伴，在 AppCenter 2.0 上各自开发一个云应用，青云工程师作为云平台的提供者来说没有任何独特优势，因为用的是同一个平台。比如，双方都要做一个 Hadoop ，比的是谁有更深厚的经验，能够把这个应用做得更好，调优调得更好，彼此 PK 的是应用本身。
标准化平台设计的思考
标准化平台设计的难点
标准化平台设计难点在于：
一、应用种类繁多。
有的集群是没有角色的，有的是有一主一从的，也有一主多从的，或者多主多从的，甚至分片的多主多从。
此外，每个应用的集群管理方式也是多样化的。每个应用的生命周期如何管理，比如启动集群、停止集群，如何运行这些命令，都不一样，这非常复杂，也给标准化平台带来一些难度。
二、应用配置变更。
有些应用的配置与某类角色有关，同时如何实现应用配置自动变更，如何存储这些信息，这都是难点。
三、服务依赖感知。
AppCenter 2.0 不仅仅是解决集群自动化部署、自动化运维这个层面，还会成为一个生态，每个组件之间能够互相感知。比如说企业应用有一个 Kafka ，当 ZooKeeper 节点发生改变时， Kafka 能否自动感知到该变化。
一般的做法是把这些信息手动改一下，并重启 Kafka 服务。标准化平台能否自动化这个过程，即在 ZooKeeper 加节点时不需要手动操作， Kafka 可自动更新配置、自动重启，服务照样运行。使服务之间互相感知，也是一个难点。
四、集群弹性伸缩。
应用既然云化，就要满足云弹性伸缩的特征。当把没有弹性伸缩能力的传统软件搬到云上时， AppCenter 2.0 需要解决这个问题。这样一来，第三方合作伙伴用 AppCenter 2.0 平台云化应用的时候，不用写代码，只需按照 AppCenter 2.0 的规范操作即可拥有云的特性，同时实现对整个集群生命周期的管理。
标准化平台设计现有方案
业内标准化平台设计现有的解决方案，基本上是基于 Mesos 的 DC/OS 、 DockerSwarm 、 Rancher 、 K8S 而设计的，它们离生产环境还比较远。之前参加过一个 Mesos 的会议突然醒悟到，他们的重点是放在 IaaS 层的，强调的是资源层面的调度，对应用层面的调度还不深入。
作为应用调度层，还是要和底层分开为好。
应用管理平台只负责调度和管理集群生命周期，至于 IaaS 层用的是 KVM 或者 Docker 都没关系，底层的资源调度由 IaaS 层解决就好。应用层的重点应该是深刻了解各类应用、类型，并做出相应的方案。
青云 QingCloud AppCenter 2.0 探索
QingCloud AppCenter 2.0 目标
目标一，人人都可以开发云产品。
前提条件是你要懂一些基础的东西，比如写脚本。云计算目前还是有点高门槛，青云的目标就是尽可能降低这个门槛，让人人都能开发云应用产品。
目标二，缩短开发周期。
以前开发一个云应用基本上是几个月，最快是两个月，现在可以把它缩短到几天，快的话几个小时就可以搞定。
目标三，学习成本要低。
制定的规范要通俗易懂，不能让人觉得奇怪，因为奇怪的东西往往生命周期不会很长的，所以要让它的学习成本很低。
目标四，合作伙伴拥有完整的云平台。
AppCenter 不仅包括应用调度引擎，还给青云合作伙伴提供一整套云管理平台。青云合作伙伴基于 AppCenter 进行运营、运维、开发、销售等，也就是说除了自己的应用，企业不需要关心其它的东西。
AppCenter 2.0 核心：集群管理引擎
集群管理引擎是 AppCenter 2.0 最核心的一部分。
先从底层讲起，底层调用青云后台的 API —— CreateCluster ，输入一个 JSON 串。下面通过举例的方式来介绍 JSON 串。
示例一， ZooKeeper 集群创建。
第一步，定义集群。
输入该集群的名字和描述，加入到哪个二层网络，以及节点信息。比如说要创建的节点数，每个节点的 CPU 数、内存大小，指定镜像 ID 和类型（ KVM/Docker/LXC ），并说明在哪个区创建，要挂多少数据盘，盘的文件系统是什么，挂载点在哪里，大小是多少。甚至可以指定它的类型，比如容量盘、性能盘、高性能盘等。
第二步，输入 Service 信息。
即管理该 ZooKeeper 服务的命令。比如如何启动、关停 ZooKeeper 服务。
第三步，输入 advanced_actions ，比如 scale_horizontal 。
部分传统软件没有云计算弹性伸缩的特性，那它如何做到伸缩呢？一般是新起一个集群。比如原有 10 个节点的集群，现在需要加到 20 个节点的做法是，先创建一个 20 个节点的集群，把这 10 个节点的集群的数据导过来，然后把旧集群删除。 AWSRedshift 就是这样的做法。传统软件不像 Hadoop 那样在现有集群上直接加一个节点就可以伸缩。所以在这里需要先声明 advancedaction ，才可支持应用的弹性伸缩。
通过以上定义把这个应用部署到青云 AppCenter 2.0 上，那么 ZooKeeper 的云上特性就有了，包括启动、关闭、暂停、恢复、加减节点，纵向伸缩，所有这些都是这个文件内容申明的。企业用户只需填好这些信息，不到一个小时即可完成 ZooKeeper 的创建。
示例二， HBase 的创建。
示例一中， ZooKeeper 没有角色，是一个很简单的例子，通常情况下应用比这个复杂得多，比如 HBase ，它是多角色的，有外部关联，有应用参数等。创建 HBase 要点如下：
文件定义变成 node list ，每类 node 要定义角色。这个角色名字可由开发者自行定义，但需要清楚每个角色以及它们的唯一性，否则容易产生混乱。
服务依赖。因 HBase 依赖于 ZooKeeper ，这种情况下如果有人已经创建了 ZooKeeper 服务，就不需要再开发 ZooKeeper 服务了，只需开发一个 HBase 服务，指定它依赖于哪个 ZooKeeper 。输入 ZooKeeper 以 cl- 开头的 ID ，即可自动连接 ZooKeeper 与 HBase 。
节点创建的要领跟 ZooKeeper 一样。
生成公钥。运维 Hadoop 、 Spark 、 HBase 时，需要把主节点的公钥复制到从节点上，指定 passphraseless ，即可生成主节点的公钥。
Service 里设置 order ，即节点启动顺序。在云服务中，各类节点的启动顺序是不一样的。比如主从架构的应用是先启动主节点再启动从节点。如果先启动从节点的话，它可能因为找不到主节点而挂掉。所以需要指定不同节点类型的服务启动顺序。更复杂的还有 Redis Cluster ，它的执行命令只在一个节点上执行，而它的主节点至少有 3 个，从节点可以是零个到多个，所以需要制定规范满足这种特殊需求。
参数呈现。 HBase 是一个带参数的应用，这些参数需要呈现给最终用户并且可以修改，比如 HDFS 副本有几个。参数也要分角色，不同角色可能暴露不同参数给用户。
endpoint 。服务之间感知需要知道这些信息，有些软件的端口号不是标准的，这个时候需要暴露这些信息给可能会用到这个的 App 的开发者。
还有一种情况，有些端号是可变的。所以需要有一个类似于引用的功能，指向那个参数。当参数发生改变时，服务的 endpoint 端口也会改。要开发这一个标准化的平台，不仅仅是为了满足自动化的部署，还要让各个应用之间发生关联，形成一个生态。
AppCenter 2.0 集群管理引擎架构图
这是 AppCenter2.0 集群管理引擎的架构图。
首先是调度系统，统一管理着整个系统，包括元数据管理系统 metad ，它的后端是定制化的 etcd 。
confd 是配置管理系统，也是定制化的，它会从元数据管理系统获取集群信息，从而自动更新节点配置。
调度系统把集群的信息都注册到元数据管理系统里，使不同集群可以关联。比如有集群用到 ZooKeeper ，它们就可以通过元数据管理系统 metad 发生关联，集群可以从这里得到关联应用的信息，从而连接 ZooKeeper 。
那么这个元数据结构是什么样的呢？它是一个树状结构，根节点是 self 。每个节点可发出指令到元数据中心取它所在集群相关的所有信息，这个信息包括以下：
集群所有节点的信息，每个节点的详细信息包括： IP 地址、 MAC 、 server ID 、 CPU 、内存以及主机所在物理机位置。
主机本身信息，详细信息同上。
Cluster 信息，包括集群所在网络。
env 参数，这些参数可以用来更新应用配置。
伸缩信息。在加减节点的时候，每个集群会做一些动作。比如数据的迁移，删节点的时候不能盲目地把节点全删掉，一定是在数据迁走之后再删掉才最安全。增减节点的时候，你可以获取相应节点的 IP 地址、 MAC 等全部信息。我们还提供了 scale in/scale out 的命令接口。
Links 信息。当 Kafka 要用某个 ZooKeeper ，通过 ZooKeeper 的 ID 就可以获取刚才说到的 ZooKeeper 这个集群的所有信息，而后可将 Kafka 里的应用配置跟 ZooKeeper 相关的信息全部更新，这就发生了集群关联。
最后是 endpoint ，当应用之间发生关联的时候，有这个信息就可以自动更新服务的关联。
应用如何实现自动更新？
那么应用如何实现自动更新？和 Rancher 、 DCOS 的思路一致，需要写两类文件，其中一个是以 toml 结尾的配置文件，另一个是以 tmpl 结尾的配置文件，它们是 Gotemplate 的模板语言，这个学习曲线是最高的，但它并不难。因为元数据结构是一个 tree 结构，需要用到的无非就是那几类：得到某个 Key 的 value ，或者得到某个 Key 的 name ，或者要遍历 node 下面所有的 Key ，没有其它更多的。我们的文档基本上提供了所有可能用到的语法案例。
ZooKeeper 有两个配置文件，一个叫 zoo.cfg ，一个叫 myid 。
先看 zoo.cfg.toml 配置文件，该配置文件下有个 src ，即 ZooKeeper 应用的配置模板。 src 会更新 ZooKeeper 配置的内容，即 dest 指定的文件。更新过程通过 watch 的 keys 变更触发，更新完之后， reload_cmd 定义的命令根据你的业务需求来选择触发与否，比如当 ZooKeeper 配置文件发生改变时， ZooKeeperservice 需要重启。
再来看 zoo.cfg.template ， range 这个模板语法可以获取 hosts 集群信息。先是 lsdir ，获取主机集群目录下所有的 instanceid ，然后获取每个主机的 serverid 和 IP 信息，把变量替换之后就变成了类似于 server.1=192.168.100.2 ： 28888 ： 38888 这样的配置。 myid 的更新就更简单了，直接拿到本机的 serverID 更新就行了。
这样一来，包含两个配置文件的 image 就做好了，再结合前面的创建集群输入 json 信息，就可以实现应用的云化了。
应用管理仅需做好三件事情
前面讲的是一个具体的实例 ZooKeeperinstance 以及 json 里面指定了几颗 CPU 、几个节点。对于应用中心的一名应用开发者，要提供 ZooKeeper 服务的话，肯定不能指定几个 CPU ，而是要让最终用户去选择，需要几个节点和几颗 CPU 等信息。
要开发这样的应用，就要加两个文件， config.json 和 cluster.json.mustache 。这两个文件加起来，经过渲染就变成了一个应用的实例信息即前面讲的创建集群输入参数信息 cluster.json 。
青云调度系统根据 config.json 这个文件展现给用户进行选择，比如有一个 key 叫 CPU ，它的 default 值是一颗 CPU ，前端根据这个信息配置文件，展现给最终用户以选择几个 CPU 。
cluster.json.mustache 和 cluster.json 很像， mustache 里的变量比如 name 是最终用户根据前面的 config.json 在 UI 上填的内容，如 cluster.name 、 CPU 数量、 nodecount 、 volumesize 。也就是说{{}} 里面是个变量，来自于 configjson 里最终用户填的具体值，把它渲染完以后就变成了一个集群的实例信息，即前面讲的 cluster.json 。此时系统就会自动调用 CreateCluster ，创建这个应用实例。
所以，开发者要开发应用给最终用户使用，他需要写这两个文件，一个是 config.json ，一个是 cluster.json.mustache 。把这两个文件写好之后，打包上传到 AppCenter 平台上就 OK 了。
除了以上两个文件，还要制作相应的镜像。
基本上就这三件事情，写 config.json ，写 cluster.json.mustache 以及制作镜像。
AppCenter 2.0 集群管理引擎的运用：应用编排
相信大家看到这里肯定有一个感觉， AppCenter 2.0 集群管理引擎可以有很多使用方法。
使用方法一，开发者可以利用这个引擎写很复杂的应用，甚至不用 link ， ZooKeeper 和 Kafka 也不用分开。比如说一个日志系统，可以把 ZooKeeper 、 Kafka 、 Storm 、 Hadoop 写进同一个 App ，赋予不同的角色就行了，按照前面的一套方法就可以做这个事情。
还有一种使用方法就是应用嵌套。当开发者要做一个系统，发现已经有人做了某些需要用到的应用，开发者就不需要重复做这个事情，只需要直接 link ，就可以把小的应用组成一个大的应用。比如日志系统，有人做了 ZooKeeper 、 Kafka 、 Storm 、 Hadoop ，你可以把这些应用组成大的日志系统应用提供给最终用户使用，在这些小应用之上你可以额外收费，这些小应用的提供者同时也能收取他应得的报酬，这些是通过青云收费系统自动完成的。
这是应用编排的示意图，第三方合作伙伴和青云的 App 都会展现在这里。最终用户和开发者都可以对这些 App 进行拖拽，可以把它分层，底层是基础层，中间是 middleware 层，再上层是应用层，每一层都是 App ，把它们全部关联起来然后封装成一个大的 App 。
举例来说，日志系统中的 Kafka 、 ZooKeeper 、 Hadoop 、 Storm 全拖拽进来之后，再拖拽主机进来。主机对青云来说是一个系统 App ，在这个主机里可以部署程序，程序可以从 Kafka 取数据、消费数据，结合 Storm 处理这些数据， Storm 处理结果输出到 Redis 、 MySql 、 Hadoop 等，把这个模板做好之后就可以发布，使用过程中还可以通过对象存储不停地迭代程序，因为在主机程序里，可以通过 environment 的方式把 Link 传进对象存储，每次把代码上传到对象存储里面，点一下部署，主机会自动把代码拉进来，自动更新。
结语
以上是我们在做 QingCloud AppCenter 2.0 的思考。我们已经看到，无论是公有云、私有云或混合云，还是 IaaS 、 PaaS 或 SaaS ，越来越多的企业和个人已经在使用云上提供的各类丰富服务，云计算的常态化在全世界已成为不可逆转的趋势。
青云 QingCloud AppCenter 2.0 志在建立一个学习使用成本低的高度标准化平台，使得原有不论多复杂的产品和应用的架构都可以在“以天计算”的时间成本内完成产品和应用的云化，变成一个拥有所有云计算内置能力的新产品和应用。
除此之外，平台上所有的产品和应用都可以以服务的形式和其它产品和应用一起灵活简洁的集成编排，形成更具价值的大服务。可以想像，这种以生态系统为形式的融合创造，将会为最终用户提供无限广阔的价值。
AppCenter 2.0 会贯通资源和应用，将是一个非常强大的平台。今年 7 月份的 QingCloud Insight 大会我们会推出更多激动人心的产品。欢迎大家到时来参加。
青云 QingCloud 大数据平台负责人周小四
以下为分享正文：
云计算常态化意味着云应用的常态化
相信大家都听过这句话，叫做“云计算常态化”。
在三年前，云计算在中国还只是一个概念，近年来，这个火热的概念转为实际，我们也帮助越来越多如银行、保险、证券这样的大型企业客户实现云计算项目的真实落地。如此来看，云计算已经常态化了。
云计算常态化，就意味着云应用要常态化。
在我们跟企业客户交流时发现，客户希望我们能 把中间件都搞定，让他们不用操心安装和运维问题，从而能把更多的精力投入应用。如果我们像过去一样只提供云主机和网络，已经远远不能满足用户的需求了。而青云的愿景是云计算要像水电一样服务于大众，所以我们要去解决水电运输问题，让用户只需要关心电器。
云应用常态化，意味着云化应用是一个极低的门槛。云化应用门槛如果太高，那么成为常态化就不是一件容易的事情。
降低门槛，也意味着要有标准化的平台，企业的应用云化过程才能变得简单。
关于架构的演变，我们在过去两年切身体会到很多内容，可以分为以下三个阶段：
初级阶段，每个应用在开发的时候完全是孤立的，每个研发组独立开发项目。目前，很多业内几乎都是处在这个阶段的。
第二阶段，底层的应用实现框架化，并将相同的模块抽象出来共用。
但每个应用还是单独开发的，主要原因是应用之间千差万别，体系架构各不相同。比如说应用配置文件的定义都不一样，所以每个应用都需要单独开发。
第三阶段，也是青云近一年来一直在探索的，一个端到端的标准云化平台—— AppCenter 2.0 。
在这个标准云化平台上，企业开发云应用的时候，不用关心需要什么样的技术，同时可以简单、快速地云化应用。它的特征是高度抽象，高度标准化。简单地说，企业在云化应用的时候，可按照标准批量生产各类云应用。以后云技术就不再是企业核心了，而应用本身才是核心。
这会使得最终竞争的是应用本身，而不是云计算平台。这里的含义是，如果青云的工程师和青云的合作伙伴，在 AppCenter 2.0 上各自开发一个云应用，青云工程师作为云平台的提供者来说没有任何独特优势，因为用的是同一个平台。比如，双方都要做一个 Hadoop ，比的是谁有更深厚的经验，能够把这个应用做得更好，调优调得更好，彼此 PK 的是应用本身。
标准化平台设计的思考
标准化平台设计的难点
标准化平台设计难点在于：
一、应用种类繁多。
有的集群是没有角色的，有的是有一主一从的，也有一主多从的，或者多主多从的，甚至分片的多主多从。
此外，每个应用的集群管理方式也是多样化的。每个应用的生命周期如何管理，比如启动集群、停止集群，如何运行这些命令，都不一样，这非常复杂，也给标准化平台带来一些难度。
二、应用配置变更。
有些应用的配置与某类角色有关，同时如何实现应用配置自动变更，如何存储这些信息，这都是难点。
三、服务依赖感知。
AppCenter 2.0 不仅仅是解决集群自动化部署、自动化运维这个层面，还会成为一个生态，每个组件之间能够互相感知。比如说企业应用有一个 Kafka ，当 ZooKeeper 节点发生改变时， Kafka 能否自动感知到该变化。
一般的做法是把这些信息手动改一下，并重启 Kafka 服务。标准化平台能否自动化这个过程，即在 ZooKeeper 加节点时不需要手动操作， Kafka 可自动更新配置、自动重启，服务照样运行。使服务之间互相感知，也是一个难点。
四、集群弹性伸缩。
应用既然云化，就要满足云弹性伸缩的特征。当把没有弹性伸缩能力的传统软件搬到云上时， AppCenter 2.0 需要解决这个问题。这样一来，第三方合作伙伴用 AppCenter 2.0 平台云化应用的时候，不用写代码，只需按照 AppCenter 2.0 的规范操作即可拥有云的特性，同时实现对整个集群生命周期的管理。
标准化平台设计现有方案
业内标准化平台设计现有的解决方案，基本上是基于 Mesos 的 DC/OS 、 DockerSwarm 、 Rancher 、 K8S 而设计的，它们离生产环境还比较远。之前参加过一个 Mesos 的会议突然醒悟到，他们的重点是放在 IaaS 层的，强调的是资源层面的调度，对应用层面的调度还不深入。
作为应用调度层，还是要和底层分开为好。
应用管理平台只负责调度和管理集群生命周期，至于 IaaS 层用的是 KVM 或者 Docker 都没关系，底层的资源调度由 IaaS 层解决就好。应用层的重点应该是深刻了解各类应用、类型，并做出相应的方案。
青云 QingCloud AppCenter 2.0 探索
QingCloud AppCenter 2.0 目标
目标一，人人都可以开发云产品。
前提条件是你要懂一些基础的东西，比如写脚本。云计算目前还是有点高门槛，青云的目标就是尽可能降低这个门槛，让人人都能开发云应用产品。
目标二，缩短开发周期。
以前开发一个云应用基本上是几个月，最快是两个月，现在可以把它缩短到几天，快的话几个小时就可以搞定。
目标三，学习成本要低。
制定的规范要通俗易懂，不能让人觉得奇怪，因为奇怪的东西往往生命周期不会很长的，所以要让它的学习成本很低。
目标四，合作伙伴拥有完整的云平台。
AppCenter 不仅包括应用调度引擎，还给青云合作伙伴提供一整套云管理平台。青云合作伙伴基于 AppCenter 进行运营、运维、开发、销售等，也就是说除了自己的应用，企业不需要关心其它的东西。
AppCenter 2.0 核心：集群管理引擎
集群管理引擎是 AppCenter 2.0 最核心的一部分。
先从底层讲起，底层调用青云后台的 API —— CreateCluster ，输入一个 JSON 串。下面通过举例的方式来介绍 JSON 串。
示例一， ZooKeeper 集群创建。
第一步，定义集群。
输入该集群的名字和描述，加入到哪个二层网络，以及节点信息。比如说要创建的节点数，每个节点的 CPU 数、内存大小，指定镜像 ID 和类型（ KVM/Docker/LXC ），并说明在哪个区创建，要挂多少数据盘，盘的文件系统是什么，挂载点在哪里，大小是多少。甚至可以指定它的类型，比如容量盘、性能盘、高性能盘等。
第二步，输入 Service 信息。
即管理该 ZooKeeper 服务的命令。比如如何启动、关停 ZooKeeper 服务。
第三步，输入 advanced_actions ，比如 scale_horizontal 。
部分传统软件没有云计算弹性伸缩的特性，那它如何做到伸缩呢？一般是新起一个集群。比如原有 10 个节点的集群，现在需要加到 20 个节点的做法是，先创建一个 20 个节点的集群，把这 10 个节点的集群的数据导过来，然后把旧集群删除。 AWSRedshift 就是这样的做法。传统软件不像 Hadoop 那样在现有集群上直接加一个节点就可以伸缩。所以在这里需要先声明 advancedaction ，才可支持应用的弹性伸缩。
通过以上定义把这个应用部署到青云 AppCenter 2.0 上，那么 ZooKeeper 的云上特性就有了，包括启动、关闭、暂停、恢复、加减节点，纵向伸缩，所有这些都是这个文件内容申明的。企业用户只需填好这些信息，不到一个小时即可完成 ZooKeeper 的创建。
示例二， HBase 的创建。
示例一中， ZooKeeper 没有角色，是一个很简单的例子，通常情况下应用比这个复杂得多，比如 HBase ，它是多角色的，有外部关联，有应用参数等。创建 HBase 要点如下：
文件定义变成 node list ，每类 node 要定义角色。这个角色名字可由开发者自行定义，但需要清楚每个角色以及它们的唯一性，否则容易产生混乱。
服务依赖。因 HBase 依赖于 ZooKeeper ，这种情况下如果有人已经创建了 ZooKeeper 服务，就不需要再开发 ZooKeeper 服务了，只需开发一个 HBase 服务，指定它依赖于哪个 ZooKeeper 。输入 ZooKeeper 以 cl- 开头的 ID ，即可自动连接 ZooKeeper 与 HBase 。
节点创建的要领跟 ZooKeeper 一样。
生成公钥。运维 Hadoop 、 Spark 、 HBase 时，需要把主节点的公钥复制到从节点上，指定 passphraseless ，即可生成主节点的公钥。
Service 里设置 order ，即节点启动顺序。在云服务中，各类节点的启动顺序是不一样的。比如主从架构的应用是先启动主节点再启动从节点。如果先启动从节点的话，它可能因为找不到主节点而挂掉。所以需要指定不同节点类型的服务启动顺序。更复杂的还有 Redis Cluster ，它的执行命令只在一个节点上执行，而它的主节点至少有 3 个，从节点可以是零个到多个，所以需要制定规范满足这种特殊需求。
参数呈现。 HBase 是一个带参数的应用，这些参数需要呈现给最终用户并且可以修改，比如 HDFS 副本有几个。参数也要分角色，不同角色可能暴露不同参数给用户。
endpoint 。服务之间感知需要知道这些信息，有些软件的端口号不是标准的，这个时候需要暴露这些信息给可能会用到这个的 App 的开发者。
还有一种情况，有些端号是可变的。所以需要有一个类似于引用的功能，指向那个参数。当参数发生改变时，服务的 endpoint 端口也会改。要开发这一个标准化的平台，不仅仅是为了满足自动化的部署，还要让各个应用之间发生关联，形成一个生态。
AppCenter 2.0 集群管理引擎架构图
这是 AppCenter2.0 集群管理引擎的架构图。
首先是调度系统，统一管理着整个系统，包括元数据管理系统 metad ，它的后端是定制化的 etcd 。
confd 是配置管理系统，也是定制化的，它会从元数据管理系统获取集群信息，从而自动更新节点配置。
调度系统把集群的信息都注册到元数据管理系统里，使不同集群可以关联。比如有集群用到 ZooKeeper ，它们就可以通过元数据管理系统 metad 发生关联，集群可以从这里得到关联应用的信息，从而连接 ZooKeeper 。
那么这个元数据结构是什么样的呢？它是一个树状结构，根节点是 self 。每个节点可发出指令到元数据中心取它所在集群相关的所有信息，这个信息包括以下：
集群所有节点的信息，每个节点的详细信息包括： IP 地址、 MAC 、 server ID 、 CPU 、内存以及主机所在物理机位置。
主机本身信息，详细信息同上。
Cluster 信息，包括集群所在网络。
env 参数，这些参数可以用来更新应用配置。
伸缩信息。在加减节点的时候，每个集群会做一些动作。比如数据的迁移，删节点的时候不能盲目地把节点全删掉，一定是在数据迁走之后再删掉才最安全。增减节点的时候，你可以获取相应节点的 IP 地址、 MAC 等全部信息。我们还提供了 scale in/scale out 的命令接口。
Links 信息。当 Kafka 要用某个 ZooKeeper ，通过 ZooKeeper 的 ID 就可以获取刚才说到的 ZooKeeper 这个集群的所有信息，而后可将 Kafka 里的应用配置跟 ZooKeeper 相关的信息全部更新，这就发生了集群关联。
最后是 endpoint ，当应用之间发生关联的时候，有这个信息就可以自动更新服务的关联。
应用如何实现自动更新？
那么应用如何实现自动更新？和 Rancher 、 DCOS 的思路一致，需要写两类文件，其中一个是以 toml 结尾的配置文件，另一个是以 tmpl 结尾的配置文件，它们是 Gotemplate 的模板语言，这个学习曲线是最高的，但它并不难。因为元数据结构是一个 tree 结构，需要用到的无非就是那几类：得到某个 Key 的 value ，或者得到某个 Key 的 name ，或者要遍历 node 下面所有的 Key ，没有其它更多的。我们的文档基本上提供了所有可能用到的语法案例。
ZooKeeper 有两个配置文件，一个叫 zoo.cfg ，一个叫 myid 。
先看 zoo.cfg.toml 配置文件，该配置文件下有个 src ，即 ZooKeeper 应用的配置模板。 src 会更新 ZooKeeper 配置的内容，即 dest 指定的文件。更新过程通过 watch 的 keys 变更触发，更新完之后， reload_cmd 定义的命令根据你的业务需求来选择触发与否，比如当 ZooKeeper 配置文件发生改变时， ZooKeeperservice 需要重启。
再来看 zoo.cfg.template ， range 这个模板语法可以获取 hosts 集群信息。先是 lsdir ，获取主机集群目录下所有的 instanceid ，然后获取每个主机的 serverid 和 IP 信息，把变量替换之后就变成了类似于 server.1=192.168.100.2 ： 28888 ： 38888 这样的配置。 myid 的更新就更简单了，直接拿到本机的 serverID 更新就行了。
这样一来，包含两个配置文件的 image 就做好了，再结合前面的创建集群输入 json 信息，就可以实现应用的云化了。
应用管理仅需做好三件事情
前面讲的是一个具体的实例 ZooKeeperinstance 以及 json 里面指定了几颗 CPU 、几个节点。对于应用中心的一名应用开发者，要提供 ZooKeeper 服务的话，肯定不能指定几个 CPU ，而是要让最终用户去选择，需要几个节点和几颗 CPU 等信息。
要开发这样的应用，就要加两个文件， config.json 和 cluster.json.mustache 。这两个文件加起来，经过渲染就变成了一个应用的实例信息即前面讲的创建集群输入参数信息 cluster.json 。
青云调度系统根据 config.json 这个文件展现给用户进行选择，比如有一个 key 叫 CPU ，它的 default 值是一颗 CPU ，前端根据这个信息配置文件，展现给最终用户以选择几个 CPU 。
cluster.json.mustache 和 cluster.json 很像， mustache 里的变量比如 name 是最终用户根据前面的 config.json 在 UI 上填的内容，如 cluster.name 、 CPU 数量、 nodecount 、 volumesize 。也就是说{{}} 里面是个变量，来自于 configjson 里最终用户填的具体值，把它渲染完以后就变成了一个集群的实例信息，即前面讲的 cluster.json 。此时系统就会自动调用 CreateCluster ，创建这个应用实例。
所以，开发者要开发应用给最终用户使用，他需要写这两个文件，一个是 config.json ，一个是 cluster.json.mustache 。把这两个文件写好之后，打包上传到 AppCenter 平台上就 OK 了。
除了以上两个文件，还要制作相应的镜像。
基本上就这三件事情，写 config.json ，写 cluster.json.mustache 以及制作镜像。
AppCenter 2.0 集群管理引擎的运用：应用编排
相信大家看到这里肯定有一个感觉， AppCenter 2.0 集群管理引擎可以有很多使用方法。
使用方法一，开发者可以利用这个引擎写很复杂的应用，甚至不用 link ， ZooKeeper 和 Kafka 也不用分开。比如说一个日志系统，可以把 ZooKeeper 、 Kafka 、 Storm 、 Hadoop 写进同一个 App ，赋予不同的角色就行了，按照前面的一套方法就可以做这个事情。
还有一种使用方法就是应用嵌套。当开发者要做一个系统，发现已经有人做了某些需要用到的应用，开发者就不需要重复做这个事情，只需要直接 link ，就可以把小的应用组成一个大的应用。比如日志系统，有人做了 ZooKeeper 、 Kafka 、 Storm 、 Hadoop ，你可以把这些应用组成大的日志系统应用提供给最终用户使用，在这些小应用之上你可以额外收费，这些小应用的提供者同时也能收取他应得的报酬，这些是通过青云收费系统自动完成的。
这是应用编排的示意图，第三方合作伙伴和青云的 App 都会展现在这里。最终用户和开发者都可以对这些 App 进行拖拽，可以把它分层，底层是基础层，中间是 middleware 层，再上层是应用层，每一层都是 App ，把它们全部关联起来然后封装成一个大的 App 。
举例来说，日志系统中的 Kafka 、 ZooKeeper 、 Hadoop 、 Storm 全拖拽进来之后，再拖拽主机进来。主机对青云来说是一个系统 App ，在这个主机里可以部署程序，程序可以从 Kafka 取数据、消费数据，结合 Storm 处理这些数据， Storm 处理结果输出到 Redis 、 MySql 、 Hadoop 等，把这个模板做好之后就可以发布，使用过程中还可以通过对象存储不停地迭代程序，因为在主机程序里，可以通过 environment 的方式把 Link 传进对象存储，每次把代码上传到对象存储里面，点一下部署，主机会自动把代码拉进来，自动更新。
结语
以上是我们在做 QingCloud AppCenter 2.0 的思考。我们已经看到，无论是公有云、私有云或混合云，还是 IaaS 、 PaaS 或 SaaS ，越来越多的企业和个人已经在使用云上提供的各类丰富服务，云计算的常态化在全世界已成为不可逆转的趋势。
青云 QingCloud AppCenter 2.0 志在建立一个学习使用成本低的高度标准化平台，使得原有不论多复杂的产品和应用的架构都可以在“以天计算”的时间成本内完成产品和应用的云化，变成一个拥有所有云计算内置能力的新产品和应用。
除此之外，平台上所有的产品和应用都可以以服务的形式和其它产品和应用一起灵活简洁的集成编排，形成更具价值的大服务。可以想像，这种以生态系统为形式的融合创造，将会为最终用户提供无限广阔的价值。
AppCenter 2.0 会贯通资源和应用，将是一个非常强大的平台。今年 7 月份的 QingCloud Insight 大会我们会推出更多激动人心的产品。欢迎大家到时来参加。
 |
1
lyhiving 2017-03-31 07:42:20 +08:00 via Android
qingcloud 那么贵居然还活着
|
Select Language