Çoklu kiracılık mı yoksa çok aşamalı mı?

Web tabanlı bir SaaS çözümü oluşturmaya çalışıyorum ve çoklu kiracılık veya çoklu örnek kullanma konusunda emin olmadığım bir yola çıktım. Neyi başarmaya çalıştığımı ve her yaklaşımın avantaj ve dezavantajlarını (okuduğum şeye göre fikrim) açıklamaya çalışacağım. Bir yaklaşımda diğerini kaçırdığımda lütfen önerilerinizi ekleyin.

Oluşturmaya çalıştığım uygulama, daha önce de belirttiğim gibi, şirketlerin hesaplarını oluşturabileceği bir SaaS çözümüdür ve her hesabın / şirketin kendi kullanıcıları, müşterileri, ürünleri, hizmetleri ... vb. Her kullanıcı; şirket çalışanı olan; bir hesap / şirketle ilgili olarak yalnızca şirket müşterileri, ürünleri ve hizmetlerine erişebilir. Şirketler sınırsız sayıda müşteri, ürün ve hizmete sahip olabilir, bu nedenle her şirketin kendi veri merkezi olmalıdır.

Bunun için paylaşılan bir veritabanı (giriş için tüm kullanıcıların kimlik bilgilerini kaydetme) ve birden çok veritabanı paylaşılan şeması (hesap / şirket başına veritabanı) oluşturmaya karar verdim. Temel olarak, Çoklu Kiracılık .

Daha sonra birisi bunun yerine Multi Instance kullanılmasını önerdi , burada her şirket kendi uygulama örneğine (yani kod, kütüphaneler, veritabanı, çerçeveler ... vb.) Diğer şirketlerden tamamen ayrılmış olacak. Her kiracının kullanıcılarının yalnızca şirket verilerine erişebildiğinden emin olmam gereken ekstra bir katmana dikkat etmek zorunda olmadığım için bu daha iyi görünüyor. Bu yaklaşımı elde etmek için Docker'a bağımlı olduğumu belirtmek iyi olduğunu düşünüyorum (daha önce hiç kullanmadım), ancak gelecekte ihtiyaç duyacağım özelliklere (daha sonra daha fazla) sahip olmadığını düşünüyorum (en azından ben yapmadım) onları biraz arama ile bulamazsınız).

Ancak, her yaklaşım artıları ve eksileri ile birlikte gelir, bu yüzden hangi yaklaşımın gideceğine karar veremedim. İşte bir liste, ama her ikisinde de bilgim eksik olduğu için benimle çıplak, bu yüzden farkında olmadığım bir şey veya web'de bulamadığım bir sorunun çözümü olabilir: [Her yaklaşımın sıralı bir listesini tek tek karşılaştırmamı izliyorum]

Çoklu Kiracılık :

1. Paylaşılan ana bilgisayar / donanım, paylaşılan kod ve çoklu veritabanı.
2. Bu var daha kolay kod ve düzeltme hataların işlevselliğini (paylaşılan kodu) uzatmak için.
3. Bu var zor (bir bulut hizmetini kullanabilirsiniz) donanım uzatmak veya yasasında değişiklik yapmadan başka bir sisteme bireysel kiracının veritabanını taşımak için.
4. En önemlisi, daha önce de bahsettiğim gibi, kullanıcının aslında kendi şirketine ait olduğundan ve diğer şirketin bilgilerine erişmediğinden emin olmak için sisteme fazladan bir katman eklemem gerekiyor.

Çok Örnek :

1. Paylaşılan veya paylaşılmayan ana bilgisayar / donanım, örnek başına kod ve örnek başına veritabanı.
2. Bu var zor (ben emin bir örneği veya Docker kaba işlevsellik / özelliğini ekleyin ve başkalarına dağıtabilir nerede Docker bunu yapmanın bir yolu varsa değilim) işlevselliği veya düzeltme hataları uzatmak.
3. Bu var daha kolay farklı bir host / donanıma bütün örneği taşımak.
4. Örnek olarak, her örneğin kendi veritabanına sahip olacağı için bu katmanla ilgilenmem gerekmiyor.

Tüm avantajları ve dezavantajları el ile bir şey yapmak istemem durumunda gereksizdir (her kiracı için el ile bir örnek oluştururken) ve bu yüzden Docker çözümünden şüphe duyuyorum, belki de ana yol budur sorunun nedeni. Soruyu çözümlere referansla cevaplarsanız çok memnun olurum ve bu yaklaşımın neden diğerinden daha iyi olduğunu düşünüyorsunuz?

Bu yardımcı olabilirse (belki?), Laravel'i arka uç için ana çerçeve olarak kullanıyoruz (hepsi RESTfully).

Kendime şu anda aynı soruyu soruyorum.

Çok örnekli tek kiracılık çözümüne yöneliyorum ancak henüz kesin bir karar almadım. Düşüncelerimin bazılarını paylaşmama izin verin:

Çok kiracı mimarisinin önemli tarihi avantajı olan altyapı kaynaklarının daha iyi kullanılması ile, ortak kullanımı (tek OS, tek Veritabanı, tek uygulama katmanı) ve daha iyi sözü kaynakların işgal (bir kullanıcı olduğunda ötede başka aynı kaynağı kullanabilirsiniz) .

Ayrıca yazılımın yaşam döngüsünü büyük ölçüde basitleştirir : bir sürümde yeni sürümler dağıtırsınız, tüm müşteriler aynı anda güncellenir.

Bununla birlikte, bulut teknolojisindeki son gelişmeler, birinci sınıf avantajları çok örnekli (müşteri başına örnek) bir mimaride (özellikle Jelastic gibi bir platform düşünüyorum, ancak burada eminim ki) aynı özellikleri sağlar):

• Kap tabanlı PaaS
• Konteynerlerin temini ve otomatik ölçeklendirilmesi (elastik konteynerler)

Dolayısıyla, donanım ve platform yönetimi artık Yazılım sağlayıcısının endişesi değildir. Kaynaklar altyapı ve plaform seviyelerinde eskisinden çok daha verimli bir şekilde karşılıklılaştırılmaktadır .

Çok eşgörünüm için yine de bir ek yük olacak (bazı uygulama ve ara katman yazılımı yalnızca bir yerine N kez çalıştırılacaktır), ancak örnek başına ayrı (sanal) bir makine kullanıldığında olduğundan çok daha düşük olacaktır. Veritabanı yine de paylaşılabilir (örnek başına bir şema, DB sunucusu başına birkaç şema)

Ayrıca :

• PaaS API aracılığıyla yeni örneklerin oluşturulmasının otomasyonu mümkündür
• Sıfır duruş süresiyle PaaS API ile yeni sürümlerin dağıtımının otomasyonu mümkündür (yerine koymak için biraz çalışma gerektirir)
• Ölçeklendirme her zaman dışarıda, asla yukarı. Örnek düzeyinde büyük veri kümeleri hakkında endişelenmemize gerek yok.

Elbette, tüm bunları otomatik olarak yöneten bir tür merkezi hizmete ihtiyacımız olacaktı (örneğin, yeni bir kullanıcı bir hesap oluşturduğunda örnek oluşturma). Bu aynı zamanda ödeme ve lisanslama sorunlarını, örnekler arasındaki etkileşimi vb. Yönetecektir. Bu merkezi hizmet oldukça karmaşık ve geliştirilmesi zor olabilir, ancak iyi olan şey, bunu önceden uygulamak zorunda olmamamızdır (şimdi çok fazla şeye sahip değiliz) oysa çok kiracı en baştan uygulamaya dönüştürülmelidir.

Bu da beni çok erken bir aşama (yatırım öncesi) başlangıç ​​projesi için tek kiracı geliştirmenin nihai avantajlarına getiriyor:

• Uygulamanın aynı (veya neredeyse aynı) sürümü, şirkete sanal bir cihaz veya docker konteyneri olarak veya hatta müşteri tarafından yönetilen makineye dağıtılabilir (bazı şirketler hala Bulut'a karşı isteksizdir ve erken aşamada başlatılmasına yardımcı olabilir. önemli erken benimseyenleri dışarı çekin)
• Sınırlı kaynaklara sahip bir ürünü daha hızlı çıkarmak (uygulama katmanı ve veritabanı şeması daha az karmaşıktır), ilk uygulayıcılar için ilk önce "aptal" tek örnekli tek kiracı ürünü (MVP) alabilir ve uygulamanın iş değerini gösterebilir potansiyel yatırımcılara ve tüm bulut otomasyonunu daha sonra
• Veri güvenliği konusunda endişeli müşteriler için bir satış argümanı olarak görülebilir: her müşterinin kendi şeması veya hatta veritabanı olduğundan veriler daha iyi kapsüllenir . Çok daha az "dökülme" riski

Not: Ben burada müşterilerin bireysel değil işletmeler (her biri birden çok bireysel kullanıcı) olacak bir iş uygulaması düşünüyorum. Her bir kullanıcı için ayrı bir uygulama örneği çalıştırmak mantıklı olmaz (ya da?)

Her iki seçeneği de desteklemek mümkündür (birden fazla örnekte kiracı havuzu).

Doğal izolasyonun çok örnekli nedenini destekliyorum. Her müşterinin örneği kendi işlemlerinde çalışır ve verileri kendi veritabanında yalıtılır. Örnekleri istediğiniz zaman müşteri / örnek temelinde yeni sürümlere yükseltebilirsiniz.

Kiracı tabanlı sistemler bilgi güvenliği riskiyle karşı karşıyadır. Bir "WHERE tenantId = x" yan tümcesini unutmanın ne kadar kolay olduğunu düşünün. Kiracı özellikli bir sistemi kullanmanın temel nedeni performanstır, süreçler ağır ağırlıktır, bir işlemi paylaşarak potansiyel olarak bir makineden daha fazla yararlanabilirsiniz. Bu daha doğruydu, 32 bitlik bir dünyada sanırım bugünlerde çok daha fazla RAM'e sahip 64 bit makinelerde.

Çok eşgörünümlü bir sistemin, veritabanları ve web uygulaması örnekleri gibi ortamı oluşturmak ve yapılandırmak için biraz daha fazla araca ihtiyacı olabilir. Bu, tek örnekli dağıtımlarınız için yine de bu komut dosyasına sahip olmanız gerektiğini iddia edebilir. Bunu yapmak, geliştirme ve test ortamları kurma yeteneği gibi başka avantajlara da sahiptir.

Sen bir dava yapana kadar kiracı yeteneklerini dışarıda bırakacaktım (süreç paylaşımı yoluyla (donanım) altyapısında biriken paraya karşı mühendislik maliyeti).