These architectures are increasingly diversifying in line with the needs of technological development. In software projects, the architectural design began with the monolithic architecture. The term "monolithic" in software refers to a single-piece coded software method in which the modules cannot be run independently. The architecture in which the entire application is developed as a whole is also called monolithic architecture. Here, all functions are provided from a single package. Monolithic architecture provides an easy structure for distributing the application. The entire system is deployed and distributed with a single package.
To scale the application, that is, to adjust the infrastructure on which the same application will run, it is sufficient to add and remove the servers on which the application runs behind a load balancer. However, in general, the fact that the application is a single piece makes it both large and complex. The collapse of one of the tightly coupled components triggers the failure of the entire system and over time makes it difficult to develop and maintain. In other words, if there is an error in a part of the monolithic system, every service provided will stop working. To solve these problems, layered architecture, service-oriented architecture, and microservice architecture have been developed over time.
Microservices are essentially independent software services that provide a specific feature or function, serving a single purpose, in a software application. Technologies and platforms are independent of each other. Each service has its own business rules and domain. Services communicate with each other through different architectures. This allows the services to be maintained, monitored, and distributed independently.
Microservice architecture is built on SOA, i.e., "Service-Oriented Architecture". SOA is an architecture that allows services to communicate in a distributed system, whether on a single machine or across multiple machines on a network. Both architectures come from the client-server architecture. Microservice architecture can be seen as an extension of SOA with its own unique characteristics. However, the design principles of microservice architecture are not exactly the same as service-oriented architecture. There are differences between SOA and microservice architecture. While SOA is an enterprise-level architecture, microservice architecture is an application-level architecture.
One of the most important features of microservice architecture is that it does not share data structures. Each microservice has its own data storage area (such as a database schema or table). In other words, each one is responsible for its own data model and data. Other services cannot access the storage area they do not own. Microservices can communicate using simple protocols through APIs.
Generally, a single entry point called the API GATEWAY is created. Users making requests to the system make requests through this gateway instead of directly to the microservices. Routing, authorization, and other such operations are performed here. Multiple microservices may be called in the background for this process. Finally, a single result is returned to the user.
Each microservice works with very little dependence (loosely coupled) on other services. These services are self-sufficient and provide a single functionality (or a group of common functionalities).
Mikroservis Mimarisinin Avantajları Nelerdir?
- Bu mimari servislerde sık güncelleme ihtiyacı olan uygulamaların modern ihtiyaçlarını karşılamak için alternatif bir mimari olarak geliştirilmiştir. Mikroservis mimarisinin temel amacı uygulamayı küçük bağımsız servislere bölmektir.
- Çok sık ölçeklendirme gereken bir uygulamada bu mimari önemli faydalar sunar (scalability-ölçeklenebilirlik prensibi.) Onun için sık ölçeklendirme ihtiyacı varsa bu mimari kullanılabilir. Örneğin bir servise yapılan istek diğer servislere nazaran çok arttıysa sadece bu servisin sayısını artırabiliriz. Monolitik uygulamada olduğu gibi tüm sistemi artırmamıza gerek kalmaz.
- Büyük bir sistem ve burada çalışması gereken çok sayıda insan kaynağı varsa, böl parçala yönet mantığıyla iş akışları ayrılarak burada mikroservis mimarisi uygulanabilir.
- Bir servisin durması, hata vermeye başlaması (availability-kullanılabilirlik oranının düşmesi) sistemin diğer fonksiyonlarını etkilememesi için kullanılabilir. Bu prensip isolation of failure (hata izolasyonu) olarak geçer.
- Bazı hizmetlerin, fonksiyonların sürekli güncellenmesi gerekiyorsa bu mimari ile tüm sistemin elden geçirilmesi gerekmez. Çünkü servisler birbirinden tamamen bağımsızdır. Bu da iş birimlerinin pazara çıkma hızını artırmasına yardımcı
- Ayrıca günümüzün iş gereksinimlerine ve çözümlerine ayak uydurmak için günümüzün programlama dillerinde veya teknoloji ürünleriyle eski uygulamaları yeniden yazmanız gerektiğinde de kullanabilirsiniz.
Kural Tabanlı IoT Projesinde Mikroservis Mimarisinin Kullanımı Nedir?
Projenin servislerinin mikroservis olarak olmasının temel sebebi, sektörde görev yapmakta olan çalışanların karmaşık kod yapısını anlayamayıp sürekli desteğe ihtiyaç duymalarından kaynaklanan zorlukların çözümüne yönelik yenilikçi bir yöntem geliştirme ihtiyacı oluşturmaktadır. Üretim ortamında, makinelerin sürekli ayarlamalar ile çalışmasının devam etmesi ve fabrikalardaki zorlu makinelerin iş kazası risklerini arttırması önemli bir problemdir. Kullanıcı dostu bir kural tabanı oluşturmak, oluşturulan bu kuralların makinelerle iletişiminin sağlanması ve makinelerin sürekli işlem verilerini aktarması için bir yapı oluşturulması projenin teknolojik değeridir. Bu işlemin insanlar tarafından basit bir şekilde yönetilmesi içinde Kural Tabanlı İş Yönetim Sistemi’nden (Business Rules Management Systems - BRMSs) yararlanılmaktadır. Bu sistem kullanıcının her türlü kuralı oluşturmasına imkân vermektedir. Oluşturulacak servis yapısıyla birlikte bu kuralların bilgisayarlar tarafından anlaşılabilir hale gelmesi, makinelerle iletişim halinde olması ve kural doğrultusunda gereken programları çalıştırmasını sağlayacaktır. Bu doğrultuda incelendiğinde veri tabanı bulut (cloud) üzerinden haberleşme işlem doğruluğunun sağlanması ve veri büyüklüğü sebebiyle mikroservis mimarisi tercih edilmelidir.
Mikroservis mimarisinin projeye sağladığı avantajlar şu şekildedir:
- RabbitMQ ve Azure Servis Bus olay tabanlı mesajlaşma protokolleri sayesinde servisler arası veri doğruluğunu sağlayabilmekteyiz ve verinin kesintisiz ulaştığından emin olabilmekteyiz.
- Sistem aynı anda birden fazla işlem yapabileceği ve kural işleyebileceği için yavaşlama durumlarında sadece kural işleyen servislerin dağıtımın ölçeklenebilmesi tüm programı ölçeklendirmekten daha düşük maliyete sebep olacaktır.
- Farklı veri tabanlarının kullanılması büyük verilerin işlenmesini kolaylaştırmaktadır.
- Projeye özellik eklenmesine ve geliştirilmesine kolaylık sağlar.
Ceyda TEKİN
İletişim Yazılım / Yazılım Uzmanı
Kaynakça
(https://www.ibm.com/cloud/blog/business-rules-management-systems-101)
(https://ieeexplore.ieee.org/abstract/document/7300793)
(Butzin, B., Golatowski, F., & Timmermann, D. (2016, September). Microservices approach for the internet of things. In 2016 IEEE 21st International Conference on Emerging Technologies and Factory Automation (ETFA) (pp. 1-6). IEEE.)
