我们的技术选型

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

开发语言的选型

我们选择的语言是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 条评论
登录 后参与评论

相关文章

来自专栏Java技术

一篇故事告诉你什么是微服务架构!

看到最近“微服务架构”这个概念这么火,作为一个积极上进的程序猿,成小胖忍不住想要学习学习。而架构师老王(不是隔壁老王)最近刚好在做公司基础服务的微服务化研究和落...

763
来自专栏Java技术

2018年微服务将疯狂至死?带你领略不一样的思维历程!

原文作者:Dave Kerr;原文地址:https://www.jdon.com/49261

1654
来自专栏pangguoming

Hadoop概念学习系列之Hadoop、Spark学习路线(很值得推荐)

说在前面的话   此笔,对于仅对于Hadoop和Spark初中学者。高手请忽略! 1 Java基础: 视频方面:           推荐《毕向东JAVA基础...

4737
来自专栏云计算D1net

裸机云服务优缺点

裸机云计算服务综合了物理服务器和公共云两者的优点,但是这可能并不适用于所有的工作负载。用户在做出决定之前应权衡利弊。 在某些情况下,公共云服务无法为管理员提供全...

2938
来自专栏云计算D1net

私有存储云如何构建?

构建内部的云存储必须考虑到弹性、选择正确的平台、支持工作流,以及批量部署和跟公有云的集成。 随着时间的推移,存储即服务的交付进展惊人。如今,公有云,如Amazo...

3035
来自专栏架构师小秘圈

微服务改造那些痛

1284
来自专栏方俊贤的专栏

微服务架构 : 从既有的架构迁移到微服务的策略 ( 二 )

全世界没有任何的一个系统, 可一步到位的, 就达到微服务核心概念中, 所谈及的架构上的要求。 我们真正应该要做的事是: 找出将既有架构迁移到微服务的策略、方法、...

2032
来自专栏程序你好

应用服务网格(Service Mesh)应对微服务中面临的三种挑战

微服务适用于开发运维(DevOps),可是这些架构依赖的服务到服务通信在生产环境下运行和管理起来很复杂。这时候Service Mesh闪亮登场了:这是企业扩展、...

893
来自专栏SDNLAB

【双语频道】ONOS架构原理

The purpose of this ONOS talk is to convey the rationale behind our approach to ...

3139
来自专栏Java技术栈

2017年,Java程序猿10本经典好书推荐

1、Java 8实战 本书全面介绍了Java 8 这个里程碑版本的新特性,包括Lambdas、流和函数式编程。有了函数式的编程特性,可以让代码更简洁,同时也能自...

38612

扫码关注云+社区