在正文開(kāi)始之前，我們來看一個日常生活場景，咖啡自動售賣機：   

第一排，是四個選項：美式、拿鐵、摩卡、白咖啡；

第二排，單位是ml，代表産出咖啡的量；

第三排，是否加糖；

第四排，是否加奶。

輸入以上這(zhè)四個參數後(hòu)，自動售賣的咖啡機便會(huì)按照要求提供所需的咖啡。當然售賣機還(hái)是會(huì)根據操作者的人臉或掃碼确定其身份信息，做出相應的扣款，或是先付款後(hòu)操作等處理。這(zhè)就(jiù)是一台咖啡機所提供的服務，機身上提供了操作的說(shuō)明，根據提示輸入類型、口味等信息，制造出對(duì)應的咖啡。

微服務與 API

咖啡機提供的是生活服務，而我們一直以來的話題：“微服務”，則提供的是軟件服務。一個軟件服務的使用，需要輸入參數：如第一個參數代表了類型，第二個參數代表了返回的數量，第三個、第四個參數代表了是否需要加某些規則；同時(shí)也需要身份信息：如報頭加入消費者名稱，加入認證信息等；當然還(hái)需要有返回，也就(jiù)是計算或者處理的結果返回。這(zhè)就(jiù)是軟件服務提供的能(néng)力，也是軟件服務的API。

在微服務的架構提出之前，行業内首先提出的是服務化，畢竟服務能(néng)力的封裝、自運行，可比自己編碼實現要快捷、低廉很多。在服務化的基礎上才有了微服務，微服務就(jiù)是其基于服務化將(jiāng)應用程序構造爲一組松散耦合的服務。

因此，微服務基于 API 作爲服務能(néng)力的提供，也是服務間消費的規則和方式。信息标識認證的方式、參數傳遞的類型，格式返回的方式，這(zhè)都(dōu)是API定義的。

API

API 的定義是應用程序編程接口，而在服務化的場景中，API 是應用程序間的訪問接口，即服務提供的行爲合同。那麼(me)在微服務的場景中，API就(jiù)是微服務間獲取信息的契約。

微服務架構中服務間調用關系錯綜複雜，程序提供的服務能(néng)力可以被其他任意服務消費和使用，這(zhè)也是建設微服務的一個優勢。服務能(néng)力的複用，可以在某個業務領域内被消費，也可以被網絡區域外的服務所依賴，也可以是整體企業對(duì)外的能(néng)力開(kāi)放，其本質歸根結底都(dōu)是 API 的調用。

當然，還(hái)有調用中的信息認證，調用允許/拒絕的控制，應對(duì)大流量時(shí)限流控制，熔斷控制，批處理方式等等，全都(dōu)是 API 管理内容。有了這(zhè)麼(me)細則的控制，對(duì)于 API 的監控也尤爲重要，因爲很多控制的數據皆是從監控記錄而來。

因此，API 才是微服務化建設中最爲核心的管理對(duì)象，而且從整體微服務化建設的角度出發(fā)，在開(kāi)發(fā)态、運維态、運行态均需要關注對(duì) API 的管理。

開(kāi)發(fā)态：API 管理

之前提過(guò)微服務的建設，從橫向(xiàng)上看，跨越微服務的開(kāi)發(fā)态、運維态、運行态，那麼(me)在開(kāi)發(fā)态，API 設計是先于服務開(kāi)發(fā)的，因此 API 管理應該在開(kāi)發(fā)态就(jiù)已經(jīng)開(kāi)始記錄和調試。

API 包括請求方法（GET、POST等）、請求參數（請求頭、請求體）、響應内容等信息，對(duì)于 API 接口文檔的管理，應該是當做微服務間調用的契約，在服務調用中，指導消費服務的使用。

API 管理可能(néng)在不同的階段會(huì)有不同的運用，在開(kāi)發(fā)階段可以幫助開(kāi)發(fā)人員快速的對(duì) API 進(jìn)行設計和調整，在測試階段方便測試人員查看 API 的用法，也更有利于知識傳遞和工作交接；在運行階段，API 的說(shuō)明也會(huì)便于其他應用或系統對(duì)該服務的調用。

運維态：API 變更

微服務場景下，敏捷是第一要務。因此，服務可能(néng)會(huì)經(jīng)常升級、變更，也難免會(huì)有 API 的變動和更改。既然 API 是微服務間的契約，那麼(me) API 的變更也就(jiù)如同契約的變更，將(jiāng)會(huì)對(duì)所有消費者産生影響。

因此 API 的變更需要慎重，變更之後(hòu)也需要做詳細的變更說(shuō)明以供消費者參閱，甚至需要有固定的流程審批。

當然這(zhè)裡(lǐ)也給 API 管理提供了一個要求，就(jiù)是要支持多版本的管理，以滿足持續集成(chéng)、持續發(fā)布，以及變更的信息。

運行态：API 治理

運行态下，對(duì)于 API 的治理算是細粒度的微服務治理。畢竟微服務化的建設，是企業服務化中台建設的第一步，可不隻是調調微服務框架那麼(me)簡單。

未來在服務化中台中，服務能(néng)力均以 API 的方式提供，所有的管理粒度都(dōu)是 API 接口。因此，對(duì)于 API 的治理，才是微服務治理的重點，如 API 粒度的訪問控制，API粒度的限流、降級、熔斷，API 級别的性能(néng)監控信息，API 的調用依賴關系。API 的鏈路節點信息等等。

當然除了服務間的 API 治理以外，伴随微服務逐漸走進(jìn)人們視線的 API 網關，更是對(duì) API 的南北向(xiàng)調用的管理和控制。API 網關提供 API 的統一對(duì)外能(néng)力輸出，在真實環境中，也不隻是對(duì)外能(néng)力，也表現在跨網絡域、兼容異構框架等等方面(miàn)，但都(dōu)是針對(duì) API 粒度的管控和觀測。

總結

微服務的建設其管理的核心對(duì)象是比服務更細粒度的 API，管理内容包括 API 接口信息的管理，變更的影響，運行的監控，以及流量控制等各個方面(miàn)。

當然還(hái)未提到存量的業務系統，因爲非微服務架構提供的接口也非标準協議，這(zhè)類的系統也是以 API 接口形式提供，并在适當的位置做好(hǎo)協議、報文的轉換。存量老舊系統的兼容，將(jiāng)會(huì)在下一期文章中做詳細介紹和分享。