总体思路总结这些年的经验，在选择架构演进方向时，应该达到以下目标：快速开发部署（写一个经过测试的hello五分钟世界并且可以访问/调用，可以公网访问）自然可扩展（业务层无状态，尽量放在***）自动化（内存不足，除了alarm，应该自动给它加一些机器；新项目，基本代码应该不用写，自动生成即可）framed（public层面的东西尽量frame，类似于日志的一层,counters,traces，开发后一行代码都应该默认开启）量化（所有调用都应该有百分位和rps，提供透明的服务反馈质量，跟踪系统甚至可以为内部系统模拟用户）同构（因为做两套成本巨大，整体应该越来越像同一种语言）硬件虚拟化（整个平台应该对用户透明流程（以下硬件条件）分版和灰度（所有软件网上应该都有清晰的版本，网上的流程有点灰度）上图花了点时间纯手绘。描述图中从上到下的顺序。在移动互联网环境下，用户会分为好网络用户和坏网络用户。我们应该尽一切可能为网络不好的用户提供合适的链接和可靠的DNS。接入层在接入层的代码层面，需要准备一个client-serversuite，也就是说需要一个同时懂客户端和server端开发如android\ios..的团队专门打造一个networksuite.这一层的目标是让客户端开发者不再关心网络协议问题。业务接入层的目标是灵活分配流量。往往大家的解决方案都是LVS或者F5。大一点，还有一些流量分析设备，在突然增加的时候，方便发现问题。业务层在统一的业务框架下完成各个灵活组织的BIZ逻辑，这就涉及到异构系统对一个大公司的影响。如果80%的人工作都在使用java，那么还是尽早使用java比较好，因为这意味着剩下的20%使用其他语言的同学可能要实现所有的基础知识这80%的学生都做到了。异构性必然导致一些模块无法安全工作，比如后续RPC、配置管理、监控告警、跟踪系统等。RPC框架和队列共同完成IDC中的数据传递。区别在于一个是同步的，一个是异步的。统一RPC框架的好处就不用多说了。配置管理zookeeper被选为leader角色，zk基本会出现在一定规模的服务中。日志系统统一的日志系统，方便获取未来开发所需的各种数据。日志系统的特点和要求：快速、容错网络、部署简单、流程稳定、可水平扩展。scribe和kafka都是不错的选择。这里最终的日志可能需要放在hdfs或者hbase中进行hive查询，否则数据量大后日志不好用。监控报警系统ganglia和nagios仍然是最常用的开源管理软件。需要考虑的是对业务框架默认记录的公共perfcounter进行监控告警。跟踪系统用于在系统出现bug时快速调试。当服务越来越多时，跟踪系统是必不可少的工具。Twitter的zipkin是一个很好的开源实现，但是如果你想在自己的代码中使用它，你可能需要对其进行处理。PaaSAgentDaemon是整体统一运维平台的客户端程序。该程序负责：向监控系统上报硬件和网络数据，启动和停止应用程序，将应用程序的运行状态传输给监控系统和PaaS平台。存储平台该层包括所有状态繁重的托管服务。Memcached集群采用统一一致的哈希客户端，所有缓存服务器统一管理，计算命中率和使用率，实时添加内存。DBMS集群采用统一的数据库分库和分表层动态检测和切换故障。mysqlproxy、amoeba等常见项目。HBase集群作为独立的存储可用性保证，也被设计为高可用集群。PaaS资源控制层的目标是实时反馈整个或多个IDC还剩多少内存，CPU是否足够，下次采购需要多少台机器。虚拟化是一个关键问题。常见的开源软件：docker、warden、LXC。对于资源控制，CPU可以使用cgroups，磁盘可以使用aufs等，这些方案已经包含在通用的虚拟化方案中。PaaS用户界面层主要面向运维和开发者，比如在线服务，增删机等。除了web界面，还应该支持cli模式。自动部署层一般是在hudson的CI（continuousbuild）完成之后进行的，但是自动部署必须要有非常可靠的测试框架和可靠的测试代码，否则就是悲剧了。测试框架借鉴了一些高级框架，让代码少写，比如jmockit，spring-test等。编译工具java的maven是最好的选择。编译包仓库，推荐nexus。代码生成开发者不需要做重复操作，只要框架固定，应该可以生成所有代码。只需修改核心逻辑即可。这个比较抽象，有方法可以用，比如做一个maven-plugin，让所有工程师都可以用。不断升级此工具以包含更多可能的代码方法。代码质量工程师的代码完成后，进行静态分析，提前发现一些问题，可以做一个有规律的pattern放在一起，持续集成。推荐hudson+maven+sonar三剑合一。代码与常规系统代码托管：gitlab是一个类似github的好工具（越来越多）。codereview：可以直接使用gitlab的mergerequest，也可以使用开源的reviewboard。知识管理：没什么好说的，mediawiki。要求和错误：jira。故障管理：没有开源项目，事后系统，是一个记录故障原因的系统。当下次故障来临时，来本系统进行问卷调查和反思。DEV&TEST开发阶段的PAAS需要前面提到的cli发布到自己的开发机上（这里也需要PaaS方便的开启新的开发机）。测试阶段需要比开发阶段更高可用的环境，基础工具的可靠性必须时刻提升。不应让开发环境在开发过程中消失。相反，应该将测试环境用作开发环境。现实中之所以会出现此类事件，都是因为部署不完善。原文链接：http://2014.54chen.com/
