Yeni bir yazılım projesinin planlama aşamasındaysanız, monolitik bir sistemi daha küçük alt sistemlere ayırmaya çalışıyorsanız veya sadece micro services hakkında bir şey öğrenmek istiyorsanız doğru yere geldiniz.

Micro Services nedir ve neden kullanayım?

Bir micro services mimarisi, farklı görevleri genellikle tek bir yerden birden çok services’e dağıtır. Ama neden monolitik bir mimari yerine services’leri kullanalım ?

Micro services kullanmak zorunda değilsiniz. Küçük ve bazı orta ölçekli projeler için bu, aşırı mühendislik olarak kabul edilebilir. Aşağıdaki şekil, micro services ve monolitlerin üretkenlik ve karmaşıklıkla nasıl ilişkili olduğunu göstermektedir:

Düşük karmaşıklığa sahip sistemler, micro services mimarisinden faydalanmaz

Genel olarak, micro services işlevselliği, monolitik mimari yaklaşımına göre çeşitli avantajlara sahiptir:

1. Esneklik : Bir micro services bağımsız olarak dağıtılabildiğinden teslimat süresi uzatmaları önemli ölçüde azalır open-closed principle izlediğinizi varsayarsak bu büyük bir karmaşıklığı azaltır.
2. Hızlı geliştirme: Loose connection nedeniyle componentler bağımsız olarak uygulanabilir, test edilebilir ve dağıtılabilir, böylece planlamadan üretime kadar geçen toplam süre kısalır.
3. Bağımsızlık : Her bir micro services için tamamen farklı teknolojilere karar vermek mümkündür.
4. Maliyet azaltma : Tasarım, uygulama ve bakım aşamaları genellikle basit, hızlı ve ucuzdur. Tek bir ekip, tek bir micro services çalıştırabileceğinden, services hakkında derinlemesine bilgi sahibi olması gereken kişi sayısı azalır.
5. Esneklik : Bir micro services’in hatalı olması tüm serv ağının kesintiye uğramasına neden olmaz.
6. Katı modül sınırları : Özel bir görevden bir micro services sorumludur. Ve evet, erkenden ele alınması gereken zorluklar var:
7. Bakım karmaşıklığı : Tek bir micro services tek başına hızlı ve kolay bir şekilde dağıtılırken, birden fazla services’e sahip olmak, yüksek bakım çabasına neden olabilecek karmaşık bir altyapı oluşturur.
8. Sistem karmaşıklığı : Micro services mimarisine dayalı bir sistem, gecikme, aktarım hızı, hata işleme ve izleme gibi farklı zorluklar getiren dağıtılmış bir sistemdir. Ekibiniz, ek karmaşıklığı yönetmek için gerekli beceri setini getirmelidir.
9. Dağıtılmış monolit : Sistemi tam olarak doğru component’lere doğru bir şekilde uygulamak zor bir görev olabilir: Micro services arasında birçok bağımlılık varsa, temel olarak, muhtemelen daha önce listelenen avantajlardan yoksun olan aşırı karmaşık bir micro service oluşturdunuz.

Micro Services Tasarım Modelleri

Micro services mimarileri diğer diğer mimarileri arasındaki bariz farklar, seçilen teknoloji ve entegrasyon stilleridir. JSON web service’i ile REST’e dayalı birçok mikro services vardır, bu nedenle birçok geliştirici bunun bir mikro service oluşturmanın tek yolu olduğunu düşünür. Aslında, sadece farklı yaklaşımlar değil, aynı zamanda, özellikle bir çağrı yolunda çok sayıda services varsa, senkronize iletişimin bir anti-kalıp olduğu düşünülür. Popüler asenkron protokoller, AMQP (Advanced Message Queuing Protocol) veya Apache Kafka olacaktır. Öte yandan, HTTP tabanlı iletişim, mesajlaşma kuyruğundaki emsallerinden daha fazla aktarım hızı sunar ve daha düşük kaynak gereksinimlerine sahiptir.

Bununla birlikte, özellikle birden fazla protokole sahip olabileceğiniz için, yalnızca iletişim protokolünü seçmekten çok daha fazlası var. Örneğin başka bir konu, sistemin mimarisini etkileyen kesişen endişelerdir. Dikkate alınması gereken bir diğer husus, genellikle bir micro services ortamında çok büyük bir konu olan depolamadır. Services için veritabanlarının gerekli olduğunu varsayarsak, aşağıda özetlediğim iki seçenek var.

Services başına veritabanı

Her micro services, şemalar ve tablolar dahil olmak üzere kendi veritabanına sahiptir ve bundan sorumludur. Ayrıca, her service yalnızca sahip olunan depolara erişebilir.

Veritabanları services’ler arasında paylaşılmaz

Services’ten sorumlu ekip, ideal olarak ihtiyaçlara ve bilgilerine en uygun veritabanını seçmelidir. Bireysel düzeyde, veri tabanının karmaşıklığı düşüktür, nispeten az veri olmalıdır ve anlaşılması kolaydır.

Paylaşılan veritabanı

Paylaşılan bir veritabanı loose connection’nı ihlal ediyor

Paylaşılan veritabanı yaklaşımı olan bir micro services bir veritabanını paylaşıyorlarsa gerçekten bağımsız olmadıklarından sık kullanılmaz. Kesinlikle ölçeklenebilirlikten ödün veriyorlar. Ancak, sistem bir monolit olarak başlar ve yıllar süren operasyondan sonra bir micro services mimarisine dönüşürse ne olur? Ortaya çıkan bir problem, verilerin bu kadar kolay bölümlere ayrılamamasıdır. Kendinizi benzer bir durumda bulursanız, müşteriniz bir noktada eski yazılımı bitirip ve yalnızca yeni micro services’ler ile çalışmak istiyorsa, o zaman services başına veritabanı yaklaşımına geçebilirsiniz .

API Gateway

Bir API Gateway arasında bir katman uyguladığı için önceki sorunu da çözebilir. Ve bu gönderiye göre , eski uygulama kodunu kademeli olarak değiştirmek için kullanılabilir. Bununla birlikte, bu reverse proxy’nin arkasındaki asıl amaçlar :

• Micro services, doğrudan “halka” maruz bırakılmamalıdır, çünkü bunların her biri gelişmiş güvenlik ister ve kötüye kullanımın önlenmesini gerektirir. Client ve services’lerin arasında bir reverse proxy varsa, yetkilendirme ve aktarım şifrelemesi ( TSL ) gibi sorunların yalnızca bir kez ele alınması gerekiyor.
• Logları kaydetme, hata kontrolü, önbelleğe alma veya exception işleme gibi diğer konular, büyük parçalar halinde API gateaway’2 taşınabilir.
• Client/caller uygulamaları doğrudan belirli micro services’lere bağlıysa, birleştirilirler, bu da ölçeklenebilirlik ve esneklik açısından kötüdür.

Micro service bir reverse proxy’nin arkasına gizleyin

Bu bir API Gateaway’nin hatalarını tamamen çözmez, ancak büyük bir bölümünü çözebilir. Micro services’iniz muhtemelen log dosyaları yazmaya devam edecek, yine de yetkilendirme mantığı içerebilir ve kesinlikle kendi exception işlemesine sahip olacaktır. Ancak, belirli iş kapasitesi için gerekli olana geçirilebilir.