• Tercüme

Uber'e iki yıl önce arka uç geliştirme deneyimi olan bir mobil geliştirici olarak katıldım. Burada uygulamadaki ödeme işlevini geliştiriyordum - ve bu arada uygulamanın kendisini yeniden yazdım. Ondan sonra geliştirme yönetimine geçtim ve ekibin başına geçtim. Bu sayede, ödemelere izin veren arka uç sistemlerimizin çoğundan ekibim sorumlu olduğu için arka uca çok daha aşina olabildim.

Uber'e katılmadan önce dağıtık sistemlerle ilgili hiçbir deneyimim yoktu. Bilgisayar Bilimi alanında geleneksel bir eğitim aldım, ardından bir düzine yıl boyunca tam kapsamlı geliştirme yaptım. Bu nedenle, çeşitli diyagramlar çizebilsem ve değiş tokuşlar hakkında konuşabilsem de ( takaslar) sistemlerde, o zamana kadar dağıtım kavramlarını yeterince iyi anlamadım ve algıladım, örneğin tutarlılık ( tutarlılık), kullanılabilirlik ( kullanılabilirlik) veya idempotency ( iktidarsızlık).

Bu yazıda, bugün Uber'in işlettiği büyük ölçekli, yüksek oranda erişilebilir dağıtılmış ödeme sistemini kurarken öğrenmem ve uygulamaya koymam gereken birkaç kavramı paylaşacağım. Bu, sistemin belirli bölümlerinin çalışmayı durdurduğu durumlarda bile, ödemelerin kritik işlevselliğinin doğru çalışması gereken, saniyede birkaç bin istek yüküne sahip bir sistemdir.

Bu tam bir liste mi? Büyük olasılıkla hayır. Ancak bu kavramları daha önce kendim öğrenmiş olsaydım, hayatım çok daha kolay olurdu.

Öyleyse SLA, tutarlılık, veri dayanıklılığı, mesaj bütünlüğü, bağımsız olma ve yeni işimde öğrenmem gereken diğer birkaç şeye dalışımıza geçelim.

SLA

Günde milyonlarca olayı işleyen büyük sistemlerde, tanım gereği bazı şeylerin yanlış gitmesi gerekir. Bu nedenle sistem planlamasına geçmeden önce en önemli adım “sağlıklı” bir sistemin bizim için ne anlama geldiğine karar vermektir. "Sağlık" derecesi şu şekilde olmalıdır: aslındaölçülebilir. Bir sistemin "sağlığını" ölçmenin genel olarak kabul edilen yolu SLA'dır ( Hizmet Seviyesi Anlaşmaları). Pratikte karşılaştığım en yaygın SLA türlerinden bazıları şunlardır:

• kullanılabilirlik: Hizmetin çalıştığı ve çalıştığı sürenin yüzdesi. %100 kullanılabilirlik elde etmek cazip gelse de, bu sonuca ulaşmak gerçekten zor ve maliyetli olabilir. VISA kart ağı, Gmail veya İnternet sağlayıcıları gibi büyük ve kritik sistemler bile %100 kullanılabilir değildir - yıllar geçtikçe arıza sürelerinde harcanan saniyeler, dakikalar veya saatler birikir. Birçok sistem için, dört dokuzluk bir kullanılabilirlik (%99,99 veya yılda kabaca 50 dakikalık kesinti süresi) yüksek kullanılabilirlik olarak kabul edilir. Bu seviyeye gelebilmek için çok terlemelisiniz.
• Kesinlik: veri kaybı kabul edilebilir mi yoksa yanlış mı? Eğer öyleyse, yüzde kaç kabul edilebilir? Üzerinde çalıştığım ödeme sistemi için bu rakamın %100 olması gerekiyordu çünkü veri kaybetmenin bir yolu yoktu.
• Kapasite / Kapasite: Sistem ne tür yüklere dayanabilmelidir? Bu metrik genellikle saniyedeki istek sayısı olarak ifade edilir.
• gecikme: sistem ne kadar süre yanıt vermelidir? İsteklerin %95'ini ve %99'unu yerine getirmek ne kadar sürer? Bu tür sistemlerde, sorguların çoğu genellikle "gürültü"dür, bu nedenle p95 ve p99 gecikmeleri gerçek dünyada daha pratik uygulamalar bulur.

Büyük bir ödeme sistemi oluştururken SLA'lara neden ihtiyaç duyulur? Mevcut sistemin yerine yeni bir sistem oluşturuyoruz. Her şeyi doğru yaptığımızdan ve yeni sistemimizin öncekinden "daha iyi" olacağından emin olmak için beklentilerimizi tanımlamak için SLA'yı kullandık. Erişilebilirlik en önemli gereksinimlerden biriydi. Bir hedefimiz olduğunda, bu ölçütlere ulaşmak için mimari değiş tokuşlarla uğraşmamız gerekiyordu.

Yatay ve dikey ölçekleme

Yeni oluşturulan sistemimizi kullanarak iş büyüdükçe, üzerindeki yük daha da artacaktır. Bir noktada, mevcut kurulum yükteki daha fazla artışa dayanamayacak ve izin verilen yükü artırmamız gerekecek. İki yaygın ölçeklendirme stratejisi, dikey veya yatay ölçeklendirmedir.

Ölçeklendirme, verimi artırmak için sisteme daha fazla makine (veya düğüm) eklemekle ilgilidir ( kapasite). Ölçeklendirme, dağıtılmış sistemleri ölçeklendirmenin en popüler yoludur.

Ölçek büyütmek esasen "daha büyük/daha güçlü bir makine satın almaktır" - daha fazla çekirdeğe, daha iyi işlem gücüne ve daha fazla belleğe sahip (sanal) bir makine. Dağıtılmış sistemler söz konusu olduğunda, dikey ölçeklendirme, yatay ölçeklendirmeden daha pahalı olabileceğinden genellikle daha az popülerdir. Ancak, Stack Overflow gibi bazı iyi bilinen büyük siteler, iş yükünü karşılamak için başarıyla dikey olarak ölçeklendirildi.

Büyük bir ödeme sistemi kurarken ölçeklendirme stratejisi neden anlamlıdır? Yatay olarak ölçeklenecek bir sistem kurmaya erken karar verdik. Bazı durumlarda dikey ölçeklendirme kabul edilebilir olsa da, ödeme sistemimiz o zamana kadar zaten öngörülen yüke ulaşmıştı ve tek süper pahalı ana bilgisayarın bugün, hatta gelecekte bu yüke dayanabileceği varsayımı konusunda karamsardık. ... ... Ek olarak, ekibimizde büyük ödeme hizmeti sağlayıcıları için çalışan ve o yıllarda paranın satın alabileceği en güçlü makinelerde bile dikey olarak ölçeklendirmeye çalışmanın olumsuz deneyimini yaşayan birkaç kişi vardı.

Tutarlılık

Sistemlerden herhangi birinin kullanılabilirliği önemlidir. Dağıtılmış sistemler genellikle bireysel kullanılabilirliği tüm sisteminkinden daha düşük olan makinelerden oluşturulur. Hedefimiz %99,999 kullanılabilirliğe sahip bir sistem kurmak olsun (kapalı kalma süresi yaklaşık 5 dakika/yıl). Ortalama %99,9 kullanılabilirliğe sahip makineler/düğümler kullanıyoruz (bunlar yaklaşık 8 saat/yıl kesinti süresidir). İhtiyacımız olan kullanılabilirlik göstergesine ulaşmanın doğrudan yolu, kümeye bu tür birkaç makine/düğüm daha eklemektir. Bazı düğümler kapalı olsa bile, diğerleri çalışmaya devam edecek ve sistemin genel kullanılabilirliği, bireysel bileşenlerinin kullanılabilirliğinden daha yüksek olacaktır.

