【乾貨】微服務設計的基礎知識

人體是不一樣系統的組合，其中大多數系統是獨立的，而且做爲一個總體協同工做。每一個系統都有本身的特定功能。全部具備多種其餘支持框架的器官構成了一個功能完備的機構。如今，若是應用於軟件系統，這就是微服務架構的概念。

在技術方面，微服務系統容許開發單個功能模塊。這種開發單一功能模塊的趨勢爲大型和小型組織提升了靈活性，性能和成本效率，同時實現了持續測試和早期交付。可是，在咱們深刻研究微服務設計的基礎知識以前，讓咱們先看看它的優勢。

微服務架構的優勢

對於單一體系結構，開發人員常常面臨有限的可重用性和可伸縮性的挑戰。可是，經過微服務設計，能夠將這個單元分解爲不一樣的模塊，從而簡化開發，部署和維護。那麼讓咱們來看看微服務架構的一些主要優勢：

技術靈活性

雖然單片架構老是讓開發人員尋找「適合工做的正確工具」，但微服務架構在一個封面下提供了多種技術的共存。能夠用多種編程語言編寫不一樣的解耦服務。這不只使開發人員可以進行實驗，還經過添加其餘功能和功能來擴展其產品。

提升效率

微服務架構加速了整個建立過程。與單個單元不一樣，團隊能夠同時處理軟件系統的多個組件。除了提升生產率以外，還能夠更輕鬆地定位特定組件並專一於它們。單個組件的故障不會影響整個系統。相反，這也簡化了錯誤定位和維護。

產品不是項目

根據Martin Fowler的說法，微服務架構能夠幫助企業建立「 產品而不是項目」。簡單來講，微服務架構的使用容許團隊彙集在一塊兒併爲業務建立功能而不是簡單的代碼。整個團隊彙集在一塊兒，爲不一樣的功能作出貢獻。若是適用，這些能夠進一步用於不一樣的業務。此外，它還建立了一個自主的跨職能團隊。

成功的微服務設計的基礎知識

如今咱們知道微服務架構的優點，可是，咱們如何實現完美？咱們是否瞭解微服務設計原則？設計微服務架構的最佳實踐是什麼？讓咱們回答這些問題，看當作功的微服務設計的一些基礎知識。

1.功能範圍

經過不一樣團隊同時實施開發和部署以創建或支持與產品分別獨特的功能，定義微服務的範圍成爲很是重要的任務。雖然許多人擔憂建立「太多」微小的微服務，但一般更常見的是這些微服務過載。

當咱們談論微服務的範圍時，咱們指的是獨立軟件模塊的功能。微服務做爲幾乎無狀態系統的能力使其可以獨立開發。所以，必須肯定微服務將實現的功能。這有助於理解微服務的責任嗎？實現每一個微服務應該服務的預期功能。不只要防止過載，還要服務於不一樣的場景。例如，在單片設置中屢次調用一段代碼，建立微服務將使其更易於訪問和使用。最小化代碼量只會提升效率並避免膨脹的服務。

問題是關於如何定義微服務的範圍。雖然沒有明肯定義的規則集來實現這一目標，但若是您能夠定義範圍，則可使用一些指南或最佳實踐。如下是您能夠用來定義微服務的一些步驟。

• 第一步是肯定在各類模塊下複製的代碼片斷。你常常看到它們重複嗎？每次在不一樣的模塊中設置它們須要花費多少精力？若是全部這些的答案都很高，那麼微服務的範圍就是隻處理重複的代碼片斷。

• 您能夠採起的另外一個步驟是檢查模塊是否不依賴於其餘模塊或更簡單的術語，檢查模塊是否可能與其他服務鬆散耦合。若是是這樣，那麼微服務的範圍將是整個模塊的範圍。

• 在定義範圍時要考慮的另外一個很是重要的指標是檢查功能是否將用於重負載。這將檢查微服務是否必須在不久的未來擴展。若是確實如此，那麼將可擴展位定義爲微服務的範圍而不是將其與其餘功能相結合是一個好主意。

2.高內聚力與鬆耦合

任何微服務的主要動機是使服務彼此獨立。這意味着能夠編輯，更新或部署新服務，而不會妨礙任何其餘服務。若是相互依賴性很低，這是可能的。鬆散耦合的系統是一個服務對其餘服務知之甚少或什麼都不知道的系統。

在將總體架構分解爲更小的服務或組件時，將相似功能組合起來很是重要。將相關邏輯組合成單個單元是已知的內聚。內聚力越高，微服務架構越好。較低的內聚力代表不一樣服務之間的通訊過多致使系統性能較差。

3.獨特的身份識別來源

遵循微服務設計的基本原則，任何服務都必須成爲系統其他部分的惟一識別源。讓咱們舉一個例子來理解這種狀況。

在電子商務網站上下訂單後，向用戶提供訂單ID。生成此訂單ID包含有關訂單的全部信息。做爲微服務，訂單ID是有關訂單服務的任何信息的惟一來源。所以，若是任何其餘服務尋求關於訂單服務的信息，則訂單ID充當信息源而不是其實際屬性。

4. API集成

將總體設計分解爲多種服務意味着這些服務將協調並協同工做以造成系統。可是，這些服務如何溝通？想象一下，使用多種技術來建立不一樣的服務。它們如何相互關聯？

嗯，簡單的答案是使用API（應用程序編程接口）。微服務設計的基礎是使用正確的API。這對於維護服務和客戶端調用之間的通訊相當重要。輕鬆過渡和執行對於正常運行很是重要。

建立API時須要注意的另外一個重要事項是業務領域。域的這種定義將簡化區分功能的過程。有幾個客戶端在系統外部。這些客戶端能夠是其餘應用程序或用戶。不管什麼時候調用業務邏輯，它都由適配器（消息網關或Web控制器）處理，該適配器返回請求並對數據庫進行更改。

5.數據存儲隔離

爲特定服務存儲的任何數據都應該對該特定服務保密。這意味着對數據的任何訪問都應歸服務全部。此數據只能經過API與任何其餘服務共享。這對於保持對數據的有限訪問並避免「服務耦合」很是重要。基於用戶的數據分類很重要，能夠經過命令和查詢責任分離（CQRS）來實現。

6.交通管理

一旦設置了API而且系統啓動並運行，不一樣服務的流量就會有所不一樣。流量是客戶端發送給特定服務的呼叫。在現實世界中，服務可能運行緩慢，從而致使調用花費更多時間。或者服務可能充斥着呼叫。在這兩種狀況下，性能都會受到影響，甚至致使軟件或硬件崩潰。

這種高流量需求須要管理。呼叫和被叫的特定方式是流暢的流量的答案。服務應該可以終止任何致使延遲並影響性能的實例。

這也可使用稱爲「自動縮放」的過程來實現，該過程包括在須要時經過快速動做持續跟蹤服務。在某些狀況下，「斷路器模式」對於提供在呼叫中斷或服務無響應時可用的任何不完整信息很是重要。

7.自動化流程

獨立設計的微服務應該可以自行運行。自動化將實現自我部署和功能，而無需任何干預。此過程使服務本質上具備雲原生性，而且可以在任何環境中部署。但要實現這一目標，讓DevOps團隊不斷致力於服務的發展是很是重要的。

8.最小數據庫表（最好是隔離表）

訪問數據庫表以獲取數據多是一個漫長的過程。它可能須要時間和精力。在設計微服務時，主要動機應該圍繞業務功能而不是數據庫及其工做。爲了確保這一點，即便數據條目達到數百萬，微服務設計也應該只有幾個表。除了最小數量，關注業務是關鍵。

9.持續監測

想象一下，將單片架構分解爲微服務設計。這須要大量的時間和資源。在傳統工具的幫助下監控所作的全部更改並不容易。插入數據層和緩存會提升性能，但卻難以監控整個過程。

所以，爲了設計微服務架構，重要的是創建用於主動監視中心位置的數據存儲的過程。這有助於反映頻繁的變化，而不會影響系統的性能。在一個常見的場景中，微服務監控工具將監控單個服務，而後經過將數據存儲在一個集中位置來組合數據。這是遵循微服務設計原則的必要步驟。

實現API在成功的微服務架構中扮演的關鍵角色。還必須有一個持續監控API性能的過程。API性能監控對於任何微服務架構都相當重要，以確保功能在速度，響應性和產品的總體性能方面始終如一。

微服務架構的侷限性

雖然微服務是下降總體結構的最佳方式，但它有其自身的一些缺點。但在得出任何結論以前，讓咱們來看看其中的一些。

1.開發環境超載

隨着應用程序及其數據庫的增加，代碼庫也在不斷擴展。隨着針對每一個微服務的代碼擴展，它會使每一個加載的應用程序的開發環境過載。這可能致使生產力的重大延遲。

2. DevOps複雜性

單功能微服務的開發和部署並不是易事。使用多種技術並建立API來集中系統是一項挑戰。這須要一個經驗豐富的DevOps團隊。採購這樣一個經驗豐富的DevOps團隊對於維護基於微服務的應用程序的複雜性相當重要。

3.增長資源和網絡使用

因爲多個組件協同工做，所以在某種程度上彼此進行通訊很是重要。此通訊將致使網絡使用量增長。這須要高速可靠的網絡鏈接。此外，運行這些應用程序的費用也會增長。全部服務都單獨運行，增長了運營成本。

4.測試

測試應用程序可能具備挑戰性，由於有單獨的組件。與單片應用程序相比，微服務須要更長的時間進行測試，而且在出現任何錯誤時更加複雜。有時，因爲測試最終會影響整個應用程序，可能會致使延遲。

5.安全

在Web應用程序方面，安全性相當重要。使用微服務，實現這一點很困難。當存在獨立模塊的集羣時，每一個模塊都須要遵照爲整個系統定義的認證和受權規範。

除此以外，每一個模塊可能與其餘模塊通訊，跟蹤數據流變得很是困難。須要其餘措施，例如具備負載平衡的API網關，以確保行爲一致。這些額外的步驟致使每一個微服務的開銷。

6.應用程序的複雜性

因爲微服務是獨立組件，所以每一個微服務一般都有一個最適合其需求的技術堆棧。例如，機器學習模塊可能使用python堆棧，而計量服務可能使用Java堆棧，UI服務可能使用MEAN堆棧。這會致使複雜性，由於資源池和管理和構建新功能所需的技能將很是高。

7.高初始投資

微服務獨立運行，它們須要獨立的容器或資源來運行它們。每一個項目可能有不少微服務一塊兒工做，須要更高的投資來設置包括微服務，安全容器，負載平衡器，API網關等的全部集羣。

這值得麼？

在閱讀了微服務設計的基本原理以後，很明顯須要遵循一系列最佳實踐。可是，咱們還觀察微服務設計原則如何經過打破單片架構來簡化建立應用程序的過程。可是，與此同時，在調整微服務架構時須要克服某些挑戰。這些複雜性會影響運營流程，但從長遠來看，克服這些挑戰能夠帶來優化和更高效的應用。

此外，它還能夠克服延遲和缺陷，同時提升靈活性和性能。記住上面提到的，能夠說微服務架構對於成功的軟件系統是必要的。

包括PayPal，Twitter，LambdaTest和Netflix 在內的許多企業都支持微服務架構的可靠性，以部署更具可擴展性，功能性和強大的軟件。

---------------------------------------------

推薦閱讀：

微信支付開發中幾個值得注意的地方

解析：微服務的原則

老王講架構：負載均衡

支付寶系統架構內部剖析

SaaS技術棧的走勢

大數據Spark與Storm技術選型