Açık Kaynak Tanımı ile Özgür Yazılım Tanımı Karşılaştırma

Açık Kaynak Tanımı ile Karşılaştırma

Özgür yazılım hareketi ve açık kaynaklı yazılım hareketi arasındaki felsefi farklılıklara rağmen, FSF tarafından ücretsiz yazılım ve OSI tarafından açık kaynaklı yazılımın resmi tanımları, birkaç küçük istisna dışında, temelde aynı yazılım lisanslarına atıfta bulunur. . Özgür Yazılım Vakfı, felsefi farklılıkları vurgularken şu yorumu yapıyor:

"Açık kaynaklı" yazılım terimi, bazı kişiler tarafından özgür yazılımla aşağı yukarı aynı kategoriyi ifade etmek için kullanılır. Tam olarak aynı yazılım sınıfı değildir: çok kısıtlayıcı olduğunu düşündüğümüz bazı lisansları kabul ederler ve kabul etmedikleri özgür yazılım lisansları vardır. Ancak, kategorinin genişletilmesindeki farklılıklar küçüktür: neredeyse tüm özgür yazılımlar açık kaynaklıdır ve neredeyse tüm açık kaynaklı yazılımlar özgürdür.

— Özgür Yazılım Vakfı

Özgür Yazılımın Dört Temel Özgürlüğü - wikipedia.org ÇEVİRSİ

 Özgür Yazılımın Dört Temel Özgürlüğü

FSF tarafından Şubat 1986'da yayınlanan tanımda iki nokta vardı:

Adımızdaki "FREE" kelimesi fiyat anlamına gelmez; özgürlüğe atıfta bulunur. Birincisi, bir programı kopyalama ve komşularınıza yeniden dağıtma özgürlüğü, böylece onlar da sizin kadar iyi kullanabilirler. İkincisi, programın sizi kontrol etmesi yerine sizin kontrol edebilmeniz için bir programı değiştirme özgürlüğü; bunun için kaynak kodun size sunulması gerekir.

1996'da, gnu.org web sitesi başlatıldığında, "özgür yazılım", yazılımı inceleme özgürlüğünden (iki noktalı tanımda şu şekilde okunabilir) açık bir söz eklenerek "üç özgürlük düzeyine" atıfta bulunularak tanımlandı. Stallman daha sonra "seviye" kelimesinden kaçınarak tüm özgürlüklerin gerekli olduğunu, dolayısıyla seviyeler açısından düşünmenin yanıltıcı olduğunu söyledi.

Son olarak, kullanıcıların programı çalıştırabilmesi gerektiğini açıkça söylemek için başka bir özgürlük eklendi. Mevcut özgürlükler zaten birden üçe numaralandırılmıştı, ancak bu özgürlük diğerlerinden önce gelmeliydi, bu yüzden "özgürlük sıfır" olarak eklendi.

Modern tanım, özgür yazılımı, alıcının aşağıdaki dört özgürlüğe sahip olup olmadığına göre tanımlar:

Programı istediğiniz gibi, herhangi bir amaç için çalıştırma özgürlüğü (özgürlük 0).

Programın nasıl çalıştığını inceleme ve bilgisayarınızı istediğiniz gibi yapması için değiştirme özgürlüğü (özgürlük 1). Kaynak koduna erişim bunun için bir ön koşuldur.

Komşunuza yardım edebilmeniz için kopyaları yeniden dağıtma özgürlüğü (özgürlük 2).

Değiştirilmiş sürümlerinizin kopyalarını başkalarına dağıtma özgürlüğü (özgürlük 3). Bunu yaparak, tüm topluluğa değişikliklerinizden yararlanma şansı verebilirsiniz. Kaynak koduna erişim bunun için bir ön koşuldur.

Richard Stallman tarafından yazılan ve Özgür Yazılım Vakfı (FSF) tarafından yayınlanan Özgür Yazılım Tanımı, özgür yazılımı, son kullanıcıların bu yazılımı kullanma, inceleme, paylaşma ve değiştirme özgürlüğüne sahip olmasını sağlayan yazılım olarak tanımlar. "Özgür" terimi, "ücretsiz" değil, "özgür konuşma" anlamında kullanılır. Tanımın bilinen en eski yayını, FSF tarafından artık durdurulan GNU's Bulletin yayınının Şubat 1986 baskısındaydı. Belgenin kanonik kaynağı, GNU Projesi web sitesinin felsefe bölümündedir. Nisan 2008 itibariyle burada 39 dilde yayınlanmaktadır. FSF, bu tanıma uyan lisansların bir listesini yayınlar.

Açık Kaynak Tanımı (The Open Source Definition) - opensource.org çevirisi

 Açık Kaynak Tanımı

Tanıtım

Açık kaynak sadece kaynak koduna erişim anlamına gelmez. Açık kaynaklı yazılımın dağıtım koşulları aşağıdaki kriterlere uygun olmalıdır:

1. Ücretsiz Yeniden Dağıtım

Lisans, herhangi bir tarafı, yazılımı birkaç farklı kaynaktan programları içeren toplu bir yazılım dağıtımının bir bileşeni olarak satmasını veya başka birine vermesini kısıtlamaz. Lisans, bu tür bir satış için telif hakkı veya başka bir ücret gerektirmez.

2. Kaynak Kodu

Program kaynak kodu içermeli ve kaynak kodun yanı sıra derlenmiş formda dağıtıma izin vermelidir. Bir ürünün herhangi bir biçiminin kaynak koduyla dağıtılmadığı durumlarda, kaynak kodunu makul bir çoğaltma maliyetinden fazla olmayan, tercihen İnternet üzerinden ücretsiz olarak indirerek elde etmenin iyi tanıtılmış bir yolu olmalıdır. Kaynak kodu, bir programcının programı değiştireceği tercih edilen form olmalıdır. Kasıtlı olarak karıştırılmış kaynak koduna izin verilmez. Bir önişlemcinin veya çevirmenin çıktısı gibi ara formlara izin verilmez.

3. Türetilmiş İşler

Lisans, değişikliklere ve türetilmiş çalışmalara izin vermeli ve bunların orijinal yazılımın lisansı ile aynı koşullar altında dağıtılmasına izin vermelidir.

4. Yazarın Kaynak Kodunun Bütünlüğü

Lisans, kaynak kodunun değiştirilmiş biçimde dağıtılmasını ancak lisans, "yama dosyalarının" kaynak kodla birlikte, derleme sırasında programı değiştirmek amacıyla dağıtılmasına izin veriyorsa kısıtlayabilir. Lisans, değiştirilmiş kaynak koddan oluşturulan yazılımın dağıtımına açıkça izin vermelidir. Lisans, türetilmiş çalışmaların orijinal yazılımdan farklı bir ad veya sürüm numarası taşımasını gerektirebilir.

5. Kişi ve Gruplara Karşı Ayrımcılık Yapılmaması

Lisans, herhangi bir kişi veya kişi grubuna karşı ayrımcılık yapmamalıdır.

6. Çalışma Alanlarına Karşı Ayrımcılık Yapılmaması

Lisans, hiç kimsenin programı belirli bir çalışma alanında kullanmasını kısıtlamamalıdır. Örneğin, programın bir işletmede kullanılmasını veya genetik araştırmalar için kullanılmasını kısıtlayamaz.

7. Lisansın Dağılımı

Programa bağlı haklar, bu taraflarca ek bir lisans yürütülmesine gerek kalmadan programın yeniden dağıtıldığı herkese uygulanmalıdır.

8. Lisans Bir Ürüne Özel Olmamalıdır

Programa eklenen haklar, programın belirli bir yazılım dağıtımının parçası olmasına bağlı olmamalıdır. Program bu dağıtımdan çıkarılırsa ve programın lisans koşulları dahilinde kullanılır veya dağıtılırsa, programın yeniden dağıtıldığı tüm taraflar, orijinal yazılım dağıtımıyla bağlantılı olarak verilenlerle aynı haklara sahip olmalıdır.

9. Lisans Diğer Yazılımları Kısıtlamamalıdır

