微服務體系java類文章,目前比較流程的微服務開發框架

本文目錄一覽：

• 1、微服務：Java EE的拯救者還是掘墓人?
• 2、如何使用 java 構建微服務
• 3、北大青鳥java培訓：微服務與傳統單一服務架構的區別？

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

引言

有人說，Java確實過於臃腫，經常「小題大做」。但PHP、Node.js擴展方面短板太明顯，做小應用可以，大型應用就玩不轉了。另外，JavaEE領域有太多優秀框架可以解決開發效率的問題，事實上借用Spring等框架，開發的效率絲毫不亞於PHP。

互聯網時代的Java開發者，很多都不是基於Servlet和EJB來開發Web應用，而且WebLogic、WebSphere也只會存在於大公司的存量系統中，互聯網公司的Java都是Tomcat的世界。

那麼，微服務能完全彌補JavaEE的短板嗎?對於JaveEE來說，微服務扮演的，究竟是拯救者還是掘墓人的角色?

在Java問世之初，包括IBM、BEA、Oracle在內的一些巨頭公司，看到了Java作為一門傑出的Web編程語言可能給他們帶來的巨大商機。那麼如何通過一門編程語言來賺錢呢?答案就是，使用這門語言構建複雜無比的伺服器，讓那些大公司支付一大筆費用來購買這些伺服器。於是緊接著就出現了JavaEE規範、JSR規範，以及WebLogic、WebSphere等伺服器中間件。

在這些伺服器上面部署了大型的程序包，它們運行緩慢，消耗大量的內存。基於這些容器的開發和調試對開發人員來說簡直就是噩夢，作為對他們的補償，他們從僱主那裡獲得了豐厚的報酬。

因為耗資巨大，幾乎找不到一家公司可以使用合理的費用長時間地支持Java。如果你要用Java構建一個網站，你必須支付一大筆費用來運行這些伺服器，哪怕你只用到了Servlet容器。在很長一段時間裡，Java被用在企業和公司里，因為只有這些大公司能夠負擔得起數百萬美元的伺服器費用，並為那些企業級開發人員支付高額的薪水。

RodJohnson在2003年發布了Spring框架，Spring提供了IoC和對POJO的支持，幫助開發人員逃脫EJB魔掌。開發效率因此得到大幅的提升，大量開發人員轉向Spring，把EJB丟在一邊。應用伺服器開發商看到了這一點，他們在JavaEE5里提供了一些可以減輕開發人員負擔的特性。可惜的是，Spring被一路追捧，人們幾乎把它跟JavaEE容器混為一談，它仍然運行在JavaEE的Servlet容器里，這些容器沿用的是十年前的設計，並沒有考慮到多核CPU和NIO。

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

2009年，RyanDahl啟動了Node.js項目，它支持非同步非阻塞的、基於事件驅動的I/O。如果伺服器的線程使用得當，Node.js可以極大地提升響應速度，單個伺服器的吞吐量可以媲美一個JavaEE伺服器集群。Node.js是一個很好的作品，但它也有自己的局限性。Node.js難以擴展，也難以與遺留的系統集成。

2014年，Undertow出現了，它是一個基於Java的非阻塞Web伺服器。從#的測試結果來看，在一個價值8000美金的戴爾伺服器上，它可以每秒鐘處理幾百萬個請求，而谷歌需要使用一個集群才能處理一百萬個同樣的請求。它是輕量級的，它的核心部分只需要1M內存，它還包含了一個內嵌的伺服器，這個伺服器使用不到4M的堆內存。

基於UndertowCore構建的LightJavaFramework是一個微服務容器，它支持設計驅動及生成代碼，並支持運行時安全和運行時驗證。

JavaEE廠商多年前，JavaEE廠商，比如Oracle和IBM，他們花費數億美元開發應用伺服器(WebLogic和WebSphere)，這些伺服器以數百萬的價格賣給了大型組織。但現在這些伺服器賣不動了，因為JBoss迅速搶佔了市場份額，Oracle對JavaEE的支持正在走下坡路：

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

隨著微服務越來越多地受到關注，這些應用伺服器很難有好的銷量，因為這些伺服器更適合用來部署單體應用。有一個包含了數百個EJB的應用，為了在WebLogic上測試一行代碼改動，居然用了45分鐘時間。

JavaEE客戶

從客戶角度來看，耗費巨資購買這些伺服器是不值得的，因為JavaEE所承諾的未必都是真的。一個為WebSphere開發的應用無法部署在WebLogic上，所以你需要花更多的錢去升級伺服器，因為廠商可能不再支持舊版的伺服器，而這樣的更新會花費你數百萬美元。

於是一些聰明人不禁要問，為什麼我們要把應用部署在這些龐然大物上?為什麼我們要把應用打包成一個ear包或war包，而不是jar包?為什麼我們不能把大型的應用拆分成更小的塊，讓它們可以獨立部署和擴展?

微服務

微服務是這些問題的解藥。Wikipedia把微服務定義為「??一種軟體架構風格，複雜的應用由一些獨立的進程組成，這些進程使用與語言無關的API進行交互。這些進程服務規模很小，高度離散，聚焦在一個很小的任務上，使用模塊化方式來構建系統」。

微服務架構讓構建應用變得更加容易，而且應用被拆分成單獨的服務，這些服務可以被任意組合。每個服務可以被獨立部署，也可以被組合成一個應用。這些服務還可能會被其他應用依賴。它加快了服務的開發速度，因為只要定義好介面，服務可以並行開發。

微服務具備彈性和伸縮性。微服務不只依賴單個伺服器和部署，它們可以被發布到多個機器上，或者多個數據中心及其它任何可用的區域。如果一個服務失效，可以啟動另外一個。因為整個應用被分解成了微服務(小型服務)，可以很容易地對其中某些熱門的服務進行橫向擴展。

如果你曾經使用過COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那麼你就會知道服務和組件並不是什麼新生事物。企業在使用組件方面存在的一個最大問題是他們依賴大型的硬體伺服器，並在同一個伺服器上運行很多應用。我們有EJB、WAR包和EAR包，以及各種組件包，因為伺服器資源太過昂貴，要儘可能地物盡其用。

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

在開始新項目的時候不要再使用EAR包或WAR包了。現在我們可以在Docker里運行JVM，Docker只不過是一個進程，但它可以表現得像一個操作系統一樣。Docker運行在雲端的操作系統上，而雲端的操作系統運行在虛擬機里，虛擬機運行在Linux伺服器上。這些伺服器不是歸誰所有，而是被很多互不相識的人共享。如果出現流量高峰怎麼辦?很簡單，使用更多的伺服器實例。這就是為什麼要把Java微服務運行在一個單獨的進程里，而不是JavaEE容器或servlet容器。

微服務一般會提供基於HTTP/JSON的API端點。這樣可以很容易地與其他服務(開源或閉源的)集成，只要這些服務提供了HTTP/JSON介面。服務可以通過更有意義的方式被消費、被組合。EC2、S3及其他來自Amazon(或其他公司)的服務就是最好的例子。基礎設施會成為應用程序的一部分，而且它們是可編程的。

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

隨著微服務逐漸流行起來，很多廠商開始嘗試把他們的JavaEEWeb服務轉成微服務，這樣他們就可以繼續賣他們的過時產品，APIGateway就是這些廠商中的一個。

JasonBloomberg是Intellyx的主席，他在一篇文章里指出了傳統Web服務和微服務的區別，並對把傳統Web服務轉成微服務的趨勢提出了質疑：

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

微服務不是企業服務匯流排里的Web服務，也不是傳統的面向服務架構，儘管它沿襲了SOA的一些基本概念。從根本上來說，微服務跟SOA是不一樣的，因為整個環境已經發生了徹底的轉變。

微服務架構的環境是沒有邊界的：端到端，基於雲的應用程序運行在完全虛擬和容器化的基礎設施上。容器把應用程序和服務組件化，DevOps為IT基礎設施提供框架，幫助自動化開發、部署和管理環境。

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

Docker和其他容器技術在某種程度上已經被視為微服務的最好伴侶。容器是運行微服務的最小資源子集。Docker簡化了微服務的開發，讓集成測試變得更簡單。

