Microservice Arsitektur

Secara singkat Microservice arsitektur adalah sebuah metode pengembangan perangkat lunak yang didasarkan pada konsep pembuatan sistem aplikasi yang terdiri dari beberapa layanan kecil yang independen. Setiap layanan terpisah satu sama lain, dapat dikembangkan dan dikelola oleh tim yang berbeda secara terpisah, serta dapat diintegrasikan secara fleksibel.

Sebelum membahas microservices arsitektur lebih jauh ada baiknya kita mengetahui dulu tentang monolith arsitektur.

A. Apa itu monolith arsitektur?

• Single development unit
• Dimana semua fitur dibuat dalam sebuah aplikasi besar

Monolith adalah arsitektur yang semua fiturnya tergabung dalam satu aplikasi besar.

Mulailah dari aplikasi monolith jangan langsung microservice

• Banyak hal yang perlu dipertimbangkan sebelum menggunakan arsitektur microservice.
• Jika kita belum tahu aplikasinya akan sebesar apa, jumlah usernya berapa, dan detail lainnya yang seperti apa maka sebaiknya kita menggunakan arsitektur monolith.
• Kalau aplikasinya sudah cukup besar dan dibutuhkan perubahan arsitektur guna meningkatkan performa aplikasi maka arsitektur dapat diubah ke microservice.

Kelebihan arsitektur monolith

• Mudah di develop
• Mudah di deploy
• Mudah di test
• Mudah di scale
• Suitable for small team

Kekurangan arsitektur monolith yang menjadi pertimbangan migrasi ke microservices

• Mengintimidasi developer yang baru bergabung (new recruiter developer mungkin tidak mampu beradaptasi dengan project yang sudah terlalu besar karena tidak terstrukturnya code atau sulit mengikuti flow dari project aplikasi tersebut)
• Scaling development dengan banyak developer agak menyulitkan (ratusan developer bisa terjadi conflict code)
• Butuh kontrak pangjang dengan teknologi yang digunakan (bahasa pemrograman. Database, dll) (kesulitan jika bahasa yang digunakan kurang developernya seperti .net, java karena bahasa tidak dapat diganti misalnya ke php, js, dsb karena untuk mengganti harus merombak seluruh aplikasi)
• Scalling pada bagian tertentu tidak bisa dilakukan (misal kita hanya ingin scaling aplikasi flash sale tapi aplikasi registrasi juga ikut terscale jadinya kita hanya buang2 resource, satu fitur yang akan discale mengharuskan kita scale semua fitur)
• Running app monolith akan menjadi sangat berat kedepannya (misal Anda hanya ubah 1 line code tapi restartnya butuh waktu 15 menit)

B. Microservice arsitektur

• Kumpulan Aplikasi-aplikasi kecil yang saling bekerja sama
• Aplikasi kecil (satu aplikasi mengurus satu tugas saja data produk saja atau data costumer saja)
• Fokus mengerjakan satu pekerjaan dengan baik
• Independent, dapat di deploy dan diubah tanpa tergantung dengan aplikasi lain
• Setiap komponen pada sistem dibuat dalam service

Klw di microservices, aplikasi disebut service (product service = aplikasi yang memanage data product)

• Komunikasi antar service biasanya melalui network-call (http api, )

Microservices arsitektur adalah arsitektur yang semua fiturnya berpisah satu sama lain namun tetap saling berkomunikasi dan bekerja sama dalam menyelasikan tugasnya. Arsitektur ini merupakan kebalikan dari monolith arsitektur dimana semua fitur terpusat dalam satu aplikasi.

Contoh Arsitektur

Kelebihan arsitektur microservices

• Mudah dimengerti, karena relative kecil ukuran servicesnya
• Lebih mudah di develop, dimaintain, ditest dan dideploy
• Lebih mudah bergonta-ganti teknologi
• Mudah discale sesuai kebutuhan
• Bisa dikerjakana dalam tim-tim kecil

Kekurangan arsitektur microservices

1. Distributed system dimana setiap fitur terpecah-pecah
2. Komunikasi antar service yang rawan error (solve by making error handling)
3. Tersting interaksi antar service lebih sulit (harus run semua service utk lihat integrasi jika ada yang tidak bisa di run harus buat mock server)

