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

0 0

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

有个项目需要重构：原来一个java后端服务的项目，用的是简单的servlet和JDBC 为 android app 提供的api，并发访问通过单例、线程池和多线程、缓存做的。
现在相对这个项目进行重构，考虑设计一套 restful风格的api,不知道有什么成熟的 rest框架可以推荐下。数据库部分的框架ibaits是否合适？高并发访问在写代码的时候又应该注意那些地方？总结下：
在高并发访问，主从多数据库的情况下，
1、restFUL api 该选用什么成熟的框架？
2、数据库部分选用什么框架比较合适，多数据配置该注意哪些？
3、在以上框架的基础上，代码有哪些地方需要注意？

4、以前那种简单粗暴设计有什么缺点？大家可以吐槽。

能给点儿意见的都给点儿意见吧，有指导性的相关链接也可以。我刚接触app后端设计这方面，虚心求教学习。只有30分，全给了。

问题补充：我现在的考虑是： springMVC + ibaits. redis 做分布式缓存，mysql主从读写分离， apache tomcat +nginx 部署。 rest并不是必须的。
高并发代码注意点暂时没有什么头绪。

2014年5月12日 00:19

louistz
6
0 0 4

7个答案按时间排序按投票排序

0 0

采纳的答案

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.一些小建议，不对的请指出，勿喷~。~

2014年5月12日 11:26

greemranqq
58
0 1 11

1条评论

0 0

大并发一般现在比较流行的是通过云端部署，没有云服务的话也可以通过tomcat自己做集群处理，这样的处理一般要求业务比较简单，一个事务中处理时间足够短。

数据库看你要不要横向或纵向分库，如果需要，不建议使用ibaits。
且分库之后要通过业务限制跨库查询的操作
横向分库相对比较简单:
1. 根据表分库，读取写入数据时根据表名确定获取哪个connection
2. 也可以根据条件获取connection，这样更限制你的查询条件，必须每个select中都包含分库条件的字段。
纵向分库则更加复杂，一般使用动态数据源，动态分库。需要做到这一步的话，建议使用淘宝的tddl做

基本设计到分库，一般数据量都够大，数据库就mysql了

如果只是横向分库的话，JPA框架应该都可以实现。

至于restful API,搞个jaxrs 好了

缓存，多线程之类的，这个根据业务需要看怎么处理合适了。
效率要比较高的话，可以模块化部署，通过内部消息框架通讯
如一些统计，校对，报表等操作，可以单独部署，一些计算可以部署成无状态的服务，内存计算还是很快的。
消息可以使用JMS，同样也可以使用一些框架，如HSF 也比较牛逼。

简单粗暴的方法可以使用阿里云的分布式数据库，这样不用关心存储了，部署也同样可以使用云服务，这样不用担心并发了。

2014年5月12日 21:19

chenxiang105
2039
0 0 7

添加评论

0 0

如果你在意数据库速度，可以考虑用VOLTDB：一款高速度的内存数据库。

2014年5月12日 12:06

foxsky
30
0 0 0

添加评论

0 0

dropwizard java rest 快速开发框架我在用

2014年5月12日 09:54

kaelrock
25
0 0 3

添加评论

0 0

https://github.com/MaOrKsSi/HZS.Durian

这是一款基于scoket、安全的、针对管理软件的框架。只提供数据服务，不提供资源服务，而且限制并发数量。你可以参考并修改，但框架本身必需保持开源。

2014年5月12日 09:32

foxsky
30
0 0 0

1条评论

0 0

首先第一点，不能为了rest而rest，而是要看自己的应用场景，其实最后性能的瓶颈点不会在MVC框架上，只要这个MVC框架是比较靠谱的框架。

最后的性能点会是：

1. 服务器的内核参数调整，使之能支持高并发的连接，默认是不太能支持的。
2. 缓存的使用，使用得当可以提大地提升系统的性能。
3. 数据库层的优化，当数据大了以后，数据库的优化就显得很重要了，特别是在设计的时候可能就需要反范式来设计了。
4. 如果有多线程的话，就是线程竞争和数据不一致的问题。

2014年5月12日 09:10

lbfhappy
281
0 0 15

添加评论

0 0

rest现在有好多个实现，比如借助springmvc实现的rest，jboss的resteasy，restlet？jersey？cxf？大概名字记不清了，从方向性文档性发展性来讲推荐3个，如果和spring集成那还是springmvc实现的是不是更好些，虽然其他几个也都能很轻轻的集成，如果有洁癖或者正统思想resteasy也不错（这里只是说它是比较遵守标准相对于springmvc），如果一直中意apache，那么cxf又是一个选择。
如果高并发，是不是选择分布式缓存或nosql数据库？多数据库都是自己搞的，没有什么框架专门针对多数据库数据源的吧。
架构不是我来搭建，代码不是我来编写，所以技术选型应该从你们本身来选，最终的并发量访问量不是一个高字就能描述的。
另外rest本身就不同于平时的风格，它是以资源为中心的，不一定适合你们的应用。
以上，你就算给几百分也解决不了你的问题，几百人回答会有几百答案，结合实际才是最终选择！首先你要做的是需求调研或预估，然后技术调研，团队人员构成，时间，成本。

2014年5月12日 06:59

zhuyx808
91
0 0 1

添加评论

已解决问题

未解决问题

排行榜

查看全部排名>>