Java領域從傳統行業向互聯網轉型你必須知道的那些事兒
我為什么要寫這篇文章
武林中，"天下武功出少林"指各門各派的武功都與少林武學有一定的淵源，技術也是相同的道理，對于Java領域的應用而言，傳統行業與互聯網行業的技術都來自J2SE和J2EE的生態圈，但是兩個行業的側重點不同，傳統行業側重于嚴格的規范、復雜的流程、豐富的功能，因此或多或少的都會使用J2EE規范定義的技術，Appserver是J2EE規范的完全實現，因此，傳統行業的企業級軟件開發基本都是部署在Appserver上的，這樣可以重復利用Appserver提供的通用功能而節省開發和實現的工作量，而后者更注重互聯網產品的非功能質量需求，通常包括：高可用、高性能、安全性、可伸縮、可擴展等，互聯中***的一句話是：天線武功唯"快"而不破，充分看出互聯網企業里程序性能的重要性，為了達到較好的性能，高度抽象的J2EE技術已經沒法滿足需求，因此互聯網技術更傾向于在簡單的J2SE上發展具有互聯網特色的技術棧，重新定義互聯網級的開發工具、平臺和技術棧。
由于筆者從傳統的外企轉型到互聯網已經有3個年頭，近兩年來面試了很多來自傳統行業的同行們，筆者發現這些同行們都有意向走進處于風口的互聯網，但是由于傳統行業使用的技術棧與互聯網有所不同，不知從哪里開始入手準備和提高，盡管他們有強烈的學習和提高的愿望，本文就是給這些想從傳統行業跨入互聯網的小伙伴們準備的一篇導向性文章，幫助讀者了解互聯網的技術棧、了解互聯網的側重點、了解互聯網的核心技術，并給出如何以傳統行業的技術棧為基礎快速掌握互聯網的核心技術，其實，那只有一墻之隔，捅破那張窗戶紙兒，一切都豁然開朗。
這里需要再次澄清，我并不認為互聯網行業的技術要比傳統技術深奧多少，這些技術跑不出J2SE和J2EE的生態圈，只不過高度抽象的J2EE技術由于性能上的局限性而被互聯網撇棄而已，但是不得不承認的是兩個行業的側重點不同，傳統行業側重于規范，流程，功能的復雜性以及正確性，而互聯網更側重于“快”，這里的“快”有兩方面的意思，一個是產品運行效率要高，響應速度要快，另外一個是開發效率要快，響應市場需求要快。從另外一個側面說，傳統行業一般關注一個復雜系統的功能完善和豐富，而互聯網企業更關注一個簡單的垂直業務的非功能質量，例如：高性能，可用性，高并發，可擴展，可伸縮，安全性等，那么，一個從業人員從傳統行業到互聯網行業，你到底還有多少距離?
小伙伴們從哪里開始入手互聯網
這兩年來面試下來看到了一個普遍的現象，來自于傳統行業的技術人員，他們大多數掌握的技能是SSH，稍微資深一點的工程師對J2EE規范有所了解，他們仍然在使用J2EE規范的EJB, JPA, JMS, JCA, JAAS等技術，數據庫基本上使用Oracle，DB2，Sqlserver等等。傳統行業的開發人員基本實施“模塊包攬制”，這得益于J2EE規范的完整性，以及Appserver提供了基本所有架構需要的功能，開發人員只需要將各個業務模塊填入J2EE和Appserver提供給你的框架即可，因此，一個傳統的開發人員會包攬一個模塊從前臺到后臺所有的工作，這包括：HTML, JS, CSS, EJB, JPA, SQL, PLSQL等等。這些技術是不是一無是處，當然不是，反而是非常有價值的，那有了這些技術，我們是否可以一步跨入互聯網，也不是，還需要以這些技術為基礎，進一步擴展技術視野，對欠缺的技術廣度和深度進行不足。
下面就學習傳統行業技術人員擁有哪些技術積累，下一步又如何補充自己的知識面，成為能夠勝任互聯網行業的優秀技術人員呢?
消息隊列
在傳統行業，相信你一定用過JMS，作為J2EE規范的一部分，所有的Aappserver(Weblogic、Websphere、Jboss等)都有JMS的實現，那你一定知道JMS包含Queue和Topic兩種Subject，你也知道Send/Receive和Publish/Subscribe兩種收發模式，那在互聯網為什么就不用這些呢?
原因主要有兩個，一個是商業的Appserver都是收費的，然而，互聯網提供的產品是免費的，互聯網使用的產品也多是免費的，另外一個原因就是這些Appserver的實現性能差，有測評顯示ActiveMQ比JbossMQ速度要高出10倍，在某些應用場景下ZeroMQ的速度要高出一個數量級，可達到微妙級別的延遲，有興趣可以參考ZeroMQ的性能測試頁面。
除此之外，一些開源的MQ的實現針對互聯網業務，提供了除Queue和Topic的支持，還有partition，group，broker等更復雜的消息模型，具體參考Kafka, Kafka的設計具有使用簡單、功能豐富、高性能等優點，不但天生具有持久、分片、復制等功能，而且在使用上對開發者和運維的體驗也很好。對于Kafka的中間件設計，請參考我的博客文章簡單易用的消息隊列框架的設計與實現。
那么如果你在傳統行業掌握了JMS規范定義的消息隊列技術，你只需要再往前走一步，請深入學習開源的Kafka、RockitMQ、ActiveMQ、RabbitMQ、MemcacheQ、Redis、ZeroMQ、MSQ等。
緩存
在傳統行業，相信大家都用過Oscache和Ehcache, 前者主要針對網頁的緩存，后者主要針對數據庫數據的緩存，通常可作為Hibernate的二級緩存，相信有些人還用過Jboss Cache，這是一個分布式企業級可實時復制的Cache，有些人在項目中也寫了自己的緩存，甚至在一些項目中直接使用Hashtable作為緩存，其實這些緩存加速了特定場景下的數據訪問，對你的項目成功起到了至關重要的作用。
但是互聯網行業則從另外一個角度來使用緩存，主要應用場景有兩個：***，大量的數據需要集中保存，在服務的任意節點上可以訪問緩存中的任意數據，也就是需要數據的中心存儲，而且還要滿足快速的查詢需求的場景;第二，數據庫讀性能是有瓶頸的，廉價硬件機器上的單機Mysql讀操作吞吐量在1000/s左右，大量的讀查詢會壓垮數據庫，這需要使用緩存來抗住讀流量，通常應用在有熱點數據的場景。
從這兩個應用場景來看，互聯網行業更關心分布式緩存，那數據如何分布呢?很簡單，Hash或者一致性Hash，所以，咱們可不可以先把Oscache和Ehcache放一邊，來研究一下Redis，Memcache或者淘寶的Tair呢?最簡單的辦法從Redis和Memcache的區別開始入手?
除了要學習分布式緩存，例如：Redis、Memcache本身的功能和技術點外，最主要的要有緩存分片的思想，在互聯網里大多數的熱數據都是緩存在緩存服務中的，這需要大量的緩存服務器，單臺機器是不能滿足需求的，那緩存分片是一個大話題，緩存分片的實現方式一般有如下3種：
- 通過代理層實現，例如Codis，在代理層實現數據的路由，對應用層透明。
- 客戶端分片，可參考我的開源項目redic，實現簡單、使用簡單、支持分片、復制、失效轉移等功能。
- 緩存服務器支持的高可用模式，例如：Redis 3.x、Sentinel等。
服務框架
在傳統行業，相信大家都使用EJB和Webservice來提供服務的導出和導入，有些個別傳統行業不用APP服務器，僅僅使用JDK的RMI來導出和導入服務，但是為什么互聯網偏偏不喜歡這些技術呢?Webservice使用重量級的SOAP協議，臃腫的XML滿世界都是，性能上的去嗎? 那互聯網用什么，互聯網使用輕量級的RPC框架和RESTful服務，前者使用輕量級的序列化框架，例如：Google的ProtoBuffer, 還有Hessian和Burlap等序列化協議，后者則使用簡單的HTTP協議，前者適合在內網做高性能的服務調用，而后者適合異構平臺的服務調用，例如: 跨語言，跨防火墻，前后臺之間等。RPC遠程調用請參考阿里的Dubbo框架和Twitter的Finagle框架，至于Rest框架參請考Spring Web MVC，Spring Boot、Jersey，Apache CXF等。
在互聯網的世界里，幾乎所有的公司都實現了服務化，服務化導致的問題就是一致性問題，如何解決高并發系統的一致性呢?使用兩階段提交協議、三階段提交協議、TCC?還是遵循ACID原理、CAP原理、BASE原理?如果我們保證的是最終一致性模型，我們都有哪些模式可以應用。
最近微服務變得越來越流行，微服務實際上是服務化的一個延續，是更細致化的服務化的架構，微服務的服務框架的代表是Spring Cloud，它與Netflix集成，提供了限流、熔斷、倉壁隔離、失效轉移等為服務化中必不可少的高級特性，大家可以到官網文檔進一步學習Spring Cloud相關技術。
數據庫
在傳統行業，大多數人開發人員都使用Oracle, DB2, Sqlserver數據庫，其實，從功能和性能上來講，他們都不亞于Mysql, 甚至比Mysql更優秀，但是Mysql是免費的，這使得Mysql得到互聯網行業的青睞。
那么我們分析下，傳統行業的人員在數據庫方面欠缺什么嗎?首先，Oracle和Mysql都使用B+樹索引，原理相同，使用方法相同;Oracle支持行級鎖，Mysql Innodb同樣支持行級鎖;Oracle Dataguard支持數據復制，Mysql也支持數據復制，但是Mysql的復制模式更靈活，并且支持主主配置。前面這些都是大同小異，如果你理解了相應的Oracle技術，你用很少的時間就可以掌握Mysql的相關技術。但是不同點是，Oracle雖然支持集群，通過增加服務節點的方式可以增加服務性能，但是集群的節點數量是有限的，并且數據存儲是共享的，所以擴容基本采用垂直方式，然而使用Mysql則采用水平擴展，也就是需要進行手工的分區分表，對數據進行分而治之，以滿足日益增長的讀寫壓力以及數據存儲壓力。因此，如果想向互聯網轉行，一定要學好Mysql，推薦閱讀《高性能Mysql》，這本書是必讀的書籍，而且推薦每一個應用開發人員都要通讀全書，而不是僅僅讀其中與應用相關的那部分。
在互聯網行業里面對性能追求到達了***，因此會要求開發人員對數據庫原理有所了解，其中最重要的部分就是索引。
負載均衡
剛才談到，高并發系統，壓力山大的時候怎么辦?思想只有一個分而治之( divide-and-conquer)。因此，負載均衡則非常重要，傳統行業以銷售產品為盈利模式，因此，大多數項目在需要負載均衡的時候，多使用F5硬件負載均衡。
實際上傳統的J2EE規范的EJB也可以分布式發布，通過JNDI的集成，也可以進行一定程度的負載均衡，但是這個負載均衡顯得太重量級，用起來非常的不方便，效率也很低，并且和APP服務器綁定。
那么互聯網呢?多采用軟負載均衡，你必須了解LVS，nginx, Apache, Varnish, Haproxy等七層和三四層負載均衡原理和產品。
JVM
另外，在互聯網行業做Java開發，一定要對JVM有所了解，并且進行深入的研究，例如：GC，類加載，Hotspot編譯器，多線程、并發和鎖，IO和NIO等。推薦閱讀《深入理解Java虛擬機++JVM高級特性與***實踐》,《深入理解Java7》,《Java Concurrency In Practice》,《Pro Java 7 NIO.2》,《Java Performance》等一系列深層次的JVM相關數據，***能閱讀《The Java® Language Specification》和《The Java® Virtual Machine Specification》兩本龍書。
大數據與云計算
作為一個IT從業人員，一定要跟上技術潮流，像云計算，大數據，CAP, BASE, 選主算法等概念不得不去了解，對于熱點技術不得不研究，例如： Hadoop, Hbase, Zookeeper, Openstack, Dooker, Kafka, Storm等。
性能評估和容量估算
如果你決定要來互聯網一顯身手，你必須學會性能評估和容量估算，這包括對前端機、緩存、消息隊列、數據庫等各個性能指標的估算，例如：吞吞量，響應時間，內存，CPU，IO，網絡IO等。
性能和容量評估的方法論和典型案例可參考文章互聯網性能與容量評估的方法論和典型案例。
為了確保架構設計的合理性，性能和容量評估是在架構設計初期完成的，用來證明架構方案可行，但是在項目實施中和實施后，還需要對項目的進行壓測，來證明項目按照既定的目標而推薦和完成，關于性能測試的方法論和設計流程，我將會在后續文章中介紹給讀者。
互聯網架構方法論
在互聯網行業里，處理大規模高并發的用戶請求的核心思想只有一個，那就是“分而治之”，因此，通常業務被拆分為多個職責單一的服務，在某一個單服務里，業務邏輯并不復雜，但是對非功能質量需求的要求較高，這通常表現在性能、可用性等方面，因此互聯網的架構設計中首要考慮的是非功能質量，這和傳統行業注重功能和業務流程的情況有所不同，對于互聯網行業中，架構設計的案例，可以參考發號器Vesta的設計與實現如何設計一款多場景分布式發號器(Vesta)，來了解互聯網業務的架構設計的風格和思路。
技術攻關和線上應急
在互聯網企業里，大多數產品都是針對用戶端的，用戶端的產品的特點是擁有海量的用戶、產品要能夠處理海量用戶產生的大規模高并發的用戶請求，因此會對產品的可用性比較敏感，在這種環境下，技術攻關和線上應急顯得尤為重要，例如：如何解決線上線程卡死問題、如何解決OOM問題、如何解決服務超時問題等，可以參考如下兩篇文章：Java服務化系統線上應急和技術攻關，你必須掌握的Linux命令和Java服務化系統線上應急和技術攻關，你必須擁有的那些應用層腳本和Java虛擬機命令。
向這里看你會豁然開朗
希望這篇文章能夠幫助更多的傳統行業的從業人員轉入互聯網，在互聯網的大舞臺上展現你的才能，***，附贈一張筆者在互聯網行業里通過面試識別人才的《Java技能圖譜》，大家可以根據其中的思維導圖來深入學習各項知識點，每個知識點都需要系統的學習，或者看一本書或者查詢相關的資料，切記要積累知識的廣度的同事也要有一定的深度。
Java秘籍圖譜
點擊《Java領域從傳統行業向互聯網轉型你必須知道的那些事兒》閱讀原文。
【本文為51CTO專欄作者“李艷鵬”的原創稿件，轉載可通過作者簡書號(李艷鵬)或51CTO專欄獲取聯系】
