{"id":4344,"date":"2023-03-18T00:58:07","date_gmt":"2023-03-17T23:58:07","guid":{"rendered":"https:\/\/gokhan-gokalp.com\/?p=4344"},"modified":"2023-03-18T20:57:03","modified_gmt":"2023-03-18T19:57:03","slug":"how-to-order-events-in-microservices-by-using-azure-service-bus-fifo-consumers","status":"publish","type":"post","link":"https:\/\/gokhan-gokalp.com\/tr\/how-to-order-events-in-microservices-by-using-azure-service-bus-fifo-consumers\/","title":{"rendered":"Azure Service Bus Kullanarak Microservice\u2019lerde Event\u2019ler Nas\u0131l S\u0131ralan\u0131r (FIFO Consumers)"},"content":{"rendered":"

Bazen baz\u0131 senaryolar vard\u0131r karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 veya eksi yanlar\u0131n\u0131 bildi\u011fimiz halde implemente etmekten ka\u00e7amad\u0131\u011f\u0131m\u0131z veya implemente etme zorunda kald\u0131\u011f\u0131m\u0131z. Distributed ortamlarda birbirlerine ba\u011fl\u0131 baz\u0131 event’leri\/message’lar\u0131 belirli bir s\u0131ra<\/strong> (publish edildikleri) i\u00e7erisinde i\u015fleyebilmek de bence bunlardan birisi. \u00d6rne\u011fin batch processing yap\u0131yor ve her bir item’\u0131 belirli bir s\u0131ra i\u00e7erisinde i\u015flememiz gerekiyor olabilir veya bir e-ticaret firmas\u0131n\u0131n fulfillment domain’inde \u00e7al\u0131\u015f\u0131yor olabilir ve sipari\u015flerin stat\u00fcslerini do\u011fru g\u00fcncelleyebilmek i\u00e7in ilgili event’leri ger\u00e7ekle\u015fen s\u0131ralar\u0131yla i\u015flememiz gerekiyor olabilir.<\/p>\n

Bir \u00e7ok message broker’\u0131n FIFO<\/strong><\/em> prensibi ile \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve normal \u015fartlarda FIFO<\/em> ordering’i sa\u011flad\u0131klar\u0131n\u0131 d\u00fc\u015f\u00fcn\u00fcrsek, bir publisher ve bir subscriber’a sahip olarak birbirine ba\u011fl\u0131 baz\u0131 event’leri publish edildikleri s\u0131ra i\u00e7erisinde kolayl\u0131kla consume edebiliriz. Tabi event i\u015fleme s\u0131ras\u0131nda olu\u015fabilecek network veya uygulama kaynakl\u0131 hatalar\u0131 saymazsak. \u00d6rne\u011fin ge\u00e7ici bir hata y\u00fcz\u00fcnden ilgili event kolayl\u0131kla re-queue olabilir ve ilgili s\u0131ray\u0131 bozabilir veya message broker i\u015flenmi\u015f bir event i\u00e7in yine ge\u00e7ici bir hatadan dolay\u0131 ack bilgisini alamaz ve ilgili event’i tekrar i\u015flenmeye uygun hale getirebilir ve duplication’lar olu\u015fturabilir. Alternatif \u00e7\u00f6z\u00fcm olarak event’ler i\u00e7erisine bir timestamp dahil etmeyi de d\u00fc\u015f\u00fcnebilir ve gerekli kontrolleri ger\u00e7ekle\u015ftirdikten sonra i\u015fleme i\u015flemini ger\u00e7ekle\u015ftirebiliriz. Maalesef bu sefer de race-condition gibi farkl\u0131 problemler ile ba\u015fa \u00e7\u0131kmam\u0131z gerekecektir. Teknik olarak elbette olu\u015fabilecek bu tarz hatalar\u0131 da ele alabilir ve event i\u015fleme s\u0131ras\u0131n\u0131 koruyabilmek ad\u0131na farkl\u0131 logic’ler kodlayabiliriz. Fakat g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi event ordering standart FIFO<\/em> queue’lar ile kolay eri\u015filebilir gibi g\u00f6r\u00fcnmesine ra\u011fmen, subscriber taraf\u0131nda herhangi bir garanti olmad\u0131\u011f\u0131 i\u00e7in i\u015fler karma\u015f\u0131kla\u015fmaya ba\u015fl\u0131yor.<\/p>\n

Daha da \u00f6tesi tek bir subscriber gereklili\u011fi y\u00fcz\u00fcnden scalability <\/strong>ve decoupling<\/strong> gibi \u00f6nemli prensipleri de kaybediyor ve genel throughput’dan fedakarl\u0131k ediyor olaca\u011f\u0131z.<\/p>\n

Dolay\u0131s\u0131yla sistemimizi, architecture’\u0131m\u0131z\u0131 veya event payload’lar\u0131m\u0131za design ederken bu tarz operasyonlara gerek olmayacak \u015fekilde design etmemiz veya en az\u0131ndan minimuma indirgememiz, ileriye y\u00f6nelik sistemimizin sa\u011fl\u0131\u011f\u0131 a\u00e7\u0131s\u0131ndan olduk\u00e7a \u00f6nem ta\u015f\u0131maktad\u0131r.<\/p>\n

Peki, event ordering’e ihtiyac\u0131m\u0131z oldu\u011funda ve implemente etme durumunda kald\u0131\u011f\u0131m\u0131zda ne yapaca\u011f\u0131z? Bu makale kapsam\u0131nda ise en verimli bi \u015fekilde bu i\u015flemi Azure Service Bus<\/strong><\/em> kullanarak nas\u0131l ger\u00e7ekle\u015ftirebilece\u011fimize de\u011finece\u011fim. Dolays\u0131yla message broker olarak Azure Service Bus<\/em> kulland\u0131\u011f\u0131m\u0131z\u0131 varsayaca\u011f\u0131m ve bu konuda bizlere Azure Service Bus<\/em>‘\u0131n sunmu\u015f oldu\u011fu “sessions<\/strong>” \u00f6zelli\u011finin nas\u0131l yard\u0131mc\u0131 olabilece\u011fine bir bakaca\u011f\u0131z.<\/p>\n

Azure Service Bus – Sessions<\/h2>\n

Normal \u015fartlarda FIFO<\/em> event delivery garantisi sa\u011flayan bir message broker kullan\u0131yorsak, bir publisher ve bir subscriber’a sahip olarak birbirine ba\u011fl\u0131 baz\u0131 event’leri publish edildikleri s\u0131ra i\u00e7erisinde consume edebilece\u011fimizi s\u00f6yledik. Fakat subscriber taraf\u0131nda herhangi bir garanti olmad\u0131\u011f\u0131 i\u00e7in bu yakla\u015f\u0131m\u0131n ne kadar k\u0131r\u0131lgan ve karma\u015f\u0131k olabilece\u011finden de bahsettik. Peki bu FIFO<\/em> event delivery garantisini en kolay yoldan subscriber taraf\u0131 i\u00e7in de nas\u0131l sa\u011flayabiliriz?<\/p>\n

\u0130\u015fte tam da bu noktada Azure Service Bus<\/em>‘\u0131n sessions<\/em><\/strong> \u00f6zelli\u011fi devreye girmekte. Sessions’lar\u0131 kullanarak istedi\u011fimiz event’leri belirleyece\u011fimiz bir “SessionId<\/em>” ile etiketleyerek, ilgili event’lerin bir grup halinde ve publish edildikleri s\u0131ra i\u00e7erisinde i\u015flenebilmelerini sa\u011flayabiliriz. Ayr\u0131ca bu i\u015flemi scalability prensibinden de k\u0131smen fazla \u00f6d\u00fcn vermeden ger\u00e7ekle\u015ftirebilmekteyiz.<\/p>\n

Peki nas\u0131l?<\/h3>\n
\"\"<\/a>
Ref: https:\/\/devblogs.microsoft.com\/premier-developer\/wp-content\/uploads\/sites\/31\/2019\/09\/word-image.png<\/figcaption><\/figure>\n

\u00d6ncelikle bu \u00f6zelli\u011fi kullanabilmek i\u00e7in, Azure Service Bus<\/em>‘\u0131n “Standard<\/em>” veya “Premium<\/em>” se\u00e7eneklerinden birisini kullan\u0131yor olmam\u0131z gerekmektedir. Azure Service Bus<\/em> \u00fczerinde bir “queue<\/em>” veya “subscription<\/em>” olu\u015ftururken, message sessions \u00f6zelli\u011fini de aktifle\u015ftirmemiz gerekmektedir. Aktifle\u015ftirme i\u015flemi i\u00e7in buraya<\/a><\/em> g\u00f6z atabilirsiniz.<\/p>\n

NOT<\/strong><\/em>: Sessions’\u0131n etkinle\u015ftirildi\u011fi queue’larda t\u00fcm event’ler bir session id’si i\u00e7ermesi gerekmektedir.<\/p><\/blockquote>\n

Sessions’\u0131n \u00e7al\u0131\u015fma mant\u0131\u011f\u0131n\u0131 k\u0131saca \u00f6zetlemek gerekirse, event’ler publish edilirken bir session id’si ile publish edilmektedir. \u00d6rne\u011fin bir sipari\u015f id’si. Daha sonra herhangi bir subscriber ilgili queue’dan hen\u00fcz \u00fczerinde lock bulunmayan bir event’i al\u0131r ve i\u015fleyebilmek i\u00e7in \u00f6ncelikle o event’in session id’si i\u00e7in bir lock i\u015flemi ger\u00e7ekle\u015ftirir. B\u00f6ylelikle queue’daki ayn\u0131 session id’sine sahip t\u00fcm event’ler, lock’\u0131 tutan subscriber taraf\u0131ndan tek tek publish edildikleri s\u0131ra i\u00e7erisinde i\u015flenebilmektedir. Ayr\u0131ca bu noktada tek bir subscriber’a sahip olma zorunlulu\u011fumuz da bulunmamaktad\u0131r. Elbette bir session<\/strong> alt\u0131ndaki event’leri i\u015flerken paralellikten fedakarl\u0131k etmi\u015f olmaktay\u0131z, fakat farkl\u0131 session’lar<\/strong> alt\u0131ndaki ayn\u0131 event’leri paralel olarak i\u015fleyebilmekteyiz.<\/p>\n

Bir \u00d6rnek Ger\u00e7ekle\u015ftirelim<\/h2>\n

Konuyu daha iyi anlayabilmek ad\u0131na basit bir \u00f6rnek ger\u00e7ekle\u015ftirelim. Bir e-ticaret firmas\u0131nda \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131z\u0131 varsayal\u0131m ve bir sipari\u015fin m\u00fc\u015fteriye teslim edilene kadar olan stat\u00fcs de\u011fi\u015fikliklerini m\u00fc\u015fteriye g\u00f6stermek istiyoruz.<\/p>\n

\u00d6ncelikle Contracts<\/strong><\/em> ad\u0131nda bir .NET 7<\/em> class library projesi olu\u015ftural\u0131m ve i\u00e7erisine a\u015fa\u011f\u0131daki gibi “OrderStatusChangedEvent<\/em>” ad\u0131nda bir event tan\u0131mlayal\u0131m.<\/p>\n

namespace Contracts;\r\n\r\npublic class OrderStatusChangedEvent\r\n{\r\n    public OrderStatusChangedEvent(string orderId, string status, DateTime changeDate)\r\n    {\r\n        OrderId = orderId;\r\n        Status = status;\r\n        ChangeDate = changeDate;\r\n    }\r\n\r\n    public string OrderId { get; set; }\r\n    public string Status { get; set; }\r\n    public DateTime ChangeDate { get; set; }\r\n}<\/pre>\n
Bu event ile ilgili sipari\u015f \u00f6zelindeki stat\u00fcs de\u011fi\u015fikliklerini publish etti\u011fimizi ve a\u015fa\u011f\u0131daki gibi de stat\u00fcs’lere sahip oldu\u011fumuzu varsayal\u0131m.<\/p>\n