本篇文章給大家談?wù)刯ava微服務(wù)開源框架，以及java web微服務(wù)對(duì)應(yīng)的知識(shí)點(diǎn)，希望對(duì)各位有所幫助，不要忘了收藏本站喔。

本文目錄一覽：

• 1、GitHub上那些值得一試的Java開源庫？
• 2、北大青鳥java培訓(xùn)：編程開發(fā)都有哪些常用的開源框架？
• 3、北大青鳥java培訓(xùn)：微服務(wù)系統(tǒng)架構(gòu)的發(fā)展趨勢(shì)？
• 4、主流的微服務(wù)框架
• 5、北大青鳥java培訓(xùn)：微服務(wù)架構(gòu)的軟件運(yùn)行可能存在哪些問題？
• 6、微服務(wù)：Java EE的拯救者還是掘墓人?

GitHub上那些值得一試的Java開源庫？

作為一名程序員，你幾乎每天都會(huì)使用到GitHub上的那些著名Java第三方庫，比如ApacheCommons,Spring，Hibernate等等。除了基襲這些，你可能還會(huì)fork或Star一些其他的開源庫，但GitHub上的庫實(shí)在太多了，以至于對(duì)于個(gè)人來說，你很難有時(shí)間去發(fā)現(xiàn)并了解那些不斷加入的新庫，而它們卻往往能在一些新興領(lǐng)域中給你提供幫助。

我一直使用JAVA來寫后端應(yīng)用，平時(shí)也會(huì)關(guān)注一些國外技術(shù)大牛的博客(來自Tapki、DZone、GoogleDeveloper等技術(shù)博客)，從而注意到了一些新的而且很有意思Java開源庫，它們有些能給你的項(xiàng)目帶來幫助，有些是以游戲的形式幫你提高Java的編程水平，而另一些則能夠幫助你識(shí)別JAVA程序中的常見問題。在這多達(dá)330,000個(gè)JAVA開源庫中，我收集了下面這些或許也值得你一試的Java開源庫。

Strman-java_字符串處理

Strmen-java是一個(gè)字符串處理工具，你可以通過maven將它引入到項(xiàng)目中。除了Java本身的字符串處理方式外，我們還可以使用ApacheCommonLangs里的StringUtils來簡(jiǎn)化String的操作。但以上兩種方式對(duì)于我們?nèi)粘＞幊讨凶钊菀着龅降淖址幚韥碚f，仍然顯得有些不足。Strmen-java為我們提供了一個(gè)非常完整且強(qiáng)大的解決方案，使用它可以解決幾乎所有字符串瞎弊處理場(chǎng)景。

Bootique_微服務(wù)框架

以前開發(fā)Web應(yīng)用程序時(shí)，我們總需要先構(gòu)建一個(gè)應(yīng)用，然后將它打包(war)，再部署到如Tomcat這樣的Web容器中。但隨著微服務(wù)架構(gòu)的流行，我們需要更輕量化，非容器的開發(fā)框架。SpringBoot是我一直在使用的，而Bootique無疑是另一種優(yōu)秀的選擇。它允許你通過具有不同功能的模塊插入，來支持如RESTService，Webapp，定時(shí)調(diào)度，數(shù)據(jù)遷移等功能。而使用它寫的程序都則會(huì)被打包為一個(gè)Jar文件，你可以通過命令行更靈活地去啟動(dòng)它。

從很多角度看，它都很像SpringBoot，將你從Java應(yīng)用從它所依賴的Web容器中解放出來，程搏神兄序員們可以有更強(qiáng)的自主性，去寫主程序的main()函數(shù)。甚至在你不添加任何額外的模塊的情況下，你也能直接使用Bootqiue去實(shí)現(xiàn)一個(gè)Java應(yīng)用。

Gumshoe_Java程序檢測(cè)

Gumshoe是一個(gè)JAVA程序檢測(cè)工具，它能幫助你跟蹤程序的負(fù)載和性能。它能通過度量TCP,UDP,CPU使用等信息，幫助你分析出資源的使用情況，同時(shí)電腦培訓(xùn)發(fā)現(xiàn)它也提供了Java程序中調(diào)用棧的分析功能，比如提供某個(gè)方法調(diào)用的次數(shù)，頻度等信息。

