處理微服務架構的內部架構和外部架構

關鍵點

• 微服務架構MSA并不是一個全新的概念，它旨在通過使用現代技術的優點來正確地實現SOA。
• 微服務只能解決整體問題的一小部分——架構師們需要將微服務架構作為一種架構實踐，并實現它以滿足企業級應用要求。
• “微”不僅僅只是關注大小，它主要是關注范圍。
• 整合是微服務架構的一個關鍵方面，在適用時，它可以作為微整合來實施。
• 迭代式的方法可以幫助組織從其當前狀態轉換到一個完整的微服務架構。

今天的企業里內容范圍非常廣，包括服務、傳統應用程序和數據等等，這由一系列的消費渠道為首，包括桌面、網站和移動應用等。但是，通常情況下，由于沒有一個被以適當的方式創建和系統化地管理的集成層，會出現斷層，這些消費渠道需要有這樣的集成層來使能業務功能。大多數企業正在通過面向服務的架構（Service-Oriented aArchitecture，SOA）來應對這一挑戰。在面向服務的架構中，應用程序組件通過網絡上的通信協議向其他組件提供松散耦合的服務。最終，它的意圖是讓微服務架構可以更靈活和更容易地擴展。雖然沒有充分地準備好采用微服務架構，但是這些組織正在規劃架構并實現企業應用和服務平臺，使他們可以逐步走向微服務架構。

事實上，Gartner預測到2017年為止，超過20%的大型機構將會部署完整的微服務，以提高靈活性和可擴展性，事實上她們已經這樣做了。微服務架構正日益成為有效地提交新功能的重要途徑。它可以解決伴隨著創建新服務的同時帶來的復雜難題，結合傳統應用程序和數據庫，并開發Web應用程序、移動應用程序或任何基于消費者的應用。

現在，企業們正在朝著SOA發展，并且在SOA的范圍里張開臂膀迎接微服務架構的概念。很有可能，最大的吸引力在于由這些微服務提供的組件化和單一功能，使得迅速部署組件以及按需擴展變得可能。它已經不再只是一個新的概念。

比如在2011年，有一個醫療服務平臺啟動了一個新的策略，就是每當它寫了一個新的服務時，它就會相應地為它配備一臺新的應用服務器，以支持服務部署。因此，這是一個來自于DevOps的實踐，它為服務之間創造了一種依賴較少的環境，并確保在進行某些維護操作的時候對其他系統影響可以降到最小。其結果是，這些服務運行在超過了80臺服務器之上。事實上這是非常基本的，因為那時不像現在這樣有適當的DevOps工具，相反，他們使用Shell腳本和Maven類型的工具來構建服務器。

然而微服務是非常重要的，它只是一個大格局的一個小方面。很明顯，一個組織不可能僅僅因為使用了微服務就能得到微服務的全部好處。在設計微服務的時候，采用微服務架構以及最佳實踐的做法是營造一個鼓勵創新的環境，并實現業務能力的快速提交的關鍵所在。這就是真正的附加價值。

解決實現的挑戰

在構建你自己的微服務架構時，大家普遍接受的實踐是專注于你如何打磨出單一功能的服務，而不是服務的規模。內部架構通常只能解決微服務自己的實現。外部架構包括必需的平臺能力，在開發和部署你的微服務時，會需要這些平臺能力來確保可連接性、靈活性和可擴展性。為此，在制作你內部和外部的微服務架構的時候，企業中間件起著關鍵的作用。

首先，中間件技術應該兼容是對DevOps友好的，它包含高性能的功能，并且支持關鍵服務標準。此外，它必須支持一些設計原則，比如迭代架構并且易于插拔，這反過來將提供快速的應用程序開發與持續發布。最重要的是，一個全面的數據分析層對于設計失敗的支持是至關重要的。

在實施微服務架構時，企業常犯的最大錯誤往往是完全拋棄了已經確立的SOA方法，并且用微服務背后的理論來替換它們。這樣就會導致架構不完整，并且引入了冗余。聰明一些的做法是把一個微服務架構當成一個分層的系統，它包括類似企業服務總線（Enterprise Service Bus，ESB）的功能來處理所有的與整合相關的功能。這也將作為一個中間層，使變化可以發生在這個層面上，這樣它可以應用到所有相關的微服務。換句話說，ESB或類似的中介引擎通過提供所需的連接性去將歷史數據和服務整合到微服務，實現逐步向微服務架構推進。先發布微服務，然后再通過API把它提供出去，這種方法對于整合一些基本規則來說也很重要。

