当前位置:首页 > 运维干货

从无到有:熊猫直播 Rancho 发布系统构建之路从无到有:熊猫直播 Rancho 发布系统构建之路

e8yw

  随着熊猫直播的业务发展越来越快,业务需求的迭代和版本更新需求越来越多,对开发和运维面临以下4个痛点:

  项目需求上线越来越多。

  发布周期比较长,需要人工操作比较繁琐。

  发布项目效率和风险的问题,比如平滑发布,切换负载均衡。

  发布过程没有详细的审计功能。

  由此,团队内部决定在现有的发布过程上实现开发统一的发布系统平台,实现熊猫直播的运维发布流程化、标准化、自动化为一体的统一发布要求,下面围绕整个 Rancho 发布系统做总结梳理,总共分为9个方面:

  实现的最终目的

  用户登陆(发布系统的第一道安全墙)

  用户权限(发布系统的第二道安全墙)

  项目权限(发布系统的第三道安全墙)

  代码发布前台

  代码发布后台

  发布过程/结果

  标准的 wiki 文档建立

  小结

  Rancho 发布系统流程概述架构图:

  Rancho 发布系统流程完整架构图:

  一、实现的最终目的

  随着熊猫直播业务的迅猛发展,项目、产品的需求规模和版本迭代频次是无法预估的。传统的运维支持方式已渐渐无法满足这种工程应用现状。但是如果把发布权利交付到开发人员手里控制,运维安全是比较大的隐患。当2者都无法平衡的时候,利用高效的标准化,自动化体系将2个无法逾越的问题优化结合起来,我们结合了上述问题,实现了内部的发布系统,对于发布系统,实现了2个核心目标,如下:

  发布项目统一接入

  在新项目接入平台的第一次起,运维只需要把项目添加上,给对应的开发开放相对应的发布权限,项目接入+权限都是正常状态下,运维需要做的事情就完成了。

  一键自动发布

  开发可以根据自己所拥有的项目发布权限,进行任何时间段的发布,同时发布系统会对用户,发布项目,发布操作,结果做到全方位的记录。

  总结:让研发自助运维。

  二、用户登陆(发布系统的第一道安全墙)

  对于发布系统的登陆,我们结合了内部开发的一套 SSO 系统+Rancho 系统并加了一层白名单策略,有以下3个方面考虑:

  安全性:

  平台登陆安全性,SSO 采用统一认证+MD5 算法+Hash算法+静态系统唯一标识。

  连接:

  统一的 Session/Cookie 允许连接,保持会话,过期,删除由SSO管理。

  双权验证:

  假如用户在 SSO 可以正常登陆,但是在 Rancho 发布平台没有登陆权限,就是禁止登陆。原因很简单,因为全公司每个人都拥有自己的统一登陆账户,防止有人试探登陆/误操作登陆。

  三、 用户权限(发布系统的第二道安全墙)

  用户权限,我们分为2类角色:

  管理员:

  具有发布系统超级权限,可以对所有项目/用户进行操作。

  普通用户:

  只能看到运维授权的项目,发布,发布详情,查看发布历史,查询,但是不可编辑,更新项目。

  四、项目权限(发布系统的第三道安全墙)

  项目权限设计,我们当时也花很多时间去讨论,最终拟定方案,项目不首先对应用户,而是在用户和项目中间建立一个桥梁,我们命名为项目组。

  原因:当多个用户同时去拥有一个项目权限的时候,这个时候要全部用户都要增加到这个项目体系中去。

  如果这样做的问题是:增加繁琐,当项目删除改用户权限/或者用户不再拥有该项目权限,还要精确的删除,否则删除错了,后果很严重,逻辑同时还要对用户和项目,做双层处理操作。

  解决方案:

  用户—-项目组——项目

  方案优点:

  项目组方便了运维管理,如果没有项目组,一个项目对应的权限用户比较多的话,需要管理员分别的去增加/更新编辑比较繁琐。

  系统根据项目组有效控制不同用户之间对应项目的权限隔离发布。

  项目组图例:

  五、代码发布前台

  前台用于开发人员进行发布所操作的页面,其中功能包含:

  发布页面

  发布tag种类选择

  发布环境/机器列表选择

  当用户进来某个项目的时候,Rancho 发布系统会同时异步获取该项目所有的环境/主机列表,对用户而言无需任何操作处理。

  ①. 发布页面支持机器单选,多选,全选,临时主机添加等:

  ②. 发布tag种类发布 tag 种类选择如下:

  开发tag(可测试)

  线上tag(灰度/线上)

  其他tag(代表开发/线上 tag 未显示你要发布的 tag,发布人员可以根据 tag号输入,如果 git 库里存在,可以正常发布,如果不存在,用户也可以接收到对应的错误结果)

  线上/开发tag,Rancho 发布系统会自动实时更新git库前10个最新的tag,供用户选择。

  ③. tag 版本选择页面如下:

  ④. tag 比对图用户选择的 tag 和主干,和最后一次发布 tag 比对如下:

  ⑤. 发布环境/机器列表选择:对于发布环境我们有自己的一套命名扩展规则,有3种类型:

  类型一:根据项目功能服务来命名

  类型二:根据发布环境来命名

  类型三:前2者整合

  比如某个项目命名情况:

  项目功能服务拆分,包含:crontab,sdk,console,front等,

  项目发布环境拆分,包含:online,beta,gray等

  独立情况/整合情况,如下说明:

  beta环境可以独立的命名

  beta环境有sdk服务,命名为:sdk_beta

  beta环境有console,命名为:beta_console

  PS:环境命名,细化,拆解,开发人员根据项目功能类型,自定义,

  Rancho自动识别和拆解命名体系。

  每个发布环境对应发布的机器,其中一个项目页面如下展示:

  ⑥. 前台首页图用户登陆进来看到的所拥有项目的页面,功能有发布,查看,发布历史,需说明(只有管理员才有展示启用/禁用权限)

  启用:代表这个项目是正常运行发布

  禁用:可以看作删除,但是我们不作为真正删除,临时迁入回收站,如果哪天这个项目需要启用发布了,我们再打开进行该项目发布。

  ⑦. 前台发布确认清单发布前让发布用户再次确认上线的项目,tag,发布环境,是否重启,机器(现有的和临时添加的主机):

  ⑧. 发布清单提交请求避免脏数据的方法:

  程序监控对发布队列是否正常服务检测,并且自动做干预。

  程序监控对数据库/缓存正常服务检测,并且自动做干预。

  程序监控对生成的task_ID是否存在,并且自动做干预。

  程序监控对生成的发布指令做严格的判断,是否为不正确指令,并且自动做出干预。

  六、代码发布后台

  后台项目管理的成功/失败,对整个前台发布起到至关重要的。

  后台操作权限为管理员:一般是指定对应的运维人员。

  操作程度:简单、易用,所有处理逻辑都交给Rancho去搞定。

  ①. 后台操作新项目流程页面新建字段说明:

  名称:代表项目的主名称(唯一,如果重复则提示错误详情),别名:代表项目的描述,可以是中文/英文,名称可以重复。

  git clone url地址:

  开发提供,这个地址Rancho在处理的过程中,会对本身项目权限,该项目类型标识进行判断和提取,比如我们有2种功能发布:rigger和ansible,而发布语言有:golang,php,nodejs,python,lua,c++等多种混合语言,排名不分先后。

  项目组权限:

  添加该项目允许哪些项目组成员进行发布。

  备注:可写/可不写

  至此,运维管理员需要做的事情已经完成,剩下的点击提交,剩下的事情交给 Rancho 去处理了。

②. 后台新建页面

③. Rancho底层基本处理流程

④. 项目失败手动触发 Rancho 处理恢复流程

  七、发布过程/结果

  前期的工作:后台新建项目完成,到发布提交申请,最后查看发布过程/结果的验证。

  ①. 发布过程的处理流程概述和原理图例展示:描述,发布过程有3种场景负载均衡四/七层策略和无负载均衡策略/项目服务是否重启。针对以上3种场景,分别作了不同的处理规则:

  负载均衡场景:

  有白名单策略代表该项目拥有负载均衡策略(至于挂了多少负载均衡节点在发布的时候,Rancho 发布系统会自动的计算,并且做相对应的平滑策略切换).

  无负载均衡策略:

  走正常的发布流程。

  项目服务发布是否重启

  (Rancho 支持重启项目服务/支持不重启项目服务)需求描述:

  熊猫直播发布项目的时候,有2种情况:

  项目发布更新,但是不重启服务,看下项目代码发布过程是否成功/失败。(这点对于发布项目业务正常运行不会出现有损情况)

  项目发布更新,重启服务(项目发布代码完成,自动重启项目服务)

  发布速度:无负载均衡策略项目相对于比有LB策略的项目快2ms-30ms,根据项目绑定的LB有关联。

  ②. 项目发布锁图例展现发布锁作用:防止同项目同发布环境多任务一起发布,会有覆盖,冲突。

  ③. 项目发布历史统计图例展现状态:正在发布,触发失败,发布成功

④. 项目发布手工终止图例展现

⑤. 发布结果成功图例展现

  ⑥. 发布结果失败/终止图例展现失败单台,未执行的机器程序自动干预停止发布实例子

  ⑦. 发布过程中,手工可以终止发布功能,说明防止发布过程中有未知的原因或长时间缓慢/卡顿等,发布人员可以根据业务重要评估,进行降级发布过程停止操作,并且系统会把操作用户,时间,项目,降级操作等做详细记录)。

  正常发布完成后,终止发布按钮功能会自动消失.

  下面截图所示:

  ⑧. 项目回滚策略当某个项目发布失败或者异常,想回滚到上个正常版本,可以以对应的 tag 号来进行重新发布.

  ⑨. 发布结果日志截图展现(自动按天生成日志,并且按天做发布日志全量汇总)

  八、完善的Wiki文档建立

  Rancho 发布系统在熊猫直播循序渐进的优化功能/需求,bug修复等,wiki文档的规范化也要随之建立起来,以下是wiki文档建立的图例:

  九、小结

  Rancho 发布系统已经在线上运行了将近5个月的时间,目前 Rancho 系统功能包含了:

  项目建立

  用户登陆权限严格的隔离

  项目锁机制

  项目前台

  项目后台

  LB 4/7层和 Nginx upstream 白名单策略

  平滑摘取/绑定主机

  支持Rigger发布功能和Ansible发布功能

  多语言混合并行发布(Golang,PHP,Nodejs,C++,Lua,Python,Shell等,语言排名不分先后)

  异步实时处理发布任务

  实时可视化展现发布结果

  多环境发布

  跨多机房发布

  手工/自动干预终止发布

  避免严重的错误影响到正常业务

  详细的发布操作记录:用户操作,时间,发布环境,发布tag,发布主机成功次数统计,发布主机失败次数统计,发布主机程序自动干预终止次数统计,发布主机手工干预终止次数统计,发布主机正在发布中次数统计等。

  目前熊猫直播 Rancho 发布系统解决的痛点:

  研发自助运维:熊猫直播产品业务线的发布更新/回滚变更等操作,都由各自的项目线开发人员操作发布/回滚,运维不直接参与整个发布/回滚流程,遇到发布错误/异常,运维才介入和开发一起排查相关问题。

  发布时间周期长:目前发布系统异步处理整个发布流程,点击发布提交之后,页面关闭都可以,发布人员想看结果的时候,才登陆系统查看即可。

  平滑切换负载均衡:发布系统增加了白名单策略,发布项目上线前,Rancho发布系统会自动判断白名单策略项目,如果该项目存在白名单策略,Rancho发布系统会自动做整个负载均衡下线—上线—绑定上线流程操作。

  发布系统详细的审计功能:从用户登陆-创建发布清单-点击发布-发布过程-发布结果都做了详细的记录,记录纬度:登陆时间,发布起始时间,发布完成时间,用户,发布环境,发布项目(平滑,服务是否重启,tag,主机数量,主机信息清单),发布结果(成功,失败,终止)等。

  目前发布次数/项目总数统计: 2017年2月16日上线到目前,累计发布工单12000次,最多单次工单发布主机100台+,成功96%,失败3%,终止1%,接入发布项目将近100+。

  Rancho 发布系统未来优化的路还有很多,优化方向分为以下3点:

  接入发布预警平台:

  当某个项目出现异常的时候,运维能及时收到短信/邮件的提示。

  定时作业发布:

  可以按照用户自定义的发布时间,定时发布代码。

  发布错误/异常自动修复:

  目前Rancho发布系统,已经可以收集到全部错误发布类型,但是真正修复还需人工,以后当错误出现了,自动上报到修复库里进行存档,在下一次同样错误出现的时候,Rancho 自动修复,并优雅提示用户发布错误修复完成,请重新发布。

  随着熊猫直播的业务发展越来越快,业务需求的迭代和版本更新需求越来越多,对开发和运维面临以下4个痛点:

  项目需求上线越来越多。

  发布周期比较长,需要人工操作比较繁琐。

  发布项目效率和风险的问题,比如平滑发布,切换负载均衡。

  发布过程没有详细的审计功能。

  由此,团队内部决定在现有的发布过程上实现开发统一的发布系统平台,实现熊猫直播的运维发布流程化、标准化、自动化为一体的统一发布要求,下面围绕整个 Rancho 发布系统做总结梳理,总共分为9个方面:

  实现的最终目的

  用户登陆(发布系统的第一道安全墙)

  用户权限(发布系统的第二道安全墙)

  项目权限(发布系统的第三道安全墙)

  代码发布前台

  代码发布后台

  发布过程/结果

  标准的 wiki 文档建立

  小结

  Rancho 发布系统流程概述架构图:

  Rancho 发布系统流程完整架构图:

  一、实现的最终目的

  随着熊猫直播业务的迅猛发展,项目、产品的需求规模和版本迭代频次是无法预估的。传统的运维支持方式已渐渐无法满足这种工程应用现状。但是如果把发布权利交付到开发人员手里控制,运维安全是比较大的隐患。当2者都无法平衡的时候,利用高效的标准化,自动化体系将2个无法逾越的问题优化结合起来,我们结合了上述问题,实现了内部的发布系统,对于发布系统,实现了2个核心目标,如下:

  发布项目统一接入

  在新项目接入平台的第一次起,运维只需要把项目添加上,给对应的开发开放相对应的发布权限,项目接入+权限都是正常状态下,运维需要做的事情就完成了。

  一键自动发布

  开发可以根据自己所拥有的项目发布权限,进行任何时间段的发布,同时发布系统会对用户,发布项目,发布操作,结果做到全方位的记录。

  总结:让研发自助运维。

  二、用户登陆(发布系统的第一道安全墙)

  对于发布系统的登陆,我们结合了内部开发的一套 SSO 系统+Rancho 系统并加了一层白名单策略,有以下3个方面考虑:

  安全性:

  平台登陆安全性,SSO 采用统一认证+MD5 算法+Hash算法+静态系统唯一标识。

  连接:

  统一的 Session/Cookie 允许连接,保持会话,过期,删除由SSO管理。

  双权验证:

  假如用户在 SSO 可以正常登陆,但是在 Rancho 发布平台没有登陆权限,就是禁止登陆。原因很简单,因为全公司每个人都拥有自己的统一登陆账户,防止有人试探登陆/误操作登陆。

  三、 用户权限(发布系统的第二道安全墙)

  用户权限,我们分为2类角色:

  管理员:

  具有发布系统超级权限,可以对所有项目/用户进行操作。

  普通用户:

  只能看到运维授权的项目,发布,发布详情,查看发布历史,查询,但是不可编辑,更新项目。

  四、项目权限(发布系统的第三道安全墙)

  项目权限设计,我们当时也花很多时间去讨论,最终拟定方案,项目不首先对应用户,而是在用户和项目中间建立一个桥梁,我们命名为项目组。

  原因:当多个用户同时去拥有一个项目权限的时候,这个时候要全部用户都要增加到这个项目体系中去。

  如果这样做的问题是:增加繁琐,当项目删除改用户权限/或者用户不再拥有该项目权限,还要精确的删除,否则删除错了,后果很严重,逻辑同时还要对用户和项目,做双层处理操作。

  解决方案:

  用户—-项目组——项目

  方案优点:

  项目组方便了运维管理,如果没有项目组,一个项目对应的权限用户比较多的话,需要管理员分别的去增加/更新编辑比较繁琐。

  系统根据项目组有效控制不同用户之间对应项目的权限隔离发布。

  项目组图例:

  五、代码发布前台

  前台用于开发人员进行发布所操作的页面,其中功能包含:

  发布页面

  发布tag种类选择

  发布环境/机器列表选择

  当用户进来某个项目的时候,Rancho 发布系统会同时异步获取该项目所有的环境/主机列表,对用户而言无需任何操作处理。

  ①. 发布页面支持机器单选,多选,全选,临时主机添加等:

  ②. 发布tag种类发布 tag 种类选择如下:

  开发tag(可测试)

  线上tag(灰度/线上)

  其他tag(代表开发/线上 tag 未显示你要发布的 tag,发布人员可以根据 tag号输入,如果 git 库里存在,可以正常发布,如果不存在,用户也可以接收到对应的错误结果)

  线上/开发tag,Rancho 发布系统会自动实时更新git库前10个最新的tag,供用户选择。

  ③. tag 版本选择页面如下:

  ④. tag 比对图用户选择的 tag 和主干,和最后一次发布 tag 比对如下:

  ⑤. 发布环境/机器列表选择:对于发布环境我们有自己的一套命名扩展规则,有3种类型:

  类型一:根据项目功能服务来命名

  类型二:根据发布环境来命名

  类型三:前2者整合

  比如某个项目命名情况:

  项目功能服务拆分,包含:crontab,sdk,console,front等,

  项目发布环境拆分,包含:online,beta,gray等

  独立情况/整合情况,如下说明:

  beta环境可以独立的命名

  beta环境有sdk服务,命名为:sdk_beta

  beta环境有console,命名为:beta_console

  PS:环境命名,细化,拆解,开发人员根据项目功能类型,自定义,

  Rancho自动识别和拆解命名体系。

  每个发布环境对应发布的机器,其中一个项目页面如下展示:

  ⑥. 前台首页图用户登陆进来看到的所拥有项目的页面,功能有发布,查看,发布历史,需说明(只有管理员才有展示启用/禁用权限)

  启用:代表这个项目是正常运行发布

  禁用:可以看作删除,但是我们不作为真正删除,临时迁入回收站,如果哪天这个项目需要启用发布了,我们再打开进行该项目发布。

  ⑦. 前台发布确认清单发布前让发布用户再次确认上线的项目,tag,发布环境,是否重启,机器(现有的和临时添加的主机):

  ⑧. 发布清单提交请求避免脏数据的方法:

  程序监控对发布队列是否正常服务检测,并且自动做干预。

  程序监控对数据库/缓存正常服务检测,并且自动做干预。

  程序监控对生成的task_ID是否存在,并且自动做干预。

  程序监控对生成的发布指令做严格的判断,是否为不正确指令,并且自动做出干预。

  六、代码发布后台

  后台项目管理的成功/失败,对整个前台发布起到至关重要的。

  后台操作权限为管理员:一般是指定对应的运维人员。

  操作程度:简单、易用,所有处理逻辑都交给Rancho去搞定。

  ①. 后台操作新项目流程页面新建字段说明:

  名称:代表项目的主名称(唯一,如果重复则提示错误详情),别名:代表项目的描述,可以是中文/英文,名称可以重复。

  git clone url地址:

  开发提供,这个地址Rancho在处理的过程中,会对本身项目权限,该项目类型标识进行判断和提取,比如我们有2种功能发布:rigger和ansible,而发布语言有:golang,php,nodejs,python,lua,c++等多种混合语言,排名不分先后。

  项目组权限:

  添加该项目允许哪些项目组成员进行发布。

  备注:可写/可不写

  至此,运维管理员需要做的事情已经完成,剩下的点击提交,剩下的事情交给 Rancho 去处理了。

②. 后台新建页面

③. Rancho底层基本处理流程

④. 项目失败手动触发 Rancho 处理恢复流程

  七、发布过程/结果

  前期的工作:后台新建项目完成,到发布提交申请,最后查看发布过程/结果的验证。

  ①. 发布过程的处理流程概述和原理图例展示:描述,发布过程有3种场景负载均衡四/七层策略和无负载均衡策略/项目服务是否重启。针对以上3种场景,分别作了不同的处理规则:

  负载均衡场景:

  有白名单策略代表该项目拥有负载均衡策略(至于挂了多少负载均衡节点在发布的时候,Rancho 发布系统会自动的计算,并且做相对应的平滑策略切换).

  无负载均衡策略:

  走正常的发布流程。

  项目服务发布是否重启

  (Rancho 支持重启项目服务/支持不重启项目服务)需求描述:

  熊猫直播发布项目的时候,有2种情况:

  项目发布更新,但是不重启服务,看下项目代码发布过程是否成功/失败。(这点对于发布项目业务正常运行不会出现有损情况)

  项目发布更新,重启服务(项目发布代码完成,自动重启项目服务)

  发布速度:无负载均衡策略项目相对于比有LB策略的项目快2ms-30ms,根据项目绑定的LB有关联。

  ②. 项目发布锁图例展现发布锁作用:防止同项目同发布环境多任务一起发布,会有覆盖,冲突。

  ③. 项目发布历史统计图例展现状态:正在发布,触发失败,发布成功

④. 项目发布手工终止图例展现

⑤. 发布结果成功图例展现

  ⑥. 发布结果失败/终止图例展现失败单台,未执行的机器程序自动干预停止发布实例子

  ⑦. 发布过程中,手工可以终止发布功能,说明防止发布过程中有未知的原因或长时间缓慢/卡顿等,发布人员可以根据业务重要评估,进行降级发布过程停止操作,并且系统会把操作用户,时间,项目,降级操作等做详细记录)。

  正常发布完成后,终止发布按钮功能会自动消失.

  下面截图所示:

  ⑧. 项目回滚策略当某个项目发布失败或者异常,想回滚到上个正常版本,可以以对应的 tag 号来进行重新发布.

  ⑨. 发布结果日志截图展现(自动按天生成日志,并且按天做发布日志全量汇总)

  八、完善的Wiki文档建立

  Rancho 发布系统在熊猫直播循序渐进的优化功能/需求,bug修复等,wiki文档的规范化也要随之建立起来,以下是wiki文档建立的图例:

  九、小结

  Rancho 发布系统已经在线上运行了将近5个月的时间,目前 Rancho 系统功能包含了:

  项目建立

  用户登陆权限严格的隔离

  项目锁机制

  项目前台

  项目后台

  LB 4/7层和 Nginx upstream 白名单策略

  平滑摘取/绑定主机

  支持Rigger发布功能和Ansible发布功能

  多语言混合并行发布(Golang,PHP,Nodejs,C++,Lua,Python,Shell等,语言排名不分先后)

  异步实时处理发布任务

  实时可视化展现发布结果

  多环境发布

  跨多机房发布

  手工/自动干预终止发布

  避免严重的错误影响到正常业务

  详细的发布操作记录:用户操作,时间,发布环境,发布tag,发布主机成功次数统计,发布主机失败次数统计,发布主机程序自动干预终止次数统计,发布主机手工干预终止次数统计,发布主机正在发布中次数统计等。

  目前熊猫直播 Rancho 发布系统解决的痛点:

  研发自助运维:熊猫直播产品业务线的发布更新/回滚变更等操作,都由各自的项目线开发人员操作发布/回滚,运维不直接参与整个发布/回滚流程,遇到发布错误/异常,运维才介入和开发一起排查相关问题。

  发布时间周期长:目前发布系统异步处理整个发布流程,点击发布提交之后,页面关闭都可以,发布人员想看结果的时候,才登陆系统查看即可。

  平滑切换负载均衡:发布系统增加了白名单策略,发布项目上线前,Rancho发布系统会自动判断白名单策略项目,如果该项目存在白名单策略,Rancho发布系统会自动做整个负载均衡下线—上线—绑定上线流程操作。

  发布系统详细的审计功能:从用户登陆-创建发布清单-点击发布-发布过程-发布结果都做了详细的记录,记录纬度:登陆时间,发布起始时间,发布完成时间,用户,发布环境,发布项目(平滑,服务是否重启,tag,主机数量,主机信息清单),发布结果(成功,失败,终止)等。

  目前发布次数/项目总数统计: 2017年2月16日上线到目前,累计发布工单12000次,最多单次工单发布主机100台+,成功96%,失败3%,终止1%,接入发布项目将近100+。

  Rancho 发布系统未来优化的路还有很多,优化方向分为以下3点:

  接入发布预警平台:

  当某个项目出现异常的时候,运维能及时收到短信/邮件的提示。

  定时作业发布:

  可以按照用户自定义的发布时间,定时发布代码。

  发布错误/异常自动修复:

  目前Rancho发布系统,已经可以收集到全部错误发布类型,但是真正修复还需人工,以后当错误出现了,自动上报到修复库里进行存档,在下一次同样错误出现的时候,Rancho 自动修复,并优雅提示用户发布错误修复完成,请重新发布。


分享到: