武林中，"天下武功出少林"指各門各派的武功都與少林武學有一定的淵源，技術(shù)也是相同的道理，對于Java領(lǐng)域的應(yīng)用而言，傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)的技術(shù)都來自J2SE和J2EE的生態(tài)圈，但是兩個行業(yè)的側(cè)重點不同，傳統(tǒng)行業(yè)側(cè)重于嚴格的規(guī)范、復雜的流程、豐富的功能，因此或多或少的都會使用J2EE規(guī)范定義的技術(shù)，Appserver是J2EE規(guī)范的完全實現(xiàn)，因此，傳統(tǒng)行業(yè)的企業(yè)級軟件開發(fā)基本都是部署在Appserver上的，這樣可以重復利用Appserver提供的通用功能而節(jié)省開發(fā)和實現(xiàn)的工作量，而后者更注重互聯(lián)網(wǎng)產(chǎn)品的非功能質(zhì)量需求，通常包括高可用、高性能、安全性、可伸縮、可擴展等，“天下武功唯快而不破”，充分看出互聯(lián)網(wǎng)企業(yè)里程序性能的重要性，為了達到較好的性能，高度抽象的J2EE技術(shù)已經(jīng)沒法滿足需求，因此互聯(lián)網(wǎng)技術(shù)更傾向于在簡單的J2SE上發(fā)展具有互聯(lián)網(wǎng)特色的技術(shù)棧，重新定義互聯(lián)網(wǎng)級的開發(fā)工具、平臺和技術(shù)棧。

本文就是給這些想從傳統(tǒng)行業(yè)跨入互聯(lián)網(wǎng)的小伙伴們準備的一篇導向性文章，幫助各位了解互聯(lián)網(wǎng)的技術(shù)棧、互聯(lián)網(wǎng)的側(cè)重點、互聯(lián)網(wǎng)的核心技術(shù)，并給出如何以傳統(tǒng)行業(yè)的技術(shù)棧為基礎(chǔ)快速掌握互聯(lián)網(wǎng)的核心技術(shù)。

這里需要再次澄清，小編并不認為互聯(lián)網(wǎng)行業(yè)的技術(shù)要比傳統(tǒng)技術(shù)深奧多少，這些技術(shù)跑不出J2SE和J2EE的生態(tài)圈，只不過高度抽象的J2EE技術(shù)由于性能上的局限性而被互聯(lián)網(wǎng)撇棄而已，但是不得不承認的是兩個行業(yè)的側(cè)重點不同，傳統(tǒng)行業(yè)側(cè)重于規(guī)范，流程，功能的復雜性以及正確性，而互聯(lián)網(wǎng)更側(cè)重于“快”，這里的“快”有兩方面的意思，一個是產(chǎn)品運行效率要高，響應(yīng)速度要快，另外一個是開發(fā)效率要快，響應(yīng)市場需求要快。從另外一個側(cè)面說，傳統(tǒng)行業(yè)一般關(guān)注一個復雜系統(tǒng)的功能完善和豐富，而互聯(lián)網(wǎng)企業(yè)更關(guān)注一個簡單的垂直業(yè)務(wù)的非功能質(zhì)量，例如高性能，可用性，高并發(fā)，可擴展，可伸縮，安全性等，那么，一個從業(yè)人員從傳統(tǒng)行業(yè)到互聯(lián)網(wǎng)行業(yè)，你到底還有多少距離?

小伙伴們從哪里開始入手互聯(lián)網(wǎng)

來自于傳統(tǒng)行業(yè)的技術(shù)人員，他們大多數(shù)掌握的技能是SSH，稍微資深一點的工程師對J2EE規(guī)范有所了解，他們?nèi)匀辉谑褂肑2EE規(guī)范的EJB、JPA、JMS、JCA、JAAS等技術(shù)，數(shù)據(jù)庫基本上使用Oracle、DB2、Sqlserver等等。傳統(tǒng)行業(yè)的開發(fā)人員基本實施“模塊包攬制”，這得益于J2EE規(guī)范的完整性，以及Appserver提供了基本所有架構(gòu)需要的功能，開發(fā)人員只需要將各個業(yè)務(wù)模塊填入J2EE和Appserver提供給你的框架即可，因此，一個傳統(tǒng)的開發(fā)人員會包攬一個模塊從前臺到后臺所有的工作，這包括HTML、JS、CSS、EJB、JPA、SQL、PLSQL等等。這些技術(shù)是不是一無是處，當然不是，反而是非常有價值的，那有了這些技術(shù)，我們是否可以一步跨入互聯(lián)網(wǎng)，也不是，還需要以這些技術(shù)為基礎(chǔ)，進一步擴展技術(shù)視野，對欠缺的技術(shù)廣度和深度進行不足。下面就學習傳統(tǒng)行業(yè)技術(shù)人員擁有哪些技術(shù)積累，下一步又如何補充自己的知識面，成為能夠勝任互聯(lián)網(wǎng)行業(yè)的優(yōu)秀技術(shù)人員呢?

消息隊列

在傳統(tǒng)行業(yè)，相信你一定用過JMS，作為J2EE規(guī)范的一部分，所有的Aappserver都有JMS的實現(xiàn)，那你一定知道JMS包含Queue和Topic兩種Subject，你也知道Send/Receive和Publish/Subscribe兩種收發(fā)模式，那在互聯(lián)網(wǎng)為什么就不用這些呢?原因主要有兩個，一個是商業(yè)的Appserver都是收費的，然而，互聯(lián)網(wǎng)提供的產(chǎn)品是免費的，互聯(lián)網(wǎng)使用的產(chǎn)品也多是免費的，另外一個原因就是這些Appserver的實現(xiàn)性能差，有測評顯示ActiveMQ比JbossMQ速度要高出10倍，在某些應(yīng)用場景下ZeroMQ的速度要高出一個數(shù)量級，可達到微妙級別的延遲。除此之外，一些開源的MQ的實現(xiàn)針對互聯(lián)網(wǎng)業(yè)務(wù)，提供了除Queue和Topic的支持，還有partition、group、broker等更復雜的消息模型，具體參考Kafka。 Kafka的設(shè)計具有使用簡單、功能豐富、高性能等優(yōu)點，不但天生具有持久、分片、復制等功能，而且在使用上對開發(fā)者和運維的體驗也很好。那么如果你在傳統(tǒng)行業(yè)掌握了JMS規(guī)范定義的消息隊列技術(shù)，你只需要再往前走一步，請深入學習開源的Kafka、RockitMQ、ActiveMQ、RabbitMQ、ZeroMQ、MSQ等。

緩存

在傳統(tǒng)行業(yè)，相信大家都用過Oscache和Ehcache, 前者主要針對網(wǎng)頁的緩存，后者主要針對數(shù)據(jù)庫數(shù)據(jù)的緩存，通常可作為Hibernate的二級緩存，相信有些人還用過Jboss Cache，這是一個分布式企業(yè)級可實時復制的Cache，有些人在項目中也寫了自己的緩存，甚至在一些項目中直接使用Hashtable作為緩存，其實這些緩存加速了特定場景下的數(shù)據(jù)訪問，對你的項目成功起到了至關(guān)重要的作用。但是互聯(lián)網(wǎng)行業(yè)則從另外一個角度來使用緩存，主要應(yīng)用場景有兩個：第一，大量的數(shù)據(jù)需要集中保存，在服務(wù)的任意節(jié)點上可以訪問緩存中的任意數(shù)據(jù)，也就是需要數(shù)據(jù)的中心存儲，而且還要滿足快速的查詢需求的場景;第二，數(shù)據(jù)庫讀性能是有瓶頸的，廉價硬件機器上的單機Mysql讀操作吞吐量在1000/s左右，大量的讀查詢會壓垮數(shù)據(jù)庫，這需要使用緩存來抗住讀流量，通常應(yīng)用在有熱點數(shù)據(jù)的場景。從這兩個應(yīng)用場景來看，互聯(lián)網(wǎng)行業(yè)更關(guān)心分布式緩存，那數(shù)據(jù)如何分布呢?很簡單，Hash或者一致性Hash，所以，咱們可不可以先把Oscache和Ehcache放一邊，來研究一下Redis，Memcache或者淘寶的Tair呢?最簡單的辦法從Redis和Memcache的區(qū)別開始入手?除了要學習分布式緩存，例如Redis、Memcache本身的功能和技術(shù)點外，最主要的要有緩存分片的思想，在互聯(lián)網(wǎng)里大多數(shù)的熱數(shù)據(jù)都是緩存在緩存服務(wù)中的，這需要大量的緩存服務(wù)器，單臺機器是不能滿足需求的，緩存分片是一個大話題，就不在這里深入討論了。

服務(wù)框架

