设计中立公有云云管平台

第一本文目标

 

我本来没兴趣写云管平台的设计思路的，我想你也没兴趣读，觉得这个问题没什么难度、没什么意义，网上一搜也有很多成型产品。但架不住客户的要求真动笔去写之后，我发现设计云管平台像素描画苹果、小饭馆的鸡蛋炒饼一样，看似简单的需求，却考察很深的基本功。

 

此文的第一目标不是要上云管平台的客户，而是要被管理的云平台的售前、产品和研发，本文是站在客户角度去看云端资源到底有何用途的一个梳理列表，各云厂商要坚持自己的产品战略，但引导客户需求不等于忽略客户需求。

 

此文的直接目标就是采购大量公有云资源的厂商。本文是为说清楚云平台哪些功能是最重要的，哪些功能是可有可无的。无论是自己研发云管平台还是买云管软件，这个云管平台必须符合哪些特性、支持哪些功能。

 

第二云管平台概述

 

说完了本文的目标读者，我们再看核心问题，为什么要做一个云管平台。

 

当客户的非CDN云资源采购金额过500万以后，如果其子项目之间没有内网互通的需求，甚至刻意要做成广域网容灾互备时，这时候我们该做一个跨厂商的云端资源管理方案了。现在虚拟机不能像CDN一样随意迁移，但未来容器、Servless和PaaS服务崛起，彻底改变了现有程序发布模式后，计算能力也会在多厂商之间漂移的。我们提前把云管平台从计费和权限层面做好，至少现在就和厂商砍价有底气，还能模糊计费相关业务数据。

 

整个云管平台涉及三个参与角色：

 

供应商或厂商，实际提供云资源的厂商，如3A、百度、七牛。

 

云管平台，即本文中设计或者采购评估的云资源管理平台。

 

用户，登陆云管平台进行诸如创建主机、修改存储空间等操作的最终用户

 

#注意，云管平台才是最终用户要操作的云平台。

 

任何一个在云管平台可以独立计费或独立管理的功能组件都叫做资源。

 

每个资源都有唯一的ID做代码逻辑层面的描述标识，云资源供应商、云管平台、用户管理控制台、计费系统、API对接等等系统，都需要用到这个资源ID做管理系统的描述识别。该资源ID一般是供应商平台自动随机生成的，用户无法指定甚至不关心ID内容，而云管平台可以简单封装标识该ID。比如用户申请来自a01供应商的云主机，供应商内部给该主机定义的资源id为“abcdef”，则云管平台的资源id应为“a01-abcdef”。

 

每个资源都有一个用户自定义，便于用户人工操作可读性的名称；在供应商自己提供的云平台上，这个名称仅仅是个标识，客户可以随便修改，也不影响实际云端业务。如果你要做大而全的云管平台，可以让客户随意操作资源名称。但如果只是做简易云管平台，我的建议是用资源名称做不同用户的隔离标识，且让用户不可轻易修改该名称。比如说用户user1创建的云主机名字叫“web01”，那实际创建的云主机名应该是“web01.user1”，且“.user1”部分不可修改。这样通过资源后缀名就可以笨拙但有效的区分开不同用户的资源。

 

本文接下来的内容就是云管平台拿到的不同供应商资源，哪些是必要资源，哪些是可选资源；这些资源至少要进行哪种程度的管理才能满足用户的基础需求，哪些功能用户嚷的响亮，但不是燃眉之急，可以放到二期三期来做。

 

第三必要云资源

 

云计算平台最早是对物理服务器的模拟，所以必须的云资源就是模拟物理服务器的资源。但云平台用SDN管理网络，云主机无法像物理机一样自由发ARP广播，所以和主机网络相关的配置也要单独管理。现在云平台都把云硬盘独立于主机之外单独管理，本地虚拟盘几乎绝迹。

 

当我们要设计云管平台时，最小必须的云计算资源为这几项：

 

1.云主机，2.云硬盘，3.公网IP+带宽4.VPC+安全组5.负载均衡

 

一个云平台缺少这五项中任何一项，用户都不可能达到等同于自购物理机的效果，甚至最基本的功能都无法执行。当前各大供应商（含OpenStack和Zstack方案）都将这些云资源都已经实现API化创建、查询、管理、删除。

 

对这些必要云资源的规划思路是，在能保证基础功能和用户便利的前提下，尽量砍掉一些炫酷但只有少数厂商支持的功能，为了简化开发难度，对一些通用但低频功能也可以拖到二期三期再做。

 

比如云主机创建主机API时必备功能是“选择硬件配置”“顺手创建公网IP”“自定义镜像克隆主机”“设置主机名”的，管理API必须有“查看主机状态和配置”“硬重启”“绑定/解绑IP、硬盘”。其他的功能根据项目组的人力和工期可选展示给客户，有人有时间就多做，没人没时间就少做。比如说“选择可用区”功能可以展示到界面上，也可以保持默认；“设置修改密码”功能可以直接带上短信验证通道开发完成，也可以用户发一次邮件就代为操作一次；至于“配置升级”等功能，做功能接口并不难，难得是供应商的计费策略并不统一，并且云管平台的计费系统变得复杂了。

 

云硬盘和IP/带宽的设置很简单，VPC和安全组就要多考虑了。如果云平台面对的客户需求很简单，那可以每个用户默认只有一个VPC一个子网就可以实现基本功能；NAT端口映射、VPC互联、VPN路由等高级功能都是可选功能。当前安全组功能繁琐而混乱，大部分客户需要的只是管控对外开放端口。

 

负载均衡是云平台唯一必备的PaaS服务，因为VPC环境下很难做keepalived和heartbeat。客户在VPC里只能搭建没有HA的LB，还不如把LB整体外抛给云平台解决。从技术上说负载均衡必备的服务是按源IP分配的TCP负载均衡，让这个负载均衡主要做HA用，后端可以再接用户自定义的LB；但是各大云平台都已经支持HTTP/HTTPS/UDP负载均衡，云管平台可以一开始就把四七层负载均衡功能都开放给用户。

 

第四附加云资源

 

前文的必要云资源是狭义但经典的云资源，其主要目的是将物理资源抽象化输出资源池化调用。而另一些服务上云更多是技术上强调自己接入了VPC，或者强调自己开箱即用、无限扩容。云管平台集成这些资源是为了节省用户人力和统一出账单，在人力和工期紧张时，下列服务我们一个也不做，让用户自己在虚拟机上搭建；在人力和时间富裕状态，我们要认真评估如何接入服务。

 

依赖虚拟IP和共享硬盘的传统群集服务，比如双主多从MYSQL，Keepalived+Redis，Heardbeat+DRBD+NFS，Oracle RAC。前文在LB阶段已经讲过VIP无法在VPC网络里自由漂移，大部分云厂商又不太支持共享硬盘、心跳线等功能。云管平台可以集成这些资源应对中小型客户需求，也可以直接建议客户单机部署；重型用户需求产生了就不轻易变动，可以通过云管平台自主测试、云厂商定制开发、接入混合云物理机等方式来个案单独处理。

 

客户端旁观选举的自协商群集服务。最近十年出的新服务，以及一些老服务的Cluster版都在走向智能化群集的方向。以Mongodb为例，客户端会连接多个mongos和mongod，客户端旁观服务端选举和切换主节点，不依赖虚拟IP就实现应用层高可用和负载均衡。云管平台可选接入厂商服务满足中小型客户需求，毕竟不用自己做服务维护；但遇到重型客户需求建议直接在高配虚拟机上自己搭，或者走混合云物理机接入VPC的模式。

 

不考虑高可用性的服务。这其实挺尴尬的，理论上来说即使是内存缓存型服务也有双活机制，但是厂商PaaS服务的后台架构完全是黑盒，没出故障时都是专业架构，出故障了都是百年一遇，大都是“只考虑人品”的服务。以RDS为例，不同厂商的RDS可靠性千差万别，我亲眼看过很低可靠性的服务，也听朋友说过本厂的RDS可靠性远超普通DBA；但RDS对客户只暴露一个服务接口，我们不知道厂商给主库磁盘做没做RAID，也不知道主从库会不会在同一个物理机。所以前文中我对中小客户用PaaS当做节省自己搭建的人力，对大型重型PaaS需求建议个案处理，因为各厂商通用的百倍赔偿根本就是个免责条款。

 

