Mikro hizmetler için bir Azure işlem seçeneği belirleme
İşlem terimi, uygulamanızın üzerinde çalıştığı işlem kaynakları için barındırma modelini ifade eder. Mikro hizmet mimarisi için iki yaklaşım özellikle popülerdir:
- Ayrılmış düğümlerde (VM) çalışan hizmetleri yöneten bir hizmet düzenleyici.
- Hizmet olarak işlevleri (FaaS) kullanan sunucusuz mimari.
Bunlar tek seçenek olmasa da, mikro hizmetler oluşturmaya yönelik kanıtlanmış yaklaşımlardır. Bir uygulama her iki yaklaşımı da içerebilir.
Hizmet düzenleyicileri
Düzenleyici, bir hizmet kümesini dağıtma ve yönetme ile ilgili görevleri işler. Bu görevler düğümlere hizmet yerleştirmeyi, hizmetlerin durumunu izlemeyi, iyi durumda olmayan hizmetleri yeniden başlatmayı, hizmet örnekleri arasında ağ trafiğini yük dengelemeyi, hizmet bulmayı, bir hizmetin örnek sayısını ölçeklendirmeyi ve yapılandırma güncelleştirmelerini uygulamayı içerir. Popüler düzenleyiciler arasında Kubernetes, Service Fabric, DC/OS ve Docker Swarm bulunur.
Azure platformunda aşağıdaki seçenekleri göz önünde bulundurun:
Azure Kubernetes Service (AKS) yönetilen bir Kubernetes hizmetidir. AKS, Kubernetes'i sağlar ve Kubernetes API uç noktalarını kullanıma sunar, ancak Kubernetes denetim düzlemini barındırıp yönetir, otomatik yükseltmeler, otomatik düzeltme eki uygulama, otomatik ölçeklendirme ve diğer yönetim görevlerini gerçekleştirir. AKS'yi "Hizmet olarak Kubernetes API'leri" olarak düşünebilirsiniz.
Azure Container Apps , Kapsayıcı düzenleme ve diğer yönetim görevlerinin karmaşıklıklarını soyutlayan Kubernetes üzerinde oluşturulmuş bir yönetilen hizmettir. Container Apps, kubernetes özelliklerini sağlarken sunucusuz bir ortamda kapsayıcılı uygulamaların ve mikro hizmetlerin dağıtımını ve yönetimini basitleştirir.
Service Fabric , mikro hizmetleri paketlemeye, dağıtmaya ve yönetmeye yönelik bir dağıtılmış sistemler platformudur. Mikro hizmetler Service Fabric'e kapsayıcı, ikili yürütülebilir dosya veya Reliable Services olarak dağıtılabilir. Reliable Services programlama modelini kullanarak hizmetler sistemi sorgulamak, sistem durumunu raporlamak, yapılandırma ve kod değişiklikleri hakkında bildirim almak ve diğer hizmetleri keşfetmek için Service Fabric programlama API'lerini doğrudan kullanabilir. Service Fabric ile önemli bir fark, Güvenilir Koleksiyonlar kullanarak durum bilgisi olan hizmetler oluşturmaya odaklanmaktır.
Docker Enterprise Sürümü gibi diğer seçenekler Azure'daki bir IaaS ortamında çalıştırılabilir. Dağıtım şablonlarını Azure Market bulabilirsiniz.
Kapsayıcılar
Bazen insanlar kapsayıcılar ve mikro hizmetler hakkında aynı şeymiş gibi konuşur. Bu doğru olmasa da ( mikro hizmetler oluşturmak için kapsayıcılara ihtiyacınız yoktur), kapsayıcıların özellikle mikro hizmetlerle ilgili bazı avantajları vardır, örneğin:
Taşınabilirlik. Kapsayıcı görüntüsü, kitaplıkları veya diğer bağımlılıkları yüklemeye gerek kalmadan çalışan tek başına bir pakettir. Bu, dağıtımlarını kolaylaştırır. Kapsayıcılar hızlı bir şekilde başlatılabilir ve durdurulabilir, böylece daha fazla yükü işlemek veya düğüm hatalarından kurtarmak için yeni örnekler oluşturabilirsiniz.
Yoğunluk. Kapsayıcılar, işletim sistemi kaynaklarını paylaştığından sanal makine çalıştırmaya kıyasla basittir. Bu, birden çok kapsayıcıyı tek bir düğüme paketlemeyi mümkün kılar. Bu, özellikle uygulama birçok küçük hizmet içerdiğinde kullanışlıdır.
Kaynak yalıtımı. Bir kapsayıcının kullanabileceği bellek ve CPU miktarını sınırlayabilirsiniz. Bu, bir kaçamak işleminin konak kaynaklarını tüketmediğinden emin olmanıza yardımcı olabilir. Daha fazla bilgi için bkz. Bulkhead deseni.
Sunucusuz (Hizmet Olarak İşlevler)
Sunucusuz mimari ile VM'leri veya sanal ağ altyapısını yönetmezsiniz. Bunun yerine, kodu dağıtırsınız ve barındırma hizmeti bu kodu bir VM'ye yerleştirip yürütür. Bu yaklaşım, olay tabanlı tetikleyiciler kullanılarak eşgüdümlü küçük ayrıntılı işlevleri destekleme eğilimindedir. Örneğin, kuyruğa yerleştirilen bir ileti, kuyruktan okuyan ve iletiyi işleyen bir işlevi tetikleyebilir.
Azure İşlevleri HTTP istekleri, Service Bus kuyrukları ve Event Hubs olayları gibi çeşitli işlev tetikleyicilerini destekleyen sunucusuz bir işlem hizmetidir. Tam liste için bkz. tetikleyiciler ve bağlamalar kavramları Azure İşlevleri. Ayrıca Azure'da yönetilen olay yönlendirme hizmeti olan Azure Event Grid'i de göz önünde bulundurun.
Orchestrator mı sunucusuz mu?
Düzenleyici yaklaşımı ile sunucusuz yaklaşım arasında seçim yaparken dikkate alınması gereken bazı faktörler aşağıdadır.
Yönetilebilirlik Platform tüm işlem kaynaklarını sizin için yönettiğinden sunucusuz bir uygulamayı yönetmek kolaydır. Düzenleyici bir kümeyi yönetme ve yapılandırmanın bazı yönlerini soyutlasa da, temel alınan VM'leri tamamen gizlemez. Bir düzenleyici ile yük dengeleme, CPU ve bellek kullanımı ve ağ gibi sorunları düşünmeniz gerekir.
Esneklik ve denetim. Düzenleyici, hizmetlerinizi ve kümenizi yapılandırma ve yönetme konusunda size çok fazla denetim sağlar. Denge ek karmaşıklıktır. Sunucusuz mimaride, bu ayrıntılar soyutlandığından bir derece denetimden vazgeçersiniz.
Taşınabilirlik. Burada listelenen tüm düzenleyiciler (Kubernetes, DC/OS, Docker Swarm ve Service Fabric) şirket içinde veya birden çok genel bulutta çalışabilir.
Uygulama tümleştirmesi. Birçok küçük bağımsız işlevi koordine etme, dağıtma ve yönetme gereksinimi nedeniyle sunucusuz bir mimari kullanarak karmaşık bir uygulama oluşturmak zor olabilir. Azure'daki bir seçenek, bir dizi Azure İşlevleri koordine etmek için Azure Logic Apps'i kullanmaktır. Bu yaklaşımın bir örneği için bkz . Azure Logic Apps ile tümleşen bir işlev oluşturma.
Maliyet. Bir düzenleyici ile, kümede çalışan VM'ler için ödeme gerçekleştirirsiniz. Sunucusuz bir uygulamayla yalnızca tüketilen gerçek işlem kaynakları için ödeme alırsınız. Her iki durumda da depolama, veritabanları ve mesajlaşma hizmetleri gibi ek hizmetlerin maliyetini dikkate almanız gerekir.
Ölçeklenebilirlik. Azure İşlevleri gelen olayların sayısına göre talebi karşılamak için otomatik olarak ölçeklendirilir. Düzenleyici ile kümede çalışan hizmet örneklerinin sayısını artırarak ölçeği genişletebilirsiniz. Kümeye ek VM'ler ekleyerek de ölçeklendikleyebilirsiniz.
Başvuru uygulamamızda öncelikli olarak Kubernetes kullanılıyor, ancak Azure İşlevleri tek bir hizmet için(Teslim Geçmişi hizmeti) kullandık. Azure İşlevleri, olay odaklı bir iş yükü olduğundan bu hizmet için uygundu. İşlevi çağırmak için bir Event Hubs tetikleyicisi kullanarak hizmetin en az miktarda koda ihtiyacı vardı. Ayrıca Teslim Geçmişi hizmeti ana iş akışının bir parçası olmadığından Kubernetes kümesinin dışında çalıştırmak, kullanıcı tarafından başlatılan işlemlerin uçtan uca gecikme süresini etkilemez.