Pengurusan urus niaga di bawah seni bina perkhidmatan mikro Spring Cloud

Memandangkan perniagaan perusahaan terus berkembang, satu aplikasi selalunya tidak dapat mengendalikan pemprosesan perniagaan berskala besar. Seni bina perkhidmatan mikro ialah penyelesaian yang muncul mengikut keperluan masa Ia membahagikan sistem aplikasi yang besar kepada beberapa unit perkhidmatan kecil Setiap unit perkhidmatan boleh dibangunkan, digunakan, dikendalikan, diselenggara dan ditingkatkan secara bebas. Seni bina ini boleh meningkatkan fleksibiliti dan kebolehskalaan aplikasi dengan banyak, di samping mengurangkan gandingan antara pembangun dan mempercepatkan pembangunan dan lelaran aplikasi.

Dalam seni bina perkhidmatan mikro, permintaan perniagaan perlu memanggil berbilang unit perkhidmatan untuk diselesaikan, yang membawa isu yang sangat penting: pengurusan transaksi. Kerana jika permintaan perniagaan melibatkan berbilang unit perkhidmatan, ia mesti dipastikan bahawa unit perkhidmatan ini boleh berada di bawah pengurusan urus niaga yang sama, sama ada diserahkan bersama atau digulung semula, untuk memastikan ketekalan data. Jika tidak, pelbagai masalah akan berlaku, seperti penyerahan berulang, data tidak konsisten, dsb.

Di bawah seni bina perkhidmatan mikro Spring Cloud, secara amnya terdapat tiga cara untuk mengurus urus niaga yang diedarkan:

1. Tulis kod pengurusan transaksi setempat
2. Gunakan Mekanisme Transaksi perisian tengah mesej
3. Penyelesaian berdasarkan rangka kerja pengurusan transaksi teragih

Di bawah saya akan memperkenalkan dan membandingkan ketiga-tiga penyelesaian ini masing-masing untuk memilih penyelesaian yang paling sesuai untuk menangani isu pengurusan Transaksi yang diedarkan.

1. Tulis kod pengurusan transaksi tempatan

Idea penyelesaian ini ialah: setiap unit perkhidmatan mengekalkan pengurus transaksi tempatan secara dalaman apabila unit perkhidmatan tertentu perlu diproses data Semasa beroperasi, mula-mula buka urus niaga, laksanakan operasi data, dan kemudian lakukan atau gulung semula transaksi.

Contohnya: Jika sistem pesanan perlu memanggil sistem akaun untuk melaksanakan operasi pemindahan, maka sistem pesanan akan sama ada memasukkan data pesanan terus ke dalam pangkalan datanya sendiri, atau memasukkan data pesanan ke dalam konteks pengurus transaksi tempatan bagi data pesanan. Kemudian, sistem pesanan memanggil perkhidmatan pemindahan sistem akaun untuk melaksanakan operasi pemindahan Pengurus urus niaga tempatan juga mesti didayakan di dalam perkhidmatan pemindahan untuk memastikan keatoman dan ketekalan operasi. Akhir sekali, jika semuanya berjalan lancar, sistem pesanan boleh melakukan transaksi, jika tidak, ia akan melancarkan transaksi tersebut.

Kelebihan penyelesaian ini ialah ia mudah dan mudah difahami tidak perlu bergantung pada komponen tambahan dan boleh dilaksanakan terus menggunakan anotasi @Transactional yang disediakan oleh Spring. Kelemahannya ialah ia memerlukan penulisan manual kod pengurusan transaksi dan tidak cukup fleksibel. Di samping itu, jika operasi perniagaan memerlukan panggilan berbilang sistem perkhidmatan pihak ketiga, pelaksanaan penyelesaian ini akan menjadi sangat rumit.

2. Menggunakan mekanisme transaksi perisian tengah mesej

Idea penyelesaian ini adalah menggunakan ciri baris gilir mesej untuk mencapai pengurusan transaksi. Apabila permintaan perniagaan perlu memanggil berbilang unit perkhidmatan, ia mula-mula meletakkan permintaan itu ke dalam baris gilir mesej, dan kemudian setiap unit perkhidmatan mendapat permintaan daripada baris gilir mesej dan memprosesnya. Jika baris gilir mesej menyokong ciri transaksi, maka operasi pemprosesan ini akan berada dalam urus niaga yang sama, sama ada diserahkan bersama atau digulung semula bersama.

Contohnya: Jika sistem pesanan perlu memanggil sistem logistik untuk operasi penghantaran, maka sistem pesanan akan menerbitkan mesej "permintaan penghantaran" dalam baris gilir mesej. Sistem logistik juga mesti melanggan mesej ini Selepas menerima mesej, ia akan menjalankan operasi penghantaran Selepas operasi berjaya, transaksi akan diserahkan, jika tidak, transaksi akan ditarik balik. Jika sistem pesanan juga perlu mengendalikan pangkalan data tempatannya sendiri, maka sistem pesanan juga perlu mengambil bahagian dalam transaksi baris gilir mesej.

Kelebihan penyelesaian ini ialah ia boleh mengelak daripada menulis kod pengurusan transaksi secara manual dan boleh memastikan ketekalan dan atomicity transaksi. Kelemahannya ialah ia perlu bergantung pada baris gilir mesej Konfigurasi dan penyelenggaraan baris gilir mesej akan menjadi lebih rumit, dan jika skala sistem besar, daya tampung dan kelewatan baris gilir mesej akan menjadi hambatan.

3. Penyelesaian berdasarkan rangka kerja pengurusan transaksi teragih

Idea penyelesaian ini ialah menggunakan rangka kerja pengurusan transaksi teragih pihak ketiga untuk melaksanakan pengurusan transaksi. Sebagai contoh, urus niaga teragih silang perkhidmatan boleh dilaksanakan dengan mudah menggunakan rangka kerja Seata Alibaba.

Contohnya: Jika sistem pesanan perlu memanggil sistem akaun untuk operasi pemindahan, maka sistem pesanan boleh memanggil perkhidmatan transaksi teragih yang disediakan oleh rangka kerja Seata untuk membuat transaksi teragih. Kemudian, kedua-dua sistem pesanan dan sistem akaun boleh mengambil bahagian dalam pengurusan urus niaga yang diedarkan ini, melaksanakan operasi data, dan kemudian menyerahkan atau tarik balik transaksi bersama-sama. Apabila menggunakan rangka kerja Seata, anda perlu menetapkan konfigurasi yang sepadan dalam setiap unit perkhidmatan Konfigurasi ini termasuk parameter yang berkaitan dengan sumber data dan transaksi yang diedarkan.

Kelebihan penyelesaian ini ialah ia menggunakan rangka kerja pengurusan transaksi teragih yang matang, yang boleh mengelakkan masalah pengurusan urus niaga ke tahap yang paling besar dan mempunyai kebolehskalaan yang kukuh. Kelemahannya ialah konfigurasi tambahan dan pelarasan kod diperlukan, dan kerumitan pengurusan akan meningkat apabila terdapat banyak unit perkhidmatan dan proses perniagaan.

Tiga penyelesaian di atas masing-masing mempunyai kelebihan dan keburukan tersendiri Anda perlu memilih penyelesaian yang paling sesuai berdasarkan keperluan perniagaan dan reka bentuk sistem. Sudah tentu, dalam projek sebenar, anda mungkin menghadapi lebih banyak situasi istimewa yang perlu dikendalikan secara fleksibel.

Untuk seni bina perkhidmatan mikro Spring Cloud, pengurusan transaksi merupakan isu yang mesti dipertimbangkan Jika transaksi tidak dikendalikan dengan betul, ia akan membawa bahaya tersembunyi yang besar kepada perniagaan. Oleh itu, dalam reka bentuk dan pembangunan seni bina, adalah perlu untuk mematuhi prinsip dan amalan terbaik pengurusan transaksi teragih dengan tegas dan mengurangkan kerumitan pengurusan transaksi teragih sebanyak mungkin untuk memastikan kebolehpercayaan dan kestabilan aplikasi.

Atas ialah kandungan terperinci Pengurusan urus niaga di bawah seni bina perkhidmatan mikro Spring Cloud. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!