"Chia Để Trị" (MicroServices) — Một Dạng Tư Duy "Bình Cũ Rượu Mới" Chưa Được Khám Phá
Last updated: August 01, 2025 Xem trên toàn màn hình
Recommended for you
- 11 May 2021
Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án 806 - 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 667
- 18 May 2021 Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 631
- 01 Jun 2021 Bản thiết kế sơ bộ (Brief) là gì? 544
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 483
- 01 Jan 2024 Tổng hợp 25 quy luật quan trọng trong quản lý dự án 481
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 466
- 19 Aug 2024 Kiểm toán công nghệ thông tin (IT Audit) - Nghề mới mẻ ở Việt Nam 453
- 03 May 2022 Mô hình Hybrid Agile là gì? 451
- 02 Jan 2024 Domain Engineering là gì? 434
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 400
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 392
- 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 378
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 352
- 01 Sep 2023 "Data steward" là gì? 348
- 01 Aug 2021 Hiện tượng Gold plating (mạ vàng) là gì? Tại sao có ảnh hưởng quyết định đến chất lượng dự án? 339
- 05 Aug 2024 Giải mã 10 sai lầm về quản lý thay đổi 333
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 319
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 297
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 275
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 243
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 231
- 08 Aug 2023 Mất kiểm soát phạm vi dự án (Scope Creep) và hiệu ứng quả cầu tuyết (snowball) 219
- 12 Jan 2024 Tư duy hệ thống trong Quản Lý Dự Án diễn ra như thế nào? 208
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 205
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 186
- 08 Apr 2024 Hiệu ứng Matthew: Tác động và Ứng dụng trong Chuyển đổi Số và Công nghệ tại Việt Nam 180
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 160
- 08 Aug 2019 10 lý do tại sao việc sử dụng và vận hành phần mềm điều hành doanh nghiệp không được hiệu quả 115
- 10 Aug 2020 Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 102
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 93
- 14 Sep 2021 COQ (Cost of quality) áp dụng cho chất lượng phần mềm như thế nào? 88
- 26 Mar 2025 Từ điển tất cả các chức danh trong lĩnh vực CNTT và Chuyển Đổi Số 65
- 02 Aug 2025 Cloud vs On-Premise vs Hybrid: Lựa chọn nào phù hợp nhất cho vận hành phần mềm doanh nghiệp? 62
- 11 Mar 2025 Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 55
- 01 May 2024 Tổng hợp các thuật ngữ lĩnh vực tư vấn CNTT 49
- 03 Jul 2025 20 "NGHỊCH LÝ" NHƯNG "THUẬN LÝ" TRONG CUỘC SỐNG 41
- 02 Apr 2025 Anti-Hiring Là Gì? Tại sao các doanh nhân tinh gọn lại nói “KHÔNG” với tuyển dụng? 40
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 34
- 11 Apr 2025 Dữ liệu sống – nền tảng cốt lõi cho sự sinh tồn và phát triển trong kỷ nguyên số 31
- 15 Aug 2025 Dự án phần mềm bị trì hoãn và vấn đề "akrasia" 29
- 01 Apr 2025 CTO ra quyết định như thế nào? 27
- 19 Aug 2025 Lập dự toán chi phí và thời gian cho dự án Software Outsourcing Project 15
Xu hướng mới trong thế giới điện toán đám mây (cloud computing) là tách các hệ thống nguyên khối (monoliths) thành các dịch vụ vi mô (microservices) nhằm cải thiện khả năng mở rộng (scalability) của hệ thống. Nhưng liệu đó có phải là lý do duy nhất khiến chúng ta làm điều này? Bên cạnh khả năng mở rộng, microservices còn mang lại vô số lợi ích khác. Những lợi ích này không chỉ "có thì tốt" mà còn là điều khách hàng hiện đại (modern-day customers) thực sự đòi hỏi — như tính sẵn sàng cao (high availability), độ trễ thấp (low latency), và khả năng triển khai tính năng nhanh chóng.
Tuy nhiên, những lợi ích này chỉ đạt được nếu bạn tuân theo một số thực hành nhất định. Để làm được điều đó, bạn không chỉ cần thay đổi mã nguồn (code) mà còn phải thay đổi tư duy (mindset) về cách nhìn nhận các dịch vụ. Việc hiểu rõ động lực và mục đích của việc tạo ra microservices là yếu tố then chốt để dẫn đến thành công cho bất kỳ ứng dụng đám mây hiện đại nào.
Một số điểm cần cân nhắc khi chuyển từ monolith sang microservices:
-
Dịch vụ nhỏ, tập trung (Small focused services): Mục tiêu không chỉ là tái cấu trúc mã thành các thực thể khác nhau. Ý tưởng cốt lõi là mỗi dịch vụ chỉ làm một việc và làm “đúng”.
-
Đừng quá đà nhưng cũng đừng ngại nhiều microservices: Không có kích thước chuẩn nào cho một microservice. Có thể là một dịch vụ rất nhỏ với một API, hoặc một dịch vụ lớn hơn với nhiều API và các điểm đầu cuối bất đồng bộ (async endpoints). Dịch vụ lớn sẽ tiếp tục phình to theo thời gian và phải tái cấu trúc lại. Quy tắc cơ bản là đưa ra quyết định hợp lý theo từng trường hợp.
-
Kỳ vọng cao về thời gian hoạt động và SLA: Microservices được kỳ vọng là cực kỳ đáng tin cậy. Dù có thể gặp lỗi, chúng phải phục hồi nhanh chóng. Hệ thống cần có fallbacks và cache ở nhiều tầng để đảm bảo SLA với nhiều chữ số 9 (multiple nines).
-
Khắc phục sự cố nhanh chóng: Triển khai nhanh đồng nghĩa với việc sửa lỗi (fix forward) cũng nhanh như quay lui (rollback). Hãy sử dụng feature flags không chỉ để rollback an toàn mà còn để kiểm soát tính năng.
-
Không chỉ microservices, mà còn micro-frontends: Các nguyên tắc tương tự cũng được áp dụng cho frontend. Micro-frontends giúp bạn phát hành từng phần giao diện độc lập. Frontend không chỉ là UI – còn nhiều thứ khác phía sau.
-
Triển khai liên tục (Continuous Deployment): Mã sẽ được đưa vào môi trường production chỉ trong vài phút. Dịch vụ nhỏ, thay đổi nhỏ giúp build và deploy nhanh. Điều này đòi hỏi kiểm thử tự động, tuân thủ test pyramid, kiểm tra chất lượng mã nghiêm ngặt và rollback tự động.
-
Công nghệ luôn thay đổi (Evolving Technologies): Bạn cần sẵn sàng thay đổi công nghệ thường xuyên hơn so với monolith. Microservice phục vụ mục tiêu cụ thể, nên cần cập nhật công nghệ tương ứng. Điều này thúc đẩy sự đổi mới.
-
Rủi ro khi mắc lỗi là tối thiểu: Vì thay đổi nhỏ và rollback nhanh khi kiểm thử thất bại, nên việc triển khai dễ dàng hơn. Lỗi dễ cô lập vì bạn biết rõ API nào của microservice nào bị lỗi.
-
Lập trình viên và người review mã hài lòng: Thay đổi nhỏ, thường xuyên giúp review dễ dàng, không còn kéo dài hàng ngày. Branch ngắn hạn, ít xung đột merge. Việc kiểm tra chất lượng cũng dễ quản lý hơn.
-
Tự động hoàn nguyên (Automated Reverts): Nếu kiểm thử hoặc kiểm tra chất lượng thất bại, hệ thống sẽ tự động rollback commit. Dù cần giảm thiểu lỗi âm tính giả (false negatives), nhưng đổi lại lập trình viên tự tin hơn khi triển khai.
-
Chỉ cần tuân thủ hợp đồng API (API contracts): Các nhóm khác chỉ cần biết khi hợp đồng API thay đổi. Hợp đồng này không chỉ bao gồm giao diện phản hồi mà còn cả hành vi API. Những thay đổi về framework, hạ tầng hay phiên bản mới có thể ẩn với người dùng.
-
Chuẩn bị cho lưu lượng cao (High traffic): Khi tách một dịch vụ lớn thành nhiều dịch vụ nhỏ, các tương tác nội bộ trở thành tương tác bên ngoài. Mỗi microservice có thể nhận lưu lượng từ cả bên ngoài lẫn từ các dịch vụ khác, bao gồm các tác vụ nền. Do đó cần có rate-limiting và backpressure.
-
Luồng API ngắn và đơn giản (Simplified API flows): Nếu microservice quản lý một thực thể dữ liệu cụ thể, thì các tương tác nên giới hạn trong thực thể đó. Ví dụ: dịch vụ người dùng (user service) không nên lưu thông tin về tính năng, gói cước, hay doanh nghiệp của người dùng. Thay vào đó, hãy tạo orchestration services để tổng hợp và xử lý logic kinh doanh.
-
Văn hóa DevOps là chìa khóa (DevOps culture): Microservices giả định rằng nhóm dev chịu trách nhiệm toàn bộ – từ phát triển, kiểm thử đến triển khai và hạ tầng. Việc tách nhóm vận hành riêng chỉ gây cồng kềnh và làm mất lợi ích microservices.
-
Tin tưởng vào cache đối với dịch vụ dữ liệu: Dù có thể dùng cơ sở dữ liệu với autoscaling và hỗ trợ nhiều vùng, nhưng việc dùng cache giúp đảm bảo SLA ổn định cho cả khách hàng nội bộ và bên ngoài.
-
Microservices làm hài lòng doanh nghiệp và khách hàng: Đây là điểm cốt lõi để thuyết phục ban lãnh đạo đầu tư chuyển từ monolith sang microservices. Khách hàng đòi hỏi tính năng nhanh, SLA tốt, độ tin cậy cao. Từ đó dẫn đến doanh thu cao hơn, giảm chi phí hạ tầng, và lợi thế cạnh tranh.
-
Kiến trúc rời rạc (Loosely coupled architecture): Xem mỗi dịch vụ như một thực thể độc lập giúp dễ bảo trì và triển khai tính năng mới. Phụ thuộc lẫn nhau sẽ làm chậm tiến độ. Hiểu rõ “kiến trúc rời rạc” là gì và thực hiện nghiêm túc là điều thiết yếu.
-
Nhiều tương tác bất đồng bộ (Asynchronous chatter): Để đạt SLA và cô lập lỗi, microservices thực hiện nhiều tác vụ dưới dạng bất đồng bộ. Nếu không nằm trong đường đi chính (critical path) thì nên làm bất đồng bộ.
-
Metrics, Logging và Alerts là yếu tố sống còn: Dịch vụ nhỏ giúp dễ debug, ít luồng logic nên việc cảnh báo và đo lường rất hiệu quả. Đây là một trong các lý do microservices đạt độ sẵn sàng rất cao. Đồng thời, log ít nhưng mang nhiều thông tin giá trị hơn.
Trên đây là một số điểm để thay đổi tư duy khi tiếp cận microservices, khác với cách tiếp cận hệ thống nguyên khối (monoliths) truyền thống. Để tìm hiểu sâu hơn về microservices, hãy đón đọc bài viết tiếp theo hoặc tham khảo các liên kết được đề xuất.
Tác giả: Deepesh Thakkar
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Link copied!
Mới cập nhật