【Tóm tắt】

Chuyển đổi từ kiến trúc dịch vụ phân tán Apache Dubbo sang Spring Cloud và triển khai lên nền tảng đám mây Huawei.

【Bối cảnh】

Trong quá trình hỗ trợ xây dựng một hệ thống, yêu cầu sử dụng kiến trúc đám mây nguyên sinh. Hệ thống được phát triển hoàn toàn dựa trên mô hình này, hiện đang trong giai đoạn cải tiến và chuyển đổi dịch vụ phân tán. Kế hoạch chia nhỏ thành hai hệ thống con: nội bộ và đối ngoại. Hệ thống đối ngoại sẽ áp dụng kiến trúc Spring Cloud, còn hệ thống nội bộ vẫn giữ lại kiến trúc Dubbo. Việc triển khai sử dụng CCE và CSE (nền tảng quản lý dịch vụ phân tán) trên nền tảng đám mây chính phủ, cùng với các dịch vụ khác không được đề cập chi tiết.

【Vấn đề】

1. Hệ thống nội bộ sử dụng kiến trúc Dubbo, tuy nhiên nền tảng CSE của nhà cung cấp đám mây chính phủ chỉ hỗ trợ framework ServiceComb (tương thích với Spring Cloud), không hỗ trợ Dubbo → cần phải thực hiện cải tiến kiến trúc.

2. Sau khi cải tiến, làm thế nào để thực hiện việc di chuyển?

【Quy trình và giải pháp】

【Ý tưởng ban đầu】

1. Có cách nào tránh phải thay đổi framework, ví dụ như sử dụng middleware hoặc agent?

2. Đánh giá mức độ khó khăn và khối lượng công việc khi chuyển từ Dubbo sang Spring Cloud, cùng với kế hoạch cải tiến;

3. Kế hoạch di chuyển sau khi cải tiến.

【Framework dịch vụ phân tán】

(Tham khảo "Whitepaper về Kiến trúc Nguyên sinh của Alibaba Cloud"): Trước đây, các framework phát triển phần mềm truyền thống thường là những hệ thống monolithic lớn, ảnh hưởng mạnh đến toàn bộ ứng dụng khi có thay đổi. Để giải quyết vấn đề này, mô hình dịch vụ phân tán ra đời. Kiến trúc này giải quyết tận gốc các vấn đề về khả năng mở rộng và ổn định vốn có trong ứng dụng monolithic. Trong thời đại đám mây nguyên sinh, việc sử dụng container và engine Kubernetes giúp tận dụng tối đa tính sẵn sàng và bảo mật của tài nguyên đám mây, mang lại sự linh hoạt, khả dụng và an toàn tốt hơn cho ứng dụng. Ứng dụng được xây dựng trên hạ tầng và dịch vụ cơ sở do đám mây cung cấp, tận dụng tiện ích, độ ổn định mà các dịch vụ đám mây mang lại, đồng thời giảm thiểu độ phức tạp trong kiến trúc. Kiến trúc dịch vụ phân tán đám mây nguyên sinh cũng giúp nâng cấp toàn diện kiến trúc ứng dụng, mang lại khả năng quan sát, kiểm soát, và chịu lỗi tự nhiên.

Sự phát triển của kiến trúc dịch vụ phân tán trải qua nhiều giai đoạn, dẫn đến sự xuất hiện của nhiều framework khác nhau. Hiện nay, Spring Cloud là framework phổ biến nhất. Tuy nhiên, nó cũng đã trải qua quá trình tích lũy lâu dài để trở nên phổ biến như ngày nay. Khi một framework trở nên phổ biến, nó cũng bắt đầu đối mặt với sự thay thế từ các framework mới hơn.

Các mô hình kiến trúc điển hình theo thứ tự phát triển gồm bốn thế hệ:

• Thế hệ thứ nhất: Trong mô hình dịch vụ phân tán, ứng dụng phải tự xử lý các vấn đề như định địa chỉ, giao tiếp giữa các dịch vụ và khả năng chịu lỗi. Khi quy mô dịch vụ tăng lên, logic tìm kiếm địa chỉ trở nên phức tạp hơn, thậm chí ngay cả khi dùng cùng ngôn ngữ lập trình, các chức năng cơ bản này đều phải được tái hiện.

