Mico的架构之旅 魏佳 Co-Founder & CTO @ Mico Inc..

Slides:



Advertisements
Similar presentations
AWS 公有云服务. Amazon Web Service 简介 AWS 是向最终用户交付计算资源、保存数据和其他应用程序的一种最经济划算的方式,开发人员只需要按使用量付费,无需前期资本支出。利用 AWS ,开发人员可以轻松购买计算、存储、数据库和其他基于 Internet 的服务来支持其应用程序,以及灵活选择任何开发平台或编程环境。
Advertisements

趋势护航 安享云端 趋势科技 王进华 Internal - Confidential.
Web Maple— 云端计 算 数学学院刘海洋 胡婷婷. 需求 什么是 Web Maple ? Maple : “ 数学家的软件 ” 符号和数值计算 动态编程语言 集成编辑环境与图形输出 Web Maple :网页上的数学家 完整的 Maple 功能 云端计算 网页独特的输入输出格式.
ArchSummit 全球架构师峰会深 圳站 移动大数据平台架构实践 阎志涛 关于 TalkingData TalkingData( 北京腾云天下科技有限公司 ) 成立于 2011 年 9 月, 2013 年完成千万美元 A 轮融资 ( 北极光 领投 ) , 2014 年完成数千万美元的.
2011 年 2 月 网站管理员. 第一步、进入管理界面 输入网址,点击 “ 管理 ” ,进入身份认证界面, 输入用户密码后进入工具箱.
XX啤酒营销及广告策略.
Amazon 云计算 AWS (三) 云计算 (第三版) 第 3 章 CLOUD COMPUTING Third Edition
资源平台应用培训 武汉市交通学校信息化建设指导委员会.
第四章:长期股权投资 长期股权投资效果 1、控制:50%以上 有权决定对方财务和经营.
中华字库的云输入法 王勇 基础软件国家工程研究中心
爱上我们的图书馆 —新生入馆引导 河海大学图书馆.
AnyShare5.0入门指导 —— 普通用户篇.
104年度國立宜蘭大學新進主管研討 主計業務宣導說明
KOOBSOFT跨境电商织网系统 顾博软件- KOOBSOFT产品部.
102年實施之高中職及五專多元入學(含免試入學)之招生機制
事件驱动的移动数据中心 广州舜飞信息科技有限公司 谭荣棉.
城市电视台 全媒体发展策略 索贝云计算.

