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

原文地址：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可很容易地开一个新的开发机）的工具。
• 测试阶段须要比开发阶段更加高可用性的环境，并且要时刻提高基础工具的可靠性，不该该让开发环境在发展中消失，反而用测试环境来看成开发环境，现实中发生此类事件的缘由，都是部署没有作到完美。