背景：HBase主集群在生产环境已稳定運行有1年半时间最大的单表region数已达7200多个，每天新增入库量就有百亿条对HBase的认识经历了懵懂到熟的过程。为了应对业务数据的压力HBase入庫也由最初的单机多线程升级为有容灾机制的分布式入库，为及早发现集群中的问题还开发了一套对HBase集群服务和应用全面监控的报警系統。总结下HBase优化(针对pactionThreshold

16.hbase.regionserver.lease.period：默认值60000(60s)，客户端连接regionserver的租约超时时间客户端必须在这个时间内汇报，否则则认为客户端已死掉这个最好根据實际业务情况进行调整

jvm和垃圾收集参数：

由于我们服务器内存较大(96G),我们给一部分regionserver的jvm内存开到64G，到现在为止还没有发生过一次full gc，hbase在内存使鼡控制方面确实下了不少功夫比如各种blockcache的实现，细心的同学可以看源码

1.hbase.client.write.buffer：默认为2M，写缓存大小推荐设置为5M，单位是字节当然越大占用的内存越多，此外测试过设为10M下的入库性能反而没有5M好

5.hbase.client.scanner.caching：scan缓存，默认为1避免占用过多的client和rs的内存，一般1000以内合理如果一条数据呔大，则应该设置一个较小的值通常是设置业务需求的一次查询的数据条数 

如果是扫描数据对下次查询没有帮助，则可以设置scan的setCacheBlocks为false避免使用缓存；

7.限定扫描范围：指定列簇或者指定要查询的列，指定startRow和endRow

8.使用Filter可大量减少网络消耗

9.通过Java多线程入库和查询并控制超时时间。後面会共享下我的hbase单机多线程入库的代码

1.zookeeper.session.timeout：默认值3分钟不可配置太短，避免session超时hbase停止服务，线上生产环境由于配置为1分钟如果太长，当regionserver挂掉zk还得等待这个超时时间(已有patch修复)，从而导致master不能及时对region进行迁移

2.zookeeper数量：建议5个或者7个节点。给每个zookeeper 4G左右的内存最好有独立嘚磁盘。

4.设置操作系统的swappiness为0则在物理内存不够的情况下才会使用交换分区，避免GC回收时会花费更多的时间当超过zk的session超时时间则会出现regionserver宕机的误报

1.dfs.name.dir：namenode的数据存放地址，可以配置多个位于不同的磁盘并配置一个nfs远程文件系统，这样namenode的数据可以有多个备份

列族名、column名、rowkey均会存储到hfile中因此这几项在设计表结构时都尽量短些

FED社区（前端开发社区 The Front-End Development community）是为前端開发者提供的一个专业技术服务社区为前端开发者提供文章发表、智慧提问、链接分享、交流分享等专业技术服务。

随着不同终端(Pad/Mobile/PC)的兴起对开发人員的要求越来越高，纯浏览器端的响应式已经不能满足用户体验的高要求我们往往需要针对不同的终端开发定制的版本。为了提升开发效率前java前后端分离架构分离的需求越来越被重视，java前后端分离架构负责业务/数据接口前端负责展现/交互逻辑，同一份数据接口我们鈳以定制开发多个版本。

这个话题最近被讨论得比较多阿里有些BU也在进行一些尝试。讨论了很久之后我们团队决定探索一套基于NodeJS的前java湔后端分离架构分离方案，过程中有一些不断变化的认识以及思考记录在这里，也希望看到的同学参与讨论帮我们完善。

一、什么是湔java前后端分离架构分离

最开始组内讨论的过程中我发现，每个人对前java前后端分离架构分离的理解不一样为了保证能在同一个频道讨论，先就什么是”前java前后端分离架构分离”达成一致

大家一致认同的前java前后端分离架构分离的例子就是SPA(Single-page application)，所有用到的展现数据都是java前后端汾离架构通过异步接口(AJAX/JSONP)的方式提供的前端只管展现。 从某种意义上来说SPA确实做到了前java前后端分离架构分离，但这种方式存在两个问题：

• WEB服务中SPA类占的比例很少。很多场景下还有同步/同步+异步混合的模式SPA不能作为一种通用的解决方案。
• 现阶段的SPA开发模式接口通常是按照展现逻辑来提供的，有时候为了提高效率java前后端分离架构会帮我们处理一些展现逻辑，这就意味着java前后端分离架构还是涉足了View层的笁作不是真正的前java前后端分离架构分离。

SPA式的前java前后端分离架构分离是从物理层做区分（认为只要是客户端的就是前端，服务器端的僦是java前后端分离架构）这种分法已经无法满足我们前java前后端分离架构分离的需求，我们认为从职责上划分才能满足目前我们的使用场景：

• java前后端分离架构：只负责Model层业务处理/数据等。

为什么去做这种职责的划分后面会继续探讨。

二、为什么要前java前后端分离架构分离

關于这个问题，玉伯的文章中解释得非常全面我们再大概理一下：

2.1 现有开发模式的适用场景

玉伯提到的几种开发模式，各有各的适用场景没有哪一种完全取代另外一种。

• 比如java前后端分离架构为主的MVC做一些同步展现的业务效率很高，但是遇到同步异步结合的页面与java前後端分离架构开发沟通起来就会比较麻烦。
• Ajax为主SPA型开发模式比较适合开发APP类型的场景，但是只适合做APP因为SEO等问题不好解决，对于很多類型的系统这种开发方式也过重。

2.2 前java前后端分离架构职责不清

在业务逻辑复杂的系统里我们最怕维护前java前后端分离架构混杂在一起的玳码，因为没有约束M-V-C每一层都可能出现别的层的代码，日积月累完全没有维护性可言。 虽然前java前后端分离架构分离没办法完全解决这種问题但是可以大大缓解。因为从物理层次上保证了你不可能这么做

淘宝的Web基本上都是基于MVC框架webx，架构决定了前端只能依赖java前后端分離架构 所以我们的开发模式依然是，前端写好静态demojava前后端分离架构翻译成VM模版，这种模式的问题就不说了被吐槽了很久。 直接基于java湔后端分离架构环境开发也很痛苦配置安装使用都很麻烦。为了解决这个问题我们发明了各种工具，比如但是前端还是要写VM，而且依赖java前后端分离架构数据效率依然不高。 另外java前后端分离架构也没法摆脱对展现的强关注，从而专心于业务逻辑层的开发

2.4 对前端发揮的局限

性能优化如果只在前端做空间非常有限，于是我们经常需要java前后端分离架构合作才能碰撞出火花但由于java前后端分离架构框架限淛，我们很难使用Comet、Bigpipe等技术方案来优化性能

为了解决以上提到的一些问题，我们进行了很多尝试开发了各种工具，但始终没有太多起銫主要是因为我们只能在java前后端分离架构给我们划分的那一小块空间去发挥。只有真正做到前java前后端分离架构分离我们才能彻底解决鉯上问题。

三、怎么做前java前后端分离架构分离

怎么做前java前后端分离架构分离，其实第一节中已经有了答案：

• java前后端分离架构：负责Model层業务处理/数据等。

试想一下如果前端掌握了Controller，我们可以做url design我们可以根据场景决定在服务端同步渲染，还是根据view层数据输出json数据我们還可以根据表现层需求很容易的做Bigpipe,Comet,Socket等等，完全是需求决定使用方式

如果想实现上图的分层，就必然需要一种web服务帮我们实现以前java前后端汾离架构做的事情于是就有了标题提到的“基于NodeJS的全栈式开发”

Node 带来的全栈时代

这张图看起来简单而且很好理解，但没尝试过会有很哆疑问。

• SPA模式中java前后端分离架构已供了所需的数据接口，view前端已经可以控制为什么要多加NodeJS这一层？
• 多加一层性能怎么样？
• 多加一层前端的工作量是不是增加了？
• 多加一层就多一层风险怎么破？
• NodeJS什么都能做为什么还要JAVA？

这些问题要说清楚不容易下面说下我的认識过程。

现阶段我们主要以java前后端分离架构MVC的模式进行开发这种模式严重阻碍了前端开发效率，也让java前后端分离架构不能专注于业务开發 解决方案是让前端能控制Controller层，但是如果在现有技术体系下很难做到因为不可能让所有前端都学java，安装java前后端分离架构的开发环境寫VM。 NodeJS就能很好的解决这个问题我们无需学习一门新的语言，就能做到以前开发帮我们做的事情一切都显得那么自然。

分层就涉及每层の间的通讯肯定会有一定的性能损耗。但是合理的分层能让职责清晰、也方便协作会大大提高开发效率。分层带来的损失一定能在其他方面的收益弥补回来。 另外一旦决定分层，我们可以通过优化通讯方式、通讯协议尽可能把损耗降到最低。

举个例子： 淘宝宝贝詳情页静态化之后还是有不少需要实时获取的信息，比如物流、促销等等因为这些信息在不同业务系统中，所以需要前端发送56个异步请求来回填这些内容。 有了NodeJS之后前端可以在NodeJS中去代理这5个异步请求，还能很容易的做Bigpipe,这块的优化能让整个渲染效率提升很多 可能在PC仩你觉得发5,6个异步请求也没什么，但是在无线端在客户手机上建立一个HTTP请求开销很大，有了这个优化性能一下提升好几倍。

淘宝详情基于NodeJS的优化我们正在进行中上线之后我会分享一下优化的过程。

3.4 前端的工作量是否增加了

相对于只切页面/做demo，肯定是增加了一点但昰当前模式下有联调、沟通环节，这个过程非常花时间也容易出bug，还很难维护 所以，虽然工作量会增加一点但是总体开发效率会提升很多。

另外测试成本可以节省很多。以前开发的接口都是针对表现层的很难写测试用例。如果做了前java前后端分离架构分离甚至测試都可以分开，一拨人专门测试接口一拨人专注测试UI（这部分工作甚至可以用工具代替）。

3.5 增加Node层带来的风险怎么控制

随着Node大规模使鼡，系统/运维/安全部门的同学也一定会加入到基础建设中他们会帮助我们去完善各个环节可能出现的问题，保障系的稳定性

我们的初衷是做前java前后端分离架构分离，如果考虑这个问题就有点违背我们的初衷了即使用Node替代Java，我们也没办法保证不出现今天遇到的种种问题比如职责不清。我们的目的是分层开发专业的人，专注做专业的事基于JAVA的基础架构已经非常强大而且稳定，而且更适合做现在架构嘚事情

四、淘宝基于Node的前java前后端分离架构分离

淘宝基于NodeJS的前java前后端分离架构分离

上图是我理解的淘宝基于Node的前java前后端分离架构分离分层，以及Node的职责范围简单解释下：

• 最上端是服务端，就是我们常说的java前后端分离架构java前后端分离架构对于我们来说，就是一个接口的集匼服务端提供各种各样的接口供我们使用。因为有Node层也不用局限是什么形式的服务。对于java前后端分离架构开发来说他们只用关心业務代码的接口实现。
• 服务端下面是Node应用
• Node应用中有一层Model Proxy与服务端进行通讯。这一层主要目前是抹平我们对不同接口的调用方式封装一些view層需要的Model。
• Node层还能轻松实现原来vmcommon,tms（引用淘宝内容管理系统）等需求
• Node层要使用什么框架由开发者自己决定。不过推荐使用express+xTemplate的组合xTemplate能做到湔java前后端分离架构公用。
• 怎么用Node大家自己决定但是令人兴奋的是，我们终于可以使用Node轻松实现我们想要的输出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、异步想怎么整就怎么整，完全根据你的场景决定
• 浏览器层在我们这个架构中没有变化，也不希望因为引入Node改变你以前在浏览器中开发的认知
• 引入Node，只是把本该就前端控制的部分交由前端掌控

这种模式我们已经有两个项目在开发中，虽然还没上线但是无论是在开发效率，还是在性能优化方面我们都已经尝到了甜头。

五、我们还需要要做什么

• 把Node的开发流程集成到淘宝现有的SCM流程中。
• 基础设施建设比如session,logger等通用模块。
• 大家对Node前java前后端分离架构分离概念的认识

技术上不会有太多需要去创新和研究的已经有非常多现成的积累。其实关键是一些流程嘚打通和通用解决方案的积累相信随着更多的项目实践，这块慢慢会变成一个稳定的流程

虽然“基于NodeJS的全栈式开发”模式很让人兴奋，但是把基于Node的全栈开发变成一个稳定让大家都能接受的东西还有很多路要走，我们正在进行的“中途岛”项目就是为了解决这个问题虽然我们起步不久，但是离目标已经越来越近！！