Şu anda klasik bir n katmanlı uygulamamız var: DB / web hizmeti / ön uç. Diğer bileşenleri var, ancak temel düzen.

Uygulama kullanılabilirliğini 3 ana nedenden dolayı iyileştirmek istiyoruz:

1. Ev sahibimiz bazen (hepsi gibi) kesintiler yaşar ve müşterilerimiz üzerindeki etkiyi en aza indirmek istiyoruz, bu nedenle örneğin veri merkezi A kapalı olduğunda veri merkezi B'yi açacaklardı.
2. Sürümü yükselttiğimizde, siteyi bakım amacıyla kapattık ve genellikle birkaç saat sürüyor (geçiş komut dosyaları, vb.). Kullanıcıların olabildiğince az kesinti süresi ile daha sorunsuz bir geçiş yapmasını istiyoruz (A sunucusu yükseltilirken B sunucusunu kullanıyorlar).
3. İsteğe bağlı olarak, müşterilerimiz dünyanın dört bir yanında bulunmaktadır ve olası crappy bağlantılarına rağmen mümkün olan en iyi deneyime sahip olmalarını istiyoruz (Hint devs ile çalışan herkes ne demek istediğimi bilmelidir). İdeal olarak, ofislerine bir sunucu ekleyebiliriz (veya şehirlerinin yakınında bir veri merkezi kullanabiliriz) ve mimarimize sorunsuz bir şekilde entegre olur.

Uzaktan% 99 kullanılabilirliğe ihtiyacımız yok,% 95 bile değil. Bu bir belge yönetimi uygulaması. Kimse umursamaz. Ancak, geçişler biraz zaman alabildiğinden ve dünya çapında müşteriler olduğundan, bazen bir müşterinin günlerinin çoğunda çalışmasını engelliyoruz.

SQL parçası için, "uygun" DBA'lar olmasa da , SQL olasılıklarını biliyoruz : çoğaltma, yansıtma, vb. DB tarafında, bunun için kaynak bulmak oldukça kolaydır. Daha zor olan her şeydir: oturumları, kodu vb. Saklamak Web servis sunucum çökerse, arayüzümün değişmesi gerektiğini nasıl bilebilir? Oturumlarım sunucular arasında nasıl devam ediyor?

Ne yazık ki, hiçbirimiz bu alanda deneyime sahip değiliz ve nereden bakmaya başlayacağımızı bile bilmiyoruz. Bunun için en iyi uygulamalar var mı? Tasarım desenleri? Kütüphaneler (paramız olmadığı için ücretsiz olmalı)?

ASP.Net ve SQL Server kullanıyoruz, ortada bir WCF web servisi var. Bir sürü Windows hizmetimiz var, ancak bunlar kritik öneme sahip değiller ve web sitesi ile başa çıkma yöntemlerinin hizmetler için geçerli olacağını varsayıyorum.

Çoğu bulut platformunun bunun için yerleşik bir sistem sağladığını anlıyorum, ancak bulut barındırma, her şeyi kendileri yönetmek ve kimseye güvenmek istemeyen sistem yöneticimiz nedeniyle hareketsizdir.

Ne tür bir yüksek kullanılabilirlik aradığınızı netleştirmeniz gerekiyor. Çalıştığım ve% 95 oranında olması gereken yüksek kullanılabilir uygulamalar var. % 99 koşması gereken başkaları da var. % 100 çalışma süresi gerektiren ölüm kalım senaryolarını düşünebilirim. Sadece bu üçünün çok farklı yaklaşımları ve maliyetleri var.

İhtiyaçlarınıza ve% 95-99 çalışma süresi SLA'sına göre tahmin etme:

