Kiến trúc Microservice - Tìm hiểu, Xây dựng và Triển khai Microservices



Blog này giải thích chi tiết về Kiến trúc Microservice. Nó cũng bao gồm những ưu và khuyết điểm và một nghiên cứu điển hình giải thích kiến ​​trúc của UBER.

Kiến trúc Microservice:

Từ của tôi , bạn phải có hiểu biết cơ bản về Kiến trúc Microservice.Nhưng, là một chuyên gia với sẽ yêu cầu nhiều hơn những điều cơ bản. Trong blog này, bạn sẽ đi sâu vào các khái niệm kiến ​​trúc và triển khai chúng bằng cách sử dụng nghiên cứu điển hình UBER.

Trong blog này, bạn sẽ tìm hiểu về những điều sau:





  • Định nghĩa về kiến ​​trúc Microservice
  • Các khái niệm chính của kiến ​​trúc microservice
  • Ưu và nhược điểm của kiến ​​trúc Microservice
  • UBER - Nghiên cứu điển hình

Bạn có thể tham khảo , để hiểu các nguyên tắc cơ bản và lợi ích của Microservices.

Sẽ chỉ công bằng nếu tôi cung cấp cho bạn định nghĩa về Microservices.



Định nghĩa của Microservices

Do đó, không có định nghĩa thích hợp về Microservices hay còn gọi là Kiến trúc Microservice, nhưng bạn có thể nói rằng nó là một khuôn khổ bao gồm các dịch vụ nhỏ, có thể triển khai riêng lẻ thực hiện các hoạt động khác nhau.

Microservices tập trung vào một miền doanh nghiệp duy nhất có thể được triển khai dưới dạng các dịch vụ có thể triển khai độc lập hoàn toàn và triển khai chúng trên các ngăn xếp công nghệ khác nhau.

Sự khác biệt giữa kiến ​​trúc nguyên khối và thiết bị siêu nhỏ - Kiến trúc microservice - Edureka



Hình 1: Sự khác biệt giữa kiến ​​trúc nguyên khối và kiến ​​trúc microservice - Kiến trúc microservice

Tham khảo sơ đồ trên để hiểu sự khác biệt giữa kiến ​​trúc nguyên khối và microservice.Để hiểu rõ hơn về sự khác biệt giữa cả hai kiến ​​trúc, bạn có thể tham khảo blog trước của tôi

Để bạn hiểu rõ hơn, hãy để tôi cho bạn biết một số khái niệm chính về kiến ​​trúc microservice.

Các khái niệm chính của kiến ​​trúc microservice

Trước khi bắt đầu xây dựng các ứng dụng của riêng mình bằng microservices, bạn cần phải hiểu rõ về phạm vi và các chức năng của ứng dụng của mình.

Sau đây là một số nguyên tắc cần tuân thủ khi thảo luận về microservices.

Nguyên tắc khi thiết kế dịch vụ nhỏ

cách tạo chuỗi ngẫu nhiên trong java
  • Là một nhà phát triển, khi bạn quyết định xây dựng một ứng dụng, hãy tách biệt các miền và rõ ràng với các chức năng.
  • Mỗi microservice mà bạn thiết kế sẽ chỉ tập trung vào một dịch vụ của ứng dụng.
  • Đảm bảo rằng bạn đã thiết kế ứng dụng theo cách mà mỗi dịch vụ có thể triển khai riêng lẻ.
  • Đảm bảo rằng giao tiếp giữa các microservices được thực hiện thông qua một máy chủ không trạng thái.
  • Mỗi dịch vụ có thể được tái cấu trúc lại thành các dịch vụ nhỏ hơn, có các microservices của riêng chúng.

Bây giờ, bạn đã đọc qua các nguyên tắc cơ bản khi thiết kế microservices, hãy hiểu kiến ​​trúc của microservices.

Kiến trúc Microservice hoạt động như thế nào?

Một Kiến trúc Microservice (MSA) điển hình phải bao gồm các thành phần sau:

  1. Khách hàng
  2. Nhà cung cấp danh tính
  3. API cổng
  4. Định dạng nhắn tin
  5. Cơ sở dữ liệu
  6. Nội dung tĩnh
  7. Sự quản lý
  8. Khám phá dịch vụ

Tham khảo sơ đồ bên dưới.

Hình 2: Architecture Of Microservices - Kiến trúc Microservice

Tôi biết kiến ​​trúc trông hơi phức tạp, nhưng hãyTôiđơn giản hóa nó cho bạn.

1. Khách hàng

Kiến trúc bắt đầu với các loại máy khách khác nhau, từ các thiết bị khác nhau cố gắng thực hiện các khả năng quản lý khác nhau như tìm kiếm, xây dựng, cấu hình, v.v.

2. Nhà cung cấp danh tính

Các yêu cầu này từ khách hàng sau đó được chuyển đến các nhà cung cấp danh tính xác thực yêu cầu của khách hàng và truyền đạt yêu cầu tới API Gateway. Các yêu cầu sau đó được truyền đạt đến các dịch vụ nội bộ thông qua API Gateway được xác định rõ.

3. Cổng API

Vì khách hàng không gọi trực tiếp đến các dịch vụ, API Gateway đóng vai trò như một điểm vào để khách hàng chuyển tiếp các yêu cầu tới các dịch vụ nhỏ thích hợp.

Những lợi thế của việc sử dụng cổng API bao gồm:

  • Tất cả các dịch vụ có thể được cập nhật mà khách hàng không biết.
  • Các dịch vụ cũng có thể sử dụng các giao thức nhắn tin không thân thiện với web.
  • API Gateway có thể thực hiện các chức năng xuyên suốt như cung cấp bảo mật, cân bằng tải, v.v.

Sau khi nhận được yêu cầu của khách hàng, kiến ​​trúc nội bộ bao gồm các microservices giao tiếp với nhau thông qua các thông điệp để xử lý các yêu cầu của khách hàng.

4. Định dạng nhắn tin

Có hai loại thông điệp mà chúng giao tiếp:

  • Tin nhắn đồng bộ: Trong tình huống khách hàng đợi phản hồi từ một dịch vụ, Microservices thường có xu hướng sử dụng REST (Chuyển trạng thái đại diện) vì nó dựa trên một máy chủ, không trạng thái, và Giao thức HTTP . Giao thức này được sử dụng vì nó là một môi trường phân tán, mỗi và mọi chức năng được thể hiện bằng một tài nguyên để thực hiện các hoạt động
  • Tin nhắn không đồng bộ: Trong trường hợp khách hàng không đợi phản hồi từ một dịch vụ, Microservices thường có xu hướng sử dụng các giao thức như AMQP, STOMP, MQTT . Các giao thức này được sử dụng trong kiểu giao tiếp này vì bản chất của các thông điệp được xác định và các thông điệp này phải có khả năng tương tác giữa các lần triển khai.

Câu hỏi tiếp theo có thể xuất hiện trong đầu bạn là các ứng dụng sử dụng Microservices xử lý dữ liệu của chúng như thế nào?

5. Xử lý dữ liệu

Mỗi Microservice đều sở hữu một cơ sở dữ liệu riêng để thu thập dữ liệu của họ và triển khai các chức năng kinh doanh tương ứng. Ngoài ra, cơ sở dữ liệu của Microservice chỉ được cập nhật thông qua API dịch vụ của họ. Tham khảo sơ đồ bên dưới:

Hình 3: Biểu diễn dữ liệu xử lý microservices - Kiến trúc microservice

Các dịch vụ do Microservices cung cấp được chuyển tiếp đến bất kỳ dịch vụ từ xa nào hỗ trợ giao tiếp giữa các quá trình cho các ngăn xếp công nghệ khác nhau.

6. Nội dung tĩnh

Sau khi các Microservices giao tiếp với nhau, chúng triển khai nội dung tĩnh tới một dịch vụ lưu trữ dựa trên đám mây có thể phân phối chúng trực tiếp đến khách hàng thông qua Mạng phân phối nội dung (CDN) .

Ngoài các thành phần trên, có một số thành phần khác xuất hiện trong Kiến trúc Microservices điển hình:

7. Quản lý

Thành phần này chịu trách nhiệm cân bằng các dịch vụ trên các nút và xác định các lỗi.

8. Khám phá dịch vụ

Hoạt động như một hướng dẫn để Microservices tìm ra lộ trình giao tiếp giữa chúng vì nó duy trì một danh sách các dịch vụ có các nút nằm trên đó.

Đăng ký kênh youtube của chúng tôi để cập nhật những thông tin mới ..!

Bây giờ, hãy xem xét những ưu và nhược điểm của kiến ​​trúc này để hiểu rõ hơn về thời điểm sử dụng kiến ​​trúc này.

Ưu và nhược điểm của Kiến trúc Microservice

Tham khảo bảng dưới đây.

Ưu điểm của kiến ​​trúc Microservice Nhược điểm của Microservice Ngành kiến ​​trúc
Tự do sử dụng các công nghệ khác nhauTăng thách thức gỡ rối
Mỗi microservice tập trung vào khả năng kinh doanh đơn lẻTăng độ trễ do các cuộc gọi từ xa
Hỗ trợ các đơn vị có thể triển khai riêng lẻTăng cường nỗ lực cấu hình và các hoạt động khác
Cho phép phát hành phần mềm thường xuyênKhó duy trì an toàn giao dịch
Đảm bảo tính bảo mật của từng dịch vụKhó theo dõi dữ liệu qua các ranh giới dịch vụ khác nhau
Nhiều dịch vụ được phát triển và triển khai song songKhó di chuyển mã giữa các dịch vụ

Hãy để chúng tôi hiểu thêm về Microservices bằng cách so sánh kiến ​​trúc trước đây của UBER với kiến ​​trúc hiện tại.

NGHIÊN CỨU TRƯỜNG HỢP UBER

Kiến trúc trước đây của UBER

Giống như nhiều công ty khởi nghiệp khác, UBER bắt đầu hành trình của mình với một kiến ​​trúc nguyên khối được xây dựng cho một dịch vụ duy nhất trong một thành phố. Có một cơ sở mã dường như đã được làm sạch vào thời điểm đó và giải quyết các vấn đề kinh doanh cốt lõi của UBER. Tuy nhiên, khi UBER bắt đầu mở rộng ra toàn thế giới, họ phải đối mặt với nhiều vấn đề khác nhau liên quan đến khả năng mở rộng và tích hợp liên tục.

Hinh 4: Kiến trúc nguyên khối của UBER - Kiến trúc Microservice

Sơ đồ trên mô tả kiến ​​trúc trước đây của UBER.

  • Có một API REST để hành khách và tài xế kết nối với nhau.
  • Ba bộ điều hợp khác nhau được sử dụng với API bên trong chúng, để thực hiện các hành động như lập hóa đơn, thanh toán, gửi email / tin nhắn mà chúng tôi thấy khi đặt taxi.
  • Một cơ sở dữ liệu MySQL để lưu trữ tất cả dữ liệu của họ.

Vì vậy, nếu bạn nhận thấy ở đây, tất cả các tính năng như quản lý hành khách, thanh toán, tính năng thông báo, thanh toán, quản lý chuyến đi và quản lý tài xế đều được tạo trong một khuôn khổ duy nhất.

Báo cáo vấn đề

Trong khi UBER bắt đầu mở rộng trên toàn thế giới, loại khuôn khổ này đã đưa ra nhiều thách thức khác nhau. Sau đây là một số thách thức nổi bật

  • Tất cả các tính năng phải được xây dựng lại, triển khai và thử nghiệm lại nhiều lần để cập nhật một tính năng duy nhất.
  • Việc sửa lỗi trở nên cực kỳ khó khăn trong một kho lưu trữ vì các nhà phát triển phải thay đổi mã nhiều lần.
  • Việc mở rộng các tính năng đồng thời với việc giới thiệu các tính năng mới trên toàn thế giới là điều khá khó khăn để xử lý cùng nhau.

Giải pháp

Để tránh những vấn đề như vậy, UBER quyết định thay đổi kiến ​​trúc của mình và tiếp bước các công ty siêu tăng trưởng khác như Amazon, Netflix, Twitter và nhiều công ty khác. Do đó, UBER quyết định phá vỡ kiến ​​trúc nguyên khối của nó thành nhiều cơ sở mã để tạo thành kiến ​​trúc microservice.

Tham khảo sơ đồ bên dưới để xem kiến ​​trúc microservice của UBER.

Hình 5: Kiến trúc Microservice của UBER - Kiến trúc Microservice

  • Sự thay đổi lớn mà chúng tôi quan sát được ở đây là sự ra đời của API Gateway mà qua đó tất cả người lái và hành khách được kết nối với nhau. Từ API Gateway, tất cả các điểm nội bộ được kết nối như quản lý hành khách, quản lý tài xế, quản lý chuyến đi và các điểm khác.
  • Các đơn vị là các đơn vị có thể triển khai riêng lẻ thực hiện các chức năng riêng biệt.
    • Ví dụ: Nếu bạn muốn thay đổi bất kỳ điều gì trong Microservices thanh toán, thì bạn chỉ cần triển khai Microservices thanh toán và không phải triển khai các Microservices khác.
  • Tất cả các tính năng hiện đã được chia tỷ lệ riêng lẻ, tức là sự phụ thuộc lẫn nhau giữa mỗi và mọi tính năng đã bị loại bỏ.
    • Ví dụ, chúng ta đều biết rằng số người tìm kiếm xe taxi tương đối nhiều hơn số người thực sự đặt xe taxi và thanh toán. Điều này khiến chúng tôi suy luận rằng số quy trình hoạt động trên dịch vụ vi mô quản lý hành khách nhiều hơn số quy trình hoạt động trên thanh toán.

Trong nàyđường, UBER được hưởng lợi nhờ chuyển đổinó làkiến trúc từ nguyên khối sang Microservices.

Tôi hy vọng bạn đã thích đọc bài đăng này trên Kiến trúc Microservice.Tôi sẽ tạo ra nhiều blog hơn, trong đó cũng sẽ có các bài viết thực hành.
Bạn muốn tìm hiểu thêm về Microservices?

Nếu bạn muốn tìm hiểu Microservices và xây dựng các ứng dụng của riêng mình, hãy xem đi kèm với đào tạo trực tiếp do người hướng dẫn và trải nghiệm dự án thực tế. Khóa đào tạo này sẽ giúp bạn hiểu sâu về Microservices và giúp bạn thành thạo chủ đề này.

Có một câu hỏi cho chúng tôi? Hãy đề cập đến nó trong phần bình luận của ” Kiến trúc Microservice ”Và tôi sẽ liên lạc lại với bạn.