• Thế hệ thứ hai: Giới thiệu trung tâm đăng ký dịch vụ như một bên điều phối, tự động hóa việc đăng ký và phát hiện dịch vụ. Giao tiếp giữa các dịch vụ và cơ chế chịu lỗi bắt đầu được mô-đun hóa thành framework độc lập. Tuy nhiên, khi các chức năng trong framework ngày càng phong phú, việc tái sử dụng các chức năng bằng ngôn ngữ khác trở nên khó khăn, khiến người phát triển bị ràng buộc vào ngôn ngữ cụ thể, vi phạm nguyên tắc linh hoạt trong phát triển dịch vụ phân tán.

• Thế hệ thứ ba: Mô hình service mesh. Các chức năng cơ bản của dịch vụ phân tán được tách khỏi framework và chuyển thành một tiến trình riêng biệt gọi là Sidecar. Sự thay đổi này giải quyết triệt để vấn đề hỗ trợ đa ngôn ngữ trong thế hệ thứ hai, tách biệt hoàn toàn giữa chức năng nền tảng dịch vụ và logic nghiệp vụ. Kiến trúc này chính là mô hình dịch vụ phân tán nguyên sinh trong thời đại đám mây - Cloud Native Microservices. Sidecar đảm nhận luồng giao tiếp giữa các ứng dụng, thực hiện các chức năng như phát hiện dịch vụ, chịu lỗi, và quản trị dịch vụ như định tuyến trọng số, định tuyến xám, tái phát luồng dữ liệu, giả lập dịch vụ...

• Thế hệ thứ tư: Kiến trúc Serverless được sử dụng gần đây. Trong mô hình này, dịch vụ phân tán được đơn giản hóa thành các logic nhỏ gọi là Micrologic, đặt ra yêu cầu cao hơn đối với mô hình sidecar, nhiều chức năng phân tán có thể tái sử dụng được tách ra khỏi ứng dụng và đưa xuống sidecar, như quản lý trạng thái, ràng buộc tài nguyên, theo dõi chuỗi, quản lý giao dịch, bảo mật... Đồng thời, phát triển hướng tới lập trình cục bộ (localhost), cung cấp API tiêu chuẩn để che giấu sự khác biệt của hạ tầng, dịch vụ và tài nguyên, giảm độ phức tạp trong phát triển dịch vụ phân tán. Đây là mô hình đa runtime microservices (Muti-Runtime Microservices) được giới thiệu trong ngành.

Rõ ràng, xu hướng phát triển của dịch vụ phân tán là tách rời các chức năng có thể tái sử dụng khỏi ứng dụng, để ứng dụng tập trung vào logic nghiệp vụ, trong khi các đặc điểm quan trọng liên quan đến hạ tầng, cấu hình, phát hiện dịch vụ, quản trị dịch vụ và vận hành được trừu tượng hóa xuống lớp thấp hơn. Nói cách khác: nghiệp vụ thuộc về nghiệp vụ, vận hành thuộc về vận hành.

Trong quá trình phát triển, đã hình thành nhiều framework dịch vụ phân tán với sự khác biệt rõ rệt về thế hệ:

1. Apache Dubbo: Framework RPC mã nguồn mở từ Alibaba, có khả năng cân bằng tải thông minh, tự động đăng ký và phát hiện dịch vụ, khả năng mở rộng cao, định tuyến luồng thời gian thực và quản trị dịch vụ trực quan. Là framework phổ biến nhất tại Trung Quốc, đã xây dựng hệ sinh thái mạnh mẽ và mở rộng các công cụ như Spring Cloud-Alibaba, Nacos, Sentinel, Seata, Chaosblade. Alibaba cũng đang phát triển Dubbo theo hướng Service Mesh.

2. Spring Cloud: Là lựa chọn hàng đầu cho dịch vụ phân tán, tích hợp quản lý cấu hình, phát hiện dịch vụ, circuit breaker và các công cụ phát triển. Đặc biệt với Java là ngôn ngữ phát triển chủ đạo, Spring Cloud cung cấp mô hình lập trình cơ bản cho dịch vụ phân tán Java, đồng thời dễ dàng tích hợp với kiến trúc Service Mesh.

3. TAF: Framework dịch vụ phân tán nội bộ của Tencent, hỗ trợ quản trị dịch vụ và đa ngôn ngữ.

4. ServiceComb: Xuất phát từ Huawei Cloud Microservice Engine (CSE), được mở rộng năm 2017.

5. Dapr: Framework serverless có thể di chuyển của Microsoft.

Trong dự án này, Huawei Cloud CSE hỗ trợ dịch vụ phân tán, tương thích với Spring Cloud và ServiceComb. Nếu là ứng dụng ServiceComb, có thể tích hợp mà không cần sửa đổi mã nguồn; nếu là Spring Cloud, chỉ cần một vài sửa đổi; nếu là Dubbo thì không thể tích hợp trực tiếp.

