Ne yazık ki, bu terimin Rusça'da iyi bir analoğu yok. Vikipedi verir "çoklu kiracılık, çoklu kiracılık." Buna bazen "çoklu sahiplik" denir. Konu doğası gereği kiralama veya sahip olma ile ilişkili olmadığından bu terimler biraz kafa karıştırıcı olabilir. Bu, yazılım mimarisi ve işleyişinin organizasyonu ile ilgili bir sorundur. Ve ikincisi daha az önemli değil.
1C:Enterprise'da bulut (hizmet) çalışma modeline yönelik bir yaklaşım tasarlamaya başladığımız aynı zamanda çoklu kiracılık anlayışımızı da formüle etmeye başladık. Bu birkaç yıl önceydi. Ve o zamandan beri anlayışımız sürekli olarak genişledi. Bu konunun giderek daha fazla yeni yönlerini keşfediyoruz (artıları, eksileri, zorlukları, özellikleri vb.).
Bazen geliştiriciler çoklu kiralamayı çok basit bir konu olarak anlıyor: "Birkaç kuruluşun verilerinin tek bir veritabanında saklanabilmesi için tüm tablolara kuruluş tanımlayıcısını içeren bir sütun eklemeniz ve üzerine bir filtre ayarlamanız gerekir." Biz de elbette bu andan itibaren konuyla ilgili çalışmalarımıza başladık. Ancak bunun yalnızca bir açıklık olduğunu (bu arada, hiç de kolay olmadığını) hemen anladılar. Genel olarak burası “bütün bir ülke”.
Çoklu varlığın temel fikri şu şekilde tarif edilebilir. Tipik bir uygulama, altyapısını (duvarlar, çatı, su temini, ısıtma vb.) kullanan bir aileyi barındıracak şekilde tasarlanmış bir kır evidir. Çoklu kiracılık uygulaması bir apartman binasıdır. İçinde her aile aynı altyapıyı kullanıyor, ancak altyapının kendisi evin tamamı için uygulanıyor.
Çoklu kiracılık yaklaşımı iyi mi yoksa kötü mü? Bu konuda çok farklı görüşler bulabilirsiniz. Görünüşe göre “iyi ya da kötü” diye bir şey yok. Çözülen belirli görevler bağlamında artıları ve eksileri karşılaştırmanız gerekir. Ama bu ayrı bir konu...
En basit anlamıyla çoklu kiracılığın amacı, altyapı maliyetlerini "sosyalleştirerek" bir uygulamanın bakım maliyetini azaltmaktır. Bu, bir uygulamanın maliyetini "sipariş üzerine" yazmak yerine bir üretim çözümü kullanarak (muhtemelen özelleştirme ve modifikasyonla) azaltmakla aynı harekettir. Yalnızca bir durumda kalkınma toplumsallaşır, diğerinde ise sömürü.
Üstelik tekrarlıyoruz, satış yöntemiyle doğrudan bir bağlantı yoktur. Çoklu kiralama mimarisi, çok sayıda benzer şubeyi ve holding işletmesini otomatikleştirmek için kurumsal veya departmana ait BT altyapısında da kullanılabilir.
Çoklu kiralamanın sadece veri depolamayı organize etme meselesi olmadığını söyleyebiliriz. Bu, uygulamanın bir bütün olarak nasıl çalıştığının bir modelidir (mimarisinin önemli bir kısmı, dağıtım modeli ve bakım organizasyonu dahil).
Bize öyle geliyor ki, çoklu kiralama modeliyle ilgili en zor ve ilginç şey, uygulamanın özünün "çatallara ayrılmasıdır". İşlevselliğin bir kısmı belirli veri alanlarıyla (apartmanlar) çalışır ve diğer apartman sakinlerinin varlığıyla "ilgilenmez". Bazıları ise evi bir bütün olarak algılıyor ve tüm sakinler için aynı anda çalışıyor. Aynı zamanda, ikincisi bunların sonuçta ayrı daireler olduğu ve gerekli düzeyde ayrıntı ve güvenlik sağlanmasının gerekli olduğu gerçeğini göz ardı edemez.
1C:Enterprise'da çoklu kiracılık modeli çeşitli teknolojiler düzeyinde uygulanır. Bunlar 1C:Enterprise platformunun mekanizmalarıdır."Ve"", mekanizmalar (standart alt sistem kütüphaneleri).
Bu öğelerin her biri bir apartman binasının genel altyapısının inşasına katkıda bulunur. Bu neden örneğin bir platformda değil de birden fazla teknolojide uygulanıyor? Her şeyden önce, bazı mekanizmaların belirli bir dağıtım seçeneği için değiştirilmeye oldukça uygun olduğunu düşünüyoruz. Ancak genel olarak bu zor bir sorudur ve sürekli olarak bir seçimle karşı karşıyayız - çoklu kiracılığın şu veya bu yönünü hangi düzeyde uygulamak daha iyidir.
Açıkçası mekanizmaların temel kısmının platformda uygulanması gerekiyordu. Örneğin, gerçek veri ayrımı. İnsanların genellikle çoklu kiralama hakkında konuşmaya başladıkları yer burasıdır. Ancak sonuçta, çoklu kiracılık modeli, platform mekanizmalarının önemli bir bölümünde "gezindi" ve bunların iyileştirilmesini ve bazı durumlarda yeniden düşünülmesini gerektirdi.
Platform düzeyinde tam olarak temel mekanizmaları uyguladık. Çoklu kiralama modelinde çalışan uygulamalar oluşturmanıza olanak tanır. Ancak uygulamaların böyle bir modelde "yaşaması ve çalışması" için, onların "yaşam aktivitelerini" yönetecek bir sisteme sahip olmanız gerekir. Bunun sorumlusu 1cFresh teknolojileri ve BSP seviyesindeki birleşik iş mantığı katmanıdır. Bir apartman binasında altyapının konut sakinlerine ihtiyaç duydukları her şeyi sağlaması gibi, 1cFresh teknolojileri de çoklu kiralama modelinde çalışan uygulamalar için ihtiyaç duydukları her şeyi sağlar. Uygulamaların bu altyapıyla (önemli değişiklikler olmadan) etkileşime girebilmesi için, bunlara karşılık gelen "konektörler" BSP alt sistemleri biçiminde yerleştirilir.
Platform mekanizmaları açısından bakıldığında, deneyim kazandıkça ve "1C:Enterprise" bulut kullanım örneğini geliştirdikçe, bu mimaride yer alan mekanizmaların bileşimini genişlettiğimizi fark etmek kolaydır. Bir örnek verelim. Çoklu kiralama modelinde uygulama hizmeti katılımcılarının rolleri önemli ölçüde değişmektedir. Uygulamaların işletilmesinden sorumlu olanların rolü (sorumluluk düzeyi) önemli ölçüde artmaktadır. Daha güçlü uygulama kontrol araçlarına sahip olmaları gerekli hale geldi. Çünkü uygulama kullanıcıları (sakinleri) öncelikle çalıştıkları sağlayıcıya güvenirler. Bunu yapmak için yeni bir uygulama başlattık. . Bu mekanizma, sağlayıcı yöneticilerinin, uygulama geliştiricilerinin özgürlüğünü gerekli güvenlik düzeyiyle sınırlamasına, yani uygulamanın çalışmasını belirli bir sanal alan içinde her kiracı için izole etmesine olanak tanır.
Çoklu kiralama modunda çalışan uygulamaları yönetmeye yönelik mimari (1cFresh ve BSP teknolojilerinde uygulanan) daha az ilgi çekici değildir. Burada, geleneksel dağıtım modeliyle karşılaştırıldığında, yönetim süreçlerinin otomasyonuna yönelik gereksinimler önemli ölçüde artmaktadır. Bu tür düzinelerce süreç var: yeni veri alanları ("daireler") oluşturmak, uygulamaları güncellemek, düzenleyici bilgileri güncellemek, yedeklemeler vb. Ve elbette, güvenilirlik ve kullanılabilirlik düzeyine yönelik gereksinimler artıyor. Örneğin uygulamalar ve kontrol sistemi bileşenleri arasında güvenilir etkileşimi sağlamak için garantili teslimatla asenkron çağrı sistemi teknolojisini uyguladık.
Verileri ve süreçleri sosyalleştirmenin yolu çok incelikli bir noktadır. Sadece ilk bakışta basit görünüyor (eğer birine öyle geliyorsa). En büyük zorluk, veri ve süreçlerin merkezileştirilmesi ile merkezi olmayan yönetim arasındaki dengedir. Merkezileştirme bir yandan maliyetleri (disk alanı, işlemci kaynakları, yönetici çabaları...) azaltmanıza olanak tanır. Öte yandan “kiracıların” özgürlüğünü de sınırlıyor. Bu, geliştiricinin uygulama hakkında aynı anda dar anlamda (bir "daireye" hizmet etmek) ve geniş anlamda (tüm "kiracılara" aynı anda hizmet vermek) düşünmesi gerektiğinde, uygulamanın "çatallanma" anlarından biridir. .
Böyle bir "ikileme" örnek olarak düzenleyici bilgiler ve referans bilgileri verilebilir. Tabii ki, bunu evin tüm "kiracıları" için ortak hale getirmek için büyük bir cazibe var. Bu, onu tek bir kopya halinde saklamanıza ve herkes için aynı anda güncellemenize olanak tanır. Ancak bazı sakinlerin belirli değişikliklere ihtiyacı var. Garip bir şekilde, pratikte bu, düzenleyiciler (hükümet kurumları) tarafından belirtilen bilgiler için bile meydana geliyor. Bunun zor bir soru olduğu ortaya çıkıyor: sosyalleşmek mi, sosyalleşmemek mi? Elbette bilgiyi herkes için genel, isteyenler için özel kılmak cazip geliyor. Bu da zaten çok zor bir uygulamaya yol açıyor. Ama bunun üzerinde çalışıyoruz...
Diğer bir örnek ise düzenli süreçlerin (bir programa göre yürütülen, kontrol sistemi tarafından başlatılan vb.) uygulanmasının tasarımıdır. Bir yandan her veri alanı için ayrı ayrı uygulanabilirler. Daha kolay ve daha kullanışlı. Ancak öte yandan, bu kadar ince ayrıntı düzeyi sistem üzerinde büyük bir yük oluşturur. Yükü azaltmak için sosyalleştirilmiş süreçleri uygulamanız gerekir. Ancak daha dikkatli bir çalışma gerektirirler.
Tabii bu çok önemli bir soruyu gündeme getiriyor. Uygulama geliştiricileri çoklu kiralamayı nasıl sağlayabilir? Bunun için ne yapmaları gerekiyor? Elbette teknolojik ve altyapı sorunlarının yükünün mümkün olduğunca sağlanan teknolojinin omuzlarına düşmesini ve uygulama geliştiricisinin yalnızca iş mantığı görevleri açısından düşünmesini sağlamaya çalışıyoruz. Ancak diğer önemli mimari konularda olduğu gibi, uygulama geliştiricilerin çoklu kiralama modelinde çalışma konusunda biraz anlayışa sahip olmaları gerekir ve uygulamalar geliştirilirken biraz çaba sarf edilmesi gerekecektir. Neden? Çünkü teknolojinin verinin anlambilimini dikkate almadan otomatik olarak sağlayamayacağı noktalar var. Örneğin, bilgi sosyalleşmesinin sınırlarının aynı tanımı. Ama biz bu zorlukları küçük tutmaya çalışıyoruz. Bu tür uygulamaların uygulanmasına ilişkin örnekler zaten mevcuttur.
1C:Enterprise'da çoklu kiracılığın uygulanması bağlamında önemli bir nokta, bir uygulamanın hem çoklu kiralama modunda hem de normal modda çalışabileceği hibrit bir model oluşturmamızdır. Bu çok zor bir iştir ve ayrı bir tartışmanın konusudur.
Kaynak: habr.com