SpringCloud 微服務最佳開發實踐

Posted on by

現在基於SpringCloud的微服務開發日益流行，網上各種開源項目層出不窮。我們在實際工作中可以參考開源項目實現很多開箱即用的功能，但是必須要遵守一定的約定和規范。

本文結合我們實際的開發中遇到的一些問題整理出瞭一份微服務開發的實踐規范，歡迎各位大佬拍磚指點。

Maven規范

1.所有項目必須要有一個統一的parent模塊

所有微服務工程都依賴這個parent，parent用於管理依賴版本，maven倉庫，jar版本的統一升級維護

在parent下層可以有 core，starter，rate-limit 等自定義模塊

2.core 核心包的作用：

  • 以POJO形式約定各種開發規范；如BaseEntity，統一入參，返參
  • 各種二方、三方組件開箱即用AutoConfig；
  • 各種提高開發效率的幫助類等 XXXUtil

註意：core包所有依賴的scope必須是provided，避免傳遞依賴，同時配合Condition註解按條件加載Bean 如 @ConditionalOnClass(Ribbon.class)，@ConditionalOnBean(StringRedisTemplete.class)

3.starter模塊

如果你每個服務都需要依賴10幾個starter，可以建一個統一的starter模塊幫他們統一依賴進來，管理依賴集，簡化依賴

4.rate-limit模塊

用於放置非通用的自開發組件

5.正確區分Release版本 和 Snapshot版本

說明：如果是Snapshot版本，那麼在mvn deploy時會自動發佈到快照版本庫中，而使用快照版本的模塊，在不更改版本號的情況下，直接編譯打包時，Maven會自動從鏡像服務器上下載最新的快照版本。

如果是Release版本，那麼在mvn deploy時會自動發佈到正式版本庫中，而使用正式版本的模塊，在不更改版本號的情況下，編譯打包時如果本地已經存在該版本的模塊則不會主動去鏡像服務器上下載。

簡而言之：

Release : 正式版，有bug不能再繼續使用這個版本號

Snapshot：快照版，有bug可以繼續使用同一版本號，可以自動升級，推薦使用

服務調用

規范服務間通過引入sdk調用，服務消費者需要依賴生產者提供的api，配合snapshot方便升級

account
	account-api
	account-service

account-api 模塊中放消費方需要用到的東西，api接口，vo，入參等…

public interface AccountApi {
    ...
}

account-service實現account-api提供的接口

@RestController
@Log4j2
@Api(tags = "用戶接口")
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class AccountController implements AccountApi {
    ...
}

消費者通過feign調用生產者，直接集成生產者提供的接口並處理熔斷

@Component
@FeignClient(name = "account-service",fallbackFactory = AccountClientFallbackFactory.class)
public interface AccountClient extends AccountApi {
    ...
}

@Component
public class AccountClientFallbackFactory implements FallbackFactory<AccountClient> {

    @Override
    public AccountClient create(Throwable throwable) {
        AccountClientFallback accountClientFallback = new AccountClientFallback();
        accountClientFallback.setCause(throwable);
        return accountClientFallback;
    }

}

@Slf4j
public class AccountClientFallback implements AccountClient {
    @Setter
    private Throwable cause;

    @Override
    public ResultData<AccountDTO> getByCode(String accountCode) {
        log.error("查詢失敗,接口異常" ,cause);
        AccountDTO account = new AccountDTO();
        account.setAccountCode("000");
        account.setAccountName("測試Feign");
        return ResultData.success(account);
    }

}

Restful設計規范

一個 API 是一個開發者的 UI – 就像其他任何 UI 一樣, 確保用戶體驗被認真的考慮過是很重要的！

可以使用以下兩種格式：

  1. /版本/訪問控制/域對象
  2. /版本/訪問控制/域對象/動作

域對象需要遵循以下幾條約束：

  • 域對象 用名詞而非動詞
  • 直接使用域對象名 使用/ticket而不是復數/tickets
  • 域對象關系表達 最大不超過2層，如/ticket/12/message
  • 需要正確區分 GET PUT POST DELETE 請求方法
  • 無法用名詞 + 請求方法表述的可以擴展為 /域對象/動詞 如 POST /user/login

在網關層對接口進行訪問控制，訪問控制的規則分為：

pb – public 所有請求均可訪問

pt – protected 需要進行token認證通過後方可訪問

pv – private 無法通過網關訪問，隻能微服務內部調用

df – default 網關請求token認證，並且請求參數和返回結果進行加解密

版本：

以微服務為力度，整個服務進行升級

例如，一個微服務有如下API

GET /v1/pb/user

POST /v1/pb/user

PUT /v1/pb/user

如果 POST /v1/pb/user 需要升級，則需要將整個微服務 /v1 升級到 /v2，同時保證版本兼容的api老版本可以繼續訪問

GET /v2/pb/user 等價於 GET /v1/pb/user

POST /v1/pb/user 標記為已廢棄

POST /v2/pb/user

PUT /v2/pb/user 等價於 PUT /v1/pb/user

代碼實現：

1.GET方式{version}可以是任意值，v1,v2均可，如：@GetMapping(“/{version}/pb/user”)

2.POST方法強制使用 V1 ,並標記為已廢棄，但是仍可使用

@Deprecated
@PostMapping("/v1/pb/user")

3.POST {version}應是當前版本，隻能是v2

@PostMapping("/{version}/pb/user")

網關

  1. 可以不承擔微服務鑒權功能，由自己服務實現（簡單服務可以直接在網關層鑒權）
  2. 網關鑒權與微服務鑒權的差異在我其他文章中有詳細說明，可參考此文：http://t.hk.uy/2c3
  3. 需要實現訪問控制權限，結合上文的Restful規范，屏蔽/pv/** 等特殊請求
  4. 需要實現灰度發佈功能

開發聯調的時候需要將服務器流量導入到本地，結合nacos的元數據與請求頭可實現服務實例的篩選。參考此文實現：http://t.hk.uy/2c6

到此這篇關於SpringCloud 微服務最佳開發實踐的文章就介紹到這瞭,更多相關SpringCloud 微服務內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：