構建微服務實際上意味著什么？ 通過微服務框架的眼光回答

忽略微服務的趨勢已變得不可能。 有些人會說這只是另一個難以忍受的流行語，而另一些人會背誦打破巨石的優(yōu)勢或采取逆勢方法并關注負面因素。

在本文中，我們將深入了解我們擁有的框架，重點是Java生態(tài)系統(tǒng)，以實際實現(xiàn)微服務并了解它們的全部含義。 讓我們潛入。

蛋糕是一個謊言

我想到的第一個問題是，我們真的需要一個專門的框架來構建微服務嗎？ 答案是不。 您可以使用微服務框架構建整體嗎？ 是。 因此，如果真正由您決定并且要使用它做什么，那么微服務框架相對于Java EE或Spring有什么好處？ 什么使它值得采用？ 它們是否同時解決內(nèi)部架構和外部運維架構？

在接下來的幾節(jié)中，我們將仔細研究Java EE及其新的微型配置計劃，Spring和Spring Boot，帶有Lagom的Lightbend堆棧以及其他開源解決方案，例如Spotify的Apollo。

在繼續(xù)前進之前，值得一提的是，關于微服務架構的定義還不是很明確。 ThoughtWorks的首席科學家Martin Fowler在他的第一篇涉及微服務的文章中試圖對其進行定義：

“微服務架構風格是一種將單個應用程序開發(fā)為一組小型服務的方法，每個小型服務都在自己的進程中運行并與輕量級機制（通常是HTTP資源API）進行通信。 這些服務圍繞業(yè)務功能構建，并且可以通過全自動部署機制獨立部署?！?

這篇文章與微服務的優(yōu)缺點無關，它假定您只是對支持它的底層技術感興趣。 另一篇值得探討這些問題的文章涵蓋了調(diào)試微服務的主要挑戰(zhàn) -這是許多人在考慮微服務體系結構時并未想到的常見陷阱。

讓我們開始并逐一檢查以下技術/平臺/框架。

1. Java企業(yè)版

用于構建應用程序的經(jīng)典Java EE方法是針對整體的，隨著時間的流逝，這些整體往往會變成……意大利面條式代碼怪物。 傳統(tǒng)上，企業(yè)應用程序將被打包到單個EAR（企業(yè)歸檔）部署單元中，該單元包括WAR（網(wǎng)絡歸檔）文件和JAR（Java歸檔）。

但是，“ Vanilla” Java EE也可以用于微服務架構。 有關將Java EE整體重構為微服務體系結構的步驟的深入研究示例， 請查看 Arun Gupta的這篇文章 ，他在其中通過購物車的示例應用程序介紹了此過程中所需的步驟。

盡管Java EE 8的開發(fā)有所放緩，但背后的“非官方”社區(qū)仍然活躍而且活躍。 Java EE Microprofile背后的人們提出了一項針對微服務架構優(yōu)化企業(yè)Java的新計劃。 您可以在此處加入討論 。

考慮Java EE微服務時要考慮的另一個有趣項目是Kumuluz 。 該框架可以利用您現(xiàn)有的Java EE知識，并為您提供一種輕松選擇應用程序所需組件的方法，而不會浪費太多時間在配置上。

底線： Java EE及其周圍的項目非常適合微服務，但不涉及操作方面，而是將其用法和最佳實踐留給您個人解釋。

2. Lightbend：Play，Akka，ConductR和Lagom

Lightbend（以前稱為Typesafe）為我們提供了更多選擇。 與Kumuluz相對于普通Java EE的優(yōu)勢類似，Lagom將Lightbend堆棧與Play，Akka和ConductR包裹在一起，并提供了構建微服務的簡便方法。 它的基礎組件還包括Cassandra，Guice，Jackson，slf4j，Logback和其他Lightbend組件。

Lagom （瑞典語中“恰到好處的數(shù)量”）仍處于早期階段，但對于Lightbend堆棧而言，這似乎是一個有希望的方向。 Lightbend的首席技術官Jonas Boner在接受InfoQ采訪時說：“目前大多數(shù)微服務框架都集中在簡化單個微服務的構建上，這很容易。 Lagom將其擴展到微服務系統(tǒng)，大型系統(tǒng)–這是困難的部分，因為在這里我們面臨著分布式系統(tǒng)的復雜性。

底線： Lagom將Lightbend的功能結合了ConductR提供的ops功能。 不僅關注單個微服務，而且關注整個系統(tǒng)。

3，Spring，Spring Boot和Spring Cloud

盡管Spring和Spring Boot并不稱自己為微服務框架，并且Spring站點的首頁上沒有提及微服務，但這并不意味著它們不在循環(huán)之中。 幾乎似乎好像他們是故意不稱其為微服務，以遠離流行語大肆宣傳。

Spring Stack與Spring Cloud一起，利用Netflix Eureka和Ribbon來支持分布式系統(tǒng)的開發(fā)（該術語通常與“微服務”重疊）。 這些功能包括配置管理，服務發(fā)現(xiàn)，智能路由，控制總線，領導者選舉，分布式會話等。

要深入了解如何使用Spring以及其他一些Netflix和其他開源項目構建微服務， 請查看InfoQ的這篇文章 。

底線： Spring在微服務開發(fā)方面處于有利位置，并且圍繞著解決了運營問題的外部開源項目提供了產(chǎn)品。

4. Dropwizard

與Spring類似， Dropwizard也沒有太多談論微服務。 這是一個用于開發(fā)對ops友好的高性能RESTful Web服務的Java框架。 經(jīng)過認真研究的Java庫集合，使構建易于生產(chǎn)的Java應用程序變得更加容易。

Dropwizard模塊允許掛接Dropwizards核心所沒有的其他項目，并且社區(qū)還開發(fā)了一些模塊來掛接Netflix Eureka等項目，與Spring Cloud相當。

之前，我們還對Dropwizard和Spring Boot進行了正面對比，并比較了它們的功能。

底線：由于Dropwizard是一個社區(qū)項目，沒有像Spring和Pivotal，Java EE和Oracle，Lagom和Lightbend這樣的大型公司的支持，因此其開發(fā)速度可能會較慢，但是背后有一個強大的社區(qū)，因此可以大公司和較小項目的框架。

5. Spotify Apollo，VertX和其他“ Microframeworks”

除了我們在這里提到的4個主要參與者之外，還有很多其他項目值得一提，它們也可以用于編寫微服務：

Vertx ，一個用于在JVM上構建響應式應用程序的工具包。 有人可能會認為它應該在四大巨頭中占有一席之地。

Spotify Apollo ，Spotify在編寫Java微服務時使用的一組Java庫。 Apollo包括HTTP服務器和URI路由系統(tǒng)等功能，使實現(xiàn)RESTful服務變得輕而易舉。

其他框架包括Spark，Ninja和Jodd以及Restlet 。

底線： Java微服務的競爭領域很大，值得一試的是較小的參與者。

6.微服務先決條件

正如馬丁·福勒（Martin Fowler）在他的微服務先決條件帖子中所說：“重要的是要確保您的監(jiān)控指示問題時能夠Swift做出反應。 尤其是，任何事件管理都需要開發(fā)團隊和運營部門參與，以解決緊迫的問題和根本原因分析，以確?；締栴}得到解決?！?同樣，如果您還沒有準備好使用微服務體系結構，則此帖子和Hackernews上的帖子會共享更多的問題。

在OverOps ，我們正在構建一個工具來解決這一難題 ，并顯示何時，何地以及為什么在生產(chǎn)中導致代碼中斷。 它是唯一可以為您顯示整個調(diào)用堆棧中每個異常，記錄的警告和錯誤的完整源代碼和變量狀態(tài)的工具。 檢查一下 。

OverOps錯誤分析屏幕

最重要的是：微服務要付費，而且并非每個系統(tǒng)都適合。 如果您選擇微服務架構，則應該深入了解成本并確定應改進的流程。

最后的想法

不管使用哪種框架或平臺，構建微服務都與它們緊密結合。 這是一種思維定勢和一種體系結構的方法，您可能應該選擇一個自己覺得會更有效率的選擇。

話雖如此，成功實現(xiàn)微服務架構并不僅限于應用程序本身。 圍繞它的大部分成本來自所謂的DevOps流程，監(jiān)控，CI / CD，日志更改，服務器配置等。 將來，我們將在博客上介紹這些方面，并很高興聽到您對此的想法，并在我們的下一篇文章中進行介紹。 隨時通過hello@overops.com和@overopshq進行聯(lián)系 。

翻譯自: https://www.javacodegeeks.com/2016/11/java-microservices-cake-lie-cant-ignore.html

總結

以上是生活随笔為你收集整理的Java微服务：蛋糕是骗人的，但您不能忽略它的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。