Mengapa kami membuang seni bina sistem Reaktif daripada kod kami?

Artikel ini meneroka keputusan kami untuk beralih daripada seni bina reaktif dalam projek perisian kami. Kami akan menyelidiki prinsip teras sistem reaktif, faedah I/O tanpa sekatan dan cabaran yang kami hadapi dengan pendekatan reaktif.

Memahami gaya seni bina Reaktif

Reaktif merangkumi satu set prinsip dan garis panduan yang bertujuan untuk membina sistem dan aplikasi teragih responsif, dicirikan oleh:

1. Responsif: Mampu mengendalikan permintaan dengan pantas, walaupun di bawah beban berat.
2. Ketahanan: Mampu pulih daripada kegagalan dengan masa henti yang minimum.
3. Keanjalan: Boleh menyesuaikan diri dengan perubahan beban kerja dengan menskalakan sumber dengan sewajarnya.
4. Didorong Mesej: Menggunakan pemesejan tak segerak untuk meningkatkan toleransi kesalahan dan memisahkan komponen.

Satu faedah utama sistem reaktif ialah penggunaan I/O yang tidak menyekat. Pendekatan ini mengelak daripada menyekat benang semasa operasi I/O, membenarkan satu utas mengendalikan berbilang permintaan secara serentak. Ini boleh meningkatkan kecekapan sistem dengan ketara berbanding I/O penyekatan tradisional.
Dalam multithreading tradisional, operasi menyekat menimbulkan cabaran besar dalam mengoptimumkan sistem (Rajah 1). Aplikasi tamak yang menggunakan memori yang berlebihan adalah tidak cekap dan menghukum aplikasi lain, selalunya memerlukan permintaan untuk sumber tambahan seperti memori, CPU atau mesin maya yang lebih besar.

Rajah 1 – Benang Berbilang Tradisional

---

Operasi I/O adalah penting kepada sistem moden, dan mengurusnya dengan cekap adalah penting untuk mengelakkan tingkah laku tamak. Sistem reaktif menggunakan I/O tanpa sekatan, membolehkan bilangan urutan OS yang rendah untuk mengendalikan banyak operasi I/O serentak.

Model Perlaksanaan Reaktif

Walaupun I/O tanpa sekatan menawarkan faedah yang besar, ia memperkenalkan model pelaksanaan baru yang berbeza daripada rangka kerja tradisional. Pengaturcaraan reaktif muncul untuk menangani isu ini, kerana ia mengurangkan ketidakcekapan benang platform yang melahu semasa operasi menyekat (Rajah 2).

Rajah 2 – Gelung Peristiwa Reaktif

---

Quarkus dan Reaktif

Quarkus memanfaatkan enjin reaktif yang dikuasakan oleh Eclipse Vert.x dan Netty, memudahkan interaksi I/O yang tidak menyekat. Pemberontakan, pendekatan pilihan untuk menulis kod reaktif dengan Quarkus, mengamalkan paradigma terdorong peristiwa, di mana tindak balas dicetuskan oleh peristiwa yang diterima.

Mutiny menawarkan dua jenis dipacu acara dan malas:

1. Uni: Memancarkan satu peristiwa (item atau kegagalan), sesuai untuk mewakili tindakan tak segerak dengan sifar atau satu hasil.
2. Berbilang: Memancarkan berbilang peristiwa (n item, satu kegagalan atau satu penyiapan), mewakili aliran item, berpotensi tidak terhad.

Cabaran dengan Reaktif

Walaupun sistem reaktif menawarkan faedah, kami menghadapi beberapa cabaran semasa pembangunan:

• Anjakan Paradigma: Pengaturcaraan reaktif memerlukan peralihan asas dalam pemikiran pembangun, yang boleh mencabar, terutamanya bagi pembangun yang terbiasa dengan pengaturcaraan imperatif. Tidak seperti alat bantu seperti Streams API, pendekatan reaktif memerlukan baik pulih minda yang lengkap.
• Kebolehbacaan dan Pemahaman Kod: Kod reaktif menimbulkan kesukaran untuk difahami oleh pembangun baharu, yang membawa kepada peningkatan masa yang dihabiskan untuk mentafsir dan memahaminya. Kerumitan yang diperkenalkan oleh paradigma reaktif menggabungkan isu ini.

"Sememangnya, nisbah masa yang dihabiskan untuk membaca berbanding menulis adalah melebihi 10 berbanding 1. Kami sentiasa membaca kod lama sebagai sebahagian daripada usaha untuk menulis kod baharu. ...[Oleh itu,] menjadikannya mudah dibaca menjadikan lebih mudah untuk menulis."
― Robert C. Martin, Kod Bersih: Buku Panduan Ketukangan Perisian Agile

• Cabaran Penyahpepijatan: Penyahpepijatan kod reaktif terbukti hampir mustahil dengan penyahpepijat IDE standard disebabkan oleh lambdas yang merangkumi kebanyakan kod. Selain itu, kehilangan surih tindanan yang bermakna semasa pengecualian menghalang usaha penyahpepijatan lagi. Meningkatkan Usaha Pembangunan dan Pengujian: Kerumitan yang wujud bagi kod reaktif boleh membawa kepada kitaran pembangunan yang lebih lama disebabkan oleh masa yang diperlukan untuk menulis, mengubah suai dan menguji.

Berikut ialah contoh kod reaktif menggunakan Mutiny untuk menggambarkan kerumitan:

Multi.createFrom().ticks().every(Duration.ofSeconds(15))
    .onItem().invoke(() - > Multi.createFrom().iterable(configs())
    .onItem().transform(configuration - > {
  try {
    return Tuple2.of(openAPIConfiguration,
        RestClientBuilder.newBuilder()
            .baseUrl(new URL(configuration.url()))
            .build(MyReactiveRestClient.class)
            .getAPIResponse());

  } catch (MalformedURLException e) {
    log.error("Unable to create url");

  }
  return null;
}).collect().asList().toMulti().onItem().transformToMultiAndConcatenate(tuples - > {

  AtomicInteger callbackCount = new AtomicInteger();
  return Multi.createFrom().emitter(emitter - > Multi.createFrom().iterable(tuples)
      .subscribe().with(tuple - >
          tuple.getItem2().subscribe().with(response - > {
              emitter.emit(callbackCount.incrementAndGet());

  if (callbackCount.get() == tuples.size()) {
    emitter.complete();
  }
                    })
                ));

}).subscribe().with(s - > {},
Throwable::printStackTrace, () - > doSomethingUponComplete()))
    .subscribe().with(aLong - > log.info("Tic Tac with iteration: " + aLong));

Tinjauan Masa Depan-Projek Loom and Beyond

Project Loom, pembangunan terbaru dalam ekosistem Java, berjanji untuk mengurangkan isu yang berkaitan dengan operasi menyekat. Dengan mendayakan penciptaan beribu-ribu utas maya tanpa perubahan perkakasan, Project Loom berpotensi menghapuskan keperluan untuk pendekatan reaktif dalam banyak kes.

"Project Loom akan membunuh Pengaturcaraan Reaktif"
―Brian Goetz

Kesimpulan

Kesimpulannya, keputusan kami untuk beralih daripada gaya seni bina reaktif pendekatan pragmatik kepada kebolehselenggaraan jangka panjang projek kami. Walaupun sistem reaktif menawarkan potensi manfaat, cabaran yang mereka kemukakan untuk pasukan kami mengatasi kelebihan tersebut dalam konteks khusus kami.

Yang penting, peralihan ini tidak menjejaskan prestasi. Ini adalah hasil yang positif, kerana ia menunjukkan bahawa seni bina bukan reaktif(imperatif) yang direka dengan baik boleh memberikan prestasi yang diperlukan tanpa kerumitan yang dikaitkan dengan seni bina reaktif dalam kes kami.

Sambil kita melihat ke arah masa depan, tumpuan kekal pada membina pangkalan kod yang bukan sahaja berfungsi tetapi juga mudah difahami dan diselenggara untuk pembangun semua peringkat pengalaman. Ini bukan sahaja mengurangkan masa pembangunan tetapi juga memupuk kerjasama yang lebih baik dan perkongsian pengetahuan dalam pasukan.

Dalam graf di bawah, paksi-X mewakili peningkatan kerumitan pangkalan kod kami semasa ia berkembang, manakala paksi-Y menggambarkan masa yang diperlukan untuk perubahan perkembangan ini.

Atas ialah kandungan terperinci Mengapa kami membuang seni bina sistem Reaktif daripada kod kami?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!