SlideShare a Scribd company logo
1 of 33
Microservices Architecture
ddemirel / 28.02.2018
Nedir?
Bir uygulama geliştirme mimarisidir.
Birbirleriyle gevşek bağ ile bağlı uygulama parçacıklarının oluşturduğu mimari olarak
da tanımlanabilir.
Microservices mimarisi büyük, karmaşık uygulamaların sürekli delivery/deploy
yapılabilmesini mümkün kılar. Ayrıca şirketin ileriye dönük teknoloji gelişimini
kolaylıkla yapılabilmesine imkan sunar.
Microservislerin mimarisel bazı problemleri vardır. Microservices mimarisini anlamak
ve uygulamak için çeşitli patternler vardır. Bunun amacı vardır:
1- Uygulamanız için microservices mimarisinin uygun olup olmadığına karar
vermenize yardımcı olmak
2- Microservices mimarisinin başarıyla kullanımanıza yardımcı olmak
Microservisin Amacı/Özellikleri
En temel amaç geliştirmeyi hızlandırmaktır. Bunu sağlayan en önemli unsur ise
continuous delivery/deployment’tır.
Microservices başarılı/hızlı uygulama geliştirmeyi iki şekilde sağlar;
1- Testi basitleştirip ve servislerin bağımsız olarak konumlanmasını sağlayarak
2- Takım organizasyonunu, her biri bir veya daha fazla hizmetten sorumlu küçük,
özerk takımlar şeklinde yapılandırarak sağlar.
Bu otomatik olarak sağlanan bir şey değildir. Bunu sağlamadaki en büyük unsur
uygulamayı servislere dikkatli bir şekilde ayırmaktır.
Microservisin Amacı/Özellikleri
Bir servis küçük bir takımın geliştirip test edebileceği kadar küçük olmalıdır. Bunu
sağlamak için «Single Responsibility Principle»(Tek Sorululuk Prensibi) bize yol
gösterici olabilir.
Uygulama aynı zamanda yeni eklenen ya da değişikliğe sebep olan gereksinimlerin
çoğunu tek bir servisi etkileyecek şekilde parçalanmalıdır. Bunun nedeni birden çok
ekip üzerinde koordinasyon gerektiren birden fazla servisi etkileyen değişikliklerin
geliştirmeyi yavaşlatmasıdır.
Patternler
• Decomposition – Ayrıştırma
• Deployment
• Cross Cutting Concerns
• Communication Style
• External API
• Service Discovery
• Reliability – Güvenilirlik
• Data Management
• Security
• Testing
• Observability
• UI
Decomposition – Ayrıştırma
• Decompose by business capability
• İş sorumluluklarına göre ayırma. Birçok organizasyonda bu konu multi-level
hiyerarşi ile ayrılmıştır. Örneğin ; Ürün/Hizmet geliştirme, Ürün/Hizmet teslimi,
Talep Yönetimi vb.
• Decompose by subdomain
• Domain-Driven-Design yaklaşımı ile ayrıştırma yapılır. DDD uygulamayı
domain olarak varsayar. Bir domain birden fazla alt domainlerden oluşur. Her
bir sub domain uygulamanın modüllerini ifade eder. Alt domainler aşağıdaki
yaklaşımla tasarlanır;
• Core : İşin en değerli ve en önemli bölümlerini ifade eder
• Supporting : Uygulamanın ana konularıyla alakalı süreçlerdir.
• Generic : İşe özgü olmayan ve temel olması gereken konulardır
Deployment
• İhtiyaçlar
• Servisler birçok farklı dil,framework ve framework versiyonu ile yazılmıştır
• Servisler verim ve kullanılabilirlik açısından birden fazla servisten oluşur
• Servisler birbirinden bağımsız olarak deploy edilebilmeli ve scale edilebilmeli
• Servis instansları diğerlerinden izole olmalı
• Bir servisi hızlıca build edip yükleyebilmelisiniz
• Bir hizmetin kullanabileceği sistem kaynalarını sınırlayabilmelisiniz
• Her servis instansını izleyebilmelisiniz
• Deploymentı güvenli yapabilmelisiniz
• Uygulamayı olabildiğince düşük maaliyetle deploy edebilmelisiniz
• Yöntemler
• Multiple service instances per host(physical or virtual)
• Service instance per host
• Service instance per VM
• Service instance per Container
• Serverless deployment
• Service deployment platform
Cross Cutting Concerns
• Örnekler:
• Externalized configuration
• Logging
• Health checks
• Metrics
• Distrubuted tracing
• Bunlar gibi generic CCC’lerin yanında uygulamaya özel CCC konuları da çıkabilir.
Örneğin RDBMS kullanan bir uygulamada connection pool kullanmak gibi.
• Bu konuların uygulamanın tasarım aşamasında oturtulması gereklidir ileriye dönük
refactoring yapmak maliyetli olabilir.
• Bunlara bağlı olarak:
• Yeni bir microservices oluşturmak hızlı ve kolay olmalıdır
• Yeni microsevice CCC’leri kapsayacak şekilde olmalıdır
Communication Style
• Servisler istemcilerden gelen istekleri yerine getirmelidir. Hatta bu istekleri yerine
getirirken diğer servisler ile çalışması gerekebilir. Bu durumda süreçler arası iletişim
yapmaları gerekmektedir.
• Remote procedure invocation
• REST,gRPC,Apache Thrift
• Messaging
• Apache Kafka, RabbitMQ
• Domain-specific protocol
• Email : SMTP, IMAP
• Media Streaming : RTMP, HLS, HDS
External API - API Gateway / Backend for Front-End
• Faydaları
• Encapsulate internal services
• Load Balancing
• Authentication
• Monitoring
• Caching
• Örneğin microservices mimarisi ile online store geliştiriyoruz ve ürün detay sayfası
implemente ediyoruz. Bu sayfanın iki farklı arayüz ile hizmet vermesi isteniyor:
• HTML5/Javascript based web page
• Rest API ile çalışan Native Android ve Iphone client
• Ayrıca uygulama 3.parti uygulamaların kullanması için ürün detaylarını Rest API ile
servis etmelidir.
• Ürün detay sayfasında birçok bilgiye ihtiyaç vardır:
• Temel bilgiler : Başlık, yazar, fiyat
• Satış geçmişi
• Stok durumu
• Satın alma opsiyonları : hard copy/e-book
• Genellikle bu kitapla birlikte satın alınan ürünler
• Kitap yorumları
• Satıcılar
External API - API Gateway / Backend for Front-End
• Microservices mimarisi kullanıldığı için ürün bilgileri birden fazla hizmete
yayılmıştır. Örneğin;
• Product Info Service - basic information about the product such as title, author
• Pricing Service - product price
• Order service - purchase history for product
• Inventory service - product availability
• Review service - customer reviews
• Sonuç olarak ürün ayrıntılarını gösteren uygulama bu servislerin tümünden bilgi
almak zorundadır.
External API - API Gateway / Backend for Front-End
• Microservices mimarisi kullanan bir uygulamanın clientleri servislere nasıl erişir?
• Farklı clientler farklı datalara ihtiyaçları vardır. Örneğin masaüstü bilgisayardan
açılan ürün detayları sayfasında mobil uygulamadan daha çok veri vardır.
• Farklı clientler için farklı network performans problemleri oluşabilir.
• Servis instanslarının sayıları dinamik olarak değişebilir(host+port)
• Servislerin ayrıştırılması zamanla değişebilir ve bunun clientlerdan bağımsız
olması gerekir
• Servisler farklı iletişim protokolleri kullanabilir
External API - API Gateway / Backend for Front-End
• Bu durumlar için clientlerin apilere erişirken tek giriş noktasını bilmesi gerekir.
Gateway istekleri iki şekilde karşılayabilir; proxy ya da route
External API - API Gateway / Backend for Front-End
• Gateway’ler her cliente ortak bir apı sunmak yerine cliente uygun apileri sunabilir.
• Gatewayler ayrıca güvenlik katmanı olarak da kullanılabilir.
External API - API Gateway / Backend for Front-End
• Clientler servislerin nasıl bölümlendiğiniden izole eder
• Clientlerin servis adreslerini bilmesini gerekliliğini ortadan kaldırır
• Her istemci için uygun API’yi sağlar
• Complexitiyi artırabilir, doğru yönetilmesi gereken bir modeldir
• Request/response süreleri artabilir. Ama bu süre ihmal edilebilecek kadar azdır.
Service Discovery
• Client-side discovery
• Server-side discovery
• Service registry
• Self registration
• 3rd party registration
Reliability
• Circuit Breaker
• Servislerde endpointlerde oluşacak hataların sistemi tamamen kilitlemesini
önlemek için kullanılmaktadır.
• Eğer servis enpointinde belirli sayıda hata gerçekleşirse o endopointe gelen
requestleri belirli süre engelliyoruz, o süre sonunda tekrar kontrol ediliyor eğer
hata düzelmişse normal akışına devam ediyor.
• Bu sayede endpointin kullandığı sistem kaynaklarını gereksiz kullanmayı ve
sistem içerisindeki cascade hatalar oluşmasının önüne geçiyoruz
• Retry : Genelde farklı sistemlere bağlı işlem yaparken bazı durumlarda geçici
hatalar oluşabilir. Bu hataları elemine etmek için retry mekanizması
kullanılarbilir. Örneğin ilk hatadan sonra 3 defa daha deneme yaparak 3.nü n
sonunda başarılı cevap alabiliriz.
• Fallback : Retry sürecini işlettik ve hala hata alıyorsak ve daha önce bir alternatif
yöntem (vazgeçip başka bir yol izlemek) stratejisi belirlediysek bunu devreye
sokabiliriz.
Reliability
Data Management
• Servisler serbestçe geliştirilebilecek ve ölçeklendirilebilecek yapıda olmalıdır. Bunun
için servisler gevşek bir şekilde (loosely coupled) olmalıdır.
• Bazı işlemler birden fazla serviste veri değişikliğini zorunlu kılmaktadır.
• Bazı işlemler birden fazla servisin sahip olduğu veriyi sorgulamalıdır.
• Bazı işlemler birden fazla servisin sahip olduğu veriyi sorgulayıp birleştiriyor
olabilir.
• Veritabanları bazen çoğaltılıp ölçeklenebilir.
• Farklı servislerin farklı depolama gereksinimleri olur. Bazı servisler RDBMS, bazıları
NoSQL, bazıları ise GraphDB’ye ihtiyaç duyabilir.
Data Management
• Solutions
• Database per Service
• Shared database
• Saga
• API Composition
• CQRS
• Event sourcing
• Transaction log tailing
• Database triggers
• Application events
Data Management - SAGA
• SAGA – Distrubuted Transaction
• Her servisin local transactionalarının bir sırasıdır.
• Her servis kendi verisini güncller ve bir sonraki işlemi tetikleyecek message
veya event yayınlar.
• Herhangi bir servisin işlemi başarısız olursa SAGA önceki işlemleri geri alacak
bir dizi telafi işlemi gerçekleştirir.
• Order Service bekleme durumunda
bir sipariş oluşturur
• Customer Service sipariş için kredi
reserv eder
• Order Service reservasyon işlemi
sonucuna göre siparişi onaylar ya
da iptal eder
• CreateOrder saga içinde OrderCreated eventi
yayınlanır, CustomerService CreditReserved ya
da CreditLimitExceeded eventi yayınlar.
Data Management – API Composition
• Birden farklı servisten gelen dataları barındıran sorgulara ihtiyaç olduğunda bunu
en efektif olarak yapmak için API Composer pattern uygulanabilir.
Data Management – CQRS
• CQRS – Command Query Responsibility Segregation
• Uygulama command-side ve query-side olmak üzere ikiye ayrılır. Command-
side insert,update vb. işleri yapar. Query-side ise commandlar sonucu oluşan
eventler ile sorgu datalarını günceller.
Data Management – Event Sourcing
• Temel prensip olarak doğrudan tablolarda entity olarak verileri saklamak yerine
domainler üzerinde gerçekleşen olayları saklamaktır. Yani sipariş oluşturma
sonucunda sipariş için bir tabloya kaydetmek yerine sipariş oluşturuldu eventini
sipariş bilgisi ile birlikte saklar.
• Bu model özellikle dağıtık sistemlerde veri tutarlılığını saklamak için önemli bir
çözümdür. Verinin eventlerini replay ettiğinizde hangi aşamada ne durumda
olduğunu her zaman elde edebilirsiniz.
Security
• Access Token
Testing
• Service Component Test
• Uçtan uca servisleri test etmek zor ve yavaştır. Bunun için servisleri yalıtılmış
olarak kendi başlarına test etmek gerekir.
• Bu kolay ve hızlıdır.
• Bu bazı durumlarda testlerin development ortamında başarılı fakat production
ortamında hatalı olmasına sebep olabilir.
Testing
• Service Integration Contract Test
• Bu patternde her servis kendini kullanan servislerin ona sağladığı test
paketlerini uygulayarak entegrasyon testini sağlamış olur.
Observability
• Log aggregation
• Application metrics
• Audit logging
• Distributed tracing
• Exception tracking
• Health check API
• Log deployments and changes
Observability – Log aggregation
Observability – Distributed tracking
Microservices with Spring Cloud
• Microservices uygulamalarında ihtiyaç duyulan önceki slaytlarda belirttiğimiz
gereksinimleri Spring Boot uygulamalarında kolayca kullanabilmeyi sağlayan
kütüphanedir.
Auth
Admin
Dashboard
Spring Cloud Demo
Kaynak
• http://microservices.io
• https://cloud.spring.io

