我们的技术实践

本文是我在中生代技术群分享的话题《创业一年经历的技术风雨》中的第三部分《研发团队总结的技术实践》。若要阅读第二部分《技术团队的管理》,请移步中生代技术群公众号。

与大多数团队相比,因为我们使用了小众的Scala,可以算得上是“捞偏门”了,所以总结的技术实践未必具有普适性,但对于同为Scala的友朋,或许值得借鉴一二。Scala社区发出的声音还是太小,有点孤独——“鹦其鸣也,求其友声”。

这些实践不是书本上的创作,而是在产品研发中逐渐演化而来,甚至一些实践会非常细节。不过,那个优秀的产品不是靠这些细节堆砌出来的呢?

Scala语言的技术实践

两年前我还在ThoughtWorks的时候,与同事杨云(大魔头)在一个Scala的大数据项目,利用工作之余,我结合了一些文档整理了一份Scala编码规范,放在了github上,链接地址为:https://github.com/agiledon/scala_coding_convention。

我们的产品后端全部由Scala进行开发。对于编写Scala代码,我的要求很低,只有两点:

  • 写出来的代码尽可能有scala范儿,不要看着像Java代码
  • 不要用Scala中理解太费劲儿的语法,否则不利于维护

对于Scala编程,我们还总结了几条小原则:

  • 将业务尽量分布到小的trait中,然后通过object来组合
  • 多用函数或偏函数对逻辑进行抽象
  • 用隐式转换体现关注点分离,既保证了职责的单一性,又保证了API的流畅性
  • 用getOrElse来封装需要两个分支的模式匹配
  • 对于隐式参数或支持类型转换的隐式调用,应尽量让import语句离调用近一些;对于增加方法的隐式转换(相当于C#的扩展方法),则应将import放在文件头,保持调用代码的干净
  • 在一个模块中,尽量将隐式转换定义放到implicits命名空间下,除非是特别情况需要放到package object中
  • 在不影响可读性的情况下,且无需封装任何行为,可以考虑使用tuple,而非case class
  • 在合适的地方使用lazy关键字

AKKA的技术实践

我们产品用的AKKA并不够深入,仅仅使用了AKKA的基本功能。主要用于处理前端发来的数据分析消息,相当于一个dispatcher,也承担了部分消息处理的职责,例如对消息包含的元数据进行解析,生成SQL语句,用以发送给Spark的SqlContext。分析的结果则以Future的方式返回给Spray。

几条AKKA实践的小原则:

  • actor接收的消息可以分为command和event两类。命名时,前者用动宾短语,表现为命令请求;后者则使用过去时态,体现fact的本质。
  • 产品需要支持多种数据源,不同数据源的处理逻辑放到不同的模块中,我们利用actor来解耦

以下是为AKKA的ActorRefFactory定义的工厂方法:

通过向自定义的工厂方法actorOf()传入Actor的名称来创建Actor:

  • 注意actor的sender不能离开当前的ActorContext
  • 采用类似Template Method模式的方式去扩展Actor
  • 或者以类似Decorator模式扩展Actor
  • 考虑建立符合项目要求的SupervisorStrategy
  • 尽量利用actor之间的协作来传递消息,这样就可以尽量使用tell而不是ask

Spark SQL的技术实践

目前的产品特性还未用到更高级的Spark功能。针对一些特殊的客户,我们计划采用Spark Streaming来进行流处理,除此之外,核心的数据分析功能都是使用Spark SQL。

以下是我们的一些总结:

  • 要学会使用Spark Web UI来帮助我们分析运行指标;另外,Spark本身提供了与Monitoring有关的REST接口,可以集成到自己的系统中;
  • 考虑在集群环境下使用Kryo serialization;
  • 让参与运算的数据与运算尽可能地近,在SparkConf中注意设置spark.locality值。注意,需要在不同的部署环境下修改不同的locality值;
  • 考虑Spark SQL与性能有关的配置项,例如spark.sql.inMemoryColumnarStorage.batchSize和spark.sql.shuffle.partitions;
  • Spark SQL自身对SQL执行定义了执行计划,而且从执行结果来看,对SQL执行的中间结果进行了缓存,提高了执行的性能。例如我针对相同量级的数据在相同环境下,连续执行了如下三条SQL语句:

第一次执行的SQL语句: SELECT UniqueCarrier,Origin,count(distinct(Year)) AS Year FROM airline GROUP BY UniqueCarrier,Origin 第二次执行的SQL语句: SELECT UniqueCarrier,Dest,count(distinct(Year)) AS Year FROM airline GROUP BY UniqueCarrier,Dest 第三次执行的SQL语句: SELECT Dest , Origin , count(distinct(Year)) AS Year FROM airline GROUP BY Dest , Origin

观察执行的结果如下所示:

观察执行count操作的job,显然第一次执行SQL时的耗时最长,达到2s,而另外两个job执行的时间则不到一秒。

  • 针对复杂的数据分析,要学会充分利用Spark提供的函数扩展机制:UDF((User Defined Function)与UDAF(User Defined Aggregation Function);详细内容,请阅读文章《Spark强大的函数扩展功能》。

React+Redux的技术实践

我们一开始并没有用好React+Redux。随着对它们的逐渐熟悉,结合社区的一些实践,我们慢慢体会到了其中的一些好处,也摸索出一些好的实践。

  • 遵循组件设计的原则,我们将React组件分为Component与Container两种,前者为纯组件。

组件设计的原则

  • 一个纯组件利用props接受所有它需要的数据,类似一个函数的入参,除此之外它不会被任何其它因素影响;
  • 一个纯组件通常没有内部状态。它用来渲染的数据完全来自于输入props,使用相同的props来渲染相同的纯组件多次,
  • 将得到相同的UI。不存在隐藏的内部状态导致渲染不同。
  • 在React中尽可能使用extends而不是mixin;
  • 对State进行范式化,不要定义嵌套的State结构,不同数据的相互引用都通过ID来查找。范式化的state可以更有效地利用Store里存储空间;
  • 如果不能更改后端返回的模型,可以考虑使用normalizr;但在我们的项目中,为了满足这一要求,我们专门修改了后端的API。因为采用了之前介绍的元数据架构,这个修改主要影响到了REST路由层和应用服务层的部分代码;
  • 遵循Redux的三大基本原则;

Redux的三大基本原则

  • 单一数据源
  • State 是只读的
  • 使用纯函数来执行修改

在我们的项目中,将所有向后台发送异步请求的操作都封装到service中,action会调用这些服务。我们使用了redux-actions的createAction创建dispatch需要的消息:

在Reducer中,通过redux-actions的handleAction来处理action,避免使用丑陋的switch语句:

在Container组件中,如果Store里面的模型对象需要根据id进行filter或merge之类的操作,则交给selector对其进行封装。于是Container组件中就可以这样来调用:

  • 使用eslint来检查代码是否遵循ES编写规范;为了避免团队成员编写的代码不遵守这个规范,甚至可以在git push之前将lint检查加入到hook中:

echo "npm run lint" > .git/hooks/pre-push chmod +x .git/hooks/pre-push

Spray与REST的技术实践

我们的一些总结:

  • 站在资源(名词)的角度去思考REST服务,并遵循REST的规范;
  • 考虑GET、PUT、POST、DELETE的安全性与幂等性;
  • 必须为REST服务编写API文档,并即使更新;
  • 使用REST CLIENT对REST服务进行测试,而不能盲目地信任Spray提供的ScalatestRouteTest对客户端请求的模拟,因为这种模拟其实省略了对Json对象的序列化与反序列化;
  • 为核心的REST服务提供健康服务检查;
  • 在Spray中,尽量将自定义的HttpService定义为trait,这样更利于对它的测试;在自定义的HttpService中,采用cake pattern(使用Self Type)的方式将HttpService注入;
  • 我个人不太喜欢Spray以DSL方式编写REST服务,因为它可能让函数的嵌套层次太深;如果在一个HttpService(在我们的项目中,皆命名为Router)中,提供的服务较多,建议将各个REST动作都抽取为一个返回Route对象的私有函数,然后利用RouteConcatenation的~运算符拼接起来,以便于阅读:
  • Spray默认对Json序列化的支持是使用的是Json4s,为此Spray提供了Json4sSupport trait;如果需要支持更多自定义类型的Json序列化,需要重写隐式值json4sFormats;建议将这些隐式定义放到Object中,交由Router引用,而不是定义为trait去继承。因为并非Router都使用Json格式,由于trait定义的继承传递性,可能会导致未使用Json格式的Router出现错误;
  • Json4s可以支持Scala的大多数类型,包括Option等,但不能很好地支持Scala枚举以及复杂的嵌套递归结构,包括多态。这时需要自定义Serializer,具体做法可以参考我在知乎专栏上的文章,请通过点击「阅读原文」阅读。

整个技术分享内容包括产品的技术架构、技术选型与技术实践并非我一个人的体会,而是整个研发团队的知识荟萃,我只是将这些知识搬运过来介绍给大家罢了。所以还要谢谢我研发团队的兄弟们。

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

原文发表时间:2016-05-03

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏贤羽的前端小栈

探索 PHP 与 Vue 通用直出模板方案

我们通常说的“页面直出”,其实就是服务端渲染(SSR, Server-Side Render)。最初的 JS SPA 方案有个常见的问题,就是脚本没有加载执行完...

2.4K2
来自专栏数据和云

防不胜防:一个空格在数据库里可能引发的N重血案

杨廷琨(网名 Yangtingkun) 云和恩墨 CTO,Oracle ACE Director,ACOUG 核心专家 编辑手记:在Oracle DBA的...

2624
来自专栏我杨某人的青春满是悔恨

如何提高代码品味

写代码虽然大多数时候是个体力活,但不可否认,也需要一点品位。我曾经觉得代码质量很重要,后来写业务写多了,又觉得如果连代码正确都做不到,又谈何代码质量。后来我又醒...

622
来自专栏北京马哥教育

Python面试必须要看的15个问题

引言 想找一份Python开发工作吗?那你很可能得证明自己知道如何使用Python。下面这些问题涉及了与Python相关的许多技能,问题的关注点主要是语言本身...

3589
来自专栏java达人

为什么又要造一个叫 Latke 的轮子

欢迎投稿 黑客派作品 框架 使用框架的好处很多,它规范了我们的开发方式,减少了出错的可能性,让我们可以更快地完成开发目标,后续维护也可以有章可循;使用框架的弊...

1785
来自专栏Java3y

纳税服务系统七(投诉管理模块)【显示投诉信息、处理回复、我要投诉、Quartz自动受理、统计图FusionCharts】

投诉受理管理模块 接下来,就是来开发我们的投诉受理管理模块了…..我们来看看原型图与需求吧: 查询用户提交的投诉信息,可以根据投诉部门(部门A/B)、投诉时间段...

4267
来自专栏互联网杂技

AngularJS与服务器端MVC比较

这是一篇讨论客户端MVC和服务器端MVC的比较文章。 首先分离关注是架构设计的一个基本原则,多层架构中:数据存储 服务层 API层和表现层各层之间应该最小依赖...

3354
来自专栏web前端教室

今天-零基础课的教学事故及全过程

有什么说什么,有错了就要认。 “今天我有个地方讲错了”,“然后我还说提出问题的同学有点过于纠结”。出问题要说清楚,来,事情是这样的。。。 ? 截图一中,点击事件...

1646
来自专栏Java帮帮-微信公众号-技术文章全总结

solr使用教程二【面试+工作】

6.3高亮显示 我们经常使用搜索引擎,比如在baidu 搜索 java ,会出现如下结果,结果中与关键字匹配的地方是红色显示与其他内容区别开来。 solr 默认...

3827
来自专栏一个会写诗的程序员的博客

《Kotlin极简教程》第一章 Kotlin简介100% interoperable with Java™

JetBrains开源其Kotlin语言 基于JVM的新编程语言。 Kotlin,类似 Xtend 一样,旨在提供一种更好的 Java 而非重建整个新平台。这...

822

扫码关注云+社区