在(zài)正文開始之(zhī)前，我們來(lái)看一(yī / yì ／yí)個(gè)日常生活場景，咖啡自動售賣機：   

第一(yī / yì ／yí)排，是(shì)四個(gè)選項：美式、拿鐵、摩卡、白咖啡；

第二排，單位是(shì)ml，代表産出(chū)咖啡的(de)量；

第三排，是(shì)否加糖；

第四排，是(shì)否加奶。

輸入以(yǐ)上(shàng)這(zhè)四個(gè)參數後，自動售賣的(de)咖啡機便會按照要(yào / yāo)求提供所需的(de)咖啡。當然售賣機還是(shì)會根據操作者的(de)人(rén)臉或掃碼确定其身份信息，做出(chū)相應的(de)扣款，或是(shì)先付款後操作等處理。這(zhè)就(jiù)是(shì)一(yī / yì ／yí)台咖啡機所提供的(de)服務，機身上(shàng)提供了(le／liǎo)操作的(de)說(shuō)明，根據提示輸入類型、口味等信息，制造出(chū)對應的(de)咖啡。

微服務與 API

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

在(zài)微服務的(de)架構提出(chū)之(zhī)前，行業内首先提出(chū)的(de)是(shì)服務化，畢竟服務能力的(de)封裝、自運行，可比自己編碼實現要(yào / yāo)快捷、低廉很多。在(zài)服務化的(de)基礎上(shàng)才有了(le／liǎo)微服務，微服務就(jiù)是(shì)其基于(yú)服務化将應用程序構造爲(wéi / wèi)一(yī / yì ／yí)組松散耦合的(de)服務。

因此，微服務基于(yú) API 作爲(wéi / wèi)服務能力的(de)提供，也(yě)是(shì)服務間消費的(de)規則和(hé / huò)方式。信息标識認證的(de)方式、參數傳遞的(de)類型，格式返回的(de)方式，這(zhè)都是(shì)API定義的(de)。

API

API 的(de)定義是(shì)應用程序編程接口，而(ér)在(zài)服務化的(de)場景中，API 是(shì)應用程序間的(de)訪問接口，即服務提供的(de)行爲(wéi / wèi)合同。那麽在(zài)微服務的(de)場景中，API就(jiù)是(shì)微服務間獲取信息的(de)契約。

微服務架構中服務間調用關系錯綜複雜，程序提供的(de)服務能力可以(yǐ)被其他(tā)任意服務消費和(hé / huò)使用，這(zhè)也(yě)是(shì)建設微服務的(de)一(yī / yì ／yí)個(gè)優勢。服務能力的(de)複用，可以(yǐ)在(zài)某個(gè)業務領域内被消費，也(yě)可以(yǐ)被網絡區域外的(de)服務所依賴，也(yě)可以(yǐ)是(shì)整體企業對外的(de)能力開放，其本質歸根結底都是(shì) API 的(de)調用。

當然，還有調用中的(de)信息認證，調用允許/拒絕的(de)控制，應對大(dà)流量時(shí)限流控制，熔斷控制，批處理方式等等，全都是(shì) API 管理内容。有了(le／liǎo)這(zhè)麽細則的(de)控制，對于(yú) API 的(de)監控也(yě)尤爲(wéi / wèi)重要(yào / yāo)，因爲(wéi / wèi)很多控制的(de)數據皆是(shì)從監控記錄而(ér)來(lái)。

因此，API 才是(shì)微服務化建設中最爲(wéi / wèi)核心的(de)管理對象，而(ér)且從整體微服務化建設的(de)角度出(chū)發，在(zài)開發态、運維态、運行态均需要(yào / yāo)關注對 API 的(de)管理。

開發态：API 管理

之(zhī)前提過微服務的(de)建設，從橫向上(shàng)看，跨越微服務的(de)開發态、運維态、運行态，那麽在(zài)開發态，API 設計是(shì)先于(yú)服務開發的(de)，因此 API 管理應該在(zài)開發态就(jiù)已經開始記錄和(hé / huò)調試。

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

API 管理可能在(zài)不(bù)同的(de)階段會有不(bù)同的(de)運用，在(zài)開發階段可以(yǐ)幫助開發人(rén)員快速的(de)對 API 進行設計和(hé / huò)調整，在(zài)測試階段方便測試人(rén)員查看 API 的(de)用法，也(yě)更有利于(yú)知識傳遞和(hé / huò)工作交接；在(zài)運行階段，API 的(de)說(shuō)明也(yě)會便于(yú)其他(tā)應用或系統對該服務的(de)調用。

運維态：API 變更

微服務場景下，敏捷是(shì)第一(yī / yì ／yí)要(yào / yāo)務。因此，服務可能會經常升級、變更，也(yě)難免會有 API 的(de)變動和(hé / huò)更改。既然 API 是(shì)微服務間的(de)契約，那麽 API 的(de)變更也(yě)就(jiù)如同契約的(de)變更，将會對所有消費者産生影響。

因此 API 的(de)變更需要(yào / yāo)慎重，變更之(zhī)後也(yě)需要(yào / yāo)做詳細的(de)變更說(shuō)明以(yǐ)供消費者參閱，甚至需要(yào / yāo)有固定的(de)流程審批。

當然這(zhè)裏也(yě)給 API 管理提供了(le／liǎo)一(yī / yì ／yí)個(gè)要(yào / yāo)求，就(jiù)是(shì)要(yào / yāo)支持多版本的(de)管理，以(yǐ)滿足持續集成、持續發布，以(yǐ)及變更的(de)信息。

運行态：API 治理

運行态下，對于(yú) API 的(de)治理算是(shì)細粒度的(de)微服務治理。畢竟微服務化的(de)建設，是(shì)企業服務化中台建設的(de)第一(yī / yì ／yí)步，可不(bù)隻是(shì)調調微服務框架那麽簡單。

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

當然除了(le／liǎo)服務間的(de) API 治理以(yǐ)外，伴随微服務逐漸走進人(rén)們視線的(de) API 網關，更是(shì)對 API 的(de)南北向調用的(de)管理和(hé / huò)控制。API 網關提供 API 的(de)統一(yī / yì ／yí)對外能力輸出(chū)，在(zài)真實環境中，也(yě)不(bù)隻是(shì)對外能力，也(yě)表現在(zài)跨網絡域、兼容異構框架等等方面，但都是(shì)針對 API 粒度的(de)管控和(hé / huò)觀測。

總結

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

當然還未提到(dào)存量的(de)業務系統，因爲(wéi / wèi)非微服務架構提供的(de)接口也(yě)非标準協議，這(zhè)類的(de)系統也(yě)是(shì)以(yǐ) API 接口形式提供，并在(zài)适當的(de)位置做好協議、報文的(de)轉換。存量老舊系統的(de)兼容，将會在(zài)下一(yī / yì ／yí)期文章中做詳細介紹和(hé / huò)分享。