DonanımHaber

mikroservis etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
mikroservis etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

Spring Cloud Stream ile Spring Cloud Projemde Kod Örnekleri İle Event Driven Mimari

2024 yılında, kafka kullanan bir Spring Cloud microservice projemiz var. Event driven architecture kurmak istiyoruz. Event'lerın yanında kafka ile ms'ler arası mesajlarda iletmek istiyoruz. Bazı ms'lerim producer iken, bazı ms'lerim consumer durumunda. Event ve message'ların formatı ne olmalı? Serialization ve deserialization nasıl yapılmalı? Pub-Sub sistemi nasıl kurulmalı? Projenin bağımlılıkları neler olmalı? Spring boot ms'lerimde implementesyon nasıl olmalı?



Spring Cloud ve Apache Kafka kullanarak event-driven mimari kurarken dikkate almanız gereken birkaç önemli nokta bulunmaktadır. Bu mimari, mikroservisler arasında asenkron iletişim sağlayarak sistemlerin daha esnek ve ölçeklenebilir olmasına yardımcı olur. Aşağıda, bir event-driven mimari kurulumunda dikkate almanız gereken adımlar ve uygulama detayları bulunmaktadır:


1. Event ve Mesaj Formatı

JSON: Kolayca okunabilir ve insan tarafından anlaşılır. Farklı platformlar ve diller arasında geniş destek görür.

Avro: Schema tabanlı bir serialization framework’üdür. Veri yapısını ve türlerini tanımlamak için schema kullanır, bu da verilerin daha kompakt olmasını ve hızlı işlenmesini sağlar.

Protobuf: Google tarafından geliştirilen, veri yapılarını sıkı bir şekilde tanımlayan ve verileri çok kompakt bir biçimde serialize eden bir sistemdir.

2. Serialization ve Deserialization

Apache Kafka, veri serializasyonu ve deserializasyonu için kendi Serializer ve Deserializer sınıflarını sağlar. Spring Kafka, bu işlemleri daha da kolaylaştırır ve Spring'in @KafkaListener ve KafkaTemplate kullanımı ile entegre eder.


3. Pub-Sub Sistemi Kurulumu

Topic Oluşturma: İletişim kurulacak her bir event veya mesaj türü için Kafka'da bir topic oluşturulmalıdır.

Producer Konfigürasyonu: Mikroservislerin producer olarak ayarlanması, Kafka'ya mesaj göndermek için KafkaTemplate kullanılmalıdır.

Consumer Konfigürasyonu: Mikroservislerin consumer olarak ayarlanması, mesajları almak için @KafkaListener anotasyonu kullanılmalıdır.

4. Projenin Bağımlılıkları

Spring Boot mikroservisleriniz için Maven veya Gradle bağımlılıklarınız şunları içermelidir:


xml

Copy code

<!-- Kafka -->

<dependency>

    <groupId>org.springframework.kafka</groupId>

    <artifactId>spring-kafka</artifactId>

</dependency>

<!-- Kafka Streams (Eğer stream işlemleri yapılacaksa) -->

<dependency>

    <groupId>org.springframework.kafka</groupId>

    <artifactId>spring-kafka-streams</artifactId>

</dependency>

5. Spring Boot Mikroservislerde Implementasyon

Producer Konfigürasyonu: KafkaTemplate kullanarak mesaj gönderme işlemleri için bir servis sınıfı oluşturulur.

Consumer Konfigürasyonu: @KafkaListener anotasyonu ile mesajları dinleyen bir metot tanımlanır. Bu metod, belirli bir topic'ten mesajları alır ve işler.

6. İyi Uygulama Örnekleri

Idempotence ve Deduplication: Mesaj işleme idempotent olmalıdır; yani, aynı mesaj birden fazla kez işlense bile, yalnızca bir kez etki eder.

Error Handling: Hatalı mesajların nasıl ele alınacağını planlayın. Örneğin, bir hata kuyruğuna yönlendirme veya yeniden deneme mekanizmaları.

Monitoring ve Logging: Kafka ve mikroservislerinizin durumunu izlemek için uygun araçları ve yöntemleri kullanın.

