深信服杨旭荣：传统企业云化IT架构建设之路

本文根据杨旭荣2018年10月17日在【第十届中国系统架构师大会】上的演讲内容整理而成。

讲师介绍：

杨旭荣

深信服云计算BU架构师，拥有近10年云计算领域，核心底层技术研发工作。热爱开源社区，OpenStack，SDN，PAAS专家，挖掘发表多项核心专利。作为云计算架构师，主导超融合，私有云，混合云等架构产品化落地，参与电信，金融等行业云化数据中心解决方案，SDN/NFV及应用架构转型专项工作。

分享大纲：

• 传统企业IT架构演进及核心诉求

• 深信服云体系架构介绍

• 超融合aCloud+aCMP架构设计

• 数据中心可靠性能力建设

• 数据中心安全能力建设

结合过去数字化转型实践，介绍企业IT架构演进思路和核心诉求，通过深信服超融合架构和云管一体化架构满足广泛应用，打造安全可靠数据中心!

一、传统企业IT架构演进及核心诉求

目前而言，越来越多的传统业务客户选择把核心的应用或数据上云。超融合凭借其把计算网络存储安全融为一体的架构，很灵活满足了整个传统企业的IT应用。

随着核心的应用上云之后，可能会涉及到另外一个问题，即整个数据可靠性的保障和容灾中心的建立，包括本地容灾，异地容灾两地三中心的架构体系的建设，整个体系完全是为了满足传统企业虚拟化云化之后的过程。

但另一方面某些创新型的应用，比如AI大数据，包括在整个公有云服务体系上，一些模型场景的具象化服务能力输出之后，部分客户对公有云的能力开始有一些诉求，整个业务就必须要从私有的数据中心，或者单一的云环境要向多元业务，或者说像混合云这方面去倾斜。

有些客户可能对公有云有特殊的要求，比如专属云，或者托管服务。整个基础设施这一层的构成，从深信服过去实施的大量项目中，得到一个很大的实践诉求，就是一定是要求稳定安全可靠和高性能的基础设施。

基于整个底层的架构之上，还会进一步引申出来一个对底层多集群多业务多租户的一个管理诉求。云管理平台(CMP)的主要职责就是体现多租户业务，包括计量计费、自服务体系、以及服务目录等一些建设。

深信服把所有的诉求做了一个中心化的具象，抽象开来说，第一个基础的服务模块叫资源池，是统一管理底层的虚拟化资源和多集群等，然后体现多租户能力，设置配额，发放资源等。

第二个是监控中心，即可以对业务进行端到端的检测和告警，收集相关日志，包括数据探测、性能探测等。另外一个是可靠性中心，即整个数据中心的可靠性的建设。做两方面去拆解，一个是在整个可视化上做了全面可视化的管理。第二个就是依赖底层虚拟化的技术，能够实现备份，容灾等能力。

另外一个就是多云，整个管理功能就是要给公有云和私有云提供一致性的操作体验。在整个资源池入口，发放一个虚机，它的资源池是可以选择私有云，也可以选择公有云进行发放。实际上对于传统的制造业来讲，会存在特别多的分支机构，而且很多是部署在多个地方，我们的超融合集群可以部署不同的地方，然后通过CMP平台统一管理起来。

还有一个能力中心是安全中心，以往整个传统IT建设是有安全边界的，并且借助一些具体的安全厂商的能力去做安全的区域防守或区域的这种保护。随着业务云化之后，上了虚机之后，实际上边界保护变得越来越模糊了，而且虚拟化的安全的防护会让客户会变得更加困难。

整个安全中心，借助安全产品和优势，集成虚拟化的能力，从虚拟化底层到整个安全资源池，包括整个安全服务体系的建设，为客户的整个安全等保业务打造了一个非常安全的体系。

基于安全中心之上，还有两大中心，一个是应用中心，随着现在越来越多的客户对云原生应用的场景诉求，包括容器、服务目录等，用户通过应用中心的视角，把企业固有的一些IT应用进行模板化和编排。在整个应用中心里，可以提供各种各样的服务目录，包括大数据服务，数据库RDS服务的一些应用，这是应用中心的构成。

最后一个是运营中心，就是把整个云体系的解决方案给到更多的企业和客户，实际上这个阶段会碰到一个问题，就是如何把云数据中心的能力往垂直行业，或者说往自己的渠道商输送。这需要一个运营体系去支撑，包括整个服务商的管理计量计费，VDC虚拟数据中心和运维体系的构成。

整个CMP的诉求实际上就是需要完成对广泛业务形成一个支撑，并且能够适应整体企业传统转型过程中业务架构的变化，从而能更好的支持上层传统数据库和新型应用。

二、深信服云体系架构介绍

