Kiến trúc tiến hóa (Evolutionary Architecture) và hàm thể lực (Fitness Function)

1. Tổng quan

Kiến trúc tiến hóa là kiến trúc được thiết kế để hỗ trợ các thay đổi — xảy ra trên nhiều chiều (dimension) — theo phương thức "được dẫn hướng (guided), tăng dần (incremental)", và công cụ cốt lõi của sự "dẫn hướng" đó chính là hàm thể lực (fitness function), thứ đo lường một cách khách quan một thuộc tính chất lượng của kiến trúc.

Kiến trúc phần mềm từ lâu đã dựa trên tiền đề rằng "nếu thiết kế đúng ngay từ đầu thì sẽ bền lâu". Nhưng khi cloud, microservices và phân phối liên tục trở nên phổ biến, yêu cầu, công nghệ, tổ chức và quy định bắt đầu thay đổi theo nhịp tuần hay ngày thay vì theo quý, và chính tiền đề về "tính trọn vẹn của thiết kế ban đầu" đã sụp đổ. Trong một thế giới mà thay đổi là hằng số, thành bại của kiến trúc đã chuyển từ "thiết kế hoàn hảo đến đâu" sang "thay đổi an toàn được đến đâu một cách liên tục". Kiến trúc tiến hóa chính là cách tiếp cận mà Rebecca Parsons, Neal Ford, Patrick Kua và Pramod Sadalage hệ thống hóa để trả lời đúng câu hỏi này, với nền tảng lý thuyết là cuốn Building Evolutionary Architectures phiên bản đầu năm 2017 và phiên bản thứ hai năm 2022.

Hiểu biết cốt lõi là nó đã kỹ thuật hóa "sự tiến hóa (evolution)" vượt ra ngoài phép ẩn dụ sinh học. Giống như một giải thuật di truyền chấm điểm độ thích nghi của lời giải (solution) theo số mỗi thế hệ và tạo áp lực chọn lọc theo hướng tốt hơn, kiến trúc cũng có thể giữ được các đặc tính đã định trong khi tiến hóa nếu tự động đo độ thích nghi của các thuộc tính chất lượng ở mỗi thay đổi và chỉ cho qua những thay đổi chấp nhận được. Nói cách khác, hàm thể lực quy câu hỏi "thay đổi này có hợp lý về mặt kiến trúc không" về một kiểm tra thực thi được (executable check) thay vì một bản rà soát chủ quan của con người.

Định nghĩa của kiến trúc tiến hóa được phân rã thành ba tính chất. Thứ nhất, được dẫn hướng (guided) — hàm thể lực định hướng để thay đổi không xảy ra theo bất kỳ hướng nào. Thứ hai, tăng dần (incremental) — xây dựng theo đơn vị nhỏ và triển khai theo đơn vị nhỏ giúp kiểm soát biên độ thay đổi. Thứ ba, đa chiều (multiple dimensions) — bảo toàn đồng thời nhiều trục chất lượng, không chỉ kỹ thuật mà còn dữ liệu, bảo mật, vận hành và hiệu năng. Khái niệm cấp cao ràng buộc ba tính chất này là tư duy "nâng thay đổi lên thành một mối quan tâm thiết kế hạng nhất", và kỹ sư chuyên nghiệp phải có thể giải thích điều này trong sự đối lập với mô hình "thiết kế một lần" truyền thống.

2. Cấu trúc tổng thể: Thay đổi được dẫn hướng, thay đổi tăng dần, đa chiều

Cấu trúc tổng thể của kiến trúc tiến hóa mang hình thái một vòng lặp khép kín: "mục tiêu kiến trúc → hàm thể lực → thay đổi tăng dần được dẫn hướng → hệ thống vận hành → phản hồi được quan sát". Sơ đồ dưới đây cho thấy cách các yêu cầu thuộc tính chất lượng và các chiều đặc tính khác nhau hội tụ thành một tập hàm thể lực, cách kết quả quyết định một thay đổi được cho qua hay bị chặn, và cách các chỉ số thu thập trong vận hành quay về nạp lại cho các hàm thể lực.

