vi
new
+4
Avatar
Dao Van Tuan @tuandv2611
159 6 13
Đã đăng vào thg 6 24, 2016 2:48 SA 10 phút đọc
6.6K

Pattern - Microservices Architecture

Overview

Microservices Architecture là một mô hình kiến trúc để phát triển hệ thống phần mềm. Chúng được ứng dụng để thay đổi cho mô hình cấu trúc một khối. Nhờ khả năng mở rộng rất dễ dàng của kiến trúc này mà nó được coi là kiến trúc lý tưởng để xây dựng lên nền tảng phát triển diện rộng trên các thiết bị di dộng, internet, web...

Case study

Lấy một Case study cụ thể: xây dựng một ứng dụng doanh nghiệp server-side. Nó phải hỗ trợ tất cả mọi người dùng trên các thiết bị di động, các trình duyệt trên các máy tính để bàn hay các thiết bị mobile. Ứng dụng này cũng cung cấp cả API cho bên thứ ba có thể sử dụng được. Và Ứng dụng này cũng có thể tích hợp các ứng dụng khác thông qua web service hoặc message broker. Các ứng dụng sử lý yêu cầu (HTTP request và messages) bằng cách thực hiện business logic, truy cập vào cơ sở dữ liệu để có thể trao đổi messages với các hệ thống khác. Reponse trả về có định dạng format HTML/JSON/XML.

Các ứng dụng này được thể hiện một kiến trúc lớp hoặc hình lục giác bao gồm các component khác nhau:

  • Presentation components: xử lý các yêu cầu HTTP và trả về dạng HTML/JSON/XML (webs services APIS)
  • Business logic: Xử lý nghiệp vụ
  • Database access logic: truy vấn và cập nhật dữ liệu.
  • Application integration logic: quản lý messages, ví dụ dựa trên tích hợp Sring

Chúng là những thàng phần hợp lý tương ứng với các chức năng khác nhau của ứng dụng.

Problem

Chúng ta nên lựa chọn kiến trúc nào để triển khai ứng dụng trên?

Forces

  • Nhóm phát triển thực hiện trên cùng một ứng dụng
  • Các members mới phải nhanh chóng trở thành key để tham gia tạo ứng dụng
  • Ứng dụng được viết dễ hiểu và sể maintain
  • Ứng dụng luôn được triển khai và nâng cấp
  • Cần phải chạy nhiều bản release khác nhau trên nhiều máy tính để so sánh và fix các vấn đề của ứng dụng, đáp ứng tính mở rộng và luôn sẵn sàng xử lý các yêu cầu.
  • Tận dụng lợi thế các công nghệ mới nhất, các frameworks, các ngôn ngữ lập trình mới...

Solution

Áp dụng kiến trúc Scale Cube (thay đổi trên trục y) và chức năng decompose các ứng dụng vào một tập hợp các dịch vụ. Mỗi dịch vụ thực hiện một tập các chức năng liên quan. Ví dụ một ứng dụng có thể bao gồm các dịch vụ như quản lý order service, quản lý customer service...

Các services thực hiện giao tiếp thông qua giao thức đồng bộ HTTP/REST hoặc giao thức không đồng bộ AMPQ (Advanced Message Queuing Protocol)

Các dịch vụ được phát triển và triển khai độc lập với nhau.

Mỗi dịch vụ có cơ sở dữ liệu riêng của mình để có thể tách riêng từ các dịch vụ khác. Các dữ liệu phải được duy trì bằng cách sử dụng cơ chế tái tạo cơ sở dữ liệu hoặc từ các events ở các cấp của ứng dụng

Example

Hãy tưởng tượng rằng bạn đang xây dựng một ứng dụng thương mại điện tử mà có đơn đặt hàng từ khách hàng, có hàng tồn kho, thanh toán, ship. Ứng dụng này bao gồm các thành phần StoreFrontUI, thực hiện các giao diện người dùng cùng với một số dịch vụ kiểm tra tín dụng, duy trì hàng tồn kho và vận chuyển.

Ứng dụng này bạn sẽ hiểu nó như một ứng dụng được tích hợp các dịch vụ, order, inventory, credit, ship..

DecomposingApplications.027.jpg

Resulting

Advantage

  1. Mỗi microservice là một cấu trúc nhỏ: Chia nhỏ ứng dụng một khối cồng kềnh thành các dịch vụ nhỏ dễ quản lý, bảo trì nâng cấp, tự do chọn, nâng cấp công nghệ mới.

  2. Mỗi dịch vụ nhỏ sẽ định ra ranh giới rõ ràng dưới dạng RPC hay API Messages.

  3. Dễ dàng mở rộng qui mô phát triển, cho phép phát triển các thành phần xung quanh dễ dàng. mỗi team phát triển, triển khai độc lập với các team khác.

  4. Microservice thúc đẩy tách rạch ròi các khối chức năng (loose coupling - high cohesion), điều rất khó thực hiện với ứng dụng một khối. Nếu muốn loose coupling - high cohesion trong ứng dụng một khối, sẽ phải thiết kế theo Design Pattern (Gang Of Four) và liên tục tái cấu trúc.

  5. Cải thiện cách tìm ra lỗi dễ dàng bằng việc cô lập từng service, ví dụ: nếu có một rò rỉ bộ nhớ trong một dịch vụ thì chỉ có dịch vụ đó bị ảnh hưởng. Các dịch vụ khác sẽ tiếp tục xử lý các yêu cầu.

Disadvantages

  1. Phải xử lý sự cố khi kết nối chậm, lỗi khi thông điệp không gửi được hoặc thông điệp gửi đến nhiều đích đến vào các thời điểm khác nhau.

  2. Đảm bảo giao dịch phân tán (distributed transaction) cập nhật dữ liệu đúng đắn (all or none) vào nhiều dịch vụ nhỏ khác nhau khó hơn rất nhiều, đôi khi là không thể so với đảm bảo giao dịch cập nhật vào nhiều bảng trong một cơ sở dữ liệu trung tâm.

  3. Theo nguyên tắc CAP (CAP theorem) thì giao dịch phân tán sẽ không thể thỏa mãn cả 3 điều kiện: consistency (dữ liệu ở điểm khác nhau trong mạng phải giống nhau), availablity (yêu cầu gửi đi phải có phúc đáp), partition tolerance (hệ thống vẫn hoạt động được ngay cả khi mạng bị lỗi). Những công nghệ cơ sở dữ liệu phi quan hệ (NoSQL) hay môi giới thông điệp (message broker) tốt nhất hiện nay cũng chưa vượt qua nguyên tắc CAP.

  4. Kiểm thử tự động một dịch vụ trong kiến trúc microservices đôi khi yêu cầu phải chạy cả các dịch vụ nhỏ khác mà nó phụ thuộc. Do đó khi phân rã ứng dụng một khối thành microservices cần luôn kiểm tra mức độ ràng buộc giữa các dịch vụ mềm dẻo hơn hay cứng nhắc - lệ thuộc hơn. Nếu ràng buộc ít đi, lỏng leo hơn, bạn đi đúng hướng và ngược lại.

  5. Nếu các dịch vụ nhỏ thiết kế phục thuộc vào nhau theo chuỗi. A gọi B, B gọi C, C gọi D. Nếu một mắt xích có giao tiếp API thay đổi, liệu các mắt xích khác có phải thay đổi theo không? Nếu có thì việc bảo trì, kiểm thử sẽ phức tạp tương tự ứng dụng một khối. Thiết kế dịch vụ tốt sẽ giảm tối đa ảnh hưởng lan truyền đến các dịch vụ khác.

  6. Triển khai dịch vụ microservices nếu làm thủ công theo cách đã làm với ứng dụng một khối phức tạp hơn rất nhiều. Ứng dụng một khối bổ xung các server mới giống hệt nhau đằng sau bộ cần bằng tại. Trong khi ở kiến trúc microservice, các dịch vụ nhỏ nằm trên nhiều máy ảo hay Docker container khác nhau, hoặc một dịch vụ có nhiều thực thể phân tán ra nhiều. Theo Adrian Crockcroft, Hailo có 160 dịch vụ, NetFlix có hơn 600 dịch vụ. Trong dịch vụ đám mây, các máy ảo, docker container, thực thể có thể linh động bật tắt, dịch chuyển. Vậy cần thiết phải có một cơ chế phát hiện dịch vụ (service discovery mechanism) để cập nhật tự động địa chỉ IP và cổng, mô tả, phiên bản của mỗi dịch vụ.

Related patterns

Những patterns liên quan đến microservices

PatternsRelatedToMicroservices.jpg

  1. The Monolithic architecture là một kiến trúc thay thế cho microservices

  2. The API Gateway pattern định nghĩa việc truy khách hàng truy cập vào dịch vụ trong kiến trúc microservices như thế nào

  3. The Client-side Discovery and Server-side Discovery patterns

  4. The Messaging and Remote Procedure

  5. The Single Service per Host and Multiple Services per Host patterns

  6. The Database per Service pattern

  7. The Microservice chassis pattern

Regard

Bài này được dịch từ http://microservices.io/patterns/microservices.html .

Kiến trúc một khối sẽ hữu hiệu đối với ứng dụng đơn giản, ít chức năng. Nó bộc lộ nhiều nhược điểm khi ứng dụng phát triển lớn nhiều chức năng. Kiến trúc microservices chia nhỏ kiến trúc một khối ra các dịch vụ nhỏ. Microservices sẽ hiệu quả, phù hợp cho những ứng dụng phức tạp, liên tục phát triển nếu được thiết kế đúng và tận dụng các công nghệ quản lý, vận hành tự động.

Tài liệu tham khảo

https://techmaster.vn/posts/33594/gioi-thieu-ve-microservices

http://microservices.io/patterns/microservices.html

https://smartbear.com/learn/api-design/what-are-microservices

Design Programming Design Pattern architecture

All rights reserved

Mục lục


Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí