云管理平台的定义、需求、功能与架构设计
云管理平台的定义是Gartner提出来的，总结起来就是两块，第一是管理，管理公有云、私有云，形成混合云。第二是自服务，镜像划分，计量与计费，负载优化。云管理平台最终的目标是应用在云平台上运行时取得最优化的效果。大家熟悉的公有云有上云服务，能最大限度的保证应用的可靠性，我们自己设计一个云管理平台时也要考虑这方面，还附加了一些外部系统的对接与管理功能。
说到云计算，大家会想到OpenStack，OpenStack跟云管理平台有什么区别，是不是可以基于OpenStack做一些云管理平台？目前从我们自己的定义以及市场上的反馈来看，我们认为云管理平台是更广的范围。我们可以把OpenStack看作是云管理平台下属的资源模块，云管理平台可以管理多个OpenStack版本。有些企业会在不同的数据中心里部署不同的OpenStack资源池管理模块，在OpenStack之上也需要一个云管理平台来管理多个OpenStack资源池以及管理不同的OpenStack版本，另外还有很多虚拟化不是由OpenStack+KVM实现的，比如Vmware、Xen等虚拟化，所以云管理平台还要针对这种虚拟化做对接。从层次上来看，云管理平台是解决用户最后的资源使用一公里的问题，最终提供给用户服务的是云管理平台的自服务平台。
我们实现的云管理平台主要分三大功能：
异构的虚拟化管理。OpenStack天生对接KVM平台，在Xen、hyper-v、VMware对接上是相对劣势的一点，
我们实现的是同等能力的管理。
多个OpenStack版本、多个资源池管理还有多数据中心扩展。
调度、计量计费、外部系统集成。
云管理平台主要有资源管理、运营、自服务三个功能，资源提供方比如存储、计算、网络。资源池最终交付给用户的是一个一个服务，比如计算服务、存储服务、网络服务等IaaS层面的，中间件服务、数据服务等PaaS层面的。怎么交付给用户的？是云管理平台将资源管理起来，通过运营，在公有云上这种运营可以是计量计费，之后通过自服务界面把应用提供给用户使用。
这是云管理整体的定位，它是承上启下的。对下管理资源、对上提供应用使用的界面和API。如果创业公司自己设计一个云管理平台的话，五个模块必不可少，一是资源管理，二是运营管理，三是服务提供管理（使用界面与API），还有运维管理与安全管理。
这是我们设计CMP1.0时第一版的架构，拆分一下有资源管理系统、运营管理系统。资源管理系统负责物理机管理、存储管理、网络管理、多数据中心管理。架构图右上角的模块是一个专门的虚拟化管理系统，它也可以看做是一个资源管理模块。为什么把虚拟化管理系统拆分出来？因为虚拟化管理系统是云管理平台一个比较核心的模块，需要对它做更精细的设计，所以单独拆分出来。
运营管理系统最终的目标就是将资源管理系统、虚拟化管理系统管理出来的资源运营成为一种服务，比如服务目录就是将资源发布成云计算产品，工单管理、流程管理、计量计费负责用户申请一个虚拟机或一块存储空间，怎么做计量计费，怎么发布出去。再往上是用户使用的自服务，运营门户、管理员门户，当然也要开放统一API，因为有些应用使用的不是自服务界面，而是使用API调用虚拟化、存储、网络。要做好一个系统，运维管理，比如监控还有日志分析等等，是必不可少的。在云管理平台之外我们单独设计一个运维管理系统，通过Zabbix等采集模块采集系统运行状态，实时呈现给云管理平台的管理员，这是CMP总体架构设计的1.0版本。
1.0版本的资源管理系统
首先看资源管理系统。 虚拟化管理系统可以看作是资源管理系统的子模块。目前市场上常用的虚拟化大的用户里最多的是VMware。我们统计过电信运营商、银行等等，VMware占有量大概在80%以上。第二个是中小企业，用微软hyper-v的比较多，还有citrix、kvm、苏研虚拟化。我们在做虚拟化管理系统时是做虚拟化适配层，针对每一个虚拟化平台做一个driver，这个driver可以下发指令、并反馈状态，同时开放API针对管理层使用。比如虚拟机的基础管理，像开机关机都可以通过driver做。在基于KVM去做的时候引用了OpenStack虚拟化管理的nova模块，主要目的是有了nova我们也没有必要完全重写针对KVM虚拟化管理的功能。
我们在设计私有云的时候，用户对应用支撑这块有很高的要求，比如数据库服务，他会明确要求放在物理机上。 所以资源管理模块需要做物理机管理，目前是基于IPMI实现的，可以做物理机的分配、自动安装、自动服务提供。跟虚拟化的区别就是物理机的分配单位是一台一台的物理机，虚拟化的分配单位可以在物理机上做更小的切分。
还有存储模块。目前说云计算的时候大家一提存储往往是提分布式存储或者云存储，类似对象存储的实现。如果在传统企业做存储管理并将存储形成存储服务的话，还有一块就是传统存储，也叫SAN存储，包括FC存储和iSCSI存储。这种存储管理的实现我们是通过标准的SMIS协议，如果没有这个协议就要对接cmd
line/shell脚本实现。
资源管理的网络管理。云计算里面经常介绍SDN的管理，除此之外还有路由、交换机、防火墙，这块的管理需要在上面自动划分网络服务，划分一个VPC或者子网，需要通过网络管理模块API做对接和呈现。
最后是多数据中心管理。比如要帮一个公有云的客户实现一个云管理平台，这个公有云可能会在全国部署多个数据中心。涉及到一个云管理平台对多个数据中心的管理，这是一种分布式架构的实现。比如说在数据中心里把OpenStack或者vCenter作为一个资源池模块，最终是一个云管理平台去管理多个数据中心，并做整体平台的运营和服务。
刚才简单的给大家总结了资源管理这一部分，包括计算资源、存储资源、网络资源的统一管理。
1.0版本的运营管理
管理完之后是运营的过程。运营包括将管理完的资源发布成服务，需要一种服务模板的规划设计。服务模板包括把一个虚拟机定义成一个服务，包括虚拟机的定义、发布、审核以及在界面上的呈现。在服务目录之后，我们有了服务的概念，还要做计量计费，用户使用资源时要做统计，公有云上可以收费用，私有云可以做跨部门之间的资源使用统计，这是订单管理和用户管理、资源使用计量计费三块合一，也就是要确定一个用户或者一个部门使用的资源时间时长以及最终的计量计费的过程。最后是运营门户，运营管理员可以运营这些服务。比如公有云厂商定期有新的云服务发布，基本是在运营管理层面上做的。
我们做了一个总结， 应用在使用时主要可以分为两种类型：实时交易类型和在线批处理。这两种应用迁移到云平台的时候都有自己的特定要求。
首先看传统的交易系统，比如电商系统或者是CRM人力资源管理系统，它分三层：Web、App、DB。以前中大型的企业，比如银行或者运营商都是放在小型机上承载的，Web用X86服务器，App可能用weblogic、websphere放在小型机上运行，还有DB用Oracle或者DB2的数据库，都放在小型机上。阿里一直在提的去IOE，实际上是一种分布式架构改造，改造之后传统的Oracle数据库、DB2数据库，逐步去做分布式数据库或者是关联不复杂的数据逐步往非结构化数据、内存数据库做迁移，还有NoSQL数据库，实际上数据库是在逐步做新技术的引入，实现模块化分布式改造。如果我们把原先单一的数据库改造成分布式数据库，需要分布式数据库的数据路由和集中访问。到应用这层，以前我们说weblogic、websphere，现在就改成微服务，比如一个一个的应用，每个应用单一化改造成单一的服务。有了微服务之后，在微服务上层还需要微服务的治理，比如服务编排、服务访问路由。再上层就是用户交互层。
传统应用云化改造对云管理平台功能设计的新需求
传统的应用在改造成云化架构时带来了很多需求：
第一个关键点是Web接入，比如从单机变成负载均衡+后端多节点。从客户流量变化上大家都知道有弹性伸缩，节点数量随着流量变化而变化。
第二是X86集群部署，小型机的年代是单机或者是HA的部署，到了云化的时候，从Web到App到数据层，都是x86集群化部署，所以要有集群管理功能。
第三是数据分布式部署，原先的单一数据库在存储几亿条数据之后，查询交易上延迟性和响应上比较大，所以会考虑数据库的拆分，比如数据库表的垂直拆分或者水平拆分。拆分之后会带来新的问题，比如数据对外的统一访问，原先是一个表如果拆成多个表，每个表跨库join、跨表join都是新的问题，所以在云平台上要构建数据路由层或者统一数据访问引擎。开源的有Hibernate、Shards、Ibatis-Sharding，但是开源的访问引擎如果集成到云平台上，云平台对他们的监控、调用逻辑的呈现是必要的需求。
第四是数据平台化。以前App跟数据库逻辑一般是绑死的，比如在数据库里写一些存储过程，这种存储过程往往跟中间件层有很强的逻辑关联性。微服务化之后，需要后台单一的每个不同的数据库存储，需要有集中的存储平台的概念，最终要做存储分析、订单的历史趋势呈现，都需要数据平台来做。
还有一块是联机分析处理。以前做数据仓库就是大的Oracle数据仓库，Hadoop技术出现之后大家就想用Hadoop做Oracle的数据仓库功能。最开始的架构就是在原先的Oracle
DW之外，逐步引入Hadoop技术，如果要做关联复杂的历史数据分析，比如银行的复杂的用户数据画像需要MPP数据库，如果不复杂也可以用Hadoop做。最开始的联机处理分析引入的是Hadoop并列割裂式的架构。如果需要在Hadoop分析，可以把数据仓库上的数据导到Hadoop上进行分析。这种方式有一个问题，相互独立的信息系统缺乏数据交互性，演进路线受限。后来大家提企业级数据平台，是从ETL层到数据汇总，统一做拉开。
总结一下交易系统跟批处理系统在上云过程中对云管理平台的新的需求。第一是弹性计算，Web节点实时弹性伸缩。第二是App中间件层逐渐引入微服务，微服务架构有很多，设计出的微服务也很多，需要对微服务做统一管控。第三是越来越多的模块，需要对产生的数据监控做更多分析。比如一个用户三年前上云，现在数据中心积累了海量的监控数据，监控数据对他也是很有用的，可以做历史趋势的分析。第四是需要支持大数据类、开源数据库类的开源组件对接与管理。
我们做了几点，第一是虚拟机编排跟弹性伸缩。大家知道Docker有自带的弹性伸缩，在虚拟机这一层也需要弹性伸缩。第二是资源管理系统引入了微服务管理。第三是开源组件的支持，引入了Docker+Kubernetes，把hadoop和spark的一些内容往弹性计算体系迁移，这样云管理平台新的针对应用的设计演进了一步。这是2013年1.3版本的设计，到2014、2015年3.1版本的设计，逐步引入弹性子计算系统。
云管理平台最开始1.0的设计只是对资源的管理，到了2.0、3.0的设计时，我们逐步发现上云的过程中，应用会对云管理平台提出新的需求，如何调整、如何增加新的技术实现对应用的支撑。接下来看一下容器跟微服务引入之后对云管理平台本身设计架构的改变。
容器与微服务化对云管理平台新的架构设计的支撑
两张图的对比。左边是1.0的架构，它的部署架构包括自服务门户、门户后台、用户服务、运营服务、运维管理。运营服务里面有订单管理、计费管理、AZ配置。所有业务都是耦合的，如果要升级一个功能整个服务都要升级。这是一个不利点，而且开发测试团队也不明晰，升级任何功能点都要对模块进行重构。所以我们在微服务上考虑引入这样一个架构，运营服务、产品支撑和运维管理里面每一个功能点都单独做成一个微服务。
微服务的系统架构主要是两个分离： 第一是客户交互与业务逻辑分离。前台的JS与后台java分离。 第二就是微服务化，把这些服务都通过服务管理、服务注册、服务发现管理起来，前台对服务的使用都通过微服务管理平台发现相应的服务，导流到各个服务节点上。云管理平台最终提供很多产品，像云主机产品、块存储产品等等，我们会把这些产品做成一个一个的服务，通过微服务化可以实现数据中心里每个服务的自治，不同服务的升级可以完全基于自己去做，只需要保证对外API是统一的。再一个就是分布式，我们做了无状态化可以做更好的云管理平台本身的弹性。比如一个大的运营商是集团级的，用户量有上千万，每次促销时云管理平台自身的压力也是一个比较大的点。每次促销都是先备很多虚拟机上去，现在微服务化之后通过无状态化可以实施自动的扩展。
微服务化之后每一个管理平台最终的状态是什么样的？第一是运营管理门户，每个门户有订单查询、产品目录、工单等等呈现。在门户选择一个服务就会通过REST
API的形式到运营管理API上，每一个API都是一个单独的服务。点了一个服务之后，这个服务的逻辑实现是在后台，通过微服务管理平台上找相应的已经注册的服务，然后服务将最终的逻辑实现。
资源管理平台也是同样的概念，比如说资产管理、故障告警等功能最终会落在一个个服务的API上，再通过服务发现、服务管理功能导流在后台服务做统一处理。
微服务化之后有一个比较重要的就是对服务能力的监控。目前我们是两种方式，一种方式是用ceilometer实时采集呈现，还有一种是实时呈现完之后历史数据的存储，目前是用Spark集群做。需要对每个Hypervisor做实时呈现跟监控，这是做平台必不可少的模块。
再就是日志，比如说调用的日志，从用户申请一个虚拟机的服务到每个服务之间的调用是7步左右，这7步任何一步出现了问题都要做产品回退，因为这会影响最终使用，所以需要对每一步的调用日志进行监控和采集，以确保可以排查哪一步出了问题。日志我们采用了开源的Elastic
Search，做了一些封装和改造。最终在日志管理的界面上呈现。
最后就是微服务化之后系统模块之间的关系图。以前就Web、App、DB三个服务，微服务化之后变成30几个服务，每个服务之间也有调用关系，这种关系图是维护系统运行的最重要的模块。CMP1.0的时候我们很少强调总架构师的功能，微服务化引入之后我们在后台研发上专门设立总架构师的功能，他来维护模块之间的关系定义及关系服务之间的架构设计。
微服务化达到的效果就是变快，从迭代、变革上大大加速了产品响应速度。以前公有云厂商每次找我们开发页面时，好几个晚上都要加班上线，达到微服务化后基本上白天做版本更新，可以做到快速响应跟上线。
云管理平台未来的定位展望
最后说一下云管理平台未来的展望。我自己总结了几点：
精细化管理，管理能力更强、更精。SDN、SDS等的管理，打通编排的所有环节。
计费方向的细化。我们需要去做基础设施更精细的计费，以前按天按月，现在按时按分。
云+应用的一体化管控。从用户系统的接入到对云服务组件的调用，全流程的监控分析体系。
混合云管理。公有云是不可阻挡的趋势，私有云和公有云的混合管理也是一个方向。
行业云和社区云的建设与支撑。如果你抓住一种特定的行业或者特定的应用场景，比如说渲染云、高性能计算云等，它的盈利点还是比较多的。
大规模节点管理时，考虑结合AI，针对资源池的运行数据进行分析与运营，形成运维知识的深度学习。
|
