Articles and some problems about programming

Aspect Oriented Programming Proqrama kenardan yanashilir. Niye lazimdir ? Proqramda chixan xetalar barede xeberdar olmaq uchun try catch istifade edilmelidir. Bunu AOP la da etmek mumkundur.   Tutaq ki, her hansi bir servis classin da her hansi bir metoda hansi userin muraciet etdiyini teyin etmek lazimdir, meselen hal hazir da login olar user hansi metodlara muraciet etdi. Bu meseleni her bir metod uchun ayrica da yazmaq olar, sadece metodlari sayi chox olduqda bu chetin olacaq. Spring Proxy Pattern istifade etdiyine gore AOP anlayishindan Spring de movcuddur. Yeni bir her hansi bir oz obyektimizin metodunu cagiran zaman, eslinde hemin obyektin Proxy obyektininin metodunu cagiririq. Hemin Proxy obyekt gedir bizim obyektin metodunu cagirir. Bu da Spring e AOP u istifade etmeye imkan yaradir. Esas istifade olunan ozelliyi Logging dir. Istifadesi : Ilk once classin bashina @Aspect annotation yazilir. Note: @Component de yazilmalidir ki, bu class Spring terefinden yaradilsin

Spring Cloud teqdim etdiyi bezi ozellikler Config Server - Butun konfiqurasiyalari ozunde saxlayan bir server teqdim edir. Bu konfiqurasiyalari git uzerinde saxlamaq mumkundur. Arxada ishleyen zaman git vasitesile bu konfiq.-e chata bilir. Encrypting and Decrypting ozelliyine sahibdir. Service Registry - servislerin unvanini saxlayir, kataloq yaradir. Meselen Euroka Server. Logging Sleuth - butun servislerde enable etdiyiz zaman butun loglar i dashboard a dushur. Stream - servisler arasinda elaqe qurmalari uchun vasitedir. Meselen, Kafka, RabbitMQ, ActiveMQ gostermek olar. Load Balancer - servislerin yukune gore yeni servislerin yaranib yaranmamasini idare edir. Circuit Breaker - eger bir servis davamli olaraq xeta alirsa, elaqeni kesmek uchun istifade olunur. Cluster Management - butun class lari idare etmek uchun istifade olunan ozellik. Distributed Messaging - oz yazdigimiz api - lerin inteqrasiyasini istifade etmek uchun olan ozellik Auth server - authorization ve a

Mikroservisleri tercih etmek uchun 4 esas sebeb var : Scalability Bu ozellik monolit application da da mumkundur. Horizontal ve Vertical Scalability: - Horizontal, Serverimiz tutaq ki , 4gb ram da ishleyir. Hal hazir ki veziyyete gore uygun olsada musteri sayi artandan sonra serverin ramini artira bilerik. Lakin bunun bir limiti vardir. (diger paratmetrlerde daxilidr, cpu, harddrive). Yeni horizontal - sistemi guclendirmek basha dushulur. Burada limit oldugundan , sonradan yeni sistem alinmalidir, lakin server yalniz bir komputer olmalidir. - Vertical, burada yaradilan servisin kopyasini yaratmaq basha dushulur. Esasen mikroservis arxitekturasinda istifade olunur. Meselen Account Service 1000 sorgu emal ede bilirse, bu servisin kopyasi da 1000 sorgu emal edecek. Bu mikroservis oluduguna gore ishletdiyi ram daha az olacaqdir (ve ya diger parametrler) Burada servislerin kopyasini avtomatik yaradilmasini temin eden sistemler var ki, bunlara misal olaraq Kubernetes, Rancher ve ya cust

================ sudo usermod -aG docker docker istifade edende her defe sudo yazmamaq uchun komanda ================ docker run -p 8080:8080 -d /path/to/image burada gosterilen image docker container-de 8080 portunda run olacaq (2ci 8080), ve bizim localimizin 8080 portuna bind olacaq. bu zaman bu image i 8080 portunda istifade ede bilerik.  -d ise detached modda ishlediyini gosterir. yeni terminla baglansa bele container run olunmush veziyyetde qalacaq.  ================ docker container in loglarina baxmaq uchun docker logs (-f) <container_id> -f option loglari davamli olaraq izlemek uchun istifade olunur. bu option olmadan loglara baxsaq sadece hazirki veziyyeti gosterib bitirecek. davamli olaraq loglara baxa bilmeyeceyik. ================ docker image <image_id> history - image haqqinda butun history ni gosterir. (dockerfile daki komandalar) docker image <image_id> inspect - image haqqinda butun melumatlari verir. ================ docker inspect <container_id&