微服務是商業應用程序開發中最熱門的新事物。微服務這個詞取代了敏捷、DevOps和RESTful，成為了所有簡歷和大會演講中都必須提及的新熱門詞。

微服務這一概念出現于2012年，因敏捷開發方法創始人之一的Martin Fowler而流行，微服務架構是一項在云中部署應用和服務的新技術。

微服務可以在“自己的程序”中運行，并通過“輕量級設備與HTTP型API進行溝通。”關鍵在于該服務可以在極致的程序中運行。

微服務作為一項云中部署應用和服務的新技術，已成為當下最新的熱門話題。大部分為稍微服務的爭論都集中在容器或其他技術是否能夠很好地實施微服務。企業和服務提供商正在尋找更好的方法將應用程序部署在云環境中，微服務被認為是未來的方向。通過將應用和服務分解成更小的、松散耦合的組件，它們可以更加容易升級和拓展。

讓我們回到上世紀80年代初，第一種重要的系統分發技術"遠程過程調用(RPC)"誕生的時候。RPC是Sun Microsystems最初的ONCRPC背后的設想理念，也是DCE（1988年）和CORBA（1991年）背后的基本理念。

我們使用Enterprise JavaBeans(EJBs)實現了第一個Session Facade，盡管僅在Java中使用時很有效，但它很復雜，難以調試，而且無法與其他語言或其他供應商產品互操作。缺乏互操作性直接導致我們在2000年代初期到中期開展了下一項工作：該工作成果后來以面向服務的架構(SOA)而聞名。但是，SOA最初沒有采用這個高端大氣的術語。它最初始于一次"以最簡單方式實現目標"的嘗試，獲得的成果就是Microsoft最初在1999年發布的簡單對象訪問協議(SOAP)。

圍繞SOAP進行的初期工作很有幫助，這一點很快得到證明，人們可以輕松地合并使用許多不同語言和在許多不同平臺上實現的系統。但SOA在整體上的敗筆是，它脫離了簡單的初衷，開始添加一層又一層脫離了簡單方法調用的一些附加概念：添加了異常處理、事務支持、安全性和數字簽名，人們感覺SOA已經變成了一個復雜協議。

使用EJB、SOAP和其他復雜分發技術的團隊最終發現，嘗試讓分布式系統看起來像本地系統最終會帶來苦果。最后，Fowler圍繞分散化治理和分散化數據管理的規定源于一項來之不易的發現：您的程序和運行時環境應自給自足。

在Netflix和Amazon等公司發布大量成功案例后，微服務架構開始引起關注。

微服務的另一個重要方面，微服務涉及到稱為DevOps的一組實踐的操作端。這個方面源于最初為傳統應用程序管理而開發的許多模式。Fowler在其最初的微服務論文中強調了這方面的重要性，他指出有必要在基于持續交付和持續集成原則構建的DevOps流程中適應基礎架構的自動化。

正因如此，許多常見的框架（比如用于微服務的Netflix框架和Amalgam8）都在適應Service Registry模式：通過避免將特定的微服務端點硬編碼到您的代碼中，不僅可以更改下游微服務的實現，還可以在DevOps管道的不同階段中選擇不同的服務位置。如果沒有Service Registry，隨著對代碼的更改開始沿一個微服務調用鏈向上傳播，您的應用程序很快將會陷入困境。

Microservices are a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion. It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. It also allows the architecture of an individual service to emerge through continuous refactoring. Microservice-based architectures facilitate continuous delivery and deployment.

單體架構Monolithic：

單個Java WAR文件。

單個Rails或者NodeJS代碼目錄層級。

單體架構比較適合小項目，優點是：

開發簡單直接，集中式管理

基本不會重復開發

功能都在本地，沒有分布式的管理開銷和調用開銷

它的缺點也非常明顯，特別對于互聯網公司來說（不一一列舉了）：

開發效率低：所有的開發在一個項目改代碼，遞交代碼相互等待，代碼沖突不斷

代碼維護難：代碼功能耦合在一起，新人不知道何從下手

部署不靈活：構建時間長，任何小修改必須重新構建整個項目，這個過程往往很長

穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉

擴展性不夠：無法滿足高并發情況下的業務需求

對于單塊架構的優缺點概括如下：
優點有：易于開發、測試（模式易于理解，并且有成熟的開發工具能夠使用）；易于部署和水平伸縮（只需把對應的軟件包復制到配置好運行環境的節點即可）。
不足有：維護成本增加（隨著應用程序功能越來越多，團隊越來越大，相應的溝通成本、管理成本、人員協調成本必然會顯著增加）；持續交付周期長（代碼逐漸復雜之后，構建和部署的時間也會相應增加）；新人培養周期漸長；技術選型成本高（初始的技術選型嚴重限制了將來采用不同語言或框架的能力。如果想嘗試新的編程語言或框架，沒有完備的功能測試集，很難平滑完成替換，而且系統規模越大，風險越高）；可擴展性差（不論是垂直擴展還是水平擴展，其代價都會比較高）；構建全功能團隊難（這種開發模式在分工時往往以技能為單位，這將導致任何功能上的改變都可能需要跨團隊的溝通和協調）。

微服務架構：

具體實現手段：

單獨的數據庫，如果該微服務的數據量比較大，需要分庫分表。

統一的服務接口，尤其是使用了API網關

所有的微服務都是獨立的Java進程跑在獨立的虛擬機上

要解決的技術難點：

1、這么多服務，怎么找?

通過zookeeper等類似技術做服務注冊信息的分布式管理。當服務上線時，服務提供者將自己的服務信息注冊到ZK（或類似框架），并通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過ZK尋址，根據可定制算法，找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZK會發通知給服務客戶端。

2、服務之間如何通信？

因為所有的微服務都是獨立的Java進程跑在獨立的虛擬機上，所以服務間的通行就是IPC（inter process communication），已經有很多成熟的方案。現在基本最通用的有兩種方式

3、這么多服務，服務掛了怎么辦？

相應的手段有很多：
重試機制
限流
熔斷機制
負載均衡
降級（本地緩存）

這些方法基本上都很明確通用，就不詳細說明了。比如Netflix的Hystrix：Netflix/Hystrix

作為服務注冊中心，Eureka比Zookeeper好在哪里

著名的CAP理論指出，一個分布式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由于分區容錯性在是分布式系統中必須要保證的，因此我們只能在A和C之間進行權衡。在此Zookeeper保證的是CP, 而Eureka則是AP。

Zookeeper保證CP

當向注冊中心查詢服務列表時，我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高于一致性。但是zk會出現這樣一種情況，當master節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行leader選舉。問題在于，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。在云部署的環境下，因網絡問題使得zk集群失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。

Eureka保證AP

Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩余的節點依然可以提供注冊和查詢服務。而Eureka的客戶端在向某個Eureka注冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證注冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：
1. Eureka不再從注冊列表中移除因為長時間沒收到心跳而應該過期的服務
2. Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網絡穩定時，當前實例新的注冊信息會被同步到其它節點中

因此， Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。

相關資料：

小草：技術分享|微服務模式發展簡史?zhuanlan.zhihu.comhttps://blog.csdn.net/u012422829/article/details/68947350?blog.csdn.nethttps://blog.csdn.net/m0_37707170/article/details/82253058?blog.csdn.netLean Work：微服務，敏捷開發方法的關鍵?zhuanlan.zhihu.com趙云：Eureka的工作原理以及它與ZooKeeper的區別?zhuanlan.zhihu.comhttps://blog.csdn.net/m0_37707170/article/details/82253058?blog.csdn.net

總結

以上是生活随笔為你收集整理的eureka跨服务_微服务（microservices) 资料总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。