Birleştirilebilir mimari, tek bir büyük hepsi bir arada platform yerine, API'ler aracılığıyla birbirleriyle iletişim kuran bağımsız, birbirinin yerine geçebilen en iyi sınıf bileşenlerden yazılım sistemleri oluşturma yöntemidir. Başsız hareketin altında yatan daha geniş bir fikir olup, açık, birleştirilebilir kurumsal teknolojiyi teşvik eden satıcıdan bağımsız endüstri kuruluşu olan MACH Alliance ile yakından bağlantılıdır.
Önce hızlı bir ayrım
“Birleştirilebilir” kelimesi üç çok farklı yerde karşımıza çıkıyor. Kılavuzun geri kalanının anlamlı olması için şimdi bunları açıklığa kavuşturalım.
- Birleştirilebilir mimari (bu makale) bir yazılım tasarım yaklaşımıdır. Bir uygulamayı, her biri API'ler aracılığıyla entegre edilmiş ayrı iş bileşenlerinden oluşturursunuz.
- Birleştirilebilir altyapı bir donanım ve veri merkezi konseptidir. İşlem, depolama ve ağ iletişimi havuzlanır ve isteğe bağlı olarak iş yüklerine tahsis edilir. İşletim sisteminin altında yer alır, uygulama kodunuzda değil.
- DeFi birleştirilebilirliği, genellikle “para legoları” olarak adlandırılan bir blok zinciri fikridir. Borç verme ve takas protokolleri gibi akıllı sözleşmeler, yeni finansal ürünler oluşturmak için üst üste yığılır.
Aynı kök kelime, üç ilgisiz katman. Bundan böyle, “birleştirilebilir” yazılım mimarisi anlamını ifade edecektir.
Birleştirilebilir mimarinin gerçekte ne anlama geldiği
Birleştirilebilir bir sistem, her biri eksiksiz bir işlevine sahip modüler, kendi kendine yeten birimlerden oluşturulur. Her iş için en iyi aracı seçer, bunları API'ler aracılığıyla bağlar ve etrafındaki her şeyi yeniden inşa etmeden daha sonra herhangi birini değiştirebilirsiniz.
Birleştirme biriminin bir adı vardır: paketlenmiş iş yeteneği veya PBC. Gartner, PBC'leri kendi kendine yeten iş verileri, mantık ve süreçler içeren ve API'ler ve olay kanalları aracılığıyla diğer uygulamalarla etkileşime giren, bağımsız olarak dağıtılabilir yetenekler olarak tanımlar.
Bir PBC'yi kutu içinde bütün bir iş alanı olarak düşünün. Bir “ödeme” PBC'si ödeme yöntemlerini, dolandırıcılık kontrollerini, geri ödemeleri ve anlaşmazlıkları yönetir. Bir “arama” PBC'si indekslemeyi, sıralamayı ve sorgu işlemeyi yönetir. Her biri ham bir veritabanı tablosu değil, iş düzeyinde bir API sunar ve bunu bir satıcıdan temin edebilir veya kendiniz oluşturabilirsiniz. Ürününüzü, bir kitin parçalarını bir araya getirir gibi bu bloklardan oluşturursunuz.
Birleştirilebilir vs. Monolit
Bir monolit, her yeteneği paylaşılan bir veritabanına sahip tek bir dağıtılabilir uygulamada bir araya getirir. Başlangıçta basittir ve büyüdükçe değiştirmek zorlaşır. Birleştirilebilir mimari, bu yetenekleri birbirinden ayırır, böylece her biri kendi başına gelişebilir. Monolit ve mikro hizmetler arasındaki ayrımdan bahseden bir şey okuduysanız, birleştirilebilir, aynı değişimin iş yeteneği çerçevesidir: mikro hizmetler teknik bir ayrıştırma iken, PBC'ler iş alanı ayrıştırmasıdır.
Karşılaştırma bir bakışta:
| Boyut | Monolit | Birleştirilebilir mimari |
|---|---|---|
| Değişim birimi | Uygulamanın tamamı | Tek bir PBC |
| Veri | Tek paylaşılan veritabanı | Her yetenek kendi verisine sahiptir |
| Satıcı seçimi | Tek platform, hepsini al | Yetenek başına en iyi sınıf |
| Ön yüz | Arka uca bağlı | Ayrıştırılmış, herhangi sayıda kanal |
| Entegrasyon | Dahili fonksiyon çağrıları | API'ler ve olaylar |
| Satıcıya bağımlılık riski | Yüksek | Daha düşük, bileşenler değiştirilebilir |
Ödünleşme gerçektir. Birleştirilebilir, esneklik ve değiştirilebilirlik sağlar. Ayrıca entegre edilecek, izlenecek ve sözleşmede tutulacak daha fazla hareketli parça sunar.
MACH: Çoğu kişinin kastettiği standart
Ekipler “birleştirilebilir” dediğinde, genellikle MACH ilkelerini takip eden bir mimari yığını kastederler. MACH bir kısaltmadır ve MACH Alliance (2020'de kurulmuştur) bunu açık, birleştirilebilir sistemler için mimari olarak tanıtır.
- M, Mikro hizmetler. Yetenekler tek bir blok yerine küçük, bağımsız olarak dağıtılabilir hizmetler olarak oluşturulur.
- A, API-öncelikli. Her fonksiyon bir API aracılığıyla sunulur. Kullanıcı arayüzü, bu API'nin tek tüketicilerinden sadece biridir, tek giriş yolu değildir.
- C, Bulut-yerel. Bileşenler, elastik ölçeklendirme ve yönetilen hizmetler kullanılarak bulut için oluşturulur.
- H, Başsız. Ön yüz arka yüzden ayrılmıştır, böylece web, mobil, kiosklar veya başka herhangi bir şeye aynı API'lerden gönderebilirsiniz.
Birleştirilebilir, başsız ve MACH'ın eşanlamlı olmadığını unutmayın. Başsız, MACH'ın bir harfidir. MACH, birleştirilebilir sistemler inşa etmenin belirli, iddialı bir yoludur. Birleştirilebilir, hepsinin üzerindeki şemsiyedir.
API-öncelikli omurga
Bu konuların herhangi birini incelediğinizde aynı noktaya varırsınız: API, birleştirilebilir bir sistemi bir arada tutan entegrasyon katmanıdır. Bileşenler bağımsızsa ve her biri kendi verisine sahipse, onları birbirine bağlayan tek şey aralarındaki sözleşmedir.
Bu yüzden API-öncelikli geliştirme, vazgeçilmez bir temeldir. Bir monolit sistemde, iki modül aynı veritabanına erişebilir ve birbirlerinin fonksiyonlarını doğrudan çağırabilir. Birleştirilebilir bir sistemde bu kısayol ortadan kalkar. Bir yetenek, sunduğu API kadar kullanışlıdır ve bir sistem, parçaları arasındaki sözleşmeler kadar sağlamdır.
Bu aynı zamanda API'nin bir yan kapı olmaktan çıkıp ürünün kendisi haline geldiği andır. Ön yüz başsız olduğunda ve yetenekler değiştirilebilir olduğunda, API, diğer ekiplerinizin ve ortaklarınızın gerçekten tükettiği üründür. Dikkatsizce tasarlarsanız, her aşağı akış tüketicisi bunun etkisini hisseder.
Faydaları ve ödünleşmeleri
Kısaca birleştirilebilirliğin faydaları:
- En iyi sınıf. Bir satıcının en zayıf modülüne razı olmak yerine, her yetenek için en güçlü aracı kullanın.
- Bağımsız değişiklik. Bir PBC'yi geri kalanına dokunmadan değiştirin veya yükseltin.
- Daha az bağımlılık. Değiştirilebilir bileşenler, tek bir platforma bağlı olmadığınız anlamına gelir.
- Paralel ekipler. Ayrıştırılmış yetenekler, ekiplerin kendi programlarına göre yayın yapmasına olanak tanır.
- Çok kanallı. Başsız ön yüzler, bir dizi API'nin birçok yüzeye hizmet etmesini sağlar.
Ve dürüst maliyetler:
- Entegrasyon ek yükü. Daha fazla bileşen, kablolamak ve izlemek için daha fazla bağlantı anlamına gelir.
- Sözleşme disiplini. Bir API'deki kırıcı bir değişiklik, onu çağıran her şeyi etkileyebilir.
- Operasyonel karmaşıklık. İzleme, kimlik doğrulama ve sürümleme tek bir hizmeti değil, birçok hizmeti kapsar.
- Ön tasarım. Yayın yapmadan önce sınırlar ve sözleşmeler üzerinde daha fazla zaman harcarsınız.
Esneklik, ölçeklenebilirlik ve birden fazla kanala ihtiyacınız olduğunda birleştirilebilir güçlü bir çözümdür. İyi inşa edilmiş tek bir monolit yeterli olacakken aşırıya kaçmaktır.
Apidog'un yeri: API-öncelikli temel
Apidog mimarinizi birleştirilebilir yapmaz. Bir CMS, bir ticaret motoru, bir API ağ geçidi veya bir MACH platformu değildir ve bunların hiçbirini değiştirmeyecektir. Yaptığı şey, MACH'taki "A"yı, yani API-öncelikli temeli sahiplenmektir; bu da birleştirilebilir bir sistemdeki her şeyin bağlı olduğu katmandır.
API, bağımsız bileşenleriniz arasındaki tek arayüz olduğu için sözleşmenin doğru olması gerekir. Apidog, bu sözleşmeyi tasarladığınız, test ettiğiniz, taklit ettiğiniz ve belgelediğiniz yerdir:
- Önce tasarıma dayalı sözleşmeler. Her yeteneğin API'sini, kimse uygulamayı yazmadan önce bir OpenAPI sözleşmesi olarak tanımlayın, böylece tüketiciler ve sağlayıcılar şekil üzerinde önceden anlaşabilirler.
- Taklit sunucular. Ayrıştırılmış ekiplerin birbirini beklemesi gerekmemelidir. Bir taklit sunucu, arka plandaki PBC hala inşa edilirken bir ön yüz veya bir ortağın sözleşmeye göre geliştirme yapmasına olanak tanır.
- Başsız test yürütme. Apidog CLI, API testlerinizi GUI olmadan doğrudan CI'da çalıştırır. Bu, “başsız” kavramıyla gerçek bir uyum içindedir; testler bir ekran aracılığıyla değil, sözleşme üzerinde çalışır.
- Araçlarınızdan yönetin. MCP aracılığıyla, API projenizi bir yapay zeka aracısından veya IDE'den yönetebilirsiniz.
Sisteminiz API-üründür modelini takip ediyorsa, bu, sözleşmeleri dürüst tutan kalite katmanıdır. Arka uç mevcut olmadan önce bir sözleşme tasarlamak ve taklit etmek için Apidog'u indirin.
Birleştirilebilir mimariyi ne zaman benimsemeli
Bu durumlardan birden fazlası geçerliyse birleştirilebilir mimariye yönelin:
- Paylaşılan mantıktan birden fazla kanala (web, mobil, mağaza içi, sesli) hizmet vermeniz gerekiyorsa.
- Farklı yetenekler çok farklı hızlarda değişiyorsa ve küçük bir düzeltme için her şeyi yeniden dağıtmaktan sıkıldıysanız.
- Tek bir paket yerine yetenek başına en iyi sınıf satıcıları istiyorsanız.
- Satıcıya bağımlılık sizin için gerçek bir iş riski ise.
- Zamanla API sözleşmelerine ve entegrasyonuna sahip çıkacak ekibiniz ve disiplininiz varsa.
Sıkı bir zaman çizelgesinde tek bir ürün gönderen küçük bir ekipseniz, genellikle temiz bir monolit daha akıllıca bir seçimdir. Birleştirilebilir, karmaşıklığını ölçekte kazanır.
Sıkça sorulan sorular
Birleştirilebilir mimari mikro hizmetlerle aynı mı?
Hayır, ancak örtüşüyorlar. Mikro hizmetler, bir sistemi küçük, dağıtılabilir hizmetlere ayırmanın teknik bir yoludur. Birleştirilebilir mimari, iş yetenekleri (PBC'ler) boyunca ayrışır ve API'ler aracılığıyla bağlanan en iyi sınıf, değiştirilebilir bileşenler fikrini ekler. Mikro hizmetler genellikle birleştirilebilir bir sistemin arka ucunu oluşturma şeklinizdir. Daha geniş ayrım için, monolit ve mikro hizmetler karşılaştırmasına bakın.
Birleştirilebilir ve başsız arasındaki fark nedir?
Başsız demek, ön yüzün arka yüzden ayrıldığı ve böylece herhangi bir istemcinin aynı API'leri tüketebileceği anlamına gelir. Birleştirilebilir, daha geniş bir yaklaşımdır: bağımsız, API bağlantılı yeteneklerden tüm bir sistemi bir araya getirmektir. Başsız, birleştirilebilir sistemlerin takip etme eğiliminde olduğu bir prensiptir (MACH'taki “H”). Yığın genelinde tamamen birleştirilebilir olmadan, tek bir yetenekte başsız olabilirsiniz.
Paketlenmiş iş yeteneği (PBC) nedir?
Bir PBC, verileri, mantığı ve API'leri dahil olmak üzere eksiksiz bir iş işlevine sahip, kendi kendine yeten bir birimdir. Gartner, PBC'leri API'ler ve olay kanalları aracılığıyla diğer uygulamalarla etkileşime giren, bağımsız olarak dağıtılabilir yetenekler olarak tanımlar. Her biri iş düzeyinde bir API sunan bir “arama”, “ödeme” veya “envanter” bileşeni, tipik bir PBC'dir.
Birleştirilebilir olmak için bir API platformuna ihtiyacım var mı?
API sözleşmelerinizi tasarlamak, test etmek ve kararlı tutmak için bir yola ihtiyacınız var, çünkü bu sözleşmeler bağımsız bileşenleri bir arada tutan tek şeydir. Bu, ayrı araçlar kümesi veya tasarım, taklit, test ve belgeleri tek bir yerde kapsayan tek bir platform olabilir. Önemli olan sözleşme disiplinidir, tek bir ürün değil.
Özetle
Birleştirilebilir mimari cinstir ve başsız, MACH ve mikro hizmetler onun içindeki türlerdir. Ana fikir basittir: bağımsız yetenekler, en iyi sınıf seçim ve bağ dokusu olarak API'ler. Riskin çoğu bu son kısımda yatar, çünkü sözleşme sistemin kendisidir. Apidog gibi bir araçla API tasarımını, taklitini, testini ve belgelerini doğru yapın, böylece birleştirilebilir vaadin geri kalanı (değiştirilebilir, çok kanallı, satıcıya bağımlılıksız) sağlam bir zemine sahip olur.
