Mikro hizmetler için bir Azure işlem seçeneği belirleyin
İşlem terimi, uygulamanızın üzerinde çalıştığı işlem kaynakları için barındırma modelini ifade eder. Mikro hizmet mimarisi için özellikle popüler iki yaklaşım vardır:
- Adanmış düğümlerde (VM 'Ler) çalışan hizmetleri yöneten bir hizmet Orchestrator.
- Hizmet olarak işlevler (FaaS) kullanan sunucusuz bir mimari.
Bunlar tek seçenekseler de, mikro hizmetler oluşturmaya yönelik kanıtlanmış yaklaşımlardır. Bir uygulama her iki yaklaşımı de içerebilir.
Hizmet yöneticileri
Orchestrator, bir hizmet kümesini dağıtma ve yönetme ile ilgili görevleri işler. Bu görevler, Hizmetleri düğümlere yerleştirmeyi, hizmetlerin sistem durumunu izlemeyi, sağlıksız hizmetleri yeniden başlatmayı, hizmet örnekleri genelinde 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 kubernetes, Service Fabric, DC/OS ve docker sısınma içerir.
Azure platformunda aşağıdaki seçenekleri göz önünde bulundurun:
Azure Kubernetes Service (AKS) yönetilen bir Kubernetes hizmetidir. AKS, Kubernetes sağlar ve Kubernetes API uç noktalarını sunar, ancak otomatik yükseltmeler, otomatik düzeltme eki uygulama, otomatik ölçeklendirme ve diğer yönetim görevlerini gerçekleştirerek Kubernetes denetim düzlemi 'ni barındırır ve yönetir. AKS 'i bir hizmet olarak "Kubernetes API 'Leri" olarak düşünebilirsiniz.
Service Fabric , mikro hizmetleri paketlemek, dağıtmak ve yönetmek için dağıtılmış bir sistem platformudur. mikro hizmetler kapsayıcı olarak Service Fabric, ikili yürütülebilir dosyalar veya Reliable Servicesolarak dağıtılabilir. hizmetler, Reliable Services programlama modelini kullanarak sistemi sorgulamak, sistem durumunu raporlamak, yapılandırma ve kod değişiklikleri hakkında bildirim almak ve diğer hizmetleri saptamak için doğrudan programlama apı 'lerini Service Fabric kullanabilir. Service Fabric bir temel fark, güvenilir koleksiyonlarkullanılarak durum bilgisi olan hizmetler oluşturmaya yönelik güçlü bir odadır.
docker Enterprise Sürümü ve mesosphere DC/OS gibi diğer seçenekler Azure 'da bir ıaas ortamında çalıştırılabilir. Dağıtım şablonlarını Azure Marketi'nde bulabilirsiniz.
Kapsayıcılar
Bazen insanlar, kapsayıcılar ve mikro hizmetler hakkında aynı şey gibi konuşur. Doğru olmasa da, mikro hizmetler oluşturmak için kapsayıcılar gerekmez — kapsayıcılar, özellikle mikro hizmetlerle ilgili bazı avantajlara sahiptir; Ö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ımını kolaylaştırır. Kapsayıcılar hızla başlatılabilir ve durdurulabilir, böylece daha fazla yük işlemek veya düğüm hatalarından kurtarmak için yeni örnekler çalıştırabilirsiniz.
Yoğunluğu. Kapsayıcılar, işletim sistemi kaynaklarını paylaştıkları için bir sanal makine çalıştırmaya kıyasla hafif. Bu, özellikle uygulama birçok küçük hizmetten oluşuyorsa yararlı olacak şekilde, birden çok kapsayıcıyı tek bir düğüme paketlamanızı olanaklı kılar.
Kaynak yalıtımı. Bir kapsayıcı için kullanılabilir olan bellek ve CPU miktarını sınırlayabilirsiniz. Bu, ard bir işlemin konak kaynaklarını tüketmediğinden emin olmaya yardımcı olabilir. Daha fazla bilgi için bkz. Bulkbaş model .
Sunucusuz (hizmet olarak Işlevler)
Sunucusuz mimariyle VM 'leri veya sanal ağ altyapısını yönetmezsiniz. Bunun yerine, kodu dağıtırsınız ve barındırma hizmeti, kodu bir VM 'ye yerleştirerek ve yürüterek yürütür. Bu yaklaşım, olay tabanlı tetikleyiciler kullanılarak koordine edilen küçük ve ayrıntılı işlevlere izin vermez. Örneğin, bir sıraya yerleştirilmiş bir ileti kuyruktan okuyan ve iletiyi işleyen bir işlevi tetikleyebilir.
Azure işlevleri , HTTP istekleri, Service Bus kuyrukları ve Event Hubs olayları dahil çeşitli işlev tetikleyicilerini destekleyen sunucusuz bir işlem hizmetidir. Tüm liste için bkz. Azure işlevleri Tetikleyicileri ve bağlamaları kavramları. Ayrıca, Azure 'da yönetilen bir olay yönlendirme hizmeti olan Azure Event Gridde göz önünde bulundurun.
Orchestrator veya sunucusuz?
Bir Orchestrator yaklaşımı ve sunucusuz bir yaklaşım arasında seçim yaparken göz önünde bulundurmanız gereken bazı etmenler aşağıda verilmiştir.
Yönetilebilirlik Platform tüm işlem kaynaklarını sizin için yönettiğinden, sunucusuz bir uygulamanın yönetilmesi kolaydır. Orchestrator bir kümeyi yönetme ve yapılandırmanın bazı yönlerini soyutlarken, temel alınan VM 'Leri tamamen gizlemez. Orchestrator ile yük dengeleme, CPU ve bellek kullanımı ve ağ iletişimi gibi sorunlar hakkında düşünmeniz gerekir.
Esneklik ve denetim. Orchestrator, hizmetlerinizi ve kümeyi yapılandırma ve yönetme konusunda harika bir denetim sağlar. Zorunluluğunu getirir, ek karmaşıklığa sahiptir. Sunucusuz bir mimariyle, bu ayrıntılar soyutlandığından, bir ölçüde denetim verirsiniz.
Taşınabilirlik. burada listelenen tüm düzenleyiciler (kubernetes, DC/OS, docker sısınma 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 etmeniz, dağıtmanız ve yönetmeniz gerekmesi nedeniyle sunucusuz bir mimari kullanılarak karmaşık bir uygulama oluşturmak zor olabilir. azure 'daki bir seçenek, azure işlevleri kümesini koordine etmek için Azure Logic Apps 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. Orchestrator ile kümede çalışan VM 'Ler için ödeme yaparsınız. Sunucusuz bir uygulamayla, yalnızca tüketilen gerçek işlem kaynakları için ödeme yaparsınız. Her iki durumda da depolama, veritabanları ve mesajlaşma hizmetleri gibi ek hizmetlerin maliyetini çarpanlara almanız gerekir.
Ölçeklenebilirlik. Azure Işlevleri, gelen olayların sayısına bağlı olarak talebi karşılamak için otomatik olarak ölçeklendirilir. Orchestrator ile, kümede çalışan hizmet örneği sayısını artırarak ölçeği artırabilirsiniz. Ayrıca, kümeye ek VM 'Ler ekleyerek ölçeklendirebilirsiniz.
Başvuru uygulamamız öncelikle Kubernetes kullanır, ancak teslimat geçmişi hizmeti gibi bir hizmet için Azure Işlevleri kullanıyoruz. Azure Işlevleri, bu hizmet için bir olay odaklı iş yükü olduğundan, bu hizmete uygun bir şekilde uyum sağlandı. İşlevi çağırmak için bir Event Hubs tetikleyicisi kullanarak, hizmet en az bir kod miktarına ihtiyaç duyuyordu. Ayrıca, dağıtım geçmişi hizmeti ana iş akışının bir parçası olmadığından, Kubernetes kümesi dışında çalıştırmak, Kullanıcı tarafından başlatılan işlemlerin uçtan uca gecikmesini etkilemez.