想要做好微服務(wù)化，這個核心對象要管好
在正文開始之前，我們來看一個日常生活場景，咖啡自動售賣機：
第一排，是四個選項：美式、拿鐵、摩卡、白咖啡；
第二排，單位是ml，代表產(chǎn)出咖啡的量；
第三排，是否加糖；
第四排，是否加奶。
輸入以上這四個參數(shù)后，自動售賣的咖啡機便會按照要求提供所需的咖啡。當(dāng)然售賣機還是會根據(jù)操作者的人臉或掃碼確定其身份信息，做出相應(yīng)的扣款，或是先付款后操作等處理。這就是一臺咖啡機所提供的服務(wù)，機身上提供了操作的說明，根據(jù)提示輸入類型、口味等信息，制造出對應(yīng)的咖啡。
微服務(wù)與 API
咖啡機提供的是生活服務(wù)，而我們一直以來的話題：“微服務(wù)”，則提供的是軟件服務(wù)。一個軟件服務(wù)的使用，需要輸入?yún)?shù)：如第一個參數(shù)代表了類型，第二個參數(shù)代表了返回的數(shù)量，第三個、第四個參數(shù)代表了是否需要加某些規(guī)則；同時也需要身份信息：如報頭加入消費者名稱，加入認證信息等；當(dāng)然還需要有返回，也就是計算或者處理的結(jié)果返回。這就是軟件服務(wù)提供的能力，也是軟件服務(wù)的API。
在微服務(wù)的架構(gòu)提出之前，行業(yè)內(nèi)首先提出的是服務(wù)化，畢竟服務(wù)能力的封裝、自運行，可比自己編碼實現(xiàn)要快捷、低廉很多。在服務(wù)化的基礎(chǔ)上才有了微服務(wù)，微服務(wù)就是其基于服務(wù)化將應(yīng)用程序構(gòu)造為一組松散耦合的服務(wù)。
因此，微服務(wù)基于 API 作為服務(wù)能力的提供，也是服務(wù)間消費的規(guī)則和方式。信息標(biāo)識認證的方式、參數(shù)傳遞的類型，格式返回的方式，這都是API定義的。
API
API 的定義是應(yīng)用程序編程接口，而在服務(wù)化的場景中，API 是應(yīng)用程序間的訪問接口，即服務(wù)提供的行為合同。那么在微服務(wù)的場景中，API就是微服務(wù)間獲取信息的契約。
微服務(wù)架構(gòu)中服務(wù)間調(diào)用關(guān)系錯綜復(fù)雜，程序提供的服務(wù)能力可以被其他任意服務(wù)消費和使用，這也是建設(shè)微服務(wù)的一個優(yōu)勢。服務(wù)能力的復(fù)用，可以在某個業(yè)務(wù)領(lǐng)域內(nèi)被消費，也可以被網(wǎng)絡(luò)區(qū)域外的服務(wù)所依賴，也可以是整體企業(yè)對外的能力開放，其本質(zhì)歸根結(jié)底都是 API 的調(diào)用。
當(dāng)然，還有調(diào)用中的信息認證，調(diào)用允許/拒絕的控制，應(yīng)對大流量時限流控制，熔斷控制，批處理方式等等，全都是 API 管理內(nèi)容。有了這么細則的控制，對于 API 的監(jiān)控也尤為重要，因為很多控制的數(shù)據(jù)皆是從監(jiān)控記錄而來。
因此，API 才是微服務(wù)化建設(shè)中最為核心的管理對象，而且從整體微服務(wù)化建設(shè)的角度出發(fā)，在開發(fā)態(tài)、運維態(tài)、運行態(tài)均需要關(guān)注對 API 的管理。
開發(fā)態(tài)：API 管理
之前提過微服務(wù)的建設(shè)，從橫向上看，跨越微服務(wù)的開發(fā)態(tài)、運維態(tài)、運行態(tài)，那么在開發(fā)態(tài)，API 設(shè)計是先于服務(wù)開發(fā)的，因此 API 管理應(yīng)該在開發(fā)態(tài)就已經(jīng)開始記錄和調(diào)試。
API 包括請求方法（GET、POST等）、請求參數(shù)（請求頭、請求體）、響應(yīng)內(nèi)容等信息，對于 API 接口文檔的管理，應(yīng)該是當(dāng)做微服務(wù)間調(diào)用的契約，在服務(wù)調(diào)用中，指導(dǎo)消費服務(wù)的使用。
API 管理可能在不同的階段會有不同的運用，在開發(fā)階段可以幫助開發(fā)人員快速的對 API 進行設(shè)計和調(diào)整，在測試階段方便測試人員查看 API 的用法，也更有利于知識傳遞和工作交接；在運行階段，API 的說明也會便于其他應(yīng)用或系統(tǒng)對該服務(wù)的調(diào)用。
運維態(tài)：API 變更
微服務(wù)場景下，敏捷是第一要務(wù)。因此，服務(wù)可能會經(jīng)常升級、變更，也難免會有 API 的變動和更改。既然 API 是微服務(wù)間的契約，那么 API 的變更也就如同契約的變更，將會對所有消費者產(chǎn)生影響。
因此 API 的變更需要慎重，變更之后也需要做詳細的變更說明以供消費者參閱，甚至需要有固定的流程審批。
當(dāng)然這里也給 API 管理提供了一個要求，就是要支持多版本的管理，以滿足持續(xù)集成、持續(xù)發(fā)布，以及變更的信息。
運行態(tài)：API 治理
運行態(tài)下，對于 API 的治理算是細粒度的微服務(wù)治理。畢竟微服務(wù)化的建設(shè)，是企業(yè)服務(wù)化中臺建設(shè)的第一步，可不只是調(diào)調(diào)微服務(wù)框架那么簡單。
未來在服務(wù)化中臺中，服務(wù)能力均以 API 的方式提供，所有的管理粒度都是 API 接口。因此，對于 API 的治理，才是微服務(wù)治理的重點，如 API 粒度的訪問控制，API粒度的限流、降級、熔斷，API 級別的性能監(jiān)控信息，API 的調(diào)用依賴關(guān)系。API 的鏈路節(jié)點信息等等。
當(dāng)然除了服務(wù)間的 API 治理以外，伴隨微服務(wù)逐漸走進人們視線的 API 網(wǎng)關(guān)，更是對 API 的南北向調(diào)用的管理和控制。API 網(wǎng)關(guān)提供 API 的統(tǒng)一對外能力輸出，在真實環(huán)境中，也不只是對外能力，也表現(xiàn)在跨網(wǎng)絡(luò)域、兼容異構(gòu)框架等等方面，但都是針對 API 粒度的管控和觀測。
總結(jié)
微服務(wù)的建設(shè)其管理的核心對象是比服務(wù)更細粒度的 API，管理內(nèi)容包括 API 接口信息的管理，變更的影響，運行的監(jiān)控，以及流量控制等各個方面。
當(dāng)然還未提到存量的業(yè)務(wù)系統(tǒng)，因為非微服務(wù)架構(gòu)提供的接口也非標(biāo)準(zhǔn)協(xié)議，這類的系統(tǒng)也是以 API 接口形式提供，并在適當(dāng)?shù)奈恢米龊脜f(xié)議、報文的轉(zhuǎn)換。存量老舊系統(tǒng)的兼容，將會在下一期文章中做詳細介紹和分享。