More Related Content

What's hot

컨텐트 협업플랫폼 Amazon WorkDocs 활용하기 - 박상희 상무, 한글과컴퓨터 / Ben Fitzpatrick, Head of Bu...
컨텐트 협업플랫폼 Amazon WorkDocs 활용하기 - 박상희 상무, 한글과컴퓨터 / Ben Fitzpatrick, Head of Bu...컨텐트 협업플랫폼 Amazon WorkDocs 활용하기 - 박상희 상무, 한글과컴퓨터 / Ben Fitzpatrick, Head of Bu...
컨텐트 협업플랫폼 Amazon WorkDocs 활용하기 - 박상희 상무, 한글과컴퓨터 / Ben Fitzpatrick, Head of Bu...Amazon Web Services Korea
 
Integração contínua com Jenkins
Integração contínua com JenkinsIntegração contínua com Jenkins
Integração contínua com JenkinsAécio Pires
 
Packer + Ansible을 이용한 AMI 생성 및 AutoScaling Group 이미지 교체 이야기
Packer + Ansible을 이용한 AMI 생성 및 AutoScaling Group 이미지 교체 이야기Packer + Ansible을 이용한 AMI 생성 및 AutoScaling Group 이미지 교체 이야기
Packer + Ansible을 이용한 AMI 생성 및 AutoScaling Group 이미지 교체 이야기AWSKRUG - AWS한국사용자모임
 
Awsでのsql高可用構成 Always On
Awsでのsql高可用構成 Always OnAwsでのsql高可用構成 Always On
Awsでのsql高可用構成 Always OnShinodaYukihiro
 
Docker and Kubernetes 101 workshop
Docker and Kubernetes 101 workshopDocker and Kubernetes 101 workshop
Docker and Kubernetes 101 workshopSathish VJ
 
Ibm mq with c# sending and receiving messages
Ibm mq with c# sending and receiving messagesIbm mq with c# sending and receiving messages
Ibm mq with c# sending and receiving messagesShreesha Rao
 
AWS Black Belt Online Seminar 2017 動画配信 on AWS
AWS Black Belt Online Seminar 2017 動画配信 on AWSAWS Black Belt Online Seminar 2017 動画配信 on AWS
AWS Black Belt Online Seminar 2017 動画配信 on AWSAmazon Web Services Japan
 
Kerberos and its application in cross realm operations
Kerberos and its application in cross realm operationsKerberos and its application in cross realm operations
Kerberos and its application in cross realm operationsArunangshu Bhakta
 
Flyway _ A Database Version Management Tool
Flyway _ A Database Version Management ToolFlyway _ A Database Version Management Tool
Flyway _ A Database Version Management ToolKnoldus Inc.
 
ElastiCacheを利用する上でキャッシュをどのように有効に使うべきか
ElastiCacheを利用する上でキャッシュをどのように有効に使うべきかElastiCacheを利用する上でキャッシュをどのように有効に使うべきか
ElastiCacheを利用する上でキャッシュをどのように有効に使うべきかAmazon Web Services Japan
 
실시간 이상탐지를 위한 머신러닝 모델에 Druid _ Imply 활용하기
실시간 이상탐지를 위한 머신러닝 모델에 Druid _ Imply 활용하기실시간 이상탐지를 위한 머신러닝 모델에 Druid _ Imply 활용하기
실시간 이상탐지를 위한 머신러닝 모델에 Druid _ Imply 활용하기Kee Hoon Lee
 
AWS Kubernetes 서비스 자세히 살펴보기 (정영준 & 이창수, AWS 솔루션즈 아키텍트) :: AWS DevDay2018
AWS Kubernetes 서비스 자세히 살펴보기 (정영준 & 이창수, AWS 솔루션즈 아키텍트) :: AWS DevDay2018AWS Kubernetes 서비스 자세히 살펴보기 (정영준 & 이창수, AWS 솔루션즈 아키텍트) :: AWS DevDay2018
AWS Kubernetes 서비스 자세히 살펴보기 (정영준 & 이창수, AWS 솔루션즈 아키텍트) :: AWS DevDay2018Amazon Web Services Korea
 
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기NHN FORWARD
 
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015 AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015 Amazon Web Services Korea
 
Immutable infrastructure with Docker and containers (GlueCon 2015)
Immutable infrastructure with Docker and containers (GlueCon 2015)Immutable infrastructure with Docker and containers (GlueCon 2015)
Immutable infrastructure with Docker and containers (GlueCon 2015)Jérôme Petazzoni
 
Architecting ASP.NET Core Microservices Applications on AWS (WIN401) - AWS re...
Architecting ASP.NET Core Microservices Applications on AWS (WIN401) - AWS re...Architecting ASP.NET Core Microservices Applications on AWS (WIN401) - AWS re...
Architecting ASP.NET Core Microservices Applications on AWS (WIN401) - AWS re...Amazon Web Services
 
Drive business outcomes using Azure Devops
Drive business outcomes using Azure DevopsDrive business outcomes using Azure Devops
Drive business outcomes using Azure DevopsBelatrix Software
 

What's hot (20)

컨텐트 협업플랫폼 Amazon WorkDocs 활용하기 - 박상희 상무, 한글과컴퓨터 / Ben Fitzpatrick, Head of Bu...
컨텐트 협업플랫폼 Amazon WorkDocs 활용하기 - 박상희 상무, 한글과컴퓨터 / Ben Fitzpatrick, Head of Bu...컨텐트 협업플랫폼 Amazon WorkDocs 활용하기 - 박상희 상무, 한글과컴퓨터 / Ben Fitzpatrick, Head of Bu...
컨텐트 협업플랫폼 Amazon WorkDocs 활용하기 - 박상희 상무, 한글과컴퓨터 / Ben Fitzpatrick, Head of Bu...
 
WebSphere MQ tutorial
WebSphere MQ tutorialWebSphere MQ tutorial
WebSphere MQ tutorial
 
Лекція №3
Лекція №3Лекція №3
Лекція №3
 
Integração contínua com Jenkins
Integração contínua com JenkinsIntegração contínua com Jenkins
Integração contínua com Jenkins
 
Packer + Ansible을 이용한 AMI 생성 및 AutoScaling Group 이미지 교체 이야기
Packer + Ansible을 이용한 AMI 생성 및 AutoScaling Group 이미지 교체 이야기Packer + Ansible을 이용한 AMI 생성 및 AutoScaling Group 이미지 교체 이야기
Packer + Ansible을 이용한 AMI 생성 및 AutoScaling Group 이미지 교체 이야기
 
Awsでのsql高可用構成 Always On
Awsでのsql高可用構成 Always OnAwsでのsql高可用構成 Always On
Awsでのsql高可用構成 Always On
 
Docker and Kubernetes 101 workshop
Docker and Kubernetes 101 workshopDocker and Kubernetes 101 workshop
Docker and Kubernetes 101 workshop
 
Ibm mq with c# sending and receiving messages
Ibm mq with c# sending and receiving messagesIbm mq with c# sending and receiving messages
Ibm mq with c# sending and receiving messages
 
AWS Black Belt Online Seminar 2017 動画配信 on AWS
AWS Black Belt Online Seminar 2017 動画配信 on AWSAWS Black Belt Online Seminar 2017 動画配信 on AWS
AWS Black Belt Online Seminar 2017 動画配信 on AWS
 
Kerberos and its application in cross realm operations
Kerberos and its application in cross realm operationsKerberos and its application in cross realm operations
Kerberos and its application in cross realm operations
 
Flyway _ A Database Version Management Tool
Flyway _ A Database Version Management ToolFlyway _ A Database Version Management Tool
Flyway _ A Database Version Management Tool
 
ElastiCacheを利用する上でキャッシュをどのように有効に使うべきか
ElastiCacheを利用する上でキャッシュをどのように有効に使うべきかElastiCacheを利用する上でキャッシュをどのように有効に使うべきか
ElastiCacheを利用する上でキャッシュをどのように有効に使うべきか
 
실시간 이상탐지를 위한 머신러닝 모델에 Druid _ Imply 활용하기
실시간 이상탐지를 위한 머신러닝 모델에 Druid _ Imply 활용하기실시간 이상탐지를 위한 머신러닝 모델에 Druid _ Imply 활용하기
실시간 이상탐지를 위한 머신러닝 모델에 Druid _ Imply 활용하기
 
AWS Kubernetes 서비스 자세히 살펴보기 (정영준 & 이창수, AWS 솔루션즈 아키텍트) :: AWS DevDay2018
AWS Kubernetes 서비스 자세히 살펴보기 (정영준 & 이창수, AWS 솔루션즈 아키텍트) :: AWS DevDay2018AWS Kubernetes 서비스 자세히 살펴보기 (정영준 & 이창수, AWS 솔루션즈 아키텍트) :: AWS DevDay2018
AWS Kubernetes 서비스 자세히 살펴보기 (정영준 & 이창수, AWS 솔루션즈 아키텍트) :: AWS DevDay2018
 
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
 
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015 AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
AWS로 사용자 천만 명 서비스 만들기 (윤석찬)- 클라우드 태권 2015
 
Immutable infrastructure with Docker and containers (GlueCon 2015)
Immutable infrastructure with Docker and containers (GlueCon 2015)Immutable infrastructure with Docker and containers (GlueCon 2015)
Immutable infrastructure with Docker and containers (GlueCon 2015)
 
Architecting ASP.NET Core Microservices Applications on AWS (WIN401) - AWS re...
Architecting ASP.NET Core Microservices Applications on AWS (WIN401) - AWS re...Architecting ASP.NET Core Microservices Applications on AWS (WIN401) - AWS re...
Architecting ASP.NET Core Microservices Applications on AWS (WIN401) - AWS re...
 
Intro - Cloud Native
Intro - Cloud NativeIntro - Cloud Native
Intro - Cloud Native
 
Drive business outcomes using Azure Devops
Drive business outcomes using Azure DevopsDrive business outcomes using Azure Devops
Drive business outcomes using Azure Devops
 

Similar to Microservices Architecture

İleri Seviye T-SQL Programlama - Chapter 19
İleri Seviye T-SQL Programlama - Chapter 19İleri Seviye T-SQL Programlama - Chapter 19
İleri Seviye T-SQL Programlama - Chapter 19Cihan Özhan
 
Docker - Ankara Cloud Meetup
Docker - Ankara Cloud Meetup Docker - Ankara Cloud Meetup
Docker - Ankara Cloud Meetup Mustafa AKIN
 
Sinema Seans Bilgi ve Rezervasyon Sisteminin Mikro Servis Yaklaşımıyla Gelişt...
Sinema Seans Bilgi ve Rezervasyon Sisteminin Mikro Servis Yaklaşımıyla Gelişt...Sinema Seans Bilgi ve Rezervasyon Sisteminin Mikro Servis Yaklaşımıyla Gelişt...
Sinema Seans Bilgi ve Rezervasyon Sisteminin Mikro Servis Yaklaşımıyla Gelişt...Tolga Kaprol
 
Buluta Ilk Adım Analizi
Buluta Ilk Adım AnaliziBuluta Ilk Adım Analizi
Buluta Ilk Adım AnaliziGokhan Boranalp
 
Docker Nedir, Ne İşe Yarar, Nasıl Kullanılmalıdır?
Docker Nedir, Ne İşe Yarar, Nasıl Kullanılmalıdır? Docker Nedir, Ne İşe Yarar, Nasıl Kullanılmalıdır?
Docker Nedir, Ne İşe Yarar, Nasıl Kullanılmalıdır? Mustafa AKIN
 
Microsoft Azure ITPro - Microsoft Azure'a Giriş- Bölüm 1
Microsoft Azure ITPro - Microsoft Azure'a Giriş- Bölüm 1Microsoft Azure ITPro - Microsoft Azure'a Giriş- Bölüm 1
Microsoft Azure ITPro - Microsoft Azure'a Giriş- Bölüm 1Önder Değer
 
agem_intern_report
agem_intern_reportagem_intern_report
agem_intern_reportMeliz Ersoy
 
Ağ i̇şleti̇m si̇stemleri̇ne örnekler
Ağ i̇şleti̇m si̇stemleri̇ne örneklerAğ i̇şleti̇m si̇stemleri̇ne örnekler
Ağ i̇şleti̇m si̇stemleri̇ne örneklerAlonelaz
 
Azure Cloud Engineer - Bölüm 2
Azure Cloud Engineer - Bölüm 2Azure Cloud Engineer - Bölüm 2
Azure Cloud Engineer - Bölüm 2Önder Değer
 
Bulutbilisim sunum
Bulutbilisim sunumBulutbilisim sunum
Bulutbilisim sunumugurbudak
 
Web servisi güvenliği
Web servisi güvenliğiWeb servisi güvenliği
Web servisi güvenliğiEmrah Gürcan
 
Solarwinds SAM ve Patch Manager
Solarwinds SAM ve Patch ManagerSolarwinds SAM ve Patch Manager
Solarwinds SAM ve Patch ManagerKavi International
 
System Center 2012 R2 ile Gelen Yenilikler
System Center 2012 R2 ile Gelen YeniliklerSystem Center 2012 R2 ile Gelen Yenilikler
System Center 2012 R2 ile Gelen YeniliklerMustafa
 
sunum_Service Oriented Architecture (SOA)_off2007
sunum_Service Oriented Architecture (SOA)_off2007sunum_Service Oriented Architecture (SOA)_off2007
sunum_Service Oriented Architecture (SOA)_off2007Efe Eyüboğlu
 
Microsoft Azure Sanal Ağ Temelleri
Microsoft Azure Sanal Ağ TemelleriMicrosoft Azure Sanal Ağ Temelleri
Microsoft Azure Sanal Ağ TemelleriMustafa
 
Microsoft Azure Sql Server HADR
Microsoft Azure Sql Server HADRMicrosoft Azure Sql Server HADR
Microsoft Azure Sql Server HADRÖnder Değer
 

Similar to Microservices Architecture (20)

12factor apps
12factor apps12factor apps
12factor apps
 
İleri Seviye T-SQL Programlama - Chapter 19
İleri Seviye T-SQL Programlama - Chapter 19İleri Seviye T-SQL Programlama - Chapter 19
İleri Seviye T-SQL Programlama - Chapter 19
 
Devnot - Dev Summit 2018
Devnot - Dev Summit 2018Devnot - Dev Summit 2018
Devnot - Dev Summit 2018
 
Docker - Ankara Cloud Meetup
Docker - Ankara Cloud Meetup Docker - Ankara Cloud Meetup
Docker - Ankara Cloud Meetup
 
Sinema Seans Bilgi ve Rezervasyon Sisteminin Mikro Servis Yaklaşımıyla Gelişt...
Sinema Seans Bilgi ve Rezervasyon Sisteminin Mikro Servis Yaklaşımıyla Gelişt...Sinema Seans Bilgi ve Rezervasyon Sisteminin Mikro Servis Yaklaşımıyla Gelişt...
Sinema Seans Bilgi ve Rezervasyon Sisteminin Mikro Servis Yaklaşımıyla Gelişt...
 
Buluta Ilk Adım Analizi
Buluta Ilk Adım AnaliziBuluta Ilk Adım Analizi
Buluta Ilk Adım Analizi
 
Docker Nedir, Ne İşe Yarar, Nasıl Kullanılmalıdır?
Docker Nedir, Ne İşe Yarar, Nasıl Kullanılmalıdır? Docker Nedir, Ne İşe Yarar, Nasıl Kullanılmalıdır?
Docker Nedir, Ne İşe Yarar, Nasıl Kullanılmalıdır?
 
Linkle mimari
Linkle mimariLinkle mimari
Linkle mimari
 
Microsoft Azure ITPro - Microsoft Azure'a Giriş- Bölüm 1
Microsoft Azure ITPro - Microsoft Azure'a Giriş- Bölüm 1Microsoft Azure ITPro - Microsoft Azure'a Giriş- Bölüm 1
Microsoft Azure ITPro - Microsoft Azure'a Giriş- Bölüm 1
 
agem_intern_report
agem_intern_reportagem_intern_report
agem_intern_report
 
Sukru_TRSUG2016
Sukru_TRSUG2016Sukru_TRSUG2016
Sukru_TRSUG2016
 
Ağ i̇şleti̇m si̇stemleri̇ne örnekler
Ağ i̇şleti̇m si̇stemleri̇ne örneklerAğ i̇şleti̇m si̇stemleri̇ne örnekler
Ağ i̇şleti̇m si̇stemleri̇ne örnekler
 
Azure Cloud Engineer - Bölüm 2
Azure Cloud Engineer - Bölüm 2Azure Cloud Engineer - Bölüm 2
Azure Cloud Engineer - Bölüm 2
 
Bulutbilisim sunum
Bulutbilisim sunumBulutbilisim sunum
Bulutbilisim sunum
 
Web servisi güvenliği
Web servisi güvenliğiWeb servisi güvenliği
Web servisi güvenliği
 
Solarwinds SAM ve Patch Manager
Solarwinds SAM ve Patch ManagerSolarwinds SAM ve Patch Manager
Solarwinds SAM ve Patch Manager
 
System Center 2012 R2 ile Gelen Yenilikler
System Center 2012 R2 ile Gelen YeniliklerSystem Center 2012 R2 ile Gelen Yenilikler
System Center 2012 R2 ile Gelen Yenilikler
 
sunum_Service Oriented Architecture (SOA)_off2007
sunum_Service Oriented Architecture (SOA)_off2007sunum_Service Oriented Architecture (SOA)_off2007
sunum_Service Oriented Architecture (SOA)_off2007
 
Microsoft Azure Sanal Ağ Temelleri
Microsoft Azure Sanal Ağ TemelleriMicrosoft Azure Sanal Ağ Temelleri
Microsoft Azure Sanal Ağ Temelleri
 
Microsoft Azure Sql Server HADR
Microsoft Azure Sql Server HADRMicrosoft Azure Sql Server HADR
Microsoft Azure Sql Server HADR
 

More from Dilaver Demirel

More from Dilaver Demirel (14)

Git - Code Versiyon Yönetim Sistemi
Git - Code Versiyon Yönetim SistemiGit - Code Versiyon Yönetim Sistemi
Git - Code Versiyon Yönetim Sistemi
 
Unit test
Unit testUnit test
Unit test
 
Software/Yazılım Test
Software/Yazılım TestSoftware/Yazılım Test
Software/Yazılım Test
 
SDLC - Software Development Life Cycle
SDLC - Software Development Life CycleSDLC - Software Development Life Cycle
SDLC - Software Development Life Cycle
 
Yazılım Prensipleri ve Code Review Check List
Yazılım Prensipleri ve Code Review Check ListYazılım Prensipleri ve Code Review Check List
Yazılım Prensipleri ve Code Review Check List
 
Oracle Weblogic Server
Oracle Weblogic ServerOracle Weblogic Server
Oracle Weblogic Server
 
Java Server Faces
Java Server FacesJava Server Faces
Java Server Faces
 
Pentaho BI
Pentaho BIPentaho BI
Pentaho BI
 
JVM ve VisualVm
JVM ve VisualVmJVM ve VisualVm
JVM ve VisualVm
 
Apache Maven
Apache MavenApache Maven
Apache Maven
 
Aspect Oriented Programming
Aspect Oriented ProgrammingAspect Oriented Programming
Aspect Oriented Programming
 
NodeJS ve MongoDB
NodeJS ve MongoDBNodeJS ve MongoDB
NodeJS ve MongoDB
 
NodeJS Nedir
NodeJS NedirNodeJS Nedir
NodeJS Nedir
 
Jpa
JpaJpa
Jpa
 