Pembagian microservices

• Tidak ada ketentuan baku
• Bisa Displit berdasarkan bussines domainnya
• Klw kita masih bingung domain bisnisnya maka awali saja dengan monolith architecture

Seberapa kecil aplikasi microservices

• Tidak ada ketentuan baku
• Bisa Single responsibility
• Bisa Sekecil mungkin sehingga bisa dimengerti oleh satu orang
• Bisa dikerjakan sejumlah X developer

Perbedaan monolith dan microservices

monolith	microservices
Simplicity (antar code) Consitency (use same languange ) Easy to refactor	Partial development Availability Multiple platform Easy to scale

C. Database di microservice

1. Database per service

Kenapa harus database per service

• Memastikan bahwa antar service tidak ketergantungan (misal jika 2 service menggunakan 1 database yang sama, kemudian service 1 membutuhkan perubahan tabel structure tapi service 2 tidak sehigga service 2 akan error hal ini menunjukkan ketergantungan 2 service terhadap 1 database)
• Tiap service bisa menggunakan aplikasi database sesuai kebutuhan
• Service tidak perlu tahu kompleksitas internal database service lainnya
• Sesuai untuk microservice yang dibuat dari 0
• Tiap service harus memiliki database masing-masing karena tiap service memiliki spesifikasi tertentu

2. Shared Database

Kapan harus mengimplementasikan shared database

• Ketika melakukan transisi dari aplikasi monolith ke microservices

• Migrasi total (buat microservicesnya hinga selesai baru migrasi)
  • Migrasi partial (per fitur), ada suatu waktu service kita masih ambil data dari database versi monolith (sharing database) setelah selesai microservicenya baru kita pecah databasenya
  • Ketika bingun memecahkan data antar service

• Service a butuh data service b dan service b butuh data service a, bingung cara mecah datanya? Gabungkan saja dulu servicenya dengan 2 service menggunakan secara bersama 1 databasenya (sharing database)

• Ketika dikejar waktu, sehingga tidak ada waktu membuat API  (keadaan terdesak)

Gambar diatas menampilkan merchant service mengambil data tanpa menggunakan API dari order service karena fitur api nya belum sempat dibuat karena dikejar deadline untuk menampilkan datanya. Tapi tahap selanjutnya harus dibuatkan API kerena tidak boleh service langsung berhubungan dengan database.

3. NoSQL (Not Only SQL)

• noSQL bukan No sql
• NoSQL singkatan dari Not Only SQL

Jenis jenis NoSQL

• Document oriented database (mongoDB)
• Key-value database (Redis)
• Column families database (Apache Cassandra)
• Graph database (Neo4J)
• Search database (elasticSearch)
• Time series database (influxDB)
• Dll

Kenapa penting tahu NoSQL

• Agar bisa disesuaikan dengan kebutuhan microservices
  • Klw servicenya tujuannya pencarian data pakai database search
  • Klw terkoneksi antar data -> graph database
  • Timse series, bisa geser2 waktunya -> time series database
• Bisa mencari alternatif cara mengolah data
  • Misal search service dan kita pakai sql dimana searchnya aneh2, pakai regex dll maka performance nya jelek
• Mempercepat dalam proses penulisan atau pencarian

Product service

• Attiribute menyesuaikan kategorinya misal elekronik, food, dll
• Klw kita pakai sql akan banyak columnya dan banyak join sehingga performance nya jelek

D. Komunikasi antar services

• Bagaimana service mendapatkan data dari service lain. Kita dapat menggunakan remote procedure invocation atau messaging

1. Remote Producedure Invocation (RPI)

Komunikasi antar service

• Idealnya komunikasi dilakukan melalui RPI (remote procedure invocation) or RPC (remote procedure call)
• Tidak direkomendasikan komunikasi dilakukan via database

Jika komunikasinya directly database, tidak lucu jika service a yang konfigurasinya postgree harus pakai konfigurasi lagi utk mongoDB

Contoh RPI

• RESTful API (HTTP)
• gRPC
• Apache Thrift
• SOAP
• Java RMI
• Corba (Common Object Request Broker Architecture)

Keuntungan using RPI