Tutarlılık, yüksek oranda erişilebilir sistemlerde önemli bir konudur. Tüm düğümler aynı verileri aynı anda görür ve döndürürse sistem tutarlıdır. Daha fazla kullanılabilirlik elde etmek için daha fazla düğüm eklediğimiz önceki modelimizin aksine, sistemin tutarlı kalmasını sağlamak önemsiz olmaktan uzaktır. Her bir düğümün aynı bilgileri içerdiğinden emin olmak için, sürekli senkronize olmak üzere birbirlerine mesaj göndermeleri gerekir. Ancak, birbirlerine gönderdikleri mesajlar teslim edilemeyebilir - kaybolabilir ve bazı düğümler kullanılamayabilir.

Tutarlılık, anlamadan ve takdir etmeden önce kavramak için en çok zamanımı alan kavramdır. Birkaç tutarlılık türü vardır, dağıtılmış sistemlerde en yaygın olarak kullanılanı güçlü tutarlılıktır ( güçlü tutarlılık), zayıf tutarlılık ( zayıf tutarlılık) ve nihayetinde tutarlılık ( nihai tutarlılık). Bu makalede, her modelin avantajları ve dezavantajları hakkında pratik bir tartışmayı okuyabilirsiniz. Tipik olarak, gerekli tutarlılık düzeyi ne kadar zayıfsa, sistem o kadar hızlı çalışabilir - ancak en son veri kümesini döndürmemesi daha olasıdır.

Büyük bir ödeme sistemi oluştururken neden tutarlılık dikkate alınmalıdır? Sistemdeki veriler tutarlı olmalıdır. Ama ne kadar tutarlı? Sistemin bazı bölümleri için yalnızca son derece tutarlı veriler çalışacaktır. Örneğin, ödemenin başlatıldığı bilgisini oldukça tutarlı bir biçimde tutmamız gerekir. Sistemin çok önemli olmayan diğer kısımları için tutarlılık, nihayetinde makul bir uzlaşma olarak kabul edilebilir.

Bu, son işlemlerin listelenmesiyle iyi bir şekilde gösterilmiştir: bunlar nihai olarak tutarlılıkla uygulanabilir ( nihai tutarlılık) - yani, son işlem sistemin bazı bölümlerinde yalnızca bir süre sonra görünebilir, ancak bu nedenle, liste sorgusu daha az gecikmeyle bir sonuç döndürür veya yürütmek için daha az kaynak gerektirir.

Veri dayanıklılığı

Uzun ömür, verilerin veri ambarına başarıyla eklendikten sonra gelecekte bizim için kullanılabilir olacağı anlamına gelir. Bu, sistemin düğümleri çevrimdışı olsa, başarısız olsalar veya düğümlerin verileri zarar görse bile bu doğru olacaktır.

Farklı dağıtılmış veritabanları, farklı veri dayanıklılığı seviyelerine sahiptir. Bazıları destekliyor veri dayanıklılığı makine/düğüm düzeyinde, diğerleri bunu küme düzeyinde yapar ve bazıları bu işlevi kutunun dışında hiç sağlamaz. Uzun ömürlülüğü artırmak için tipik olarak bir tür çoğaltma kullanılır - veriler birden fazla düğümde depolanırsa ve düğümlerden biri çalışmayı durdurursa, veriler yine kullanılabilir olacaktır. dağıtık sistemlerde uzun ömürlülüğe ulaşmanın neden büyük bir zorluk olabileceğini açıklamak.

Bir ödeme sistemi oluştururken veri dayanıklılığı neden önemlidir? Veriler kritikse (örneğin ödemeler), o zaman sistemimizin birçok bölümünde bu verileri kaybetmeyi göze alamayız. Oluşturduğumuz dağıtılmış veri depoları, küme düzeyinde veri ömrünü korumak zorundaydı - bu nedenle, örnekler çökse bile tamamlanan işlemler devam ederdi. Günümüzde, Cassandra, MongoDB, HDFS veya Dynamodb gibi çoğu dağıtılmış depolama hizmetinin tümü, çeşitli düzeylerde dayanıklılığı destekler ve tümü, küme düzeyinde dayanıklılık sağlayacak şekilde yapılandırılabilir.

Mesaj kalıcılığı ve dayanıklılığı

Dağıtılmış sistemlerdeki düğümler hesaplamalar yapar, verileri depolar ve birbirlerine mesajlar gönderir. Mesaj göndermenin önemli bir özelliği, bu mesajların ne kadar güvenilir bir şekilde ulaştığıdır. Görev açısından kritik sistemler için genellikle hiçbir mesajın kaybolmaması şartı vardır.

Dağıtılmış sistemler söz konusu olduğunda, mesajlaşma ( mesajlaşma) genellikle bir tür dağıtılmış mesajlaşma servisi kullanılarak yapılır - RabbitMQ, Kafka veya diğerleri. Bu ileti aracıları, farklı düzeylerde ileti teslim güvenilirliğini destekleyebilir (veya destekleyecek şekilde yapılandırılabilir).

İleti kalıcılığı, iletiyi işleyen düğümde bir hata oluştuğunda, sorun çözüldükten sonra iletinin işlenmeye devam edeceği anlamına gelir. İleti dayanıklılığı, yaygın olarak ileti kuyruğu düzeyinde kullanılır. Uzun ömürlü bir mesaj kuyruğunda, bir mesaj gönderildiğinde bir kuyruk (veya düğüm) çevrimdışı olursa, tekrar çevrimiçi olduğunda mesajı almaya devam eder. Konuyla ilgili güzel ve ayrıntılı bir makale burada mevcuttur.


