Phong cách kiến trúc và Mẫu thiết kế
1. Tổng quan
A. Định nghĩa
Phong cách kiến trúc (Architecture Style) là khung thiết kế vĩ mô (Macro) tổ chức cấu trúc tổng thể của hệ thống, còn mẫu thiết kế (Design Pattern) là giải pháp vi mô (Micro)·tái sử dụng được giải quyết lặp đi lặp lại một vấn đề thiết kế cụ thể. Cái trước quy định việc bố trí·kết nối các thành phần và các thuộc tính chất lượng, còn cái sau quy định việc tạo·cấu trúc·hành vi ở mức lớp·đối tượng.
Quan hệ của hai khái niệm trở nên rõ ràng nếu ví với "kiểu kết cấu của tòa nhà" và "kỹ thuật định hình để trang trí căn phòng". Nếu phong cách kiến trúc quyết định bộ khung tổng thể của tòa nhà là chung cư hay nhà riêng (kiểu phân tầng·MSA·hướng sự kiện), thì mẫu thiết kế là giải pháp giải quyết theo phương thức đã được kiểm chứng những vấn đề cục bộ gặp đi gặp lại bên trong tòa nhà đó — ví dụ "làm sao để chỉ tạo một đối tượng cụ thể duy nhất và chia sẻ nó". Việc thay đổi kiểu kết cấu của tòa nhà gần như là phải làm lại từ móng, nhưng việc thay đổi kỹ thuật bố trí nội thất trong phòng thì tương đối cục bộ và dễ đảo ngược.
Sự khác biệt bản chất giữa hai điều nằm ở mức trừu tượng hóa (Abstraction Level) và phạm vi ảnh hưởng (Scope of Impact). Việc chọn phong cách kiến trúc là quyết định khó đảo ngược (irreversible), chi phối các thuộc tính chất lượng (Quality Attribute) của toàn hệ thống như hiệu năng·khả năng mở rộng·khả năng sẵn sàng·bảo mật. Ngược lại, mẫu thiết kế xử lý tính linh hoạt·khả năng tái sử dụng ở mức lớp·thành phần cụ thể nên có thể thay thế tương đối dễ dàng bằng tái cấu trúc. Việc Martin Fowler diễn đạt "kiến trúc là tập hợp các quyết định khó đảo ngược" cũng nằm trong bối cảnh này.
B. Bối cảnh ra đời và sự cần thiết
Phần mềm càng lớn và phức tạp thì việc mỗi lần đều nghĩ cấu trúc từ đầu càng kém hiệu quả và rủi ro thất bại lớn. Từ sau cái gọi là "khủng hoảng phần mềm (Software Crisis)" cuối thập niên 1960, các nỗ lực tái sử dụng những giải pháp cấu trúc đã được kiểm chứng đã được tích lũy. Phong cách kiến trúc được David Garlan và Mary Shaw hệ thống hóa vào thập niên 1990, còn mẫu thiết kế được định hình thành 23 mẫu bởi cuốn sách Design Patterns: Elements of Reusable Object-Oriented Software của GoF (Gang of Four) năm 1994.
Lý do cần hai công cụ này được tóm gọn thành ba điều. Thứ nhất, khả năng tái sử dụng — tái sử dụng các giải pháp mà các lập trình viên đi trước đã kiểm chứng qua thử-sai để không phát minh lại cái bánh xe. Thứ hai, giao tiếp — truyền đạt cô đọng ý đồ thiết kế bằng vốn từ chung (Vocabulary) như "phần này là mẫu observer", "toàn bộ là MSA". Thứ ba, khả năng dự đoán chất lượng — cấu trúc đã kiểm chứng cho biết sẽ đạt được thuộc tính chất lượng nào và hy sinh điều gì, nên có thể đánh giá trước sự đánh đổi.
2. Cục diện tổng thể của phong cách kiến trúc và mẫu thiết kế
Hai khái niệm đảm nhiệm các tầng khác nhau trong cùng một hệ thống. Sơ đồ khái niệm dưới đây cho thấy vĩ mô (phong cách) và vi mô (mẫu) cùng hoạt động theo tầng lớp như thế nào.
flowchart TB
subgraph MACRO["Vĩ mô · Toàn hệ thống(Architecture Style)"]
L["Phân tầng(Layered)"]
M["Microservice(MSA)"]
E["Hướng sự kiện(Event-driven)"]
end
subgraph MICRO["Vi mô · Bên trong thành phần(Design Pattern)"]
C["Tạo(Creational)"]
ST["Cấu trúc(Structural)"]
B["Hành vi(Behavioral)"]
end
MACRO -->|"Định bộ khung cấu trúc rồi lấp đầy bên trong"| MICRO
QA["Thuộc tính chất lượng(hiệu năng·mở rộng·bảo mật)"] --- MACRO
RU["Tái sử dụng mã·tính linh hoạt"] --- MICRO
style MACRO fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style MICRO fill:#fef3e8,stroke:#ed8a2f,stroke-width:2px
Điểm được nhấn mạnh trong hình trên là hai tầng có quan hệ bổ sung chứ không phải cạnh tranh. Khi phong cách kiến trúc định bộ xương và ranh giới thành phần của hệ thống, thì bên trong mỗi thành phần được hiện thực bằng mẫu thiết kế. Chẳng hạn trong MSA, mô-đun thanh toán bên trong mỗi microservice có thể thay đổi phương thức thanh toán bằng mẫu chiến lược (Strategy), tạo đối tượng thanh toán bằng mẫu nhà máy (Factory), và thông báo sự kiện hoàn tất thanh toán bằng mẫu observer (Observer).
Tổng hợp sự khác biệt của hai khái niệm dưới góc nhìn thực tiễn như sau. Bảng là công cụ hỗ trợ so sánh, còn cốt lõi là "vì sao sự khác biệt đó sinh ra". Vì phạm vi khác nhau nên hiệu ứng lan tỏa của thay đổi khác nhau, và vì lan tỏa thay đổi khác nhau nên độ khó đảo ngược khác nhau.
| Phân loại | Phong cách kiến trúc | Mẫu thiết kế |
|---|---|---|
| Phạm vi | Toàn hệ thống(vĩ mô) | Lớp·thành phần(vi mô) |
| Mối quan tâm | Cấu trúc·thành phần·kết nối·thuộc tính chất lượng | Tạo·cấu trúc·hành vi đối tượng |
| Ảnh hưởng | Hiệu năng·mở rộng·bảo mật(khó đảo ngược) | Tái sử dụng mã·linh hoạt(dễ thay thế) |
| Sản phẩm tiêu biểu | Đặc tả kiến trúc·sơ đồ C4 | Sơ đồ lớp·UML |
| Ví dụ | Phân tầng, MSA, hướng sự kiện, pipe-filter | Singleton, factory, observer, strategy |
3. Các phong cách kiến trúc tiêu biểu
Phong cách kiến trúc được lựa chọn tùy theo miền vấn đề và yêu cầu chất lượng. Ở đây trình bày chi tiết đến cả nguyên lý và sự đánh đổi của ba phong cách được dùng thường xuyên nhất trong thực tế — phân tầng, microservice, hướng sự kiện.
flowchart TB
S["Chọn phong cách kiến trúc"] --> L["Phân tầng(Layered)<br/>đơn giản·phổ biến"]
S --> M["Microservice(MSA)<br/>mở rộng·tự chủ"]
S --> E["Hướng sự kiện(Event-driven)<br/>thời gian thực·bất đồng bộ"]
L --> LT["Đánh đổi: dễ tổn thương khi thay đổi xuyên tầng"]
M --> MT["Đánh đổi: phức tạp phân tán"]
E --> ET["Đánh đổi: khó truy vết luồng"]
style S fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
A. Kiến trúc phân tầng (Layered)
Phân tầng là phong cách phổ biến và dễ hiểu nhất, tách hệ thống theo chiều ngang thành các tầng biểu diễn (Presentation)·nghiệp vụ (Business)·truy cập dữ liệu (Data Access) để phân chia mối quan tâm. Mỗi tầng lấy nguyên tắc là luồng một chiều chỉ phụ thuộc vào tầng ngay bên dưới, và nhờ quy tắc này mà thay đổi nội bộ của một tầng cụ thể không lan sang tầng khác. Chẳng hạn dù có đổi công nghệ truy cập dữ liệu từ MyBatis sang JPA thì tầng nghiệp vụ chỉ cần giữ nguyên interface là không bị ảnh hưởng.
Điểm mạnh của phong cách này là chi phí học tập thấp và phân chia trách nhiệm rõ ràng. Đây là lý do phần lớn ứng dụng web doanh nghiệp (cấu trúc 3-tier Spring MVC truyền thống) áp dụng phương thức này. Tuy nhiên giới hạn cũng rõ ràng. Nếu tình huống một thay đổi yêu cầu xuyên qua (sinkhole) cả tầng biểu diễn·nghiệp vụ·dữ liệu — ví dụ để thêm một trường thì phải sửa cả màn hình·service·DTO·entity·bảng — trở nên thường xuyên thì lợi ích của việc phân tầng trở nên vô nghĩa. Ngoài ra vì mọi yêu cầu đều đi qua các tầng theo trình tự, nên ở các dịch vụ quy mô lớn có lưu lượng bùng nổ thì đơn vị mở rộng theo chiều ngang (scale-out) trở thành toàn bộ ứng dụng, gây kém hiệu quả.
Về mặt thực tiễn, nó phù hợp với những nơi coi trọng phát triển nhanh như hệ thống quản lý nội bộ có quy tắc miền đơn giản và tuổi thọ dự đoán được, hay MVP của startup giai đoạn đầu. Ngược lại, ở các nền thương mại điện tử lớn nơi lưu lượng và độ phức tạp miền cùng tăng thì khó trụ được chỉ bằng phân tầng, nên nhiều trường hợp tiến hóa sang MSA.
B. Kiến trúc microservice (MSA)
Microservice là phong cách phân rã hệ thống thành các dịch vụ nhỏ có thể triển khai độc lập. Mỗi dịch vụ sở hữu cơ sở dữ liệu riêng (Database per Service), và giữa các dịch vụ giao tiếp bằng REST·gRPC·message. Netflix là trường hợp tiêu biểu đã chuyển đổi monolith thành hơn 700 microservice trong khoảng 7 năm kể từ 2009 để xử lý hàng triệu yêu cầu mỗi giây, và Amazon·Uber·Coupang cũng đi theo lộ trình tương tự.
Lợi ích cốt lõi của MSA có ba điều. Thứ nhất triển khai độc lập — có thể triển khai riêng dịch vụ thanh toán hàng chục lần mỗi ngày nên rủi ro triển khai được cô lập. Thứ hai mở rộng theo từng dịch vụ — chỉ tăng instance cho dịch vụ tra cứu sản phẩm nơi lưu lượng dồn về để dùng tài nguyên hiệu quả. Thứ ba cô lập lỗi (Fault Isolation) — có thể dùng circuit breaker để chặn sao cho dù dịch vụ gợi ý chết thì dịch vụ đặt hàng vẫn tiếp tục hoạt động.
Tuy nhiên cái giá của lợi ích này là sự phức tạp bản chất của hệ thống phân tán. Mạng không đáng tin cậy (trễ·đứt), tính nhất quán dữ liệu trải trên nhiều dịch vụ phải giải bằng saga·nhất quán cuối cùng (Eventual Consistency) thay cho giao dịch phân tán, và cần thêm hạ tầng khả quan sát (Observability) và service mesh cho log·truy vết·giám sát. Tức là độ phức tạp phát triển chuyển hóa thành độ phức tạp vận hành. Đây là lý do Martin Fowler cảnh báo "để gánh được MSA thì trước hết phải có mức độ trưởng thành tối thiểu (tự động hóa triển khai·giám sát·ứng phó lỗi)".
Dưới đây là sơ đồ chi tiết luồng yêu cầu đặt hàng của người dùng được xử lý trong môi trường MSA.
sequenceDiagram
participant U as Người dùng
participant G as API Gateway
participant O as Dịch vụ đặt hàng
participant P as Dịch vụ thanh toán
participant I as Dịch vụ tồn kho
participant Q as Message Broker
U->>G: Yêu cầu đặt hàng
G->>O: Định tuyến
O->>P: Yêu cầu duyệt thanh toán
P-->>O: Duyệt hoàn tất
O->>Q: Phát sự kiện tạo đơn hàng
Q->>I: Đăng ký trừ tồn kho
I-->>Q: Sự kiện xác nhận tồn kho
O-->>U: Phản hồi tiếp nhận đơn hàng
C. Kiến trúc hướng sự kiện (Event-driven)
Hướng sự kiện là phong cách trong đó thành phần phát (Publish) sự thay đổi trạng thái dưới dạng "sự kiện", và thành phần quan tâm thì đăng ký (Subscribe) sự kiện đó để phản ứng. Vì bên phát và bên đăng ký không trực tiếp biết nhau nên kết nối lỏng lẻo (Loose Coupling) được tối đa hóa, và đạt được tính thời gian thực và khả năng mở rộng nhờ xử lý bất đồng bộ. Truyền dòng sự kiện lấy Apache Kafka làm trung tâm là hiện thực tiêu biểu, và phát huy sức mạnh ở những nơi xử lý hàng trăm nghìn sự kiện mỗi giây như gợi ý thời gian thực·xử lý cảm biến IoT·log kiểm toán giao dịch tài chính.
Điểm mạnh của phong cách này là khả năng mở rộng và khả năng tiến hóa. Dù thêm bên đăng ký mới (ví dụ dịch vụ phân tích marketing) cũng không cần sửa mã của bên phát nên có thể mở rộng hệ thống một cách dần dần. Ngược lại, vì luồng lan tỏa bất đồng bộ qua nhiều sự kiện nên khó truy vết·gỡ lỗi toàn bộ luồng xử lý một cách bao quát, và phải thiết kế riêng việc đảm bảo thứ tự sự kiện·xử lý trùng lặp (tính lũy đẳng)·nhất quán cuối cùng. Để nắm bắt "đã xử lý đến đâu" khi có lỗi thì truy vết phân tán (Distributed Tracing) trở thành bắt buộc.
So sánh sự đánh đổi của ba phong cách, thì tiêu chí lựa chọn rốt cuộc nằm ở thuộc tính chất lượng được yêu cầu. Nếu ưu tiên sự đơn giản thì phân tầng, nếu ưu tiên mở rộng độc lập·phát triển tự chủ thì MSA, nếu ưu tiên thời gian thực·kết nối lỏng lẻo thì hướng sự kiện.
| Phong cách | Điểm mạnh cốt lõi | Đánh đổi | Áp dụng tiêu biểu |
|---|---|---|---|
| Phân tầng | Đơn giản·phân chia trách nhiệm rõ | Dễ tổn thương khi thay đổi xuyên tầng, đơn vị mở rộng là toàn bộ | Hệ thống quản lý nội bộ, MVP |
| Microservice | Triển khai·mở rộng·cô lập lỗi độc lập | Phức tạp phân tán·gánh nặng vận hành | Netflix, thương mại điện tử lớn |
| Hướng sự kiện | Kết nối lỏng lẻo, thời gian thực·bất đồng bộ | Khó truy vết luồng·thứ tự·xử lý trùng lặp | Gợi ý thời gian thực, IoT, tài chính |
4. Mẫu thiết kế GoF
Mẫu thiết kế GoF chia thành ba loại theo mục đích. Mẫu tạo (Creational) đóng gói việc tạo đối tượng như thế nào để tách logic tạo khỏi logic sử dụng, mẫu cấu trúc (Structural) xử lý việc kết hợp đối tượng·lớp như thế nào để tạo cấu trúc lớn hơn, còn mẫu hành vi (Behavioral) xử lý việc phân bổ trách nhiệm và tương tác·giao tiếp giữa các đối tượng. Nền tảng của phân loại này là nguyên tắc đóng gói "hãy tách cái thay đổi khỏi cái không thay đổi" và các nguyên tắc thiết kế SOLID.
flowchart TB
G["23 mẫu GoF"] --> CR["Tạo(5)<br/>đóng gói tạo đối tượng"]
G --> STR["Cấu trúc(7)<br/>kết hợp đối tượng·lớp"]
G --> BEH["Hành vi(11)<br/>phân bổ trách nhiệm·tương tác"]
CR --> C1["singleton·factory method<br/>abstract factory·builder·prototype"]
STR --> S1["adapter·decorator·proxy<br/>facade·composite·bridge·flyweight"]
BEH --> B1["observer·strategy·command·state<br/>iterator·template method·chain of responsibility"]
style G fill:#fef3e8,stroke:#ed8a2f,stroke-width:2px
A. Mẫu tạo (Creational)
Động cơ cốt lõi của mẫu tạo là "làm sao để khi phương thức tạo đối tượng thay đổi thì mã sử dụng đối tượng đó không bị lung lay". Singleton chỉ tạo·chia sẻ một instance duy nhất, dùng cho các tài nguyên chỉ cần một cái duy nhất trên toàn cục như cấu hình·log·connection pool. Tuy nhiên nó tạo trạng thái toàn cục khiến việc kiểm thử khó khăn và phát sinh chi phí đồng bộ trong môi trường đa luồng, nên ngày nay nhiều trường hợp DI container (Bean scope của Spring) thay thế việc quản lý singleton.
Factory Method ủy thác việc tạo đối tượng cho lớp con để hạ độ kết nối giữa client và lớp cụ thể. Dù thêm kiểu mới cũng không sửa mã client mà chỉ cần mở rộng factory nên hỗ trợ nguyên tắc mở-đóng (OCP). Builder khi tham số hàm khởi tạo nhiều và có tùy chọn thì lắp ráp đối tượng theo từng bước để nâng cao khả năng đọc và tính bất biến (ví dụ: StringBuilder của Java, Builder API của nhiều SDK).
B. Mẫu cấu trúc (Structural)
Mẫu cấu trúc tập trung vào việc kết hợp các lớp·đối tượng đã tồn tại để tạo chức năng hoặc interface mới nhưng không sửa mã hiện có. Adapter chuyển đổi interface không tương thích để kết nối — thiết yếu khi khớp hệ thống legacy hoặc thư viện bên ngoài vào mã mới, và liên quan trực tiếp đến khái niệm 'adapter' của kiến trúc hexagonal. Decorator khoác thêm chức năng cho đối tượng một cách động bằng kết hợp thay cho kế thừa (ví dụ: BufferedReader(new FileReader(...)) của luồng I/O Java). Proxy để đối tượng đại diện kiểm soát việc truy cập đối tượng thực, xử lý trong suốt việc tải trễ·kiểm soát truy cập·caching·gọi từ xa (ví dụ: proxy tải trễ của JPA, stub RPC).
C. Mẫu hành vi (Behavioral)
Mẫu hành vi xử lý việc phân chia trách nhiệm giữa các đối tượng như thế nào và cho chúng giao tiếp ra sao. Observer tự động thông báo sự thay đổi trạng thái của một đối tượng (Subject) cho các bên đăng ký để hiện thực publish-subscribe ở mức mã, và trở thành nền tảng cho việc cập nhật model-view của MVC và event listener. Điều thú vị là mẫu observer có thể được xem là phiên bản vi mô của kiến trúc hướng sự kiện đã thấy ở trên, cho thấy phong cách và mẫu là cùng một nguyên lý ở các thang đo khác nhau. Strategy đóng gói riêng từng nhóm thuật toán để có thể thay thế trong lúc chạy — dùng khi "làm gì thì giống nhau nhưng phương thức khác nhau" như phương thức thanh toán (thẻ·tài khoản·thanh toán nhanh) hoặc chính sách sắp xếp·giảm giá. Command đóng gói yêu cầu thành đối tượng để có thể thực thi·hoàn tác (Undo)·xếp hàng·ghi log.
| Loại | Mục đích | Mẫu tiêu biểu | Ví dụ thực tiễn |
|---|---|---|---|
| Tạo | Đóng gói tạo đối tượng | singleton, factory method, builder | DI container, SDK Builder |
| Cấu trúc | Kết hợp đối tượng·lớp | adapter, decorator, proxy | luồng I/O, tải trễ JPA |
| Hành vi | Phân bổ trách nhiệm·tương tác | observer, strategy, command | MVC, chiến lược thanh toán, Undo |
5. Chuyên sâu: Mẫu kiến trúc phân tán trong kỷ nguyên cloud-native
Nếu mẫu GoF truyền thống xử lý vấn đề ở mức đối tượng trong một tiến trình đơn lẻ, thì môi trường MSA·cloud-native đòi hỏi một loại mẫu mới "vượt qua tiến trình và mạng". Điều này không phải thay thế GoF, mà bổ sung ở thang đo cao hơn.
Thứ nhất, Circuit Breaker là mẫu được phổ biến bởi Netflix Hystrix (hiện là Resilience4j), ngăn lỗi dây chuyền (Cascading Failure) của các dịch vụ hạ nguồn. Khi tỷ lệ gọi thất bại vượt ngưỡng thì "mở (Open)" mạch để trả về ngay phản hồi thất bại, và sau một khoảng thời gian thì chuyển sang "bán mở (Half-Open)" gửi lời gọi thử để xác nhận việc phục hồi. Điều này chặn về mặt vật lý việc lỗi lan ra toàn hệ thống.
Thứ hai, Saga là mẫu thay thế giao dịch phân tán trong MSA. Nó chia nghiệp vụ trải trên nhiều dịch vụ thành chuỗi các giao dịch cục bộ, và nếu thất bại ở giữa thì thực thi giao dịch bù (Compensating Transaction) đảo ngược các bước đã thực hiện. Có phương thức điều phối (bộ điều phối trung tâm) và phương thức biên đạo (chuỗi sự kiện), đảm bảo tính nhất quán cuối cùng ở các nghiệp vụ đi qua nhiều dịch vụ như đặt hàng-thanh toán-giao hàng.
Thứ ba, API Gateway và BFF (Backend for Frontend) xử lý xác thực·định tuyến·tổng hợp·giới hạn tốc độ tại một điểm vào duy nhất giữa client và nhiều microservice. Thứ tư, CQRS·Event Sourcing tách model lệnh (ghi) và truy vấn (đọc) và lưu trạng thái dưới dạng tích lũy các sự kiện, cung cấp khả năng mở rộng đọc và truy vết kiểm toán hoàn chỉnh.
Dưới góc nhìn liên kết đề thi, kỳ thi Kỹ sư chuyên nghiệp về quản lý thông tin đã ra đề về phong cách kiến trúc (phân tầng·MSA·hướng sự kiện) và phân loại GoF, và gần đây ra đề về chiến lược chuyển đổi MSA·circuit breaker·saga dưới dạng đơn lẻ hoặc dạng tình huống. Do đó nếu triển khai bài làm theo cấu trúc tầng lớp "sự khác biệt giữa phong cách và mẫu → sự đánh đổi của các phong cách tiêu biểu → ba phân loại GoF → mở rộng sang mẫu cloud-native" thì có thể đồng thời thể hiện chiều sâu và tính cập nhật.
6. Cân nhắc và hàm ý
Đảm bảo thuộc tính chất lượng bằng phong cách kiến trúc, và tính linh hoạt của mã bằng mẫu thiết kế. Hai tầng có mục đích và phạm vi ảnh hưởng khác nhau nên phải áp dụng bổ sung lẫn nhau chứ không phải cạnh tranh. Nếu chỉ chồng mẫu mà trì hoãn quyết định phong cách thì dừng lại ở tối ưu cục bộ, còn nếu chỉ định phong cách mà không có mẫu thì độ kết nối tăng cao ở giai đoạn hiện thực.
Lạm dụng mẫu là thiết kế quá mức (Over-engineering). Nếu không có vấn đề mà lại áp dụng "mẫu vì mẫu" thì chỉ làm tăng độ phức tạp. Theo nguyên tắc YAGNI (You Aren't Gonna Need It), hãy áp dụng có tiết chế chỉ vào những điểm thực sự được dự báo có thay đổi, và trước tiên kiểm chứng xem lý do thay đổi (trục thay đổi) có thực sự tồn tại hay không.
Vì kiến trúc là quyết định khó đảo ngược nên hãy đánh giá sự đánh đổi một cách tường minh. MSA phải có tiền đề là mức độ trưởng thành về tự động hóa triển khai·giám sát·ứng phó lỗi của tổ chức, và nếu áp dụng khi chưa trưởng thành thì sẽ sinh ra kết quả tệ nhất là "monolith phân tán (Distributed Monolith)". Cũng cần cân nhắc sự phù hợp giữa cấu trúc tổ chức và kiến trúc như định luật Conway (Conway's Law).
Trong kỷ nguyên cloud-native·MSA, các mẫu phân tán bổ sung cho GoF truyền thống là bắt buộc. Phải hiểu circuit breaker·saga·CQRS·event sourcing, và kết hợp với khả quan sát (log·metric·truy vết)·service mesh (như Istio)·điều phối container (Kubernetes) để đưa cả góc nhìn vận hành vào thiết kế.
Lựa chọn chiến lược dưới góc nhìn Kỹ sư chuyên nghiệp. Phong cách·mẫu không phải là viên đạn bạc (Silver Bullet), mà được lựa chọn bằng cách tổng hợp yêu cầu nghiệp vụ·năng lực đội ngũ·tuổi thọ dự kiến·đặc tính lưu lượng. Chiến lược thực tiễn để hạ rủi ro là ban đầu khởi đầu đơn giản bằng monolith và tiến hóa dần sang MSA·hướng sự kiện khi nhu cầu trở nên rõ ràng (mẫu Strangler Fig).
Tài liệu tham khảo
- Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.
- Martin Fowler, "Microservices", https://martinfowler.com/articles/microservices.html
- Chris Richardson, "Microservices Patterns", https://microservices.io/patterns/index.html
- Refactoring.Guru, "Design Patterns", https://refactoring.guru/design-patterns
- Microsoft, "Cloud Design Patterns", https://learn.microsoft.com/en-us/azure/architecture/patterns/
Tóm tắt một câu: Phong cách kiến trúc (phân tầng·MSA·hướng sự kiện) là khung vĩ mô·khó đảo ngược quyết định cấu trúc tổng thể và thuộc tính chất lượng của hệ thống, còn mẫu thiết kế GoF (tạo·cấu trúc·hành vi) là giải pháp vi mô cho các vấn đề thiết kế lặp lại, và trong kỷ nguyên cloud-native thì các mẫu phân tán như circuit breaker·saga bổ sung cho chúng, nên phải đánh giá tường minh sự đánh đổi để áp dụng có tiết chế và bổ sung lẫn nhau.