武林中，"天下武功出少林"指各門各派的武功都與少林武學有一定的淵源，技術也是相同的道理，對於 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 vs. Memcache，這裡部落格文章只是簡單的介紹了 Redis 和 Memcache 的區別，要想深入學習快取技術推薦大家仔細閱讀 Redis 設計與實現一書。

除了要學習分散式快取，例如：Redis、Memcache 本身的功能和技術點外，最主要的要有快取分片的思想，在互聯網裡大多數的熱資料都是快取在快取服務中的，這需要大量的快取伺服器，單臺機器是不能滿足需求的，那快取分片是一個大話題，快取分片的實現方式一般有如下 3 種：

1. 通過代理層實現，例如 Codis，在代理層實現資料的路由，對應用層透明。

2. 客戶端分片，可參考我的開源專案 redic，實現簡單、使用簡單、支援分片、複製、失效轉移等功能。

3. 快取伺服器支援的高可用模式，例如：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 原理？如果我們保證的是最終一致性模型，我們都有哪些模式可以應用，請參考我的部落格文章保證微服務架構一致性的公開課，這篇文章裡有視訊、PPT 和完整的一致性保證的文章幫助大家學習一致性保證的最佳實踐和完善的理論體系。

最近微服務變得越來越流行，微服務實際上是服務化的一個延續，是更細緻化的服務化的架構，微服務的服務框架的代表是 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》兩本龍書，這些書籍都可以從Java核心必讀書籍共享這篇文章下載。

  大資料與雲端計算

作為一個IT從業人員，一定要跟上技術潮流，像雲端計算，大資料，CAP, BASE, 選主演算法等概念不得不去了解，對於熱點技術不得不研究，例如： Hadoop, Hbase, Zookeeper, Openstack, Dooker, Kafka, Storm 等。

對於大資料技術推薦閱讀Google三大論文，Mapreduce, GFS和BigTable，這三篇論文是大資料處理的鼻祖型論文，最核心的分散式儲存、分散式處理、大檔案的高效儲存等技術都在這裡，大資料鼻祖的三大論文可以從我的部落格文章谷歌大資料的三駕馬車下載。

  效能評估和容量估算

如果你決定要來網際網路一顯身手，你必須學會效能評估和容量估算，這包括對前端機、快取、訊息佇列、資料庫等各個效能指標的估算，例如：吞吞量，響應時間，記憶體，CPU，IO，網路 IO 等。

為了確保架構設計的合理性，效能和容量評估是在架構設計初期完成的，用來證明架構方案可行，但是在專案實施中和實施後，還需要對專案的進行壓測，來證明專案按照既定的目標而推薦和完成，關於效能測試的方法論和設計流程，我將會在後續文章中介紹給讀者。

  網際網路架構方法論

在網際網路行業裡，處理大規模高併發的使用者請求的核心思想只有一個，那就是“分而治之”，因此，通常業務被拆分為多個職責單一的服務，在某一個單服務裡，業務邏輯並不複雜，但是對非功能質量需求的要求較高，這通常表現在效能、可用性等方面，因此網際網路的架構設計中首要考慮的是非功能質量，這和傳統行業注重功能和業務流程的情況有所不同，對於網際網路行業中，架構設計的案例，可以參考這篇原創發號器 Vesta 的設計與實現如何設計一款多場景分散式發號器（Vesta），來了解網際網路業務的架構設計的風格和思路。

  技術攻關和線上應急

在網際網路企業裡，大多數產品都是針對使用者端的，使用者端的產品的特點是擁有海量的使用者、產品要能夠處理海量使用者產生的大規模高併發的使用者請求，因此會對產品的可用性比較敏感，在這種環境下，技術攻關和線上應急顯得尤為重要，例如：如何解決線上執行緒卡死問題、如何解決 OOM 問題、如何解決服務超時問題等，可以參考如下兩篇文章：和。

  向這裡看你會豁然開朗

希望這篇文章能夠幫助更多的傳統行業的從業人員轉入網際網路，在網際網路的大舞臺上展現你的才能，最後，附贈一張筆者在網際網路行業裡通過面試識別人才的《Java 技能圖譜》，大家可以根據其中的思維導圖來深入學習各項知識點，每個知識點都需要系統的學習，或者看一本書或者查詢相關的資料，切記要積累知識的廣度的同事也要有一定的深度。