Kiến ​​trúc microservice: tất cả mọi thứ bạn cần để bắt đầu

Kiến ​​trúc microservice: tất cả mọi thứ bạn cần để bắt đầu

Kiến trúc microservice là một trong những xu hướng kiến ​​trúc phần mềm được thảo luận nhiều nhất tại thời điểm này và nó đã thay đổi mãi mãi cách thức xây dựng các ứng dụng doanh nghiệp.

Thay vì cách tiếp cận nguyên khối (monolithic) chậm chạp, phức tạp trong quá khứ, các nhà phát triển và công ty ở khắp mọi nơi đang chuyển sang kiến ​​trúc microservice để đơn giản hóa và mở rộng cấu trúc của họ.

Trên thực tế, ngay cả các công ty như Amazon, Netflix, Spotify và Uber cũng đã thực hiện quá trình chuyển đổi này từ lâu rồi.

Cho dù bạn muốn bắt đầu với microservice hay bạn chỉ tò mò về cuộc tranh luận xung quanh nó, bạn đang ở đúng nơi.

Hôm nay, tôi sẽ hướng dẫn bạn mọi thứ bạn cần biết về microservice, từ các ví dụ thực tế đến các mẫu kiến ​​trúc và hơn thế nữa.

Chúng tôi sẽ tìm hiểu những điều sau đây:

  • Kiến trúc microservice là gì?
  • Ưu điểm và nhược điểm.
  • Microservice và Docker.
  • Ngăn xếp công nghệ và mô hình kiến ​​trúc.

Bắt đầu nào!


Kiến trúc microservice là gì?

Không có định nghĩa phổ quát về thuật ngữ microservice. Định nghĩa đơn giản nhất của microservice, còn được gọi là kiến trúc microservice (microservice architecture), là một kiểu kiến ​​trúc ứng dụng sử dụng các dịch vụ được liên kết lỏng lẻo. Các dịch vụ này có thể được phát triển, triển khai và duy trì độc lập.

Kiến trúc microservice là gì?
Kiến trúc microservice là gì?

Chúng hoạt động với tốc độ nhanh hơn và đáng tin cậy hơn nhiều so với các ứng dụng nguyên khối, phức tạp truyền thống. Sử dụng kiến ​​trúc microservice, một tổ chức có kích thước bất kỳ có thể phát triển các ngăn xếp công nghệ phù hợp với khả năng của họ.

Có nhiều lợi ích hữu hình khi sử dụng microservice, chúng ta sẽ thảo luận sau, nhưng vẫn còn một số tranh cãi về việc liệu các công ty có nên chuyển từ kiến ​​trúc nguyên khối sang kiến ​​trúc microservice hay không. Hãy xem xét sự khác biệt giữa hai kiến trúc để hiểu cuộc tranh luận.

Monolithic so với microservice

Monolithic so với microservice

Kiến trúc nguyên khối (monolithic) là cách truyền thống để xây dựng và triển khai các ứng dụng.

Cấu trúc này dựa trên khái niệm về một đơn vị duy nhất, không thể chia tách, bao gồm phía máy chủ, phía máy khách và cơ sở dữ liệu. Tất cả các khía cạnh được thống nhất và quản lý như một đơn vị và cơ sở mã.

Điều này có nghĩa là mọi cập nhật phải được thực hiện cho cùng một cơ sở mã, vì vậy toàn bộ ngăn xếp phải được thay đổi. Khi các ứng dụng nguyên khối có quy mô, chúng có thể trở nên khá phức tạp, do đó sự phát triển tổng thể thường dài hơn.

Ngược lại, kiến trúc microservice chia nhỏ khối đó thành các đơn vị độc lập có chức năng như các dịch vụ riêng biệt. Điều này có nghĩa là mọi dịch vụ đều có logic và cơ sở mã riêng. Chúng giao tiếp với nhau thông qua các API (giao diện lập trình ứng dụng).

Vậy, bạn nên chọn kiến ​​trúc nào?

Chọn kiến ​​trúc nguyên khối

  • Nếu công ty của bạn là một nhóm nhỏ:Sử dụng kiến trúc này, bạn không phải đối phó với sự phức tạp của việc triển khai kiến ​​trúc microservice.
  • Nếu bạn muốn khởi động nhanh hơn:Kiến trúc nguyên khối nhỏ đòi hỏi ít thời gian hơn để khởi động. Hệ thống này sẽ cần nhiều thời gian hơn để cập nhật hệ thống của bạn, nhưng việc khởi chạy ban đầu nhanh hơn.

Chọn kiến ​​trúc microservice

  • Nếu bạn muốn phát triển một ứng dụng có khả năng mở rộng hơn:Mở rộng một kiến ​​trúc microservice dễ dàng hơn nhiều. Các chức năng và mô-đun mới có thể được thêm vào rất dễ dàng và nhanh chóng.
  • Nếu công ty của bạn lớn hơn hoặc có kế hoạch phát triển:Sử dụng microservice rất tốt cho một công ty có kế hoạch phát triển, vì kiến ​​trúc microservice có khả năng mở rộng và dễ dàng tùy chỉnh hơn theo thời gian.

Ưu điểm và nhược điểm của microservice

Ưu điểm và nhược điểm của microservice

Có một số lý do tại sao kiến ​​trúc microservice là lựa chọn tốt hơn cho công ty của bạn. Hãy thảo luận về những ưu điểm đáng chú ý nhất và sau đó kiểm tra một số nhược điểm.

Ưu điểm của microservice

Cải thiện khả năng mở rộng và năng suất

Các nhóm lớn thường phải làm việc cùng nhau trong các dự án phức tạp. Với microservice, các dự án có thể được chia thành các đơn vị nhỏ hơn, độc lập.

Điều này có nghĩa là các nhóm có thể hành động độc lập về logic nghiệp vụ, giúp giảm thiểu sự phối hợp và nỗ lực.

Trên hết, các nhóm chịu trách nhiệm cho từng microservice có thể đưa ra quyết định công nghệ của riêng họ tùy thuộc vào nhu cầu của họ.

Ví dụ: cấu trúc bên trong của mỗi đơn vị hoặc vùng chứa không quan trọng miễn là giao diện hoạt động chính xác. Do đó, bất kỳ ngôn ngữ lập trình nào cũng có thể được sử dụng để viết microservice, vì vậy nhóm chịu trách nhiệm có thể chọn ngôn ngữ tốt nhất cho đồng đội của họ.

Tích hợp tốt với các hệ thống cũ

Hệ thống nguyên khối rất khó để duy trì. Nhiều hệ thống cũ có cấu trúc kém, thử nghiệm kém hoặc phụ thuộc vào các công nghệ lỗi thời.

May mắn thay, microservice có thể làm việc cùng với các hệ thống cũ để cải thiện mã và thay thế các phần cũ của hệ thống.

Tích hợp rất dễ dàng và có thể giải quyết nhiều vấn đề khiến các hệ thống nguyên khối trở thành quá khứ.

Phát triển bền vững

Kiến trúc microservice tạo ra các hệ thống có thể duy trì trong thời gian dài do các bộ phận khác nhau có thể thay thế.

Điều này có nghĩa là một microservice có thể dễ dàng được viết lại mà không ảnh hưởng đến toàn bộ hệ thống.

Miễn là sự phụ thuộc giữa các microservice được quản lý phù hợp, các thay đổi có thể dễ dàng được thực hiện để tối ưu hóa nhu cầu và hiệu suất của nhóm.

Chức năng chéo

Microservice là tốt nhất cho các nhóm phân phối. Nếu bạn có các nhóm trên toàn thế giới hoặc các bộ phận khác nhau, microservice cấp các quyền tự do cần thiết và linh hoạt để hoạt động tự chủ.

Các quyết định kỹ thuật có thể được đưa ra nhanh chóng, tích hợp với các dịch vụ khác trong nháy mắt. Chức năng chéo chưa bao giờ được dễ dàng hơn.

Nhược điểm của microservice

Triển khai đòi hỏi nhiều nỗ lực hơn

Hoạt động của một hệ thống microservice thường đòi hỏi nhiều nỗ lực hơn, vì có nhiều đơn vị có thể triển khai hơn mà mỗi đơn vị phải được triển khai và giám sát.

Thay đổi giao diện phải được thực hiện để có thể triển khai độc lập các microservice riêng lẻ.

Kiểm thử phải độc lập

Vì tất cả các microservice phải được kiểm thử cùng nhau, một microservice có thể làm gián đoạn thử nghiệm và ngăn chặn việc triển khai các microservice khác.

Có nhiều giao diện để kiểm tra và kiểm tra phải độc lập cho cả hai mặt của giao diện.

Khó thay đổi nhiều microservice

Những thay đổi ảnh hưởng đến nhiều microservice có thể khó thực hiện hơn. Trong một hệ thống microservice, các thay đổi đòi hỏi một số triển khai phối hợp.


Microservice và Docker

Microservice và Docker

Docker và microservices gần như đồng nghĩa. Các dịch vụ phải được triển khai riêng biệt, các đơn vị độc lập có thể mở rộng.

