整体服务器与微服务
介紹
剛開始時，由于要求簡單，所以應用程序既簡單又小。 隨著時間要求和需求的增長，我們的應用程序變得越來越大，越來越復雜。 這導致將單片服務器開發和部署為一個單元。 在某種程度上，微服務可以通過簡單的應用程序回歸基礎，這些應用程序可以通過利用彼此之間的API一起工作來滿足當今對復雜性的需求。
什么是整體服務器？
與微服務相比，微服務最好被解釋。 整體服務器 。 它們作為一個單元開發和部署 。 對于Java，最終結果通常是單個WAR或JAR文件。 C ++ 、. Net，Scala和許多其他編程語言也是如此。
大多數軟件開發的短暫歷史都以我們開發的應用程序規模的不斷增加為標志。 隨著時間的流逝，我們將越來越多地添加到我們的應用程序中，從而不斷增加它們的復雜性和大小，并降低我們的開發，測試和部署速度 。
隨著時間的流逝，我們開始將應用程序劃分為多個層：表示層，業務層，數據訪問層等。這種分離比物理上更邏輯。 盡管開發變得容易一些，但每次更改或發布時，我們仍然需要測試和部署所有內容。 在企業環境中，擁有花費數小時才能構建和部署的應用程序并不少見。 測試，尤其是回歸測試，往往是一場噩夢，在某些情況下會持續數月之久。 隨著時間的流逝，我們進行僅影響一個模塊的更改的能力正在下降。 分層的主要目的是使它們易于替換或升級。 這個承諾從未真正實現。 在大型整體應用中更換零件幾乎從來都不容易，而且沒有風險。
擴展此類服務器意味著擴展整個應用程序，從而產生非常不平衡的資源利用。 如果我們需要更多的資源，即使瓶頸是一個模塊，我們也被迫在新服務器上復制所有內容。
什么是微服務？
微服務是一種架構和開發由小服務組成的單個應用程序的方法。 了解微服務的關鍵是它們的獨立性 。 彼此分別開發，測試和部署。 每個服務作為單獨的進程運行。 不同微服務之間的唯一關系是通過它們公開的API來完成數據交換。 它們以某種方式繼承了Unix / Linux中使用的小型程序和管道的思想。 大多數Linux程序很小，并且會產生一些輸出。 該輸出可以作為輸入傳遞給其他程序。 鏈接在一起時，這些程序可以執行非常復雜的操作。 它是由許多簡單單元組合而成的復雜性。
微服務的關鍵方面是：
- 他們做一件事或負責一項功能。
- 每個微服務都可以通過任何一組工具或語言來構建，因為它們彼此獨立。
- 由于每個微服務在物理上是彼此分離的，因此它們實際上是松散耦合的。
- 開發不同的微服務的不同團隊之間的相對獨立性（假設它們公開的API是預先定義的）。
- 簡化測試以及持續交付或部署
微服務的問題之一是決定何時使用它們。 最初，盡管應用程序仍然很小，但是微服務試圖解決的問題并不存在。 但是，一旦應用程序增長并且可以提出微服務的理由，切換到另一種體系結構樣式的成本可能會太大。 經驗豐富的團隊可能從一開始就使用微服務，因為他們知道他們以后可能需要償還的技術債務比起一開始使用微服務要昂貴得多。 通常，就像Netflix，eBay和Amazon一樣，整體式應用程序開始逐漸向微服務發展。 新模塊被開發為微服務，并與系統的其余部分集成。 一旦證明了自己的價值，現有的整體應用程序的一部分就會重構為微服務。
企業應用程序開發人員經常引起批評的一件事是數據存儲的分散化。 盡管微服務可以使用集中式數據存儲來工作（只需進行少量調整），但至少應該探索使該部分分散的選項。 將與某些服務相關的數據存儲在單獨的（分散式）存儲中并將其全部打包到同一容器中的選擇在許多情況下比將數據存儲在集中式數據庫中更好。 我們不建議始終使用分散存儲，而在設計微服務時考慮使用該選項。
缺點
運營和部署復雜性增加
反對微服務的主要論點是操作和部署復雜性的增加。 這種說法是正確的，但是由于有了相對較新的工具，它可以緩解。 配置管理（CM）工具可以相對輕松地處理環境設置和部署。 Docker對容器的利用大大減少了微服務可能引起的部署麻煩。 CM工具與Docker一起使我們能夠輕松部署和擴展微服務。 可以在文章連續部署：使用Ansible和Docker實施中找到一個示例。
在我看來，增加部署復雜性的爭論通常沒有考慮到我們在過去幾年中看到的進步，并且被夸大了。 這并不意味著一部分工作不會從開發轉移到DevOps 。 肯定是。 但是，在許多情況下，收益要大于轉移帶來的不便。
遠程過程調用
另一個反論點是遠程進程調用會降低性能。 通過類和方法進行內部調用更快，并且無法解決此問題。 性能損失對系統的影響取決于具體情況。 重要的因素是我們如何拆分系統。 如果我們將非常小的微服務（如果有人建議它們的LOC不應超過10-100 LOC）達到極限，那么這種影響可能是相當大的。 我喜歡創建圍繞用戶，購物車，產品等功能組織的微服務。這減少了遠程流程調用的數量。 另外，必須注意的是，如果從一個微服務到另一微服務的呼叫正在通過快速內部LAN進行，則負面影響相對較小。
優點
以下僅是微服務可以帶來的一些優勢。 這并不意味著在其他類型的體系結構中不存在相同的優勢，而是與微服務相比，與其他一些選擇相比，它們可能會更加突出。
縮放比例
擴展微服務比單片應用程序容易得多。 在后一種情況下，我們將整個應用程序復制到一臺新機器上，而在微服務中，我們僅復制那些需要擴展的服務 。 我們不僅可以擴展需要擴展的內容，而且可以更好地分發內容。 例如，我們可以將一個CPU利用率很高的服務與另一個使用大量RAM的服務放在一起，同時將第二個CPU需求服務移至其他硬件。
革新
一旦建立了初始架構，單片服務器就不會留出太多的創新空間。 由于其性質，更改事物會花費時間，并且實驗非常冒險，因為它可能影響所有事物。 例如，不能僅僅因為它更適合一個特定的模塊就更改Apache Tomcat for NodeJS。
我并不是建議我們應該為每個模塊更改編程語言，服務器，持久性等。 但是，單片服務器趨向于相反的極端，在這種極端情況下，即使不是不受歡迎的更改也會帶來風險。 借助微服務，我們可以分別為每個服務選擇我們認為最佳的解決方案 。 一個可能使用Apache Tomcat，而另一個可能使用NodeJS。 一個可以用Java編寫，另一個可以用Scala編寫。 我并不是在提倡每種服務都與其他服務有所不同，但是可以以我們認為最適合當前目標的方式來進行每種服務。 最重要的是，更改和實驗要容易得多。 畢竟，只要尊重API，我們所做的一切只會影響眾多微服務中的一個，而不會影響整個系統。
尺寸
由于微服務很小，因此更容易理解。 查看一個微服務正在做什么的代碼要少得多。 這本身就極大地簡化了開發，尤其是當新來者加入該項目時。 最重要的是，其他所有東西都趨向于更快。 與整體應用程序中使用的大型項目相比， IDE在小型項目中的運行速度更快 。 由于沒有大型服務器或大量庫需要加載，因此啟動速度更快 。
部署，回滾和故障隔離
部署更快，更容易 。 部署小部件總是比部署大部件更快（如果不是更容易的話）。 如果我們意識到存在問題，則該問題的影響可能有限，并且可以更輕松地回滾 。 在回滾之前， 故障只隔離到系統的一小部分。 連續交付或部署可以用大型服務器無法實現的速度和頻率來完成。
無需長期承諾
整體應用程序的常見問題之一是承諾。 我們經常被迫從一開始就選擇會持續很長時間的體系結構和技術。 畢竟，我們正在構建一些可以持續很長時間的大型項目。 對于微服務， 需要長期承諾的需求并不大 。 在一種微服務中更改編程語言，如果發現它是一個不錯的選擇，則將其應用于其他微服務。 如果實驗失敗或不是最佳方案，則僅需要重做系統的一小部分。 同樣適用于框架，庫，服務器等。我們甚至可以使用不同的數據庫。 如果某些輕量級NoSQL似乎最適合特定的微服務，為什么不使用它并將其打包在容器中？
最佳實踐
以下大多數最佳實踐通常都可以應用于面向服務的體系結構。 但是，借助微服務，它們變得更加重要或有益。
貨柜
處理許多微服務很容易成為一項非常復雜的工作。 每種都可以用不同的編程語言編寫，可以需要不同的服務器（希望是輕量級的）或可以使用不同的庫集。 如果將每個服務打包為一個容器，那么大多數問題將消失。 我們要做的就是使用例如Docker運行容器，并相信所需的一切都在其中。
代理微服務或API網關
大型企業前端可能需要調用數十甚至數百個HTTP請求（與Amazon.com一樣 ）。 與接收響應數據相比，調用請求通常花費更多時間。 在這種情況下，代理微服務可能會有所幫助。 他們的目標是調用不同的微服務并返回聚合的服務。 它們不應包含任何邏輯，而只是將多個響應組合在一起，并以匯總數據響應給消費者。
反向代理
切勿直接公開微服務API。 如果沒有某種類型的編排，則消費者與微服務之間的依賴關系變得如此之大，以至于它可能會消除自由，而微服務應該給我們帶來自由。 諸如nginx和Apache Tomcat之類的輕量級服務器非常擅長執行反向代理任務，并且可以輕松地以很少的開銷使用。 請查閱《 持續部署：實施 》一文，以了解將反向代理與Docker和其他一些工具結合使用的一種可能方式。
極簡主義方法
微服務應僅包含它們真正需要的包，庫和框架。 它們越小越好。 這與單片應用程序使用的方法形成了鮮明對比。 以前我們可能曾經使用過像JBoss這樣的JEE服務器，它包裝了我們可能需要或可能不需要的所有工具，而微服務則可以與更簡單的解決方案一起工作。 擁有數百個微服務，每個微服務都具有完整的JBoss服務器，這會顯得過時了。 例如， Apache Tomcat是一個更好的選擇。 我傾向于使用更小的解決方案，例如，將Spray作為一種非常輕量級的RESTful API服務器。 不要打包您不需要的東西。
同樣的方法也應應用于操作系統級別。 如果我們將微服務部署為Docker容器，那么CoreOS可能是比Red Hat或Ubuntu更好的解決方案。 它擺脫了我們不需要讓我們更好地利用資源的事情。
必須進行配置管理
隨著微服務數量的增長，對配置管理（CM）的需求也在增加。 不用工具如Puppet ， Chef或Ansible （僅舉幾例）部署許多微服務很快就成為噩夢。 實際上，無論有沒有微服務，對于最簡單的解決方案不使用CM工具都是一種浪費。
跨職能團隊
雖然沒有規定使用哪種類型的團隊的規則，但是當一個團隊中的團隊是多功能的時，微服務才是最好的選擇。 從開始（設計）到完成（部署和維護），應由一個團隊負責。 它們太小，無法從一個團隊轉移到另一個團隊（架構/設計，開發，測試，部署和維護團隊）。 最好有一個負責微服務整個生命周期的團隊。 在許多情況下，一個團隊可能負責多個微服務，但多個團隊不應該一個。
API版本控制
版本控制應該應用于任何API，微服務也是如此。 如果某些更改會使API格式失效，則該更改應作為單獨的版本發布。 對于公共API或微服務，我們無法確定誰在使用它們，因此必須保持向后兼容性，或者至少要給消費者足夠的時間來適應。 REST API with JSON文章中發布了有關API版本控制的部分。
摘要
微服務并不能解決我們所有的問題。 沒有什么是。 它們不是所有應用程序都應創建的方式。 沒有適合所有情況的單一解決方案。
微服務已經存在了很長時間，近年來，它們的普及程度也在不斷提高。 導致這種趨勢的因素很多，可伸縮性可能是最重要的一種。 新工具（尤其是Docker）的出現使我們能夠從新的角度看待微服務，并消除了其開發和部署所造成的部分問題。 諸如Amazon，NetFlix，eBay等“大佬”對微服務的利用，提供了足夠的信心，即企業應用程序開發人員已經可以評估（如果不使用）這種體系結構樣式。
翻譯自: https://www.javacodegeeks.com/2015/01/monolithic-servers-vs-microservices.html
總結
- 上一篇： 开户是什么意思？
- 下一篇： EE Servlet 3：简单表单处理