[Các tính năng tối ưu của Dubbo3] "Kiến trúc ba trung tâm gốc đám mây" đưa bạn khám phá các nguyên tắc và hoạt động phát triển của trung tâm cấu hình, trung tâm siêu dữ liệu và trung tâm đăng ký trong hệ thống Dubbo3 (Phần 1) -6ren

[Các tính năng tối ưu của Dubbo3] "Kiến trúc ba trung tâm gốc đám mây" đưa bạn khám phá các nguyên tắc và hoạt động phát triển của trung tâm cấu hình, trung tâm siêu dữ liệu và trung tâm đăng ký trong hệ thống Dubbo3 (Phần 1)

In lại Tác giả: Tôi là một chú chim nhỏ Thời gian cập nhật: 2023-01-15 14:31:06

Khám phá dịch vụ cấp ứng dụng với Dubb3

Dubbo3 cung cấp một mô hình khám phá dịch vụ cấp ứng dụng mới, khác với mô hình khám phá dịch vụ cấp giao diện của Dubbo2 về mặt thiết kế và triển khai.

Tóm lại, tính năng khám phá dịch vụ cấp ứng dụng do Dubbo3 giới thiệu có những ưu điểm chính sau.

Thích ứng với sự chuyển đổi dịch vụ vi mô gốc đám mây . Trong kỷ nguyên đám mây gốc, khả năng cơ sở hạ tầng liên tục được phát hành theo hướng lên trên. Các nền tảng như Kubernetes đã tích hợp khái niệm trừu tượng hóa dịch vụ vi mô. Khám phá dịch vụ cấp ứng dụng của Dubbo3 là một mô hình phổ quát thích ứng với nhiều hệ thống dịch vụ vi mô khác nhau.
Cải thiện hiệu suất và khả năng mở rộng . Hỗ trợ quản trị dịch vụ của các cụm siêu lớn luôn là lợi thế của Dubbo. Bằng cách giới thiệu mô hình khám phá dịch vụ cấp ứng dụng, về cơ bản, nó giải quyết được áp lực lưu trữ và đẩy dữ liệu địa chỉ của trung tâm đăng ký, đồng thời áp lực tính toán địa chỉ tương ứng ở phía Người tiêu dùng cũng giảm đi theo cấp số nhân; quy mô cụm cũng trở nên có thể dự đoán và đánh giá được (không liên quan đến số lượng giao diện RPC, mà chỉ liên quan đến quy mô triển khai phiên bản).

Hình sau là mô hình khám phá dịch vụ của Dubbo2: Nhà cung cấp đăng ký địa chỉ dịch vụ, Người tiêu dùng phối hợp và khám phá địa chỉ dịch vụ thông qua trung tâm đăng ký, sau đó bắt đầu giao tiếp với địa chỉ. Đây là quy trình khám phá dịch vụ cổ điển được hầu hết các khuôn khổ dịch vụ vi mô sử dụng. Điều đặc biệt về Dubbo2 là nó còn tích hợp thông tin của "giao diện RPC" vào quá trình khám phá địa chỉ và phần thông tin này thường liên quan chặt chẽ đến định nghĩa doanh nghiệp cụ thể.

Sau khi kết nối với cơ sở hạ tầng đám mây gốc, cơ sở hạ tầng sẽ kết hợp khái niệm trừu tượng về dịch vụ vi mô và quá trình sắp xếp và lập lịch các dịch vụ vi mô được chứa trong container sẽ hoàn tất việc đăng ký ở cấp độ cơ sở hạ tầng. Như thể hiện trong hình bên dưới, cơ sở hạ tầng không chỉ đảm nhận trách nhiệm của trung tâm đăng ký mà còn hoàn thành hành động đăng ký dịch vụ. Tuy nhiên, thông tin "giao diện RPC" liên quan đến doanh nghiệp cụ thể và không thể hoặc không phù hợp để cơ sở hạ tầng lưu trữ.

Trong một kịch bản như vậy, hai yêu cầu được đưa ra cho cơ chế đăng ký và khám phá dịch vụ của Dubbo3: Dubbo3 cần trừu tượng hóa một mô hình ánh xạ địa chỉ chung độc lập với logic kinh doanh khỏi quy trình khám phá dịch vụ ban đầu và đảm bảo rằng phần này của mô hình đủ hợp lý để hỗ trợ việc ủy thác đăng ký và lưu trữ địa chỉ cho cơ sở hạ tầng cơ bản. Cơ chế đồng bộ hóa giao diện kinh doanh độc đáo của Dubbo3 là một lợi thế mà Dubbo3 cần giữ lại và cần được giải quyết thông qua cơ chế riêng của khuôn khổ trên mô hình địa chỉ mới được xác định trong Dubbo3.

