Mikro Servisleri Nasıl Ana Sisteme Bağlayabiliriz?

Question

Selamlar,

Proje içerisi şöyle
abc
├── abc1
├── abc2
└── abc3
dce
├── dce1
├── dce2
└── dce3

Sistem bu formatda bunun gibi 5 farklı yapı daha bağlı. Ve abc ve dce birbirlerinden tamamen bağımsız servisler. Ama hepsi ana bir çatı altında topluyoruz.
Şuanda şöyle yapıyoruz abc 0123 portunu veriyoruz, dce'ye ise 0124 portunu veriyoruz bu sayede çıktı responseleri aynı formatda oluyor ve abc ve dce başarıyla güncellemesini yapıldığında ana panele güncelleme yapmaya gerek kalmıyor.Ama bu bizi rahatsız ediyor yani ne bileyim her port bir servis mantığı çok mantıklı gelmiyor,aklıma farklı bir çağrışım fikri de gelmedi.
Peki alt servislere güncelleme yapsak bile ana sisteme güncelleme yapmamıza gerek kalmayan farklı bir çalışma mantığı var mıdır?Varsa nedir?
Bir örnek ile açıklama şansınız var mıdır?
Teşekkürler.

zafersari82 · Answer

en kisa sürede kendi̇ne chatgpt al

PRIMEPANEL · Answer

Konu çok üstü kapalı olmuş hiç bir şey anlaşılmıyor.

ByCaner · Answer

Hocam tam olarak sorununuz ne tekrar anlatmayı deneyebilir misiniz? Portların olması mı sorun yoksa bir API gateway mi oluşturamadınız

_4uwp · Answer

aşağıda şöyle bir soru var:
...
bu soruya mono repo mantığını uygulayarak bir yanıt hazırlamanı istiyorum
ai'ye hazırlattığım yanıt:

Selamlar,
Anlattığınız yapı için Monorepo (tek depo) mimarisini, ortak modüller ve merkezi bir API geçidiyle birlikte kullanmayı değerlendirebilirsiniz.
Öncelikle önemli bir ayrım var: Monorepo, bütün servislerin aynı uygulama içerisinde çalışması demek değildir. Birbirinden tamamen bağımsız servisleri tek bir kaynak kod deposunda yönetmenizi sağlar. Her servis kendi içerisinde geliştirilebilir, test edilebilir ve diğer servislerden bağımsız olarak yayımlanabilir.
Örneğin mevcut projenizi şöyle düzenleyebilirsiniz:

Burada üç temel yaklaşım birlikte çalışıyor.
1. Monorepo: ABC, DCE ve diğer servisler aynı depoda bulunur ancak birbirlerinin iç işleyişine bağımlı olmak zorunda değildir. Örneğin ABC içerisindeki bir değişiklik yalnızca ABC'nin yeniden derlenmesini ve yayımlanmasını gerektirebilir. Nx gibi araçlarla hangi projelerin değişiklikten etkilendiğini belirleyip yalnızca ilgili projelerin testlerini ve dağıtım işlemlerini çalıştırabilirsiniz.
2. Ortak API sözleşmesi: packages/api-contracts altında servislerin ana sisteme hangi veri biçiminde yanıt vereceğini tanımlarsınız. Örneğin bütün servislerin döndürdüğü temel yanıt yapısı şu olabilir:
{  "success": true,  "data": {},  "error": null }
ABC içerisinde istediğiniz kadar değişiklik yapabilirsiniz. DCE tamamen farklı bir teknolojiyle de geliştirilebilir. Önemli olan ana sistemin kullandığı API sözleşmesinin korunmasıdır. Böylece servislerin iç işleyişindeki değişiklikler ana paneli etkilemez.
3. API Gateway: Ana panel bütün servislerle ayrı ayrı haberleşmek yerine tek bir giriş noktası kullanır.
Örneğin:
/api/abc/... → ABC servisi /api/dce/... → DCE servisi
ABC ve DCE arka planda farklı portlarda veya farklı sunucularda çalışmaya devam edebilir. Ancak ana panel bunların hangi portlarda çalıştığını bilmek zorunda değildir. Yönlendirmeyi API geçidi gerçekleştirir.
Burada önemli bir nokta var: Monorepo tek başına port ihtiyacını ortadan kaldırmaz. Portlar uygulamaların çalışma biçimiyle, Monorepo ise kaynak kodun düzenlenmesi ve geliştirme süreciyle ilgilidir. Birbirinden bağımsız çalışan HTTP servislerinin ayrı dinleme noktalarına sahip olması son derece normaldir.
Eğer amacınız gerçekten bütün modüllerin tek süreçte ve tek port üzerinden çalışmasıysa Monorepo içerisinde modüler monolit mimarisi de kurabilirsiniz. Böylece ABC ve DCE ayrı modüller olur ancak aynı uygulama içerisinde çalışırlar. Bunun karşılığında bağımsız dağıtım ve süreç yalıtımı gibi bazı avantajlardan vazgeçmiş olursunuz.
Son olarak, ana panelin hiç güncellenmemesi meselesini de ayırmak gerekiyor. Bir servisin iç işleyişi değişirken API sözleşmesi aynı kalıyorsa ana panelin güncellenmesi gerekmez. Fakat servise ana panelde gösterilmesi gereken yepyeni bir özellik ekleniyorsa panelin bunu nasıl sunacağını bilmesi gerekir. Bunun da otomatik olmasını istiyorsanız servislerin özelliklerini bildirdiği bir kayıt mekanizması ve bu tanımlardan arayüz üretebilen bir panel geliştirebilirsiniz.
Kısacası benim önerim: Bağımsız servis yapınızı koruyun, kaynak kodlarını Monorepo altında yönetin, ortak API sözleşmeleri oluşturun ve servislerin erişimini bir API Gateway üzerinden sağlayın. Böylelikle her servisi bağımsız geliştirmeye devam ederken ana panel ile servisler arasındaki bağımlılığı da mümkün olduğunca azaltmış olursunuz.
Bu yanıtın temel teknik ayrımı, Monorepo'nun kaynak kodu ve geliştirme süreçlerini düzenlemesi; API Gateway'in ise servisler arasındaki erişim mimarisini çözmesidir. Nx'in güncel belge yapısı ve API Gateway mimari örüntüsü bu ayrımı destekliyor.