Bu yapıyı kurarken, Spring Cloud Stream gibi daha yüksek seviyeli abstraksiyonlar sağlayan kütüphaneleri de değerlendirebilirsiniz. Bu, Kafka ile iletişim kurarken daha az boilerplate kodu ile çalışmanızı sağlayabilir ve daha hızlı geliştirme yapmanıza olanak tanır.


Spring Cloud Stream, Spring Cloud ve Apache Kafka kullanarak event-driven mikroservisler geliştirmek için daha yüksek seviyeli bir abstraksiyon sağlar. Bu, konfigürasyon ve kodlama yükünü azaltırken, mesajlaşma sistemleri arasında kolay geçiş yapmanıza olanak tanır. Spring Cloud Stream ile çalışırken dikkate almanız gereken temel kavramlar şunlardır:


Spring Cloud Stream ile Çalışmak

Binder Konfigürasyonu

Spring Cloud Stream, mesajlaşma sistemlerine (Kafka, RabbitMQ vb.) bağlanmak için "Binder" kavramını kullanır. Bu, uygulamanızın hangi mesajlaşma sistemiyle iletişim kuracağını belirlemenize olanak tanır. Kafka için spring-cloud-stream-binder-kafka bağımlılığını projenize eklemeniz gerekir:


xml

Copy code

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-stream-binder-kafka</artifactId>

</dependency>

Uygulama Yapılandırması

Spring Cloud Stream, application.properties veya application.yml dosyasında yapılandırılabilir. Örneğin, Kafka ile çalışırken, broker adresleri, topic isimleri ve diğer Kafka özellikleri bu dosyada tanımlanır.


StreamListener ve EnableBinding

Spring Cloud Stream, mesajları işlemek için @StreamListener anotasyonunu kullanır. Ayrıca, @EnableBinding anotasyonu ile hangi kanalların kullanılacağını belirtirsiniz. Örneğin, bir mesajı dinlemek ve işlemek için bir kanala bağlanabilirsiniz.


java

Copy code

@EnableBinding(Processor.class)

public class MyMessageProcessor {


    @StreamListener(target = Processor.INPUT)

    public void processMyMessage(String message) {

        // Mesaj işleme mantığı

    }

}

Mesaj Gönderme

Mesaj göndermek için, Spring Cloud Stream StreamBridge veya @Output anotasyonu kullanılarak tanımlanan bir kanal üzerinden MessageChannel aracılığıyla yapılabilir. StreamBridge kullanımı, programatik olarak mesaj göndermenize olanak tanır.


java

Copy code

@Autowired

private StreamBridge streamBridge;


public void sendMessage(String message) {

    streamBridge.send("myChannel", message);

}

İyi Uygulama Örnekleri ve Dikkat Edilmesi Gerekenler

Dinamik Özellikler: Spring Cloud Stream, runtime'da özellikleri değiştirmek için destek sunar. Bu, canlı sistemlerde ayarları değiştirmenize olanak tanır.

Partitioning: Kafka ile çalışırken, mesajların birden fazla partition arasında dengeli bir şekilde dağıtılmasını sağlayarak işlem kapasitesini artırabilirsiniz.

Güvenlik: Kafka ve Spring Cloud Stream kullanırken, mesajlaşma sistemlerinize erişimi güvenli hale getirmek için uygun güvenlik önlemlerini alın.

Test Desteği: Spring Cloud Stream, mikroservislerinizin mesajlaşma yönlerini test etmek için araçlar ve metodolojiler sağlar. Bu, entegrasyon testleri sırasında faydalıdır.

Spring Cloud Stream kullanımı, Kafka ve diğer mesajlaşma sistemleri ile çalışırken, uygulamanızın bağlantı detaylarından soyutlanmasını sağlar. Bu, kodunuzu daha temiz, yönetilebilir ve adaptif hale getirirken, aynı zamanda geliştirme sürecini hızlandırır.