Büyük ödeme sistemleri oluştururken mesajların güvenliği ve dayanıklılığı neden önemlidir? Kaybetmeyi göze alamayacağımız mesajlarımız vardı - örneğin, bir kişinin seyahat için ödeme yapmaya başladığına dair bir mesaj. Bu, kullanacağımız mesajlaşma sisteminin kayıpsız çalışması gerektiği anlamına geliyordu: her mesajın bir kez iletilmesi gerekiyordu. Ancak, her mesajı ileten bir sistem oluşturmak düz yerine bir kez en azından bir kez - bunlar, zorluk derecelerinde önemli ölçüde farklılık gösteren görevlerdir. En az bir kez ileten bir mesajlaşma sistemi uygulamaya karar verdik ve bir mesaj yolu seçtik ( mesajlaşma otobüsü), üzerine inşa etmeye karar verdik (bizim durumumuzda gerekli olan kayıpsız bir küme oluşturarak Kafka'yı seçtik).

iktidarsızlık

Dağıtılmış sistemler söz konusu olduğunda her şey ters gidebilir - bağlantılar yarıda kesilebilir veya istekler zaman aşımına uğrayabilir. Müşteriler bu istekleri sık sık tekrarlayacaktır. İdempotent bir sistem, ne olursa olsun ve belirli bir istek kaç kez yürütülürse yürütülsün, bu isteğin fiili yürütmesinin yalnızca bir kez gerçekleşmesini sağlar. Ödeme yapmak iyi bir örnektir. Müşteri bir ödeme talebinde bulunursa talep başarılı olur, ancak müşteri zaman aşımına uğrarsa müşteri aynı talebi tekrarlayabilir. İdempotent bir sistem olması durumunda, ödemeyi yapan kişiden iki kez ücret alınmayacaktır; ancak idemponet olmayan bir sistem için bu oldukça olası bir olgudur.

Anlamsız dağıtılmış sistemler tasarlamak, bir tür dağıtılmış kilitleme stratejisi gerektirir. Burada daha önce tartıştığımız kavramlar devreye giriyor. Eşzamanlı güncellemeleri önlemek için iyimser kilitlemeyi kullanarak bağımsızlığı uygulamak istediğimizi varsayalım. İyimser kilitlemeye başvurabilmemiz için sistem kesinlikle tutarlı olmalıdır - böylece bir işlemin yürütülmesi sırasında başka bir işlemin bir çeşit sürüm oluşturma kullanmaya başlayıp başlamadığını kontrol edebiliriz.

Bağımsızlığı elde etmenin birçok yolu vardır ve her bir özel seçim, sistemin kısıtlamalarına ve gerçekleştirilen işlemin türüne bağlı olacaktır. Belirsiz yaklaşımlar tasarlamak bir geliştirici için değerli bir meydan okumadır - Ben Nadel'in hem dağıtılmış kilitler hem de kısıtlamalar içeren kullandığı çeşitli stratejiler hakkında konuştuğu gönderilerine bakın ( kısıtlamalar) Veri tabanı. Dağıtılmış bir sistem tasarlarken, yetersizlik kolayca gözden kaçırdığınız parçalardan biri olabilir. Uygulamamızda, bazı kilit operasyonlar için doğru bağımsızlığa ikna olmayarak ekibimin “yandığı” durumlarla karşılaştık.

Büyük bir ödeme sistemi oluştururken impotency neden önemlidir? En önemlisi: çifte ücretlerden ve çifte geri ödemelerden kaçınmak. Mesajlaşma sistemimizin en az bir kayıpsız teslimatı olduğu göz önüne alındığında, tüm mesajların birden çok kez iletilebileceğini ve sistemlerin bağımsızlığı garanti etmesi gerektiğini varsaymalıyız. Bunu, sistemlerimizin veri kaynağı olarak son derece tutarlı depolama kullanarak yetersiz davranış uyguladığı sürüm oluşturma ve iyimser kilitleme ile ele almaya karar verdik.

Parçalama ve çekirdek

Dağıtılmış sistemler genellikle tek bir düğümün karşılayabileceğinden çok daha fazla veri depolamak zorundadır. Peki veri setini doğru sayıda makinede nasıl saklarız? Bunun için en popüler teknik parçalamadır. Veriler, bölüme atanan bir karma kullanılarak yatay olarak bölümlenir. Günümüzde pek çok dağıtılmış veri tabanı, parçalama özelliğini başlık altında uygularken, parçalamanın kendisi, özellikle yeniden parçalama olmak üzere, araştırmaya değer ilginç bir konudur. Foursquare, 2010'da bir Edge sharding olayı nedeniyle 17 saatlik bir kesinti yaşadı ve ardından şirket paylaştı ve sorunun kökenine ışık tuttu.

Birçok dağıtılmış sistem, birden çok düğümde çoğaltılan verilere veya hesaplamalara sahiptir. İşlemlerin tutarlı bir şekilde gerçekleştirilmesini sağlamak için, bir işlemin başarılı sayılabilmesi için belirli sayıda düğümün aynı sonucu alması gereken bir oylama yaklaşımı tanımlanır. Bu işleme nisap denir.

Uber'de büyük bir ödeme sistemi oluştururken nisap ve paylaşım neden anlamlıdır? Bu kavramların her ikisi de basittir ve neredeyse evrensel olarak kullanılır. Cassandra'da çoğaltmayı kurduğumuzda onları tanıdım. Cassandra (ve diğer dağıtılmış sistemler) nisap ve yerel nisap ( yerel çoğunluk) kümeler arasında tutarlılığı sağlamak için.

Aktör modeli

Değişkenler, arayüzler, yöntem çağrıları gibi programlama uygulamalarını tanımlamak için kullandığımız tanıdık kelime dağarcığı, sistemleri tek bir makineden alır. Dağıtılmış sistemlerden bahsettiğimizde, başka yaklaşımlar kullanmalıyız. Bu tür sistemleri tanımlamanın yaygın bir yolu, kodun bizim tarafımızdan iletişim açısından görüldüğü aktör modelidir. Bu model, örneğin bir organizasyondaki insanların etkileşimini nasıl hayal ettiğimizin zihinsel modeliyle örtüştüğü için popülerdir. Dağıtılmış sistemleri tanımlamanın daha az popüler olmayan bir başka yolu, sıralı süreçlerle etkileşime giren CSP'dir.

Oyuncu modeli, birbirlerine mesaj gönderen ve onlara cevap veren aktörlere dayanmaktadır. Her aktör sınırlı sayıda şey yapabilir - başka aktörler yaratabilir, başkalarına mesaj gönderebilir veya bir sonraki mesajla ne yapacağına karar verebilir. Birkaç basit kuralla, bir aktörün çökmesinden sonra kendilerini yeniden inşa edebilen karmaşık dağıtılmış sistemleri oldukça iyi tanımlayabiliriz. Bu yaklaşıma aşina değilseniz, size makaleyi tavsiye ederim.

Şu anda, ticari amaçlar için geliştirilen tüm IC'ler, küresel ve / veya yerel ağların kullanımını ima eden dağıtılmış bir mimariye sahiptir.

Tarihsel olarak, dosya sunucusu mimarisi, mantığı basit olduğundan ve halihazırda çalışmakta olan IS'leri böyle bir mimariye aktarmak en kolay olduğu için yaygınlaşan ilk mimariydi. Daha sonra mantıksal devamı olarak yorumlanabilecek bir sunucu-istemci mimarisine dönüştürülmüştür. Küresel İNTERNET ağında kullanılan modern sistemler, temel olarak dağıtılmış nesnelerin mimarisiyle ilgilidir (bkz. III‑15 )

IS'nin aşağıdaki bileşenlerden oluştuğu düşünülebilir (Şekil III-16)

III.03.2. a Dosya sunucusu uygulamaları.

Tarihsel olarak ilk dağıtılmış mimaridir (Şekil III-17). Çok basit bir şekilde düzenlenmiştir: sunucuda yalnızca veri vardır ve diğer her şey istemci makineye aittir. Yerel ağlar oldukça ucuz olduğundan ve böyle bir mimari ile uygulama yazılımının özerk olması nedeniyle, bugün böyle bir mimari sıklıkla kullanılmaktadır. Bunun, sunucu üzerinde yalnızca veri dosyalarının bulunduğu istemci-sunucu mimarisinin bir varyantı olduğunu söyleyebiliriz. Farklı kişisel bilgisayarlar yalnızca ortak bir veri deposu aracılığıyla etkileşime girer, bu nedenle bir bilgisayar için yazılan programların böyle bir mimariye adapte edilmesi en kolay olanıdır.

Artıları:

Bir dosya sunucusu mimarisinin artıları:

Organizasyon kolaylığı;

Veritabanının bütünlüğünü ve güvenilirliğini sürdürmesi için gerekli gereksinimlerle çelişmez.

Ağ tıkanıklığı;

Bir isteğe öngörülemeyen yanıt.

Bu dezavantajlar, veritabanına yapılan herhangi bir talebin ağ üzerinden önemli miktarda bilgi transferine yol açması ile açıklanmaktadır. Örneğin, tablolardan bir veya birkaç satır seçmek için, tüm tablo istemci makineye indirilir ve VTYS zaten orada seçer. Önemli ağ trafiği, özellikle veritabanına uzaktan erişim organizasyonu ile doludur.

III.03.2. b İstemci-sunucu uygulamaları.

Bu durumda, sunucu ve istemci arasında bir sorumluluk dağılımı vardır. Nasıl ayrıldıklarına bağlı olarak yağ ve zayıf müşteri.

İnce istemci modelinde tüm uygulama işleri ve veri yönetimi sunucu üzerinde yapılır. Bu sistemlerdeki kullanıcı arabirimi bir kişisel bilgisayara "geçer" ve yazılım uygulamasının kendisi bir sunucunun işlevlerini yerine getirir, yani. tüm uygulama süreçlerini çalıştırır ve verileri yönetir. İnce istemci modeli, istemcilerin bilgisayarlar veya iş istasyonları olduğu durumlarda da uygulanabilir. Ağ cihazları, internet tarayıcısını ve sistem içinde uygulanan kullanıcı arayüzünü çalıştırır.

Ana kusur ince istemci modelleri - yüksek sunucu ve ağ yükü. Tüm hesaplamalar sunucu üzerinde yapılır ve bu, istemci ile sunucu arasında önemli ağ trafiğine yol açabilir. Modern bilgisayarlarda yeterli bilgi işlem gücü vardır, ancak bankanın modelinde / ince istemcisinde pratik olarak kullanılmaz.

Buna karşılık, kalın istemci modeli yerel makinelerin işlem gücünü kullanır: uygulamanın kendisi istemci bilgisayara yerleştirilir. Bu tür mimariye bir örnek, ATM'nin istemci ve sunucunun müşteri hesapları veritabanına hizmet veren merkezi bilgisayar olduğu ATM sistemleridir.

III.03.2. c İki ve üç katmanlı istemci-sunucu mimarisi.

Yukarıda tartışılan tüm mimariler iki katmanlıdır. İstemci düzeyi ile sunucu düzeyi arasında ayrım yaparlar. Açıkçası, IC üç mantıksal seviyeden oluşur:

· Kullanıcı seviyesi;

Uygulama seviyesi:

· Veri katmanı.

Bu nedenle, yalnızca iki katmanın dahil olduğu iki katmanlı bir modelde, ince istemci modeli seçilirse ölçeklenebilirlik ve performans sorunları, kalın istemci modeli seçilirse sistem yönetimi sorunları vardır. İkisinin sunucu olduğu üç seviyeden oluşan bir model uygularsak bu problemlerden kaçınılabilir (Şekil III-21).

Veri sunucusu

Aslında, uygulama sunucusu ve veri sunucusu aynı makine üzerinde yer alabilir, ancak birbirlerinin işlevlerini yerine getiremezler. Üç katmanlı modelin iyi yanı, uygulama yürütme ve veri yönetimini mantıksal olarak ayırmasıdır.

Tablo III-5 Farklı mimari tiplerinin uygulanması

Mimari	Başvuru
İki katmanlı ince istemci	1 Uygulama yürütme ve veri yönetiminin ayrılmasının tavsiye edilmediği eski sistemler. 2 Az veri yönetimi ile yoğun uygulamalar hesaplayın. 3 Büyük miktarda veriye ancak az hesaplamaya sahip uygulamalar.
İki katmanlı kalın istemci	1 Kullanıcının yoğun veri işlemeye ihtiyaç duyduğu uygulamalar, yani veri görselleştirme. 2 İyi yönetilen bir sistem ortamına uygulanan, görece sabit bir dizi kullanıcı işlevine sahip uygulamalar.
Üç katmanlı sunucu-istemci	1 Hücreli ve binlerce istemcili büyük uygulamalar 2 Veri ve işleme yöntemlerinin sık sık değiştiği uygulamalar. 3 Birden çok kaynaktan gelen verileri entegre eden uygulamalar.

Bu model birçok uygulama türü için uygundur, ancak hizmetleri nerede sağlayacağına karar vermesi, ölçeklenebilirlik için destek sağlaması ve yeni müşterilerle bağlantı kurmak için araçlar geliştirmesi gereken IS geliştiricilerini sınırlar.

III.03.2. d Dağıtılmış nesne mimarisi.

Daha genel bir yaklaşım, nesnelerin ana bileşenleri olduğu dağıtılmış bir nesne mimarisi tarafından sağlanır. Arayüzleri aracılığıyla bir dizi hizmet sağlarlar. Diğer nesneler, istemci ve sunucu arasında ayrım yapmadan istek gönderir. Nesneler, ağdaki farklı bilgisayarlarda bulunabilir ve farklı aygıtları bağlamanıza ve donanım aygıtları arasındaki iletişimi sürdürmenize olanak tanıyan sistem veriyoluna benzer şekilde ara katman yazılımı aracılığıyla etkileşime girebilir.

…

ODBC Sürücü Yöneticisi

sürücü 1

Sürücü K

DB 1

DB K

SQL ile çalışmak

…

ODBC mimarisi bileşenleri içerir:

1. Uygulama (örn. IS). Görevleri yerine getirir: veri kaynağına bağlantı ister, veri kaynağına SQL sorguları gönderir, SQL sorguları için depolama alanını ve biçimini tanımlar, hataları işler ve bunlar hakkında kullanıcıyı bilgilendirir, işlemleri gerçekleştirir veya geri alır, veri kaynağına bağlantı ister. veri kaynağı.

2. Aygıt Yöneticisi. Uygulamaların talebi üzerine sürücüleri yükler, tüm uygulamalar için tek bir arabirim sunar ve ODBC yönetici arabirimi aynıdır ve uygulamanın hangi DBMS ile etkileşime gireceğinden bağımsız olarak aynıdır. Microsoft tarafından sağlanan Sürücü Yöneticisi, dinamik yüklenebilir bir DLL'dir.

3. Sürücü, DBMS'ye bağlıdır. ODBC sürücüsü, ODBC işlevlerini uygulayan ve bir veri kaynağıyla etkileşime giren bir dinamik bağlantı kitaplığıdır (DLL). Sürücü, bir VTYS'ye özel bir işlev için bir talebi işleyen (bu, VTYS'ye göre sorguları değiştirebilir) ve sonucu uygulamaya döndüren bir programdır. ODBC teknolojisini destekleyen her DBMS, uygulama geliştiricilerine bu VTYS için bir sürücü sağlamalıdır.

4. Veri kaynağı, kullanıcı tarafından belirtilen kontrol bilgilerini, veri kaynağı hakkındaki bilgileri içerir ve belirli bir VTYS'ye erişmek için kullanılır. Bu durumda, işletim sistemi ve ağ platformunun araçları kullanılır.

dinamik model

Bu model, UML dilinde en az 5 diyagram kullanılarak temsil edilen birçok yönü varsayar, bkz. s. 2.04.2- 2.04.5.

Yönetim yönünü ele alalım. Yönetişim modeli, yapısal modelleri tamamlar.

Sistemin yapısı nasıl tanımlanırsa tanımlansın, bir dizi yapısal birimden (fonksiyonlar veya nesneler) oluşur. Bir bütün olarak çalışabilmeleri için yönetilmeleri gerekir ve statik diyagramlarda kontrol bilgisi yoktur. Kontrol modelleri, sistemler arasındaki kontrol akışını tasarlar.

Yazılım sistemlerinde iki ana kontrol türü vardır.

1. Merkezi yönetim.

2. Olay tabanlı yönetim.

Merkezi yönetim şunlar olabilir:

· Hiyerarşik- "arama-dönüş" ilkesi temelinde (eğitim programları çoğunlukla bu şekilde çalışır)

· Gönderici modeli Paralel sistemler için kullanılır.

V sevk memuru modelleri sistemin bileşenlerinden birinin bir sevk memuru olduğu varsayılır. Hem sistemlerin başlatılmasını ve kapatılmasını hem de sistemdeki diğer süreçlerin koordinasyonunu yönetir. Süreçler birbirine paralel olarak çalışabilir. İşlem, o anda çalışmakta olan bir program, alt sistem veya yordam anlamına gelir. Bu model, kontrol programının bazı durum değişkenlerine bağlı olarak (operatör aracılığıyla) bireysel alt sistemleri çağırdığı sıralı sistemlerde de uygulanabilir. durum).

Olay yönetimi yönetimden sorumlu herhangi bir alt programın bulunmadığını varsayar. Kontrol, harici olaylar tarafından gerçekleştirilir: bir fare düğmesine basmak, bir klavyeye basmak, sensör okumalarını değiştirmek, zamanlayıcı okumalarını değiştirmek vb. Her harici olay kodlanır ve olay kuyruğuna yerleştirilir. Kuyruktaki bir olaya tepki verilirse, bu olaya tepkiyi gerçekleştiren prosedür (alt program) çağrılır. Sistemin tepki verdiği olaylar, diğer alt sistemlerde veya sistemin dış ortamında meydana gelebilir.

Bu tür bir yönetime bir örnek, Windows'taki uygulamaların organizasyonudur.

Daha önce açıklanan yapısal modellerin tümü, merkezi yönetim veya olay tabanlı yönetim kullanılarak uygulanabilir.

Kullanıcı arayüzü

Bir arayüz modeli geliştirirken, sadece tasarlanan yazılımın görevleri değil, aynı zamanda beynin bilgi algısı ile ilgili özellikleri de dikkate alınmalıdır.

III.03.4. a Bilginin algılanması ve işlenmesi ile ilişkili bir kişinin psikofiziksel özellikleri.

Beynin geleneksel olarak algı işlemcisi olarak adlandırılabilecek kısmı, sürekli olarak, bilincin katılımı olmadan, gelen bilgileri işler, geçmiş deneyimlerle karşılaştırır ve depolar.

Görsel bir görüntü dikkatimizi çektiğinde, ilgimizi çeken bilgi kısa süreli belleğe ulaşır. Dikkatimizi çekmediyse, depodaki bilgiler kaybolur ve yerini aşağıdaki bölümler alır.

Zamanın her anında, dikkat odağı bir noktada sabitlenebilir, bu nedenle birkaç durumu aynı anda izlemek gerekirse, odak bir izlenen nesneden diğerine geçer. Aynı zamanda dikkat dağılır ve bazı detaylar gözden kaçabilir. Algının büyük ölçüde motivasyona dayalı olması da önemlidir.

Bir çerçeveyi değiştirirken beyin bir süreliğine bloke olur: En önemli ayrıntıları vurgulayarak yeni bir resimde ustalaşır. Bu, kullanıcıdan hızlı bir yanıt almanız gerekiyorsa, resimleri aniden değiştirmemeniz gerektiği anlamına gelir.

Kısa süreli bellek, bir kişinin bilgi işleme sistemindeki darboğazdır. Kapasitesi 7 ± 2 bağlantısız nesnedir. Talep edilmeyen bilgiler içinde 30 saniyeden fazla saklanmaz. Bizim için önemli olan herhangi bir bilgiyi unutmamak için, genellikle kısa süreli bellekteki bilgileri güncelleyerek kendimize tekrarlarız. Bu nedenle, arayüzleri tasarlarken, ezici çoğunluğun, örneğin beşten fazla basamak içeren sayıları başka bir ekranda hatırlamayı ve girmeyi zor bulduğu akılda tutulmalıdır.

Uzun süreli belleğin kapasitesi ve saklama süresi sınırsız olmasına rağmen bilgiye erişim kolay değildir. Uzun süreli bellekten bilgi çıkarma mekanizması doğada ilişkiseldir. Bilginin ezberlenmesini iyileştirmek için, hafızanın halihazırda depoladığı ve elde edilmesini kolaylaştıran verilere bağlıdır. Uzun süreli belleğe erişim zor olduğu için, kullanıcının bilgiyi hatırlamasını değil, tanıyacağını düşünmesi tavsiye edilir.

III.03.4. b Arayüzleri değerlendirmek için temel kriterler

Önde gelen yazılım geliştirme firmaları tarafından yapılan çok sayıda anket ve anket, kullanıcıların bir arayüze değer verdiğini göstermiştir:

1) mastering ve ezberleme kolaylığı - özellikle mastering süresini ve bilgi ve hafızanın korunma süresini tahmin edin;

