我们的技术选型

本文是我在中生代技术群分享的话题《创业一年经历的技术风雨》中的第一部分《产品架构与技术选型》的第二部分。我要谈的是我们产品研发过程中的技术选型。

开发语言的选型

我们选择的语言是Scala。选择它的一个主因是因为Spark；另一个原因呢？或许是因为我确实不想再写Java代码了。

其实有时候我觉得语言的选型是没有什么道理的。除了特殊的应用场景，几乎所有的程序设计语言都能满足如今的软件开发需求。所以我悲哀地看到，语言的纷争成了宗教的纷争。

在我们团队，有熟悉Java的、有熟悉JavaScript包括NodeJS的，有熟悉Clojure的，当然也有熟悉Scala的。除了NodeJS，后端开发几乎都在JVM平台下。

我对语言选型的判断标准是：实用、高效、简洁、可维护。我对Java没有成见，但我始终认为：即使引入了Lambda以及Method Reference，Java 8在语法方面还是太冗长了。

Scala似乎从诞生开始，一直争议很大。早在2014年1月ThoughtWorks的Tech Radar中，就讲Scala列入了Adopt圈中，但却在其中特别标注了“the good parts”：

在2016年Stack Overflow发布的开发人员调查结果中，我们也收获了一些信心。在最爱语言的调查中，Scala排在了第四名：

在引领技术趋势的调查中，我们选用的React与Spark分列冠亚军：

在Top Paying Tech调查中，在美国学习Spark和Scala所值不菲，居然并列冠军：

其实有了微服务，在不影响代码维护性的情况下，使用多语言进行开发也成为了可能。或许在将来，我们产品的可能会用clojure或者Ruby来写DSL，用NodeJS负责元数据（以避免Spray + JSON4S不太好的Json对象序列化）。

说明：将元数据管理单独独立为一个NodeJS服务，已经列到了后续架构演进的计划中。针对元数据管理，我们会统一成JavaScript技术栈，从前端到后端再到数据库，统一为React+ES6、NodeJS和MongoDB。

坦白说，我没有强烈的语言倾向性。

数据集的选型

我们还有一个最初的技术选型，后来被认为是失败的选择。

CData服务需要将客户的数据源经过简单的ETL导入到系统中，我们称之为数据集（DataSet）。最初在进行技术选型时，我先后考虑过MySQL、Cassandra、HBase。后面两种都属于列式存储的NoSQL数据库。团队中没有一个人有Cassandra的经验，至于HBase，虽然支持高效的数据查询，但对聚合运算的支持明显不足，不适合我们的场景。再加上团队中有一位成员比较熟悉MySQL，我最终决定使用MySQL。

然而，我们的产品需要支持大数据，当数据量上升到一定级别时，就需要系统很好地支持水平扩展，通过增加更多机器来满足性能上的需求。评估我们的架构，后端平台可以简单划分为三个层次：Web应用服务层（Spray + Nginix）、数据分析层（MESOS + Spark）以及存储层（主要用于存储分析数据DataSet，MySQL）。显然，MySQL会成为水平伸缩的最大障碍。

还好我们醒悟得早，在项目初期就否定了这个方案，而改为采用HDFS+Parquet。

Parquet文件是一种列式数据存储结构，对于主要为分析型查询方式的BI数据操作，能够提供更好的查询性能。同时，Parquet文件存储的内容以二进制形式存放，相较于文本形式容量更小，可以节省更多的存储空间。

Spark SQL提供了对访问Parquet文件很好的集成。将Parquet文件存放到HDFS中，然后再通过Spark SQL访问，可以保证在存储层与数据分析层都能很好地支持分布式处理，从而保证系统的水平伸缩。当对大规模数据集进行分析处理时，可以通过水平增加更多的节点来满足高性能的实时查询要求。

我们曾经比较了Parquet方案与MySQL方案，在同等配置下前者的性能要远远优于后者，且Spark对Parquet的支持也要好于MySQL。

为了更好地提升性能，我们还计划在HDFS层之上引入Tachyon，充分发挥内存的优势，减少磁盘IO带来的性能损耗。

前端的技术选型

前端的技术选型则为React + Redux。选择React的原因很简单，一方面我们认为这种component方式的前端开发，可以极大地提高UI控件的重用，另一方面，我们认为React这种虚拟DOM的方式在性能上存在一定优势。此外，React的学习曲线也不高，很容易上手。我们招了3个大学还未毕业的实习生，JS基础非常薄弱，在我们的培养下，一周后就可以慢慢开始完成React Component开发的小Story了。

在最初的团队，我们仅有一位前端开发。他选择了使用CoffeeScript来开发React，但是在项目早期，我们还是忍痛去掉了这些代码，改为使用ES 6。毕竟随着ES 6乃至ES 7的普及，JS的标准已经变得越来越合理，CoffeeScript的生存空间似乎被压缩了。

在前端技术选型方面，我们经历了好几次演变。从CoffeeScript到ES 6，从Reflux到Redux，每次变化都在一定程度上增加了工作量。我在文章《技术选型的理想与现实》中讲述的就是这个故事。

在《技术选型的理想与现实》这篇文章中，我讲到我们选择了Reflux。然而到现在，最终还是迁移到了Redux。我们一开始并没有用好Redux，最近的一次重构才让代码更符合Redux的最佳实践。

结论

技术负责人一个非常重要的能力要求就是——善于做出好的技术决策。选择技术时，并不能一味追求新技术，也不能以自我为中心，选择“我”认为好的技术。而应该根据产品的需求场景、可能的技术风险、团队成员能力，并通过分析未来的技术发展趋势综合地判断。

技术决策不可能一成不变，需要与时俱进。如果发现决策错误，应该及时纠正，不要迟疑，更不要担心会影响自己的技术声誉。