【Quy trình】

1. Sermant Agent

Trang web chính thức giới thiệu Sermant Agent là một công nghệ service mesh không cần agent dựa trên JavaAgent. Nó hỗ trợ đăng ký vào engine ServiceComb thông qua việc sử dụng nhãn định tuyến (label routing). Dựa trên thông tin trong attachment của Dubbo, nó chuyển hướng lưu lượng phù hợp đến ứng dụng có nhãn tương ứng, thực hiện chức năng định tuyến nhãn.

Tuy nhiên, giải pháp này chỉ hỗ trợ phiên bản Dubbo từ 2.6.x đến 2.7.x, và chỉ được bật ở một số AZ công cộng. Dự án hiện đang sử dụng Dubbo phiên bản 2.0, việc nâng cấp framework là không khả thi.

2. Chuyển đổi framework Dubbo sang Spring Cloud và tích hợp vào engine CSE

Khối lượng công việc khi chuyển đổi framework có thể đánh giá từ hai góc độ: mức độ phụ thuộc của mã nguồn nghiệp vụ vào framework cũ và mức độ hỗ trợ của framework mục tiêu đối với các công nghệ sử dụng trong mã nguồn.

Theo đánh giá từ các chuyên gia, mức độ khó khăn khi chuyển từ Dubbo sang CSE là trung bình (4).

Để chuyển đổi từ Dubbo sang Spring Cloud, cần giải quyết các vấn đề chính sau:

• Chuyển định nghĩa interface RPC thành REST;
• Thay đổi cách gọi RPC thành Feign;
• Sửa đổi mối quan hệ phụ thuộc và file cấu hình;

Các vấn đề khác như sửa class khởi động, xử lý xung đột thư viện bên ngoài cũng cần được giải quyết.

Xem thêm: https://github.com/huaweicse/migrator/wiki/dubbo-2-cse

Từ góc độ kỹ thuật, việc này không quá phức tạp, có thể thực hiện tự động bằng migrator. Tuy nhiên, điều này đòi hỏi trình độ chuẩn mã nguồn của nhóm phát triển và sự hiểu biết về framework mới. Ví dụ:

• ModifyDubboAction bao gồm các hành động sau:
• ModifyDubboServiceAction: Quét tất cả file Java, tìm và thay thế @DubboService bằng @RestController.
• ModifyDubboReferenceAction: Quét và thay thế @DubboReference bằng @FeignClient.
• ModifyDubboInterface2RestAction: Phân tích các interface chứa @DubboService, chuyển đổi thành REST style.
• ModifyDubboAddBootstrapYamlAction: Thêm file bootstrap.yml vào thư mục src/main/resources.
• ModifyDubboMainClassAction: Tìm hàm main, chuyển đổi logic @EnableDubbo sang Spring Boot.
• ModifyDubboPomAction: Xóa các dependency/plugin liên quan đến Dubbo, thêm các dependency/plugin của Spring Cloud.

Các hành động này phụ thuộc rất nhiều vào cấu trúc mã nguồn gốc, do đó chất lượng và tiêu chuẩn mã nguồn trước khi cải tiến là yếu tố quyết định.

3. Tích hợp sau khi cải tiến vào CSE

Nếu đã là ứng dụng Spring Cloud, không cần sửa đổi mã nguồn, có thể sử dụng spring-cloud-starter-huawei-service-engine để kết nối với CSE. Đây là một bộ công cụ dựa trên Spring Cloud, cung cấp các thành phần mới để tích hợp với CSE.

A. Thêm dependency:

<dependency>
    <groupId>com.huaweicloud</groupId>
    <artifactId>spring-cloud-starter-huawei-service-engine</artifactId>
</dependency>

<dependency>
    <groupId>com.huaweicloud</groupId>
    <artifactId>spring-cloud-starter-huawei-service-engine-gateway</artifactId>
</dependency>

B. Kết nối với dịch vụ đăng ký và phát hiện:

spring:
  application:
    name: basic-provider
  cloud:
    servicecomb:
      discovery:
        enabled: true
        address: http://127.0.0.1:30100
        appName: basic-application
        serviceName: ${spring.application.name}
        version: 0.0.1
        healthCheckInterval: 30
      config:
        serverAddr: http://127.0.0.1:30113
      watch:
        delay: 10000

C. Cấu hình thông tin dịch vụ và engine CSE:

credentials:
  enabled: true
  accessKey: your AK
  secretKey: your SK
  akskCustomCipher: default
  project: cn-north-4