station d

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.

Cải thiện hiệu năng cho JavaScript Web Application chỉ trong vòng vài bước đơn giản

Security Considerations khi Designing Web Applications

Đáng lẽ mình sẽ tự tay implement và giải thích về ý nghĩa của từng phần, tuy nhiên, trong thời gian research đã tìm ra được một nguồn tài liệu viết rất chuyên nghiệp và đầy đủ. Vì vậy mình sẽ dựa trên đó để viết, nhằm mang đến cái nhìn professional và đúng đắn nhất Các bạn có thể đọc các bài viết nguyên bản tiếng Anh tại ĐÂY.

Trong bài viết đầu tiên này, hãy cùng xem xét về bức tranh tổng thể khi xây dựng một ứng dụng Microservices, sẽ gồm những thành phần (chính) nào, và cách chúng coordinate với nhau 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?

Hình vẽ dưới đây, theo Martin Fowler, sẽ cho ta biết chính xác điều chúng ta cần đạt được

(Nguồn: http://martinfowler.com/articles/microservices.html)

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

… và theo chiều ngang, chúng ta có thể áp dụng một số phân vùng theo domain. Điều này có thể dẫn đến một kiến trúc như dưới đây:

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ụ:

(Nguồn: http://www.infoq.com/minibooks/emag-devops-toolchain)

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ọ.”

(Nguồn: http://martinfowler.com/articles/microservices.html)

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.

Các services sử dụng và được sử dụng bởi các services khác sẽ dẫn đến một hệ thống mà nhiều services sẽ kết nối với nhau. (Xem thêm IPC)

Một số services cung cấp các API ra bên ngoài nhằm đóng gói và bảo vệ các services khác khỏi sự truy cập từ bên ngoài. (Xem thêm API Gateway)

Hệ thống sẽ động (dynamic) hơn. Các services mới được triển khai, các services cũ được thay thế hoặc loại bỏ, các instance mới của một service hiện có được khởi chạy thêm để đáp ứng tải gia tăng. Điều này có nghĩa là các services sẽ đến và đi với tần suất cao hơn nhiều so với trước đây. (Xem thêm Service Discovery)

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 cách nào để theo dõi các thông điệp giữa các services? Điều gì xảy ra nếu team bắt đầu nhận được khiếu nại về một số quá trình xử lý không thành công? Microservice nào là nguyên nhân gốc rễ của vấn đề? Làm thế nào ta có thể phát hiện ra rằng việc xử lý, ví dụ, đơn hàng 12345 bị kẹt vì không thể truy cập vào microservice A hoặc cần phê duyệt thủ công trước khi microservice B có thể gửi thông báo xác nhận liên quan đến đơn hàng đó?

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ộ?

Làm cách nào để bảo mật các API-services? Không phải là câu hỏi mới hoặc cụ thể liên quan đến microservices nhưng vẫn rất quan trọng để bảo đảm cho các microservices an toàn khi đưa ra ngoài.

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.

Circuit Breaker. Để tránh chuỗi sự cố, cần phải áp dụng Circuit Breaker pattern, bạn có thể đọc thêm trong cuốn sách Release It! hoặc bài đăng trên blog của Fowler – Circuit Breaker.

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.

Centralized log analysis. Để có thể theo dõi messages và phát hiện khi chúng bị kẹt (stuck), chúng ta cần một chức năng phân tích log tập trung có khả năng tiếp cận với máy chủ và thu thập các tệp log mà mỗi services microservice tạo ra. Chức năng phân tích log lưu trữ thông tin log này trong cơ sở dữ liệu trung tâm và cung cấp khả năng tìm kiếm và dashboard. Lưu ý : Để có thể tìm thấy các messages liên quan, điều quan trọng là tất cả các microservices phải sử dụng id đồng nhất trong các log message.

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.

Series này là phần tiếp theo series Microservices: Từ Thiết Kế Đến Triển Khai, tập trung vào việc hiện thực hóa các khái niệm đã mô tả ở phần lý thuyết. Hi vọng sẽ giúp ích được cho các bạn khi làm quen với microservies. Các bạn có thể tham khảo thêm về phần Architecture căn bản ở đây nhé.

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm IT Job hấp dẫn trên Station D

Building Microservices Application – Phần mở đầu: Bức tranh tổng thể