向您推荐
欢迎加入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