北大青鳥java培訓(xùn)：編程開發(fā)都有哪些常用的開源框架？

對(duì)于程序員來說，大部分都是學(xué)習(xí)的編程開發(fā)語言，而編程也一直是互聯(lián)網(wǎng)軟件開發(fā)領(lǐng)域的主流編程語禪早絕言之一。

今天，我睜純們就一起來了解一下，的生態(tài)圈都包含了哪些框架。

的生態(tài)環(huán)境開放、自由，在Sun/Oracle、Google、Apache、Eclipse基金會(huì)等各大廠商，還有技術(shù)大牛的共同努力下，的生態(tài)圈異常繁榮，各種優(yōu)秀的開源框架層出不窮。

SpringBootSpringBoot是Pivotal團(tuán)隊(duì)推出的一個(gè)支持快速開發(fā)的框架，伴隨Spring4.0而生，繼承了Spring的優(yōu)秀特質(zhì)，簡(jiǎn)化了使用Spring編碼、配置、部署的過程，使項(xiàng)目的開發(fā)變得簡(jiǎn)單、敏捷。

SpringCloudSpringCloud是基于SpringBoot的一整套分布式系統(tǒng)下的微服務(wù)構(gòu)建框架，包含了眾多的子項(xiàng)目，如SpringCloudConfig、SpringCloudStream等。

Hadoop/SparkHadoop是個(gè)獲得極大應(yīng)用的大數(shù)據(jù)框架，是大數(shù)據(jù)領(lǐng)域標(biāo)志性的解決方案。

Spark通過完善的內(nèi)存計(jì)算和處理優(yōu)化，極大的提升了速度，是具備流處理能力的下一代批處理框架。

Spark體系還包括一系列附加庫，如SparkStreaming、SparkMLlib、SparkGraphX、SparkNet、CaffeOnSpark等。

KafkaKafka是LinkedIn使用Scala開發(fā)的一個(gè)分布式消息中間件，可以實(shí)現(xiàn)不同應(yīng)用之間的松耦合，由于其可擴(kuò)展、高吞吐、低延遲、高可靠等特性而被廣泛使用。

ElasticSearchElasticSearch是基于Lucene的實(shí)時(shí)分布式搜索引擎，山西北大青鳥認(rèn)為由于其搜索穩(wěn)定、可靠賀姿，速度快、安裝方便等特點(diǎn)，是使用廣泛的開源搜索引擎之一。

NutchNutch是Apache旗下的高度可擴(kuò)展、可伸縮、可插拔的開源網(wǎng)絡(luò)爬蟲框架，功能完整。

當(dāng)然爬出框架還有很多：Heritrix、Crawler4j、WebCollector、WebMagic、SeimiCrawler、HtmlUnit等，可根據(jù)實(shí)際項(xiàng)目需要選擇。

在爬蟲領(lǐng)域，Python可能使用的更多一些，入門也簡(jiǎn)單。

爬蟲的難點(diǎn)不在于語言的選擇，無論、Python都可以勝任，關(guān)鍵還是反反爬策略的制定，以及各種實(shí)戰(zhàn)的積累。

北大青鳥java培訓(xùn)：微服務(wù)系統(tǒng)架構(gòu)的發(fā)展趨勢(shì)？

隨著服務(wù)器開發(fā)技術(shù)的不斷發(fā)展，微服務(wù)架構(gòu)技術(shù)在各個(gè)方面都有了衡跡州很大的技術(shù)突破。

今天，電腦培訓(xùn)就一起來了解一下，在互聯(lián)網(wǎng)大環(huán)境下的微服務(wù)系統(tǒng)州喚架構(gòu)的發(fā)展趨勢(shì)。

1.服務(wù)網(wǎng)格白熱化服務(wù)網(wǎng)格是一咐蔽個(gè)專注于服務(wù)間通信的基礎(chǔ)設(shè)施層，也是目前受關(guān)注的與云原生有關(guān)的話題。

隨著容器的普及，服務(wù)拓?fù)渥兊迷絹碓絼?dòng)態(tài)化，這對(duì)網(wǎng)絡(luò)功能提出了更多的要求。

服務(wù)網(wǎng)格通過服務(wù)發(fā)現(xiàn)、路由、負(fù)載均衡、健康檢測(cè)和可觀察性來管理流量，簡(jiǎn)化容器與生俱來的復(fù)雜性。

隨著HAProxy、traefik和NGINX逐步把自己定位成數(shù)據(jù)平面，服務(wù)網(wǎng)格也變得越來越流行。

盡管服務(wù)網(wǎng)格還沒有得到大規(guī)模部署，但確實(shí)有些企業(yè)已經(jīng)在生產(chǎn)環(huán)境中運(yùn)行服務(wù)網(wǎng)格。

另外，服務(wù)網(wǎng)格不僅可以用在微服務(wù)或Kubernetes環(huán)境中，也可以被用在VM和無服務(wù)器架構(gòu)的環(huán)境中。

例如，美國國家生物技術(shù)信息中心雖然沒有使用容器，但他們使用了Linkerd。

2.事件驅(qū)動(dòng)架構(gòu)的崛起隨著業(yè)務(wù)場(chǎng)景的不斷變化，我們已經(jīng)看到了基于推送或事件的架構(gòu)正在成為一種趨勢(shì)。

服務(wù)向訂閱事件的觀察者容器發(fā)送事件，容器異步做出響應(yīng)，事件發(fā)送者可能對(duì)此一無所知。

與請(qǐng)求響應(yīng)式架構(gòu)不同的是，在基于事件的系統(tǒng)架構(gòu)中，發(fā)起事件的容器并不依賴下游的容器，它們的處理過程和加載的事務(wù)與下游容器的可用性或完成情況無關(guān)。

這種架構(gòu)的另一個(gè)好處是，開發(fā)者可以更加獨(dú)立地設(shè)計(jì)各自的服務(wù)。

3.安全模型的變化因?yàn)閷?duì)內(nèi)核訪問方面的限制，部署在容器中的應(yīng)用程序相對(duì)安全。

在VM環(huán)境中，虛擬設(shè)備驅(qū)動(dòng)器是暴露可見性的地方。

而在容器環(huán)境里，操作系統(tǒng)提供了系統(tǒng)調(diào)用，信號(hào)源也變得更加豐富。

之前，管理員需要在VM中安裝代理，但那樣太復(fù)雜了，需要管理太多的東西。

容器提供了更清晰的可見性，相比VM，與容器的集成會(huì)更加容易。

4.從REST到GraphQLGraphQL是Facebook于2012年創(chuàng)建并于2015年開源的一套查詢語言API規(guī)范。

GraphQL的類型系統(tǒng)允許開發(fā)者自己定義數(shù)據(jù)schema，可以增加新字段，也可以刪除舊字段，這些都不會(huì)影響已有的查詢，也不需要修改客戶端。

GraphQL非常強(qiáng)大，因?yàn)樗鼪]有與特定的數(shù)據(jù)庫或存儲(chǔ)引擎綁定在一起。

主流的微服務(wù)框架

目前比較火的主流微服務(wù)框架

1）Spring Cloud , 來自Spring，具有Spring 社區(qū)的強(qiáng)大支撐，還有Netflix強(qiáng)大的后盾與技術(shù)輸出。Netflix作為一家成功實(shí)踐微服務(wù)架構(gòu)的互聯(lián)網(wǎng)公司在幾年前就把幾乎整個(gè)微服務(wù)框架棧開源貢獻(xiàn)給了社區(qū)，這些框架開源的整套服務(wù)架構(gòu)套件是Spring Cloud的核心。

- Eureka:服務(wù)注冊(cè)發(fā)現(xiàn)框架；

- Zuul:服務(wù)網(wǎng)關(guān)；

- Karyon：服務(wù)端框架；

- Ribbon：客戶端框架；

- Hystrix：服務(wù)容錯(cuò)組件；

- Archaius：服務(wù)配置組亮嫌件；