Spring Cloud Stream'in sunduğu esneklik ve kolay kullanımın yanı sıra, bir mikroservis mimarisinde event-driven iletişim kurarken dikkate almanız gereken ileri düzey konseptler ve en iyi uygulamalar da bulunmaktadır. Bu konseptler, sisteminizin ölçeklenebilirliğini, dayanıklılığını ve bakım kolaylığını artırabilir.


İleri Düzey Konseptler ve En İyi Uygulamalar

Error Handling ve Retry Mechanisms

Spring Cloud Stream, hata yönetimi için kapsamlı destek sunar. Mesaj işleme sırasında bir hata meydana geldiğinde, sistem otomatik olarak yeniden deneme (retry) mekanizmalarını devreye sokabilir veya hatalı mesajları bir "dead letter" kuyruğuna yönlendirebilir. Bu işlevsellik, application.properties dosyasında yapılandırılabilir ve işlem mantığınızın dayanıklılığını artırır.


Dinamik Özellikler

Spring Cloud Stream, runtime sırasında özelliklerin dinamik olarak değiştirilmesini destekler. Bu, canlı sistemlerde, uygulamanızın davranışını değiştirmenize olanak tanırken, sistemin yeniden başlatılmasına gerek kalmaz. Örneğin, log seviyeleri, yeniden deneme politikaları ve hatta bağlı olduğunuz topic'ler gibi özellikler dinamik olarak yönetilebilir.


Monitoring ve Logging

Mikroservis mimarisinde, her bir servisin ve mesajlaşma altyapısının izlenmesi ve loglanması kritik öneme sahiptir. Spring Cloud Stream, Spring Boot'un Actuator desteği ile entegre çalışır, bu da sağlık durumu, metrikler ve loglama için kapsamlı destek sağlar. Kafka'nın kendi monitoring araçları ile birlikte, bu özellikler sistem genelinde görünürlüğü ve izlenebilirliği artırır.


Event Sourcing ve CQRS

Event-driven mimarilerde, Event Sourcing ve Command Query Responsibility Segregation (CQRS) desenleri sıkça kullanılır. Spring Cloud Stream, bu desenlerin uygulanmasını kolaylaştırabilir. Event Sourcing, sistemdeki değişiklikleri bir dizi event olarak kaydetmeyi, CQRS ise okuma ve yazma işlemlerini ayrı modeller üzerinden yönetmeyi ifade eder. Bu yaklaşımlar, sistemlerin ölçeklenebilirliğini ve performansını artırabilir.


Multi-Binder Destek

Bir uygulama içinde birden fazla mesajlaşma sistemiyle iletişim kurma ihtiyacı doğabilir. Spring Cloud Stream, aynı uygulama içinde birden fazla binder (Kafka, RabbitMQ vb.) kullanımını destekler. Bu, farklı sistemler arasında köprü kurmanıza ve mesajlaşma altyapınızı esnek bir şekilde genişletmenize olanak tanır.


Sonuç

Spring Cloud Stream ve Apache Kafka kullanarak kurulan event-driven mimari, mikroservisler arasında güçlü, esnek ve ölçeklenebilir asenkron iletişim sağlar. En iyi uygulamaları ve ileri düzey konseptleri takip etmek, sisteminizin performansını, dayanıklılığını ve bakım kolaylığını artırır. Sisteminizi tasarlarken bu prensipleri ve uygulamaları dikkate almak, uzun vadede faydalar sağlayacaktır.


User

Örnek 2 ms'li bir spring cloud, kafka ve spring cloud stream senaryosu ve kodu

ChatGPT

Bir Spring Cloud, Kafka ve Spring Cloud Stream kullanarak basit bir senaryo üzerinden gitmek, konseptleri daha iyi anlamanıza yardımcı olacaktır. Bu örnekte, iki mikroservisimiz olacak: biri mesaj üreten bir Producer ve diğeri bu mesajları tüketen bir Consumer.


Ortam Kurulumu

Öncelikle, Apache Kafka'nın sisteminizde çalışır durumda olduğundan emin olun. Kafka ve Zookeeper'ı başlatmak için resmi Kafka Quickstart dokümantasyonunu takip edebilirsiniz.


Maven Bağımlılıkları

