2. Agenda
• Giới thiệu về Bizweb
• Mô hình kiến trúc cũ & các vấn đề gặp phải
• Mô hình kiến trúc Microservices áp dụng cho Bizweb
• Demo
• Chia sẻ kinh nghiệm áp dụng
2
6. Công nghệ sử dụng
• .NET Framework
• ASP.NET Web Forms
• VB.NET
• SQL Server
• Windows Server / IIS
• Thrift – media server
• Redis – cache, chống DOS đơn
giản
• HA Proxy – load balancer
6
9. Vấn đề hệ thống
• Công nghệ lạc hậu: phát triển từ năm 2007 trên nền tảng VB.NET
• Hệ thống chạy thiếu ổn định
• Sử dụng View engine của Web Forms:
• Stateful: website chứa file giao diện (60K thư mục template)
• Tốn nhiều thời gian biên dịch & khởi động lại IIS
• Khó scale được hệ thống do không đồng bộ được thư mục template
10. Vấn đề phát triển
• Có quá nhiều tính năng (48 module)
• Tốc độ phát triển chậm
• Khó nắm bắt & sửa code, đặc biệt là với nhân viên mới
• IDE bị quá tải, chạy chậm
• Khó mở rộng & phân chia đội ngũ
• Gắn chặt với 1 nền tảng công nghệ (Microsoft)
10
12. Một số yêu cầu
• Tối giản số tính năng phát triển (23 tính năng)
• Mở API để các nhà phát triển ứng dụng có thể tích hợp
• Service hóa mọi nghiệp vụ, Web/API/Mobile gọi vào qua Service
• Cơ chế giao diện mới
• Dễ phát triển và mở rộng (scale hệ thống, team phát triển)
• Chỉ có 6 tháng phát triển để đưa vào hoạt động
12
14. Ưu điểm của kiến trúc Microservices
• Phân tách hệ thống ra thành từng service nhỏ, phục vụ 1 mục đích
duy nhất -> dễ hiểu, dễ sửa
• Project/Solution nhỏ -> IDE chạy nhanh
• Mỗi service chạy trên 1 instance riêng -> khởi động nhanh
• Deploy 1 service ko làm chết service khác -> deploy dễ hơn
• Ko phụ thuộc vào 1 nền tảng công nghệ nào cả
• Dễ scale
14
21. Request vào hệ thống
Microservices
• Service chạy trên nhiều máy chủ,
ở nhiều port khác nhau
• Các service có thể bật, tắt, bổ
sung bất cứ lúc nào
• Cân tải giữa các microservices
• Request giữa các microservices
• Nginx (bản free) không giải quyết
được việc định tuyến này
21
22. Eureka Service Discovery
• Mỗi 1 service được định danh bằng
serviceId (cấu hình trong
spring.application.name)
• Service sử dụng Eureka Client để tương
tác với Eureka Server:
• Register: đăng ký mới (serviceId, host,
port)
• Renew: sử dụng heartbeats định kỳ đăng
ký lại để biết service còn hoạt động
• Get Registry: trả về danh sách host:port
của các service theo serviceId
22
23. Service Discovery & API Gateway
23
Get Registry
store
10.0.0.1:8080
10.0.0.2:8081
10.0.0.3:8082
24. Zuul API Gateway
• Địa chỉ truy xuất duy nhất để gọi vào các microservices
• Zuul là edge service -> không dùng để các microservices gọi lẫn nhau
• Zuul sử dụng Ribbon để gọi tới các service
• Client Load Balancer
• Caching
• ZuulFilter: xử lý các request theo cơ chế pipeline
• PRE: xử lý trước khi routing đến service
• ROUTING: thay đổi routing
• POST: xử lý sau khi service trả về kết quả
• ERROR: xử lý khi có lỗi xảy ra
24
26. RateLimitFilter
• Dùng để giới hạn tần suất gọi API
• Sử dụng giải thuật Leaky Bucket (Fill
Rate: 2 request/s, Bucket Size: 200)
• Thông tin trả về cho client qua Http
Header:
X-Bizweb-Api-Call-Limit: 16/200
• 16: số request đã sử dụng
• 200: số request tối đa
• Vượt ngưỡng: trả về mã lỗi 429 - Too
Many Requests
26
28. Centralized Configuration
28
Vấn đề:
- Cấu hình phân tán, khó
kiểm soát
- Các service có 1 số cấu
hình chung, thay đổi là
phải đổi hàng loạt
- Reload config khi đang
chạy
30. Spring Cloud Config
• Thông tin file cấu hình được lưu trong git hoặc file vật lý
• Tên file: {serviceId}.yml
• Nhiều môi trường: dev, test, stage, live...
• Kế thừa từ application.yml: mọi service đều lấy cấu hình
chung
• File bootstrap.yml: cấu hình serviceId, config server, môi
trường
• Reload Config: HTTP GET [service-host:port]/refresh
• Spring Cloud Bus 1.1 – đang phát triển, auto reload
30
32. Đối tượng yêu cầu truy cập
• 1st Party: Frontend, Backend, kho Theme, kho App, quản trị hệ
thống...: toàn quyền truy xuất mọi website
• 3rd Party: ứng dụng của các nhà phát triển cung cấp thêm tính năng
cho chủ website: chủ website cấp quyền truy xuất từng tài nguyên
• Private App: chủ website tự phát triển hoặc thuê làm: quyền truy
xuất mọi tài nguyên của website đó
• Mobile app: đăng nhập để lấy token truy xuất
→Cần 1 phương thức xác thực & kiểm tra quyền linh hoạt -> OAuth2 +
Spring Security
32
33. 33
Ghi chú:
• 3rd Apps: xác thực OAuth qua
Access Token
• Private App: Basic Authentication
• Store Front: Client Credential
• Store Backend: Client Credential,
Session Credential (Share session
giữa Backend và OAuth Server)
35. 35
Fallback
Fault Tolerance
• Điều gì xảy ra khi Order Service chết?
• Chết hàng loạt các service liên quan
• Thời gian xử lý request lâu do phải chờ
timeout 30s
• Chiếm tài nguyên
• => cần giảm thời gian chết bằng cách
báo lỗi luôn (fail fast) , ko đưa vào
queue xử lý
• Bizweb sử dụng Hystrix để xử lý
36. Circuit Breaker Pattern
• Giống cầu dao điện:
• Closed: đóng – hoạt động
• Open: ngắt – không hoạt động
• Failure: exception hoặc timeout
• Threshold = failure / (success + failure) *
100%
• Threshold = 50%, volumn = 20, retry = 5s
-> trong 20 request gần nhất, 10 request lỗi
là ngắt, sau mỗi 5s cho 1 request qua để
kiểm tra, thành công thì đóng mạch, thất
bại thì tiếp tục mở
36
37. Hystrix Dashboard & Turbine
• Hystrix dashboard:
• Xem biểu đồ thời gian thực các API được gọi, độ trễ 2s
• Xem cho từng service instance
• Turbine: tổng hợp các service instance cùng serviceId lại để dễ theo
dõi
• Dữ liệu từ mỗi instance gửi về Turbine theo 2 cách:
• Gửi trực tiếp
• Gửi qua message queue (RabbitMQ)
37
39. Bizweb mới đi được hơn 1/3 chặng đường
1. Mô hình ban đầu chạy được
• Hệ thống chạy ổn định theo hướng kiến trúc Microservices
2. Áp dụng CI/CD & Monitoring
• Tự động hóa quy trình test & deploy hệ thống
• Centralized logging, debug + performance tools, email/SMS/app alert
3. Phân tách service & Scale hệ thống
• Chia nhỏ Microservices
• Virtualization & Auto Scaling
39
41. 41
Tiền điều kiện:
• Kỹ năng lập trình tốt
• Công cụ giám sát dịch vụ
• Áp dụng CI/CD
• Văn hóa DevOps
42. Nếu team bạn không đủ điều
kiện, bạn có dám làm?
42
43. Khó khăn gặp phải của team Bizweb
• Mô hình mới hoàn toàn, tài liệu/code mẫu ít
• Thư viện Spring Cloud Netflix vẫn đang phát triển
• Không có chuyên gia để hỏi
• Dịch chuyển closed source -> open source, từ Windows -> Linux
• Code đồng thời C#, Java (coding convention, tăng thời gian phát triển)
• Test phức tạp hơn
• Áp lực lớn, lụt deadline
• Nhân sự: thiếu người nghiên cứu & phát triển, thiếu vị trí DevOps
43
44. Thuận lợi
• Có mô hình chuẩn để học theo (Netflix, Shopify)
• Nghiệp vụ hệ thống không quá phức tạp
• Bounded Context không phải là vấn đề cần phải xử lý ngay từ đầu
44
45. Thiết kế hướng Microservices trước
• Nghiên cứu chuẩn viết API
• Không sử dụng phiên bản
API
• Định dạng URI snake_case
• Đặt tên hàm, biến
• Method: GET, POST, PUT,
DELETE
• Lựa chọn ngôn ngữ phù
hợp thay vì ngôn ngữ thời
thượng
• Tìm hiểu trước về Bounded
Context
45
46. Chưa cần áp dụng mô hình triệt để
• Phân tách ra 2-3 Service
• Gọi trực tiếp vào từng
service
• Hạn chế tối đa gọi chéo
giữa các service
• Chưa cần Service
Discovery, API Gateway,
Fault Tolerant, Message
Queue...
46
47. Hạn chế thêm nhiều công nghệ/công cụ mới
đồng thời
47
48. Cách tiếp cận của Bizweb
• Thiết kế hướng Microservices trước
• Chưa cần áp dụng ngay mô hình chuẩn
• Hạn chế thêm nhiều công nghệ/công cụ mới đồng thời
• Cải tiến & làm mịn dần
• Liên tục tự nâng cao kỹ năng của nhóm
48