2) fare tarafından girilen veya seçilen komut ve ayarların sayısı ile belirlenen, sistemi kullanırken sonuçlara ulaşma hızı;

3) sistemin çalışmasından öznel memnuniyet (kullanım kolaylığı, yorgunluk, vb.).

Ayrıca, sürekli aynı paketle çalışan profesyonel kullanıcılar için, ikinci ve üçüncü kriterler hızla ilk sıraya gelir ve profesyonel olmayan kullanıcılar için periyodik olarak yazılımla çalışan ve nispeten basit görevleri gerçekleştiren - birinci ve üçüncü.

Bu açıdan bakıldığında ücretsiz navigasyonlu arayüzler günümüzde profesyonel kullanıcılar için en iyi özelliklere, profesyonel olmayan kullanıcılar için ise direkt manipülasyon arayüzlerine sahiptir. Dosyaları kopyalarken, diğer her şey eşit olmak üzere, çoğu profesyonelin Far gibi kabukları kullandığı, profesyonel olmayanların ise Windows "sürükle ve bırak" kullandığı uzun zamandır fark edilmiştir.

III.03.4. c Kullanıcı arabirimi türleri

Aşağıdaki kullanıcı arabirimi türleri ayırt edilir:

İlkel

Ücretsiz navigasyon

Doğrudan manipülasyon.

Arayüz ilkel

İlkel kullanıcı ile etkileşimi organize eden ve konsol modunda kullanılan arayüze denir. Verilerin sağladığı sıralı süreçten tek sapma, birden çok veri kümesi arasında döngü yapmaktır.

Menü arayüzü.

İlkel arayüzün aksine, kullanıcının program tarafından görüntülenen özel bir listeden bir işlem seçmesini sağlar. Bu arayüzler, eylemlerin sırası kullanıcılar tarafından belirlenen birçok çalışma senaryosunun uygulanmasını içerir. Menülerin ağaç benzeri organizasyonu, iki seviyeli menülerden daha fazla öğe bulmanın zor olduğunu gösteriyor.

Dağıtılmış sistem mimarisi

Günümüzde, neredeyse tüm büyük yazılım sistemleri dağıtılmaktadır. Dağıtılmış bir sistem, bilgi işlemenin tek bir bilgisayarda değil, birkaç bilgisayar arasında dağıtıldığı bir sistemdir. Diğer yazılımların tasarımıyla pek çok ortak noktası olan dağıtılmış sistemler tasarlarken, dikkate alınması gereken bir dizi özel özellik vardır. Bunlardan bazıları, istemci/sunucu mimarisine baktığımızda Bölüm 10'un girişinde zaten belirtilmişti ve burada daha ayrıntılı olarak tartışıldı.

