Cara seni bina Java digunakan pada produk yang berbeza

Apabila kita menyediakan sistem, kita biasanya perlu mempertimbangkan cara untuk berinteraksi dengan sistem lain, jadi kita perlu mengetahui terlebih dahulu cara pelbagai sistem berinteraksi antara satu sama lain dan teknologi yang digunakan untuk melaksanakannya.

1. Interaksi antara sistem yang berbeza dan bahasa yang berbeza

Pada masa kini, interaksi biasa kami antara sistem yang berbeza dan bahasa yang berbeza menggunakan permintaan WebService dan Http. WebService, iaitu, "Perkhidmatan Web", disingkatkan sebagai WS. Difahamkan secara literal, ia sebenarnya adalah "perkhidmatan berasaskan web". Tetapi perkhidmatan adalah untuk kedua-dua pihak Jika ada permintaan perkhidmatan, akan ada penyedia perkhidmatan. Pembekal perkhidmatan menerbitkan perkhidmatan kepada dunia luar, dan peminta perkhidmatan memanggil perkhidmatan yang diterbitkan oleh pembekal perkhidmatan. Untuk meletakkannya secara lebih profesional, WS sebenarnya adalah alat yang dibina pada protokol HTTP untuk mencapai komunikasi sistem heterogen. betul! Secara terang-terangan, WS adalah berdasarkan protokol HTTP, iaitu, data dihantar melalui HTTP. Pada mulanya kami menggunakan CXF untuk membangunkan perkhidmatan SOAP untuk melaksanakan WS, dan kemudian kami menggunakan perkhidmatan REST untuk melaksanakan WS (ini lebih kerap digunakan pada masa ini, dan ia juga yang paling saya gunakan). Perkhidmatan REST juga boleh dibangunkan berdasarkan CXF, tetapi kami biasanya menggunakan springMVC atau rangka kerja MVC lain secara langsung untuk melaksanakan perkhidmatan REST.

Tetapi dalam fikiran ramai orang, perkhidmatan Web secara amnya merujuk kepada pelbagai teknologi interaktif berasaskan XML yang diterajui oleh IBM lebih daripada sepuluh tahun yang lalu, kecuali beberapa syarikat, hanya sedikit orang yang menggunakannya. Dalam erti kata yang luas, Perkhidmatan Web ialah perkhidmatan Web, dan semuanya adalah perkhidmatan.

2. Interaksi antara sistem berbeza dengan bahasa yang sama

Interaksi biasa antara sistem berbeza dengan bahasa yang sama menggunakan RPC (Panggilan Prosedur Jauh), atau RMI (Kaedah Jauh call) dilaksanakan tanpa menyediakan perkhidmatan luaran Sudah tentu, yang disebutkan di atas juga boleh digunakan untuk interaksi antara bahasa yang sama, tetapi saya biasanya menggunakan RPC.

Seni bina produk yang berbeza

3 Seni bina evolusi produk tunggal

Secara amnya, proses evolusi seni bina apabila kita hanya satu produk, jika perlu Untuk menyediakan webService kepada dunia luar, ia biasanya dilaksanakan menggunakan perkhidmatan REST.

Kandungan berikut berasal dari Zhihu

1) Evolusi seni bina teragih Evolusi seni bina sistem - seni bina peringkat awal

Pada peringkat awal, semua sumber aplikasi sistem kecil, pangkalan data, fail, dll. berada pada satu pelayan, biasanya dikenali sebagai LAMP

Ciri: aplikasi, pangkalan data, fail Tunggu sehingga semua sumber berada pada satu pelayan.

Penerangan: Biasanya sistem pengendalian pelayan menggunakan Linux, aplikasi dibangunkan menggunakan PHP, dan kemudian digunakan pada Apache, pangkalan data menggunakan Mysql, dan pelbagai perisian sumber terbuka percuma dan pelayan murah boleh memulakan pembangunan daripada sistem.

2) Evolusi seni bina sistem - pengasingan perkhidmatan aplikasi dan perkhidmatan data

Masa yang baik tidak bertahan lama, dan didapati bahawa dengan peningkatan dalam bilangan lawatan sistem meningkat semula, tekanan pada mesin pelayan web akan meningkat ke tahap yang agak tinggi semasa tempoh puncak Pada masa ini, pertimbangkan untuk menambah pelayan web

Ciri: Aplikasi , pangkalan data dan fail digunakan pada sumber bebas.

Penerangan: Jumlah data meningkat, prestasi dan ruang storan pelayan tunggal tidak mencukupi, dan aplikasi dan data perlu diasingkan keupayaan pemprosesan serentak dan ruang storan data telah dipertingkatkan dengan banyak.

3) Evolusi seni bina sistem - menggunakan cache untuk meningkatkan prestasi

Ciri: Sebahagian kecil data dalam pangkalan data adalah diakses dengan lebih intensif Disimpan dalam pelayan cache, mengurangkan bilangan capaian pangkalan data dan mengurangkan tekanan capaian pada pangkalan data.

Penerangan: Ciri akses sistem mengikut peraturan 80/20, iaitu, 80% akses perniagaan tertumpu pada 20% data. Cache dibahagikan kepada cache tempatan dan cache teragih jauh Cache tempatan mempunyai kelajuan akses yang lebih cepat tetapi jumlah data cache adalah terhad Pada masa yang sama, ia mungkin bersaing dengan aplikasi untuk memori.

4) Evolusi seni bina sistem - menggunakan kluster pelayan aplikasi

Selepas menyiapkan kerja sub-pustaka dan sub-jadual, pangkalan data Tekanan ke atas sistem telah menurun ke tahap yang agak rendah, dan saya telah mula menjalani kehidupan yang bahagia melihat bilangan lawatan meningkat setiap hari Tiba-tiba suatu hari, saya mendapati bahawa akses kepada sistem telah mula perlahan Pada masa ini, saya mula-mula memeriksa pangkalan data. Tekanan Semuanya adalah normal permintaan adalah terlalu tinggi, yang menyebabkan keperluan untuk menunggu dalam talian dan kelajuan tindak balas menjadi lebih perlahan

Ciri : Berbilang pelayan menyediakan perkhidmatan ke luar pada masa yang sama melalui pengimbangan beban, menyelesaikan masalah kuasa pemprosesan dan had ruang storan bagi satu pelayan.

Penerangan: Menggunakan kluster ialah kaedah biasa untuk sistem menyelesaikan masalah konkurensi tinggi dan data besar-besaran. Dengan menambahkan sumber pada kluster, keupayaan pemprosesan serentak sistem dipertingkatkan, supaya tekanan beban pelayan tidak lagi menjadi hambatan bagi keseluruhan sistem.

5) Evolusi seni bina sistem - pemisahan baca dan tulis pangkalan data

Selepas menikmati kebahagiaan pertumbuhan pesat dalam lawatan sistem untuk tempoh masa, saya mendapati bahawa Sistem mula perlahan semula Apakah keadaan kali ini, selepas mencari, saya mendapati bahawa persaingan sumber beberapa sambungan pangkalan data untuk operasi penulisan dan pengemaskinian pangkalan data sangat sengit, menyebabkan sistem menjadi perlahan.

Ciri: Berbilang pelayan menyediakan perkhidmatan ke luar pada masa yang sama melalui pengimbangan beban, menyelesaikan masalah kuasa pemprosesan dan had ruang storan pelayan tunggal.

Penerangan: Menggunakan kluster ialah kaedah biasa untuk sistem menyelesaikan masalah konkurensi tinggi dan data besar-besaran. Dengan menambahkan sumber pada kluster, tekanan beban pada pelayan tidak lagi menjadi hambatan bagi keseluruhan sistem.

6) Evolusi seni bina sistem - proksi songsang dan pecutan CDN

Ciri-ciri: Menggunakan CDN dan proksi songsang untuk mempercepatkan akses sistem kelajuan.

Penerangan: Untuk menghadapi persekitaran rangkaian yang kompleks dan akses daripada pengguna di rantau yang berbeza, CDN dan proksi terbalik digunakan untuk mempercepatkan akses pengguna sambil mengurangkan tekanan beban pada pelayan bahagian belakang. Prinsip asas CDN dan proksi terbalik ialah caching.

7) Evolusi seni bina sistem - sistem fail teragih dan pangkalan data teragih

Apabila sistem terus berjalan, data Jumlah mula meningkat dengan ketara Pada masa ini, saya mendapati bahawa pertanyaan masih akan agak perlahan selepas pangkalan data dibahagikan, jadi saya mula mengusahakan pembahagian jadual mengikut idea sub-pangkalan data

Ciri: Pangkalan data menggunakan pangkalan data teragih, dan sistem fail menggunakan sistem fail Teragih.

Penerangan: Mana-mana pelayan tunggal yang berkuasa tidak dapat memenuhi keperluan perniagaan yang berkembang secara berterusan bagi sistem berskala besar dan pangkalan data yang diedarkan perlu digunakan untuk menyokong. Pangkalan data teragih ialah satu-satunya cara untuk memisahkan pangkalan data sistem Ia hanya digunakan apabila skala data jadual tunggal adalah sangat besar Kaedah pemisahan pangkalan data yang lebih biasa digunakan ialah sub-pangkalan data perniagaan, yang menggunakan pangkalan data perniagaan yang berbeza pada pelayan fizikal yang berbeza. .

8) Evolusi seni bina sistem - menggunakan NoSQL dan enjin carian

Ciri-ciri: Sistem ini memperkenalkan pangkalan data NoSQL dan enjin carian.

Penerangan: Apabila perniagaan menjadi semakin kompleks, keperluan untuk penyimpanan dan pengambilan data menjadi semakin kompleks Sistem perlu menggunakan beberapa pangkalan data bukan perhubungan seperti NoSQL dan pertanyaan sub-pangkalan data teknologi seperti enjin carian. Pelayan aplikasi mengakses pelbagai data melalui modul capaian data bersatu, mengurangkan masalah aplikasi menguruskan banyak sumber data.

