DEV Community: Mustafa Emre Başar

Resilience4j

Mustafa Emre Başar — Sun, 14 Aug 2022 11:16:00 +0000

Resilience4j, birbirleri ile iletişim içerisinde bulunan sistemler için hata toleransını yöneterek daha esnek bir yapı içerisinde
işlemlerinı sürdürmelerine yardımcı olan bir kütüphanedir. Bir noktadaki hatanın bütün sistemi etkilememesi asıl amaçtır.

Gerçekleştirmesinde Decorator Pattern ve Fonksiyonel Programlama konseptlerinden faydalanır.

Bu esnek yapıyı oluşturmak için çeşitli temel parçalar içerir;

CircuitBreaker
Retry
TimeLimiter
RateLimiter
Bulkhead

Circuit Breaker

Sistemdeki hata veya gecikmenin belirlenebilen bir eşik değerinin üzerine çıktığı durumlarda, kaynakların boşa harcanmaması için bağlantının kesilmesi olayıdır.

Bu oranı gözlemlemek için sliding window kullanılır ve iki tipi vardır;

Count Based : Son N çağrı göz önünde bulundurulur ve çıktılarını N boyutunda bir circular array içerisinde toplar. Bu çağrılarda gecikme veya hata oranı eşik değeri aşarsa, devre kesilir.
Time Based : Son N saniyede gelen çağrıların çıktıları için N boyutunda bir circular array oluşturur. Her bir indeks bir saniyelik aralığa denk gelmektedir. Her bir indekste hatalı, gecikmeli ve toplam çağrıları belirten 3 ayrı integer tutulur. Bu değerlerin oranına göre devrenin kesilmesine karar verilir.

Tanımlanan listelere veri girişi olduğu zaman yapılan hesaplama ile belirlenen hata ve gecikme eşik değerleri karşılaştırılır ve durum değişiklikleri yapılır.

failureRateThreshold : Hata oranının eşik değeridir, varsayılan olarak %50 durumundadır.
slowCallRateThreshold : Gecikme oranının eşik değeridir, varsayılan olarak %100 durumundadır. Bir çağrının gecikme olarak kabul edilmesi de (slow call) slowCallDurationThreshold değerine bağlıdır. Varsayılan olarak 60000 ms üzeri süren bir çağrı gecikme olarak kabul edilir.

Bu eşik değerleri ile ilgili bir diğer önemli bir nokta da, kontrole dahil edilmeleri, toplam istek sayısının minimumNumberOfCalls değerini aşmasından sonra gerçekleşir. Örneğin bu değer 10 olduğunda, gelen 9 istek de hatalı olsa dahi minimumNumberOfCalls değeri henüz aşılmadığı için devre kesilmez.

Devre Durumları

Devrenin bulunabileceği 3 farklı durum söz konusudur;

CLOSED : Devre kesiminin gerçekleşmediği, her şeyin normal seyrinde devam ettiği durumdur.
OPEN : Hata veya gecikme oranlarının eşik değerleri aşıldığında sistemin bulunduğu durumdur. Bu durumda iken gelen istekler CallNotPermittedException hatası ile geri çevrilir.
HALF-OPEN : Kesilmiş bir devrenin, waitDurationInOpenState ile belirlenen süreyi beklemesinden sonra, direk olarak CLOSED durumuna geçmek yerinde geçtiği ara durumdur. Bu durumda permittedNumberOfCallsInHalfOpenState ile belirtilen miktarda istek alınmasına izin verilir. Eğer bu isteklerdeki hata veya gecikme oranı eşik değerlerinden yüksek ise tekrar OPEN durumuna, değil ise CLOSED durumuna geçilir. Bu duruma geçişin otomatik bir şekilde yapılması için automaticTransitionFromOpenToHalfOpenEnabled değerinin true olarak ayarlanması gereklidir.

Bu işlemeler dahilinde varsayılan olarak, bütün Exception tipleri hata olarak sayılır. Ancak bu yaklaşım yerine kendi ayarlamalarımızı da yapabiliriz;

recordExceptions listesi kullanarak hata olarak sayılmasını istediğimiz Exception sınıflarını tanımlayabiliriz. Bunlar haricindekiler başarılı olarak sayılacaktır. Ayrıca belirtilen sınıflardan miras almış sınıflar da aynı şekilde ele alınacaktır.
ignoreExceptions listesi ile görmezden gelinecek Exception sınıflarını tanımlayabiliriz. Bu sınıflar ne başarılı ne de başarısız olarak kabul edilecektir.

Retry

Hata ile sonuçlanan bir çağrının otomatik olarak yeniden gönderilmesi amacıyla kullanılır.

Retry ile alakalı dikkat edilmesi gereken önemli bir nokta, çağrı sonucu çalışan operasyonun idempotent olması, yani tekrarlanan istekte gereksiz olan bulunuyorsa bunun görmezden gelinebilmesidir, aksi takdirde mantık hatalarına yol açabilir. Örneğin operasyon için çağrı yapıldığında, gerekli işlemler sağlıklı bir şekilde gerçekeştirilmiş olsun ancak geri dönüşte bir problem oluşmuş olsun, bu durumda istek tekrarlanacak ve eğer sistem buna hazırlıklı değilse aynı işlemler tekrar yapılmaya çalışılacaktır.

Retry kullanımında çeşitli değerleri konfigüre edebiliriz ;

maxAttempts: Hata durumunda maksimum deneme sayısını belirtir.
waitDuration: Her bir deneme arasında geçen sabit süreyi belirtir.
enableExponentialBackoff: Denemeler arasındaki geçen sürenin sabit olmayıp, exponential şekilde artacağını belirtir. Örneğin, denemeler arasında geçen süreler 2-4-8 şeklinde artar

Yeniden deneme durumları istenen şekilde ayarlanabilir.

Atılan isteğe bir cevap dönülmüş ise konfigürasyon dosyasına eklenecek resultPredicate değeri ile hangi koşulda retry yapılacağı ayarlanabilir.

resultPredicate: io.reflectoring.resilience4j.springboot.predicates.ConditionalRetryPredicate

ConditionalRetryPredicate implements Predicate<SearchResponse> {
 @Override
 public boolean test(SearchResponse searchResponse) {
   if (searchResponse.getErrorCode() != null) {
     return searchResponse.getErrorCode().equals("FS-167");
   } 
   return false;
 }
}

İstek gerçekleştirilirken hata gerçekleşmiş ise retryExceptionPredicate kullanılarak, hata incelenip retry yapılıp yapılmayacağına karar verilebilir veya retryExceptions ve ignoreExceptions değerleri kullanılarak direk olarak sınıflarına göre filtreleme de yapılabilir.

retryExceptionPredicate: io.github.resilience4j.circuitbreaker.RecordFailurePredicate

public class RecordFailurePredicate implements Predicate<Throwable> {

   @Override
   public boolean test(Throwable throwable) {
       return throwable instanceof IOException || throwable instanceof IgnoredException;
   }
}

Time Limiter

TimeLimiter, ilgili uca yapılan işlemin en fazla ne kadar zaman alacağını belirlemek için kullanılır.

TimeLimiter sadece asenkron işlemin yapıldığı(CompletableFuture ile sağlanan) endpoint'lere uygulanabilir.

TimeLimiter kullanımında çeşitli değerleri konfigüre edebiliriz;

timeoutDuration: Gelen isteğin zaman aşımı süresini belirtir.
cancelRunningFuture: Hali hazırda çalışan future için iptal edilip edilemeyeceğini belirtir.

Rate Limiter

Sisteme, belirtilen zaman aralığı içerisinde gelebilecek istek sayısını kontrol edebilmemizi sağlar.

Rate Limiter kullanımında çeşitli değerleri konfigüre edebiliriz;

limitForPeriod: Belirtilen periyot için izin verilecek azami istek sayısır
limitRefreshPeriod: Verilen limit değerinin geçerli olacağı süreyi belirtir. Süre sonunda istek sayısı sıfırlanır.
timeoutDuration: Limit değere ulaşıldığında, blokalanan thread için kaç saniye bekleneceğini belirtir.

Bulkhead

Bulkhead ile gelen eşzamanlı çağrı sayısını sınırlayabiliriz.

İki şekilde gerçekleştirilebilir ;

SemaphoreBulkhead : Gelen isteklerin semafor yardımı ile kilitleme mantığı ile yürütülmesi.
FixedThreadPoolBulkhead : Gelen her istek için, oluşturulan thread havuzundan uygun bir thread alınır ve izole bir şekilde işlemler gerçekleştirilir..

Semafor yaklaşımı için iki değer konfigüre edilebilir;

maxConcurrentCalls: Bulkhead tarafından aynı anda yürütülebilecek, azami istek sayısını belirtir.
maxWaitDuration: Belirlenen maxConcurrentCalls sayısının aşımına sebep olan isteğin ne kadar süre bloklanacağını belirtir.

Thread havuzu yaklaşımı için çeşitli değerler konfigüre edilebilir;

coreThreadPoolSize : Oluşturlan havuz için sabit(minimum) thread miktarını belirtir.
maxThreadPoolSize : coreThreadPoolSize miktarından daha fazla thread kullanımı gerektiğinde, geçici şekilde oluşturulabilecek yeni threadlerin azami miktarını belirtir.
queueCapacity : Thread havuzunda uygun thread bulunmadığında gelen isteklerin bekletileceği sıranın kapasitesini belirtir.
keepAliveDuration : Geçici oluşturulan threadlerin boşta ne kadar süre bekleyebileceğini belirtir. Bu süre aşımında thread sonlandırılır.

Transaction Management ve Spring Boot

Mustafa Emre Başar — Sun, 14 Aug 2022 11:07:47 +0000

Transaction Nedir ?

Transaction, beraberce başarılı veya başarısız olan olaylar serisidir.
Yapılan işlemlerin her birinin başarılı olması durumunda commit edilmesi herhangi birinin başarısız olması
ise işlemlerin tamamının başarısız olarak kabul edilerek rollback yapması olayıdır. Bu işlem bize veri bütünlüğünü sağlar.

Transaction Türleri

Transactionlar kullanım yerlerine göre global ve local olarak ikiye ayrılır.

Yukarıdaki sipariş örneğinde gösterildiği gibi, kullanıcı monolitik bir sisteme Order isteği gönderdiği zaman, alakalı transactionlar ortak bir veritabanına yazılır. Hata durumunda ise tek bir yapı halinde rollback edilebilir.

Sistem Monolit yapıdan Mikroservis mimarisine geçirildiğinde, Customer ve Order işlemleri için iki farklı servis oluşturulur ve alakalı veritabanlarıda ayrılmış olur.
Bu durumda iki servis için gerekli olan transactionların ayrı olarak yönetilmesi gerekir. Transaction artık birden çok veritabanında olduğundan, Distributed Transaction olarak kabul edilir.

Transaction Özellikleri

Transaction yönetiminde aşağıdaki konular göz önünde bulundurulmalıdır;

Failure recovery (Atomicity, Durability).
Concurrency control (Isolation, Consistency).

ACID prensiplerinın uygulanması sağlıklı bir transaction gerçekleştirmemizi sağlar.

Automicity

Transaction işlemini bir bütün olarak görür. İşlem sırasında birden fazla veritabanı/tablodaki verinin güncellenmesi gerçekleşiyor
ise tüm bunların hepsi birden başarılı olacaktır veya başarısız olacaktır

Consistency

