TechTalk 專訪 Episode 29 逐字稿 – Interview with Anthony Chen about Dropwizard

TechTalk 專訪 Episode 28 逐字稿 – Interview with PCMan about LXQt << 前情

A：訪談者－Mao Yang,　B：受訪者－Anthony　C：Hao Cheng

A：大家好，歡迎收聽TechTalk@TW第二十九集，今天是十月二十七日星期一，我是Mao Yang

C：我是Hao Cheng 。今天邀請的來賓是在 HTC 服務的Anthony，他是Taiwan Java User Group社群的朋友，他在社群裡面相當的活躍，常常會跟大家分享一些新的技術，像是 JSF 或者是 Spring framework，Anthony 你可以先跟聽眾做個簡單的自我介紹嗎？

B：好啊，大家好，我是Anthony，我在 Java World 活動蠻久了，我的 ID 就是 Anthony Chen，我現在是在 HTC 工作，大概已經有六年的時間，本身喜好就是在 Java 技術開發這一部份，所以也嘗試了蠻多不同的技術，那在 HTC 之前，我在 Sun Microsystems 做過一陣子講師，講的主題也是以 Java 為主。

A：Anthony，你可以跟大家介紹一下我們今天的主題 Dropwizard 這個 Java framework嗎？

B：ok，Dropwizard 這個framework 事實上就是 micro service 的一個 framework，那什麼是micro service？就有點類似一個比較微型的服務，然後有點像是 ruby on rails 這樣子，它是一個整合性的服務，提供了從前端的 view 到周邊的 restful service，然後到後端的 Hibernate 等等，它提供了一些整合，你不需要透過太複雜的設定，就可以很快速的開發這樣子的一個服務。
為什麼叫 micro service，就是因為很小，而且它本身並不是用一般我們熟知的那種， War 檔的方式去佈署，它是用一個單一的 Jar 檔，本身就具備了 HTTP service 功能，所以這個 framework 很特殊，跟我們平常接觸的 Spring 或是 JSF 等等的 MVC framework不太一樣。

C：所以它裡面也是 embed 一個 Tomcat 或是 Jetty 嗎？

B：對，它其實包含了一個 Jetty server 在裡面，所以其實它強調的是說，它不需要 Application server，它本身就有 HTTP service的能力，而且根據他們官方的一些實測，因為他們官方的，也不能講官方，就是它是個open source project，他們原本是一個公司，那他們公司有做一些網站，然後在他們的應用上面來講，測試過就是包裝成 Jar 檔然後 embed Jetty 以後其實服務的承載能力還是蠻好的，這也增強他們的信心，所以他們才把 Dropwizard open source，希望讓大家可以去應用。

C：如果你要修改 embed Jetty 的一些設定會比較麻煩嗎，還是沒有什麼差別？

B：會，目前看起來，官方有個設定檔，就是在 run 這個 framework 的時候，有一個用 yaml 格式的一個設定檔，有提供一些設定，讓你去自訂 Jetty 的一些設定，譬如說 port number，譬如說 context root，還有一些細節的設定等等，但是除此之外，如果你還要再設定的話，你可能就要動到 Source code，這就比較麻煩，

C：OK。

A：你剛才有提到說有 embed Jetty ，那會不會受限就是說，我使用這個library，我只能佈署到特定的 Java container，還是說，會跟某些 Java 版本有相依性的問題。

B：其實這一個點就是說，他們推所謂的 micro service，其實就是希望你不要再去管 library dependency，譬如說，我想要寫一個網站，那我可能要選用 Spring framework，我可能會有搭配 Spring MVC，搭配 Hibernate 等等的，那每一個的 library 都有各自的版本，而且有的時候，會搭配一些其他的，譬如說我們講就是子專案，所謂子專案就是像你寫web，你會用到 logback，你會用到那個 SLF4J 嘛，維護這些東西的版本也是一個問題，像我自己之前開發就有遇過就是，我的JSF的網站，在某一個 framework 搭配的 logback，會跟另外一個 framework 搭配的 SLF4J 衝突，我必須要把它們調到兩個是相符的版本才可以用，這個就是dependency 管理的一個問題。