內部架構的范圍確定和設計

值得注意的是，內部架構需要設計得比較簡單，因此它才可以很容易地獨立部署，或者單獨廢棄。一旦出現微服務失敗或有更好的服務出現，可廢棄性是必需的。無論是這兩種情況下的哪一種，都需要可以很容易地廢棄相應的微服務。微服務也需要獲得部署架構和運行環境的強有力支持，微服務要在這樣的運行環境中被構建、部署和執行。因此，它需要足夠簡單，這樣才能獨立部署。理想的做法是發布一個相同服務的新版本，加入對缺陷的修復，包括新的功能或者對現有功能的改進，并去除掉廢棄的功能。

微服務架構建立的基礎框架決定著對一個微服務架構的內部架構的關鍵需求。吞吐量、延遲和低資源使用率（內存和CPU）等都是需要考慮的關鍵需求。一個好的微服務框架通常會建立在輕量級、運行速度快和現代編程模型的基礎之上，比如注釋元配置，它與核心業務邏輯相獨立。此外，它應該有能力來保障微服務的安全，滿足必要的行業領先的安全標準，也應同時提供一些指標來監測微服務的行為。

與外部架構相比，內部架構中每一個微服務的實現都比較簡單。在搜尋和設計內部架構時，一個好的服務設計要考慮到以下六個因素：

首先，微服務應該有單一的目的和單一的責任，并且服務本身應該作為一個獨立的部署單元，可以在生產部署時創建多個實例。

其次，微服務應該有這樣的能力，那就是可以采用一個最適合它要發布的功能的架構，并且此架構能夠使用適當的技術。

第三，一旦單體服務被細分為微服務，每一項微服務或每套微服務就應該有可以通過API提供服務的能力。然而，在內部實現中，該服務可以采用任何合適的技術，實現業務需求，實現各自的業務能力。為此，企業可能要考慮像 Swagger 那樣的東西來定義API規范或特定微服務的API定義，并且微服務能利用這個作為互動的點。這在微服務開發中被稱為以API為先的方法。

第四，要部署的內容也可能有不同，比如捆綁在基于Hypervisor的鏡像的獨立的可部署單元，或者是容器鏡像，這通常是更受歡迎的選擇。

第五，企業需要利用分析來細化微服務，同時一旦服務失敗要提供恢復手段。為此，企業要整合使用度量指標和監控來支持微服務的演進方法。

第六，即使微服務范式本身可以讓企業的微服務有多種實現或多語言實現，對最佳實踐和標準的使用對于保持一致性是非常必要的，同時要確保解決方案遵循一般的企業架構原則。這并不是說，多語言的機會就被完全否決了，而是說它們在使用時需要被監管。

用“外部架構”來解決平臺能力

一旦內部架構已經建立，架構師就需要關注組成他們微服務架構的外部架構的功能。外部架構的一個關鍵組成部分是引入企業服務總線（ESB）或類似的中介引擎，它們將會幫忙把歷史數據和服務與微服務架構連接起來。中介層也將使企業可以維護自己的標準，同時讓別人可以在相應的生態系統里管理他們自己的。

使用服務注冊中心可以支持依賴管理、影響分析、微服務和API的發現功能。這也可以把服務和API的組合流水線化，并把微服務連線到服務經紀人或樞紐。任何微服務架構都應該支持創建RESTful API，這將有助于在企業開發應用軟件時定制資源模型和應用邏輯。

先設計API，再實現微服務，然后通過API將它提供出去，要注意提供出去的是API而不是微服務。要堅持這樣的原則。各家企業都想要解決的另一個共同需求是微服務的安全問題。在一個典型的單體應用程序中，企業將使用底層存儲庫或用戶存儲區來生成來自舊架構的安全層所需要的信息。在微服務架構中，企業可以利用在業界廣泛采用的API安全標準，比如OAuth2和OpenID Connect等，去實現對邊緣模塊的安全層，包括微服務架構中的API。

在所有這些能力中，最重要的也是真正有助于解決微服務架構復雜性的是使用企業級的底層平臺，它可以提供豐富的功能來管理可擴展性、可用性和性能。這是因為把一個單體應用分解成微服務并不意味著一個簡化了的環境或服務。可以肯定的是在應用層面，企業本質上是在處理幾個微服務，這遠比一個單一的復雜的應用更簡單。然而，作為一個整體的構建卻是相當地艱巨。

事實上，微服務架構的復雜度可能更大，因為我們當需要考慮其他方面時，比如向一個進程發起一次單向調用這不算復雜，但微服務之間是需要相互調用的。這在本質上意味著，系統的復雜性已經變成了所謂的“外部架構”，這通常由API網關、服務路由、發現、消息通道和依賴管理等組成。

因為內部架構現在已經極其簡單，它只包含用來構建一個微服務架構的基礎和運行時，架構師將會發現現在微服務架構已經有了一個干凈的服務層。我們需要更多地關注外部架構，以解決大家所共同面臨的復雜性。如下圖所示，有一些常見的切實的場景需要解決：

外部架構將需要一個API網關，以幫助它對內對外提供業務API的能力。通常，大家會使用API管理平臺來管理這方面的外部架構。這對于那些正在構建Web應用程序、移動應用程序和物聯網解決方案等的用戶來說，把這些基于微服務架構的服務能力提供給他們是非常必要的。

一旦微服務到位，就會出現某種形式的服務路由，通過API發過來的業務請求將被路由到相關服務集群或服務。在微服務內部，會有以分擔負載為目的的多個實例。因此，有必要進行某種形式的負載均衡。

此外，微服務之間也有相關性。例如，如果微服務A對微服務B有依賴，它將在運行時調用微服務B。服務注冊中心可以讓微服務發現后臺服務節點，所以它可以解決這個需求。服務注冊中心還將管理API和服務依賴關系，以及其他資產，包括策略。

接下來，微服務架構外部架構需要一定的信息傳遞渠道，這基本上形成了一層，允許微服務內部的交互，并且該層還把微服務架構連接到舊的系統。此外，這一層也有助于建立微服務之間通信（微整合）通道，并且這樣的通道應該是輕量級的協議，比如HTTP、MQTT等等。

當微服務之間相互通信時，需要有某種形式的身份驗證和授權。使用單體的應用程序時這是不必要的，因為有一個直接的過程調用。相比之下使用微服務時，這些就轉化成了網絡調用。最后，診斷和監控都是需要考慮的關鍵方面，以找出由每個微服務處理的請求類型。這將有助于企業擴展單個微服務的規模。

回顧微服務架構場景

為了全面正確地看待事情，我們分析一些實際場景，這些場景展示了微服務架構的內部和外部架構如何一起運作。我們將假設組織已經使用微軟Windows Communication Foundation或Java JEE/J2EE服務框架實現了她的服務，并且開發人員還在寫新服務代碼，使用的是應用了微服務架構原則的微服務框架。

在這種情況下，提供數據和業務能力的現有服務不能被忽視。因此，新的微服務將需要與現有服務平臺之間相互通信。在大多數情況下，這些現有的服務將使用框架所堅持的固有標準。例如，舊的服務可能使用服務綁定，比如HTTP上的SOAP、Java Message Service （JMS）或IBM MQ等，并使用Kerberos或WS-Security進行保護。在這個例子中，消息渠道也將在協議轉換、信息轉換、從舊架構通向新的微服務架構的安全過渡中起重要的作用。

另一個組織需要考慮的方面是在業務增長方面可能造成的對其可擴展性的影響，由于單體應用在這方面是有很明顯的局限性的，而微服務架構是可以橫向擴展的。在這些明顯的限制中，還有可能的錯誤，因為在一個單片環境里測試新的功能非常繁瑣，會導致延遲實現這些變更，成為滿足快速提交需求的障礙。另一個挑戰將是在所有者缺失的情況下支撐這個單體的代碼庫，在微服務的情況下，個人或單個功能是可以自己管理的，這些可以在不影響其他功能的情況下根據需要迅速擴展。

總之，雖然微服務對于組織有顯著的好處，以逐步淘汰或迭代的方式向前推進微服務架構以確保平穩過渡，這可能是最好的辦法。能使微服務架構成為被優先選擇的以服務為向導的方案，其關鍵是明確所有權，以及它可以將故障隔離，從而使這些所有者可以把他們的領域內的服務實現得更加穩定和高效。

 

 

來自：http://www.infoq.com/cn/articles/navigating-microservices-architecture