dombalak · Answer

her proje kendine hastır ama modüller için port açmak ciddi bir hamallık olur.

modüller arası iletişim veya bir modeüle güncelleme/talimat vermek için artifact sistemi yeterli. modülle konuşacak bir .json dosyası yeter de artar bile.

ben tüm projelerimde yüzlerce mikro modülleri artifact ile iletişim sağlattırıyorum. her bir modül diğer modülleri bilmez asla. sadece kendisine gelen json dosyasını okur

TeknoWeb · Answer

hocam aslında aradığın şey servislerle panel arasında sabit bir sözleşme yani api. panel servislerin içini bilmeyecek sadece her servisin aynı formatta cevap verdiği birkaç endpoint bilecek mesela durum veri ve sağlık kontrolü gibi. servisin içinde ne değiştirirsen değiştir bu cevabın formatı aynı kaldığı sürece panele dokunman gerekmez. portları panele tek tek yazmak yerine önüne nginx ya da traefik gibi bir reverse proxy koyarsan panel tek adresle konuşur servisin portu değişse bile sadece proxy ayarı değişir. formatı bozan büyük bir değişiklik olursa eski sürümü v1 diye bırakıp yenisini v2 diye açarsın panel hazır olunca geçer. veri anlık değil de olay bazlıysa redis ya da rabbitmq ile servisler mesaj yayınlar panel dinler bu da bağımlılığı iyice azaltır

soylenmezsmt · Answer

TeknoWeb adlı üyeden alıntı:						mesajı görüntüle									hocam aslında aradığın şey servislerle panel arasında sabit bir sözleşme yani api. panel servislerin içini bilmeyecek sadece her servisin aynı formatta cevap verdiği birkaç endpoint bilecek mesela durum veri ve sağlık kontrolü gibi. servisin içinde ne değiştirirsen değiştir bu cevabın formatı aynı kaldığı sürece panele dokunman gerekmez. portları panele tek tek yazmak yerine önüne nginx ya da traefik gibi bir reverse proxy koyarsan panel tek adresle konuşur servisin portu değişse bile sadece proxy ayarı değişir. formatı bozan büyük bir değişiklik olursa eski sürümü v1 diye bırakıp yenisini v2 diye açarsın panel hazır olunca geçer. veri anlık değil de olay bazlıysa redis ya da rabbitmq ile servisler mesaj yayınlar panel dinler bu da bağımlılığı iyice azaltır 		Teşekkür ediyorum hocam

Jonezz · Answer

Hocam her servis için ayrı port kullanmak yerine Nginx veya API Gateway üzerinden yönlendirme yapabilirsiniz; servisler ortak bir API sözleşmesiyle çalışırsa alt servisleri güncellediğinizde ana sistemi değiştirmek zorunda kalmazsınız.

frozenruzgar · Answer

Hocam API Gateway + Service Discovery yapısını kullanabilirsiniz. Docker ve Traefik ile servisleri tek domain üzerinden (api.domain.com/abc, /dce) yönetebilirsiniz. Servisler bağımsız çalışır, güncellemelerde ana sisteme dokunmanız gerekmez. API formatını sabit tutmanız yeterli.