API-first và composable hứa hẹn sẽ thay thế một nền tảng đơn khối bằng một tập hợp các khả năng độc lập: nội dung, thương mại, tìm kiếm, danh tính, thanh toán hoặc dữ liệu sản phẩm. Các nhóm có thể phát triển từng thành phần và tạo ra các kênh mới nhanh hơn.
Lời hứa này là thực tế trong một số bối cảnh. Nó cũng có thể biến một ứng dụng dễ hiểu thành một mạng lưới các phụ thuộc, hợp đồng và nhà cung cấp khó khai thác. Việc tách rời không phải là mục đích cuối cùng. Nó phải làm giảm chi phí thay đổi trên các ranh giới ổn định.
Ý nghĩa thực sự của API-first
API-first không chỉ đơn giản là thêm các điểm cuối sau khi đã xây dựng giao diện. Hợp đồng được thiết kế như một sản phẩm được nhiều người tiêu dùng sử dụng. Nó mô tả các tài nguyên, thao tác, lỗi, quyền, giới hạn và quy tắc phát triển trước khi các triển khai trở nên khác nhau.
Một quy trình đầy đủ bao gồm:
- nhu cầu của người tiêu dùng;
- mô hình miền và từ vựng chung ;
- sơ đồ chi tiết theo phiên bản;
- ví dụ và môi trường thử nghiệm;
- chính sách xác thực và cấp quyền;
- kiểm tra hợp đồng;
- khả năng quan sát
- thủ tục giảm giá trị.
API không chỉ là một giao diện kỹ thuật. Nó trở thành một cam kết giữa các nhóm.
Những gì mà composable bao phủ
Một kiến trúc có thể kết hợp lắp ráp các khả năng có thể thay thế phía sau các hợp đồng. Nó có thể bao gồm các sản phẩm thị trường, dịch vụ nội bộ và các thành phần mã nguồn mở. Giao diện người dùng đôi khi điều phối nhiều nguồn thông qua một lớp chuyên dụng, chẳng hạn như một backend-for-frontend.
Tính tổng hợp hữu ích giả định rằng các khối có thể phát triển mà không cần phối hợp liên tục. Nếu mỗi thay đổi đều yêu cầu phải chỉnh sửa sáu dịch vụ và ba nhóm, thì nền tảng được phân phối nhưng không thực sự có thể tổng hợp.
Những tình huống mà phương pháp tạo ra giá trị
Nhiều kênh
Một trang web, một ứng dụng di động, một extranet và các đối tác có thể sử dụng cùng một khả năng. Một API ổn định tránh việc triển khai lại nghiệp vụ cho từng kênh.
Nhịp độ phát triển khác nhau
Danh mục, nội dung và việc thanh toán có thể thay đổi với các tần suất khác nhau. Các ranh giới rõ ràng giới hạn việc triển khai kết hợp.
Các đội thực sự tự chủ
Mỗi năng lực đều có một chủ sở hữu, một ngân sách, một nhiệm vụ trực ca có thể có và các mục tiêu. Tính tự chủ tổ chức sau đó mang lại ý nghĩa cho tự chủ kỹ thuật.
Cần thay thế có mục tiêu
Một viên gạch có thể được thay đổi mà không cần di cư toàn cục nếu dữ liệu, hợp đồng và phụ thuộc được kiểm soát.
Những tình huống mà cô ấy phóng đại dự án
Một đội duy nhất, một kênh duy nhất và một lĩnh vực vẫn chưa ổn định thường hưởng lợi nhiều hơn từ một khối đơn mô-đun. Việc phân tách sớm sẽ cố định các ranh giới mà sau đó sẽ phải thương lượng lại. Chi phí mạng, bảo mật, khả năng quan sát và phối hợp xuất hiện ngay lập tức, trong khi lợi ích vẫn còn là giả thuyết.
Một giải pháp có thể kết hợp không loại bỏ sự tích hợp. Nó biến điều đó thành một trách nhiệm thường xuyên.
Tám năng lực thiết yếu
1. Chiến lược sản phẩm
Mỗi API hoặc thành phần phải có người dùng, mục tiêu, lộ trình và mức dịch vụ. Nếu không có điều đó, danh mục API sẽ trở thành một kho lưu trữ bỏ hoang.
2. Phân tách theo nghiệp vụ
Các ranh giới phải theo trách nhiệm và dữ liệu, không phải theo màn hình hoặc sơ đồ tổ chức. Một lĩnh vực phải có khả năng giải thích những gì nó sở hữu và những gì nó công bố.
3. Hợp đồng dữ liệu
Sơ đồ, định danh, đơn vị, thời gian và nguồn sự thật phải rõ ràng. Các ví dụ và quy tắc xác thực là một phần của hợp đồng.
4. An toàn
Xác thực, phân quyền ở mức tài nguyên, giới hạn tốc độ, bảo vệ thông tin bí mật và ghi nhật ký phải nhất quán trên tất cả các API.
5. Vòng đời
Một phiên bản không thể biến mất mà không biết người tiêu dùng của nó. Tính tương thích, ngày hết hạn và việc di chuyển đều được quản lý.
6. Bài kiểm tra
Các bài kiểm tra đơn vị, tích hợp, hợp đồng và toàn bộ quy trình phải bổ sung cho nhau. Các môi trường thử nghiệm không được phụ thuộc vào các dịch vụ không ổn định mà không có giải pháp mô phỏng.
7. Khả năng quan sát
Mỗi yêu cầu nhận một mã nhận dạng tương quan. Nhật ký, số liệu và dấu vết cho phép theo dõi hành trình và phân biệt lỗi cục bộ với sự cố của nhà cung cấp.
8. Tổ chức và khai thác
Một thành phần có một chủ sở hữu có thể liên lạc, tài liệu, ngân sách và một quy trình xử lý sự cố. Nhóm sử dụng biết mức dịch vụ nào để mong đợi.
Lộ trình tiến triển của một khối đơn cấu trúc hướng tới kiến trúc có thể ghép khi nhu cầu yêu cầu.
Thiết kế hợp đồng trước khi lập trình
Một đặc tả OpenAPI có thể được sử dụng như một tài liệu thảo luận, xác minh, tạo client và kiểm thử. Nó không thay thế việc thiết kế miền. Tên gọi, trạng thái, lỗi và các hành vi bất đồng bộ phải được các nhóm nghiệp vụ hiểu.
Lỗi là một phần của sản phẩm. Một API phải phân biệt giữa việc xác thực, xung đột, thiếu tạm thời và bị cấm. Người sử dụng không nên phân tích một văn bản tự do để quyết định phải làm gì.
Quản lý phiên bản một cách kỷ luật
Tạo /v2 Mỗi thay đổi đều dẫn đến việc duy trì nhiều thế giới. Ưu tiên là tính tương thích: thêm một trường tùy chọn, chấp nhận các giá trị mới mà không phá vỡ các giá trị cũ và thông báo việc giảm giá trị.
Khi một sự gián đoạn là cần thiết, hãy liệt kê các người tiêu dùng, cung cấp một khoảng thời gian tồn tại cùng nhau, các công cụ di cư và các số liệu sử dụng. Một phiên bản có thể bị loại bỏ khi việc thiếu nó được xác minh, không chỉ khi một ngày đã trôi qua.
Tránh bẫy của các microservice theo mặc định
API-first không có nghĩa là microservices. Một khối đơn mô-đun có thể cung cấp các hợp đồng ổn định và tách biệt rõ ràng các miền mà không tốn chi phí phân tán. Các dịch vụ có thể được tách ra khi có những lý do có thể đo lường được xuất hiện: tải tăng khác nhau, tính tự chủ của nhóm, chu trình triển khai hoặc cách ly rủi ro.
Quá trình tiến triển này vẫn giữ khả năng học hỏi trước khi nhân lên các thành phần.
Tạo giao diện frontend mà không làm nó yếu đi
Một frontend gọi trực tiếp mười dịch vụ trở nên chịu trách nhiệm về bảo mật, độ trễ và tính nhất quán. Một lớp tổng hợp hoặc một backend-for-frontend có thể điều chỉnh các phản hồi, áp dụng quyền và giới hạn số lượt đi lại.
Việc hiển thị trên máy chủ, xem trước, vô hiệu hóa bộ nhớ đệm và các lỗi một phần cần được thiết kế. Một trang không nên trở nên không sử dụng được chỉ vì một thành phần phụ không có sẵn.
Quản lý các nhà cung cấp
Composable giúp sử dụng các sản phẩm chuyên dụng dễ dàng hơn, nhưng tạo ra các phụ thuộc thương mại và kỹ thuật. Đối với mỗi thành phần, cần tài liệu hóa:
- dữ liệu sở hữu và khả năng xuất khẩu;
- hợp đồng và giới hạn;
- sẵn sàng và hỗ trợ ;
- sự biến động giá cả;
- cư trú và nhà thầu phụ ;
- chiến lược thay thế;
- hành vi suy giảm trong trường hợp hỏng hóc.
Một bộ chuyển đổi nội bộ có thể giảm sự ghép nối, nhưng nó phải giữ đơn giản và được kiểm tra.
Khả năng quan sát từ đầu đến cuối
Việc giám sát từng dịch vụ là không đủ. Cần theo dõi một quá trình hoàn chỉnh: yêu cầu của người dùng, tổng hợp, API nghiệp vụ, tin nhắn không đồng bộ và hệ thống bên thứ ba. Các mục tiêu về mức độ dịch vụ có thể được xác định cho các quá trình, không chỉ cho các thành phần.
Ngân sách lỗi giúp cân bằng giữa tốc độ và độ tin cậy. Nếu một dịch vụ thường xuyên sử dụng hết ngân sách của quá trình, ưu tiên của nó sẽ trở nên rõ ràng.
Chi phí tổng và năng lực hoạt động
Giá mua của một viên gạch chỉ chiếm một phần chi phí. Cần phải cộng thêm tích hợp, bảo mật, môi trường, kiểm thử, giám sát, hỗ trợ, nâng cấp và kỹ năng. Nền tảng có thể ghép nối thường đòi hỏi một đội ngũ nền tảng hoặc các tiêu chuẩn tự động hóa.
Một kiến trúc kinh tế lành mạnh giới hạn số lượng công nghệ, chia sẻ các cơ chế xuyên suốt và đo lường giá trị của mỗi sự tách biệt.
Một quỹ đạo thận trọng
Quá trình có thể bắt đầu bằng:
- vẽ bản đồ các lĩnh vực và nguồn sự thật;
- ổn định một vài hợp đồng nội bộ;
- trích xuất một năng lực có giá trị cao ;
- thiết lập các bài kiểm tra, bảo mật và khả năng quan sát;
- đo lường lợi ích;
- chỉ mở rộng nếu mô hình hoạt động.
Chuỗi này xây dựng sự trưởng thành trước khi phức tạp.
Sáng tác để thay đổi tốt hơn
Một nền tảng có thể kết hợp thành công không được phân biệt bởi số lượng dịch vụ. Nó được phân biệt bởi mức độ dễ dàng mà một khả năng có thể phát triển, được quan sát và được thay thế mà không làm gián đoạn phần còn lại.
Partitech có thể kiểm toán một kiến trúc hiện có, xác định chiến lược API-đầu tiên, thiết kế các hợp đồng và công nghiệp hóa bảo mật, kiểm thử và vận hành. Mục tiêu là đạt được tính tự chủ mà không mất đi sự hiểu biết tổng thể về hệ thống.
Hãy nói về dự án của bạn
Đánh giá một lộ trình ưu tiên API hoặc có thể kết hợp với Partitech. Liên hệ Partitech.