在傳統(tǒng)行業(yè)，相信大家都使用EJB和Webservice來提供服務(wù)的導出和導入，有些個別傳統(tǒng)行業(yè)不用APP服務(wù)器，僅僅使用JDK的RMI來導出和導入服務(wù)，但是為什么互聯(lián)網(wǎng)偏偏不喜歡這些技術(shù)呢?Webservice使用重量級的SOAP協(xié)議，臃腫的XML滿世界都是，性能上的去嗎? 那互聯(lián)網(wǎng)用什么，互聯(lián)網(wǎng)使用輕量級的RPC框架和RESTful服務(wù)，前者使用輕量級的序列化框架，例如：Google的ProtoBuffer, 還有Hessian和Burlap等序列化協(xié)議，后者則使用簡單的HTTP協(xié)議，前者適合在內(nèi)網(wǎng)做高性能的服務(wù)調(diào)用，而后者適合異構(gòu)平臺的服務(wù)調(diào)用，例如跨語言、跨防火墻、前后臺之間等。在互聯(lián)網(wǎng)的世界里，幾乎所有的公司都實現(xiàn)了服務(wù)化，服務(wù)化導致的問題就是一致性問題，如何解決高并發(fā)系統(tǒng)的一致性呢?使用兩階段提交協(xié)議、三階段提交協(xié)議、TCC?還是遵循ACID原理、CAP原理、BASE原理?如果我們保證的是最終一致性模型，我們都有哪些模式可以應(yīng)用。最近微服務(wù)變得越來越流行，微服務(wù)實際上是服務(wù)化的一個延續(xù)，是更細致化的服務(wù)化的架構(gòu)，微服務(wù)的服務(wù)框架的代表是Spring Cloud，它與Netflix集成，提供了限流、熔斷、倉壁隔離、失效轉(zhuǎn)移等為服務(wù)化中必不可少的高級特性。

數(shù)據(jù)庫

在傳統(tǒng)行業(yè)，大多數(shù)人開發(fā)人員都使用Oracle、DB2、Sqlserver數(shù)據(jù)庫，其實，從功能和性能上來講，他們都不亞于Mysql, 甚至比Mysql更優(yōu)秀，但是Mysql是免費的，這使得Mysql得到互聯(lián)網(wǎng)行業(yè)的青睞。

那么我們分析下，傳統(tǒng)行業(yè)的人員在數(shù)據(jù)庫方面欠缺什么嗎?首先，Oracle和Mysql都使用B+樹索引，原理相同，使用方法相同;Oracle支持行級鎖，Mysql Innodb同樣支持行級鎖;Oracle Dataguard支持數(shù)據(jù)復制，Mysql也支持數(shù)據(jù)復制，但是Mysql的復制模式更靈活，并且支持主主配置。前面這些都是大同小異，如果你理解了相應(yīng)的Oracle技術(shù)，你用很少的時間就可以掌握Mysql的相關(guān)技術(shù)。但是不同點是，Oracle雖然支持集群，通過增加服務(wù)節(jié)點的方式可以增加服務(wù)性能，但是集群的節(jié)點數(shù)量是有限的，并且數(shù)據(jù)存儲是共享的，所以擴容基本采用垂直方式，然而使用Mysql則采用水平擴展，也就是需要進行手工的分區(qū)分表，對數(shù)據(jù)進行分而治之，以滿足日益增長的讀寫壓力以及數(shù)據(jù)存儲壓力。因此，如果想向互聯(lián)網(wǎng)轉(zhuǎn)行，一定要學好Mysql。在互聯(lián)網(wǎng)行業(yè)里面對性能追求到達了極致，因此會要求開發(fā)人員對數(shù)據(jù)庫原理有所了解，其中最重要的部分就是索引。

負載均衡

剛才談到，高并發(fā)系統(tǒng)，壓力山大的時候怎么辦?思想只有一個分而治之( divide-and-conquer)。因此，負載均衡則非常重要，傳統(tǒng)行業(yè)以銷售產(chǎn)品為盈利模式，因此，大多數(shù)項目在需要負載均衡的時候，多使用F5硬件負載均衡。實際上傳統(tǒng)的J2EE規(guī)范的EJB也可以分布式發(fā)布，通過JNDI的集成，也可以進行一定程度的負載均衡，但是這個負載均衡顯得太重量級，用起來非常的不方便，效率也很低，并且和APP服務(wù)器綁定。那么互聯(lián)網(wǎng)呢?多采用軟負載均衡，你必須了解LVS、nginx、Apache、Varnish、Haproxy等七層和三四層負載均衡原理和產(chǎn)品。

性能評估和容量估算

如果你決定要來互聯(lián)網(wǎng)一顯身手，你必須學會性能評估和容量估算，這包括對前端機、緩存、消息隊列、數(shù)據(jù)庫等各個性能指標的估算，例如：吞吞量，響應(yīng)時間，內(nèi)存，CPU，IO，網(wǎng)絡(luò)IO等。為了確保架構(gòu)設(shè)計的合理性，性能和容量評估是在架構(gòu)設(shè)計初期完成的，用來證明架構(gòu)方案可行，但是在項目實施中和實施后，還需要對項目的進行壓測，來證明項目按照既定的目標而推薦和完成。

希望這篇文章能夠幫助更多的傳統(tǒng)行業(yè)的從業(yè)人員轉(zhuǎn)入互聯(lián)網(wǎng)，在互聯(lián)網(wǎng)的大舞臺上展現(xiàn)你的才能。