[amarifleur]

Quan trọng là cái business logic chứ không phải ở số lượng microservice. Nếu mà bussiness logic phức tạp chồng chéo thì nếu design không tốt là sau này thành một đống sphagetti luôn. Cái này tùy từng trường hợp ứng dụng, nếu bussiness logic có thể chia nhỏ hoạt động độc lập thì không phải lo rồi. Ơ mà cái này lúc bắt đầu dự án là phải phân tích rồi mà. Đâu có thuốc chung cho mọi loại bệnh nhỉ.

Mỗi quốc gia sản phẩm bên mình nghiệp vụ nó lại khác nhau, ngay cả ở VN, việc thay đổi là diễn ra hằng ngày, thiết kế ban đầu rất khó khăn, team lại khá ít người phải phục vụ kha khá nhân sự trong công ty, BA thường không có, việc design đúng với thời điểm này chưa chắc đã đúng với thời điểm khác. Ban đầu tụi mình xây thường xây rất nhanh và phải đập đi đập lại kha khá .
Ban đầu team có đưa ra các flow làm việc riêng, ví dụ đều yêu cầu viết test trước khi viết một function . Thử áp dụng một số quy trình nhưng đều fail vì đặc thù công ty, như trên, nghiệp vụ chính xác hơn là có thể thay đổi hàng giờ, và nó không chỉ một mà là rất nhiều, không như một team outsource khi mà sản phẩm có thể kéo dài đến 2-3 tháng

Monitor system có thể độc lập (chạy ngoài ứng dụng) hoặc built-in (chạy trong ứng dụng) ví dụ gởi Request đến TraLuongService mà bị Time-Out là tự động gởi Email báo CEO biết. =)).

Báo email, log tập trung đều có triển khai, nhưng có flow nào hiệu quả hơn không

[amarifleur]

Originally Posted by _sharp_

Không biết business ko tư vấn được.
Còn thế nào là hợp lý thì cứ bounded context, aggregate mà áp dụng thôi.


Không hiểu ý này lắm, ý là bạn Service A connect DB A, Service B connect DB B. Mà data A và B phải đồng bộ, service B call DB B mà có issue thì phải rollback data ở DB A ???



Test độc lập từng service:
- test business.
- test perfomance xem chịu tải được bao nhiêu.

Test các service ràng buộc nhau; ví dụ service A call B (test như trên).
Test all hệ thống (test như trên).

Lúc đó sẽ biết được khả năng, chịu tải và lên được các phương án dự phòng cho service bị die.

Ngoài ra có nhiều tool để monitor hệ thống.



Ngôn ngữ nào mà chả được tuỳ vào nhân sự trong team. Chứ team toàn ông Java, PHP chả thể nào ép Dev qua code .NET hay thay máu toàn bộ nhân viên tuyển .NET vào.

Còn apply các công nghệ mới để sau này proj có fail thì còn đống công nghệ đấy trong profile để đi tìm việc mới thì tuỳ.


Queue


Công ty nào thế ??? cho vài cái hình girl lên đây xem nào


// Kinh nghiệm bản thân architect project micro-services (không bác thớt lại bảo mình chém)

Thường ban đầu tech có thể sai lầm khi chia quá nhỏ một số service hoặc tách một số table ra từng service khác nhau, dẫn đến khi sản phẩm phát triển đến một mức nào đó, việc thay đổi sẽ tạm thời ảnh hưởng tới các đội khác. Ở đây bên mình ban đầu chọn mongodb .
VD: Một service payment của bên mình sử dụng sql, nhưng dữ liệu về order, customer lại sử dụng nosql từ trước. Với những payment sử dụng hình thức thanh toán là COD (chuyển hàng tận nhà), dữ liệu vận đơn được tách riêng ra , trạng thái thanh toán thường phụ thuộc vào bên đối tác vận đơn. Thường là được cập nhật tự động từ đối tác . Nên việc rất hay gặp là sai sót giá , hoặc cập nhật sai trạng thái đơn hàng , dữ liệu lại không thể để sai sót do nhu cầu phân tích hàng giờ và báo cáo hằng ngày.
Một số thị trường nước ngoài, sản phẩm của mình bị thay đổi nghiệp vụ khá nhanh, nên một số service được dùng không phải sản phẩm của team build , việc mất mát dữ liệu là rất dễ

[amarifleur]

Originally Posted by RPG29

Đặc thù của startup là nghiệp vụ thay đổi liên tục và thời gian thay đổi rất nhanh nên mình vẫn thích bắt đầu dự án với monolith hơn. Code có thể lộn xộn chồng chéo nhưng ít nhất nó vẫn dễ hơn là handle network failure, distribute transaction, polyglot consistency... Có thể hạn chế sự lộn xộn bằng refactor liên tục. Và khi nghiệp vụ đủ ổn định thì khi đó có thể thấy rõ boundary context để tách nhỏ ra.

Túm lại mình rất nể architect bên đó vì đủ dũng cảm để bắt đầu với microservices. Xưa mình cũng làm một dự án startup sử dụng microservices từ đầu nhưng thất bại, đến giờ vẫn bị ám ảnh

Mới dự án của team mình thì có thể nói là nếu không đi theo microservice sẽ bị ngập lụt từ trong trứng, chết ngay từ lúc mới bắt đầu. kể cũng hơi khác với nhiều nhóm khác
Một flow mà team mình đang theo khi đưa một service lên production. Run xong đống này thì tự đẩy lên dọcker chạy luôn .

[_sharp_]

Originally Posted by amarifleur

...

"Công ty nào thế ??? cho vài cái hình girl lên đây xem nào"
Cái quan trọng thì ko thấy trả lời

Thôi lượn qua f33 đây, dạo này ở f33 vui hơn bên này.

[4nh7i3m]

Ban đầu team có đưa ra các flow làm việc riêng, ví dụ đều yêu cầu viết test trước khi viết một function . Thử áp dụng một số quy trình nhưng đều fail vì đặc thù công ty, như trên, nghiệp vụ chính xác hơn là có thể thay đổi hàng giờ, và nó không chỉ một mà là rất nhiều

Tui thấy có gì sai sai ở đây. Theo ý của tui thôi nhe, nếu Business Logic rõ ràng thì TDD là tốt nhưng nếu kiểu thay đổi từng giờ như vậy TDD có vẻ hơi bị sai sai í.

Báo email, log tập trung đều có triển khai, nhưng có flow nào hiệu quả hơn không

Có. Tìm lỗ kiếm tiền. Thưởng tiền cho nhân viên nào phát hiện hệ thống bị sập đầu tiên và phạt tiền thằng nào làm nó sập. =)).

, trạng thái thanh toán thường phụ thuộc vào bên đối tác vận đơn. Thường là được cập nhật tự động từ đối tác . Nên việc rất hay gặp là sai sót giá , hoặc cập nhật sai trạng thái đơn hàng , dữ liệu lại không thể để sai sót do nhu cầu phân tích hàng giờ và báo cáo hằng ngày

Cái này đâu phải vấn đề kỹ thuật ông ơi. Đây là lỗi ở con người mà. Ví dụ "sai sót giá", "cập nhật sai trạng thái" là do nhân viên bên thứ 3 làm lỗi mà. Cái này làm sao bên kỹ thuật giải quyết được nhỉ. Hay tui lại hiểu sai.

Thôi lượn qua f33 đây, dạo này ở f33 vui hơn bên này.

Có thấy ông chém gió gì trong đó đâu? )

[RPG29]

Bên đấy đang dùng API Gateway nào nhỉ?

Với cả đang dùng IPC protocol nào thế? Làm Ruby thì chắc chủ yếu dùng REST?

[_sharp_]

"Báo email, log tập trung đều có triển khai, nhưng có flow nào hiệu quả hơn không"
Không thấy nhắc đến việc có người monitor hệ thống hàng ngày nhỉ, xem 1 ngày lượng request như nào, thời gian cao điểm thấp điểm của từng service, cpu/ram load, write/read sata/ssd, write/read db.

