Truy tìm dịch vụ trong một kiến trúc Microservices

Truy tìm dịch vụ trong một kiến trúc Microservices
02 tháng 11, năm ngoái – 2684 lượt xemĐây là bài thứ tư trong loạt bài về phong cách thiết kế, thiết kế xây dựng và tiến hành những ứng dụng sử dụng kiến trúc Microservices. Trong bài tiên phong, quy mô kiến trúc Microservices đã được ra mắt và bàn luận về những ưu điểm và hạn chế trong việc ứng dụng và tiến hành. Bài thứ hai diễn đạt về phương pháp mà những client tương tác với những dịch vụ nhỏ trải qua một phương tiện đi lại trung gian gọi là API gateway. Bài thứ ba tìm hiểu và khám phá về cách mà những dịch vụ nhỏ trong cùng một mạng lưới hệ thống tiếp xúc với nhau. Trong bài viết này, tất cả chúng ta cùng làm sáng tỏ những yếu tố tương quan thân mật đến truy lùng dịch vụ .

Tại sao cần truy tìm dịch vụ?

Tưởng tượng rằng bạn đang viết một đoạn mã để truy vấn đến một dịch vụ mà dịch vụ này có REST API hoặc Thrift API. Đoạn mã đó cần có thông tin về vị trí mạng ( địa chỉ IP và cổng ) của một thực thể dịch vụ để gửi nhu yếu. Trong một ứng dụng truyền thống cuội nguồn chạy trên phần cứng vật lý, những vị trí mạng của những instance service là tương đối tĩnh. Ví dụ, code của bạn hoàn toàn có thể đọc những vị trí mạng từ một tập tin thông số kỹ thuật được update tiếp tục .

Ngược lại, trong các ứng dụng microservices hiện đại được xây dựng và triển khai trên nền tảng điện toán đám mây. Do đó, việc truy tìm dịch vụ là một nhiệm vụ khó khăn hơn rất nhiều, thể hiện trong sơ đồ sau đây. 

Học lập trình trực tuyến tốt nhất

Mỗi thực thể dịch vụ trong một ứng dụng microservices đều được gán vị trí mạng và chúng có khuynh hướng đổi khác linh động vì những tác động ảnh hưởng khác mang đến. Do đó, đoạn mã của client cần vận dụng một kỹ thuật tìm kiếm phức tạp hơn .Có hai quy mô hầu hết được sử dụng để săn lùng dịch vụ là : client-side discovery và server-side-discovery .

Mô hình client-side discovery

Mô hình client-side discovery lao lý rằng những client sẽ phải xác lập vị trí mạng của những dịch vụ khả dụng và nhu yếu cân đối tải. Để làm được điều này client cần truy vấn một cơ sở tài liệu gọi là Service Registry. Đây là một cơ sở tài liệu chứa thông tin và vị trí mạng của những thực thể dịch vụ. Sau khi truy vấn được vị trí của dịch vụ, client sử dụng một thuật toán cân đối tải giúp chọn ra một dịch vụ khả dụng để gửi nhu yếu .

Học lập trình trực tuyến cơ bản

Mô hình này đối phó với việc vị trí mạng không không thay đổi của mỗi dịch vụ bằng cách :

  • Khi khởi động dịch vụ, ghi vị trí mạng vào Service Registry và xóa bỏ khi thực thể dịch vụ này kết thúc.
  • Áp dụng kỹ thuật tín hiệu tuần hoàn (heartbeat mechanism) vào việc cập nhật vị trí mạng của các dịch vụ.

Netflix OSS phân phối một ví dụ tuyệt vời của quy mô client-side discovery. Netflix Eureka là một service registry. Nó phân phối một REST API cho việc quản trị ĐK service-instance và cho việc truy vấn những instance có sẵn. Netflix Ribbon là một IPC client thao tác với Eureka để cân đối tải những nhu yếu trên những service instance có sẵn. Chúng ta sẽ đàm đạo về Eureka sâu hơn ở phần sau của bài viết này .Mô hình client-side discovery có những quyền lợi :

  • Một mô hình đơn giản, ngoại trừ service registry thì không có gì phức tạp.

Những hạn chế :

  • Sự ràng buộc giữa client với Service Registry
  • Cần viết mã lệnh cho client đối với mỗi ngôn ngữ lập trình và framework

Mô hình server-side discovery 

Học lập trình trực tuyến nâng cao

Client tạo ra một nhu yếu tới một dịch vụ trải qua một bộ cân đối tải. Bộ cân đối tải sẽ truy vấn Service Registry và định tuyến mỗi nhu yếu tới một instance service có sẵn. Cũng giống như quy mô client-side discovery, những instance service được ĐK và hủy ĐK với Service Registry .Một AWS Elastic Load Balancer ( ELB ) là ví dụ về một bộ định tuyến server-side discovery. Một ELB thường được sử dụng để cân đối tải lưu lượng truy vấn từ bên ngoài Internet. Tuy nhiên, bạn cũng hoàn toàn có thể dùng ELB để cân đối tải lưu lượng truy vấn bên trong một đám mây riêng ảo ( Virtual Private Cloud ). Một client tạo ra nhu yếu ( HTTP hay TCP ) trải qua ELB sử dụng tên DNS của nó. ELB cân đối tải lưu lượng truy vấn trong một tập hợp những instance Elastic Compute Cloud ( EC2 ) đã ĐK hoặc những container EC2 Container Service ( ECS ). Không có một Service Registry riêng không liên quan gì đến nhau. Thay vào đó, những instance EC2 và những container ECS được ĐK với chính ELB .

Các máy chủ HTTP và cân bằng tải như NGINX Plus và NGINX cũng có thể được sử dụng như là một cân bằng tải server-side discovery. Ví dụ, bài viết trên blog này mô tả cách sử dụng Consul Template để tự động cấu hình lại NGINX làm reverse proxying. Consul Template là một công cụ mà theo định kỳ tái tạo các tập tin cấu hình tùy ý từ dữ liệu cấu hình được lưu trữ trong Consul Service Registry. Nó chạy một lệnh shell tùy ý bất cứ khi nào các tập tin thay đổi. Ở ví dụ được mô tả trong bài viết blog đó, Consul Template tạo ra một tập tin nginx.conf, để cấu hình reverse proxying, và sau đó chạy một lệnh mà nói với NGINX tải lại cấu hình. Một thực thi tinh vi hơn có thể cấu hình động lại NGINX Plus bằng cách sử dụng API HTTP hoặc DNS của nó.

Trong một vài môi trường tự nhiên tiến hành như Kubernetes và Marathon, proxy đóng vai trò như một cân đối tải. Để gửi một nhu yếu đến một dịch vụ thì một client cần gửi nhu yếu trải qua proxy sử dụng địa chỉ IP của sever và cổng dịch vụ đã được gán. Sau đó, proxy sẽ chuyển tiếp nhu yếu đến một thực thể dịch vụ khả dụng .Server-side discovery có những quyền lợi :

  • Các client chỉ cần gửi yêu cầu tới bộ cân bằng tải, quá trình truy tìm tách biệt với client, phần mã lệnh của client cũng đơn giản hơn. Do đó, giảm đi mã lệnh cho client đối với mỗi ngôn ngữ lập trình và framework.
  • Một vài môi trường triển khai cung cấp sẵn mô hình truy tìm dịch vụ này, trong đó có AWS Elastic Load Balancer.

Những hạn chế của quy mô server-side discovery :

  • Nếu bộ cân bằng tải không được tích hợp sẵn vào môi trường triển khai thì bạn cần phải cài đặt và quản lý.

Service Registry

Service Registry ( SR ) là một bộ phận rất quan trọng trong truy lùng dịch vụ. Nó là một cơ sở tài liệu gồm có vị trí mạng của những thực thể dịch vụ, do đó năng lực update tức thời luôn là một nhu yếu cao. Về triết lý, những client hoàn toàn có thể lưu vị trí mạng được lấy từ SR vào bộ nhớ trong thời điểm tạm thời, nhưng chắc như đinh rằng những thông tin này nhanh gọn vô dụng vì vị trí mạng đổi khác rất linh động và tiếp tục. Vậy nên, một SR gồm có rất nhiều sever sử dụng giao thức nhân bản để duy trì sự đồng điệu tài liệu .Như đã đề cập ở trên, Netflix Eureka là một ví dụ nổi bật của một SR. Nó cung ứng một REST API giúp bạn ĐK và truy vấn những thực thể dịch vụ. Một thực thể dịch vụ sử dụng lệnh POST để ĐK vị trí mạng của nó và cứ mỗi 30 giây nó liên tục dùng lệnh PUT để gửi nhu yếu update đến SR. tin tức của một dịch vụ sẽ bị tự động hóa xóa bỏ nếu không update sau 30 giây và nó cũng hoàn toàn có thể bị xóa khi dùng lệnh HTTP DELETE. Client hoàn toàn có thể sử dụng lệnh HTTP GET để lấy thông tin vị trí mạng của một dịch vụ .Netflix có được tính khả dụng cao là nhờ chạy một hoặc nhiều sever Eureka trong mỗi vùng AWS EC2 khả dụng. Mỗi sever Eureka chạy trên một thực thể EC2 – có một địa chỉ IP Elastic. Các bản ghi của DNS TEXT được sử dụng để tàng trữ tài liệu thông số kỹ thuật của Eureka. Đó là một tấm map chứa thông tin những vùng khả dụng và list những vị trí mạng của những sever Eureka. Khi một sever Eureka khởi động, nó truy vấn DNS để lấy thông tin thông số kỹ thuật của nhóm Eureka, xác lập vị trí những sever khác và tự gán cho nó một địa chỉ IP Elastic chưa dùng đến .

Eureka clients- service và service – clients truy vấn DNS để tìm ra vị trí mạng của các máy chủ Eureka. Clients được khuyến khích dùng một máy chủ Eureka trong cùng một vùng khả dụng. Tuy nhiên, nếu không còn cái nào khả dụng thì client sẽ sử dụng một máy chủ Eureka ở một vùng khả dụng khác.

Một vài ví dụ khác về SR :

  • etcd – một cơ sở dữ liệu key-value có tính khả dụng cao, phân phối và nhất quán sử dụng để tìm kiếm dịch vụ. Kubernetes và Cloud Foundry là hai dự án nổi tiếng có dùng etcd.
  • consul – một công cụ giúp tìm kiếm và cấu hình các dịch vụ. Nó cung cấp một bộ API cho phép các client đăng ký và tìm kiếm dịch vụ. Consul có khả năng kiểm tra tính khả dụng của các dịch vụ.
  • Apache Zookeeper – một dịch vụ được sử dụng rộng rãi, có khả năng phối hợp cao dành cho các ứng dụng phân tán. Apache Zookeeper ban đầu là một phần dự án của Hadoop nhưng giờ nó là một dự án quan trọng hàng đầu.

Cần nhắc lại rằng SR là một bộ phận được tích hợp trong hạ tầng dịch vụ, những mạng lưới hệ thống như Kubernetes, Marathon và AWS không sống sót một SR hoàn hảo .

Các mô hình đăng ký thông tin dịch vụ

Bằng cách nào đó, thông tin của những thực thể dịch vụ phải được ghi và xóa trong SR. Có hai giải pháp để xử lý yếu tố này :Một là thực thể dịch vụ tự ghi thông tin lên SR ( self-registration pattern )Hai là sử dụng một công cụ tương hỗ ghi và quản trị ( third party registration pattern )

Mô hình dịch vụ tự ghi xóa thông tin

Trong quy mô này, mỗi thực thể dịch vụ sẽ chịu nghĩa vụ và trách nhiệm trong việc ghi và xóa thông tin của chính nó trong SR. Đồng thời, mỗi thực thể cũng tiếp tục gửi những nhu yếu tuần hoàn để update thông tin .

Học lập trình trực tuyến tìm việc

Netflix OSS Eureka client là một ví dụ minh họa cho quy mô này. Eureka client quản trị toàn bộ những yếu tố tương quan đến ĐK và hủy ĐK thông tin của những thực thể dịch vụ. Dự án Spring Cloud ( có tương hỗ truy lùng dịch vụ ) giúp Eureka tự động hóa ghi thông tin dịch vụ một cách thuận tiện. Bạn chỉ cần chú thích class Java Configuration của mình với một chú thích @ EnableEurekaClient .Điểm lợi của quy mô này là nó tương đối đơn thuần không nhu yếu sự trợ giúp của bất kể bên thứ ba nào. Tuy nhiên, việc những thực thể dịch vụ bị ràng buộc với SR lại là một hạn chế, bạn cần phải viết những mã lệnh tương hỗ việc ĐK cho những dịch vụ trong mỗi ngôn từ lập trình và framework .

Mô hình hỗ trợ đăng ký bên thứ ba 

Trong quy mô này, những thực thể dịch vụ sẽ không tự ĐK thông tin với SR, việc làm sẽ được giao cho một thành phần bên thứ ba đó là một Service Registrar. Nó sẽ tiếp tục kiểm tra xem khi một thực thể dịch vụ khởi động lên, Service Registrar sẽ ghi thông tin vị trí mạng của dịch vụ đó vào SR. Khi dịch vụ dừng hoạt động giải trí, Registrar sẽ xóa thông tin về thực thể này khỏi SR .

Học lập trình trực tuyến kiếm tiền

Dự án nguồn mở Registrator là ví dụ về một service registrar. Nó tự động hóa ĐK và hủy ĐK thông tin những thực thể dịch vụ được tiến hành bởi Docker containers. Registrator tương hỗ một vài SR trong đó có etcd và Consul .Một ví dụ khác về service registrar là Netflix Prana. Mục đích chính của registrar này là tương hỗ những dịch vụ không được viết bởi ngôn từ JVM ( Java Virtual Machine ), nó là một ứng dụng phụ chạy song song với một thực thể dịch vụ. Prana dùng Netflix Eureka để ghi và xóa thông tin của những thực thể dịch vụ .Service registrar là một thành phần gắn liền với hạ tầng tiến hành dịch vụ. Mỗi thực thể EC2 được tạo ra bởi Autoscaling Group hoàn toàn có thể được tự động hóa ĐK bởi một ELB. Các dịch vụ của Kubernetes được tự động hóa ĐK và luôn khả dụng cho việc tìm kiếm .Một ưu điểm rõ ràng của quy mô này là những dịch vụ không bị ràng buộc với SR, mã lệnh của dịch vụ sẽ ít phức tạp hơn so với quy mô tiên phong. Công việc ĐK thông tin cho dịch vụ được tập trung chuyên sâu giải quyết và xử lý bởi một mạng lưới hệ thống của bên thứ ba. Một hạn chế của quy mô này đó là, bạn sẽ phải setup và quản trị registrar nếu nó không là một phần của hạ tầng tiến hành dịch vụ hoặc không là một bộ phận luôn khả dụng trong mạng lưới hệ thống .

Kết luận

Trong một ứng dụng microservices, khuynh hướng của những thực thể dịch vụ đang chạy là biến hóa linh động. Các thực thể được gán vị trí mạng không cố định và thắt chặt. Do đó, những client cần vận dụng kỹ thuật truy lùng dịch vụ để gửi nhu yếu đến .Một bộ phận rất quan trọng trong săn lùng dịch vụ đó là Service Registry. Đây là một cơ sở tài liệu của những thực thể dịch vụ đang được kích hoạt. Service registry cung ứng những API giúp quản trị ghi xóa và truy vấn thông tin dịch vụ .Client-side discovery và server-side discovery là hai quy mô tìm kiếm dịch vụ hầu hết được vận dụng. Trong mạng lưới hệ thống với quy mô client-side discovery, những client truy vấn đến SR, chọn một thực thể khả dụng và gửi nhu yếu đi. Trong mạng lưới hệ thống vận dụng quy mô server-side discovery, những client gửi nhu yếu đến dịch vụ khả dụng trải qua một thiết bị định tuyến ( router ). Router có trách nhiệm truy vấn đến SR và chuyển tiếp nhu yếu từ client đến thực thể đang hoạt động giải trí .Self-registration và third-party registration là hai phương pháp chính để ĐK và hủy ĐK thông tin dịch vụ trong SR. Cách thứ nhất do những thực thể dịch vụ tự thực thi những phép ghi xóa update, cách thứ hai do một mạng lưới hệ thống bên thứ ba đảm nhiệm update và quản trị .

Trong một vài môi trường triển khai, bạn phải sử dụng một Service Registry như Netflix Eureka, etcd hay Apache Zookeeper để tự cài đặt hệ thống truy tìm dịch vụ của mình. Trong một số môi trường triển khai khác, hệ thống này được tích hợp sẵn. Ví dụ, Kubernetes và Marathon điều khiển việc đăng ký và hủy đăng ký thông tin dịch vụ. Chúng cũng có khả năng chạy một proxy trên mỗi cụm máy chủ – với vai trò như một bộ định tuyến server-side discovery.

Một proxy đảo ngược HTTP và cân đối tải như NGINX cũng hoàn toàn có thể sử dụng như một cân đối tải. Service Registry hoàn toàn có thể đẩy thông tin đến NGINX và gọi ra một bản update thông số kỹ thuật thuận tiện. Ví dụ, bạn hoàn toàn có thể sử dụng Consul Template. NGINX Plus tương hỗ kỹ thuật additional dynamic reconfiguration – nó sử dụng DNS để lấy thông tin dịch vụ từ Service Registry đồng thời cung ứng một API để giúp thông số kỹ thuật lại thông tin dịch vụ .Trong những bài viết tiếp, tất cả chúng ta sẽ liên tục đào sâu khám phá những yếu tố khác của microservices .

Bản gốc tiếng Anh “Service Discovery in a Microservice Architecture” 
Bản dịch của nhóm học viên lớp Java Spring dịch

admin

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *