Mikro ve Monolitik Sunucu mimarisi

Şu anda yeni ürün / projemiz üzerinde çalışıyoruz, belirli belirli sanayi / hizmet işletmelerine yönelik bir istemci-sunucu uygulamasıdır. TCP'nin üstünde Java ön uçlu özel bir protokol çalıştıran bir sunucu (Sadece C Dili ve Linux) kuruyoruz. Kodlama işinin yaklaşık% 20'sindeyiz ve Mikro veya Monolitik Çekirdek Mimarisi arasında seçim yapmak zorunda olan bir durumla karşı karşıyayız.

Micro vs. Monolithic'in genellikle çekirdek mimarisiyle ilişkili olduğunun farkındayım, ancak özellikle sunuculardan bahsediyoruz.

Neden var olan bir şey değil, özel bir sunucu?

• Kullanıcı arayüzü ihtiyaçlarımız önemli ve çok dinamik olduğundan Web / Web tarayıcı tabanlı çözümler uygun değildi.
• İstatistiksel işlem, istemci sonunda önemlidir ve bu nedenle, tarayıcılar çok az yardımcı olmuştur. (Tabii ki, işlemi sunucu sonunda yapabilir ve işlenen verileri istemciye aktarabiliriz, ancak bu sunucuda çok fazla yük ve istemci kaynaklarının israfı anlamına gelir).
• Dahası, tek bir olayı bile yönetmek için en az üç teknoloji (JS / HTML / CSS) ile, tüm deneyimi bir çöl fırtınasının ortasında evi süpürmek gibi yapar - n-kez süpürürsünüz, toz n + 1 kez birikir.

Mikro ve Monolitik Sunucu ne olacak? Ne konuşuyorsun?

Aşağıdaki (varsayımsal) istemci isteğini göz önünde bulundurun:

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

Böyle bir isteği alırken, bir sunucu genellikle (basitlik için iplik ve çatal gibi eşzamanlılık tekniklerini göz ardı ediyoruz):

• İstek dizesini ayrıştırın
• Eylemi tanımlayın ( HistoricDataSets LIMIT Year (2010)Bizim durumumuzda getirin)
• Kalıcılık katmanıyla etkileşime geçin (Oracle, örneğimizde diyelim) ve verileri getirin.

• Verileri protokole göre biçimlendirin. Ör:

  response-id: 123
  başarı: gerçek
  yanıt metni: DataSets

• Bu şekilde biçimlendirilmiş verilerle istemciye yanıt verin.

Biz buna Monolithic Server diyoruz (tüm OS işlemlerinin çekirdek alanında yapıldığı monolitik bir çekirdeğe benzer).

Aynı isteği, makbuzda, bu sefer sunucu üzerinde tekrar düşünün (basitlik için tekrar IPC olarak yalnızca paylaşılan belleği varsaydık):

• İsteği Parserişlem için paylaşılan belleğe koyar
• ParserGörevi tanımlar, dizeyi ayrıştırır ve yönlendirir Executionergörevleri yürütmek için süreç.
• ExecutionerDaha sonra veri geçer Fomatterişlemi, hangi bir protokol dizesine veri biçimlendirme sonra, sunucu döner.
• Sunucu istemciye gönderir (yanıt).

Tabii ki, yerine Parser, Executionerve Formatterbu tek ama ayrı bir süreç olabilirdi. Biz buna Micro Server diyoruz (gerekli olan zar zor minimum bir mikro çekirdeğe benzer). Sunucu etkili bir şekilde sadece dinliyor ve yanıt veriyorken, tüm adımlar farklı süreç (ler) tarafından halledilir.

Hangisini seçmeli? Kafamız karıştı! Monolitik sunucular denenip test edilirken (çoğu HTTP-Web Sunucusu?) Ve programlanması daha kolaydır ve eşzamanlılığı oldukça iyi idare edebilir. Mikro sunucular, prima facie, bir program yapmak için bir programın UNIX prensibine göre hızlı ve hızlı görünmektedir, ancak aynı zamanda geliştirilmesi karmaşıktır, esp. eşzamanlılığı akılda tutarak.

