微服務和API：必要的結合

微服務架構正在各類規模的企業中得到普遍的關注;它們是目前設計軟件應用程序最流行的方法之一。與傳統的單體應用開發方法相比，微服務架構能夠更快地更改和開發新的應用程序，所以能夠提供更高的敏捷性。 Netflix，Google，亞馬遜和許多其餘IT企業已成功地採用此架構，並引導其餘人模擬這種模式。

對於大多數企業而言，微服務架構的採用和過渡將是一個漸進的過程，基於微服務的應用程序將與傳統的應用程序共存和交互。微服務必須與傳統應用程序、現有系統和業務流程，以及當前的企業運營，以及合規性的要求同時存在。

此外，微服務在帶來的好處的同時也引入了一些負面性，例如服務蔓延，複雜性增長，以及增長冗餘工做的風險。企業和組織須要微服務和API共同有效地實施IT架構。

對於許多公司而言，挑戰在於學習如何將微服務架構與企業中已部署的衆多其餘架構模式相結合。在控制複雜性的同時，管理微服務提供的速度和靈活性的一種方法是採用API。制定一個總體的API策略將使得微服務更易於管理，並容許它們與現有的遺留系統共存，而不是生活在遠離這些關鍵系統的圍牆花園中。將微服務架構與總體的API策略相結合是得到微服務帶來的優點的有效方法，同時能夠有效地限制以上提到的缺點。

微服務和API如何協同工做

API曾經是底層的代碼編程接口，但如今它們已成爲產品自己，遵循必定的API標準，例如REST，使他們對開發人員更友好，並具備更強的管理和治理能力。 API提供商們如今互相競爭，以引發開發人員的注意。而且，API經濟，一個圍繞着API使用者和API提供者之間價值交換的新經濟模式正在日漸增加。

對API使用方法的變化也改變了他們的技術要求。API如今須要複雜的門戶，這樣開發人員才能發現並測試它們。同時也須要提供註冊和支付API調用，以及限制API使用的各類機制。而且，因爲API是對外部公開的，它們須要經過API網關提供強大的安全防範能力。當全部這些功能結合在一塊兒時，便造成了API管理這樣一類新的解決方案，爲愈來愈有價值的業務資產提供控制，可見性和治理的功能。

全部對互聯網上公開API（以及它們創造的價值）的關注都提出了一個問題：是否有辦法爲企業內部的API實現相同的價值？如今API管理技術已經變得更加成熟， 如今能夠實現數據源，服務和應用程序的 發現和自助 服務。 這使得整個企業內更多的團隊可以以受控和可見的方式開發軟件，擴展IT團隊的生產力，並建立內部的API經濟。

使用微服務架構，內部API經濟的價值甚至更高，由於隨着微服務建立更多數據端點，控制鏈接的難度就越大。試圖在全部這些端點之間建立點對點的鏈接將會是災難性的。在一個像微服務架構這樣的高度分佈式環境中，開發一個總體的API策略將會相當重要。

許多公司採用這樣一種API策略來開放全部的服務（不管他們是基於微服務仍是是單體架構；是在本地部署仍是基於雲端部署）：由API主導的鏈接。 這種以API爲主導的集成方法是一種明確的總體策略：它使用不一樣功能的，可重用的API來開放服務，而且使用API來組合和重構出不一樣類型的服務，以建立易於更改和演進的業務需求。

隨着微服務架構的應用變得更加普及，尤爲對於具備傳統IT技術棧的老牌組織而言，集成全部這些服務並從中獲取價值的問題變得更加劇要。 這就是實施以API主導的系統集成策略，對於使微服務架構在企業內部生效的重要緣由。

API不只彌合了微服務和傳統系統之間的差距，而且還使得構建和管理微服務變得更加容易。經過制定API策略，公司能夠將微服務提供得功能公開爲產品，這能夠同時帶來內部和外部的業務價值。

標準化的、產品化的API還有助於減小SaaS應用程序與傳統IT系統之間構建點對點集成的相關成本。這使得組織能夠根據業務需求快速插拔微服務，而無需大量定製化的開發。API能夠在整個企業中以標準化方式爲流量管理和監控、日誌記錄、審計和安全等提供標準化的機制，同時保留業務所需的靈活性。

這些管理良好的API還能夠實現微服務的重用和可發現性。隨着開發團隊構建了可能對更普遍的消費用戶有益的微服務，API接口使它們可被發現。而後，這些微服務能夠向更普遍的受衆開放-內部或外部–而且做爲可重用的功能進行管理。