Khi viết phần mềm, hãy xem xét cả việc triển khai và kiến ​​trúc của mã. Phần mềm bạn viết sẽ hiệu quả nhất khi được viết theo cách hợp lý và có ý nghĩa. Ngoài việc phù hợp về mặt kiến ​​trúc, phần mềm cũng nên xem xét sự tương tác mà người dùng sẽ có với nó và giao diện mà người dùng sẽ trải nghiệm.

Cả khái niệm API và khái niệm microservice đều liên quan đến cấu trúc và các tương tác của phần mềm. Một microservice có thể được hiểu sai chỉ đơn giản là một điểm cuối để cung cấp một API. Nhưng microservices có nhiều tính linh hoạt và khả năng hơn thế. Bài viết này sẽ nói về sự khác biệt giữa API và microservices, đồng thời nêu chi tiết một số lợi ích mà microservice có thể cung cấp.

Để bắt đầu, hãy xác định các thuật ngữ của chúng tôi.

API là gì?

Đầu tiên, hãy định nghĩa API là gì. Theo Wikipedia, một API (giao diện lập trình ứng dụng) là:

“Một tập hợp các định nghĩa về chương trình con, các giao thức truyền thông và các công cụ để xây dựng phần mềm. Nói chung, nó là một tập hợp các phương pháp được xác định rõ ràng về communication giữa các thành phần khác nhau. ”

Một cách dễ dàng để nghĩ về API là nghĩ về nó như một hợp đồng hành động mà bạn có thể yêu cầu cho một dịch vụ cụ thể. Ngày nay, API đang được sử dụng trong vô số ứng dụng web, chẳng hạn như phương tiện truyền thông xã hội, phần mềm ngân hàng, v.v. Hợp đồng được tiêu chuẩn hóa cho phép các ứng dụng bên ngoài giao tiếp với một ứng dụng khác.

Ví dụ: giả sử bạn đang xây dựng một ứng dụng sẽ tích hợp với Facebook. Bạn có thể sử dụng Facebook Graph API để truy cập dữ liệu bên trong Facebook, chẳng hạn như người dùng, bài đăng, nhận xét, v.v. API đơn giản hóa sự phức tạp của việc cố gắng sử dụng dữ liệu bên trong Facebook và cung cấp một cách dễ sử dụng để nhà phát triển truy cập vào dữ liệu đó.

Các hành động API phổ biến

Trong thế giới ngày nay, các API thường được phát triển theo kiểu RESTful. Các API này sẽ có một loạt các động từ liên kết với các hành động HTTP, như sau:

  • NHẬN (nhận một mục duy nhất hoặc một bộ sưu tập)
  • ĐĂNG (thêm một mục vào bộ sưu tập)
  • PUT (chỉnh sửa một mục đã tồn tại trong bộ sưu tập)
  • DELETE (xóa một mục trong bộ sưu tập)

Ưu điểm của tính nhất quán này thông qua các ứng dụng khác nhau là có một tiêu chuẩn khi thực hiện các hành động khác nhau. Bốn động từ HTTP khác nhau ở trên tương quan với các khả năng CRUD phổ biến mà nhiều ứng dụng sử dụng ngày nay. Khi làm việc với các API khác nhau trong một ứng dụng, điều này tạo ra một cách dễ nhận biết để hiểu ý nghĩa của các hành động được thực hiện trên các giao diện khác nhau.

Nếu bạn quan tâm đến việc làm việc với một ví dụ tương tác, hãy xem Reqres. Reqres cung cấp dữ liệu giả để giao tiếp với API RESTful và các hành động bạn có thể thực hiện khi tương tác với API.

Được rồi, bây giờ chúng ta đã đề cập đến vấn đề đó, chúng ta hãy xem xét các microservices.

Microservice là gì?

Wikipedia định nghĩa một microservice là:

“Một kỹ thuật phát triển phần mềm – một biến thể của phong cách kiến ​​trúc hướng dịch vụ (SOA) cấu trúc một ứng dụng như một tập hợp các dịch vụ được kết hợp lỏng lẻo. Trong kiến ​​trúc microservices, các dịch vụ rất chi tiết và các giao thức có trọng lượng nhẹ ”.

Nhưng trước khi chúng ta tìm hiểu sâu hơn về microservices là gì và chúng có thể hữu ích như thế nào, chúng ta hãy cùng tìm hiểu sơ qua về nguyên khối. Hiểu microservices khác với monoliths như thế nào sẽ giúp bạn hiểu rõ hơn về lợi ích của việc chuyển sang kiến ​​trúc microservices.

Tiền thân của Microservices: Monoliths

Trong những ngày đầu phát triển phần mềm (và tiếp tục trong nhiều môi trường doanh nghiệp lớn ngày nay), có khái niệm về một khối nguyên khối. Monolith là một ứng dụng duy nhất chứa một bộ sưu tập đầy đủ các chức năng, đóng vai trò như một nơi để lưu trữ mọi thứ. Về mặt kiến ​​trúc, nó trông như thế này:Tiêu đề hình ảnh

Tất cả các thành phần của ứng dụng nằm trong một khu vực, bao gồm lớp giao diện người dùng, lớp logic nghiệp vụ và lớp truy cập dữ liệu. Xây dựng các ứng dụng trong một khối là một quá trình dễ dàng và tự nhiên, và hầu hết các dự án đều bắt đầu theo cách này. Nhưng việc thêm chức năng vào codebase gây ra sự gia tăng cả về kích thước và độ phức tạp của khối nguyên khối, đồng thời việc cho phép khối nguyên khối phát triển lớn đi kèm với những bất lợi theo thời gian. Một số trong số này bao gồm:

  • Rủi ro rơi vào những quả bóng lớn của bùn chống mẫu, không có bất kỳ vần điệu hay lý do gì trong kiến ​​trúc của họ và khó hiểu từ cấp cao.
  • Hạn chế của chồng công nghệ bên trong nguyên khối. Đặc biệt là khi ứng dụng ngày càng phát triển, khả năng chuyển sang một nền tảng công nghệ khác ngày càng trở nên khó khăn hơn, ngay cả khi công nghệ đó không còn là sự lựa chọn tốt nhất.
  • Việc thực hiện các thay đổi đối với cơ sở mã sẽ ảnh hưởng đến toàn bộ ứng dụng, bất kể nhỏ như thế nào. Ví dụ: nếu chỉ một trong các phần logic nghiệp vụ nhận được những thay đổi liên tục, điều này buộc phải triển khai lại toàn bộ ứng dụng, gây lãng phí thời gian và tăng rủi ro.

Vậy đâu là giải pháp thay thế cho việc xây dựng một khối đá nguyên khối? Lấy nguyên khối và chia nhỏ thành microservices.

Nhập Microservice

Hãy lấy ví dụ nguyên khối ở trên và chuyển đổi nó để sử dụng microservices. Trong trường hợp đó, kiến ​​trúc ứng dụng sẽ thay đổi thành như thế này:Tiêu đề hình ảnh

Có một số điểm rút ra chính từ việc tái kiến ​​trúc này:

  • Các phần chia nhỏ của logic nghiệp vụ, mỗi phần bao gồm một microservice. Thay vì có một ranh giới duy nhất cho toàn bộ ứng dụng, ứng dụng được chia thành nhiều mảnh. Độ phức tạp của ứng dụng được giảm bớt, vì các dịch vụ khác nhau có các tương tác được xác định rõ ràng với nhau. Ví dụ, điều này cho phép khả năng chỉ định các nhóm liên kết cho từng dịch vụ riêng lẻ, bao gồm trách nhiệm trong một phần tóm tắt.
  • Lớp giao diện người dùng trước đây chỉ cần giao diện với các dịch vụ nhỏ của khách hàng và sự kiện, loại bỏ sự phụ thuộc cho vi dịch vụ thanh toán trên giao diện người dùng.
  • Dịch vụ vi mô thanh toán không cần lưu trữ dữ liệu, vì vậy nó không có lớp truy cập dữ liệu hoặc cơ sở dữ liệu. Thay vào đó, nó tương tác và xử lý dữ liệu trực tiếp từ cả khách hàng và dịch vụ sự kiện.

Với kiểu kiến ​​trúc này có rất nhiều lợi thế:

  • Việc tách biệt các mối quan tâm sẽ dễ dàng hơn. Những ranh giới này giữa các khu vực giúp phát triển (bạn chỉ cần quan tâm đến microservice của mình, không phải toàn bộ ứng dụng) và hiểu được kiến ​​trúc của ứng dụng.
  • Không giống như nguyên khối, một microservice có thể sử dụng một ngăn xếp công nghệ khác nếu cần. Đang cân nhắc viết lại mọi thứ bằng một ngôn ngữ mới? Chỉ cần thay đổi một microservice để sử dụng công nghệ mới, đánh giá những lợi ích thu được và xác định xem có nên tiếp tục hay không.
  • Việc triển khai toàn bộ ứng dụng trở nên tập trung hơn. Microservices cung cấp cho bạn sự linh hoạt để triển khai các dịch vụ khác nhau khi cần thiết.

Trong ví dụ trên, hãy để ý API nằm dọc theo các phần khác của microservice? Chúng tôi sẽ tìm hiểu điều đó. Cuối cùng đã đến lúc nói về sự khác biệt giữa API và microservices.

Sự khác biệt giữa API và Microservices

Dưới đây là những điểm khác biệt chính giữa API và microservices:

  • API là một hợp đồng cung cấp hướng dẫn cho người tiêu dùng sử dụng dịch vụ cơ bản.
  • Một microservice là một thiết kế kiến ​​trúc phân tách các phần của một ứng dụng (thường là nguyên khối) thành các dịch vụ nhỏ, tự chứa.

Theo định nghĩa, điều này có nghĩa là một API thường là phần của một microservice, cho phép tương tác với chính microservice đó. Một cách khác để suy nghĩ về điều này là API đóng vai trò như một hợp đồng cho các tương tác trong microservice, trình bày các tùy chọn có sẵn để tương tác với microservice.

Tuy nhiên, nếu chúng ta nhìn vào sơ đồ microservices ở trên, chúng ta có thể thấy rằng mỗi microservice được xây dựng hơi khác nhau dựa trên nhu cầu của nó. Dưới đây là một vài ví dụ về các chức năng khác nhau mà một microservice có thể có:

  • Cung cấp các hoạt động CRUD cho một loại thực thể cụ thể, chẳng hạn như khách hàng, sự kiện, v.v. Dịch vụ này sẽ có khả năng duy trì dữ liệu trong cơ sở dữ liệu.
  • Cung cấp một phương tiện để chấp nhận các tham số và trả về kết quả dựa trên các phép tính (có thể có cường độ cao). Dịch vụ vi mô thanh toán ở trên có thể lấy thông tin về một sự kiện hoặc khách hàng và trả lại thông tin thanh toán cần thiết mà không cần lưu trữ dữ liệu.

Với ví dụ trên, bạn có thể thấy rằng một microservice có khả năng không chỉ là một API cho một hệ thống. Toàn bộ ứng dụng có thể bao gồm một loạt các dịch vụ nhỏ sử dụng các API của riêng chúng để giao tiếp với nhau. Ngoài ra, mỗi microservices này có thể tóm tắt chức năng của riêng nó, vạch ra ranh giới hợp lý cho trách nhiệm trong ứng dụng và phân tách các mối quan tâm để tạo ra một cơ sở mã dễ bảo trì hơn.

Sự kết luận

Hy vọng rằng bây giờ bạn đã hiểu rõ hơn về cả API và microservices là gì. Khả năng bảo trì và chất lượng mã đều là những phần quan trọng của một chiến lược CNTT thành công. Microservices giúp bạn trung thực với chúng. Họ giữ cho nhóm của bạn nhanh nhẹn và giúp bạn đáp ứng nhu cầu của khách hàng bằng cách tạo ra mã chất lượng cao, có thể bảo trì.

Bạn đang làm việc trong một cơ sở mã nguyên khối? Hãy suy nghĩ về việc lấy một phần của khối đá nguyên khối đó và chuyển nó thành một microservice của riêng nó. Khi bạn làm điều đó, bạn sẽ có thể thấy những lợi ích của việc sử dụng microservices. Trên thực tế, bạn thậm chí có thể quyết định chuyển đổi toàn bộ.