Olay güdümlü mimari, birkaç hizmet arasındaki sınırlı bir modelden geniş bir üretici, tüketici ve mesaj kanalı ağına dönüşüyor. Bu noktada temel sorun artık mesajı göndermek değil; neyin gönderildiğini, kime ait olduğunu, kimin buna bağımlı olduğunu ve üretim kesintilerine yol açmadan şemasının nasıl değiştirilebileceğini veya altyapısının nasıl yeniden oluşturulabileceğini bilmektir. Ian Cooper'ın Just Eat Takeaway'deki gerçek mühendislik uygulamalarına dayanarak büyük ölçekte asenkron API'leri yönetme konulu oturumunun odağı budur.
Ölçek büyüdükçe işler neden karmaşıklaşıyor?
Küçük kuruluşlarda ekip üyeleri, olayları yayımlayan ve tüketen hizmetleri biliyor olabilir; ayrıca konu veya kanallar bir mesajlaşma çerçevesi aracılığıyla ya da platform ekibine doğrudan talep gönderilerek oluşturulabilir. Ancak ekip ve hizmet sayısı arttıkça bu yaklaşım etkinliğini kaybeder. Belirli bir uç noktanın kime ait olduğu, mesajı tanımlayan sözleşmenin ne olduğu veya veri ve analiz ekiplerinde bilinmeyen tüketicilerin bulunup bulunmadığı açık olmayabilir.
Risk, bir ekibin yalnızca bilinen tüketicilerle görüştükten sonra bir mesaj şemasını değiştirmesiyle ortaya çıkar; oysa başka ekipler iletişim çemberinde yer almadan bu mesaja bağımlı olabilir. Kullanılmadığı düşünülen bir konunun silinmesi, özellikle sahibini belirlemenin veya gereken altyapıyı yeniden yayımlamanın güvenilir bir yolu yoksa ve sistemin büyük bölümlerini yeniden yayımlamak gerekiyorsa, kritik bir akışın kaybedilmesine yol açabilir.
Olay arayüzlerini yönetmek için üç eksen
Cooper sorunu keşif, yönetişim ve tedarik olarak üçe ayırıyor. Bu süreç, «ABC'ler» olarak adlandırdığı yaklaşım aracılığıyla herhangi bir uç noktada neyin tanımlanması gerektiğini anlamakla başlıyor: adres, binding ve sözleşme. Adres, mesaj akışının konumunu belirler; binding, protokolü, aktarımı ve kodlamayı tanımlar; sözleşme ise mesajın taşıdığı başlıkları ve verileri belirler.
Bu bağlamda AsyncAPI, OpenAPI gibi HTTP API'lerini dokümante etme mekanizmalarına bir karşılık sunar ve protokole özgü sunucuları, kanalları, mesajları, işlemleri ve bağlantıları modeller. JSON Schema, Avro ve Protobuf kullanarak mesajların tanımlanmasını destekler; ayrıca tanımların birden çok dosyada tekrarlanması yerine yeniden kullanılmasına olanak tanır. Ancak Cooper, yüzlerce AsyncAPI dosyasını tek bir depoya koymanın keşif sorununu tek başına çözmediğini vurguluyor; olay envanteri büyüdüğünde metin araması sınırlı kalıyor.
Bu nedenle kuruluşların EventCatalog veya Marmot gibi katalog araçlarına ya da xRegistry gibi açık bir kayda ihtiyacı olabilir. Amaç, mesaj akışlarını ve bunlar arasındaki ilişkileri göstermek ve şemaları üreticiler ile tüketicilere bağlamaktır. Bu araçlar görselleştirme ve kullanıma hazır arayüzler bakımından farklılık gösterir; ancak ortak işlevleri, keşfi Slack'te sorulan veya dağınık depolarda aranan bir sorudan sorgulanabilir bir hizmete dönüştürmektir.
CloudEvents'in meta verileri standartlaştırmadaki rolü
CloudEvents, kimlik, kaynak, sürüm ve tür gibi standartlaştırılmış bir meta veri kümesi sunarak sorunun farklı bir yönünü ele alır; ayrıca veri içerik türü, konu, zaman ve şema bağlantısı için isteğe bağlı alanlar sağlar. Olay türü, mesajı yönlendirmek veya bir kanalda birden çok tür birlikte bulunduğunda serisini çözme mekanizmasını seçmek için kullanılabilir.
Oturumda, CloudEvents'teki binary ve structured modellerinin, mesajın alışılmış anlamda «ikili» veya «yapılandırılmış» olmasından değil, taşıma protokolünün başlık taşıma kapasitesinden kaynaklandığı açıklanıyor. Bu ayrıntı, SNS gibi sistemlerde önem kazanır; CloudEvents verilerinin tamamı başlıklara yerleştirilirse sınırlı sayıdaki mesaj özniteliği hızla tüketilebilir. Bu nedenle bazı senaryolarda bunları gövde içine sarmalamak pratik bir seçenek olabilir.
Yönetişim yalnızca dokümantasyondan ibaret değil
Sözleşmeleri dokümante etmek, tüketicilere mesajın ne olduğunu açıklar; ancak üreticinin onların bağımlılıklarını bozan bir değişiklik yayımlamasını engellemez. Bu nedenle sunulan yaklaşım, sözleşmeler güncellenirken uyumluluk kuralları uygulayan ve kurallara uymayan mesajları veya değişiklikleri reddeden bir şema kaydının kullanılmasını öneriyor.
Güvenli uygulamalar genellikle alanların isteğe bağlı olarak eklenmesini, alanların silinmesinin tüm tüketiciler onları kullanmayı bırakana kadar ertelenmesini ve yeniden adlandırmanın silme ile eklemeden oluşan bir değişiklik olarak ele alınmasını içerir. Alan türünün değiştirilmesi ise çoğunlukla geriye dönük uyumluluğu bozan bir değişikliktir. Bu işlem, istenen türe sahip yeni bir alan eklenerek, tüketiciler bu alana taşınarak ve eski alan kaldırılmadan önce gerçekleştirilebilir.
Pratikte ne değişiyor?
Teknik okuyucuya verilen temel mesaj, büyük ölçekte olay yönetiminin tek bir araca değil, birbiriyle bağlantılı bir zincire ihtiyaç duyduğudur: arayüzleri tanımlamak için AsyncAPI, meta verileri standartlaştırmak için CloudEvents, keşfi kolaylaştırmak için bir katalog veya kayıt, uyumluluğu zorunlu kılmak için bir şema kaydı ve altyapıyı tedarik etmek ve kaymasını izlemek için otomasyon. Bu katmanlar olmadan olay güdümlü mimari, görünmeyen bağımlılıklarla dolu bir ağa dönüşebilir.
Pratik sınırlamalar da devam ediyor: standartlar tek başına tüketiciler hakkında tam bilgi sağlamaz; ayrıca araçlar arayüzler, görselleştirme ve aracılarla entegrasyon desteği bakımından farklılık gösterir. Bu nedenle bu yaklaşımın uygulanması, sözleşmelerin ve kanalların sahipliğinin açıkça belirlenmesini, değişikliklerin CI/CD süreçlerine bağlanmasını ve kaynakları yeniden oluşturabilecek bir kurtarma yolunun korunmasını gerektirir; böylece bireysel bilgiye veya eski dokümantasyona bağımlı kalınmaz.