# Shoprocket'ın mikroservislere yolculuğu, 1. bölüm: monoliti parçalamak konusunda neyi yanlış anladım

> Shoprocket'ın ilk yıllarından bir mühendislik ekibi yazısı: bir PHP monolitinden ilk servisi ayırma denemesi. Neden yanlış ilk servisi seçtim, sıkı bağlılık bana ne öğretti ve çok daha önce dinlemem gereken Newman tavsiyesi.

Winston Berty  - 17 Mart 2016 - 5 dk okuma

Shoprocket'taki işimin birkaç ay sonrasında hayal kırıklığına uğramaya başlamıştım. Dünyanın dört bir yanına dağılmış, küçük bir keskin geliştirici ekibinin üzerinde çalıştığı bir PHP uygulamamız vardı ve bana göre hata düzeltmeleri yeni hatalar doğuruyordu, yeni özellikleri entegre etmek olması gerektiği kadar basit değildi ve dağıtımlar seyrek ve stresliydi. Sebep: yüksek derecede bağlı kod.

Neredeyse tamamı tek bir GitHub deposunda duran monolitik bir uygulamamız vardı. Bir özellikte yapılan güncelleme ya da düzeltme çoğu zaman birkaç yerde değişiklik gerektiriyordu. Test için, bir dalın master'a birleşip dağıtılmadan önce en az iki geliştiricinin onaylaması gereken bir akran inceleme sürecimiz vardı. Bütün bunlar, bir hata sızdığında bozan değişikliği bulmanın çoğu zaman zor olduğu anlamına geliyordu. Bulduğumuzda düzeltme aynı süreçten geçiyordu ve bütün uygulamanın yeniden dağıtılması gerekiyordu.

Sürekli yeni bir şey arayan hevesli genç bir geliştirici olarak mikroservislerle karşılaştığımda bunun tüm sorunlarımızı çözeceğini düşündüm.

## Mikroservislerin ne olduğunu sandığım şey

Mikroservislerin resmi bir tanımı yok, ama araştırmamdan çıkardığım şu: mikroservis mimarisi, yazılım uygulamalarını her biri yüksek derecede uzmanlaşmış ve kendi yaşam döngüsüne sahip bağımsız servislerden oluşan dağıtık sistemler olarak tasarlama yöntemidir. Ayrıntılı bir giriş için Martin Fowler'ın [makalesi](https://martinfowler.com/articles/microservices.html) mükemmel.

Beni iki unsur kendine bağladı. Birincisi, uygulamayı katı sınırlara sahip servislere bölme fikri. Bu, bir iş bağlamına özgü mantığın bileşenler arasında sızma olasılığını düşürür, çünkü sınırlar arasındaki arayüzlerin dikkatle planlanması gerekir. Yerel fonksiyon çağrıları yapmak kadar basit değildir. İkincisi, her bileşenin kendi bağımsız yaşam döngüsüne sahip olabilmesi. Ekipler kodlarının sahibi olabilir ve servise en uygun yığını kullanabilir, değişiklikler tek seferde bir servis olarak dağıtılabilir ve geri alınabilir, geri kalanı etkilenmez.

İkna olmuştum. Shoprocket monoliti parçalayacaktı. Bu, yolculuğu anlatan kısa bir serinin 1. bölümü. Umudum, benzer bir geçişi planlayan ya da yaşayan okuyucuların başarılarımızdan ve başarısızlıklarımızdan öğrenmesi.

## İlk zorluk teknik değil, insanla ilgiliydi

Fikri ekibin geri kalanına satmam gerekiyordu. Meraklıydılar ama heyecanımı paylaşmıyorlardı ve ürünün bu erken döneminde geliştirme saatlerinden vazgeçmek istemiyorlardı. Neyse ki CTO oturum yönetimimize bakmamı istiyordu, ben de fırsatı yakaladım: onu bir oturum servisini ayırabileceğime ikna ettim.