• Simple and easy
• Biasanya digunakan for request-reply communication
• used to Sync process (yang butuh menunggu jawaban)

2. Messaging

Kita bahas sedikit kekurangan metode RPI sebelum masuk ke pembahasan messaging.

masalah di komunikasi RPI

• proses lama (pada email serivice (5s) dan sms service (2s)) jadi costumer tunggu 7s ketika order barang
• mengirim data yang sama berkali2 (data yang sama dikirim ke 2 service yang berbeda yaitu pada finance service dan report service)
• membuat paralel process sangat rumit dan ada kemungkinan ada process gagal dan sukses secara bersamaan

backend max 2s diatas 2s itu lemot

untuk mengatasi kekurangan metode RPI kita menggunakan messaging

komunikasi dengan cara messaging

• messaging biasanya digunakan utk komunikasi async
• async artinya komunikasi dilakukan tanpa harus menunggu selesai diproses
• dalam async, kadang tidak perlu peduli balasan dari service yang dituju
• biasanya komunikasi messaging membutuhkan message channel sebagai jembatan untuk mengirim dan menerima data
• direkomendasikan menggunakan apk message broker to do management message channel

Arsitektur

• message broker didalamnya ada message channel
• order service tidak usah berhubungan dengan service, cukup kirim data ke message channel

contoh message broker

• Redis (PubSub)
• Apache KafKa
• rabbitMQ
• NSQ
• Google PubSUb
• Amazon Web Service SQS

Tidak harus menggunakan  1 communication method Bisa combine RPI dan messaging

E. Jenis-jenis microservices

• Stateless microservices
• Persitence microservices
• Aggregation microservices

1. Stateless

• Biasanya tidak memiliki database (tapi bisa punya)
• Digunakan untuk tugas sederhana
• Biasanya digunakan sebagai utiliy utk microservice lain (service yang help service lain)
• Tidak bergantung degan microservice lain

Contoh

Klw tugasnya simple, knp tidak diselipkan di servicenya saja tidak usah buat service baru?

• Biasanya ada banyak provider utk email atau sms sehingga jika terjadi masalah kita bisa switch.
• Jadi klw dijadikan satu service maka kita harus mengurus keribetan dari service email atau sms jika ganti provider padahal service sudah punya tugas yang lain
• Service bisa digunakan oleh service lain

2. Persistence

• kebalikan dari stateless
• Biasanya memiliki database
• Bisa juga disebut master data microservice
• Biasa digunakan untuk mengolah data di database (CRUD)

Contoh

3. Aggregation

• Bergantung dengan microservice lain
• Biasa digunakan sebagai pusat business logic aplikasi
• Boleh memiliki database atau tidak
• Tidak bisa berdiri sendiri

contoh

Cart service

1. Car service : tambah barang ke keranjang belanja
2. Service ini get data product dulu dan cek stok dari product service
3. Kemudian buat order, harus send data to order service

F. Aggregation + services communication

terbagi 2 yaitu

• Service orchestration
• Service choreography

1. Service orchestration

• Cara aggregation microservices berkomunikasi dengan microservices lain.
• Jika menggunakan RPI maka dinamakan Service Orchestration Pattern
• Dalam service orchestration pattern, aggregation microservices bertugas untuk mengatur alur business logic sistem

Contoh

• Langsung call directly service degan RPI (Remote procedure invocation)

Keuntungan service orchestration

• Mudah dibuat dan dimengerti, karena kode business logic akan terpusat di aggregation microservices

Kekurangan service orchestration

• Terlalu bergantung dengan service lain (1 service mati aggregation service tidak dapat berjalan)
• Akan lebih lambat karena bergantung dengan service lain (menunggu seluruh service yang terkait selesai)
• Akan lebih mudah error jika microservice lain terdapat masalah
• Jika perlu microservice baru, perlu dilakukan perubahan di aggregation microservices

2. Service choreography

• kebalikan dengan service orchestration
• Komunikasi menggunakan messaging

Perbedaan choreography dan orchestration

• Orchestration : Bisnis logic terpusat dann hanya dia yang mengerti bisnis logicnya (pintar) service lain hanya menunggu untuk menjalankan perintah dari aggregation (bodoh)
• Choreography:  bisnis logicnya tersebar sehingga semua dituntut pintar (mengerti bisnis logic)