Her iki mikroservis için pom.xml dosyasına Spring Cloud Stream ve Kafka bağımlılıklarını ekleyin.


xml

Copy code

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-stream-kafka</artifactId>

</dependency>

Producer Servisi

Producer mikroservisi, belirli aralıklarla mesajları bir Kafka topic'ine gönderir.


Application.properties

properties

Copy code

spring.cloud.stream.bindings.output.destination=my-topic

spring.cloud.stream.kafka.binder.brokers=localhost:9092

Producer Kodu

java

Copy code

package com.example.producer;


import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.cloud.stream.function.StreamBridge;

import org.springframework.scheduling.annotation.Scheduled;

import org.springframework.stereotype.Component;


@Component

public class MessageProducer {


    @Autowired

    private StreamBridge streamBridge;


    @Scheduled(fixedDelay = 5000)

    public void sendMessage() {

        String message = "Hello from Producer at " + System.currentTimeMillis();

        streamBridge.send("output", message);

        System.out.println("Sent: " + message);

    }

}

@Scheduled anotasyonu ile sendMessage metodunu her 5 saniyede bir çalışacak şekilde ayarlayabilirsiniz.


Consumer Servisi

Consumer mikroservisi, Producer tarafından gönderilen mesajları tüketir.


Application.properties

properties

Copy code

spring.cloud.stream.bindings.input.destination=my-topic

spring.cloud.stream.kafka.binder.brokers=localhost:9092

Consumer Kodu

java

Copy code

package com.example.consumer;


import org.springframework.cloud.stream.annotation.StreamListener;

import org.springframework.cloud.stream.messaging.Sink;

import org.springframework.stereotype.Component;


@Component

public class MessageConsumer {


    @StreamListener(Sink.INPUT)

    public void handleMessage(String message) {

        System.out.println("Received: " + message);

    }

}

Uygulamaları Çalıştırmak

Her iki uygulamayı da Spring Boot uygulaması olarak başlatın. Producer uygulaması, mesajları Kafka topic'ine gönderirken, Consumer uygulaması bu mesajları alacak ve konsola yazdıracaktır.


Sonuç

Bu basit senaryo, bir Producer ve bir Consumer kullanarak Spring Cloud Stream ve Kafka ile event-driven mimari kurulumunun temellerini göstermektedir. Gerçek dünya uygulamalarında, bu yapı daha karmaşık iş akışlarına, hata yönetimi mekanizmalarına ve performans iyileştirmelerine genişletilebilir.


User

Örnek bir event için json yazar mısın?

ChatGPT

Elbette, bir mikroservis mimarisinde kullanılabilecek örnek bir event için basit bir JSON formatı aşağıdaki gibidir. Bu örnek, bir sipariş sisteminde bir siparişin başarıyla oluşturulduğunu temsil eden bir event'i göstermektedir. JSON formatı, event'in tipini, zaman damgasını ve siparişle ilgili detayları içerir.


json

Copy code

{

  "eventType": "OrderCreated",

  "timestamp": "2024-02-04T12:34:56Z",

  "orderId": "123456",

  "userId": "78910",

  "orderDetails": {

    "totalAmount": 299.99,

    "currency": "USD",

    "items": [

      {

        "itemId": "001",

        "productName": "Wireless Mouse",

        "quantity": 1,

        "price": 29.99

      },

      {

        "itemId": "002",

        "productName": "Keyboard",

        "quantity": 1,

        "price": 49.99

      },

      {

        "itemId": "003",

        "productName": "USB-C Charging Cable",

        "quantity": 2,

        "price": 19.99

      }

    ]

  }

}

Bu JSON yapısı, bir event'in temel unsurlarını içerir:


eventType: Event'in tipi, bu durumda bir siparişin oluşturulduğunu belirten "OrderCreated".

timestamp: Event'in oluşturulduğu zaman damgası. ISO 8601 formatında.

orderId: Oluşturulan siparişin benzersiz kimliği.

userId: Siparişi oluşturan kullanıcının kimliği.

