Eazybank tổng quan về kiến trúc monolith

Kết luận Hệ thống microservices này minh họa một thiết kế hiện đại, sử dụng các công nghệ tiên tiến đểđảm bảo:  Khả năng mở rộng: Các dịch vụ độc lập, dễ triển khai thêm hoặc nâng cấp..

Tổng quan về kiến trúc Monolith

Ứng dụng đơn (Single Page Application - SPA) được định nghĩa là một hệ thống mà tất cả các chức năng như giao diện người dùng (UI), logic nghiệp vụ và truy cập dữ liệu đều được triển khai trên một máy chủ duy nhất Thông thường, ứng dụng này sẽ kết nối với một cơ sở dữ liệu (DB) duy nhất để quản lý và lưu trữ thông tin.

The fundamental layers of a Monolith architecture include the Presentation Layer (UI), which is responsible for the user interface; the Business Logic Layer, which handles the processing of business rules; and the Data Access Layer, which facilitates connections and interactions with the database.

Phát triển và triển khai trở nên đơn giản hơn, lý tưởng cho các đội nhóm nhỏ và ứng dụng quy mô nhỏ, giúp tiết kiệm thời gian và công sức Người dùng không cần phải quản lý các dịch vụ riêng lẻ, tạo điều kiện thuận lợi cho việc triển khai nhanh chóng và hiệu quả.

 Giảm các vấn đề liên quan đến giao thoa (cross-cutting concerns): o Tất cả các chức năng đều nằm trong một codebase, dễ dàng kiểm soát hơn.

 Hiệu suất tốt hơn: o Không có độ trễ mạng (network latency) giữa các thành phần, vì tất cả đều nằm trong cùng một ứng dụng.

 Khó áp dụng công nghệ mới: o Vì tất cả chức năng được tích hợp chặt chẽ, việc thay đổi hoặc cập nhật công nghệ trở nên khó khăn.

 Hạn chế về tính linh hoạt: o Mọi thay đổi nhỏ đều cần triển khai lại toàn bộ ứng dụng.

 Codebase lớn và khó duy trì: o Dễ dẫn đến "technical debt" (nợ kỹ thuật) khi ứng dụng phát triển phức tạp.

 Không có khả năng chịu lỗi (Not fault-tolerant): o Nếu một phần của ứng dụng gặp lỗi, toàn bộ ứng dụng có thể bị ảnh hưởng.

 Cập nhật nhỏ cần triển khai lớn: o Mỗi lần thêm tính năng hoặc sửa lỗi nhỏ đều yêu cầu triển khai lại toàn bộ ứng dụng.

 Single-Process Monolith: Ứng dụng chạy như một quy trình đơn lẻ.

 Modular Monolith: Ứng dụng được chia thành các mô-đun, nhưng vẫn triển khai dưới dạng một đơn vị duy nhất.

 Distributed Monolith: Dù các thành phần được triển khai trên nhiều máy chủ, nhưng vẫn phụ thuộc mạnh mẽ lẫn nhau.

5 Tình huống ứng dụng thực tế

Tình huống 1: Ứng dụng quản lý thư viện nhỏ

 Mô tả: o Một thư viện nhỏ muốn quản lý sách, khách hàng, và lịch mượn trả. o Ứng dụng sử dụng kiến trúc Monolith với các lớp:

 UI: Giao diện quản lý sách và khách hàng.

 Business Logic: Xử lý logic như kiểm tra số lượng sách mượn.

 Data Access: Kết nối với cơ sở dữ liệu SQLite để lưu trữ thông tin.

 Lợi ích: o Đơn giản để phát triển và triển khai. o Không cần chia nhỏ ứng dụng thành nhiều dịch vụ.

Tình huống 2: Ứng dụng bán hàng cho doanh nghiệp nhỏ

Một cửa hàng nhỏ đang tìm cách phát triển một ứng dụng quản lý đơn hàng, kho hàng và hóa đơn Ứng dụng này sẽ tích hợp tất cả các chức năng cần thiết trong một hệ thống Monolith, giúp tối ưu hóa quy trình quản lý và nâng cao hiệu quả kinh doanh.

Một số nhược điểm của ứng dụng bao gồm việc khi cần thay đổi logic tính thuế, toàn bộ hệ thống phải được triển khai lại, gây tốn thời gian và công sức Ngoài ra, khi cửa hàng mở rộng, việc duy trì ứng dụng trở nên khó khăn hơn, ảnh hưởng đến hiệu suất và khả năng quản lý.

Tình huống 3: Chuyển đổi từ Monolith sang Microservices

Một công ty tài chính đã áp dụng Monolith để quản lý tài khoản, giao dịch và thực hiện phân tích Tuy nhiên, khi số lượng người dùng gia tăng, ứng dụng trở nên cồng kềnh và khó khăn trong việc nâng cấp.

 Chuyển đổi từng phần của Monolith thành các microservices độc lập (như tài khoản, giao dịch, báo cáo).

 Kết quả: o Tăng tính linh hoạt và khả năng mở rộng. o Dễ dàng cập nhật và triển khai từng phần riêng lẻ.

Kiến trúc Monolith phù hợp cho:

 Các dự án nhỏ hoặc đội phát triển nhỏ.

 Các ứng dụng không yêu cầu mở rộng hoặc thay đổi công nghệ thường xuyên.

Tuy nhiên, nó gặp nhiều hạn chế khi:

 Ứng dụng phát triển phức tạp.

 Nhu cầu mở rộng và cập nhật tăng cao.

Đặc điểm của Microservices

 Độc lập: Mỗi microservice có thể được phát triển, triển khai, và mở rộng riêng biệt.

 Tổ chức xung quanh domain kinh doanh: Ví dụ, một dịch vụ có thể xử lý Accounts, một dịch vụ khác xử lý Loans.

 Kết nối thông qua mạng: Các dịch vụ giao tiếp với nhau qua API hoặc hệ thống nhắn tin.

2 Ưu điểm (Pros) a Phát triển, kiểm thử, triển khai dễ dàng (Easy to develop, test, and deploy)

 Chi tiết: Mỗi microservice có thể được phát triển độc lập, kiểm thử nhanh, và triển khai mà không cần ảnh hưởng đến các thành phần khác.

Khi cần thay đổi logic tính lãi suất trong dịch vụ cho vay, chỉ dịch vụ này cần được cập nhật mà không ảnh hưởng đến các dịch vụ khác như tài khoản hay thẻ Điều này giúp tăng tính linh hoạt và khả năng thích ứng của hệ thống.

 Chi tiết: Các đội nhóm có thể làm việc song song trên các dịch vụ khác nhau.

 Ví dụ: Đội A phát triển dịch vụ Accounts trong khi đội B làm việc trên dịch vụ Cards. c Mở rộng theo chiều ngang (Horizontal scaling)

 Chi tiết: Có thể mở rộng riêng lẻ một microservice để đáp ứng tải cao mà không cần mở rộng toàn bộ hệ thống.

Khi dịch vụ Loans gặp nhiều yêu cầu, việc tăng số lượng container cho dịch vụ này trong khi giữ nguyên các dịch vụ khác là một giải pháp hiệu quả Phát triển song song giúp tối ưu hóa nguồn lực và đáp ứng nhanh chóng nhu cầu của khách hàng.

 Chi tiết: Nhiều đội nhóm có thể làm việc song song mà không bị phụ thuộc vào tiến độ của nhau.

Một đội phát triển tính năng mới cho dịch vụ Cards, trong khi đội khác tập trung vào việc nâng cao hiệu suất của dịch vụ Loans Điều này cho thấy cách thiết kế hệ thống được xây dựng dựa trên các lĩnh vực kinh doanh cụ thể.

 Chi tiết: Mỗi dịch vụ tập trung vào một domain cụ thể, làm cho việc tổ chức code và dữ liệu trở nên rõ ràng hơn.

 Ví dụ: Dịch vụ Accounts chỉ quản lý tài khoản, trong khi dịch vụ Cards quản lý thẻ tín dụng.

3 Nhược điểm (Cons) a Tính phức tạp cao (Complexity)

 Chi tiết: Hệ thống trở nên phức tạp hơn do phải quản lý nhiều dịch vụ và sự phụ thuộc giữa chúng.

 Ví dụ: Cần thiết lập hệ thống giám sát và theo dõi để đảm bảo các microservices hoạt động tốt. b Chi phí cơ sở hạ tầng cao (Infrastructure overhead)

 Chi tiết: Cần thêm tài nguyên và công cụ để triển khai, giám sát, và mở rộng từng dịch vụ.

Each service may require its own database and container, which can lead to increased infrastructure costs Additionally, there are significant security concerns associated with managing multiple services and their data.

 Chi tiết: Giao tiếp qua mạng giữa các dịch vụ có thể tạo ra lỗ hổng bảo mật.

 Ví dụ: Một dịch vụ bị tấn công có thể gây ảnh hưởng đến giao tiếp với các dịch vụ khác.

4 Tóm tắt quan trọng từ hình ảnh

Ưu tiên khả năng triển khai độc lập cho phép tập trung vào việc triển khai và cập nhật từng microservice mà không ảnh hưởng đến các dịch vụ khác Lợi ích của phương pháp này là tăng tốc độ phát triển và giảm rủi ro khi thực hiện cập nhật.

5 Tình huống ứng dụng thực tế

Tình huống 1: Hệ thống ngân hàng

 Mô tả: o Ngân hàng sử dụng microservices cho các dịch vụ như Accounts, Cards, vàLoans. o Ưu điểm:

 Dịch vụ Loans có thể được cập nhật riêng biệt để thay đổi chính sách lãi suất mà không ảnh hưởng đến các dịch vụ khác.

 Nếu dịch vụ Cards gặp sự cố, dịch vụ Accounts vẫn hoạt động bình thường. o Nhược điểm:

 Yêu cầu giám sát toàn bộ các giao tiếp giữa các dịch vụ, ví dụ như sử dụng Grafana hoặc Prometheus.

Phân tích chi tiết từ ảnh: Monolithic vs SOA vs Microservices

Bài viết trình bày sự khác biệt giữa ba kiến trúc phần mềm chính: kiến trúc nguyên khối (Monolithic), kiến trúc hướng dịch vụ (SOA), và kiến trúc vi dịch vụ (Microservices) Mỗi kiến trúc đều có những đặc điểm riêng và ứng dụng thực tế khác nhau, giúp các nhà phát triển lựa chọn giải pháp phù hợp với nhu cầu dự án của họ.

1 So sánh ba kiến trúc a Monolithic Architecture

Tất cả các thành phần của ứng dụng, bao gồm giao diện người dùng (UI), logic nghiệp vụ và truy cập dữ liệu, được tích hợp trong một hệ thống duy nhất và hoạt động trên một máy chủ chung Ứng dụng này sử dụng một cơ sở dữ liệu chung, giúp tối ưu hóa việc quản lý và truy xuất dữ liệu cho toàn bộ hệ thống.

 Ưu điểm: o Phát triển, triển khai đơn giản, đặc biệt với các ứng dụng nhỏ. o Hiệu suất cao do không có độ trễ mạng giữa các thành phần.

Nhược điểm của kiến trúc ứng dụng truyền thống bao gồm khó khăn trong việc mở rộng khi ứng dụng phát triển lớn hơn, sự cố trong một phần của ứng dụng có thể tác động tiêu cực đến toàn bộ hệ thống, và việc cập nhật hoặc bảo trì đòi hỏi phải triển khai lại toàn bộ ứng dụng.

Các dịch vụ độc lập được kết nối thông qua một Enterprise Service Bus (ESB), đóng vai trò là hệ thống trung gian quản lý giao tiếp giữa các dịch vụ Thông thường, các dịch vụ này sẽ chia sẻ một cơ sở dữ liệu chung để đảm bảo tính đồng nhất và khả năng truy cập dữ liệu hiệu quả.

Dịch vụ tái sử dụng mang lại nhiều lợi ích, trong đó nổi bật là khả năng chia sẻ và sử dụng giữa nhiều ứng dụng khác nhau, giúp tối ưu hóa hiệu quả Bên cạnh đó, việc này cũng góp phần giảm thiểu sự phụ thuộc lẫn nhau giữa các dịch vụ, tạo ra một hệ sinh thái linh hoạt và bền vững hơn.

ESB có thể trở thành điểm yếu duy nhất nếu không được thiết kế hợp lý, dẫn đến nguy cơ mất ổn định cho hệ thống Bên cạnh đó, chi phí để thiết lập và bảo trì ESB thường cao, gây khó khăn cho các tổ chức Hơn nữa, việc giao tiếp qua ESB có thể tạo ra độ trễ lớn hơn so với kiến trúc Monolith, ảnh hưởng đến hiệu suất tổng thể của ứng dụng.

Microservices là kiến trúc chia nhỏ hệ thống thành nhiều dịch vụ độc lập, mỗi dịch vụ hoạt động trên một container hoặc máy chủ riêng biệt Mỗi microservice sở hữu cơ sở dữ liệu riêng, không phụ thuộc vào các dịch vụ khác, giúp tăng cường tính linh hoạt và khả năng mở rộng Các dịch vụ này giao tiếp với nhau thông qua REST API hoặc các giao thức khác, tạo điều kiện cho việc phát triển và bảo trì hệ thống hiệu quả hơn.

Dịch vụ microservices mang lại nhiều ưu điểm nổi bật, bao gồm tính linh hoạt cao khi cho phép phát triển, triển khai và mở rộng từng dịch vụ một cách độc lập Điều này cũng giúp tăng khả năng chịu lỗi, bởi nếu một dịch vụ gặp sự cố, các dịch vụ khác vẫn có thể hoạt động bình thường Hơn nữa, microservices rất phù hợp cho các hệ thống lớn và phức tạp, giúp tối ưu hóa hiệu suất và quản lý dễ dàng hơn.

Hệ thống microservices có nhược điểm là độ phức tạp cao trong quản lý và giám sát, yêu cầu hạ tầng mạnh mẽ để hỗ trợ giao tiếp giữa các dịch vụ, và cần nhiều tài nguyên hơn so với các kiến trúc như Monolith hoặc SOA.

2 Tình huống ứng dụng thực tế

 Ứng dụng: Một cửa hàng nhỏ cần quản lý sản phẩm, khách hàng, và hóa đơn.

 Mô tả: o Tất cả các chức năng được gộp trong một ứng dụng Monolith. o Ứng dụng sử dụng một cơ sở dữ liệu chung để lưu trữ dữ liệu.

 Ưu điểm: Dễ phát triển và triển khai.

 Nhược điểm: Khi cửa hàng mở rộng, ứng dụng sẽ khó bảo trì và mở rộng.

 Ứng dụng: Một nền tảng thương mại điện tử như Amazon.

Các dịch vụ như giỏ hàng, thanh toán và quản lý sản phẩm được triển khai độc lập, mỗi dịch vụ sở hữu cơ sở dữ liệu riêng biệt Các dịch vụ này giao tiếp với nhau thông qua REST API, đảm bảo tính linh hoạt và hiệu quả trong quản lý và vận hành.

Định nghĩa Microservices là