- Servo：Metrics組件；

- Blitz4j：日志組件；

2）Dobbo是一個(gè)分布式服務(wù)框架，是阿里開放的微服務(wù)化治理框架，致力于提高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案。其核心部分(官網(wǎng))

- 遠(yuǎn)程通訊: 提供對(duì)多種基于長(zhǎng)連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請(qǐng)求-響應(yīng)”模式的信息交換方式；

- 集群容錯(cuò): 提供基于接口方法的透明遠(yuǎn)程過程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯(cuò)，地址路由，動(dòng)態(tài)配置等集群支持；

- 自動(dòng)發(fā)現(xiàn): 基于注咐者冊(cè)中心目錄服務(wù)，使服務(wù)消費(fèi)方能動(dòng)態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。

Dubbo 也是采用全 Spring 配置方式，透明化接入應(yīng)用，對(duì)應(yīng)用沒有任何 API 侵入，只需用 Spring 加載 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 擴(kuò)展進(jìn)行加載。當(dāng)然也支持官方不推薦的 API 調(diào)用方式。

3）lstio 作為用于微服務(wù)聚合層管理的新銳項(xiàng)目，是Google、IBM、Lyft（海外共享出行公司、Uber勁敵），首個(gè)共同聯(lián)合開源的項(xiàng)目，提供了統(tǒng)一的連接，安全，管理和監(jiān)控微服務(wù)的方案。

目前首個(gè)測(cè)試版是針對(duì)Kubernetes環(huán)境的，社區(qū)宣稱在未來幾個(gè)月內(nèi)會(huì)為虛擬機(jī)和Cloud Foundry 等其他環(huán)境增加支持。lstio將 流量管理添加到微服務(wù)中，并為增值功能（如安全性、監(jiān)控、路由、連接管理和策略）創(chuàng)造了基礎(chǔ)。

- HTTP、gRPC 和 TCP 網(wǎng)絡(luò)流量自動(dòng)負(fù)載均衡；

- 提供了豐富的路由規(guī)則，實(shí)現(xiàn)細(xì)顆粒度的網(wǎng)絡(luò)流量行為控制；

- 流量加密、服務(wù)件認(rèn)證，以及強(qiáng)身份聲明；

- 全范圍（Fleet-wide）的策略執(zhí)行；

- 深度遙測(cè)和報(bào)告。

開源社區(qū)情況：現(xiàn)如今企業(yè)在采用云計(jì)算首選開源，而選擇一個(gè)開源框架，社區(qū)的活躍度將作為重要參考選項(xiàng)。

查看下在 Github 上的更新時(shí)間，截止 2017 年 8 月 31 日：

可衡鍵薯見，項(xiàng)目在社區(qū)活躍度上，Istio Spring Cloud Dubbo，結(jié)合穩(wěn)定性來看，對(duì)于使用 Java 系開發(fā)業(yè)務(wù)較多的企業(yè)，Spring Cloud 是相對(duì)更優(yōu)的選擇，對(duì)于更多企業(yè)來說，與語言幾乎無綁定的 Istio 也是可以好好期待一下其在社區(qū)的發(fā)展。

同時(shí)，隨著近幾年微服務(wù)架構(gòu)和 Docker 容器概念的火爆，也會(huì)讓 Spring Cloud 在未來越來越“云”化的軟件開發(fā)風(fēng)格中立有一席之地

北大青鳥java培訓(xùn)：微服務(wù)架構(gòu)的軟件運(yùn)行可能存在哪些問題？

微服務(wù)架構(gòu)開發(fā)在軟件編程開發(fā)領(lǐng)域中是一種非常常見的軟件開發(fā)方式了，而今天我們就一起來了解一下，基于微服務(wù)架構(gòu)的系統(tǒng)軟件在運(yùn)行過程中都有哪些問題會(huì)發(fā)生。

