Cách gỡ lỗi ứng dụng Spring WebFlux

Gỡ lỗi ứng dụng Spring WebFlux có thể là một nhiệm vụ đầy thách thức, đặc biệt là khi xử lý các luồng phản ứng phức tạp. Không giống như các ứng dụng chặn truyền thống, trong đó theo dõi ngăn xếp cung cấp dấu hiệu rõ ràng về nguyên nhân cốt lõi của sự cố, các ứng dụng phản ứng có thể khó gỡ lỗi hơn. Các vấn đề như mã chặn, sự cố đồng thời và điều kiện chủng tộc đều có thể gây ra các lỗi tinh vi khó chẩn đoán. Kịch bản Khi xử lý một lỗi, không phải lúc nào vấn đề cũng liên quan đến mã. Nó có thể là một tập hợp các yếu tố, chẳng hạn như tái cấu trúc gần đây, thay đổi nhóm, thời hạn khó khăn, v.v. Trong cuộc sống thực, việc khắc phục sự cố các ứng dụng lớn được tạo bởi những người đã rời công ty một thời gian trước đây và bạn mới tham gia là một điều phổ biến. Biết một chút về miền và công nghệ sẽ không giúp cuộc sống của bạn dễ dàng hơn. Trong ví dụ mã bên dưới, tôi muốn tưởng tượng mã lỗi có thể trông như thế nào đối với một người mới tham gia nhóm. Hãy coi việc gỡ lỗi mã này giống như một hành trình hơn là thử thách. Nguyên nhân gốc rễ có thể rõ ràng đối với những người đã quen thuộc với các ứng dụng Phản ứng. Tuy nhiên, một số thực hành dưới đây vẫn có thể rất hữu ích để sửa đổi. @GetMapping("/greeting/{firstName}/{lastName}") public Mono greeting(@PathVariable String firstName, @PathVariable String lastName) { return Flux.fromIterable(Arrays.asList(firstName, lastName)) .filter(this::wasWorkingNiceBeforeRefactoring) .transform(this::senselessTransformation) .collect(Collectors.joining()) .map(names -> "Hello, " + names); } private boolean wasWorkingNiceBeforeRefactoring(String aName) { // We don't want to greet with John, sorry return !aName.equals("John"); } private Flux senselessTransformation(Flux flux) { return flux .single() .flux() .subscribeOn(Schedulers.parallel()); } Vì vậy, những gì đoạn mã này thực hiện là: Nó thêm “Xin chào,” vào các tên được cung cấp dưới dạng tham số. Đồng nghiệp John của bạn đang nói với bạn rằng mọi thứ đều hoạt động trên máy tính xách tay của anh ấy. Đúng: > curl localhost:8080/greeting/John/Doe > Hello, Doe Nhưng khi bạn chạy nó như , bạn sẽ thấy stacktrace tiếp theo: curl localhost:8080/greeting/Mick/Jagger java.lang.IndexOutOfBoundsException: Source emitted more than one item at reactor.core.publisher.MonoSingle$SingleSubscriber.onNext(MonoSingle.java:134) ~[reactor-core-3.5.5.jar:3.5.5] Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: Error has been observed at the following site(s): *__checkpoint ⇢ Handler com.example.demo.controller.GreetingController#greeting(String, String) [DispatcherHandler] *__checkpoint ⇢ HTTP GET "/greeting/Mick/Jagger" [ExceptionHandlingWebHandler] Original Stack Trace: at java.base/java.util.concurrent.FutureTask.run(FutureTask.java) ~[na:na] (4 internal lines) Tốt, không có dấu vết nào dẫn đến mẫu mã ở trên. Tất cả những gì nó tiết lộ là 1) nó xảy ra trong phương thức , và 2) máy khách đã thực hiện `HTTP GET "/greeting/Mick/Jagger GreetingController#greeting .doOnError() Điều đầu tiên và dễ dàng nhất để thử là thêm lệnh gọi lại `.doOnError()` vào cuối chuỗi lời chào. @GetMapping("/greeting/{firstName}/{lastName}") public Mono greeting(@PathVariable String firstName, @PathVariable String lastName) { return Flux.fromIterable(Arrays.asList(firstName, lastName)) // .doOnError(e -> logger.error("Error while greeting", e)); } Cố gắng tốt, nhưng các bản ghi không cho thấy bất kỳ sự cải thiện nào. Tuy nhiên, dấu vết ngăn xếp nội bộ của Lò phản ứng: Dưới đây là một số cách có thể/không thể hữu ích trong quá trình gỡ lỗi: doOnError : Bạn có thể sử dụng để ghi nhật ký thông báo lỗi và cung cấp thêm ngữ cảnh về những gì đã xảy ra trong luồng phản ứng của bạn. Điều này có thể đặc biệt hữu ích khi gỡ lỗi sự cố trong một luồng phức tạp có nhiều toán tử. Ghi nhật ký doOnError : cũng có thể được sử dụng để khôi phục lỗi và tiếp tục xử lý luồng. Ví dụ: bạn có thể sử dụng để cung cấp giá trị hoặc luồng dự phòng trong trường hợp có lỗi. Khôi phục doOnError onErrorResume : rất có thể sẽ không cung cấp bất kỳ dấu vết ngăn xếp nào tốt hơn ngoại trừ những gì bạn đã thấy trong nhật ký. Đừng dựa vào nó như một trình khắc phục sự cố tốt. Gỡ lỗi doOnError nhật ký() Điểm dừng tiếp theo là thay thế lệnh gọi phương thức đã thêm trước đó bằng lệnh gọi phương thức . Đơn giản như nó được. quan sát tất cả các tín hiệu Luồng phản ứng và theo dõi chúng vào các bản ghi dưới cấp INFO theo mặc định. doOnError() log() log() Bây giờ hãy xem thông tin bổ sung nào chúng tôi thấy trong nhật ký: Chúng ta có thể xem những phương thức Phản ứng nào đã được gọi ( , và ). Ngoài ra, việc biết các luồng (nhóm) mà các phương thức này đã được gọi từ đâu có thể là thông tin rất hữu ích. Tuy nhiên, nó không liên quan đến trường hợp của chúng tôi. onSubscribe request onError Giới thiệu về nhóm chủ đề Tên chủ đề là viết tắt của . Các phương thức phản hồi và đã được thực thi trên nhóm luồng IO (bộ lập lịch). Các tác vụ này đã được thực thi ngay lập tức trên một chuỗi đã gửi chúng. ctor-http-nio-2 reactor-http-nio-2 onSubscribe() request() Bằng cách có bên trong , chúng tôi đã hướng dẫn Reactor đăng ký các phần tử khác trên nhóm luồng khác. Đó là lý do tại sao đã được thực thi trên song song. .subscribeOn(Schedulers.parallel()) senselessTransformation onError parallel-1 Bạn có thể đọc thêm về thread pool . trong bài viết này cho phép bạn thêm các câu lệnh ghi nhật ký vào luồng của mình, giúp theo dõi luồng dữ liệu và chẩn đoán sự cố dễ dàng hơn. Nếu chúng tôi có luồng dữ liệu phức tạp hơn với những thứ như FlatMap, chuỗi con, chặn cuộc gọi, v.v., thì chúng tôi sẽ được hưởng lợi nhiều từ việc đăng nhập tất cả. Đó là một điều rất dễ dàng và tốt đẹp để sử dụng hàng ngày. Tuy nhiên, chúng ta vẫn chưa biết nguyên nhân gốc rễ. log() Hooks.onOperatorDebug() Hướng dẫn yêu cầu Reactor bật chế độ gỡ lỗi cho tất cả các toán tử trong luồng phản ứng, cho phép thông báo lỗi chi tiết hơn và dấu vết ngăn xếp. Hooks.onOperatorDebug() Theo tài liệu chính thức: Khi các lỗi được phát hiện sau này, chúng sẽ được bổ sung thêm bằng một Ngoại lệ bị chặn nêu chi tiết ngăn xếp dây chuyền lắp ráp ban đầu. Phải được gọi trước khi các nhà sản xuất (ví dụ: Flux.map, Mono.fromCallable) thực sự được gọi để chặn đúng thông tin ngăn xếp. Hướng dẫn nên được gọi một lần mỗi lần chạy. Một trong những nơi tốt nhất sẽ là các lớp Cấu hình hoặc Chính. Đối với trường hợp sử dụng của chúng tôi, nó sẽ là: public Mono greeting(@PathVariable String firstName, @PathVariable String lastName) { Hooks.onOperatorDebug(); return // } Bằng cách thêm cuối cùng chúng ta cũng có thể đạt được tiến bộ trong cuộc điều tra của mình. Stacktrace hữu ích hơn nhiều: Hooks.onOperatorDebug() Và trên dòng 42, chúng tôi có . single() Đừng cuộn lên, biến sẽ xuất hiện tiếp theo: senselessTransformation private Flux senselessTransformation(Flux flux) { return flux .single() // line 42 .flux() .subscribeOn(Schedulers.parallel()); } Đó là nguyên nhân sâu xa. phát ra một mục từ nguồn Flux hoặc báo hiệu cho một nguồn có nhiều hơn một phần tử. Điều đó có nghĩa là thông lượng trong phương thức phát ra nhiều hơn 1 mục. Bằng cách đi lên trong phân cấp cuộc gọi, chúng ta thấy rằng ban đầu có một Flux với hai phần tử . single() IndexOutOfBoundsException Flux.fromIterable(Arrays.asList(firstName, lastName)) Phương pháp lọc loại bỏ một mục khỏi một dòng khi nó bằng . Đó là lý do tại sao mã này hoạt động cho một trường đại học tên là John. Huh. wasWorkingNiceBeforeRefactoring John có thể đặc biệt hữu ích khi gỡ lỗi các luồng phản ứng phức tạp, vì nó cung cấp thông tin chi tiết hơn về cách luồng đang được xử lý. Tuy nhiên, việc bật chế độ gỡ lỗi có thể ảnh hưởng đến hiệu suất ứng dụng của bạn (do dấu vết ngăn xếp đã điền), do đó, chế độ này chỉ nên được sử dụng trong quá trình phát triển và gỡ lỗi chứ không phải trong quá trình sản xuất. Hooks.onOperatorDebug() trạm kiểm soát Để đạt được hiệu quả gần như tương tự như mang lại với tác động hiệu suất tối thiểu, có một toán tử đặc biệt. Nó sẽ bật chế độ gỡ lỗi cho phần đó của luồng, trong khi phần còn lại của luồng không bị ảnh hưởng. Hooks.onOperatorDebug() checkpoint() Hãy thêm hai điểm kiểm tra sau khi lọc và sau khi chuyển đổi: public Mono greeting(@PathVariable String firstName, @PathVariable String lastName) { return Flux.fromIterable(Arrays.asList(firstName, lastName)) .filter(this::wasWorkingNiceBeforeRefactoring) /* new */ .checkpoint("After filtering") .transform(this::senselessTransformation) /* new */ .checkpoint("After transformation") .collect(Collectors.joining()) .map(names -> "Hello, " + names); } Hãy nhìn vào các bản ghi: Bảng phân tích điểm kiểm tra này cho chúng tôi biết rằng lỗi đã được quan sát thấy sau điểm kiểm tra thứ hai được mô tả là . Điều đó không có nghĩa là điểm kiểm tra đầu tiên chưa đạt được trong quá trình thực thi. Đúng như vậy, nhưng lỗi chỉ bắt đầu xuất hiện sau lỗi thứ hai. Đó là lý do tại sao chúng tôi không thấy . Sau khi chuyển đổi Sau khi lọc Bạn cũng có thể thấy thêm hai điểm kiểm tra được đề cập trong bảng phân tích, từ và . Họ đã đạt được sau cuộc gọi mà chúng tôi đã đặt, theo thứ bậc cuộc gọi. DispatcherHandler ExceptionHandlingWebHandler Bên cạnh mô tả, bạn có thể buộc Reactor tạo stacktrace cho điểm kiểm tra của mình bằng cách thêm làm tham số thứ hai cho phương thức . Điều quan trọng cần lưu ý là stacktrace được tạo sẽ dẫn bạn đến dòng có điểm kiểm tra. Nó sẽ không điền vào stacktrace cho ngoại lệ ban đầu. Vì vậy, nó không có nhiều ý nghĩa vì bạn có thể dễ dàng tìm thấy điểm kiểm tra bằng cách cung cấp mô tả. true checkpoint() Phần kết luận Bằng cách làm theo các phương pháp hay nhất này, bạn có thể đơn giản hóa quy trình gỡ lỗi cũng như nhanh chóng xác định và giải quyết các sự cố trong ứng dụng Spring WebFlux của mình. Cho dù bạn là nhà phát triển dày dạn kinh nghiệm hay mới bắt đầu lập trình phản ứng, những mẹo này sẽ giúp bạn cải thiện chất lượng và độ tin cậy của mã, đồng thời mang lại trải nghiệm tốt hơn cho người dùng của bạn.