Cách tiếp cận phát triển ứng dụng hiệu quả là chia nhỏ một ứng dụng lớn thành các dịch vụ nhỏ, mỗi dịch vụ đảm nhiệm một chức năng riêng biệt Phương pháp này giúp tối ưu hóa quy trình phát triển và quản lý ứng dụng.

 Chạy độc lập (Own process): o Mỗi dịch vụ hoạt động trong quy trình riêng (process) mà không phụ thuộc trực tiếp vào các dịch vụ khác.

Các dịch vụ thường sử dụng cơ chế giao tiếp nhẹ như REST, gRPC, hoặc thông qua các hệ thống message broker như RabbitMQ và Kafka để tối ưu hóa quy trình trao đổi thông tin.

Tập trung vào năng lực kinh doanh là yếu tố quan trọng, với mỗi dịch vụ được thiết kế nhằm đáp ứng nhu cầu cụ thể của doanh nghiệp, chẳng hạn như dịch vụ quản lý tài khoản và dịch vụ thanh toán.

 Triển khai độc lập (Independently deployable): o Các dịch vụ có thể được triển khai riêng lẻ, không ảnh hưởng đến hoạt động của các dịch vụ khác.

Fully automated deployment machinery utilizes CI/CD tools such as Jenkins, GitHub Actions, or GitLab CI/CD to enable seamless and efficient automated deployment processes.

2 Phân biệt Microservices với các kiến trúc khác

So với Monolithic (Nguyên khối):

 Monolith: Tất cả các thành phần (UI, logic nghiệp vụ, dữ liệu) được tích hợp trong một ứng dụng duy nhất.

 Microservices: Chia nhỏ thành nhiều dịch vụ độc lập, mỗi dịch vụ có thể mở rộng và triển khai riêng.

So với SOA (Service-Oriented Architecture):

 SOA: Dựa vào một hệ thống trung gian như Enterprise Service Bus (ESB) để giao tiếp giữa các dịch vụ.

 Microservices: Giao tiếp trực tiếp hoặc qua các message broker mà không cần ESB.

3 Tình huống ứng dụng thực tế

Tình huống 1: Hệ thống ngân hàng

 Mô tả: o Ngân hàng triển khai các microservices như:

 Accounts Service: Quản lý tài khoản người dùng.

 Loans Service: Quản lý khoản vay.

 Payments Service: Xử lý thanh toán. o Mỗi dịch vụ có thể được triển khai trên container riêng và giao tiếp qua REST API.

 Ưu điểm: o Nếu dịch vụ Payments gặp sự cố, các dịch vụ Accounts và Loans vẫn hoạt động bình thường.

Tình huống 2: Nền tảng thương mại điện tử

Nền tảng thương mại điện tử cung cấp các dịch vụ chuyên biệt cho giỏ hàng, thanh toán và quản lý sản phẩm Dịch vụ giỏ hàng được thiết kế linh hoạt, có khả năng mở rộng để đáp ứng nhu cầu cao trong ngày Black Friday mà không làm gián đoạn dịch vụ thanh toán.

 Ưu điểm: o Khả năng mở rộng riêng lẻ từng dịch vụ (horizontal scaling).

Tình huống 3: Ứng dụng streaming video

Ứng dụng được chia thành các dịch vụ riêng biệt như tải video lên, xử lý video và phát trực tiếp Trong trường hợp dịch vụ phát trực tiếp gặp sự cố, người dùng vẫn có thể tiếp tục tải video lên mà không bị ảnh hưởng.

 Ưu điểm: o Tăng tính chịu lỗi và linh hoạt trong việc nâng cấp dịch vụ.

4 Lợi ích của Microservices a Linh hoạt và khả năng mở rộng

 Dễ dàng mở rộng dịch vụ nào cần thiết mà không làm tăng tải cho các thành phần khác. b Phát triển và triển khai độc lập

 Các đội nhóm có thể làm việc trên các dịch vụ khác nhau mà không gây xung đột. c Tính chịu lỗi cao

 Nếu một dịch vụ bị lỗi, hệ thống tổng thể vẫn có thể hoạt động bình thường. d Sử dụng công nghệ phù hợp

 Mỗi dịch vụ có thể sử dụng ngôn ngữ lập trình hoặc công nghệ riêng mà không cần đồng bộ với toàn bộ hệ thống.

 Độ phức tạp cao: Quản lý và giám sát nhiều dịch vụ là một thách thức.

 Bảo mật: Các dịch vụ giao tiếp qua mạng cần được bảo vệ.

 Chi phí hạ tầng: Yêu cầu tài nguyên lớn hơn so với kiến trúc Monolith.

Tại sao nên sử dụng Spring Boot cho Microservices

1 Lợi ích của Spring Boot trong phát triển Microservices a Tích hợp nhiều tính năng sẵn có (Built-in features)

 Tính năng: o Cấu hình tự động (Auto-configuration). o Dependency injection. o Hỗ trợ nhiều nền tảng đám mây (Cloud platforms).

Spring Boot giúp tiết kiệm thời gian trong việc thiết lập nhanh chóng một microservice mới bằng cách tự động cấu hình các thành phần cần thiết như cơ sở dữ liệu và API Ngoài ra, Spring Boot còn hỗ trợ máy chủ tích hợp, giúp đơn giản hóa quá trình phát triển và triển khai ứng dụng.

 Tính năng: o Tích hợp sẵn Tomcat, Jetty, hoặc Undertow. o Có thể chạy trực tiếp mà không cần cài đặt máy chủ riêng.

Một công ty muốn triển khai nhanh dịch vụ trên container Docker có thể dễ dàng thực hiện với Spring Boot, chỉ cần đóng gói JAR và chạy mà không cần cấu hình máy chủ web Spring Boot cung cấp các tính năng sẵn sàng cho môi trường sản xuất, giúp tối ưu hóa quy trình triển khai và quản lý ứng dụng.

 Tính năng: o Cung cấp sẵn các công cụ kiểm tra sức khỏe dịch vụ (health checks), cấu hình bên ngoài (externalized configuration), và metrics.

Trong hệ thống thương mại điện tử, Spring Boot đóng vai trò quan trọng trong việc tự động giám sát hiệu suất và báo lỗi khi dịch vụ gặp tình trạng quá tải, giúp nâng cao trải nghiệm người dùng Ngoài ra, Spring Boot cũng hỗ trợ khởi tạo nhanh dự án, tiết kiệm thời gian và công sức cho các nhà phát triển.

 Tính năng: o Cung cấp các starter dependencies để cấu hình các thành phần như cơ sở dữ liệu và hàng đợi tin nhắn (queues).

Khi phát triển dịch vụ xử lý thanh toán, việc sử dụng Spring Boot Starter giúp dễ dàng cấu hình kết nối với cơ sở dữ liệu và RabbitMQ, từ đó tối ưu hóa quy trình xử lý Công nghệ này đặc biệt phù hợp cho phát triển ứng dụng Cloud-native, mang lại hiệu suất và tính linh hoạt cao.

 Tính năng: o Tích hợp tốt với Kubernetes, hỗ trợ containerization, và triển khai dễ dàng lên các nhà cung cấp đám mây như AWS, Google Cloud, hoặc Azure.

Một tổ chức sử dụng Kubernetes có thể thuận lợi đóng gói và triển khai dịch vụ Spring Boot dưới dạng container độc lập, giúp tối ưu hóa quy trình phát triển và quản lý ứng dụng.

2 Sự khác biệt giữa WAR và JAR a WAR (Web Application Archive - Cách tiếp cận truyền thống)

Ứng dụng cần được triển khai trên máy chủ bên ngoài như Tomcat hoặc Jetty, điều này đòi hỏi một quy trình thiết lập và vận hành gồm nhiều bước.

 Hạn chế: o Cấu hình phức tạp. o Phụ thuộc vào máy chủ bên ngoài. b JAR (Java Archive - Cách tiếp cận hiện đại)

 Đặc điểm: o Ứng dụng được đóng gói dưới dạng self-contained JAR (bao gồm cả ứng dụng, dependencies, và máy chủ tích hợp). o Không cần máy chủ bên ngoài.

 Ưu điểm: o Dễ triển khai trong container Docker hoặc trên đám mây. o Quản lý độc lập từng dịch vụ mà không ảnh hưởng đến hệ thống chung.

3 Tình huống ứng dụng thực tế

Tình huống 1: Phát triển dịch vụ trong ngân hàng

 Mô tả: o Ngân hàng muốn triển khai các microservices cho Accounts, Loans, và Payments. o Sử dụng Spring Boot:

 Embedded Tomcat giúp dịch vụ chạy độc lập.

 Các starter dependencies giúp cấu hình nhanh cơ sở dữ liệu và API REST.

 Kết quả: o Tiết kiệm thời gian triển khai. o Mỗi dịch vụ có thể được giám sát riêng biệt với metrics tích hợp.

REST Services là gì?

REST (Representational State Transfer) is a widely used architecture for communication between web systems It enables clients to access server functions through callable endpoints Data is typically exchanged in JSON or XML formats.

2 Các trường hợp sử dụng REST Services a Giao tiếp giữa Mobile App và Backend Server

Ứng dụng di động gửi yêu cầu REST đến máy chủ backend để truy xuất dữ liệu hoặc thực hiện các thao tác cần thiết, chẳng hạn như lấy thông tin tài khoản người dùng và lịch sử giao dịch.

Backend giúp giảm tải cho ứng dụng frontend bằng cách xử lý các logic phức tạp và gửi dữ liệu phù hợp về ứng dụng di động, đồng thời đảm bảo giao tiếp hiệu quả giữa các máy chủ backend.

Các máy chủ backend giao tiếp thông qua REST API để chia sẻ dữ liệu và xử lý yêu cầu Ví dụ, một dịch vụ thanh toán cần sử dụng REST API từ dịch vụ tài khoản để xác minh số dư.

 Ưu điểm: o Tăng tính module hóa của hệ thống. o Cho phép mở rộng dịch vụ dễ dàng. c Giao tiếp giữa Web App và Backend Server

Ứng dụng web được phát triển bằng Angular, React hoặc Vue.js sử dụng REST API để hiển thị dữ liệu trên giao diện người dùng Chẳng hạn, bảng điều khiển của quản trị viên sẽ tải thông tin người dùng từ REST API để cung cấp cái nhìn tổng quan và quản lý hiệu quả.

 Ưu điểm: o Tăng tốc độ tải trang vì dữ liệu được tải động. o Backend xử lý logic và chỉ gửi dữ liệu cần thiết.

3 Các tiêu chuẩn cần tuân thủ khi triển khai REST Services a Hỗ trợ CRUD Operations

 HTTP Methods cho CRUD: o Create: Sử dụng POST. o Read: Sử dụng GET. o Update: Sử dụng PUT hoặc PATCH. o Delete: Sử dụng DELETE.

 POST /users: Tạo người dùng mới.

 GET /users/1: Lấy thông tin người dùng với ID 1.

 PUT /users/1: Cập nhật thông tin người dùng với ID 1.

 DELETE /users/1: Xóa người dùng với ID 1. b Xử lý và xác thực đầu vào (Input validation & exception handling)

REST services must validate input data and handle exceptions, whether they are runtime or business-related It is essential to provide clear error messages to the client to ensure effective communication and troubleshooting.

When a user sends a POST request to /users without including the email field, the server responds with a 400 Bad Request error, indicating that the email field is missing This highlights the importance of proper documentation for REST services to ensure users understand the required fields for successful requests.

Sử dụng các công cụ như Swagger hoặc OpenAPI Specification để tài liệu hóa REST API giúp các nhà phát triển và client hiểu rõ cách sử dụng API một cách hiệu quả.

 Ví dụ: o API /products có thể được mô tả bằng Swagger, bao gồm:

 Các tham số đầu vào (query parameters, body, headers).

 Các mã trạng thái trả về (200, 400, 404, 500).

Các Annotation chính

Annotation @RestController trong Java được sử dụng để đánh dấu một lớp như một REST Controller, kết hợp chức năng của @Controller và @ResponseBody Điều này cho phép lớp tự động trả về dữ liệu dưới dạng JSON hoặc XML mà không cần cấu hình bổ sung.

Chức năng của annotation này được áp dụng cho phương thức hoặc lớp, cho phép giá trị trả về tự động được chuyển đổi thành định dạng JSON hoặc XML trong phản hồi HTTP Annotation này thường được sử dụng kết hợp với @Controller, không phải với @RestController.

Chức năng của việc đánh dấu một lớp là cung cấp xử lý toàn cục cho các lỗi hoặc ngoại lệ xảy ra trong ứng dụng, thường được kết hợp với @ExceptionHandler để quản lý lỗi hiệu quả.

Chức năng của @RequestHeader là lấy thông tin từ phần header của HTTP Request, trong khi @RequestBody được sử dụng để lấy dữ liệu từ body của HTTP Request và ánh xạ nó vào một đối tượng Java.

 Chức năng: o Tạo HTTP Response với body, headers, và status code tùy chỉnh.

 Chức năng: o Nhận HTTP Request bao gồm body, headers, và các thông tin khác.

Các annotation và class trong Spring Boot giúp đơn giản hóa việc phát triển REST API:

 @RestController và @ResponseBody: Tạo các endpoint trả về JSON/XML dễ dàng.

 @ControllerAdvice và @ExceptionHandler: Quản lý lỗi toàn cục hiệu quả.

 ResponseEntity và RequestEntity: Quản lý thông tin yêu cầu và phản hồi HTTP linh hoạt

Domain-Driven Sizing

Xây dựng microservices theo nhu cầu kinh doanh và áp dụng thiết kế hướng miền (Domain-Driven Design - DDD) là một phương pháp hiệu quả Các microservices được xác định dựa trên các khả năng kinh doanh, đảm bảo sự liên kết chặt chẽ với từng miền cụ thể.

Thách thức trong việc áp dụng kiến thức chuyên sâu về miền nghiệp vụ là điều không thể tránh khỏi, bởi vì quá trình này thường yêu cầu phân tích chi tiết và có thể tiêu tốn nhiều thời gian.

 Tình huống 1: Hệ thống ngân hàng o Miền nghiệp vụ:

 Quản lý tài khoản: Lưu giữ thông tin tài khoản, số dư.

 Thanh toán: Xử lý giao dịch giữa các tài khoản.

 Khoản vay: Theo dõi và quản lý các khoản vay. o Giải pháp:

 Mỗi miền (Accounts, Payments, Loans) trở thành một microservice độc lập. o Kết quả:

 Tăng khả năng chịu lỗi, nếu dịch vụ thanh toán gặp lỗi, dịch vụ quản lý tài khoản vẫn hoạt động.

 Tình huống 2: Nền tảng thương mại điện tử o Miền nghiệp vụ:

 Quản lý sản phẩm: Theo dõi thông tin sản phẩm.

 Giỏ hàng: Quản lý các sản phẩm được thêm vào giỏ.

 Thanh toán: Xử lý giao dịch thanh toán. o Giải pháp:

 Chia hệ thống thành các microservices tương ứng với các miền nghiệp vụ. o Kết quả:

 Linh hoạt trong việc mở rộng tính năng riêng lẻ, ví dụ thêm phương thức thanh toán mới.

