Kiến trúc Composable là gì? Cẩm nang MACH và API-first

Kiến trúc có khả năng ghép nối (Composable architecture) là một cách xây dựng hệ thống phần mềm từ các thành phần độc lập, có thể thay thế được, tốt nhất trong phân khúc (best-of-breed) giao tiếp với nhau thông qua API, thay vì một nền tảng lớn tất cả trong một. Đây là ý tưởng rộng lớn hơn mà phong trào headless nằm dưới, và nó gắn chặt với Liên minh MACH (MACH Alliance), một tổ chức công nghiệp trung lập về nhà cung cấp nhằm thúc đẩy công nghệ doanh nghiệp mở, có khả năng ghép nối.

Làm rõ nhanh chóng trước tiên

Từ "composable" (có khả năng ghép nối) xuất hiện ở ba nơi rất khác nhau. Hãy sắp xếp chúng ngay bây giờ để phần còn lại của hướng dẫn này có ý nghĩa.

• Kiến trúc có khả năng ghép nối (Composable architecture) (bài viết này) là một phương pháp thiết kế phần mềm. Bạn lắp ráp một ứng dụng từ các thành phần nghiệp vụ riêng biệt, mỗi thành phần được tích hợp thông qua API.
• Cơ sở hạ tầng có khả năng ghép nối (Composable infrastructure) là một khái niệm phần cứng và trung tâm dữ liệu. Tính toán, lưu trữ và mạng được gộp chung và phân bổ cho các khối lượng công việc theo yêu cầu. Nó nằm dưới hệ điều hành, không nằm trong mã ứng dụng của bạn.
• Khả năng ghép nối DeFi (DeFi composability) là một ý tưởng blockchain, thường được gọi là "money legos" (xếp hình tiền). Các hợp đồng thông minh như giao thức cho vay và hoán đổi xếp chồng lên nhau để tạo ra các sản phẩm tài chính mới.

Cùng một từ gốc, ba lớp không liên quan. Từ đây trở đi, "composable" có nghĩa là theo nghĩa kiến trúc phần mềm.

Kiến trúc có khả năng ghép nối thực sự có nghĩa là gì

Một hệ thống có khả năng ghép nối được xây dựng từ các đơn vị mô-đun, tự chứa, mỗi đơn vị sở hữu một chức năng nghiệp vụ hoàn chỉnh. Bạn chọn công cụ tốt nhất cho mỗi công việc, kết nối chúng thông qua API và có thể thay thế bất kỳ công cụ nào trong số đó sau này mà không cần xây dựng lại mọi thứ xung quanh nó.

Đơn vị ghép nối có một cái tên: khả năng nghiệp vụ đóng gói (packaged business capability), hay PBC. Gartner định nghĩa PBC là các khả năng có thể triển khai độc lập, bao gồm dữ liệu nghiệp vụ, logic và quy trình tự chứa, và tương tác với các ứng dụng khác thông qua API và kênh sự kiện.

Hãy nghĩ về một PBC như một miền nghiệp vụ hoàn chỉnh trong một hộp. Một PBC "thanh toán" sở hữu các phương thức thanh toán, kiểm tra gian lận, hoàn tiền và tranh chấp. Một PBC "tìm kiếm" sở hữu việc lập chỉ mục, xếp hạng và xử lý truy vấn. Mỗi PBC đều cung cấp một API cấp nghiệp vụ, không phải một bảng cơ sở dữ liệu thô, và bạn có thể lấy nó từ một nhà cung cấp hoặc tự xây dựng. Bạn cấu thành sản phẩm của mình từ các khối này giống như bạn lắp ráp các bộ phận của một bộ kit.

Có khả năng ghép nối so với khối nguyên khối (monolith)

Một khối nguyên khối gộp mọi khả năng vào một ứng dụng có thể triển khai với một cơ sở dữ liệu chia sẻ. Việc bắt đầu thì đơn giản nhưng việc thay đổi sẽ trở nên khó khăn hơn khi nó phát triển. Kiến trúc có khả năng ghép nối tách rời các khả năng đó để mỗi khả năng có thể phát triển độc lập. Nếu bạn đã đọc về sự phân chia khối nguyên khối so với vi dịch vụ, thì có khả năng ghép nối là cách khung khả năng nghiệp vụ của cùng một sự thay đổi: vi dịch vụ là sự phân tách kỹ thuật, PBC là sự phân tách miền nghiệp vụ.

Đây là sự tương phản trong nháy mắt.

Sự đánh đổi là có thật. Có khả năng ghép nối mang lại cho bạn sự linh hoạt và khả năng thay thế. Nó cũng mang lại nhiều bộ phận chuyển động hơn để tích hợp, giám sát và duy trì hợp đồng.

MACH: tiêu chuẩn mà hầu hết mọi người thường nhắc đến

Khi các nhóm nói "composable" (có khả năng ghép nối), họ thường có ý muốn nói đến một kiến trúc tuân theo các nguyên tắc MACH. MACH là một từ viết tắt, và Liên minh MACH (MACH Alliance) (thành lập năm 2020) thúc đẩy nó như là kiến trúc cho các hệ thống mở, có khả năng ghép nối.

• M, Microservices (Vi dịch vụ). Các khả năng được xây dựng dưới dạng các dịch vụ nhỏ, có thể triển khai độc lập thay vì một khối duy nhất.
• A, API-first (Ưu tiên API). Mọi chức năng đều được cung cấp thông qua một API. Giao diện người dùng chỉ là một người tiêu dùng của API đó, không phải là cách duy nhất để truy cập.
• C, Cloud-native (Thiết kế cho đám mây). Các thành phần được xây dựng cho đám mây, sử dụng khả năng mở rộng linh hoạt và các dịch vụ được quản lý.
• H, Headless (Không đầu). Giao diện người dùng được tách rời khỏi phần phụ trợ, vì vậy bạn có thể triển khai cho web, di động, ki-ốt hoặc bất kỳ thứ gì khác từ cùng một API.

Lưu ý rằng composable (có khả năng ghép nối), headless (không đầu) và MACH không phải là từ đồng nghĩa. Headless là một chữ cái của MACH. MACH là một cách cụ thể, có chủ ý để xây dựng các hệ thống có khả năng ghép nối. Composable là cái ô bao trùm tất cả.

Xương sống ưu tiên API

Kéo bất kỳ sợi dây nào trong số này và bạn sẽ đến cùng một điểm: API là lớp tích hợp giữ một hệ thống có khả năng ghép nối lại với nhau. Nếu các thành phần độc lập và mỗi thành phần sở hữu dữ liệu riêng của nó, thì điều duy nhất kết nối chúng là hợp đồng giữa chúng.

Đó là lý do tại sao phát triển ưu tiên API là trụ cột không thể thương lượng. Trong một khối nguyên khối, hai mô-đun có thể truy cập vào cùng một cơ sở dữ liệu và gọi trực tiếp các hàm của nhau. Trong một hệ thống có khả năng ghép nối, đường tắt đó không còn nữa. Một khả năng chỉ hữu ích khi API mà nó cung cấp hữu ích, và một hệ thống chỉ ổn định khi các hợp đồng giữa các bộ phận của nó ổn định.

Đây cũng là thời điểm API không còn là một cánh cửa phụ nữa mà trở thành chính sản phẩm. Khi giao diện người dùng không đầu và các khả năng có thể hoán đổi, API là sản phẩm mà các nhóm và đối tác khác của bạn thực sự sử dụng. Thiết kế nó cẩu thả và mọi người tiêu dùng hạ nguồn đều cảm thấy điều đó.

Lợi ích và đánh đổi

Tóm lại, những lợi ích của kiến trúc có khả năng ghép nối:

• Tốt nhất trong phân khúc. Sử dụng công cụ mạnh nhất cho từng khả năng thay vì chấp nhận mô-đun yếu nhất của một nhà cung cấp.
• Thay đổi độc lập. Thay thế hoặc nâng cấp một PBC mà không ảnh hưởng đến phần còn lại.
• Giảm sự phụ thuộc. Các thành phần có thể hoán đổi có nghĩa là bạn không bị ràng buộc với một nền tảng duy nhất.
• Các nhóm song song. Các khả năng được tách rời cho phép các nhóm triển khai theo lịch trình riêng của họ.
• Đa kênh. Giao diện người dùng không đầu cho phép một bộ API phục vụ nhiều bề mặt.

Và những chi phí trung thực:

• Chi phí tích hợp. Nhiều thành phần hơn có nghĩa là nhiều kết nối hơn để kết nối và theo dõi.
• Kỷ luật hợp đồng. Một thay đổi gây lỗi trong một API có thể lan truyền khắp mọi thứ gọi nó.
• Độ phức tạp vận hành. Giám sát, xác thực và quản lý phiên bản trải rộng trên nhiều dịch vụ, không phải một.
• Thiết kế ban đầu. Bạn dành nhiều thời gian hơn cho các ranh giới và hợp đồng trước khi triển khai.

Composable (có khả năng ghép nối) rất phù hợp khi bạn cần sự linh hoạt, khả năng mở rộng và nhiều kênh. Nó trở nên quá mức cần thiết khi một khối nguyên khối được xây dựng tốt là đủ. Composable đòi hỏi sự phức tạp của nó ở quy mô lớn.

Apidog phù hợp ở đâu: trụ cột ưu tiên API

Apidog không làm cho kiến trúc của bạn có khả năng ghép nối. Nó không phải là một CMS, một công cụ thương mại điện tử, một API gateway hay một nền tảng MACH, và nó sẽ không thay thế bất kỳ thứ nào trong số đó. Điều nó làm là sở hữu chữ "A" trong MACH, trụ cột ưu tiên API, là lớp mà mọi thứ khác trong một hệ thống có khả năng ghép nối đều phụ thuộc vào.

Vì API là giao diện duy nhất giữa các thành phần độc lập của bạn, nên hợp đồng phải chính xác. Apidog là nơi bạn thiết kế, kiểm thử, mô phỏng và tài liệu hóa hợp đồng đó:

• Hợp đồng thiết kế trước. Định nghĩa API của từng khả năng dưới dạng hợp đồng OpenAPI trước khi bất kỳ ai viết mã triển khai, để người tiêu dùng và nhà cung cấp thống nhất về hình dạng ngay từ đầu.
• Máy chủ mô phỏng (Mock servers). Các nhóm tách rời không cần phải chờ đợi lẫn nhau. Một máy chủ mô phỏng cho phép giao diện người dùng hoặc đối tác xây dựng dựa trên hợp đồng trong khi PBC phụ trợ vẫn đang được xây dựng.
• Thực thi kiểm thử không đầu. Apidog CLI chạy các kiểm thử API của bạn mà không cần GUI, trực tiếp trong CI. Đó là một sự tương đồng khái niệm thực sự với "không đầu", các kiểm thử chạy trên hợp đồng, không thông qua màn hình.
• Quản lý từ các công cụ của bạn. Thông qua MCP, bạn có thể điều khiển dự án API của mình từ một tác nhân AI hoặc IDE.

Nếu hệ thống của bạn tuân theo mô hình API là sản phẩm, thì đây là lớp chất lượng giúp duy trì tính trung thực của các hợp đồng. Tải xuống Apidog để thiết kế và mô phỏng hợp đồng trước khi phần phụ trợ tồn tại.

Khi nào nên áp dụng kiến trúc có khả năng ghép nối

Hãy tìm đến kiến trúc có khả năng ghép nối khi có nhiều hơn một trong các điều sau là đúng:

• Bạn cần phục vụ nhiều kênh (web, di động, tại cửa hàng, giọng nói) từ logic được chia sẻ.
• Các khả năng khác nhau thay đổi với tốc độ rất khác nhau, và bạn đã chán việc triển khai lại mọi thứ chỉ vì một lỗi nhỏ.
• Bạn muốn các nhà cung cấp tốt nhất trong phân khúc cho từng khả năng thay vì một bộ công cụ duy nhất.
• Sự phụ thuộc vào nhà cung cấp là một rủi ro nghiệp vụ thực sự đối với bạn.
• Bạn có đội ngũ và kỷ luật để tự chủ các hợp đồng API và tích hợp theo thời gian.

Nếu bạn là một nhóm nhỏ đang triển khai một sản phẩm duy nhất với thời gian gấp rút, một khối nguyên khối sạch thường là lựa chọn thông minh hơn. Kiến trúc có khả năng ghép nối thể hiện sự phức tạp của nó ở quy mô lớn.

Các câu hỏi thường gặp

Kiến trúc có khả năng ghép nối có giống như vi dịch vụ không?

Không, nhưng chúng có sự chồng chéo. Vi dịch vụ là một cách kỹ thuật để phân tách một hệ thống thành các dịch vụ nhỏ có thể triển khai được. Kiến trúc có khả năng ghép nối phân tách theo các khả năng nghiệp vụ (PBC) và thêm ý tưởng về các thành phần tốt nhất trong phân khúc, có thể hoán đổi được kết nối bằng API. Vi dịch vụ thường là cách bạn xây dựng phần phụ trợ của một hệ thống có khả năng ghép nối. Để hiểu rõ hơn về sự phân tách, hãy xem khối nguyên khối so với vi dịch vụ.

Sự khác biệt giữa có khả năng ghép nối và không đầu là gì?

Không đầu (Headless) có nghĩa là giao diện người dùng được tách rời khỏi phần phụ trợ, vì vậy bất kỳ client nào cũng có thể sử dụng cùng một API. Có khả năng ghép nối (Composable) là cách tiếp cận rộng hơn: lắp ráp toàn bộ hệ thống từ các khả năng độc lập, được kết nối bằng API. Không đầu là một nguyên tắc (chữ "H" trong MACH) mà các hệ thống có khả năng ghép nối thường tuân theo. Bạn có thể không đầu ở một khả năng mà không hoàn toàn có khả năng ghép nối trên toàn bộ kiến trúc.

Khả năng nghiệp vụ đóng gói (PBC) là gì?

PBC là một đơn vị tự chứa sở hữu một chức năng nghiệp vụ hoàn chỉnh, bao gồm dữ liệu, logic và API của nó. Gartner mô tả PBC là các khả năng có thể triển khai độc lập, tương tác với các ứng dụng khác thông qua API và kênh sự kiện. Một thành phần "tìm kiếm", "thanh toán" hoặc "kho hàng", mỗi thành phần cung cấp một API cấp nghiệp vụ, là một PBC điển hình.

Tôi có cần một nền tảng API để chuyển sang kiến trúc có khả năng ghép nối không?

Bạn cần một cách để thiết kế, kiểm thử và giữ cho các hợp đồng API của mình ổn định, vì những hợp đồng đó là thứ duy nhất giữ các thành phần độc lập lại với nhau. Đó có thể là một bộ công cụ riêng biệt hoặc một nền tảng duy nhất bao gồm thiết kế, mô phỏng, kiểm thử và tài liệu hóa ở một nơi. Vấn đề là kỷ luật hợp đồng, không phải bất kỳ sản phẩm nào.

Tóm tắt

Kiến trúc có khả năng ghép nối là khái niệm chung, còn headless, MACH và microservices là các loại cụ thể trong đó. Điểm chung đơn giản là: các khả năng độc lập, lựa chọn công cụ tốt nhất trong phân khúc, và API làm xương sống kết nối. Phần cuối cùng này là nơi tiềm ẩn nhiều rủi ro nhất, bởi vì hợp đồng chính là hệ thống. Thiết kế, mô phỏng, kiểm thử và tài liệu hóa API đúng cách với một công cụ như Apidog, và phần còn lại của lời hứa về kiến trúc có khả năng ghép nối (có thể hoán đổi, đa kênh, không bị khóa chặt) sẽ có một nền tảng vững chắc để đứng vững.