2019云计算开源产业大会丨刘宇：CMP技术架构

大家下午好！首先很荣幸能够来到这里跟大家分享一下贝斯平CMP的技术架构。我主要还是做研发为主，大家如果有什么问题的话可以跟我做一些技术方面的探讨和交流。

在讲CMP的时候我会重点讲几个核心的点的技术架构，第一个在CMP里面的定义，中国信通院在针对于云管核心能力上会有明确的几个大的定义，几个大的定义里面第一个会放在多云的接入能力，多云接入能力很多人会觉得不管是几朵云，能用就好了，但是实际上在底层技术架构里面我们要去接入每一家云的时候，其实成本是非常高的，我也会重点讲一下我们怎么样克服这里面的技术困难。第二个就是异构资源的纳管，我们也会把它放在CMP的最底层，我们统一做纳管的这一层面。第三个是资源的管理，包括资源的查看，包括操作层面，再就是整个服务的编排，这个就会涉及到上层的操作会更加多一些，再就是监控的层面，我们有了资源的管控和纳管，肯定需要知道它的可用性，它是不是可用？再就是成本，大概哪个部门花的钱最多，哪个部门的成本最高，可能某个部门特别不挣钱，但是你却发现它的资源大批量在浪费，因为大家很多时候公有云上面没有办法按照公司的组织架构去分，所以没有这么一个概念的时候更加不知道这个钱到底花在哪里，所以在成本核算和成本优化，我原来的做法很简单，就是做一些监控，只能做到利用率。最后一个话题是在安全方面。

在讲之前先说一下贝斯平是干什么的。第一个是国内象限，连续三年不断在往前排的就我们，之前谁讲的好像我们只是在国内象限有一个点，后来发现连续三年不断做攀升。第二部分是我们公司内部的企业文化，我们努力地帮助每一个企业驾驭云IT，这是我们公司的使命，我们怎么做的呢？主要分如下几大块，第一个是帮助企业做一些转型，现在这一块是MSP大的能力，我们会结合我们对云，包括云原生的理解，我们会给出更专业性的建议，包括云架构的调整，怎么上云、怎么做迁移、架构如何做优化，甚至我们会做一些双活的建议。但是双活又很贵，所以我们会根据企业的每一个不同发展阶段给出不同的建议。

另外我们会有专业的团队管理你的服务，包括24小时的监控，我以前在大公司的梦想就是期望公司轮值的手机永远不要到我手上，只要到我手上我就很不开心，每天几百个短信过来的时候，经常起得早，我就直接冲出来拿起电脑干活，这是原来的日子。现在我们有一个团队就在过这种日子，我经常跟他们说你应该多关怀一下你家的兄弟们。

但是研发有研发另外一个层面的问题，研发就是在最后那一块，就是在OpsNow，在多云管理平台这一块，在底层平台以及开发的时候，我们就会想到怎么帮助原来的我节省更多的精力。做监控的时候我会想到第一个监控要全，第二个怎么做收敛，在管理资源的时候怎么更加方便，而不至于操作特别繁琐。这是我们推出的OpsNow。

先看一下整个产品的大的架构，分层，架构无外乎是一层、两层、三层。现在的公有云给我们解决的原来的IDC机房最底层的那一层，我们把它叫作基础设施层，实际上我们在很多业务运维、开发、业务架构或者是做录入代码的时候会发现我们是关注在上层的业务层，为此我们在构建整个多云管理平台的时候，我们会把整个底层，也会把它叫作大的CMP，会把它纳入进去，上层会通过资源管理之上再去构建各个不同形态的树，我们把它叫业务树、财务树、组织架构树，比方说分了BUA、BUB这样导入公司整个OA。

当我们看到一个IP的时候我们不理解，但是当我们看到一个业务名字的时候是比较理解的，就像我们记域名一样，我们不会记IP，只会记所在的域名。在这个基础之上，我们会去做很多运营层面的东西，包括计费、监控、事件等等，包括资源的管控。上层会把安全类的产品封装在最上层，这就是我们OpsNow大的业务架构对外所输出的产品和能力。

首先，整个资源接入层架构。我相信每家公司都在乎成本，我们公司融的钱挺多的，也很在乎成本，怎么样省钱？刚才提到我们接入的云商很多，国外的云也好，国内的云也好我们都接了，接每一朵云就需要有1-2个工程师，我相信在座各位很多都是管理者，你们应该知道招工程师的话大概要多少钱一个月。其实在资源接入的情况下，我们会有技术的难点，刚才提到的第一个层面是一个方面，第二个，每个云上的接口也都不一样，输出的参数也不一样，所以会有参数支点的转换，参数支点的转换在整个技术架构里面比较大的亮点，参数支点转换的好处是什么？好处是指每一个云里面不同的参数会统一做输出，统一做输出的情况下对于整个架构的上层分离而言，上层的API就可以统一走一个接口调用，不管底层是接的阿里也好，腾讯也好，任何一个云也好，对于前端而言就是一套接口，对于后端而言怎么办？就是需要有一个支点去转换或者适配前端的接口，调各个不同云上的SDK。其实我们这样做的第一个做法就是为了快速接入，第二个减少前后联调的工作。

第三个优势就是在于每一个云商都是完全独立的SDK，比方说阿里的SDK某一个区出现了故障，它不会对其他或者对整个平台造成任何影响，只会影响这个区的资源调度和使用情况，其他的都不会受任何影响，为此其实我们在这里维护了一整套的框架，帮我们做排错、定位等等一系列的故障处理，为了做参数智能转换的情况下，我们会有比较大的结构输出，我们会把云上的输出统一表结构，去抓取每个云商的接口，是每一个类型，计算资源是计算资源，存储是存储，网络是网络，我们把每一家云全部摘出来，然后抽取共性，然后再将共性里面的名字进行重命名，再做映射关系，这个时候只需要拿到一个资源的类型经过资源转换之后立马可以进行入库，这个时候对于底层开发而言，接A云资源，按照这个模板快速对接就好了，因为转换这一层不需要你管，对于开发的速度、效率、自己调试的能力各方面来讲，会得到一个大幅度的提升，因为没有任何其他的外部以来。这是我们整个架构里面花的时间最多的一部分。

在服务调度逻辑里面，做过开发的人知道这是一部分很大的工程量。单位不同的数据，有很多云商它的数据不一样，我们说其实在这里面接的所有的云商里面最难的就是AWS，因为它是独立门户，其他的所有云商都是仿AWS。

包括名称映射、格式化等等一系列的操作。第三个是把安全组和名称跟AWS不相同的地方做一个转换，主要也是体现各个云商的差异。同时，统一规则，刚才我也提到了统一规则最大的好处就是甭管有多少资源我都可以统一入库，统一的规则还有一个好处是什么？你们想一下这么一个场景，如果说客户使用了云管平台去创建了一台虚拟机，平台是有记录的，但是如果这个用户心情不太好，他忘记了，他直接通过云上的创造了云主机，请问平台是否需要记录这个云主机，这个场景的解决方案很简单，需要具备定时任务的功能去扫，扫这个客户所在的云商所有的云主机的历史记录，找到差异化的地方重新入库，这就是一个工程量。有清楚或者了解的情况下，如果云上的资源大概超过几千条的情况下，少一次以及入库的时间会非常长。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!