向您推荐
欢迎加入QQ技术交流群：300139299
背景及发展历程
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公开发布内容，如有版权请联系我:字母哥博客
向您推荐
欢迎加入QQ技术交流群：300139299
