Triển khai Microservices với Micro Toolkit

Sử dụng Micro cho hệ thống microservices

Microservice đã được nhắc đến ở bài viết trước.

Micro là một microservices toolkit, cung cấp các khối xây dựng cơ bản cho microservices nhằm đơn giản hóa việc phát triển hệ thống phân tán. Nó được xây dựng với các tính năng và giao diện dễ tiếp cận,  cung cấp một kiến trúc pluggable mạnh mẽ, cho phép các thành phần cơ bản có thể đổi chỗ.

Micro tập trung vào giải quyết các yêu cầu cơ bản để xây dựng các services.

Bộ Toolkit

• Go-Micro: là một "pluggable RPC framework" cho phát triển hệ thống phân tán. Nó cung cấp các thư viện để khai báo service, cân bằng tải, mã hóa, đồng bộ,...
• Micro-api là một API gateway phục vụ HTTP và điều phối request đến các service thích hợp. Nó hoạt động như một single-end-point và có thể được sử dụng như một reverse-proxy hoặc chuyển các yêu cầu HTTP sang RPC.
• Micro-web là một giao diện điều khiển các ứng dụng web trong micro.
• Micro-sidecar cung cấp tất cả các tính năng của go-micro như một dịch vụ http. Go-lang là một ngôn ngữ tuyệt vời để xây dựng các dịch vụ microservices, bạn cũng có thể sử dụng các ngôn ngữ khác, bởi Sidecar cung cấp một cách để tích hợp các ứng dụng khác của bạn vào hệ thống Micro.
• Micro-CLI: là các câu lệnh để tương tác với các dịch vụ micro. Nó cũng cho phép tận dụng Sidecar như một proxy, bạn có thể không cần kết nối trực tiếp với các service đăng ký.

Cụ thể hơn - RPC, REST, Proto …

Đầu tiên, tại sao lại là RPC mà không phải REST. RPC là sự lựa chọn thích hợp hơn cho việc giao tiếp giữa các service. Cụ thể hơn thì RPC sử dụng mã hóa protobuf và định nghĩa các API với protobuf IDL. Sự kết hợp này tạo ra các giao diện API mạnh mẽ, mã hóa message hiệu quả.

Google tạo ra protobuf, sử dụng RPC trong nội bộ và mới đây đã đưa ra gRPC, một RPC framework. Hailo cũng ủng hộ mạnh mẽ RPC và sử dụng rất hiệu quả. Uber chọn con đường riêng là phát triển một giao thức khung cho RPC gọi là TChannel.

HTTP to RPC, API ...

Tuy nhiên trong thực tế, còn một quãng đường dài từ RPC đến web. Mặc dù nó hoàn hảo bên trong hệ thống, giao tiếp giữa các service, nhưng khi phục vụ các kết nối khác như website và mobile API, thì lại là câu chuyện khác. Sẽ còn một khoảng thời gian dài nữa để chúng ta tách biệt khỏi HTTP. Đó là lý do tại sao Micro lại bao gồm một API gateway, để phục vụ các yêu cầu HTTP.

API gateway hoạt động như một single-end-point cho phép các yêu cầu bên ngoài gọi đến được với service thích hợp. Đây là một mô hình kiến ​​trúc mạnh mẽ. Đã qua rồi những ngày mà một thay đổi nhỏ trên API của bạn có thể làm hỏng toàn bộ hệ thống nguyên khối.

Micro-API có thể sử dụng đường dẫn đến từng dịch vụ, sao cho mỗi đường dẫn phục vụ các service khác nhau là duy nhất, ví dụ /user => user api, /order => order api.

Các services đã định nghĩa

• API - Được phục vụ bởi micro-api, một API service, phục vụ các giao tiếp công cộng, mobile, ứng dụng web. Có thể xây dựng nó với bộ xử lý HTTP và chạy micro-api trong chế độ reverse-proxy hoặc xử lý định dạng mặc định phản hồi RPC API.
• WEB - Một dịch vụ web tập trung vào phục vụ nội dung html và giao diện điều khiển, reverse proxy và websocket.

• SRV - Services RPC nền tảng, tập trung cung cấp các chức năng cốt lõi cho hệ thống. Bạn vẫn có thể truy cập thông qua api hoặc web bằng cách sử dụng đường dẫn /prc endpoint nếu muốn. Nhưng tốt hơn là API, Web và SRV service sử dụng go-micro client để gọi trực tiếp đến chúng.

Bằng cách thêm tiền tố vào tên dịch vụ để xác định rõ ràng mục đích và vị trí các services trong hệ thống.

Micro api và web sẽ soạn tên service theo tên và phần đầu của request, ví dụ : yêu cầu đến api /customer trở thành go.micro.api.customer.

Tên mặc định như sau:

• API - go.micro.api
• Web - go.micro.web
• SRV - go.micro.srv

Bạn nên đặt chúng vào tên miền của bạn , ví dụ com.example.{api,web,srv}. Micro-api và micro-web có thể được cấu hình trong thời gian chạy để định tuyến tên của bạn.