基于CloudFoundry的私有云平台
阿里云计算开放平台与产品 阿里云-刘飞 2012年10月.
上海地面通云主机产品 产品介绍 通信成就梦想 未来你我把握
Bilibili的存储实战(bfs) —— 分布式小文件存储.
基于Pomelo的MMO RPG开发 网易杭州研究院
云计算学习报告 报告人: 陈 霁 大规模数据处理软件Apache Hadoop.
初中语文总复习 说明文 阅读专题 西安市第六十七中学 潘敏.
优卡会介绍资料 ——健 康 数 据 管 理 专 家—— ——爱上优卡会,生活好品味
天涯运维的那些事 网络系统部.天涯.
Canal开源产品介绍 taobao.
58同城从MongoDB到MySQL迁移之路
为教师开展大数据课程教学提供全方位、一站式服务
学习目标 掌握电子商务网站体系结构 掌握企业电子商务网站体系结构 掌握PWS的安装与设置
面对经济全球化.
科學科 污染 空氣 成因 的 : 題目 及 減少空氣污染的方法 陳玉玲 (4) 姓名 : 去到目錄.
北师大版七年级数学 5.5 应用一元一次方程 ——“希望工程”义演 枣庄市第三十四中学 曹馨.
海洋存亡 匹夫有责 ——让我们都来做环保小卫士 XX小学三(3)班.
网络协会2017培训 Node.js专题 (1) 2017/3/12 – Payne.
用BOSH自动部署大规模 云平台Cloud Foundry
华南师范大学 防火墙 华南师范大学
第3讲 网络安全协议基础 此为封面页,需列出课程编码、课程名称和课程开发室名称。
Arena System Technology Architecture 系统技术架构 1、Database V2(Lotus Notes)V3(Oracle8i) 2、Application Server SilverStream2.53 (Java as server side programming.
XinyiZhou 11/ PPTV LB日志实时分析平台 XinyiZhou 11/
網路概論 第9章 DNS通訊協定.
中国式的云计算服务模式 中企开源信息技术有限公司 CE Open Source Software.
弹性计算云安全 魏兴国(云舒) 2012年9月.
Hadoop平台與應用規劃實作 報告者:劉育維.
考试题型 填空题(30) 选择题(20) 名词解释(10) 问答题(24) 计算题(16) 附加题(30) 成绩核算:
RESTful API 设计及应用 REST Representational State Transfer 演讲人:李盛洲 致
软件工程基础 云计算概论 刘 驰.
任务调度架构变迁史 知道创宇 杨冀龙.
欢迎各位 Nice to Meet U.
中国式的云计算服务模式 中企开源信息技术有限公司 CE Open Source Software.
交換器(Switch)功能介紹.
Web前端开发 第23章:网站发布 阮晓龙 / 河南中医药大学管理科学与工程学科
報告人:中央大學計中包元輝 中央大學APP開發團隊經驗分享 報告人:中央大學計中包元輝
Sym社区系统商业版 背景、功能以及技术架构简介.
性能的秘诀 chrome插件支持推送.
微软云计算 --Windows Azure platform
第七章  事业单位支出的核算      §第一节  支出概述     §第二节  拨出款项     §第三节  各项支出     §第四节  成本费用.
Dubbo介绍 Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和Spring框架无缝集成.
万方数据知识服务平台 论文相似性检测 培训师:何娟
指導老師:蘇怡仁老師 組員:陳翊嘉、何盈宏、黃皇瑋、鄭楚懷
指導老師:詹進科、陳育毅 開發團隊 : 呂峻豪、謝佳峻、黃傳強 中興大學資訊科學與工程學系 2015/12/11
【VA虚拟应用管理平台】专题培训 接入防火墙 陕西益和信息技术开发有限责任公司 2011年2月.
研发技术体系梳理 陈玮
Internet课程设计 教师:陈 妍 朱海萍 西安交通大学计算机系
基于 Spectrum Scale 的数据安全
大数据应用人才培养系列教材 数据挖掘基础 刘 鹏 张 燕 总主编 陶建辉 主编 姜才康 副主编.
天翼云3.0产品介绍 2018/4/24.
基于全球云平台的SaaS业务面临的挑战与难题
天翼云3.0产品介绍及18年规划.
Presentation transcript:

Mico的架构之旅 魏佳 Co-Founder & CTO @ Mico Inc.

关于我 分布式消息中间件 虚拟化及多租户弹性运行时 大规模分布式系统服务质量 分别在美国和国内发表技术专利 2009 2012 2014 IBM 新浪微博 Mico创业 资深工程师 Co-Founder & CTO 平台架构部架构师 技术评审委员会成员

关于Mico 是什么? 定位 形态 类似产品 市场? 用户群体分布 为什么选择这样的市场

关于Mico 相关数据? 注册用户数 日活跃用户数、日在线用户数、月活跃用户数、 日消息量、日服务请求量、日通知推送量 UGC内容量、图片/语音/短视频等

关于Mico 技术团队 团队规模、职责划分 技术准则和文化

今天分享些什么 初起炉灶 高速发展 步入正轨

初起炉灶 业务驱动,简单分层,粗放、够用就好 暴露的问题 SCM和流程 环境 基本架构组成(带图,细讲) 这种情况下如何应对增长(扩展)? 功能简单,除了应用后台外,无其他周边系统 运维工具的缺失,全手工 环境的监控和告警 发布和上线过程 手工环境的错误不可控 * 业务驱动,简单分层,粗放、够用就好 Bitbucket作为scm Linode,东京机房,裸VM+自己搭建生产环境 单实例的biz backend(Java,Spring Boot),暴露REST API,为移动端提供业务功能。 缓存(Memcached、Redis),隔离业务功能和通信,无sharding,Redis以master-slave拓扑 存储(MySQL、MongoDB),MySQL一主一从(实例中按业务分库但无分表),MongoDB一主两从 GridFS用于文件存储,比如图片、短视频等,文件访问API(NodeJS),直接使用Nginx的local cache来做二进制资源的缓存。 单实例的socket backend,提供长连接通信,资源与biz backend共用。 单独的Web server(Nginx+NodeJS)用来server产品官网、外部内容分享以及所有应用内HTML5的页面。 这种情况下如何应对增长? 扩展接入层,直接扩展业务server和socket server,直接扩展文件存储的Nginx(local cache) 扩展缓存和存储的从实例来抗读 * App功能简单,除了应用后台,无其他周边系统 早期的推荐用户、推荐动态的功能都有人工标记,没有引入其他流处理和单独的推荐系统等等。 * 缺失运维工具,全手工 Linode提供VM级的系统监控,包括CPU、Mem、Disk、Load、Network等 没有应用级的监控/告警工具,依赖各组件内置的stat工具来手工查看 构建和发布系统也很弱(简单Jenkins job) * 各种暴露的问题 1. 对系统状况没有直观实时的了解 2. 人工参与的环节错误不可控

初起炉灶 * 业务驱动,简单分层,粗放、够用就好 Bitbucket作为scm Linode,东京机房,裸VM+自己搭建生产环境 细讲 * 业务驱动,简单分层,粗放、够用就好 Bitbucket作为scm Linode,东京机房,裸VM+自己搭建生产环境 单实例的biz backend(Java,Spring Boot),暴露REST API,为移动端提供业务功能。 缓存(Memcached、Redis),隔离业务功能和通信,无sharding,Redis以master-slave拓扑 存储(MySQL、MongoDB),MySQL一主一从(实例中按业务分库但无分表),MongoDB一主两从 GridFS用于文件存储,比如图片、短视频等,文件访问API(NodeJS),直接使用Nginx的local cache来做二进制资源的缓存。 单实例的socket backend,提供长连接通信,资源与biz backend共用。 单独的Web server(Nginx+NodeJS)用来server产品官网、外部内容分享以及所有应用内HTML5的页面。 这种情况下如何应对增长? 扩展接入层,直接扩展业务server和socket server,直接扩展文件存储的Nginx(local cache) 扩展缓存和存储的从实例来抗读 * App功能简单,除了应用后台,无其他周边系统 早期的推荐用户、推荐动态的功能都有人工标记,没有引入其他流处理和单独的推荐系统等等。 * 缺失运维工具,全手工 Linode提供VM级的系统监控,包括CPU、Mem、Disk、Load、Network等 没有应用级的监控/告警工具,依赖各组件内置的stat工具来手工查看 构建和发布系统也很弱(简单Jenkins job) * 各种暴露的问题 1. 对系统状况没有直观实时的了解 2. 人工参与的环节错误不可控

高速发展 数据增长很快,开着飞机换引擎 这个阶段的架构变更(带图,细讲) 异步消息组件 拆分业务(细讲,缘由,做法等) 文件存储系统 请求接入 通信 跨长链消息 拆分业务(细讲,缘由,做法等) Api层 Server层 资源层 文件存储系统 实现 做法 问题 * 数据增长很快,一边继续产品迭代一边进行架构改造(开着飞机换引擎) 这个阶段的系统架构图 * 引入消息组件,这里面临技术选型的问题。目前开源并且广泛实用的mom非常多,不同的系统的设计侧重点也不同。(比如事务完备,确保投递,分布式的方式等等) 1. http上下行请求分离,上行请求全部异步,移动端假写,服务层直接写cache,具体业务逻辑在消息处理器中完成 2. 通信消息异步写库,上行直接写cache 3. 跨socket server通信写队列 * 按业务拆分,因为各业务的使用量和场景不同,这就决定了生产环境上资源的使用是不均等的,高峰期遇到的压力也不同。 1. 划分api pool,可以更细粒度的控制请求,可以根据需要单独扩展某业务,可以在故障或高峰时单独降级某业务 2. 划分service,为之后的微服务化铺路,将各业务作为内聚的最小服务单元,提供多种服务协议,如RPC、消息、HTTP等,这样也为之后的产品功能迭代提供更快速的业务支撑能力(搭积木) 3. 划分各类资源,比如cache、redis,根据各业务数据量的不同以及预计的增长量,可以更细粒度得控制这些组件的部署规模。 * 使用新的文件存储系统 1. Nginx(local cache)+ NodeJS(API)+ GridFS(storage)的方案带来的运维痛苦以及较大的性能问题 * scaleout时,部署一整套组件,同时新的的gridfs实例作为secondary需要从primary全量复制,时间长(standby状态写不能提供服务) * primary在持续的较大写入量下,secondary会追不上 2. 将数据全部迁移到S3,我们用Golang写了个工具用来迁移数据。但是全量数据中有大量缩略图(对于图片来说共3种尺寸的缩略图,对于视频来说共3种尺寸的首帧缩略图),连缩略图一起迁移太耗时,所以我们将原来文件系统API(NodeJS)中的生成缩略图的逻辑摘出来放到AWS的Lambda服务上(Lambda的名字非常形象,可以用于S3任意action的回调函数使用,其中一个典型用途就是图片上传到S3后异步生成缩略图),这样我们就很快将原始图片、短视频以及语音迁移到S3上了。搭配S3,AWS提供了Cloudfront,它是一个global的CDN服务,迁移过程中同步就将内容复制到各个region的节点上。迁移完成后,对于未升级的客户端(早期写死了IP地址),将原有的文件系统API的前置Nginx将请求转发到cloudfront来下载。

高速发展 * 数据增长很快,一边继续产品迭代一边进行架构改造(开着飞机换引擎) 这个阶段的系统架构图 细讲 * 数据增长很快,一边继续产品迭代一边进行架构改造(开着飞机换引擎) 这个阶段的系统架构图 * 引入消息组件,这里面临技术选型的问题。目前开源并且广泛实用的mom非常多,不同的系统的设计侧重点也不同。(比如事务完备,确保投递,分布式的方式等等) 1. http上下行请求分离,上行请求全部异步,移动端假写,服务层直接写cache,具体业务逻辑在消息处理器中完成 2. 通信消息异步写库,上行直接写cache 3. 跨socket server通信写队列 * 按业务拆分,因为各业务的使用量和场景不同,这就决定了生产环境上资源的使用是不均等的,高峰期遇到的压力也不同。 1. 划分api pool,可以更细粒度的控制请求,可以根据需要单独扩展某业务,可以在故障或高峰时单独降级某业务 2. 划分service,为之后的微服务化铺路,将各业务作为内聚的最小服务单元,提供多种服务协议,如RPC、消息、HTTP等,这样也为之后的产品功能迭代提供更快速的业务支撑能力(搭积木) 3. 划分各类资源,比如cache、redis,根据各业务数据量的不同以及预计的增长量,可以更细粒度得控制这些组件的部署规模。 * 使用新的文件存储系统 1. Nginx(local cache)+ NodeJS(API)+ GridFS(storage)的方案带来的运维痛苦以及较大的性能问题 * scaleout时,部署一整套组件,同时新的的gridfs实例作为secondary需要从primary全量复制,时间长(standby状态写不能提供服务) * primary在持续的较大写入量下,secondary会追不上 2. 将数据全部迁移到S3,我们用Golang写了个工具用来迁移数据。但是全量数据中有大量缩略图(对于图片来说共3种尺寸的缩略图,对于视频来说共3种尺寸的首帧缩略图),连缩略图一起迁移太耗时,所以我们将原来文件系统API(NodeJS)中的生成缩略图的逻辑摘出来放到AWS的Lambda服务上(Lambda的名字非常形象,可以用于S3任意action的回调函数使用,其中一个典型用途就是图片上传到S3后异步生成缩略图),这样我们就很快将原始图片、短视频以及语音迁移到S3上了。搭配S3,AWS提供了Cloudfront,它是一个global的CDN服务,迁移过程中同步就将内容复制到各个region的节点上。迁移完成后,对于未升级的客户端(早期写死了IP地址),将原有的文件系统API的前置Nginx将请求转发到cloudfront来下载。

高速发展 补齐或完善运维系统,半手工扩容 云环境的迁移 封装环境vagrant Gitflow,完善构建发布过程 简单的监控系统 朴素的定时任务 用户管理系统和内容管理系统 手工扩容 云环境的迁移 为什么? 资源 定价 服务单一 * 一边补全运维工具,一边应对高峰期手工扩容 * 使用Vagrant构建最小化的dev环境,可以确保所有成员环境一致 * 合理使用Gitflow,Jekins每日构建dev branch,每日部署staging环境,同样使用Vagrant来封装staging环境 * munin搭建监控系统,覆盖所有的资源或组建。munin的plugin机制(Python/Perl)可以灵活扩展或定制监控项 * 定时任务+离线脚本去统计业务数据 * 用NodeJS+Angular搭建用户管理和内容管理后台(包括内容运营/发布,应用内官方帐号消息,应用内用户反馈,用户封禁/解封,内容审核,外部内容分享控制等) * 依赖监控系统的各类数据指标指导高峰期的扩容(需手工执行,是一套简易的python实现的工具箱,可以根据base image(AMI)快速创建实例,更新前端LB,更新资源配置等。) * 云环境的迁移 * 为什么放弃Linode? 1. 资源欠缺 Linode(tokyo地区)的机器资源实际是使用AWS的,在我们高速发展的阶段(频繁需要扩容)但是Linode经常提示没有实例可以提供。 2. 定价模式 Linode的机器都是按实例按规格按月结算,不论用多用少没有灵活的收费模式(主要还是因为我们穷) 3. 服务太单一 只提供VM,连IaaS都称不上,没有其他任何云服务。相比AWS,提供很多开箱即用的服务,能极大节省我们的精力和时间。 * AWS,使用了EC2、Loadbalancer、EIP、S3、CloudFront、Lambda。后期又陆续使用了ElasticCache、RDS、MailService等。

高速发展 * 一边补全运维工具,一边应对高峰期手工扩容 * 使用Vagrant构建最小化的dev环境,可以确保所有成员环境一致 细讲 * 一边补全运维工具,一边应对高峰期手工扩容 * 使用Vagrant构建最小化的dev环境,可以确保所有成员环境一致 * 合理使用Gitflow,Jekins每日构建dev branch,每日部署staging环境,同样使用Vagrant来封装staging环境 * munin搭建监控系统,覆盖所有的资源或组建。munin的plugin机制(Python/Perl)可以灵活扩展或定制监控项 * 定时任务+离线脚本去统计业务数据 * 用NodeJS+Angular搭建用户管理和内容管理后台(包括内容运营/发布,应用内官方帐号消息,应用内用户反馈,用户封禁/解封,内容审核,外部内容分享控制等) * 依赖监控系统的各类数据指标指导高峰期的扩容(需手工执行,是一套简易的python实现的工具箱,可以根据base image(AMI)快速创建实例,更新前端LB,更新资源配置等。) * 云环境的迁移 * 为什么放弃Linode? 1. 资源欠缺 Linode(tokyo地区)的机器资源实际是使用AWS的,在我们高速发展的阶段(频繁需要扩容)但是Linode经常提示没有实例可以提供。 2. 定价模式 Linode的机器都是按实例按规格按月结算,不论用多用少没有灵活的收费模式(主要还是因为我们穷) 3. 服务太单一 只提供VM,连IaaS都称不上,没有其他任何云服务。相比AWS,提供很多开箱即用的服务,能极大节省我们的精力和时间。 * AWS,使用了EC2、Loadbalancer、EIP、S3、CloudFront、Lambda。后期又陆续使用了ElasticCache、RDS、MailService等。

高速发展 IM系统的架构和改进(带图,细讲) 协议 传输 场景 * IM系统的架构和改进 * 协议 自己实现的轻量sync协议 inbox/outbox 单点消息推模式,群组消息拉模式,支持多端同步(app,web) 文本消息,图片消息(附带缩略图),语音消息(分片),短视频消息(附带首帧缩略图) 文本消息直接push,图片、语音通知后主动拉 支持消息状态,如『已达』『已读』 * 通信 Netty实现的TCP socket server,单机(AWS xlarge.m2配置)60万长链接,用于iOS/Android Netty实现的WebSocket endpoint,用于browser 二进制(Protobuf)和JSON均支持 跨server通信支持RPC式和异步队列,可手动切换;消息状态走异步队列,高峰期走异步队列; api server定期检查socket server的可用性并提供一个查询接口,移动端通过该接口来始终获取最新的可用endpoint 关于长链维系,调研了一些IM产品以及国内外不同运营商的网络品质,搞了套自适应心跳机制,做到了消息投递/通知时效性和power saver的平衡 和业务资源隔离,和相关业务有关系的资源通通异步更新。消息异步落地,投递时只写cache。 * 场景 * 其他

高速发展 * IM系统的架构和改进 * 协议 自己实现的轻量sync协议 inbox/outbox 细讲 * IM系统的架构和改进 * 协议 自己实现的轻量sync协议 inbox/outbox 单点消息推模式,群组消息拉模式,支持多端同步(app,web) 文本消息,图片消息(附带缩略图),语音消息(分片),短视频消息(附带首帧缩略图) 文本消息直接push,图片、语音通知后主动拉 支持消息状态,如『已达』『已读』 * 通信 Netty实现的TCP socket server,单机(AWS xlarge.m2配置)60万长链接,用于iOS/Android Netty实现的WebSocket endpoint,用于browser 二进制(Protobuf)和JSON均支持 跨server通信支持RPC式和异步队列,可手动切换;消息状态走异步队列,高峰期走异步队列; api server定期检查socket server的可用性并提供一个查询接口,移动端通过该接口来始终获取最新的可用endpoint 关于长链维系,调研了一些IM产品以及国内外不同运营商的网络品质,搞了套自适应心跳机制,做到了消息投递/通知时效性和power saver的平衡 和业务资源隔离,和相关业务有关系的资源通通异步更新。消息异步落地,投递时只写cache。 * 场景 * 其他

步入正轨 功能迭代非常快,数据增长非常快,需要周边系统支撑 这个阶段的架构变更(带图,细讲) 我们的日志分析 * 我们的日志分析 解决什么问题 怎么演进的 架构图(细讲) 场景 * 我们的日志分析 * 更细粒度日志的分类和梳理(业务日志,行为/访问/统计日志(包括HTTP、Service/RPC、Cache/DB等不同层次),一些BI用途的日志等) * 最早期crontab+rsync+grep/awk大法,简单够用;然后过渡到fluentd写mongodb(capped collection),web console提供展现和查询; * 最后过渡为ELK+kafka/redis的方案 * 架构图(再典型不过) * 根据使用场景不同和目的不同。其中部分由logstash收集写redis queue(这里引入redis queue中转的目的是提供日志内容的容错性,如es下线或维护时日志信息暂存。之后也有kafka替换了),之后由logstash再送入es做索引,展示到kibana上,这种大部分是无计算或少计算(聚合)的指标数据。es大家都很熟悉,它是基于lucene的,对于日志的所有字段都可以索引,并且其倒排索引的数据结构非常紧凑,搜索效率非常的高。反映到前端Kibana上,用户可以随意组合条件过滤日志,随意伸统计时间窗,秒级获取聚合计算结果。 * 需要做计算、统计类的日志数据(由logstash收集)写kafka,再由storm来消费。storm流式得做业务数据的聚合计算,主要是各种社交应用会遇到的数据统计场景,比如各种xx率,xx趋势,a/b test效果等等。数据驱动 * es目前数据节点和查询节点并没有分离(规模不到),目前还在使用http protocol模式 * 一些坑:开启doc_values;recovery和relocation的参数配置;默认的sharding策略shard总数均衡,不考虑IO。而做日志的时候,只有最近的索引的分片才有 IO 压力。所以如果你今天新上一个节点,然后隔天新建索引,一看,所有新分片全给分配到这台上,直接 IO 压垮。这个是有一个配置,针对索引级别的,可以对每个索引指定在单个节点上,最多分配几个分片。 * spark做业务数据方面的准实时计算, * kibana

步入正轨 细讲 * 我们的日志分析 * 更细粒度日志的分类和梳理(业务日志,行为/访问/统计日志(包括HTTP、Service/RPC、Cache/DB等不同层次),一些BI用途的日志等) * 最早期crontab+rsync+grep/awk大法,简单够用;然后过渡到fluentd写mongodb(capped collection),web console提供展现和查询; * 最后过渡为ELK+kafka/redis的方案 * 架构图(再典型不过) * 根据使用场景不同和目的不同。其中部分由logstash收集写redis queue(这里引入redis queue中转的目的是提供日志内容的容错性,如es下线或维护时日志信息暂存。之后也有kafka替换了),之后由logstash再送入es做索引,展示到kibana上,这种大部分是无计算或少计算(聚合)的指标数据。es大家都很熟悉,它是基于lucene的,对于日志的所有字段都可以索引,并且其倒排索引的数据结构非常紧凑,搜索效率非常的高。反映到前端Kibana上,用户可以随意组合条件过滤日志,随意伸统计时间窗,秒级获取聚合计算结果。 * 需要做计算、统计类的日志数据(由logstash收集)写kafka,再由storm来消费。storm流式得做业务数据的聚合计算,主要是各种社交应用会遇到的数据统计场景,比如各种xx率,xx趋势,a/b test效果等等。数据驱动 * es目前数据节点和查询节点并没有分离(规模不到),目前还在使用http protocol模式 * 一些坑:开启doc_values;recovery和relocation的参数配置;默认的sharding策略shard总数均衡,不考虑IO。而做日志的时候,只有最近的索引的分片才有 IO 压力。所以如果你今天新上一个节点,然后隔天新建索引,一看,所有新分片全给分配到这台上,直接 IO 压垮。这个是有一个配置,针对索引级别的,可以对每个索引指定在单个节点上,最多分配几个分片。 * spark做业务数据方面的准实时计算, * kibana

步入正轨 功能迭代非常快,数据增长非常快,需要周边系统支撑 这个阶段的架构变更(带图,细讲) 我们的监控/告警 我们的搜索 * 我们的搜索 解决什么问题 怎么演进的 架构图(细讲) 场景 我们的搜索 架构(细讲) 局限性 * 我们的搜索 * elasticsearch * spatial@mongo+redis(geohash zone) * 架构图 * 我们的监控/告警 * 最早期是依赖各组建或系统的stat功能,直接在terminal中输出,之后改为基于munin的监控,munin提供各类plugin(python/perl/shell)同时也非常方便自己扩展, * 最终到了zabbix(下一步准备迁到openfalcon)? * OS层面,cpu、load、mem、io等的监控和告警都有云基础设施完成,AWS上的cloudwatch+mailservice * 基础设施层面,memcache、redis、mongo、MySQL等 * 应用层面,容器,jvm状况,其他jmx扩展(如socket server中队列堆积,kafka中jmx数据项)等 * kibana

步入正轨 * 我们的搜索 * elasticsearch * spatial@mongo+redis(geohash zone) * 架构图 细讲 * 我们的搜索 * elasticsearch * spatial@mongo+redis(geohash zone) * 架构图 * 我们的监控/告警 * 最早期是依赖各组建或系统的stat功能,直接在terminal中输出,之后改为基于munin的监控,munin提供各类plugin(python/perl/shell)同时也非常方便自己扩展, * 最终到了zabbix(下一步准备迁到openfalcon)? * OS层面,cpu、load、mem、io等的监控和告警都有云基础设施完成,AWS上的cloudwatch+mailservice * 基础设施层面,memcache、redis、mongo、MySQL等 * 应用层面,容器,jvm状况,其他jmx扩展(如socket server中队列堆积,kafka中jmx数据项)等 * kibana

步入正轨 功能迭代非常快,数据增长非常快,需要周边系统支撑 这个阶段的架构变更(带图,细讲) 我们的服务框架(RPC)和配套设施 场景 架构图(细讲) 目前数据 我们的异步/定时任务框架 架构(细讲) 局限性 * 我们的RPC框架和配套设施 * 改造thrift,在thrift的骨架之上做了failover、loadbalance策略,降级开关,请求统计和性能采用,服务注册和发现(zk/curator-receipe) * rpc服务的注册和发现使用zookeeper+curator * 架构图 * 我们的异步/定时任务框架 * 早期crontab,后来使用Quartz封装了一套简单的任务框架 * 支持任务手工触发,任务结果通知,任务结果验证等 * 主要任务都是和产品运营相关的,类似于离线任务,大量的读和内存计算

步入正轨 细讲 * 我们的RPC框架和配套设施 * 改造thrift,在thrift的骨架之上做了failover、loadbalance策略,降级开关,请求统计和性能采用,服务注册和发现(zk/curator-receipe) * rpc服务的注册和发现使用zookeeper+curator * 架构图 * 我们的异步/定时任务框架 * 早期crontab,后来使用Quartz封装了一套简单的任务框架 * 支持任务手工触发,任务结果通知,任务结果验证等 * 主要任务都是和产品运营相关的,类似于离线任务,大量的读和内存计算

下一步的方向 基于公有云环境的容器化架构 跨机房高可用 通信协议的改进 业界怎么做的 我们的架构愿景 依赖AWS的跨区域avaiable zone 虚拟网络 通信协议的改进 多端同步 周边