详解互联网APP架构1.0

详解互联网APP架构1.0

详解互联网APP架构2.0

由于最近负责一个互联网APP项目，需要重新设计架构，这边架构已经设计完成，跟小伙伴们分享下设计思想：

首先我们分析大概的需求，可归结为以下几点：

1. 此项目为互联网项目，后期用户量可能会增长；
2. 需要涉及支付，可能需要对接支付宝、微信、银联等第三方支付接口，当然会涉及交易流水等记录数据；
3. 需要对接外部其他系统的接口，接口协议以Http或者Soap暂未确定；
4. 有支付消息推送模块，涉及内部系统推送和极光推送等；

因为项目时间较赶，所以拿到手，大概分析了下业务，就着手设计，以下为初步设计的架构图：

针对以上了解到的业务场景，架构从几个方面开始设计：

        1、接入层： 互联网项目，用户体验至关重要，考虑到体验性，前端加载速度要求要快，所以静态资源我们考虑以Nginx来直接做动静分离，后面如果用户量有提升，或者小视频、限时抢购接入等考虑CDN来保证页面加载效率；

        2、网关层：独立网关层，用于服务接入，在网关层做Token鉴权、服务分发等操作，实现网关层和服务层的彻底解耦，网关层注重业务之外的鉴权、分发、限流等，服务层可以只注重业务操作；

        3、服务层：服务层独立四个微服务，内部通讯都是采用RPC来支撑，这边介绍下这四个微服务：

            基础业务服务：由于前期对业务比较模糊，暂未确认清楚拆分几个业务服务，这边先规划一个基础服务微服务来支 持，基础服务主要做一下基础业务操作；

            支付网关：根据业务可以确定，项目需要对接多个支付渠道，拆分出支付服务，做支付统一路由、统一分发、验证签名、回调处理、流水记录、日志记录等操作，做架构垂直的拆分，分离解耦的更彻底，上游只需要关心基础业务；

            对外交换网关：项目需要对接对个外部系统，交换数据，且对接方式（Http、Soap）暂不确定。与支付网关相似，独立对外交换网关，对接外部不同协议的接口，统一路由、统一分发、验证签名、协议转换等操作；

            消息网关：项目涉及多种消息推送服务，例如：app推送、站内信、短信等推送服务，独立消息网关，并且采用MQ作为内部服务异步调用，至于MQ选型，出于前期吞吐量不大、更注重消息稳定性等因素，先选型Rabbitmq作为MQ中间件；

       4. 存储层：APP涉及比较多的搜索模块，所以考虑直接用ElasticSearch搜索引擎来操作，Redis作为缓存中间件，Mysql作为关系型数据存储，FastDFS做为非关系型数据存储；

以上就是初步架构设计，当然架构上还有很多可以优化，需要考虑的点，后面再慢慢完善。