通過優銳課核心java學習筆記中，我們可以看到，碼了很多專業的相關知識， 分享給大家參考學習。
探索過去的軟件設計模式對微服務創建的影響
介紹
微服務是商業應用程序開發中的熱門新事物。 微服務一詞已取代敏捷，DevOps和RESTful，成爲所有履歷表和會議演講都必須使用的熱門新流行語。 但是微服務不只是一時的流行。 實際上，它們是所有這些先前概念的演變，並且這種方法已經開始顯示出有望解決應用程序開發中許多長期存在的問題的希望。 在閱讀本文的同時，我鼓勵你觀看MicroservicesTV第13集和第14集（請參閱下文），以掌握有關微服務的發展方式，位置和原因的牢固掌握。
從頭開始
爲了理解這種發展，我們需要退後一步來研究什麼是微服務，它們被替換了什麼以及爲什麼它們變得必要。讓我們從1980年代初期開始，引入第一個主要的系統分發技術：遠程過程調用（RPC）。 RPC是Sun Microsystems最初的ONC RPC背後的概念，也是DCE（1988）和CORBA（1991）背後的基本思想。
在每種技術中，基本思想是使開發人員可以遠程調用。諾言是，如果開發人員不必關心他們調用的過程調用或方法是本地的還是遠程的，那麼他們可以構建更大的跨機器系統，從而避免處理和內存可擴展性問題，這些問題影響了當時的系統。 。 （請記住，此時最常見的處理器是具有64K地址空間的16位處理器！）
隨着處理器的改進和本地地址空間的增大，此問題變得不那麼重要了。更重要的是，DCE和CORBA的第一批大型實現向架構師傳達了有關分佈式計算的一個重要發現：``僅僅是因爲可以分發的東西並不意味着應該分發它。
一旦大內存空間變得司空見慣，很明顯，對跨機器分佈方法的錯誤選擇可能會對系統性能產生可怕的影響。早期分發所有內容的努力導致許多系統具有非常健談的界面-甚至達到以面向對象的語言分發變量getter和setter的地步。在這樣的系統中，網絡開銷遠遠超過了分配的優勢。
這導致我們進入第一個模式，該模式旨在解決上述觀察問題，而這是我與John Crupi和Martin Fowler獨立發現的一種模式。在每種情況下，我們從Erich Gamma的書《設計模式：可重用的面向對象設計的元素》開始，並注意到了Facade模式。 Facade模式是關於將大型系統的非結構化接口封裝在單個結構化的接口中，以減少“成色”。換句話說，這是關於減少系統的接口橫截面。我們開發的Session Facade方法通過識別整個子系統的關鍵，大粒度的接口並僅公開那些用於分發的接口，將該模式應用於分佈式系統。
我們使用Enterprise JavaBeans（EJB）實施了第一個會話外觀，儘管你僅使用Java可以很好地實現，但是它複雜，難以調試並且不能與其他語言甚至其他供應商產品互操作。缺乏互操作性直接導致了2000年代初至中期的下一個努力：即所謂的面向服務的體系結構（SOA）。但是，SOA並不是從這樣宏偉的術語開始的。它最初是由“做最簡單的可能可行的工作”開始的，該工作稱爲簡單對象訪問協議（SOAP），最初由Microsoft在1999年發佈。
從本質上講，SOAP只是通過HTTP調用對象方法的一種方式。它利用了2000年代初期計算世界的兩個工件：公司網絡對HTTP的日益增長的支持，以及該支持包括用於記錄和調試基於文本的網絡調用的機制這一事實。
圍繞SOAP進行的第一手工作非常有幫助，因爲它很快就使你可以輕鬆地在以多種不同語言和多種平臺實現的系統之間進行互操作。但是，整個SOA失敗的地方遠遠超出了這個簡單的開始，除了簡單的方法調用之外，還增加了一層又一層的附加概念：異常處理，事務支持，安全性和數字簽名都被添加到了一些已經很複雜的東西上協議。這導致了下一個主要觀察結果：試圖使分佈式呼叫的行爲像本地呼叫一樣總是以眼淚結束。
整個行業逐漸開始轉向拒絕SOAP和WS- *標準固有的過程性分層概念。取而代之的是，採用可追溯到Roy Fielding博士的代表性國家轉移（REST）。 REST的基本原理非常簡單：將HTTP視爲HTTP。 REST不會通過HTTP來分層過程調用語義，而是以創建，讀取，刪除和更新語義的方式指定HTTP動詞。它還概述了通過Web的另一個公認原則指定唯一實體名稱的方法：URI。
同時，該行業還開始拒絕Java平臺，企業版（JEE）和SOA世界的另一個遺產：大型應用服務器場。自從1999年引入Enterprise Java（版本爲1.2）以來，應用程序所有者和應用程序管理員之間一直存在緊張關係。
引入JEE時，許多公司開始採用應用程序服務器的概念作爲許多不同應用程序的主機，因爲它類似於大型機領域的現有IT模型。一個操作小組將控制，監視和維護來自Oracle或IBM的相同應用程序服務器的“服務器場”，並將不同部門的應用程序部署到該服務器場上。這種標準化和一致性對於運營團隊非常有用，並降低了總體運營成本。但這與應用程序開發人員產生了衝突，因爲開發和測試環境很大，難以創建，並且需要操作團隊的參與。這通常意味着創建新環境可能要花費數月的時間，這會減慢項目速度並增加其開發成本。而且，由於這些環境不受團隊控制，因此應用服務器版本，補丁程序級別，應用程序數據和環境之間的軟件安裝之間通常存在不一致之處。
開發人員更喜歡的是更小，重量更輕的應用程序平臺，通常是諸如Tomcat或Glassfish之類的開源應用程序服務器。同時，隨着諸如控制反轉和依賴注入之類的技術的普及，JEE的複雜性正在迴避，而轉向了所謂的Spring平臺的簡單性。由此得出的結論是，開發團隊發現，能夠在彼此儘可能接近的開發，測試和生產環境中持續穩定地自行構建和部署應用程序的能力不僅速度更快，而且錯誤更少。 -容易發生，因爲消除了由環境不一致引起的所有錯誤類別。這導致下一個觀察結果：只要可能，你的程序及其運行時環境應完全獨立。
這三個觀察是Fowler所描述的微服務的核心。 Fowler的微服務設計原則之一是，微服務是“圍繞業務功能組織的”。這直接源於一個發現，即僅僅因爲你可以分發某些東西並不意味着你應該這樣做。 Facade模式的各種形式的整個概念都是關於爲系統或子系統定義特定的外部API。這樣做的潛臺詞是該API將由業務驅動。 Fowler使該上下文明確。
通常，瞭解這對某些開發團隊是一個障礙–他們只是不習慣於在業務接口方面進行設計，並且可能會發現自己很快就轉移到了技術接口（例如Login或Logging）上。在這些情況下，許多團隊發現適用的是Eric Evans的書《域驅動設計》中的幾種模式。特別是，他的實體和聚合模式可用於識別直接映射到微服務的特定業務概念。同樣，他的服務模式還提供了一種映射操作的方式，這些操作不對應於單個實體，也不聚合到微服務所需的基於實體的方法中。
同樣，Fowler使用“智能端點和啞管道”的規則源於使用EJB，SOAP和其他複雜分發技術的團隊的經驗，結果是，人們試圖使分佈式系統在本地看起來總是以失敗告終。最後，Fowler關於分散管理和分散數據管理的命令源於來之不易的發現，即你的程序和運行時環境應該是獨立的。
這在哪裏離開我們
Fowler，Adrian Cockcroft和其他人現在已經提出了令人信服的理由，說明爲什麼開發團隊應該採用微服務。 但是，如果我們研究學習微服務架構的所有課程的方法，我們可以得出一個結論，該結論與我剛纔講的以開發人員爲中心的故事有些不同。 特別是，你必須瞭解使微服務在現有應用程序的公司環境中工作的現實，並且還必須意識到微服務體系結構在DevOps的操作方面的額外重視。
生活在企業世界中
在Netflix，Gilt.com和Amazon等公司發佈了許多成功案例之後，微服務體系結構開始引起人們的關注。但是，所有這些公司以及微服務的許多其他成功都有一個共同點-它們都是誕生於開發新應用程序或沒有可替代的大量舊代碼庫的網絡公司。當傳統公司採用微服務時，選擇第一個綠色應用程序來測試微服務後，他們遇到的一個問題是微服務架構的某些原則，特別是“分散數據管理”和“當你必須重構大型整體應用程序時，很難實施“分散治理”原則。
但幸運的是，針對該問題的方法已經存在了好幾年了，其形式是馬丁·福勒（Martin Fowler）最初在2004年記錄的，即他從事微服務工作的幾年之前。他的概念稱爲“扼殺程序應用程序模式”，它旨在解決你幾乎從未真正生活在綠色領域的事實。最需要微服務的程序是Web上最大，最討厭的程序，但是再次利用Web的體系結構可以爲我們提供管理所需重構的策略。
詳細瞭解Martin Fowler的扼殺器應用程序。
重構到微服務，第1部分介紹瞭如何從傳統的中間件架構過渡到微服務。
扼殺器應用程序是一個簡單的概念，其基於葡萄藤將其纏繞的樹扼死的類比。這個想法是，你使用Web應用程序的結構-它是從功能上映射到業務域的各個方面的單個URI構建的事實-將應用程序拆分爲不同的功能域，並用新的域替換這些域基於微服務的實現，一次僅一個域。這兩個方面構成了在同一個URI空間中並行存在的獨立應用程序。隨着時間的流逝，新重構的應用程序將扼殺或替換原始應用程序，直到你最終能夠關閉整體應用程序爲止。
但這並不是我們發現對使微服務方法在企業界有效的唯一模式。另一個重要方面是，在許多情況下，開發團隊都無法對其數據進行分散控制。這就是我們稱爲Adapter Microservice的模式的原因，它是Erich Gamma等人設計模式的原始Adapter模式的擴展。
在適配器微服務中，你可以在兩個不同的API之間進行調整。第一個是面向業務的API，它使用RESTful或輕量級消息傳遞技術構建，並使用與傳統微服務相同的域驅動技術進行設計。但是它適應的第二個API是現有的遺留API或基於傳統WS- *的SOAP服務。純粹主義者可能會反對這種方法，並試圖堅持認爲，如果你不採用分散數據，那麼你就不會使用微服務。但是，公司數據的存在是有原因的，而且除了組織慣性之外，還有很多其他原因使數據保持不變。可能是仍有大量舊應用程序仍需要訪問其當前格式的數據，而這些舊應用程序無法輕鬆適應新的API，或者數據的絕對重量（通常以數百TB或PB爲單位） ）排除了遷移到單一服務擁有的新表格的可能性。
將操作放回DevOps中
微服務的另一個重要方面涉及稱爲DevOps的一組實踐的操作方面。這源於最初爲常規應用程序管理開發的許多模式。 Fowler在其關於微服務的原始論文中強調了這一點的重要性，他指出在基於持續交付和持續集成的DevOps流程中，有必要對基礎架構自動化進行調整。但是，對於開始小規模採用微服務的團隊而言，對此的需求並不總是很清楚。問題在於，儘管使用微服務可以更輕鬆地快速更改和部署單個服務，但與相應的整體應用程序相比，管理和維護一組服務的整體工作量也更大。
例如，這就是許多常見框架（例如微服務的Netflix框架和Amalgam8）採用服務註冊表模式的原因之一：通過避免將特定的微服務終結點硬編碼到你的代碼中，不僅可以更改代碼的實現，下游微服務，但它還允許選擇服務位置，以在DevOps管道的不同階段有所不同。沒有Service Registry，隨着對代碼的更改開始通過微服務的調用鏈向上傳播，你的應用程序將很快陷入困境。
實現更好的隔離同時又可以更輕鬆地調試微服務的想法是我們已經確定的幾種DevOps模式的核心，特別是相關ID和Log Aggregator。在Gregor Hohpe的《企業集成模式》一書中以特定的形式識別並記錄了相關ID模式，但是現在我們已經看到了在OpenTracing等項目中推廣的概念，該概念允許通過多種以多種不同語言編寫的微服務傳播跟蹤。 Log Aggregator是一種新模式，已在許多開源和商業產品（例如Cloud Foundry和開源ELK堆棧）中實現；它通過允許將來自多個不同微服務的日誌聚合到一個可搜索的存儲庫中來補充相關性ID。總之，無論服務的數量或每個調用堆棧的深度如何，這些都允許對微服務進行高效且易於理解的調試。
最後，Fowler在他的文章中指出，DevOps的另一個方面是兩者之間的關鍵橋樑：爲失敗而設計的重要性。尤其是，由於Netflix的Hystrix框架實現了Circuit Breaker模式，因此它已成爲許多微服務實現中的重要組成部分。斷路器最早記錄在邁克爾·尼加德（Michael Nygard）的2007年的《釋放！使用Circuit Breaker，你可以避免浪費時間處理下游故障（如果你知道下游故障已在發生），並且可以通過在上游服務調用中植入代碼的Circuit Breaker部分來處理，以檢測下游服務何時發生故障並避免嘗試稱呼它。這樣做的好處是每個調用都會“快速失敗”，當你知道下游調用註定會失敗時，你可以爲用戶提供更好的整體體驗，並避免對線程和連接池等資源進行錯誤的管理。
這種資源管理曾經是DevOps運營方面的專屬工作，但是微服務體系結構可以更有效地將雙方融合在一起，因爲它們都致力於使最終的應用程序更加可靠，高效和靈活。
下一步是什麼
在本文和隨附的視頻中，我們探索了微服務的歷史先例，並研究了微服務體系結構是如何產生的。 我們還討論了在企業界成功應用微服務需要遵循的模式，以及在應用微服務體系結構時可能遇到的挑戰。
喜歡這篇文章的可以點個贊，歡迎大家留言評論，記得關注我，每天持續更新技術乾貨、職場趣事、海量面試資料等等
如果你對java技術很感興趣也可以交流學習，共同學習進步。
不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代
文章寫道這裏，歡迎完善交流。最後奉上近期整理出來的一套完整的java架構思維導圖，分享給大家對照知識點參考學習。有更多JVM、Mysql、Tomcat、Spring Boot、Spring Cloud、Zookeeper、Kafka、RabbitMQ、RockerMQ、Redis、ELK、Git等Java乾貨