DockOne微信分享(九十八):Insta360容器化&DevOps之路

  • 时间:
  • 浏览:0

数据中心
该每种的数据为数据库存储的数据:

原文发布时间为:2016-12-10

Kafka在内存占用上,大大超出RabbitMQ,单机部署RabbitMQ,当Queue数量达到1W左右则刚开始英语 英语 突然经常出现无法继续出理 的情况,同配置机器安装Kafka,测试期间100W左右任务,内存情况依然完好。

配置服务
配置服务觉得是简单的Redis主从,主要功能是维护这些配置信息,如服务的IP地址(实测结果中,海外各类运营商DNS解析有严重间题图片,故而放弃域名使用IP);服务的配置信息,如服务名称,前端服务请求数据结果变更等;使用Redis的原应 也是一样,也能自我维护情况的,尽量放弃人工干预,不可能 该每种占用资源较小,Master做持久化,Slave直接运行即可,使用Alpine镜像,仅仅10m左右。

测试组成员收到提示后,与开发确认测试要点后,可登录内部人员测试平台(使用Rancher搭建),挑选对应的应用测试,并反馈结果给产品&项目经理,通过则验收完成。

这里的版本参考了阿里云镜像服务的自动构建规则。

构建

构建服务目前我们我们我们我们我们我们我们我们我们我们 有总体富含三套:

以上内容根据2016年12月6日晚微信群分享内容分派。分享人苏依(杨贺强),高级前端工程师兼Web组技术负责人,专职前端技术选型与分派。就职于Insta3100(全球3100°全景相机(VR相机)全景领跑品牌,深圳岚锋创视网络科技有限公司)DockOne每周一定会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听搞笑的话题不可能 想分享搞笑的话题都要给我们我们我们我们我们我们我们我们我们我们 留言。

SSH/Fabric是我最初尝试的方案,因此都要进行这些列的开发,基本在实验阶段就被放弃;Ansible并非 强大,因此也依然不利用上述挑战的出理 ,主要间题图片如下:

  1. 配置繁琐
  2. 扩展性差(相对而言)
  3. 可靠性差(使用SSH依据 ,受网络影响大)
而Docker也因此在此时成为可选方案之一,其优势并非 :
  1. 灵活,将应用于系统容器化,不都要额外依赖
  2. 便捷,任意Linux发行版配置Docker Engine即可启动
  3. 开源&免费,开源/免费低成本,Linux内核驱动
  4. 轻量,仅需去掉 或减小镜像即可,在一台服务器上都要布署多个容器
  5. 环境一致性,镜像四种 即富含运行环境,出理 不可能 环境不一致带来的各种异常与风险

架构/容器化

第一代架构

  • SSH
  • Fabric/Ansible

用户访问域名后通过dns-load-balancer进行第一次负载,解析到CDN的不同CNAME,CDN判断请求类型:

  1. 资源 mp4/mp3/jpg/png返回客户端
  2. 请求转发到SLB,SLB通过加权轮训依据 进行二次负载
  3. 请求到达前端服务器(Node.js),通过内部人员Redis集区获取数据
  4. 数据指在则返回,不指在则请求数据中心并缓存,再返回客户端
  5. 作为CDN源站,通过Nginx/HAProxy反向代理OSS,走阿里云内网对外提供媒体资源
数据存储
我司业务目前分为两类:

本文来自云栖社区企业协作伙伴Dockerone.io,了解相关信息都要关注Dockerone.io。

我司目前对用户开放的业务为主要富含以下三块:

  1. 视频图片分享(2C)
  2. 全景 / VR直播(2B)
  3. 新闻媒体企业协作(2B)
其中视频图像分享针对C端用户,用户遍布全球,要求各地用户都也能方便快速分享,一块儿也要求较好的浏览体验,不可能 点对点分享的内部人员,该每种流量正常情况我越多 越来越多;因此新闻媒体又扮演了特殊角色,同类11月25日,不可能 凤凰网首页嵌入我司分享页,从8:00至9:100期间,持续一小时多的(n)Gbps流量&以及每秒(n)K请求数几乎扮演了DDoS身份,瞬间拖垮后端统计服务器,原应 普通用户完整无法访问。同理,全景 / VR直播目前觉得为测试功能,但仍指在潜在风险。故而要求我司也能建立快速的相应机制,以及可用入党入党积极分子方案。

挑战

面临的挑战简单罗列如下:

  • Dockerfile
  • src放置项目代码
  • root存放Docker配置信息,覆盖容器内部人员系统配置
代码提交
  • 分支/Branch

    • dev 开发分支,构建开发镜像(本地构建测试)
    • test 测试分支,用于构建线上测试镜像
    • master 主分支,构建latest镜像
  • 版本/tag 

    • 规则:release-v{version}.{month}.{date}.{order}
    • 示例:release-v5.12.05.02

