Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Bizweb Microservices Architecture
KhoiNM@dkt.com.vn
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 B...
Sale
channel
Shipping
Sale Tool
Payment
CRM
Marketing
Theme
Store
App
Store
Bizweb
OPEN
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 serve...
Kiến trúc Monolithic
7
Scale
Vertical 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 V...
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 ...
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
•...
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...
Scale
Functional 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
•...
17
Bizweb Microservices Architecture
Các vấn đề trong kiến trúc Microservices của
Bizweb
• Routing & Service Discovery
• Centralized Configuration
• Authentica...
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...
Eureka Service Discovery
• Mỗi 1 service được định danh bằng
serviceId (cấu hình trong
spring.application.name)
• Service ...
Service Discovery & API Gateway
23
Get Registry
store
10.0.0.1:8080
10.0.0.2:8081
10.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 mic...
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...
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à
...
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 ...
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 ...
33
Ghi chú:
• 3rd Apps: xác thực OAuth qua
Access Token
• Private App: Basic Authentication
• Store Front: Client Credenti...
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ử...
Circuit Breaker Pattern
• Giống cầu dao điện:
• Closed: đóng – hoạt động
• Open: ngắt – không hoạt động
• Failure: excepti...
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 s...
Demo
Eureka, 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 Microserv...
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 p...
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ôn...
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
• ...
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...
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...
Tham khảo
• http://netflix.github.io/
• http://spring.io/
• http://microservices.io/
• http://martinfowler.com/bliki/Micro...
Liên hệ
• Nguyễn Minh Khôi – DKT Technology
• Email: khoinm@dkt.com.vn
• Facebook: https://fb.com/khoinguyen84
50
Giao lưu!
51
Upcoming SlideShare
Loading in …5
×

Bizweb Microservices Architecture

20,502 views

Published on

Bizweb Microservices Architecture

Published in: Software
  • Be the first to comment

Bizweb Microservices Architecture

  1. 1. Bizweb Microservices Architecture KhoiNM@dkt.com.vn
  2. 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
  3. 3. Sale channel Shipping Sale Tool Payment CRM Marketing Theme Store App Store Bizweb OPEN platform
  4. 4. 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
  5. 5. Kiến trúc Bizweb cũ 5
  6. 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
  7. 7. Kiến trúc Monolithic 7
  8. 8. Scale Vertical Scaling Horizontal Scaling 8
  9. 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. 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
  11. 11. Kiến trúc Bizweb mới 11
  12. 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
  13. 13. Mô hình Microservices 13
  14. 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
  15. 15. Scale Functional Scaling (Microservices) Team Scaling (Microservices) 15
  16. 16. 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. 17. 17 Bizweb Microservices Architecture
  18. 18. Các vấn đề trong kiến trúc Microservices của Bizweb • Routing & Service Discovery • Centralized Configuration • Authentication & Authorization • Fault Tolerance 18
  19. 19. Routing & Service Discovery 19
  20. 20. 20 /admin/products.json Request ngoài hệ thống Bizweb ???
  21. 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. 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. 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. 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
  25. 25. 25
  26. 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
  27. 27. Centralized Configuration 27
  28. 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
  29. 29. Centralized Configuration 29
  30. 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
  31. 31. Authentication & Authorization 31
  32. 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. 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)
  34. 34. Fault Tolerance 34
  35. 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. 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. 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
  38. 38. Demo Eureka, Hystrix Dashboard, RateLimitFilter, & Circuit Breaker 38
  39. 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
  40. 40. Chia sẻ kinh nghiệm 40
  41. 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. 42. Nếu team bạn không đủ điều kiện, bạn có dám làm? 42
  43. 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. 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. 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. 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. 47. Hạn chế thêm nhiều công nghệ/công cụ mới đồng thời 47
  48. 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
  49. 49. 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
  50. 50. Liên hệ • Nguyễn Minh Khôi – DKT Technology • Email: khoinm@dkt.com.vn • Facebook: https://fb.com/khoinguyen84 50
  51. 51. Giao lưu! 51

×