中大型移动互联网公司技术架构选择(转载)

原文地址:http://2014.54chen.com/blog/2014/03/05/ihaveadream/

总体思考

总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:

  • 可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问)
  • 天然可扩展(业务层无状态,尽可能全部放到最后)
  • 自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可)
  • 框架化(公共层面的东西尽可能框架化,一层类似日志、counter、trace,应该不需要开发再写一行代码即默认打开)
  • 量化(所有的调用都应该有percentile与rps,透明反馈服务质量,跟踪系统更是可以模拟用户进行系统内部)
  • 同构化(因为搞两套的成本巨大,整体应该越来越趋同于同一种语言)
  • 硬件虚拟化(整个平台应该对进程透明下面的硬件情况)
  • 版本化、灰度化(所有的软件都应该在线上有明确的版本,且上线过程是一点点灰度上)

上图纯手绘花了些时间,本文以此图从上到下的顺序进行描述。

用户

在移动互联网环境下,用户会被分为好网络的用户和坏网络的用户,我们要为坏网络的用户尽一切可能提供合适的链路和可靠的DNS。

接入层

在接入层的代码层面,需要准备client-server套件,这意味着,需要一个同时了解android\ios..等客户端和服务器端开发的团队,专门打造网络套件。

  • 这一层的目标是,让客户端开发人员不再关心网络协议的问题。

业务接入层

这一层的目标是灵通机动调配流量,往往大家的方案都是LVS,或者是F5等。更高大上一点,再上一些流量分析设备,在有突增的时候好用来找问题。

业务层

在统一的业务框架下,去完成各个灵活组织的BIZ逻辑,这里就涉及到异构系统对一个大型公司的影响。

  • 如果80%的人都在使用java的活,还是趁早全用java,因为意味着剩下20%用其他语言的同学,有可能要把这80%的同学做的基础全部实现一遍。
  • 异构必然会导致某些模块不能完美工作,比如后续的RPC、配置管理、监控报警、跟踪系统等等。

RPC框架与队列

二者一起完成数据在IDC的传递,不同在于,一个是同步,一个是异步。

  • 统一的RPC框架好处不必言说。

配置管理

zookeeper当选最佳角色,上点规模的服务里基本都会有zk的身影。

日志系统

统一的日志系统,对未来发展中所需要的各种数据更加容易得到。日志系统的特点要求:快,容网络错误,部署简单,进程稳定,可水平扩展。

  • scribe与kafka都是不错的选择。
  • 这里最终的日志,可能会需要放到hdfs或者是hbase里进行hive查询,否则数据量大了之后要想把日志用起来很不容易。

监控报警系统

ganglia与nagios仍旧是最好用的开源管理软件。

  • 需要考虑的是,要将在业务框架里默认记录的公共的perfcounter进行监控与报警。

跟踪系统

当系统出现bug的时候,用来快速debug,当服务越来越多的时候,跟踪系统是个必不可少的工具。

  • twitter的zipkin是个不错的开源的实现,不过要使用到自家的代码里来,可能要加工一下。

PAAS Agent Daemon

整体统一的运维平台的客户端程序,此程序负责:向监控系统汇报硬件及网络数据,启动和停止应用程序,向监控系统和PAAS平台传递应用程序的运行状态。

存储平台

此层包括所有重状态的hosting service。

  • memcached cluster,使用统一的一致性hash客户端,所有的缓存服务器进行统一管理,计算命中率、使用率,实时添加内存。
  • DBMS cluster,使用统一的数据库分库分表层,动态地感知和切换故障。常见的项目如mysqlproxy,变形虫。
  • HBase cluster,独立的存储可用性保障,本身也是设计为高可用性的集群。

PAAS 资源控制层

目标是实时反馈整个或多个IDC内部的内存还有多少、CPU是否够用、下次采购还需要多少机器。

  • 虚拟化是个重点难题。常见开源软件:docker、warden、LXC。
  • 资源控制CPU可用cgroups,磁盘可用aufs等,一般的虚拟化方案中都已经包括这几项解决办法。

PAAS用户界面层

这一层主要面向运维和开发人员,比如用来上线服务、添加删除机器。

  • 除了web界面,还应该有cli模式的支持。

自动部署层

一般都以hudson的CI(持续构建)完成之后进行,但可自动化的部署一定需要测试框架非常靠谱,以及测试代码靠谱,否则就是个悲剧。

测试框架

借用一些高级框架,让代码写少一点,比如jmockit、spring-test等等。

编译工具

java的maven为不二选择。编译好的包仓库,推荐nexus。

代码生成

开发人员不需要重复进行操作,只要框架是固定的,所有的代码应该都是可以生成的。只需要花精力去修改核心逻辑。

  • 这里比较抽象,可以用的办法比如做一个maven-plugin,让全部工程师都会用。
  • 不断地去升级这个工具,使其包括更多的可能的代码方式。

代码质量

在工程师的代码完成之后,跑一遍静态分析,可以提前发现一些问题,可以做成定期的模式,与持续集成放在一起。

  • 推荐hudson + maven + sonar三剑合一。

代码及常规系统

  • 代码托管:gitlab是一个不错的类似github(越来越像了)的工具。
  • codereview:可直接使用gitlab的merge request,也可以使用开源的reviewboard。
  • 知识管理:没什么好说的,mediawiki。
  • 需求与bug:jira。
  • 故障管理:这个没有开源项目,post-mortem system,是一种记录故障原因的系统,下一次故障来临的时候,来这个系统里进行问卷式的调查和反思。

PAAS for DEV & TEST

  • 开发阶段需要之前提到的cli可发布到自己的开发机(这里还需要PAAS可很容易地开一个新的开发机)的工具。
  • 测试阶段需要比开发阶段更加高可用性的环境,而且要时刻提升基础工具的可靠性,不应该让开发环境在发展中消失,反而用测试环境来当作开发环境,现实中发生此类事件的原因,都是部署没有做到完美。

中大型移动互联网公司技术架构选择(转载),布布扣,bubuko.com

时间: 2024-08-02 18:56:24

中大型移动互联网公司技术架构选择(转载)的相关文章

中大型移动互联网公司技术架构选择

  总体思考 总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标: 可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问) 天然可扩展(业务层无状态,尽可能全部放到最后) 自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可) 框架化(公共层面的东西尽可能框架化,一层类似日志.counter.trace,应该不需要开发再写一行代码即默认打开) 量化(所有的调用都应该有percentile与rps

大型网站IT技术架构

1.Varnish 反向代理服务器(外网client向内网server请求资源) 模式: 代理缓存,外网client在varnish找不到请求的资源,varnish会向上游的apache请求资源,然后传给client,并同时缓存该资源: 旁路缓存,外网client在varnish找不到请求的资源,varnish将client的请求路由到上游的apache,client取得资源后将该资源返回给varnish: 最近公司做活动推广,流量暴增,后端服务器压力山大,导致用户的请求响应时间延长,客户因此抱

(转)各种大型网站技术架构

引言近段时间以来,通过接触有关海量数据处理和搜索引擎的诸多技术,常常见识到不少精妙绝伦的架构图.除了每每感叹于每幅图表面上的绘制的精细之外,更为架构图背后所隐藏的设计思想所叹服.个人这两天一直在搜集各大型网站的架构设计图,一为了一饱眼福,领略各类大型网站架构设计的精彩之外,二来也可供闲时反复琢磨体会,何乐而不为呢?特此,总结整理了诸如国外wikipedia,Facebook,Yahoo!,YouTube,MySpace,Twitter,国内如优酷网等大型网站的技术架构(本文重点分析优酷网的技术架

各种大型网站技术架构

引言近段时间以来,通过接触有关海量数据处理和搜索引擎的诸多技术,常常见识到不少精妙绝伦的架构图.除了每每感叹于每幅图表面上的绘制的精细之外,更为架构图背后所隐藏的设计思想所叹服.个人这两天一直在搜集各大型网站的架构设计图,一为了一饱眼福,领略各类大型网站架构设计的精彩之外,二来也可供闲时反复琢磨体会,何乐而不为呢?特此,总结整理了诸如国外wikipedia,Facebook,Yahoo!,YouTube,MySpace,Twitter,国内如优酷网等大型网站的技术架构(本文重点分析优酷网的技术架

《大型网站技术架构》笔记

最近又把<大型网站技术架构>看了一遍.而中间读了一本<计算机操作系统>的教材后,感觉对大型网站的技术架构有更深的了解.在此结合对这两本书的理解做一些笔记 传统的OS(Operator System)有四个基本的功能: 处理机管理:以进程为基本单位,对其创建和撤销 a)         进程控制 b)         进程同步 c)         进程通信 d)         调度 存储器管理 a)         内存分配 b)         内存保护 c)         

读书笔记(二)-- 《大型网站技术架构:核心原理与案例分析》

注:作为一个搞IT的技术人员,技术书籍是不可缺少的,<大型网站技术架构:核心原理与案例分析>这本书是app后台开发群的群主推荐的书籍,书中提到的技术架构方法,不仅仅适用于网站,其他方面的开发都可以借鉴其中的思想,是不可多得的一本好书.由于本书是找一位同事借的,周末就需要读完还给他,再次验证一个道理,书还是借的读起来有效率. 阅读时间:2015年1月15日--2015年1月18日 本书主要讲述的是大型网站的技术架构,着重从五个方面阐述需要关心的核心架构元素:性能.可用性.伸缩性.扩展性和安全性.

云端高性能技术架构浅析一

无论是国外的Google.Facebook.Amazon,还是国内的Baidu.Taobao等,这些高性能的服务器在处理高并发的请求时,都能快速.准确的给予应答.通过查阅资料,了解现有大型网站的技术架构,发现目前常用的技术有分层.缓存.负载均衡.数据库性能优化,分布式系统等等.接下类分别对这些技术进行简单介绍. 1 分层与服务分离 无论OSI的7层网络结构,还是计算机底层硬件与上层软件之间的分层,甚至于Web领域大家非常熟悉的MVC开发模式,分层在计算机领域无处不在.分层可以将不同的功能部件独立

从Hadoop框架与MapReduce模式中谈海量数据处理(含淘宝技术架构)

从hadoop框架与MapReduce模式中谈海量数据处理 前言 几周前,当我最初听到,以致后来初次接触Hadoop与MapReduce这两个东西,我便稍显兴奋,认为它们非常是神奇,而神奇的东西常能勾起我的兴趣,在看过介绍它们的文章或论文之后,认为Hadoop是一项富有趣味和挑战性的技术,且它还牵扯到了一个我更加感兴趣的话题:海量数据处理. 由此,近期凡是空暇时,便在看"Hadoop","MapReduce""海量数据处理"这方面的论文.但在看论

海量数据处理之从Hadoop框架与MapReduce模式中谈海量数据处理(淘宝技术架构)

几周前,当我最初听到,以致后来初次接触Hadoop与MapReduce这两个东西,我便稍显兴奋,觉得它们很是神秘,而神秘的东西常能勾起我的兴趣,在看过介绍它们的文章或论文之后,觉得Hadoop是一项富有趣味和挑战性的技术,且它还牵扯到了一个我更加感兴趣的话题:海量数据处理. 由此,最近凡是空闲时,便在看"Hadoop","MapReduce""海量数据处理"这方面的论文.但在看论文的过程中,总觉得那些论文都是浅尝辄止,常常看的很不过瘾,总是一个东