orderDetails: Siparişle ilgili detayları içeren bir nesne. Bu nesne, siparişin toplam tutarını, para birimini ve siparişteki ürünlerin bir listesini içerir.

Bu tür bir JSON yapısı, mikroservisler arasında iletişim kurarken veya bir event sourcing sisteminde event'leri saklarken kullanılabilir. Event'in yapısı, uygulamanızın ihtiyaçlarına göre özelleştirilebilir.


Bu event'i spring cloud stream ile nasıl gönderir ve okurum?


Spring Cloud Stream ile bir JSON event'ini göndermek ve okumak için, Spring Boot uygulamanızda birkaç adımı takip etmeniz gerekmektedir. Bu işlemleri gerçekleştirmek için önce sisteminizi yapılandırmanız, ardından event gönderme ve okuma için kodunuzu yazmanız gerekir. Aşağıda, bir önceki örnekte oluşturduğumuz JSON event'ini kullanarak bir Producer ve bir Consumer servisi oluşturacağız.


Producer Servisi Yapılandırması ve Kodu

Öncelikle, event'leri Kafka'ya gönderen bir Producer servisi oluşturalım. Bu servis, önceden tanımladığımız JSON event'ini kullanacak.


application.properties Yapılandırması

properties

Copy code

spring.cloud.stream.bindings.output-out-0.destination=order-events

spring.cloud.stream.kafka.binder.brokers=localhost:9092

Bu yapılandırma, order-events adlı Kafka topic'ine mesaj göndermek için kullanılacak output kanalını tanımlar.


Event Gönderme Kodu

java

Copy code

package com.example.producer;


import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.messaging.Message;

import org.springframework.messaging.support.MessageBuilder;

import org.springframework.cloud.stream.function.StreamBridge;

import org.springframework.stereotype.Service;


@Service

public class OrderEventProducer {


    @Autowired

    private StreamBridge streamBridge;


    public void sendOrderCreatedEvent(OrderCreatedEvent orderEvent) {

        Message<OrderCreatedEvent> message = MessageBuilder.withPayload(orderEvent).build();

        streamBridge.send("output-out-0", message);

    }

}

OrderCreatedEvent sınıfınız, örnek JSON event'imize karşılık gelen bir Java sınıfıdır. Bu sınıfı, JSON event'inizdeki alanları temsil edecek şekilde oluşturmalısınız.


Consumer Servisi Yapılandırması ve Kodu

Şimdi, Kafka'dan event'leri okuyan bir Consumer servisi oluşturalım.


application.properties Yapılandırması

properties

Copy code

spring.cloud.stream.bindings.input-in-0.destination=order-events

spring.cloud.stream.kafka.binder.brokers=localhost:9092

Bu yapılandırma, order-events adlı Kafka topic'inden mesaj almak için kullanılacak input kanalını tanımlar.


Event Okuma Kodu

java

Copy code

package com.example.consumer;


import org.springframework.cloud.stream.annotation.StreamListener;

import org.springframework.cloud.stream.messaging.Sink;

import org.springframework.stereotype.Component;


@Component

public class OrderEventConsumer {


    @StreamListener(Sink.INPUT)

    public void handleOrderCreatedEvent(OrderCreatedEvent orderEvent) {

        System.out.println("Received order event: " + orderEvent);

    }

}

Bu kod parçası, order-events topic'inden gelen mesajları dinler ve konsola yazdırır. OrderCreatedEvent sınıfını, JSON event'inizdeki alanları temsil edecek şekilde oluşturmalısınız ve bu sınıf @StreamListener metodunun parametresi olarak kullanılmalıdır.


JSON Serileştirme/Çözümleme

Spring Cloud Stream otomatik olarak Java nesnelerini JSON'a serileştirir ve JSON'dan Java nesnelerine çözümler. Ancak, bu işlevsellikten faydalanmak için spring-cloud-stream bağımlılığınızın yanı sıra jackson-databind gibi bir JSON işleme kütüphanesine ihtiyacınız olacaktır. Bu genellikle Spring Boot'un spring-boot-starter-web bağımlılığı ile otomatik olarak sağlanır.


Notlar