Lisans, lisanslı yazılımla birlikte dağıtılan diğer yazılımlara kısıtlama getirmemelidir. Örneğin, lisans aynı ortamda dağıtılan diğer tüm programların açık kaynaklı yazılım olması konusunda ısrar etmemelidir.

10. Lisans Teknolojiden Tarafsız Olmalıdır

Lisansın hiçbir hükmü, herhangi bir bireysel teknolojiye veya arayüz stiline dayandırılamaz.

Softtech 2021 Teknoloji Raporu

 

PDF olarak buradan indirebilirsiniz.

Siteyi buradan ziyaret edebilirsiniz.

Java Object Sınıfı ve Metodları - wikibooks.org çevirisi

 

Java Programming/API/java.lang.Object

java.lang.Object

Object sınıfı, tüm Java sınıflarının üst sınıfıdır. Bu sınıftan tüm Java sınıfları miras alınır. Bu, tüm Java sınıflarında mevcut olan metodlara sahip olmamızı mümkün kılar. Bu, durumun söz konusu olmadığı 

C ++ ile karşılaştırıldığında işleri basitleştirir.

Object sınıfı metodları ve açıklamaları

boolean equals( Object o ); :  Nesneleri karşılaştırmak için genel bir yol sağlar

Class getClass();             :  Class sınıfı bize nesne hakkında daha fazla bilgi verir

int hashCode();                  :  Bir koleksiyondaki nesneleri aramak için kullanılan bir hash değeri döndürür

void notify();                      :  synchronizing thread'lerde kullanılır

void notifyAll();                 :  synchronizing thread'lerde kullanılır

String toString();                :  Nesneyi String'e dönüştürmek için kullanılabilir

void wait();                         :  synchronizing thread'lerde kullanılır

protected Object clone() throws CloneNotSupportedException ; : Mevcut nesneyle tamamen aynı olan yeni bir nesne döndür.

protected void finalize() throws Throwable; : Bu metod garbage collection nesneyi toplamadan hemen önce çalışır.

equals() Metodu

Boolean equals (Object o) yöntemi, nesneleri eşitlik açısından karşılaştırmak için genel bir yol sağlar. Sınıfınızda onu override etmeniz gerekir. O zaman şu şekilde yazabilirsiniz:

  public boolean isCustomerExist( Customer newCustomer )
{
   boolean isRet = false;
   Iterator iter = _collAllCustomer.iterator();
   while ( iter.hasNext() )
   {
      if ( newCustomer.equals( (Customer) iter.next() )
      {
         // -- Customer was found ---
         isRet = true;
      }
   }
  return isRet;
}
  

equals() öğesini geçersiz kıldığınızda, her zaman hashCode() öğesini de geçersiz kılmanız gerektiğini unutmayın, böylece iki yöntem tutarlı olur. İki nesne eşitse, aynı hashcode'a sahip olmaları gerekir.

hashCode() Metodu

Çoğu durumda, bu yöntemin varsayılan uygulaması nesne için benzersiz bir sayı döndürdüğünden, bu yöntemi geçersiz kılmamalısınız. Sayı, nesne bir koleksiyona konulduğunda kullanılır. Büyük bir koleksiyonda bir nesneyi bulmak, nesneler tek tek sırayla karşılaştırılırsa biraz zaman alabilir. Aramayı hızlandırmak için, nesneler bir tamsayı karma kod ile ağırlıklandırılan bir ağaç yapısına yerleştirilebilir. Ağaçta gezinirken karma kodu karşılaştırarak, nesne karşılaştırma sayısı azaltılabilir.

   _______ A _____
   |              |  
__ B__          __C__
|     |        |     |
D     E        F     G
...  ...      ...   ...

Size nasıl çalıştığı hakkında genel bir fikir vermek için yukarıdaki şemaya bakın. G nesnesini aradığımızı varsayalım. Ağacın her bir 'düğümünde' hangi yöne gideceğimize karar verebilirsek, 3 adımda G nesnesine ulaşırız.

Doğrusal bir aramada yorumla:

A --- B  ----- C  ---- C  ---- D  ---- E ---- F ---- G

G nesnesine ulaşmak için 8 adıma ihtiyacımız var.

Böylece ağaç yapısı ile arama daha hızlı olacaktır. Ancak yeni bir nesne eklemek daha yavaş olacaktır çünkü ağaç yapısının korunması gerekir. Yeni nesnenin ağaçtaki yeri ilk önce bulunmalıdır.

getClass() Metodu

Programınızdaki her sınıf için bir Class nesnesi vardır. Her dizi, aynı öğe türüne ve boyut sayısına sahip tüm diziler tarafından paylaşılan bir Class nesnesi olarak yansıtılan bir sınıfa da aittir. İlkel Java türleri (boolean, byte, char, short, int, long, float ve double) ve void anahtar sözcüğü de Class nesneleri olarak temsil edilir. Class'ın genel kurucusu yoktur. Bunun yerine Class nesneleri, sınıflar yüklenirken Java Sanal Makinesi tarafından otomatik olarak oluşturulur.

Class'ın en popüler kullanımı, çalışma zamanı sırasında nesnenin sınıf adını bulmaktır.

  ,
  import com.yourCompany.Customer;
...
Object obj = new Customer();
...
System.out.println( "Name:" + obj.getClass().getName() );
  
 

toString() Metodu

Bu yöntem, bir nesneyi bir String'e dönüştürmek için kullanılabilir. Nesneleri String'e dönüştürmek için birçok yerde otomatik olarak kullanılır; örneğin: PrintStream'de, StringBuffer'da ve nesnelerde kullanıldığında string concatenation operatörü için.

Varsayılan uygulama, sınıf adı ve hash kodu ile garip bir dize döndürür.

Örneğin:

  
  String str = "This customer is " + objCust;
  

ToString () yöntemi objCust nesnesinde çağrılır. ToString () yöntemi, debugging için de kullanılabilir:

  
  public class Customer
{
   private String _name;
   private String _address;
   private String _age;
...
   public String toString()
   {
       StringBuffer buf = new StringBuffer();
       buf.append( "Name   = " );  buf.append( _name );     buf.append( "\n" );
       buf.append( "Address= " );  buf.append( _address );  buf.append( "\n" );
       buf.append( "Age    = " );  buf.append( _age );      buf.append( "\n" );
    ...
       return buf.toString();
   }
...
}
  

Bundan sonra, kodunuzda ne zaman bir müşteri nesnesinin ne olduğunu görmek istersiniz, sadece şunu kullanabilirsiniz:

  
  System.out.println( objCustomer );
  

Synchronizing Thread'lerin Metodları

Çok iş parçacıklı bir ortamda, birden fazla iş parçacığı bir kaynağa erişip değiştirebildiğinde, sonuç tahmin edilemez olabilir. Örneğin, birden fazla iş parçacığı tarafından artırılan bir sayaç değişkenimiz olsun.

Dikkat! Senkronizasyon belirsiz bir terimdir. Aynı kod bölümünü aynı anda yürüten tüm iş parçacıklarını yapmaktan ibaret değildir. Tam tersi. Herhangi iki iş parçacığının aynı kod bölümünü aynı anda yürütmesini engeller. Bir işlemin sonunu ikinci bir işlemin başlangıcıyla senkronize eder.

Yukarıdaki kod, aşağıdaki alt işlemlerle oluşturulmuştur:

Read; değişken sayacını oku

Add; değere 1 ekle

Save ; yeni değeri değişken sayaca kaydet

Diyelim ki iki iş parçacığının bu kodu çalıştırması gerekiyor ve eğer sayaç değişkeninin başlangıç değeri sıfır ise, işlemlerden sonra değerin 2 olmasını bekliyoruz.

Yukarıdaki durumda Thread 1 işlemi kaybolur, çünkü Thread 2 kendi değerinin üzerine yazar. Thread 2'nin, Thread 1 işlemi bitirene kadar beklemesini istiyoruz. Aşağıya bakınız:

Kritik Bölüm (Critical Section)

Yukarıdaki örnekte, sayaç+=1 kodu herhangi bir zamanda bir ve yalnızca bir iş parçacığı tarafından yürütülmelidir. Buna kritik bölüm denir. Programlama sırasında, çok iş parçacıklı bir ortamda, kritik bir bölüme ait olan tüm kod parçalarını tanımlamalı ve herhangi bir zamanda yalnızca bir iş parçacığının bu kodları çalıştırabildiğinden emin olmalıyız. Buna senkronizasyon denir.

Konuları senkronize etme (Synchronizing threads)

Kritik bir bölüm koduna iş parçacığı erişimi, iş parçacıkları arasında senkronize edilmelidir, yani herhangi bir zamanda yalnızca bir iş parçacığının onu çalıştırabilmesini sağlamak için.

Nesne monitörü (Object monitor)

Her nesnenin bir Nesne monitörü vardır. Temel olarak, bir iş parçacığı tarafından kritik bir bölüm kodunun yürütülüp yürütülmediğini gösteren bir semafordur. Kritik bir bölümün yürütülebilmesi için iş parçacığının bir Nesne izleyicisi edinmesi gerekir. Bir seferde yalnızca bir iş parçacığı o nesnenin monitörüne sahip olabilir.

Bir iş parçacığı, üç yoldan biriyle nesnenin monitörünün sahibi olur

Bu nesnenin synchronized instance method yürüterek. Senkronize edilmiş anahtar kelimeye bakın.

Nesne üzerinde senkronize olan synchronized statement gövdesini yürüterek. Senkronize edilmiş anahtar kelimeye bakın.

Class türündeki nesneler için, o sınıfın synchronized static method yürüterek.

Object Monitor senkronizasyonla ilgilenir, öyleyse neden "wait() ve notify() yöntemlerine" ihtiyacımız var?

Senkronizasyon için onlara gerçekten ihtiyacımız yok, ancak bazı durumlarda bunları kullanmak güzel. Güzel ve düşünceli bir thread onları kullanacaktır. Kritik bir bölümün yürütülmesi sırasında iş parçacığı sıkışmış olabilir, devam edemeyebilir. Bir IO ve diğer kaynakları beklediği için olabilir. Her durumda, iş parçacığının nispeten uzun bir süre beklemesi gerekebilir. İş parçacığının nesne monitörüne tutunması ve diğer iş parçacıklarının işini yapmasını engellemesi bencillik olurdu. Böylece iş parçacığı, nesne üzerinde wait() yöntemini çağırarak bir 'bekleme' durumuna gider. İş parçacığının nesne monitörünü aldığı aynı nesne olmalıdır.

Öte yandan, bir iş parçacığı, yalnızca, kaynak kullanılabilir olduğunda notify() yöntemini çağıracak en az bir başka iş parçacığı varsa, wait() yöntemini çağırmalıdır, aksi takdirde iş parçacığı, bir parametre olarak zaman aralığı belirtilir.

Bir benzetme yapalım. Bazı eşyaları almak için bir dükkana girersiniz. Tezgahta sıraya girersiniz, satış memurunun dikkatini çekersiniz - onun "nesne-monitörünü" alırsınız. İstediğiniz ürünü soruyorsunuz. Bir depodan bir ürün getirilmesi gerekiyor. Beş dakikadan fazla sürecektir, bu nedenle satış memurunu serbest bırakırsınız ("nesne monitörünü" ona geri verin), böylece diğer müşterilere hizmet verebilir. Bekleme durumuna geçersiniz. Diyelim ki bekleyen beş müşteri daha var. Depodan eşyaları getiren başka bir satış memuru var. Bunu yaparken, ilk satış memurunun dikkatini çeker, nesne monitörünü alır ve bekleyen bir veya tüm müşteriyi/müşterileri bilgilendirir, böylece bekleyen müşteri(ler) uyanır ve müşterinin dikkatini çekmek için tekrar sıraya girer. ilk satış memuru.

Bekleyen müşteri ile ürünleri getiren satış memuru arasındaki senkronizasyona dikkat edin. Bu bir tür üretici-tüketici senkronizasyonudur.

Ayrıca, ilk satış memuruna ait yalnızca bir nesne monitörü olduğunu unutmayın. Beklemeden ve bir bildirimin gerçekleşebilmesi için önce bu nesne-monitörünün/memurun notify edilmesi gerekir.

final void wait() yöntemi

Geçerli iş parçacığı, bu nesnenin monitörüne sahip olmalıdır. İş parçacığı, bu monitörün sahipliğini serbest bırakır ve başka bir iş parçacığı, bu nesnenin monitöründe bekleyen iş parçacıklarının, notify yöntemine veya notifyAll yöntemine yapılan bir çağrı yoluyla uyanmasını bildirene kadar bekler. İş parçacığı daha sonra monitörün sahipliğini yeniden elde edene ve yürütmeye devam edene kadar bekler.

final void wait (long time)

Bekleme ile aynıdır, ancak bir bildirim olup olmadığına bakılmaksızın belirtilen süre geçtikten sonra iş parçacığı uyanır.

final void notify()

Bu yöntem yalnızca bu nesnenin monitörünün sahibi olan bir iş parçacığı tarafından çağrılmalıdır. Bu nesnenin monitöründe bekleyen tek bir iş parçacığını uyandırır. Bu nesnenin monitöründe çok sayıda iş parçacığı bekliyorsa, bunlardan biri uyandırılmak üzere seçilir. Seçim keyfidir ve uygulamanın takdirine bağlı olarak gerçekleşir. Bir iş parçacığı, bekleme yöntemlerinden birini çağırarak bir nesnenin monitöründe bekler.

Uyandırılan iş parçacığı, mevcut iş parçacığı bu nesne üzerindeki kilidi bırakana kadar ilerleyemeyecektir. Uyandırılan iş parçacığı, bu nesne üzerinde eşzamanlamak için aktif olarak rekabet edebilecek diğer iş parçacıklarıyla olağan şekilde rekabet edecektir; örneğin, uyanmış iş parçacığı, bu nesneyi kilitleyecek bir sonraki iş parçacığı olma konusunda güvenilir bir ayrıcalığa veya dezavantaja sahip değildir.

final void notifyAll()

notify() ile aynıdır, ancak bu nesnenin monitöründe bekleyen tüm iş parçacıklarını uyandırır.

sleep() ve wait() yöntemleri arasındaki farklar nelerdir?

Thread.sleep(milis)

Bu, Thread sınıfının statik bir yöntemidir. Şu anda yürütülmekte olan iş parçacığının belirtilen milisaniye sayısı boyunca uyumasına (yürütmeyi geçici olarak durdurmasına) neden olur. İş parçacığı herhangi bir monitörün sahipliğini kaybetmez. Bu, iş parçacığının bir nesne izleyicisi varsa, bu monitöre ihtiyaç duyan diğer tüm iş parçacıklarının engellendiği anlamına gelir. Bu yöntem, iş parçacığının herhangi bir monitörü olup olmadığına bakılmaksızın çağrılabilir.

wait()

Bu yöntem, Object sınıfından miras alınır. İş parçacığı, wait() yöntemini çağırmadan önce o nesnenin nesne monitörünü almış olmalıdır. Nesne izleyicisi wait() yöntemiyle serbest bırakılır, bu nedenle bu nesne izleyicisini isteyen diğer bekleyen iş parçacıklarını engellemez.

Orjinal metin

Mikro Servislerin 6 Avantajı - Hazelcast Makalesi Çevirisi

 Mikro Servislerin Altı Avantajı

İşletmeler giderek daha karmaşık çözümler ürettikçe mikro servisler konusu önemli bir gündem olmaya devam ediyor. Mikro servislerin birçok avantajı vardır ve bu makale, bir mikro servis mimarisinin sizin için neden iyi çalışabileceğini tartışmak için bunları altı bölümde toplamaktadır.

Giriş

Mikro servisler, daha büyük bir çözüm oluşturmak için birbirleriyle çalışan, sınırlı kapsam için tasarlanmış bir dizi yazılım uygulamasıdır. Her mikro servis, adından da anlaşılacağı gibi, yüksek düzeyde modülerleştirilmiş bir genel mimari oluşturmak adına minimum yeteneklere sahiptir. Bir mikro servis mimarisi, her bir mikro servisin montaj hattındaki bir istasyon gibi olduğu bir üretim montaj hattına benzer.

Her istasyonun belirli bir görevden sorumlu olması gibi, aynı şey mikro servisler için de geçerlidir. Her istasyon/mikro servis, ilgili sorumluluklarda uzmanlığa sahiptir, böylece iş akışında ve çıktılarda verimliliği, tutarlılığı ve kaliteyi destekler. Bunu, her istasyonun tüm ürünün kendisinden sorumlu olduğu bir üretim ortamıyla karşılaştırın. Bu, tüm görevleri aynı süreç içinde gerçekleştiren monolitik bir yazılım uygulamasına benzer.

Mikro servisler, genel bir çözüm sunmak için birlikte çalışan ayrı bileşenlerdir.

Açık olmak gerekirse, mikro servisler ve montaj hatlarının kesinlikle seri hale getirilmiş bir sırada çalışması gerekmediğinden, montaj hattı analojisi tek bir doğrusal akış anlamına gelmez. Mikro servislerle, veriler kolayca kopyalanabilir ve daha sonra veri hattının bir parçası olarak birden çok konuma dağıtılabilir ve böylece birden çok yol alabilir ve yönlendirilmiş bir döngüsel olmayan grafikte (DAG) olduğu gibi farklı şekillerde işlenebilir. Bu, veri hattını nasıl tanımlayacağınız konusunda size daha fazla esneklik sağlar ve ayrıca akışta daha fazla çıktı oluşturmak istemeniz durumunda pipelinenızı genişletme çabasını basitleştirir.

Bir mikro servis mimarisindeki veri akışı, bir DAG ile temsil edilebilir.

Mikro servisler son zamanlarda popülerlik kazanmış olsa da, arkasındaki kavramlar yeni değil. Modüler programlama, endişelerin ayrılması ve servis odaklı mimari (SOA) gibi konuların tümü, bir mikro servis mimarisinin hedefleriyle uyumlu ilkelere sahiptir. Bu, mikro servislerin yıllar içinde kullandığımız en iyi uygulamalara dayandığı ve bu nedenle kullanımlarının kolayca doğrulanabileceği anlamına gelir. Bazı geliştirme ekipleri, mikro servis mimarisini zorunlu olarak adlandırmadan zaten benimsemiş olabilir. Big Data pipelineları tipik olarak verileri bir seferde bir adım olarak işler ve bu da mikro servis yaklaşımıyla iyi uyum sağlar. Akış tabanlı bir mimariniz varsa (bununla ilgili daha fazla bilgi daha sonra), muhtemelen bu çerçevede mikro servisler çalıştırıyorsunuzdur. Halihazırda uyguladığınız teknikleri kullanarak mikro servislere daha bilinçli bir yaklaşımla, dağıtımlarınızdan potansiyel olarak daha fazla değer elde edebilirsiniz. Ve mikro servisler, bulut ortamları için çok uygundur; bu nedenle, bir Kubernetes kümeniz varsa ve/veya genel bulutta çalışıyorsanız, mikro servisler, bulut özelliklerinden yararlanmak için harika bir mimariyi temsil eder.

Mikro Servis Mimarisi Gereksinimler

Uygulamalarınızı ve çözümlerinizi bir mikro servis mimarisinde oluşturmak, herhangi bir özel bilgi veya deneyim gerektirmez. Stratejinin çoğu tanıdık gelecek ve muhtemelen daha önce uyguladığınız modülerlik gibi kavramlardan yararlanacak. Elbette, mikro servisler arası iletişim mimarinin önemli bir parçasıdır ve REST servisleri veri alışverişi için yaygın olarak kullanılır. Bununla birlikte, sizin için yeni olabilecek, veri alışverişi için giderek daha popüler bir tasarım modeli, olay güdümlü bir mimaride merkezi, hafif bir mesajlaşma veriyolunun kullanılmasıdır. Her bir mikro servis, daha büyük bir çözümün parçası olarak birbiriyle ilişkili olduğundan, durumunu izlemenin ve bireysel mikro servisler arasında veri aktarmanın kolay bir yolunun olması gerekir. Diğer veri alışverişi araçlarına göre mikro servislerle mesajlaşma veri yolu kullanmanın avantajları olduğundan, bu makale bu tasarım modeline odaklanacaktır. Mesajlaşma sistemi için bir seçenek Apache Kafka'dır. Apache Kafka, verileri "topics" adı verilen ayrı kanallarda depolayan bir publish/subscribe (pub/sub) mesajlaşma veriyoludur. Topic, veri öğelerini (veya "mesajları") sırayla izleyen bir veri yapısıdır. Topicler esnektir ve mesajları hemen hemen her biçimde saklayabilir. Kodlama açısından, topiclere mesaj yazmak ve okumak kolaydır. Ve bu mesajlaşma yaklaşımı mikro servisler kodundan ayrıldığından, mikro servislerin birbirleriyle doğrudan iletişim kurmasına kıyasla veri alışverişinde bulunma konusunda daha fazla esneklik elde edersiniz. Dağıtımınız için mesajlaşma sistemini oluşturmak üzere mikro servisleriniz için source (kaynak) ve destinition(hedef) olarak bir dizi topic ayarlayabilirsiniz.

Mikro servisler, verileri sonraki mikro servise geçirmek için Kafka topiclerini kullanabilir.

Her mikro servis, belirlenen kaynak topiclerinden bir veya daha fazlasından gönderilen verileri alır ve verileri işledikten sonra, çıktıyı belirlenen hedef konusuna sıralı bir şekilde yazar (veya serideki son mikro servis ise mesaj yazmaz) . Çıktı mesajı, verilen mikro servis için en anlamlı biçimde gönderilir ve daha sonra, bu mesaj biçiminin ne olduğunu ve nasıl tüketileceğini bilmek akıştaki bir sonraki mikro servise bağlıdır. Genel olarak, herhangi bir mikro servisin yalnızca (en fazla) bir topice yazması gerekir, çünkü birden çok alt akış mikro servisi aynı konudan çakışma olmadan bağımsız olarak okuyabilir. Montaj hattı benzetmesine devam etmek gerekirse, mesajlar devam eden ürünler gibidir ve her mikro servis bu ürünler üzerinde daha fazla iş yapar. Topicler, ürünleri montaj hattı istasyonları arasında taşıyan konveyör bantları gibidir. Kafka genellikle mikro servis mimarileri için kullanıldığından, "streaming architecture (akış mimarisi)" veya "streams based architecture (akış tabanlı mimari)" gibi terimlerin "mikro servis mimarisi" ile yakından ilişkili olduğu (ve bazen birbirinin yerine kullanıldığı) mantıklıdır. Bu farklı terimler, mimarinin farklı bir odağını ifade etse de, temel temel aynıdır. Mesajlaşma sistemi için başka bir seçenek, RAM ve paralelleştirme vurgusu nedeniyle verileri aşırı hızda depolamanıza ve işlemenize izin veren dağıtılmış bir bilgi işlem sistemi olan inmemory data grid'dir (IMDG). Bir IMDG, sabit sürücülere veya katı hal sürücülerine (SSD) dayanan Kafka'nın aksine, veri yapılarını bellekte depolar. Bu, bir IMDG'nin mikro servislerinizin verilere çok daha yüksek hızlarda erişmesine izin verdiği ve bu da genel çözümünüzün performansını önemli ölçüde hızlandırdığı anlamına gelir.

IMDG'ler, mikro servisler arasında mesaj iletmek için kullanabileceğiniz Kafka'ya benzer veri yapıları olarak konuları da içerir. Mapler(yani bir anahtar/değer deposu gibi davranan veri yapıları) gibi IMDG'lerde mesajlaşma için kullanılabilecek başka veri yapıları da vardır, ancak basitlik adına tartışmamız konulara odaklanacaktır. Hıza ek olarak, mikro servisler için IMDG'leri kullanmanın bir başka avantajı da, mikro servisleriniz için mesajların ötesinde veri depolamak ve almak için daha fazla veri yapısından yararlanabilmenizdir. IMDG, akış zenginleştirme için arama verileri sağlayan bir veritabanı gibi davranır ve ayrıca mikro servisleriniz için durumu izlemek için verileri depolayabilir. Bir mikro servis mimarisinde mesajlaşma katmanı olarak bir mesaj veriyolu kullanarak, mikro servisleri oluşturmak için bir akış işleme motoru (Hazelcast Jet gibi) kullanmak da mantıklıdır. Bu, bu makalenin ilerleyen kısımlarında tartışacağımız gibi, mikro servisler iş mantığını kodlamak için herhangi bir teknolojiyi desteklemek için gerçekten harika olduğundan, kullanabileceğiniz bir teknoloji örneğidir.

In-memory data grids, hızlı mesajlaşma ve veri depolama/alma sağlar.

Diğer teknolojiler, mikro servis mesajlaşması için kullanılabilir ancak ideal olmaktan uzaktır. Bazen REST servisleri olarak uygulanan dosya sistemleri ve veritabanları (RDBMS veya NoSQL) kullanılabilir, ancak bunlar yukarıda açıklanan teknolojilere göre önemli bir performans dezavantajından muzdariptir. Ayrıca, bu sistemleri bir mesajlaşma sistemi olarak kullanmak için gereken kodlama ve yönetim yükü, onları, aksi takdirde çevik odaklı bir mikro servis mimarisi için ideal olmaktan uzak kılar. Elbette, bu teknolojiler önceki nesil mikro servisler için kullanılmıştır, ancak uygulama geliştiricileri, aradıkları performans düzeylerini ve sürdürülebilirliği sağlamak için daha uygun teknolojilere olan ihtiyacı kabul etmektedir.

Neden Mikro Servisler?

Mikro servisler, bulut (private,public,hybrid,multi), bulut nesnesi depolama, Docker kapsayıcıları, Kubernetes ve Intel® Optane™ DC Kalıcı Bellek gibi RAM alternatifleri gibi popüler teknolojileri kullanan modern dağıtımlar için idealdir. Aşağıda, mikro servislerden yararlanan bazı teknik kullanım durumları verilmiştir: 

T Makine öğrenimi modellerini operasyonel hale getirme (makine öğrenimi çıkarımı) 

• ​Uçtan buluta Nesnelerin İnterneti veri analizi ve işleme 

• Sahtekarlık/anomali algılama 

• Büyük ölçekli e(xtract transform-load (ETL) T İşlem izleme ve işleme (çevrimiçi ödemeler ve e-ticaret gibi) 

Bu kullanım örnekleri arasındaki ortak tema, karşılanması gereken çok büyük miktarda veri, servis düzeyi sözleşmesi (SLA) gereksinimleri ve önemli bir kod miktarı. Bu tür kullanım durumlarını monolitik bir yaklaşımla ele almaya çalışmak yerine, mikro servislerin bir avantaj sağlamasının aşağıdaki altı nedenini göz önünde bulundurun:

1. Mikro Servislerin Oluşturulması ve Geliştirilmesi Daha Kolaydır

Mikro servisler, daha fazla odaklanmayı teşvik ederek daha yüksek kaliteli kod sağlar. Bireysel mikro servisler, tanım gereği, monolitik uygulamalardan daha küçük olduğundan, daha az kapsam ve daha az koda sahiptirler. Bu, artımlı kod güncellemeleriyle deneme ve test yapmayı çok daha kolay hale getirir. Tüm bir mikro servis tabanlı çözüm için toplam kod miktarı, işlevsel olarak karşılaştırılabilir bir monolitik uygulamaya benzer olsa da, zorunlu kod ayrımı, her bir parçanın yönetimini kolaylaştırır. Mikro servis düzeyinde daha az kod, daha az karmaşıklık, daha düşük test çalışması, daha kolay birim testi ve daha düşük sorun riski anlamına gelir. Ve tüm bu özellikler, kodu korumanın ve geliştirmenin daha kolay olduğu anlamına gelir, böylece size daha fazla çeviklik ve daha yüksek kalite sunar. Geliştirme ekibinin yeni üyelerinin her bir mikro servisin hedeflerini anlaması ve daha kolay katkıda bulunması daha kolaydır ve uygulamaların kaynak kodunun içine giremeyecek kadar karmaşık olduğu "kara kutular" haline gelme riski daha düşüktür.

Mikro servisler bağlamında düşünmek, iyi geliştirme uygulamalarını güçlendirmeye yardımcı olabilir. Çözümünüzü bir dizi küçük görev olarak tanımlayabilirseniz, her bir görevin süreçteki bir sonraki görevi nasıl etkileyeceği konusunda daha az endişe duyarak her görevi doğru yapmaya daha fazla odaklanabilirsiniz. Kafka veya Hazelcast IMDG gibi ayrıştırılmış bir mesajlaşma sisteminin de mikro servis geliştirme sürecini basitleştirmeye yardımcı olacağı yer burasıdır. Her mikro servis, akıştaki bir sonraki mikro servisin anlayabileceği kendi standartlaştırılmış biçiminde Kafka/IMDG'ye yazabilir. Mikro servislerin uyması gereken katı bir mesajlaşma formatı yoktur. Örneğin, bir mikro servisin yalnızca commadelimited tamsayılar listesi göndermesi gerekiyorsa, bunu yapabilir ve bir sonraki mikro servis, kendi işlemesini yapmak için bu biçimi okumaktan sorumludur. Bu ayrıştırma, veri hattına yeni kod eklemek kolay olduğundan, aynı ortamdaki farklı kod sürümlerini karşılaştırmak için deneyi ve A-B testini teşvik eder. Her bir mikro servisin basitliği ve modülerliği, yeniden kullanılabilirliğe de katkıda bulunur. Bir mikro servis, CSV'yi JSON'a dönüştürmek gibi genelleştirilmiş bir görevden sorumluysa, bu modül, bu dönüştürmeye ihtiyaç duyan herhangi bir mikro servis dağıtımına kolayca takılabilir. Bu, sonraki tüm mikro servis tabanlı çözümler için hızlı geliştirme ve genişlemeye yardımcı olur. Tabii ki, mikro servisin her tür CSV girdisini işlemek için yazılması gerekir, bu nedenle geliştirme sırasında genelleştirmeyi ve yeniden kullanılabilirliği aklınızda tutmanız yeterlidir; bu, sınırlı kapsamlı görevleri kodlarken yapılması daha kolay olma eğilimindedir. Bir mikro servis mimarisi mutlaka bir ya hep ya hiç çabası değildir. Bu uygulamaya daha fazla yetenek eklemek istiyorsanız, mevcut bir monolitik uygulamaya aşamalı olarak mikro servisler ekleyebilirsiniz. Ayrıca, bu belgede açıklanan tüm avantajları elde etmek için monolitik bir uygulamayı mikro servis mimarisine aşamalı olarak geçirebilirsiniz. Bu kulağa SOA gibi gelse de, temel fark, bir mikro servis mimarisinin uygulamalarınızın her birini küçük ve yönetilebilir hale getirmesi, SOA ise büyük ölçüde büyük uygulamaların birbirleriyle iletişim kurmasını sağlamasıdır. Bir SOA zihniyetiyle, verileri daha az karmaşık bir şekilde paylaşabileceksiniz, ancak yine de oluşturulması daha kolay olmayan karmaşık uygulamalarla uğraşacaksınız.

Bir mikro servis mimarisi, daha geniş bir yetenek havuzundan yararlanmanızı da sağlar, çünkü her bir mikro servis, diğerlerinden bağımsız olarak hemen hemen her programlama diline ve ortamına dayanabilir. Her bir mikro servisin nasıl oluşturulduğuna dair bir gereklilik yoktur. Her mikro servis için en uygun teknoloji yığınını seçebilirsiniz. Farklı becerilere sahip ayrı uygulama geliştirme ekipleri, teknolojiler ve beceri düzeyinde ortaklığa ihtiyaç duymadan bir mikro servis mimarisi üzerinde birlikte çalışabilir. Bu aynı zamanda gelecekte daha yeni teknolojileri mimarinize daha iyi dahil edebileceğiniz anlamına gelir. Genel olarak teknoloji standardizasyonu ile mücadele etmek yerine, yalnızca daha hızlı ve/veya daha verimli hale getirilebilecek mikro servisleri güncellemek için yeni teknolojilerden kademeli olarak yararlanabilirsiniz. Bu size, diğer kapasitelerde ne kadar iyi çalışabileceklerini görmek için yeni teknolojileri kontrollü bir şekilde deneme fırsatı verir.

2. Mikro Servislerin Dağıtımı Daha Kolay

Mikro servislerin dağıtımı, monolitik uygulamalardan daha kolaydır, çünkü daha küçüktürler ve bu nedenle daha az çevresel bağımlılığa sahiptirler. Monolitik uygulamaların dağıtımıyla ilgili yaygın bir sorun, geliştirme ortamları ile üretim ortamları arasındaki bilinmeyen tutarsızlıklardır. İşletim sistemi sürümlerine, kitaplık sürümlerine, RAM miktarına vb. bağımlılıklar vardır ve çok sayıda bağımlılığa sahip karmaşık bir uygulamanız varsa, saptaması zor dağıtım sorunlarıyla karşılaşabilirsiniz. Mikro servisleri artımlı bir şekilde dağıtırsanız, daha küçük kapsamları daha az bağımlılığa sahip oldukları anlamına geldiğinden, her bir mikro servisle karşılaştığınız sorunları izlemeniz daha kolay olacaktır.

Geliştirmeden üretime bağımlılık tutarsızlıklarının azaltılması da kapsayıcı mimarinin önemli bir avantajıdır. Bireysel mikro servislerin minimalist doğası, bunların bir kapsayıcıda ve diğer sanallaştırılmış teknolojilerle dağıtılmasını daha da kolaylaştırır ve bunu yapmak, bağımlılık çakışmaları potansiyelini daha da azaltmanıza olanak tanır. Konteyner tabanlı bir dağıtımın orkestrasyon sistemi olarak Kubernetes ile birleştirilmesi, mikro servisleri mevcut kaynaklara verimli bir şekilde tahsis ederek dağıtımı daha da basitleştirir.

Yine basit olacak şekilde tasarlandıkları için mikro servislerin çeşitli dağıtım seçeneklerinde dağıtılması kolaydır. Şirket içinde, bulutta, uçta, sanallaştırılmış ortamlarda (özellikle Docker kapsayıcılarında), sunucusuz ortamlarda, bir düğümde veya bir düğüm kümesinde devreye alınabilirler. Aslında, mikro servisler, mevcut kaynaklarınızdan yararlanmak için aynı kapsamlı uygulamaların bir parçası olarak birkaç farklı konuma dağıtılabilir.

Ayrıca, diğer mikro servislere yönelik güncellemeleri beklemeden mikro servislerin yeni sürümlerini dağıtabilirsiniz. Mesajlaşma biçiminiz olduğu gibi kaldığı sürece, mikro servislerin güncel sürümlerini sisteminizin geri kalanını olumsuz etkilemeden yeniden dağıtabilirsiniz. Yeni mikro servisinizle ilgili bir sorun ortaya çıkarsa, sistemin yeniden tam olarak çalışmasını sağlamak için önceki mikro servisi değiştirebilirsiniz.

3. Mikro Servislerin Bakımı, Sorun Gidermesi ve Genişletilmesi Daha Kolaydır

Mikro servisler, herhangi bir büyük ölçekli yazılım ortamında büyük zorluklar olan sürekli bakım ve hata toleransını daha sorunsuz bir şekilde sağlar. Monolitik bir uygulamada bir sorun ortaya çıktığında sorun giderme zordur çünkü verilerin dahili iş akışı içinde nasıl işlendiği her zaman açık değildir. Sorunun kaynağını izole etmek, tüm kod tabanının iyi anlaşılmasını gerektirir. Öte yandan, her bir mikro servisin kendi çıktıları olduğundan, hangi çıktının bir sorunu olduğunu ve dolayısıyla hangi mikro servisin ilgilenilmesi gerektiğini belirlemek daha kolaydır. Örneğin, mikro servis tabanlı bir sistemdeki son hesaplamaların yanlış olduğunu keşfederseniz, sorunlu hesaplamayı bulmak için sistemdeki verilerin kökenini, her seferinde bir mikro servis olmak üzere geriye doğru izleyebilirsiniz. Her bir mikro servisin sınırlı kapsamı ve ayrıca mikro servislerin otomatikleştirilmiş, standartlaştırılmış test senaryolarının çalıştırılmasını kolaylaştırması, bunların hatalarının ayıklanmasını ve dolayısıyla daha yüksek kaliteli kod oluşturulmasını kolaylaştırır.

Mikro servislerin birden çok bilgisayar sunucusu ve kaynağı arasında dağıtılmış yapısı, 7x24 dağıtımları etkinleştirmek için hata toleransı stratejilerine yardımcı olur. Herhangi bir mikro servis, tek bir arıza kaynağı olmaması için yedekli olarak dağıtılabilir. Her mikro servis, diğer örneklerden bağımsız olarak çalışır ve herhangi biri başarısız olursa, diğerleri boşluğu alır. Bu, ayrıştırılmış mesajlaşma katmanının değerli olduğu başka bir alandır, çünkü her bir mikro servis bağımsız bir tüketici olarak hareket eder, bu nedenle bir mikro servis hatası mesajlaşma sistemini bozmaz. Kubernetes kümesindeki Docker kapsayıcılarında mikro servisleri dağıtmak, Kubernetes bazı hata toleransı gereksinimlerini yönetebildiğinden ve arızalı mikro servisleri yeniden başlatabildiğinden bakımı da basitleştirir.

Yüksek modüler mimari nedeniyle uygulamanızda artımlı güncellemeler yapmak kolaydır ve nispeten düşük risklidir. Mevcut işlevselliği geliştirmek için güncellenmiş kodu ekleyebilir veya daha fazla çıktı sağlamak üzere sisteminizi genişletmek için yeni kod ekleyebilirsiniz. Mesajlaşma katmanının ayrıştırılması, yeni güncellemelerin sorunlu olduğu tespit edilirse veri kaybı (veya diğer önemli arızalar) riskini azaltır. Uygulamanızda kapsamlı değişiklikler yapmanız gerekse bile, bunu monolitik bir uygulamaya kıyasla çok daha az riskle yapabilirsiniz. Örneğin, güncellenmiş bir mikro serviste mesajlaşma biçiminizi değiştirirseniz, konuları ayırmak için hem eski biçimi hem de yeni biçimi aynı anda gönderebilirsiniz. Sıradaki mevcut mikro servisler, orijinal konudaki eski formatı kullanmaya devam edecek ve bu arada, yeni eklenen konudan yeni formattan yararlanacak güncellenmiş bir mikro servis yazabilirsiniz. Bu, sorunlara karşı ekstra bir savunma önlemi olarak eski kodu yeni kodun yanında çalıştırmanıza olanak tanır.

Ve daha sonra öngörülemeyen bir hata meydana gelirse, veri akışını geçici olarak durduracak olan belirli bir görevi kapatabilirsiniz, ancak mesajlar mesajlaşma katmanında sıraya alınır ve söz konusu görev geri yüklendiğinde okunacaktır. Mesaj yolu, tüm mikro servisler tekrar çalışır hale gelene kadar tüm verilerin korunmasını sağlar.

4. Mikro Servisler Ekipler Arası Koordinasyonu Basitleştirir

Herhangi bir büyük ölçekli yazılım geliştirme çabasının zorluklarından biri, entegrasyon noktalarını aşırı karmaşık hale getirme riskidir. Bir mikro serviste dahili iş akışı, bir kaynaktan veri okumak, veriler üzerinde bir eylem gerçekleştirmek ve ardından çıktıları bir hedefe göndermek kadar basit olabilir. SOA'da olduğu gibi hangi verilerin hangi entegrasyon noktalarında paylaşılacağı konusunda kapsamlı bir planlamaya gerek yoktur. Mikro servisler tipik olarak bir seferde küçük miktarlardaki verilerle ilgilenir, bu nedenle veriler işlendikten sonra çıktıyı yönetmek ve paylaşmak daha kolaydır. İşleme ve veri kapsamındaki bu basitlik, aktarımda basitliğe yol açar.

Bu basitleştirmeyi desteklemek için mikro servisler, mikro servislerin iletişim kurmasını sağlamak için hafif bir mesajlaşma sisteminden yararlanarak geliştirme ekipleri arasındaki koordinasyonu basitleştirmelidir. Her mikro servis, istediğiniz biçimde mesaj/veri gönderebilir, bu da sizi doğal olarak mümkün olan en basit biçimi benimsemeye teşvik eder. Gelecekteki iletişimi ironik bir şekilde karmaşıklaştırma eğiliminde olan evrensel bir mesajlaşma standardı etrafında bir gereklilik yoktur. Her bir biçim belgelendikten sonra, ardışık düzendeki bir sonraki mikro servisin geliştirme ekibi mesajları kabul etmek için bu biçimi kullanabilir. Ve her bir mikro servis, veriler üzerinde sınırlı bir görevi yerine getirdiğinden, karmaşık çıktılara gerek yoktur. Kapsamlı bir mesajın paylaşılması gerekmediğinden, yıllar öncesinin karmaşık mesajlaşma biçimlerine ihtiyaç yoktur. Mesajlaşmadaki bu basitlik, bilgi türü değiştiğinde yardımcı olur. Biçimdeki güncellemeler büyük olasılıkla basit olacak ve böylece bir sonraki mikro servisin bu güncellemeleri barındırmasını kolaylaştıracak.

Bu hafif mesajlaşma modeli, iletişim topolojisini aşırı derecede karmaşık hale getirmekten kaçınmaya yardımcı olur. Tasarımlarınızın ekibinizin iletişim yapılarının kopyaları haline geleceğini belirten Conway Yasasında ifade edilenler gibi riskler hala mevcuttur, ancak yalnızca tek tip bir zihniyete sahip olursanız. Örneğin, her geliştiricinin kendi modüllerinin diğerleriyle entegre olması gerektiğine inandığı tek bir büyük ekip oluşturursanız, baştan sona birçok entegrasyon, API ve veri yapısı içeren karmaşık bir mimariyle sonuçlanırsınız. Öte yandan, bir mimar bir mikro servis mimarisinin bileşenlerini tanımlayabilir ve ardından ekip liderlerinin mimariyi yansıtacak ekip yapılarını tanımlamasını sağlayabilirse, sistemin iletişimini uygulama çabasını basitleştireceksiniz.

5. Mikro Servisler Performans ve Ölçek Sağlar

Mikro servislerin dağıtılmış mimarisi, performansı artırmak ve ölçeği genişletmek için fırsatlar sunar. Her mikro servisin hata toleransı için yedekli olarak çalıştırılabilmesi gibi, bu yedeklilik de performans ve ölçek ekleyen daha fazla paralellik sağlar. Daha fazla mikro servis örneği, ilgili görevlere ayrılan daha fazla bilgi işlem kaynağı anlamına gelir. Aynı zamanda, bu yaklaşım daha büyük bir ölçek sağlar, böylece artan paralellik yoluyla daha fazla veri işlenebilir. Bu, esasen, daha fazla CPU gücü ve RAM'den yararlanmak için işi daha fazla mikro servise yaydığınız, verilerinizi işlemeye yönelik bir böl ve yönet yaklaşımıdır. İşlem hattında bir darboğaz ortaya çıktığında, yük dengeleme sağlamak için daha fazla bulut sunucusu (manuel olarak veya Kubernetes ile kapsayıcılı bir ortamda) dağıtılabilir. Yine, ayrılmış mesajlaşma katmanı, ek mikro servislerin kolay artımlı dağıtımlarına yardımcı olur.

Performans ve ölçek ekleme yeteneği, yalnızca SLA'ları gelecekteki büyümeyi göz önünde bulundurarak karşılamakla ilgili değildir. Aynı zamanda, yeni yetenekleri denemek için fazladan boşluk payına sahip olmakla da ilgilidir. Bu, denemenin dağıtım yaşam döngüsünün doğasında olduğu üretim makine öğrenimi dağıtımlarında özellikle kritiktir. Bir makine öğrenimi modeli nadiren yeterince iyi kabul edilir ve doğruluğu ancak modeller canlı veriler üzerinde çalıştırılarak tam olarak değerlendirilebilir. Deneme yeteneğiyle, aynı anda iyileştirme için yeni fırsatları keşfederken, günlük operasyonlarınızın güvenilir bir şekilde çalışmasını sağlayabilirsiniz.

Elbette performans ve ölçek avantajları yalnızca mikro servis dağıtımının özel olarak bir parçası olan kod için geçerlidir. Başka bir deyişle, ardışık düzenin parçası olarak adlandırılan uzak, üçüncü taraf API gibi harici kaynaklar varsa, mikro servis mimarisinin size orada yardımcı olması gerekmez. Yedekli mikro servislerinizin bunu paralel bir şekilde kullanabilmesi için harici kaynağın da ölçeklenebildiğinden emin olmanız gerekir.

6. Mikro Servisler Gerçek Zamanlı İşlemeyi Basitleştirir

Aciliyet talebi artmaya devam ediyor ve işletmelerin rekabet avantajını korumak için eskisinden daha hızlı yanıt vermesi gerekiyor. Bu nedenle akış mimarileri ve gerçek zamanlı işleme bugün popüler konulardır ve bunlar mikro servislerle uyumludur.

Gerçek zamanlı işleme, performans, ölçek, güvenilirlik ve sürdürülebilirlik ile ilgili birçok zorluğu beraberinde getirir ve mikro servisler yaklaşımı bu zorluğun hafifletilmesine yardımcı olabilir. Gerçek zamanlı işleme, genellikle bir dizi Nesnenin İnterneti cihazından gelen gibi sürekli bir veri akışıyla başlar. Gelen verilerin genellikle zenginleştirme, toplama ve filtreleme gibi çeşitli işleme görevlerinden geçmesi gerekir. Bu adımların her biri, verileri diğerine aktaran net bir görev ayrımı oluşturmak için bir mikro servis tarafından yapılabilir. Mesajlaşma katmanı, bu gerçek zamanlı akışı kolaylaştırmaya yardımcı olur ve gelen akış verileri akışıyla mükemmel şekilde hizalanır.

Bazı durumlarda, işlem, tipik olarak daha küçük ayak izi donanımı gerektiren sınırlı fiziksel alanın olduğu uçta hemen yapılmalıdır. Bu donanım sistemleri, veri merkezlerindeki veya buluttaki sunuculardan daha az güçlü olma eğiliminde olduğundan, azaltılmış bilgi işlem gücüyle çalışmak için hafif, verimli yazılım paketleri gereklidir. Hazelcast Jet gibi teknolojiler, tüm verileri merkezi bir veri merkezine aktarmaya çalışmak yerine bazı işlemleri uç bilgisayarlara boşaltmanıza izin vermek için uçta dahil olmak üzere çok çeşitli dağıtımlar için tasarlanmıştır. Bu dağıtım modeli, temel olarak, bazı görevlerin veri kaynağına yakın bir yerde gerçekleştirildiği ve daha sonra, daha yüksek güçlü bilgisayarlarda ek işlemler gerçekleştirmek için verilerin buluta veya başka bir veri merkezine teslim edildiği, yaygın olarak dağıtılmış bir mikro servis mimarisidir.

Sonuç

Bu yazıda tartışıldığı gibi, bir mikro servis mimarisini benimsemek için birkaç iyi neden vardır. Artık her zamankinden daha fazla veriyle uğraştığımıza göre, bu verilerin nasıl ele alınacağı konusunda daha stratejik düşünmek bugün önemli bir öncelik. Bugün yeni teknoloji yeniliklerini araştırmak, mikro servislerle yolculuğunuza daha fazla yardımcı olacaktır.

Yenilik, bizi yeni bir donanım performansı düzeyine getiren Intel Optane teknolojisinden daha önce bahsettiğimiz gibi, yazılım teknolojileriyle sınırlı değildir. Bellek içi RAM'den yararlanmak geçmişte pahalı bir teklifti, bu nedenle Optane ile bellek içi hızlara ekonomik olarak daha erişilebilir. Geçici bellek modunda, Optane karşılaştırılabilir hızlarda (iş yüklerine ve veri modellerine bağlı olarak) ancak yaklaşık yarı maliyetle RAM gibi davranır. Bu, daha fazla işletmeyi uygulama performansını hızlandırmak için bellek içi teknolojilere yönelmeye teşvik eder. Tüm bellek içi teknolojiler, kullanıma hazır Optane'den yararlanamaz, ancak Optane'i (diğer Intel teknolojileriyle birlikte) çok daha yüksek için kullanmak üzere onaylanan Hazelcast teknoloji paketini (Hazelcast IMDG ve Hazelcast Jet) göz önünde bulundurmalısınız. (disk veya SSD tabanlı sistemlerinize kıyasla hızlı işleme.)

Mikro Servisler için İlgili Teknolojiler

Bu makalede tartışıldığı gibi, mikro servis mimarileri bellek içi, bulut ve akış teknolojilerinden yararlanabilir. Hazelcast, IBM ve Intel, verilerle ilgili günümüzün zorlu gereksinimlerini karşılayan çözümler sunmak için birlikte çalışıyor. Özellikle bulutta yerel ortamlarda performans, ölçek, güvenlik, güvenilirlik ve çeviklik, başarılı, iş açısından kritik sistemleri devreye almanın temel bileşenleridir. Hazelcast'in bellek içi bilgi işlem platformu, Intel'in yenilikçi donanımı ve IBM'in uçtan buluta kurumsal çaptaki çözümleri ile veriye dayalı işletmeler, mevcut ve gelecekteki dijital stratejileri için sağlam teknoloji seçeneklerine sahipler.

Hazelcast Bellek İçi Bilgi İşlem Platformu

Hazelcast, Global 2000 kuruluşlarına zamana duyarlı, bulutta yerel uygulamalar için ultra yüksek performans sağlayan sektör lideri bellek içi bilgi işlem platformunu sunar.

Hazelcast Bellek İçi Bilgi İşlem Platformu, en yaygın olarak kullanılan bellek içi veri grid olan Hazelcast IMDG ve endüstrinin en gelişmiş bellek içi akış işleme çözümü olan Hazelcast Jet'ten oluşur. Bu teknoloji, bilgi işlem içgörülerini daha hızlı elde etmenize, eylemleri daha kısa sürelerde etkinleştirmenize ve yeni verilerle gelme hızında etkileşime geçmenize olanak sağlamak için benzersiz bir şekilde tasarlanmıştır. Ek olarak, dağıtılmış bir önbelleğe alma mimarisi, yüzlerce terabayta kadar ölçeklendirmenize ve uzak veri veya uç işleme ile uğraşırken maksimum verimlilik için ölçeği genişletmenize olanak tanır.

Aşırı ölçekte ultra hızlı işleme için tasarlanan Hazelcast'in bulut yerel bellek içi veri ızgarası ve olay akışı işleme teknolojileri, JPMorgan Chase, Charter Communications, Ellie Mae, UBS ve National Australia Bank gibi önde gelen şirketler tarafından işi hızlandırmak için güveniliyor. kritik uygulamalar Dünyanın en büyük e-ticaret siteleri, Kara Cuma, Siber Pazartesi veya Bekarlar Günü ile ilişkili büyük hacim artışlarını desteklemek için milisaniyeden kısa yanıt süreleri için Hazelcast Platformuna güveniyor.

Intel® Optane™ DC Kalıcı Bellek

Performans gereksinimlerinin çoğu bellek içi işlemeye bağlı olduğundan, ortaya çıkan en büyük engel rastgele erişimli belleğin (RAM) maliyetidir. Çoğu durumda, RAM ağırlıklı donanım sunucularına yapılan yatırım haklıdır ve RAM fiyatları düşmeye devam ettikçe, bellek içi işleme kullanımı daha erişilebilir hale gelir.

Son yenilikler, bellek içi işlemenin benimsenmesini daha da pratik hale getiriyor. Intel Optane DC Kalıcı Bellek teknolojisi, bellek içi işlemenin daha uygun maliyetli olabileceği iki yol sunar. İlk yol, Optane yongalarının RAM'e alternatif olarak hareket ettiği ve neredeyse aynı hızda ancak çok daha düşük maliyet ve çok daha yüksek kapasitelerde çalıştığı geçici bellek modundadır. Bu, işletmelerin bellek içi teknolojileri daha kolay gerekçelendirmesine ve böylece bellek içi işlemenin sunduğu performans avantajlarından yararlanmasına olanak tanır.

Optane'in bellek içi teknolojileri desteklediği ikinci yol kalıcı moddur. Bu modda Optane, katı hal sürücülerine (SSD'ler) daha hızlı bir alternatif olarak kullanılabilir. Örneğin, Hazelcast, bellekteki verilerin kalıcı bellekte kalıcı olduğu bir çalışırken yeniden başlatma özelliği sağlar, böylece bir düğüm geçici olarak çökerse, etkin yeniden başlatma deposundan veri okuyarak hızla geri yüklenebilir. Çalışırken yeniden başlatma verileri kalıcılık modunda Optane'de depolanırsa, bu düğümün kurtarılması SSD'lerin kullanılmasından 3,5 kata kadar daha hızlı olabilir.

IBM Cloud Paks ve Edge Application Manager

Daha fazla işletme genel, özel, çoklu veya hibrit bulut etrafında bulut stratejileri izledikçe, doğru temel yazılım bu yolculukta yardımcı olacaktır. Bulut dağıtımları, uçta bilgi işlem içeren ve sistem dağıtımını daha karmaşık hale getiren genel bir dağıtılmış bilgi işlem sisteminin yalnızca bir parçasıdır.

IBM, işletmelerin dağıtılmış verilerinden daha fazla değer elde etmelerine yardımcı olmak için uçtan buluta zorlukları çözme konusunda önemli girişimlere sahiptir. Altı Bulut Pak'ı (Uygulamalar, Veriler, Entegrasyon, Otomasyon, Çoklu Bulut Yönetimi, Güvenlik) ile IBM, kurumsal kullanıma hazır, bulut tabanlı bir yazılım yığını aracılığıyla temel iş uygulamalarını herhangi bir bulut ortamına taşımak için daha hızlı ve daha güvenli bir yol sağlar. Red Hat OpenShift üzerinde Kubernetes ile oluşturulan Cloud Paks, müşterilere dijital dönüşüm stratejilerini yönlendirmek için esneklik ve çeviklik sağlar. Hazelcast, Pak'ta dağıtılan tüm uygulamalara bulutta yerel bir çerçevede bellek içi hızlar sağlamak için Cloud Paks'e dahil edilmiştir.

IBM Edge Application Manager (EAM), uçta bilgi işlemi etkinleştirerek iş verilerinin erişimini genişletir. Uç bilgi işlem tipik olarak sınırlı fiziksel alana ve dolayısıyla sınırlı bilgi işlem gücüne sahip uzak, erişilmesi zor konumlar gerektirdiğinden, başarılı bir dağıtım için en önemli faktörlerden bazıları verimlilik, güvenilirlik ve güvenliktir. IBM EAM ile birlikte Hazelcast, uç bilgi işlemi etkinleştirmek ve işletmelerin verileri oluşturuldukları yerde işlemesine, analiz etmesine, toplamasına ve/veya filtrelemesine izin vermek için taşınabilir ve hafif ancak güçlü bellek içi ve akış işleme teknolojileri sağlar.