Bir operasyon ve bakım girişimcisini düşünmek: bulut bilişim çağında otomatik operasyon ve bakım trendi
Yazar Qin Jianxiang
"Bulut Bilişim Çağında Otomatik İşletim ve Bakım" konusuna gelince, popüler bir deyişle, uygulamaların otomatik olarak devreye alınmasıdır.
İlk anahtar kelime, yüksek verimlilik ve düşük maliyet anlamına gelen otomasyondur; ikinci anahtar kelime ise uygulama dağıtımıdır. Yani fiziksel altyapının (bilgisayar odası altyapısı, enerji, yangından korunma, güvenlik, kablolama vb.) İşletilmesi ve bakımını içermez.
Bir işletmenin bir e-ticaret sitesi yapmak istediğini varsayarsak, tipik işletme ve bakım süreci şu şekildedir:
1. Donanım ekipmanı satın alın: sunucular, anahtarlar. Yönlendiriciler, yük dengeleyiciler, güvenlik duvarları olabilir, hepsinden bahsetmiyorum bile.
2. İşletim sistemini sunucuya kurun
3. Sunucudaki temel ortamı (veritabanı, Web sunucusu, arama motoru vb.) Kurun ve yapılandırın.
4. Uygulama yazılımını sunucuya kurun ve yapılandırın (Java ve PHP ile geliştirilmiş e-ticaret yazılımı)
5. Donanım ekipmanını barındırılması için bilgisayar odasına gönderin ve genel ağ erişimini açın
6. İşletmeyi işletim ve bakımda izleyin ve günlük yedekleme, genişletme / azaltma, taşıma ve yükseltme yapın
Genel bir bulut kullanıyorsanız, 1., 2. ve 5. adımlara sahip değilsiniz ve doğrudan genel bulut sanal makineleri, kapsayıcılar ve platform hizmetleri (dosya depolama, ilişkisel veritabanı, içerik dağıtımı vb.)
Uygulama ortamı ve uygulama yazılımı dağıtımı 3. ve 4. adımlara bakın.
1 İşletim sisteminin otomatik dağıtımı
İkinci adım, çıplak fiziksel makinelerin konuşlandırılmasıdır. Artık piyasadaki ana akım sunucular IPMI yönetimini destekler ve BIOS ayarları, güç açıldıktan sonra yönetim bağlantı noktasına bağlanarak tamamlanabilir ve gözetimsiz otomatik kurulum işlemlerini gerçekleştirmek için DHCP, TFTP ve KickStart ile desteklenebilir. sistemi.
Şu anda sanallaştırma, özel bulut ve genel bulut oldukça popülerdir.Özel donanımın gerekli olduğu bazı durumlar ve bazı tarihsel durumlar dışında, sanal makineler diğer birçok durumda kullanılabilir. Ana bilgisayar işletim sistemi ve uygulama yazılımı fiziksel makineye yüklenir. Bir sanal makineye kurulur, böylece çıplak fiziksel makinenin yalnızca ana işletim sistemini kurması gerekir.Gereklilikler nispeten basittir ve uygulama dağıtımı kadar karmaşık değildir. Kurulumdan sonra sık sık değiştirilmeyecek ve çalışma kararlıdır.
2 Uygulama dağıtımı
İşletim sistemi dağıtımı ile karşılaştırıldığında, uygulama dağıtımı çok daha karmaşıktır, özellikle şu alanlarda:
· Birçok sahne
Yük dengeleyici, web sunucusu, uygulama sunucusu, önbellek sunucusu, arama motoru, dağıtılmış dosya sistemi, üretim denetim merkezi, günlük merkezi, VPN sunucusu gibi ondan fazla sunucu rolüne sahip küçük bir B2C web sitesi.
· Güven karmaşıktır
Yazılım paketleri arasında bağımlılıklar ve sunucular arasında iletişim bağımlılıkları vardır
· Farklı konfigürasyonlar
Standart ini, xml, yaml, json, özellik dosyaları, iptables, sysctl, nginx, haproxy, pptpd, vs.'ye ek olarak, yüzlerce kişiye kadar kendine özgü yapılandırma dosyası formatları vardır. Belge açıklaması ve çalıştırma ve bakım komut dosyası oluşturma oldukça zordur.
3 Uygulama Dağıtım Teknolojisinin Geliştirme Geçmişi
Uygulama dağıtım teknolojisinin geliştirme sürecini gözden geçirmek için nginx'in CentOS üzerine kurulumunu örnek olarak alalım:
3.1 Manuel kurulum ve yapılandırma
Bu, en eski dağıtım yöntemidir ve bugüne kadar büyük ve küçük ekipler tarafından yaygın olarak benimsenmiştir. Dağıtım süreci genellikle ileride başvurmak üzere böyle bir belge üretir:
3.1.1 Avantajlar
3.1.1.1 Yüksek esneklik
İstediğiniz herhangi bir sürümü kurabilir, istediğiniz herhangi bir modülü etkinleştirebilirsiniz (kendi geliştirdiğiniz özel modüller dahil)
3.1.1.2 Düşük öğrenme eşiği
Belge doğal dilde yazılmıştır, okunması ve yazılması kolaydır, diğer teknik dilleri öğrenmeye gerek yoktur. Ayrıca, kurulum ve konfigürasyon için daha az araç ve komut vardır, özellikle ağdan indirme, açma, derleme ve ustalaşması kolay olan metin düzenleme.
3.1.2 Dezavantajlar
En eski dağıtım teknolojisi olarak, eksiklikleri de açıktır:
3.1.2.1 Hatalı belgeler
Doküman doğal bir dilde yazıldığından makinenin çalışması için değil, işletme ve bakım mühendislerinin okuması için yazılmıştır. Belgede yazılanlar ve makinede gerçekte yürütülenler% 100 tutarlı değildir ve insan dönüşümü gerektirir. Eksiklikler, uzun vadeli sürüm değişikliklerine ve personel değişimine aşırı derecede eğilimlidir. Tabii ki bu tür gizli tehlikeler idari yönetimden çözülebilir. Birçok büyük şirket, insanları daha az hata yapmaya teşvik etmek için süreçlere katılmayı ve test ve inceleme süreçlerini kullanmayı sever. Bununla birlikte, bu belge, makinenin çalıştırılması yerine insanların görmesi için olduğu sürece, bu belge her zaman yazım hataları, yanlış ifade ve zamansız güncelleme gibi gizli tehlikelerle karşı karşıya kalacaktır. Bu gizli tehlikeleri tamamen ortadan kaldırmak için süreçlerin kullanılması maliyetlidir.
3.1.2.2 Düşük verimlilik
Yukarıdaki 5 adımın tümü seridir, sonraki adıma geçmeden önce bir adımı tamamlamalısınız. Adım 1 ve 3 zaman alıcıdır Ağ hızı hızlı değilse veya derleme süresi çok uzunsa, işletme ve bakım mühendisi bekleyerek zaman kaybedecektir.
Öte yandan, birden fazla makinenin aynı dağıtım işlemini gerçekleştirmesi gerekiyorsa, tekrarlayan işlemler azaltılamaz.
3.2 Otomatik dağıtım: kabuk betiği
Sunucu biraz daha büyük bir ekipse, yukarıdaki manuel dağıtım büyük bir sorun haline gelir.
İnsan tarafından okunabilen belgelerin acilen makine tarafından çalıştırılan koda dönüştürülmesi gerekir. En eski ve en yaygın kullanılan otomatik dağıtım teknolojisi kabuk komut dosyasıdır. Örnek olarak bash alırsak, yukarıdaki 5 adım şuna benzer bir bash kabuğu olarak yazılmıştır (örnek kod, test edilmemiştir):
Nginx'i otomatik olarak kurmak ve yapılandırmak için bu betiği doğrudan çalıştırın.
Manuel konuşlandırma ile karşılaştırıldığında, kabuk komut dosyalarını kullanmanın yalnızca iki dezavantajı vardır: Biri, kod yazmanın belirli bir öğrenme eşiği gerektirmesidir. İkincisi, bakımın teknik zorluğu biraz daha yüksek olacaktır.
3.2.1 Avantajlar
3.2.1.1 Doğru
Kabuk betiği makine tarafından yürütüldüğünden, kabuk betiğinin kendisi doğru bir yürütülebilir belgedir, dolayısıyla yazım hataları, yanlış ifade ve zamansız güncelleme gibi bir sorun yoktur.
3.2.1.2 Yüksek verimlilik
İşletim ve bakım mühendisi, komut dosyası etkinleştirildiği sürece başka işler yapabilir.
3.2.2 Bash'in dezavantajları
Bash, neredeyse tüm Linux dağıtımlarında yerleşiktir, iyi bir çevre uyumluluğuna sahiptir ve basit ve öğrenmesi kolaydır. Ancak, işletim ve bakım programlaması için nihai seçim değildir. Spesifik olarak, iki büyük dezavantaj vardır:
3.2.2.1 Üst düzey dil özelliklerinin eksikliği
Bash, üst düzey bir programlama dili değildir.Kabuk programlama dilleri olarak da kullanılabilen Perl / Python / Ruby / PHP ile karşılaştırıldığında, işletim ve bakım dağıtımında kullanılacak birçok üst düzey dil özelliğine sahip değildir.
3.2.2.1 Takım zinciri zengin değil
OOP desteklenmediğinden, tam bir birim testi çerçevesi yoktur.
Geliştirme çerçevesi, hata analizi ve performans analizi araçları neredeyse boştur. IDE desteği mevcut olmasına rağmen (JetBrains IntelliJ'in bir bash kabuğu eklentisi vardır), çok fazla işlev yoktur.
3.3 Otomatik Dağıtım: İşletme ve Bakım DSL
Sanallaştırmanın ve genel bulutun hızla yaygınlaşması sayesinde, yüksek verimlilik ve yüksek kaliteli uygulama dağıtımı artık büyük şirketlerin özel bir gereksinimi değil, aynı zamanda küçük ve orta ölçekli işletmeler için katı bir gereksinimdir. Daha önce analiz ettiğimiz gibi, bash kabuğu büyük ölçekli kapasiteye sahip değildir Karmaşık uygulama dağıtımı, otomatik çalıştırma ve bakım programlama dili DSL (Etki Alanına Özel Dil) icat edildi, kukla, şef, yanıtlayıcı, saltstack olağanüstü temsilcilerdir.
4 Otomatikleştirilmiş işletim ve bakım teknolojisinin gelişme eğilimi için beklentiler
4.1 Dağıtım çalışmasının kodlanması
İster bash / python kabuğu kullanın, ister kukla, şef gibi DSL kullanın, kodlama sürecini tamamlayabilirsiniz. Manuel işlemleri koda dönüştürün.
Uygulama ortamlarının ve uygulamaların dağıtımını otomatikleştirmek için kod kullanmak, ofis test ortamında veya bilgisayar odası üretim ortamında ne olursa olsun, dağıtım kodunu her çalıştırdığınızda aynı sonuçları alabilmenizi sağlayabilir. Bu, tüm otomatik dağıtımın temelidir.
4.2 İşletim ve Bakım Kodunun Sürümlendirilmesi
İşletim ve bakım kodu, Java, PHP ve diğer uygulama kodları gibi SVN ve GIT kod ambarlarına dahil edilmeli ve sıkı bir geliştirme-test-çevrimiçi-geri alma süreci uygulanmalıdır.
Bu şekilde, svn / git'in olgun SCM işlevi bu tür senaryolar için kullanılabilir:
4.2.1 Yeni şube
İşletim ve bakım kodu 1.0'dan 2.0'a yükseltildi ve bir önbellek katmanı eklendi. Bir dalı 1.0'dan kopyalayabilir, 2.0 olarak adlandırabilir ve ardından 2.0 temelinde değiştirebilirsiniz.
4.2.2 Fark karşılaştırması
1.0 ve 2.0 işletim ve bakım mimarisinde nelerin değiştiğini anlamak için, her bir kod satırındaki değişiklikleri görüntülemek için svn ve git'in farkını çalıştırın.
4.2.3 Tarihsel arşiv
Sürüm 1.0, yarım yıldır istikrarlı bir şekilde çalışıyor ve sürüm 2.0'a yükseltiliyor. Şu anda, sürüm 1.0 yazma isteklerini donduruyor ve bunları arşivliyor. 2.0, bir süre çevrimiçi oldu ve istikrarın yeterli olmadığını gördü. 1.0 sürümünün dağıtım kodunu arşivden bulabilir ve 1.0 sürümüne geri dönebilirsiniz.
4.3 Yüksek doğruluk test ortamı
Birçok şirketin, birçok şirketin test ve üretim ortamlarında tutarsız işletim sistemleri, yazılım sürümleri ve yapılandırma öğeleri vardır. Bu tür standart dışı işlem ve bakımın iki ana sonucu vardır: Birincisi, hatanın test ortamında tespit edilememesi ve çevrimiçi arızalara yol açması; diğeri ise, çevrimiçi bir anormallik olduğunda test ortamının yeniden üretilememesidir.
Bir uygulamanın en az iki ortamı vardır: test ortamı ve üretim ortamı. Daha büyük şirketler de şu bölümlere ayrılacaktır: geliştirme ortamı, işlevsel test ortamı, performans test ortamı, yayın öncesi ortam ve üretim ortamı. Prensip olarak, bu kadar çok ortam için otomatik dağıtım kodunun% 90'ından fazlası aynı olmalıdır ve yalnızca birkaç yer farklıdır.
4.4 Otomatik test
Dağıtmak için kod otomasyonunu kullandıktan sonra, sunucunun hemen kullanılabilir olup olmadığı test ve doğrulama gerektirir. Otomatik test, tüm operasyon ve bakım sürecini daha verimli hale getirebilir.
Uygulama geliştirme alanında, otomatik test ve birim testi çok popüler hale geldi.İşletme ve bakım geliştirme, bazı benzer otomatik kabul testi görevlerini de yapabilir:
4.4.1 Terminal uygulama testi
Yeni dağıtılan hizmete erişen bir istemciyi simüle edin, örneğin: RESTful API'sinin beklenen sonuçları alıp almadığını doğrulama.
Avantajı, gerçek kullanıcıya en yakın olmasıdır.Bu test başarılı olursa, yazılım kurulumu, konfigürasyon değişikliği ve hizmet başlangıcının doğru olduğu anlamına gelir. Dezavantajı, test başarısız olursa, neyin yanlış gittiğini hemen bulamamanızdır. Aşağıdaki alt seviye testin yardımıyla sorunu bulun.
4.4.2 Dört katmanlı ağ testi
Hedef bağlantı noktasının normal şekilde yanıt verip vermediğini kontrol etmek için nmap gibi araçlar kullanın (güvenlik duvarının buna izin verip vermediği dahil)
4.4.3 Yerel test
· Paketin kurulu olup olmadığını tespit etmek için yum, apt kullanın
· Arka plan programının normalde desteklenip desteklenmediğini kontrol etmek için hizmet durumunu kullanın
· İşlemin çalışıp çalışmadığını tespit etmek için ps'yi kullanın
· Bir dosyanın varlığını tespit etmek için ls kullanın
· Yapılandırma önerisinin belirtilen değere ayarlanıp ayarlanmadığını kontrol etmek için grep kullanın
Otomatik test senaryolarının yeterli kapsamı ile, bir makineyi gözetimsiz olarak çıplak makineden çevrimiçi hizmete otomatikleştirmemiz mümkündür. Otomatik test yoksa, uygulama dağıtıldıktan sonra yine de çevrimiçi hizmetin gereksinimlerini karşılayıp karşılamadığını manuel olarak doğrulamak gerekir.
4.5 İş Akışı
İşletim ve bakım kodu, geliştirmeden çevrimiçine kadar bir rol oynar ve uygulama kodu olarak aşağıdaki iş akışını izlemelidir:
Bu akış şeması yalnızca en temel gereksinimi gösterir: bir üretim ortamına dağıtılmadan önce bir test ortamında doğrulanmalıdır. Kod alma, performans testi ortamı doğrulama, güvenlik açığı tarama ortamı doğrulama, yayın öncesi ortam doğrulama ve üretim ortamı toplu yayınlama adımları daha karmaşıktır.
Birçok şirketin mevcut durumu, işletme ve bakım mühendisinin iki ssh terminali ve bir komut açmasıdır.İlk olarak, etkisini görmek için yerel ortamda çalıştırın.Başarılı olursa, çevrimiçi olarak çalıştırılacaktır. Dahası, yerel doğrulama olmadan doğrudan çevrimiçi çalışabilirsiniz. Bunun başlıca nedeni, işletim ve bakım çalışmalarının tam olarak kodlanmaması ve işletim ve bakım kodunun svn ve git depolarına batırılmış olmasıdır.
4.6 Grafik arayüz ve IDE
Operasyon ve bakım alanı her zaman evrensel ve verimli bir grafik arayüz ve IDE'den yoksundu. Bunun yaklaşık iki nedeni vardır:
Birincisi, talep güçlü değil. Sonuçta, operasyon ve bakım programlamasının karmaşıklığı, uygulama programlamasından birkaç kat daha basittir. Günlük işletme ve bakım işleri kodlu değildir ve çok fazla manuel işlem vardır, bu nedenle işletim ve bakım kodu genellikle şekerlenmiş bir haw gibidir.Birbirine dizilmiş olsa da çoğunlukla bağımsız kişilerdir ve bu kadar güçlü bir kod organizasyon yapısına sahip değildirler.
İkincisi, işletme ve bakım topluluğundaki meraklıların güçlü atmosferi. Uygulama programlama alanında yalnızca Java, .NET ve diğer dillere sahip olan kullanıcılar bile IDE'leri tercih etmektedir. PHP, Python ve Perl topluluklarında vim partisi, emacs partisi, yüce metin partisi ve notepad ++ partisi başı çekiyor. Bu partiler farklı editörlere taparlar, ancak ortak bir inancı paylaşırlar: Bir IDE'ye güvenmeden kod yazmak, iyi bir programcı için temel bir niteliktir.
Bu soruya gelince, bence yüksek teknoloji, programlama yaşam kalitesini artırabilir, neden kullanmayalım? Kukla ve şef böylesine iyi bir işletim ve bakım programlama deneyimi elde etmiş olsalar bile, işletim ve bakım endüstrisinde Eclipse ve AdobeFlash gibi bir grup grafik arayüz ve IDE'nin ortaya çıkmasını dört gözle bekliyorum. Bırakın IDE'nin verimliliği ve kullanım kolaylığı ile komut satırı operasyon ve bakım operasyonları birbirini tamamlasın.
4.7 İşletme ve bakım kodu böl ve yönet
İşletme ve bakım endüstrisinde atalardan kalma bir slogan vardır: savurma yok, arıza yok.
Ancak, iş ihtiyaçlarına hızlı bir şekilde yanıt vermek ve kaynak kullanımını iyileştirmek için, işletim ve bakımın sık sık değişmesi gerekir. "Ne kadar çok atılırsa, o kadar çok başarısızlık" laneti kırmanın bir yolu var mı? Evet, böl ve fethet.
Böl ve fethet, yüksek riskli ve düşük riskli, yüksek önemde ve düşük riskli, basit ve karmaşık, sık değişim ve seyrek ayrımı ayırmaktır. Uygulama programlaması alanında, aktif olarak keşfettiğimiz ve uyguladığımız çeşitli mimariler, çerçeveler ve kalıpların hepsi son analizde iki şey yapıyor: karmaşıklığı kapsüllemek ve değişiklikleri izole etmek.
Uygulama sunucularının ve veritabanı sunucularının ayrılması, işlem veritabanları ile kullanıcı veritabanlarının ayrılması; üretim ve test ortamlarının izolasyonu gibi işletim ve bakım mimarisi katmanının bölünmesi ve ele geçirilmesi endüstride zaten çok yaygındır.
4.7.1 Ayrı yapılandırma öğeleri ve mantık kodları
Aslında, endüstri bunu zaten yaptı, kuklanın hiera'sı ve tuz yığını bu amaçla kullanılıyor.
Bazı işletim ve bakım değişiklikleri, yalnızca yapılandırma öğelerinin değerini değiştirebilir, ancak işletme ve bakım kodundaki iş mantığını ve süreç kontrolünü değiştiremez. Yalnızca konfigürasyon dosyası değiştirilirse, işlem ve bakım betiği değişmez. Yayınlanma riski çok daha düşüktür, en azından gramer hatalarına neden olmaz.
4.7.2 Değişecek bağımsız yapılandırma öğeleri
Uygulama geliştirme alanındaki şablon motoru gibi, konfigürasyon dosyası bir şablon olarak yazılır ve şablon değişkenler içerir.İşletme ve bakım aracı veya işletim ve bakım platformu şablon içeriğini ayrıştırır ve değişkenleri gerçek değerlerle değiştirir.
4.7.3 Hizmet keşfi
Değiştirilen konfigürasyon öğeleri bağımsız ve dinamik olarak korunur ve hizmet keşfi de gerçekleştirilebilir. Örnek olarak haproxy + etcd + confd alalım:
confd, Java'da Velocity ve Python'da Jinja'ya benzer bir şablon motorudur. Fark şudur: confd ayrıca etcd'yi otomatik olarak sorgulama yeteneğine de sahiptir. Haproxy yapılandırma dosyalarını ayrıştırmak ve yönetmek için confd kullanın, alıntı aşağıdaki gibidir:
Yerel haproxy yapılandırma dosyasından farklı olarak, son üç satır confd şablonudur.
etcd, memcached'e benzer bir KV deposudur. Aradaki fark, etcd'nin doğası gereği, yüksek kullanılabilirlik ve yük dengeleme genleri ve erişilmesi kolay HTTPRESTful API ile dağıtılmasıdır. Arka uç sunucularının listesini saklamak için etcd kullanın.
Arka uçta bir nginx hizmeti başladığında, bu makinenin IP adresini etcd'deki listeye yazmak için etcd'nin api'sini çağırın. Confd etcd yoklama yaparken bu yeni eklenen makineyi bulduğunda, onu haproxy'nin arka uç sunucusuna ekleyecektir.
Bu şekilde, yük dengeleme kümesinin otomatik olarak genişletilmesi gerçekleşir.Aynı durum çevrimdışı nginx makinesi için de geçerlidir.İlk olarak etcd api'yi bir makineyi silmek için ayarlayın.Bir dakika sonra, bu nginx üzerinde çevrimdışına almadan önce trafik algılanamaz.
Genişleme işlemi sırasında, haproksinin konfigürasyonu değiştirilmedi ve haproksi konuşlandırılmadı. Sadece etcd'nin RESTful API'sini çağıran bu risk, haproxy yapılandırma dosyasını değiştirip çevrimiçi olarak dağıtmaktan çok daha küçüktür.
4.8 Altyapı API'sini Entegre Etme
Tüm genel bulut satıcıları, yabancı aws, azure, gce ve yerel Alibaba Cloud, Ucloud ve Qingyun dahil olmak üzere HTTPOpenAPI sağlar.
Pazar payındaki en iyi sanallaştırma yazılımı satıcıları ayrıca VMware, Hyper-V, XenServer ve OpenStack dahil olmak üzere HTTPOpenAPI'ye sahiptir.
Bu nedenle, sanal makine oluşturma, başlatma, işletim sistemi kurulumu, ağ oluşturma, komut yürütme, kapatma ve yok etmenin tüm yaşam döngüsünün otomasyonunu gerçekleştirmek için altyapı sağlayıcılarının API'sini entegre etmek teknik olarak mümkündür.
Uygulama dağıtım betiklerinden farklı olarak, bulut satıcılarının API'lerini çağırmak DSL betikleri ile yapılamaz ve bash kabuğunu kullanmak çok sakıncalıdır. PHP ve Java gibi uygulama programlama dillerinde bir uygulama yazarak yapılmalıdır.
Bu noktada, sanal makine ve işletim sistemi başlatma, uygulama ortamı dağıtımı ve uygulama yazılımı dağıtımı otomatikleştirildi ve sıfırdan hizmete çevrimiçi bir makine oluşturulabilir.
4.9 Satıcılar arası ve şehirler arası yük devretme
Dağıtım işi kodlama ve altyapı API entegrasyonunun uygulanmasından sonra, satıcılar ve şehirler arasında serbestçe geçiş yapabilirsiniz: aynı verilerin iki kopyasını farklı bilgisayar odalarında saklayın ve her dakika senkronize edin. Altyapıda büyük bir arıza meydana geldiğinde ve kısa sürede kurtarılması zor olduğunda, uygulamanın tamamı başka bir bilgisayar odasına veri ile hızlı bir şekilde dağıtılabilir.
4.10 Elastik ölçeklendirme
İnsanlar tarafından ziyaret edilen hemen hemen her web sitesinde, sunucu kaynağı kullanımında belirgin zirveler ve inişler vardır:
· Yılda bir kez bazı ani artışlar görülür, tipik bir örnek Alinin Double Elevenidir. Her 11 Kasım'da e-ticaret çılgınlığı yaşanıyor. Taobao ekolojik zincirindeki büyük satıcıların ve SaaS hizmet sağlayıcılarının faturalama sistemlerinin sistem baskısı (hızlı siparişlerin çevrimiçi olarak yazdırılması, SMS kupon kodlarının gönderilmesi ve lojistik takibi gibi) da 1-2 büyüklükte siparişle arttı. Genişletmeye yatırım yaptıkları donanım ekipmanı ancak bu gün tam olarak kullanılabilir ve normal kullanım oranı son derece düşüktür.
· Vipshop ve Ju'nun 10 puanlık artışları gibi bazı ani artışlar günde bir veya birkaç kez meydana gelir. Temel olarak, her e-ticaret şirketinin bir günde birden fazla ani artış ve enstantane dalgası vardır.
· Daha yaygın olanı, gün içinde zirveler ve sabahın erken saatlerinden sabahın erken saatlerine kadar alçak olanlardır.
Otomatik çalıştırma ve bakım (sanal makinelerin otomatik satın alınması ve tahsisi, uygulama ortamlarının otomatik dağıtımı, uygulama yazılımının otomatik dağıtımı ve otomatik test dahil), bilgi işlem kaynaklarının isteğe bağlı olarak planlanmasını mümkün kılar. Gerçek zamanlı elastik ölçeklendirme, kapasite artırma ve daralmasının her gün, hatta her dakika yapıldığı anlamına gelir ve bu, otomatikleştirilmiş işletim ve bakım ile başarılmalıdır.
4.10.1 Genel bulutta isteğe bağlı tedarik
Yaygın genel bulut faturalama ayrıntı düzeyi saat kadar iyi (aws, Alibaba Cloud, Ucloud) ve bazıları dakikada (gök mavisi, gce) ve hatta saniyede (Qingyun) başardı.
Nispeten düşük frekans ve planlı ani artışlar için, genişleme ve büzülme planlarını önceden hazırlamak için manuel müdahale gerekir.Örnek olarak Double Eleven'ı alın, bir grup makine satın almayı manuel olarak ayarlayın (paket değil Yıllık abonelik), bu makineler 15 Kasım'da piyasaya sürüldüğünde, üreticiler faturalandırmayı durduracak.
Yüksek frekanslı ani artışlar için, işletim ve bakım platformu, sistem kaynaklarının her 5 saniyede bir örneklenmesi gibi akıllıca planlar, makineleri otomatik olarak satın alır ve belirtilen genişleme eşiğine ulaşıldığında hizmetleri otomatik olarak dağıtır, test eder ve başlatır ve belirtilen kurtarma eşiğinin altındaysa otomatik olarak indirir Hat sunucusu, üreticiye faturalandırmayı durdurmasını bildirin. Bu, hizmetleri çok kısa bir çevrimiçi süreye, özellikle de durum bilgisi olmayan ve kullanıcı verisi olmayan uygulama sunucularına dağıtmak için uygundur. Daha uzun bir ısınma süresine ihtiyacınız varsa (veritabanları, önbellekler, arama motorları gibi), kapasiteyi önceden genişletmeniz gerekir, bu da geçmiş performans eğrilerine dayalı akıllı tahmin gerektirir.
Talep üzerine satın alma, genel bulut satıcıları için de olumludur:
· Makro açıdan, kullandığınız kadar satın alın, israfı ortadan kaldırın ve küresel genel bulut kaynak havuzunda kaynak kullanımını artırın Kaynak kullanımını iyileştiren her şey olumludur.
· Ekonomik açıdan bakıldığında, genel bulut tarafından saatlik olarak satılan makinelerin birim fiyatı yıllık aboneliğe göre daha pahalıdır.İki satış yöntemi makineleri% 100 satabiliyorsa, saatlik faturalamanın toplam geliri daha yüksek olacaktır.
· Şu anda, bazı genel bulut satıcıları bilgisayar odalarındaki bazı fiziksel kaynakları sattı. Gerçek zamanlı hizmetler (e-ticaret, ödeme, haber ve sosyal ağ gibi) sağlayan müşteriler talep üzerine satın alırlarsa, kaynakları boş zamanlarında düşük gerçek zamanlı gereksinimleri olan müşterilere (çevrimdışı büyük veri işleme, animasyon oluşturma gibi) bırakmak mümkündür. kullanın.
4.10.2 Özel bulutun işletmeler arası dağıtımı
Büyük miktarda donanıma yatırım yapan şirketler, gün boyunca tüketicilere hizmet sağlamak için makinelerin çoğunu kullanmak ve geceleri tüketici isteklerini taşıyan makinelerin ölçeğini azaltmak gibi farklı dahili işletmeler arasında zamanlama yapabilir ve serbest bırakılan bilgi işlem kaynakları genişletmek için kullanılabilir. veri işleme.
5 Otomatik operasyon ve bakım platformu
2012 yılında, son derece zor bir ortamda kendi kendime işletilen bir B2C yaptım. 12306'nın sık sık başarısızlıklarını gördüm. Takımın onlardan daha iyisini yapmasına öncülük edebileceğimi hissettim, bu yüzden veritabanı modellemesi yapmaya çalıştım. "Kod Çiftçisi Olarak 12306 İçin İki Cümle Söyle" adlı makaleyi yazdım, bu makale çok popüler. Çeşitli Weibo, WeChat ve forumlar yüzbinlerce yeniden paylaşım biriktirmiş olabilir ve ayrıca "Teknoloji Günlüğü" nde de yayınlandı "Southern Metropolis Daily", "Beijing News" ve 10'dan fazla yazılı basın dışında, 12306'nın teknik direktörü (Çin Demiryolu Bilimleri Akademisi Bilgisayar Teknolojisi Enstitüsü Müdür Yardımcısı) bile People's Daily Online'da röportaj yaptı. Daha sonra Weibo'daki birçok kişi, "Bu kardeş canlı bir şekilde açıkladı: Yapabilirsiniz, yapamazsınız, zorlamayın."
2015 yılında, işletme ve bakım için çok fazla olasılığım vardı ve teknik olarak çok caziptim. Tekrar "sen yap, sen yapabilirsin" uygulamasına karar verdim. Bu yüzden "İşletme ve Bakım Mutfağı" gibi otomatik bir işletme ve bakım platformu oluşturmak için milyonlarca dolar yatırım yaptım. Burada detaylandırmayacağım.
Yazar tanıtımı: Qin Jianxiang
Dünyanın en gelişmiş otomatik operasyon ve bakım platformunun [O&M Kitchen] kurucusu. Kendini 16 yıldır yazılım geliştirme ve açık kaynak işine adamış. Yahoo'nun kıdemli teknik uzmanı, Alibaba'nın kıdemli teknik uzmanı ve borsada işlem gören Xiangjiang Holdings e-ticaret şirketinin genel müdürü olarak görev yapmıştır. Segmentfault topluluğunda prestijli bir yanıtlama uzmanı ve konuk konuşmacı. Yüz milyonlarca görüşle "Kod çiftçisi olarak 12306 için birkaç kelime adalet söyle" yazarı sıcak yazarı.
Bulut Teknolojisi Topluluğuna Giriş:
Bulut Teknolojisi Topluluğu 2014 yılında kurulmuştur. Çin'deki en büyük bulut teknolojisi değişim platformudur. Bulut bilişim / sanallaştırma projelerinin uygulanmasında bilgi, deneyim ve teknolojiyi paylaşır ve kuru mallarda ısrar eder.