Dağıtılmış sistemler bu günlerde yaygın olduğu için, yazılım geliştiricilerin tasarımlarının özelliklerine aşina olmaları gerekir. Yakın zamana kadar, tüm büyük sistemler büyük ölçüde merkezileştirildi ve terminallere bağlı tek bir ana bilgisayar (ana bilgisayar) üzerinde çalıştı. Terminaller pratik olarak bilgileri işlemedi - tüm hesaplamalar ana makinede yapıldı. Bu tür sistemlerin geliştiricileri, dağıtılmış bilgi işlem sorunları hakkında düşünmek zorunda değildi.

Tüm modern yazılım sistemleri üç geniş sınıfa ayrılabilir.

1. Yalnızca bir kişisel bilgisayar veya iş istasyonunda çalışmak üzere tasarlanmış uygulama yazılım sistemleri. Bunlara kelime işlemciler, elektronik tablolar, grafik sistemleri ve benzerleri dahildir.

2. Tek bir işlemcide veya tümleşik bir işlemci grubunda çalışacak şekilde tasarlanmış yerleşik sistemler. Bunlar, ev aletleri, çeşitli aletler vb. için kontrol sistemlerini içerir.

3. Yazılımın, bir ağ aracılığıyla birbirine bağlı, zayıf bir şekilde entegre edilmiş paralel işlemciler grubu üzerinde çalıştığı dağıtılmış sistemler. Bunlara bir bankanın sahip olduğu ATM sistemleri, yayın sistemleri, paylaşılan yazılım sistemleri vb. dahildir.

Şu anda, listelenen yazılım sistemleri sınıfları arasında, gelecekte giderek daha da bulanıklaşacak olan net sınırlar vardır. Zamanla, yüksek hızlı kablosuz ağlar yaygın olarak kullanılabilir hale geldikçe, cihazları daha genel sistemlerle elektronik düzenleyiciler gibi gömülü yazılım sistemleriyle dinamik olarak entegre etmek mümkün olacaktır.

Dağıtılmış sistemlerin altı ana özelliği vardır.

1. Kaynakları paylaşmak. Dağıtılmış sistemler, sabit sürücüler, yazıcılar, dosyalar, derleyiciler ve bir ağ aracılığıyla birbirine bağlanan benzerleri gibi donanım ve yazılım kaynaklarının paylaşılmasına izin verir. Çok kullanıcılı sistemlerde kaynakların paylaşımının da mümkün olduğu açıktır, ancak bu durumda kaynakların sağlanmasından ve yönetiminden merkezi bilgisayar sorumlu olmalıdır.

2. Açıklık. Bu, yeni kaynaklar ekleyerek sistemi genişletme yeteneğidir. Dağıtılmış sistemler, farklı üreticilerin donanım ve yazılımlarını birbirine bağlayan açık sistemlerdir.

3. paralellik. Dağıtılmış sistemlerde, ağ üzerindeki farklı bilgisayarlarda aynı anda birden fazla işlem çalışabilir. Bu süreçler, çalışırken birbirleriyle etkileşime girebilir (ancak buna gerek yoktur).

4. Ölçeklenebilirlik. Prensip olarak, tüm dağıtılmış sistemler ölçeklenebilir: yeni gereksinimleri karşılamak için sistem yeni bilgi işlem kaynakları eklenerek genişletilebilir. Ancak uygulamada, sistemdeki bireysel bilgisayarları birbirine bağlayan ağla sınırlı olabilir. Birçok yeni makine bağlıysa, ağ bant genişliği yeterli olmayabilir.

5. Hata toleransı. Birden fazla bilgisayarın varlığı ve bilgileri çoğaltma yeteneği, dağıtılmış sistemlerin belirli donanım ve yazılım hatalarına karşı dirençli olduğu anlamına gelir. Çoğu dağıtılmış sistem, bir hata durumunda, genellikle en azından kısmi işlevselliği destekleyebilir. Sistemin tam bir arızası, yalnızca ağ hataları durumunda meydana gelir.

6. Şeffaflık. Bu özellik, kullanıcılara kaynaklara tamamen şeffaf erişim verildiği ve aynı zamanda sistemdeki kaynakların dağılımı hakkındaki bilgilerin onlardan gizlendiği anlamına gelir. Bununla birlikte, çoğu durumda, sistemin organizasyonuna ilişkin özel bilgi, kullanıcının kaynakları daha iyi kullanmasına yardımcı olur.

Elbette, dağıtılmış sistemlerin bir takım dezavantajları vardır.

Karmaşıklık. Dağıtılmış sistemler merkezi sistemlerden daha karmaşıktır. Genel olarak dağıtık sistemlerin özelliklerini anlamak ve değerlendirmek ve ayrıca bu sistemleri test etmek çok daha zordur. Örneğin, burada sistem performansı bir işlemcinin hızına değil, ağ bant genişliğine ve farklı işlemcilerin hızına bağlıdır. Kaynakları sistemin bir bölümünden diğerine taşımak, sistem performansını büyük ölçüde etkileyebilir.

Güvenlik. Tipik olarak, sisteme birkaç farklı makineden erişilebilir, ağdaki mesajlar görüntülenebilir veya engellenebilir. Bu nedenle, dağıtık bir sistemde güvenliği sağlamak çok daha zordur.

Kontrol edilebilirlik. Sistem, farklı işletim sistemleri sürümlerinin kurulabileceği farklı bilgisayar türlerinden oluşabilir. Bir makinedeki hatalar, öngörülemeyen sonuçlarla diğer makinelere yayılabilir. Bu nedenle, sistemi çalışır durumda yönetmek ve sürdürmek için çok daha fazla çaba gerekir.

Tahmin edilemezlik. Tüm Web kullanıcılarının bildiği gibi, dağıtılmış sistemlerin belirli olaylara tepkisi tahmin edilemez ve sistemin tam yüküne, organizasyonuna ve ağ yüküne bağlıdır. Tüm bu parametreler sürekli değişebileceğinden, kullanıcının isteğinin bir anda yerine getirilmesi için harcanan süre önemli ölçüde değişebilir.

Dağıtık sistemlerin avantajları ve dezavantajları tartışılırken, bu tür sistemler için bir takım kritik tasarım problemleri tanımlanır (Tablo 9.1).

Tablo 9.1. Dağıtık Sistem Tasarım Problemleri

