ke_xa_la_01
Member
Dự án này hoàn toàn fail về mặt business. Dù sao cũng +1 cho tinh thần chia sẻ của bác, nhưng em cũng khuyên bác nên dừng cuộc chơi tại đây, em thấy có vẻ phí thời gian khi tiếp tục đầu tư vào nó.
thảo luận Xin nhận xét về SaaS app mà mình vừa hoàn thành
- Thread starter PuKaX
- Start date
lam vung lau lam
Junior Member
Lúc gitlab mới ra tất nhiên tôi không dùng rồi.
Nói về tin cậy thì nói mồm không thể tin được. Như nhiều sàn giao dịch bitcoin ôm tiền chạy đó. Anh nói RSA dễ implement nên cho vào, thế sao hash function cũng dễ mà nhiều thằng còn lưu plain password.
Thứ 2 là tôi không muốn chứng minh gì cả. Tôi chỉ không hiểu tại sao anh cần 2 bus. webservice anh gửi thông tin tài khoản đi (sau khi được anh mã hóa + SQS mã hóa), rồi sau đó webservice nhận lại thông tin giao dịch về, nghĩa là webservice có tất cả thông tin, vậy thì cần tách thành 2 bus làm gì.
katoshi
Senior Member
Bác này cứ lăm le vô điểm này thấy nó ngây thơ vs bắt bẻ vô lý vãi.
Như tôi thấy thì volume của SQS-A có thể sẽ ít hơn nhiều so vs SQS-B.
Mô hình này hợp lý quá chứ còn j nữa. Tách riêng ra 2 sqs càng tăng tính độc lập và dễ xử cũng đc chứ sao.
Tất nhiên gom chung cũng ddc ko sao cả. Có j mà bác cứ lăm le bắt bẻ điểm này nhỉ.
Còn về bác thớt: Mình đồng ý vs nhiều bác ở đây về vụ độ tin tưởng . Bác có thể hưa ABC nhưng close source thì ko có j để chứng minh và làm an lòng khách hàng hết vì thông tin tiền bạc cấp độ nhảy cảm và quan trong số 1.
lam vung lau lam
Junior Member
Bệnh nghề nghiệp thôi anh. Tôi làm gì cũng đều hỏi tại sao. Tôi không phải muốn chứng minh chủ thớt thiết kế sai, mà tôi muốn hỏi lí do sâu xa để sau này biết đâu áp dụng được.
À mà lí do thớt tách thành 2 bus là vì bảo mật nhé. Chính anh cũng hiểu sai ý định của thớt rồi.
python2.7
Member
- Nhu cầu là có nhưng thớt là thằng nào đâu ai biết, nên chắc chẳng ai dại mà dám dùng service của thớt.
- Ai thực sự có nhu cầu tích hợp kiểu này, chắc cũng có khả năng tự setup dc. Thớt build dạng sdk bán source + dịch vụ support, triển khai nghe bộ còn có lý hơn.
- thay vì dựa vào crawl để lấy thông tin giao dịch từ bank, có thể lấy từ sms (smart banking dc ko nhỉ?) Mình ko rõ, chỉ nghĩ vậy thôi. Mấy bên nhà mạng hình như có Api cho sms.
- tần suất crawl 30 phút theo mình là hơi lâu. 5,10 phút là hợp lý. Cơ mà do thớt tự crawl nên cũng chưa biết mai mốt ngân hàng nó chặn thì thớt giải quyết như nào
Huhu7991
Senior Member
Trừ khi bị lộ aws credentials thì mới có khả năng thôi chứ lộ endpoint cũng không phải vấn đề
lam vung lau lam
Junior Member
Nếu bảo mật như vậy thì 2 cái bus 1 chiều khác gì 1 cái bus 2 chiều nhỉ?
katoshi
Senior Member
Thì tôi cũng đồng ý vs anh tách vì lý do bảo mật nó hơi "lạ" .
Bản thân tôi tự thấy lí do đơn giản là:
- tăng sự độc lập & tách biệt nhau do data ở 2 queue có độ nhạy cảm khác nhau
- dễ phân bổ tài nguyên vì volume 2 queue khác biệt nhau.
Theo m là không khác j về mặt bảo mật . Như bác đã nói ở trên , lý do bảo mật nên xài 2 sqs nó lạ lạ sao á
Fail business
lam vung lau lam
Junior Member
Cái mà tôi lăn tăn là vậy đó.
Web ba ếch
Junior Member
Mấy web kiểu này lưu lượng nhỏ thì dùng monolith quản lý transaction cực kì đơn giản, làm ra cái mớ microservices thì chắc gì bạn đảm bảo được data consistency, fault tolerance các kiểu
.
Bản chất thì monolith nó bảo mật tốt hơn microservice nhiều lần, chứ cái mớ trên kia nhìn tới nhìn lui là thấy 4 lỗ có thể exploit rồi: web server, crawler, 2 cái bus. Lủng chỗ nào cũng đều chết cả
Bản chất thì monolith nó bảo mật tốt hơn microservice nhiều lần, chứ cái mớ trên kia nhìn tới nhìn lui là thấy 4 lỗ có thể exploit rồi: web server, crawler, 2 cái bus. Lủng chỗ nào cũng đều chết cả
Last edited:
lam vung lau lam
Junior Member
Theo tôi hiểu là dùng microservice là để dùng SQS, để bảo mật thông tin tài khoản ngân hàng.Mấy web kiểu này lưu lượng nhỏ thì dùng monolith quản lý transaction cực kì đơn giản, làm ra cái mớ microservices thì chắc gì bạn đảm bảo được data consistency, fault tolerance các kiểu
Web ba ếch
Junior Member
Không hiểu tư duy cậu thread lắm, data ngân hàng nằm hết trong cái crawler kia chứ có bảo mật quái gì đâu, data giao dịch nằm hết trong cái web service. Rồi 2 cái bus thằng nào inject vô được cũng soi được thông tin.
Data cậu encrypt hết rồi thì thích thì gửi qua http còn được, cần đếch gì sqs
Hay ý cậu kia là giấu cái crawler service đi thì không ai biết cái database ngân hàng nó nằm ở đâu
Nói chung cậu này làm mấy thứ liên quan đến tiền bạc mà tư duy bảo mật như lol, không nói thì thôi nói ra có cức mà tôi dám xài, bài toán security đơn giản cậu vẽ lại 1 cách ngây ngô, tôi nghĩ cậu thread nên học 1 khóa security 101 trước rồi hẵng làm
Tôi nhìn tới nhìn lui cái hình là thấy có mùi security by obscurity đâu đây rồi
Last edited:
Huhu7991
Senior Member
SQS là pull-based message queue không phải là pub-sub nên dùng 1 SQS cho cả 2 chiều thì xử lý rắc rối vkl.
Do SQS sẽ dùng at-least-once delivery nên hiếm khi có trường hợp cùng một message nhưng được pull nhiều lần. Vì thế nếu message này không phải dành cho crawler thì lại phải đẩy vào SQS ngược lại.
Nên dùng cho một SQS cho một mục đích để dễ xử lý.
Còn bảo mật thì không biết.
Do SQS sẽ dùng at-least-once delivery nên hiếm khi có trường hợp cùng một message nhưng được pull nhiều lần. Vì thế nếu message này không phải dành cho crawler thì lại phải đẩy vào SQS ngược lại.
Nên dùng cho một SQS cho một mục đích để dễ xử lý.
Còn bảo mật thì không biết.
Last edited:
gaveezy
Senior Member
in đậm ghi tào lao, trong 3 loại at-least-once, at-most-once và exactly-once thì cái at-least-once là thường xảy ra việc xử lý 1 message nhiều lần nhất rồi còn gì
Huhu7991
Senior Member
At-least-once là vì sau khi message được xử lý thành công sẽ bị xóa khỏi queue nên trong trường hợp có lỗi xử lý hoặc không xóa được thì có thể bị duplicate.
Và khi một message được pull về bởi 1 consumer/receiver thì các consumer khác sẽ không thấy được message này nữa cho đến khi timeout.
https://docs.aws.amazon.com/AWSSimp...s.html#standard-queues-at-least-once-delivery
gaveezy
Senior Member
có hiểu tôi nói gì không đấy
lam vung lau lam
Junior Member
Giải thích như này còn hợp lí. Nếu thớt giải thích như này thì tôi đã không thắc mắc.
Bị nói ngược at most once. Tôi chưa dùng SQS bao giờ nhưng theo logic là như thế.
Huhu7991
Senior Member
Hiểu nhưng ý câu in đậm là nói cho việc dùng 1 cái SQS để làm 2 chiều cho cả web service và crawler của thread. Giả sử khi crawler nhận message và check không phải topic tương ứng thì phải push lại vào SQS chứ trong quá trình một message được nhận bởi một consumer thì nó sẽ not available cho các consumer khác.
loilinh90
Senior Member
Cái này trước đội Money Lover có làm.
Bên mình cũng làm 1 phần tương tự, cơ mà là tích hợp vào hệ thống quản trị tài chính cho doanh nghiệp.
Dùng private cho doanh nghiệp thì còn tạm an tâm về vấn đề bảo mật. Chứ của thím là Saas thế kia thì chắc chắn sẽ bị hack luôn
.
Nói chung là khách hàng ko ai dám nhập user + password lên site của thím cả. Không ai đảm bảo được tính bảo mật của hệ thống hết.
Ở VN mấy cty to như Thegioididong, VNG còn bị hacker nằm trong hệ thống cả năm trời mà ko phát hiện ra. Site của thím thì lấy gì ra mà đảm bảo.
Edit: Ngoài ra thì còn vấn đề về bảo mật thông tin. Hầu hết người dùng không muốn lộ thông tin các khoản thu chi của mình.
Khách hàng cá nhân thì lượng giao dịch tương đối ít, không khó kiểm soát mà phải dùng hệ thống này.
Doanh nghiệp thì chỉ một số ít doanh nghiệp đặc thù (có quá nhiều giao dịch chuyển khoản). Chứ hầu hết các cty bán lẻ nhiều đơn thì giờ chỉ đối soát qua COD với bên vận chuyển, chứ hạn chế giao dịch chuyển khoản lắm.
Nói chung là ngày xưa bên mình cũng làm rồi, sau nửa năm làm hệ thống như này thì phát hiện ra là không có tiềm năng kinh doanh. Được cái mày mò cách login vào các ngân hàng cũng hay. Phát hiện ra là các hệ thống của ngân hàng hầu như đều nát như shit hết
Bên mình cũng làm 1 phần tương tự, cơ mà là tích hợp vào hệ thống quản trị tài chính cho doanh nghiệp.
Dùng private cho doanh nghiệp thì còn tạm an tâm về vấn đề bảo mật. Chứ của thím là Saas thế kia thì chắc chắn sẽ bị hack luôn
.Nói chung là khách hàng ko ai dám nhập user + password lên site của thím cả. Không ai đảm bảo được tính bảo mật của hệ thống hết.
Ở VN mấy cty to như Thegioididong, VNG còn bị hacker nằm trong hệ thống cả năm trời mà ko phát hiện ra. Site của thím thì lấy gì ra mà đảm bảo.
Edit: Ngoài ra thì còn vấn đề về bảo mật thông tin. Hầu hết người dùng không muốn lộ thông tin các khoản thu chi của mình.
Khách hàng cá nhân thì lượng giao dịch tương đối ít, không khó kiểm soát mà phải dùng hệ thống này.
Doanh nghiệp thì chỉ một số ít doanh nghiệp đặc thù (có quá nhiều giao dịch chuyển khoản). Chứ hầu hết các cty bán lẻ nhiều đơn thì giờ chỉ đối soát qua COD với bên vận chuyển, chứ hạn chế giao dịch chuyển khoản lắm.
Nói chung là ngày xưa bên mình cũng làm rồi, sau nửa năm làm hệ thống như này thì phát hiện ra là không có tiềm năng kinh doanh. Được cái mày mò cách login vào các ngân hàng cũng hay. Phát hiện ra là các hệ thống của ngân hàng hầu như đều nát như shit hết
Last edited:
Similar threads