Mô hình khám phá dịch vụ mới này mang lại nhiều lợi thế hơn cho Dubbo3 về khả năng tương thích và khả năng mở rộng kiến trúc.

Về khả năng tương thích kiến trúc, như đã đề cập ở trên, Dubbo3 tái sử dụng khả năng trừu tượng hóa dịch vụ của cơ sở hạ tầng cơ bản, điều này giúp thực hiện được điều đó. Mặt khác, các giải pháp dịch vụ vi mô khác trong ngành, chẳng hạn như Spring Cloud, cũng sử dụng mô hình này. Sau khi phát hiện địa chỉ được bật, người dùng có thể khám phá bằng Dubbo để kết nối các hệ thống dịch vụ vi mô không đồng nhất.

Làm thế nào chúng ta có thể hiểu rằng mô hình khám phá dịch vụ Dubbo3 phù hợp hơn cho việc xây dựng hệ thống dịch vụ có khả năng mở rộng? Sau đây là một ví dụ đơn giản để so sánh trực quan những thay đổi trong lưu lượng dữ liệu trong quá trình khám phá địa chỉ giữa Dubbo2 và Dubbo3: giả sử rằng một ứng dụng dịch vụ vi mô xác định 100 giao diện (dịch vụ trong Dubbo), thì 100 dịch vụ cần được đăng ký trong trung tâm đăng ký. Nếu ứng dụng này được triển khai trên 100 máy, thì 100 dịch vụ này sẽ tạo ra tổng cộng 100 * 100 = 10.000 nút ảo; đối với cùng một ứng dụng, đối với Dubbo3, mô hình đăng ký và khám phá mới chỉ yêu cầu 1 dịch vụ (chỉ liên quan đến ứng dụng chứ không phải giao diện) và chỉ đăng ký 1 * 100 = 100 nút ảo bằng với số lượng phiên bản máy vào trung tâm đăng ký. Trong ví dụ đơn giản này, số lượng địa chỉ được Dubbo đăng ký đã giảm xuống còn 1/100 so với con số ban đầu, điều này giúp giảm đáng kể áp lực lưu trữ cho trung tâm đăng ký và người đăng ký. Quan trọng hơn, khả năng khám phá địa chỉ được tách biệt hoàn toàn khỏi định nghĩa RPC doanh nghiệp và việc đánh giá khả năng của toàn bộ cụm sẽ trở nên minh bạch hơn đối với hoạt động và bảo trì: số lượng máy được triển khai sẽ xác định tải, không giống như Dubbo2, trong đó việc tái cấu trúc RPC doanh nghiệp sẽ ảnh hưởng đến tính ổn định của toàn bộ quá trình khám phá dịch vụ cụm.

Kiến trúc triển khai Dubbo3

Bài viết này chủ yếu tập trung vào kiến trúc triển khai trong bối cảnh đám mây gốc, chủ yếu thể hiện ở thực tế là cơ sở hạ tầng (Kubernetes, Service Mesh, v.v.) sẽ đảm nhiệm nhiều trách nhiệm hơn và kiến trúc ba trung tâm như: trách nhiệm của trung tâm đăng ký, trung tâm siêu dữ liệu và trung tâm cấu hình được tích hợp, giúp kiến trúc hoàn hảo hơn và tối ưu hóa tài nguyên toàn diện hơn. Phân tích các thành phần tập trung này giúp chúng ta hiểu rõ hơn cách Dubbo3 hoạt động ở chế độ đám mây gốc.

Từ hình trên, chúng ta có thể thấy rằng trong toàn bộ khuôn khổ Dubbo Rpc, ngoài Consumer, Provider và Registry tương ứng đã được định nghĩa trong Dubbo, còn có thêm hai trung tâm nữa: config-center và metadata.

Hệ thống ba trung tâm của Dubbo3

Là một khuôn khổ dịch vụ vi mô, Dubbo SDK được triển khai ở nhiều vị trí khác nhau của cụm phân tán cùng với các thành phần dịch vụ vi mô. Để đạt được sự cộng tác giữa các thành phần dịch vụ vi mô khác nhau trong môi trường phân tán, Dubbo3 mở rộng một số thành phần tập trung, bao gồm:

Trung tâm đăng ký
- Phối hợp đăng ký địa chỉ và khám phá giữa người tiêu dùng và nhà cung cấp dịch vụ.
Trung tâm cấu hình
- Lưu trữ cấu hình toàn cầu của Dubbo trong giai đoạn khởi động để đảm bảo chia sẻ giữa các môi trường và tính nhất quán toàn cầu của cấu hình
- Chịu trách nhiệm lưu trữ và đẩy các quy tắc quản trị dịch vụ (quy tắc định tuyến, cấu hình động, v.v.).
Trung tâm siêu dữ liệu
- Nhận siêu dữ liệu giao diện dịch vụ được báo cáo bởi máy chủ Nhà cung cấp và cung cấp khả năng vận hành và bảo trì (như thử nghiệm dịch vụ, tài liệu giao diện, v.v.) cho Quản trị viên và các bảng điều khiển khác
- Là phần bổ sung cho cơ chế khám phá dịch vụ, nó cung cấp khả năng đồng bộ hóa thông tin cấu hình cấp độ giao diện/phương pháp, tương đương với phần mở rộng bổ sung của trung tâm đăng ký.

Lưu ý: Ba hệ thống trung tâm trên không phải là điều kiện cần thiết để chạy Dubbo. Người dùng có thể quyết định chỉ bật một hoặc nhiều hệ thống trong số chúng theo điều kiện kinh doanh của riêng họ (kể cả khi không có bất kỳ trung tâm nào, chế độ kết nối trực tiếp, tất nhiên, không được khuyến nghị cho sản xuất) để đơn giản hóa việc triển khai.

Tiếp theo, chúng tôi sẽ giải thích chi tiết về ba trung tâm này.

Trung tâm đăng ký

Trong hầu hết các trường hợp, chúng tôi sẽ bắt đầu phát triển dịch vụ Dubbo với một trung tâm đăng ký độc lập và trung tâm cấu hình cùng trung tâm siêu dữ liệu sẽ được giới thiệu dần dần khi cần thiết trong quá trình phát triển các dịch vụ vi mô.

Sổ đăng ký đóng vai trò rất quan trọng. Nó chịu trách nhiệm đăng ký dịch vụ và khám phá dịch vụ. Hiện tại Dubbo hỗ trợ hai cấp độ khám phá dịch vụ và đăng ký dịch vụ sau: cấp độ giao diện và cấp độ ứng dụng. Trung tâm đăng ký có thể được triển khai khi cần:

Chế độ kết nối trực tiếp

Trong lần sử dụng Dubbo SDK đầu tiên, nếu chỉ cung cấp dịch vụ RPC ở chế độ kết nối trực tiếp thì không cần triển khai trung tâm đăng ký.

Chế độ đăng ký

Cho dù ở cấp độ giao diện hay cấp độ ứng dụng, nếu bạn cần Dubbo SDK để thực hiện đăng ký dịch vụ và khám phá dịch vụ, bạn có thể chọn triển khai một trung tâm đăng ký và tích hợp trung tâm đăng ký tương ứng trong Dubbo.

Chế độ lưới

Trong kịch bản Dubbo + Mesh, khi khả năng đăng ký dịch vụ Dubbo yếu đi, trung tâm đăng ký trong Dubbo không còn là điều bắt buộc nữa và trách nhiệm của nó được thay thế bằng mặt phẳng điều khiển. Nếu phương pháp triển khai Dubbo + Mesh được áp dụng, cho dù đó là phương pháp lưới ThinSDK hay phương pháp lưới Proxyless, thì không còn cần phải triển khai trung tâm đăng ký độc lập nữa.

Trung tâm đăng ký không phụ thuộc vào trung tâm cấu hình và trung tâm siêu dữ liệu

Đối với việc biên soạn, trung tâm đăng ký không hoàn toàn phụ thuộc vào trung tâm cấu hình và trung tâm siêu dữ liệu, như thể hiện trong hình sau.

Nếu trung tâm cấu hình và trung tâm siêu dữ liệu không được triển khai, thì phiên bản của trung tâm đăng ký sẽ được sử dụng làm cả trung tâm cấu hình và trung tâm siêu dữ liệu theo mặc định trong Dubbo. Đây là hành vi mặc định của Dubbo. Nếu khả năng của trung tâm cấu hình hoặc trung tâm siêu dữ liệu thực sự không cần thiết, bạn có thể tắt chúng trong cấu hình. Có hai cấu hình trong cấu hình của trung tâm đăng ký, use-as-config-center và use-as-metadata-center. Đặt cấu hình thành false.

Trung tâm siêu dữ liệu