ada member baru atau perubahan member -> member service publish perubahan ke message broker -> siapa pun yang butuh dapat mengambil datanya di message broker

transaction service ->  butuh data member -> consume data dari message broker (member event) -> data disimpan di DB transaction service (duplikasi data member)

Keuntungan

• Tidak bergantung dengan microservice lain
  • Misal email service nya nonaktif, transaction service tetap berjalan dan mengirimkan event di message broker dan transaksi tetap sukses. Setelah email service aktif, dia kemudian consume transaction event. Sehingga tidak ada data yang hilang
  • Berbeda dengan orchestration ketika ada service nonaktif, sehingga menyebabkan ada data hilang krn tidak terproses akibat servicenya mati namun transaksi di aggregation service berhasil sehingga ini sedikit berbahaya
• Lebih cepat, karena tidak perlu berkomunikasi dengan microservice lain (cukup krim data ke message broker dan selesai)
• Jika ada microservice baru, aggregation microservice tidak perlu melakukan perubahan lagi

Zero changes di aggregation, fitur baru di develop di service yang baru

Kekurangan

• Lebih sulit di debug
• Flow sulit dimengerti harus di track di semua micro service
• Sangat bergantung dengan message broker

Klw tim nya sudah senior dan banyak bisa pakai choreography tapi klw tidak mending yang mudah dulu yaitu orchestration

G. Ekspos aplikasi ke internet

API Gateway

• Api gateway adalah aplikasiyang bertugas sebagai gerbang dari luar ke dalam
• Luar dimaksud adalah akses dari internet, dan dalam adalah aplikasi microservices
• API Gateway bertugas sebagai proxy server (perantara aplikasi dan internet) ke semua aplikasi microservices
• Aplikasi microservices hanya bisa diakses dari luar melaui API Gateway

Jadi hanya api gateway yang terekpos keluar, all microservices tidak terekspos

Internet -> api gateway -> microservices

Keuntungan

• Lebih aman karena satu gerbang
• Service tidak perlu mengimplementasikan proses authentikasi, cukup dilakukan di API Gateway
• api gateway bisa digunakan sebagai load balancer (pendistribusian beban kerja)
  • misal member service dibuat 2 agar jika ada salah satu yang nonaktif bisa change ke service backup sehingga menjaga avaibility atau mendistribusika request ke existing service agar lebih cepat nah load balancer berfungsi to chage it
• bisa digunakan sebagai rate limiter
  • misal ada service yang lambat, 1s for 1 request, so di api gatewaynya kita batasi hanya boleh 1 request/1s jika lebih dari 1 request/detik kita reject
• bisa digunakan sebagai pengaman sehingga error dari service tidak terekspos

contoh API Gateway

• Nginx
• Apache HTTPD
• Kong (NginX approvement)
• Netflix Zuul
• Spring Cloud Gateway

Authentication and authorization

Authentication	Authorization
Menvalidasi credential to verify indentiy owner. Contoh: Login process use username and pass, otp,sms	It is process that is done after authenthication Validation whether identity owner have hak access to resource or not like user level Contoh: Access-control list

1. Auth Service

Kita membuat service baru untuk auth service. Kenapa kita membuat auth service?

• Jika api gateway hanya proxy server maka kita harus melakukan authentication ke semua microservices
• Jika kita set auth ke semua service maka akan sangat sulit apalagi jika jumlah servicenya banyak. Untuk menghindari hal tersebut kita harus set authentication di api gateway saja.

Bagaimana api gateway bekerja ?

• Ada use request dari internet ke microservices
• Kemudian api gateway bertanya ke auth services -> user ini akan mengakses data tertentu, apakah diperbolehkan atau tidak?
• Jika user berhasil login maka Auth services akan mengizinkannya -> api gateway, okk , request user tersebut aka diarahkan ke service target

• Bagaimana jika request lebih dari satu?,  haruskah api gateway bertanya ke auth service berulang kali setiap kali ada request ? No, kita dapat menggunakan cache selama waktu tertentu misal 5 minutes, in 5 minutes setelah login, api gateway tidak akan bertanya ke auth services

• Selanjutnya, bagaimana mendapatkan detail authentication untuk memutuskan user memiliki authorization?

• Middleware pada service target akan bertanya kembali kembali ke authservice untuk detail data user

• Tapi masalah selanjutnya adalah auth service mendapatkan banyak traffic. Dan jika service tersebut tidak sanggup menhandle nya mengakibatkan auth service down sehingga akan mempengaruhi semua performance service kita.
  • Untuk mengatasi masalah tersebut Data authservice bisa di forward ke targeted service

Teknologi pendukung

• Secure cookie
• Oauth (mobile)
• JSON web token (JWT)
• Basic auth
• API key / secret key
• Username n password
• Dll

H. Frontend problem

*third party : to allow integration our product to others 

Problem banyak jenis frontend

• Tiap front end punya mekanisme authentikasi berbeda
  • Website menggunakan username password
  • Mobil menggunakan No hp
  • Third party tidak login, server to server biasanya menggunakan api key, basic auth, atau server key
  • Jadi kita harus menyediakan auth yang berbeda untuk setiap fronted

• Kecepatan bandwith tiap frontend berbeda
  • Tidak menyamaratakan bandwith karena tiap frontend  spesfilasi yang berbeda
  • Kebutuhan Data yang ditampilkan untuk frontend web dan mobile berbeda dengan thirdparty
  • Thirdparty tidak masalah dengan data yang besar karena server to server pasti cepat
  • Klw web dan mobile kita harus mempertimbangkan specsification nya (ram, lebar layar, cpu, dsb)
• Api yang dibutuhkan tiap front end berbeda
  • Website yang tampil di pc or laptop dapat menampilkan banyak informasi
  • Berbeda halnya dengan mobile dimana informasi dibatasi karena ukuran layar yang tidak selebar pc atau laptop
  • Sehingga kita buat endpoint berbeda utk tiap frontend

• Semua kebutuhan jenis frontend harus diimplementasikan di satu API Gateway

Untuk mengatasi permasalahan tersebut diatas, kita dapa mengimplementasikan ‘backend for frontend’ atau graphQL

1. Backend for frontend

• Konsep ini menyediakan backend khusus untuk frontend tertentu
• biasanya 1 backend akan melayani spesific 1 frontend
• semakin banyak jenis frontend nya, semakin banyak pula jenis backend nya

• Get data
  • Mobile : 10 field
  • Website : 100 field
  • Server : 1000 field

Sebelumnya ada proses auth di api gateway namun karena proses auth tiap frontend berbeda-beda maka proses auth berpindah ke masing-masing frontend api

Keuntungan

• Pengemabangan backend tiap frontend bisa terisolasi one another
• Logic for frontend doenst be mixed in one backend

2. graphQL

• Konsep ini adalah query language untuk API
• graphQL dapat digunakan untuk manipulate API response secara runtime

frontend ask data 10 field ->  api return 100 field -> graphQL query 10 field -> 10 field

• frontend bebas untuk menentukan data apapun yang ingin didapatkan
• backend hanya menyediakan data lengkap kemudian dari data tersebut frontend dapat memilih data yang diinginkan secara bebas

Kekurangan

• Butuh development graphQL server di backend
• Butuh development graphQL clinet di frontend

Klw tim banyak bisa pakai backed for frontend tapi klw sedikit dan mw ambil risiko bisa pakai graphQL

I. CQRS (Command Query Responsibility Segregation (pemisahan))

• Konsep ini adalah process yang membedakan command operation and query operation
• command operation adalah operasi yang megubah data (create, update, delete)
• query operaton adalah operasi yang mendapatkan data (get, search)
• dalam CQRS, biasanya database untuk service dibedakan untuk kebutuhan command dan query
• jadi kita split module command and query

kita menggunakan konsep ini jika kita mempunyai data besar dan kecepatan akses mulai lemot

• alternative solusi mungkin kita menggunakan indeks to column untuk membuatnya lebih cepat. Kita melakukannya berulang kali hingga kita memiliki banyak kolom yang terindeks. Dengan begitu pengambilan data akan lebih cepat.
• Namun hal ini justru membuat masalah  pada command operation (create, update, delete) karena indeks yang banyak membuat operasi menjadi lambat
• Hal tersebut menjelaskan bahwa kita hanya mempunyai satu pilihan
  • membuat query operation lebih cepat tapi command ops lebih lambat atau
  • membuat command operation lebih cepat tapi query ops lebih lambat

• jadi untuk mengatasi masalah terebut diatas, kita pisah module and database nya

*elastic search, we use because it have best search performance

Kenapa tidak 1 database saja yang digunakan yaitu elastic search ?

• secara umum db jarang ada yang realtime, pencarian itu tentatif seperti menggunakan sufix, prefix, dll. tapi berbeda halnya dengan DB elastic search karen Biasanya db pencarian itu sudah dioptimize buat pencarian
• Ketika kita akan mengubah data structure pada DB elastic search, kita harus melakukan indeks ulang dan insert datanya dari awal lagi.
  • Hal tersebut akan menjadi masalah ketika kita hanya menggunakan 1 database (elastic search) -> sehingga akan terjadi down
• Jika kita mempunyai minimal 2 db dan kita membutuhkan perubahan struktur tabel di DB elastic search. Kita dapat membuat new table in elastic search dan query tetap di table yang lama
  • Data dari mysql dipindahkan ke table baru di elastic search
  • kemudian switch query ke table baru
  • langkah tersebut diatas dapat mecegah downtime
• jadi mysql tidak hanya sebagai primary db tapi juga backup db

Keuntungan CQRS

• dapat memilih db berbeda-beda sesaui kebutuhan untuk mengoptimalkan proses command and query sehingga kedua operasi lebih cepat
• Membedakan model for command and query dalam aplikasi akan memudahkan dalam mengerti flow aplikasi serta meningkatkan performanya daripada menggabunnya dalam satu model yang sama.

Berdasarkan penjelasan sebelumnya diatas maka disarankan product service dipecah jadi 2 service seperti gambar dibawah

• product service and
• product search service

kenapa dipecah?

• Product service : not every time user insert product (have beban ringan) -> No. need improve
• Product search service : every time user search product (have beban tinggi) -> need to improve

Tidak disarankan menggunakan RPI sebagai metode komunikasi karena jika salah satu service mati maka aplikasi error namun berbeda halnya dengan messaging.

Keutungan CQRS menggunakan messaging

• Aplikasi command and query terpisah, jadi dapat dikerjakan oleh tim yang berbeda secara paralel
• Aplikasi command tidak perlu pusing memikirkan struktur data aplikasi query, hanya cukup mengirim datanya ke message broker
• Scaling aplikasi bisa sesuai dengan kebutuhan, baik itu command or query
• Jika aplikasi query sedang nonaktif or error, data from aplikasi command akan tetap aman tersimpan di message broker
• Mekanisme retry akan lebih mudah dilakukan jika melalui message broker

J. Menemukan lokasi service node

• Di kasus yang nyata, kita menggunakan lebih dari 1 node pada service untuk mempertahankan high avaiblity
  • If traffic nya tinggi mungkin kita akan memiliki 3-5 node

• Merchant -> product service (Dimana lokasi product service? Or node yang mana dari product service yang harus di hit karena ada 3)
  • Banyaknya node bisa naik jika traffic tinggi or turun jika traffic rendah
  • Sehingga perubahan jumlah node membuat lokasinya berubah2

• For example

Node nya menggunakan ip address. Maka ip addressnya akan berubah2 jika nodenya nonaktif baru aktif lagi

• So how we find sevice yang selalu berubah2? We can use server side discovery atau client side discovery

1. Server side discovery

• Membuat server khusus sebagai router atau load balancer service
• Client hanya membutuhkan terkoneksi ke router atau load balancer
• Jika jumlah node service bertambah atau berkurang, hanya router yang perlu diubah, client tidak perlu berubah

• Merchant services hit -> product server Load Balancer (LB) -> split traffice to product services
• Klw ada penambahan or penguranga product service yang diubah only load balancer

Contoh router or load balancer

• Nginx
• Apacher Httpd
• Traefik

Kekurangan

• Tiap service harus memiliki router atau load balancer (10 services-> install 10 LB)
  • Knp tidak satu LB saja? 1 LB akan terbebani dengan all trafic dari services dan jika LB nya mati all services kita juga mati
• Agar tidak terjadi single point of failure , maka router or load balancer harus di setup sebanyak 2 instance (agar ada LB backup sehingga services tetap bisa jalan ketika salah satu LB mati)
• Cost biaya akan lebih mahal, karena 1 service harus menjalankan 2 router

2. Client side discovery

• Kebalikan dari server side discovery
• Konsep ini merupakan solusi untuk client mengetahui location of all services yang akan dituju
• Tidak perlu lagi router/load balancer to comunicate with other services
• Semua logic to distribute traffic harus dilakukan di client atau service yang akan melakukan request

• Client di Merchant service harus pintar mendistribusikan request
  • Jika kita menggunakan http client sebagai api kita harus mengaturnya menjadi multple endpoint

Konsep ini cukup complex karena client harus set lokasi node manually tanpa bantuan LoadBalancer namun ini adalah cost yang harus diterima jika kita tidak mau terlalu banyak hardware yang digunakan untuk instal load balancer

Kekurangan

• Client harus tahu lokasi all service
• Jika jumlah node service bertambah or berkurang, client harus diubah untuk lokasi yang baru nya (harus diubah semua service konfigurasinya)
• Jika client salah mengimplementasikan logic utk load balancer, maka traffic ke service yang dituju tidak merata pembagiannya

Saran klw cost tidak ada masalah lebih baik pakai server side discovery

kekurangan point b dari client service sangat susah untuk di solve dan sangat berbahaya, sehingga untuk mengatasi ini kita dapat menggunakan service registry

Service registry

• Ini tetap client side discovery tapi dengan tambahan aplikasi service registry
• Konsep ini adalah aplikasi yang digunakan sebagai tempat untuk menyimpan all information yang berhubungan dengan lokasi service (disimpan di satu service jadi tidak lagi disimpan di setiap service)
• All service akan meregistrasikan alamat lokasi nya di service registry ketika pertama kali nyala (sebelumnya di client side discovery kan manual)
• All service akan laporan ke service registry jika akan berhenti beroperasi, sehingga service registry akan menghilangkan informasi service tersebut agar tidak mendapat traffice dari service yang bertanya

• Merchant service (sy aktif di ip … ) -> tell service registry

• Merchant service -> hit product service -> tapi sebelumnya dia akan bertanya node yang tersedia ke -> service registry

Bertanya sebelum nembak ke service akan membuat process menjadi lambat, sehingga bertanyanya ke service registry dibuat berkala misal 5s sekali kemudian datanya disimpan di merchant service sehingga tidak perlu setiap mw nembak data harus tanya

Fitur service registry : Health check

• Hit ke all services untuk memastikan service masih aktif
  • Karena ada kemungkinan service mati mendadak dan belum sempat info ke service registry

Contoh aplikasi service registry

• Hashicorp consul
• Netflix eureka

K. Centralized configuration

Dimana menyimpan konfigurasi

• Tiap aplikasi biasanya mempunyai configuration, seperti database configuration
• Dimana menyimpan konfigruasi agar mudah dimaintain dan digunakan oleh aplikasi
• Tidak ada ketentuan yang baku

Contoh lokasi konfigurasi

• Database -> masih bisa diubah cuman harus bisa akses ke database
• File (json, php, dll) -> sulit diubah harus akses ke file
• Environment variabel -> sulit diubah apalagi sudah running

Jadi untuk mengatasi masalah tersebut kita menggunakan centralized configuration

• Centralized configuration is pattern where we save all configuration in a aplikasi atau service
• Service yang butuh configuration will ask ke aplikasi tersebut to get data configuration

For example

• Saya aplikas A (konfigurasi saya apa saja)-> ask configuration service -> data configruation -> apliasi a nyala

Data pada centralized configuration dapat di encription sehingga aman jika sewaktu2 datan confignya  bocor

Tidak ada lagi config yang nempel  di tiap service

Contoh aplikasi centralized configuration

• Hashicorp consul (hanya pakai token tidak bisa encrpt)
• Hashicorp vault (bisa encrpt)
• Etcd
• Zookeeper (java)
• Doozerd
• dll

Referensi

Youtube: programer zaman now