由于最近负责一个互联网APP项目，需要重新设计架构，这边架构已经设计完成，做下详解：
首先，笔者其实也未达到架构师级别，但是在一直坚信一个原则，架构一定要建立在业务的基础上，没有经过业务就设计的架构就是耍流氓！！！
首先我们分析大概的需求，可归结为以下几点：
1、此项目为互联网项目，后期用户量可能会增长；
2、需要涉及支付，可能需要对接支付宝、微信、银联等第三方支付接口，当然会涉及交易流水等记录数据；
3、需要对接外部其他系统的接口，接口协议以Http或者Soap暂未确定；
4、有支付消息推送模块，涉及内部系统推送和极光推送等；
因为项目时间较赶，所以拿到手，大概分析了下业务，就着手设计，以下为初步设计的架构图：
接下来我们详解下为什么要这样来做？
针对以上了解到的业务场景，我是这样的思路来设计：
1、互联网项目，用户体验至关重要，考虑到体验性，前端加载速度要求要快，所以静态资源我们考虑以Nginx来直接做动静分离，后面如果用户量有提升，考虑接入CDN来保证页面加载效率；
2、有一部分基础业务，这块考虑独立出一个基础业务微服务，来处理一些简单的业务操作；
3、需要对接多个支付接口，这块可以独立出一个支付网关，做支付统一路由、统一分发、流水记录、日志记录等操作，由一个能力强的开发来独立负责，分离解耦的更彻底，上游只需要关心基础业务；
4、需要对接多个外部系统，且对接方式（Http、Soap）暂不确定，这块考虑独立出一个对外交换网关来集成不同接口，统一路由、统一分发，并做一些验签等安全机制；
5、涉及多种消息推送服务，这块也一样考虑独立出一块消息推送网关，我们前面说到后期用户量可能会有增长，所以采用MQ做异步提交到网关，数据量大可以做削峰限流等处理；
6、因为APP涉及比较多的搜索模块，所以考虑直接用ElasticSearch搜索引擎来操作；
7、独立出一个API服务做Token验证、路由分发服务，基础业务服务、支付网关、对外交换网关以RPC方式传输，后续生产环境可以根据不同服务模块流量，部署多个服务来支撑；
8、文件服务器考虑直接用FastDFS来操作，后期如果部署在阿里云ESC，可以考虑购买OSS服务，更加简单、效率更快；
以上就是初步架构设计，当然架构上还有很多可以优化，需要考虑的点，后面再慢慢完善。