flowchart TB
    subgraph DIM["Các chiều đặc tính kiến trúc"]
        D1["Kỹ thuật: độ ghép, tham chiếu vòng"]
        D2["Bảo mật: lỗ hổng phụ thuộc"]
        D3["Vận hành: tính sẵn sàng, khả năng mở rộng"]
        D4["Hiệu năng: thời gian đáp ứng p99"]
        D5["Dữ liệu: tiến hóa lược đồ"]
    end
    GOAL["Mục tiêu kiến trúc\n(yêu cầu thuộc tính chất lượng)"] --> FF["Tập hàm thể lực\n(đo độ thích nghi khách quan)"]
    DIM --> FF
    FF -->|đạt| CHANGE["Thay đổi tăng dần được dẫn hướng\n(qua đường ống triển khai)"]
    FF -->|trượt| BLOCK["Chặn thay đổi, phản hồi"]
    CHANGE --> SYS["Hệ thống đang vận hành"]
    SYS -->|thu thập chỉ số quan sát| FF
    BLOCK -.->|sửa rồi thử lại| CHANGE

Thay đổi được dẫn hướng là nguyên lý giam độ tự do của thay đổi bên trong hàng rào các thuộc tính chất lượng. Lập trình viên thay đổi chức năng tự do, nhưng ngay khi họ vượt qua một ranh giới mà hàm thể lực đã định (ví dụ: "tầng trình bày không được tham chiếu trực tiếp tầng bền vững", "phụ thuộc vòng giữa các dịch vụ phải bằng 0"), thay đổi bị từ chối tự động. Điều quan trọng ở đây là hàm thể lực không phải "danh sách cấm" mà là "định nghĩa các đặc tính kiến trúc phải được bảo toàn". Khai báo đặc tính một cách tường minh giúp ý đồ thiết kế sống động bên trong mã nguồn và đường ống như "tài liệu sống", ngay cả khi người phụ trách thay đổi theo thời gian.

Thay đổi tăng dần đòi hỏi hai mặt cùng lúc. Về phía phát triển, mọi thứ phải được xây dựng theo đơn vị nhỏ và kiểm thử được; về phía vận hành, chúng phải triển khai và thu hồi được an toàn theo đơn vị nhỏ. Mặt trước được hậu thuẫn bởi mô-đun hóa, độ ghép thấp và kiểm thử tự động; mặt sau bởi các cơ chế triển khai như [[ci-cd-pipeline]], [[feature-flag]], canary và blue-green. Nếu không bảo đảm tính tăng dần thì dù hàm thể lực có tốt đến đâu cũng không kiểm soát được rủi ro của "thay đổi khối lớn", nên năng lực thay đổi tăng dần là điều kiện tiên quyết của kiến trúc tiến hóa.

Bảo toàn đa chiều phản ánh sự thật rằng kiến trúc không phải một chất lượng đơn lẻ mà là sự cân bằng của nhiều chất lượng xung đột nhau. Bảng dưới đây liệt kê các chiều tiêu biểu và các hàm thể lực thường dùng ở mỗi chiều.

Khai báo cho mỗi chiều "bảo vệ cái gì, ở ngưỡng nào, bằng công cụ nào" sẽ biến quản trị kiến trúc từ khẩu hiệu trừu tượng thành các quy tắc thực thi được.

3. Phân loại và vận hành của hàm thể lực kiến trúc

Hàm thể lực không phải một hình thái đơn lẻ mà được phân loại theo nhiều trục, và sự kết hợp của chúng quyết định chiến lược quản trị. Các phân biệt được dùng rộng rãi nhất là nguyên tử (atomic) với toàn cục (holistic) trên trục phạm vi (scope), và kích hoạt (triggered) với liên tục (continual) trên trục nhịp thực thi (cadence).