一：Hystrix是什么?1.1:基本解釋Hystrix開始由Netflix(看過美劇的都知道,它是一個(gè)美劇影視制作的巨頭公司)開源的，后來由SpringCloudHystrix基于這款框架實(shí)現(xiàn)了斷路器、線程隔離等一系列服務(wù)保護(hù)功能,該框架的目標(biāo)在于通過控制訪問遠(yuǎn)程系統(tǒng)、服務(wù)和三方庫的節(jié)點(diǎn)，從而延遲和故障提供更強(qiáng)大的容錯(cuò)能力。

hystrix具備服務(wù)降級(jí)、服務(wù)熔斷、線程和信號(hào)隔離、請(qǐng)求緩存、請(qǐng)求合并以及服務(wù)監(jiān)控等強(qiáng)大功能。

起到了微服務(wù)的保護(hù)機(jī)制,防止某個(gè)單元出現(xiàn)故障.從而引起依賴關(guān)系引發(fā)故障的蔓延，終導(dǎo)致整個(gè)系統(tǒng)的癱瘓。

1.2:斷路器的概念斷路器本身是一個(gè)開關(guān)裝置，用在電路上保護(hù)線路碧族過載，當(dāng)線路中有電器發(fā)生短路的時(shí)候。

“斷路器”能夠及時(shí)切斷故障，防止發(fā)生過載、發(fā)熱甚至起火等嚴(yán)重后果。

當(dāng)分布式架構(gòu)中，斷路器模式起到的作用也是類似的。

當(dāng)某個(gè)服務(wù)發(fā)生故障的時(shí)候，通過斷路器的故障監(jiān)控向調(diào)用方返回一個(gè)錯(cuò)誤響應(yīng)，而不是長(zhǎng)時(shí)間的線程掛機(jī)，無限等待。

這樣就不會(huì)使線程因故障服務(wù)被長(zhǎng)時(shí)間占用不釋放，避免了故障在分此弊布式系統(tǒng)中的蔓延。

二：Hystrix解決超時(shí)問題2.1：?jiǎn)栴}假設(shè)我們前端提供了用戶查詢訂單的功能，先請(qǐng)求映射到OrderController，控制器通過調(diào)用服務(wù)orderService獲取訂單信息，前端傳過來兩個(gè)參數(shù)：一個(gè)是訂單id,一個(gè)是用戶id,orderService需要通過用戶id調(diào)取用戶服務(wù)來獲取用戶的相關(guān)信息返回給訂單服務(wù)去組裝信息，假設(shè)這里是通過http請(qǐng)求的，我們有一個(gè)單獨(dú)的工程叫做：userService部署在其他的服務(wù)器上。

但是這個(gè)服務(wù)器宕機(jī)了，這時(shí)候訂單服務(wù)調(diào)取用戶信息就失敗了，然后查詢訂單整個(gè)請(qǐng)求就失敗了!由一個(gè)服務(wù)的宕機(jī)就導(dǎo)致整個(gè)查詢都失敗了，牽一發(fā)而動(dòng)全身。

三：Hystrix的流程Hystrix實(shí)際上的工森慧族作原理是這樣的:通過command來解耦請(qǐng)求與返回操作，在具體的實(shí)例中就是，Hystrix會(huì)對(duì)依賴的服務(wù)進(jìn)行觀察,通過command.toObservable調(diào)用返回一個(gè)觀察的對(duì)象，同時(shí)發(fā)起一個(gè)事件，然后用Subscriber對(duì)接受到的事件進(jìn)行處理。

陜西北大青鳥建議在command命令發(fā)出請(qǐng)求后，它通過一系列的判斷，順序依次是緩存是否命中、斷路器是否打開、線程池是否占滿，然后它才會(huì)開始對(duì)我們編寫的代碼進(jìn)行實(shí)際的請(qǐng)求依賴服務(wù)的處理，也就是Hystrix.run方法，如果在這其中任一節(jié)點(diǎn)出現(xiàn)錯(cuò)誤或者拋出異常，它都會(huì)返回到fallback方法進(jìn)行服務(wù)降級(jí)處理，當(dāng)降級(jí)處理完成之后，它會(huì)將結(jié)果返回給,際的調(diào)用者,經(jīng)過一系列流程處理的。

微服務(wù)：Java EE的拯救者還是掘墓人?

引言

有人說，Java確實(shí)過于臃腫，經(jīng)?！靶☆}大做”。但PHP、Node.js擴(kuò)展方面短板太明顯，做小應(yīng)用可以，大型應(yīng)用就玩不轉(zhuǎn)了。另外，JavaEE領(lǐng)域有太多優(yōu)秀框架可以解決開發(fā)效率的問題，事實(shí)上借用Spring等框架，開發(fā)的效率絲毫不亞于PHP。

互聯(lián)網(wǎng)時(shí)代的Java開發(fā)者，很多都不是基于Servlet和EJB來開發(fā)Web應(yīng)用，而且WebLogic、WebSphere也只會(huì)存在于大公司的存量系統(tǒng)中，互聯(lián)網(wǎng)公司的Java都是Tomcat的世界。

那么，微服務(wù)能完全彌補(bǔ)JavaEE的短板嗎?對(duì)于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)試對(duì)開發(fā)人員來說簡(jiǎn)直就是噩夢(mèng)，作為對(duì)他們的補(bǔ)償，他們從雇主那里獲得了豐厚的報(bào)酬。

因?yàn)楹馁Y巨大，幾乎找不到一家公攜判司可以使用合理的費(fèi)用長(zhǎng)時(shí)間地支持Java。如果你要用Java構(gòu)建一個(gè)網(wǎng)站，你必須支付一大筆費(fèi)用來運(yùn)行這些服務(wù)器，哪怕你只用到了Servlet容器。在很長(zhǎng)一段時(shí)間里，Java被用在企業(yè)和公司里，因?yàn)橹挥羞@些大公司能夠負(fù)擔(dān)得起數(shù)百萬美元的服務(wù)器費(fèi)用，并為那些企業(yè)級(jí)開發(fā)人員支付高額的薪水。

RodJohnson在2003年發(fā)布了Spring框架，Spring提供了IoC和對(duì)POJO的支持，幫助開發(fā)人員逃脫EJB魔掌。開發(fā)效率因此得到大幅的提升，大量開發(fā)人員轉(zhuǎn)向Spring，把EJB丟在一邊。應(yīng)用服務(wù)器開發(fā)商看到了這一點(diǎn)，他們?cè)贘avaEE5里提供了一些可以減輕開發(fā)人員負(fù)擔(dān)的特性。可惜的是，Spring被一路追捧，人們幾乎把它跟JavaEE容器混為一談，它仍然運(yùn)行在JavaEE的Servlet容器里，這些容器沿用的是十年前的設(shè)計(jì)，并沒有考慮到多核CPU和NIO。

在這期間，PHP奮起直追。PHP使用更少的內(nèi)存和資源，得到很多公司的支持。一些CMS平臺(tái)，比如WordPress、Drupal等都是基于PHP構(gòu)建的，這些平臺(tái)吸引了大批PHP開發(fā)人員。不過，雖然PHP仍然是現(xiàn)今最流行的編程語言，但它也有自己的短板。它運(yùn)行速度不是很快，而且難以橫向擴(kuò)展。

2009年，RyanDahl啟動(dòng)了Node.js項(xiàng)目，它支持異步非阻塞的、基于事件驅(qū)動(dòng)的I/O。如果服務(wù)器的線喚知程使用得當(dāng)，Node.js可以極大地提升響應(yīng)速度，單個(gè)服務(wù)器的吞吐量可以媲美一個(gè)JavaEE服務(wù)器集群。Node.js是一個(gè)很好的作品，但它也有自己的局限性。Node.js難以擴(kuò)展，也難以與遺留的系統(tǒng)集成。

2014年，Undertow出現(xiàn)了，它是一個(gè)基于Java的非阻塞Web服務(wù)器。從#的測(cè)試結(jié)果來看，在一個(gè)價(jià)值8000美金的戴爾服務(wù)器上，它可以每秒鐘處理幾百萬個(gè)請(qǐng)求，而谷歌需要使用一個(gè)集群才能處理一百萬個(gè)同樣的請(qǐng)求。它是輕量級(jí)的，它的核心部分只需要1M內(nèi)存，它還包含了一個(gè)內(nèi)嵌的服務(wù)器，這個(gè)服務(wù)器使用不到4M的堆內(nèi)存。