实际上产品体系可以分为几大模块，最下面是资源池的诉求，通过自己的超融合架构acloud去交付整个虚拟化资源池的能力，然后基于acloud之上，形成AC MP的云管平台。

基于这个平台之上，为更大的客户和集团输出MSP运营商管理平台，它可以把云的能力变成行业的解决方案或垂直的解决方案，并且把这种能力很好的为其他客户或同行去进行输出。

整个运维平台和服务体系的打造，结合了公有云运维。在帮助企业客户运维的过程中，逐步形成了这样的一个运维平台，可以交付给客户。通过运维平台更好地实现对数据中心的管理，也可以通过运维平台帮助客户代运维和管理。

整个云的业务体系介绍完成之后，接下来我会分解一下支撑整个云业务体系的超融合架构和acmp的管理平台。过去在大型项目的实施过程中，都会有这样一个感受，就是必须要有一个统一标准的公共框架来支撑整个产品的引进过程。

随着并发项目的增多，整个开发团队能力的边界其实是参差不齐的，大家对规范的遵守，以及一些公共组件的使用，实际上也是不标准的。这样会导致整个产品体系和平台体系慢慢的进行腐化，腐化到一定过程就会导致必然要采取措施对这个架构要进行重构。

在重构的过程中，会整合客户的需求。实际上自己的开发速度也很慢，会拖累整个产品的迭代速度。举个列子，阿里云把电商的一些模型也进行了服务化的框架输出，包括在阿里云上类似EDAS的服务，把电商的基础服务框架进行产品化输出之后，可以很好地支撑同行企业的快速创新和产品开发。

想进行电商业务尝试的企业，可以很快把底层的基础架构构建起来。深信服也有这样的一个基础框架叫phoenix框架。实际它是由这几部分组成，底层框架，中间件和业务应用app，最底层都是要依赖一个体系的服务框架。

在开发队伍里面，采用多进程或协程的模式，或者是微服务这样一种形态，都是属于底层服务框架。服务框架实际上是作为底层的一个插座。基于服务框架之上，可能还会依赖很多中间件，包括扩展模块，比如说整个日志的处理。

配置的管理操作，还有整个国际化翻译，包括整体测试框架的遵守，实际上是整个中间件的组成。这些中间件经过一定的封装适配之后提供标准的公共接口，开发人员只需要遵守公共接口，后台整个中间件的能力建设，由整个后台的底层框架去保障的。

基于上面来做业务需求的转化，当开发人员或产品经理接到新的需求时，实际上有开发人员只是把业务需求转化成具体的一个业务应用，它并不关心底层实际应用是多进程还是多线程。

在整个体系架构向前引进的过程中，底层是用微服务架构，还是用容器去部署，作为APP来讲实际上是解耦的。也就相当于把开发人员的角色跟整个底层框架的角色进行区分，这样的话整个业务在开发和部署速度上都会加快起来。

三、超融合aCloud+aCMP架构设计

整个Phoenix基础框架的底层，实际上把通用服务能力，比如说外部响应的这种服务能力，一些周期任务，这种RPC还有日志公共的进行一层封装，基于这个框架上进行上层APP的开发，拿到phoenix基础框架的开发人员。

第一个命令可以很快创建一个项目，第二个是创建项目之后对整个服务进行开发。如果把这个框架拿去要做一个用户管理系统，可能有一个APP是用户账号，一个是认证APP，这些APP之间的内部可以通过RPC调用，也可以通过http调用。

对于超融合架构来讲，基于通用X86服务器上进行去中心化设计，整个主控节点是通过集群的通信去自动选举出来的，当发生网络或者服务器宕机的故障后，对整个主控节点会进行重新选取，这就是去中心化设计的架构原则。

而后台实现这种技术实际上用到了一个集群文件系统，它分布于每一个X86的节点上，对所有虚拟化资源的配置信息进行存放。无论哪个节点挂了，另外的节点会对这些配置数据的一些恢复，这是集群文件系统的一个技术采用，整个超融合架构，可以把计算网络存储安全融合于一体，然后支持提供给客户这样一个特别简单容易部署的架构。同时也可以进行计算和存储分离和混合部署。

整个超融合架构的基础，实际上就是最下面的计算存储网络的虚拟化，持续的会在整个底层的虚拟化平台上打造，为了满足客户稳定可靠安全高性能的诉求，会持续的打磨整个底层平台。

从存储网络计算上，可能会去对比一些友商，或者一些性能去进行测试，在更多的用户场景上，更好地保证整个应用的运行。aCMP架构对于云管平台来讲其实并不陌生，都是开源的。

我们对云管平台进行了重新的设计，其原因有以下几点：

