Bài viết được sự cho phép của tác giả Edward Thien Hoang
Đây là bài viết đầu tiên trong phần Xây dựng ứng dụng với Microservices. Trong những loạt bài trước, chúng ta đã tìm hiểu qua phần lý thuyết về những “viên gạch” (building block) chủ đạo trong Microservies. Loạt bài tiếp theo sẽ hướng đến việc implement những pattern như API Gateway, Service Discovery, Circuit Breaker trong kiến trúc Microservices như thế nào.
1. ĐIỀU KIỆN CẦN
Điều gì là cần thiết để triển khai một số lượng lớn các microservices trong hệ thống?
Tuy nhiên, trước khi chúng ta có thể bắt đầu tung ra số lượng lớn các microservices trong hệ thống để thay thế các ứng dụng nguyên khối, có một số điều kiện tiên quyết cần được đáp ứng (hoặc ít nhất là ở mức độ nào đó). Chúng ta cần:
- một kiến trúc mục tiêu
- một chuỗi công cụ phân phối liên tục (continues delivery)
- một tổ chức phù hợp
Hãy xem xét một cách ngắn gọn từng điều kiện tiên quyết.
1.1. KIẾN TRÚC MỤC TIÊU
Đầu tiên chúng ta cần một ý tưởng kiến trúc về cách phân vùng tất cả các microservices. Ví dụ, có thể phân vùng chúng theo chiều dọc trong một số layer như:
- Core services Xử lý logic nghiệp vụ cốt lõi
- Composite services có thể phối hợp một số Core services để thực hiện nhiệm vụ chung hoặc tổng hợp thông tin từ một số Core services.
- API services cung cấp chức năng cho bên ngoài
Lưu ý: Đây chỉ là một kiến trúc mẫu, kiến trúc của bạn có thể hoàn toàn khác nhau. Điều quan trọng ở đây là cần phải có một kiến trúc mẫu được thiết lập trước khi bắt đầu mở rộng quy mô triển khai các microservices. Nếu không, bạn có thể kết thúc trong một cảnh quan hệ thống mà chỉ trông giống như một dĩa mì spaghetti (cực kỳ rối rắm, vô tổ chức) với đặc điểm thậm chí còn tồi tệ hơn so với các ứng dụng nguyên khối hiện có.
1.2. CONTINOUS DELIVERY
Chúng ta cũng giả định rằng có một hệ thống continuous delivery tool chain để có thể triển khai các microservices của mình theo cách có hiệu quả và có thể lặp lại được, ví dụ:
1.3. TỔ CHỨC
Cuối cùng, giả định rằng chúng ta đã thông qua tổ chức của mình để tránh các vấn đề với định luật Conway:
“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
“Một công ty thiết kế hệ thống thế nào cũng sẽ làm ra những thiết kế giống y hệt với thiết kế hệ thống của chính công ty họ.”
2. MỘT HỆ THỐNG PHỨC TẠP HƠN
Điều gì sẽ xảy ra trong một hệ thống khi chúng ta bắt đầu phân chia ứng dụng nguyên khối và thay thế chúng bằng một số lượng lớn các microservices?
Số lượng đơn vị triển khai (tức là microservice) lớn hơn. Nhiều microservices thay vì một ứng dụng nguyên khối lớn, do đó cần phải quản lý và theo dõi nhiều thành phần hơn.
MTBF (Mean time between failures – thời gian để có lỗi xảy ra) sẽ giảm (tức là lỗi nhiều hơn). Với rất nhiều service được triển khai và hoạt động thì xác suất xảy ra lỗi sẽ tăng lên là điều hiển nhiên.
3. NHỮNG VẤN ĐỀ ĐẶT RA
Làm thế nào tất cả các microservices được cấu hình và nó có đúng không? Xử lý cấu hình không phải là vấn đề lớn với một vài ứng dụng, ví dụ: mỗi ứng dụng lưu trữ cấu hình của riêng nó trong các tệp thuộc tính trên đĩa hoặc các bảng cấu hình trong cơ sở dữ liệu riêng của nó. Với một số lượng lớn các microservices được triển khai với nhiều instances trên nhiều máy chủ, cách tiếp cận này sẽ tạo nên vấn đề về cách quản lý cấu hình. Nó sẽ dẫn đến rất nhiều tập tin cấu hình nhỏ trên tất cả hệ thống làm cho việc duy trì và kiểm soát rất khó khăn.
Những microservices nào được triển khai và ở đâu? Bởi vì việc các microservies được triển khai với các địa chỉ máy chủ / cổng khác nhau. Với một số lượng lớn các microservices được triển khai độc lập với nhau sẽ có nhiều thay đổi liên tục trong hệ thống và điều này có thể dễ dẫn đến cơn ác mộng bảo trì nếu phải xử lý thủ công.
Cách cập nhật thông tin định tuyến (routing)? Client sử dụng các services cũng gặp các khó khăn. Cụ thể, nếu các bảng định tuyến, ví dụ như các reverse proxies hoặc các tệp cấu hình của Client, cần được cập nhật theo cách thủ công. Về cơ bản sẽ không có thời gian để chỉnh sửa thủ công các bảng định tuyến trong một hệ thống đang được phát triển liên tục với các microservices mới xuất hiện trên các địa chỉ máy chủ / cổng mới. Thời gian delivery sẽ kéo dài và rủi ro đối với các lỗi thủ công sẽ gây rủi ro về khía cạnh chất lượng và / hoặc làm cho chi phí hoạt động không cần thiết tăng lên.
Làm thế nào để ngăn chặn chuỗi sự cố xảy ra (chain of failures)? Vì các microservices sẽ được kết nối với nhau, cần phải chú ý đặc biệt để tránh các chuỗi sự cố. Nếu không được xử lý đúng thì một lỗi ở một microservies nào đó cũng có thể dẫn đến việc ngừng trệ toàn bộ cả hệ thống.
Làm cách nào để xác minh rằng tất cả các services đều đang hoạt động? Việc theo dõi trạng thái của một vài ứng dụng khá đơn giản nhưng làm cách nào để chúng ta xác minh rằng tất cả các microservices đều khỏe mạnh và sẵn sàng nhận request?
Làm thế nào để đảm bảo rằng chỉ các API-services được đưa ra bên ngoài? Ví dụ: làm cách nào để tránh truy cập trái phép từ bên ngoài vào các microservices nội bộ?
4. CÁC THÀNH PHẦN CHÍNH TRONG MICROSERVICES
Để giải quyết các câu hỏi này, chúng ta sẽ cần các thành phần sau trong một hệ thống microservies:
Central Configuration server. Thay vì cấu hình cục bộ cho mỗi đơn vị triển khai (tức là microservice), chúng ta cần quản lý cấu hình tập trung. Chúng ta cũng cần một configuration API để các microservices có thể sử dụng để lấy thông tin cấu hình.
Service Discovery server. Thay vì theo dõi thủ công những microservices nào được triển khai hiện tại và trên máy chủ và cổng nào, chúng ta cần chức năng Service Discovery cho phép microservices tự đăng ký khi khởi động thông qua API.
Dynamic Routing and Load Balancer. Với chức năng service discovery, các thành phần định tuyến có thể sử dụng discovery API để tra cứu nơi mà microservice được yêu cầu được triển khai và các thành phần cân bằng tải có thể quyết định định tuyến yêu cầu tới instance nào nếu nhiều instance được triển khai cho một service được yêu cầu.
Monitoring. Vì đã có circuit breakers, chúng ta có thể bắt đầu theo dõi trạng thái của chúng và thu thập số liệu thống kê thời gian chạy từ chúng để có được một bức tranh về tình trạng sức khỏe của hệ thống.
Edge Server. Để đưa các API services ra bên ngoài và để ngăn chặn truy cập trái phép vào các microservices nội bộ, chúng ta cần một edge server nơi tất cả request bên ngoài đi qua. Một edge server có thể tái sử dụng khả năng định tuyến động và cân bằng tải dựa trên service discovery được mô tả ở trên. Edge server sẽ hoạt động như một proxy ngược chủ động mà không cần cập nhật thủ công khi hệ thống nội bộ thay đổi.
OAuth 2.0 protected API’s Để bảo vệ các API services được expose ra bên ngoài, quy trình của OAuth 2.0 có thể như sau:
- Một component mới có thể đóng vai trò như một Máy chủ ủy quyền (OAuth Authorization Server)
- Các API services sẽ đóng vai trò như các Máy chủ tài nguyên (OAuth Resource Server)
- Các Client bên ngoài gọi đến API services với tư cách là OAuth Clients
- Edge server sẽ làm việc như một OAuth Token Relay, có nghĩa là:
- Nó sẽ hoạt động như một OAuth Resource Server
- Nó sẽ chuyển các OAuth Access Tokens có trong request bên ngoài đến các API services
5. MÔ HÌNH THAM CHIẾU
Lưu ý: Để giảm độ phức tạp, các tương tác giữa microservices và các services hỗ trợ không được vẽ.
6. BƯỚC TIẾP THEO
Trong các bài viết sắp tới, chúng ta sẽ lần lượt tìm hiểu về từng thành phần trong mô hình tham chiếu.