服務提供者如何釋出一個服務？
服務消費者如何引用這個服務？
具體來說，就是這個服務的接口名是什麼？
調用這個服務需要傳遞哪些參數？
接口的傳回值是什麼類型？
RESTful API
首先來說說RESTful API的方式，主要被用作HTTP或者HTTPS協定的接口定義，即使在非微服務架構體系下，也被廣泛采用。
以開源服務化架構Motan釋出RESTful API為例釋出三個RESTful格式的API聲明
具體的服務實作如下：
服務提供者這一端通過部署代碼到Tomcat中，并配置Tomcat中如下的web.xml，就可以通過servlet的方式對外提供RESTful API。
這樣服務消費者就可以通過HTTP協定調用服務了，因為HTTP協定本身是一個公開的協定，對于服務消費者來說幾乎沒有學習成本，是以比較适合用作跨業務平台之間的服務協定。比如你有一個服務，不僅需要在業務部門内部提供服務，還需要向其他業務部門提供服務，甚至開放給外網提供服務，這時候采用HTTP協定就比較合适，也省去了溝通服務協定的成本。
XML配置
主要三步：
服務提供者定義接口，并實作接口
服務提供者程序啟動時，通過加載server.xml配置檔案将接口暴露出去，開啟8002端口監聽。
服務消費者程序啟動時，通過加載client.xml配置檔案來引入要調用的接口
服務消費者要想調用服務，就必須在程序啟動時，加載配置client.xml，引用接口定義，然後發起調用。
client.xml
服務消費者啟動時，加載client.xml
就這樣，通過在服務提供者和服務消費者之間維持一份對等的XML配置檔案，來保證服務消費者按照服務提供者的約定來進行服務調用。在這種方式下，如果服務提供者變更了接口定義，不僅需要更新服務提供者加載的接口描述檔案server.xml，還需要同時更新服務消費者加載的接口描述檔案client.xml。
一般是私有RPC架構會選擇XML配置描述接口，因為私有RPC協定的性能要比HTTP協定高，是以在對性能要求比較高的場景下，采用XML配置的方式比較合适。
但這種方式對業務代碼侵入性比較高，XML配置有變更的時候，服務消費者和服務提供者都要更新，是以适合公司内部聯系比較緊密的業務之間采用。如果要應用到跨部門之間的業務調用，一旦有XML配置變更，需要花費大量精力去協調不同部門做更新工作。
在我經曆的實際項目裡，就遇到過一次底層服務的接口更新，需要所有相關的調用方都更新。是以對于XML配置方式的服務描述，一旦應用到多個部門之間的接口格式約定，如果有變更，最好是新增接口，不到萬不得已不要對原有的接口格式做變更。