2 Event Storming Sizing Đặc điểm:

Phương pháp tiếp cận dựa trên sự kiện cho phép các bên liên quan tham gia vào một phiên họp nhằm xác định các sự kiện chính trong hệ thống Những sự kiện như "Hoàn tất thanh toán" và "Tìm kiếm sản phẩm" được nhóm lại để hình thành các dịch vụ dựa trên miền, tạo ra một cách tiếp cận có tổ chức và hiệu quả cho việc phát triển dịch vụ.

Quy trình tương tác nhanh chóng giúp xác định các yêu cầu nghiệp vụ một cách hiệu quả, đồng thời tạo điều kiện cho các bên liên quan hiểu rõ hơn về cách hoạt động của hệ thống Những ưu điểm này không chỉ nâng cao sự minh bạch mà còn tối ưu hóa quy trình làm việc trong các ứng dụng thực tế.

 Tình huống 1: Quản lý giao hàng o Sự kiện:

 Order Placed (Đặt hàng thành công).

 Package Shipped (Gói hàng được vận chuyển).

 Package Delivered (Gói hàng được giao). o Giải pháp:

 Tạo các dịch vụ riêng như Order Service, Shipping Service, và Delivery Service dựa trên các sự kiện. o Kết quả:

 Dịch vụ vận chuyển có thể hoạt động độc lập mà không cần chờ dịch vụ đặt hàng hoàn thành.

3 So sánh hai phương pháp

Tiêu chí Domain-Driven Sizing Event Storming Sizing

Dựa trên phân tích miền nghiệp vụ và khả năng kinh doanh.

Dựa trên các sự kiện chính trong hệ thống.

Thời gian thực hiện có thể kéo dài do yêu cầu phân tích chi tiết, nhưng có thể rút ngắn bằng cách tập trung vào các sự kiện chính Độ phức tạp của hệ thống đòi hỏi sự hiểu biết sâu sắc về lĩnh vực nghiệp vụ, phù hợp với các nhóm đa lĩnh vực Ứng dụng của hệ thống cần có cấu trúc nghiệp vụ rõ ràng và khả năng xử lý nhiều sự kiện tương tác lẫn nhau.

 Domain-Driven Sizing: Phù hợp với các hệ thống có miền nghiệp vụ phức tạp, cần sự linh hoạt trong quản lý nghiệp vụ.

Event Storming Sizing là phương pháp hữu ích để xác định nhanh chóng các dịch vụ dựa trên sự kiện Phương pháp này đặc biệt phù hợp khi nhóm phát triển cần tổ chức các cuộc thảo luận trực tiếp với các bên liên quan, nhằm tối ưu hóa quy trình làm việc và nâng cao hiệu quả trong việc phát triển sản phẩm.

Migration từ Monolithic sang Microservices

1 Kiến trúc Monolithic (Ban đầu)

Toàn bộ ứng dụng hoạt động như một khối duy nhất, bao gồm các module quan trọng như: quản lý người dùng và xác thực trong module Identity, danh mục sản phẩm trong module Catalog, quản lý đơn hàng qua module Orders, xuất hóa đơn với module Invoices, và phân tích bán hàng cùng chiến lược tiếp thị trong module Sales & Marketing.

 Relational Database (CSDL quan hệ) lưu trữ dữ liệu chung cho tất cả các module. Ưu điểm (giai đoạn đầu):

 Đơn giản hóa: Phát triển và triển khai nhanh khi nhóm nhỏ và khối lượng công việc ít.

 Tích hợp: Tất cả các module hoạt động trên cùng một codebase, dễ quản lý khi khối lượng nhỏ.

Nhược điểm (khi hệ thống mở rộng):

Hệ thống ngày càng trở nên phức tạp, khiến cho cá nhân khó có thể nắm bắt toàn bộ thông tin Sự thay đổi nhỏ trong cấu trúc có thể dẫn đến những lỗi nghiêm trọng, ảnh hưởng đến toàn bộ hệ thống.

Triển khai một ứng dụng mới đòi hỏi tốn kém thời gian và tài nguyên, vì cần phải xây dựng lại toàn bộ hệ thống Việc thêm tính năng hoặc sửa lỗi cũng trở nên khó khăn và chậm chạp, gây ảnh hưởng đến hiệu suất và tiến độ phát triển.

3 Mất tính ổn định: o Một module gặp lỗi (vd: Orders) có thể làm cả hệ thống ngừng hoạt động.

4 Không linh hoạt: o Khó áp dụng công nghệ mới hoặc thay đổi nhanh theo yêu cầu kinh doanh.

2 Kiến trúc Microservices (Sau khi chuyển đổi)

Ứng dụng được thiết kế theo kiến trúc microservices độc lập, mỗi service đảm nhận một chức năng cụ thể Microservice Xác thực Người dùng sử dụng RDBMS để quản lý thông tin người dùng, trong khi Microservice Quản lý Danh mục Sản phẩm cũng dựa vào RDBMS để tổ chức danh mục sản phẩm Microservice Xử lý Đơn hàng và Microservice Tạo Hóa đơn sử dụng MongoDB để quản lý quy trình đặt hàng và tạo hóa đơn Cuối cùng, các Microservices Bán hàng & Tiếp thị sử dụng Redis để lưu trữ dữ liệu cache nhanh, tối ưu hóa hiệu suất ứng dụng.

 API Gateway: o Là điểm giao tiếp duy nhất giữa các ứng dụng khách (Client Apps) và microservices. o Hỗ trợ điều hướng yêu cầu đến đúng microservice.

 Event Bus: o Cho phép các microservices giao tiếp không đồng bộ (async) thông qua cơ chế messaging. Ưu điểm:

1 Tăng hiệu quả và ổn định: o Một dịch vụ có thể được triển khai, sửa lỗi, hoặc nâng cấp mà không ảnh hưởng đến các dịch vụ khác.

2 Khả năng mở rộng: o Các microservices có thể mở rộng độc lập dựa trên nhu cầu (vd: Catalog Service có thể mở rộng nhanh hơn Order Service).

3 Linh hoạt công nghệ: o Mỗi dịch vụ có thể sử dụng công nghệ hoặc cơ sở dữ liệu phù hợp (vd: MongoDB cho Orders, Redis cho Marketing).

4 Phát triển nhanh: o Nhiều nhóm có thể làm việc song song trên các microservices khác nhau.

3 Tình huống ứng dụng thực tế

Tình huống 1: Sàn thương mại điện tử

Khi hệ thống monolithic mở rộng để phục vụ hàng triệu người dùng và sản phẩm, việc tích hợp các module mới, chẳng hạn như phương thức thanh toán PayPal, có thể gây ra gián đoạn cho toàn bộ hệ thống.

 Giải pháp: o Tách các module thành microservices như Catalog, Orders, và Payment, cho phép mỗi module phát triển độc lập.

 Kết quả: o Tích hợp phương thức thanh toán mới nhanh chóng mà không làm gián đoạn hoạt động hệ thống.

Tình huống 2: Dịch vụ đặt vé trực tuyến

 Vấn đề với Monolithic: o Lượng người dùng tăng đột biến vào giờ cao điểm khiến toàn bộ hệ thống ngừng hoạt động.

 Giải pháp: o Tách các chức năng thành microservices như Ticketing, Payment, và Notification.

Mở rộng độc lập microservice xử lý vé.

 Kết quả: o Hệ thống hoạt động ổn định, ngay cả khi lưu lượng tăng cao.

Tình huống 3: Ngân hàng trực tuyến

 Vấn đề với Monolithic: o Quá trình xử lý báo cáo và giao dịch gây nghẽn hệ thống.

 Giải pháp: o Tách Transaction Service và Report Service thành các microservices độc lập, xử lý giao dịch và báo cáo không đồng bộ thông qua Event Bus.

 Kết quả: o Giảm thời gian chờ xử lý và tăng trải nghiệm khách hàng.

Chuyển đổi từ kiến trúc Monolithic sang Microservices mang lại:

 Sự linh hoạt: Tăng khả năng mở rộng và tích hợp công nghệ mới.

 Sự ổn định: Giảm tác động của lỗi từ một phần nhỏ lên toàn bộ hệ thống.

 Sự hiệu quả: Phát triển và triển khai nhanh chóng hơn.

Microservices: Deployment, Portability, và Scalability, đồng thời đề xuất Containerization

1 Các thách thức chính a Deployment (Triển khai)

Để triển khai hàng trăm microservices với chi phí và công sức thấp, cần có giải pháp quản lý tập trung và tự động hóa Khi số lượng microservices gia tăng, việc triển khai trở nên phức tạp hơn, đòi hỏi các công cụ và quy trình hiệu quả để giảm thiểu rủi ro và tối ưu hóa tài nguyên.

 Ứng dụng thực tế: o Công ty SaaS:

 Ví dụ: Zoom, nơi cần triển khai nhiều tính năng độc lập như ghi âm, gọi video, và chia sẻ màn hình.

 Giải pháp: Sử dụng CI/CD pipelines tự động hóa quá trình build và deploy microservices bằng Docker và Kubernetes. o Thương mại điện tử:

 Amazon triển khai riêng lẻ từng microservice như thanh toán, tìm kiếm, và quản lý sản phẩm.

 Mỗi dịch vụ có thể cập nhật mà không ảnh hưởng đến hệ thống chung. b Portability (Khả năng di động)

Để di chuyển microservices giữa các môi trường như local, staging và production một cách hiệu quả với chi phí và cấu hình tối ưu, cần áp dụng các phương pháp quản lý và tự động hóa Điều này không chỉ giúp tiết kiệm thời gian mà còn đảm bảo microservices hoạt động mượt mà trên các nền tảng đám mây như AWS, Azure và Google Cloud Việc sử dụng công cụ container hóa như Docker và orchestration như Kubernetes có thể giúp đơn giản hóa quy trình triển khai và quản lý microservices trên nhiều môi trường khác nhau.

 Ứng dụng thực tế: o Ngành tài chính:

 Các ngân hàng sử dụng microservices để chạy trên cả môi trường tại chỗ (on-premises) lẫn đám mây (cloud) nhằm đảm bảo tuân thủ quy định.

 Docker containers cho phép đóng gói ứng dụng và chạy nhất quán bất kể hạ tầng. o Ứng dụng DevOps:

Jenkins và GitLab CI/CD sử dụng Docker containers để xây dựng ứng dụng trên nhiều nền tảng mà không gặp phải vấn đề về phụ thuộc môi trường, giúp đảm bảo tính nhất quán trong quá trình phát triển Khả năng mở rộng của hệ thống cũng được cải thiện, cho phép dễ dàng điều chỉnh quy mô và hiệu suất khi cần thiết.

Để mở rộng ứng dụng theo nhu cầu với chi phí và công sức tối thiểu, cần áp dụng các giải pháp linh hoạt giúp scale up hoặc scale down hiệu quả Đồng thời, việc đảm bảo dịch vụ luôn có khả năng đáp ứng lưu lượng người dùng tăng đột biến là điều quan trọng để duy trì trải nghiệm người dùng mượt mà.

 Ứng dụng thực tế: o Ngày lễ lớn (Black Friday):

 Hệ thống thương mại điện tử cần mở rộng dịch vụ thanh toán và xử lý đơn hàng để đáp ứng lưu lượng truy cập tăng gấp 10 lần.

 Giải pháp: Kubernetes tự động scale các container của dịch vụ thanh toán. o Streaming media (Netflix):

 Netflix sử dụng Docker và Kubernetes để mở rộng các microservices như đề xuất phim hoặc streaming media dựa trên lưu lượng của từng khu vực địa lý.

Docker Compose là gì?

Docker Compose là công cụ do Docker cung cấp, cho phép định nghĩa và quản lý các ứng dụng đa container một cách hiệu quả Nó sử dụng file YAML để mô tả các container, mạng, và volume cần thiết cho ứng dụng, từ đó giúp cấu hình mối quan hệ giữa các container Nhờ vào Docker Compose, việc quản lý môi trường ứng dụng phức tạp trở nên dễ dàng hơn.

Tập trung các thông số cấu hình trong một file YAML duy nhất giúp quản lý dễ dàng hơn Điều này không chỉ đơn giản hóa việc triển khai các container liên quan như frontend, backend và database mà còn tối ưu hóa quy trình phát triển và vận hành ứng dụng.

2 Vì sao không nên sử dụng CLI cho nhiều container?

Docker CLI có một số hạn chế đáng chú ý Đầu tiên, việc quản lý nhiều container thông qua dòng lệnh có thể trở nên phức tạp và dễ dẫn đến lỗi Thứ hai, các câu lệnh thường dài, khó đọc và khó hiểu, đặc biệt khi làm việc trong nhóm Cuối cùng, việc kiểm soát phiên bản hoặc chia sẻ cấu hình container trong các dự án cũng gặp nhiều khó khăn.

3 Lợi ích của Docker Compose

 Quản lý toàn bộ hệ thống với một lệnh: o Có thể sử dụng một lệnh đơn giản như docker-compose up để khởi chạy toàn bộ container.

 Tự động điều phối và kết nối: o Docker Compose xử lý việc điều phối và kết nối mạng giữa các container.

 Kiểm soát vòng đời ứng dụng: o Hỗ trợ scale số lượng container dễ dàng, quản lý phụ thuộc và vòng đời ứng dụng.

Lựa chọn lý tưởng cho việc phát triển và triển khai là tối ưu hóa cho môi trường đa container, bao gồm các dịch vụ liên quan như microservices, cơ sở dữ liệu và bộ nhớ đệm.

Tình huống ứng dụng thực tế

An e-commerce application requires essential services including a frontend developed with React or Angular, a backend utilizing microservices built with Node.js or Spring Boot, and a database system that incorporates MySQL or PostgreSQL alongside Redis for caching.

 Giải pháp: o Sử dụng Docker Compose để định nghĩa tất cả container trong một file YAML. o Chỉ cần lệnh docker-compose up để khởi chạy toàn bộ hệ thống.

Định nghĩa ứng dụng Cloud Native

Ứng dụng Cloud Native được thiết kế nhằm khai thác tối đa tiềm năng của môi trường điện toán đám mây Chúng mang lại tính linh hoạt và khả năng mở rộng cao, thường áp dụng các công nghệ như microservices, containers và dịch vụ quản lý đám mây.

2 Đặc điểm chính của Cloud Native:

Microservices là kiến trúc phân mảnh thành các dịch vụ nhỏ độc lập, cho phép phát triển và triển khai linh hoạt hơn Ví dụ điển hình là một hệ thống e-commerce, trong đó các microservices được thiết kế riêng biệt cho các chức năng như thanh toán, quản lý đơn hàng và danh mục sản phẩm.

Sử dụng Docker để đóng gói ứng dụng cùng với tất cả các dependencies giúp đảm bảo tính nhất quán khi triển khai Điều này cho phép chạy ứng dụng trên nhiều môi trường khác nhau mà không cần phải cấu hình lại, tiết kiệm thời gian và giảm thiểu lỗi.

