大家下午好！首先很荣幸能够来到这里跟大家分享一下贝斯平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不相同的地方做一个转换，主要也是体现各个云商的差异。同时，统一规则，刚才我也提到了统一规则最大的好处就是甭管有多少资源我都可以统一入库，统一的规则还有一个好处是什么？你们想一下这么一个场景，如果说客户使用了云管平台去创建了一台虚拟机，平台是有记录的，但是如果这个用户心情不太好，他忘记了，他直接通过云上的创造了云主机，请问平台是否需要记录这个云主机，这个场景的解决方案很简单，需要具备定时任务的功能去扫，扫这个客户所在的云商所有的云主机的历史记录，找到差异化的地方重新入库，这就是一个工程量。有清楚或者了解的情况下，如果云上的资源大概超过几千条的情况下，少一次以及入库的时间会非常长。
所以统一入库之后，再做一些差异化，入库规则是固定的，所以我在写库的时候速度效率会变得非常快，中间加上一个缓存，我们的性能就是杠杠的。另外我们会把用户的主表，包括一些详情表拆分出来，就是把账户以及对应的资源的信息拆开进行存储，因为要考虑的东西就是AWS还会有主账号，阿里、华为只有一个主账号的概念，在处理云商不同的账号以及资源之间的关系的时候就变得简单了，我们拿账号跟公司本ID做一个绑定，这个ID和主账号可以做绑定，你只需要和底下的详情表做一个Link关系就可以了，不管是否有变更都可以清楚地了解这里面的资源管理，这就回到一开始信通院的要求，就是资源管理的能力，在这里面就算一个点。所以我们在数据变更的时候会采用Redis进行缓存，这也是我们需要考虑的点。
我们如何统一优化云商的调用关系，我们是用Spring框架，各个云商之间如果涉及到资源之间的依赖，我们就可以通过MQ的方式进行发消息，解决这里面异步的问题。另外一个情况下，我们会统一一个日志输出，云商资源越接越多，云商资源的变化也很多，不同的区，不同的进项都会有变化，我们也需要定期发现这里面的问题，主动发现问题，同时告诉客户这里面已经没有办法使用了，这里面就需要有一个完整的日志的监控信息，通过这种方式，我们所有的东西都是通过拦截的方式，将自动参数写入数据库，这里面有一个比较难的地方，就是日志的格式很难做规范和统一输出，这是比较难的，我们解决的方案其实也非常简单，拦截的时候，统一输出，这样可以做到整个数据库在排错和检查的时候会非常顺利和方便，这是整个性能优化的大点。可能前期的时候不会在乎这些细节，当接入的资源越来越多的时候，这里就是你的瓶颈。
这是现在整个OpsNow产品的基本展示，大家也可以看得到，通过平台可以快速地看得到所有的资源的情况，每一个云商资源的消耗情况，包括消耗在哪一些资源上等等这些。通过平台当然也可以快速地创建一些资源。所以我们主要是利用资源优化和成本优化快速地体现出我们对整个资源提升的情况，比方说我们可以提升40不能的资源利用率，以及30%的成本节省。
运维工程师最主要的职责之一是替公司省钱，但是平台给公司省钱和利用率的提升里面有一个最关键的点就是跟业务架构关联在一起，为什么说资源纳管以后一定要有业务的服务数，业务服务数配合监控数才有下一步的东西可以说，就是多云账单处理，多云账单处理在很多家不说是世界性难题，我们一开始做的时候也面临很多的问题，比如账单的接口也不一样，第一个是这个，第二个权限不一样，云商的账号是分很多的权限的，你能拿到什么权限以及每一个账单的权限是直接给你账单接口的权限还是它的账单是入在S3里面，你去S3里面读取账单，接口的数据处理完全不一样，我们在整个底层这一块，在整个数据采集和处理模块就分了三个模块，主要是分为采集、提炼和聚合。采集分各个云审不同的逻辑采集，包括次日账单、存储桶、API接口，处理完成以后再根据公司的组织架构、公司的业务架构对数据进行一次提炼，提炼完了之后再把它合在一起，再根据资源预算、优化、算法、RI的整个东西都融合在一起才出现现在的产品形态，包括就能体现按小时的挑战。
底层实现的细节，第一个会有定时的任务，scheduler-Worker做账单的采集。第二个是不同的云商采集的模式，刚才我们提到有四五种采集模式，会有差异。AWS的DBR和CUR也是有差异的，根据这个差异我们也会做不同的数据采集和处理。存储的话，我们会按照小时、天、分步、分表，计算完成以后分步存储，这个逻辑很像很早的Hadoop的处理方法，包括Hadoop的2.0时代会进行分层计算，这里面其实也非常像。在精度保证的情况下会做自动的校验，包括准确性的校验，最终还有人工核查的过程，这是为了保证账单采集过来之后是准的，再进行计算。
产品形态上会看到整个账单的趋势，会有整个同比、环比，包括简单的预测，同时可以根据，我刚才所提到的产品的公司的部门、组织架构，再一个就是我们的业务，每一个业务大概花了多少钱，在这里面我们会区分各个不同的模式或者说不同的方式给客户一个展示，最终回答一个问题就是我的钱到底花在哪里？哪些地方可以省钱，哪些地方不能省钱，帮决策者做一个更好的决策。
最后讲一下，因为时间特别紧张，我没有重点讲监控，最后讲的是我们在后续能够做的大的方向，我们在整个数据赋能以及在整个数据驱动上面我们会推动整个OpsNow不断地往前发展，包括我们也会不断地优化我们在成本优化、资源管理以及其他各个方面的能力。
我的分享就到这里，谢谢大家。