Hàm thể lực nguyên tử kiểm chứng một đặc tính kiến trúc một cách độc lập. Chẳng hạn, quy tắc "dịch vụ A không được import gói nội bộ của dịch vụ B" chỉ nhìn một mối quan tâm đơn lẻ nên thực thi nhanh như một bài kiểm thử đơn vị. Ngược lại, hàm thể lực toàn cục xem xét cùng nhau các điểm tích hợp nơi nhiều đặc tính tương tác. Một kiểm chứng như "khi dịch vụ xác thực và dịch vụ thanh toán hoạt động cùng nhau, cả giao dịch tổng thể có thỏa đồng thời điều kiện bảo mật và độ trễ không" thuộc về đây; nó chạy trong môi trường tích hợp nên tốn kém nhưng bắt được các khiếm khuyết chỉ lộ ra khi kết hợp.

Trên trục nhịp thực thi, loại kích hoạt thực thi để phản ứng với một sự kiện cụ thể như commit hay triển khai. Phần lớn quy tắc nguyên tử thuộc đây và trở thành các chặng của đường ống triển khai. Loại liên tục đo lường thường trực trong lúc vận hành, độc lập với sự kiện. Giám sát độ trễ p99 hay tính sẵn sàng ở môi trường sản xuất và phát cảnh báo khi vi phạm SLO là ví dụ điển hình, và nó ghép với hạ tầng khả quan sát ([[opentelemetry-observability]]). Ngoài ra còn có loại thời gian (temporal) chạy định kỳ độc lập với mã (ví dụ: kiểm tra hằng tháng việc hết hạn/ngừng dùng thư viện mật mã), loại tĩnh (static) kết thúc bằng phân tích tĩnh so với loại động (dynamic) cần phải thực thi, và phân biệt thủ công (manual) do con người thực hiện so với tự động (automated). Chiến lược thực tế lấy mặc định là "tự động, nguyên tử, kích hoạt" và bổ sung bằng các hàm thủ công, thời gian chỉ cho những đặc tính khó tự động hóa.

Sơ đồ dưới đây cho thấy cách các hàm thể lực này được đặt vào đường ống triển khai và môi trường vận hành để tự động hóa quản trị.

flowchart LR
    DEV["Commit của lập trình viên"] --> VCS["Quản lý cấu hình(Git)"]
    VCS --> CI["Đường ống CI"]
    subgraph STAGE["Cổng hàm thể lực"]
        direction TB
        S1["Nguyên tử, tĩnh\n(quy tắc phụ thuộc ArchUnit)"]
        S2["Toàn cục, kích hoạt\n(kiểm chứng hợp đồng tích hợp)"]
        S3["Động, liên tục\n(thời gian đáp ứng khi tải)"]
    end
    CI --> STAGE
    STAGE -->|tất cả đạt| DEPLOY["Triển khai(canary)"]
    STAGE -->|vi phạm| FAIL["Chặn merge, thông báo"]
    DEPLOY --> PROD["Môi trường sản xuất"]
    PROD -->|chỉ số khả quan sát| MON["Hàm thể lực liên tục\n(giám sát sẵn sàng, độ trễ)"]
    MON -.->|cảnh báo vi phạm SLO| DEV

Cụ thể, trong giới Java người ta viết "gói ..web.. không được truy cập gói ..persistence.." dưới dạng một bài kiểm thử JUnit bằng ArchUnit và chạy ở mỗi PR. NetArchTest của .NET, import-linter của Python và dependency-cruiser của JavaScript cũng đóng vai trò tương tự. Khi bài kiểm thử này trượt thì merge bị chặn, nên quy tắc thiết kế được cưỡng chế không phải bằng một tài liệu wiki mà bằng tín hiệu tức thì của một lần build thất bại. Đây chính là "Tự động hóa quản trị kiến trúc (Automating Architectural Governance)" mà phiên bản thứ hai đặc biệt nhấn mạnh, và nó khác về căn bản so với cách một hội đồng rà soát kiến trúc (ARB) mỗi quý một lần lướt qua hàng trăm thay đổi sau khi việc đã rồi.