第一点， 实际上，整个openstack随着社区化的运作和发展，其实整个体系已经非常庞大了，它的业务模块以及整个交互，整个业务流程变得相当的复杂。

第二点， 社区化的版本向前引进的过程跟产品化的整个配套过程是很难融合在一起的。作为产品来讲，我们必须要响应客户的定制化的需求，从而满足客户脱离整个社区以外的其他功能。

虽然整个架构的底层组件，比如说计算存储网络组件，实际上底层的代码风格，包括组织都千差万别。这样就会给整个开发团队带来许多问题，如何建立这样的过程以及维护。

所以基于此，我们对整个aCMP架构设计做了一些变动。对比较成熟的一些公共组件，比如说用户认证管理体系，数据采集等，会基于框架做相关扩展开发。

这是整个CMP体系，上层是一个适配层，适配层主要是去区分用户界面和后端模块化设计的适配。

后端的业务模块化划分之后，需要在上层进行数据的聚合，包括很好的用户体验，必然就会把多个模块的数据需要组装在一起。比如在虚拟机列表里面，它可能同时需要计算模块的虚拟机信息，同时又需要告警模块或监控模块。

那这些数据需要单个模块去调试接口，从产生这样的一些数据，最终提供给客户，需要很久的响应时间。由此可见，这种体验是非常差劲的。在此我们用了一个适配层，但是整个aCMP设计架构的亮点，就是采用了portal-api和数据查找库libselect打造的。

为了更好地满足用户体验，包括整个界面的响应请求。我们用了一个缓存层，实际上是快速地把后台各个模块的数据进行一个聚合，融合之后能够呈现在这个界面上，使其用户访问数据的时候，不需要按照传统已有的模块分别查询数据。

但是引入缓存层之后，会面临一个问题。对于整个实时数据的请求，比如说我在上层创了一个虚机之后，如何能够快速地把下面创建的虚机信息刷到访谈层里面，其实这里面涉及了一个reflesh机制，是对它的整个用户请求的读与写进行了分离。

在写请求完成之后，会自动带入已同步的数据刷新到缓存，这是一个数据同步和一致性设计。

整个CMP对于多云的或者第三方云的托管，实际上都有一个最大的困难，就是公有云的各个厂商，它的整个接口形式，包括数据模型千差万别。在混合云管理平台里，我们用了多云模板，并将其能力进行抽象。最后统一把整个云能力拉管起来，提供这种一致性的操作。

四 、数据中心可靠性能力建设

可靠性中心，实际上分为两个版块。第一块就是可视，能够从整个硬件资源，包括平台的服务，CPU，或者网口和数据的容灾备份，进行统一的全局可视化服务。

这样针对传统企业来说，或者IT运维能力相对比较差的客户。在整个可视化的过程当中，可以快速地发现整个平台存在的问题。这个能力就是可视化的一个能力输出。

第二块就是对于整个数据的容灾，传统的数据库首先建立容灾和备份的机制，然后是生产的节点和恢复节点，它们之间可以通过底层虚拟化的数据进行实时的备份同步。当虚机数据受损时，可以从本地的备份进行恢复，也可以在恢复站点里面，通过恢复中心同步回来。

对于不同保护组的应用，进行这种保护策略，来设置它的RPO和RTO。然后对本地的备份和实时的云端进行容灾，然后看到整个业务保护组策略，一个全局关联关系。

五、数据中心安全能力建设

整个可靠性的能力打造之后，实际上在面向更多的客户输出，包括目前来讲对于整个云平台的安全治理的产出规范之后，借助于安全厂商的这些优势，在整个云平台上做了很多关于安全体系架构设计的内容。

作为在CMP上的独立安全中心，能够实现整个云平台的安全策略体系。在平台层提供了一个虚拟化安全，在网络整块虚拟化安全上一系列安全防护，使得在整个虚拟化平台层能够帮助客户减少很多的安全配置。

安全的运维会把整个安全体系和安全能力，作为一个安全资源池来统一编排。或者通过安全组件化，在整个超融合架构里面，帮助客户能够在安全能力建设上达到安全担保和行业行规的标准。

安全服务体系可以通过安全服务化的能力，帮助客户在云平台建设过程中达到安全的指标，包括整个安全事故或安全保障，基于所有底层的虚拟化安全和安全配置，包括整个安全资源池。

在上面有一个全局的SIP(态势感知平台)，它可以实现对于整个平台的统一监测，包括数据分析，借助大数据和AI的后台，进行一些训练和学习，可以实时地把整个病毒库和所有的安全体系，能够在整个态势感知平台里进行一个展示。最终达到一个可视可控的平台，从而灵动地响应整个安全事件。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31545813/viewspace-2219845/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31545813/viewspace-2219845/