• Veritabanı değişikliklerinin çoğu değişiklik için gerçek zamanlı olarak gerçekleşebilmesi gerekir. Pratik Evrimsel veritabanı tasarımı . Daha invaziv davranış gerektiren değişiklikler için birkaç seçeneğiniz vardır. Birincisi çalışmama süresini almak. Mümkünse, hizmetinizi salt okunur modda çalıştırmak işe yarayabilir. Tam işlevsellik için, bir süredir ScaleArc'ı denemek istiyordum. SQL Server dünyasında ölçeklendirme ve esneklik için gerçekten kaygan bir araç gibi görünüyor.
• Sunucuları, müşterinizin sitelerine koymak, birinci sınıf dağıtım stratejileriniz (taşıma işlemlerinizin açıklamasına dayanarak henüz sahip değilseniz) yönetilemeyen bir felaket için bir reçetedir. Performans sorunlarınız olduğu için bulut hizmetlerini yerinde zorlamayın. Performans sorunlarını şimdi çözün ve sonra daha pahalı olanlarla uğraşmak zorunda kalmayacaksınız.
• Durum sunucunuz bir tür veritabanı olmalıdır. HA talimatlarına uyun. Bunun için SQL Server'ı kullanabilirsiniz, çünkü zaten kullanılabilir.
• Veritabanlarından bahsetmişken, çoğaltma HA'yı etkinleştirmez. Aslında, SQL Çoğaltma her turda baş ağrısına neden olur (birden fazla düğüm çoğaltma senaryosu deneyiminden bahsederek). Yansıtma işe yarayabilir, ancak en son hatırladığım kadarıyla SQL kümelemenin yeni sunucuya geçmesi 1-5 dakika sürer. AlwaysOn hakkında iyi şeyler duydum, ancak Microsoft'un geçmişine baktığımda hala şüpheliyim. ScaleArc gibi bir şey burada daha fazla yardımcı olabilir.
• Web sunucunuz vatansız olmalıdır. Üç veya dört yukarı çevirin ve bir yük dengeleyicinin arkasına koyun. Bu, çalışma sürenizi orada çözer. Frederik'in daha önce de belirttiği gibi, haddeleme dağıtımlarını da bu şekilde yapabilirsiniz.
• Web hizmetiniz muhtemelen vatansız olmalıdır. Değilse, vatansız ve durumsal bitlere ayırabilir misiniz? Birden fazla örneğini aynı yük dengeleyicinin arkasına koymak, çalışma zamanı endişelerini çözer ve daha fazla ilgilenilen dağıtım senaryoları sağlar (örn. Mavi / yeşil dağıtımlar).

Frederik'in aksine, bulut paranoyasına haksız demeyeceğim. Çalışma zamanı gereksinimlerinize bağlıdır. Bir hizmetin yedeklilik uğruna farklı ülkelerdeki farklı sağlayıcılar tarafından işletilen birden fazla veri merkezinde çalışması gerektiği düşünülebilir. Bununla birlikte, mevcut durumunuz göz önüne alındığında, AWS, Azure veya benzerinin şirketiniz için muhtemelen güvenli bahisler olduğunu kabul ediyorum.

Web ve uygulama katmanınızda bir miktar HA elde etme:

1. İdeal olarak, oturum durumu dahil herhangi bir durumu veritabanı veya bellek içi oturum durumu sunucusu gibi paylaşılan durum sistemlerine dahil etme. Uygulama tasarımınıza bağlı olarak, ek gecikmenin büyük miktarda durum alması nedeniyle performans sorunlarına neden olabilir.

2. Web sitenizin ve uygulama katmanınızın her birinin önünde bağımsız bir yük dengeleyici olmalıdır. NGINX hile yapacak, ancak IIS bunu da yapabilir (ARR).

3. Tek bir veritabanı yükü kaldıramazsa, belirli bir isteği belirli bir veritabanı kutusuna yönlendirmek için oturum durumu bölümlemesinden (veya parçalama veya tutarlı karma) yararlanın.

