快速了解Scala技术栈
我無可救藥地成為了Scala的超級粉絲。在我使用Scala開發項目以及編寫框架后，它就仿佛凝聚成為一個巨大的黑洞，吸引力使我不得不飛向它，以至于開始背離Java。固然Java 8為Java陣營增添了一絲亮色，卻是望眼欲穿，千呼萬喚始出來。而Scala程序員，卻早就在享受lambda、高階函數、trait、隱式轉換等帶來的福利了。
Java像是一頭史前巨獸，它在OO的方向上幾乎走到了極致，硬將它拉入FP陣營，確乎有些強人所難了。而Scala則不，因為它的誕生就是OO與FP的混血兒——完美的基因融合。
“Object-Oriented Meets Functional”，這是Scala語言官方網站上飄揚的旗幟。這也是Scala的野心，當然，也是Martin Odersky的雄心。
相關廠商內容
看Scala如何顛覆傳統金融企業
在容器時代，云計算下一步將如何發展？
微眾架構首秀--基于自主可控技術的分布式架構實踐
企業級SaaS應用平臺--釘釘技術歷程之路
看一號店如何直擊電商系統痛點！
相關贊助商
全球架構師峰會，12月18-19日，北京·國際會議中心，精彩內容邀您參與！
Scala社區的發展
然而，一門語言并不能孤立地存在，必須提供依附的平臺，以及圍繞它建立的生態圈。不如此，語言則不足以壯大。Ruby很優秀，但如果沒有Ruby On Rails的推動，也很難發展到今天這個地步。Scala同樣如此。反過來，當我們在使用一門語言時，也要選擇符合這門語言的技術棧，在整個生態圈中找到適合具體場景的框架或工具。
當然，我們在使用Scala進行軟件開發時，亦可以尋求龐大的Java社區支持；可是，如果選擇調用Java開發的庫，就會犧牲掉Scala給我們帶來的福利。幸運的是，在如今，多數情況你已不必如此。伴隨著Scala語言逐漸形成的Scala社區，已經開始慢慢形成相對完整的Scala技術棧。無論是企業開發、自動化測試或者大數據領域，這些框架或工具已經非常完整地呈現了Scala開發的生態系統。
快速了解Scala技術棧
若要了解Scala技術棧，并快速學習這些框架，一個好的方法是下載typesafe推出的Activator。它提供了相對富足的基于Scala以及Scala主流框架的開發模板，這其中實則還隱含了typesafe為Scala開發提供的最佳實踐與指導。下圖是Activator模板的截圖：
那么，是否有渠道可以整體地獲知Scala技術棧到底包括哪些框架或工具，以及它們的特性與使用場景呢？感謝Lauris Dzilums以及其他在Github的Contributors。在Lauris Dzilums的Github上，他建立了名為awesome-scala的Repository，搜羅了當下主要的基于Scala開發的框架與工具，涉及到的領域包括：
- Database
- Web Frameworks
- i18n
- Authentication
- Testing
- JSON Manipulation
- Serialization
- Science and Data Analysis
- Big Data
- Functional Reactive Programming
- Modularization and Dependency Injection
- Distributed Systems
- Extensions
- Android
- HTTP
- Semantic Web
- Metrics and Monitoring
- Sbt plugins
是否有“亂花漸欲迷人眼”的感覺？不是太少，而是太多！那就讓我刪繁就簡，就我的經驗介紹一些框架或工具，從持久化、分布式系統、HTTP、Web框架、大數據、測試這六方面入手，作一次蜻蜓點水般的俯瞰。
持久化
歸根結底，對數據的持久化主要還是通過JDBC訪問數據庫。但是，我們需要更好的API接口，能更好地與Scala契合，又或者更自然的ORM。如果希望執行SQL語句來操作數據庫，那么運用相對廣泛的是框架ScalikeJDBC，它提供了非常簡單的API接口，甚至提供了SQL的DSL語法。例如：
val alice: Option[Member] = withSQL {select.from(Member as m).where.eq(m.name, name)}.map(rs => Member(rs)).single.apply()如果希望使用ORM框架，Squeryl應該是很好的選擇。我的同事楊云在項目中使用過該框架，體驗不錯。該框架目前的版本為0.9.5，已經比較成熟了。Squeryl支持按慣例映射對象與關系表，相當于定義一個POSO（Plain Old Scala Object），從而減少框架的侵入。若映射違背了慣例，則可以利用框架定義的annotation如@Column定義映射?？蚣芴峁┝薿rg.squeryl.Table[T]來完成這種映射關系。
因為可以運用Scala的高階函數、偏函數等特性，使得Squeryl的語法非常自然，例如根據條件對表進行更新：
update(songs)(s =>where(s.title === "Watermelon Man")set(s.title := "The Watermelon Man",s.year := s.year.~ + 1) )分布式系統
我放棄介紹諸如模塊化管理以及依賴注入，是因為它們在Scala社區的價值不如Java社區大。例如，我們可以靈活地運用trait結合cake pattern就可以實現依賴注入的特性。因此，我直接跳過這些內容，來介紹影響更大的支持分布式系統的框架。
Finagle的血統高貴，來自過去的寒門，現在的高門大族Twitter。Twitter是較早使用Scala作為服務端開發的互聯網公司，因而積累了非常多的Scala經驗，并基于這些經驗推出了一些頗有影響力的框架。由于Twitter對可伸縮性、性能、并發的高要求，這些框架也極為關注這些質量屬性。Finagle就是其中之一。它是一個擴展的RPC系統，以支持高并發服務器的搭建。我并沒有真正在項目中使用過Finagle，大家可以到它的官方網站獲得更多消息。
對于分布式的支持，絕對繞不開的框架還是AKKA。它產生的影響力如此之大，甚至使得Scala語言從2.10開始，就放棄了自己的Actor模型，轉而將AKKA Actor收編為2.10版本的語言特性。許多框架在分布式處理方面也選擇了使用AKKA，例如Spark、Spray。AKKA的Actor模型參考了Erlang語言，為每個Actor提供了一個專有的Mailbox，并將消息處理的實現細節做了良好的封裝，使得并發編程變得更加容易。AKKA很好地統一了本地Actor與遠程Actor，提供了幾乎一致的API接口。AKKA也能夠很好地支持消息的容錯，除了提供一套完整的Monitoring機制外，還提供了對Dead Letter的處理。
AKKA天生支持EDA（Event-Driven Architecture）。當我們針對領域建模時，可以考慮針對事件進行建模。在AKKA中，這些事件模型可以被定義為Scala的case class，并作為消息傳遞給Actor。借用Vaughn Vernon在《實現領域驅動設計》中的例子，針對如下的事件流：
我們可以利用Akka簡單地實現：
case class AllPhoneNumberListed(phoneNumbers: List[Int]) case class PhoneNumberMatched(phoneNumbers: List[Int]) case class AllPhoneNumberRead(fileName: String)class PhoneNumbersPublisher(actor: ActorRef) extends ActorRef {def receive = {case ReadPhoneNumbers =>//list phone numbersactor ! AllPhoneNumberListed(List(1110, ))} }class PhoneNumberFinder(actor: ActorRef) extends ActorRef {def receive = {case AllPhoneNumberListed(numbers) => //matchactor ! PhoneNumberMatched()} }val finder = system.actorOf(Prop(new PhoneNumberFinder(...))) val publisher = system.actorOf(Prop(new PhoneNumbersPublisher(finder)))publisher ! ReadPhoneNumbers("callinfo.txt")若需要處理的電話號碼數據量大，我們可以很容易地將諸如PhoneNumbersPublisher、PhoneNumberFinder等Actors部署為Remote Actor。此時，僅僅需要更改客戶端獲得Actor的方式即可。
Twitter實現的Finagle是針對RPC通信，Akka則提供了內部的消息隊列（MailBox），而由LinkedIn主持開發的Kafka則提供了支持高吞吐量的分布式消息隊列中間件。這個頂著文學家帽子的消息隊列，能夠支持高效的Publisher-Subscriber模式進行消息處理，并以快速、穩定、可伸縮的特性很快引起了開發者的關注，并在一些框架中被列入候選的消息隊列而提供支持，例如，Spark Streaming就支持Kafka作為流數據的Input Source。
HTTP
嚴格意義上講，Spray并非單純的HTTP框架，它還支持REST、JSON、Caching、Routing、IO等功能。Spray的模塊及其之間的關系如下圖所示：
我在項目中主要將Spray作為REST框架來使用，并結合AKKA來處理領域邏輯。Spray處理HTTP請求的架構如下圖所示：
Spray提供了一套DSL風格的path語法，能夠非常容易地編寫支持各種HTTP動詞的請求，例如：
trait HttpServiceBase extends Directives with Json4sSupport {implicit val system: ActorSystemimplicit def json4sFormats: Formats = DefaultFormatsdef route: Route }trait CustomerService extends HttpServiceBase {val route = path("customer" / "groups") {get {parameters('groupids.?) {(groupids) =>complete {groupids match {case Some(groupIds) => ViewUserGroup.queryUserGroup(groupIds.split(",").toList)case None => ViewUserGroup.queryUserGroup()}}}}} ~path("customers" / "vip" / "failureinfo") {post {entity(as[FailureVipCustomerRequest]) {request => complete {VipCustomer.failureInfo(request) }}}} }我個人認為，在進行Web開發時，完全可以放棄Web框架，直接選擇AngularJS結合Spray和AKKA，同樣能夠很好地滿足Web開發需要。
Spray支持REST，且Spray自身提供了服務容器spray-can，因而允許Standalone的部署（當然也支持部署到Jetty和tomcat等應用服務器）。Spray對HTTP請求的內部處理機制實則是基于Akka-IO，通過IO這個Actor發出對HTTP的bind消息。例如：
IO(Http) ! Http.Bind(service, interface = "0.0.0.0", port = 8889)我們可以編寫不同的Boot對象去綁定不同的主機Host以及端口。這些特性都使得Spray能夠很好地支持當下較為流行的Micro Service架構風格。
Web框架
正如前面所說，當我們選擇Spray作為REST框架時，完全可以選擇諸如AngularJS或者Backbone之類的JavaScript框架開發Web客戶端?？蛻舳四軌蛱幚碜约旱倪壿?#xff0c;然后再以JSON格式發送請求給REST服務端。這時，我們將模型視為資源（Resource），視圖完全在客戶端。JS的控制器負責控制客戶端的界面邏輯，服務端的控制器則負責處理業務邏輯，于是傳統的MVC就變化為VC+R+C模式。這里的R指的是Resource，而服務端與客戶端則通過JSON格式的Resource進行通信。
若硬要使用專有的Web框架，在Scala技術棧下，最為流行的就是Play Framework，這是一個標準的MVC框架。另外一個相對小眾的Web框架是Lift。它與大多數Web框架如RoR、Struts、Django以及Spring MVC、Play不同，采用的并非MVC模式，而是使用了所謂的View First。它驅動開發者對內容生成與內容展現（Markup）形成“關注點分離”。
Lift將關注點重點放在View上，這是因為在一些Web應用中，可能存在多個頁面對同一種Model的Action。倘若采用MVC中的Controller，會使得控制變得非常復雜。Lift提出了一種所謂view-snippet-model（簡稱為VSM）的模式。
View主要為響應頁面請求的HTML內容，分為template views和generated views。Snippet的職責則用于生成動態內容，并在模型發生更改時，對Model和View進行協調。
大數據
大數據框架最耀眼的新星非Spark莫屬。與許多專有的大數據處理平臺不同，Spark建立在統一抽象的RDD之上，使得它可以以基本一致的方式應對不同的大數據處理場景，包括MapReduce，Streaming，SQL，Machine Learning以及Graph等。這即Matei Zaharia所謂的“設計一個通用的編程抽象（Unified Programming Abstraction）。
由于Spark具有先進的DAG執行引擎，支持cyclic data flow和內存計算。因此相比較Hadoop而言，性能更優。在內存中它的運行速度是Hadoop MapReduce的100倍，在磁盤中是10倍。
由于使用了Scala語言，通過高效利用Scala的語言特性，使得Spark的總代碼量出奇地少，性能卻在多數方面都具備一定的優勢（只有在Streaming方面，遜色于Storm）。下圖是針對Spark 0.9版本的BenchMark：
由于使用了Scala，使得語言的函數式特性得到了最棒的利用。事實上，函數式語言的諸多特性包括不變性、無副作用、組合子等，天生與數據處理匹配。于是，針對WordCount，我們可以如此簡易地實現：
file = spark.textFile("hdfs://...")file.flatMap(line => line.split(" ")).map(word => (word, 1)).reduceByKey(_ + _)要是使用Hadoop，就沒有這么方便了。幸運的是，Twitter的一個開源框架scalding提供了對Hadoop MapReduce的抽象與包裝。它使得我們可以按照Scala的方式執行MapReduce的Job：
class WordCountJob(args : Args) extends Job(args) {TextLine( args("input") ).flatMap('line -> 'word) { line : String => tokenize(line) }.groupBy('word) { _.size }.write( Tsv( args("output") ) )// Split a piece of text into individual words.def tokenize(text : String) : Array[String] = {// Lowercase each word and remove punctuation.text.toLowerCase.replaceAll("[^a-zA-Z0-9\\s]", "").split("\\s+")} }測試
雖然我們可以使用諸如JUnit、TestNG為Scala項目開發編寫單元測試，使用Cocumber之類的BDD框架編寫驗收測試。但在多數情況下，我們更傾向于選擇使用ScalaTest或者Specs2。在一些Java開發項目中，我們也開始嘗試使用ScalaTest來編寫驗收測試，乃至于單元測試。
若要我選擇ScalaTest或Specs2，我更傾向于ScalaTest，這是因為ScalaTest支持的風格更具備多樣性，可以滿足各種不同的需求，例如傳統的JUnit風格、函數式風格以及Spec方式。我的一篇博客《ScalaTest的測試風格》詳細介紹了各自的語法。
一個被廣泛使用的測試工具是Gatling，它是基于Scala、AKKA以及Netty開發的性能測試與壓力測試工具。我的同事劉冉在InfoQ發表的文章《新一代服務器性能測試工具Gatling》對Gatling進行了詳細深入的介紹。
ScalaMeter也是一款很不錯的性能測試工具。我們可以像編寫ScalaTest測試那樣的風格來編寫ScalaMeter性能測試用例，并能夠快捷地生成性能測試數據。這些功能都非常有助于我們針對代碼或軟件產品進行BenchMark測試。我們曾經用ScalaMeter來編寫針對Scala集合的性能測試，例如比較Vector、ArrayBuffer、ListBuffer以及List等集合的相關操作，以便于我們更好地使用Scala集合。以下代碼展示了如何使用ScalaMeter編寫性能測試：
import org.scalameter.api._object RangeBenchmark extends PerformanceTest.Microbenchmark {val ranges = for {size <- Gen.range("size")(300000, 1500000, 300000)} yield 0 until sizemeasure method "map" in {using(ranges) curve("Range") in {_.map(_ + 1)}} }根據場景選擇框架或工具
比起Java龐大的社區，以及它提供的浩如煙海般的技術棧，Scala技術棧差不多可以說是滄海一粟。然而，麻雀雖小卻五臟俱全，何況Scala以及Scala技術棧仍然走在邁向成熟的道路上。對于Scala程序員而言，因為項目的不同，未必能涉獵所有技術棧，而且針對不同的方面，也有多個選擇。在選擇這些框架或工具時，應根據實際的場景做出判斷。為穩妥起見，最好能運用技術矩陣地方式對多個方案進行設計權衡與決策。
我們也不能固步自封，視Java社區而不顧。畢竟那些Java框架已經經歷了千錘百煉，并有許多成功的案例作為佐證。關注Scala技術棧，卻又不局限自己的視野，量力而為，選擇合適的技術方案，才是設計與開發的正道。
from: http://www.infoq.com/cn/articles/scala-technology/
總結
以上是生活随笔為你收集整理的快速了解Scala技术栈的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Scala 指南
- 下一篇： 计算机视觉Computer Vision