Embed Size (px)
Citation preview
Bizweb Microservices [email protected]
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
Sale channel
Shipping
Sale Tool
Payment
CRM
Marketing
Theme Store
App Store
BizwebOPEN
platform
Thống kê Bizweb
• Shop trả phí đang hoạt động: +11K
• Shop tăng hàng tháng: +700
• Shop dùng thử hàng tháng: +10K
4
Kiến trúc Bizweb cũ
5
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
Kiến trúc Monolithic
7
ScaleVertical Scaling Horizontal Scaling
8
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
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
Kiến trúc Bizweb mới
11
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
Mô hình Microservices
13
Ư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
ScaleFunctional Scaling
(Microservices)
Team Scaling(Microservices)
15
Công nghệ sử dụng
• ASP.NET MVC
• C# / Java / NodeJS
• Spring Boot, Spring Cloud, Spring Security, Spring Security OAuth
• Netflix OSS: Zuul, Hystrix, Turbine, Eureka, Ribbon, Feign
• IIS/Jetty
• Windows Server / Ubuntu
• dotLiquid
• RabbitMQ
• Redis
• Nginx
• Cloud Service: Amazon EC2, S3, Route53
• Apache Traffic Server
• Thumbor
16
17
Bizweb Microservices Architecture
Các vấn đề trong kiến trúc Microservices của Bizweb
• Routing & Service Discovery
• Centralized Configuration
• Authentication & Authorization
• Fault Tolerance
18
Routing & Service Discovery
19
20
/admin/products.json
Request ngoài hệ thống Bizweb
???
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
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
Service Discovery & API Gateway
23
Get Registrystore
10.0.0.1:808010.0.0.2:808110.0.0.3:8082
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
25
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
Centralized Configuration
27
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
Centralized Configuration
29
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
Authentication & Authorization
31
Đố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
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)
Fault Tolerance
34
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ý
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
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
DemoEureka, Hystrix Dashboard, RateLimitFilter, & Circuit Breaker
38
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
Chia sẻ kinh nghiệm
40
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
Nếu team bạn không đủ điều kiện, bạn có dám làm?
42
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
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
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
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
Hạn chế thêm nhiều công nghệ/công cụ mới đồng thời
47
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
Tham khảo
• http://netflix.github.io/
• http://spring.io/
• http://microservices.io/
• http://martinfowler.com/bliki/MicroservicePrerequisites.html
• http://martinfowler.com/articles/microservices.html
• http://12factor.net/
49
Liên hệ• Nguyễn Minh Khôi – DKT Technology
• Email: [email protected]
• Facebook: https://fb.com/khoinguyen84
50
Giao lưu!
51
