Microservices Thực Tiễn: Từ Thiết Kế Đến Triển Khai phần 2
02/10/2017 | 16:27 PM

Service Registry & Service Discorvery (Truy Tìm Dịch Vụ)

Trong microservices, số lượng services mà bạn cần xử lý khá lớn. Và địa điểm của chúng có thể thay đổi nhanh và thường xuyên vì tính chất của việc phát triển microservices là nhanh. Nên bạn cần phải xác định được vị trí của một service trong quá trình chạy. Giải pháp cho vấn đề này là Service Registry.

Service Registry

Service Registry giữ các thực thể microservices và địa chỉ của chúng. Thực thể microservices được đăng kí với service registery khi bắt đầu chạy và hủy đăng kí khi tắt. Người dùng có thể tìm các services đang tồn tại và địa chỉ của chúng qua service registry.

Service Discovery

Để tìm các microservices đang tồn tại và địa điểm của chúng, chúng ta cần một quy trình truy tìm dịch vụ. Có hai mô hình là Client-side Discovery và Server-side Discovery. Hãy cùng xem xét hai mô hình này.

Client-side Discovery - Với mô hình này, client hay API Gateway lấy thông tin địa điểm của một thực thể service bằng cách truy vấn Service Registry.

Hình 9: Client-side Discovery

Client hay API Gateway phải thực hiện logic tìm kiếm service bằng cách gọi vào Service Registry.

Server-side Discovery - Với cách này, client hay API Gateway gửi yêu cầu lên một component (có thể là một Load Balancer). Component này sẽ gọi Service Registry và quyết định địa điểm của các microservices.

Hình 10: Server-side Discovery

Một số giải pháp triển khai microservices như Kubernetes cung cấp mô hình server-side discovery.

Deployment

Việc triển khai các dịch vụ có một trò trọng yếu và gồm các yêu cầu sau:

  • Khả năng triển khai/ gỡ xuống độc lập mà không ảnh hưởng đến dịch vụ khác

  • Có thể mở rộng theo cấp microservices, chỉ mở rộng microservices cần thiết

  • Phát triển và triển khai microservices nhanh chóng

  • Một microservice ngắt kết nối hay sập thì không ảnh hưởng các dịch vụ khác

Docker (một công cụ mã nguồn mở cho phép lập trình viên và quản trị viên hệ thống triển khai các ứng dụng thành các containers trên môi trường Linux) cung cấp một công cụ tuyệt vời để triển khai microservices đáp ứng đủ các yêu cầu trên. Các bước chính gồm:

  • Đóng gói mỗi microservice thành một ảnh Docker (docker image)

  • Triển khai mỗi thực thể của service là một Docker container

  • Mở dộng dựa vào số lượng thực thể

  • Phát triển, triển khai và khởi động microservices trở nên nhanh hơn với Docker (nhanh hơn nhiều các máy ảo thông thường - VM)

Kubernetes mở rộng khả năng của Docker bằng cách quản lý một cụm các Linux container như một hệ thống duy nhất, quản lý và chạy các Docker containers trên nhiều hosts, cung cấp service discovery và kiểm soát việc nhân rộng. Như bạn có thể thấy, những tính năng này cần thiết cho kiến trúc microservices. Vì vậy sử dụng Kurbernetes (trên nền Docker) để triển khai microservices đang trở thành một phương pháp cực kì hữu dụng, đặc biệt với ứng dụng lớn.

Hình 11: Phát triển và triển khai microservices containers

Hình 11 thể hiện tổng quát việc triển khai các microservices. Mỗi thực thể của microservices được triển khai thành một container và có hai containers trên mỗi host. Bạn có thể thay đổi số lượng containers chạy trên một host theo ý mình.

Security - Bảo Mật

Bảo mật microservcies là một yêu cầu phổ biến trong thực tế. Trước khi nói đến bảo mật microservices, hãy nhìn lại cách chúng ta thường thực hiện bảo mật của ứng dụng monolithic.

  • Bảo mật của một ứng dụng monolithic thường là về xác định xem "Ai là người gọi đến", "Người này có quyền hạn gì" và "Ứng dụng thông báo về nhưng thông tin này thế nào"

  • Một component phụ trách bảo mật chung thường nằm ở đầu chuỗi xử lý yêu cầu và component sẽ trả về thông tin cần thiết

Vậy chúng ta có thể chuyển đổi trực tiếp mô hình này sang kiến trúc microservices không? Có nhưng điều này yêu cầu phát triển bảo mật ở từng microservices và kết nối với một cơ sở trung tâm về người dùng để lấy thông tin cần thiết. Đây là một cách khá rối rắm. Thay vào đó, chúng ta có thể tận dụng các API bảo mật tiêu chuẩn như OAuth2 và OpenID Connect để tìm một giải pháp tốt hơn cho vấn đề bảo mật. Trước khi nói sâu hơn, chúng ta sẽ tóm tắt mục tiêu của mỗi tiêu chuẩn và cách sử dụng chúng.

  • OAuth2 - một phương thức chứng thực kiểu ủy quyền. Client xác thực với server cấp quyền (authorization server) và nhận một token gọi là "Access token". Access token không chứa bất kì thông tin gì về client. Nó chỉ là một tấm vé tham chiếu đến thông tin người dùng mà server cấp quyền có thể truy xuất đến. Do đó, đây cũng được gọi là token kiểu tham chiếu "by-reference token" và an toàn để sử dụng trên mạng lưới mở và internet.ư

  • OpenID Connect hoạt động tương tự OAuth nhưng ngoài Access Token, server cấp quyền còn phát một ID token chứa thông tin người dùng. Token này thường dạng JWT (JSON Web Token) và được kí bởi server cấp quyền. JWT token do đó được coi là token kiểu tham trị "by-value token" bởi vì nó chức thông tin về người dùng và có thể trở nên không an toàn.

Bây giờ, hãy xem xét những tiêu chuẩn này có thể bảo mật microservices trong ví dụ bán hàng của chúng ta như thế nào.

Hình 12: Bảo mật microservice với OAuth2 và OpenID Connect

Như hình trên, các bước chính để thực hiện bảo mật microservices gồm:

  • Chuyển việc xác thực cho server dạng OAuth và OpenID Connect (Authorization server) 

  • Sử dụng API Gateway để có một điểm đầu vào duy nhất cho yêu cầu từ clients

  • Client kết nối với server cấp quyền và nhận Access token. Sau đó gửi token này đến API Gateway cùng với yêu cầu

  • Dịch token tại Gateway - API Gateway lấy ra access token và gửi đến server cấp quyền để lấy JWT

  • Gateway truyền JWT cùng với yêu cầu đến microservices

  • JWT chứa thông tin người dùng cần thiết để lưu user sessions,....

  • Ở mỗi lớp microservice, bạn có thể có một component xử lý JWT, việc này khác đơn giản

Design for Failures - Thiết Kế Cho Thất Bại

Kiến trúc microservices tăng khả năng xảy ra thất bại tại microservices. Một microservice có thể sập do một vấn đề mạng, nguồn tài nguyên bị thiếu hụt hoặc không sẵn sàng,... Một microservice không đáp ứng lại không nên dẫn đến toàn bộ ứng dụng microservices sập. Do đó, mỗi microservices nên có khả năng chịu lỗi và hồi phục khi có thể. Người dùng phải có trải nghiệm tốt, nhẹ nhàng và không nhận ra lỗi bên trong hệ thống.

Thêm nữa, vì các dịch vụ có thể gặp lỗi bất cứ lúc nào, việc phát hiện (giám sát thời gian thực) lỗi nhanh chóng và nếu có thể tự động phục hồi dịch vụ là cực kì quan trọng.

Có một vài kiểu mẫu xử lý lỗi trong microservices phổ biến.

Circuit Breaker 

Khi có lời gọi từ bên ngoài đến một microservice, bạn có thể cấu hình một component giám sát lỗi với mỗi lời gọi. Component này đếm số yêu cầu thành công và thất bại, khi lỗi đạt một giới hạn nhất định thì component này sẽ dừng hoạt động của service (ngắt giao mạch).

Cách này hữu dụng để tránh tiêu tốn tài nguyên không cần thiết, yêu cầu bị chậm vì timeouts, cách này cũng giúp giám sát hệt thống.

Bulkhead

Vì một ứng dụng kiến trúc microservices bao gồm nhiều microservices, một service dừng hoạt động không nên ảnh hưởng đến phần còn lại. Kiểu mẫu bulkhead tách biệt các phần của ứng dụng để lỗi một chỗ không ảnh hưởng hệ thống.

Timeout

Kiểu mẫu timeout là một quy trình cho phép dừng một yêu cầu khi thời gian chờ đợi vượt quá hạn mức. Bạn có thể cấu hình khung thời gian tùy ý.

Vậy khi nào chúng ta sử dụng những kiểu mẫu này? Trong phần lớn trường hợp, những kiểu mẫu này được áp dựng ở lớp Gateway. Khi microservices không đáp lại hay không sẵn sàng, ở cấp Gateway chúng ta có thể quyết định có nên gửi yêu cầu đến microservices sử dụng circuit breakers hay timeout. Hơn nữa, sử dụng bulkhead ở Gateway khá quan trọng vì đây là một điểm đầu vào cho tất cả yêu cầu từ clients, nên nếu lỗi một service cũng không ảnh hưởng đến việc gửi yêu cầu đến các services khác.

Thêm vào đó, Gateway có thể được sử dụng như một điểm trung tâm ta có thể lấy thông tin về trạng thái và theo dõi các microservices hoạt động.

Microservices, Tích Hợp Cho Doanh Nghiệp, Quản Lý API và hơn thế nữa

Chúng ta đã trao đổi các đặc tính của kiến trúc Microservices và cách bạn có thể thực hiện chúng. Tuy nhiên, bạn nên lưu ý rằng Microservices toa thuốc chữa bách bệnh. Việc áp dụng mù quáng những khái niệm đang nổi sẽ không xử lý vấn đề thực tế của bạn. Nếu bạn đã đọc toàn bộ bài này thì bạn sẽ thấy Microservices có nhiều lợi ích và chúng ta nên tận dụng. Tuy nhiên, bạn cần hiểu rằng mong chờ microservices giải quyết tất cả các vấn đề là không thực tiễn.

Mong rằng các bạn đã có một cái nhìn rõ hơn về Microservices. 

Bài viết được dịch từ Microservices in Practice: From Architecture to Deployment

Nguồn: TechMaster (by Ngô Thùy Linh)

Tin nổi bật Tin nổi bật