Trong thế giới thực, điều này thật nực cười. Nhưng trong thế giới lập trình Web và API, tình huống này xảy ra thường xuyên đến mức nó trở thành “cơn đau đầu” kinh niên của giới bảo mật. Nó được gọi là IDOR (Insecure Direct Object Reference) hay BOLA (Broken Object Level Authorization).

Nếu bạn là một Backend Developer, và bạn tin rằng chỉ cần có Authentication (Đăng nhập) là hệ thống đã an toàn, thì bài viết này sẽ thay đổi tư duy lập trình của bạn. Chúng ta sẽ không chỉ nói về bề nổi, mà sẽ đi sâu vào bản chất kiến trúc của lỗi này.

1. Bản chất kỹ thuật của IDOR

IDOR (Insecure Direct Object Reference) không chỉ là một lỗi code, nó là một lỗi về thiết kế Logic (Business Logic Flaw).

Trong danh sách OWASP API Security Top 10, IDOR chính là bản chất của lỗ hổng số 1: API1: 2023 Broken Object Level Authorization (BOLA).

Hiểu sâu hơn, IDOR xảy ra khi 3 điều kiện sau hội tụ:

1. Direct Reference: Ứng dụng để lộ mã định danh nội bộ (Internal Identifier) của đối tượng (như Database Primary Key, Filename) trực tiếp ra ngoài URL hoặc Body request.
2. User Input: Ứng dụng tin tưởng và sử dụng trực tiếp đầu vào này để truy vấn dữ liệu.
3. Missing Authorization: Ứng dụng bỏ qua bước kiểm tra quyền truy cập tại thời điểm truy xuất đối tượng.

Sai lầm phổ biến: Nhiều Dev nhầm lẫn giữa Authentication (Bạn là ai?) và Authorization (Bạn được làm gì?). IDOR xảy ra khi bạn đã qua cửa Authentication, nhưng hệ thống quên kiểm tra Authorization ở mức độ đối tượng (Object-level).

2. Giải phẫu cơ chế tấn công

Hãy mổ xẻ một HTTP Request để thấy IDOR có thể lẩn trốn ở đâu. Không chỉ ở URL Parameter, nó có thể nằm ở Header hoặc Body.

Kịch bản: Ứng dụng Chat cho phép người dùng tải lại lịch sử chat.

Request bình thường:

GET /api/v1/messages/history HTTP/1.1
Host: example.com
Cookie: session_id=abc123xyz...
X-User-ID: 1005  <-- IDOR tiềm ẩn ở Header

1. Hacker quan sát: Thấy Header X-User-ID: 1005 được gửi kèm mỗi request.
2. Thử nghiệm: Hacker dùng Postman hoặc Burp Suite để chặn request, sửa X-User-ID thành 1006.
3. Kết quả: Server, thay vì lấy ID từ session an toàn (Server-side), lại tin tưởng lấy ID từ Header (Client-side) để query database SELECT * FROM messages WHERE user_id = 1006.
4. Hậu quả: Hacker đọc được toàn bộ tin nhắn của người dùng 1006.

IDOR có thể xuất hiện ở:

• URL Path: /users/100/profile
• Query Params: /invoices?id=100
• Body (JSON/XML): POST /api/change-password với body {"user_id": 100, "new_pass": "..."}

3. Tại sao IDOR lại là “Sát thủ thầm lặng”?

IDOR nguy hiểm vì tính “hợp lệ” về mặt cú pháp của nó.

• Vượt mặt WAF (Web Application Firewall): Các tường lửa thường chặn các ký tự lạ như ' OR 1=1 -- (SQL Injection) hay <script> (XSS). Nhưng với IDOR, payload chỉ là một con số: id=1006. Đối với WAF, đây là một con số hoàn toàn sạch và hợp lệ.
• Khó phát hiện bằng Automation Tool: Các máy quét (Scanner) không hiểu ngữ cảnh nghiệp vụ. Nếu máy quét gửi id=1006 và nhận về 200 OK, nó đánh dấu là “Thành công”. Nó không biết rằng dữ liệu trả về đó không thuộc về người đang gửi request. Chỉ có con người (Pentesters) hoặc Unit Test được viết kỹ lưỡng mới phát hiện ra.
• Hệ quả dây chuyền: IDOR thường là bước đệm để leo thang đặc quyền (Privilege Escalation), dẫn đến việc chiếm đoạt toàn bộ hệ thống (Account Takeover).

Sự nguy hiểm của IDOR nằm ở chỗ nó là một lỗ hổng logic, không phải lỗ hổng cú pháp. Các công cụ quét bảo mật tĩnh (SAST) truyền thống thường thất bại trong việc phát hiện IDOR vì chúng không thể hiểu ngữ cảnh “ai sở hữu cái gì” trong một ứng dụng cụ thể. Điều này dẫn đến một nghịch lý: trong khi các lỗ hổng kỹ thuật như SQL Injection đang giảm dần nhờ các framework hiện đại, IDOR vẫn tồn tại dai dẳng và chiếm tỷ lệ cao trong các chương trình săn lỗi nhận thưởng (Bug Bounty), đặc biệt là trong các lĩnh vực y tế, chính phủ và dịch vụ chuyên nghiệp.

4. Phân loại IDOR chuyên sâu.

4.1. Leo thang đặc quyền ngang (Horizontal Escalation)

Đây là dạng phổ biến nhất. Người dùng A truy cập dữ liệu của Người dùng B có cùng vai trò.

• Ví dụ: Xem đơn hàng, tải hóa đơn, xem ảnh riêng tư.
• Rủi ro: Rò rỉ thông tin cá nhân (PII Breach), vi phạm GDPR/CCPA.

4.2. Leo thang đặc quyền dọc (Vertical Escalation)

Người dùng thường (User) tìm cách gọi các API dành riêng cho Quản trị viên (Admin/Manager).

• Ví dụ:
  • Hacker tìm thấy API: POST /api/users/1001/roles.
  • Hacker gửi request với body: {"role": "ADMIN"}.
  • Nếu Backend không check xem “người gọi API này có phải là Super Admin không”, Hacker lập tức trở thành Admin.

4.3. IDOR trên File tĩnh (Static File IDOR)

Tên file thường dễ đoán.

• Ví dụ: https://example.com/uploads/receipts/receipt_001.pdf.
• Hacker viết script lặp từ 001 đến 9999 để tải toàn bộ hóa đơn của hệ thống.

5. Dẫn chứng thực tế: Khi “Ông lớn” cũng mắc sai lầm

5.1. McDonald’s & sự cố McHire (7/2025)

Link: https://research.cgu.edu/icdc/2025/07/01/mcdonalds-july-2025-breach/

Bối cảnh: Hệ thống bị ảnh hưởng là McHire, nền tảng tuyển dụng toàn cầu của McDonald’s, được vận hành bởi đối tác công nghệ bên thứ ba là Paradox.ai. Paradox.ai cung cấp giải pháp chatbot AI tên là “Olivia” để tự động hóa quy trình phỏng vấn, thu thập thông tin ứng viên và lên lịch làm việc. Sự phụ thuộc vào bên thứ ba này đã mở rộng bề mặt tấn công của McDonald’s ra ngoài hạ tầng kiểm soát trực tiếp của họ.   

Nguyên nhân chính
Sự cố xảy ra do kết hợp 2 lỗi nghiêm trọng:

1. Xác thực yếu (Weak Authentication)
   • Một tài khoản admin thử nghiệm của Paradox.ai dùng mật khẩu “123456”, không có MFA.
   • Tài khoản này tồn tại từ 2019, không bị vô hiệu hóa dù có quyền truy cập production.
2. Lỗ hổng IDOR (Missing Object Level Authorization)
   • API backend cho phép truy xuất hồ sơ ứng viên bằng applicant_id.
   • Không kiểm tra quyền truy cập → chỉ cần đổi ID là đọc được dữ liệu của bất kỳ ứng viên nào.
   • Từ 1 tài khoản → mở rộng ra 64 triệu hồ sơ toàn cầu.

Tác động

• Rò rỉ PII: tên, email, số điện thoại, địa chỉ nhà.
• Lộ dữ liệu nhạy cảm: log chat với AI (tính cách, sở thích, thông tin cá nhân).
• Lộ token phiên → có thể giả danh ứng viên.
• Nguy cơ cao cho social engineering, lừa đảo, chiếm tài khoản.

Sự kết hợp giữa quản lý tài khoản kém (tài khoản ma, không MFA) và thiếu kiểm soát quyền API (IDOR) tạo ra “cơn bão hoàn hảo” cho rò rỉ dữ liệu quy mô toàn cầu – một xu hướng cực kỳ đáng báo động trong năm 2025

5.2. Mozilla Firefox Accounts – Lỗ hổng xóa tài khoản (5/2025)

Link: https://hackerone.com/reports/3154983

Bản chất sự cố

• Lỗ hổng IDOR nghiêm trọng trong API xóa tài khoản (/v1/account/destroy).
• Cho phép xóa vĩnh viễn tài khoản người khác mà không cần tương tác từ nạn nhân (zero-click).
• Ảnh hưởng trực tiếp đến Integrity (toàn vẹn) và Availability (sẵn sàng) của dữ liệu.

Nguyên nhân kỹ thuật

• Lỗi Session Misbinding: backend không kiểm tra phiên làm việc có khớp với tài khoản bị xóa hay không.
• API tin vào payload JSON (email, authPW) thay vì session của người gửi request.
• Đây là dạng IDOR ghi/xóa, nguy hiểm hơn IDOR đọc dữ liệu.

Kịch bản khai thác

1. Kẻ tấn công tạo tài khoản Firefox, đăng nhập bằng SSO (Google).
2. Chặn request xóa tài khoản của chính mình.
3. Đổi email trong payload thành email nạn nhân (cũng dùng SSO, chưa set mật khẩu).
4. Gửi request → hệ thống xóa tài khoản nạn nhân.

Tác động

• Mất vĩnh viễn dữ liệu: mật khẩu đã lưu, lịch sử duyệt web, tab, sync data.
• Không thể khôi phục, không cần nạn nhân click hay xác nhận.
• Được đánh giá Critical trên HackerOne.

Bài học cốt lõi: IDOR không chỉ gây rò rỉ dữ liệu (read) mà còn có thể phá hủy dữ liệu (write/delete) nếu backend không ràng buộc chặt chẽ giữa session và đối tượng tài nguyên.

5.3. GitLab – Lỗ hổng Machine Learning Model Registry (2024–2025)

Link: https://hackerone.com/reports/2528293

Bối cảnh

• GitLab triển khai Machine Learning Model Registry để quản lý phiên bản mô hình AI.
• Lỗ hổng được báo cáo từ 5/2024, vá và công bố kéo dài sang 2025, cho thấy độ phức tạp của bảo mật trên nền tảng lớn.
• Sự cố ảnh hưởng trực tiếp đến tài sản trí tuệ AI (model weights, biases).

Nguyên nhân kỹ thuật

• GitLab dùng ID tịnh tiến (1,2,3,…) cho model_id thay vì UUID ngẫu nhiên.
• API tải/xem mô hình không kiểm tra quyền truy cập dự án (Missing Object Level Authorization).
• Đây là IDOR điển hình + thiết kế API kém an toàn.

Cách khai thác

• Kẻ tấn công chỉ cần tài khoản GitLab miễn phí.
• Lặp ID từ 1 → hàng triệu để liệt kê và tải mô hình của dự án khác.
• Không cần brute-force, không cần quyền dự án.

Tác động

• Rò rỉ mô hình ML độc quyền của doanh nghiệp.
• Nguy cơ mất bí mật thương mại, thiệt hại kinh tế lớn trong bối cảnh AI là tài sản cốt lõi.
• Lỗ hổng có thể bị khai thác tự động, quy mô lớn (enumeration).