Microservices Architecture

  • 2. Nedir? Bir uygulama geliştirme mimarisidir. Birbirleriyle gevşek bağ ile bağlı uygulama parçacıklarının oluşturduğu mimari olarak da tanımlanabilir. Microservices mimarisi büyük, karmaşık uygulamaların sürekli delivery/deploy yapılabilmesini mümkün kılar. Ayrıca şirketin ileriye dönük teknoloji gelişimini kolaylıkla yapılabilmesine imkan sunar. Microservislerin mimarisel bazı problemleri vardır. Microservices mimarisini anlamak ve uygulamak için çeşitli patternler vardır. Bunun amacı vardır: 1- Uygulamanız için microservices mimarisinin uygun olup olmadığına karar vermenize yardımcı olmak 2- Microservices mimarisinin başarıyla kullanımanıza yardımcı olmak
  • 3. Microservisin Amacı/Özellikleri En temel amaç geliştirmeyi hızlandırmaktır. Bunu sağlayan en önemli unsur ise continuous delivery/deployment’tır. Microservices başarılı/hızlı uygulama geliştirmeyi iki şekilde sağlar; 1- Testi basitleştirip ve servislerin bağımsız olarak konumlanmasını sağlayarak 2- Takım organizasyonunu, her biri bir veya daha fazla hizmetten sorumlu küçük, özerk takımlar şeklinde yapılandırarak sağlar. Bu otomatik olarak sağlanan bir şey değildir. Bunu sağlamadaki en büyük unsur uygulamayı servislere dikkatli bir şekilde ayırmaktır.
  • 4. Microservisin Amacı/Özellikleri Bir servis küçük bir takımın geliştirip test edebileceği kadar küçük olmalıdır. Bunu sağlamak için «Single Responsibility Principle»(Tek Sorululuk Prensibi) bize yol gösterici olabilir. Uygulama aynı zamanda yeni eklenen ya da değişikliğe sebep olan gereksinimlerin çoğunu tek bir servisi etkileyecek şekilde parçalanmalıdır. Bunun nedeni birden çok ekip üzerinde koordinasyon gerektiren birden fazla servisi etkileyen değişikliklerin geliştirmeyi yavaşlatmasıdır.
  • 5. Patternler • Decomposition – Ayrıştırma • Deployment • Cross Cutting Concerns • Communication Style • External API • Service Discovery • Reliability – Güvenilirlik • Data Management • Security • Testing • Observability • UI
  • 6. Decomposition – Ayrıştırma • Decompose by business capability • İş sorumluluklarına göre ayırma. Birçok organizasyonda bu konu multi-level hiyerarşi ile ayrılmıştır. Örneğin ; Ürün/Hizmet geliştirme, Ürün/Hizmet teslimi, Talep Yönetimi vb. • Decompose by subdomain • Domain-Driven-Design yaklaşımı ile ayrıştırma yapılır. DDD uygulamayı domain olarak varsayar. Bir domain birden fazla alt domainlerden oluşur. Her bir sub domain uygulamanın modüllerini ifade eder. Alt domainler aşağıdaki yaklaşımla tasarlanır; • Core : İşin en değerli ve en önemli bölümlerini ifade eder • Supporting : Uygulamanın ana konularıyla alakalı süreçlerdir. • Generic : İşe özgü olmayan ve temel olması gereken konulardır
  • 7. Deployment • İhtiyaçlar • Servisler birçok farklı dil,framework ve framework versiyonu ile yazılmıştır • Servisler verim ve kullanılabilirlik açısından birden fazla servisten oluşur • Servisler birbirinden bağımsız olarak deploy edilebilmeli ve scale edilebilmeli • Servis instansları diğerlerinden izole olmalı • Bir servisi hızlıca build edip yükleyebilmelisiniz • Bir hizmetin kullanabileceği sistem kaynalarını sınırlayabilmelisiniz • Her servis instansını izleyebilmelisiniz • Deploymentı güvenli yapabilmelisiniz • Uygulamayı olabildiğince düşük maaliyetle deploy edebilmelisiniz • Yöntemler • Multiple service instances per host(physical or virtual) • Service instance per host • Service instance per VM • Service instance per Container • Serverless deployment • Service deployment platform
  • 8. Cross Cutting Concerns • Örnekler: • Externalized configuration • Logging • Health checks • Metrics • Distrubuted tracing • Bunlar gibi generic CCC’lerin yanında uygulamaya özel CCC konuları da çıkabilir. Örneğin RDBMS kullanan bir uygulamada connection pool kullanmak gibi. • Bu konuların uygulamanın tasarım aşamasında oturtulması gereklidir ileriye dönük refactoring yapmak maliyetli olabilir. • Bunlara bağlı olarak: • Yeni bir microservices oluşturmak hızlı ve kolay olmalıdır • Yeni microsevice CCC’leri kapsayacak şekilde olmalıdır
  • 9. Communication Style • Servisler istemcilerden gelen istekleri yerine getirmelidir. Hatta bu istekleri yerine getirirken diğer servisler ile çalışması gerekebilir. Bu durumda süreçler arası iletişim yapmaları gerekmektedir. • Remote procedure invocation • REST,gRPC,Apache Thrift • Messaging • Apache Kafka, RabbitMQ • Domain-specific protocol • Email : SMTP, IMAP • Media Streaming : RTMP, HLS, HDS
  • 10. External API - API Gateway / Backend for Front-End • Faydaları • Encapsulate internal services • Load Balancing • Authentication • Monitoring • Caching • Örneğin microservices mimarisi ile online store geliştiriyoruz ve ürün detay sayfası implemente ediyoruz. Bu sayfanın iki farklı arayüz ile hizmet vermesi isteniyor: • HTML5/Javascript based web page • Rest API ile çalışan Native Android ve Iphone client • Ayrıca uygulama 3.parti uygulamaların kullanması için ürün detaylarını Rest API ile servis etmelidir. • Ürün detay sayfasında birçok bilgiye ihtiyaç vardır: • Temel bilgiler : Başlık, yazar, fiyat • Satış geçmişi • Stok durumu • Satın alma opsiyonları : hard copy/e-book • Genellikle bu kitapla birlikte satın alınan ürünler • Kitap yorumları • Satıcılar
  • 11. External API - API Gateway / Backend for Front-End • Microservices mimarisi kullanıldığı için ürün bilgileri birden fazla hizmete yayılmıştır. Örneğin; • Product Info Service - basic information about the product such as title, author • Pricing Service - product price • Order service - purchase history for product • Inventory service - product availability • Review service - customer reviews • Sonuç olarak ürün ayrıntılarını gösteren uygulama bu servislerin tümünden bilgi almak zorundadır.
  • 12. External API - API Gateway / Backend for Front-End • Microservices mimarisi kullanan bir uygulamanın clientleri servislere nasıl erişir? • Farklı clientler farklı datalara ihtiyaçları vardır. Örneğin masaüstü bilgisayardan açılan ürün detayları sayfasında mobil uygulamadan daha çok veri vardır. • Farklı clientler için farklı network performans problemleri oluşabilir. • Servis instanslarının sayıları dinamik olarak değişebilir(host+port) • Servislerin ayrıştırılması zamanla değişebilir ve bunun clientlerdan bağımsız olması gerekir • Servisler farklı iletişim protokolleri kullanabilir
  • 13. External API - API Gateway / Backend for Front-End • Bu durumlar için clientlerin apilere erişirken tek giriş noktasını bilmesi gerekir. Gateway istekleri iki şekilde karşılayabilir; proxy ya da route
  • 14. External API - API Gateway / Backend for Front-End • Gateway’ler her cliente ortak bir apı sunmak yerine cliente uygun apileri sunabilir. • Gatewayler ayrıca güvenlik katmanı olarak da kullanılabilir.
  • 15. External API - API Gateway / Backend for Front-End • Clientler servislerin nasıl bölümlendiğiniden izole eder • Clientlerin servis adreslerini bilmesini gerekliliğini ortadan kaldırır • Her istemci için uygun API’yi sağlar • Complexitiyi artırabilir, doğru yönetilmesi gereken bir modeldir • Request/response süreleri artabilir. Ama bu süre ihmal edilebilecek kadar azdır.
  • 16. Service Discovery • Client-side discovery • Server-side discovery • Service registry • Self registration • 3rd party registration
  • 17. Reliability • Circuit Breaker • Servislerde endpointlerde oluşacak hataların sistemi tamamen kilitlemesini önlemek için kullanılmaktadır. • Eğer servis enpointinde belirli sayıda hata gerçekleşirse o endopointe gelen requestleri belirli süre engelliyoruz, o süre sonunda tekrar kontrol ediliyor eğer hata düzelmişse normal akışına devam ediyor. • Bu sayede endpointin kullandığı sistem kaynaklarını gereksiz kullanmayı ve sistem içerisindeki cascade hatalar oluşmasının önüne geçiyoruz • Retry : Genelde farklı sistemlere bağlı işlem yaparken bazı durumlarda geçici hatalar oluşabilir. Bu hataları elemine etmek için retry mekanizması kullanılarbilir. Örneğin ilk hatadan sonra 3 defa daha deneme yaparak 3.nü n sonunda başarılı cevap alabiliriz. • Fallback : Retry sürecini işlettik ve hala hata alıyorsak ve daha önce bir alternatif yöntem (vazgeçip başka bir yol izlemek) stratejisi belirlediysek bunu devreye sokabiliriz.
  • 19. Data Management • Servisler serbestçe geliştirilebilecek ve ölçeklendirilebilecek yapıda olmalıdır. Bunun için servisler gevşek bir şekilde (loosely coupled) olmalıdır. • Bazı işlemler birden fazla serviste veri değişikliğini zorunlu kılmaktadır. • Bazı işlemler birden fazla servisin sahip olduğu veriyi sorgulamalıdır. • Bazı işlemler birden fazla servisin sahip olduğu veriyi sorgulayıp birleştiriyor olabilir. • Veritabanları bazen çoğaltılıp ölçeklenebilir. • Farklı servislerin farklı depolama gereksinimleri olur. Bazı servisler RDBMS, bazıları NoSQL, bazıları ise GraphDB’ye ihtiyaç duyabilir.
  • 20. Data Management • Solutions • Database per Service • Shared database • Saga • API Composition • CQRS • Event sourcing • Transaction log tailing • Database triggers • Application events
  • 21. Data Management - SAGA • SAGA – Distrubuted Transaction • Her servisin local transactionalarının bir sırasıdır. • Her servis kendi verisini güncller ve bir sonraki işlemi tetikleyecek message veya event yayınlar. • Herhangi bir servisin işlemi başarısız olursa SAGA önceki işlemleri geri alacak bir dizi telafi işlemi gerçekleştirir. • Order Service bekleme durumunda bir sipariş oluşturur • Customer Service sipariş için kredi reserv eder • Order Service reservasyon işlemi sonucuna göre siparişi onaylar ya da iptal eder • CreateOrder saga içinde OrderCreated eventi yayınlanır, CustomerService CreditReserved ya da CreditLimitExceeded eventi yayınlar.
  • 22. Data Management – API Composition • Birden farklı servisten gelen dataları barındıran sorgulara ihtiyaç olduğunda bunu en efektif olarak yapmak için API Composer pattern uygulanabilir.
  • 23. Data Management – CQRS • CQRS – Command Query Responsibility Segregation • Uygulama command-side ve query-side olmak üzere ikiye ayrılır. Command- side insert,update vb. işleri yapar. Query-side ise commandlar sonucu oluşan eventler ile sorgu datalarını günceller.
  • 24. Data Management – Event Sourcing • Temel prensip olarak doğrudan tablolarda entity olarak verileri saklamak yerine domainler üzerinde gerçekleşen olayları saklamaktır. Yani sipariş oluşturma sonucunda sipariş için bir tabloya kaydetmek yerine sipariş oluşturuldu eventini sipariş bilgisi ile birlikte saklar. • Bu model özellikle dağıtık sistemlerde veri tutarlılığını saklamak için önemli bir çözümdür. Verinin eventlerini replay ettiğinizde hangi aşamada ne durumda olduğunu her zaman elde edebilirsiniz.
  • 26. Testing • Service Component Test • Uçtan uca servisleri test etmek zor ve yavaştır. Bunun için servisleri yalıtılmış olarak kendi başlarına test etmek gerekir. • Bu kolay ve hızlıdır. • Bu bazı durumlarda testlerin development ortamında başarılı fakat production ortamında hatalı olmasına sebep olabilir.
  • 27. Testing • Service Integration Contract Test • Bu patternde her servis kendini kullanan servislerin ona sağladığı test paketlerini uygulayarak entegrasyon testini sağlamış olur.
  • 28. Observability • Log aggregation • Application metrics • Audit logging • Distributed tracing • Exception tracking • Health check API • Log deployments and changes
  • 29. Observability – Log aggregation
  • 31. Microservices with Spring Cloud • Microservices uygulamalarında ihtiyaç duyulan önceki slaytlarda belirttiğimiz gereksinimleri Spring Boot uygulamalarında kolayca kullanabilmeyi sağlayan kütüphanedir. Auth Admin Dashboard