Soru (lar)
- Her yaklaşımın artıları ve eksileri nelerdir (muhtemelen olabilir)?
- Hangisi ne zaman kullanılır? (Ayrıca genel bir soru olarak da yorumlanabilir: IPC ne zaman kullanılır?)
- Mikro çekirdek seçilirse, hangi işlevlerin çekirdek sunucunun bir parçası olması gerekir, ne yapılmaz?

Benzer / İlgili sorular

• Büyük monolitik uygulama tehlikeleri
• Harici Vs Gömülü tarayıcı (Teğet)
• Monolitik uygulamayı çoklu iş parçacığına dönüştürme (Teğet)

• Potansiyel müşterilerimiz iki kategoriye ayrılabilir:
  • Büyük: Dakikada yaklaşık 1.700 - 2.000 istek
  • Küçük: Dakikada yaklaşık 650 - 700 istek
• Talep döngüsü başına veri hacminin (talep ve sonraki yanıt) normal olarak ortalama ~ 1.20 MB ve daha kötü durumda yaklaşık 250-300 MB ile dağıtıldığı varsayılabilir.
• Ürün konsepti nispeten yenidir ancak çekirdek operasyonları etkileme yeteneğine sahiptir, bu nedenle müşteri bütçelerinin, dağıtımdan sonra belirli bir gecikme (9-12 ay) sonra esnek olmasını bekleriz, bu da müşterinin istediği donanım miktarını sınırlar esp. küçük olanlar.
• Her müşterinin kendi istemci-sunucu yığını olacaktır. Sunucu, müşterinin ekibi tarafından yönetilen müşterinin donanımında çalışacak, istemciler ise işlevsel çalışanların makinelerine dağıtılacak
• Hem istemci hem de sunucu uygulaması için uzaktan güncellemeler bir zorunluluktur
• PUSHÜrün tıklarsa, sunucunun gerçek zamanlı hizmetleri 'çok' istenebilir!

Ekonomi bazen seçimlerin ardındaki temel teoriden çok daha kritik bir cevabı yönetir. En önemli şey, uygulamanızın gerçekten zor bir dağıtım gerektirdiği durumda büyük bir şeye bakıyorsanız - kendinizi icat ettiğiniz tekerlek sayısı ne kadar azsa, o kadar iyidir. Eğer çalışırsa, monolitik veya mikro olup olmadığı umurumda değil; eğer ben de umurumda değil!

Web sayfası tabanlı çok geleneksel uygulamaların sizin için uygun olmayabileceği doğru olabilir - ancak biraz daha geniş bir bakış atmanız ve gitmeye hazır şeyleri kullanabileceğinizi görmeniz ve daha sonra bu öğeyi bir şeyle değiştirip değiştiremeyeceğinizi görmek için çıkış yolunuzu geliştirmeniz gerekir. daha iyi. Bu şekilde, ilk şey için sadece zamandan tasarruf etmekle kalmaz, aynı zamanda gerçek hayatta önemli olan şey hakkındaki anlayışınızı da geliştirirsiniz. İşte aklınıza gelebilecek bazı işaretçiler.

1. Gerçekten çok yüksek ölçeklendirilebilirliğe ihtiyacınız varsa, sunucularınızın sayıları olabildiğince hızlı çalkalamak yerine görevi nasıl böleceğini düşünün. Sonunda, intel dünyadaki en hızlı işlemciyi yapıyor ve müşteri ödemeye hazır olsa bile bir sunucunun gerçekten alamadığı bir yüke sahip olacaksınız! Bu nedenle, istek yönlendirme ve yük dengeleme protokolün verimliliğinden daha önemlidir.

2. HTTP hala en iyisidir - ölçeklendirmeniz gerekiyorsa. (Ayrıca kullanırsanız yük dengeleyicileri de satın alabilirsiniz). Özel protokol özel düzenlemeler gerektirir.

3. HTTP, HTML, java betiği atmanız gerektiği anlamına gelmez. Normal bir apache sunucusuna ve web tarayıcısına sahip olmanız gerektiği anlamına gelmez. İki büyük istemci ve iletişim çok büyük bir veri aktarımı değilse, kütüphane olarak kullanılabilen AOL sunucusu veya lighthttpd gibi öğeler arasında HTTP kullanabilirsiniz . GSOAP gibi araç kitleriyle SOAP'ı her iki tarafta da kullanabilirsiniz .

4. HTTP kesinlikle faturaya uymasa bile , işleri daha verimli hale getirmenize yardımcı olan BEEP gibi bir şey düşünün . Alternatif olarak, kanıtlanmış birçok RPC, RMI mekanizması vardır.

5. Arka uçta paralel işleme yaparak maksimum işi daha fazla yapabileceğinizi görmeye çalışın ve sunucular yalnızca iş yapıldığında sorgulanır. Bu çalışırsa -orada gibi çerçeveler vardır MPI veya Yardımcı olabileceğimiz başka birçok dağıtık bilgi işlem aracı kitleri vardır.

6. Son olarak, tam ihtiyaçları bilecek bir konumda olmasam da, ikisine de ihtiyacınız varsa, çok fazla veri dağıtmanız veya çok fazla hesaplama yapmanız gerekebilir - hala bazı temel mimari verimsizlikler var.

Bana göre, yeni bir Protokol oluşturmak ve yeni bir sunucu çerçevesi oluşturmak yerine, birlikte yapmamanız gereken çift bir deneydir. Bahisleriniz çok yüksekse, öncelikle şu ana kadar yapılanların sınırlarını görmek için mevcut araçları denemelisiniz - ancak o zaman gerçek zorlukları bileceksiniz.

Dağıtılmış sistemlerin araştırılmasında sadece web uygulamalarından çok daha fazlası gerçekleştirildi. Bunu araştırmalısınız.

Dipan.

Bu bana çok akademik geliyor. Açıkçası, ikinci yaklaşımı aynı monolitik olarak görüyorum. Bu, gitmeniz gerektiği kadarıyla:

1. İsteği ayrıştırın
2. İsteği yerine getirme

İstek parametrelerine dayanarak seçilen istek işleyici, talebin ele alınmasının tüm yönlerini kapsamalıdır. İşleyicinin veri deponuzda gerçekten sorgular gerçekleştirip gerçekleştirmediği ve verileri döndürmek için standart biçimlendirme kullanıp kullanmadığı yukarıdaki katmanla ilgisizdir. Nitekim, muhtemelen sadece bunu yapacak, ancak bu konuda varsayımlarda bulunmanın bir değeri yok.

1. Monolitik çekirdek Mikrokernel'den çok daha eskidir . Unix'te kullanılır. mikro çekirdek fikri 1980'lerin sonunda ortaya çıktı .

2. Monolitik çekirdeklere sahip os örneği UNIX, LINUX , Microkernel'e sahip os ise QNX, L4, HURD , başlangıçta Mach (mac os x değil), daha sonra hibrid çekirdeğe dönüştürülecek, MINIX bile saf çekirdek değil çünkü aygıt sürücüsü çekirdeğin bir parçası olarak derlendi.

3. Monolitik çekirdek mikro çekirdekten daha hızlıdır . ilk mikro çekirdekli Mach, Monolitik çekirdeğe göre% 50 daha yavaş, L4 gibi sonraki sürümlerde ise Monolitik çekirdeğe göre sadece % 2 veya% 4 daha yavaştır .

4. Monolitik çekirdek genellikle hantaldır . Saf monolitik çekirdek işlemcinin birinci seviye önbelleğine (birinci nesil mikro çekirdek) sığacak kadar küçük boyutlu olmalıdır .

5. Monolitik çekirdek aygıt sürücüsünde çekirdek alanında bulunur . Microkernel aygıt sürücüsünde ise kullanıcı alanında bulunur .

6. aygıt sürücüsü çekirdek alanında bulunduğundan monolitik çekirdeği mikro çekirdekten daha az güvenli hale getirir . (Sürücüdeki arıza çökmeye neden olabilir) Mikro çekirdekler bazı askeri cihazlarda kullanılan monolitik çekirdekten daha güvenlidir .

7. Monolitik çekirdekler IPC'yi sağlamak için sinyaller ve soketler kullanırken mikro çekirdek yaklaşımı mesaj kuyrukları kullanır . 1 gen mikro çekirdeği zayıf uygulanan IPC, bağlam anahtarlarında yavaştı.

8. Bir monolitik sistem araçlarına yeni bir özellik ekleyerek tüm çekirdeği derlemeye Sen yeni özelliği veya yamaları ekleyebilir ederken derlemeye olmadan .