Arsitektur Server Mikro vs Monolitik

Saat ini kami sedang mengerjakan produk / proyek baru kami, ini adalah aplikasi server-klien yang diarahkan ke perusahaan industri / jasa tertentu. Kami sedang membangun server (Hanya Bahasa C dan Linux) yang menjalankan protokol khusus di atas TCP dengan Java front-end. Kami sekitar 20% dalam pekerjaan pengkodean dan dihadapkan pada situasi harus memilih antara Arsitektur Kernel Mikro atau Monolitik.

Saya sadar bahwa Micro vs. Monolithic biasanya terkait dengan arsitektur kernel, tetapi kita secara khusus berbicara tentang server.

Mengapa server khusus dan bukan sesuatu yang ada?

• Kebutuhan UI kami signifikan dan sangat dinamis, sehingga solusi berbasis Web / browser tidak sesuai.
• Pemrosesan statistik sangat penting di ujung klien dan oleh karena itu, sekali lagi, peramban tidak banyak membantu. (Tentu saja, kita bisa melakukan pemrosesan di ujung server dan meneruskan data yang diproses ke klien tapi itu akan menyiratkan banyak beban di server dan pemborosan sumber daya klien).
• Selain itu, dengan minimal tiga teknologi (JS / HTML / CSS) untuk mengelola bahkan satu peristiwa membuat seluruh pengalaman seperti menyapu rumah di tengah-tengah badai gurun - Anda menyapunya berkali-kali, debu menumpuk n + 1 kali.

Bagaimana dengan Server Mikro dan Monolitik? Apa yang kamu bicarakan?

Pertimbangkan permintaan klien (hipotetis) berikut:

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

Saat menerima permintaan seperti itu, server biasanya (kami mengabaikan teknik konkurensi seperti utas dan garpu untuk kesederhanaan):

• Parsing string permintaan
• Identifikasi tindakan (Ambil HistoricDataSets LIMIT Year (2010)dalam kasus kami)
• Berinteraksi dengan lapisan persisten (Oracle, katakanlah, dalam contoh kita) dan ambil datanya.

• Memformat data sesuai protokol. Ex:

  response-id: 123
  success: true
  response-text: DataSets

• Tanggapi klien dengan data yang diformat seperti itu.

Inilah yang kami sebut Server Monolithic (mirip dengan kernel monolitik di mana semua pekerjaan OS dilakukan dalam ruang kernel).

Pertimbangkan permintaan yang sama lagi, saat diterima, kali ini server (kami mengasumsikan hanya memori bersama sebagai IPC, sekali lagi untuk kesederhanaan):

• Masukkan permintaan ke dalam memori bersama untuk Parserproses tersebut
• The Parsermem-parsing string, mengidentifikasi tugas dan mengarahkan Executionerproses untuk melaksanakan tugas-tugas.
• The Executionerkemudian melewati data ke Fomatterproses yang, setelah memformat data menjadi string protokol, kembali ke server.
• Server mengirimkannya ke klien (respons).

Tentu saja, alih-alih Parser, Executionerdan Formatteritu bisa menjadi proses tunggal tetapi terpisah. Ini adalah apa yang kita sebut Server Mikro (mirip dengan kernel mikro melakukan hampir minimum yang diperlukan). Server secara efektif hanya mendengarkan dan merespons sedangkan semua langkah dijaga oleh berbagai proses.

Yang mana yang harus dipilih? Kami bingung! Sementara server monolitik dicoba dan diuji (sebagian besar HTTP-Web Server?) Dan lebih mudah diprogram dan dapat menangani concurrency dengan cukup baik. Server mikro, prima facie, tampak cepat dan sejalan dengan prinsip UNIX dari satu program untuk melakukan satu tugas, tetapi juga rumit untuk dikembangkan, khususnya. menjaga konkurensi dalam pikiran.

Pertanyaan
- Apa (mungkin bisa) pro dan kontra dari setiap pendekatan?
- Kapan menggunakan yang mana? (Bisa juga ditafsirkan sebagai pertanyaan umum: Kapan menggunakan IPC?)
- Jika Micro kernel dipilih, maka fungsi apa yang perlu menjadi bagian dari server inti dan apa yang tidak?

Pertanyaan serupa / Terkait

• Bahaya aplikasi monolitik besar
• Browser Vs Tertanam Eksternal (Tangensial)
• Saran untuk mengubah aplikasi Monolitik menjadi multithreaded (Tangential)

• Calon pelanggan kami dapat dibagi menjadi dua kategori:
  • Besar: Sekitar 1.700 - 2.000 permintaan per menit
  • Kecil: Sekitar 650 - 700 permintaan per menit
• Volume data per siklus permintaan (permintaan dan respons selanjutnya) dapat diasumsikan terdistribusi normal dengan rata-rata ~ 1,20 MB dan lebih buruk lagi sekitar 250-300 MB.
• Konsep produk relatif baru tetapi memiliki kemampuan untuk mempengaruhi operasi inti, oleh karena itu kami berharap anggaran pelanggan menjadi fleksibel hanya mengirim keterlambatan tertentu (9-12 bulan) pasca penempatan, ini membatasi jumlah perangkat keras yang diinginkan klien untuk melakukan esp. yang kecil.
• Setiap pelanggan akan memiliki tumpukan server klien. Server akan berjalan pada perangkat keras pelanggan yang dikelola oleh tim pelanggan, sementara klien akan ditempatkan pada mesin karyawan fungsional
• Pembaruan jarak jauh untuk aplikasi klien dan server adalah suatu keharusan
• PUSHLayanan waktu nyata oleh server mungkin 'sangat' diinginkan jika produk mengklik!

Ekonomi terkadang mengatur jawaban yang jauh lebih kritis daripada teori inti di balik pilihan. Yang paling penting adalah bahwa jika Anda melihat sesuatu yang 'luas' dalam kasus Anda, di mana aplikasi Anda membutuhkan penyebaran yang benar-benar tangguh - semakin sedikit jumlah roda yang Anda buat sendiri, semakin baik. Jika berhasil, saya tidak akan peduli apakah itu monolitik atau mikro; jika tidak saya tidak akan peduli juga!

Mungkin benar bahwa aplikasi berbasis Webpage yang sangat konvensional mungkin tidak cocok untuk Anda - tetapi Anda perlu melihat sedikit lebih luas dan melihat Anda dapat menggunakan hal-hal yang siap digunakan dan kemudian mengembangkan jalan keluar untuk melihat apakah Anda dapat mengganti elemen itu dengan sesuatu lebih baik. Dengan begitu, tidak hanya Anda akan menghemat waktu untuk hal pertama - tetapi Anda juga akan meningkatkan pemahaman Anda tentang apa yang sebenarnya penting dalam kehidupan nyata. Berikut adalah beberapa petunjuk yang dapat Anda pertimbangkan.

1. Jika Anda benar-benar membutuhkan skalabilitas yang sangat tinggi, pertimbangkan bagaimana server Anda akan membagi tugas daripada jumlah churn secepat mereka bisa. Pada akhirnya, Anda akan memiliki beban yang tidak dapat diterima oleh satu server meskipun intel membuat prosesor tercepat di dunia dan pelanggan siap membayar! Jadi permintaan routing dan load balancing lebih penting daripada efisiensi protokol itu sendiri.

2. HTTP masih yang terbaik -jika Anda perlu meningkatkannya. (Anda juga dapat dengan mudah membeli penyeimbang beban jika menggunakannya). Protokol khusus memerlukan pengaturan khusus.

3. HTTP tidak berarti Anda harus memutar HTML, skrip java sama sekali. Bahkan tidak berarti Anda harus memiliki server apache dan browser web biasa. Anda dapat menggunakan HTTP antara dua klien khusus dan elemen-elemen seperti server AOL atau lighthttpd yang dapat digunakan sebagai pustaka jika komunikasi bukanlah transfer data yang sangat besar. Anda juga dapat menggunakan SOAP di kedua sisi dengan tool kit seperti gSOAP .

4. Bahkan jika HTTP jelas tidak sesuai dengan tagihan, pertimbangkan sesuatu seperti BIP , yang membantu Anda membuat segalanya lebih efisien. Atau ada banyak RPC terbukti, mekanisme RMI yang ada.

5. Cobalah untuk melihat bahwa Anda dapat melakukan pekerjaan maksimal lebih banyak dengan melakukan pemrosesan paralel di back-end dan server hanya ditanya ketika pekerjaan selesai. Jika ini berhasil - ada kerangka kerja seperti MPI , atau ada banyak kit alat komputasi terdistribusi yang dapat membantu.

6. Akhirnya, sementara saya mungkin tidak dalam posisi untuk mengetahui kebutuhan yang tepat, tetapi Anda mungkin perlu mendistribusikan banyak data atau melakukan banyak perhitungan, jika Anda membutuhkan keduanya - masih ada beberapa inefisiensi arsitektur inti.

Bagi saya, membuat Protokol baru, dan daripada membuat kerangka server baru adalah eksperimen ganda yang tidak boleh Anda lakukan bersama. Jika taruhan Anda sangat tinggi, pertama-tama Anda harus benar-benar mencoba untuk bereksperimen dengan alat yang ada untuk melihat batas apa yang telah dilakukan sejauh ini - hanya kemudian Anda akan tahu tantangan yang sebenarnya.

Lebih banyak yang telah dicapai dalam penelitian sistem terdistribusi dari sekedar aplikasi web. Jadi Anda harus meneliti itu.

Dipan.

Ini sepertinya sangat akademis bagi saya. Dan sejujurnya, saya menemukan pendekatan kedua sama monolitiknya. Ini sejauh yang Anda harus lakukan:

1. Pisahkan permintaan itu
2. Tangani permintaan

Penangan permintaan yang dipilih berdasarkan parameter permintaan harus merangkum semua aspek penanganan permintaan. Apakah pawang benar-benar melakukan kueri pada penyimpanan data Anda dan apakah ia menggunakan pemformatan standar atau tidak untuk mengembalikan data tidak relevan dari lapisan di atas. Faktanya, itu mungkin akan melakukan hal itu, tetapi tidak ada nilai dalam membuat asumsi tentang hal itu.

1. Kernel monolitik jauh lebih tua dari Microkernel . Ini digunakan di Unix. sementara Ide microkernel muncul pada akhir 1980 - an .

2. contoh os memiliki kernel Monolithic adalah UNIX, LINUX sedangkan os memiliki Microkernel adalah QNX, L4, HURD , awalnya Mach (bukan mac os x) kemudian akan dikonversi menjadi hybrid kernel, bahkan MINIX bukan kernel murni karena driver perangkat dikompilasi sebagai bagian dari kernel.

3. Kernel monolitik lebih cepat dari microkernel . sedangkan The microkernel Mach pertama adalah 50% lebih lambat dari kernel Monolithic sedangkan versi kemudian seperti L4 hanya 2% atau 4% lebih lambat dari kernel Monolithic .

4. Kernel monolitik umumnya besar . sementara Pure monolithic kernel harus berukuran kecil bahkan pas di cache tingkat pertama prosesor (microkernel generasi pertama).

5. di driver perangkat kernel Monolitik berada di ruang kernel . sementara dalam driver perangkat Microkernel berada di ruang pengguna .

6. karena driver perangkat berada di dalam ruang kernel, itu membuat kernel monolitik kurang aman daripada microkernel. (Kegagalan dalam pengemudi dapat menyebabkan crash) sementara Microkernels lebih aman daripada kernel monolitik yang digunakan dalam beberapa perangkat militer.

7. Kernel monolitik menggunakan sinyal dan soket untuk memastikan IPC sementara pendekatan microkernel menggunakan antrian pesan . 1 gen microkernel mengimplementasikan IPC dengan buruk sehingga lambat pada sakelar konteks.

8. menambahkan fitur baru ke sistem monolitik berarti mengkompilasi ulang seluruh kernel sementara Anda dapat menambahkan fitur atau tambalan baru tanpa mengkompilasi ulang .