Dropwizard 的好處就是說，你拿到這一個framework，其實你根本不用管裡面包了什麼版本，已經初步幫你排除這個問題，至於說 server 的部份，它可以期望就是說你不需要依賴任何其他的 Container，尤其現在雲端這麼發達了，你可以直接就是去Linode 開一個那個空間，把這個 Jar 檔丟上去，就變成一個可以運作的服務，你不需要還要去架設一個 application server 或是 Apache，或是 Tomcat，然後再佈署，然後再設定等等，它希望就是你一次到位，直接丟上去就可以運作。

C：我看Dropwizard的網頁上，其實預設就包了蠻多東西，它幫你把 Jersey 或者處理 JSON 的Jackson 也包進來了？

B：對，對。

C：然後還有像你剛剛說 logback，還有 Hibernate 的一些東西，HTTP client，然後還有 Freemarker 這些？

B：對。

A：如果除了這些東西之外，你還想要再加其他 library 的話？

B：其實還是可以，畢竟它是一個 Java framework 的集合，所以你額外想要再加自己的東西，譬如說你自己開發的 API，你還是可以在撰寫的過程之中 include 進來，因為它打包的方式是用 Jar 檔的打包方式，所以你還是可以包進你自己的，或是其他你想要用的一些library，把它包成一個 Jar 檔佈署上去，還是可以，所以事實上，如果你硬要放其他的東西進來，譬如說假設你想要整合 Spring，你想要整合，我看到國外有人做的就是把 Guice，就是一個 DI 的 framework 整合進來，還是可以做。

C：那可以拿掉某些部份不要嗎，因為剛剛那些東西是預設就全部加進來嗎？

B：應該是說，它預設會加進來，其實一個 Dropwizard 的核心程式很小，那其他的整合，包括像剛剛講了什麼，Hibernate，還有 logging，還有其他這些東西，都是用不同的 module 拆開來，所以你要用的時候，假設你用 Maven 開發，其實你不需要一次把 Dropwizard 所有的module 載進來，你只要擺你需要的就好，舉例來講，我不用 Hibernate，我根本不需要把Hibernate 的 module 放進來。

C：之前有聊到，就是 Java 其實已經有很多成熟的framework了，基本上不管你想要做什麼事情，你大概都可以找到，還蠻成熟蠻穩定的東西，譬如說，其實像 Spring 基本上就包山包海了。

B：是啊。

C：那你當初為什麼會想要選擇 Dropwizard，相對於其他的framework，它有什麼樣的優點？

B：其實我本來不是要找 Dropwizard。最早的起因是因為我手邊有一個很小型的 demo 網站，要 demo 我自己從網路抓來的一些資料，我自己寫了一個爬蟲程式，去爬一些資料，那我想說，那爬完要 demo 給人家看的時候，我可能需要一個很簡單的網站，但是這個簡單的網站又不是那麼的簡單，就要有一些基本的 CRUD 一些功能，我就想說好吧，我是熟 Java 嘛，我就想說用 Spring，然後用 Hibernate 把它弄起來，結果我發現，我弄這個網站時間，比我寫爬蟲的時間還要多，所以…

C：都在架這網站就對了？

B：對，因為那個時候，我剛好是有一陣子沒有接觸 Spring，所以我想說用新的版本，然後再整合 Hibernate ，然後去熟悉之前的東西，然後我就發現說…

C：Spring 最麻煩就是那一堆設定，不管你是用 XML 還是用 Java config，就是有蠻多東西要處理的。

B：那時候我就心血來潮，我就嘗試看看那個 Spring MVC 出來有一個，剛好 Spring Data 剛出來，因為我熟 JPA ，我想說用 Spring Data 來整合看看，那後來發現說還可以用 Querydsl，所以我把 Querydsl 也放進來，結果後來就發現我寫了一個很簡單的網站，但是我用到了一大堆的東西，我把 Spring MVC 放進來，Spring Data也放進來，Querydsl 又放進來，只是為了寫幾個CRUD，然後我的 Class 沒有多少，為了搞這些設定，又要把我熟悉的JSF 前端整合在一起，那又更困難，所以我後來放棄 JSF 整合，我就不用了，因為我發現說我怎麼一直在整東西。

C：所以 Dropwizard 的前端，剛剛沒有提到這個，就是它主要是以一個 restful 的service嗎？

B：對。

C：如果你想要整合其他的前端 framework 的話，有什麼選擇？

B：它內建的功能，就提供了 Freemarker，還有另外一個叫做 mustache 的 Javascript template engine，我覺得它前端整合只是聊備一格，只是提供你有，就像我剛剛講的，我如果只是要一個基本的頁面的整合的話，它有提供這樣子的功能，那它沒辦法，譬如說去整合 JSF甚至其他的一些 Java web framework，真的沒有辦法。但是我覺得它很適合，第一，就是現在很流行的 Javascript MVC framework，因為它有基本的 HTTP 的能力，然後它也有支援 HTML，因為它裡面有 Jetty，支援 HTML 還有 Javascript，所以事實上，它反而因為沒有提供就是傳統的 JSP view 的整合，所以它反而蠻適合這些 Javascript MVC framework 去撰寫前端，那就變成是說，原本你的 binding 的部份，可能是在 JSP 裡面，那你現在倒過來就是說，把 Dropwizard 當一個 restful platform，那你的 binding 就是在 Javascript MVC 這個階段去讀。

C：我看它連 metrics 都整合進來了？

B：對，它連 metrics 和 liquidbase 都包進來，我覺得理由是這樣子，因為 microservice 的架構比較傾向是每一個 service 很獨立，然後一個系統由很多個 service 串連，所以其實如何去偵測這些服務就變得蠻重要的，因為萬一掛一個的話，其實你很不容易發現，因為它可能是某一個 module 不見了，不像你以前做一個網站，網站掛了，你一進去就知道，所以它才把 metrics 整合進來，把偵測還有所謂的監視的功能放進來，然後 health check 等等的一個設計，就把它提供出去，所以我覺得它整合了很多蠻必要的 library，不必要的就沒放進去。

C：這麼多一個一個的service，deploy 會不會很麻煩？

B：我覺得反而還好，因為我自己，以之前在HTC我有擔任類似 deploy manager 的角色，那我們那時候 deploy 的是 War 檔，然後 deploy 在 Weblogic 上面，，有的系統一次要佈署很多台，其實後來發現，如果像 Dropwizard 這種很多台 deploy 的方式的話，因為它是包成一個個Jar 檔，所以其實 container 已經在程式裡面了，deploy manager 其實很輕鬆，他不用管 container的設定，或是說 container 的一些其他相關的，而針對這個 application 要做什麼特別的config，不需要，它只要把這個 Jar 檔 deploy 到那一台server上去，然後蓋過原來的 Jar 檔就可以，也不用去管很複雜的 deployment 程序。

譬如說，我一定要先把 AP server shutdown，然後deploy，然後再起來，然後再去做 ping 或是什麼樣的測試，確認它存活，我才知道是 deploy 成功，那我覺得 Dropwizard 這種方式，變的對 devops 這種角色的人很方便，管理的對象很單純，我只要確認說，這一次的 deployment，我的 Jar 檔有 deploy 到指定的 server，然後服務有有起來，http 是通得，這樣就是ok了，所以反而這樣的方式對像 deploy manager 是比較friendly。

A：請問一下，你們是在新的專案導入 Dropwizard，還是說既有的專案去做 refactoring，去導入 Dropwizard？

B：我一開始用 Dropwizard 是在一個很小的，屬於我自己可以 handle 的新專案去用，所以算是從新專案開始吧，然後，未來希望可以在一些舊的比較大型的專案，把部份的一些 legacy code 切出來，變成 Dropwizard 的 module，放在新專案也是一個考量，事實上，一個新的技術或是framework，尤其 Dropwizard 連 1.0 版都還沒到，畢竟大家還是會怕這東西那麼新，甚至說micro service 這個概念在國外也是還算新的概念，所以在國內的接受度，或是說以大公司來講，接受度一定會有所考慮，不一定很快可以接受，所以這個技術，對我們來講的話，就是剛開始試用，並沒有要很擴大，或是說會馬上就用在一些很重要的一些應用程式上面。

A：現在你們 team 就只有你在用就對了？

B：對啊，現在只有我在用，屬於我個人可以 handle，即使是造成什麼問題，範圍也不至於太大的狀況下。

A：那你當初就是在新的專案導入這個 Dropwizard 有沒有遇到什麼樣的困難？

B：困難喔，假設你是一個比較熟悉 Java 的生態系統的人，所謂熟悉生態系統就是你知道Hibernate，你知道 Spring，你可能懂，譬如說 Jersey，或是一些這種東西，你大概都有碰過了，其實並沒有什麼困難的，可能會有點要去接受的概念就是說，你會發現沒有一個，container 去deploy 這件事情，你變成要信賴他的 Jetty server，對於那種已經習慣去維護，維護一個 application server，像 Weblogin/JBoss 的一個工程師來講的話，剛開始會有點怪異感，除了這個之外，其他我覺得都還好，甚至不用花太多時間就可以上手，可以很快的寫出一個東西來。

A：所以這個framework算是蠻新的，就是你在導入新的專案以後，踩到什麼樣的地雷？

B：地雷？

A：對。

B：算是有一個地雷，open source的一個通病就是改版之間差異非常大，我第一版在測試的時候，所用的那個版本是0.6.5，後來就是要準備在那個 JUG 聚會講 Dropwizard 的時候，我發現改版了，改成 0.7 版，然後改版的幅度之大，程式一定要全部重寫，否則你沒辦法升上去。

C：有點砍掉重練吧？

B：差不多了，你原本繼承的 A Class，它根本就叫成 B Class 了，名稱都不對了，所以根本升不上去，然後 package name 全改，然後，剩，就，就說它，它，就我的角度來看是變好，就是它提供的設定變多了，功能也變多了，但是幾乎就要重寫，所以這個是用open source，尤其是很 early stage 的 open source 麻煩的地方，萬一大改版就變得很麻煩，如果真要講地雷的話，我覺得這個遇到蠻困擾的。

C：所以還沒有要 1.0，現在好像 0.7 而已？

B：0.7.1，對。

C：直接跳1.0嗎？

B：今年開始在用的時候，有一直在關注這個project，它更新的蠻勤快的，大概沒幾天就會有一個 update，然後內部也蠻活躍的，所以我是還蠻看好它未來的一個發展，但是我也不覺得它可以取代 Spring或是取代 Hibernate，變成一個非常 popular 的一個framework，因為它畢竟有它的一個特色，就是我剛講的 micro service，就變成是說，你要在某些特殊情境下面，你才會想要去用這種，或者是說你拿來做 prototype ，一般的大企業，假設你今天做一個幾十萬、一佰萬的案子，我覺得應該沒有人會敢去用 Dropwizard 來做這樣子的一個系統，大部份一定還是走 Spring, Hibernate。

C：或者是Java EE？現在Java EE 用的人也還不少，所以你 Dropwizard 其實都還沒有遇到，需要去調校一些設定，效能都還不錯就對了？

B：對，它的提供的功能，讓你的目的就是只有提供一個 service，事實上你會發現，它的效能的問題只會在兩個地方，第一個就是，因為它是 Jetty，會受到你那台 server 上連線數的一些限制，第二個就是假設你用 Hibernate 的話，你沒有寫好的話，就會有一個效能的瓶頸，至於說其他來講的話，目前看起來應該是沒有什麼效能的問題。

A：突然想到一個問題，你剛才提到說Dropwizard 有一個方便性，就是把很多東西都包好，讓你可以直接開發你想要的功能？

B：對啊。

A：那假設說，我剛開始就是想要快速開發一個 prototype，開發到某個階段之後，也許我真的要把它上線的話，我就想把它弄到 spring framework，如果初期用它做 prototype 的開發，那後期把它導到spring的 framework，這樣子的話，會不會有…

B：花很大功夫或是很困難？

A：對。

B：其實 Dropwizard 的核心，我們講商業邏輯或是API的部份就是以 Jersey 為主，所以那後面的話你一樣可以透過DAO去存取，然後，透過 Hibernate 然後再去執行資料庫，所以其實我覺得，假設你開發到一半，或是說你已經開發完了，然後長官跟你講說 Dropwizard 是什麼，我們要用 Spring，我覺得改寫成 Sspring MVC，或是 Jersey 的一個架構，其實還蠻快的，因為只要改變跟 view 整合的那一部份，以我的瞭解，它跟spring MVC 有差別的就是在 Spring MVC 有提供 model/view 的整合，那 Dropwizard 沒有，所以它是提供一個 class 讓你去繼承，你自己去寫這種所謂的view之間的 binding，所以如果你要把整支程式換成 Spring MVC，就是只有 view 這邊的整合程式要換掉，那其他的部份，我覺得核心的邏輯程式，還有 API 的部改寫的幅度還蠻小的，應該是蠻容易直接轉換過去的。

C：我有看到 Spring 有另外一個專案是 Spring boot。

B：對。

C：Spring boot 裡面有個 actuator，說明跟 sample 看起來還蠻像Dropwizard的…

B：所以我看到網路上有人在講，就很好笑，就是好像大家都一直在學來學去，就是 Java EE 一直變得越來越像spring，然後 Spring 越來越像 Dropwizard，就是 spring boot 你剛講那個專案，我沒有直接寫過，但是我有看過網站和那個sample程式，就是百分之九十以上的概念是跟 Dropwizard 一模一樣，甚至可以到九十五以上，只有少數的一些 term 或是一些結構不一樣，那基本概念是一模一樣的，甚至連 build/run 的方式也是一模一樣，可以說這兩個東西，我覺得甚至就是名稱不同的兩個一樣的東西。

C：不過看起來，Spring 這個專案討論度沒有太高?相較於其他專案？

B：對，因為它比較新，然後 Spring 好像沒有很大力的去，應該說它太多了啦…

C：是 Spring 東西太多了吧？

B：對，太多了，所以好像也沒有人在討論，但是在 Dropwizard 的 google 討論區裡面有人在討論，Spring 的這個新方案真的蠻像的，我覺得這東西出來，代表一個意義就是事實上像 Dropwizard 這樣的 micro service 框架，看起來有一個市場需求在，甚至說未來也可能是一個小風潮，或許我可以看到其他的一些應用，譬如說以前我們在講 SOA 嘛，maybe 哪一天，某個企業會開始想說，我們走 micro service 的架構，說不定會變成某些大公司用來做企業系統，所謂的Enterprise Integration 的一個武器，所以我覺得 Spring 會寫這東西出來，可能有這一層意義在，就是連 Spring 都意識到用 micro service 的 framework 是有一定的 value 在。

C：Spring 一開始要能夠動需要一些設定，一開始要花的功夫還蠻大的。

B：對，，而且很麻煩，然後，你會發現說，我現在做法就是自己先寫好一個 Spring 專案，我有一個標準專案，然後我每次都把那些 copy 過來用，要不然其實我都會忘記該設什麼這樣子。

C：基本上我們也是這樣，有一堆 Spring XML 就 copy 過來。然後再來改。

B：對對，然後拿來改這樣子，其實我要用 Dropwizard 之前，因為我那時候我只是一個 prototype，好奇的心態，我本來看的是其他的 framework，就是最早在做 micro service 的一個framework，叫做 Sinatra 是 Ruby 的一個framework，然後， Sinatra 強調的就是 比 ruby on rails 更簡單，只要透過設定和幾行的程式，就可以跑一支程式起來，然後內建一個 HTTP server ，後來我就想到說，Ruby 有這種framework，那 Java 有沒有，所以我又找到了Dropwizard，畢竟我比較熟 Java 嘛，Dropwizard 用一用發現這個東西還不錯，所以我才開始使用Dropwizard，然後我就想說像這種 micro service 的 framework 是不是很多，結果發現找出來還蠻多的，每個語言都有，有 Go，有 Python，有 Perl，好多種。

