基于CSE的微服務工程實踐-Native API先行

[Open API]( https://swagger.io/docs/specification/about/) 采用Swagger進行描述，能夠靈活的支持RPC風格和REST風格的接口定義，并且考慮了跨平臺接口定義要求。使用Swagger進行接口開發代碼，需要熟悉這個規范，并理解和代碼邏輯之間的約束關系，對于一些初步接觸的設計人員來講，這個過程會比較痛苦。 在不寫Swagger的情況下，CSE推薦設計者可以先結合自己熟悉的開發語言，使用接口的方式定義RPC或者REST接口。本文以JAVA語言為例，描述設計者如何定義接口。

微服務架構下，所有微服務之間都通過暴露REST接口進行訪問。從管理/設計者的視角，通常期望系統的邊界清晰，規格可控，因此接口的開發是獨立受控的。早期JAVA標準，比如JSR Validation API等，都通過API包的方式供實現者使用。借鑒這個思路，設計者在設計微服務的時候，也可以將微服務的接口在獨立的jar包項目中提供，實現者應用這個jar包即可。

使用CSE設計公共的接口，建議設計者提供兩個類：

·???????? Service: 一個JAVA接口，這個接口可以由開發者實現。

·???????? Endpoint: 接口的REST描述。

舉個例子，Service定義了開發者如何實現這個服務，開發者可以看不到REST標簽，不用思考和HTTP的映射關系。

public?interface?UserService?{ ??public?SessionInfo?login(String?userName, ??????String?password); ? ??public?SessionInfo?getSession(String?sessionId); ? ??public?String?ping(String?message); }

Endpoint定義這個服務對外暴露的REST接口，可以采用Spring MVC或者JAX RS兩種方式進行描述。Endpoint是一個具體實現類，但是其實現邏輯，全部代理給Service的實現。

@RestSchema(schemaId?=?"user") @RequestMapping(path?=?"/") @SwaggerDefinition(info?=?@Info(description?=?"用戶認證、會話等管理",?title?=?"用戶管理接口",?version?=?"v1"),?basePath?=?"/") public?class?UserEndpoint?{ ??@Autowired ??private?UserService?userService; ? ??@PostMapping(path?=?"/v1/user/login",?produces?=?MediaType.APPLICATION_JSON_VALUE) ??@ApiOperation(value?=?"登錄") ??public?SessionInfo?login(@RequestParam(name?=?"userName")?String?userName, ??????@RequestParam(name?=?"password")?String?password)?{ ????return?userService.login(userName,?password); ??} ? ??@GetMapping(path?=?"/v1/user/session",?produces?=?MediaType.APPLICATION_JSON_VALUE) ??@ApiOperation(value?=?"查詢會話") ??public?SessionInfo?getSession(@RequestParam(name?=?"sessionId")?String?sessionId)?{ ????return?userService.getSession(sessionId); ??} ? ??@GetMapping(path?=?"/v1/user/ping",?produces?=?MediaType.APPLICATION_JSON_VALUE) ??@ApiOperation(value?=?"系統測試接口") ??public?String?ping(@RequestParam(name?=?"message")?String?message)?{ ????return?userService.ping(message); ??} }

[porter例子]( https://github.com/huaweicse/cse-java-chassis-samples/tree/master/porter ) ?展現了這個設計思路。

接口定義的一些注意事項和討論

上訴方式是在實踐中探索的一種比較好的接口組織形式，當然可以有其他各種形式。比較常見的辯論形式有直接定義Endpoint接口，所有的標簽寫到Endpoint上，開發者只需要實現Endpoint即可。這種形式看起來更加的簡潔，但是CSE沒有提供這種開發方式的支持，即REST的標簽必須在實現類上，不能出現在實現類的父類或者實現接口上。CSE考慮過是否提供這種開發模式的支持，后面放棄了。主要的原因是因為JAVA在語言機制上，并沒有提供annotation的繼承機制（class的annotation可以通過@Inherited繼承，但是Method沒有）。當然通過反射遍歷也是可以獲取到父類的annotation的，把技術建立在一個不可靠的技術基礎上，會帶來大量的問題。當然放棄這種模式還有其他原因，關于是否共享Interface供服務實現者實現和客戶端開發引用存在大量的爭論，感興趣的開發者可以搜索網絡，查詢這方面的設計討論。

注意事項

由于@RestSchema也是一個bean，在所有微服務的接口定義都在一個common jar包里面時，要避免一個微服務加載所有的bean。所以需要把不同服務的定義放到不同的package里面，通過ComponentScan控制加載范圍或者創建不同的jar包，完全不引用。

API網關 APIG CSE 契約

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。