在Java生態(tài)中，構(gòu)建微服務(wù)的策略包括Container-less，Self-contained，以及In-container等。
創(chuàng)新互聯(lián)專注于靖邊企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),成都商城網(wǎng)站開發(fā)。靖邊網(wǎng)站建設(shè)公司,為靖邊等地區(qū)提供建站服務(wù)。全流程按需搭建網(wǎng)站，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)
Container-less微服務(wù)將應(yīng)用及其依賴打包成一個單一的jar文件。
Self-contained微服務(wù)也是打包成一個單一的Jar文件，但它還包括一個嵌入式框架，這個框架含有可選的第三方lib，當(dāng)然這些lib是兼容的。
In-container微服務(wù)打包成一個完整的Java
EE容器，該服務(wù)在Docker鏡像中實現(xiàn)。
基于微服務(wù)的架構(gòu)給架構(gòu)師和開發(fā)者帶來了新的挑戰(zhàn)，然而，隨著語言的升級和工具數(shù)量的增加，開發(fā)者和架構(gòu)師完全有能力應(yīng)對這樣的挑戰(zhàn)。Java也不例外，本文探討了在Java生態(tài)系統(tǒng)內(nèi)構(gòu)建微服務(wù)的不同方法。
引言
有人說，Java確實過于臃腫，經(jīng)常“小題大做”。但PHP、Node.js擴(kuò)展方面短板太明顯，做小應(yīng)用可以，大型應(yīng)用就玩不轉(zhuǎn)了。另外，JavaEE領(lǐng)域有太多優(yōu)秀框架可以解決開發(fā)效率的問題，事實上借用Spring等框架，開發(fā)的效率絲毫不亞于PHP。
互聯(lián)網(wǎng)時代的Java開發(fā)者，很多都不是基于Servlet和EJB來開發(fā)Web應(yīng)用，而且WebLogic、WebSphere也只會存在于大公司的存量系統(tǒng)中，互聯(lián)網(wǎng)公司的Java都是Tomcat的世界。
那么，微服務(wù)能完全彌補(bǔ)JavaEE的短板嗎?對于JaveEE來說，微服務(wù)扮演的，究竟是拯救者還是掘墓人的角色?
在Java問世之初，包括IBM、BEA、Oracle在內(nèi)的一些巨頭公司，看到了Java作為一門杰出的Web編程語言可能給他們帶來的巨大商機(jī)。那么如何通過一門編程語言來賺錢呢?答案就是，使用這門語言構(gòu)建復(fù)雜無比的服務(wù)器，讓那些大公司支付一大筆費(fèi)用來購買這些服務(wù)器。于是緊接著就出現(xiàn)了JavaEE規(guī)范、JSR規(guī)范，以及WebLogic、WebSphere等服務(wù)器中間件。
在這些服務(wù)器上面部署了大型的程序包，它們運(yùn)行緩慢，消耗大量的內(nèi)存?；谶@些容器的開發(fā)和調(diào)試對開發(fā)人員來說簡直就是噩夢，作為對他們的補(bǔ)償，他們從雇主那里獲得了豐厚的報酬。
因為耗資巨大，幾乎找不到一家公司可以使用合理的費(fèi)用長時間地支持Java。如果你要用Java構(gòu)建一個網(wǎng)站，你必須支付一大筆費(fèi)用來運(yùn)行這些服務(wù)器，哪怕你只用到了Servlet容器。在很長一段時間里，Java被用在企業(yè)和公司里，因為只有這些大公司能夠負(fù)擔(dān)得起數(shù)百萬美元的服務(wù)器費(fèi)用，并為那些企業(yè)級開發(fā)人員支付高額的薪水。
RodJohnson在2003年發(fā)布了Spring框架，Spring提供了IoC和對POJO的支持，幫助開發(fā)人員逃脫EJB魔掌。開發(fā)效率因此得到大幅的提升，大量開發(fā)人員轉(zhuǎn)向Spring，把EJB丟在一邊。應(yīng)用服務(wù)器開發(fā)商看到了這一點(diǎn)，他們在JavaEE5里提供了一些可以減輕開發(fā)人員負(fù)擔(dān)的特性?？上У氖?，Spring被一路追捧，人們幾乎把它跟JavaEE容器混為一談，它仍然運(yùn)行在JavaEE的Servlet容器里，這些容器沿用的是十年前的設(shè)計，并沒有考慮到多核CPU和NIO。
在這期間，PHP奮起直追。PHP使用更少的內(nèi)存和資源，得到很多公司的支持。一些CMS平臺，比如WordPress、Drupal等都是基于PHP構(gòu)建的，這些平臺吸引了大批PHP開發(fā)人員。不過，雖然PHP仍然是現(xiàn)今最流行的編程語言，但它也有自己的短板。它運(yùn)行速度不是很快，而且難以橫向擴(kuò)展。
2009年，RyanDahl啟動了Node.js項目，它支持異步非阻塞的、基于事件驅(qū)動的I/O。如果服務(wù)器的線程使用得當(dāng)，Node.js可以極大地提升響應(yīng)速度，單個服務(wù)器的吞吐量可以媲美一個JavaEE服務(wù)器集群。Node.js是一個很好的作品，但它也有自己的局限性。Node.js難以擴(kuò)展，也難以與遺留的系統(tǒng)集成。
2014年，Undertow出現(xiàn)了，它是一個基于Java的非阻塞Web服務(wù)器。從#的測試結(jié)果來看，在一個價值8000美金的戴爾服務(wù)器上，它可以每秒鐘處理幾百萬個請求，而谷歌需要使用一個集群才能處理一百萬個同樣的請求。它是輕量級的，它的核心部分只需要1M內(nèi)存，它還包含了一個內(nèi)嵌的服務(wù)器，這個服務(wù)器使用不到4M的堆內(nèi)存。
基于UndertowCore構(gòu)建的LightJavaFramework是一個微服務(wù)容器，它支持設(shè)計驅(qū)動及生成代碼，并支持運(yùn)行時安全和運(yùn)行時驗證。
JavaEE廠商多年前，JavaEE廠商，比如Oracle和IBM，他們花費(fèi)數(shù)億美元開發(fā)應(yīng)用服務(wù)器(WebLogic和WebSphere)，這些服務(wù)器以數(shù)百萬的價格賣給了大型組織。但現(xiàn)在這些服務(wù)器賣不動了，因為JBoss迅速搶占了市場份額，Oracle對JavaEE的支持正在走下坡路：
#/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee
隨著微服務(wù)越來越多地受到關(guān)注，這些應(yīng)用服務(wù)器很難有好的銷量，因為這些服務(wù)器更適合用來部署單體應(yīng)用。有一個包含了數(shù)百個EJB的應(yīng)用，為了在WebLogic上測試一行代碼改動，居然用了45分鐘時間。
JavaEE客戶
從客戶角度來看，耗費(fèi)巨資購買這些服務(wù)器是不值得的，因為JavaEE所承諾的未必都是真的。一個為WebSphere開發(fā)的應(yīng)用無法部署在WebLogic上，所以你需要花更多的錢去升級服務(wù)器，因為廠商可能不再支持舊版的服務(wù)器，而這樣的更新會花費(fèi)你數(shù)百萬美元。
于是一些聰明人不禁要問，為什么我們要把應(yīng)用部署在這些龐然大物上?為什么我們要把應(yīng)用打包成一個ear包或war包，而不是jar包?為什么我們不能把大型的應(yīng)用拆分成更小的塊，讓它們可以獨(dú)立部署和擴(kuò)展?
微服務(wù)
微服務(wù)是這些問題的解藥。Wikipedia把微服務(wù)定義為“??一種軟件架構(gòu)風(fēng)格，復(fù)雜的應(yīng)用由一些獨(dú)立的進(jìn)程組成，這些進(jìn)程使用與語言無關(guān)的API進(jìn)行交互。這些進(jìn)程服務(wù)規(guī)模很小，高度離散，聚焦在一個很小的任務(wù)上，使用模塊化方式來構(gòu)建系統(tǒng)”。
微服務(wù)架構(gòu)讓構(gòu)建應(yīng)用變得更加容易，而且應(yīng)用被拆分成單獨(dú)的服務(wù)，這些服務(wù)可以被任意組合。每個服務(wù)可以被獨(dú)立部署，也可以被組合成一個應(yīng)用。這些服務(wù)還可能會被其他應(yīng)用依賴。它加快了服務(wù)的開發(fā)速度，因為只要定義好接口，服務(wù)可以并行開發(fā)。
微服務(wù)具備彈性和伸縮性。微服務(wù)不只依賴單個服務(wù)器和部署，它們可以被發(fā)布到多個機(jī)器上，或者多個數(shù)據(jù)中心及其它任何可用的區(qū)域。如果一個服務(wù)失效，可以啟動另外一個。因為整個應(yīng)用被分解成了微服務(wù)(小型服務(wù))，可以很容易地對其中某些熱門的服務(wù)進(jìn)行橫向擴(kuò)展。
如果你曾經(jīng)使用過COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那么你就會知道服務(wù)和組件并不是什么新生事物。企業(yè)在使用組件方面存在的一個最大問題是他們依賴大型的硬件服務(wù)器，并在同一個服務(wù)器上運(yùn)行很多應(yīng)用。我們有EJB、WAR包和EAR包，以及各種組件包，因為服務(wù)器資源太過昂貴，要盡可能地物盡其用。
不過從最近幾年的發(fā)展情況來看，之前的方式有些落伍。操作系統(tǒng)服務(wù)器一直在變化，虛擬資源可以被當(dāng)成組件發(fā)布，比如EC2、OpenStack、Vagrant和Docker。世界變了。微服務(wù)架構(gòu)看到了這種趨勢，硬件、云技術(shù)、多核CPU和虛擬技術(shù)也在發(fā)展，所以我們要改變以前的開發(fā)方式。
在開始新項目的時候不要再使用EAR包或WAR包了?，F(xiàn)在我們可以在Docker里運(yùn)行JVM，Docker只不過是一個進(jìn)程，但它可以表現(xiàn)得像一個操作系統(tǒng)一樣。Docker運(yùn)行在云端的操作系統(tǒng)上，而云端的操作系統(tǒng)運(yùn)行在虛擬機(jī)里，虛擬機(jī)運(yùn)行在Linux服務(wù)器上。這些服務(wù)器不是歸誰所有，而是被很多互不相識的人共享。如果出現(xiàn)流量高峰怎么辦?很簡單，使用更多的服務(wù)器實例。這就是為什么要把Java微服務(wù)運(yùn)行在一個單獨(dú)的進(jìn)程里，而不是JavaEE容器或servlet容器。
微服務(wù)一般會提供基于HTTP/JSON的API端點(diǎn)。這樣可以很容易地與其他服務(wù)(開源或閉源的)集成，只要這些服務(wù)提供了HTTP/JSON接口。服務(wù)可以通過更有意義的方式被消費(fèi)、被組合。EC2、S3及其他來自Amazon(或其他公司)的服務(wù)就是最好的例子?；A(chǔ)設(shè)施會成為應(yīng)用程序的一部分，而且它們是可編程的。
使用微服務(wù)架構(gòu)的應(yīng)用程序應(yīng)該是模塊化、可編程和可組合的。微服務(wù)之間可以相互替換。應(yīng)用程序的局部可以被重寫或改進(jìn)，而不會影響到整個應(yīng)用。如果所有的組件都提供了可編程的API，那么微服務(wù)之間的交互就會變得更簡單(永遠(yuǎn)不要相信那些不能通過curl訪問的微服務(wù))。
隨著微服務(wù)逐漸流行起來，很多廠商開始嘗試把他們的JavaEEWeb服務(wù)轉(zhuǎn)成微服務(wù)，這樣他們就可以繼續(xù)賣他們的過時產(chǎn)品，APIGateway就是這些廠商中的一個。
JasonBloomberg是Intellyx的主席，他在一篇文章里指出了傳統(tǒng)Web服務(wù)和微服務(wù)的區(qū)別，并對把傳統(tǒng)Web服務(wù)轉(zhuǎn)成微服務(wù)的趨勢提出了質(zhì)疑：
#/dangers-microservices-washing-get-value-strip-away-hype
微服務(wù)不是企業(yè)服務(wù)總線里的Web服務(wù)，也不是傳統(tǒng)的面向服務(wù)架構(gòu)，盡管它沿襲了SOA的一些基本概念。從根本上來說，微服務(wù)跟SOA是不一樣的，因為整個環(huán)境已經(jīng)發(fā)生了徹底的轉(zhuǎn)變。
微服務(wù)架構(gòu)的環(huán)境是沒有邊界的：端到端，基于云的應(yīng)用程序運(yùn)行在完全虛擬和容器化的基礎(chǔ)設(shè)施上。容器把應(yīng)用程序和服務(wù)組件化，DevOps為IT基礎(chǔ)設(shè)施提供框架，幫助自動化開發(fā)、部署和管理環(huán)境。
雖然容器對微服務(wù)來說不是必需的，不過微服務(wù)可以很容易地運(yùn)行在容器里。況且，把非微服務(wù)的代碼部署在容器里不是一個明智的選擇。
Docker和其他容器技術(shù)在某種程度上已經(jīng)被視為微服務(wù)的最好伴侶。容器是運(yùn)行微服務(wù)的最小資源子集。Docker簡化了微服務(wù)的開發(fā)，讓集成測試變得更簡單。
容器有助于微服務(wù)開發(fā)，但不是必需的。Docker也可以被用來部署單體應(yīng)用。微服務(wù)與容器可以很好地相融并進(jìn)，不過微服務(wù)包含的東西遠(yuǎn)比容器多!
結(jié)論
應(yīng)用開發(fā)的風(fēng)格這幾年一直在變化，而微服務(wù)變得越來越流行。大公司把大型應(yīng)用拆分成可以單獨(dú)部署的小型應(yīng)用，這些小型應(yīng)用被部署在云端的容器里。開源微服務(wù)框架LightJava為這些運(yùn)行在容器里的微服務(wù)提供了很多特性，它支持設(shè)計驅(qū)動，開發(fā)者只需要把注意力專注在業(yè)務(wù)邏輯上，剩下的事情可以由框架和DevOps流程來處理。
那么問題來了，你怎么看?
微服務(wù)有助于開發(fā)人員用更低的成本和更少的錯誤來開發(fā)程序。
常用的微服務(wù)框架：
1、Spring Boot
Spring Boot是Spring的一個特定版本，它通過對配置細(xì)節(jié)的處理，使微服務(wù)構(gòu)建更加簡便。創(chuàng)建Spring Boot旨在自啟動任何類型的Spring項目，而不僅僅是微服務(wù)。應(yīng)用程序完成后，Spring Boot將在Web服務(wù)器中混合，并輸出一個JAR文件，JVM除外。你可以將其視為原始Docker容器，這也是許多負(fù)責(zé)構(gòu)建微服務(wù)的開發(fā)者都非常喜歡Spring Boot的原因。
2、Dropwizard
Dropwizard框架為開發(fā)者提供了一個非常簡單的模型，里面包含了許多重要的模塊，你可以根據(jù)需求添加一些業(yè)務(wù)邏輯，或者配置其他內(nèi)容，最后你會發(fā)現(xiàn)JAR文件非常小，并且能夠快速啟動。
Dropwizard最大的限制可能是缺乏依賴注入。如果你希望使用依賴項注入來保持代碼的整潔和松散耦合，則需要自己添加庫，這點(diǎn)和Spring不同，但是現(xiàn)在Dropwizard也支持大多數(shù)功能，包括日志記錄、健康檢查和提供彈性代碼。
3、Cricket
是一個用于快速API開發(fā)框架。Cricket很小，盡管它包括許多額外的功能，如鍵值數(shù)據(jù)存儲，以避免連接數(shù)據(jù)庫和調(diào)度程序來控制后臺重復(fù)處理。沒有添加復(fù)雜性或其他依賴項，因此很容易將代碼添加到Cricket并啟動獨(dú)立的微服務(wù)。
4、Jersey
開發(fā)web服務(wù)的標(biāo)準(zhǔn)方法之一是RESTful web服務(wù)的Java API(又名JAX-RS)，這是Jersey框架中實現(xiàn)的通用規(guī)范。這種方法主要依賴于使用注釋來指定路徑映射和返回細(xì)節(jié)。從參數(shù)解析到JSON打包的所有其他內(nèi)容都由Jersey處理。
Jersey的主要優(yōu)點(diǎn)是它實現(xiàn)了JAX-RS標(biāo)準(zhǔn)，這個特性非常受歡迎，一些開發(fā)人員習(xí)慣將Jersey與Spring Boot結(jié)合在一起使用。
5、Play
體驗JVM跨語言能力的最佳方式之一是使用Play框架，這是可以與Java或任何其他JVM語言兼容的。它的基礎(chǔ)非常現(xiàn)代，具有異步、無狀態(tài)的模型，不會讓試圖跟蹤用戶及其會話數(shù)據(jù)的線程使服務(wù)器過載。還有許多額外的特性可以用來充實網(wǎng)站，比如OpenID、驗證和文件上傳支持。Play代碼庫已經(jīng)發(fā)展了十多年，因此你還會發(fā)現(xiàn)類似于對XML的支持的這種古老的功能。play既成熟又輕盈，這種組合還是比較有特色的。
當(dāng)然，常用的Java微服務(wù)框架還有Swagger、Helidon、WildFly Thorntail等，在此就不多贅述了。
希望能幫到你，望采納?。?！
重慶分公司
重慶分公司