Originally Posted by 4nh7i3m

"Ban đầu team có đưa ra các flow làm việc riêng, ví dụ đều yêu cầu viết test trước khi viết một function . Thử áp dụng một số quy trình nhưng đều fail vì đặc thù công ty, như trên, nghiệp vụ chính xác hơn là có thể thay đổi hàng giờ, và nó không chỉ một mà là rất nhiều"

Tui thấy có gì sai sai ở đây. Theo ý của tui thôi nhe, nếu Business Logic rõ ràng thì TDD là tốt nhưng nếu kiểu thay đổi từng giờ như vậy TDD có vẻ hơi bị sai sai í.

Đây mới là lúc cần áp dụng DDD, tất cả out of scope business đều phải xác định thật rõ và như bác 4nh7i3m nói cái này áp dụng TDD là thừa rồi.

Originally Posted by 4nh7i3m

"trạng thái thanh toán thường phụ thuộc vào bên đối tác vận đơn. Thường là được cập nhật tự động từ đối tác . Nên việc rất hay gặp là sai sót giá , hoặc cập nhật sai trạng thái đơn hàng , dữ liệu lại không thể để sai sót do nhu cầu phân tích hàng giờ và báo cáo hằng ngày"

Cái này đâu phải vấn đề kỹ thuật ông ơi. Đây là lỗi ở con người mà. Ví dụ "sai sót giá", "cập nhật sai trạng thái" là do nhân viên bên thứ 3 làm lỗi mà. Cái này làm sao bên kỹ thuật giải quyết được nhỉ. Hay tui lại hiểu sai.

Cái này phải define được work-flow thật chuẩn, code business logic, validate data tất cả các case. Sau đó là phải xác định đươc user role, user nào được thưc hiện chức năng nào (create, edit info, edit status,...), log tất cả user behavior, event,...
Lúc đó sẽ giải quyết được vấn đề data sai, update nhầm,....

Originally Posted by 4nh7i3m

Có thấy ông chém gió gì trong đó đâu? )

Nằm vùng đọc comment thôi bác ơi, chém trong đấy dễ bị hội đồng hoặc KIA ra đảo lắm

[cuoc_song]

Mấy bác cho hỏi là nếu làm micro service thì phần security và permission sẽ làm thế nào ? Có những nghiệp vụ phụ thuộc vào loại data để đưa tới người có trách nhiệm tương ứng => chưa hiểu cơ chế phân quyền thì làm thế nào. Hay bỏ qua tất cả phân quyền trong service và xác định quyền theo frontend ?

[momotico]

Originally Posted by cuoc_song

Mấy bác cho hỏi là nếu làm micro service thì phần security và permission sẽ làm thế nào ? Có những nghiệp vụ phụ thuộc vào loại data để đưa tới người có trách nhiệm tương ứng => chưa hiểu cơ chế phân quyền thì làm thế nào. Hay bỏ qua tất cả phân quyền trong service và xác định quyền theo frontend ?

như mình hiện tại là lưu thông tin phân quyền trong JWT, sau đó check authorization thông qua middleware

[cuoc_song]

Originally Posted by momotico

như mình hiện tại là lưu thông tin phân quyền trong JWT, sau đó check authorization thông qua middleware

Ồ. Tức là bác lưu role tại client chăng? Vậy việc attacker tự động add thêm quyền vào local storage để khám phá các chức năng ẩn thì thế nào nhỉ?

Nhưng với những workflow phức tạp yêu cầu check quyền với data hiện thời thì bác sẽ xử lý thế nào? Ví dụ như việc chuyển hàng vào miền Nam sẽ khác với việc chuyển hàng qua miền Bắc và cần thông báo riêng 2 người khác nhau. Người này sẽ không nhận được thông báo của người kia.

Việc bác check authorization là xử lý tại từng service hay xử lý tập trung tại API Gateway ?