Một mô hình hoạt động cho Microservices

Bài đăng này đã không được cập nhật trong 2 năm

Bài viết này không phải là một bài giới thiệu về microservices, nếu cần bạn có thể đọc nó từ tác giả mà nếu ai làm về Java đều biết Fowler - Microservices Mục đích bài viết sẽ giới thiệu một mô hình hoạt động microservices để decompose một monolithic application thành các microservices do đó việc deploy và scale application trở thành dễ dàng hơn. Khi số lượng các microservices trong application tăng lên sẽ phát sinh các vấn đề mới, bài viết này sẽ focus vào những vấn đề này và xây dựng lên một mô hình triển khai cho một hệ thống gồm nhiều microservices Nội dung bài viết:

Prerequisites
Scaling up
Questions
Required components
A reference model
Next step

1. Prerequisites

Theo Fowler’s blog post việc chia tách một ứng dụng truyền thống monolithic application thành các microservices giúp chúng ta đạt được những điều sau đây:

Tuy nhiên trước khi có thể deploy một hệ thống gồm nhiều microservices, phải đạt một số điều kiện cần dưới đây:

A target architecture: Có một kiến trúc cho hệ thống rõ ràng
A continuous delivery tool chain: CI/CD tools
A proper organization: Organization phù hợp để phát triển và vận hành hệ thống

1.1 A target architerture

Trước khi bắt tay vào phát triển cần xác định rõ kiến trúc cho hệ thống, làm thế nào để phân tách các chức năng của hệ thống thành các microservices. Ví dụ chúng ta có thể phân tách chúng thành các layers theo chiều dọc(vertically):

Core services: Xử lý các logic tầng bussiness, các core logic dùng chung
Composite services: Kết hợp một số các core services để expose ra các API cần thiết, hoặc dùng để aggregate data từ các core services
API services: Expose ra các external APIs do đó các Client có thể trực tiếp truy xuất đến các API này

Đồng thời chúng ta có thể kết hợp để tách các Domain theo chiều ngang áp dụng DDD(Domain Driven Design). Kết hợp cả 2 các phân tách ngang và dọc chúng ta có một kiến trúc như dưới đây: Architecture

1.2 Continuous delivery

Áp dụng DEVOPS và sử dụng các CI/CD tools, giúp việc deploy các microservices nhanh chóng hiệu quả và tin cậy hơn:

Devops

1.3 Organization

Cuối cùng, để làm được điều trên cũng cần phải có một organization phù hợp để vận hành chúng, tránh việc thiết kế microservices theo Conway’s law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Đại ý là một tổ chức mà thiết kế ra một hệ thông kiểu gì các ông ấy cũng áp đặt cái hệ thống communication của mình vào cái hệ thông thiết kế đó, nên tránh điều này và chia microservices theo hướng bussiness

Organization

2. Scaling up

Chuyện gì sẽ xảy ra khi chúng ta decompose một vài monolithic applications thành nhiều microservices

1. Larger number of deployed units: Các microservices sẽ gia tăng đáng kể => cần thêm effort để deploy, manage và monitor. 2. The microservices will both expose and consume services: Các microservices có thể sẽ vừa expose ra các API đồng thời sẽ giao tiếp trực tiếp với nhau. 3. Some microservices will expose an external API: Chỉ một số services chịu trách nhiệu expose ra các external APIs. 4. The system landscape will be more dynamic: Các services có thể được thêm hoặc được loại bỏ với tần suất liên tục. 5.MTBF(Mean time between failures) will decrease, e.g. failures will happen more frequently in the system landscape: Do số lượng các services tăng, nên sẽ không tránh khỏi việc một vài services sẽ down ở một thời điểm nào đó.

3. Questions

Đến đây một số câu hỏi sau sẽ nảy trong đầu các bạn khi bắt đầu nghĩ về áp dụng kiến trúc microservices: 1. Làm thế nào để config tất cả các microservices? Với một hệ thống gồm nhiều microservices được deploy với nhiều instance khác nhau trên các server vật lý khác nhau, việc config cho cả hệ thống trở nên phức tạp hơn, sao để việc config dễ maintain và quản lý 2. Những microservices nào sẽ được deploy và deploy ở đâu? Monitor các host và post các services là cực kỳ quan trọng, đặc biệt khi các services được replace liên tục và deploy trên môi trường cloud nơi mà IP address và port của các server là dynamic. 3. Làm thế nào quản lý routing cho các microservices? 4. Làm sao để ngăn ngừa chain of failures của hệ thống? Vì các microservices sẽ interconnected(kết nối nội bộ) với nhau, phụ thuộc vào nhau nên có khả năng nếu 1 service chết sẽ kéo theo các sevices phụ thuộc vào nó chết => hệ thống sụp đổ. 5. Làm thế nào để biết tất cả các services đang hoạt động tốt? 6. Làm thế nào để track được 1 request được truyền qua nhiều services? Giả sử có một đơn hàng có id=12345 bị pending, đơn hàng này cần được xử lý qua 2 services A và B, sao để biết được đơn hàng bị pending do service A hay B. 7. Làm sao bảo đảm rằng chỉ những API cần thiết mới được expose ra ngoài? Authenticate và Authorize các microservices như thế nào?

4. Required Components

chúng tôi suggest các solution cho lần lượt các câu hỏi ở trên:

1. Central Configuration server: Thay vì config cho từng microservice dưới dạng local file config, chúng ta cần config các file cấu hình ở một chỗ, và cung cấp các configuration APIs do đó các microservices có thể fetch các cấu hình cần thiết cho chúng thông qua các API 2. Service Discovery Server: Sử dụng một service chuyên cung cấp thông tin các microservices cho cả hệ thống đồng thời cho phép các microservice co thể tự register cho chính mình trên service này. Tưởng tượng rằng khi 1 service A cần giao tiếp với service B. Vì địa chỉ IP và Port của service B có thể thay đổi bất kỳ lúc nào, nên nếu A luôn gọi trực tiếp B qua IP và Port khi B thay đổi thì A sẽ ko thể connect được với B. Để giải quyết vấn đề này A chỉ cần biết đến B qua một Alias name, khi B thay đổi IP hay Port, B sẽ register lại trên service discovery server với Alias name, IP và port. A chỉ cần tìm alias name của B trên service discovery server là sẽ biết được IP và Port của B, A ko cần giữ config của B mà sử dụng server trung gian quản lý các config này. 3. Dynamic Routing and Load Balancer: Sử dụng các routing components và load balancer để routing request và điều phối request đến các instance khác của một microservice 4. Circuit Breaker: Áp dụng Circuit Breaker pattern để ngăn ngừa chain of failures problem, chi tiết hơn các bạn có thể đọc Fowler - Circuit Breaker 5. Monitoring 6. Centralized log analysis: Để có thể track được request và detect tại sao request bị pending chúng ta cần một hệ thống để quản lý log tập trung, collect log files của các microservice và phân tích các file đó 7. Edge Server and OAuth 2.0 protected API’s: Edge Server là một proxy server quản lý tất cả các request từ bên ngoài access vào hệ thống, và sử dụng OAuth 2.0 đế authenticate và authorize các APIs.