我们的技术选型

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

开发语言的选型

我们选择的语言是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的最佳实践。

结论

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

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

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2016-04-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏非著名程序员

听说 Flutter 最近要多火爆就有多火爆,那就推荐一个不错的系列文章吧

就在上上周Flutter 发布首个预览版,Flutter 是谷歌的移动 UI 框架,可以快速在 iOS 和 Android 上构建高质量的原生用户界面。 Flu...

1334
来自专栏编程软文

一大波编程视频资料赠送(亲自整理)

2219
来自专栏互联网数据官iCDO

跳出率骗局,带你洞察跳出率背后的真相

虽然保持一个较低的平均跳出率是网站优化的很重要的部分,但是许多人并不真的了解跳出率对转化真正的作用。

1133
来自专栏竹清助手

如何优化长尾关键词

对于很多小站长或者刚入职的推广人员来说,负责行业的核心关键词应该早就被其他竞争对手给抢先占有排名了,短期内应该是无法通过正常的seo优化来抢夺流量,因此长尾关键...

653
来自专栏听雨堂

微信小程序价值思考:手机端的CS-BS迁移

从很多特点来看,小程序都非常类似于网页:主要的业务逻辑在服务端、客户端无需安装应用程序、小程序的开发采用的HTML+JS+CSS技术等等。张小龙自己对小程序的定...

5767
来自专栏Wordpress专用主机|主题模板|必备插件

6款最佳WORDPRESS免费主题模板:GENERATEPRESS位列榜首

无论你的网站是什么内容,是什么行业,访客首先关注的是你的主题(外观),毕竟颜值即正义的时代。所以,对于Worpdress网站来讲,主题的重要性不言而喻。 今晚博...

3525
来自专栏前端桃园

如何学习一个框架

昨天我在一个群里有一个人在问,谁会 rxjs?我当时其实还有点好奇,对于 rxjs 我一直觉得很难,前阵子我也一直在研究。

691
来自专栏IMWeb前端团队

积木系统,将运营系统做到极致

本文作者:IMWeb 江源 原文出处:IMWeb社区 未经同意,禁止转载 积木系统上线半年,取得了些成绩,也暴露出不少问题,加上 2.0 版本也准备开...

1.7K5
来自专栏木东居士的专栏

聊一聊 ETL 的设计

4594
来自专栏知晓程序

微信小程序发布时间出炉!全面了解小程序的前世今生

1053

扫码关注云+社区