Trung tâm siêu dữ liệu không được giới thiệu trong Dubbo 3, nhưng đã được hỗ trợ kể từ phiên bản 2.7.x. Với việc triển khai đăng ký dịch vụ cấp ứng dụng và khám phá dịch vụ trong Dubbo, trung tâm siêu dữ liệu ngày càng trở nên quan trọng, như thể hiện trong hình sau.

Sơ đồ trên không bao gồm trung tâm cấu hình, nghĩa là không cần khả năng quản lý cấu hình toàn cầu. Không có trung tâm đăng ký trong hình này, điều đó có nghĩa là giải pháp lưới Dubbo có thể được áp dụng hoặc có thể không cần đăng ký dịch vụ và chỉ nhận các cuộc gọi dịch vụ ở chế độ kết nối trực tiếp. Trung tâm siêu dữ liệu cần được triển khai trong các tình huống sau:

(Kịch bản 1) Di chuyển từ phiên bản cũ của Dubbo sang phiên bản mới của Dubbo3

Đối với dịch vụ ứng dụng ban đầu được xây dựng bằng phiên bản cũ của Dubbo, khi di chuyển sang Dubbo3, Dubbo3 sẽ cần một trung tâm siêu dữ liệu để duy trì mối quan hệ ánh xạ giữa các dịch vụ RPC và ứng dụng (tức là mối quan hệ ánh xạ giữa giao diện và ứng dụng).

Khám phá dịch vụ cấp ứng dụng và đăng ký dịch vụ

Biểu mẫu tổ chức dữ liệu của cấu trúc "danh sách giao diện-thể hiện" trước đây được hiển thị trong hình bên dưới.

Nếu sử dụng khám phá dịch vụ và đăng ký dịch vụ ở cấp ứng dụng, biểu mẫu tổ chức dữ liệu theo cấu trúc "danh sách phiên bản ứng dụng" sẽ được áp dụng tại trung tâm đăng ký, như thể hiện trong hình sau.

Trước đây, khi các dịch vụ ứng dụng sử dụng đăng ký dịch vụ cấp giao diện và khám phá dịch vụ được di chuyển đến cấp ứng dụng, chúng không thể có được mối quan hệ tương ứng giữa giao diện và ứng dụng, do đó không thể có được thông tin danh sách phiên bản từ trung tâm đăng ký. Do đó, để tương thích với kịch bản này, Dubbo sẽ lưu trữ mối quan hệ ánh xạ giữa giao diện và ứng dụng trong trung tâm siêu dữ liệu khi phía Nhà cung cấp được khởi động.

(Kịch bản 2) Để trung tâm đăng ký tập trung nhiều hơn vào khả năng phát hiện địa chỉ và đẩy

Để trung tâm đăng ký tập trung hơn vào khả năng phát hiện và đẩy địa chỉ, đồng thời giảm gánh nặng cho trung tâm đăng ký, trung tâm siêu dữ liệu chứa tất cả siêu dữ liệu dịch vụ, một lượng lớn thông tin cấu hình cấp giao diện/phương thức, v.v. Trung tâm siêu dữ liệu đóng vai trò quan trọng trong việc phát hiện và đăng ký dịch vụ ở cả mức độ chi tiết của giao diện và ứng dụng.

Nếu bạn đáp ứng được hai yêu cầu trên, bạn có thể chọn triển khai trung tâm siêu dữ liệu và tích hợp trung tâm siêu dữ liệu thông qua cấu hình Dubbo. Trung tâm siêu dữ liệu không phụ thuộc vào trung tâm đăng ký và trung tâm cấu hình. Người dùng có thể tự do lựa chọn tích hợp và triển khai trung tâm siêu dữ liệu, như thể hiện trong hình sau:

Có thể thấy rằng người tiêu dùng kéo mối quan hệ giữa giao diện và dịch vụ ứng dụng từ trung tâm siêu dữ liệu. Cùng với mối quan hệ giữa ứng dụng và phiên bản dịch vụ được sổ đăng ký kéo, cả hai tạo thành một định dạng thanh lịch hơn và tối ưu hóa không gian lưu trữ.

Trung tâm đăng ký-Lưu trữ: Tên ứng dụng->Địa chỉ phiên bản dịch vụ giao diện
Trung tâm siêu dữ liệu-Lưu trữ: Tên ứng dụng->Thông tin giao diện+Thông tin tham số

Cả hai có thể được tích hợp trực tiếp vào tên ứng dụng->địa chỉ thể hiện dịch vụ giao diện->thông tin giao diện.

Trung tâm cấu hình