4. Lượng tử kiến trúc và quy trình áp dụng

Khái niệm cốt lõi khi bàn về đơn vị thay đổi trong kiến trúc tiến hóa là lượng tử kiến trúc (architectural quantum). Lượng tử nghĩa là đơn vị nhỏ nhất có thể triển khai độc lập, có độ gắn kết chức năng cao, và có độ ghép tĩnh lẫn động trọn vẹn. Lượng tử càng nhỏ và ranh giới càng rõ thì phạm vi lan tỏa của một thay đổi càng hẹp, làm cho sự tiến hóa dễ hơn; ngược lại, khi độ ghép rối rắm — chẳng hạn nhiều dịch vụ dùng chung một cơ sở dữ liệu — thì lượng tử phình to và sự tiến hóa trở nên khó như trong một "monolith phân tán". Do đó khả năng tiến hóa gắn trực tiếp với việc căn chỉnh các bounded context trong [[domain-driven-design]] và với thiết kế độ ghép thấp, và nó ăn khớp tự nhiên với chiến lược thay thế hệ thống cũ một cách tăng dần qua [[strangler-fig-pattern]].

Quy trình áp dụng thường theo thứ tự sau. ① Thống nhất với các bên liên quan về các đặc tính kiến trúc (thuộc tính chất lượng) cần bảo toàn và ưu tiên hóa chúng — vì không thể bảo vệ tất cả, hãy chọn "vài cái quan trọng nhất". ② Dịch mỗi đặc tính thành một hàm thể lực kèm theo một ngưỡng đo được. ③ Đặt các hàm thể lực vào đường ống/giám sát để chạy tự động. ④ Xây dựng và triển khai thay đổi theo đơn vị nhỏ, nhận phản hồi tức thì khi vi phạm. ⑤ Quan sát các chỉ số vận hành và định kỳ xem xét lại các ngưỡng và bản thân các hàm.

Điều thường bị bỏ sót trong quy trình này là nguyên tắc thời điểm chịu trách nhiệm cuối cùng (last responsible moment) và nghịch lý của hàm thể lực quá mức. Vì trừu tượng hóa quá sớm làm cho thay đổi khó hơn, hãy trì hoãn quyết định đến đúng thời điểm cần thiết, nhưng một khi một đặc tính quan trọng đã được định thì đóng đinh nó ngay lập tức bằng một hàm thể lực. Đồng thời, nếu có quá nhiều hàm hoặc ngưỡng quá nghiêm ngặt thì ngay cả sự tiến hóa bình thường cũng bị chặn, sinh ra nghịch lý "công cụ nhằm hỗ trợ thay đổi lại cản trở thay đổi". Ngoài ra, khai thác việc theo định luật Conway cấu trúc hệ thống đi đến chỗ giống cấu trúc tổ chức, chạy một "cơ động Conway ngược" bố trí các đội trước cho khớp với kiến trúc mong muốn sẽ khiến sự tiến hóa được hậu thuẫn ở cấp độ tổ chức ([[team-topologies]]).

5. So sánh với quản trị kiến trúc truyền thống

Giá trị của cách tiếp cận tiến hóa trở nên rõ ràng khi đối chiếu với quản trị truyền thống. Thay vì chỉ liệt kê các mục, nhìn vào "vì sao có sự khác biệt" sẽ thấy mấu chốt nằm ở chỗ thời điểm, chủ thể và hình thức của việc kiểm chứng khác nhau.

