基于java聊聊架构

工作中经常需要自己做一些架构，会积累一些简单的经验，也经常会受限于这些经验。做个简单分享，供大家交流学习。

通常情况下，架构的模式如图所示:

前端采用nginx/haproxy,后端多模块采用RPC/RMI方式进行相互调用。

问题1:为什么要使用前端

1.拦截非法请求。后端业务机直接暴露给外部会使业务机上的一些资源信息非常危险，比如数据库信息。其次网络经常会有一些扫描机扫描你的端口，然后你的后端日志就会看到一些莫名的错误。

2.前端可以起到负载均衡的作用，使流量相对均匀的分发到后端多个业务机。高并发情况下后端业务机如果只有单台是没法想象的，可能会挂了(系统内存耗尽)，即使没挂，请求到响应的时间也会非常长，严重影响用户体验。

问题2:同作为前端，nginx 与haproxy 怎么选择

nginx/haproxy 生成环境中都用过。总体感觉作为前端，nginx用起来比较简单，但是不够专业，经常会涉及到打一些补丁，比如后端检测的补丁；而haproxy虽然一开始配置起来比较麻烦，但是够专业，你能通过自带的web界面，看到各个时间片段耗费的时间。如下图:

nginx:

haproxy:

问题3:后端多模块RPC/RMI通信方式的选择

java应用程序间通信最传统的就是采用RMI方式进行方法调用，但是RMI没法穿透防火墙，因为RMI通信的端口是随机生成的，如果两个应用部署在不同机子，并且开启了防火墙，通信就会受阻。RMI采用RMI协议，该协议由jdk本身实现。RPC一般基于http协议，如http invoker，hession等，也有类似dubbo自定义一套协议，不受防火墙影响。生产环境中，如果后端模块间的调用比较简单，还是推荐用http invoker，hession之类，如果你想对后端资源做一些全局的调度监控，dubbo(最新的应该叫dubbox)更加合适。

问题4:如何评价一套框架的稳定性

1.从读取请求的第一个字节到响应请求输出最后一个字节的时间开销。客户端到前端的这段时间的开销由于受客户端本身网络环境的影响，我们是没法去保证的。我们能保证的是后端业务机之间尽快的流转。由于后端业务机一般都在局域网内，网络上通信开销耗时基本能接受，最耗时的还是业务机本身。生产环境中，遇到的后端业务机最耗时的应该是IO操作，比如从数据库读取信息。所以增加缓存是个不错的选择。还有一种情况比较常见，在统计的时候我们经常会写一些sql来得到一个最终的结果集，但是当单表的数据记录比较大(千万级别)的时候，出结果比较慢。比如统计某个渠道的当天的新增用户，执行sql比较慢。生产环境中的做法是在每个新增用户上来的时候，就对redis里面的某个key的值加1。统计的时候直接取key的值就行了。

2.单个请求响应所耗费的带宽资源。服务器端响应的内容如果有大部分是静态不变的内容，可以考虑将这部分内容迁移到cdn上，一来加快它的下载，二来减轻业务服务器的压力。