Kiến trúc hệ thống của SOML

Chương 2. Xây dựng ứng dụng SOML trên microservices

2.2. Mô hình hoá các micoservice trong SOML

2.2.3. Kiến trúc hệ thống của SOML

Kiến trúc hệ thống của SOML gồm có một cổng API và bốn microservice:

Users service, Stories service, Photos service và Comments service. Mỗi microservice này có một API, một cơ sở dữ liệu và các thành phần được cài đặt để thưc hiện chức năng của microservice. Các microservice trong SOML giao tiếp với nhau bằng kỹ thuật tương tác IPC (Inter-Process communication) sử dụng giao thức HTTP dựa trên REST (Hình 2.10).

5https://aws.amazon.com/what-is-aws/

(LUAN.van.THAC.si).phat.trien.phan.mem.dua.tren.microservices(LUAN.van.THAC.si).phat.trien.phan.mem.dua.tren.microservices(LUAN.van.THAC.si).phat.trien.phan.mem.dua.tren.microservices(LUAN.van.THAC.si).phat.trien.phan.mem.dua.tren.microservices(LUAN.van.THAC.si).phat.trien.phan.mem.dua.tren.microservices(LUAN.van.THAC.si).phat.trien.phan.mem.dua.tren.microservices(LUAN.van.THAC.si).phat.trien.phan.mem.dua.tren.microservices(LUAN.van.THAC.si).phat.trien.phan.mem.dua.tren.microservices

Hình 2.10.Kiến trúc hệ thống của SOML

Mỗi microservice trong SOML đều có một API để có thể giao tiếp với nhau.

Để tạo ra API cho mỗi microservice, ta phải đảm bảo được ba phần chính sau:

 Phải định nghĩa và mô tả được microservice mà ta muốn viết API. Các thông tin này sẽ được lưu trong file interface.idl cho mỗi microservice.

Ví dụ trong SOML, file interface.idl dùng để mô tả các thông tin của microservice Users service sẽ như sau:

struct UserProperties {

name string

email string

password string

password_confirmation string

description string

}

struct User extends UserProperties { id int

}

interface UserService {

create_user(properties UserProperties) User update_user(properties UserProperties) User delete_user(properties UserProperties) User get_all_users() []User

}

Trong đó cấu trúc UserProperties{} sẽ mô tả các cột trong cơ sở dữ liệu của mỗi tài khoản người dùng và kiểu dữ liệu để lưu trữ chúng.

Cấu trúc User{}dùng để đĩnh nghĩa khóa chính cho Users service và giao diện interface UserService{} cho phép mô tả các hành vi trong Users service bao gồm tạo, sửa, xóa một tài khoản và hiển thị tất cả các tài khoản trong SOML.

 Nắm được quy mô thay đổi của API bởi vì API của microservice luôn thay đổi theo thời gian. Khi đã biết rõ quy mô thay đổi của API ta có thể đưa ra các biện pháp xử lý hiệu quả nhất:

o Đối với các thay đổi nhỏ, tính tương thích giữa API và các máy trạm chưa bị phá vỡ ta có thể thêm thay đổi vào phần yêu cầu và hồi đáp.

o Đối với các thay đổi lớn, tính tương thích bị phá vỡ ta bắt buộc phải tạo ra thêm phiên bản mới cho API trong microservice và vẫn duy trì API cũ.

 Các API phải có khả năng xử lý được các lỗi cục bộ như microservice bị ngưng hoạt động tạm thời, bị quá tải. Để có thể xử lý được các lỗi cục bộ ta có thể áp dụng một trong các phương pháp sau:

o Tạo một khoản thời gian chờ - timeout cho các máy trạm.

o Tạo fallback cho phép trả lại các thông báo, khuyến cáo để các máy trạm biết microservice được kết nối đến đang bị lỗi gì.

Các API của các microservice trong SOMLgiao tiếp với nhau bằng REST và sau khi thực hiện xong các HTTP request nó sẽ trả về kết quả dưới dạng JSON.

Ví dụ thông tin của người dùng trong SOML sau khi được truy vấn đến User service sẽ có dạng sau:

{"user"=>

{"id"=>887,

"name"=>"Van Pham",

"email"=>" vanpt.mi12@vnu.edu.vn",

"description "=>"This is Van’s account on SOML"

}}}

Để dễ dàng xây dựng và phát triển các microservice, mỗi API trong các microservice cần phải có một phần tài liệu để mô tả các chức năng cách dùng gọi là tài liệu API. Trong RoR có một thư viện rất hữa ích để viết tài liệu API gọi là swagger6, ví dụ trong SOML viết tài liệu cho việc tạo Story như sau:

swagger_api :create do summary 'Creates a story'

notes 'This helps user to create a new story'

param :form, 'story[name]', :string, :required, 'Name'

param :form, 'story[interval]', :integer, :required, 'Interval' param :form, 'story[description]', :string, :optional, 'Description' param :form, 'story[latitude]', :float, :optional, 'Latitude'

param :form, 'story[longitude]', :float, :optional, 'Longitude' param :form, 'story[location]', :string, :optional, 'Location' response :created

response :unprocessable_entity response :unauthorized

end

Trong đó summary được dùng để mô tả chung về API, notes cho phép mô tả chi tiết về API, param dùng để khai báo các thuộc tính của mỗi story và response cho phép thể hiện các thông điệp trả về các máy trạm khi có yêu cầu tạo story.

Giao thức HTTP cho phép các microservice trong SOML giao tiếp với nhau bằng một cặp yêu cầu và hồi đáp (request/response) trong đó microservice muốn kết nối trước sẽ đóng vai trò là máy trạm và microservice nhận kết nối sẽ đóng vai trò là máy chủ. Để bắt đầu kết nối máy trạm sẽ khởi tạo HTTP request đến máy chủ và nhận HTTP response trả về từ máy chủ. HTTP request gồm hai thành phần chính là URL và các các phương thức, trong đó các phương thức thường được sử dụng:

 POST cho phép tạo ra sự thay đổi trong cơ sở dữ liệu, được dùng khi các máy trạm muốn tạo ra đối tượng mới hoặc khi các máy trạm muốn gửi dữ liệu đến các microservice và ngược lại.

 GET dùng để truy vấn dữ liệu và tài nguyên với các tham số và giá trị

6https://github.com/richhollis/swagger-docs

nằm ngay trên URL.

 PUT/PATCH được dùng khi máy trạm muốn cập nhật dữ liệu.

 DELETE sẽ xóa đối tượng khỏi cơ sở dữ liệu.

HTTP response cũng gồm hai thành phần là mã trạng thái (Status code) và thông điệp (Message body). Trong đó mã trạng thái sẽ chứa kết quả sau khi xử lý yêu cầu HTTP request ở máy chủ, một số mã trạng thái thường dùng:

 2xx: thể hiện HTTP request đã được máy chủ thực hiện thành công o 200: OK

o 201: Created o 204: No_content

 3xx: chuyển hướng

 4xx: thể hiện các lỗi từ phía máy trạm o 400 – : bad_request

o 403 – : forbidden o 401 – : unauthorized o 404 – : not_found o 410 – : gone

o 422 – : unprocessable_entity

 5xx: các lỗi từ phía máy chủ

Mô hình tổng quan của SOML

Cơ chế kết nối trong SOML