Ali'nin çifte onbir terfisi, teknik hazırlıklar sadece bu iki şeyi mi yaptı?
Yazar Jiang Jiangwei
Editör Liu Jiayang
Double Eleven için teknik hazırlıklar iki şey yapıyor: Birincisi, kapasitenin kesinliği ve kaynakların kesinliği de dahil olmak üzere sistemin mümkün olduğunca gerçeğe yakın hazırlanması; ikincisi, insan ve birim kaynaklarının verimliliği de dahil olmak üzere tüm sürecin verimliliğidir. Bu iki şey bu büyük promosyonu destekleyebilir mi?
Bu makale Jiang Jiangwei'nin ArchSummit 2016 Pekin İstasyonunda yaptığı konuşmadan derlenmiştir.
"Double Eleven" anahtar kelimesi arka planda yanıtlanır ve bu makalenin tam PPT'si indirilir.
Double Eleven'i Deneyimleyin
2009'dan 2016'ya kadar 8. Double Eleven teknik hazırlık çalışmasına katıldı. 2009'daki çifte onbir çok etkileyici değildi. Asıl neden, Taobao'nun o zamanlar zaten çok büyük olması ve günlük işlem hacminin yüz milyonlarca olması, Taobao alışveriş merkezinin iki kat on bir işlem hacminin sadece yaklaşık 50 milyon olmasıydı. , Hacim yüz milyonlara kıyasla hala çok küçük, bu yüzden daha başlamadan geçmiş gibi hissediyor.
Önümüzdeki birkaç yıl içinde, dikkatli hazırlıklar yapmak, izlemek ve alarm vermek, kapasiteyi planlamak, tüm bağımlılığı yönetmek vb. Ve çeşitli metodolojileri organize etmek her yıl birkaç ay sürecektir. . Bu tabii ki bir süreç, çok anlamlı birçok şey de bu süreçte ortaya çıktı. Bugün birisi bana double onbiri nasıl yapacağımı ve nasıl büyük promosyon aktiviteleri yapacağımı sordu ona çok basit bir yöntem anlatacağım, kapasite planlamasında iyi bir iş yapmak ve mevcut sınırlama ve düşürme konusunda iyi bir iş çıkarmak.
2008'de Taobao'ya katıldım ve Taobao Mall'un araştırma ve geliştirmesine doğrudan katıldım. Taobao Alışveriş Merkezi daha sonra Tmall olarak adlandırıldı. O zamanlar Taobao Alışveriş Merkezi'nin tüm teknik sistemi Taobao'dan tamamen farklıydı ve tamamen bağımsız bir sistemdi. Üyeleri, ürünleri, pazarlaması, önerileri, noktaları ve forumlarının Taobao ile hiçbir ilgisi yoktur. İki sistem tamamen bağımsızdır ve önemli olan tek şey tüm üyenin verilerinin paylaşılmasıdır.
İki sistemin verilerini ve işlerini birbirine bağlamak için 2008 yılının sonunda başlatılan "Renkli Taş Projesi" nin temel noktası, iş geliştirmenin çok esnek hale gelmesidir. Bu projenin tamamlanması, Taobao Alışveriş Merkezi'nin geliştirilmesinde büyük bir sıçrama getirdi ve daha sonra Taobao Alışveriş Merkezi de markasını Tmall'a yükseltti.
Ayrıca mimarinin, işin ve teknolojinin ölçeklenebilirliğini daha şık bir şekilde elde etmek olan bu projede büyük bir önem var. Tüm hizmetin tüm hizmetini gerçekleştirdik ve üyelik sistemi, emtia merkezi, işlem merkezi, pazarlama, mağaza, öneri vb. Dahil olmak üzere e-ticaret ile ilgili tüm kamusal unsurları çıkardık. Bu sisteme dayanarak, Juhuasuan, Electric City ve Air Travel gibi daha sonraki işletmeleri kurmak çok hızlı. Orijinal yapıyı kırıp tüm kamu hizmetini çıkardıktan sonra, üst düzey işletme çok hızlı yürüdü ve bu da iş ölçeklenebilirliği sorununu çözdü.
Ara yazılımın ilk büyük ölçekli kullanımı bu projede oldu. 3 kılıç ustası, HSF, Notify ve TDDL büyük bir yenilik elde etti ve geniş ölçekte kullanıldı. Dağıtımla ilgili sorun, bir sistemin birçok sisteme bölünmesidir ve bu da ölçeklenebilirlik sorunları içerir. Bu proje aynı zamanda işin geliştirilmesinden teknolojinin ölçeklenebilirliğine kadar teknolojik ilerlemeyi de beraberinde getirdi, çok güzel hedeflere ulaşıldı.
Neden kapasite planlaması yapılır?
2012 yılında, bir ara katman yazılımı ürün grubu ve yüksek kullanılabilirlikli mimari ekibi getirmeye başladım. Öyleyse neden kapasite planlaması yapılıyor? Double Eleven, Alibaba'da çok büyük bir teknolojik yeniliği teşvik ediyor ve kapasite planlaması da Double Eleven sürecinde çok iyi bir yenilik.
Bu yıl Double Eleven yaparken, patronum bana bu yıl ne gibi risklerim olduğunu sordu. Ona çok fazla riskin olması gerektiğini söyledim ama sonuçta sistemde bir sorun varsa işlem ile ilgili sistemde olması gerekiyor. Alibaba'nın sistemi iki bölüme ayrılmıştır: Bir sistem, işlemleri teşvik eden ve çeşitli pazarlama yapan öneriler, alışveriş rehberleri, arama, kanallar vb. İşlemleri teşvik eder; diğer sistem işlemler, kırmızı zarflar, indirimler vb. sistemi.
Nedeni çok basit.Alışveriş rehberi sistemi size bir karar vermeniz için yeterli zaman verir. Trafikteki artış anlık bir artış değil, yavaşça yükselen bir eğridir.Size bir karar vermeniz için 30 dakika bırakır. fakat Alım satım sistemi yargılama için herhangi bir zaman ayırmaz. Akış başladığında, karar verme için tepki süresi veya zamanı yoktur.Sadece sistem tüm eylemleri otomatik olarak yürütür. Bu süreçte kapasite planlaması çok önemli hale geliyor.
İlk yıllarda, işimizin doğal büyümesi çok hızlıydı. Herkesin alışveriş yaparken açtığı ürün ayrıntıları sayfasından çok etkilendim. Bir süredir bu sayfadaki yük nispeten yüksekti. Şirket, optimize etmek ve optimize etmek için sanal makine ayarı ve performans optimizasyonu konusunda iyi olan bazı kişileri çağırdı. Sistem birkaç gün sonra nihayet kapattı. Neyse ki bazı genişletme hazırlıkları da yapılıyor.Genişletme tamamlandıktan sonra sistem yeniden başlatıldıktan sonra geri yüklenir. Bu neyi gösterir? İlk yıllarda Taobao aynıydı.Kapasite hazırlama ve tahmin kavramı yoktu, tüm sistemin gerektirdiği kapasiteyi ne kadar destekleyebileceğini bilmiyorum.
Yeni işletmeler çevrimiçi olmaya devam ediyor ve ticari operasyonlar ve tanıtım faaliyetleri de çok sık oluyor. Bir zamanlar bir promosyonun çok büyük olduğunu hatırlıyorum. Üyelik sistemi çok önemlidir, çünkü tüm işletmeler temelde alıcı verileri ve satıcı verileri dahil olmak üzere üye merkezindeki kullanıcı verilerine erişir. O zamanlar fiziksel bir makinenin tek makineli önbellek kapasitesi saniyede yaklaşık 80.000 istekti ve bugün bundan çok daha fazlası. Ancak çok büyük bir sayı olan en yoğun dönemden önce 60.000'e ulaştı.
Ziyaret eden üyelerin tüm sistemlerini çıkaracağız ve hangilerinin işlemle ilgili olmadığını göreceğiz ve yarısını durdurma veya durdurma ihtiyacını bildireceğiz. Örneğin, işletmelerle, açıklıkla ilgili olanlarla ve topluluklarla ilgili olanlarla ilgili sistemleri kapatın. Bu süreçte çeşitli sorunlar yaşandı Özetle, kapasiteyi nasıl yapacağımızı bilmiyoruz ya da kapasite yapmak için bir kavram yok. Dolayısıyla, kapasite planlamasının en önemli kısmı şudur: Ne zaman ve ne tür bir sistem kaç sunucuya ihtiyaç duyar? Belirleyici ve nicel rakamlar vermemiz gerekiyor.
Kapasite planlamasının üç aşaması
Kapasite planlama sürecinin tamamı, toplam üç aşama olmak üzere yaklaşık yedi veya sekiz yıl sürdü.
İlk aşama çok erkendir, bizim değerlendirme yöntemimiz "kafayı tokatlamaktır" (deneysel yargı). Yük durumuna göre sistemin tepki süresi ve çeşitli performanslar bir numara alır. O sırada bir yöneticiye sunucunun yeterli olup olmadığına nasıl karar vereceğimi ve ne kadar trafik desteklenmesi gerektiğini sordum. Bana ampirik bir değer söyledi, her sunucu 1 milyon PV'yi destekliyor.
O sırada, bir günün akış eğrisinde dokuzdan ona, öğlen iki ila üçten beşe ve akşam sekizden ona kadar üç tepe vardı. Neden 1 milyon? Bu aynı zamanda ampirik bir değerdir ve elbette bilimsel bir temeli vardır. Sunucuların yarısının durduktan sonra çevrimiçi trafiği destekleyebileceğini ve aynı zamanda hepsinin de zirveyi destekleyebileceğini umuyoruz. Aslında, tek bir makine o zamanki ampirik değer olan 3,2 milyon PV'yi destekleyebilir.
Tabii ki, bu ampirik değer o zamanlar işe yaradı ve nedeni çok basitti, çünkü o zamanki sistem mimarisi basitti. Taobao'nun tüm mantığının ve modüllerinin tek bir sistemde yoğunlaştığı anlaşılabilir, bu nedenle her modülün sıcak noktaları arasında, bir sunucunun dahili CPU'sunu önceden kullanarak veya programlayarak OS düzeyinde çözülebilecek bir zaman farkı vardır.
İkinci aşama, çevrimiçi basınç testi aşamasıdır. Çünkü dağıtılırsa sorunlar çıkacaktır. Örneğin, üyenin çağrısı ve işlemin çağrısı orijinal olarak aynı sunucu üzerindeydi, ancak ayrılmadan sonra trafik oranı net değil. Bu nedenle, bazı stres testi mekanizmaları devreye sokulmalıdır.Efor testi yapmak için bazı ticari stres testi araçları sunuyoruz.
O zaman iki amaç vardı: Birincisi, sistem çevrimiçi olmadan önce yanıt süresinin ve yükün çevrimiçi gereksinimleri karşılayıp karşılamadığını belirlemek için bir basınç testi yapmaktı; ikinci amaç, çevrimiçi basıncı çevrimdışı basınç testine göre doğru şekilde değerlendirmekti. Yaklaşık olarak kaç sunucuya ihtiyaç vardır. İkinci amaç daha zor, performans stres testi ekibinin de çevrimdışı ve çevrimiçi kapasite ilişkisi denen bir proje yaptığını hatırlıyorum. Çevrimiçi ortam ve veriler çevrimdışı olandan tamamen farklı olduğundan, bulunacak bir model yoktur ve çevrimdışı basınç testi göstergeleri aracılığıyla çevrimiçi olarak geri bildirimde bulunmanın bir yolu yoktur.
Şu anda ne yapmalı? Birincisi, doğrudan çevrimiçi basınç ölçümüdür. O zaman bu kararı verdiğimizi görmek çılgıncaydı, çünkü Alibaba da dahil hiçbir şirket doğrudan çevrimiçi stres testi yapmadı. Önceki güne ait günlükleri çıkarmak ve çevrimiçi olarak oynatmak için bir araç yazdık. Örneğin, yanıt süresi ve yüke göre önceden ayarlanmış bir değer ayarlayın ve önceden ayarlanmış değer tetikleyicisine ulaştığında, QPS değerine bağlıdır.
İkinci olarak, bir saptırma yaptık. Alinin tüm mimarisi nispeten tekdüze olduğundan, tümü tam bir ara yazılım setine dayalıdır, bu nedenle yumuşak yük yoluyla, örneğin bir sunucuya giden çevrimiçi trafiği ağırlığa göre ayarlamak gibi oran ayarlayarak ve uygulama ve hizmete göre ayarlama yaparak Terminal sürekli olarak bir sunucuya uyum sağlar ve ağırlığını arttırır Bu sırada yükü ve QPS'si de artacaktır.Bu işlemi kaydedin.
Burada zaten iki senaryo var, biri simülasyon, tekrar oynatma günlükleri. İkinci tür, her gün otomatik olarak veri oluşturmak için otomatikleştirilen gerçek trafiktir. Bu yapıldıktan sonra, çevrimdışı performans stres testi sürecinin yerini tek boyutta alır. Çünkü her sistemin her gün kendi performans durumunu elde etmesine izin verir. Proje yayınlama performansının veya günlük talep açıklamasının herhangi bir etkisi olup olmadığı doğrudan görülebilir. Daha sonra performans testi ekibi dağıldı.
Burada bir sorun var, sahneye bağlı değil. Bağlamsallaştırma çok önemlidir.Örneğin, bir parça kıyafet satın aldığımda, alışılagelmiş bir şey satın alma işlemi, alışveriş arama kutusunda arama veya aramadan alışveriş sepetine, sipariş vermeye kadar kategori navigasyonunda arama olabilir. süreç. Çift on bir itme, ürünün kesinliğiyle ilgilidir. Birçok kanal sayfası, satıcının daha iyi promosyon ürünlerini bir kanal sayfası olarak doğrudan çıkarır. Double Twelve sırasında mağazalar zorlandı ve KPI'lar farklıydı ve ittikleri şeyler de farklıydı.
Double Eleven ürünleri ile ilgili sunucu sisteminin trafiği daha yüksek olacak ve daha fazla sunucu gerektirecektir. Double Twelve ile ilgili sistem sunucularına ve mağazalara daha fazla ihtiyaç duyulacaktır. Bu, normal trafik performansından farklıdır. Senaryoya dayalı trafiği hesaplamak için normal kapasiteyi kullanmak da yanlıştır.
Ayrıca çok önemli bir şey yaptık: tam bağlantı basınç testi. 2013'te başardığımız şey bu. Bundan daha önce hiç bahsetmedik, bu bir nükleer silah ve ayırıcı bir çizgisi var. 2009 yılı en akıcı Double Eleven'dı çünkü fazla trafik yoktu, görmezden geldik. 2010, 2011, 2012'de aslında her yıl Double Eleven'da her zaman bazı küçük sorunlar oluyordu ama ne yapacağımı bilmiyordum.
2013 yılında, tam bağlantılı bir stres testi yaptıktan sonra, önemli bir değişiklik meydana geldi. 2013'teki performans çok iyiydi ve 2014 de çok iyiydi Bu bir nükleer silahın doğuşu. Pazarlama ve tanıtım için zirveye sahiptir.Zaman içinde bu noktadan önce zirve çok düşüktür ve bu noktadan sonra zirve aniden yükselir. Bu, bu durumla başa çıkmanın çok etkili bir yoludur.
Çevrimdışından çevrimiçine: Bağımsız basınç testinin kapasite değerlendirmesi
Çevrimiçi stres testi ve senaryo tabanlı tam bağlantılı stres testini analiz etmeye odaklanın.
Çevrimiçi stres testi, esas olarak Taobao'nun çeşitlendirilmiş iş formlarından kaynaklanmaktadır. Dağıtımdan sonra çeşitli işletmeler ortaya çıktı ve üretkenliğin özgürleşmesine yardımcı oldu. Geçmişte yüzden fazla kişi çok kötü bir sistem üzerinde çalışıyordu, ancak dağıtılmış dönüşümden sonra, tüm iş hizmeti soyutlandıktan sonra verimlilik serbest bırakıldı.
İkincisi, her işletmenin makine ölçeği çok büyük ve her bir işletme için uygulama sayısı çok büyük. Aslında, bir sistemin kapasitesine göre sürekli hesaplayarak ve sonunda Alibaba'nın küme kapasitesini hesaplayarak bir katmanlama yaptık. Öncelikle bir uygulama sistemi yapalım.Dağıtım sayesinde akış yük üzerinden içe aktarılır ve yük en yüksek değere ulaştıktan sonra hesaplanır. Bu APP'nin tüm kümesinin ne kadarını, örneğin 100 sunucunun destekleyebileceğini hesaplayın. Tabi ki veri tabanının hesaplanması çok zordur ve veri tabanı önceden planlanmıştır Genel olarak, veri tabanı veri tabanına bölündükten sonra, miktar birkaç yıl için rezerve edilir ki bu daha zordur.
Tüm kümenin hacmini ve ölçeğini bu şekilde yapmak sorunlu, neden? Çünkü sistem bölünmeye başladığında temizlenemez ve gittikçe daha fazlası bölünür. Sistem bağımlılıkları araçlarla çözülebilse de, bu senaryo altında hangi sistemlerin hangi sebeplerden dolayı kümenin tamamında küçük bir soruna neden olacağını görme tecrübesi yaşamadık. Küçük bir sorun oluştuğunda, tüm küme çöker ve bu sorun önlenemez.
2013 öncesinde bu sisteme dayanıyordu, düşünmek mantıklı ... Her bir sistemin kapasitesini hesaplamak, kümeler halinde hesaplamak ve ardından tüm büyük kümeyi hesaplamak mümkün ama çok da iyi bir çözüm değil. Program. Bunun en iyi yanı, otomatik olarak çalıştırılabilmesi, sistem kapasitesinin her gün tükenebilmesi ve sistemin bozulmamasını ve günlük performans ve göstergelerin bozulmamasını sağlayabilmesidir.
Stres testi platformunun mimarisi
2013 yılında Double Eleven bu sistem üzerinden yapıldı. Çeşitli şekillerde, simülasyon ve akış çoğaltma yoluyla, iletme saptırma ve yük dengeleme akışına ulaşmak için. Tüm sistem otomatikleştirilir ve her hafta çalışır ve performansın düşüp düşmediğine ilişkin geri bildirim vermek için sürümden önceki ve sonraki gün veriler tükendikten sonra bir rapor oluşturulur. Hesaplanan değere göre toplam aktivite akışını yaklaşık olarak hazırlayın. İşte bazı veriler: Her ay beş günlük otomatik stres testi vardır Bu durumda, otomatik olduğu için manuel olarak performans stres testi yapmak imkansızdır.
Biraz önce bazı eksikliklerden de bahsetmiştim, bir çizgi ve bir yüzeye uzanan noktadan yüzeye kapasite değerlendirmesine dayanıyor. En büyük sorun, hiç kimsenin tüm mimarinin neye benzediğini anlayamaması ... Tüm sistemin bağımlılığında bir eksiklik olursa, tüm sistem çökecektir.
Neden senaryo bazlı kapasite değerlendirmeleri yapılıyor?
Senaryo temelli stres testine ihtiyaç duymamızın bir başka nedeni de, arka plandaki trafiğin çoğunun yönlendirme olması, yani bunun gerçek trafikle yapıldığı anlamına geliyor. Sözde gerçek trafik, faaliyet yapmakla karşılaştırıldığında aslında çok düşük. Trafik çok düşük ve arka planda trafik yok Tüm bilgisayar odasındaki ağ ekipmanı ve anahtarlar dolu olamaz, bu nedenle bu sorunlar ortaya çıkamaz. İkinci sorun sahnenin kesinliğidir Herkesin alışveriş süreci farklıdır Farklı süreçlerde tüm sistemin kaynakları belirlenmeli ve en büyük miktarı desteklemek için en az sunucu kullanılmalıdır.
Buna dayanarak, o zamanlar bir takım tartışmalar vardı, sahne temelli stres testi nasıl yapılır? İlk yöntem, tüm Taobao ağını küçük bir ortama izole etmek ve 100'den fazla sistemi dağıtmaktır. Tüm akış içeri getirilir ve küme doludur ve akış doludur. Bağımlılık sorununu daha iyi çözer Bağımlılıkla ilgili bir sorun varsa bu ortamda doğrulanabilir. Ancak çevre sorununu çözmenin bir yolu yoktu. O yıl şirketimizin bir işi vardı, çünkü bu şemayı benimsemediğimiz ve küçük ortam trafik doğrulamasına benzer bir plan benimsediğimiz için giriş anahtarının tüm trafiğinin artmasına neden oldu.
Senaryoya dayalı kapasite değerlendirmesi
Bu nedenle, senaryoya dayalı tam bağlantılı bir stres testi olan daha basit ve daha güvenilir bir değerlendirme aracına ihtiyaç vardır. 2013'ten sonra hepimiz bu sisteme dayandık, önce veri oluşturmamız gerekiyor, trafiğin gerçek duruma daha yakın oluşturulabileceğini umuyoruz. Daha önce de belirtildiği gibi, zirveye yakın karar vermenin bir yolu yok, yapılabilecek tek şey nedir? Önceden sıfır pik simüle etmek mümkün mü? Tüm akışı simüle etmeyi umuyoruz, bu ideal bir mimari ama aynı zamanda birçok zorluğu da var.
Verileri olabildiğince doğru hale getirmeli ve çeşitli senaryoları simüle etmeliyiz , Kuponların nasıl kullanılacağı, alışveriş sepetindeki ürünlerin oranı nedir, bir siparişte kaç ürün olduğu ve Alipay'e kaç ürün gönderildiği vb. Veri miktarı her yıl daha da artıyor.Örneğin 2015'te veri miktarı 1T'ye yaklaşıyor. 1T verileri merkeze ve ardından merkez aracılığıyla stres testi düğümüne iletiliyor. Bu stres testi kümesidir. Bu bir stres testi aracıdır, ancak aynı zamanda kümelenmiş bir stres testi aracıdır. Double 11 ile tam olarak aynı ölçekte büyük miktarda trafik ve veri oluşturabilir.
Kümeyi CDN düğümüne dağıtmak büyük bir trafik oluşturur. İşte bazı teknik noktalar: Stres testi aracının HTTPS protokolü gibi birden çok protokolü desteklemesi ve performansın iyileştirilmesi gerekiyor. Akışı kontrol etmek ve akışı farklı iş senaryolarına göre ayarlamak da gereklidir. Üçüncü nokta ise akışın renklendirilmesi gerektiğidir.Sağdaki resim gerçek akışı yansıtır.Bunların hepsi çevrimiçidir.Bu ortamı çevrimdışı simüle etmenin bir yolu yoktur, aksi takdirde hattaki normal akışı etkileyecektir.Bu nedenle normal akışı ölçülen basınçla karşılaştırmak gerekir. Tam bir ayrım yapın. Dördüncü nokta, trafiğin izolasyonudur. Trafik izolasyonundan önce sıfırdan sonra sistemlerinde herhangi bir sorun olup olmadığına ancak trafik çok düşük olduğunda bakabiliriz ki bu çok zordur. İkinci yılda herkesin mutluluk endeksini iyileştirme umuduyla bir hedef yükseltildi ve bu nedenle trafik izolasyonunu başlattık.
Trafik izolasyonu, hızlı bir şekilde yük dengeleme yoluyla tüm kümeyi orijinal çevrimiçi kümeden izole etmektir. Elbette, izole kümenin ölçeği çok büyüktür ve orijinal kümenin% 90 ila% 10'unu oluşturabilir. Örneğin, 100.000 sunucu vardır, ancak 90.000 sunucu izole edilebilir. Örneğin, büyük bir promosyon için hazırlanırken, Double Eleven üzerindeki trafik normalin 20 katından fazla olduğundan, normal trafik çok düşüktür ve mevcut trafiği etkilemeyebilir.
Tüm süreç nasıl? Örnek olarak rakamı alın ABCD'nin dört sistemi günlük trafiktir.Orijinal senaryo C daha fazla sunucu gerektirir, ancak stres testinden sonra B ve D'nin daha fazla sunucuya ihtiyaç duyduğu bulundu. Tüm süreç otomatiktir.C'nin bu kadar çok sunucuya ihtiyacı yoksa sunucuları çevrimdışı olur ve bu sunucular otomatik olarak B ve D'ye eklenir. Tamamı otomatik olarak çalıştıkları için, verimlilik çok yüksektir ve sabahın erken saatlerinde çalıştırılmasına gerek yoktur. Son olarak, sunucuların oranı haline gelmek için izole edilmiş kümeyi orijinal çevrimiçi kümeye geri döndürmeniz gerekir ve ertesi günün büyük sınava hazırlanabilirsiniz.
Akış değerlendirme süreci
Veri yapımından akış bağlantılarına kadar tüm kapasite değerlendirme süreci için bir merkezimiz var. Örneğin, bir etkinlik yapacağız Bu olay saniyede yaklaşık 50.000 işlemdir.Saniyede 50.000 işlem sayısını girdikten sonra, tüm sistem çalışmaya başlar. Stres testi, esnek zamanlama ve izolasyon hepsi. Otomatik süreç. Kapasite tahmin edilebilir, ancak planlamanın bir yolu yoktur, sadece mevcut limit vardır. Ne kadar hacmin geleceğini, kaç kullanıcının geleceğini ve o andaki en yüksek değeri büyük bir doğrulukla tahmin edebiliriz.
Ancak tahmin etmek pek mantıklı değil.Yapabileceğimiz şey cari işlemlerin sayısını sınırlamaktır.Örneğin 2016'da 175.000 işlem gerçekleştirdik ve mevcut limit değeri 172.000 olarak belirlendi. Tüm sistemler önce bu değeri ayarladı. Bu da imkansızdır, çünkü gerçek trafik bundan çok daha büyüktür ve gerçek trafiği destekleme maliyeti çok yüksek olacaktır.
Günlük sunucu işgali çok düşük. Esas olarak Alibaba Cloud sunucularını büyük promosyonlar sırasında kullanıyoruz, bu nedenle maliyet önemli ölçüde düştü. Bu nedenle, tüm kapasite planı 170.000 gibi bir değeri sınırlar. Önümüzdeki yıl 200.000 veya 250.000 olabilir Bu değere dayanarak, senaryo tabanlı tam bağlantılı stres testi araçlarını kullanın ve ardından tüm sistemin kapasitesini hesaplayın. Basınç ölçülür ve hesaplanır ve tüm sunucu kaynak kullanımı dengelenir. Bunu yapmanın avantajı, en başarılı etkinliği yapmak için en az kaynağı kullanmaktır.
Senaryo bazlı kapasite değerlendirme performansı
2013 yılından bu yana, bu teknolojiler dizisi aracılığıyla çok sayıda sorun bulduk ve bu sorunlar, günlük testler, işlevsel testler veya bazı araçların test edilmesinden sonra bu sorunları bulamadı. Donanım, ağ ve işletim sistemi sorunları açığa çıktı ve ağır yük altında her türlü garip sorun ortaya çıktı.
Double Eleven sırasında ortaya çıkan herhangi bir sorun felaket olabilir. Bunları 2013'te yaptıktan sonra, 2012 ve 2011'e dönüp baktığımızda, bir sorun ya da tuhaflık yok ve kesinlikle sorunlar çıkacak. En yoğun trafiğin, olağan en yoğun trafiğin kaç katından fazla olduğu herhangi bir aktivite, kesinlikle sorunlara neden olacaktır, çünkü birçok sorun bazı mantık ve bazı düşüncelerle bulunamaz.Tüm sahnelerin trafiğini simüle etmek için gerçek bir ortama güvenmek zorundadır. Oluşturun.
Kapasite değerlendirmesinin özeti
Kapasite planlama bir alan ve uzun bir süreçtir. Başlangıçta, performans stres testi için ticari yazılımlar kullanıldı. O zamanlar, bu yazılım uygulamasının oldukça iyi olduğunu ve tüm kapasitenin bazı hesaplamalarını destekleyebileceğini hissettim.Bugün bile, birçok şirket performans değerlendirme için hala benzer bir yazılım kullanıyor, bu da sürekli bir giriş süreci. Daha sonra, gerçek stres testi değerlendirmesinin kapasitesinin hala çok uzakta olduğu keşfedildi, bu nedenle çevrimiçi stres testini başlattık, saptırma, çoğaltma trafiği ve günlük oynatmayı başlattık ve her düğüm üzerinden kendi trafiğimizi değerlendirdik.
O zamanlar bu sistemin çok güçlü olduğunu düşünmüştüm, çünkü bu sistemi yaptım ve tüm teknik departmanın inovasyon ödülünü kazandım, bu yüzden bu sistemle ileride çift on bir endişelenmeme ve herhangi bir faaliyet için endişelenmeme gerek olmadığını düşündüm. Bence bu harika bir sistem. Gerçek durumun hala sürekli olarak geliştirilmesi ve tam bağlantılı bir stres testinin gerçekleştirilmesi gerekmektedir.Bağlantının tamamı, tüm kümeyi test etmek için senaryo tabanlı gerçek sahne simülasyonuna dayanmaktadır.
Bir alanda geriye dönüp baktığınızda, mevcut statükodan memnun olduğunuzda, örneğin, CSP "günlük stres testi platformu" mevcut statükodan tamamen tatmin olduğunda ve halihazırda birçok yerli ürünün önünde olduğunda, aslında yine de yapabilirsiniz Bir adım ileri gitmeye devam edin.
Double Eleven inovasyonunda kapasite planlamasını yaptık. Alibaba'nın tüm teknik mimarisi çok birleşiktir, çünkü tam bağlantı stres testi yapıldıktan sonra, Alipay vb. Birçok iş birimi bu şekilde yapılabilir.Çok basit bir şekilde kopyalanabilir, bu da bize getirir Çok düşük maliyet. Ar-Ge'den öğrenmeye ve işletme ve bakıma kadar, ürün yelpazesi işletme ve bakım, bize çok düşük maliyetler getirdi. Bu nedenle tüm ekibimizde çok az kişi var.Tam hat stres testini yapmak için sadece 4 veya 5 kişiye ihtiyacımız var, ancak tüm grupta 100'den fazla iş partisine hizmet veriyor.Bu da tüm yapının birliğinden kaynaklanıyor.
Bu yıl Double Eleven'ı bitirdikten sonra, CTO'muz da bize yeni bir zorluk çıkardı: Double Eleven'ın tüm süreci daha az maliyetle yatırım yapabilir ve tam bağlantı stres testi bir arama değil, günlük sistemin bir doğrulamasıdır. Sorunun kendisi ve sistemimizin daha otomatik ve akıllı olacağını umuyoruz. Bunu nasıl başaracağımızı düşünüyoruz.
yazar hakkında
Alibaba araştırmacısı Hua Ming Xiaoxie, Jiang Jiangwei, 2008 yılında Taobao'ya katıldı ve iş sistemi araştırma ve geliştirmesine katıldı. Alibaba'nın ara katman teknolojisi ürünlerinden ve 2012'de yüksek kullanılabilirlik mimarisinden sorumludur. Ara yazılım ürünleri, Alibaba'nın e-ticaretinin ve diğer iş dağıtılmış mimarilerinin temel teknik bileşenleridir ve çeşitli iş sistemlerinin hızlı bir şekilde yüksek oranda erişilebilir dağıtılmış mimari kümeler oluşturmasını sağlar. .
Bugünün TavsiyesiOkumak için aşağıdaki resme tıklayın
Konteynerin 2016'sını hatırlayarak: "Ölü" veya "Sonsuz Yaşam"?
Şükran Günü Kırmızı Paket Sezonu - Rongyun tarafından sağlanan anlık mesajlaşma bulut hizmeti, küresel geliştiricilerin indirmesi ve kullanması için anlık mesajlaşma teknolojisini bir SDK'da içerir ve geliştiricilere platform ortamı, teknik destek ve geliştiricilerin iş yapmasını sağlamak için operasyon sonrası ve bakım hizmetleri sağlar. Sosyal ağ, müşteri hizmetleri, sohbet odaları ve diğer senaryoların ihtiyaçlarını karşılamak için hızlı bir şekilde anlık mesajlaşma, tek sohbet, grup sohbeti vb. Gibi işlevleri gerçekleştirebilir. SDK 2.8.0 ve üstünü entegre edin, kırmızı zarf işlevini açın (çevrimiçi olmak için başvurun) ve Uygulamadaki kırmızı zarf gönderme deneyimini tamamlayın ve bonus kazanma şansınız var. Özel ayrıntılar "Orijinal metni okuyun" olarak damgalanmıştır ve sürprizler sonsuzdur!