对象存储（OSS）和CDN。我一直不理解Nova和Swift如何从业务上联动，做虚拟机时跟客户解释买虚拟机不关心OSS，做对象存储时解释OSS和其他云平台没什么好混合的。云厂商提供OSS+CDN的好处就是内网互通节省带宽费用，但大客户很可能越过云管平台直接采购，小客户一年可能只节省几十块钱。云管平台要集成OSS和CDN服务时，一定要注意这两个服务是没有区域概念的，比如客户用了百度北京的虚拟机加上七牛浙江的云存储和阿里全国的CDN，此时客户业务绝对跑的通，三方互通有额外网络开销。云管平台的资源创建和计费系统都要考虑清楚，尽量资源走一个供应商，或要求不同供应商之间相互免费。

 

上述PaaS资源都有一个特点，可以按照使用量付费，或者提供贴合到业务逻辑操作层面的支持功能，那也就代表着客户的计费访问数据铁定会被供应商拿到，而业务数据是否被偷窥要看供应商自律。

 

我们再看看下文一些更专业（偏门）的服务。

 

容器云入门门槛太高，在中小客户场景下缺乏成功案例，如果没有具体项目要求上容器云，就等到接完上面的PaaS服务再考虑接入容器云。

 

反DDOS攻击服务只能由云厂商提供，因为开销偏大计费不灵活，但又没有日常管理需求，客户到云管平台到厂商沟通时直接用邮件、工单和合同即可，如果没有频繁攻击和检测需求，可以不留展示界面只用邮件通知。至于渗透测试和漏洞扫描，其实和云服务没直接关系，没必要纳入云管平台。WAF可以参照负载均衡服务进行设计处理。

 

物理机和自控超卖比虚拟机，这是部分云厂商才提供的功能，这类资源开销偏大和计费不灵活，客户要给云管平台发邮件才能申请到资源，客户日常有类似于虚拟机的管理和监控需求。

 

云监控是一个基本免费的服务，对该服务的设计包含安全评估、数据展示和通知机制。安全评估就是要不要装各厂商以Root权限运行的Agent，数据展示就是各种监控统计表和折线图展示给客户，各厂商是直接通知到最终用户还是通知到云管平台后中转传递信息。

 

其他，诸如域名、ICP备案、虚拟空间等服务。

 

第五核心业务系统

 

已知云管平台要管理上述资源，且不同资源的优先级不同、同一个资源也不需要部署所有功能，那云管平台自身该如何设计和展示？经过对多个云管平台的调研统计，其核心必须的业务系统有四个，分别是“管理平台”“用户系统”“计费系统”“厂商API封装工作”。这几个业务子系统都有几个人月就可以做出的简易版核心功能，也可以按照大型软件工程去做全功能规划设计。

 

管理平台

 

这是运营人员使用的的资源统计、展示操作平台。

 

平台首页是一个全部资源汇总页，即平台已经开通多少用户、多少主机、多少带宽等等，无论是日常运营还是工作汇报都需要汇总统计。如有余力可以和计费系统配合，做出各个厂商资源汇总对比页面。

 

平台还要有各项资源分类汇总及单资源详情页，即虚拟机、硬盘等资源。这里要求即可以做整体list，也可以查看单独一个资源的状态。前文提到要统一的资源ID可以调用厂商API快速查询和操作资源。前文提到的统一资源名称前后缀，可用于快速过滤出单个用户的云资源。如果快速施工可以只做资源的统计展示，云管平台操作员去各厂商的管理控制台上执行资源操作；如果时间来得及那就把厂商提供的功能在本平台全部实现出来。

 

2.用户系统

 