Gerçekleştirilen Transaction işleminden etkilenen verilerin başlangıç ve bitiş durumlarının tutarlı olması gereklidir. Transaction sırasında oluşan bir hatanın, sistemin durumunu beklenmeyen bir şekilde etkilemesi engellenir.

Isolation

Aynı anda aynı veri üzerinde birden fazla Transaction gerçekleşebilir. Transaction’ların birbirlerinin işlemlerinden etkilenmemesi için işlemlerin Seri olarak yapılması gerekir. Transaction sırasında ilgili ve etkilenecek veri, işlem başarılı veya başarısız olarak sonuçlanana kadar veri setleri kilitlenir.

Durability

Transaction sırasında fiziksel veya işlemsel bir hata olması durumunda sistemin kendisini bir önceki geçerli veri durumuna döndürebilme kabiliyetidir.

Transaction Yönetimi Nedir?

Kullanılan transactionların ne gibi kurallar dahilinde çalışacağı kontrol edilebilir.

Spring Proxy Kullanımı

Spring, Transactional anotasyonu kullanılmış sınıf veya metodlar için direk çağrı yerine, bir proxy kullanır. Bu transaction mantığı ile iş mantığını birbirinden ayırma konusunda yardım eder.

Örneğin aşağıdaki gibi bir yapıya sahip olalım.

AccountService sınıfı için bir çağrı yapıldığında;

Burada araya bir proxy yapısı girer ve gerekli sınıfa veya metoda bu yapı üzerinden ulaşırız.

Transaction Yönetim Türleri

Spring transaction yönetimi için iki yöntem sunar. Programatik ve Deklaratif

Programmatic

Transaction yönetimi(commit, rollback) kodlarının içinde barındıran bir yöntemdir.

@Override
public void transferMoney(Account from, Account to, double amount, double fee) {
    TransactionDefinition transactionDefinition = new DefaultTransactionDefinition();
    TransactionStatus transactionStatus = transactionManager.getTransaction(transactionDefinition);
    try {
        withdraw(from, amount, fee);
        deposit(to, amount);
        transactionManager.commit(transactionStatus);
    } catch (RuntimeException e) {
        transactionManager.rollback(transactionStatus);
        throw e;
    }
}

Declarative

Spring altyapısında bazı kurallar çerçevesinde Spring Container tarafından gerçekleştirilir.

@Transactional Anotasyonu sayesinde yapılır

@Override
@Transactional
public void transferMoney(Account from, Account to, double amount, double fee){
    withdraw(from, amount, fee);
    deposit(to, amount);
}

Bu transaction yönetimi şeklinde sahip olduğumuz bazı işlem tipleri vardır.

Propagation tipi
Isolation seviyesi
Timeout süresi
readOnly flag
Rollback kuralı

Propagation

Transaction başladıktan sonraki davranışları ele aldığımız özelliktir. Bu tanımlamaya göre sonraki transaction davranışı belirlenir.

REQUIRED Propagation

REQUIRED, varsayılan propagation tekniğidir. Spring, aktif bir transaction olup olmadığını kontrol eder ve yoksa yeni bir tane oluşturur. Aksi takdirde, işlemler etkin olan transactiona eklenir:

@Transactional(propagation = Propagation.REQUIRED)
public void requiredExample(String user) {
// ...
}

REQUIRES_NEW Propagation

Var olan transactionu kullanmak yerine, onu askıya alarak yeni bir transaction oluşturmayı zorunlu kılar. Yeni transaction tamamlandığında askıya alınan transactiona geri dönülür.

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void requiresNewExample(String user) { 
    // ... 
}

SUPPORTS Propagation

Aktif var olan bir transaction bulunuyorsa ona dahil olur ancak yok ise non-transactional bir davranış sergiler.

@Transactional(propagation = Propagation.SUPPORTS)
public void supportsExample(String user) { 
    // ... 
}

NOT_SUPPORTED Propagation

Var olan aktif bir transaction varsa onu kullanmak yerine, onu askıya alarak işlemleri non-transactional olarak gerçekleştirir.

@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void notSupportedExample(String user) { 
    // ... 
}

MANDATORY Propagation

Aktif bir transaction bulunması durumunda ona dahil olur ancak bulunmadığı takdirde IllegalTransactionStateException fırlatır.

@Transactional(propagation = Propagation.MANDATORY)
public void mandatoryExample(String user) { 
    // ... 
}

NEVER Propagation

Aktif bir transaction bulunması durumunda IllegalTransactionStateException fırlatır, yoksa işlemleri non-transactional olarak gerçekleştirir.

@Transactional(propagation = Propagation.NEVER)
public void neverExample(String user) { 
    // ... 
}

Isolation

Her bir transactiondaki veriyi manipule etmek amacıyla kullanılır.

READ_UNCOMMITTED Isolation

Diğer transactionlarda gerçekleşen veri değişimlerinin, commitlenmeden önce, mevcut transactiondan okunabilmesini sağlar.

@Transactional(isolation = Isolation.READ_UNCOMMITTED)
public void log(String message) {
    // ...
}

READ_COMMITTED Isolation

Diğer transactionlarda gerçekleşen veri değişimlerinin, commitlenmeden önce okunmasını engeller.

@Transactional(isolation = Isolation.READ_COMMITTED)
public void log(String message) {
    // ...
}

REPEATABLE_READ Isolation
- Bir silme veya yeni kayıt ekleme işlemi sırasında, aynı anda okuma işlemi yapılabilmesine izin verir.

@Transactional(isolation = Isolation.REPEATABLE_READ)
public void log(String message) {
// ...
}

SERIALIZABLE Isolation

En yüksek seviye izolasyon yöntemidir. Bir kayıt üzerinde işlem yapılırken, bu kayıt kitlenir ve diğer transactionların üzerinde çalışması engellenir.

@Transactional(isolation = Isolation.SERIALIZABLE)
public void log(String message) {
// ...
}

Rollback