第三代架构仍指在完善阶段,上图简单描述了我司一一4个多多region服务于应用的分布:

  • 杭州/美西

    • 前端服务
    • 数据存储
    • 镜像仓库
    • 图像出理 /视频转码 worker
    • 配置服务 redis slave

      • 服务IP地址
      • 服务域名信息
      • 服务配置信息
  • 香港

    • 数据中心(数据库)
    • 里边件(第三方服务)
    • 统计系统
    • 消息队列
    • 配置服务 redis master
前端服务
其中前端服务为主要为浏览服务,由CDN + SLB +(Node.js + Redis)组成:

  1. 使用阿里云VPC,内部人员使用Ansible管理服务器
  2. 通过Ansible运行Docker命令进行容器进行部署
  3. 后端服务&RabbitMQ,依然使用传统依据 部署

第三代架构

原文标题:DockOne微信分享(九十八):Insta3100容器化&DevOps之路

本文作者:苏依

  • Aliyun 镜像服务,自动构建,用于正式环境的镜像发布
  • CircleCi,自动构建与测试,用于GitHub项目的自动构建
  • DroneCI,用于内部人员构建,主要用于内网的自动构建与测试
构建成功后使用Webhooks推送到BearyChat通知Web组成员:

  • OSS 使用Aliyun OSS存储服务,存储媒体资源如视频与图片
  • Volume,使用阿里云ossfs搭建的Docker Volume,存放持久化数据
图像出理
视频出理 目前使用了阿里云MTS转码服务做普通视频视频转码,一块儿,不可能 行业特殊性,都要对全景视频和图像进行这些列出理 ,由Python + Celery + C配置的worker出理 ,该每种内容由香港数据中心的RabbitMQ进行统一管理,消息到达RabbitMQ后自动进行分派,由空闲的worker出理 并通过MQ返回结果(事先一定会尝试过HTTP依据 进行返回,但不可能 网络环境较为恶劣,不可能 突然经常出现HTTP请求无法达到,自行出理 错误逻辑较为麻烦,因而使用MQ,设置一定过期时间,不可能 无法获取结果,则重新发送任务),当前架构的优化版本MQ不可能 由Kafka代替。

刀耕火种的SSH方案与Docker实验阶段,目前不可能 全面弃用。

第二代架构

  1. Aliyun RDS (事先业务量增加后都要考虑过渡到DRDS)
  2. Aliyun Mongodb
任务队列/消息队列
  • RabbitMQ
  • ZooKeeper 集群
  • Kafka(目前单机,存储使用ossfs)

Hook接口出理 会返回:

  • 时间
  • 名称
  • 版本
  • 命名空间
  • 镜像全名

测试

Hook服务收到信息后,根据tag判断应该发送到BearyChat的何种分组:

  • 集群化部署
  • 差异化部署
  • 全球化部署
  • 环境差异大
  • 资源利用率低
  • 项目数量&语言增加
具体到各个内容四种 ,首先我们我们我们我们我们我们我们我们我们我们 都要前端服务器在各个region集群化部署,分摊访问压力,一块儿集群内在这些情况下都要一块儿提供线上测试环境(不同于常规的测试环境,是完整等同于正式环境的测试版),从而都要差异化部署能力支持。其次,不可能 我司全球化战略,业务不光要考虑国内用户,一块儿也要为海外用户提供一致的体验,故而要求全球化部署。环境差异大,是指采用前后端分离的依据 进行开发后,前端及Web服务富含Redis+Node.js环境,后端一块儿指在PHP + Java + Python + C等,传统依据 部署不可能 无法满足快速响应的需求,采用Ansible觉得也能满足需求,但配置繁琐,故而也被放弃。一块儿,考虑业务的拓展性,单机部署上述各种环境时,都要预留一定资源作储备,出理 突发情况;即使采用镜像的依据 对当前环境进行打包,在遇到突发情况时,还原依然都要较长时间,响应传输速度太慢;综合前几点考虑,采用了保证稳定性与可用性,降低资源利用率低的依据 。最后不得不说的是,从最初的好多个项目到如今的几六个项目(日常更新10~20),不可能 继续按照以往的依据 ,则只能专人专职负责部署业务。对于一家创业公司来说,将更多的精力用于开发新功能与为用户提供更优体验,显然更为重要。综上所述,所有间题图片一定会求我们我们我们我们我们我们我们我们我们我们 转变原始的CI/CD依据 ,采用四种 更加轻量,更加简单的方案势在必行

方案

  • SSH/Fabric
  • Ansible
  • Docker