架构这个词就和云一样，越来越多的人去说，但是其实这个本身一直就存在你身边，只不过大家用新的归纳方法进行了整理，出现的一个热词。那么就生产中实例：如何实现稳定的千万级日PV的移动应用架构？
第一步：要保证日均千万级PV的移动应用访问正常，我们需要有一个好的应用框架，代码不能写的都是坑。
至少代码本身质量要过关，我们这里说的是抛却代码质量这个因素，首先要模块化的拆分业务应用，不能所有的业务用一套系统，放1台服务器，这个肯定抗不了千万日PV，模块化后，各业务之间开放api进行互访传递数据，便于我们对各个模块进行改进。
第二步：当我们将业务进行了模块化拆分后，就要根据业务量对现有的各个模块进行量化评估和改进，改造的方向主要有下面几点：
1.对各个模块进行集群化部署，根据业务量分配集群规模。
2.消除整个结构化中的单点问题，不能有任何业务有单点故障，保障业务模块的高可用。
3.核心模块进行纵向的分层化处理，增加模块的处理能力和可扩展性/独立性。
4.异步化处理，很多实时性不高的业务进行异步化处理，减少整个系统的压力。
5.内存化处理，对交互处理频繁的数据，可以放到内存数据库中处理，异步进行数据的落地（使用内存数据库的集群和分布式机制保障数据的安全和高可用）。
6.精简目前的架构纵向层次，避免超过3层，越简单越高效，越易于管理。
第三步：关系数据库进行读写分离，或者集群化处理，目前大多数改进的方案最终的核心都在数据库上，大多方式：
1.使用内存数据库做数据库前端，所有对数据的更/删/改/查操作都在内存数据库中执行，最终异步将数据落地到关系数据库中，此方式能大大减少关系数据库的操作。
2.使用双主多从的方式部署数据库集群，oracle的自己有一套商业的解决方案（比如:rac）,这里就不说了
3.在程序层做数据库的读写分离或集群读取（这个要求程序员能力），或者使用数据库代理软件（路由软件），大公司自己写，开源的也有不少，但是多多少少都有一些小毛病，需要代码配套修改，很多用法是不支持的。
4.分库/分区/分表 这个主要是减轻单数据库服务器的压力，增加数据库处理能力。
5.慢查询日志分析，优化sql
第四步：监控，这个是保证千万级PV移动应用稳定运行的关键，主要分为下面几类：
1.服务器层基础监控：CPU/MEM/DISK/IO
2.应用服务状态：端口/服务进程
3.服务质量：连接数/响应速度/接口数据返回值
4.数据分析：定期的日志分析 PV/UV/QP
转载请注明：自动化运维 » 千万级PV(日)的移动应用架构如何实现?