Transaction için rollback işlemini gerçekleştirmek ve gerçekleştirmemek istediğimiz Exception tiplerini belirtmemiz mümkündür.

@Transactional(rollBackFor = NullPointerException.class)
public void method(String message) {
// ...
}

@Transactional(noRollBackFor = NullPointerException.class)
public void method(String message) {
// ...
}

Ayrıca rollBackFor, varsayılan olarak RunTimeException için ayarlanmıştır.

Timeout

Transactionun belirli bir süre geçtikten sonra sonlanamaması durumunda otomatik olarak bitirilmesini sağlar. Varsayılan olarak 60 saniyedir.

@Transactional(timeout = 15)
public void method(String message) {
// ...
}

Read Only

Transactionunun sadece okuma işlemi için kullanılacağını belirtmek için kullanılır. Veriye erişimin buna göre optimize edilmesini sağlar.

@Transactional(readOnly = true)
public void method(String message) {
// ...
}

JUNIT 4 v JUNIT 5

Mustafa Emre Başar — Sun, 14 Aug 2022 10:58:44 +0000

JUnit son versiyonu JUnit5, Java8'in özelliklerini kullanarak daha okunabiilir, kullanışlı ve esnek bir framework ortaya koymaya çalışmıştır.

Annotations

@TestFactory : Metodun dinamik test olduğunu belirtir.
@Nested : Test sınıfı içerisinde nested sınıflar tanımlamamıza imkan sağlar.
@ExtendWith : İsteğe bağlı class veya package eklemek için kullanılır.
Varsayılan olarak hem JUnit 4 hem JUnit 5 için metodlar static olarak tanımlanmalıdır, ancak JUnit 5 @TestInstance(TestInstance.Lifecycle.PER_CLASS) anotasyonu kullanarak static kullanımının zorunluluğunu kaldırabiliyoruz.

Assertions

JUnit 4

Junit 4'te, org.junit.Assert, beklenen ve elde edilen sonuçları doğrulamak için tüm assert yöntemlerine sahiptir.

public static void assertEquals(long expected, long actual)
public static void assertEquals(String message, long expected, long actual)

Hata mesajı için ekstra parametre ilk argüman olarak beklenir.

JUnit 5

JUnit 5 ile, org.junit.jupiter.Assertions, yeni olarak assertThrows() ve assertAll() yöntemleri dahil, çoğu assert yöntemini içerir.

public static void assertEquals(long expected, long actual)
public static void assertEquals(long expected, long actual, String message)
public static void assertEquals(long expected, long actual, Supplier messageSupplier)

Hata mesajı için ekstra parametre son argüman olarak beklenir.
Supplier messageSupplier, olası bir hata durumunda, metod referansı veya lambda operasyonu kullanarak, verilen cevabın dinamik bir şekilde tanımlanabilmesini sağlar.
Junit 4'te, bir exceptionın fırlatıldığını kontrol ederken, @test(expected = InterruptedException.class) anotasyoununu kullanırken, JUnit 5 ile aşağıdaki gibi assertThrows kullanarak kontrol yapılabilir.

    @Test
    public void shouldThrowAnCheckedException(){
        Exception exception = Assertions.assertThrows(IOException.class, () -> {
            throw new IOException(
                       "We interrupt this test to throw an checked exception");
        });
     }