基于UndertowCore構(gòu)建的LightJavaFramework是一個(gè)微服務(wù)容器，它支持設(shè)計(jì)驅(qū)動(dòng)及生成代碼，并支持運(yùn)行時(shí)安全和運(yùn)行時(shí)驗(yàn)證。

JavaEE廠商多年前，JavaEE廠商，比如Oracle和IBM，他們花費(fèi)數(shù)億美元開發(fā)應(yīng)用服務(wù)器(WebLogic和WebSphere)，這些服務(wù)器以數(shù)百萬的價(jià)格賣給了大型組織。但現(xiàn)在這些服務(wù)器賣不動(dòng)了，因?yàn)镴Boss迅速搶占了市場(chǎng)份額，Oracle對(duì)JavaEE的支持正在走下坡路：

#/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee

隨著微服務(wù)越來越多地受到關(guān)注，這些應(yīng)用服務(wù)器很難有好的銷量，因?yàn)檫@些服務(wù)器更適合用來部署單體應(yīng)用。有一個(gè)包含了數(shù)百個(gè)EJB的應(yīng)用，為了在WebLogic上測(cè)試一行代碼改動(dòng)，居然用了45分鐘時(shí)間。

JavaEE客戶

從客戶角度來看，耗費(fèi)巨資購買這些服務(wù)器是不值得的，因?yàn)镴avaEE所承諾的未必都是真的。一個(gè)為WebSphere開發(fā)的應(yīng)用無法部署在WebLogic上，所以你需要花更多的錢去升級(jí)服務(wù)器，因?yàn)閺S商可能不再支持舊版的服務(wù)器，而這樣的更新會(huì)花費(fèi)你數(shù)百萬美元。

于是一些聰明人不禁要問，為什么我們要把應(yīng)用部署在這些龐然大物上?為什么我們要把應(yīng)用打包成一個(gè)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ī)模很小，高度離散，聚焦在一個(gè)很小的任務(wù)上，使用模塊化方式來構(gòu)建系統(tǒng)”。

微服務(wù)架構(gòu)讓構(gòu)建應(yīng)用變得更加容易，而且應(yīng)用被拆分成單獨(dú)的服務(wù)，這些服務(wù)可以被任意組合。每個(gè)服務(wù)可以被獨(dú)立部署，也可以被組合成一個(gè)應(yīng)用。這些服務(wù)還可能會(huì)被其他應(yīng)用依賴。它加快了服務(wù)的開發(fā)速度，因?yàn)橹灰x好接口，服務(wù)可以并行開發(fā)。

微服務(wù)具備彈性和伸縮性。微服務(wù)不只依賴單個(gè)服務(wù)器和部署，它們可以被發(fā)布到多個(gè)機(jī)器上，或者多個(gè)數(shù)據(jù)中心及其它任何可用的區(qū)域。如果一個(gè)服務(wù)失效，可以啟動(dòng)另外一個(gè)。因?yàn)檎麄€(gè)應(yīng)用被分解成了微服務(wù)(小型服務(wù))，可以很容易地對(duì)其中某些熱門的服務(wù)進(jìn)行橫向擴(kuò)展。

如果你曾經(jīng)使用過COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那么你就會(huì)知道服務(wù)和組件并不是什么新生事物。企業(yè)在使用組件方面存在的一個(gè)最大問題是他們依賴大型的硬件服務(wù)器，并在同一個(gè)服務(wù)器上運(yùn)行很多應(yīng)用。我們有EJB、WAR包和EAR包，以及各種組件包，因?yàn)榉?wù)器資源太過昂貴，要盡可能地物盡其用。

不過從最近幾年的發(fā)展情況來看，之前的方式有些落伍。操作系統(tǒng)服務(wù)器一直在變化，虛擬資源可以被當(dāng)成組件發(fā)布，比如EC2、OpenStack、Vagrant和Docker。世界變了。微服務(wù)架構(gòu)看到了這種趨勢(shì)，硬件、云技術(shù)、多核CPU和虛擬技術(shù)也在發(fā)展，所以我們要改變以前的開發(fā)方式。