Örnek kodlar, Spring Cloud Stream'in temel kullanımını göstermektedir ve gerçek uygulama geliştirme sırasında uygulamanızın ihtiyaçlarına göre özelleştirilmelidir.

Kafka ve Zookeeper'ın çalışır durumda olduğundan ve application.properties dosyasındaki broker adreslerinin doğru yapılandırıldığından emin olun.

OrderCreatedEvent sınıfı, örnek JSON event'inize karşılık gelen bir POJO olmalıdır. Bu sınıf, event içindeki verileri temsil eder ve Spring'in Jackson kütüphanesi tarafından otomatik olarak JSON formatına serileştirilip, JSON'dan Java nesnesine çözümlenebilir. İşte bu sınıfın bir örneği:


OrderCreatedEvent Sınıfı

java

Copy code

package com.example.domain;


import java.math.BigDecimal;

import java.util.List;


public class OrderCreatedEvent {


    private String eventType;

    private String timestamp;

    private String orderId;

    private String userId;

    private OrderDetails orderDetails;


    // Getter'lar ve Setter'lar


    public static class OrderDetails {

        private BigDecimal totalAmount;

        private String currency;

        private List<Item> items;


        // Getter'lar ve Setter'lar

    }


    public static class Item {

        private String itemId;

        private String productName;

        private int quantity;

        private BigDecimal price;


        // Getter'lar ve Setter'lar

    }

}

Bu sınıf, önceki JSON örneğinizde belirtilen alanları temsil eder. OrderCreatedEvent, OrderDetails ve Item sınıfları iç içe tanımlanmıştır. Bu sınıfların her biri için gerekli getter ve setter metodlarını eklemeyi unutmayın.


Uygulamaları Çalıştırma

Uygulamalarınızı çalıştırmadan önce, Kafka'nın ve gerekirse Zookeeper'ın çalışır durumda olduğundan emin olun. Daha sonra, Producer ve Consumer mikroservislerinizi Spring Boot uygulaması olarak başlatın:


Producer uygulaması başladığında, OrderEventProducer sınıfındaki sendOrderCreatedEvent metodunu çağırarak bir OrderCreatedEvent mesajı gönderebilirsiniz. Bu, order-events topic'ine bir mesaj gönderir.

Consumer uygulaması bu mesajı alır ve OrderEventConsumer sınıfındaki handleOrderCreatedEvent metodunda işler. Alınan mesaj konsola yazdırılır.

Bu basit örnek, Spring Cloud Stream ile Kafka üzerinden JSON tabanlı mesajlaşmanın nasıl gerçekleştirileceğini göstermektedir. Gerçek bir uygulama senaryosunda, mesaj gönderme ve alma işlemlerini tetiklemek için HTTP endpoint'leri, zamanlanmış görevler veya sistem içi diğer olaylar kullanabilirsiniz.


Özet

Spring Cloud Stream, Kafka gibi mesajlaşma sistemleri ile çalışırken, mikroservisler arası iletişimi kolaylaştıran güçlü bir araçtır. Bu rehberde gösterilen yapılandırma ve kod örnekleri, bu teknolojileri kullanarak event-driven mikroservis mimarileri geliştirmenin temellerini sağlar. JSON tabanlı mesajların serileştirilmesi, gönderilmesi, alınması ve çözümlenmesi işlemleri, Spring Cloud Stream'in otomatik serileştirme ve çözümleme özellikleri sayesinde kolaylaştırılmıştır. Bu özellikler, modern mikroservis uygulamalarınızda esnek ve ölçeklenebilir event-driven mimariler oluşturmanıza olanak tanır.

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.








Microservice mimarsi nedir? Avantajları nelerdir?