Trong mô hình truyền thống, tài liệu thiết kế bắt đầu lệch khỏi mã nguồn ngay sau khi được viết. Một lần rà soát mỗi quý không thể theo kịp sự xói mòn cấu trúc (technical erosion) do hàng trăm đến hàng nghìn commit ở khoảng giữa tạo ra, và dù có phát hiện vi phạm thì nó đã rối chặt đến mức khó gỡ lại. Ngược lại, hàm thể lực phơi bày một vi phạm "ngay khi nó xảy ra" dưới dạng một lần build thất bại, nên nó được sửa ở thời điểm mà chi phí sửa thấp hơn hàng chục lần — khớp đúng với quy tắc kinh nghiệm cũ của kỹ nghệ chất lượng rằng chi phí sửa một khiếm khuyết tăng theo cấp số nhân khi chặng càng muộn. Sự khác biệt này chi phối tốc độ tích lũy của [[technical-debt]].

Làm ví dụ cụ thể, một công ty streaming toàn cầu thường trực kiểm chứng các đặc tính phục hồi của hàng trăm microservices bằng các hàm thể lực liên tục dựa trên thí nghiệm chaos, bảo đảm ngay từ trước khi triển khai rằng lỗi của một thực thể nào đó không lan ra toàn bộ. Làm ví dụ khác, một tổ chức nền tảng lớn đã cài hàng trăm quy tắc ArchUnit vào CI để chặn "phụ thuộc liên tầng không được phép" ở chặng merge, qua đó đưa những vi phạm thiết kế mà một ARB theo quý từng phát hiện sau khi việc đã rồi về gần như bằng 0. Điểm chung của chúng là đã chuyển các đặc tính kiến trúc từ đối tượng "khai báo trong tài liệu và do con người giữ" sang đối tượng "khai báo bằng mã và do đường ống cưỡng chế".

6. Chuyên sâu: Hàm thể lực và nền tảng hóa trong kỷ nguyên dữ liệu/AI

Một xu hướng gần đây là mở rộng hàm thể lực vượt ra ngoài cấu trúc mã sang tự động hóa quản trị trên toàn bộ địa hạt dữ liệu, ML, bảo mật và vận hành. Ở địa hạt dữ liệu, việc ghép với một schema registry chặn các thay đổi lược đồ phá vỡ tương thích ngược ([[schema-registry]]), hoặc kiểm chứng việc tuân thủ hợp đồng dữ liệu ([[data-contract]]) trong đường ống. Ở địa hạt ML, các "hàm thể lực ML" chặn triển khai khi model drift ([[model-drift-monitoring]]) hay các chỉ số công bằng/hiệu năng vượt ra ngoài ngưỡng sẽ đi vào đường ống MLOps, và trong AI tạo sinh, tư duy tiến hóa đang lan rộng qua cách đo thường trực các chất lượng như tỷ lệ ảo giác, độc tính và tỷ lệ phòng vệ prompt injection dưới dạng các cổng đánh giá (eval).

Ở cấp độ tổ chức, kỹ nghệ nền tảng ([[platform-engineering]]) cài sẵn hàm thể lực vào "con đường vàng (golden path)" theo mặc định để mọi đội tự động thừa hưởng quản trị chung. Ghép với policy-as-code ([[policy-as-code]]) và chỉ số DORA ([[dora-metrics]]) giúp có thể quan sát và cải thiện cả việc bảo toàn các đặc tính kiến trúc lẫn hiệu quả phân phối trên cùng một dashboard. Đây là một bước chuyển định nghĩa lại quản trị từ "chi phí kiểm soát" thành "năng lực làm tăng tốc độ phân phối", và trong môi trường mà AI tạo sinh làm bùng nổ lượng mã sản xuất, tầm quan trọng của việc kiểm chứng kiến trúc tự động hóa càng lớn hơn.

Dẫu vậy, sự mở rộng ấy đòi hỏi tiền đề về tính đo được. Một phần đáng kể của "kiến trúc tốt" bao gồm các đặc tính khó đo tự động như tính dễ đọc và dễ hiểu, nên lòng tham quy mọi thứ về hàm thể lực lại sinh ra méo mó. Do đó, phân biệt các đặc tính có thể tự động hóa với các đặc tính cần phán đoán của con người, và bổ sung cho loại sau bằng các hàm thủ công/thời gian và rà soát thiết kế, vẫn là một nhiệm vụ cốt lõi.