Aynı şekilde timeout kontrolu de, @test(timeout = 10), assertTimeout şeklinde değiştirildi.

    @Test
    public void testFailWithTimeout() throws InterrptedException{
        Assertions.assertTimeout(Duration.ofMiilis, () -> Thread.sleep(100); 
    }

Assumptions

JUnit 4

Junit 4'te, org.junit.Assume, bir testin anlamlı olduğu koşullar hakkında varsayımları belirtmek için yöntemler içerir. Bunlar ;
- assumeFalse()
- assumeNoException()
- assumeNotNull()
- assumeThat()
- assumeTrue()
Hata mesajı için ekstra parametre ilk argüman olarak beklenir.

JUnit 5

JUnit 5 ile, bu varsayımların sayısı düşürülmüştür ve 3 adet varsayım vardır. Ayrıca bu metodları org.junit.jupiter.api.Assumptions içerir hale gelmiştir.
- assumeFalse()
- assumingThat()
- assumeTrue()
Ayrıca metodlar overload edilebilir olup, gerektiğinde yapılması istenen operasyonlar lambda formunda parametre olarak verilebilir.

@Test
void testSomething() throws Exception{
  Assumptions.assumingThat("foo".equals("bar"),() ->{
    assertEquals(...);
  })
}

Test Suite

Farklı test sınıflarını tek bir yerden çağırıp kullanmak istediğimizde JUnit 4 ile aşağıdaki gibi bir yapı kullanırken,

import org.junit.runner.RunWith;
import org.junit.runners.Suite;

@RunWith(Suite.class)
@Suite.SuiteClasses({
        ExceptionTest.class, 
        TimeoutTest.class
})
public class JUnit4Example 
{
}

JUnit 5 ile Suite yerini SelectPackages ve SelectClasses almıştır. Bu Single Responsibility açısından faydalıdır. Ayrıca @RunWith anotasyonunun yerini @ExtendWith almış ve parametresi JUnitPlatform.class olarak değişmiştir.

import org.junit.platform.runner.JUnitPlatform;
import org.junit.platform.suite.api.SelectPackages;
import org.junit.runner.RunWith;

@ExtendWith(JUnitPlatform.class)
@SelectPackages("com.howtodoinjava.junit5.examples")
public class JUnit5Example 
{
}

Mimari

JUnit 4, her şeyi tek bir jar dosyayı altında toplamıştı, bu durum JUnit 5 için farklıdır.
JUnit 5, 3 alt elementten oluşur;
- JUnit Platform : Platformda çalışan yeni test ortamlarını geliştirmek için TestEngine API tanımlar.
- JUnit Jupiter : JUnit anotasyonlarını içerip, bu anotasyonlarla yazılmış testleri çalıştırmak için TestEngine implementasyonlarını içerir.
- JUnit Vintage : JUnit 5 platformunda JUnit 3 ve JUnit 4 yazılı testlerinin çalıştırılmasını sağlar.
JUnit 4 Java5 veya üzeri için iken, JUnit 5 Java8 veya üzeri içindir.

Üçüncü Parti Entegrasyonu

JUnit 4, üçüncü parti yazılımlar için herhangi bir destek içermeyip, bunu Java Reflection ile sağlanmaya çalışılıyordu.
JUnit 5 bu amaçla içerdiği JUnit platform ile TestEngine API kullanarak herhangi bir frameworkun çalışmasını destekler.

Ek Olarak

Parameterized Tests

Parameterized Test, JUnit 4'de çeşitli kütüphaneler ile sağlansa da, JUnit 5 ile tamamen built-in bir hale gelmiştir.

@ParameterizedTest
@ValueSource(strings = {"foo", "bar"})
@NullAndEmptySource
void myParameterizedTest(String arg){
  underTest.performAction(arg);
}

Conditional Test Execution

JUnit 5 ile ExecutionCondition API, testleri koşulsal olarak etkinleşirebilir veya devre dışı bırakabilir.
- @EnabledOnOs ve @DisabledOnOs: Yalnızca belirtilen işletim sistemlerinde bir testi etkinleştirir.
- @EnabledOnJre ve @DisabledOnJre: Java'nın belirli sürümleri için testin etkinleştirilmesi veya devre dışı bırakılması gerektiğini belirtir.
- @EnabledIfSystemProperty: JVM sistem özelliğinin değerine dayalı bir testi etkinleştirir.
- @EnabledIf: Komut dosyasıyla yazılan koşulların karşılanıp karşılanmadığını bir testi etkinleştirmek için komut dosyası mantığı kullanır.

Hystrix

Mustafa Emre Başar — Sun, 14 Aug 2022 10:45:24 +0000

Hystrix

Hystrix, dağınık sistemlerde, servisler arasında oluşabilecek gecikme ve hata durumlarında sistemin bu olaylara karşı toleransını arttırmak amacıyla bazı stratejilerin uygulanabilirliğine imkan sağlar. Bunu hizmetler arasındaki erişim noktalarını izole ederek, bunlar arasında kademeli arızaları durdurarak ve dönüş seçenekleri sunarak yapar ve genel esnekliği arttırır.
İstenmeyen bir durum oluştuğunda, bu durumun zincirleme şekilde başka durumlara yol açmadan bir an önce kontrol edilmesi, olabildiğince hızlı tespit ve kurtarma yapılmasını amaçlar ve bu seri kontrol eğilimi ile de gerçek zamana yakın bir monitörleme imkanı sunar.
Dağıtık mimaride çok fazla bağımlılık bulunur ve bunlar bir aşamada mutlaka hatalı duruma düşerler. Hystrix bu bağımlılıklar arasında bir izolasyon yaratarak 'loose coupling' hedefler.

https://github.com/Netflix/Hystrix

Örneğin 10 servisten oluşan ve her servisin has 99.99% uptime sahip olduğu bir uygulamada,

99.99¹⁰ = 99.9% uptime

0.3% of 1 billion requests = 3,000,000 failures

2+ hours downtime/month even if all dependencies have excellent uptime.

Herhangi bir üçüncü parti bağımlılığında oluşan bir gecikme, artan talep ile sistemin bütün kaynaklarını kullanmaya başlayıp, sistem genelinde bir duraksamaya sebep olacaktır.

İçerdiği Tasarım Prensipleri

Bir bağımlılığın kaynakların kullanımını domine etmemesi.
En kısa sürede sistemi hata durumuna düşürerek, cevap oluşturup yükten kurtulmak.
Hata durumunda en uygun yerde bir geri dönüş(fallback) mantığı gerçekleştirerek, kullanıcıyı korumak.
Çeşitli izolasyon teknikleri(bulkhead, swimlane, ve circuit breaker) ile bağımlılığı azaltmak.
Hatanın keşfinde ve kurtarılmasında optimizasyon.

Nasıl Gerçekleştiriliyor?

Harici sistemlere (veya "bağımlılıklara") yapılan tüm çağrıları, tipik olarak ayrı bir thread içinde yürütülen bir HystrixCommand veya HystrixObservableCommand nesnesine sarmak (Bu açıdan Command Pattern benzerliği vardır).
Bir isteğe cevap geciktiğinde, belli bir eşik değerin üzerinde gecikme oluşursa time-out atılması sağlanır.
Her dependency için bir thread-pool oluşturulur ve eğer bu pool gelen istekler ile dolarsa istek anında reddedilir ve gereksiz bekleme ve kaynak harcanması engellenir.
Bir servisin hata yüzdesi bir eşiği geçerse, belirli bir servise yönelik tüm istekleri belirli bir süre boyunca manuel olarak veya otomatik olarak durdurmak için bir circuit breaker kullanır.
Çağrıları sarmalayan yapılar içerisinde olası hatalı durumlarda izlenecek mantık gerçekleştirilerek sağlam ve kullanışlı bir sistem oluşturulur.

Bulkhead

Her bir tipteki istek için bir thread pool oluşturup, bir istek tipinin bütün kaynakları kullanıp diğer requestlerin de gecikmesine engel olmasını engeller.

Circuit Breaker

Bir thread pool içerisinde, request sayısı ve thread-pool boyutu oranı artarak belli bir eşik değeri üzerine çıkarsa, servise giden bağlantının kesilip(circuit-open) isteklerin anında cevaplanması ve gecikmenin engellenmesini sağlar.
Aynı mantık geciken cevaplardan ziyade, hata oluşan isteklerde de uygulanabilir. Belli bir değerin üzerinde hata oluştuğunda bağlantı kırılarak, fazla sayıda hatanın oluşması engellenir ve gerekli aksiyonların alınabilmesi için imkan oluşturulur.

    @SyncCallLogger
    @Override
    @HystrixCommand(fallbackMethod = "sorgulaTahakkukFallbackMethod",
            commandProperties = {@HystrixProperty(name = "execution.isolation.strategy", value = "SEMAPHORE")})
    public GumrukEttnSorgulaResponseDTO sorgulaTahakkukGumrukten(GumrukEttnSorgulaRequestDTO gumrukEttnSorgulaRequestDTO) {
        return restTemplate.postForObject(gumrukConfiguration.getMaliyews().getSorgulaTahakkuk(), gumrukEttnSorgulaRequestDTO, GumrukEttnSorgulaResponseDTO.class);
    }

Hytrix sistemlerde gereksiz işlemlerin önlenmesi için iyi bir çözüm ancak artık bakımı yapılmadığı için yakın zamanda benzerlerinin arkasında kalması ve talepleri yerine getirememesi durumu da olası. Kullanımı durumunda bu durum göz önünde bulundurulmalı.

SOLID Prensipleri

Mustafa Emre Başar — Tue, 17 Aug 2021 13:46:10 +0000

SOLID Prensipleri

SOLID Prensiplerin temel amacı modüler bir yapı sağlayarak tekrar kullanılabilirliği, test edilebilirliği, bakımı ve genişletilmesini kolaylaştırmaktır. Yazılımı daha kolay gerçekleştirilebilir hale getirip, beklenmedik etkileri engellemeyi amaçlar.

Single Responsibility

Bir class veya modül yalnızca bir işten sorumlu olmalıdır, aynı anda birbirinden farklı aktörler için hizmet vermemelidir. Aksi taktirde sorumluluklarından birinde yapacağımız bir değişiklik istenmeyen yerlerde hatalara sebep olabilir. Bir class veya modül için tanımlama yaparken tanım ne kadar uzuyorsa ve ne kadar çok "ve" kullanıyorsak, bu konseptten o kadar uzaklaşıyoruz demektir.

Open-Closed

Bir class için ana davranışı değiştirmeden, bu davranışının üzerine, izin verilen ölçüde, yeni eklemeler yapılabilir olması gerekir. Bu yaklaşım, class için önemli olan temel elemanları koruyarak, halihazırda bu classtan faydalanan birimlerde sorun oluşmasını engeller. Geliştirmelerde Single Responsibility ile ters düşmemek adına eklenen özelliklerin ana davranışa bağlı olmasına dikkat edilmelidir.

Liskov Substitution

Bir class üzerinden inheritance söz konusu olduğunda, üretilen child classların parent classın hizmetlerini yerine getirebilir olması beklenir. Child class istekler üzerine daha spesifik cevaplar verebilir olsa da verdiği cevaplar parent classın cevapları ile tutarlı olmalıdır. Burda child classlara esnek bir çalışma alanı bırakabilmek için parent classları olabildiğince abstract yapmak akılcı olacaktır.

Interface Segregation

Bir classtan beklenen aksiyonlar, o classın yapmakta yetersiz olduğu veya çalışma alanında olmayan aksiyonlar olmamalıdır, bu tanımlamalar gereksiz olup okunabilirlik açısından kötü bir etki yaratabilir. Bu kapsamda temelde aynı özelliklere sahip olsa da, farklı aksiyonlar gerçekleştirmek üzere geliştirilen classlar için, aksiyonlara yönelik interfaceler kullanılmalıdır.

Dependency Inversion

Bir class ile kullandığı araçlar arasında doğrudan değil de dolaylı bir ilişki olmalıdır. Bu ilişki interface aracılığıyla sağlanmalıdır. Bu sayede aracın nasıl çalıştığı class tarafından bilinmek zorunda değildir, aracın bağlantıyı sağlayan interface'in gerekliliklerini sağlaması yeterli olur. Bu durum classın bağımlılığını azaltmış olur ayrıca tekrar kullanılabilirlik de arttırılmış olur.

SPRING ve SOLID Prensipleri

Single Responsibility

Spring Frameworkü ile SR arasındaki ilişkiyi basitçe Controller, Service ve Repository classları üzerinden anlatmaya çalışırsak; Bir para akışı modeli için, her düzeyde, gelir ve gider için gereken aksiyonları içeren classları oluşturmak, her classın bellirli ve alakalı use case kontrolleri yapmasını sağlar ve SR arttırır.

Open-Closed

Aynı model üzerinden devam edilirse, Open-Closed ilkesi doğrultusunda en az değişiklik ile yeni özellik eklemeleri yapılabilmesi için ilk olarak, service ve controller arasındaki bağlantıyı azaltmak gereklidir. Bunu da araya bir başka interface katmanı ekleyerek yapabiliriz. Böylelikle service katmanını inject eden controller servicedeki değişikliklerden en az şekilde etkilenir.

Bir adım daha gidip, yapıyı yeni özellik eklemelerine de uygun hale getirmek için, örnek olarak gelir gider hesplamaları gibi bir özellik eklemek için de aynı yapı kullanılır.

Burda ServiceImpl classlarının hesaplama classlarına bağımlılığı en az seviyede tutulmuş olur ve daha sonradan gelecek başka türde hesaplamalar da bu CalculatorService arayüzü üzerinden gerçekleştirilebilir.

Liskov Substitution

CashFlow projesi üzerinde geliştirme için devam edersek Liskov için yapabileceğimiz şey, service classlarını düzenlemek olacak. İlk olarak Controller classları için kullanılan serviceler ile hesaplama için kullanılan serviclerin ayrımını yapıyoruz ki hesaplama servisinin repository sınıfları ile olan gereksiz bağlantısı ortadan kalksın. Bunları kendi entityleri ile başka bir package içerisie taşıyoruz.

Daha sonra Service türleri için de bir abstraction oluşturarak bağımlılığı daha da azaltıyoruz.

Burdaki bir diğer önemli nokta da her iki service tipinin de Service parent classının gerekliliklerini yerine getirerek LS prensibine uyuyor olmasıdır.

Interface Segregation

Ek olarak bir tane daha, gelir ve gider arasında dönüştürme yapan bir service yaratmak istediğimizde bunları tek bir service altında değil de, bir parentdan implement ederek oluşturduğumuzda, sınıfların ortak bir arayüzü implement edip gereksiz methodları override etmeye çalışmasını engellemiş oluruz.

Dependency Inversion

Dependency Inversion Prensibi, High-Level elemanların, Low-Level elemanlara, abstraction ile bağlanması gerektiğini söyler.

Önceki 4 prensip ile beraber yapı aşağıdaki gibi bir hal aldı ve Dependency Inversion sağlanmış oldu.

Görüldüğü üzere farklı katmanlardaki elemanlar birbirlerine doğrudan değil, Dependency Inversion doğrultusunda arayüzler aracılığıyla soyutlanarak bağlanmış durumdadır.

Dependency Inversion, Dependency Injection ve Inversion of Control

Dependency Inversion farklı seviyelerdeki modül veya sınıfların arasındaki iletişimin arayüzler aracılığıyla sağlanarak bağımlılığı azaltır ancak yine de instance tanımlamaları hala tanımlanan sınıf tarafından yapıldığı için bağımlılık tam manasıyla sağlanmış değildir. Bunu aşmak için Dependency Injection kullanılır. Dependency Injection, Inversion of Control prensibini implement eden bir design patern’dır. Bağımlılıklar class’a dışarıdan “enjekte” edilir.

Site Reliability Engineering

Mustafa Emre Başar — Tue, 17 Aug 2021 13:13:08 +0000

Site Reliability Engineering

Güvenilir olmayan yazılımlar, işletmelere bir çok alanda olumsuz etkilere sebep olabilir.
İhtiyaç duyulan düzeyde güvenilirlik sağlanmalıdır, aksi takdirde kaynak kaybına yol açar.
Sağlanan güvenilirlik sürdürülebilir olmalıdır.
SRE ve DevOps aynı amaca hizmet eden iki farklı yaklaşımdır.
SRE de kullanılan iki ana konsept:
- SLI ve SLO
- Suçlama Yapılmayan Otopsiler
;iki konsept de verimli döngüler oluşturmayı hedefler.

SLI ve SLO

SRE ile ilgili kararlar gelişimin bütün paydaşları ile beraber verilir.

SLI -> sistemin belli ölçekteki başarı sıklığı.

SLO , bu başarının hedeflenen düzeyidir.
Hedeflenen SLO dan kalan kaynağa hata bütçesi denir ve bu kısım ,SLO kaybı olmadığı takdirde, sistem gelişimi için kullanılabilir.
Hata bütçeleri genellikle ayarlanan bir süre için hesaplanır.

Suçlama Yapılmayan Otopsiler

Olası bir istenmeyen durumda hatayı yapan kişiyle ilgilenmek yerine, kişinin bu hatayı yapmasına sebep olan şeylere odaklanılır.

SRE ilkeleri

SRE için zahmetten(toil) kaçınmak için otomasyon kullanımı önemli bir husustur.
Gereğinden fazla zahmetle uğraşılması daha önce belirtilen verimli döngülerin oluşturulması ve devamlılığını baltalar.

Clean Code

Mustafa Emre Başar — Tue, 17 Aug 2021 13:05:13 +0000

TEMİZ KOD

Temiz kodlama hakkında notlar genel başlıklar halinde aşağıdaki gibidir.

Konseptin Genel Gereksinimleri

Herhangi bir kodlama elemanında tekrarlamalar yapılmamalı, olabildiğince generic bir tasarım yapılmalıdır.
Kod baştan aşağı bir anlam içermeli ve aynı bağlamdaki elemanlar alakalı yerlerde kullanılmalıdır.
Modüller arası ilişkiyi en aza indirip, olabildiğince esnek ve bağımsız bir yapı yaratılmalıdır.

İsimlendirme

Değişken : Ne hakkında bilgi taşıdığı net anlaşılmalıdır

Sınıf : Sorumlulukları kapsayan isimler olmalıdır, fiil içermemelidir.

Method: Ne iş yaptığını "Tek Görevlilik" çerçevesinde anlatmalıdır.

Boolean : Cevabının değişkenler ile alakalı olması gerekli, bir durumun kontrolünü açıkça belirtebilmelidir.
Binary sorulara cevap verebilmelidir.

İsimlendirmeleri anlık değil, genel kapsamda yapıp kodu anlaşılır yapmalı, yapılmak isteneni en uygun
şekilde ifade edecek şekilde tasarlanmalıdır. Kısaltma kullanmak, bizim için anlaşılır olsa da başkası için
olamayabileceği için, pek iyi değildir.

Koşullar

Kontrol edilen durumun ne olduğunu en iyi anlatacak şekilde tasarlanmalı, koşul kısmını olabildiğince
kısa tutmalı, gerekirse başka bir değişken kullanarak enkapsüle etmeli.

Fonksiyonlar

Tekrardan kaçınmak temel amacıyla küçük ve tek amaca hizmet eden kod blokları kullanılmalı ve verilen
parametreler ve sayıları da bu tasarımı desteklemeli.

Exception Handling

İşlerin ters gitmesi durumuna karşılık önlem alınmalı ve istenmeyen durumlarla karşılaşıldığı zaman
uygun bilgilendirme ile birlikte gerekli aksiyonlar gerçekleştirilmeli.

Sınıflar

Olabildiğince küçük ve kapsamı net olarak belli olmalı. Koşullara göre kapsamı genişleyen yapılar olmamalı.
İyi organize edilmiş, diğer modüllerle gereğinden fazla alaka kurmayan sınıflar gelecek değişimlerde kolaylık
sağlar.

Yorum Satırları

Yorum satırları direk olarak kodu açıklamak için değil, kodun gerçek manada kendini anlatmaya yetersiz
kaldığı durumlarda kullanılmalıdır. Her zaman ilk öncelik yorum satırı yerine ne yaptığını net bir şekilde
açıklayan kod blokları olmalıdır, bunun mümkün olmadığı yerlerde yorum satırları kullanılmalıdır.

Biçim

Baştan aşağı kodu okurken bir örgü içerisinde olmalı, alakalı değişkenler ve metodlar bir arada olmalı.

Güvenlik

Kullandığımız dilin bize verdiği imkanlar doğrultusunda güvenli bir kod yazmalıyız, kod elemanlarının
kullanılması gereken kapsamlar dışında kullanılmamasını sağlamalıyız. Bu hem güvenliğin yanında esnekliği,

bakım yapılabilirliği, anlaşılabilirliği ve test edilebilirliği konusunda da yardımcı olur.
Örneğin Javada kullanılan private ve public anahtar kelimeleri.

Testler

Testler bir kodun güvenilirliğini ve bakım-edilebilirliği konusunda önemlidir. Okunabilir kodlar yazmak
kadar okunabilir testler yazmak da önemlidir. Kapsamı belli, bağımsız ve hızlı testler kullanılmalıdır.

CI-CD

Mustafa Emre Başar — Tue, 17 Aug 2021 13:01:06 +0000

CI/CD

Deployment süreçlerindeki tekrar eden işleri otomatize etmek için kullanılır.
İnsan payını en az indirmeyi amaçlar ve hızlı bir gelişim süreci sağlar.
Paketin kullanıcıya sunmaya ne derecede hazır olduğunu denetler.
Integration ve Delivery aşamalarından oluşur.

Continuous Integration

Kaynak kod üzerinde değişiklik yapıldıktan sonra sistemin çalışır durumda olduğunu ve değişikliğin sorun yaratmadığını tespit etmek için kullanılır.
Sorun halinde gerekli kişilerin bilgilendirilmesi sağlanır.
Bir uygulamadaki değişiklikler birleştirildiğinde, değişikliklerin uygulamayı bozmadığından emin olmak için uygulamayı otomatik olarak oluşturarak ve farklı düzeylerde testler ile doğrular.

Continuous Delivery

Başarılı olan bir yapının bir ortama ototmatik olarak aktarılmasıdır.
Yeni bir sürüm dağıtıldığında geçici kesintilerden etkilenmeyecek şekilde tasarlanmalıdır.

CI/CD

Değişiklikler günde birçok kez ana kod dalında birleştirir
Her kod, otomatik bir kod oluşturma ve test sırasını tetiklemek için birleştirilir
Sistem tekrar eden sürümleri destekleyecek şekilde tasarlanmalıdır.
Sorunları gerçek zamanlı olarak tespit etmeye çalışılmalıdır.
Kod test odaklı geliştirmeye çalışılmalıdır.
Çeşitli araçlar yardımıyla entgre edilir. Bunlar; Jenkins, TeamCity, GitLab, CircleCI

Faydaları

Otomatik dağıtım ve testler gerçekleştirerek verimliliği artırır.
En son yazılım sürümünü destekleyerek risklere karşı önlem alır.
Teslim süreleri kısalır.
Kaynak daha verimli kullanılır.

API ?

Mustafa Emre Başar — Tue, 17 Aug 2021 12:57:00 +0000

API ve API Yönetimi

Application Programing Interface
Yazılımın asıl çalışma şekli ve karmaşıklığı ile ilgilenmeden, bu yazılımla iletişim kurma yoludur
Bu yapı sayesinde yazılım programları birbirlerine istek gönderebilir ve gelen istekleri işleyebilir.
API yönetiminin 4 temel unsuru vardır;
- Gateway : WebClient ile iletişimde olduğu service veya sistem arasında bulunur. Gerçekleşen requestlerin kontrolünü sağlar.
- Developer Portal : Geliştiricilerin API ile alakalı belgelemeleri paylaşabilecekleri bir platformdur.
- Life Cycle Manager : API gerçekleşimi boyunca adımların doğruluğunu kontrol eder.
- Reporting Analytic: API performansı hakkında gözlemleme yapmayı sağlar.

OPEN API

Belirli tanımlamaları kullanarak(YAML veya JSON dosyaları),API iç yapısında neler olduğunu anlamaya gerek kalmadan ,API kullanımı gerçekleştirilir.
Kolay entegrasyon sayesinde kısa sürede kullanıma hazır hale gelebilirler.
Bulut tabanlı yapısı, internet erişimi olan her yerde kullanıma izin verir.

REST API

Temel olarak Client ve Server arasında iletişim oluşturmak için kullanılır
REST açılımı Representational State Transfer .
RESTFUL Service, iletişim kurmak için REST kullanan bir Service demektir.

Faydaları

Basit ve standartlaştırılmış, projeniz için yapılandırması kolay.
Scalable and stateles, Service ne kadar karmaşık olursa olsun veya hangi veriler hangi durumda olursa olsun kullanılabilir.
Yüksek performans.

Genel Konsept

Server ve Client arasındaki iletişim, client tarafından yollanan request ve buna cevap olarak server tarafından verilen response ile sağlanır.
Client ve server arası iletişimdeki CRUD operasyonlarını HTTP metodları ile yönetir
Client tarafından gönderilen request;
- Operasyon(Http metodlarından bir tanesi)
- Endpoint
- Parametler/Body
- Header içerir.
Server tarafından gönderilen response JSON formatında bir yanıt olur.