Scalability và Elasticity cho phép tự động điều chỉnh tài nguyên theo nhu cầu sử dụng Ví dụ, trong mùa thi, nền tảng học trực tuyến có khả năng mở rộng để phục vụ hàng nghìn người dùng cùng lúc, đảm bảo hiệu suất và trải nghiệm người dùng tối ưu.

Độ bền và khả năng chịu lỗi là yếu tố quan trọng giúp đảm bảo hoạt động liên tục của hệ thống, ngay cả khi một phần của nó gặp sự cố Một ví dụ điển hình là trong hệ thống ngân hàng, nơi mà các giao dịch vẫn được thực hiện một cách suôn sẻ, bất chấp việc một máy chủ có thể bị lỗi.

Áp dụng các thực hành DevOps, đặc biệt là CI/CD, giúp tự động hóa quy trình triển khai và phát triển phần mềm Việc này không chỉ tối ưu hóa hiệu suất mà còn đẩy nhanh vòng đời phát triển phần mềm tại các công ty công nghệ, mang lại lợi ích rõ rệt cho việc cải tiến sản phẩm và đáp ứng nhanh chóng nhu cầu thị trường.

3 Khác biệt giữa ứng dụng Cloud Native và ứng dụng truyền thống:

Ứng dụng Cloud Native mang lại sự ổn định cao hơn, khả năng mở rộng dễ dàng và sử dụng trừu tượng hóa hệ điều hành thay vì phụ thuộc vào một hệ điều hành cụ thể Chẳng hạn, các công ty SaaS như Zoom đã áp dụng nền tảng cloud-native để phục vụ hàng triệu người dùng trên toàn cầu.

4 Nguyên tắc phát triển Cloud Native: 12-Factor & Beyond:

Các nguyên tắc này nhấn mạnh việc triển khai linh hoạt trên nền tảng đám mây, khả năng mở rộng và sự nhanh nhẹn trong phát triển Ứng dụng thực tiễn của những nguyên tắc này được thể hiện rõ qua phần mềm tài chính FinTech, giúp giảm thiểu thời gian triển khai và nhanh chóng thích ứng với những thay đổi của thị trường.

Quản lý cấu hình trong Microservices

Thách thức quản lý cấu hình trong Microservices

Separating configurations from the source code of microservices allows the same Docker image to be deployed across various environments, such as Development, Staging, and Production It is essential to avoid hard-coding configurations within the application to ensure flexibility and adaptability in different deployment scenarios.

Khi khởi động microservice, việc chèn các cấu hình như thông tin kết nối cơ sở dữ liệu, secret keys và API URLs là rất quan trọng Để đảm bảo an toàn, cần thiết phải có một cơ chế truyền thông tin môi trường một cách bảo mật.

To effectively maintain configurations and properties in a centralized repository while supporting versioning and change history, it is essential to ensure that configurations are easily updatable and synchronized across multiple microservices This approach facilitates streamlined management and enhances operational efficiency within the system.

Các giải pháp được đề xuất

Configuring Spring Boot involves utilizing configuration files such as application.properties or application.yml Profiles are essential for setting up different environments, with specific files like application-dev.properties and application-prod.properties tailored for development and production, respectively This approach enhances flexibility and organization in managing application settings.

 Dễ dàng triển khai với các dự án nhỏ.

 Hỗ trợ tích hợp nhanh trong Spring Boot.

2 Applying External Configuration with Spring Boot: o Thay vì lưu cấu hình trong mã nguồn, Spring Boot hỗ trợ đọc từ Environment

Variables, System Properties, hoặc External Config Files. o Ưu điểm:

 Tăng tính bảo mật khi không lưu trực tiếp các giá trị nhạy cảm trong mã nguồn.

 Dễ dàng tích hợp với hệ thống CI/CD.

Spring Cloud Config Server là một giải pháp quản lý cấu hình tập trung, cho phép lưu trữ cấu hình trong Git hoặc các hệ thống tương tự Nó hỗ trợ tính năng làm mới động, giúp ứng dụng tự động cập nhật khi có thay đổi trong cấu hình.

1 Triển khai dịch vụ thanh toán (Payment Service): o Separation: Tách cấu hình của Payment Service (URL API bên thứ ba, thông tin

To manage OAuth configurations effectively, store settings in the application.properties file Utilize environment variables (ENV) in Docker or Kubernetes to inject specific values Additionally, maintain all configurations in a Git Repository and leverage Spring Cloud Config for seamless management.

Server để quản lý tập trung.

Dự án thương mại điện tử (E-commerce) sử dụng kiến trúc microservices, trong đó mỗi microservice như Catalog, Order, và Inventory có khả năng đọc cấu hình từ Config Server Config Server đóng vai trò quan trọng trong việc quản lý các giá trị thiết yếu như đường dẫn cơ sở dữ liệu, URL của Redis Cache, và thông tin kết nối với Kafka.

3 Ứng dụng SaaS đa khách hàng (Multi-tenant SaaS): o Config Server quản lý cấu hình cho từng tenant dựa trên thông số khách hàng. o Ví dụ:

 Tenant A dùng cơ sở dữ liệu PostgreSQL với thông số kết nối DB_TENANT_A.

 Tenant B dùng MongoDB với thông số kết nối riêng. Ưu điểm của cách tiếp cận này

 Bảo mật: Các giá trị nhạy cảm như API keys hoặc database passwords không được lưu trữ trong mã nguồn.

 Tính mô-đun: Hỗ trợ triển khai dễ dàng trên nhiều môi trường khác nhau mà không cần chỉnh sửa mã nguồn.

 Quản lý dễ dàng: Dùng Config Server giúp quản lý tập trung và theo dõi lịch sử thay đổi

So sánh cách xử lý cấu hình trong Traditional Apps và Microservices

Routing và Cross-cutting Concerns trong Microservices

Trong một hệ thống microservices, thách thức lớn nhất là duy trì một điểm truy cập duy nhất, vì các client cần biết URL của từng dịch vụ riêng lẻ, điều này gây khó khăn khi kiến trúc hệ thống thay đổi Bên cạnh đó, việc xử lý các vấn đề chung như bảo mật, logging, tracing và auditing cần được thực hiện đồng nhất trên toàn bộ hệ thống Cuối cùng, việc định tuyến tùy chỉnh dựa trên các điều kiện khác nhau như HTTP header và tham số request cũng cần được xử lý một cách linh hoạt và động.

 Giải pháp: Sử dụng Edge Server/API Gateway o Tích hợp các chức năng như:

 Định tuyến các yêu cầu của client đến service phù hợp.

 Triển khai chính sách retry và timeout.

 Quản lý lưu lượng truy cập vào hệ thống (ingress traffic).

 Hỗ trợ bảo mật bằng cách cung cấp token đến các service downstream.

2 Vai trò của Edge Server/API Gateway

API Gateway giúp ngăn chặn lỗi lan truyền bằng cách thực hiện cơ chế retry hoặc trả về phản hồi mặc định khi một service downstream không hoạt động.

API Gateway đóng vai trò quan trọng trong việc thực thi chính sách bảo mật, hoạt động như một lớp bảo vệ giúp kiểm tra xác thực và phân quyền trước khi chuyển yêu cầu đến các dịch vụ.

 Tăng hiệu suất: o Lưu cache dữ liệu hoặc thực hiện routing động để giảm độ trễ.

Tình huống ứng dụng thực tế

1 E-commerce Platform: o Trong một nền tảng thương mại điện tử có các microservices như "quản lý sản phẩm", "giỏ hàng", "thanh toán":

 API Gateway sẽ định tuyến các yêu cầu như add-to-cart đến service giỏ hàng, hoặc checkout đến service thanh toán.

 Thực thi xác thực khi người dùng truy cập trang quản lý tài khoản.

2 Hệ thống ngân hàng trực tuyến: o Các dịch vụ như "quản lý tài khoản", "giao dịch", "báo cáo":

 API Gateway sẽ quản lý token truy cập, đảm bảo chỉ người dùng hợp lệ được gửi yêu cầu đến các service này.

 Logging các yêu cầu để theo dõi audit trail.

Kiến thức chi tiết từ hình ảnh: Nhiệm vụ của API Gateway

API Gateway là thành phần thiết yếu trong kiến trúc microservices, hoạt động như cổng trung gian giữa các client như web, mobile và các microservices Nó thực hiện nhiều nhiệm vụ quan trọng, bao gồm quản lý lưu lượng, bảo mật, và tối ưu hóa hiệu suất cho các dịch vụ.

1 Request Validation (Xác thực yêu cầu)

Kiểm tra tính hợp lệ của yêu cầu từ client là rất quan trọng, bao gồm việc xác minh xem header có đầy đủ thông tin cần thiết hay không và dữ liệu trong request có tuân thủ định dạng quy định hay không.

2 Include & Exclude List (Danh sách cho phép/chặn)

 Xác định những yêu cầu nào được phép đi qua API Gateway và những yêu cầu nào bị từ chối.

3 Authentication & Authorization (Xác thực và Phân quyền)

 Authentication: Xác minh danh tính của người dùng, thường bằng token JWT, OAuth2.

 Authorization: Kiểm tra quyền hạn của người dùng đối với tài nguyên cụ thể.

4 Rate Limit (Giới hạn tần suất truy cập)

 Hạn chế số lượng yêu cầu từ một client trong một khoảng thời gian nhất định để ngăn ngừa quá tải hoặc các cuộc tấn công DDoS.

5 Dynamic Routing (Định tuyến động)

 Định tuyến các yêu cầu từ client đến microservice phù hợp dựa trên các tiêu chí như URL, tham số, hoặc header.

6 Service Discovery (Khám phá dịch vụ)

 API Gateway sử dụng các công cụ như Eureka hoặc Consul để xác định địa chỉ IP động của các service.

7 Modify Request/Response (Chỉnh sửa yêu cầu/phản hồi)

 Điều chỉnh request trước khi gửi đến backend hoặc chỉnh sửa response từ backend trước khi trả về client.

8 Protocol Conversion (Chuyển đổi giao thức)

 Chuyển đổi giao thức giữa các client và backend, ví dụ: o HTTP thành WebSocket. o REST thành gRPC.

9 Exception Handling (Xử lý ngoại lệ)

 Quản lý lỗi phát sinh từ backend hoặc từ chính API Gateway, trả về thông báo lỗi chuẩn hóa cho client.

 Ngăn chặn các yêu cầu đến một service bị lỗi, giúp giảm tải và tránh lỗi lan rộng (cascading failures).

11 Logging & Monitoring (Ghi log và Giám sát)

 Ghi nhận thông tin về các yêu cầu và phản hồi để phân tích hiệu suất, sử dụng các công cụ như Grafana hoặc Kibana.

 Lưu trữ tạm thời dữ liệu response từ backend trong Redis hoặc các công cụ cache khác để tăng tốc độ phản hồi.

Spring Cloud Gateway là một công cụ mạnh mẽ giúp xây dựng API Gateway cho các ứng dụng Spring Boot Nó được tối ưu hóa để quản lý luồng yêu cầu từ client đến các microservice, đồng thời cung cấp tính năng định tuyến động, bảo mật, và thu thập thông tin logs cũng như metrics.

Key Points của Spring Cloud Gateway:

Spring Cloud Gateway đóng vai trò là cổng kiểm soát duy nhất, quản lý toàn bộ lưu lượng truy cập từ client đến các microservice Điều này cho phép client gửi yêu cầu chỉ đến Gateway mà không cần gọi trực tiếp vào URL của từng microservice, giúp đơn giản hóa quy trình giao tiếp và tăng cường bảo mật.

Thư viện dễ triển khai trong Spring Boot cho phép các nhà phát triển sử dụng chỉ với vài dòng code, giúp tiết kiệm thời gian và công sức Nó hoàn toàn phù hợp cho các ứng dụng được phát triển trên nền tảng Spring Framework.

Spring Cloud Gateway thực hiện việc chặn, phân tích và sửa đổi các yêu cầu trước khi chuyển đến microservice tương ứng, đồng thời hỗ trợ định tuyến dựa trên nhiều yếu tố khác nhau.

 Header chứa phiên bản API để định tuyến đến phiên bản phù hợp.

 Quản lý phiên sticky session nếu cần.

4 Ưu điểm so với Zuul: o Spring Cloud Gateway được xây dựng trên nền Spring Reactor và Spring WebFlux, đảm bảo:

 Non-blocking: Xử lý không đồng bộ, giảm tải cho hệ thống.

 Tích hợp dễ dàng với Eureka (service discovery).

 Circuit Breaker được tích hợp sẵn, ngăn ngừa lỗi lan rộng.

 Hiệu năng vượt trội so với Zuul.

5 Policy Enforcement Point (PEP): o Gateway hoạt động như một điểm kiểm soát chính sách, với các chức năng:

 Routing: Hỗ trợ định tuyến tĩnh và động.

 Security: Quản lý xác thực và phân quyền.

 Logging, Auditing, Metrics: Thu thập logs, giám sát và phân tích hiệu suất.

Spring Cloud Gateway Internal Architecture

Spring Cloud Gateway là một thành phần quan trọng trong kiến trúc microservices, hoạt động bằng cách xử lý yêu cầu từ client Nó thực hiện kiểm tra, lọc và định tuyến yêu cầu đến các microservices thích hợp, đồng thời nhận phản hồi từ các microservices và trả kết quả về cho client.

1 Clients: o Là các thiết bị hoặc ứng dụng gửi yêu cầu đến hệ thống thông qua Gateway. o Bao gồm: Web app, Mobile app, API client.

Xử lý Gateway Handler bắt đầu bằng việc kiểm tra xem yêu cầu có phù hợp với bất kỳ định tuyến nào đã được định nghĩa hay không Việc kiểm tra này dựa trên các điều kiện (Predicates) Nếu yêu cầu khớp với một định tuyến, Gateway sẽ tiếp tục xử lý thông qua các bước lọc (Filters).

Các điều kiện định tuyến, hay còn gọi là predicates, là những yếu tố được cấu hình trước mà một yêu cầu phải đáp ứng Chỉ khi tất cả các điều kiện này được thỏa mãn, yêu cầu mới được chấp nhận.

 Header chứa thông tin xác định API version.

 Path hoặc Query Parameters phù hợp.

4 Pre Filters: o Xử lý yêu cầu trước khi gửi đến microservice. o Ví dụ:

 Ghi logs thông tin yêu cầu.

 Chuyển đổi định dạng yêu cầu.

5 Microservices: o Nơi thực thi logic nghiệp vụ dựa trên yêu cầu đã qua Gateway. o Gateway chuyển yêu cầu từ client đến đúng microservice dựa trên cấu hình định tuyến.

6 Post Filters: o Xử lý phản hồi trước khi gửi lại client. o Ví dụ:

 Nén dữ liệu phản hồi.

 Xử lý lỗi từ microservice.

7 Response: o Phản hồi cuối cùng được trả về client sau khi qua các bộ lọc Post Filters.

Tình huống ứng dụng thực tế

 Client gửi yêu cầu xem chi tiết sản phẩm. o Gateway Logic:

 Kiểm tra token xác thực (Pre Filter).

 Định tuyến đến dịch vụ quản lý sản phẩm (Product Service).

 Ghi log thông tin phản hồi (Post Filter). o Ứng dụng:

 Đảm bảo client chỉ có quyền truy cập vào dữ liệu mà họ được phép xem.

2 Hệ thống Ngân hàng: o Scenario:

 Xử lý giao dịch giữa hai tài khoản. o Gateway Logic:

 Kiểm tra quyền truy cập của tài khoản (Predicates).

 Chuyển hướng yêu cầu đến Transaction Service.

 Thêm mã xác nhận giao dịch vào phản hồi (Post Filter). o Ứng dụng:

 Cải thiện bảo mật và giảm tải cho Transaction Service.

Tính resiliency trong kiến trúc microservices là yếu tố quan trọng giúp hệ thống linh hoạt xử lý lỗi và duy trì dịch vụ, ngay cả khi một phần của nó gặp sự cố Các thách thức liên quan đến tính resiliency cần được nhận diện và giải quyết để đảm bảo hiệu suất và độ tin cậy của hệ thống.

1 Tránh lỗi lan truyền (Cascading Failures)

Ý nghĩa của việc thiết kế hệ thống microservices là đảm bảo rằng một dịch vụ thất bại hoặc hoạt động chậm không ảnh hưởng đến toàn bộ hệ thống Khi các microservices giao tiếp với nhau, nếu một dịch vụ gặp sự cố, hệ thống cần phải duy trì hoạt động bình thường cho các phần còn lại.

Giải pháp cho việc quản lý lỗi trong hệ thống bao gồm hai mô hình quan trọng: Mô hình Circuit Breaker giúp ngăn chặn các yêu cầu đến dịch vụ bị lỗi, từ đó giảm thiểu nguy cơ quá tải cho toàn bộ hệ thống Mô hình Bulkhead tập trung vào việc phân vùng tài nguyên, nhằm giới hạn ảnh hưởng của lỗi trong một phân đoạn cụ thể, bảo vệ các phần khác của hệ thống khỏi bị ảnh hưởng.

Retry Pattern là gì?

Retry Pattern là một kỹ thuật được thiết lập để tự động thực hiện lại nhiều lần khi dịch vụ gặp lỗi tạm thời, giúp cải thiện tính ổn định và độ tin cậy của hệ thống Kỹ thuật này rất hữu ích trong các tình huống như kết nối mạng không ổn định hoặc khi dịch vụ bên ngoài gặp sự cố tạm thời Việc áp dụng Retry Pattern giúp giảm thiểu thời gian chết và cải thiện trải nghiệm người dùng.

 Mất kết nối mạng tạm thời.

 Lỗi dịch vụ mục tiêu có thể được giải quyết bằng cách thử lại.

 Tăng độ bền bỉ của hệ thống.

 Đảm bảo các yêu cầu có cơ hội hoàn thành khi dịch vụ phục hồi.

2 Các thành phần và yếu tố chính khi triển khai Retry Pattern trong microservices

 Retry Logic: o Quy định thời điểm và số lần cần thử lại một thao tác. o Quyết định dựa trên:

 Trạng thái phản hồi (Response status).

 Backoff Strategy: o Định nghĩa chiến lược trì hoãn giữa các lần retry để tránh làm quá tải hệ thống hoặc làm trầm trọng thêm lỗi. o Chiến lược phổ biến:

 Exponential Backoff: Tăng dần khoảng thời gian chờ giữa các lần retry, ví dụ: 1s → 2s → 4s.

 Circuit Breaker Integration: o Kết hợp Retry Pattern với Circuit Breaker để bảo vệ tài nguyên:

 Nếu retry thất bại nhiều lần liên tiếp, Circuit Breaker mở để ngăn các lần thử tiếp theo, giảm tải hệ thống.

Các thao tác idempotent đảm bảo rằng việc thực hiện lại sẽ không thay đổi trạng thái hệ thống, giúp ngăn ngừa các tác dụng phụ không mong muốn và tránh việc tạo ra dữ liệu trùng lặp.

3 Ví dụ và tình huống thực tế áp dụng Retry Pattern

 Vấn đề: o Hệ thống gửi email bị lỗi do mất kết nối mạng tạm thời với máy chủ SMTP.

 Giải pháp: o Triển khai Retry Pattern:

 Retry tối đa 3 lần, với khoảng thời gian chờ tăng dần (Exponential Backoff): 1 giây, 2 giây, 4 giây.

 Nếu vẫn thất bại, trả thông báo lỗi cho người dùng. o Tích hợp Circuit Breaker để tránh retry vô hạn khi lỗi do máy chủ SMTP.

Tình huống 2: Xác nhận thanh toán

 Vấn đề: o Microservice thanh toán (Payment) không phản hồi do quá tải tạm thời.

Để giải quyết vấn đề, hệ thống sẽ thử lại tối đa 5 lần với khoảng cách chờ 1 giây giữa mỗi lần Nếu lỗi vẫn tiếp tục xảy ra, Circuit Breaker sẽ được kích hoạt và hiển thị thông báo "Hệ thống đang bận, vui lòng thử lại sau" Đồng thời, cần đảm bảo rằng thao tác thanh toán là idempotent nhằm tránh việc bị trừ tiền nhiều lần.

Rate Limiter Pattern là gì?

Rate Limiter Pattern giới hạn số lượng yêu cầu (requests) mà một hệ thống có thể xử lý trong một khoảng thời gian nhất định.

 Khi không có Rate Limiter: o Hệ thống sẽ cố gắng xử lý tất cả các yêu cầu, dẫn đến:

 Quá tải tài nguyên (CPU, RAM, băng thông).

 Ảnh hưởng đến các dịch vụ khác do cạn kiệt tài nguyên.

 Nguy cơ bị tấn công DoS/DDoS (Denial of Service/Distributed Denial of Service).

Khi sử dụng Rate Limiter, hệ thống được bảo vệ hiệu quả bằng cách từ chối hoặc kiểm soát các yêu cầu vượt quá giới hạn, giúp duy trì tính công bằng và khả năng phục hồi cho toàn bộ hệ thống.

Cách hoạt động của Rate Limiter

1 Định nghĩa ngưỡng giới hạn (Rate Limit): o Ví dụ: Cho phép tối đa 100 requests/phút từ mỗi người dùng.

Khi vượt quá giới hạn, hệ thống sẽ trả về mã lỗi HTTP 429 (Quá nhiều yêu cầu) Đồng thời, người dùng sẽ bị đưa vào danh sách chặn tạm thời trong một khoảng thời gian nhất định.

Phân loại giới hạn có thể được thực hiện theo ba tiêu chí chính: Đầu tiên, theo địa chỉ IP, nhằm hạn chế số lượng yêu cầu từ một địa chỉ cụ thể Thứ hai, theo tài khoản người dùng, giới hạn số lần yêu cầu mà một tài khoản có thể thực hiện Cuối cùng, theo cấp độ dịch vụ hoặc tenant, với các gói dịch vụ cơ bản và nâng cao có mức giới hạn khác nhau.

Tình huống minh họa rõ ràng: Sử dụng vs Không sử dụng Rate Limiter

Tình huống 1: API thời tiết công cộng

Dịch vụ API thời tiết miễn phí cho phép người dùng gửi yêu cầu để nhận thông tin thời tiết theo thời gian thực, mang đến trải nghiệm tiện lợi và nhanh chóng.

 Không sử dụng Rate Limiter: o Người dùng hoặc bot có thể gửi hàng nghìn yêu cầu trong vài giây. o Kết quả:

 Hệ thống quá tải, các yêu cầu hợp lệ từ người dùng khác bị chậm hoặc không được xử lý.

 Nguy cơ bị tấn công DDoS tăng cao.

Để tối ưu hóa hiệu suất, chúng tôi áp dụng Rate Limiter, giới hạn mỗi người dùng tối đa 100 yêu cầu mỗi phút Khi số lượng yêu cầu vượt quá giới hạn này, hệ thống sẽ trả về mã HTTP 429 kèm thông báo: "Bạn đã vượt quá giới hạn, vui lòng thử lại sau."

 Hệ thống luôn sẵn sàng phục vụ người dùng hợp lệ.

 Giảm thiểu nguy cơ bị lạm dụng và tấn công.

Tình huống 2: Hệ thống đăng nhập

 Mô tả: o Một ứng dụng hỗ trợ người dùng đăng nhập vào tài khoản cá nhân. o Tin tặc cố gắng tấn công brute-force để đoán mật khẩu.

 Không sử dụng Rate Limiter: o Tin tặc có thể gửi hàng nghìn yêu cầu đăng nhập mỗi giây. o Kết quả:

 Hệ thống dễ bị xâm nhập nếu mật khẩu yếu.

 Tài nguyên hệ thống bị quá tải, ảnh hưởng đến các người dùng khác.

Sử dụng Rate Limiter để giới hạn mỗi địa chỉ IP chỉ được phép thử đăng nhập tối đa 5 lần trong vòng 10 phút Nếu vượt quá giới hạn này, hệ thống sẽ trả về mã HTTP 429 kèm thông báo: "Bạn đã nhập sai quá nhiều lần, vui lòng thử lại sau 10 phút."

 Ngăn chặn hiệu quả các cuộc tấn công brute-force.

 Bảo vệ tài nguyên hệ thống khỏi bị quá tải.

Observability và Monitoring trong kiến trúc Microservices.

1 Debugging a Problem in Microservices (Gỡ lỗi vấn đề trong Microservices)

Trong kiến trúc microservices, việc theo dõi yêu cầu qua nhiều dịch vụ và container khác nhau gây khó khăn trong việc xác định dịch vụ nào gặp lỗi Thách thức lớn nhất là thu thập và kết hợp tất cả các log từ nhiều dịch vụ vào một vị trí trung tâm, giúp người dùng dễ dàng tìm kiếm, lọc và nhóm lại thông tin để xác định nguyên nhân gây ra lỗi.

Khi người dùng gặp lỗi thanh toán trên website, yêu cầu thanh toán sẽ phải qua nhiều dịch vụ như dịch vụ thanh toán, dịch vụ xác thực và dịch vụ ngân hàng Để xác định nguyên nhân của vấn đề, cần thu thập log từ tất cả các dịch vụ này, chẳng hạn như lỗi kết nối giữa dịch vụ thanh toán và ngân hàng.

2 Monitoring Performance of Service Calls (Giám sát hiệu suất của các cuộc gọi dịch vụ)

Trong mạng microservices, việc theo dõi đường đi của một yêu cầu qua nhiều dịch vụ là rất quan trọng để đo lường thời gian thực hiện ở từng dịch vụ Điều này không chỉ giúp xác định các nút cổ chai trong hệ thống mà còn chỉ ra những dịch vụ cần được tối ưu hóa để nâng cao hiệu suất tổng thể.

Trong một ứng dụng thương mại điện tử, dịch vụ tìm kiếm sản phẩm là một yếu tố quan trọng Khi người dùng thực hiện tìm kiếm, yêu cầu sẽ được xử lý qua các dịch vụ như tìm kiếm, lưu trữ dữ liệu và gợi ý sản phẩm Nếu người dùng gặp phải vấn đề về tốc độ chậm, việc giám sát từng dịch vụ sẽ giúp xác định nguyên nhân gây ra sự chậm trễ.

3 Monitoring Services Metrics & Health (Giám sát chỉ số và tình trạng dịch vụ)

Để đảm bảo hiệu suất tối ưu cho các ứng dụng microservices, cần giám sát các chỉ số quan trọng như mức sử dụng CPU, bộ nhớ JVM và các chỉ số khác Việc theo dõi tình trạng và sức khỏe của tất cả các ứng dụng này tại một nơi duy nhất là rất cần thiết, đồng thời thiết lập các cảnh báo kịp thời khi phát hiện hành vi bất thường sẽ giúp nâng cao độ tin cậy và hiệu suất của hệ thống.

Trong hệ thống ngân hàng, sự gia tăng đột ngột mức sử dụng CPU của một dịch vụ giao dịch có thể chỉ ra một cuộc tấn công hoặc vấn đề hiệu suất Hệ thống giám sát cần nhanh chóng phát hiện sự bất thường này và gửi cảnh báo ngay lập tức cho quản trị viên để kịp thời xử lý.

Giải pháp và công cụ phổ biến:

Logging là gì?

o ELK Stack (Elasticsearch, Logstash, Kibana): Một bộ công cụ phổ biến giúp thu thập, lưu trữ, và phân tích log từ nhiều dịch vụ trong một hệ thống microservices.

Distributed Tracing là một kỹ thuật quan trọng trong việc theo dõi luồng yêu cầu qua nhiều dịch vụ Các công cụ như Jaeger và Zipkin cho phép bạn quan sát thời gian thực hiện của từng dịch vụ, giúp xác định các nút cổ chai trong hệ thống.

Prometheus và Grafana là hai công cụ quan trọng trong việc thu thập và hiển thị các chỉ số hiệu suất cũng như sức khỏe của dịch vụ Prometheus chuyên trách việc thu thập dữ liệu, trong khi Grafana cung cấp giao diện trực quan để hiển thị thông tin và thiết lập các cảnh báo cần thiết.

Tình huống ứng dụng thực tế:

Trong ứng dụng thương mại điện tử, một người dùng gặp khó khăn trong việc hoàn tất thanh toán Để xác định nguyên nhân, nhóm phát triển đã áp dụng phương pháp theo dõi phân tán (distributed tracing) để giám sát yêu cầu qua các dịch vụ như giỏ hàng, thanh toán và xác thực người dùng Qua việc kiểm tra log, họ phát hiện rằng dịch vụ thanh toán đang bị quá tải, dẫn đến lỗi trong quá trình thanh toán.

Khi lưu lượng truy cập tăng đột ngột trong giờ cao điểm, hệ thống giám sát phát hiện một dịch vụ API có mức sử dụng CPU tăng cao bất thường Prometheus ngay lập tức gửi cảnh báo cho nhóm vận hành, giúp họ nhanh chóng điều chỉnh tài nguyên nhằm tránh gián đoạn dịch vụ.

Ứng dụng truyền thông xã hội vừa gặp phải lỗi timeout khi người dùng đăng video Nhóm phát triển đã sử dụng Zipkin để theo dõi luồng yêu cầu và phát hiện rằng dịch vụ xử lý video mất nhiều thời gian hơn mong đợi Để khắc phục vấn đề này, họ đã tiến hành tối ưu hóa dịch vụ nhằm giảm thời gian xử lý video.

1 Khái niệm Observability (Khả năng quan sát)

 Observability là khả năng hiểu được trạng thái bên trong của một hệ thống bằng cách quan sát các đầu ra của nó.

Trong kiến trúc microservices, observability được thực hiện bằng cách thu thập và phân tích dữ liệu từ nhiều nguồn khác nhau, bao gồm chỉ số (metrics), nhật ký (logs) và vết truy xuất (traces).

2 Ba trụ cột của Observability: a Metrics (Chỉ số)

Metrics là các số liệu định lượng quan trọng để đo lường sức khỏe của hệ thống, bao gồm các chỉ số như sử dụng CPU, sử dụng bộ nhớ và thời gian phản hồi.

 Metrics giúp bạn theo dõi hiệu suất của hệ thống theo thời gian và xác định các vấn đề tiềm ẩn.

Một ứng dụng web có thể áp dụng Prometheus để thu thập chỉ số thời gian phản hồi của API Khi thời gian phản hồi vượt qua ngưỡng quy định, hệ thống sẽ gửi cảnh báo đến nhóm phát triển để họ tiến hành kiểm tra.

 Logs là các bản ghi về các sự kiện xảy ra trong hệ thống Chúng giúp theo dõi: o Errors (Lỗi) o Exceptions (Ngoại lệ) o Unexpected events (Sự kiện bất ngờ)

 Logs thường được sử dụng để phân tích và tìm hiểu nguyên nhân gốc rễ của các sự cố.

Khi người dùng không thể truy cập tài khoản, nhóm phát triển kiểm tra log dịch vụ xác thực để phát hiện lỗi, ví dụ như lỗi kết nối cơ sở dữ liệu.

Traces là bản ghi chi tiết về hành trình của một yêu cầu trong hệ thống, giúp theo dõi hiệu suất từng bước trong luồng yêu cầu Đồng thời, traces còn hỗ trợ xác định các nút cổ chai và điểm yếu trong hệ thống, từ đó nâng cao hiệu quả hoạt động.

Khi người dùng thực hiện yêu cầu tìm kiếm sản phẩm trên ứng dụng thương mại điện tử, quy trình này sẽ trải qua nhiều dịch vụ khác nhau, bao gồm dịch vụ tìm kiếm, dịch vụ cơ sở dữ liệu và dịch vụ gợi ý sản phẩm.

Distributed tracing bằng Jaeger sẽ giúp theo dõi yêu cầu này qua tất cả các dịch vụ để tìm ra nơi gây ra chậm trễ.

 Giúp chẩn đoán vấn đề nhanh chóng, cải thiện thời gian khắc phục sự cố (MTTR).

 Tối ưu hóa hiệu suất hệ thống bằng cách xác định và khắc phục các nút cổ chai.

 Nâng cao tính ổn định và độ tin cậy của hệ thống, giảm thiểu downtime.

Tình huống ứng dụng thực tế:

Tình huống 1: Tối ưu hóa hiệu suất API

 Một công ty cung cấp API cho khách hàng và nhận thấy thời gian phản hồi tăng cao trong giờ cao điểm.

 Metrics cho thấy rằng mức sử dụng CPU của dịch vụ API luôn ở mức cao.

 Logs cho thấy rằng nhiều ngoại lệ TimeoutException xảy ra khi kết nối tới dịch vụ cơ sở dữ liệu.

 Traces chỉ ra rằng hầu hết thời gian xử lý yêu cầu bị tiêu tốn ở bước truy vấn cơ sở dữ liệu.

 Giải pháp: Tối ưu hóa truy vấn SQL và tăng tài nguyên cho cơ sở dữ liệu.

Tình huống 2: Gỡ lỗi sự cố kết nối trong hệ thống microservices

 Một người dùng báo cáo rằng họ không thể đặt hàng trên ứng dụng.

 Logs cho thấy rằng có một lỗi 500 Internal Server Error trong dịch vụ đặt hàng.

 Traces chỉ ra rằng lỗi này xảy ra khi dịch vụ đặt hàng gọi đến dịch vụ thanh toán.

 Metrics cho thấy mức sử dụng bộ nhớ của dịch vụ thanh toán rất cao, có thể do quá tải.

 Giải pháp: Tăng tài nguyên cho dịch vụ thanh toán và thực hiện tối ưu hóa code để giảm mức sử dụng bộ nhớ.

Khái niệm Monitoring (Giám sát)

Giám sát trong microservices là việc theo dõi dữ liệu telemetry của ứng dụng nhằm kiểm tra tình trạng sức khỏe của hệ thống và thiết lập cảnh báo khi có sự cố xảy ra.

Quá trình này bao gồm việc thu thập và phân tích dữ liệu nhằm xác định và giải quyết các vấn đề, đồng thời theo dõi tình trạng sức khỏe của từng microservice cũng như toàn bộ hệ thống.

2 Lợi ích của Monitoring: a Identify and Troubleshoot Problems (Xác định và khắc phục sự cố)

 Monitoring giúp thu thập và phân tích dữ liệu từ microservices, cho phép phát hiện vấn đề trước khi chúng gây ra sự cố hoặc gián đoạn dịch vụ.

Một ứng dụng ngân hàng online có thể gặp lỗi kết nối do hệ thống cơ sở dữ liệu quá tải Nhờ vào việc theo dõi sức khỏe của microservices, nhóm vận hành nhận được cảnh báo kịp thời và thực hiện các biện pháp giảm tải, giúp người dùng tránh được lỗi truy cập.

 Monitoring giúp theo dõi tình trạng của từng microservice, giúp phát hiện các dịch vụ hoạt động kém hiệu quả hoặc gặp sự cố.

Trong một ứng dụng thương mại điện tử, việc theo dõi thời gian phản hồi của dịch vụ thanh toán là rất quan trọng Nếu thời gian phản hồi tăng đột biến, hệ thống giám sát sẽ ghi nhận chỉ số này và gửi cảnh báo đến nhóm phát triển Điều này giúp họ kịp thời kiểm tra và tối ưu hóa dịch vụ, đảm bảo trải nghiệm người dùng tốt nhất Tối ưu hóa microservices là một bước quan trọng trong việc duy trì hiệu suất và độ tin cậy của ứng dụng.

 Nhờ vào việc giám sát, bạn có thể xác định những khu vực cần tối ưu hóa để cải thiện hiệu suất và độ tin cậy của hệ thống.

Thách thức trong bảo mật Microservices

Microservices yêu cầu cơ chế bảo mật nâng cao vì chúng hoạt động độc lập nhưng liên kết chặt chẽ Ba vấn đề chính cần giải quyết:

Để ngăn chặn truy cập trái phép vào các microservices, việc triển khai cơ chế bảo mật là rất quan trọng Nếu không có các biện pháp bảo vệ thích hợp, bất kỳ ai cũng có thể dễ dàng truy cập và lấy đi dữ liệu nhạy cảm từ ứng dụng client hoặc người dùng cuối.

Xác thực và phân quyền là quá trình quan trọng để đảm bảo chỉ những người dùng hoặc dịch vụ được phép mới có quyền truy cập vào các dịch vụ cụ thể Trong kiến trúc microservices, việc thực hiện chức năng xác minh danh tính (authentication) và kiểm tra quyền (authorization) là cần thiết trước khi cho phép truy cập vào các tài nguyên.

Centralized Identity and Access Management (IAM) is essential for maintaining a secure system that stores login information, processes identities, and manages access rights efficiently Implementing a centralized IAM system ensures streamlined access control, enhances security by reducing vulnerabilities, and simplifies user management across the organization By consolidating identity data and access permissions, businesses can effectively monitor and protect sensitive information while ensuring compliance with regulatory standards.

2 Công cụ hỗ trợ giải quyết

OAuth2 và OpenID Connect là các giao thức hiện đại cho xác thực và phân quyền, giúp microservices quản lý quyền truy cập mà không cần lưu trữ thông tin đăng nhập của người dùng.

 API RESTful cung cấp dữ liệu tài chính cho các ứng dụng ngân hàng sử dụng OAuth2 để ủy quyền truy cập.

Keycloak là một hệ thống quản lý danh tính mã nguồn mở, cung cấp các tính năng như quản lý đăng nhập một lần (SSO), xác thực đa yếu tố (MFA) và phân quyền tập trung, giúp tăng cường bảo mật và quản lý người dùng hiệu quả Ứng dụng của Keycloak rất đa dạng, phù hợp cho các tổ chức cần giải pháp quản lý danh tính mạnh mẽ.

 Các công ty SaaS tích hợp Keycloak để quản lý đăng nhập người dùng cuối và dịch vụ.

Spring Security is a powerful framework for integrating security into Java/Spring Boot applications It offers support for encryption, JWT-based authentication, and seamless integration with OAuth2.

 Một ứng dụng quản lý bán hàng sử dụng Spring Security để xác thực admin và nhân viên.

3 Trường hợp ứng dụng thực tế

 Hệ thống thương mại điện tử: o Scenario:

 Người dùng gửi yêu cầu truy cập vào thông tin đơn hàng từ nhiều dịch vụ khác nhau (giỏ hàng, giao hàng, thanh toán). o Solution:

 Sử dụng OAuth2 để đảm bảo chỉ những người dùng đã đăng nhập mới được phép truy cập.

 Keycloak được dùng để lưu trữ thông tin người dùng và xác thực.

 Các phòng khám cần truy cập vào hồ sơ bệnh án bệnh nhân trên nhiều dịch vụ (lịch sử khám, thuốc, bảo hiểm). o Solution:

 Spring Security và OpenID Connect để bảo mật dữ liệu bệnh nhân và hạn chế truy cập chỉ cho bác sĩ được ủy quyền.

1 Vấn đề với Basic Authentication:

Basic Authentication có những nhược điểm đáng chú ý, bao gồm việc gắn chặt với backend, khiến cho quá trình xác thực và ủy quyền trở nên khó linh hoạt trong ứng dụng Hơn nữa, phương pháp này không phù hợp với REST API, không hỗ trợ tốt cho các luồng di động hoặc các API khác.

REST. o Thiếu khả năng chia sẻ thông tin: Không hỗ trợ trường hợp người dùng muốn cấp quyền cho ứng dụng bên thứ ba. Ứng dụng thực tế:

Khi phát triển ứng dụng sử dụng API của bên thứ ba như Google hoặc Facebook, việc sử dụng Basic Authentication có thể gây rủi ro vì nó không đảm bảo an toàn cho thông tin đăng nhập.

2 OAuth2 – Giải pháp cải thiện:

 OAuth2 là một framework hiện đại giúp phân tách việc authentication và authorization.

 Với OAuth2: o Authentication: Kiểm tra danh tính người dùng. o Authorization: Kiểm soát quyền truy cập vào tài nguyên.

Bạn có thể sử dụng một tài khoản Google để truy cập nhiều dịch vụ như Gmail, Google Drive và Google Photos mà không cần phải đăng nhập lại Hệ thống OAuth2 tạo ra token để cấp quyền cho từng dịch vụ, thay vì yêu cầu thông tin đăng nhập mỗi lần.

 Ứng dụng bên thứ ba: o Khi bạn đăng nhập vào Spotify bằng tài khoản Facebook hoặc Google, OAuth2 đứng sau quá trình cấp quyền này.

3 Lợi ích khi sử dụng OAuth2:

 Tách biệt Authentication và Authorization: o Backend chỉ xử lý logic của API, còn việc kiểm tra danh tính và cấp quyền do OAuth2 thực hiện.

 Hỗ trợ Mobile và REST API: o OAuth2 cung cấp token-based authentication, dễ sử dụng trên các thiết bị di động hoặc API.

 Bảo mật cao: o Token có thời hạn sử dụng, giảm rủi ro bị đánh cắp thông tin.

Tình huống triển khai thực tế:

OpenID Connect (OIDC) là một phần mở rộng của OAuth2, cung cấp thông tin chi tiết về người dùng như tên và email OIDC thường được sử dụng trong các ứng dụng yêu cầu thông tin người dùng khi đăng nhập, chẳng hạn như dịch vụ ngân hàng trực tuyến.

Keycloak là một giải pháp quản lý danh tính và truy cập tập trung (IAM) hiệu quả, giúp doanh nghiệp quản lý người dùng một cách dễ dàng Bằng cách tích hợp Keycloak, các tổ chức có thể kết nối nhiều dịch vụ khác nhau mà không cần phải xử lý logic xác thực riêng lẻ cho từng ứng dụng, từ đó tiết kiệm thời gian và tăng cường bảo mật.

OAuth2 khắc phục những hạn chế của phương pháp xác thực Basic, mang đến một giải pháp hiện đại, linh hoạt và an toàn hơn Các hệ thống lớn như Google, Facebook và nhiều doanh nghiệp thường sử dụng OAuth2 để cung cấp trải nghiệm đăng nhập một lần (SSO) và nâng cao bảo mật.

 OAuth2 (Open Authorization) là một giao thức mã nguồn mở, được xây dựng dựa trên các tiêu chuẩn của IETF và cấp phép từ Open Web Foundation.

Mục đích của ủy quyền là cấp quyền cho một ứng dụng truy cập dữ liệu hoặc sử dụng tính năng từ một ứng dụng khác thay mặt bạn mà không cần chia sẻ mật khẩu Quyền truy cập này giúp bảo vệ thông tin cá nhân của bạn trong quá trình sử dụng các ứng dụng khác nhau.

1 Hỗ trợ nhiều loại ứng dụng: o Server-to-Server Apps: Kết nối giữa các dịch vụ máy chủ (ví dụ: API Payment

Gateway technology encompasses various application types, including browser-based apps, mobile/native applications, and IoT devices such as smart TVs and consoles Additionally, it supports different authorization flows, including Authorization Code Grant and Client Credentials Grant, to ensure secure access and functionality across platforms.

Tách biệt logic xác thực là phương pháp lưu trữ tất cả thông tin xác thực của người dùng và ứng dụng trong Authorization Server, giúp quản lý bảo mật một cách hiệu quả Phương pháp này không chỉ giảm bớt khối lượng công việc xử lý logic xác thực và ủy quyền trong ứng dụng chính mà còn nâng cao tính bảo mật tổng thể.

Vấn đề và giải pháp trong xây dựng Event-Driven Microservices

Tránh "Temporal Coupling" là rất quan trọng trong phát triển dịch vụ, vì nó xảy ra khi dịch vụ gọi yêu cầu phản hồi ngay lập tức từ dịch vụ được gọi, dẫn đến việc nếu dịch vụ được gọi bị chậm trễ, thời gian phản hồi của dịch vụ gọi sẽ bị ảnh hưởng Điều này gây ra sự kém hiệu quả trong hệ thống Giải pháp hiệu quả là tối ưu hóa kiến trúc bằng cách sử dụng kiến trúc sự kiện, giúp giảm thiểu sự phụ thuộc về thời gian giữa các dịch vụ.

Giao tiếp không đồng bộ là một giải pháp hiệu quả trong nhiều trường hợp, cho phép các dịch vụ xử lý yêu cầu mà không cần chờ phản hồi ngay lập tức Việc áp dụng giao tiếp không đồng bộ giúp giảm tải công việc và tối ưu hóa quy trình, mang lại sự linh hoạt và hiệu suất cao hơn trong công việc.

Xây dựng microservices theo hướng sự kiện (Event-driven) cho phép quản lý các thay đổi trạng thái trong hệ thống, chẳng hạn như tạo đơn hàng hoặc thanh toán thành công Các sự kiện này có thể phát sinh từ nhiều nguồn khác nhau và cần được thông báo đến các dịch vụ liên quan Ví dụ, khi một đơn hàng được đặt, một sự kiện sẽ được tạo ra để cập nhật kho, thông báo cho khách hàng và xử lý thanh toán.

2 Công cụ và công nghệ áp dụng:

 Kiến trúc hướng sự kiện (Event-driven architecture): Tập trung vào việc sinh ra và tiêu thụ sự kiện giữa các dịch vụ.

 Giao tiếp không đồng bộ (Async communication): Sử dụng các hệ thống như Kafka,

RabbitMQ để đảm bảo tính không đồng bộ.

 Event brokers: Trung gian quản lý sự kiện, ví dụ như Kafka, RabbitMQ.

 Spring Cloud Stream: Một công cụ phổ biến trong hệ sinh thái Spring, hỗ trợ xây dựng các microservices hướng sự kiện.

 Spring Cloud Function: Cho phép triển khai và thực thi các chức năng nhỏ gọn, hướng sự kiện.

Tình huống ứng dụng và ví dụ thực tế:

1 Ứng dụng thương mại điện tử: o Tình huống: Khi khách hàng đặt hàng, hệ thống cần cập nhật nhiều phần (kho, thanh toán, thông báo giao hàng). o Giải pháp:

 Tạo sự kiện "Đặt hàng thành công".

 Kho, hệ thống thanh toán, và dịch vụ giao hàng lắng nghe và phản ứng với sự kiện này.

 Sử dụng Kafka làm Event Broker để giao tiếp không đồng bộ.

Hệ thống ngân hàng cần đảm bảo rằng khi người dùng gửi tiền vào tài khoản, lịch sử giao dịch sẽ được cập nhật ngay lập tức, đồng thời thông báo cho người dùng về giao dịch này và điều chỉnh số dư tài khoản một cách chính xác.

 Tạo sự kiện "Gửi tiền hoàn tất".

 Các dịch vụ liên quan (lịch sử giao dịch, thông báo) lắng nghe sự kiện và thực hiện hành động tương ứng.

Ứng dụng quản lý vận tải đóng vai trò quan trọng trong việc thông báo cho tài xế khi nhận đơn hàng, cập nhật trạng thái đơn hàng một cách kịp thời và cung cấp chỉ dẫn đường đi chính xác cho tài xế.

 Tạo sự kiện "Nhận đơn hàng".

 Các dịch vụ như thông báo, quản lý trạng thái đơn hàng, và hệ thống bản đồ phản ứng với sự kiện này.

Mô hình Publisher/Subscriber (Pub/Sub):

Cơ chế hoạt động của hệ thống bao gồm việc nhà sản xuất tạo ra các sự kiện và phân phối chúng đến tất cả các bên đăng ký để tiêu thụ Điều này đảm bảo rằng thông tin được truyền tải một cách hiệu quả và đồng bộ giữa các bên liên quan.

 Một khi sự kiện đã được nhận, nó không thể được phát lại.

 Các Subscribers tham gia sau khi sự kiện đã được phát sẽ không có quyền truy cập vào các sự kiện trong quá khứ. o Công cụ phổ biến: RabbitMQ.

Hệ thống này có ưu điểm nổi bật trong việc xử lý các sự kiện theo thời gian thực, cho phép các sự kiện được xử lý ngay tại thời điểm phát Ngoài ra, nó còn hỗ trợ mở rộng theo chiều ngang, giúp dễ dàng mở rộng khi có nhiều Subscriber tham gia.

Cơ chế hoạt động của hệ thống ghi sự kiện bao gồm việc ghi lại các sự kiện theo thứ tự tuần tự vào nhật ký Các nhà sản xuất phát hành sự kiện ngay khi chúng xảy ra, và các sự kiện này được lưu trữ một cách có tổ chức Người tiêu dùng có thể truy cập và đọc dữ liệu từ bất kỳ phần nào của dòng sự kiện, mang lại tính linh hoạt và hiệu quả trong việc xử lý thông tin.

 Các sự kiện có thể được phát lại.

 Các khách hàng tham gia sau có thể nhận được toàn bộ lịch sử sự kiện từ quá khứ. o Công cụ phổ biến: Apache Kafka.

Khả năng xử lý lại dữ liệu giúp khôi phục và phân tích thông tin hiệu quả, đồng thời phù hợp với các ứng dụng cần theo dõi và xử lý lịch sử sự kiện trong thời gian dài.

Tình huống ứng dụng và ví dụ thực tế:

Ứng dụng chat thời gian thực yêu cầu khi một người dùng gửi tin nhắn, tin nhắn đó cần được phát đến tất cả người dùng trong phòng chat Giải pháp hiệu quả cho vấn đề này là sử dụng RabbitMQ, cho phép phát tin nhắn đến tất cả các Subscribers đang kết nối một cách nhanh chóng và đồng bộ.

Hệ thống cảnh báo thời gian thực giúp gửi thông báo ngay khi phát hiện vi phạm bảo mật trong mạng Giải pháp hiệu quả là áp dụng mô hình Pub/Sub để truyền tải cảnh báo đến đội ngũ quản trị hệ thống, đảm bảo phản ứng kịp thời và nâng cao an ninh mạng.

1 Ứng dụng theo dõi đơn hàng: o Tình huống: Người dùng cần xem lịch sử toàn bộ trạng thái đơn hàng của mình

Để theo dõi trạng thái đơn hàng hiệu quả, bao gồm các giai đoạn như đã đặt hàng, đang vận chuyển và đã giao, giải pháp tối ưu là sử dụng Kafka để lưu trữ dòng sự kiện trạng thái đơn hàng Người tiêu dùng có khả năng phát lại các sự kiện này, giúp hiển thị lịch sử đơn hàng một cách rõ ràng và minh bạch.

Phân tích dữ liệu lớn (Big Data Analytics) cho phép thu thập và phân tích sự kiện từ hàng triệu thiết bị IoT trong thời gian thực Giải pháp hiệu quả là sử dụng Kafka làm nền tảng lưu trữ và phát lại dữ liệu, giúp tối ưu hóa quá trình phân tích lịch sử sự kiện.

Hệ thống phát nhạc trực tuyến cần quản lý danh sách phát cho người dùng và lưu trữ lịch sử các bài hát đã phát Giải pháp hiệu quả cho vấn đề này là áp dụng công nghệ Event Streaming, giúp theo dõi cả sự kiện phát nhạc và ghi lại lịch sử phát nhạc một cách đồng bộ và chính xác.

Chi tiết các bước trong quy trình:

1 Người dùng thực hiện yêu cầu tạo tài khoản (Step 1): o Người dùng gửi yêu cầu tạo một tài khoản mới đến Accounts Microservice.

Để tạo tài khoản và sự kiện, trước tiên, tài khoản mới sẽ được tạo thành công trong Microservice quản lý tài khoản Sau đó, một sự kiện sẽ được gửi đến Event Broker nhằm xử lý việc gửi thông báo qua email và SMS cho người dùng.

Tổng quan Control Panel (Master Node)

Control Panel (Master Node) là trung tâm điều phối và quản lý toàn bộ hệ thống Kubernetes Nó có các nhiệm vụ chính:

 Giám sát trạng thái của tất cả các Node trong cụm (Cluster).

 Lên kế hoạch triển khai các container vào các Worker Nodes.

 Quản lý dữ liệu cấu hình và trạng thái của toàn bộ cụm Kubernetes.

 Xử lý sự cố, chẳng hạn như chuyển tải công việc từ các Node bị lỗi sang Node khác hoạt động tốt hơn.

2 Các thành phần chính của Control Panel

 Là giao diện chính để tương tác với cụm Kubernetes.

 Expose các Kubernetes API, cho phép người dùng, ứng dụng và các thành phần khác giao tiếp với cụm.

 Xử lý các yêu cầu quản trị và xác thực chúng. o Ví dụ ứng dụng:

 Khi người dùng gửi yêu cầu kubectl get pods, API Server sẽ xử lý và trả về danh sách các Pods hiện tại trong cụm.

 Quyết định Node nào sẽ được sử dụng để triển khai một Pod dựa trên tài nguyên sẵn có và các ràng buộc (constraints).

 Tính toán thông minh để phân bổ Pods đồng đều, tránh quá tải trên một Node. o Ví dụ ứng dụng:

 Một Pod yêu cầu 2 CPU và 4GB RAM Scheduler sẽ kiểm tra tài nguyên sẵn có trên các Node và chọn Node phù hợp nhất.

 Giữ cho cụm Kubernetes ở trạng thái mong muốn bằng cách so sánh trạng thái hiện tại với trạng thái lý tưởng.

 Xử lý lỗi của Node, đảm bảo số lượng Pods luôn đúng như mong muốn. o Ví dụ ứng dụng:

 Nếu một Pod bất ngờ bị lỗi, Controller Manager sẽ tạo lại Pod để đảm bảo ứng dụng hoạt động liên tục.

 Là cơ sở dữ liệu key-value phân tán để lưu trữ trạng thái toàn bộ cụm.

 Lưu giữ dữ liệu cấu hình, thông tin về Pods, Services, và trạng thái của cụm. o Ví dụ ứng dụng:

 Lưu trạng thái của các ReplicaSet để đảm bảo số lượng bản sao Pods luôn khớp với cấu hình mong muốn.

3 Tình huống ứng dụng thực tế

Khi một Pod gặp sự cố hoặc Node bị ngắt kết nối, Controller Manager sẽ tự động khôi phục ứng dụng bằng cách tạo lại Pod trên một Node khác, đảm bảo duy trì trạng thái hoạt động của ứng dụng.

Scheduler đóng vai trò quan trọng trong việc phân phối tài nguyên hiệu quả, đảm bảo rằng các ứng dụng cần nhiều tài nguyên được phân bố đồng đều giữa các Node Điều này giúp giảm thiểu tình trạng quá tải trên một Node duy nhất, tối ưu hóa hiệu suất hệ thống.

Quản lý cấu hình hệ thống phân tán là yếu tố quan trọng trong việc duy trì hiệu suất của cụm Kubernetes Etcd đóng vai trò lưu trữ thông tin cấu hình, cho phép thực hiện các thay đổi một cách nhanh chóng mà không cần phải dừng toàn bộ hệ thống, từ đó nâng cao tính linh hoạt và khả năng phản ứng của hệ thống.

Triển khai liên tục (Continuous Deployment) cho phép API Server và Controller Manager làm việc cùng nhau để cập nhật các phiên bản mới của ứng dụng mà không làm gián đoạn dịch vụ.

Lợi ích chính của các thành phần Control Panel

1 Tính tự động hóa: Các thành phần phối hợp với nhau để tự động hóa việc triển khai, giám sát và quản lý trạng thái cụm.

2 Tính linh hoạt và mở rộng: Hỗ trợ thêm các Node hoặc ứng dụng mới mà không cần phải thay đổi cấu trúc cơ bản.

3 Tính sẵn sàng cao: etcd và Controller Manager giúp hệ thống tiếp tục hoạt động ngay cả khi xảy ra sự cố với một Node hoặc Pod.

Tổng quan Worker Node

Worker Node là nơi xử lý thực tế cho các ứng dụng chạy trên Kubernetes Nó có thể là:

 Virtual Machine (VM): Chạy trên đám mây (cloud) hoặc tại cơ sở (on-premise).

 Physical Machine: Máy chủ vật lý trong trung tâm dữ liệu của bạn.

Worker Node cung cấp tài nguyên tính toán, lưu trữ và mạng cần thiết cho việc chạy các container trong Pods Dưới sự điều phối của Control Panel (Master Node), các Worker Nodes thực hiện khối lượng công việc được phân bổ.

2 Pods và vai trò của chúng

 Pods là đơn vị triển khai nhỏ nhất trong Kubernetes.

 Một Pod bao gồm một hoặc nhiều container, chia sẻ mạng, IP, và các tài nguyên lưu trữ khác.

 Mỗi khi Pod được khởi chạy, nó sẽ nhận một địa chỉ IP riêng biệt trong cụm (cluster).

3 Các thành phần chính trong Worker Node

Worker Node có ba thành phần chính:

 Là một agent chạy trên mỗi Worker Node và giao tiếp với Control Panel.

 Nhận chỉ thị từ Control Plane, như tạo hoặc xóa Pods.

 Theo dõi và đảm bảo trạng thái Pods trên Node phù hợp với trạng thái mong muốn được xác định trong Kubernetes. o Ví dụ ứng dụng:

Khi triển khai ứng dụng mới, kubelet sẽ khởi tạo các container trên Node và giám sát hoạt động của chúng để đảm bảo tính ổn định và hiệu suất.

 Là một proxy mạng chạy trên mỗi Node, thực hiện một phần khái niệm

 Duy trì các quy tắc mạng để đảm bảo kết nối giữa Pods trong cụm hoặc với các dịch vụ bên ngoài cụm. o Ví dụ ứng dụng:

 Khi một Pod trong cụm Kubernetes cần truy cập một dịch vụ, kube-proxy đảm bảo rằng yêu cầu mạng được chuyển đến đúng Pod hoặc Service.

 Chạy và quản lý vòng đời container trên Worker Node.

 Docker là container runtime phổ biến nhất, nhưng Kubernetes cũng hỗ trợ các runtime khác như containerd và rkt.

 Thực hiện các tác vụ như kéo ảnh container, tạo và khởi động container. o Ví dụ ứng dụng:

 Khi một container cần được khởi động từ một ảnh (image) trên Docker Hub, Container Runtime sẽ kéo ảnh này về và chạy nó trong môi trường Kubernetes.

4 Tình huống ứng dụng thực tế

Triển khai ứng dụng phân tán sử dụng Worker Nodes để hỗ trợ mở rộng quy mô với nhiều Pods Chẳng hạn, trong một ứng dụng thương mại điện tử, việc chạy nhiều Pods cho phép xử lý hàng nghìn yêu cầu mỗi giây một cách hiệu quả.

Kubernetes đảm bảo dịch vụ liên tục bằng cách tự động khởi chạy lại Pods trên Node khác trong cụm khi một Worker Node gặp lỗi, giúp duy trì hoạt động không bị gián đoạn.

Cân bằng tải là quá trình quan trọng trong Kubernetes, nơi Kube-proxy đảm nhận vai trò phân phối đồng đều các yêu cầu từ người dùng giữa các Pods trong cụm, góp phần nâng cao hiệu suất tổng thể của hệ thống.

Node có khả năng chạy nhiều dịch vụ khác nhau nhờ hỗ trợ nhiều container runtime, cho phép Worker Node hoạt động trong các môi trường container hóa độc lập.

Lợi ích của Worker Nodes

 Hiệu quả tài nguyên: Các Node chia sẻ tài nguyên và tối ưu hóa việc sử dụng CPU,

 Tự động hóa: Các Pods được quản lý và giám sát tự động, giảm thiểu sự can thiệp thủ công.

 Tính linh hoạt: Worker Nodes có thể thêm hoặc bớt một cách linh hoạt mà không cần dừng cụm Kubernetes.

Kubernetes ConfigMap là gì?

 ConfigMap là một Kubernetes resource dùng để lưu trữ dữ liệu cấu hình (configuration data) tách biệt khỏi mã nguồn (application code).

Nó cho phép quản lý các giá trị cấu hình của ứng dụng dưới dạng cặp key-value, giúp tăng tính linh hoạt và giảm sự phụ thuộc vào việc thay đổi mã nguồn khi cần cập nhật cấu hình.

2 Các thành phần của ConfigMap

1 apiVersion: o Xác định phiên bản của API Kubernetes được sử dụng để tạo ConfigMap. o Trong ví dụ: apiVersion: v1.

2 kind: o Xác định loại Kubernetes object Trong trường hợp này, kind là ConfigMap.

3 metadata: o Chứa thông tin meta về ConfigMap, chẳng hạn như:

 name: Tên của ConfigMap, trong ví dụ là eazybank-configmap.

Phần dữ liệu chứa các cặp key-value, trong đó key là một chuỗi bất kỳ như SPRING_PROFILES_ACTIVE, và value là giá trị tương ứng có thể là chuỗi, số hoặc dữ liệu nhị phân Ví dụ, SPRING_PROFILES_ACTIVE: prod xác định profile ứng dụng đang chạy trong môi trường sản xuất.

3 Lợi ích của việc sử dụng ConfigMap

 Tách biệt cấu hình khỏi mã nguồn: o Dễ dàng thay đổi cấu hình mà không cần xây dựng lại container hoặc chỉnh sửa mã nguồn.

 Triển khai linh hoạt: o Có thể sử dụng ConfigMap trên nhiều Pod hoặc container trong cùng một cụm Kubernetes.

 Tích hợp tốt với Kubernetes Secrets: o Secrets được sử dụng cho dữ liệu nhạy cảm (như mật khẩu), trong khi ConfigMap dùng cho cấu hình thông thường.

4 Trường hợp ứng dụng thực tế

Triển khai ứng dụng trên nhiều môi trường như dev, staging và production là điều cần thiết ConfigMap cho phép xác định các cấu hình riêng biệt cho từng môi trường mà không cần thay đổi mã nguồn Chẳng hạn, một ứng dụng Spring Boot có thể sử dụng các profile khác nhau thông qua biến SPRING_PROFILES_ACTIVE.

2 Cấu hình dịch vụ bên thứ ba: o Lưu các URL API hoặc khóa API để ứng dụng truy cập các dịch vụ bên ngoài như Firebase, AWS S3, hoặc Stripe.

Cấu hình ứng dụng động cho phép điều chỉnh các thông số như số lượng kết nối database và thời gian chờ kết nối một cách dễ dàng mà không cần khởi động lại ứng dụng.

Tổng quan về Kubernetes Deployment

 Deployment là một Kubernetes resource cấp cao dùng để quản lý việc triển khai và scaling các ứng dụng container hóa.

Triển khai ứng dụng giúp xác định trạng thái mong muốn và duy trì trạng thái này bằng cách tự động quản lý các bản cập nhật, thực hiện rollback khi cần thiết và điều chỉnh quy mô ứng dụng.

2 Cấu trúc và chi tiết manifest file

Hình ảnh hiển thị một file YAML dùng để triển khai container bằng Deployment Dưới đây là các phần chính:

1 apiVersion: o Xác định phiên bản API được sử dụng. o Ở đây: apps/v1 dùng cho các Deployment hiện đại.

2 kind: o Loại Kubernetes object. o Ở đây: Deployment.

3 metadata: o Chứa thông tin về Deployment như:

 name: Tên Deployment là accounts-deployment.

 labels: Gắn nhãn (labels) để nhận diện đối tượng, ở đây là app: accounts.

The spec defines the desired state of the Deployment, specifying the number of container replicas to run In this case, a value of 1 indicates that only one replica will be active at any given time The selector is also an essential component in managing these replicas.

 Xác định các Pod mà Deployment quản lý, thông qua nhãn app: accounts. o template:

 Định nghĩa cấu hình của các Pod được tạo bởi Deployment.

 metadata: Gắn nhãn cho các Pod (app: accounts).

 spec: Định cấu hình container:

 name: Tên container là accounts.

 image: Hình ảnh Docker container được sử dụng

 ports: Container sẽ mở cổng 8080.

 Biến môi trường: SPRING_PROFILES_ACTIVE được lấy từ ConfigMap eazybank-configmap.

3 Lợi ích của Kubernetes Deployment

Quản lý ứng dụng trở nên đơn giản hơn với khả năng đảm bảo số lượng container hoạt động đúng như định nghĩa Hệ thống hỗ trợ cập nhật tự động (rolling updates) mà không làm gián đoạn dịch vụ, giúp nâng cao hiệu suất và tính ổn định cho ứng dụng.

 Khả năng rollback: o Deployment hỗ trợ quay lại phiên bản trước trong trường hợp gặp lỗi.

 Tự động scaling: o Dựa trên tài nguyên CPU, bộ nhớ, hoặc số lượng yêu cầu (nếu có cấu hình HPA -Horizontal Pod Autoscaler).

1 Tổng quan về Service trong Kubernetes

 Service là một Kubernetes resource cung cấp điểm kết nối mạng ổn định cho một nhóm

Dịch vụ trừu tượng hóa các chi tiết mạng nội bộ, cho phép người dùng truy cập và cân bằng tải giữa nhiều bản sao của một Pod mà không cần phụ thuộc vào địa chỉ IP động của chúng.

2 Cấu trúc và chi tiết manifest file

Hình ảnh hiển thị cấu hình YAML để tạo một Service trong Kubernetes Dưới đây là chi tiết các phần chính:

1 apiVersion: o Phiên bản API được sử dụng. o Ở đây: v1 dành cho các Service.

2 kind: o Loại Kubernetes object. o Ở đây: Service.

3 metadata: o Cung cấp thông tin về Service như:

 name: Tên Service là accounts-service.

4 spec: o Định nghĩa trạng thái mong muốn của Service. o selector:

 Chọn các Pod mà Service sẽ định tuyến lưu lượng dựa trên nhãn (label) app: accounts. o type:

 Loại Service, ở đây là ClusterIP, nghĩa là Service chỉ khả dụng trong cụm Kubernetes (nội bộ). o ports:

 protocol: Giao thức mạng, ở đây là TCP.

 port: Cổng mà Service lắng nghe (8080).

 targetPort: Cổng của container mà Service chuyển tiếp lưu lượng

3 Các loại Service trong Kubernetes

 ClusterIP (Mặc định): o Chỉ khả dụng trong nội bộ cụm Kubernetes. o Sử dụng để giao tiếp giữa các ứng dụng bên trong cụm.

 NodePort: o Mở cổng trên mỗi node để truy cập Service từ bên ngoài cụm.

 LoadBalancer: o Tích hợp với các nhà cung cấp dịch vụ đám mây để cung cấp một IP công cộng.

 ExternalName: o Ánh xạ một Service đến một tên miền DNS bên ngoài.

4 Tình huống ứng dụng thực tế

Hệ thống microservices cho phép ứng dụng accounts cung cấp điểm kết nối cố định thông qua service accounts-service, giúp các Pod trong ứng dụng này dễ dàng giao tiếp Điều này cho phép các ứng dụng khác như payments tương tác với accounts mà không cần phải biết địa chỉ IP của từng Pod, tạo điều kiện thuận lợi cho việc quản lý và mở rộng hệ thống.

2 Cân bằng tải nội bộ: o Nếu có nhiều bản sao (replicas) của ứng dụng accounts, Service sẽ phân phối đều lưu lượng đến các Pod, đảm bảo hiệu suất.

3 Tích hợp với CI/CD: o Khi triển khai ứng dụng mới, Service đảm bảo rằng người dùng nội bộ cụm có thể tiếp cận ứng dụng ngay lập tức.

4 Hạn chế truy cập nội bộ: o Với ClusterIP, ứng dụng chỉ khả dụng bên trong cụm, phù hợp cho các ứng dụng nội bộ hoặc backend.

Service trong Kubernetes là một thực thể giúp trừu tượng hóa kết nối mạng giữa các Pods Nó cung cấp:

 Điểm kết nối ổn định cho các ứng dụng dù Pod có thể thay đổi IP.

 Cân bằng tải giữa nhiều bản sao (replica) của Pod.

 Quản lý giao tiếp mạng bên trong cụm hoặc từ bên ngoài.

2 Phân tích file cấu hình trong hình ảnh

 apiVersion: o Xác định phiên bản API cho Kubernetes object. o Ở đây: v1 dành cho các Service.

 kind: o Xác định loại Kubernetes object Ở đây là Service.

 metadata: o Cung cấp thông tin như tên của Service. o Trong file: Tên Service là accounts-service.

 spec: o Định nghĩa trạng thái mong muốn của Service. o selector:

 Kết nối Service với các Pods dựa trên nhãn (label) Nhãn app: accounts chỉ định Service sẽ định tuyến đến Pod có cùng nhãn. o type:

 Loại Service, ở đây là ClusterIP, giới hạn truy cập nội bộ cụm. o ports:

 protocol: Giao thức sử dụng, ở đây là TCP.

 port: Cổng mạng mà Service lắng nghe (8080).

 targetPort: Cổng trong container mà lưu lượng sẽ chuyển tiếp đến (8080).

3 Các loại Service trong Kubernetes

1 ClusterIP: o Chỉ khả dụng trong nội bộ cụm Kubernetes. o Thích hợp cho giao tiếp nội bộ giữa các Pods.

2 NodePort: o Mở một cổng trên mỗi Node để truy cập Service từ bên ngoài cụm. o Thường dùng khi không có LoadBalancer.

3 LoadBalancer: o Kết nối với dịch vụ đám mây để cung cấp địa chỉ IP công cộng. o Phù hợp cho các ứng dụng yêu cầu truy cập từ bên ngoài.

4 ExternalName: o Ánh xạ đến một tên miền DNS bên ngoài thay vì Pod hoặc ClusterIp

1 Tổng quan về hình ảnh

Kubernetes sử dụng Deployment và Service để quản lý và kết nối các Pods trong một cụm (cluster) Quá trình này bao gồm việc triển khai các ứng dụng, tự động mở rộng và duy trì trạng thái mong muốn của các Pods, đồng thời đảm bảo kết nối ổn định giữa chúng thông qua Service.

The Deployment file manifest includes several key components: the apiVersion specifies the API in use (apps/v1), the kind indicates the object type as Deployment, and the metadata section contains essential information such as the Deployment name (accounts-deployment) and labels (app: accounts) Lastly, the spec outlines the desired state and configuration for the Deployment.

 replicas: Số lượng Pod được triển khai (ở đây là 1).

 selector: Sử dụng nhãn (app: accounts) để chọn các Pods thuộc

 template: Định nghĩa cấu hình của Pods, bao gồm:

 Hình ảnh container (eazybytes/accounts:latest).

Chức năng Deployment trong Kubernetes cho phép triển khai, cập nhật và quản lý các Pod một cách hiệu quả Nó đảm bảo rằng số lượng bản sao (replicas) của Pod luôn duy trì đúng theo cấu hình đã định.

 File manifest của Service: o apiVersion: Xác định API được sử dụng (v1). o kind: Loại object là Service. o metadata: Bao gồm thông tin như tên Service (accounts-service). o spec:

 selector: Kết nối Service với Pods có nhãn (app: accounts).

 type: Loại Service, ở đây là ClusterIP, chỉ khả dụng trong cụm.

 port: Cổng bên ngoài Service (8080).

 targetPort: Cổng trong container của Pod (8080).

Service đóng vai trò là một điểm kết nối ổn định, cho phép các ứng dụng khác giao tiếp với Pods mà không cần phải lo lắng về địa chỉ IP của từng Pod.

Bước 3: Liên kết giữa Deployment và Service

 Deployment tạo và quản lý các Pods, mỗi Pod có IP riêng (ví dụ: 10.1.0.1 và 10.1.0.2).

 Service liên kết với các Pods thông qua nhãn (app: accounts) và cung cấp một Cluster IP ổn định (ví dụ: 10.23.12.45) để các dịch vụ khác truy cập.

1 Hệ thống web nhiều tầng

 Frontend: o Một ứng dụng React hoặc Angular có thể giao tiếp với Backend thông qua ClusterIP của Service. o Ví dụ: Gửi yêu cầu API đến http://10.23.12.45:8080.

 Backend: o Một dịch vụ xử lý thanh toán (Payment Service) có thể gửi yêu cầu đến Accounts Service qua Service.

 Khi cập nhật ứng dụng backend, Deployment sẽ tạo Pods mới với phiên bản mới, và Service tự động chuyển hướng lưu lượng đến các Pods mới.

 Nếu số lượng bản sao Pod tăng lên (ví dụ: từ 1 thành 3), Service sẽ phân phối đều lưu lượng đến các Pods để đảm bảo hiệu năng.

Sử dụng Service ClusterIP trong Kubernetes giúp đảm bảo rằng chỉ các dịch vụ nội bộ trong cụm có thể giao tiếp với nhau, từ đó bảo vệ hệ thống khỏi truy cập trái phép từ bên ngoài.

Hình ảnh giải thích ba loại Kubernetes Service phổ biến được sử dụng trong cụm Kubernetes. Mỗi loại có đặc điểm, chức năng, và trường hợp sử dụng riêng.

Dịch vụ mặc định trong Kubernetes là loại Service sử dụng Cluster IP nội bộ để kết nối các Pods, cho phép giao tiếp nội bộ giữa các Pods hoặc các microservices trong cùng một cụm Tuy nhiên, loại dịch vụ này không thể truy cập từ bên ngoài cụm.

 Ứng dụng thực tế: o Hệ thống microservices nội bộ:

Một ứng dụng web thường bao gồm các dịch vụ như Dịch vụ Xác thực và Dịch vụ Cơ sở Dữ liệu, trong đó các dịch vụ này chỉ cần giao tiếp nội bộ trong cụm mà không cần tương tác với bên ngoài Cơ chế xử lý backend đóng vai trò quan trọng trong việc quản lý và xử lý các yêu cầu giữa các dịch vụ này.

 Một dịch vụ xử lý công việc (worker) nhận nhiệm vụ từ hàng đợi tin nhắn (queue) được triển khai trong nội bộ cụm.

Mở cổng Node Port trên mỗi Node trong cụm Kubernetes cho phép lưu lượng từ bên ngoài truy cập vào các Pods Người dùng có thể truy cập thông qua định dạng : Cổng NodePort nằm trong dải mặc định từ 30000 đến 32767, nhưng có thể được cấu hình theo nhu cầu.

Cấu hình đơn giản và dễ thiết lập là những ưu điểm nổi bật, đặc biệt phù hợp cho môi trường kiểm thử Ngoài ra, nó còn cho phép truy cập trực tiếp từ bên ngoài cụm mà không cần thực hiện các cấu hình phức tạp.

 Ứng dụng thực tế: o Kiểm thử nhanh:

Khi kiểm tra một ứng dụng đang trong quá trình phát triển, bạn có thể truy cập trực tiếp từ bên ngoài mà không cần phải triển khai Load Balancer Điều này giúp đơn giản hóa quá trình thử nghiệm và đảm bảo rằng dịch vụ hoạt động độc lập một cách hiệu quả.

 Cung cấp một dịch vụ nhỏ lẻ như API để khách hàng truy cập tạm thời qua