7. Các điểm cân nhắc và hàm ý

Từ góc độ kỹ sư chuyên nghiệp, việc áp dụng kiến trúc tiến hóa là bài toán đồng thiết kế các đánh đổi của công nghệ, tổ chức, quản trị và chi phí.

• Chiến lược áp dụng (áp dụng tăng dần): Thay vì cố biến mọi đặc tính thành hàm thể lực cùng một lúc, hãy tự động hóa từ một vài đặc tính cốt lõi dễ bị xói mòn (phụ thuộc tầng, tham chiếu vòng, các SLO then chốt) và mở rộng theo độ trưởng thành. Với hệ thống cũ, ghép với [[strangler-fig-pattern]] và áp dụng hàm trước chỉ cho đoạn được thay thế là thực tế hơn.
• Đánh đổi (nhanh nhẹn với kiểm soát): Càng nhiều hàm thể lực thì sức kiểm soát càng lớn, nhưng độ tự do thay đổi và thời gian build bị hy sinh. Siết số lượng hàm và ngưỡng quá mức sẽ rơi vào nghịch lý nơi công cụ nhằm hỗ trợ tiến hóa lại chặn tiến hóa, nên phải lấy tỷ lệ thất bại và thời gian build làm chỉ số và định kỳ tỉa bớt chính danh mục hàm.
• Tổ chức/văn hóa (cơ động Conway ngược): Quản trị tự động giả định một bước chuyển từ văn hóa "kiến trúc sư là người gác cổng" sang văn hóa "các đội tự chủ bảo toàn đặc tính". Khai thác định luật Conway theo chiều ngược để căn chỉnh ranh giới đội cho khớp với các lượng tử kiến trúc mong muốn, và để các đội căn theo luồng của [[team-topologies]] sở hữu hàm thể lực của chính mình.
• Giới hạn của việc đo và sự bổ sung: Bổ sung cho các đặc tính không tự động hóa được như tính dễ đọc và sự phù hợp của thiết kế bằng các hàm thủ công/thời gian và rà soát, chạy chúng song song với đánh giá định tính như ATAM ([[architecture-tradeoff-analysis-method]]). Tin mù quáng chỉ vào đo tự động sẽ tạo ra thiên lệch nơi "chỉ cái được đo mới được cải thiện".
• Triển vọng (mã hóa quản trị): Các hàm thể lực mở rộng sang dữ liệu, ML, AI và bảo mật hội tụ cùng kỹ nghệ nền tảng và policy-as-code thành "sự mã hóa quản trị". AI tạo sinh càng tăng tốc việc sản xuất mã, thì năng lực hấp thụ thay đổi an toàn qua kiểm chứng tự động càng trở thành năng lực cạnh tranh cốt lõi quyết định đồng thời tốc độ phân phối và chất lượng của tổ chức.

Tài liệu tham khảo

• Building Evolutionary Architectures, 2nd Edition — Ch.2 Fitness Functions (O'Reilly): https://oreilly.com/library/view/building-evolutionary-architectures/9781492097532/ch02.html
• Building Evolutionary Architectures, 2nd Edition — Ch.4 Automating Architectural Governance (O'Reilly): https://oreilly.com/library/view/building-evolutionary-architectures/9781492097532/ch04.html
• Thoughtworks, Building Evolutionary Architectures (2nd Edition): https://www.thoughtworks.com/insights/books/building-evolutionaryarchitectures-second-edition
• InfoQ, Fitness Functions for Your Architecture: https://www.infoq.com/articles/fitness-functions-architecture/

Tóm tắt một câu: Kiến trúc tiến hóa đóng đinh các thuộc tính chất lượng cần bảo toàn thành các hàm thể lực thực thi được và đánh giá chúng tự động ở mỗi thay đổi, nhờ đó hấp thụ thay đổi trên nhiều chiều một cách an toàn và tăng dần, chuyển quản trị kiến trúc từ rà soát tài liệu hậu kỳ sang tự động hóa thường trực.