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

微服務(wù)這一概念出現(xiàn)于2012年，因敏捷開發(fā)方法創(chuàng)始人之一的Martin Fowler而流行，微服務(wù)架構(gòu)是一項在云中部署應(yīng)用和服務(wù)的新技術(shù)。

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

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

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

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

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

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

在Netflix和Amazon等公司發(fā)布大量成功案例后，微服務(wù)架構(gòu)開始引起關(guān)注。

微服務(wù)的另一個重要方面，微服務(wù)涉及到稱為DevOps的一組實踐的操作端。這個方面源于最初為傳統(tǒng)應(yīng)用程序管理而開發(fā)的許多模式。Fowler在其最初的微服務(wù)論文中強調(diào)了這方面的重要性，他指出有必要在基于持續(xù)交付和持續(xù)集成原則構(gòu)建的DevOps流程中適應(yīng)基礎(chǔ)架構(gòu)的自動化。

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

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.

單體架構(gòu)Monolithic：

單個Java WAR文件。

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

單體架構(gòu)比較適合小項目，優(yōu)點是：

開發(fā)簡單直接，集中式管理

基本不會重復(fù)開發(fā)

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

它的缺點也非常明顯，特別對于互聯(lián)網(wǎng)公司來說（不一一列舉了）：

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

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

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

穩(wěn)定性不高：一個微不足道的小問題，可以導致整個應(yīng)用掛掉

擴展性不夠：無法滿足高并發(fā)情況下的業(yè)務(wù)需求

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

微服務(wù)架構(gòu)：

具體實現(xiàn)手段：

單獨的數(shù)據(jù)庫，如果該微服務(wù)的數(shù)據(jù)量比較大，需要分庫分表。

統(tǒng)一的服務(wù)接口，尤其是使用了API網(wǎng)關(guān)

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

要解決的技術(shù)難點：

1、這么多服務(wù)，怎么找?

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

2、服務(wù)之間如何通信？

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

3、這么多服務(wù)，服務(wù)掛了怎么辦？

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

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

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

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

Zookeeper保證CP

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

Eureka保證AP

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

因此， Eureka可以很好的應(yīng)對因網(wǎng)絡(luò)故障導致部分節(jié)點失去聯(lián)系的情況，而不會像zookeeper那樣使整個注冊服務(wù)癱瘓。

相關(guān)資料：

小草：技術(shù)分享|微服務(wù)模式發(fā)展簡史?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：微服務(wù)，敏捷開發(fā)方法的關(guān)鍵?zhuanlan.zhihu.com趙云：Eureka的工作原理以及它與ZooKeeper的區(qū)別?zhuanlan.zhihu.comhttps://blog.csdn.net/m0_37707170/article/details/82253058?blog.csdn.net

總結(jié)

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

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