云管平台都是做对内业务或者固定项目，所以用户系统不开放注册，不需要找回密码、身份认证等功能，但酌情开放修改密码、高危操作短信验证、特种资源申请等功能，技术咨询类工单可以透传给厂商。

 

公有云的配额系统是为了保护厂商稀缺资源不被客户滥用，用户误操作不会花光资金的。云管平台的客户很少会滥用资源，平台是厂商的大客户也不会轻易欠费停机，云管平台可以只做简单粗糙的配额系统，以减少用户误操作为准，如果工期过紧甚至可以先不做配额系统。

 

用户系统要有一个客户可用的Web管理控制台，让用户可以完成各种资源操作。该管理控制台借鉴各大公有云控制台即可，所要展示的资源和功能已经在前文讨论过了，该产品可完美模拟功能强大，也可以极速从简只做必要功能。

 

3.计费系统

 

标准计费系统的功能复杂又强大，每个账户是预付费还是后付费、当前有多少余额/透支额度、单个资源是打包整体付费还是按需按量付费，免费配赠资源的占用策略，资源欠费后的保留周期，网银和财务付费接口，甚至连发票管理都是计费系统要涉及的。

 

本部分说明如何用一两个人月就能做出来的对账式计费系统。

 

用户相对可控，对反赖账逻辑就可以弱化甚至不做。

 

按量付费就要几分钟一次频繁对账，那就把虚拟机、公网IP的按量付费砍掉，通通做成包月付费；对不能做成包月付费逻辑的资源，小金额需求直接打包或减免（比如说OSS的get post费用是一百块钱上亿次），大金额项目只能做成延迟出账单的后付费（比如CDN账单）。

 

产品品类不用太多，比如说虚拟机配置保留常用的5-10类就行了，没必要做出四五十个配置类型。

 

各个厂商产品单价都是微微不同，但云管平台的资源可以做成统一价格。云管平台可以简单的按最高价格向客户收费，也可以要求高价云平台做充值赠送把价格实际降低。

 

每个资源的到期时间都可以通过查询API方便获取，即可在资源过期前及时通知到责任人；大部分云平台资源欠费也只是资源暂停使用，不会立刻释放，短时间内缴费后就恢复；但建议将ICP备案的IP地址做自动续费另案处理。

 

4.厂商API封装工作

 

不同厂商的资源操控API语法是不同的，同样是创建虚拟机的方法，可能叫“create-instance”也可能叫“create-vm”，而云管平台的统一命令可能是“xinzeng-xuniji”，要接入多家厂商就要完成多家厂商的API封装工作。这个封装工作的结果可能是一个写死的类库文件，也可以做成高大上的动态配置代理。如果当前只接入一个云平台可以省掉这份工作，后续无论是自己开发还是甩锅给新供应商都是可行的。

 

上文谈了这么多平台设计，大家一定觉得很不爽，问题怎么会这么繁琐，实现结果为什么会如此简陋，是应该有资源隔离但统一计费的父子账户系统，是应该有功能强大百调不厌的计费API接口。笔者以前就规划过和用过这些系统，写本文的目的也是为了催促各个云平台开放此类功能。

 

第六进阶补充系统

 

除了上述核心业务系统外，云管平台还可以有一些补充子系统，让用户像在用像一个标准云平台。

 

面向客户的API系统。高级用户会有调用API管理资源的需求，云管平台需要逐步开放面向客户的API或SDK。

 

客户智能化操作系统。云管平台可以更贴近用户业务，主动替客户完成一些运维操作。简单的如滚动快照云主机，复杂的如根据LB负载动态扩容缩编Web服务器。云管平台离客户的业务足够近，又对云端资源有深入了解，完全可以以此为切入点，从资源贩售发展为技术输出。

 

日志系统。无论是计费日志还是操作日志都可以逐步记录和开放出来。

 

通知和工单系统。此系统不用过多描述。

 

附录：我们亲眼看到CDN服务从各自为战变成了智能融合，随着计算业务的成熟发展，希望计算服务也能如行云流水般想迁就迁。

 

配图是早期火车和马车赛跑但输给马车的照片，但是后来火车赢了。