Bài học cốt lõi: Không dùng ID tịnh tiến cho API công khai. Nó biến IDOR từ lỗ hổng tiềm ẩn thành thảm họa có thể khai thác hàng loạt, đặc biệt nguy hiểm với tài sản AI.

6. Ngăn chặn IDOR hiệu quả (Best Practices)

Khi một tài khoản test có thể mở khóa 64 triệu hồ sơ, một email có thể xóa tài khoản người khác, và một con số tăng dần có thể làm bay cả mô hình AI, thì rõ ràng vấn đề không nằm ở “hacker quá giỏi” — mà ở chỗ chúng ta cần chặn IDOR cho đúng cách.

“Đừng bao giờ tin tưởng Client”. Dưới đây là chiến lược phòng thủ đa lớp (Defense in Depth).

Lớp 1: Kiểm soát truy cập tại tầng Data (Data-Layer Authorization)

Đây là chốt chặn cuối cùng và quan trọng nhất. Mọi câu lệnh truy vấn liên quan đến dữ liệu người dùng phải kèm theo điều kiện về chủ sở hữu.

❌ Code rủi ro (Spring Data JPA):

// Controller
public Order getOrder(@PathVariable Long id) {
    return orderRepo.findById(id); // Chỉ tìm theo ID đơn hàng
}

✅ Code an toàn (Repository Pattern):

// Repository
// Luôn gắn kèm userId vào câu query
@Query("SELECT o FROM Order o WHERE o.id = :id AND o.owner.id = :currentUserId")
Optional<Order> findByIdAndOwner(@Param("id") Long id, @Param("currentUserId") Long userId);

// Service Layer
public Order getOrder(Long id, User currentUser) {
    return orderRepo.findByIdAndOwner(id, currentUser.getId())
        .orElseThrow(() -> new ResourceNotFoundException("Order not found or access denied"));
}

Lớp 2: Kiểm soát truy cập tại tầng Controller (Method-Level Security)

Sử dụng các Annotation bảo mật của Framework (như Spring Security) để chặn ngay từ cửa vào.

✅ Ví dụ với Spring Security (@PreAuthorize):

@GetMapping("/invoices/{id}")
// SpEL: Chỉ cho phép nếu user hiện tại là chủ sở hữu của invoice có id này
@PreAuthorize("@securityService.isOwner(authentication, #id)") 
public Invoice getInvoice(@PathVariable Long id) {
    return invoiceRepo.findById(id);
}

Cách này giúp code business logic sạch hơn, tách biệt logic bảo mật ra khỏi logic nghiệp vụ.

Lớp 3: Làm khó Hacker bằng UUID (Obfuscation)

Thay vì dùng Auto-Increment Integer (1, 2, 3), hãy dùng UUID (Random String: a0eebc99-9c0b...) hoặc các thuật toán băm ID (như Hashids).

• Lợi ích: Chặn đứng tấn công kiểu liệt kê (Enumeration Attack). Hacker không thể viết vòng lặp for (i=0; i<1000; i++) để quét dữ liệu.
• Cảnh báo: UUID KHÔNG THỂ THAY THẾ được Lớp 1 và Lớp 2. Nếu hacker bằng cách nào đó biết được UUID của nạn nhân, IDOR vẫn xảy ra nếu thiếu Authorization check. UUID chỉ là “lớp sương mù”, không phải “bức tường thép”.

Lớp 4: Kiểm thử tự động (Automated Security Testing)

Đừng đợi Pentester tìm lỗi. Hãy viết Test Case cho IDOR.

• Unit Test: Tạo 2 user (Alice, Bob). Đăng nhập bằng Alice, cố gắng request dữ liệu ID của Bob. Assert rằng kết quả trả về phải là 403 Forbidden hoặc 404 Not Found.

7. Kết luận

IDOR không phải là một lỗi kỹ thuật phức tạp, nhưng nó phản ánh sự thiếu sót trong tư duy thiết kế hệ thống.

Hãy nhớ nguyên tắc vàng: Mọi request truy cập dữ liệu đều phải trả lời được hai câu hỏi:

1. Người dùng này là ai? (Authentication)
2. Dữ liệu này có phải của họ không? (Authorization)

Nếu thiếu câu hỏi số 2, chúng ta đang mở toang cánh cửa “phòng 102” cho bất kỳ ai cầm chìa khóa “phòng 101”.

The post IDOR – Lỗ hổng “ngây thơ” nhưng chí mạng trong kiến trúc phần mềm? appeared first on Tomoshare.

Bảo mật luôn là yếu tố cốt lõi trong quá trình phát triển ứng dụng, đặc biệt khi bạn phải xử lý việc xác thực và phân quyền cho nhiều người dùng khác nhau.

Dù các developer hoàn toàn có thể tự xây dựng hệ thống quản lý danh tính từ con số 0, nhưng việc này tốn rất nhiều thời gian, công sức và dễ phát sinh lỗi – nhất là khi phải hỗ trợ các giao thức tiêu chuẩn như OAuth2 hay OpenID Connect.

Keycloak xuất hiện như một giải pháp giúp đơn giản hóa toàn bộ quá trình này. Nó không chỉ giảm tải việc triển khai xác thực mà còn mang đến sự đồng nhất, bảo mật cao và khả năng tùy biến mạnh mẽ. Bạn có thể tích hợp đăng nhập bằng Google, Facebook hoặc thiết lập SSO chỉ trong vài bước cấu hình mà không cần viết lại cả hệ thống.

1. What? Keycloak là gì?

Keycloak là một nền tảng mã nguồn mở mạnh mẽ, cung cấp giải pháp đăng nhập một lần (SSO) cùng hệ thống quản lý danh tính và quyền truy cập cho các ứng dụng và dịch vụ.

Nền tảng này được thiết kế nhằm đơn giản hóa toàn bộ bài toán bảo mật, giúp developer dễ dàng tích hợp cơ chế đăng nhập, phân quyền và xác thực vào ứng dụng mà không phải xây dựng mọi thứ từ đầu. Tất cả đều được Keycloak cung cấp sẵn dưới dạng các tính năng linh hoạt, dễ tùy chỉnh để phù hợp với nhu cầu của từng doanh nghiệp hay tổ chức.

Keycloak cho phép bạn tùy chỉnh giao diện người dùng cho các trang đăng nhập, đăng ký, quản lý tài khoản hay trang quản trị. Bên cạnh đó, nó còn hỗ trợ tích hợp với các hệ thống quản lý danh tính sẵn có như LDAP hoặc Active Directory, và cho phép xác thực thông qua các nhà cung cấp bên thứ ba như Google hay Facebook.

Tóm lại: đối với developer, Keycloak giống như một “bộ công cụ all-in-one” để giải quyết toàn bộ vấn đề liên quan đến đăng nhập và phân quyền. Thay vì tự xây các tính năng như login, role-based access hay kết nối với các nền tảng bên ngoài, bạn chỉ cần cấu hình và sử dụng những gì Keycloak đã cung cấp.

Luồng hoạt động:
+ Spring Boot kiểm tra Token và cho phép truy cập nếu hợp lệ.
+ User đăng nhập vào Keycloak.
+ Keycloak trả về Token.
+ User gửi request kèm Token đến Spring Boot.

2. Why? Tại sao lại là Keycloak?

Thay vì tự xây dựng module đăng nhập (Login) trong Spring Boot, việc sử dụng Keycloak mang lại các lợi ích:

a. Quản lý tập trung: Admin có thể khóa user, đổi password, cấp quyền ngay trên giao diện Keycloak mà không cần sửa code hay database của ứng dụng.

b. Bảo mật chuyên sâu (Delegated Authentication): Việc xử lý mật khẩu, mã hóa, 2FA (xác thực 2 bước) được Keycloak đảm nhận. Spring Boot không cần lo về lộ mật khẩu.

c. Single Sign-On (SSO): Nếu bạn có 10 ứng dụng (Microservices), user chỉ cần đăng nhập 1 lần tại Keycloak là vào được cả 10 ứng dụng.

d. Chuẩn hóa (Standardization): Sử dụng giao thức OAuth2 và OpenID Connect chuẩn quốc tế. Dễ dàng tích hợp với Frontend (React, Angular, Mobile App).

3. Các thành phần chính trong Keycloak

3.1. Realm (Không gian quản lý)

Định nghĩa: Realm là một không gian quản lý định danh hoàn toàn độc lập. Dữ liệu (user, role, client) của Realm A hoàn toàn tách biệt với Realm B.

Master Realm: Khi cài đặt xong, Keycloak có sẵn realm tên là Master. Đây là realm dùng để quản trị hệ thống Keycloak. Không nên dùng realm này để quản lý user cho ứng dụng của bạn.

Ví dụ: Bạn có thể tạo Realm Users cho người dùng cuối và Realm Admins cho site quản trị.

3.2. Client (Ứng dụng khách)

Định nghĩa: Client là các ứng dụng hoặc dịch vụ muốn sử dụng Keycloak để xác thực. Client đại diện cho các ứng dụng hoặc dịch vụ được bảo mật bởi Keycloak. Mỗi client có cấu hình riêng, bao gồm giao thức (OAuth2, OpenID Connect), URL callback, và thông tin bảo mật như client secret.

3.3. User (Người dùng)

Định nghĩa: Thực thể có thể đăng nhập vào hệ thống.

Thuộc tính: User có Username, Password, Email, và các thuộc tính tùy chỉnh (Attributes) như số điện thoại, mã nhân viên, phòng ban…

Keycloak hỗ trợ các phương thức xác thực đa dạng:
– Đăng nhập bằng email/mật khẩu.
– Đăng nhập qua các nhà cung cấp bên thứ ba (Google, Facebook).
– Xác thực hai yếu tố (2FA).

3.4. Role (Vai trò)

Role dùng để phân quyền (Authorization). Có 2 loại Role trong Keycloak:
– Realm Role: Role toàn cục. Ví dụ: Global_Admin, User. Có hiệu lực trên toàn bộ Realm.
– Client Role: Role gắn liền với một Client cụ thể. Ví dụ: Client Inventory-App có role stock-keeper. Role này chỉ có ý nghĩa với app kho, không có ý nghĩa với app nhân sự.

3.5. Group (Nhóm)

Định nghĩa: Dùng để gom nhóm các User lại.

Đặc điểm: Group có thể lồng nhau (Parent – Child). Ví dụ: IT Department -> Dev Team.

Tác dụng: Bạn có thể gán Role cho Group, tất cả User trong Group đó sẽ tự động kế thừa Role. Giúp quản lý quyền hạn dễ dàng hơn gán lẻ tẻ.

4. How? Làm thế nào để tích hợp Keycloak vào 1 ứng dụng Spring Boot chỉ trong vài bước đơn giản.

Phần A: Cấu hình Keycloak (Docker)
Bước 1: Khởi chạy Keycloak Mở terminal và chạy lệnh Docker (bản developer):

docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:24.0.1 start-dev

Bước 2: Thiết lập Realm và Client

1. Truy cập http://localhost:8080 -> Vào Administration Console (Login: admin/admin).
2. Tạo Realm: Bấm vào dropdown menu góc trái -> Create Realm -> Tên: springboot-demo.
3. Tạo Client:
   – Vào menu Clients -> Create client.
   – Client ID: my-backend-api.
   – Capability config: Bật Client authentication (để có Client Secret) và Authorization.
   – Lưu lại.
4. Tạo Roles:
   – Vào menu Realm roles -> Create role.
   – Tạo 2 role: USER và ADMIN.

Phần B: Lập trình Spring Boot (Resource Server)
Bước 1: Dependencies (pom.xml) Cần Java 17+ và Spring Boot 3.x.

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <!-- Thư viện quan trọng nhất để biến App thành Resource Server -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
</dependencies>

Bước 2: Cấu hình (application.yml) Khai báo địa chỉ của Keycloak để Spring Boot biết nơi xác thực token.

