前言:

 

 

 

 

 

 

 

 

 

 

 

 

Docker, Vagrant 幫助我們能打造出如圖中的持續交付的 「價值流」:

  • Docker, Vagrant 使得開發人員在開發的階段, 就能在 Production-like 的環境上進行更可信、更有效的契約測試 (Contract Test)。也就是說, 開發人員在開發的階段, 就能藉由在 Production-like 環境上契約測試的結果, 確定自身所新增、修改的代碼是否會對既有的系統、其他的開發人員的代碼造成影響?
  • Docker, Vagrant 使得測試人員能在 Production-like 的藍線環境上, 進行更貼近實際運維環境下的集成測試、失敗測試 (Monkey Test)、A/B Test。使得 Release Management Team 能更加的確定所發布的版本的質量與對用戶的價值。

所以, 我們是不是只要擁有了如上圖的持續交付的 「價值流」, 就能保證我們能按照外部用戶的訴求, 快速的交付, 甚至是能做到按需的交付?

當然不是。

我們還有其他的 「功課」 必需要去做; 就像不是將高速公路給建好了, 就能保證不會堵車。

本文:

我們要能按照外部用戶的訴求, 快速的交付, 甚至是能做到按需的交付, 擁有能持續交付的 「價值流」 是很關鍵且重要的第一步。

在這很關鍵且重要的第一步的基礎之上, 我們還必需要能做到:

1. 分析出能獨立發布、獨立部署的業務流(業務場景)

 

 

 

 

 

 

 

 

 

 

2. 由每個獨立發布、獨立部署的業務流 (業務場景) 所形成的 微服務」 ,其內部代碼的實踐要能遵循 「Clean Architecture」 的原則; 以 洋蔥式的架構做好 代碼的隔離

 

 

 

 

 

 

 

 

 

3. 團隊成員間可高效的協作。

 

 

 

 

 

 

 

 

 

上述的這三件事, 我們都早已清楚是必需要去做的。

但, 問題是: 我們是需要花費大量的時間先去學習些方法論; 如: 領域驅動設計, Use Case…等等; 才能做得到? 還是我們能有一輕量級、可視化的 「工具」,  就可以幫助我們省時、高效的完成?

事實上, 我們只要藉由 「卡片」; 輕量級、可視化的 「Cloud-Native 元素卡」 ;就能省時、高效的做得到。

Cloud-Native 元素卡總共區分為:

  • Cloud-Native 微服務設計元素卡: 輕量級、可視化的 卡片」, 協助我們能高效、有趣的完成微服務粒度(邊界) 的界定、Restful API 設計、Event 架構的設計。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Cloud-Native 微服務開發元素卡可視化、輕量級的卡片」, 承載著 Persistence Layer ( 使得微服務在讀、寫不同的資料庫時; : MySQL, MongoDB, SqlLite, PostgreSQL; 都有一統一的介面) gRPCRestful API 的樣例實踐代碼。所以, 不僅可以協助我們能更快、更輕鬆的開發微服務, 更能在團隊里建立起 洋蔥式架構的開發規範。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Cloud-Native 微服務架構元素卡輕量級可視化的 卡片」, 使得我們在產品的任一版本遷移至微服務的架構時, 都能高效的找到最 適合的微服務架構方案。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

結論:

Cloud-Native 元素卡使得我們:

  • 能省去學習難懂又費時的方法論。但是, 依舊是有 「規範」 的:
    • 從外部的視角, 界定可獨立發布、可獨立部署的微服務粒度。
    • 遵循著 「Clean Architecture」 的原則, 做好微服務內部開發代碼的隔離。
  • 可根據團隊、產品的現況, 加入適合團隊、適合產品的元素卡。使得團隊可永續的積累著, 可使團隊高效開發微服務的優秀實踐、架構方案、開發模式。
  • 輕量級、可視化的 “卡片” 使得團隊的產品經理、架構師、開發人員、測試人員都可更易於互相的溝通、交流、協作。而可更高效、更準確的打造出能快速響應外部變化的 Cloud-Native 微服務。

後續我將會從 Cloud-Native 元素卡出發, 持續的探討 Cloud-Native 微服務開發。我也會再加入其他的Cloud-Native 元素卡; 如: Event Sourcing, CQRS, Security, Contract Test, DevOps…等等。

期待著你的持續的關注。

 

請參考:

Cloud-Native 微服務設計元素卡

Cloud-Native 微服務開發元素卡

Cloud-Native 微服務架構元素卡

 

 

發表評論

您的電子郵箱地址不會被公開。 必填項已用*標註

此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據