Faktoring çıkış durumu çok zorsa, yük dengeleme için sunucu benzeşimi ile gidebilirsiniz (örneğin, kullanıcılar sürekli olarak aynı kutuya yönlendirilir, genellikle çerez tabanlı). Vatansız yuvarlak robin yaklaşımı kadar yüksek düzeyde mevcut değildir, çünkü bir kutu kesintisi bu kutudaki tüm kullanıcıları ve durumu etkileyecektir, ancak tam bir kesintiyi yener (kullanım durumuna bağlı).

Yükseltme tarafında:

1. Veritabanı komut dosyalarınızı, sistem çalışırken veritabanı yükseltmeleri yapılabilecek şekilde, başka bir deyişle geriye doğru uyumluluğu koruyacak şekilde tasarlayın. Bunun için iyi çalışan bir desen "genişlet, sonra daralt" -> yalnızca ek, geriye doğru uyumlu değişiklikler yapmak, ancak kurtulmak istediğiniz alanlara (vb.) Bağımlılıkları kaldırmak; sonra veritabanının tüm istemcilerini v-latest sürümüne yükseltin; sonra veritabanındaki eski alanlardan (vb.) kurtulmak için başka bir db-yükseltmesi yapın. Büyük bir veritabanınız varsa ve sisteminizin performansını düşürmemeye dikkat etmeniz gerekiyorsa, bu yavaş bir işlem olabilir.

2. Uygulama katmanınızı yükseltme: Bir bulut ortamı kullanmadığınızdan, kanarya dağıtım düzenini izlemenizi öneririm: web ve orta katman kutularınızın sürekli yükseltmesini yapın. Dağıtım yanlış giderse, kutuyu yük dengeleyiciden çıkarın, tıpkı başarısız olmuş gibi.

Uyarı kelimesi: HA için tasarlanmamış bir sistemi bir sisteme dönüştürmek uzun ve maliyetli bir süreç olabilir. Yol boyunca değiş tokuş yapmak zorunda kalacaksınız (belirli bir kullanılabilirlik seviyesine ulaşmak için maliyet vs çaba)

Bulut paranoya garanti edilmez - AWS gibi sağlayıcılar sizin tarafınızdan iyi bir uygulama ile birlikte çoğu riski kontrol edebilir / azaltabilir - hangi düzenlemelere uyduklarını öğrenmek için uyumluluk sayfalarına göz atabilirler: https: // aws .amazon.com / uyum /

TL; DR: Yedekli, modüler yapı; kullanılabilirlik testi; yakından izleyin.

Herhangi bir açıklamada sıkıştırmaya çalışmanın çok uzun sürebileceğini fark ettikten sonra yaptığım tüm gözlemleri yazacağım.

Önermenin sorgulanması

Bulut sistemi her derde deva

En iyi bulut sağlayıcısıyla tamamen bulutta olsanız bile, uygulamanızı esneklik için tasarlamanız gerekir. AWS, VM'nizin yerini alabilir, ancak hesaplamanın ortasında bırakılırsa uygulamanızın yeniden başlayabilmesi gerekir.

Bulut sistemini kullanmak istemiyoruz, çünkü x / y / z

Ultra büyük bir kuruluş değilseniz, bulut sistemlerini daha iyi kullanabilirsiniz. En iyi 3 bulut sistemi (AWS, MSFT, Google) size vaat edilen SLA'ları ve yönetimi kolay gösterge tablosunu sunmak için binlerce mühendis kullanır. Aslında bu şirket içi bir kuruş harcamak yerine onları kullanmak için iyi bir pazarlık.

Kapsam belirleme ve tasarım problemleri

Bir hizmetin kullanılabilirliğini tanımlamak, ölçmek ve sonra sürekli ölçmek, kullanılabilirlik sorunları için çözüm yazmaktan daha büyük bir sorundur.

'Kullanılabilirliği' tanımlamak ve ölçmek beklenenden daha zor