server:
  port: 5000 # Chạy port khác Keycloak

spring:
  application:
    name: keycloak-integration-demo
  security:
    oauth2:
      resourceserver:
        jwt:
          # Đường dẫn Issuer của Realm (Quan trọng)
          # Cấu trúc: http://<host>:<port>/realms/<realm-name>
          issuer-uri: http://localhost:8080/realms/springboot-demo
          # jwk-set-uri sẽ được tự động cấu hình từ issuer-uri

Bước 3: Class SecurityConfig.java (Quan trọng nhất) Mặc định Keycloak trả về role trong JSON phức tạp, ta cần convert nó về dạng ROLE_ABC để Spring Security hiểu.

package com.example.demo.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import 
org.springframework.security.config.annotation.method.configuration.EnableMethodSecurity;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.oauth2.server.resource.authentication.JwtAuthenticationConverter;
import org.springframework.security.oauth2.server.resource.authentication.JwtGrantedAuthoritiesConverter;
import org.springframework.security.web.SecurityFilterChain;

import java.util.Collection;
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;

@Configuration
@EnableWebSecurity
@EnableMethodSecurity // Cho phép dùng @PreAuthorize ở Controller
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf.disable()) // Tắt CSRF cho API
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/public/**").permitAll() // API public không cần token
                .anyRequest().authenticated() // Các API còn lại yêu cầu phải login
            )
            .oauth2ResourceServer(oauth2 -> oauth2
                .jwt(jwt -> jwt.jwtAuthenticationConverter(jwtAuthenticationConverter()))
            );
        
        return http.build();
    }

    // Converter: Biến đổi thông tin từ JWT Keycloak sang Spring Security Authority
    @Bean
    public JwtAuthenticationConverter jwtAuthenticationConverter() {
        JwtAuthenticationConverter converter = new JwtAuthenticationConverter();
        converter.setJwtGrantedAuthoritiesConverter(source -> {
            // Lấy map roles từ claim "realm_access" của Keycloak
            Map<String, Object> realmAccess = source.getClaimAsMap("realm_access");
            
            if (realmAccess == null || !realmAccess.containsKey("roles")) {
                return List.of();
            }

            List<String> roles = (List<String>) realmAccess.get("roles");
            
            // Convert: [USER, ADMIN] -> [ROLE_USER, ROLE_ADMIN]
            return roles.stream()
                    .map(role -> new org.springframework.security.core.authority.SimpleGrantedAuthority("ROLE_" + role))
                    .collect(Collectors.toList());
        });
        return converter;
    }
}

Bước 4: Class DemoController.java

package com.example.demo.controller;

import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DemoController {

    @GetMapping("/public/hello")
    public String hello() {
        return "Public: Xin chào, ai cũng xem được!";
    }

    @GetMapping("/user/profile")
    @PreAuthorize("hasRole('USER')")
    public String userProfile() {
        return "Secured: Đây là trang dành cho User có role USER.";
    }

    @GetMapping("/admin/dashboard")
    @PreAuthorize("hasRole('ADMIN')")
    public String adminDashboard() {
        return "Secured: Đây là trang quản trị (ADMIN ONLY).";
    }
}

4. RESULT: Kiểm thử hoạt động

Sử dụng Postman để demo luồng OAuth2.

Bước 1: Lấy Token từ Keycloak (Login)
– URL: http://localhost:8080/realms/springboot-demo/protocol/openid-connect/token
– Body (x-www-form-urlencoded):
+ client_id: my-backend-api
+ client_secret: (Lấy trong Keycloak: Clients -> my-backend-api -> Credentials)
+ grant_type: password
+ username: testuser
+ password: 123
– Kết quả: Bạn nhận được JSON chứa access_token. Copy chuỗi này.

Bước 2: Gọi API bảo mật
– URL: http://localhost:8081/user/profile
– Authorization Tab: Chọn type Bearer Token và dán access token vào.
– Kết quả:
+ Nếu token hợp lệ: Trả về Secured: Đây là trang dành cho User... (Status 200).
+ Nếu không gửi token: 401 Unauthorized.

Kết luận: Bạn đã xây dựng thành công một hệ thống bảo mật hiện đại, tách biệt hoàn toàn Resource Server và Authorization Server, tuân thủ chuẩn OAuth2.

The post Keycloak: Giải pháp IAM toàn diện cho ứng dụng hiện đại appeared first on Tomoshare.

1. Helidon là gì?

1.1. Giới thiệu tổng quan

Helidon là một bộ công cụ Java microservices do Oracle phát triển, tập trung vào hiệu suất, tính gọn nhẹ và khả năng triển khai linh hoạt. Helidon cho phép xây dựng ứng dụng cloud-native theo chuẩn Jakarta EE, MicroProfile hoặc theo kiểu lập trình phản ứng

1.2. Hai “flavor” của Helidon: SE và MP

Helidon SE: Lập trình thủ công theo style functional, phù hợp với ứng dụng hiệu suất cao, yêu cầu kiểm soát chi tiết.

Helidon MP: Tuân theo chuẩn MicroProfile, tương thích quen thuộc với mô hình enterprise Java (JAX-RS, CDI, Metrics, Config). Đây là lựa chọn gần nhất với Spring Boot.

1.3. Những điểm nổi bật

• Khởi động nhanh và sử dụng ít tài nguyên.
• Thiết kế dành cho microservices và cloud-native.
• Tích hợp tốt các tiêu chuẩn Jakarta & MicroProfile.
• Cấu hình đơn giản, dễ triển khai.

1.4. Môi trường và khả năng tích hợp

Helidon hoạt động tốt trong môi trường container, Kubernetes, hỗ trợ OpenTelemetry, GraalVM và dễ kết nối với các dịch vụ bên ngoài như databases, messaging hoặc service mesh.

2. Tại sao nên cân nhắc chuyển từ Spring Boot sang Helidon

2.1. Hiệu suất và footprint

Helidon có footprint nhỏ hơn Spring Boot và thời gian khởi động nhanh, phù hợp cho scaling tự động và serverless.

2.2. Microservices và khả năng quan sát

MicroProfile mang theo sẵn metrics, health check, config và fault tolerance, giúp theo dõi và vận hành dịch vụ rõ ràng hơn.

2.3. Native-image với GraalVM

Helidon hỗ trợ native-image tốt, mang lại tốc độ khởi động gần tức thì và giảm tối đa tiêu thụ CPU/RAM.

2.4. Lợi thế khi dùng AI

AI giúp tự động chuyển đổi mã, giảm sai sót, tăng tốc độ refactor và đồng bộ hóa kiến trúc từ Spring Boot sang Helidon.

Nguồn : https://medium.com/oracledevs/framework-choice-strategy-when-to-use-spring-boot-vs-helidon-in-cloud-native-microservices-ab6e288b9821

3 Chuyển đổi Spring Boot sang Helidon bằng AI

3.1 Tạo Workspace chuyển đổi

Mở Terminal và chạy:

mkdir spring-to-helidon
cd spring-to-helidon

Thư mục này sẽ chứa toàn bộ converter và output chuyển đổi.

3.2 Clone dự án spring boot mẫu

Chúng ta sử dụng Spring Petclinic để làm mẫu (bạn có thể thay bằng dự án của bạn).

git clone https://github.com/spring-projects/spring-petclinic.git

Cấu trúc được tạo:

spring-to-helidon/
 └── spring-petclinic/

3.3 Tạo bộ CONVERTER AI

mkdir converter
cd converter
mkdir prompts
mkdir output

Trong đó :

• prompts/ → chứa các prompt hướng dẫn AI convert
• output/ → nơi lưu file đã chuyển đổi

3.4 Tạo prompt chuyển đổi chuyên biệt cho từng loại File

Mỗi loại file cần một hướng dẫn riêng để AI convert chính xác.

3.4.1 Prompt cho Controller

nano prompts/controller.txt

You are converting a Spring Boot REST Controller to a Helidon MP JAX-RS resource.

Rules:
- Replace @RestController with @Path and @ApplicationScoped.
- Replace @GetMapping, @PostMapping, @PutMapping, @DeleteMapping with @GET, @POST, @PUT, @DELETE.
- Replace @Autowired with @Inject (CDI).
- Remove all Spring imports.
- Keep logic unchanged.
- Output FULL source file.

3.4.2 Prompt cho Service

nano prompts/service.txt

Convert Spring Service into CDI bean for Helidon MP.

Rules:
- Replace @Service with @ApplicationScoped.
- Replace @Autowired with @Inject.
- Remove Spring imports.
- Output full file.

3.4.3 Prompt cho Repository

nano prompts/repo.txt

Convert a Spring Data repository to a Helidon MP-compatible JPA repository.

Rules:
- Remove Spring Data interfaces.
- Replace query methods (findBy…) with JPQL.
- Use @ApplicationScoped and @Inject.
- Output full file.

3.4.4 Prompt cho Entity

nano prompts/entity.txt

Convert a Spring JPA Entity into Helidon MP Entity using Jakarta Persistence.

Rules:
- Keep @Entity, @Id, @GeneratedValue.
- Remove Lombok annotations.
- Replace org.springframework imports with jakarta.
- Output full file.

3.4.5 Prompt cho pom.xml

nano prompts/pom.txt

Convert Spring Boot pom.xml to Helidon MP pom.xml.

Replace:
- spring-boot-starter-* with helidon-microprofile modules
- Use jakarta dependencies
Return a valid Maven pom.xml

3.5 Tạo script phân loại file (classifier)

AI cần biết:
→ file nào là Controller?
→ Service?
→ Repository?
→ Entity?

3.5.1 Tạo file classify.py

nano classify.py

Code:

import os

def classify(path):
    text = open(path).read()

    if path.endswith("pom.xml"):
        return "pom"

    if "@RestController" in text:
        return "controller"

    if "JpaRepository" in text or "CrudRepository" in text:
        return "repo"

    if "@Service" in text or "@Component" in text:
        return "service"

    if "@Entity" in text:
        return "entity"

    return "java"

if __name__ == "__main__":
    base_dir = "../spring-petclinic"
    
    for root, dirs, files in os.walk(base_dir):
        for file in files:
            if file.endswith(".java") or file.endswith("pom.xml"):
                path = os.path.join(root, file)
                ftype = classify(path)
                print(f"{path}:{ftype}")

Chạy để test:

python3 classify.py

3.6 Script gọi OpenAI và chuyển đổi code

3.6.1 Export key

Sau đó:

export OPENAI_API_KEY="YOUR_API_KEY"

3.6.2 Tạo convert.py

nano convert.py

Code:

import os
from openai import OpenAI
from concurrent.futures import ThreadPoolExecutor, as_completed
from threading import Lock
import time
from datetime import datetime

# Support multiple API providers via environment variables
# Default to Ollama if available, otherwise use DeepSeek
api_key = (os.getenv("OPENAI_API_KEY") or "").strip()
base_url = (os.getenv("OPENAI_BASE_URL") or "").strip()
model_name = os.getenv("MODEL_NAME", "").strip()

# Auto-detect Ollama if not explicitly set
if not base_url:
    # Check if Ollama is running
    import socket
    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(1)
        result = sock.connect_ex(('localhost', 11434))
        sock.close()
        if result == 0:
            # Ollama is running, use it as default
            base_url = "http://localhost:11434/v1"
            model_name = model_name or "llama3"
            api_key = api_key or "ollama"
            print("ℹ Auto-detected Ollama, using it as default")
    except:
        pass
    
    # Fallback to DeepSeek if Ollama not available
    if not base_url:
        base_url = "https://api.deepseek.com"
        model_name = model_name or "deepseek-chat"
        if not api_key:
            print("⚠ Warning: Using DeepSeek default. Set OPENAI_API_KEY for Ollama or other providers.")

if not api_key:
    raise ValueError("OPENAI_API_KEY environment variable is not set")

client = OpenAI(
    api_key=api_key,
    base_url=base_url
)

PROMPTS = {
    "controller": "prompts/controller.txt",
    "repo": "prompts/repo.txt",
    "service": "prompts/service.txt",
    "entity": "prompts/entity.txt",
    "pom": "prompts/pom.txt",
    "java": "prompts/entity.txt"  # fallback
}

# Thread-safe counters for progress tracking
success_lock = Lock()
error_lock = Lock()
progress_lock = Lock()
success_count = 0
error_count = 0
completed_count = 0
start_time = None

def print_progress(completed, total, current_file=None):
    """Print progress with percentage and time estimate"""
    global start_time
    if total == 0:
        return
    
    percentage = (completed / total) * 100
    elapsed = time.time() - start_time if start_time else 0
    
    if completed > 0 and elapsed > 0:
        avg_time = elapsed / completed
        remaining = total - completed
        eta_seconds = avg_time * remaining
        eta_str = f"ETA: {int(eta_seconds//60)}m {int(eta_seconds%60)}s"
    else:
        eta_str = "Calculating..."
    
    elapsed_str = f"{int(elapsed//60)}m {int(elapsed%60)}s"
    
    bar_length = 30
    filled = int(bar_length * completed / total)
    bar = "█" * filled + "░" * (bar_length - filled)
    
    status = f"[{bar}] {completed}/{total} ({percentage:.1f}%) | {elapsed_str} elapsed | {eta_str}"
    if current_file:
        filename = os.path.basename(current_file)
        status += f" | Processing: {filename}"
    
    print(f"\r{status}", end="", flush=True)


def convert(path, ftype, max_retries=3):
    file_start_time = time.time()
    prompt = open(PROMPTS[ftype]).read()
    code = open(path).read()
    
    # Calculate dynamic timeout based on file size
    # Base timeout: 60s, add 2s per KB of code
    code_size_kb = len(code) / 1024
    base_timeout = 60
    dynamic_timeout = int(base_timeout + (code_size_kb * 2))
    # Cap at 10 minutes for very large files
    timeout = min(dynamic_timeout, 600)

    messages = [
        {"role": "system", "content": prompt},
        {"role": "user", "content": code},
    ]

    last_error = None
    for attempt in range(max_retries):
        try:
            # Add small delay between retries
            if attempt > 0:
                wait_time = min(2 ** attempt, 10)  # Exponential backoff, max 10s
                time.sleep(wait_time)
                print(f"  ↻ Retry {attempt}/{max_retries-1} for {os.path.basename(path)}...")
            
            # Call API (supports multiple providers)
            result = client.chat.completions.create(
                model=model_name,
                temperature=0,
                messages=messages,
                timeout=timeout
            )

            output = result.choices[0].message.content

            # Tạo file output theo cấu trúc map
            out_path = "output/" + path.replace("../spring-petclinic/", "")
            os.makedirs(os.path.dirname(out_path), exist_ok=True)
            with open(out_path, "w") as f:
                f.write(output)

            elapsed = time.time() - file_start_time
            return True, elapsed
        except Exception as e:
            last_error = e
            error_msg = str(e)
            # If it's not a timeout, don't retry
            if "timeout" not in error_msg.lower() and "timed out" not in error_msg.lower():
                elapsed = time.time() - file_start_time
                return False, elapsed, error_msg
            # For timeout, continue to retry
    
    # All retries failed
    elapsed = time.time() - file_start_time
    return False, elapsed, str(last_error)


def convert_with_counter(path, ftype, total, skip_existing=True):
    global success_count, error_count, completed_count
    
    # Check if output file already exists
    if skip_existing:
        out_path = "output/" + path.replace("../spring-petclinic/", "")
        if os.path.exists(out_path) and os.path.getsize(out_path) > 0:
            with progress_lock:
                completed_count += 1
                success_count += 1
                filename = os.path.basename(path)
                print(f"\n⊘ [{completed_count}/{total}] {filename} (skipped - already exists)")
                print_progress(completed_count, total)
            return True
    
    result_data = convert(path, ftype)
    
    if len(result_data) == 2:
        success, elapsed = result_data
        error_msg = None
    else:
        success, elapsed, error_msg = result_data
    
    with progress_lock:
        completed_count += 1
        
        if success:
            success_count += 1
            status = "✔"
        else:
            with error_lock:
                error_count += 1
            status = "✗"
        
        # Print detailed result on new line
        filename = os.path.basename(path)
        if success:
            print(f"\n{status} [{completed_count}/{total}] {filename} ({elapsed:.1f}s)")
        else:
            if error_msg:
                if "402" in error_msg or "Insufficient Balance" in error_msg:
                    print(f"\n{status} [{completed_count}/{total}] {filename} - Insufficient Balance")
                elif "401" in error_msg or "Unauthorized" in error_msg:
                    print(f"\n{status} [{completed_count}/{total}] {filename} - Invalid API key")
                elif "timeout" in error_msg.lower():
                    print(f"\n{status} [{completed_count}/{total}] {filename} - Timeout ({elapsed:.1f}s)")
                else:
                    print(f"\n{status} [{completed_count}/{total}] {filename} - Error: {error_msg[:50]}")
            else:
                print(f"\n{status} [{completed_count}/{total}] {filename} - Failed")
        
        # Update progress bar
        print_progress(completed_count, total)
    
    return success


# Cho phép chạy convert thủ công
if __name__ == "__main__":
    import sys
    
    print(f"Using API: {base_url}")
    print(f"Using model: {model_name}")
    print()
    
    if len(sys.argv) == 3:
        result_data = convert(sys.argv[1], sys.argv[2])
        if len(result_data) == 2:
            success, elapsed = result_data
            if success:
                print(f"✔ Converted in {elapsed:.1f}s")
            else:
                print(f"✗ Failed in {elapsed:.1f}s")
        else:
            success, elapsed, error_msg = result_data
            print(f"✗ Error: {error_msg}")
    else:
        success_count = 0
        error_count = 0
        completed_count = 0
        start_time = time.time()
        
        # Parse file list
        tasks = []
        with open("file-list.txt", "r") as f:
            for line in f:
                line = line.strip()
                if not line:
                    continue
                # Support both formats: "path:type" and "path type"
                if ":" in line:
                    parts = line.split(":", 1)
                else:
                    parts = line.rsplit(None, 1)  # Split on last whitespace
                
                if len(parts) == 2:
                    path, ftype = parts
                    path = path.strip()
                    ftype = ftype.strip()
                    tasks.append((path, ftype))
                else:
                    print(f"⚠ Skipped invalid line: {line[:50]}...")
        
        total = len(tasks)
        # Reduce default workers to avoid overwhelming Ollama
        # Ollama can be slow with too many concurrent requests
        max_workers = int(os.getenv("MAX_WORKERS", "2"))
        
        print(f"Found {total} files to convert")
        print(f"Using {max_workers} parallel workers (reduce if getting timeouts)")
        print(f"Timeout: 60s base + 2s per KB (max 10min)")
        print(f"Retries: 3 attempts per file")
        print(f"Started at {datetime.now().strftime('%H:%M:%S')}\n")
        
        # Initialize progress bar
        print_progress(0, total)
        
        # Use ThreadPoolExecutor for parallel processing
        # Add small delay between submissions to avoid overwhelming the API
        with ThreadPoolExecutor(max_workers=max_workers) as executor:
            futures = []
            for idx, (path, ftype) in enumerate(tasks):
                future = executor.submit(convert_with_counter, path, ftype, total)
                futures.append(future)
                # Small delay to avoid overwhelming Ollama
                if idx < len(tasks) - 1:
                    time.sleep(0.5)
            
            # Wait for all tasks to complete
            for future in as_completed(futures):
                try:
                    future.result()
                except Exception as e:
                    with progress_lock:
                        completed_count += 1
                        error_count += 1
                        print(f"\n✗ Unexpected error: {e}")
                        print_progress(completed_count, total)
        
        # Final summary
        total_time = time.time() - start_time
        print(f"\n\n{'='*60}")
        print(f"Summary:")
        print(f"  ✓ Succeeded: {success_count}")
        print(f"  ✗ Failed:    {error_count}")
        print(f"  ⏱ Total time: {int(total_time//60)}m {int(total_time%60)}s")
        if success_count > 0:
            avg_time = total_time / success_count
            print(f"  📊 Avg time/file: {avg_time:.1f}s")
        print(f"{'='*60}")

3.7 Chạy chuyển đổi

3.7.1 Xuất danh sách file cần convert

python3 classify.py > file-list.txt

3.7.2 Chạy convert tự động toàn bộ project

python3 convert.py

Kết quả sẽ được lưu ở :

converter/output/

3.8 Tạo project helidon và ghép code

Tạo Helidon MP project:

cd ..
mvn archetype:generate -DinteractiveMode=false \
  -DarchetypeGroupId=io.helidon.archetypes \
  -DarchetypeArtifactId=helidon-mp

Sau đó copy code đã chuyển đổi vào project Helidon.

mvn package
java -jar target/*.jar

3.9 Kết quả

4. Kết luận

AI chắc chắn đang trở thành một phần cốt lõi trong cuộc sống của chúng ta, làm thay đổi cách chúng ta tiếp cận lập trình. Nhiệm vụ chuyển đổi một dự án từ framework này sang framework khác vốn phức tạp giờ đây đã trở nên dễ dàng hơn rất nhiều với sự trợ giúp của AI, giúp tiết kiệm thời gian và tài nguyên, đồng thời mang lại hiệu quả chi phí cao.

Tuy nhiên, các bộ chuyển đổi này không chỉ giới hạn ở việc chuyển đổi Spring sang Helidon. Với bộ gợi ý phù hợp, chúng cũng có thể hỗ trợ việc chuyển đổi và di chuyển các dự án Java EE cũ dựa trên javax.* sang Jakarta EE hiện đại.

Tôi dự định sẽ tiếp tục cải thiện các bộ chuyển đổi. Như thường lệ, tôi hoan nghênh phản hồi của bạn, dù là trong phần bình luận hay trên mạng xã hội.

Dưới đây là các liên kết đến các dự án GitHub được đề cập trong bài viết này:

• Spring Pets – Một dự án thử nghiệm được sử dụng để kiểm tra chuyển đổi
• Bộ chuyển đổi theo ngữ cảnh
• Bộ chuyển đổi gia tăng

The post Helidon là gì ? Hướng dẫn chuyển đổi các dự án Spring Boot sang Helidon bằng AI appeared first on Tomoshare.

1. Vì sao nên đưa Java lên serverless?

Java đã là một trong những lựa chọn hàng đầu cho ứng dụng doanh nghiệp trong hơn 25 năm, nhờ khả năng chạy đa nền tảng, hiệu suất ổn định và cộng đồng phát triển lớn. Tuy nhiên, khi nói đến kiến trúc serverless – đặc biệt với AWS Lambda – cách triển khai ứng dụng Java đã thay đổi đáng kể.

Thay vì phải duy trì JVM và máy chủ hoạt động 24/7, ứng dụng của bạn chỉ chạy khi có sự kiện được kích hoạt. Hạ tầng tự động mở rộng, và bạn chỉ trả phí cho thời gian thực thi thực tế. Mô hình này giúp giảm chi phí vận hành, đơn giản hóa hạ tầng, đồng thời cho phép bạn tập trung vào phần logic ứng dụng.

2. Java truyền thống so với AWS Lambda

Ứng dụng Java truyền thống thường chạy trên các máy chủ ứng dụng như Apache Tomcat, Jetty, JBoss hoặc WebLogic. JVM luôn hoạt động, lắng nghe request HTTP, và xử lý luồng song song.

Trong khi đó, AWS Lambda hoạt động theo mô hình hướng sự kiện (event-driven):

• Mỗi hàm chỉ xử lý một request hoặc event duy nhất.
• Không cần máy chủ HTTP riêng.
• Tự động mở rộng và dừng khi không có request.
• Giới hạn thời gian thực thi tối đa 15 phút và 10 GB RAM.

3. AWS Serverless Java Container là gì?

AWS Serverless Java Container là thư viện giúp bạn chạy các framework Java phổ biến như Spring Boot, Jakarta EE, Micronaut hoặc Jersey trên AWS Lambda mà không cần viết lại toàn bộ mã nguồn.

Thư viện hoạt động như một adapter – nó chuyển các sự kiện từ Lambda thành request/response kiểu Servlet quen thuộc. Nhờ đó, ứng dụng Java có thể hoạt động bình thường chỉ với một số thay đổi nhỏ ở phần entry point.

Phiên bản v2 (2024) mang lại nhiều cải tiến quan trọng:

• Hỗ trợ Jakarta EE 10+.
• Tương thích Spring Framework 6.x và Spring Boot 3.x.
• Cập nhật hỗ trợ Jersey 3.x.
• Tối ưu hiệu suất và giảm kích thước file JAR.

4. Ví dụ: Chuyển ứng dụng Spring Boot 3 sang Lambda

Dưới đây là ví dụ cơ bản để triển khai ứng dụng Spring Boot 3 lên AWS Lambda sử dụng Serverless Java Container v2.

Bước 1: Thêm dependency vào pom.xml

<dependency>
    <groupId>com.amazonaws.serverless</groupId>
    <artifactId>aws-serverless-java-container-springboot3</artifactId>
    <version>2.0.0</version>
</dependency>
  

Bước 2: Loại bỏ Tomcat khỏi build

Spring Boot mặc định nhúng Tomcat. Vì Lambda sử dụng API Gateway để xử lý HTTP, bạn có thể loại bỏ Tomcat để giảm kích thước package và tăng tốc khởi động.

<excludes>
    <exclude>org.apache.tomcat.embed:*</exclude>
</excludes>
  

Bước 3: Tạo handler cho Lambda

Ví dụ cơ bản:

public class StreamLambdaHandler 
        extends SpringBootRequestHandler<APIGatewayV2HTTPEvent, APIGatewayV2HTTPResponse> {
}
  

Hoặc nếu bạn cần nhiều quyền kiểm soát hơn:

public class CustomHandler implements RequestStreamHandler {

    private static final SpringDelegatingLambdaContainerHandler<
        APIGatewayV2HTTPEvent, APIGatewayV2HTTPResponse> handler;

    static {
        handler = new SpringDelegatingLambdaContainerHandler<>(Application.class);
    }

    @Override
    public void handleRequest(InputStream input, OutputStream output, Context context)
            throws IOException {
        handler.proxyStream(input, output, context);
    }
}

  

Bước 4: Cấu hình biến môi trường

Đặt biến môi trường MAIN_CLASS trỏ tới class chính có annotation @SpringBootApplication của bạn.

5. Tối ưu hiệu suất với AWS Lambda SnapStart

Một trong những thách thức lớn khi chạy Java trên Lambda là thời gian khởi động (cold start). AWS đã giới thiệu SnapStart để giải quyết vấn đề này bằng cách “chụp ảnh” trạng thái Lambda sau khi khởi tạo, rồi khôi phục lại cực nhanh cho các request tiếp theo.

Để bật SnapStart, chỉ cần thêm cấu hình vào AWS SAM hoặc CloudFormation:

SnapStart:
  ApplyOn: PublishedVersions
  AutoPublishAlias: prod
  

Kết quả là ứng dụng Java có thể khởi động nhanh hơn gấp 5–10 lần, giúp cải thiện đáng kể trải nghiệm người dùng, đặc biệt với các API có tần suất gọi thấp hoặc không liên tục.

6. Kết nối cơ sở dữ liệu hiệu quả trong môi trường Lambda

Khi làm việc với RDS hoặc Aurora, cần lưu ý:

• Dùng connection pool nhỏ (ví dụ HikariCP với 2–5 connection).
• Tận dụng cache tầng ứng dụng (Redis, DAX) để giảm truy vấn trực tiếp DB.
• Hạn chế query đồng bộ trong hot path; nên dùng async hoặc event-driven khi có thể.

7. Nhược điểm và lưu ý khi triển khai Java trên AWS Lambda

Dù AWS Serverless Java Container giúp việc chuyển ứng dụng Java lên Lambda trở nên dễ dàng hơn, developer vẫn cần hiểu rõ một số hạn chế để thiết kế và vận hành hiệu quả hơn.

Tóm lại, Java vẫn là lựa chọn mạnh mẽ trong môi trường AWS Lambda nhờ tính ổn định và hệ sinh thái lớn, nhưng để đạt hiệu năng tối ưu, cần chú trọng vào cấu trúc ứng dụng, cách đóng gói, và kỹ thuật giảm thời gian khởi động.

Tài nguyên tham khảo

• GitHub: AWS Serverless Java Container
• Tài liệu chính thức: AWS Lambda cho Java Developer
• AWS Compute Blog

The post Re-platforming Java với AWS Serverless Java Container appeared first on Tomoshare.

1. Google Guice là gì?

Google Guice là một framework DI gọn nhẹ, mã nguồn mở giúp chúng ta phát triển các ứng dụng dạng module được phát triển và quản lý bởi Google. Guice hỗ trợ từ Java 6 trở lên nhé anh em.

Trong Guice, annotation @Inject được sử dụng để tiêm phụ thuộc. Nó cho phép chúng ta inject sự phụ thuộc tại các constructor, field hoặc method. Sử dụng Guice, chúng ta có thể xác định scope của instance đối tượng phụ thuộc. Nó cũng có các tính năng để tích hợp với Spring và Aspect Oriented Programming (AOP).

2. Cài đặt Google Guice

Để sử dụng Google Guice, anh em thêm thư viện Guice vào trong file pom.xml như sau:

<!-- https://mvnrepository.com/artifact/com.google.inject/guice -->
<dependency>
    <groupId>com.google.inject</groupId>
    <artifactId>guice</artifactId>
    <version>4.2.2</version>
</dependency>

Hoặc muốn sử dụng các version khác thì anh em có thể truy cập vào 👉 đây 👈. Cứ version nào nhiều người sử dụng mà “phang” thôi =))).

3. Ví dụ cơ bản về Dependency Injection với Google Guice

Để sử dụng Guice cần nhớ 2 thông tin quan trọng sau:

• Nói với Guice cái gì cần được inject với annotation @Inject.
• Nói với Guice cách inject mô-đun: implement Asbstract Module, bind các interface với các implementation mong muốn.

Quay trở lại với ví dụ em gái Eimi Fukada trong bài trước lần này tôi sẽ sử dụng Guice nha:

GuiceModule.java

package org.blogtms;

import com.google.inject.AbstractModule;

public class GuiceModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(Outfit.class).to(Bikini.class);
        bind(Accessories.class).to(GucciAccessories.class);
        bind(HairStyle.class).to(KoreanHairStyle.class);
    }
}

Girl.java thêm @Inject

package org.blogtms;

import com.google.inject.Inject;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

//@Component
public class Girl {

    @Autowired
    Outfit outfit;

    @Autowired
    Accessories accessories;

    @Autowired
    HairStyle hairStyle;

    @Inject
    public Girl(Outfit outfit, Accessories accessories, HairStyle hairStyle) {
        this.outfit = outfit;
        this.accessories = accessories;
        this.hairStyle = hairStyle;
    }
}

Main.java

package org.blogtms;

import com.google.inject.Guice;
import com.google.inject.Injector;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ApplicationContext;

//@SpringBootApplication
public class Main {
    public static void main(String[] args) {
//        ApplicationContext context = SpringApplication.run(Main.class, args);
//
//        Girl girl = context.getBean(Girl.class);

        Injector injector = Guice.createInjector(new GuiceModule());

        Girl girl = injector.getInstance(Girl.class);
    }
}

Thế là xong rồi =)))

Trong ví dụ trên, chúng ta thấy một số phần thay đổi so với ví dụ ở bài trước:

• Tạo một class extends từ AbstractModule, lớp này được sử dụng để định nghĩa cách mà một class/ interface sẽ được inject bởi một implement cụ thể nào. Trong ví dụ này, Outfit sẽ được inject bởi implement Bikini.
• Lớp Girl có dependency với Outfit. Trong ví dụ này, chúng ta sử dụng @Inject tại hàm xây dựng (constructor) để inject đối tượng Outfit.
• Khởi tạo Guice Injector với config.
• Lấy thể hiện đối tượng với các dependency để sử dụng.

4. Scope trong Google Guice

Theo mặc định, Guice trả về một instance mới mỗi lần nó cần cung cấp một giá trị. Hành vi này có thể cấu hình thông qua phạm vi (scope). Scope cho phép chúng ta tái sử dụng instance.

Các loại Scope được hỗ trợ bởi Google Guice:

• @Singleton : một instance duy nhất được sử dụng trong toàn bộ ứng dụng.
• @SessionScoped : mỗi session sẽ có một instance khác nhau.
• @RequestScoped : mỗi request sẽ có một instance khác nhau.

Trên đây là giới thiệu cơ bản về Google Guice. Nó cung cấp một cách tiếp cận mới cho Dependency Injection, tận dụng thế mạnh của Annotation và Generic để giúp chúng ta dễ dàng hơn trong việc quản lý và sử dụng các Dependency, cũng như dễ dàng phát triển các ứng dụng dạng module.

Tài liệu tham khảo:

• https://github.com/google/guice
• https://www.tutorialspoint.com/guice/index.htm

Cảm ơn anh em đã theo dõi bài viết 🙋‍♂️. Vẫn như mọi khi, đây là source code

The post Dependency Injection (DI) framework – Google Guice appeared first on Tomoshare.

1. Dependency Injection là gì?

Theo tài liệu thì:

Dependency Injection is a design pattern, …

Nôm na Dependency Injection (DI) là một kỹ thuật cho phép xóa bỏ sự phụ thuộc giữa các module, làm cho ứng dụng dễ dàng hơn trong việc thay đổi module, bảo trì code và testing.

DI cung cấp cho một đối tượng các thể hiện phụ thuộc (dependencies) của nó từ bên ngoài truyền vào mà không phải khởi tạo trực tiếp từ trong class sử dụng.

2. Nhiệm vụ của dependency injection

• Tạo các đối tượng.
• Quản lý sự phụ thuộc (dependencies) giữa các đối tượng.
• Cung cấp (inject) các phụ thuộc được yêu cầu cho đối tượng (được truyền từ bên ngoài đối tượng).

3. Nguyên tắc hoạt động của DI

• Các module không giao tiếp trực tiếp với nhau, mà thông qua interface. Module cấp thấp sẽ implement interface, module cấp cao sẽ gọi module cấp thấp thông qua interface.
• Việc khởi tạo các module cấp thấp sẽ do DI Container/ IoC Container thực hiện.
• Việc Module nào gắn với interface nào sẽ được config trong file properties, trong file XML hoặc thông qua Annotation. Annotation là một cách thường được sử dụng trong các Framework, chẳng hạn như @Inject với CDI, @Autowired với Spring hay @ManagedProperty với JSF.

4. Các dạng Dependency Injection

• Constructor Injection: Các dependency sẽ được container truyền vào (inject vào) 1 class thông qua constructor của class đó. Đây là cách thông dụng nhất.
• Setter Injection: Các dependency sẽ được truyền vào 1 class thông qua các hàm Setter.
• Fields/ properties: Các dependency sẽ được truyền vào 1 class một cách trực tiếp vào các field.
• Interface Injection: Class cần inject sẽ implement 1 interface. Interface này chứa 1 hàm tên Inject. Container sẽ injection dependency vào 1 class thông qua việc gọi hàm Inject của interface đó. Đây là cách rườm rà và cũng ít được sử dụng.
• Service Locator: nó hoạt động như một mapper, cho phép thay đổi code tại thời điểm run-time mà không cần biên dịch lại ứng dụng hoặc phải khởi động lại.

Anh em đọc đến đây đã hiểu Dependency Injection là gì chưa? Anh em nào đã thông não thì có thể bỏ qua, anh em nào vẫn lơ tơ mơ thì tiếp tục, full hd không che phía dưới =)))).

5. Ví dụ sử dụng Dependency Injection.

Bikini.java

package org.tmsblog.patterns.di;

public class Bikini {
    public void wear() {
        System.out.println("Đã mặc bikini");
    }
}

Girl.java

package org.tmsblog.patterns.di;

public class Girl {

    private Bikini outfit = new Bikini();
    
    public void result() {
        outfit.wear();
    }
}

Ví dụ anh em tạo 1 Girl, anh em sẽ tạo ra thêm 1 bộ Bikini đi kèm với cô gái đó. Lúc này, Bikini tồn tại mang ý nghĩa là dependency (phụ thuộc) của Girl.

Khi khởi tạo thuộc tính như này, vô tình tạo ra một điểm thắt nút trong chương trình, giả sử, Girl muốn mặc một bộ Quần Jeans + áo hai dây thì anh em sẽ phải thay class Bikini thành JeansWithTshirt(quần jeans với áo T-shirt) ư?

Hay nguy hiểm hơn, bộ đồ Bikini bị hỏng? (code lớp Bikini không hoạt động?) nó sẽ ảnh hưởng trực tiếp tới Girl.

Vấn đề là ở đó, chúng ta cùng đọc lại nguyên tắc D của SOLID:

• Các mô-đun cấp cao không được nhập bất cứ thứ gì từ các mô-đun cấp thấp. Cả hai nên phụ thuộc vào sự trừu tượng

Bây giờ chúng ta sẽ áp dụng Dependency Injection để giải quyết vấn đề trên.

Girl.java

package org.tmsblog.patterns.di;

public class Girl {

    private final Outfit anything;

    public Girl(Outfit anything) {
        this.anything = anything;
    }
}

Bikini.java

package org.tmsblog.patterns.di;

public class Bikini implements Outfit{
   @Override
    public void wear() {
        System.out.println("Đã mặc bikini");
    }
}

Outfit.java

package org.tmsblog.patterns.di;

public interface Outfit {
    public void wear();
}

Main.java

package org.tmsblog.patterns.di;

public class Main {
    public static void main(String[] args) {
        Outfit bikini = new Bikini();

        Girl fukada = new Girl(bikini);
        //Vậy là đã lấy được đối tượng Girl nha
    }
}

Với đoạn code ở trên, chúng ta đã gần như tách được Bikini ra hoàn toàn khỏi Girl. điều này làm giảm sự phụ thuộc giữa Girl và Bikini. Mà tăng tính tùy biến, linh hoạt cho code.

Bây giờ Girl sẽ hoạt động với Outfit mà thôi. Và Outfit ở đâu ra? Chúng ta tạo ra và đưa nó vào (Inject) cô gái Girl.

Khái niệm Dependency Injection từ đây mà ra:
Dependency Injection là việc các Object nên phụ thuộc vào các Abstract Class và thể hiện chi tiết của nó sẽ được Inject vào đối tượng lúc runtime.

Bây giờ muốn Girl mặc gì khác, anh em chỉ cần tạo một Class kế thừa Outfit và Inject nó vào Girl là xong!

Dependency Injection giúp chúng ta dễ dàng mở rộng code và giảm sự phụ thuộc giữa các dependency với nhau. Tuy nhiên, lúc này, khi code bạn sẽ phải kiêm thêm nhiệm vụ Inject dependency (tiêm sự phụ thuộc). Thử tưởng tượng một Class có hàng chục dependency thì bạn sẽ phải tự tay inject từng ý cái. Việc này lại dẫn tới khó khăn trong việc code, quản lý code và dependency

package org.tmsblog.patterns.di;

public class Main {
    public static void main(String[] args) {
       Outfit bikini = new Bikini();
       Accessories gucci = new GucciAccessories();
       HairStyle hair = new KoreanHairStyle();
       Girl fukada = new Girl(bikini, gucci, hair);
    }
}

Vãi chưởng nhỉ, lúc này có thằng nào làm hộ được chúng ta việc này thì tốt biết mấy =))).

Bây giờ giả sử, chúng ta định nghĩa trước toàn bộ các dependency có trong Project, mô tả nó và tống nó vào 1 cái kho và giao cho một thằng tên là framework quản lý. Bất kỳ các Class nào khi khởi tạo, nó cần dependency gì, thì cái framework này sẽ tự tìm trong kho rồi inject vào đối tượng thay chúng ta. sẽ tiện hơn phải không?

Úi dời ơi, tuyệt chứ nhỉ, đó cũng chính là nguyên lý chính của Inversion of Control (IOC) – Đảo chiều sự điều khiển

Nguyên văn Wiki:

• Inversion of Control is a programming principle. flow of control within the application is not controlled by the application itself, but rather by the underlying framework.

Khi đó, code chúng ta sẽ chỉ cần như này, để lấy ra đối tượng Girl, còn trong Girl.java anh em tiêm chích Accessories và HairStyle như Outfit nha:

package org.tmsblog.patterns.di;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ApplicationContext;

@SpringBootApplication
public class Main {
    public static void main(String[] args) {
        ApplicationContext context = SpringApplication.run(Main.class, args);

        Girl girl = context.getBean(Girl.class);
        // Anh em muốn lấy gì từ Girl thì cứ chấm mút ra nha =))
    }
}

Lời kết:

Dependency Injection và IoC container là những khái niệm rất quan trọng, hầu hết các ứng dụng, framework hiện tại đều sử dụng nó. Chúng ta cần tìm hiểu để biết rõ DI và IoC được ứng dụng trong trường hợp nào. Nếu áp dụng hợp lý code của chúng ta sẽ ít kết dính hơn (loose coupling), dễ bảo trì, dễ test hơn, tổ chức ứng dụng hợp lý và gọn gàng hơn.

Source Code tham khảo tại đây:

The post Thông não Dependency Injection bằng Eimi Fukada appeared first on Tomoshare.

1. Factory Method Pattern là gì?

Factory Method Design Pattern hay gọi ngắn gọn là Factory Pattern là một trong những Pattern thuộc nhóm Creational Design Pattern. Nhiệm vụ của Factory Pattern là quản lý và trả về các đối tượng theo yêu cầu, giúp cho việc khởi tạo đổi tượng một cách linh hoạt hơn.

Trong Factory Pattern, chúng ta tạo đối tượng mà không để lộ logic tạo đối tượng ở phía người dùng và tham chiếu đến đối tượng mới được tạo ra bằng cách sử dụng một interface chung.

Factory Pattern được sử dụng khi có một class cha (super-class) với nhiều class con (sub-class), dựa trên đầu vào và phải trả về 1 trong những class con đó.

2. Cài đặt Factory Pattern như thế nào?

Một Factory Pattern bao gồm các thành phần cơ bản sau:

• Super Class: môt supper class trong Factory Pattern có thể là một interface, abstract class hay một class thông thường.
• Sub Classes: các sub class sẽ implement các phương thức của supper class theo nghiệp vụ riêng của nó.
• Factory Class: một class chịu tránh nhiệm khởi tạo các đối tượng sub class dựa theo tham số đầu vào. Lưu ý: lớp này là Singleton hoặc cung cấp một public static method cho việc truy xuất và khởi tạo đối tượng. Factory class sử dụng if-else hoặc switch-case để xác định class con đầu ra.

Ví dụ: Tất cả hệ thống Football Club có cung cấp API để truy cập đến hệ thống của họ. Team được giao nhiệm vụ thiết kế một API để client có thể sử dụng dịch vụ của một CLB bất kỳ. Hiện tại, phía client chỉ cần sử dụng dịch vụ của 1 số đội bóng như Becamex Bình Dương, Hoàng Anh Gia Lai, Hà Nội, … Tuy nhiên để dễ mở rộng sau này, và phía client mong muốn không cần phải thay đổi code của họ khi cần sử dụng thêm dịch vụ của đội bóng khác. Với yêu cầu như vậy, chúng ta có thể sử dụng một Pattern phù hợp là Factory Method Pattern.

Hệ thống được minh họa như sau:

Chương trình được cài đặt theo Factory Pattern như sau:

Supper Class:

package com.tmsblog.patterns.creational.factorymethod;

public interface FC {
    String getFCName();
}

Sub Classes:

package com.tmsblog.patterns.creational.factorymethod;
 
public class BECAMEXBinhDuong implements FC {
 
    @Override
    public String getFCName() {
        return "Becamex Binh Duong";
    }
}

package com.tmsblog.patterns.creational.factorymethod;
 
public class HAGL implements FC {
 
    @Override
    public String getFCName() {
        return "Hoang Anh Gia Lai";
    }
}

package com.tmsblog.patterns.creational.factorymethod;
 
public class Hanoi implements FC {
 
    @Override
    public String getFCName() {
        return "Ha Noi";
    }
}

Factory class:

package org.tmsblog.patterns.creational.factorymethod;

import org.tmsblog.enums.FCType;

public class FCFactory {
    public FCFactory() {
    }

    public static final FC getFC(FCType fcType) {
        switch (fcType) {
            case BECAMEX_BD:
                return new BECAMEXBinhDuong();
            case HAGL:
                return new HAGL();
            case HANOI:
                return new Hanoi();
            default:
                throw new IllegalArgumentException("This fc type is unsupported");
        }
    }
}

FC type:

package org.tmsblog.enums;

public enum FCType {
    BECAMEX_BD, HAGL, HANOI
}

Client:

package org.tmsblog.patterns.creational.factorymethod;

import org.tmsblog.enums.FCType;

public class Client {
    public static void main(String[] args) {
        FC fc = FCFactory.getFC(FCType.HANOI);
        System.out.println(fc.getFCName());
    }
}

Như anh em thấy, phía client chỉ cần gọi duy nhất một phương thức FCFactory.getFC() là có thể sử dụng được dịch vụ của một CLB bất kỳ.

Khi hệ thống muốn cung cấp thêm dịch vụ của một CLB khác, chẳng hạn Viettel, thì cần tạo thêm một class mới implement từ interface FC, và thêm vào logic khởi tạo FC trong Factory là xong. Nó không làm ảnh hưởng đến code ở phía Client.

3. Sử dụng Factory Pattern khi nào?

Factory Pattern được sử dụng khi:

• Chúng ta có một super class với nhiều class con và dựa trên đầu vào, chúng ta cần trả về một class con. Mô hình này giúp chúng ta đưa trách nhiệm của việc khởi tạo một lớp từ phía người dùng (client) sang lớp Factory.
• Chúng ta không biết sau này sẽ cần đến những lớp con nào nữa. Khi cần mở rộng, hãy tạo ra sub class và implement thêm vào factory method cho việc khởi tạo sub class này.

4. Lợi ích của Factory Pattern là gì?

Lợi ích của Factory Pattern:

• Factory Pattern giúp giảm sự phụ thuộc giữa các module (loose coupling): cung cấp 1 hướng tiếp cận với Interface thay vì các implement. Giúp chuơng trình độc lập với những lớp cụ thể mà chúng ta cần tạo 1 đối tượng, code ở phía client không bị ảnh hưởng khi thay đổi logic ở factory hay sub class.
• Mở rộng code dễ dàng hơn: khi cần mở rộng, chỉ việc tạo ra sub class và implement thêm vào factory method.
• Khởi tạo các Objects mà che giấu đi xử lí logic của việc khởi tạo đấy. Người dùng không biết logic thực sực được khởi tạo bên dưới phương thức factory.
• Dễ dàng quản lý life cycle của các Object được tạo bởi Factory Pattern.
• Thống nhất về naming convention: giúp cho các developer có thể hiểu về cấu trúc source code.

Anh em có thể thấy Factory Pattern được áp dụng trong:

• JDK: java.util.Calendar, ResourceBundle, NumberFormat, …
• BeanFactory trong Spring Framework.
• SessionFactory trong Hibernate Framework.

Như vậy tôi đã giới thiệu xong về Factory Method Pattern, hy vọng bài viết sẽ giúp ích cho anh em trong quá trình xây dựng và phát triển ứng dụng. Hẹn gặp lại ở các bài viết tiếp theo.

Tài liệu tham khảo:

• https://refactoring.guru/design-patterns/factory-method
• https://sourcemaking.com/design_patterns/factory_method
• https://www.tutorialspoint.com/design_pattern/factory_pattern.htm

The post Hướng dẫn Java Design Pattern – Factory Method appeared first on Tomoshare.

Đôi khi, trong quá trình phân tích thiết kế một hệ thống, chúng ta mong muốn có những đối tượng cần tồn tại duy nhất và có thể truy xuất mọi lúc mọi nơi. Làm thế nào để hiện thực được một đối tượng như thế khi xây dựng mã nguồn? Chúng ta có thể nghĩ tới việc sử dụng một biến toàn cục (global variable : public static final). Tuy nhiên, việc sử dụng biến toàn cục nó phá vỡ quy tắc của OOP (encapsulation). Để giải bài toán trên, người ta hướng đến một giải pháp là sử dụng Singleton pattern.

1. Singleton Pattern là gì?

Singleton là 1 trong 5 design pattern của nhóm Creational Design Pattern.

Singleton đảm bảo chỉ duy nhất một thể hiện (instance) được tạo ra và nó sẽ cung cấp cho anh em một method để có thể truy xuất được thể hiện duy nhất đó mọi lúc mọi nơi trong chương trình.

Sử dụng Singleton khi chúng ta muốn:

• Đảm bảo rằng chỉ có một instance của lớp.
• Việc quản lý việc truy cập tốt hơn vì chỉ có một thể hiện duy nhất.
• Có thể quản lý số lượng thể hiện của một lớp trong giớn hạn chỉ định.

2. Implement Singleton Pattern như thế nào?

Có rất nhiều cách để implement Singleton Pattern. Nhưng dù cho việc implement bằng cách nào đi nữa cũng dựa vào nguyên tắc dưới đây cơ bản dưới đây:

• private constructor để hạn chế truy cập từ class bên ngoài.
• Đặt private static final variable đảm bảo biến chỉ được khởi tạo trong class.
• Có một method public static để return instance được khởi tạo ở trên.

3. Những cách nào để implement Singleton Pattern

Dựa trên những nguyên tắc thiết kế Singleton ở trên, chúng ta có các cách implement singleton như sau:

3.1. Eager initialization

Singleton Class được khởi tạo ngay khi được gọi đến.

package com.tmsblog.patterns.creational.singleton;
 
public class EagerInitializedSingleton {
 
    private static final EagerInitializedSingleton INSTANCE = new EagerInitializedSingleton();
 
    private EagerInitializedSingleton() {}
 
    public static EagerInitializedSingleton getInstance() {
        return INSTANCE;
    }
}

Eager initialization là cách tiếp cận tốt, dễ cài đặt, tuy nhiên nó có một nhược điểm mặc dù instance đã được khởi tạo nhưng có thể sẽ không dùng tới và nó dễ dàng bị phá vỡ bởi Reflection.

3.2. Static block initialization

Cách làm tương tự như Eager initialization chỉ khác phần static block cung cấp thêm lựa chọn cho việc handle exception hay các xử lý khác.

package com.tmsblog.patterns.creational.singleton;
 
public class StaticBlockSingleton {
 
    private static final StaticBlockSingleton INSTANCE;
 
    private StaticBlockSingleton() {}
 
    // Static block initialization for exception handling
    static {
        try {
            INSTANCE = new StaticBlockSingleton();
        } catch (Exception e) {
            throw new RuntimeException("Exception occured in creating singleton instance");
        }
    }
 
    public static StaticBlockSingleton getInstance() {
        return INSTANCE;
    }
}

3.3. Lazy Initialization

Là một cách làm mang tính mở rộng hơn so với 2 cách làm trên và hoạt động tốt trong môi trường đơn luồng (single-thread).

package com.tmsblog.patterns.creational.singleton;
 
public class LazyInitializedSingleton {
 
    private static LazyInitializedSingleton instance;
 
    private LazyInitializedSingleton() {}
 
    public static LazyInitializedSingleton getInstance() {
        if (instance == null) {
            instance = new LazyInitializedSingleton();
        }
        return instance;
    }
}

Cách này đã khắc phục được nhược điểm của cách Eager initialization, chỉ khi nào getInstance() được gọi thì instance mới được khởi tạo. Tuy nhiên, cách này chỉ sử dụng tốt trong trường hợp đơn luồng (single-thread), trường hợp nếu có nhiều luồng (multi-thread) cùng chạy và cùng gọi hàm getInstance() tại cùng một thời điểm thì có thể có nhiều hơn 1 thể hiện của instance. Để khắc phục nhược điểm này chúng ta sử dụng Thread Safe Singleton.

Một nhược điểm nữa của Lazy Initialization cần quan tâm là: đối với thao tác create instance quá chậm thì người dùng có phải chờ lâu cho lần sử dụng đầu tiên.

3.4. Thread Safe Singleton

Cách đơn giản nhất là chúng ta gọi phương thức synchronized của hàm getInstance() và như vậy hệ thống đảm bảo rằng tại cùng một thời điểm chỉ có thể có 1 luồng có thể truy cập vào hàm getInstance() và đảm bảo rằng chỉ có duy nhất 1 thể hiện của class.

package com.tmsblog.patterns.creational.singleton;
 
public class ThreadSafeLazyInitializedSingleton {
 
    private static volatile ThreadSafeLazyInitializedSingleton instance;
 
    private ThreadSafeLazyInitializedSingleton() {}
 
    public static synchronized ThreadSafeLazyInitializedSingleton getInstance() {
        if (instance == null) {
            instance = new ThreadSafeLazyInitializedSingleton();
        }
        return instance;
    }
}

Biến volatile trong Java có tác dụng thông báo sự thay đổi giá trị của biến tới các thread khác nhau nếu biến này đang được sử dụng trong nhiều thread.

Cách này có nhược điểm là một phương thức synchronized sẽ chạy rất chậm và tốn hiệu năng, bất kỳ Thread nào gọi đến đều phải chờ nếu có một Thread khác đang sử dụng. Có những tác vụ xử lý trước và sau khi tạo thể hiện không cần thiết phải block. Vì vậy chúng ta cần cải tiến nó đi 1 chút với Double Check Locking Singleton.

3.5. Double Check Locking Singleton

Để implement theo cách này, chúng ta sẽ kiểm tra sự tồn tại thể hiện của lớp, với sự hỗ trợ của đồng bộ hóa, hai lần trước khi khởi tạo. Phải khai báo volatile cho instance để tránh lớp làm việc không chính xác do quá trình tối ưu hóa của trình biên dịch.

package com.tmsblog.patterns.creational.singleton;
 
public class DoubleCheckLockingSingleton {
 
    private static volatile DoubleCheckLockingSingleton instance;
 
    private DoubleCheckLockingSingleton() {}
 
    public static DoubleCheckLockingSingleton getInstance() {
        // Do something before get instance ...
        if (instance == null) {
            // Do the task too long before create instance ...
            // Block so other threads cannot come into while initialize
            synchronized (DoubleCheckLockingSingleton.class) {
                // Re-check again. Maybe another thread has initialized before
                if (instance == null) {
                    instance = new DoubleCheckLockingSingleton();
                }
            }
        }
        // Do something after get instance ...
        return instance;
    }
}

3.6. Bill Pugh Singleton Implementation

Với cách làm này bạn sẽ tạo ra static nested class với vai trò 1 Helper khi muốn tách biệt chức năng cho 1 class function rõ ràng hơn. Đây là cách thường hay được sử dụng và có hiệu suất tốt (theo các chuyên gia đánh giá :v).

package com.tmsblog.patterns.creational.singleton;
 
public class BillPughSingleton {
 
    private BillPughSingleton() {}
 
    public static BillPughSingleton getInstance() {
        return SingletonHelper.INSTANCE;
    }
 
    private static class SingletonHelper {
        private static final BillPughSingleton INSTANCE = new BillPughSingleton();
    }
}

Khi Singleton được tải vào bộ nhớ thì SingletonHelper chưa được tải vào. Nó chỉ được tải khi và chỉ khi phương thức getInstance() được gọi. Với cách này tránh được lỗi cơ chế khởi tạo instance của Singleton trong Multi-Thread, performance cao do tách biệt được quá trình xử lý. Do đó, cách làm này được đánh giá là cách triển khai Singleton nhanh và hiệu quả nhất.

3.7. Phá vỡ cấu trúc Singleton Pattern bằng Reflection

Reflection có thể được dùng để phá vỡ Pattern của Eager Initialization ở trên.

package com.tmsblog.patterns.creational.singleton;
 
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
 
public class ReflectionBreakSingleton {
 
    public static void main(String[] args)
            throws InstantiationException, IllegalAccessException, InvocationTargetException {
         
        EagerInitializedSingleton instanceOne = EagerInitializedSingleton.getInstance();
        EagerInitializedSingleton instanceTwo = null;
 
        Constructor<?>[] constructors = EagerInitializedSingleton.class.getDeclaredConstructors();
        for (Constructor<?> constructor : constructors) {
            constructor.setAccessible(true);
            instanceTwo = (EagerInitializedSingleton) constructor.newInstance();
        }
 
        System.out.println(instanceOne.hashCode());
        System.out.println(instanceTwo.hashCode());
    }
}

Output của chương trình:

2018699554
1311053135

Tương tự Eager Initialization, implement theo Bill Pugh Singleton cũng bị break bởi Reflection.

3.8. Enum Singleton

Khi dùng enum thì các params chỉ được khởi tạo 1 lần duy nhất, đây cũng là cách giúp anh em tạo ra Singleton instance.

package com.tmsblog.patterns.creational.singleton;
 
/**
 * Singleton implementation using enum initialization
 */