Geriye dönüp bakınca bu, ilk servis için kötü bir seçimdi. Ürünümüz, [herhangi bir web sitesinde e-ticareti mümkün kılan](https://v3.shoprocket.io/tr/ozellikler/her-web-sitesinde-satis.md) bir JavaScript eklentisi içeriyor. Oturumları bir kaynak olarak ele alıyoruz, sepet terk oranını ve diğer KPI'ları analiz etmek için oturum bilgilerini veritabanına kaydediyoruz. Ama bu kaynak, siparişler ya da sipariş kalemleri gibi şeyler kadar somut değil ve uygulama durumundaki neredeyse her değişiklikte oturumları kullanıyorduk. Bu, servisin uygulamanın geri kalanıyla kaçınılmaz olarak gevezelik edeceği anlamına geliyordu; bunu öngörmemiştim ve işimi zorlaştırdı.

## Gerçekten inşa ederken öğrendiklerim

Araştırmamı hızlandırdım. Fowler'ın yanında Sam Newman'ın **Building Microservices** kitabı vazgeçilmez bir kaynak oldu.

Newman'ın tavsiyesi, geriye dönüp bakınca, izlemem gereken tavsiyeydi: önce mevcut uygulamayı alanın sınırlı bağlamlarını (bounded context) yansıtan modüllere yeniden yapılandırın. Geliştiriciler sınırlardan memnun olduğunda *sonra* modülleri kendi servislerine ayırın. Nedeni, kötü sınırlara sahip modülleri parçalayıp yeniden yazmanın, tüm ek tesisat kodu ve kalıcı kaynaklarıyla birlikte tüm servisleri parçalayıp yeniden yazmaktan çok daha kolay olması.

O tavsiyeyi izlemedim. Kendi bileşenimi yapmaya hevesli olarak oturum servisiyle ilerledim.

Monolitinkinden yalnızca biraz farklı bir yığın seçtim ve inşa etmeye başladım. Servisin kendisi hızla bir araya geldi, REST API'li bağımsız bir uygulama üretmek birkaç hafta sürdü. Zor olan orası değildi. Zor olan, servisi monolitle konuşturmaktı.

Oturum yönetimi kod tabanının geri kalanına sıkı biçimde bağlı çıktı. Fonksiyon çağrılarını API çağrılarıyla değiştirmek yavaş bir işti. Oturum servisi ve monolit ayrı veritabanı şemalarına sahip olduğundan, monolitte eski veritabanından oturum kaynaklarını kullanan her mantığı yeniden yazmam gerekti; JavaScript eklentimiz gibi istemcilerle uyumu korumak için veriyi uygulama sınırında yeniden yapılandırdım.

Entegrasyon, inşa etmekten daha uzun sürdü. Ve bu hâlâ mikroservislerin normalde getirdiği ek yükün çoğunu içermiyordu: servis keşfi, loglama, izleme, dağıtık takip. Daha kötüsü, sıkı bağlılık değişikliklerin kodun birçok alanına yayılması anlamına geliyordu. Ekip o süre boyunca paralel çalıştığı için birleştirme ve oturum servisini üretime almak, tahmin ettiğimden çok daha fazla koordinasyon gerektirecekti.

## Dürüst değerlendirme

Servis yakında üretime girebilir. Ama şimdi Newman'ın tavsiyesini izleyip önce mevcut uygulamayı modülerleştirmeye çaba harcamam gerektiğini hissediyorum. Tek bir servisin kendi başına yaşamasının faydası marjinal. Gerçek fayda, her şeyi parçalamaktan, en azından birbirleriyle olabildiğince az gevezelik eden iri taneli servislere bölmekten gelir. Bu, iyi düşünülmüş bileşen sınırları gerektirir ve biz henüz orada değildik.

Fikir olarak hâlâ mikroservislere ikna olmuş durumdayım. Denememi yararlı bir deney olarak görüyorum. Uygulama mimarisi, alan modelleme ve REST ilkeleri hakkında çok şey öğrendim ve bu dersler kodumuzun diğer bölümlerinde zincirleme etkiler yarattı.

Benzer bir geçişi düşünen herkes için dürüst önerilerim:

- Karar vermeden önce konu hakkında olabildiğince çok okuyun
- Mevcut kod tabanınız ve alan modelinizle gerçekten rahat olana kadar işi erteleyin
- Bir monolite kararlılık ve dayanıklılık kazandırmanın başka yolları da var. Otomatik birim ve işlevsel testler çok yardımcı olur. Test güdümlü geliştirme gerilemeleri azaltır. Yatay ölçekleme dağıtımları daha az acı verici kılar
- Servisleri çıkarmadan önce monolitinizi modülerleştirerek başlayın

Shoprocket yolculuğuna devam edecek. İşler 2. bölümde daha ilginç hale geliyor.

---

*Shoprocket'ın bir PHP monolitinden erken göçünü belgeleyen kısa bir serinin ilki olarak yayımlanmıştı. Sonraki iterasyonlarda düzeltilen hatalar da dahil olmak üzere tüm yolculuk, o zamandan beri platformun her büyük yeniden yazımı boyunca sürdü.*

---

- HTML version: https://v3.shoprocket.io/tr/blog/shoprocket-mikroservis-yolculugu-1-monoliti-parcalarken-yanlis-yaptiklarim
- Language: Türkçe (tr)
- Also in: [العربية](https://v3.shoprocket.io/ar/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Deutsch](https://v3.shoprocket.io/de/blog/shoprocket-microservices-teil-1-monolith-zerlegen-fehler.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [English](https://v3.shoprocket.io/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Español](https://v3.shoprocket.io/es/blog/shoprocket-microservicios-parte-1-lo-que-hice-mal-monolito.md), [Français](https://v3.shoprocket.io/fr/blog/shoprocket-vers-les-microservices-partie-1-decouper-le-monolithe.md), [עברית](https://v3.shoprocket.io/he/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [हिन्दी](https://v3.shoprocket.io/hi/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Bahasa Indonesia](https://v3.shoprocket.io/id/blog/perjalanan-shoprocket-menuju-microservices-bagian-1-salah-memecah-monolit.md), [Italiano](https://v3.shoprocket.io/it/blog/viaggio-di-shoprocket-verso-i-microservizi-parte-1-cosa-ho-sbagliato-sul-monolite.md), [日本語](https://v3.shoprocket.io/ja/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Lietuvių](https://v3.shoprocket.io/lt/tinklarastis/shoprocket-kelione-i-mikropaslaugas-1-dalis.md), [Norsk](https://v3.shoprocket.io/nb/blogg/shoprockets-vei-mot-mikrotjenester-del-1-hva-jeg-tok-feil-av.md), [Nederlands](https://v3.shoprocket.io/nl/blog/shoprocket-microservices-deel-1-monoliet-opknippen.md), [Polski](https://v3.shoprocket.io/pl/blog/droga-shoprocket-do-mikroserwisow-czesc-1-rozbijanie-monolitu.md), [Português](https://v3.shoprocket.io/pt/blog/jornada-do-shoprocket-para-microsservicos-parte-1-o-que-errei-ao-quebrar-o-monolito.md), [Română](https://v3.shoprocket.io/ro/blog/drumul-shoprocket-spre-microservicii-partea-1-ce-am-gresit-cu-monolitul.md), [Русский](https://v3.shoprocket.io/ru/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [ไทย](https://v3.shoprocket.io/th/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [中文](https://v3.shoprocket.io/zh/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md)