9) Evolusi seni bina sistem - pembahagian perniagaan

Ciri-ciri: Sistem dipecah dan diubah mengikut perniagaan, pelayan aplikasi Gunakan secara berasingan mengikut pembezaan perniagaan.

Penerangan: Untuk menghadapi senario perniagaan yang semakin kompleks, kaedah bahagi dan takluk biasanya digunakan untuk membahagikan keseluruhan perniagaan sistem kepada barisan produk yang berbeza Perhubungan diwujudkan antara aplikasi melalui hiperpautan, dan data juga boleh diedarkan melalui baris gilir mesej Sudah tentu Apatah lagi, sistem berkaitan yang lengkap dibentuk dengan mengakses sistem penyimpanan data yang sama. Pemisahan menegak: Pisahkan aplikasi besar kepada berbilang aplikasi kecil Jika perniagaan baharu secara relatifnya bebas, maka reka bentuk dan gunakannya secara langsung sebagai sistem aplikasi Web bebas adalah agak mudah dibahagikan kepada aplikasi yang lebih kecil Perniagaan yang berkaitan boleh dilupuskan. Pemisahan mendatar: Pisahkan perniagaan yang digunakan semula dan gunakannya secara bebas sebagai perkhidmatan yang diedarkan hanya perlu memanggil perkhidmatan yang diedarkan ini memerlukan mengenal pasti perniagaan yang boleh digunakan semula, mereka bentuk antara muka perkhidmatan dan menyeragamkan kebergantungan perkhidmatan.

10) Evolusi seni bina sistem - perkhidmatan teragih

S: Apakah masalah yang akan dihadapi oleh aplikasi perkhidmatan?

(1) Apabila semakin banyak perkhidmatan, pengurusan konfigurasi URL perkhidmatan menjadi sangat sukar, dan tekanan satu titik pada pengimbang beban perkakasan F5 juga semakin meningkat.

(2) Apabila ia berkembang lebih jauh, kebergantungan antara perkhidmatan menjadi sangat rumit sehingga tidak jelas aplikasi mana yang harus dimulakan sebelum aplikasi mana yang tidak dapat menerangkan sepenuhnya hubungan seni bina aplikasi itu.

(3) Kemudian, apabila bilangan panggilan ke perkhidmatan meningkat, masalah kapasiti perkhidmatan terdedah Berapa banyak mesin yang perlu disokong oleh perkhidmatan ini? Bilakah saya perlu menambah mesin?

(4) Dengan lebih banyak perkhidmatan, kos komunikasi telah mula meningkat kepada siapa yang harus saya hubungi jika pelarasan perkhidmatan tertentu gagal? Apakah konvensyen untuk parameter perkhidmatan?

(5) Jika perkhidmatan mempunyai berbilang pengguna perniagaan, bagaimana untuk memastikan kualiti perkhidmatan?

(6) Apabila perkhidmatan terus ditingkatkan, beberapa perkara yang tidak dijangka selalu berlaku. Contohnya, cache ditulis dengan salah, menyebabkan limpahan memori tidak dapat dielakkan Setiap kali perkhidmatan teras gagal, ia menjejaskan kawasan yang besar orang panik. Bagaimana untuk mengawal kesan kegagalan? Bolehkah perkhidmatan diturunkan taraf fungsinya? Atau kemerosotan sumber?

Ini nampaknya merupakan permulaan kepada prinsip teras dan analisis kes seni bina teknikal tapak web berskala besar, tetapi penulis meringkaskannya dengan baik, jadi saya akan mencetak semula.

4. Struktur barisan produk

Satu lagi ialah pembahagian perniagaan yang dinyatakan di atas. Sekarang kita perlu membina barisan produk Kita hanya memerlukan lapisan data, lapisan logik perniagaan umum, dan pelbagai lapisan aplikasi dan antara muka di hadapan dahulu, kami biasanya Kami memilih untuk menggunakan EJB untuk membina aplikasi teragih, tetapi kini kami boleh menggunakan rangka kerja RPC seperti dobbo, jimat, avro, dan hessian untuk membina aplikasi teragih untuk mencapai interaksi antara aplikasi dan sumber data yang berbeza. Di bawah model struktur ini, kami perlu menyediakan perkhidmatan kepada syarikat lain, dan kami boleh menulis aplikasi khusus untuk menyediakan perkhidmatan rehat kepada sistem luaran. Secara amnya, kebanyakan perkhidmatan Internet perlu mengakses sedozen atau bahkan ratusan perkhidmatan dalaman, dan kaedah komunikasi antara mereka secara amnya adalah RPC: sama seperti mengakses kaedah jauh, parameter input dan tunggu hasilnya dikembalikan. Ini adalah cara yang paling mudah difahami untuk membina sistem yang kompleks.

Seperti yang ditunjukkan di bawah, model, sistem fail dan cache tidak ditunjukkan, jadi semua orang boleh memahaminya.

Atas ialah kandungan terperinci Cara seni bina Java digunakan pada produk yang berbeza. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!