Birden fazla paydaş mevcudiyetin farklı bir görüşüne sahiptir ve olabilecek en yüksek maaşa sahip bir kişi tarafından tercih edilen tanım, diğer tanımları koyar. Bu bazen doğru tanımdır, ancak çoğu zaman eko-sistem aynı şeyi ölçmek etrafında kurulmaz, çünkü ideal tanım gerçek zamanlı olarak izlemek yerine ölçmek için çok zordur. Gerçek zamanlı olarak izlenemeyen bir kullanılabilirlik tanımınız varsa, kendi kendine benzer projenizi tekrar tekrar ürkütücü benzerliklerle bulacaksınız. Mantıklı ve kolayca izlenebilir bir şeyle devam edin.

İnsanlar her zaman mevcut olan sistemin karmaşıklığını hafife alırlar.

Odadaki fili ele almak için şunu söyleyeyim: "Hiçbir çoklu bilgisayar sistemi% 100 mevcut değil, gelecekte olabilir, ancak mevcut teknolojiyle değil." Burada mevcut teknoloji ile, ışık hızından ve bu gibi şeylerden daha hızlı sinyal gönderememize atıfta bulunuyorum. Tuzlarına değecek tüm comp-sci mühendisleri dağıtılmış bilgi işlem sınırlamalarını biliyorlar ve çoğu toplantılarda bundan bahsetmeyecek, noobs gibi görüneceklerinden korkuyorlar. Diyelim ki, karmaşık bilgisayar kısıtlamalarından bahsetmeyen herkesi telafi etmek , karmaşık ama her zaman bilgisayarlara güvenmiyorum .

İnsanlar mühendislerinin yeteneklerini abartır

Ne yazık ki, kullanılabilirlik ne istediğinizi bilmediğiniz ancak ne istemediğinizi bildiğiniz kategoriye girer. UI gibi 'istekleri biliyor' kategorisi biraz daha zordur. Başkalarının deneyimlerinden ve biraz daha fazlasını öğrenmek için biraz deneyim ve çok fazla okuma gerektirir.

Sıfırdan kullanılabilir bir sistem oluşturmak

Sistem gereksinimi olarak kullanılabilirliğin doğru önceliği hakkında her mimariye ve tasarım ekibine evanjel yapacağınızdan emin olun.

Kullanılabilirliğe yardımcı olan sistem özellikleri

Aşağıdaki sistem özelliklerinin sistemin kullanılabilirliğine katkıda bulunduğu gösterilmiştir:

fazlalık

Bunun bazı örnekleri hiçbir zaman VIP'in arkasında yalnızca tek bir VM'ye sahip olmamak veya asla verilerinizin tek bir kopyasını saklamamaktır. Bunlar, iyi bir IAAS'ın çözmenizi kolaylaştıracağı, ancak yine de bu kararları vermeniz gereken sorular.

Modülarite

Modüler bir REST , monolitik SOA'dan daha iyidir. Daha da modüler microservice aslında daha müsait normalden daha HATEOS DİNLENME . Akıl yürütme, sonraki bölümdeki Verim ile ilgili tartışmada bulunabilir. Toplu işlem yapıyorsanız, 1.000.000'luk bir parti ile uğraşmaya kıyasla 10'lu makul bir parti halinde toplu işlem yapmak daha iyidir.

Esneklik

"I am always angry"
                    - Hulk

Esnek bir sistem her zaman iyileşmeye hazırdır. Bu esneklik, ACK'yı yalnızca RAID diskine yazdıktan sonra ve muhtemelen en az iki veri merkezi üzerinden yazma için onaylama gibi durumlar için geçerlidir. Bir diğer son trend, veri yapısının iki farklı sürümle sunulduğunda çakışmaları çözme sorumluluğunu üstlendiği çakışmayan veri yapılarını kullanmaktır . Bir sistem sonradan düşünülecek kadar dayanıklı olamaz, tahmin edilmesi ve yerleşik olması gerekir. Uzun vadede bir başarısızlık garanti edilir, bu yüzden her zaman iyileşme planı ile hazırlanmalıyız.

Günlük izi

