为app提供api，架构该怎么设计，需要考虑高并发，访问量比较大

1.关于rest，仅仅是一种风格，至于框架，spring mvc 是比较成熟的，其实这块mvc 框架都不会成为你的问题，从团队熟练以及扩展上来说，spring 是个不错的选择，这块只要你设计好，开放API 是比较方便的。　　2.关于数据库方面，如果是读的量很大的情况，比如读写比例10：1的情况下，访问量比较大，你可以考虑数据库的主从，以及负载均衡的一些东西，关于这块的东西很多，得从实际情况进行处理。至于考虑的点，你得考虑数据库压力、信息监控、出现宕机等情况的处理，后面可能还会考虑你的水平扩展问题。　　3.关于你说的数据库部分的框架，我没理解，虽然数据库作为存储的东西，你也不可能将压力全部放在数据库端，在访问量大的情况下，你应该考虑缓存框架，像常用的memcache 类似的都比较 成熟了，至于缓存框架的选择，你得根据你的业务量进行选择。一旦你选择的主从或者所谓的读写分离，加上缓存，你得考虑同步、事务、以及一些失效等意外情况，挺麻烦的，这些仅仅是个思路。　　4.上面的可能有些多了，其实简单点说，访问量大的情况下：　　a.减少服务器请求压力，可以用nginx 类似的负载均衡的框架　　b.数据库访问压力大，同样你可以多部署几台,主从分离。　　c.大多情况下，请考虑缓存框架，能为你减少很多压力　　上面3点基本上能满足你的业务了，当然更麻烦的东西，得更多了，方向是这样。　　5.高并发写代码，只要你清楚了基本原理，其实现在来说并不是很难。所谓并发出现的问题主要还是怕在写入的时候出现数据错误（混乱），其实读取的情况，就是怕效率和死锁等问题，数据不会出错。主从分离后，一般情况下读数据也不会加锁，对数据的实时性，也不会要求那么高了。如果大量的写入，这考虑的就多了.如果非要说注意点什么，得注意你共享变量的读写控制，也就是说带状态的对象的操作得注意点，其他的一般都是数据库层面的的了.　　6.ibaits 更新成mybaits 了，这是orm 框架，能方便你开发，没啥好搞的，觉得方便就合适。　　7.上面的都是一些一般方法，我觉得监控是很重要的，你得想知道问题点在哪儿，才知道如何改进，还有压力测试一定要有，不然你不知道是否满足。
8.一些小建议，不对的请指出，勿喷~。~