白鹿 ai换脸 虚构化云管奇迹奥创的优化升级以及多集群下VPC汇注终了

配景先容白鹿 ai换脸

奥创(Ultron)是360里面虚构化功能的云管奇迹， 通过封装虚构化关系功能， 调治对外提供虚构化openstack关系api等奇迹， 不错暴露为openstack集群的一个调治网关奇迹，对内相沿平台HULK等平台，提供云磋磨关系功能。面前虚构化提供的包括云主机，云硬盘，云汇注，安全组，裸金属，负载平衡等功能均由奥创调治对外提供奇迹。然则跟着功能的不断丰富、用户数目的增多，同期对极致的追求，诸多问题逐步暴漏出来，对集群的性能、雄厚性、珍藏性等各方面提议了新的挑战。

历史版块 v1

由标题简略看出奥创是存在一个历史版块的，暂且叫v1 版块。v1 的奇迹以及组件如下:

在建设运维进程中，际遇的关系问题：

抓久化存储数据库使用了mongodb，mongodb本人为NOSQL，而非关系型数据库，在关联查询以及事务以及珍藏性等方面王人不友好。

引入celery酿成架构复杂，celery比较重，同期celery的任务使用多程度口头，资源销耗较大，无意有些不雄厚。

redis 中hash了好多对于openstack集群的树立信息，愚弄hash作念了好多关系型数据库所擅长的。

奥创集群不支抓水平延长，在openstack集群较多虚机较多时酿成同步任务很慢以至梗阻

....... 其他原因

濒临新的挑战

跟着公司内云磋磨提供的功能越来越多，对性能等各条目也不断升迁，濒临如下关系的挑战:

虚构化集群变多， 面前公司内有 40+套虚构化集群，且羼杂多个版块的openstack集群。

虚构化功能不断增多， 由往日仅有的云主机功能 安逸支抓云硬盘，VPC汇注，安全组，裸金属，负载平衡等

虚构机数目以及磋磨节点数目增多， 面前已有 3W+ 的虚构机，5k台磋磨节点。

虚构机创建性能的条目，往日可能莫得那么大并发，当今居品支抓了可霸占，需要支抓单次并发100台创建，而且要在1分钟内创建完

居品对标公有云，业务场景愈加复杂，功能更丰富。

新版块 v2

矫正后新版块v2 基于go说念话建设，go自然的并发上风，让架构更约略性能更好。同期将奥创组件拆分为api和conductor 变装，api只认真处理client的申请，申请校验完后将任务发到音书部队 redis ，conductor从音书部队中获得到任务后进行处理，变装之间职责清醒，同期数据库改为使用mysql，因为包括虚机，云盘，汇注等存在很强的关联关系，一台虚机势必关联汇注，安全组等，是以使用关系型数据库愈加合适。Redis在集群中领先担任音书部队的变装，同期用于散播式锁以及数据缓存的使用。

具体奇迹以及组件如下:

架构图如下：

优化内容

如下陈设作念的一些矫正点

矫正1 - 集群支抓水平延长

从性能商量将奥创奇迹拆分为两个变装，api和conductor，api 认真袭取处理http 申请，conductor认真消费任务，conductor认真与openstack以及公司内其他平台的交互责任。api和conductor之间变装清醒，通过音书部队解耦，两个组件王人支抓水平延长，当有大批数据需要处理时不错商量水平延长。因为api 只处理HTTP申请，通过负载平衡当然不错终了水平延长应答并发申请。conductor侧任务分为在线任务和离线任务，在线任务是用户申请的任务，离线任务是比如包括和openstack集群同步，以及数据分析等。conductor通过监听redis音书部队，在大批任务处理时不错商量水平延长应答。同期在处理离线任务时，通过将conductor进行分组，不同组处理不同openstack集群或者idc的任务，从而不错支抓api和conductor的水平拓展。

矫正2 - 汲取模块化单体遐想

传统单体应用的危害各人王人很明晰，出故障时犹如雪崩。由于奥创只奇迹公司里面莫得那么大的量级，情色同期微奇迹自身架构复杂，依赖kubernetes，珍藏资本较高，是以从雄厚性以及运维方面汲取了模块化单体遐想，通过docker-compose进行平素处置。

模块化单体架构的优点如下：

约略性 : 将应用奇迹按照功能拆分为多个小模块，比拟较微奇迹雄壮的架构而言，更易于暴露和珍藏。

可珍藏性: 每个模块有我方的职责和功能，界限清醒，不错升迁应用局势的可珍藏性。

可拓展性：每个模块只认真单独的功能，是以更容易拓展相应的功能。

勾引

将奥创的api以及conductor按照不同的功能比如云主机，安全组，汇注等功能拆分为不同的单体应用。

矫正3 - 引入trace id到日记中

跟着api和conductor变装的加入，同期又拆分了模块化单体，组件的容器会变多，如果需要查询某时刻某工单的日记犹如大海捞针。通过引入trace id 将每次具体的申请象征一个独一id，在扫数这个词任务处理的链路中，通过context 高下文传递到不同组件，每个组件的日记王人象征该trace id，这么通过trace id就不错在系统中将扫数这个词调用旅途串联起来。

矫正4 - 奥翻新vpc的终了

vpc汇聚合构：

创建vpc分两步走：

1.当今某个区域，比如北京区创建一个vpc汇注，这一步不会骨子性的创建出汇注实例，仅仅仅一个记载暗示也曾筹算出一个网段空间了。因此不作念小心阐扬

2.主若是第二步，创建vpc子网：

网段处置：

vpc的网段调治由hulk处置，字据具体用途和部门把11.0.0.0/8分别为多个掩码为/20的段，这亦然每一个vpc的大小，一共包含4096个地址。

一个子网的地址范围是/22的段，包含1024个IP地址，是以一个vpc不错包含4个子网。每个子网王人是在IDC内的，然则由于有的idc有多个openstack集群（一个openstack集群一个region），因此如果需要一个子网在扫数可用区王人能创建出虚机，就需要每个可用区王人有该子网的网段。

由于咱们面前一个IDC 下最多的有五个openstack 集群，为了王人能粉饰到，咱们把一个子网的/22的段分别为最多8个/25的小段。现时的分别原则：最大一个c，最少128个IP。

IP不及的补充问题：

多可用区的IP网段存在一个一样内存碎屑的问题。

假如region3的磋磨资源比较饱和，虚机创建就会一直选中region3，region3的IP很快就用罢了，这种时候即使1，2，4仍然有好多剩余IP，因为region3也曾没了，是以扫数这个词子网看上去也莫得了

对于连散漫网段也莫得了的情况：

原遐想：附加网段

当今的有谋划：链接创建新的子网，新子网的网段链接被切分以后平中分给扫数集群，哪怕有的集群践诺上根底莫得资源创建新的虚机。

优化有谋划：不错在保证扫数集群王人有符合数目的IP地址的情况下，把新增的子网创建到指定的阿谁集群下，减少IP地址的挥霍

瞻望回归:

本次奥创的升级优化主要从功能，性能以及后期的运维复杂度，雄厚性等方面商量，不仅要在建设遐想上更逼近openstack居品，同期又要有简略应答后期openstack集群领域扩大的应答智力，同期还要尽量的简略缩小运维复杂度，苟简后期运维。面前奥创v2也曾雄厚奇迹公司里面HULK等平台，总体从在线离线任务处理时间等性能方面以及运维易用性等方面来看阐扬出色，虽然本次升级优化并不代表该架构以及遐想等于最优的，后期仍会不断优化矫正。

更多360前沿技巧共享，敬请搜索“360智汇云”白鹿 ai换脸，更多好文等着你！