public enum EnumSingleton {
 
    INSTANCE;
}

Lưu ý:

• Enum có thể sử dụng như một Singleton, nhưng nó có nhược điểm là không thể extends từ một lớp được, nên khi sử dụng cần xem xét vấn đề này.
• Hàm constructor của enum là lazy, nghĩa là khi được sử dụng mới chạy hàm khởi tạo và nó chỉ chạy duy nhất một lần. Nếu muốn sử dụng như một eager singleton thì cần gọi thực thi trong một static block khi start chương trình.

So sánh giữa 2 cách sử dụng enum initialization và static block initialization method, enum có một điểm rất mạnh khi giải quyết về vấn đề Serialization/ Deserialization.

3.9. Serialization and Singleton

Đôi khi trong các hệ thống phân tán (distributed system), chúng ta cần implement interface Serializable trong lớp Singleton để chúng ta có thể lưu trữ trạng thái của nó trong file hệ thống và truy xuất lại nó sau.

package com.tmsblog.patterns.creational.singleton;
 
import java.io.ObjectStreamException;
import java.io.Serializable;
 
public class SerializedSingleton implements Serializable {
 
    private static final long serialVersionUID = 1741825395699241705L;
 
    private SerializedSingleton() {}
 
    private static class SingletonHelper {
        private static final SerializedSingleton instance = new SerializedSingleton();
    }
 
    public static SerializedSingleton getInstance() {
        return SingletonHelper.instance;
    }
     
    /**
     * Special hook provided by serialization where developer can control what object needs to sent.
     * However this method is invoked on the new object instance created by de serialization process.
     *
     * @return
     * @throws ObjectStreamException
     */
//    private Object readResolve() throws ObjectStreamException {
//        return SingletonHelper.instance;
//    }
 
}

Đoạn code test quá trình Serialize/ Deserialize:

package com.tmsblog.patterns.creational.singleton;
 
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInput;
import java.io.ObjectInputStream;
import java.io.ObjectOutput;
import java.io.ObjectOutputStream;
 
public class SingletonSerializedTest {
 
    public static void main(String[] args) throws FileNotFoundException, IOException, ClassNotFoundException {
 
        SerializedSingleton serializedSingleton1 = SerializedSingleton.getInstance();
        EnumSingleton enumSingleton1 = EnumSingleton.INSTANCE;
 
        ObjectOutput out = new ObjectOutputStream(new FileOutputStream("SingletonSerializedTest.txt"));
        out.writeObject(serializedSingleton1);
        out.writeObject(enumSingleton1);
        out.close();
 
        // De-serialize from file to object
        ObjectInput in = new ObjectInputStream(new FileInputStream("SingletonSerializedTest.txt"));
        SerializedSingleton serializedSingleton2 = (SerializedSingleton) in.readObject();
        EnumSingleton enumSingleton2 = (EnumSingleton) in.readObject();
        in.close();
 
        System.out.println("serializedSingleton1 hashCode=" + serializedSingleton1.hashCode());
        System.out.println("serializedSingleton2 hashCode=" + serializedSingleton2.hashCode());
        System.out.println("enumSingleton1 hashCode=" + enumSingleton1.hashCode());
        System.out.println("enumSingleton2 hashCode=" + enumSingleton2.hashCode());
    }
}

Output của chương trình:

serializedSingleton1 hashCode=1028566121
serializedSingleton2 hashCode=1747585824
enumSingleton1 hashCode=1118140819
enumSingleton2 hashCode=1118140819

Như trong ví dụ trên, Deserialize đối tượng của SerializedSingleton khác với đối tượng gốc. Tuy nhiên vấn đề này không xảy ra khi sử dụng enum.

Thực tế thì vẫn có cách khắc phục khi sử dụng class SerializedSingleton là implement một phương thức readResolve(). Nhưng khi chúng ta thật sự gặp vấn đề và cần sử dụng Serialize/ Deserialize, thì nên sử dụng enum sẽ đơn giản hơn.

4. Sử dụng Singleton Pattern khi nào?

Dưới đây là một số trường hợp sử dụng của Singleton Pattern thường gặp:

• Vì class dùng Singleton chỉ tồn tại 1 Instance (thể hiện) nên nó thường được dùng cho các trường hợp giải quyết các bài toán cần truy cập vào các ứng dụng như: Shared resource, Logger, Configuration, Caching, Thread pool, …
• Một số design pattern khác cũng sử dụng Singleton để triển khai: Abstract Factory, Builder, Prototype, Facade,…
• Đã được sử dụng trong một số class của core java như: java.lang.Runtime, java.awt.Desktop.

5. Tổng kết

Có rất nhiều cách implement cho Singleton, anh em có thể sử dụng BillPughSingleton vì có hiệu suất cao, sử dụng LazyInitializedSingleton cho những ứng dụng chỉ làm việc với ứng dụng single-thread và sử dụng DoubleCheckLockingSingleton khi làm việc với ứng dụng multi-thread. Tùy theo trường hợp cụ thể, anh em hãy chọn cho mình cách implement phù hợp nhé.

Tài liệu tham khảo:

• https://community.oracle.com/docs/DOC-918906
• https://www.journaldev.com/1377/java-singleton-design-pattern-best-practices-examples
• http://www.javacreed.com/the-broken-singleton/
• https://www.geeksforgeeks.org/prevent-singleton-pattern-reflection-serialization-cloning/
• http://www.java67.com/2015/09/thread-safe-singleton-in-java-using-double-checked-locking-pattern.html

The post Hướng dẫn Java Design Pattern – Singleton appeared first on Tomoshare.

Ở đây tôi có một bài toán từ khách hàng như sau: Hãy tạo cho tao một mã đơn hàng (trans_confirm_no) để tao có thể phân biệt được các đơn hàng với nhau với định dạng như này “TMSxxxxx” và nó sẽ phải bắt đầu từ “TMS00001“.

Ngay khi nhận được yêu cầu thì tôi đã bắt tay ngay vào việc code và ngôn ngữ tôi sử dụng cho dự án này là Java spring boot và MSQL.

Cách sử dụng code để generate mã trans_confirm_no

// hàm tạo ra mã trans_confirm_no mới tăng dần
private synchronized String getTransConfirmNoDiorTest(){
        String maxTransConfirmNo = transactionDiorMapper.getTransConfirmNo();
        log.info("maxTransConfirmNo: {}", maxTransConfirmNo);
        StringBuilder result = new StringBuilder();
        if (StringUtils.isBlank(maxTransConfirmNo)){
            logger.warn("Order transConfirmNo failed, transConfirmNo={}", maxTransConfirmNo);
            result.append("00001");
        } else {
            int maxTransConfirmNoIntValue = Integer.parseInt(maxTransConfirmNo.substring(3)) + 1;
            if (maxTransConfirmNoIntValue > 0 && maxTransConfirmNoIntValue < 100000 ) {
                int len = 5 - ((Integer)maxTransConfirmNoIntValue).toString().length();
                if ( len > 0 ) {
                    for (int i = 0; i < len ; i++) {
                        result.append("0");
                    }
                    result.append(maxTransConfirmNoIntValue);
                } else {
                    result.append(maxTransConfirmNoIntValue);
                }
            } else {
                result.append("00001");
            }
        }
        log.info("result: {}", result);
        return "TMS" + result;
    }

 // hàm lấy ra mã trans_confirm_no lớn nhất đang có
 SELECT
            ttd.trans_confirm_no
        FROM
            t_transaction_dior ttd
        WHERE
            ttd.delete_flag = 0
            AND ttd.trans_confirm_no LIKE 'JPD%'
            AND ttd.trans_status IS NOT NULL
        ORDER BY ttd.trans_confirm_no DESC
        LIMIT 1;

Vấn đề gặp phải ở đây là khi chúng tôi có nhiều đầu api call đến hàm này cùng thời điểm thì việc tạo ra một mã TMSxxxxx tăng dần gặp vấn đề và nó Generate không đúng với mong muốn.

Khi hệ thống có lượng truy cập lớn, số lượng user mua hàng dồn dập, hàm bên trên sẽ xảy ra trường hợp sinh ra các mã trans_confirm_no trùng nhau.

Sử dụng trigger generate mã trans_confirm_no

// Đầu tiên chúng ta tạo ra 1 bảng để sử cơ chế AUTO_INCREMENT trong mysql để  lấy được phần xxxxx nằm trong fomat "TMSxxxxx"
CREATE TABLE transaction_seq
(
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY
);

// Mình tạo ra 1 trigger sử dụng concat để nối prefix TMS + xxxxx đã được gen ở bảng transaction_seq phía trên.
DELIMITER $$
CREATE TRIGGER tg_t_transaction_dior_insert
    BEFORE INSERT ON t_transaction_dior
    FOR EACH ROW
BEGIN
    INSERT INTO transaction_seq VALUES (NULL);
    SET NEW.trans_confirm_no = CONCAT('TMS', LPAD(LAST_INSERT_ID(), 5, '0'));
END$$
    DELIMITER ;

// Đặt giá trị bắt đầu AUTO_INCREMENT trong table transaction_seq
ALTER TABLE transaction_seq AUTO_INCREMENT=00001;

Khi sử dụng trigger đã giải quyết được vấn đề của tôi trong bài toán này.

The post Sử dụng trigger trong SQL Generrate mã code kết hợp một String + id Auto Increament. appeared first on Tomoshare.

Ở bài viết này, mình sẽ hướng dẫn các bạn setup New Relic với máy chủ sử dụng dịch vụ AWS Beanstalk và ứng dụng đc viết bằng Java Spring Boot. Bắt đầu thôiiii.

1. Đăng kí tài khoản New Relic

Đăng kí tài khoản New Relic rất dễ dàng tại link sau: https://newrelic.com/signup

Sau khi đăng kí thằng công, màn hình hiển thị trang dashboard của hệ thống và chúng ta có thể bắt đầu setup

2. Tạo ứng dụng Java và cài đặt

2.1. Thông tin ứng dụng

Trên bảng stack, chọn ứng dụng Java và tiếp tục, sau đó chọn Don’t have access the host và chọn Java tại mục Connect your applications.

Ở bài viết này chúng ta đang thực hiện trên máy chủ AWS Beanstalk nên tôi sẽ chọn On a host. Sau đó nhập tên ứng dụng và làm các bước theo hướng dẫn.

Ở bước Tell us about your environment, tôi chọn running on Linux và framework là Spring Boot.

2.2. Cài đặt gói thư viện

Bước tiếp theo chúng ta cần tiến hành cài đặt gói thư viện. Bởi vì dùng AWS Beanstalk nên tôi sẽ thực hiện việc cài đặt trong folder .ebextension

Tạo file newrelic.config trong thư mục .ebextensions

commands:
  01-download-java-agent:
    command: "curl -O https://download.newrelic.com/newrelic/java-agent/newrelic-agent/current/newrelic-java.zip && mv newrelic-java.zip /var/newrelic-java.zip"
  02-unzip-java-agent:
    command: "unzip -o /var/newrelic-java.zip -d /var/"
  03-give-permissions-to-newrelic:
    command: "chmod a+rwx /var/newrelic"
  04-replace-license-key:
    command: "sed -i 's/<%= license_key %>/your_application_license_key/g' /var/newrelic/newrelic.yml"
  05-replace-application-name:
    command: "sed -i 's/My Application/your_application_license_key/g' /var/newrelic/newrelic.yml"
  06-enable-infras-and-logs-metric:
       command: "your_application_cmd_curl_infra"

Trong đó:

• your_application_license_key: license_key của bạn.
• your_application_license_key: Application name mà bạn đã đăng kí vơi new relic.
• your_application_cmd_curl_infra: Command bạn nhận đc ở bước Connect your logs and infrastructure.

Nếu bạn chỉ muốn giám sát ứng dụng mà ko muốn giám sát Infras, bạn có thể bỏ qua bước 06-enable-infras-and-logs-metric. Nếu cài đặt hãy disable option Automatically answer “yes” to all install prompts. We’ll stop the installer if there’s an error. trên dashboard NewRelic

3. Deploy với CodeBuild và CodePipeline

Chúng ta cần tạo file Procfile trong folder root của source code để định nghĩa câu lệnh chạy ứng dụng java kèm theo NewRelic

Procfile:

web: java -javaagent:/var/newrelic/newrelic.jar -jar app.jar

Config sẽ không chạy nếu folder .ebextensions không được deploy lên Beanstalk. Dưới đây là file Buildspec của tôi

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto11
  build:
    commands:
      - mvn install
      - mv target/*.jar app.jar
artifacts:
  files:
    - Procfile
    - app.jar
    - .ebextensions/**/*

Cuối cùng sau khi deploy thành công, thực hiện Test Connection trên NewRelic để tạo ứng dụng:

4. Tổng kết

Còn 1 phần quan trọng mình chưa đến đó là chi phí, theo mình tìm hiểu NewRelic sẽ tính phía dựa trên dung lượng sử dụng trên hệ thống, chúng ta sẽ được miễn phí với 100GB/tháng

Trên đây là tổng hợp các bước setup NewRelic với ứng dụng Java chạy trên AWS Beanstalk của mình, hi vọng giúp ích mọi người.

Về những thông số và giá trị đem lại anh em hãy tự trải nghiệm và tận hưởng nheeeeeeeeé

The post Setup New Relic for monitoring AWS Beanstalk and Java Spring Boot appeared first on Tomoshare.