容器有助於微服務開發，但不是必需的。Docker也可以被用來部署單體應用。微服務與容器可以很好地相融並進，不過微服務包含的東西遠比容器多!

結論

應用開發的風格這幾年一直在變化，而微服務變得越來越流行。大公司把大型應用拆分成可以單獨部署的小型應用，這些小型應用被部署在雲端的容器里。開源微服務框架LightJava為這些運行在容器里的微服務提供了很多特性，它支持設計驅動，開發者只需要把注意力專註在業務邏輯上，剩下的事情可以由框架和DevOps流程來處理。

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

如何使用 java 構建微服務

在Java生態中，構建微服務的策略包括Container-less，Self-contained，以及In-container等。

Container-less微服務將應用及其依賴打包成一個單一的jar文件。

Self-contained微服務也是打包成一個單一的Jar文件，但它還包括一個嵌入式框架，這個框架含有可選的第三方lib，當然這些lib是兼容的。

In-container微服務打包成一個完整的Java

EE容器，該服務在Docker鏡像中實現。

基於微服務的架構給架構師和開發者帶來了新的挑戰，然而，隨著語言的升級和工具數量的增加，開發者和架構師完全有能力應對這樣的挑戰。Java也不例外，本文探討了在Java生態系統內構建微服務的不同方法。

北大青鳥java培訓：微服務與傳統單一服務架構的區別？

微服務的系統架構開發方式相信大家應該不陌生了吧，在前幾期的文章中我們也對微服務的架構方式做了一個簡單的介紹。

今天，陝西北大青鳥就來對比一下，微服務與傳統單一服務架構的區別。

1.如何理解微服務，簡要說明您所理解的微服務是什麼?微服務，這個詞語其實是一次聽說，我search了下定義，然後恍然明白，其實所謂的微服務，用更通俗接地氣的詞語來定義和描述的話，就是敏捷+模塊的服務架構體系，如何解釋敏捷，原來的亞馬遜CEOBezos提出來的2pizza就是微服務系統架構的鼻祖，2pizza意思就是所有參與人從設計、開發、測試、運維所有人加起來只需要2個披薩就夠了(應用自網上資料)，所以你能知道，既然要求敏捷，那要快並且高效，就要有模塊化的思維方式，在汽車行業，如今大眾，豐田都提倡模塊化造成體系，不僅高效，而且很多可移植，在IT行業，這種模塊化的思路也是，不僅代碼可移植，如同樂高積木進行橫向功能疊加，而且基於模塊化的微服務，在運維方面，也是自成體系，不僅能減少模塊的測試壓力和成本，後我認為這個微服務還是符合當下資源高效利用的政策的，很多系統逐漸從大而全變成小而精，對於開發，運維等等也是如此，微服務就非常符合這個命題。

2.與傳統單一服務架構相比，在實戰環境下，各自的優劣都有哪些?我認為存在即合理，沒有所謂哪個好，只有哪個更合適，或者在當下需求和長期規划下，在不同階段，何種架構更性價比高，對於單一架構體系，我認為複雜性高，介面冗餘，穩定性中等是其特徵，你可以說這是缺點，但是我認為對於比如大型金融架構，比如我所在的行業，這種soa的架構體系是主流，單一服務架構優勢在於下屬模塊的差異度比較少，品類單一，規劃比較完整，屬於有了宏觀架構和願景進行搭建的方式，而微服務更適合互聯網行業，快速部署，已經對於新技術的歡迎和迭代，是微服務的佳實踐場所3.如果您考慮部署微服務，在業務部署過程中會遇到哪些關鍵挑戰?主要是在金融行業，如果在已有的單一架構系統體系中，採用微服務的部署方式，與原來系統的耦合以及介面是要好好考慮的，要不然會出現四不像，既沒有了原來大型單一系統架構的優勢，微服務的快速，高效和低成本也會體現不出其好的效果，還有就是我認為即使是模塊化的微服務部署，在能力範圍之內要選擇好不同模塊的耦合和類型選擇，否則百花齊開雖然漂亮，但是縱向升級以及進行整合還是非常讓開發和運維的人絞盡腦汁的。