關於API和微服務最重要的三個問題

API也就是咱們常說的應用程序接口，是以編程語言提供的結構，容許開發人員更容易地建立複雜的功能。它們抽象出更復雜的代碼，並提供一些簡單的語法來使用。

而微服務架構是一項在雲中部署應用和服務的新技術。微服務不須要像普通服務那樣成爲一種獨立的功能或者獨立的資源。定義中稱，微服務是須要與業務能力相匹配。微服務做爲一項在雲中部署應用和服務的新技術已成爲當下最新的熱門話題。但大部分圍繞微服務的爭論都集中在容器或其餘技術是否能很好的實施微服務，咱們認爲API應該是重點。

本文主要講的是如何讓企業高管了解API和微服務的價值，如何將單一的遺留應用程序轉換成微服務和API以及如何圍繞API和微服務組織團隊？

1、如何讓企業高管了解API和微服務的價值？

主要有兩種方式。首先，通常不多有企業高管了解API和微服務平臺的投資商業價值，所以不多有人可以成功地理解API和微服務架構的抽象價值。儘管如此，大多數人仍是都能理解相互依賴的商業投資策略。在這種狀況下，須要高於單個項目的分析，來肯定可能推進業務變化的已知業務變動計劃組合和激發這些變化的行業壓力。評估並比較在有或者沒有API和微服務的狀況下，響應這些變化的成本和時間價值。

換句話來說，要將對話提高到項目組合級別，由於這是API和微服務協同效應所發揮出最大影響力的地方，並以業務變動投資術語（而不是架構價值術語）進行對話。其次，一些業務計劃蘊含內置的API價值，能夠把這些價值單獨出售。例如，若是一個公司的目標是改進跨多個渠道的訂單履行過程(例如，移動、網絡、信息亭、直接合做夥伴集成)，那麼不管訂單來自哪一個渠道，API都是實現一致的客戶體驗和業務流程結果的最佳技術方法。在這種狀況下，API應該是建議的默認架構，而不討論非API的方法。

2、如何將單一的遺留應用程序轉換成微服務和API？

咱們必須注意不要過快地跳到轉換遺留應用程序策略上。爲了說明這一點，它有助於明確區分API和微服務。對於API，咱們能夠利用各類可用的遺留系統和應用的現代化和集成工具進行快速構建業務API，從而訪問遺留應用程序中隱藏的業務事務和數據。另外能夠避免總體結構轉換的高成本，而且經過大幅改進用戶和員工的體驗，來知足數字轉換的需求，更不用說基於API的業務流程優化和B2B集成。尤爲是當遺留下的業務規則和數據在很大的程度上與業務的將來需求相保持一致時，這種方法最能體現出價值。

可是在業務動態須要對傳統應用程序內部進行更改時，那就須要剝離遺留應用程序「塊」並將它們轉換爲微服務架構了。每一個「塊」將會被提供一組緊密的業務功能（即單個業務功能）並提供與該功能相關的業務API。漸漸地，每一個「塊」背後的遺留代碼將被模塊化、可單獨部署的微服務組件所取代。

3、如何圍繞API和微服務組織團隊？

API和微服務團隊的主要組織結構應該圍繞業務功能進行展開。上一個問題已經回答瞭如何將遺留應用程序劃分爲業務功能「塊」，那麼每一個業務功能（例如，訂單履行，計費，庫存等）都將成爲團隊交付的軟件產品（單個團隊可能擁有一項或多項業務能力），團隊負責開發由業務功能提供的服務的業務API的同時，還負責將這些API的業務能力轉化爲微服務。其優點在於，使用API的其餘團隊沒必要關心業務API是否由微服務、遺留系統和應用集成或者其餘任何實現方法所支持，全部這些都是負責業務能力的團隊負責。除此以外，每一個企業還能夠擁有組建API和微服務的卓越中心（或者更普遍地說，用於雲原生解決方案體系架構），從而創建協做設計和治理模型以促進並優化業務API業務的一致性。最後，企業能夠組建不一樣類型的專業技術API團隊，例如集成或基礎架構API團隊。