Tasarım sorunu	Açıklama
kaynak tanımlama	Dağıtılmış bir sistemdeki kaynaklar farklı bilgisayarlarda bulunur, bu nedenle kaynak adlandırma sistemi, kullanıcıların ihtiyaç duydukları kaynaklara kolayca erişebilecekleri ve başvurabilecekleri şekilde düşünülmelidir. Bir örnek, Web sayfalarının adreslerini tanımlayan Tekdüzen Kaynak Bulucu (URL) sistemidir. Kolayca algılanan ve evrensel bir tanımlama sistemi olmadan, kaynakların çoğu sistem kullanıcıları için erişilemez olacaktır.
iletişim	İnternetin evrensel çalışabilirliği ve çoğu dağıtılmış sistem için İnternet üzerinde TCP / IP protokollerinin verimli bir şekilde uygulanması, bilgisayarlar arasındaki iletişimi organize etmenin en etkili yolunun örnekleridir. Bununla birlikte, performans, güvenilirlik vb. ile ilgili özel gereksinimlerin uygulandığı durumlarda, alternatif sistem iletişim yöntemleri kullanılabilir.
Sistem hizmet kalitesi	Sistemin sunduğu hizmet kalitesi, performansını, işlerliğini ve güvenilirliğini yansıtır. Hizmet kalitesi bir dizi faktörden etkilenir: sistem süreçlerinin dağılımı, kaynak tahsisi, sistem ve ağ donanımı ve sistemin uyarlanabilirliği.
Yazılım mimarisi	Yazılım mimarisi, sistem işlevlerinin sistem bileşenleri arasında dağılımını ve bu bileşenlerin işlemciler arasında dağılımını tanımlar. Yüksek kaliteli bir sistem hizmetini sürdürmeniz gerekiyorsa, doğru mimariyi seçmek belirleyici bir faktör olarak ortaya çıkıyor.

Dağıtılmış sistem tasarımcıları için zorluk, dağıtılmış bir sistemin gerekli tüm özelliklerini sağlamak için yazılım veya donanım tasarlamaktır. Bu, çeşitli dağıtılmış sistem mimarilerinin avantajlarını ve dezavantajlarını bilmeyi gerektirir. Burada birbiriyle ilişkili iki tür dağıtılmış sistem mimarisi göze çarpmaktadır.

1. İstemci / sunucu mimarisi. Bu modelde sistem, sunucular tarafından istemcilere sağlanan hizmetler dizisi olarak düşünülebilir. Bu tür sistemlerde sunucular ve istemciler birbirinden önemli ölçüde farklılık gösterir.

2. Dağıtılmış Nesne Mimarisi. Bu durumda, sunucular ve istemciler arasında hiçbir fark yoktur ve sistem, konumu gerçekten önemli olmayan bir dizi etkileşimli nesne olarak düşünülebilir. Servis sağlayıcı ve kullanıcıları arasında bir ayrım yoktur.

Dağıtılmış bir sistemde, farklı sistem bileşenleri farklı programlama dillerinde uygulanabilir ve farklı işlemci türleri üzerinde çalıştırılabilir. Veri modelleri, bilgi sunumu ve iletişim protokolleri, dağıtılmış bir sistemde mutlaka aynı türden olmak zorunda değildir. Sonuç olarak, dağıtılmış sistemler, bu heterojen parçaları yönetebilen ve bunlar arasındaki etkileşimi ve veri alışverişini garanti eden yazılımlara ihtiyaç duyar. ara katman yazılımı tam olarak bu yazılım sınıfını ifade eder. Sanki sistemin dağıtılmış bileşenlerinin farklı bölümleri arasında ortadadır.

Dağıtılmış sistemler genellikle nesne yönelimli bir yaklaşımla tasarlanır. Bu sistemler, her biri hem kullanıcı hem de sistemin diğer bölümleri ile doğrudan etkileşime girebilen gevşek entegre parçalardan oluşturulur. Bu parçalar, mümkün olduğunca bağımsız olaylara tepki vermelidir. Bu ilkelere dayalı yazılım nesneleri, dağıtılmış sistemlerin doğal bileşenleridir. Nesne kavramına zaten aşina değilseniz.

V büyük holdingler yan kuruluşlarda on binlerce kullanıcı çalışıyor. Her kuruluşun kendi iç iş süreçleri vardır: belgelerin onaylanması, talimatların verilmesi vb. Aynı zamanda bazı süreçler bir şirketin sınırlarının ötesine geçerek diğerinin çalışanlarını da etkiliyor. Örneğin, genel müdürlük başkanı bağlı şirkete bir emir verir veya bağlı şirketin bir çalışanı, ana şirketin avukatlarına onay için bir sözleşme gönderir. Bu, birden fazla sistem kullanan karmaşık bir mimari gerektirir.

Ayrıca, içinde bir şirket farklı sorunları çözmek için birçok sistem kullanılır: muhasebe işlemleri için ERP sistemi, organizasyonel ve idari belgeler için ECM sistemlerinin ayrı kurulumları, tasarım ve tahmin belgeleri için vb.

DIRECTUM sistemi, hem holding içinde hem de bir organizasyon düzeyinde farklı sistemlerin etkileşimini sağlamaya yardımcı olacaktır.

DIRECTUM, bina için uygun araçlar sağlar yönetilen dağıtılmış mimari aşağıdaki görevleri organize etmek ve çözmek:

• aynı şirketin ve holdingin çeşitli sistemleri arasında uçtan uca iş süreçlerinin organizasyonu ve veri senkronizasyonu;
• ECM sistemlerinin farklı kurulumlarından verilere erişim sağlanması. Örneğin, birkaç özel sistemde bir belge arayın: finansal belgelerle, tasarım ve tahmin belgeleriyle vb.
• birçok sistem ve hizmetin tek noktadan yönetilmesi ve konforlu bir BT altyapısının oluşturulması;
• geliştirmenin dağıtılmış üretim sistemlerine uygun şekilde dağıtılması.

Yönetilen Dağıtılmış Mimarinin Bileşenleri

Arabağlantı Mekanizmaları (DCI)

DCI mekanizmaları, uçtan uca iş süreçlerini düzenlemek ve bir veya birkaç kuruluş (holding) içindeki farklı sistemler arasında verileri senkronize etmek için kullanılır.

Çözüm, şirketlerde var olan yerel iş süreçlerini tek bir uçtan uca sürece bağlar. Çalışanlar ve yöneticileri, zaten tanıdık olan görev, belge ve referans kitap arayüzüyle çalışır. Aynı zamanda, çalışanların eylemleri her aşamada şeffaftır: ilgili bir şirketle yazışma metnini görebilir, ana kuruluşla belge onay durumunu görebilir vb.

DCI'ya çeşitli DIRECTUM kurulumları ve diğer sistem sınıfları (ERP, CRM, vb.) bağlanabilir. Kural olarak, tesisler, kuruluşların bölgesel veya yasal konumları ve diğer faktörler dikkate alınarak iş alanlarına bölünür.

DCI ile birlikte, geliştiricinin organizasyonunun iş süreçleri için bir algoritma oluşturabilmesi sayesinde, geliştirme bileşenlerine ayrıntılı bir açıklama ve kod örnekleri sağlanır.

DCI mekanizmaları, büyük miktarda veri iletebilir ve pik yüklere dayanabilir. Ayrıca, iletişim arızaları durumunda hata toleransı ve iletilen verilerin korunmasını sağlarlar.

Birleşik arama

Birleşik arama ile, ihtiyacınız olan görevleri veya belgeleri tüm DIRECTUM sistemlerinde tek seferde bulabilirsiniz. Örneğin, çalışan sistemde ve arşivlenmiş belgelerle sistemde aynı anda bir arama başlatın.

Birleşik arama şunları yapmanızı sağlar:

