Posted inProgramming

Mở rộng ứng dụng Python với Pluggy: Cách xây dựng kiến trúc Plugin như Pytest

Programming tutorial - IT technology blog
Programming tutorial - IT technology blog

Cơn ác mộng của ứng dụng nguyên khối 3.000 dòng code

Đầu sự nghiệp, tôi tiếp nhận một công cụ xử lý dữ liệu ban đầu chỉ là một script đơn giản. Nó xử lý file CSV, kiểm tra dữ liệu cơ bản và lưu vào database. Nhưng khi công ty mở rộng, các yêu cầu “đơn giản” cũng tăng lên. Tôi bắt đầu nhận được các yêu cầu như: “Chúng ta có thể hỗ trợ Parquet không?”, “Có thể gửi cảnh báo Slack khi lỗi không?”, và “Đội tài chính cần một bước tính thuế riêng.”

Tôi đã rơi vào cái bẫy mà hầu hết các lập trình viên đều mắc phải: sử dụng các khối if-else. Chỉ trong vài tháng, logic cốt lõi đã bị chôn vùi dưới “núi” câu lệnh điều kiện. Mỗi khi đồng nghiệp muốn thêm một tính năng nhỏ, họ phải chỉnh sửa bộ máy cốt lõi (core engine). Điều này dẫn đến những lỗi không mong muốn, các cuộc xung đột khi merge (merge conflict) kéo dài 4 tiếng, và một nỗi sợ hãi thực sự khi phải deploy vào chiều thứ Sáu.

Nguyên nhân gốc rễ: Sự phụ thuộc chặt chẽ và Giả định Thế giới đóng

Vấn đề không nằm ở chất lượng code của tôi; mà ở kiến trúc nền tảng. Hệ thống tuân theo thiết kế “thế giới đóng” (closed-world), nơi core engine phải biết trước mọi tiện ích mở rộng có thể có. Việc viết cứng (hardcoding) logic vào luồng thực thi chính tạo ra sự phụ thuộc chặt chẽ (tight coupling). Nếu Slack API thay đổi, toàn bộ engine cần phải deploy lại. Thêm một định dạng file mới cũng khiến logic cốt lõi vốn đang ổn định gặp rủi ro.

Phần mềm có khả năng mở rộng yêu cầu thiết kế “thế giới mở” (open-world). Trong mô hình này, phần cốt lõi cung cấp các “hook” hoặc điểm truy cập, trong khi các phần mở rộng hoạt động độc lập. Hãy nhìn vào Pytest: nó hỗ trợ hơn 1.200 plugin từ bên thứ ba mà các nhà phát triển không cần chạm vào repository chính cho mỗi plugin đó. Đó chính là mức độ tách biệt (decoupling) mà bạn nên hướng tới.

So sánh các chiến lược mở rộng

Trước khi chọn một công cụ, tôi đã đánh giá một vài cách để làm cho code Python có thể mở rộng:

  • Ghi đè Class (Class Overriding): Cách này hiệu quả với các script nhỏ nhưng thất bại khi bạn cần kết hợp năm phần mở rộng khác nhau từ năm đội ngũ khác nhau.
  • Import động (importlib): Bạn có thể quét thư mục /plugins để tìm các file .py. Tuy nhiên, bạn sẽ phải viết rất nhiều code mẫu (boilerplate) để quản lý vòng đời và sự giao tiếp giữa các module đó.
  • Entry Points (setuptools): Đây là một tiêu chuẩn tốt để khám phá package, nhưng nó không định nghĩa cách các package đó thực sự tương tác với logic của bạn.

Pluggy lấp đầy khoảng trống này. Là xương sống của Pytest và Tox, nó chuẩn hóa mô hình “Hook”. Nó cho phép bạn định nghĩa một đặc tả (hợp đồng) và các triển khai (plugin) với chi phí vận hành tối thiểu.

Thiết kế với Pluggy: Cách tiếp cận thực tế

Pluggy hoạt động như một registry tập trung. Bạn định nghĩa **Hookspecs** để thiết lập các quy tắc và **Hookimpls** để cung cấp chức năng. Trong môi trường production, điều này cho phép các đội ngũ phát hành tính năng dưới dạng các package Python riêng biệt mà core engine sẽ tự khám phá khi chạy (runtime).

1. Thiết lập môi trường

Bắt đầu bằng việc cài đặt thư viện qua pip:

pip install pluggy

2. Định nghĩa đặc tả Hook

Hãy coi Hookspec như một bản hợp đồng. Nó cho các tác giả plugin biết chính xác hàm của họ phải trông như thế nào để được hệ thống của bạn chấp nhận.

import pluggy

# Tạo namespace duy nhất cho dự án của bạn
hookspec = pluggy.HookspecMarker("my_app")
hookimpl = pluggy.HookimplMarker("my_app")

class MySpecs:
    @hookspec
    def pre_process_data(self, data):
        """Hook để chỉnh sửa dữ liệu trước khi xử lý"""

    @hookspec
    def post_process_report(self, report_name):
        """Hook để xử lý báo cáo sau khi tạo"""

3. Tạo các triển khai Plugin

Viết một plugin rất đơn giản. Bất kỳ class hoặc module nào chứa các hàm được đánh dấu bằng decorator hookimpl đều có thể đóng vai trò là một plugin.

class LoggingPlugin:
    @hookimpl
    def pre_process_data(self, data):
        print(f"[Log] Đang phân tích {len(data)} bản ghi")

class TransformationPlugin:
    @hookimpl
    def pre_process_data(self, data):
        # Chèn timestamp xử lý vào mỗi bản ghi
        for item in data:
            item['processed_at'] = "2023-10-27"
        return data

4. Bộ điều phối (Plugin Manager)

PluginManager đóng vai trò là bộ não của ứng dụng. Nó đăng ký các plugin và kích hoạt các hook bất cứ khi nào cần thiết trong luồng thực thi.

def run_app():
    # 1. Khởi tạo manager
    pm = pluggy.PluginManager("my_app")
    
    # 2. Đăng ký các đặc tả (specifications)
    pm.add_hookspecs(MySpecs)
    
    # 3. Đăng ký các plugin (những thứ này có thể được tự động tìm thấy trong ứng dụng thực tế)
    pm.register(LoggingPlugin())
    pm.register(TransformationPlugin())

    # 4. Thực thi các hook
    my_data = [{"id": 101}, {"id": 102}]
    
    # Lệnh này kích hoạt 'pre_process_data' trên tất cả các plugin đã đăng ký
    pm.hook.pre_process_data(data=my_data)
    
    print("Core: Các plugin đã hoàn thành việc xử lý dữ liệu.")

run_app()

Các mô hình Hook nâng cao

Đôi khi bạn không muốn mọi plugin đều chạy. Pluggy cung cấp khả năng kiểm soát chi tiết cách thu thập kết quả.

Mô hình “Kết quả đầu tiên” (First Result)

Hãy tưởng tượng bạn đang tìm kiếm một file cấu hình trong nhiều thư mục. Bạn chỉ quan tâm đến đường dẫn hợp lệ đầu tiên tìm thấy. Bạn có thể cấu hình spec của mình để dừng ngay sau khi có kết quả thành công đầu tiên:

@hookspec(firstresult=True)
def load_config(self, path):
    """Dừng thực thi tại plugin đầu tiên trả về kết quả khác None"""

Thực thi lịch sử (Historical Execution)

Pluggy cũng hỗ trợ các hook “lịch sử” (historic). Điều này cho phép một plugin nhận được sự kiện ngay cả khi nó được đăng ký sau khi sự kiện đó đã xảy ra—hoàn hảo cho các chuỗi khởi động phức tạp nơi các module tải với tốc độ khác nhau.

Tại sao điều này quan trọng với DevOps và việc mở rộng

Việc tách biệt core engine khỏi các phần mở rộng sẽ thay đổi căn bản pipeline CI/CD của bạn. Khi sử dụng Pluggy, bạn sẽ có được một số lợi thế vận hành:

  • Kiểm thử cô lập (Isolated Testing): Bạn có thể xác minh core engine bằng các plugin “mock” đơn giản và kiểm thử các plugin phức tạp trong sự cô lập hoàn toàn.
  • Triển khai an toàn hơn: Bạn có thể triển khai một plugin “Slack Notification” mới dưới dạng một package riêng biệt. Nếu nó bị lỗi, bạn có thể rollback mà không ảnh hưởng đến logic xử lý dữ liệu.
  • Đóng góp nhanh hơn: Các đội ngũ nội bộ có thể đóng góp tính năng bằng cách phát hành các package Python của riêng họ. Điều này loại bỏ việc bạn phải review những Pull Request khổng lồ dài 500 dòng trong repository chính.
  • Bật/tắt tính năng động: Việc vô hiệu hóa một tính năng trở nên đơn giản như gọi lệnh pm.unregister(plugin_name).

Lời kết

Xây dựng một hệ thống plugin không phải là thêm sự phức tạp; đó là tôn trọng các ranh giới. Bằng cách áp dụng Pluggy, bạn đang sử dụng một mô hình đã được kiểm chứng qua thực tế, cung cấp sức mạnh cho những công cụ thành công nhất trong hệ sinh thái Python. Hãy bắt đầu bằng việc xác định các phần trong ứng dụng thay đổi thường xuyên nhất—đó là những ứng cử viên hàng đầu cho hook. Một khi bạn chuyển logic dễ biến động đó vào các plugin, mã nguồn cốt lõi của bạn sẽ trở nên sạch sẽ hơn, ổn định hơn và dễ bảo trì hơn đáng kể.

Share:
Tags: