內容來源：2017年5月13日，票牛網架構師黃億華在“Java開發者大會 | Java之美【上海站】”進行《創業公司中的Java高效應用》演講分享。IT大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：2509 用時: 4分鐘
摘要
Java是一門物件導向程式語言，不僅吸收了C++語言的各種優點，還摒棄了C++裡難以理解的多繼承、指標等概念，因此Java語言具有功能強大和簡單易用兩個特徵。Java語言作為靜態物件導向程式語言的代表，極好地實現了物件導向理論，允許程式設計師以優雅的思維方式進行復雜的程式設計。
有人說在網際網路創業公司中不應該使用Java，讓我們來看看票牛網架構師黃億華是怎麼說的。
嘉賓演講視訊和PPT地址
從0到1
在我們公司初創的時候，組齊了三人的團隊就開始做產品研發。當時整條業務線的東西都需要我們自己寫，要在短時間內把東西做出來，效率是非常關鍵的。
我們的產品模式本身其實是需要驗證的。創業有很多不確定性，在上線之前沒人能知道，我們的一個專案究竟能達到多大的規模，能做到什麼樣。所以這時技術的重要性就在於快速把東西做出來。
Why Java？
我們最終選擇Java，一方面是因為我們團隊已經有了一定的寫Java的基礎，從最開始的搭建到後來初具規模也能Hold住，基數很穩；另一方面是因為Java有很大的使用者量，人才儲備非常多，我們看中了它規模化的能力。
從某種意義上來說，Java的開發效率確實有些低。但是後來由於選型的原因，我們還是堅持使用了Java。
更有效率的Java
在“Java如何寫得更方便易懂”這方面，Java一直在改進。之前的Java設計思想是模組之間要做到可擴充套件，崇尚配置和程式碼分離。
現在Java社群在向高效開發比較理智的方向去做，各種語言慢慢趨向一致。
Java 8
我們在使用Java 8之前都是用物件導向的方式去思考、去處置程式碼。
當時有人貼出了Java 8，用一個Lanbda可以從頭寫到尾，十幾二十行的Lambda能做很多事情。
引入這個技術棧之後，我們發現只要控制住適用的範圍，它就是一個非常好用的東西。
我覺得無論是做Web開發還是服務端開發，都有一個非常經典的場景。在Java裡我們提倡分層，如果批量去做很容易寫成下圖中的程式碼。
這段程式碼的核心是Map，它要做的就是把兩個物件進行轉換，把一個List轉換成另一個List。
StreamAPI不單有程式設計方式上的提升，還可以在內部自行去做併發處理。
大家不用Java有很多原因，比如運維覺得它很難部署，架構師則會考慮第三方API在二次反射的時候是否能讀到Java。
其實Java是主流的Java，只要還活著的開源專案基本上都已經支援Java。
Spring Boot
SpringBoot到目前為止已經非常成熟了，我們身邊有很多最近才創業的朋友基本上用的都是這套技術棧。
它的特點是把Spring全家桶用一個看起來很簡單美好的方式進行了整合，實際上它不是對Spring技術棧的重構，而是把Spring技術棧做了封裝和組合。
現在的Spring全家桶更多了。針對Web開發，基本上可以完成全部的選型，並封裝得很漂亮。
在2015年Spring Boot還沒有那麼火的時候，我們做了一個類似的整合工作，用到了Spring 4、Spring MVC。
Spring 4
Spring4目前已經相對成熟穩定。Spring的發展經歷了一個變更過程，從最開始的XML，在當時也算輕量級；到2.5的時候有了註解，簡化了很多事情；在Java 3的時候加入了Spring Config。
Spring4相對於Spring 3加了一些Java 8的支援。
Spring MVC
如圖是MVC的一個例子。
ORM：Mybatis+Daogen
我們為了解決ORM使用繁瑣的問題，自己寫了Daogen。這個工具兼具了靈活性和規範性，它可以統一程式碼規範，強制做命名，並在編譯期自動生成XML。
Server Side Rendering
我們當時引入Jade4j框架，借用前端基本在用的模版引擎，在前端用Js可以跑，後端用Java也能跑。
現在Java比較火的框架叫Thymeleaf，這個框架也很好。基於我們想用前端來寫模版，所以當時還是選擇了Jade4j。
從1到N
在第一個版本上線之後，“從0到1”階段完成，這時我們又將面臨不一樣的問題。
隨著業務規模擴大，線上故障、可用性、質量不能忽略，團隊也要擴張，並提出新的要求。要求主要是質量、可見性和可用性三個方面。
團隊擴張
因為條件限制，我們的招聘工作進行艱難。退而求其次，我們會選擇一些資質較好、主動性較強的應屆生或一兩年工作經驗的員工做培養。
我們需要構建一個人才梯隊，以“一個帶兩個”的工作模式，把團隊組織成一個有梯隊的團隊。
質量-重構
我們是單程式碼倉庫，當程式碼不斷增加，前期又做了很多不清楚的模型或程式碼的時候，必須要去整理清楚。
我最大的經驗就是重構不合理的業務模型，業務模型是最重要的。
質量-持續交付
Devops可以做線上的無縫釋出，做版本的回滾重啟。測試環境要高可用。
可用性-應用監控
我們現在用Cat最多的是報錯功能。Java的錯誤機制還是很完整的，如果出現什麼線上問題，報錯基本都能發現。我們主要做了兩件事，一是把所有異常都發報警簡訊，另一件事是把所有異常放到一個電視機上，便於我們隨時監控。
效能評估是其次，畢竟QPS只有1。
可見性-日誌管理
ELK可以用於做日誌收集、業務監控、效能監控，甚至可以用來做資料分析。
但是因為它的資料量特別大，對伺服器的效能調優要求比較高，所以我們最終只保留了日誌管理功能。
業務可見性-報表
任何公司都有報表需求，我們的做法是跑個SQL把資料存下來然後給老闆看。後期有些資料量較大，Mysql儲存有壓力，所以我們就用了阿里雲的ODPS。
一些心得
如何做技術選型
懶是一種美德：技術選型上我們選擇更適合的，可能會提高開發效率或運營水平，但也可能不行。所以要去不斷嘗試，我們覺得這是值得的。我們為了追求更高的生產效率，也會寫很多的小工具。
找到實用和好奇心的平衡點：到了整天做業務的階段，會覺得枯燥。我覺得技術團隊應該是有追求的，在滿足“吃自己狗糧的條件下”嘗試新技術。這個平衡點是根據團隊規模和人員對某個方向的瞭解水平來定。
對利用第三方平臺：我們團隊能用別人的就儘量不自己做。用第三方服務多少會有些問題，但在衡量之下肯定會選擇先把它做出來。
如圖可見，在最初的時候單體應用的生產率更高，它有很多優點。
技術角色和創業公司的分工
技術在創業過程中相對來說還是比較確定的因素。當各部門之間出現分歧的時候，要提高效率只能選擇相信隊友，所以快速失措快速迭代是非常重要的，並且要進行有效支援。
發現當下的問題
要提高效率依靠更好的開發工具；
質量由QA人員和運維把關，進行異常監控；
可用性和安全也要通過監控來保障。
今天要分享的就是這些，謝謝大家！