Merhaba, bu yazımda sizlere yazılım dünyasında yeni bir trend olan ve benim de yeni olduğum microservice mimarisini anlatmaya çalışacağım. Fırsat buldukça farklı kaynaklardan yararlanarak güncelleiyeceğim makalemein geniş kapsamlı olmasını umuyorum.
Mayıs 2011'de Venedik yakınlarında düzenlenen yazılım mimarları çalıştayında katılımcıları çoğu yakın zamanda keşfetikleri ortak mimari tarzı olarak gördükleri mimariyi anlatırken 'microservice' ismini kullandılar.Mayıs 2012'de aynı grup en uygun isim olarak 'microservices' adına karar verdi. Aynı zamanlarda Fred George'ın yaptığı gibi, Ames Lewis Microservices-Java, Unix Way adı altında Mart 2012'de bir vaka çalışması olarak Kraków'da bu fikirlerin bazılarını sundu. Netflix'den Adrian Cockcroft web tarafında tanımlamalar yaparak yaklaşımı ince tanecikli SOA (fine grained SOA) olarak çevirebileceğimiz bir tanım yaptı.
Microservice'ler, bilinen bir diğer adıyla microservice mimariler gevşek bağımlı servislerin bir araya geldiği yazılım mimarisi stilidir.Microservices mimarisi felsefesi 'bir şeyi yapın ve bunu iyi yapın' Unix felsefesine eşittir.

Microservice mimarisinde, servislerin belli sınırlar içinde fonksiyonu belli, ve protokolleri hafif siklet olmalıdır.
Bir uygulamayı farklı küçük servislere bölmek modülariteyi arttırır ve uygulamanın anlaşılmasını kolaylaştırıp, uygulamaının geliştirilmesi ve test edilmesini kolaylaştırır. Bir uygulamayı aynı anda parelel olarak farklı servisler üzerinde farklı küçük takımların geliştirme yapmasına olanak sağlarken, uygulama yükleme (deploy) ve genişletilebilirlik (scale) işlemlerinde bu takımların bağımsız olmalarını da olanak sağlamaktadır. Mimari takımlara ayrıca refactoring'i sürekli halde yapmalarına olanak sağlarken , continuous delivery ve continuous deployment'a da imkan verir.



Microservice mimarinin yeni bir yapı olması nedniyle henüz yazılım dünyasında ortak bir tanımı bulunmamakla beraber, resmi bir tanımı da mevcut değildir. Sıklıkla bahsedilen tanımlamaları sıralayacak olursak :
Micrsoervice mimarisindeki (MSA-Microservice architecture) servisler HTTP gibi teknoloji bağımsız protokoller kullanarak bir ağ üzerinde birbiriyle haberleşen belli işleri yapan işlemler (process) lerdir.
MSA'da servisler birbirinden bağımsız ortama yüklenebilmelidirler (deploy).
Servisler birbirinin yerine kolayca geçebilmelidirler.(replace)
Servisler yeteneklerine göre organize edilebilimelidirler. (Kullanıcı arayüzü, tavsiye, lojistik, faturalandırma gibi)
Servisler ihtiyaçlarına göre farklı programlama dilleri kullanılarak kodlanabilir,farklı databaseleri kullanabilir ve farklı donanım ve yazılım çevrelerini kullanabilirler.
Servisler boyutları küçük, mesajlaşma etkin, bağlamlarda bazında sınırlandırılmış, otonom geliştirilen, bağımsız yüklenebilir, merkezi olmayan ve otomatize edilmiş süreçlerle build ve release edilen şekildedir.
Microservice Mimari :
Doğal olarak modülerdir.
Sürekli dağıtım yazılım geliştirme işlemleri destekler.Uygulamanın küçük parçasında yapılan değişiklik sadece bir servisin yeniden build edilmesi ve yeniden dağıtılmasını gerektirir.
Birçok yazılım prensibinin birleşimidir. Bunlar fine-grained interfaces (bağımsız deploy edilebilien servisler), Bussiness Driven Development (domain-driven desgin gibi),IDEAL bulut aplikasyon mimarileri, çok dilli programlama ve devamlılık, hafif siklet konteyner geliştirimi (lightweight container deployment), merkezi olmayan dağıtım (decentralized continuous delivery), ve DEVOps ile bütünsel hizmet gözetimi.



Kaynak:https://en.wikipedia.org/wiki/Microservices

Bonus :


Rastgele İçerik

© tüm hakları saklıdır
made with by templateszoo