08 · Service-Based & SOA — Sổ tay Kiến trúc Phần mềm

01 Tổng quan hai phong cách

Service-Based

distributed, thực dụng

Bản "lai nhẹ" của microservices: 4–12 domain service thô, dùng chung một DB đơn khối. Ít phức tạp & rẻ hơn microservices.

SOA điều phối

enterprise reuse, 199x–200x

Phân tầng dịch vụ quanh một orchestration engine. Sinh ra vì tái sử dụng doanh nghiệp — rồi chính tham vọng đó giết nó.

Đặt cạnh nhau để thấy rõ "mọi thứ đều đánh đổi": cùng là phân tán, Service-Based ghi điểm gần như mọi mặt, còn SOA điểm rất thấp — không phải vì người xưa kém, mà vì mục tiêu thời đó (tái sử dụng tối đa) va vào thực tế.

02 Service-Based Architecture

Cấu trúc phân tầng vĩ mô phân tán: giao diện triển khai riêng → các domain service thô truy cập từ xa (REST/messaging) → một CSDL dùng chung. Chính cái DB đơn khối là dấu hiệu nhận diện.

DB dùng chung cho phép SQL & join như monolith; vì ít service (4–12) nên kết nối DB không thành vấn đề. Khó là khi đổi lược đồ ảnh hưởng nhiều service → cần shared library theo phân vùng logic.

Giữ ACID

trong một service

Service thô nên giao dịch commit/rollback ACID gói gọn trong một service — không phải vật lộn BASE như microservices.

Thiết kế bên trong

layered / domain

Mỗi domain service thường tự là một layered nhỏ (API facade · business · persistence), hoặc chia sub-domain.

Biến thể linh hoạt

variants

UI có thể tách theo domain; DB có thể tách (hiếm); thêm API layer (tùy chọn) khi mở ra hệ ngoài. Linh hoạt bậc nhất.

Đánh giá đặc tính — Service-Based

Chi phí tổng thể Overall cost●●●●●

Tính đơn giản Simplicity●●●●●

Tính khả dụng Availability●●●●●

Khả năng chịu lỗi Fault tolerance●●●●●

Khả năng triển khai Deployability●●●●●

Khả năng kiểm thử Testability●●●●●

Hiệu suất Performance●●●●●

Sự linh hoạt Agility●●●●●

Khả năng mở rộng Scalability●●●●●

Khả năng tiến hóa Evolutionary●●●●●

Tính đàn hồi Elasticity●●●●●

03 SOA điều phối

Cuối thập niên 1990–2000, máy tính & license đắt đỏ → triết lý thống trị là tái sử dụng (reuse) tối đa. SOA dựng một phân loại dịch vụ nhiều tầng, dán keo bằng orchestration engine (ESB/message bus).

Phân loại dịch vụ + bộ máy điều phối

Business Services

điểm vào · định nghĩa WHAT

Trừu tượng, không chứa code — chỉ input/output/schema. Vd ExecuteTrade, PlaceOrder. Do người nghiệp vụ định nghĩa.

Enterprise Services

hạt mịn · HOW · dùng chung

Hiện thực nguyên tử, tái dùng: CreateCustomer, CalculateQuote. "Viên gạch" của business service.

Application Services

dùng một lần

Một ứng dụng, không chia sẻ (vd geo-location riêng). Do một đội app sở hữu.

Infrastructure Services

vận hành

Logging, giám sát, xác thực/uỷ quyền. Đội hạ tầng dùng chung sở hữu.

Orchestration Engine = trái tim. Message bus/ESB khâu business service với enterprise service: điều phối, biến đổi dữ liệu, ranh giới giao dịch. Mọi lời gọi đều đi qua nó → theo Conway's Law, đội tích hợp dần thành "nút thắt cổ chai" quan liêu.

Sai lầm chết người · tái sử dụng quá đà. Dồn mọi hành vi khách hàng vào một Customer service đạt "reuse" — nhưng một thay đổi nhỏ gợn sóng ra toàn hệ (ripple), buộc deploy phối hợp & test tổng thể. Tệ hơn: domain như CatalogCheckout bị xé mỏng qua hàng chục service nhiều tầng + một schema DB. "Thêm một dòng địa chỉ" cũng thành ác mộng. Vậy là hết tái sử dụng.

Đánh giá đặc tính — SOA

Khả năng mở rộng Scalability●●●●●

Tính đàn hồi Elasticity●●●●●

Tính khả dụng Availability●●●●●

Khả năng chịu lỗi Fault tolerance●●●●●

Chi phí tổng thể Overall cost●●●●●

Tính đơn giản Simplicity●●●●●

Khả năng triển khai Deployability●●●●●

Khả năng kiểm thử Testability●●●●●

Hiệu suất Performance●●●●●

Khả năng tiến hóa Evolutionary●●●●●

Sự linh hoạt Agility●●●●●

04 Soi qua hệ RAG

Dựng "Hỏi–đáp tài liệu" theo Service-Based là lựa chọn rất hợp lý cho một hệ vừa phải: vài domain service thô, dùng chung một kho dữ liệu.

flowchart TB
  UI["PHP · Giao diện"]:::ui
  UI --> ING["Ingestion service"]:::svc
  UI --> QRY["Query service"]:::svc
  UI --> ADM["Admin/Docs service"]:::svc
  ING --> DB[("DB dùng chung + Vector Store")]:::db
  QRY --> DB
  ADM --> DB
  classDef ui fill:#14233b,stroke:#14233b,color:#f3ede0;
  classDef svc fill:#e7ddf2,stroke:#6a4ca8,color:#1c1a14;
  classDef db fill:#e2edf3,stroke:#2f6d93,color:#1c1a14;

3 domain service thô (Ingestion/Query/Admin) cùng một kho — giữ được giao dịch ACID khi ghi metadata + vector, mà không gánh sự phức tạp của microservices.

PHP · gọi domain service từ xa (REST)

// UI gọi thẳng domain service thô — không cần API layer cho hệ nội bộ
$ans = $http->post('http://query-svc/query', ['question' => $q, 'top_k' => 5]);
// Ingestion & Query CHIA SẺ một DB → join metadata + vector trong 1 giao dịch ACID

RAG Đừng lặp lại sai lầm SOA: cám dỗ gom mọi thứ vào một DocumentService "vạn năng" rồi bắt mọi luồng đi qua một orchestration bus sẽ tạo ghép nối cực đoan — đổi cách chunk cho một loại tài liệu lại làm gợn sóng cả hệ. Giữ domain service thô vừa phải & độc lập.

05 Ghi nhớ nhanh

Service-Based = 4–12 domain service thô + 1 DB dùng chung — dấu hiệu nhận diện là cái DB đơn khối.

Giữ ACID, né BASE — service thô nên giao dịch gói trong một service; thực dụng & rẻ hơn microservices.

SOA = phân loại dịch vụ + orchestration engine — Business (WHAT) · Enterprise (HOW, dùng chung) · Application (một lần) · Infrastructure (vận hành).

Tái sử dụng quá đà = ghép nối cực đoan — bài học chết người của SOA: reuse tối đa khiến mọi thay đổi gợn sóng toàn hệ.

Cùng phân tán, điểm trái ngược — minh hoạ sống động "mọi thứ đều đánh đổi"; mục tiêu sai thời điểm có thể phá cả một phong cách.

NguồnChương 13 (Service-Based Architecture) & Chương 16 (Orchestration-Driven Service-Oriented Architecture), Fundamentals of Software Architecture — Mark Richards & Neal Ford, O'Reilly 2020.