Tại sao web service phải là stateless mà không phải stateful

#1

Web service bắt buộc phải thiết kế stateless. Theo lý thuyết thì có 2 lí do:

  • Dễ scale theo chiều ngang. Vì nếu có 2 server mà session tạo trên server 1 thì server 2 không access được session trên server 1 để author, phải gửi broadcast, multicast mỗi khi user authen.
  • Giảm tải server, server không quản lý session, restart server thì session_id của user lưu trong cookie bị hết hiệu lực, v/v.

Đối với web nhỏ như wordpress, odo và các CMS tương tự chỉ cần scale theo chiều dọc, và khách yêu cầu thêm 1 app mobile, em nghĩ không cần triển khai token JWT. Hiện tại trên mobile em xử lý như này: authen xong thì không return token mả return về session_Id cho mobile, mobile muốn gọi function của backend thì phải config tất cả request cho giống request của browser (cho session_id vào cookie do mobile fake). Server không phân biệt được mobile hay browser vì request hoàn toàn giống nhau, mobile có thể giải lập ra user agent.

Vậy cho em hỏi cách này có ưu nhược điểm gì. Cảm ơn.

#2
  1. Cách đặt câu hỏi lan man, ko đi thẳng vào vấn đề, khúc trên đưa ra nhằm mục đích gì. Sao ko hỏi thẳng vào vấn đề gặp phải bên dưới để mọi người dễ focus hơn.
  2. Vì nếu có 2 server mà session tạo trên server 1 thì server 2 không access được session trên server 1 để author -> Sai, có rất nhiều cách xử lý vấn đền này: use 1 central server để store session, hoặc sticky session, hoặc session chứa ở tất cả các server. Tùy tình huống mà dùng.
  3. JWT có gì khó đâu mà ko làm đc nhỉ, framework, lib có support hết rồi. Tìm cách dùng session cho mobile còn tốn effort hơn là dùng JWT
3 Likes
#3

Ví dụ dự như khách đang có 1 trang web WordPress, odoo đang chạy bình thường. Khách yêu cầu làm thêm 1 app di động. Khi viết controller login bằng PHP, nếu đúng như thiết kế web service thì controller này phải trả về JWT, nhưng em cho trả về session_id cũng không vấn đề gì. Nó vẫn hoạt động bình thường. Nên em mới thắc mắc thiết kế website service có nhất thiết phải stateless hoàn toàn không. Dưới góc độ client, mỗi request phải gửi kèm token trong header, nhưng thay vì gửi JWT thì thay bằng sessionId cũng có khác gì nhau đâu.

Thì em có bảo bên trên á anh, nếu có 2 server thì lại tốn thêm 1 server thứ 3 nối 2 server này lại.

Sau đó server thứ 3 multicast cái session_id này đến 2 server còn lại.
Nhưng project nhỏ ít khi dùng đến 2 server lắm, với cả case của em chỉ làm web đơn giản, web cho doanh nghiệp nhỏ bằng WordPress thì chỉ cần 1 server. Mặc dù WordPress có plugin RESTful API nhưng em vẫn thắc mắc nó có thật sự cần thiết trong những case này không?

#4

Ví dụ như case này: Ông A là web cho chị B (web dùng các công nghệ render giao diện Server side rendering như JSP, blazor, WordPress CMS, … quản lý authen/author bằng việc check role account trong session của web server) một ngày đẹp trời chị B gọi cho ông A “em ơi cái web hôm trước làm thêm cho chị một app đi động publish lên CHPlay, appstore luôn nhen em”. Cụ thể là hệ thống ERP odoo (khá giống WordPress) plugin RESTful API có thu phí, tự làm một filter layer mỗi request, viết hàm verify signature token, … có thể tốn 1 ngày mới xong. Cách nhanh nhất là tận dụng lại các control cũ, thay vi return về document HTML, thì chỉnh lại tí thành return về JSON, hàm login cho trả về thêm sessionId rồi đưa cho team mobile code tiếp và bảo “mỗi request get data các chú cứ gửi kèm session_id là được”. Case này em thấy cài JWT với dùng cách này không khác nhau.

#5

Tới đây chốt được rồi
Mục đích cuối cùng của phát triển phần mềm, là làm ra được sản phẩm vấn đề của người dùng

Còn nếu bạn có tinh thần học tập, thì sao không thử tự làm theo 2 cách?
Và theo mô tả của bạn, bạn nghĩ giải pháp của bạn đanh là stateful sao?

2 Likes
#6

Không biết em có đang bị hỏng kiến thức hay đã bỏ lỡ điều gì không?! Em nghĩ cách làm của em là stateful vì server lưu trữ session của từng client nên những request của client sẽ bị ảnh hưởng bởi những request trước đó!

#7

trước hết, bạn cần viết rõ ràng, bạn tự giải thích với bản thân cũng là một cách để xác nhận lại kiến thức
bạn giải thích câu trên xem,
lưu trữ session là lưu trữ gì, lưu trữ/truy vấn như nào?
nhận diện client như nào?

theo như bạn nói, bạn có thể chủ động truyền “session_id” để server nhận diện client, bạn truyền ở đâu? vậy là nhận diện client hay là nhận diện “session_id”? và nếu như nhận diện session_id thì client khác truyền session_id của ngừoi khác thì sao, lúc này là stateful hay stateless?

2 Likes
#8
  • Session là một cái gì đó giúp duy trì quan hệ giữa 2 thiết bị không liên quan gì đến nhau.
  • Nếu giải thích dưới góc độ kỹ thuật em sẽ giải thích như này: session là một phiên phục vụ của máy tính server với máy tính client, trong phiên làm việc này, session cần một khoảng không gian lưu trữ (Cụ thể là chúng ta có thể lưu dữ liệu vào session dạng key value, session.setAttribute("MY_KEY", 123)) khoảng không gian này cần một Id định danh để biết vùng không gian này thuộc về client nào. Đa phần dữ liệu trong bộ nhớ session này được lưu trong RAM (mặc định timeout khoảng 30 phút), theo em được biết nó còn có thể lưu vào ổ đĩa, còn việc implement và lưu trữ session này do web server thực hiện, em không hiểu sâu lắm.
    Khi client gửi request đầu tiên,cookie của request không có session Id nào cả, nên web server mới generate session và response lại session_id cho client. Sever giữ id này và client cũng giữ Id này để so sánh những lần sau. Cụ thể là khi truy cập vào daynhauhoc.com thì cookie sẽ có một mã có tên là _forum_session. Những request sau đều tự động gửi kèm _forum_session này, do đó em bấm like post sẽ không bị bắt login nữa, vì request trước đó đã authen rồi. theo lý thuyết thì em login xong chỉ cần lưu lại mã _forum_session này những lần sau không cần nhập username, password để authen nữa mà mở cookie lên paste trực tiếp mã này vào cookie hoặc dùng cách này share tài khoản cho người khác, nhưng không hiểu sao với DNH thì không làm được (web cổ cách đây chục năm thì làm được, cổ như những trang đăng kí môn học ở trường đại học)
  • Nếu giải thích kiểu bình dân học vụ thì: Anh làm bác sĩ, em là bệnh nhân lần đầu đến khám, do khám lần đầu nên anh ghi mã tái khám cho em, những lần sau đến tái khám em không cần giải thích lại tiền sử bệnh, khai báo lại họ tên CMND mà chỉ cần đưa anh một đoạn code, anh sẽ map với hồ sơ bệnh án trước đó mà khám bệnh tiếp.

Em đang là sinh viên, đây là cách em hiểu, mong được chỉ bảo thêm.

#9

Ví dụ hệ thống chat vẫn phải lưu state mới quản lý được user nào đang ở room nào.
Các state của web service thì thông thường phải lưu trên các memory cache service để đảm bảo tốc độ xử lý cũng như dễ dàng chia sẻ state giữa các web service với nhau.

Đa số các hệ thống hướng đến thiết kế stateless vì tính đơn giản, dễ dàng scale, giảm sự cố.
Ví dụ như hệ thống stateful ở trên mà chết con memory cache service thì sẽ tạch cả hệ thống.

Hệ thống nào cũng sẽ có ưu nhược điểm, phù hợp với từng trường hợp chứ ko phải nhất nhất phải dùng cái này bỏ cái kia.

5 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?