C：因為大家都有這種需求，然後大家都不想學別的語言，所以就自己做一套。

B：對，所以，我覺得它打動了某些人的需求，就是說，日復一日，我們開發一些小系統的時候已經厭倦了重覆做這些設定，你會發現說 ruby on rails 出來的時候，主打就是說，你可以就是，依照一定的 convention 去開發，你就可以很快開發一個網站 ，後來 Groovy 也有一個，叫做 Grails，但是大家可能還是覺得不夠簡單，因為你開發這個網站以後，你還要測試，你還要做很多很多東西，所以我覺得它變成一個趨勢，從 rails 以後再進化到 micro service 的概念，然後用 framework 去建立一個一個小的服務。

所以我覺得或許是一個趨勢，而且這個趨勢本來還不那麼紅，是因為在今年三月的時候 Martin Fowler 寫了一篇文章，特別在他 blog 介紹 micro service 的概念，然後就開始一堆人在討論說，那位大師都在講這個東西了，那什麼是micro service，大家就趕快來研究，所以才突然冒出來很多 micro service 的一些討論，有人就找到 Dropwizard，然後 Dropwizard 從今年的開發的進度就變得很快，因為 0.6 是去年中的時候，結果一直沒有動，但今年初開始就突然開發變得很快速，所以我覺得大師的推薦好像也幫助了一個風潮，大家才發現說，我們可以有大師認證的這樣子一個 pattern。

C：就比較多人知道這個概念？

B：對，然後很好笑，我看到有人特別寫了一篇文章說，他去看 Martin Fowler 的文章後，他還是搞不清楚，到底 micro service 跟 SOA 有什麼不一樣，所以他的結論就是，這兩個東西根本就是一樣的東西

C：概念還是蠻像的？

B：對，事實上，如果說 SOA 是一般所謂的商業公司提出來的商業解決方案，那 micro service就比較像是 open source 界或是 startup 用來做系統整合，應用整合的一個解決方案，有點像是民間版和官方版那種感覺，所以SOA 的內涵和 micro service 的內涵，事實上，你仔細看的話是差不多的，唯一的差別可能在於 SOA 當年在講這些架構的時候，它的 service 是基於所謂的 SOAP 這種web service，那到了 micro service 的時候，它的 service 就是基於 HTTP 的Restful service，我覺得唯一的差別是這樣，其他的概念我覺得是差不多的，根本就是一樣的東西，只是包裝成不同的名詞。

其實，不可否認是不是因為大師把這東西講一講，就有個新的名詞去，不能講炒作，就是可以拿來運用，但是跟當年 SOA 不一樣的是，當年你要做一個 SOA 的時候，其實也沒有什麼 framework，就算有的話，也都是大公司提供的又笨又重的那種平台，現在不一樣是說，micro service 的架構是一個很小很小的，不需要太多設定的 framework，可以很快上手，所以重點就變成是說，怎麼去拆解我的系統的 service，然後把它們串在一起，我的重心就不會放在就是說，去怎麼做平台整合啊，或是做底層的一些整合等等的，不需要，只要專心做好我每一個service，就是最後把它們串起來這樣子。

A：ok，我想我們準備的問題差不多了… Anthony 你還有什麼最後想要補充的？

B：補充的喔，暫時也沒有，事實上 Dropwizard 算是個人興趣啦，所以在研究的過程中，我也學到了蠻多的，很高興可以藉由這個機會分享給大家，我會覺得說，大家如果有機會的話真的可以去試試看，不一定要用它，那我自己的經驗是，我在用一個 framework 的過程之中，我也學到蠻多的，甚至會想到是不是在我以前開發的系統裡面，其實有一些更好的寫法，也可以參考這些 framework 的架構和設計，我覺得都蠻不錯的，所以我是抱著這種心情來分享 Dropwizard 給大家。

C：好，謝謝 Anthony 今天來接受我們的訪問。

B：不客氣，謝謝。

C：也謝謝大家收聽，今天的訪問到這邊到一個段落，謝謝大家，拜拜！

A/B：謝謝，拜拜！