Mikro servislerin faydası, Bağımsız olarak geliştirilmesi ve bağımsız olarak çalışabilmesiyle mümkündür. Mikro servisler arasındaki bağımlılıklar, micro servis mimarisini bize sunacağı faydayı azaltır.
Selective data replication, bağımlılığın scopunu en aza indirirerek başka bir mikro servisin datasını kullanmamıza olanak tanır. Bu yaklaşımı kullanarak ihtiyacımız olan datanın bulunduğu mikro servisin API'sine bağımlı olmak yerine data schemasına bağımlı oluruz. Yani ihtiyacımız olan datanın tablosunu bu micro servis içinde oluşturacağız.
Böylece geliştirme ve üretimde mikro servislerin bağımlılık maliyetini en aza indirmiş oluruz.
Giriş
Monolitik uygulamalarda, tüm verilerimiz tek bir ilişkisel veritabanında olduğundan dolayı datalara sorguları çok kolay bir şekilde yapabiliyoruz.
Micro servis mimarisiyle verilerimiz birden çok veritabanı üzerine dağıtılır. Her mikro servis sadece kendi veritabanına erişebilir. Birden çok mikro servisten gelen verileri birleştirmek için kullanıma hazır bir çözüm de yoktur.
1- Selective Data Replication
Bu yaklaşımla, diğer mikro servislerden ihtiyaç duyduğumuz verileri mikro servisimizin veritabanında replicasını oluşturuyoruz. (Yeni bir tablo açıp oraya kaydetmek)
Mikro servisler arasındaki tek bağlantı, data replication configuration olacaktır.
Publish-Subscribe Replication yaklaşımı kullanılarak veritabanı dataları güncellenir.
Advantages:
- Implemantationu basitleştirir. Verileri sorgulamak için REST çağrılarına gerek kalmaz. Ayrıca datalar micro servisin kendi veritabanınad olduğundan verileri birleştirmek için artık SQL Join kullanılabilir
- Test etmeyi basitleştirir. Mikro servis API'sini test ederken diğer mikro servislerin online olması gerekmez.
- Separation of concerns. Diğer servislerle olan veri entegrasyonu, mikro servis API'sinin implementasyonundan ayrıdır.
- Sorgu kriterleri, verileri tüketen mikro hizmet tarafından uygulanır. Artık ihtiyacınız olan sorgular için verileri sağlayan mikro servise bağımlı değiliz. Tüketici mikro servisler kendi veritabanı sorgularını yapabilirler.(ihtiyaç duydukları kriterler ne olursa olsun). Bu, tüketen mikro servislerin gereksinimleri değiştiğinde verileri sağlayan mikro servisi değiştirme ihtiyacını ortadan kaldırır.Ayrıca, mikro servisleri tüketerek artık gerekli olmayan uzak sorgu API'lerini (tedarik eden mikro hizmetten) izlemeniz gerekmeyecek.
- Daha düşük latency. Diğer mikro servisleri http requesti atmak yerine verileri doğrudan veritabanından alabilirsiniz.
Disadvantages:
- Verilerin tutarlı olmaması. Replica eninde sonunda tutarlı olacaktır; Fakat her değişiklik için, verilerin mikro servisler arasında senkronize olmayacağı kısa bir süre olacaktır.
- Deployment processe fazladan bir step eklenecektir. Veritabanı şeması değiştiğinde, microserisimiz configurasyonun güncellenmesi gerekebilir.(taloya yeni bir kolon eklenmesi vs.)
- Aynı datanın farklı veritabanlarında dublicate olması. Servisler arasında ne kadar çok veri kopyalanırsa, bakım yükü ve veritabanı yedekleme(backup) maliyetleri vb. o kadar yüksek olur.
- Veri güvenliğini sorununu arttırır. Birden fazla veritabanında ve muhtemelen mesajlaşma sunucunmzda da saklanan verilerin kopyaları olacaktır. Bu yaklaşım hassas bilgiler (ör. kredi kartı bilgileri) için uygun olmayabilir.
2- Direct Queries Between Microservices
Her bir mikro servis, ihtiyaç duyduğu veriler için diğer mikro servislere http requesti atar.
Bu, monolitic bir uygulama geçmişine sahip geliştiriciler için içgüdüsel bir seçimdir. Developerlar, local method çağrıları yerine remote çağrılar yaparlar(ör. REST).
Advantages:
- Live data. Return edilen datalar microservisin current statetidir.
Disadvantages:
- Tightly coupled. Veriyi almak istediğimiz micro servise sıkı bir şekilde bağlanmış oluruz.
- Dependencyler online olmalıdır. Bir mikro servisin offline olması diğer servislerin çökmesine neden olabilir.
- İhtiyacımızdan daha fazla veriyi almak. Sadece EntityNam alanına ihtiyacımız varken tüm entityi aldığımız durumlar yaygındır. Bu serialization/deserialization israfına yol açar
3-Composite Service Layer
Composite servis, low-level microservislerden dataları aggregate eder.
Advantages:
- Low level microservisler birbirine coupled değildir.
- Live data. Return edilen datalar microservisin current statetidir.
Disadvantages:
- Low level micro servislerde external dataya ihtiyaç duyarsa bu çözüm işe yaramaz.
- Composite servis kendi altındaki low level micro servislere tigth-coupled olacaktır. Servisler arası bağımlılığı composite servis üzerine taşımış olduk. Bu durumda composite servis dar boğaz sorunu oluşabilir.
- Dependencyler online olmalıdır. Bir mikro servisin offline olması diğer servislerin çökmesine neden olabilir.
- İhtiyacımızdan daha fazla veriyi almak. Sadece EntityNam alanına ihtiyacımız varken tüm entityi aldığımız durumlar yaygındır. Bu serialization/deserialization israfına yol açar.
- More difficult to debug requests
4- Joining data in the user interface
Bu yaklaşımda user interface (UI) ihtiyaç duyduğu tüm datalar için micro servis endpointlerine request atar.
5- Views between database schemas
Tamamen ayrı veritabanları yerine, her mikro servisin aynı veritabanında ayrı bir şeması vardır.
Disadvantages:
- The database is a single point of failure
How to request information from multiple microservices?
Front-end apisi Description, Relations, ve Prices apilerine subcribe olmuştur. O apilereden gönderilen eventlere göre kendi tablolarını update etmektedir. Front-end api dataları sadece bu eventlerle update edilmelidir.
Hiç yorum yok:
Yorum Gönder