Bu teknik olarak bir Resilience alt türüdür, ancak tüm yetenekleri yakalaması nedeniyle çok özeldir. En iyi çabaya rağmen, kullanılamama modelini tahmin edemeyebiliriz. Mümkünse, sistem olaylarını oynatabilmek için sistem etkinliklerinin yeterli günlük kaydını tutun. Bu, büyük bir manuel maliyetle, öngörülemeyen durumlardan kurtulmanızı sağlar.

Kullanılabilirlik özellikleri

'Kullanılabilirlik' için kapsamlı olmayan akılda kalıcı özellik listesi: Tartışma uğruna, kullanıcının "Alışveriş sepetimde kaç öğe var?"

doğruluk

Eğer Do gerekir en doğru olası bir cevap üretmek veya Tamam yapmak hatalar nedir? Sadece referans olarak, ATM'den para çektiğinizde, doğru olduğu garanti edilmez. Banka bunun bir hata yaptığını öğrenirse, işlemleri tersine çevirebilirsiniz. Sisteminiz asal sayılar üretiyorsa, tahmin ediyorum, her zaman doğru cevaplar isteyebilirsiniz.

Yol ver

Önceki konu sorusu için her zaman doğru cevapladıysanız bu noktayı atlayın. Bazen soruların cevabının kesin olması gerekmez, örneğin şu anda Facebook'ta kaç arkadaşım var? Ancak cevabın her zaman +/- 1 basketbol sahasında olması bekleniyor. Beklenen sonucu verirken veriminiz 100 olur.

Tutarlılık

Cevabınız bir noktada doğru olabilir, ancak ışık ekrandan çıkıp gözlemcinin retinasına girdiğinde işler değişebilirdi. Cevabınızı yanlış yapıyor mu? Hayır, sadece tutarsız hale getiriyor. Çoğu uygulama nihai olarak tutarlıdır, ancak püf noktası, uygulamanızın ne tür bir tutarlılık modeli sağlayacağını tanımlamaktadır. Şans eseri uygulamanız tek bir bilgisayarda çalışabilir, bu güzel okumayı CAP teoreminde atlayabilirsiniz .

Maliyet

Çok şey, kısa vadeli etkilerin (gelir kaybı) ve uzun vadeli etkilerin (kötü itibar, müşteriyi elde tutma) toplam etkisine bağlıdır. Müşteri türüne (ücretli / ücretsiz, tekrar / benzersiz, esir) ve kaynak kullanılabilirliğine bağlı olarak farklı düzeylerde kullanılabilirlik garantileri oluşturulmalıdır.

Mevcut bir sistemin kullanılabilirliğini iyileştirmeye doğru

Bireysel makinelerin ve bir ağın operasyonel yönetimi o kadar karmaşıktır ki, bunu bulut sağlayıcısına bıraktığınızı veya ne yaptığınızı bilecek kadar uzman olduğunuzu varsayıyorum. Kullanılabilirlik altındaki diğer konulara değineceğim. Uzun vadeli strateji için Tanımla-Ölç-Analiz Et-Kontrol cennetsel bir eşleşme, kendimi gördüğüm bir şey.

1. Paydaşlarınız için neyin "kullanılabilirlik" olduğunu tanımlayın
2. Eğer olur nasıl ölçmek tanımladığınız ne
3. Darboğazları tanımlamak için temel neden analizi
4. İyileştirmeler için görevler
5. Sistemin sürekli izlenmesi ( kontrolü )

Kullanılmama nedenleri

Herhangi bir fiziksel altyapı yönetimini kapsayacak, profesyoneller tarafından yapılması gereken operasyonel yönetimin, tamlık uğruna diğer kullanılamama nedenlerine değineceğimize karar verdik. IMO'nun kullanılabilirliği de beklenen davranış eksikliğini içermelidir, yani kullanıcıya beklenen deneyim gösterilmezse, bir şey kullanılamaz. Bu geniş tanım göz önünde bulundurulduğunda, aşağıdakiler kullanılamayabilir: - Kod hataları - Güvenlik olayları - Performans sorunları