Sunucusuz En İyi Uygulamalar
Topluluk içinde uzun yıllardır en iyi uygulamaları tartışıyoruz, ancak görece çoğu zaman kabul görmüş birkaç kişi var.
Bu uygulamalara abone olan çoğu sunucusuz uygulayıcı, ölçekte çalışır. Sunucusuzluk vaadi, nispeten düşük bir seviyeden ziyade çoğunlukla hem yüksek ölçekte hem de patlaklı iş yüklerinde ortaya çıkar, bu nedenle bu en iyi uygulamaların çoğu, örneğin ölçek açısından gelir. Perakendede Nordstrom ve IoT'de iRobot. O kadar ölçeklendirmeyi hedeflemiyorsanız, muhtemelen bu en iyi uygulamaları izlemeden uzaklaşabilirsiniz.
Ve en iyi uygulamaların “tek uygulama” olmadığını unutmayın. En iyi uygulamalar, bir takım temel varsayımlara dayanır. Bu varsayımlar kullanım durumunuza uymuyorsa, bu en iyi uygulamalar uymayabilir.
Benim temel varsayımım, herkes ölçeğe girebilmek için uygulamalarını geliştiriyor (asla ölçeğe ulaşılmasa bile).
Yani bunlar benim gördüğüm en iyi uygulamalar.
Her fonksiyon sadece bir şey yapmalı
İşlev hatası ve ölçeklendirme yalıtımı hakkında.
Başka bir deyişle, işlevinizde bir switch ifadesi kullanırsanız, muhtemelen yanlış yapıyorsunuzdur.
Birçok öğretici ve çerçeve, tek bir proxy yolunun arkasındaki büyük yekpare bir işlev temelinde çalışır ve anahtar ifadelerini kullanır. Bu modeli sevmiyorum. İyi ölçeklenmiyor ve büyük ve karmaşık işlevler ortaya koyuyor.
Uygulamanızın tamamını çalıştıran bir / birkaç işlevle ilgili sorun, ölçeklendirdiğinizde, belirli bir öğeyi ölçeklendirmek yerine tüm uygulamanızı ölçeklendirmenizdir.
Web uygulamanızın 1 milyon çağrı alan bir parçasını ve 1 bin çağrı alan diğer bir kısmını kullanıyorsanız, işlevini milyon için optimize etmelisiniz, bununla birlikte binin tüm kodunu da dahil edin. Bu bir israf ve binler için kolayca optimize edemezsiniz. Onları ayırın. Bunda çok değer var.
İşlevler diğer işlevleri çağırmaz
Başka fonksiyonlar çağıran fonksiyonlar bir anti-kalıptır.
Bunun geçerli bir model olduğu çok az sayıda kenar durumu vardır, ancak kolayca bozulmazlar.
Temel olarak, yapma. Maliyetinizi iki katına çıkarır, hata ayıklamayı daha karmaşık hale getirir ve işlevlerinizin yalıtımının değerini kaldırırsınız.
İşlevler, daha fazla çalışmaya ihtiyaç duyulduğunda başka bir işlevi tetiklemesi gereken verileri bir veri deposuna veya kuyruğa itmelidir.
İşlevlerinizde olabildiğince az kütüphane kullanın (tercihen sıfır)
Bu bana çok açık geliyor.
İşlevler soğuk başlatma (bir işlev ilk kez başlatıldığında) ve sıcak başlatma (başlatıldı ve sıcak havuzdan çalıştırılmaya hazır). Soğuk başlangıçlar birçok şeyden etkilenir, ancak zip dosyasının boyutu (veya kod yüklenir) bunun bir parçasıdır. Ayrıca, başlatılması gereken kitaplıkların sayısı.
Kodunuz ne kadar fazlaysa, o kadar yavaş başlar.
Örnekleme gerektiren kütüphaneler ne kadar çok olursa, o kadar yavaş başlar.
Örnek olarak, Java bazı platformlarda sıcak bir başlangıçta mükemmel performans gösteren bir dildir. Ancak çok sayıda kitaplık kullanırsanız, soğumaya başlaması için bir çok saniyenizi bulabilirsin. Neredeyse kesinlikle onlara ihtiyacınız yok ve soğuk başlangıç performansı sadece başlangıçta değil, ölçeklemede de engel teşkil ediyor.
Başka bir nokta olarak, geliştiricilere yalnızca gerektiğinde kitaplıkları kullanan ve hiçbiri ile başlayıp hiçbiri ile bitmeden, hiçbiri ile neye ihtiyacım olmadığını inşa edemediğimde bittiği anlamına gelen büyük bir inanıyorum.
Express gibi şeyler sunucular için üretilmiştir ve sunucusuz uygulamalar oradaki tüm unsurlara ihtiyaç duymazlar. Peki neden tüm kodları ve bağımlılıkları tanıtın? Neden gereksiz kod getirdin? Bu asla kaçamayacağınız bir şey değil, aynı zamanda bir güvenlik riski oluşturabilir.
Bunun en iyi uygulama olmasının pek çok nedeni var. Elbette, test ettiğiniz, bildiğiniz ve güvendiğiniz bir kütüphane varsa, o zaman kesinlikle onu getirin, ancak anahtar öğe, kodu sınamak, bilmek ve güvenmektir. Bir öğretici ardından, aynı şey değil.
Bağlantı tabanlı servisleri kullanmaktan kaçının; RDBMS
Mecbur kalmadıkça yapmayın.
Bu beni en çok belaya sokacak. Pek çok web uygulaması çalışanı “ancak RDBMS bildiğimiz şey” bandwagonuna atlayacak.
RDBMS ile ilgili değil. Bağlantılar hakkında.
Sunucusuz, bağlantılardan çok hizmetlerle en iyi şekilde çalışır.
Hizmetler, taleplere verilen yanıtları çok hızlı bir şekilde geri gönderme ve hizmetin arkasındaki veri katmanının karmaşıklığını ele alma amaçlıdır. Bu, sunucusuz alanda büyük bir değere sahiptir ve neden DynamoDB gibi bir şeyin sunucusuz paradigmada bu kadar iyi uyduğunu gösterir.
Dürüst olmak gerekirse, sunucusuz insanlar RDBMS'ye karşı değiller, bağlantılara karşılar. Bağlantılar zaman alır ve bir fonksiyonun ölçeklendiğini hayal ederseniz, her bir fonksiyon ortamının bir bağlantıya ihtiyacı vardır ve fonksiyonun soğuk başlangıcında hem tıkanıklık hem de bir G / Ç ile tanışıyorsunuzdur. Gereksiz.
Bu yüzden bir RDBMS kullanmanız gerekiyorsa, ancak ortadaki bağlantı havuzunu idare eden bir servis koyarsanız, belki de sadece bununla başa çıkabilmek için bir tanımlamanın otomatik ölçeklendirme kabı olabilir.
Burada yapılacak en büyük nokta, sunucusuz mimarinin veri katmanınızı yeniden düşünmenizi gerektirebileceğidir. Bu sunucusuzun suçu değil. Mevcut veri katmanı düşününüzü yeniden kullanmaya çalışırsanız ve işe yaramazsa, muhtemelen sunucusuz mimarileri anlama eksikliği demektir.
Her rota için bir fonksiyon (eğer HTTP kullanıyorsanız)
Mümkünse tek işlevli vekil sunucu kullanmaktan kaçının. İyi ölçeklenmiyor ve sorunları yalıtmanıza yardımcı olmuyor. Bundan kaçınabileceğiniz durumlar vardır, örn. Bir dizi güzergahın işlevselliğinin kesinlikle tek bir masaya bağlı olduğu ve uygulamanın geri kalanından çok daha fazla ayrıldığı, ancak bu çalıştığım çoğu uygulamada önemli bir durum.
Bu, yönetim açısından karmaşıklık sağlar, ancak uygulamanız ölçeklendiğinde hataların ve sorunların yalıtılması açısından gerçekten yardımcı olur. Devam etmek istediğin gibi başla.
Ama yine de, sen olmayan her şeyi çalıştırmak için bir çeşit konfigürasyon yönetimi aracı kullanıyordun. Ve zaten bir çeşit CI ve CD araçları kullandınız mı? Hala sunucusuz olan DevOps'a ihtiyacınız var.
Mesajları ve sıraları kullanmayı öğrenin (zaman uyumsuz FTW)
Sunucusuz uygulamalar, uygulama asenkronize olduğunda en iyi çalışma eğilimindedir. Bu, eğilimin istek-yanıt ve çok fazla sorgulama yapma eğiliminde olduğu web uygulamaları için ileriye dönük değildir.
Başka işlevler çağırmayan işlevlere geri dönersek, bunun birlikte nasıl işlev gördüğüne dikkat etmek önemlidir. Bir kuyruk, zincirleme senaryosunda bir devre kesici olarak görev yapar, böylece bir işlev başarısız olursa, bir hata nedeniyle yedeklenmiş bir kuyruğu kolayca tahliye edebilir ya da ölü bir sıraya düşmeyen mesajları zorlayabilirsiniz.
Temel olarak, dağıtılmış sistemlerin nasıl çalıştığını öğrenin.
Sunucusuz arka ucu olan istemci uygulamalarında, en iyi yaklaşım CQRS'ye bakmaktır. Veri alma noktasının, veri girişi noktasından ayrılması, bu tür bir kalıbın anahtarıdır.
Veri akışları, veri gölleri değil
Sunucusuz bir sistemde, verileriniz sisteminizden akar. Bir veri gölünde sona erebilir, ancak olasılık, sunucusuz sisteminizdeyken bir çeşit akış halinde olmasıdır. Bu nedenle, herhangi bir noktada istirahatte değil, hareket halinde olduğu gibi tüm verileri ele alın.
Her zaman mümkün değildir, ancak sunucusuz bir ortamdaki bir veri gölünden sorgulama yapmaktan kaçının.
Sunucusuz, veri katmanınızı önemli ölçüde yeniden düşünmenizi gerektirir. Bu, RDBMS'ye ulaşma eğiliminde olan ve sadece ölçeklendirme onları yakaladığı için değil aynı zamanda veri yapıları çok hızlı hale geldiği için düz düşen yeni sunucuların sunucuya gelmesiyle en büyük sorun.
Akışlarınızın uygulamanız değiştikçe değişeceğini ve ölçeğin hepsini değiştireceğini göreceksiniz. Tek yapmanız gereken bir akışı yönlendirmek ise kolaydır. Bir gölü mahvetmek çok daha zordur.
Bu noktanın diğerlerinden biraz daha “dışarıda” olduğunu biliyorum, ancak yapılacak basit bir şey değil.
Sadece ölçeğe kodlama bir hatadır, nasıl ölçeklendiğini göz önünde bulundurmalısınız.
İlk sunucusuz uygulamanızı oluşturmak ve ölçeklendirmeyi izlemek çok kolaydır. Ne yaptığınızı anlamadıysanız, diğer tüm otomatik ölçeklendirme çözümleriyle yapabileceğiniz tuzağa kolayca düşebilirsiniz.
Başvurunuzu ve bunun nasıl ölçekleneceğini düşünmüyorsanız, kendinizi sorunlara hazırlarsınız. Yavaş, soğuk bir başlangıçla (çok sayıda kütüphane ve örneğin bir RDBMS kullanarak) bir şey yaparsanız ve ardından kullanımda bir artış yakalarsanız, işlevinizin eşzamanlılığını önemli ölçüde arttırabilir ve ardından bağlantılarınızı genişletebilir ve uygulamanızı yavaşlatabilirsiniz aşağı.
Bu nedenle, bir uygulamayı sadece düşürmeyin ve daha sonra aynı yük altında çalışacağını hayal edin. Başvurunuzu yük altında anlamak hala işin bir parçası.
Sonuç
Buraya koyabileceğim daha birçok şey var ve bu, onlarla konuşurken insanlara en çok açıklamak zorunda olduğum şeyler hakkındaki fikrim.
Başvurunuzu nasıl planlayacağınız ya da bir başvuruyu maliyetlendirmenin veya bunun gibi bir şeyin kapsam dışında kaldığı gibi bir şeyi nasıl düşüneceğinizi belirtmedim.
Başkalarının düşüncelerini duymak için sabırsızlanıyorum. Tabii ki, RDBMS konusunda yanıldığımı söyleyen bir sürü insan bulacağım. Konteynerlerde olduğu gibi, RDBMS'den nefret etmiyorum, ancak doğru işler için doğru araçları kullanmayı seviyorum. Aletlerini bil!