在開始新項(xiàng)目的時(shí)候不要再使用EAR包或WAR包了。現(xiàn)在我們可以在Docker里運(yùn)行JVM，Docker只不過是一個(gè)進(jìn)程，但它可以表現(xiàn)得像一個(gè)操作系統(tǒng)一樣。Docker運(yùn)行在云端的操作系統(tǒng)上，而云端的操作系統(tǒng)運(yùn)行在虛擬機(jī)里，虛擬機(jī)運(yùn)行在Linux服務(wù)器上。這些服務(wù)器不是歸誰所有，而是被很多互不相識(shí)的人共享。如果出現(xiàn)流量高峰怎么辦?很簡(jiǎn)單，使用更多的服務(wù)器實(shí)例。這就是為什么要把Java微服務(wù)運(yùn)行在一個(gè)單獨(dú)的進(jìn)程里，而不是JavaEE容器或servlet容器。

微服務(wù)一般會(huì)提供基于HTTP/JSON的API端點(diǎn)。這樣可以很容易地與其他服務(wù)(開源或閉源的)集成，只要這些服務(wù)提供了HTTP/JSON接口。服務(wù)可以通過更有意義的方式被消費(fèi)、被組合。EC2、S3及其他來自Amazon(或其他公司)的服務(wù)就是最好的例子。基礎(chǔ)設(shè)施會(huì)成為應(yīng)用程序的一部分，而且它們是可編程的。

使用微服務(wù)架構(gòu)的應(yīng)用程序應(yīng)該是模塊化、可編程和可組合的。微服務(wù)之間可以相互替換。應(yīng)用程序的局部可以被重寫或改進(jìn)，而不會(huì)影響到整個(gè)應(yīng)用。如果所有的組件都提供了可編程的API，那么微服務(wù)之間的交互就會(huì)變得更簡(jiǎn)單(永遠(yuǎn)不要相信那些不能通過curl訪問的微服務(wù))。

隨著微服務(wù)逐漸流行起來，很多廠商開始嘗試把他們的JavaEEWeb服務(wù)轉(zhuǎn)成微服務(wù)，這樣他們就可以繼續(xù)賣他們的過時(shí)產(chǎn)品，APIGateway就是這些廠商中的一個(gè)。

JasonBloomberg是Intellyx的主席，他在一篇文章里指出了傳統(tǒng)Web服務(wù)和微服務(wù)的區(qū)別，并對(duì)把傳統(tǒng)Web服務(wù)轉(zhuǎn)成微服務(wù)的趨勢(shì)提出了質(zhì)疑：

#/dangers-microservices-washing-get-value-strip-away-hype

微服務(wù)不是企業(yè)服務(wù)總線里的Web服務(wù)，也不是傳統(tǒng)的面向服務(wù)架構(gòu)，盡管它沿襲了SOA的一些基本概念。從根本上來說，微服務(wù)跟SOA是不一樣的，因?yàn)檎麄€(gè)環(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è)施提供框架，幫助自動(dòng)化開發(fā)、部署和管理環(huán)境。

雖然容器對(duì)微服務(wù)來說不是必需的，不過微服務(wù)可以很容易地運(yùn)行在容器里。況且，把非微服務(wù)的代碼部署在容器里不是一個(gè)明智的選擇。

Docker和其他容器技術(shù)在某種程度上已經(jīng)被視為微服務(wù)的最好伴侶。容器是運(yùn)行微服務(wù)的最小資源子集。Docker簡(jiǎn)化了微服務(wù)的開發(fā)，讓集成測(cè)試變得更簡(jiǎn)單。

容器有助于微服務(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è)計(jì)驅(qū)動(dòng)，開發(fā)者只需要把注意力專注在業(yè)務(wù)邏輯上，剩下的事情可以由框架和DevOps流程來處理。

那么問題來了，你怎么看?

java微服務(wù)開源框架的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于java web微服務(wù)、java微服務(wù)開源框架的信息別忘了在本站進(jìn)行查找喔。