Nhưng, nếu bạn tạo nhiều microservices cho ứng dụng của bạn thì sao? Docker là một giải pháp nhẹ để triển khai microservices.

Một microservice có thể được đóng gói vào một image Docker và được phân lập như một container Docker. Bằng cách này, bạn có thể xây dựng một ứng dụng độc lập với môi trường máy chủ của mình.

Thay vì có một máy ảo hoàn chỉnh của riêng mình, các container Docker chia sẻ kernel của hệ điều hành trên máy chủ Docker. Các tiến trình từ các container xuất hiện trong bảng tiến trình của hệ điều hành mà các container Docker đang chạy.

Để sử dụng Docker với microservice, bạn cần tạo image Docker thông qua tập tin có tên là Dockerfile. Dockerfile rất dễ viết, vì vậy phần mềm có thể xuất bản dễ dàng. Hãy xem một ví dụ về Dockerfile cho microservice viết bằng Java sau.

FROM openjdk:11.0.2-jre-slim
COPY target/customer.jar .
CMD /usr/bin/java -Xmx400m -Xms400m -jar customer.jar
EXPOSE 8080

Một hệ thống microservice điển hình chứa nhiều container Docker. Phối hợp một hệ thống nhiều container Docker yêu cầu cấu hình cho mạng ảo.

Các container phải có khả năng tìm thấy nhau để liên lạc. Môi trường Docker Compose có thể liên hệ với một máy chủ khác thông qua một liên kết, cung cấp một hệ thống khám phá dịch vụ.


Ngăn xếp công nghệ và mô hình kiến ​​trúc

Ngăn xếp công nghệ và mô hình kiến ​​trúc

Hệ thống microservice hoạt động như thế nào và làm sao để xây dựng và triển khai một hệ thống microservice. Đó là lý do tại sao chúng tôi muốn tập trung vào các công nghệ khác nhau bạn có thể sử dụng cho toàn bộ hệ thống microservice.

Chúng ta hãy tham khảo một số ngăn xếp công nghệ, mẫu thiết kế khác nhau để tạo ra một kiến ​​trúc microservice có thể thực thi được.

Kiến ​​trúc vi mô và vĩ mô

Đó là nên phân chia kiến ​​trúc của bạn thành kiến ​​trúc vi mô và vĩ mô. Kiến trúc vi mô (micro architecture) liên quan đến quyết định đối với từng microservice. Kiến trúc vĩ mô (macro architecture) liên quan đến tất cả các quyết định ở cấp độ toàn cục áp dụng cho tất cả các microservice.

Có thể mở rộng khái niệm kiến ​​trúc vi mô và vĩ mô đến quyết định kỹ thuật. Quyết định kỹ thuật có thể được đưa ra trong khuôn khổ của kiến ​​trúc vĩ mô hoặc vi mô. Ví dụ, hãy xem các quyết định kỹ thuật được đưa ra ở cấp độ vi mô và vĩ mô cho cơ sở dữ liệu:

  • Micro: Mỗi microservice có thể có cơ sở dữ liệu riêng. Nếu cơ sở dữ liệu được định nghĩa ở kiến ​​trúc vi mô, sự cố của một cơ sở dữ liệu sẽ chỉ dẫn đến sự cố của một dịch vụ siêu nhỏ. Điều này làm cho toàn bộ ứng dụng mạnh mẽ hơn nhiều.
  • Macro: Cơ sở dữ liệu cũng có thể được định nghĩa là một phần của kiến ​​trúc macro. Nhiều microservice sẽ chia sẻ một lược đồ cơ sở dữ liệu.

Kiến trúc hệ thống khép kín

Hệ thống khép kín (SCS) là một loại kiến ​​trúc microservice để chỉ định các thành phần của kiến ​​trúc macro. Điều này có nghĩa là chúng không đại diện cho toàn bộ hệ thống.

Vì SCS là độc lập, nó cung cấp mọi thứ bạn cần để thực hiện một phần của logic nghiệp vụ, chẳng hạn như dữ liệu nhật ký và giao diện người dùng. SCS cũng có một API tùy chọn.

Ví dụ: SCS cho một microservice thanh toán sẽ lưu trữ thông tin liên quan đến khoản thanh toán vào cơ sở dữ liệu của nó. Nó cũng sẽ triển khai UI để hiển thị lịch sử thanh toán và dữ liệu về khách hàng sẽ được sao chép từ các SCS khác.

SCS cung cấp các quy tắc chính xác dựa trên các mẫu thiết kế đã thiết lập, cung cấp một điểm tham chiếu về cách xây dựng kiến ​​trúc microservice

Tất cả các quy tắc này đảm bảo rằng SCS chỉ triển khai một nghiệp vụ (miền), do đó một tính năng được thêm vào chỉ thay đổi một SCS.

Kiến trúc hệ thống khép kín

Chúng ta có thể nghĩ về SCS như một kiến ​​trúc microservice bởi vì nó có thể được triển khai độc lập và phân chia một hệ thống thành các ứng dụng web độc lập.

Trên thực tế, một SCS thậm chí có thể được chia thành nhiều microservice. Chúng khác với microservice theo ba khía cạnh chính: chúng lớn hơn microservice; chúng tập trung vào liên kết lỏng lẻo; chúng phải có giao diện người dùng (UI).

Kiến trúc tích hợp frontend

Microservice cũng có thể được tích hợp với một web frontend. Việc chia frontend thành các mô-đun khác nhau giúp giải quyết một số vấn đề xuất phát từ việc coi nó là một khối nguyên khối.

Một frontend được mô đun hóa được tạo thành từ các microservice có thể triển khai riêng biệt. Điều này có thể mang lại nhiều lợi ích cho frontend của bạn.

Ví dụ, một frontend được mô đun hóa có thể có logic nghiệp vụ (miền) độc lập và thay đổi trong miền có thể được thực hiện đơn giản bằng cách sửa đổi chỉ một microservice. Để kết hợp frontend riêng biệt, chúng phải được tích hợp, do đó cần có một hệ thống tích hợp.

Kiến trúc tích hợp frontend

Điều này có thể được thực hiện thông qua các liên kết, trong đó một frontend hiển thị một liên kết mà một frontend khác đọc và xử lý.

Điều này cũng có thể được thực hiện thông qua các chuyển hướng, ví dụ, cách OAuth2 xử lý tích hợp frontend. Chuyển hướng kết hợp truyền dữ liệu với tích hợp frontend.

Tuy nhiên, có một vài trường hợp ngoại lệ khi một frontend nên được triển khai dưới dạng nguyên khối. Ví dụ: các ứng dụng di động gốc phải triển khai nguyên khối hoặc nếu có một nhóm duy nhất chịu trách nhiệm phát triển frontend.

Kiến trúc microservice không đồng bộ

Các microservice đồng bộ tạo một yêu cầu cho các microservice khác trong khi nó xử lý các yêu cầu và chờ kết quả.

Tuy nhiên các giao thức liên lạc không đồng bộ gửi tin nhắn mà người nhận không có phản hồi trực tiếp.

Do đó một microservice có thể được định nghĩa là không đồng bộ nếu nó không tạo yêu cầu cho các microservice khác trong khi xử lý hoặc nó thực hiện các yêu cầu nhưng không chờ kết quả.

Kiến trúc microservice không đồng bộ

Các microservice không đồng bộ cung cấp một số lợi thế đáng chú ý cho các microservice đồng bộ và giải quyết nhiều thách thức của các hệ thống phân tán.

Logic cần thiết để xử lý các yêu cầu microservice không phụ thuộc vào kết quả, làm cho chúng độc lập hơn nhiều.

Tương tự, nếu một bên của sự giao tiếp thất bại, nó sẽ không sụp đổ toàn bộ hệ thống, mang lại khả năng phục hồi tổng thể cho hệ thống của bạn.

Một số ví dụ phổ biến về công nghệ cho các microservice không đồng bộ là Kafka (một MOM thường được sử dụng để nhắn tin), định dạng dữ liệu REST và Atom (để bổ sung cơ sở hạ tầng).

Nền tảng microservice

Các nền tảng microservice, như PaaS và Docker, hỗ trợ hoạt động và liên lạc của các microservice của bạn. Những công nghệ này cho phép giao tiếp giữa các microservice để triển khai, phân tích nhật ký và giám sát.

Ví dụ: các nền tảng này hỗ trợ HTTP và REST với tính năng cân bằng tải và khám phá dịch vụ. Hỗ trợ hoạt động hạn chế là cần thiết để triển khai microservice, vì vậy chúng có thể được triển khai nhanh chóng và hỗ trợ nhiều microservice.

Nền tảng microservice

Các nền tảng microservice thể hiện sự đơn giản hóa và giải pháp cho các vấn đề phổ biến. Một số nền tảng đáng chú ý là Kubernetes và Docker, rất quan trọng đối với các hoạt động của microservice. PaaS và Cloud Foundry cũng hữu ích nhưng chúng không phổ biến.

Điều quan trọng cần lưu ý là việc di chuyển sang các nền tảng này đòi hỏi phải thay đổi hoạt động và cài đặt các ứng dụng, điều này có thể khiến việc sử dụng nền tảng microservice trở thành một bước tiến lớn và kịp thời.

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *