貓頭鷹的深夜翻譯：集成方式是如何影響微服務架構的

前言

當萬維網首次出現時，集成不一樣類型的操做系統是一項主要的挑戰。HTTP的出現使得不一樣的操做系統之間能夠經過超文本使用統一的協議進行通訊。

當微服務的架構出現後，系統的集成帶來的挑戰沒有太大的分別：多種實現技術在物理網絡上彼此分離，須要相互通訊。從最終用戶的角度來看，微服務的集成在系統的無縫體驗方面起着相當重要的做用。正確集成的系統還有助於實現分佈式系統的優點：它們能夠在service級實現擴容提升效率，而且可以在知足業務需求的同時下降架構成本。

另外一方面，錯誤集成的系統可能會完全破壞微服務架構的好處：它可能會致使數據丟失和繼承問題。這些問題一般很難追蹤，同時用戶會受到不良的影響。

無縫集成有許多因素須要考慮。咱們須要針對不一樣的場景選擇最合適的集成方式。接下來，咱們會介紹不一樣集成方式的優缺點。

數據庫集成

在這種模式下，兩個或多個服務都讀寫自同一個中心數據庫。全部的服務鏈接到同一個中心數據庫上。咱們能夠用一個銀行系統來解釋這種架構。

數據庫集成的顯著優勢之一是簡單。事務的管理和別的模式相比更加直觀。這多是使用最普遍的一種模式，同時也多是最被濫用的。

這個模式下服務耦合度較高，使得微服務較難以變動和擴展。定義數據的所屬權以及更新schema會很麻煩，由於須要從新編譯和部署全部相關的服務。它致使大爆炸形式的集成。這種類型的集成可能在維護微服務的自治性方面存在問題。

在大規模應用的場景下，惟一的選擇是在數據庫中投入更多硬件，即便這樣，也很難避免數據庫和行級爭用中的死鎖。

想狀況下，咱們不建議將此模式用於服務間通訊。它能夠用於分階段微服務部署的早期階段。換句話說：若是你使用它，很快就會拋棄它。

同步API調用

在這種集成模式下，服務之間經過API同步的通訊。全部的數據訪問都是經過API以請求響應的方式實現，調用方等待API的返回數據作進一步處理。在上面的例子中，若是事務服務須要讀取用戶信息，能夠經過調用用戶服務的API來實現。

這種方式在直接數據庫的調用之上進行了良好的抽象，並在調用技術選擇方面提供了極好的靈活性。它隱藏了實現的細節：使得咱們能夠在不影響客戶的前提下自由的變動。好比，用戶模塊可能使用的是Java和MySQL，而事務模塊可能使用的是SQL Server和.NET，可是它們彼此之間仍是能夠經過API進行通訊。

可是，這個和直接的數據庫集成模式沒有本質的區別。在數據庫調用之上添加另外一個網絡調用也會j下降可擴展性：增長了負載，下降了性能。這種集成模式也使事務管理變得困難而且影響了服務自治，由於服務依賴於彼此的正常運行。在微服務中，若是必須在系統邊界以外同步讀取數據，那就是SOA架構的感受了。

在某些場景下，這種集成模式是最佳的甚至是不可避免的。API集成模式中安全令牌是一個主要的應用場景，由於這些token生命週期短，並且在使用以前才生成。若是可能的話，應謹慎使用同步API調用。若是使用這種模式，它們應該版本化而且應該與熔斷機制一塊兒使用。

ETL (Extract, Transform, and Load)

ETL須要按預約義的時間表經過後臺進程同步數據。這些數據能夠是推模式或者拉模式。它是異步的，這意味着服務能夠在不等待「回調」的狀況下執行。

這種集成模式也很好地隱藏了實現細節。它提供了合理的解耦，由於服務不依賴於彼此的正常運行。實時用戶不會受到正常運行時間或處理時間的影響。

ETL過程須要改變源和目標數據庫。經過ETL集成，數據一致性取決於計劃和持續時間。弄清楚變化的可能會使應用變得太複雜。在這種場景下，團隊不得不導出所有的數據。這使得流程運行時間很是長，嚴重影響了它們的實用性。

報告性的服務很是適用於這種集成。這些ETL的過程一般會有些耗時，只有在系統中可接受舊數據時才應使用它們。

消息

在這種模式下，服務彼此之間經過指令和事件交換信息它們經過消息中介如RabbitMQ，MSMQ等。在上面的例子中，事務服務創建了一個帳號餘額變動的時間而且放到消息中間件中。獎勵服務，積分服務和消息服務分別訂閱這個事件，而且進行處理。這是發佈訂閱模式，還有不少別的消息模式。

只要正確的實現，消息提供了很是好的解耦。它提供了很是高的靈活性，只要可以正確的通訊。將數據推送給訂閱者使得數據發送的部分很是容易完成。並且發送方徹底不會受訂閱端處理細節的影響。

不正確的服務或事務邊界可能使消息傳遞實現複雜化。並且，這種模式提供的鬆耦合影響一致性爲。它須要高度的規範化才能正確實現消息傳遞，而沒有經驗的團隊可能會很掙扎。

兩種類型的消息

典型的消息傳遞解決方案創建在傳輸屬性的基礎之上。在較高的層面上，這些傳輸能夠分爲兩類：消息隊列和消息流。

排隊解決方案涉及處理實時數據。一旦消息被成功消費，則這條消息會從隊列中出隊。只要處理可以跟上，隊列就不會累積，也不會佔用太多空間。可是，在擴展訂戶的狀況下，沒法保證消息的順序性。

在流式傳輸解決方案中，消息按順序存儲在流中。它發生在消息傳輸自己。訂戶在流上的位置保留在傳輸上。它能夠根據須要在流上倒置。這對於故障和新的訂閱方案很是有利。可是，這取決於流的長度。從存儲角度來看，它須要更多配置，所以須要對流進行歸檔。

這裏的典型用例假設系統可以處理有些陳舊的數據。若是狀況並不是如此，咱們須要更多地分析業務領域並理解緣由。在咱們的示例中，當事務更新發生時，信用分數更新不必定須要實時發生。消息在這個場景下很是適合。咱們能夠相應地設置用戶的指望，並容許服務管理本身的負載。

總結

每一種微服務架構都不一樣，沒有絕對完美的方案。當咱們使用它們時，咱們須要結合故障情景，驅動這些集成模式的組合。好比，Netflix使用消息傳遞來移動數據，若是消息不可用或數據仍在傳輸中，它們會回退同步API。在每種狀況下，理想的是實現最靈活和可擴展的微服務架構，可是必須首先考慮實施細節和本身的能力。

這裏的關鍵是在須要擴展和自治時使用異步模式。要實現這一目標，您須要可靠的服務邊界和明確的數據全部權。不然，您最終會遇到複雜且不可持續的集成方案。對業務流程建模很重要。這將讓您知道哪些用例和進程本質上是異步的而且適合於消息傳遞。

想要了解更多開發技術，面試教程以及互聯網公司內推，歡迎關注個人微信公衆號！將會不按期的發放福利哦~