目的驅動的微服務設計

建立目的驅動的微服務應該始終是一個目標。瞭解Render Blueprints如何提供可重複的微服務策略。

在我開始職業生涯的時候，流行語並不是我所期待的東西。在那些日子裡，大部分的技術新聞都是在紙質的週刊上釋出的，比如《資訊週刊》和《網路世界》。我記得我在想，"夥計，他們每週都在重複使用這些相同的詞"。

這就意味著人們一直在使用流行語......。那時，我最喜歡的兩個流行語是把網際網路稱為 "全球資訊網 "和 "資訊高速路"。我一直在想，是否在某個時候會有一條超級大高速公路。

然而，最近，我注意到流行語被用作不完全有意義的地方的佔位符。像微服務、事件驅動架構、人工智慧和ML這樣的術語被用在一些場合，這讓我得出結論，許多人並不完全理解這些術語。我也沒有想到會這樣......

想象一下與一個被誤解的問題有關的這個簡單對話：

1號人物：你的航班什麼時候起飛？

2號人:今年晚些時候。

雖然2號人物提供了一個並不錯誤的答案，但這個回答對1號人物的詢問並沒有真正產生任何價值。

按照同樣的思路，在尋求向微服務遷移的過程中也經歷了類似的挑戰。我經常與客戶和公司合作，他們的 "微服務 "設計導致了單一的單體服務。基本上，一個單體應用被替換成了一個真正大的RESTful API。

在本出版物中，我認為通過一個建立目的驅動的微服務設計的例子會很有趣......正確的方法。

目的驅動的微服務設計

目的驅動的微服務是一個可以獨立存在的服務，它可以在需要時包括一個專門的永續性儲存。通過目的驅動，微服務將提供一套集中的資訊，併成為相關API中管理的資料的記錄系統。

通過採用目的驅動的微服務方法，使用者可以增加額外的節點和縮小現有的節點，以滿足該時間點的API的需求。

舉例來說，一個專注於所得稅某一方面的目的驅動的微服務可能會在一年的上半年看到最高的使用率，而在下半年則需要較少的例項執行。

讓我們通過一個非常簡單的例子來關注目的驅動型微服務設計的建立。

建立一個基於Docker的微服務

中國的性別預測器是一個網格系統，用於預測嬰兒出生時的性別。這是通過提供受孕月份和母親受孕時的當前年齡來實現的。

據傳聞，清朝皇室也是依靠這種網格來選擇兒子的性別，因為他們可以為家庭提供工作和金錢，也可以繼承家族的血統，所以受到青睞。

下面是中國性別預測網的插圖。

舉例來說，一個18歲的母親在1月懷上孩子，會生出一個女嬰。

對於這個出版物，我們將建立一個目的驅動的微服務，根據相同的標準返回性別預測。上述例子的結果有效載荷將如下所示。

JSON

{ "month": 1, "age": 18, "gender": "female", "errorMessage": null }

該微服務將利用Java和Spring Boot，並將採用一個多階段的Dockerfile來編譯該服務，並建立一個可以承載出生預測器API的Docker映象。

該服務的程式碼可以在GitLab上找到，地址如下:

http://gitlab.com/johnjvester/birth-predictor

使用Render Blueprints建立可複製的模式

我在以下出版物中寫過關於Render平臺的文章:

• 初次使用Render和Go

• 引擎蓋下：Render統一雲

對於我在Render上執行的個人例項，我使用了Go程式語言、靜態網站和一個Postgres例項。這一次，我用Java/Spring Boot編寫服務。雖然對Java的本地支援還不存在，但Render平臺確實包括對任何在Docker容器中執行的東西的支援。

由於出生預測器服務包括一個多階段的Docker檔案，我想看看在Render平臺上部署一個基於Docker的服務有多容易。然而，我注意到藍圖（Blueprint）規範，也想看看它是如何運作的。

什麼是 "藍圖"？

藍圖是Render對基礎設施即程式碼（IaC）的實現。IaC也是我將其歸入一個更大的概念，稱為 "*為程式碼"。需要管理幾個服務的部署，或者有需要很多選項的服務的組織，可以在render.yaml檔案中把他們的Render基礎設施（服務、資料庫和環境組）定義為程式碼。

使用Render Blueprint

在這裡提供的藍圖例子的基礎上，我能夠為我的通過Docker容器執行的Spring Boot服務快速建立一個藍圖。

渲染藍圖(YAML)

services: - type: web name: restful-api-spring-boot env: docker region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443

在這裡，我為出生預測器服務定製了YAML資料，以更新名稱屬性並新增repo屬性，如下所述:

YAML

services: - type: web name: birth-predictor env: docker repo: http://gitlab.com/johnjvester/birth-predictor region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443

這些資訊被儲存在birth-predictor 倉庫的根部，在一個名為render.yaml 的檔案中。在提交和合並這一變化後，該服務已準備好在Render平臺上部署。

在Render儀表板上，我選擇了 "新建|藍圖"選項。

接下來，我選擇了birth-predictor 倉庫，用這裡的說明將其連線到我的GitLab賬戶。

由於我使用的是藍圖，我所要做的就是為我的新服務提供一個服務組名稱。

按下 "應用"按鈕後，部署過程開始了。

幾分鐘後，該服務被部署，沒有任何問題。

執行中的出生預測器

隨著出生預測器服務的執行，我可以發出以下cURL命令來獲得新的預測結果。

JSON

curl --location --request POST 'http://birth-predictor.onrender.com/predict' \ --header 'Content-Type: application/json' \ --data-raw '{ "conceptionMonth" : 11, "conceptionAge" : 43 }'

由此產生的響應有效載荷看起來像這樣。

JSON

{ "month": 11, "age": 43, "gender": "male", "errorMessage": null }

這些資訊恰好與我們的兒子（Finny）受孕時的受孕月份和我妻子的年齡相符。2017年8月，他來到了!

就像他們在清朝時一樣，我們能夠依靠中國的性別預測器成功地預測出我們孩子的性別。

結論

自2021年以來，我一直在努力遵循以下使命宣言，我覺得它可以適用於任何IT專業人士:

"把你的時間集中在提供特性/功能上，以擴大你的智慧財產權的價值。充分利用框架、產品和服務來處理其他事情。

- J. Vester

Render公司的藍圖規範堅持了我的使命宣言，允許功能和服務團隊專注於按照既定的目標和指標進行交付，而不用擔心任何與DevOps有關的事情。

一旦服務、元件或應用程式準備好了，團隊只需要在他們的資源庫的根中包含render.yaml檔案，然後使用藍圖選項在Render平臺上建立一個新的服務。今後，任何對連線倉庫的更新都會在提交程式碼到指定分支後幾分鐘自動部署。

Render平臺以 "零開發 "的心態生存，這在 "藍圖 "概念的起源中是很明顯的。功能和服務開發者希望--而且應該--專注於提供更新和功能，為他們的利益相關者提供最大的價值。Render真正理解這一現實。

我確信，流行語將永遠是技術領域的一部分。然而，理解和採用這些流行語背後的真正意圖，是我希望技術專家能夠追求的。