私有PaaS在乐视的实践

向您推荐

Dcoker入门与实践系列文章

背景及发展历程

PaaS在云平台中的作用 * 打通接入层、应用层、服务层 * 承载了云平台95%以上的业务

PaaS发展历程：阶段一

问题:

• 团队刚起步，基础设施一穷二白
• 典型的一体式应用，所有的逻辑放在一个大的JAR 包里
• 上线频繁，仅有的一个运维被折磨

部署自动化,业务标准化,混合部署de实现方案

• 中控脚本
• docker

PaaS发展历程：阶段二

问题：

• 机器挂了要人工重新部署
• 容器挂了要重新部署
• 资源无法合理分配
• 业务之间互相影响

故障迁移,资源调度,资源限制实现方案：

• Mesos + marathon + docker

PaaS发展历程：阶段三

问题：

• 业务逐步复杂化； 一个业务由多个服务组成
• 多个业务实现了重复的功能，需要抽出来成为独立服务
• 灰度发布、集中配置等新需求
• 业务人员不知道需要多少资源；容器评估： 健康、 忙、闲？

方案：

• 支持灰度发布、配置集中化、微服务

PaaS平台现状

• 全球5个 数据中心
• 400+ 服务器
• 3000+ 容器
• 150+ 业务

技术实现

核心组件

• zeus + ceberus： golang自主开发
• mesos： >= 0.23
• 尝试自己做 containerizer和executor
• 目前选择的是原生的docker-containerizer
• marathon： long-run 应用
• chronos： cron 应用
• docker： >= 1.0
• zookeeper
• nginx：七层负载均衡
• haproxy： 四层负载均衡

两种发布方式

基础镜像 + 应用代码

• 基础镜像包含支持业务代码运行的基础组件
• 应用代码由zeus进行打包并分发到不同的数据中心
• 不同业务可以共享相同的基础镜像
• 接近于业务开发的习惯，学习成本低，易于接受
• 代码源支持svn，git以及压缩包

纯镜像方式

• 业界常用的容器云部署方式
• 支持手动/自动触发编译镜像
• 通过全球镜像架构保证各个数据中心镜像一致

Project + App的组织方式

• App是部署的最小单位
• 用Project来聚合一组逻辑上相关的App

多种App类型

• WEB： 暴露HTTP端口
• Cron： 周期性任务
• Task： 一次性任务
• Worker： 通常不对外暴露端口
• Service： 微服务；暴露TCP端口

接入层负载均衡

• 七层负载均衡： nginx
• Nginx上部署agent，接受规则变更通知
• 规则加载：
• 早期：Nginx reload 实现规则加载
• 现在： 自定义 lua 模块，实现规则平滑加载
• 支持nginx自定义配置

Metrics collect

• 目的：
• 及时报警
• 容器资源使用图表
• 为容器评估及扩容/缩容提供依据
• metrics
• 容器：
• 内存、CPU、网络I/O
• 在容器外采集，更优雅
• 前端nginx：
• 请求数
• 请求处理时间
• 5xx个数

灰度发布

• 分流点
• 接入层
• 分流方案
• Nginx + LUA模块 + redis策略库
• 分流依据
• 设备型号
• IP地址
• 区域
• 流量百分比
• Cookie

微服务探索

为什么要微服务

• 业务逐步复杂化，从开发效率、易维护性、性能等角度考虑，需要将功能拆解，形成独立的服务
• 多个业务可能都实现了相同的功能，需要提取出来形成公共的服务

微服务架构的实现

两种微服务形式

• 同步类微服务： 基于RPC直接通信
• 异步类微服务： 基于MQ

轻量级微服务框架

• 基于thrift RPC框架改造，支持多语言
• 修改thrift，支持调用链trace

服务注册中心

• 目前支持 etcd
• 下一步支持 consul

服务发现与负载均衡

• 目前支持Smart client（性能更好）
• 下一步支持Load balancer

遇到的问题解决办法

• 故障诊断： 由研发人员登录机器， docker enter 进入
• 迁移后的日志保留
• 日常开发： 开发人员按自己习惯在本地开发
• 镜像制作：

待完善功能

• 镜像仓库&镜像管理
• WEB控制台
• 集群自动化管理
• 过载保护
• 自动伸缩
• 服务降级

参考

• CCTC-2016大会
• 演讲者：陈轶飞
• 此文为演讲者在CCTC-2016公开发布内容，如有版权请联系我:字母哥博客