Trung tâm cấu hình khác với hai trung tâm kia. Nó không liên quan gì đến cấp độ giao diện hoặc cấp độ ứng dụng. Nó không có mối quan hệ tương ứng với giao diện. Nó chỉ liên quan đến dữ liệu cấu hình. Ngay cả khi trung tâm đăng ký và trung tâm siêu dữ liệu không được triển khai, trung tâm cấu hình vẫn có thể được kết nối trực tiếp với dịch vụ ứng dụng Dubbo.

Trong toàn bộ kiến trúc triển khai, tất cả các phiên bản trong toàn bộ cụm (cho dù là Nhà cung cấp hay Người dùng) sẽ chia sẻ cấu hình trong cụm trung tâm cấu hình, như thể hiện trong hình sau.

Không có trung tâm đăng ký trong hình này, điều đó có nghĩa là giải pháp lưới Dubbo có thể được áp dụng hoặc có thể không cần đăng ký dịch vụ và chỉ nhận các cuộc gọi dịch vụ ở chế độ kết nối trực tiếp.
Không có trung tâm siêu dữ liệu trong sơ đồ này, điều đó có nghĩa là Consumer có thể lấy siêu dữ liệu dịch vụ từ MetadataService do Provider cung cấp để triển khai các lệnh gọi RPC.

Kiến trúc triển khai để đảm bảo tính khả dụng cao của ba trung tâm

Mặc dù ba trung tâm này không còn cần thiết cho các dịch vụ ứng dụng Dubbo nữa, nhưng trong môi trường sản xuất thực tế, sau khi chúng được tích hợp và triển khai, chúng vẫn sẽ gặp phải các vấn đề về tính khả dụng. Dubbo cần hỗ trợ các giải pháp có tính khả dụng cao cho ba trung tâm này. Dubbo hỗ trợ nhiều trung tâm đăng ký, nhiều trung tâm dữ liệu và nhiều trung tâm cấu hình để đáp ứng nhu cầu của các chế độ kiến trúc triển khai như nhiều trung tâm hoạt động trong cùng một thành phố, ba trung tâm ở hai địa điểm và nhiều trung tâm hoạt động ở các địa điểm khác nhau.

Dubbo SDK hỗ trợ chế độ Nhiều cho cả ba trung tâm.

Nhiều sổ đăng ký: Dubbo hỗ trợ nhiều sổ đăng ký, nghĩa là một giao diện hoặc ứng dụng có thể được đăng ký trong nhiều sổ đăng ký, chẳng hạn như cụm ZK và cụm Nacos. Người tiêu dùng cũng có thể đăng ký thông tin địa chỉ của các dịch vụ liên quan từ nhiều sổ đăng ký để thực hiện khám phá dịch vụ. Bằng cách hỗ trợ nhiều sổ đăng ký, chúng tôi có thể đảm bảo rằng khi một trong các cụm sổ đăng ký không khả dụng, chúng tôi có thể chuyển sang cụm sổ đăng ký khác để đảm bảo rằng các dịch vụ có thể được cung cấp và các cuộc gọi dịch vụ có thể được khởi tạo bình thường. Điều này cũng có thể đáp ứng nhu cầu của trung tâm đăng ký trong việc thích ứng với nhiều chế độ kiến trúc triển khai có tính khả dụng cao khác nhau.
Nhiều trung tâm cấu hình: Dubbo hỗ trợ nhiều trung tâm cấu hình để đảm bảo rằng khi một cụm trung tâm cấu hình không khả dụng, nó có thể chuyển sang cụm trung tâm cấu hình khác, đảm bảo rằng cấu hình toàn cầu, quy tắc định tuyến và thông tin khác có thể được lấy bình thường từ trung tâm cấu hình. Điều này cũng có thể đáp ứng nhu cầu của trung tâm cấu hình trong việc thích ứng với nhiều chế độ kiến trúc triển khai có tính khả dụng cao trong quá trình triển khai.
Nhiều trung tâm dữ liệu: Dubbo hỗ trợ nhiều trung tâm dữ liệu: được sử dụng để xử lý khôi phục sau thảm họa và các tình huống khác khiến cụm trung tâm siêu dữ liệu không khả dụng. Lúc này, bạn có thể chuyển sang cụm trung tâm siêu dữ liệu khác để đảm bảo rằng trung tâm siêu dữ liệu có thể cung cấp khả năng quản lý cho siêu dữ liệu dịch vụ một cách bình thường.

Lấy trung tâm đăng ký làm ví dụ, sau đây là sơ đồ về kiến trúc triển khai của một kịch bản đa hoạt động: