Thiết kế dịch vụ vi mô hướng mục đích

Buzzwords không phải là điều tôi mong đợi khi bắt đầu sự nghiệp của mình. Vào những ngày đó, hầu hết các tin tức công nghệ đều được xuất bản hàng tuần trên báo giấy như InformationWeek và Network World. Tôi nhớ mình đã tự nghĩ: “Trời ạ, họ dùng những từ này lặp đi lặp lại mỗi tuần.”

Điều đó được dịch cho những người sử dụng từ thông dụng ... mọi lúc. Hồi đó, hai từ thông dụng yêu thích của tôi là tham chiếu đến internet là “web trên toàn thế giới” và “siêu xa lộ thông tin”. Tôi luôn tự hỏi liệu có một lúc nào đó sẽ có một con đường siêu cao tốc.

Tuy nhiên, gần đây, tôi nhận thấy rằng từ thông dụng được sử dụng làm trình giữ chỗ mà chúng không hoàn toàn hợp lý. Các thuật ngữ như microservices, kiến trúc hướng sự kiện, AI và ML được sử dụng trong các ngữ cảnh khiến tôi kết luận rằng nhiều người không hiểu rõ về các thuật ngữ này. Tôi cũng không mong đợi điều này…

Hãy tưởng tượng cuộc trò chuyện đơn giản này liên quan đến một câu hỏi bị hiểu nhầm:

Người số 1: Chuyến bay của bạn khởi hành lúc mấy giờ?

Người số 2: Cuối năm nay.

Mặc dù Người số 2 cung cấp một câu trả lời không chính xác, nhưng câu trả lời không thực sự mang lại bất kỳ giá trị nào cho câu hỏi của Người số 1.

Cùng đường đó, nhiệm vụ chuyển sang microservices cũng gặp phải những thách thức tương tự. Thường xuyên hơn không, tôi đã làm việc với các khách hàng và tập đoàn có thiết kế "microservice" dẫn đến một dịch vụ đơn lẻ. Về cơ bản, một ứng dụng nguyên khối đã được thay thế bằng một API RESTful thực sự lớn.

Đối với ấn phẩm này, tôi nghĩ sẽ rất thú vị khi xem qua một ví dụ về việc tạo ra một thiết kế microservice có mục đích… đúng cách.

Thiết kế Microservice hướng tới Mục đích

Một microservice hướng theo mục đích là một dịch vụ có thể tự đứng vững và nó có thể bao gồm một kho lưu trữ liên tục chuyên dụng khi được yêu cầu. Bằng cách hoạt động theo mục đích, microservice sẽ cung cấp một tập hợp thông tin tập trung và là hệ thống hồ sơ cho dữ liệu được điều chỉnh trong các API được liên kết.

Bằng cách áp dụng phương pháp tiếp cận dịch vụ vi mô theo mục đích, người dùng có thể thêm các nút bổ sung và thu nhỏ các nút hiện có để đáp ứng nhu cầu của API cho thời điểm đó.

Ví dụ: một dịch vụ vi mô có mục đích tập trung vào khía cạnh thuế thu nhập có thể có mức sử dụng cao nhất trong phần đầu của năm và yêu cầu ít trường hợp chạy hơn trong nửa sau.

Hãy tập trung vào việc tạo ra một thiết kế microservice theo mục đích sử dụng một ví dụ rất đơn giản.

Tạo một dịch vụ nhỏ dựa trên Docker

Các Dự đoán giới tính Trung Quốc là một hệ thống lưới được sử dụng để dự báo giới tính của trẻ sơ sinh. Điều này được thực hiện bằng cách cung cấp tháng thụ thai và tuổi hiện tại của người mẹ tại thời điểm thụ thai.

Có tin đồn rằng hoàng gia triều Thanh đã dựa vào mạng lưới này để lựa chọn giới tính của những người con trai, những người được ưu ái cho công việc và tiền bạc mà họ có thể cung cấp cho gia đình cũng như để tiếp nối dòng họ.

Dưới đây là minh họa về lưới Dự đoán Giới tính của Trung Quốc:

Ví dụ, một bà mẹ 18 tuổi thụ thai vào tháng Giêng sẽ sinh ra một bé gái.

Đối với ấn phẩm này, chúng tôi sẽ tạo một microservice có mục đích trả về dự đoán giới tính dựa trên cùng tiêu chí. Tải trọng kết quả cho ví dụ trên sẽ xuất hiện như hình dưới đây:

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

Microservice sẽ sử dụng Java và Spring Boot và sẽ sử dụng Dockerfile nhiều giai đoạn để biên dịch dịch vụ và xây dựng hình ảnh Docker có thể lưu trữ các API dự đoán sinh.

Bạn có thể tìm thấy mã cho dịch vụ trên GitLab tại địa chỉ sau:

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

Tạo một mẫu có thể tái tạo bằng cách sử dụng bản thiết kế kết xuất

Tôi đã viết về __ Render __platform trong các ấn phẩm sau:

• Dành thời gian bằng 0 cho DevOps với Render PaaS
• Đám mây hoàn hảo: AWS, GCP và Azure tất cả trong một

Đối với các phiên bản cá nhân của tôi đang chạy trên Render, tôi đã sử dụng ngôn ngữ lập trình Go, các trang web tĩnh và một phiên bản Postgres. Lần này, tôi đã viết dịch vụ bằng Java / Spring Boot. Mặc dù hỗ trợ riêng cho Java chưa tồn tại, nhưng nền tảng Render bao gồm hỗ trợ cho bất kỳ thứ gì đang chạy trong vùng chứa Docker.

Vì dịch vụ dự đoán sinh bao gồm Dockerfile nhiều giai đoạn, tôi muốn xem việc triển khai dịch vụ dựa trên Docker trên nền tảng Render dễ dàng như thế nào. Tuy nhiên, tôi nhận thấy Đặc điểm kỹ thuật chi tiết và cũng muốn xem nó hoạt động như thế nào.

Kế hoạch chi tiết là gì?

Kế hoạch chi tiết là việc thực hiện Cơ sở hạ tầng dưới dạng mã (IaC) của Render. IaC cũng là thứ mà tôi nhóm thành một khái niệm lớn hơn được gọi là “* as Code”. Các tổ chức cần quản lý việc triển khai một số dịch vụ hoặc có các dịch vụ yêu cầu nhiều tùy chọn có thể xác định cơ sở hạ tầng Render của họ (dịch vụ, cơ sở dữ liệu và nhóm môi trường) dưới dạng mã trong tệp render.yaml.

Sử dụng Render Blueprint

Xây dựng dựa trên ví dụ Blueprint được cung cấp nơi đây , Tôi đã có thể nhanh chóng tạo Blueprint cho các dịch vụ Spring Boot của mình đang chạy qua vùng chứa Docker:

 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

Từ đó, tôi đã tùy chỉnh dữ liệu YAML cho dịch vụ dự đoán sinh để cập nhật thuộc tính tên và thêm thuộc tính repo, như đã lưu ý bên dưới:

 services: - type: web name: birth-predictor env: docker repo: https://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

Thông tin này được lưu trữ trong thư mục gốc của kho lưu trữ birth-predictor , trong một tệp có tên là render.yaml . Sau khi cam kết và hợp nhất thay đổi này, dịch vụ đã sẵn sàng để triển khai trên nền tảng Render.

Từ Render Dashboard, tôi đã chọn New | Tùy chọn kế hoạch chi tiết :

Tiếp theo, tôi đã chọn kho lưu trữ dự đoán sinh mà tôi đã kết nối với tài khoản GitLab của mình bằng cách sử dụng các hướng dẫn được tìm thấy nơi đây .

Vì tôi đang sử dụng Blueprint, tất cả những gì tôi phải làm là cung cấp tên nhóm dịch vụ cho dịch vụ mới của mình:

Sau khi nhấn nút Áp dụng , quá trình triển khai bắt đầu:

Một vài phút sau, dịch vụ đã được triển khai mà không gặp bất kỳ sự cố nào:

Dự đoán sinh trong hành động

Với dịch vụ dự đoán sinh đang chạy, tôi có thể đưa ra lệnh cURL sau để nhận dự đoán mới:

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

Tải trọng phản hồi kết quả trông giống như sau:

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

Thông tin này trùng khớp với tháng thụ thai và tuổi của vợ tôi vào thời điểm con trai chúng tôi (Finny) được thụ thai. Vào tháng 8 năm 2017, anh ấy đã đến!

Giống như họ đã làm trong thời nhà Thanh, chúng ta có thể dựa vào Dự đoán Giới tính của Trung Quốc để dự báo thành công giới tính của con mình.

Sự kết luận

Kể từ năm 2021, tôi đã cố gắng sống theo tuyên bố sứ mệnh sau đây mà tôi cảm thấy có thể áp dụng cho bất kỳ chuyên gia CNTT nào:

“Tập trung thời gian của bạn vào việc cung cấp các tính năng / chức năng giúp mở rộng giá trị tài sản trí tuệ của bạn. Tận dụng các khuôn khổ, sản phẩm và dịch vụ cho mọi thứ khác ”.

- J. Vester

Đặc tả Blueprints của Render tuân thủ tuyên bố sứ mệnh của tôi bằng cách cho phép các nhóm tính năng và dịch vụ tập trung vào việc thực hiện các mục tiêu và mục tiêu đã thiết lập mà không cần lo lắng về bất kỳ điều gì liên quan đến DevOps.

Khi dịch vụ, thành phần hoặc ứng dụng đã sẵn sàng, các nhóm chỉ cần đưa tệp render.yaml vào thư mục gốc của kho lưu trữ của họ, sau đó tạo một dịch vụ mới trên nền tảng Render bằng cách sử dụng tùy chọn Blueprint. Trong tương lai, bất kỳ bản cập nhật nào đối với kho lưu trữ được kết nối sẽ tự động triển khai vài phút sau khi cam kết mã cho nhánh được lưu ý.

Nền tảng Render tồn tại bởi tâm lý Zero DevOps, điều này thể hiện rõ ràng trong nguồn gốc của khái niệm Blueprint. Các nhà phát triển tính năng và dịch vụ muốn — và nên — tập trung vào việc cung cấp các bản cập nhật và chức năng cung cấp giá trị nhất cho các bên liên quan của họ. Render thực sự hiểu thực tế này.

Tôi chắc chắn rằng từ thông dụng sẽ luôn là một phần của không gian công nghệ. Tuy nhiên, hiểu và áp dụng ý định thực sự đằng sau những từ thông dụng đó là điều mà tôi hy vọng các nhà công nghệ sẽ theo đuổi.

Nếu bạn quan tâm đến mã nguồn của ấn phẩm này, bạn có thể tìm thấy nó trên GitLab tại địa chỉ sau:

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

Có một ngày thực sự tuyệt vời!