• bir bağlı kuruluştaki giden bir belgenin onay ilerlemesini web istemcisi aracılığıyla görüntülemek;
• Örneğin, müzakerelerin hazırlanması için tüm yan kuruluşlarda bir karşı tarafla yapılan sözleşmeleri bulun. Bu durumda sözleşmelerin eklendiği görevlere gidebilirsiniz;
• ana kuruluştan bağlı kuruluşa gönderilen siparişin yürütme durumunu veya üzerinde oluşturulan belge ve görevleri kontrol edin;
• Farklı uzmanlıklara sahip çeşitli sistemlerde, örneğin organizasyonel ve idari belgeler ve sözleşmeler gibi belgeleri aynı anda bulun;
• çalışma sisteminde ve belge arşivi ile sistemde karşı tarafla derhal denetim veya mutabakat için birincil muhasebe belgelerini bulmak;
• meslektaşlarınızla arama sonuçlarına bağlantı alışverişi yapın.

Yönetici standart aramaları değiştirebilir, yenilerini ekleyebilir ve ayrıca hangi sistemlerin kullanıcı tarafından görülebileceğini özelleştirebilir.

DIRECTUM Hizmetler Yönetim Merkezi

DIRECTUM sistemi birçok farklı görevi çözer: çalışanların etkileşimi, belgelerin saklanması vb. Bu, hizmetlerinin güvenilir çalışması nedeniyle mümkündür. Ve büyük şirketlerde, DIRECTUM sisteminin tüm kurulumlarını, örneğin arşiv belgelerinin depolanması gibi belirli bir görev için kendi hizmet setleriyle tahsis ederler. Kurulumlar ve hizmetler birden çok sunucuya dağıtılır. Bu altyapının yönetilmesi gerekiyor.

DIRECTUM Hizmetleri Yönetim Merkezi, DIRECTUM hizmetlerini ve sistemlerini yapılandırmak, izlemek ve yönetmek için tek bir idari giriş noktasıdır. Merkez, Oturum Sunucusu, İş Akışı Hizmeti, Olay Hizmeti, Dosya Depolama Hizmeti, Giriş ve Dönüştürme Hizmetleri, Birleşik Arama ve Web Yardımını yönetmek için araçlar içeren bir sitedir.

Uzak sistemlerin ve hizmetlerin uygun görsel konfigürasyonu, yöneticinin işini kolaylaştırır. Her sunucuya gitmesine ve yapılandırma dosyalarında manuel olarak değişiklik yapmasına gerek yoktur.

Hizmetler tek tıklamayla durdurulur ve etkinleştirilir. Servis durumu anında ekranda görüntülenir.

Ayarlar listesi doldurulabilir ve filtrelenebilir. Varsayılan olarak, site yalnızca temel ayarları görüntüler. Aynı zamanda, tüm ayarlar için doldurma önerileri içeren ipuçlarını görebilirsiniz.

DIRECTUM sistemi, dağıtılmış kuruluşların çalışmalarını etkin bir şekilde düzenler ve kullanıcılara şeffaf bir belge, görev ve dizin kaydı alışverişi sağlar.

Yönetilen Dağıtılmış Mimarinin her bir bileşeni ayrı ayrı kullanılabilir, ancak bunlar birlikte kuruluşunuza daha fazla iş değeri getirebilir.

Bu tür bir sistem, sistem organizasyonu açısından daha karmaşıktır. öz dağıtılmış sistemlerönemli verilerin yerel kopyalarını tutmaktır.

şematik olarak böyle mimariŞekil l'de gösterildiği gibi temsil edilebilir. 5.6.

Pirinç. 5.6. Dağıtılmış sistem mimarisi

Kurumsal yönetimde kullanılan verilerin %95'inden fazlası tek bir kişisel bilgisayarda bulunabilir ve bu da bağımsız olarak çalışmasını mümkün kılar. Bu bilgisayarda oluşturulan düzeltmeler ve eklemeler akışı, kullanılan veri miktarıyla karşılaştırıldığında önemsizdir. Bu nedenle, sürekli olarak kullanılan verileri bilgisayarların kendisinde saklarsanız ve bunlar arasında depolanan verilere yönelik düzeltme ve ekleme alışverişini düzenlerseniz, iletilen toplam trafik keskin bir şekilde düşer. Bu, bilgisayarlar arasındaki iletişim kanalları için gereksinimleri azaltmanıza ve daha sık asenkron iletişim kullanmanıza ve böylece bağımsız öğeleri bağlamak için İnternet, mobil iletişim ve ticari uydu kanalları gibi kararsız iletişimi kullanan güvenilir şekilde işleyen dağıtılmış bilgi sistemleri oluşturmanıza olanak tanır. Ve öğeler arasındaki trafiği en aza indirmek, böyle bir bağlantının işletme maliyetini oldukça uygun hale getirecektir. Tabii ki, böyle bir sistemin uygulanması temel değildir ve biri verilerin zamanında senkronizasyonu olan bir dizi sorunun çözülmesini gerektirir.

Her AWS bağımsızdır, yalnızca çalışması gereken bilgileri içerir ve tüm sistemdeki verilerin uygunluğu, diğer AWS'lerle sürekli mesaj alışverişi yoluyla sağlanır. AWP'ler arasındaki mesaj alışverişi, e-posta ile veri göndermekten ağlar üzerinden veri transferine kadar çeşitli şekillerde uygulanabilir.

Böyle bir çalışma planının avantajlarından bir diğeri ve mimari sistem, verilerin güvenliği için kişisel sorumluluk olasılığını sağlamaktır. Belirli bir iş yerinde bulunan veriler, şifreleme araçları ve özel donanım anahtarları kullanılarak yalnızca bu bilgisayarda bulunduğundan, BT yöneticileri de dahil olmak üzere dışarıdan kişiler için verilere erişim engellenir.

Çok mimari sistem ayrıca istemci makineler arasında dağıtılmış bilgi işlem düzenlemenize de olanak tanır. Örneğin, büyük hesaplamalar gerektiren bir görevin hesaplanması, kural olarak veritabanlarında aynı bilgilere sahip olmaları ve böylece maksimum sistem performansı elde etmeleri nedeniyle komşu iş istasyonları arasında dağıtılabilir.

Çoğaltma ile dağıtılmış sistemler

Farklı iş istasyonları ve merkezi veri deposu arasındaki veriler, çoğaltma yoluyla iletilir (Şekil 5.7). İş istasyonlarına bilgi girerken, veriler yerel veritabanına da yazılır ve ancak o zaman senkronize edilir.

Pirinç. 5.7.Çoğaltma ile dağıtılmış sistem mimarisi

Uzaktan yürütme öğelerine sahip dağıtılmış sistemler

Geleneksel bir çoğaltma türü dağıtılmış sistemde niteliksel olarak uygulanamayan belirli özellikler vardır. Bu özellikler şunları içerir:

uzak bir sunucuda (düğüm) depolanan varlıklardan gelen verileri kullanma;

farklı sunucularda (düğümler) depolanan varlıklardan verilerin kısmi kullanımı;

ayrılmış bir sunucuda (düğüm) yalıtılmış işlevsellik kullanımı.

Açıklanan türlerin her biri genel bir ilke kullanır: bir istemci programı ya doğrudan atanmış (uzak) bir sunucuya erişir ya da bir uzak sunucuya yapılan çağrıyı içine alan yerel bir veritabanına erişir (Şekil 5.8).

Pirinç. 5.8. Uzaktan Yürütme Dağıtılmış Sistem Mimarisi