Forum
Aktif konular
Üyeler
Kurallar
Arama
Asp.Net Core Multi Tenant Konusu Hakkında Asp.Net Core Multi Tenant Konusu Hakkında
-
.net core ile multi tenant bir uygulama geliştirileceği zaman nasıl bir yol izlenmesi gerekiyor.
Kullanıcı girişleri, veritabanları, middleware lar, yine farklı kullanıcı grupları için tutulan verilerin bütünlüğü ve bu verilerin izolasyonu, soyutlanması vs.
Multi tenant uygulamalar için farklı yaklaşımlar var sanırım;
En uygun model hangisidir ve bu uygulanış şekli nasıldır?
Asp.net core için örnek projeler var mıdır ?
Https tarafından 26/Haz/21 21:05 tarihinde düzenlenmiştir -
Up olsun
.net core bilmiyorum ve multi-tenant bir proje içerisinde hiç yer almadım.
Bununla beraber baya araştırdım ve tek app üzerinden her müşteri için ayrı DB de verileri tutmak bana daha doğru geliyor. İleride tek DB de birleştirmek istenirse bu pek mümkün olmayacaktır (primary key olarak id dışında alan kullanılabilir vs vs) ama yalıtım ve yönetilebilirlik açısından daha doğru geliyor.
-
Hocam sorduğun soru ASP.NET Core veya başka bir geliştirme ortamı/ürün den bağımsız bir soru. Buradaki veri organizasyonunu, izolasyonunu, güvenliği vs. kendin halledeceksin.
Bir CRM uygulaması yaptığını varsayalım. Şirketler, müşteriler ve kullanıcılar olsun.
Kullanıcılar sisteme login olan kişiler yani şirketlerin çalışanları. Muhasebeci, satış elemanı veya müşteri destek elemanı gibi rollere sahip olabilirler.
Müşteriler şirketlerin müşterisi. Bireysel veya kurumsal müşteri olabilir mesela. Her müşterinin bir profil sayfası var. Sen oraya adres, iletişim bilgileri vs gibi bilgileri yazıyorsun. Veya müşteriye özel not ekliyorsun. Müşterilerin sisteme giriş yapamadığını varsayalım. CRM uygulaması sadece şirketlerin çalışanları için yani kullanıcılar için.
Şirketler ise bu CRM e para ödeyen kurumlar. Her şirketin 1 adet admin hesabı olur ve diğer kullanıcıları o admin hesabı oluşturur mesela.
--------------------------------------------------------------------------
Burada sen daha işe başlarken A'dan Z'ye herşeyi bir multi-tenant uygulamanın prensiplerine göre geliştireceksin.
Veritabanında müşteriler diye bir tablo açtıysan bu tablonda "company_id" isminde bir kolon olacak. Ve bu kolon indexli olacak. Neden? Çünkü sen sıklıkla "Seçilen şirkete ait müşterileri getirme" işlemini yapacaksın. Tabloda 100.000.000 satır müşteri olsada sorun olmaz. Neden çünkü sen company_id alanını indexledin.
-------------
Gelelim Authentication ve Authorization konularına. Yani kimlik kontrolu ve yetki kontrolu. Diyelim senin müşteri sayfanı gösteren URL şu şekilde; www.crmprojesi.com/mycompany/customer/176 buraya sisteme login olmamış bir insan giriş yapamayacak elbette. Ama asıl dikkat etmen gereken nokta Authorization konusu. Diyelim sisteme giriş yapmış 2 farklı kullanıcı var. Bunlardan 1 tanesi gider adres satırındaki 176 yı 350 yaparsa doğrudan 350 numaralı müşteriyi görememesi lazım!!
Sen her gelen istekte "Acaba bu user bu işlemi yapmaya yetkili mi? Ulaşmak istediği müşteri acaba gerçekten bu user ın dahil olduğu şirkete ait bir müşteri mi?" diyerek kontrol etmen lazım. Bu kontrolü ASP.NET Core üzerinde nerede yapacağın sana kalmış. İstersen Action Metodun üzerine yazdığın bir filtre içinde yaparsın, istersen business katmanında yaparsın. Bu tamamen senin uygulamanı nasıl yazdığına bağlı. Kullandığın mimariye vs.
--------------------------------------------------------------------------Tek veritabanı mı yoksa her şirket için ayrı veritabanı mı diyecek olursan, buna cevap senin projene göre değişebilir. Artıları ve eksileri var. Ve seçtiğin projeye göre değişir.
Bu tarz CRM, üye yönetimi gibi yazılımlarda tek bir veritabanı kullanmanı tavsiye ederim. Multi tenant uygulamalarda her müşteri için ayrı veritabanı olması bakım vs işlerini inanılmaz zorlaştıracaktır. Ancak analytics tarzında bir ürün yaparsın. Çok çok yoğun bir şekilde veri yazma vs işlemleri olur o zaman her bir müşterin için gider yeni bir veritabanı açarsın.
Ayrıca tek bir veritabanı açıp, dileyen müşterilerin kendi veritabanlarını kullanabilecekleri bir yapı da organize edebilirsin. Hibrit şekilde yani.
------------------
Bu soru dil veya platform bağımsız bir soru. ASP.NET Core, Php, Java vs farketmez. Kafanda kuracaksın herşeyi.
-
En uygun model projenin içeriğine göre değişir. Vakit varsa tüm yaklaşımlar için yazılmış blog yazılarını veya makaleleri okuyup, açık kaynaklı projeleri inceleyip öyle karar vermek gerekir.
Basit bir örnek, binlerce/milyonlarca tenant ve her tenant için 1-2 kullanıcı beklenen B2B bir uygulama için veritabanlarını tenantlara göre ayırmak mantıklı olmayacaktır. Fakat tenant sayısı görece az, her tenant için binlerce kullanıcının olduğu senaryoda tek veritabanı daha mantıksız bir seçim olur.
Uzun zaman önce ASP.Net Boilerplate adlı bir projeyi incelemiştim. Geliştiriciye mimari altyapıyı hazır eden, multitenant desteği de olan başarılı bir projeydi. Halen devam ediyor ve .net core desteği sunuyorsa göz atmanızı tavsiye ederim.
-
paylaştığın imajdaki 1. yöntem iş gücü mantık ve yönetilebilirlik açısından en mantıklı olandır. ayrıca benimde projelerimde uyguladığım yöntemdi. yeni bir company ekleyeceğin zaman yazdığın admin kodundan başka bir hiç bir tool kullanmayacağın anlamına gelir. eğer her company'de milyonlarca kayıt olacak db şişecek gibi bir düşüncen varsa identity bilgileri hariç mongodb veya elastic gibi nosql toolara yönelebilirsin. ve companyid kolonuna göre sharding yapabilirsin. böylece her company'e özel bilgiler kendi shard'ında (halk dilinde anlatacak olursam partitionunda saklanır) böylece bir business ile ilgili sorgu yaptığında sadece o business'a özel sanal bir db içinde sorgu yapmış olursun. ama dbyi tek başına yönetirsin. replicalar node'lar filan tek yerden yönetilmiş olur. ama resimdeki ikinci yöntemi kullanırsan her yeni company oluşturduğunda onunla ilgili bir db oluşturman lazım. batch bile olsa yeni bir db ayağa kalkacak ve yönlendirmeler o dbnini backup maintenance ayarları vb derken ortalık karışabilir. KARIŞIR demiyorum ama işgücün baya artar.
son 6 yılı ekip lideri olmak üzere 8 yıldır multitenant projelerde çalışıyorum aklına ne gelirse sorabilrsin her konuda yardımcı olmaya çalışırım.
-
Burada senin kullandiğin alt yapi ve database türü de önemli. 40 müşteriye hizmet verdiğin zaman her müşterinin app'inin güncellemesini, app db versionunun takibini vs yapmak sıkıntı. Her db nin yedeklenmesi osu busu derken iş gücünü artıracaktır. @manglerman 'in da dediği gibi 1. yapı en güzeli geliyor bana. Bizde bir projede buna benzer bir yapi kullanıyoruz. Birazda esneklik kattık.
Entityframework'den türeyen bir ORM yapısı kullanıyoruz biz. Login olan kullanıcının mevcut Müşteri kodu ne ise, her select ve insert querysinin sonuna otomatik ekltiyoruz bu sekilde yanlış bir kullanıcı başka bir kullanıcının datasina ulaşamıyor-değiştiremiyor. Tabi her tabloda merchantCode, createdBy createdAt, updatedBy, updatedAt kolonlarıda oluyor. Eğer kullanıcının profiline bir connection string tanimlandi ise, db ye o connection string ile bağlandığı için kullanıcı tablosu ortak olsa bile, application datalar istenildiği an ayrıla biliyor. (bunun için kullanıcında extra server fee si talep ediyoruz. Ayni datacenterda kendileri sunucu tutup onların sunucusunda da o datalari tutabiliyoruz istenildiği koşulda)
Oracle bunun için biçilmiş kaftan.
dalyKadir tarafından 28/Haz/21 19:57 tarihinde düzenlenmiştir -
Her bir kıymetli yorumunuz ayrı ayrı için teşekkür ediyorum.
@coder2Banada farklı db'lerden ilerlemek mantıklı olabilir gibi geliyor ama başlangıçta iyi olsada kullanıcı sayısı belli bir seviyeyi aştığında işleri yönetmek zorlaşır gibi düşünüyorum.
Tek uygulama tek db iyi gibi ama bu noktada yapılacak konfigürasyonların iyi ayarlanması gerekiyor sanırım.
@Hannibal_King
"Seçilen şirkete ait müşterileri getirme" olayı her işlemde kontrol edilecek gibi görünüyor.
Authorization konusu için dediğin custom attribute yazıp her bir request'te gelen requesti kontrol ederek header veya cookie üzerinden gelen bilgiler ile yönlendirme yapılması gibi bir yöntem geliyor aklımıza. Uygun mudur bu hocam?
@MadJack
asp.net boilerplate artık .net core için abp.io üzerinden devam ediyor. Ve dediğiniz gibi multi-tenancy yapısı hazır geliyor hatta başlangıçta proje için istenilen ui-frameworkü ve istenilen DB türüne göre template bir proje oluşturuyor. https://abp.io/get-started
Ama Junior seviyedeki bir geliştirici için abp.io bence kompleks bir yapıda kalıyor.
DDD konseptlerine ve bir takım gerekli programlama yetkinliklerine tam hakim olmadan abp.io üzerinden geliştirme yapmak sıfırdan bir multi-tenant projeye girişmekten çok daha zor görünüyor.
Ama abp.io işlerinizi kolaylaştıracaktır. abp.io üzerinden devam etmelisiniz tavsiyesi gelirse buna mutlaka dikkat ederiz hocam
@manglermanElasticSearch kullanmadım hiç ama MongoDb'deki yapı tablolara kıyasla daha esnek olduğu için kullanılabilir gibi ama çok hakim değilim mongodb'ye de ilk çıktığı zamanlar authorization felan yoktu diyorlardı o zamanlarda güvenlik sıkıntıları vardı galiba doğru mu hatırlıyorum bilmiyorum ama şimdi böyle sıkıntıları kalmamıştır tabi.
Kurguyu baştan iyi tasarlamak gerek sanırım DB yapısı, authorization işlemlerinin nasıl izole edileceği, her bir tenant için yönetici- kullanıcı yapılandırması, yoksa direkt girişip yapılabilecek bir iş gibi durmuyor. Yine fikir almak için buraya mutlaka yazacağım hocam, teşekkürler.
@dalyKadir
Son bahsettiğin Auditing ile mi ilgili hocam.
Şöyle bir kütüphane buldum ama yapısı kompleks geldi bana
https://github.com/thepirat000/Audit.NET
Multi - tenant yapılarda Logging o kadar önemli mi hocam. Her hareketin bir yerlerde tutulması gerekiyor mu?
Yoksa ben konuyu yanlış mı anladım?
Https tarafından 05/Tem/21 19:02 tarihinde düzenlenmiştir -
Loglama yı da kolaylaştırıyor, softlocking dediğimiz sistemide. Örneğin ayni kaydın edit ekranina 2 kişi birden girdi. bir kişi kaydın x parametresini güncelledi. diğer kişi y parametresini ve kayıt tuşuna basti. son kaydeden ilk kaydedenin değşikliğini ezecektir. Fakat, update sorgusunun içinde UpdateAt değişkeninin kendi record'u actiği ilk andaki değişkenden daha ileri bir tarih olmasinin kontrolu var ise 2. kaydedenin updatedAt tarihi ilkinden önce olacağindan sorgu hata döndürecek. Kayıt başarsız ekranına kişi dönecek. O anda sizden once XXX kişisi bu kaydi güncellemiştir bilgisinin gidip x bir logdan gösterilmesinden ise direk tablodan okunmasi hem işi kolaylaştırıyor hemde bir cok hatanın önüne geciyor.
bu tarz uygulamalarin en değerli parcasi oluyor ORM. framework ekibi kenti tarafında bu tarz işleri filtreler ise üst katman da ki yazılımcı arkadaşlar isteseler bile yanlış kişiye yanliş datayi cikartamazlar. Bu sayede deneyim eksiği olan yazılımcıları bile gönül rahatlığı ile interface veya form kodlamada kullanabilirsin. Maliyetlerini düşürürsün.
Loglama konusunda ise patronum dehşet takintili. Her gelen request bir tabloda loglanir. Buna cevap giden response da loglanır. Bu requestin loglandığı tabloda ki GUID ile de db ye giden her query farkli bir tabloya loglaniyor (Select'ler dahil) bu sayede db bir sorun yaşanırsa gerekirse loglardan bu datalari tekrar oluşturabiliriz bile. Record da ki change işlemleri de ayni bir tabloda tekrar loglanıyor. Bu da recordun historysini göstermek için. Örneğin bir ürünün fiyatinda ki değişiklileri kimin yaptiğini vs direk bu tablodan filtreleyerek getirebiliyoruz.
Sektörü bilmiyorum ama ödeme sektöründe sertifikasyonlar gereği loglarin 5 yil saklanması gerekiyor. Kurum ile calismayi biraktiğinda senden logları istiyor. O durumda logları filtreliyip çekmen gerekiyor. Bunda dolayı log tablosunda da bu logu oluşturan kişinin kim oldugunu, bu log'un değiştirilmediğinin delili olarak zaman damgasini vs de koyuyor olman gerekli.
dalyKadir tarafından 05/Tem/21 20:34 tarihinde düzenlenmiştir -
Şu konularda sağlam bir eğitim seti, eğitim falan olsa gözümü kırpmadan alıcam. İnternette papağan gibi konulardan, eğitimlerden başka bir şey yok. Şurda bahsi geçen 2-3 konsepti derli toplu anlatan bir tane ücretli-ücretsiz kaynak bulamadım.
-
Code first ile oluşturulmuş 2 tablo var;
Müşteriler(PK) ve MüşteriTalepleri diye.
Başlangıçta birbirlerine bağlı olmayan bu iki tablo için sonradan birbirlerine bire çok olarak bağlandığında.
Müşteri talepleri tablosunda veriler varken yeni bir kolon(fk) oluşacak. Ve önceki satırlarda FK alanı boş olacağı için sorun oluşuyor. En baştan verileri el ile girmek gerekiyor.
Böyle bir durumda nasıl bir yöntem izlenmesi gerekiyor?
Bire çok ilişki durumlarını 3. bir tabloda tutmadan nasıl bir yol izlenir.
Tabloda sonradan açılan bu FK alan boşa düşüyor.
Projeyi sunucuya gönderdikten sonra böyle durumlarda önceki verileri kaybetmeden yeni güncellenen yapıya nasıl geçiş yapılır.
-
Up
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
mvc asp.net core asp.net core mvc .net 6 .net 5 multi-tenant .net core
Cevapla