O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
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
Próximos SlideShares
Carregando em…5
×

Bizweb Microservices Architecture

20.535 visualizações

Publicada em

Bizweb Microservices Architecture

Publicada em: Software
  • Seja o primeiro a comentar

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

×