RioZ
Junior Member
Chào các bro. Team em đang gặp khó khăn trong việc re-design lại microservices. Project của anh bạn Sing, nhưng chôm khá nhiều core từ thiên triều (cũng dễ hiểu mà, giờ project éo nào chả thế 
). Ban đầu team em gia công cho 1 client ở Sing, nên build microservice theo cái core kia, chấp nhận bị duplicated bizness code ra nhiều services, miễn là delivery cho họ kịp hạn. Giờ có đối tác được client cũ giới thiệu sang, muốn build hệ thống na ná vậy, change bizness đi một chút. Thằng lead thì bỏ của chạy lấy người rồi, team lại toàn thợ code chả thằng nào rành về design structure. Nói sơ qua về project nhé.
- Mình không thể kể ra toàn bộ, mà nói khái quát những cái đang gặp khó khăn thôi nhé, lỡ bể chuyện thì bọn nó thịt mình
. Có 1 services authern chứa credential (gọi là A), thằng này làm nhiệm vụ xác thực rồi bắn response cho customer-handle service, gọi thằng này là B, nhận được authern rồi nó cung cấp metadata cho các services khác. Ban đầu thằng B lãnh đạn hứng request từ user và cả xử lý nặng nữa, nhưng team em đã tách được nhiệm vụ này sang thằng B2 để nó chuyên xử lý mấy cái nặng nhọc như paging, handle async. Ngoài ra, do đặc thù bizness cần counter nên build thêm 1 service nữa (dùng framework khác cho thuận lợi hơn) gọi là Counter service (C)
- Server chứa credential đã được tay lead custom re-structure khá ngon, giờ chỉ ngồi custom lại chút để hợp bizness mới mà thôi. Bộ counter chạy khá ngon và chính xác, còn thằng B hứng request từ user trước mắt không cần sửa gì rồi. 3 thằng này khỏi quan tâm. Nếu sửa chắc vẫn chỉ sửa linh tinh mỗi thằng B.
- Data xịn của user được chứa ở các Division services (là các D), hứng metadata truyền từ thằng B đến và so khớp với metadata của nó, để handle việc crud. Mỗi thằng D đều có postgresql lưu data và mongodb làm cache, cũng dùng mongodb đựng các config/metadata. Tính đến giờ đã build ra 3 services cho 3 loại metadata: json, xml, REST API => tương ứng với từng format mà data lưu xuống postgre sẽ mang đặc thù riêng
; mà code các thằng D lại giống giống nhau (thậm chí giống đến 70~80% luôn ạ). Do code base của D phục vụ chuyên cho handle crud nên em đã chỉnh cho nó làm nhiệm vụ export data, gọi đến cache, paging và counter theo kiểu fix cứng trong code.
- Ông client mới đang rất ưng cái export, họ chỉ muốn chỉnh sửa bizness đôi chút cho hợp với logic bên họ thôi. Vấn đề mới bây giờ là họ cần thêm tính năng import nữa, cũng có bizness đi theo 3 loại format đó luôn.
Team phải viết thêm D+ implement tính năng import, ban đầu viết trước cái format json đã, xem họ ưng không. Mà các bác biết rồi đấy, viết code import big data khá lằng nhằng, mới viết xong 1 cái mà chi phí đã cao, bên em đang đàm phán với họ về giá của cả 3. Code export của team hiện tại đã móc logic cache, paging lung tung với thằng B2 lộn xí ngầu cả lên, trong khi import thì đách cần cache làm gì. Nhưng khổ nỗi chức năng import của client lại.. giống hệt với 3 format của D, nếu giờ tách code ra service mới thì duplicate ác mộng. Nhỡ đâu sau này maintain, client muốn sửa 1 chút bizness thế là phải sửa tất cả các thằng D, chắc cả team bốc cư't quá. Báo giá để sửa 1 nhóm nhỏ bizness không được deal quá cao, nhưng chi phí để sửa tất cả các D và D+ là rất tốn công. 
Em biết kiến trúc microservices phải chấp nhận duplicated code, không như kiến trúc mono có thể module hóa để re-use thuận tiện. Vừa đòi hỏi micro vừa đèo bòng re-use code là quá tham lam. (Chỗ này em tự gạch vì có vẻ sai sai)
Khái quát vấn đề em gặp phải: code cũ cho 3 loại metadata bị dup ra làm 3 và vẫn na ná nhau, code này gọi đến service handle để thao tác các caching, paging khá lằng nhằng; code mới cũng tương tự code cũ nhưng không gọi đến thằng handle kia. Nên em cần refactor thằng D theo kiểu gộp code base của 3 thằng cũ vào chung 1 source, rồi từ đó triển khai code import mới ở D.
Team em có 1 lợi thế lớn, là bộ code cũ đã bán cho client cũ và bên họ chạy ngon rồi, không thêm bớt gì nữa.
Sau đây là hướng xử lý của em đưa ra. Nếu các bro có cao kiến gì hãy cứ gạch đá thoải mái nhé.
). Ban đầu team em gia công cho 1 client ở Sing, nên build microservice theo cái core kia, chấp nhận bị duplicated bizness code ra nhiều services, miễn là delivery cho họ kịp hạn. Giờ có đối tác được client cũ giới thiệu sang, muốn build hệ thống na ná vậy, change bizness đi một chút. Thằng lead thì bỏ của chạy lấy người rồi, team lại toàn thợ code chả thằng nào rành về design structure. Nói sơ qua về project nhé.- Mình không thể kể ra toàn bộ, mà nói khái quát những cái đang gặp khó khăn thôi nhé, lỡ bể chuyện thì bọn nó thịt mình
. Có 1 services authern chứa credential (gọi là A), thằng này làm nhiệm vụ xác thực rồi bắn response cho customer-handle service, gọi thằng này là B, nhận được authern rồi nó cung cấp metadata cho các services khác. Ban đầu thằng B lãnh đạn hứng request từ user và cả xử lý nặng nữa, nhưng team em đã tách được nhiệm vụ này sang thằng B2 để nó chuyên xử lý mấy cái nặng nhọc như paging, handle async. Ngoài ra, do đặc thù bizness cần counter nên build thêm 1 service nữa (dùng framework khác cho thuận lợi hơn) gọi là Counter service (C)- Server chứa credential đã được tay lead custom re-structure khá ngon, giờ chỉ ngồi custom lại chút để hợp bizness mới mà thôi. Bộ counter chạy khá ngon và chính xác, còn thằng B hứng request từ user trước mắt không cần sửa gì rồi. 3 thằng này khỏi quan tâm. Nếu sửa chắc vẫn chỉ sửa linh tinh mỗi thằng B.
- Data xịn của user được chứa ở các Division services (là các D), hứng metadata truyền từ thằng B đến và so khớp với metadata của nó, để handle việc crud. Mỗi thằng D đều có postgresql lưu data và mongodb làm cache, cũng dùng mongodb đựng các config/metadata. Tính đến giờ đã build ra 3 services cho 3 loại metadata: json, xml, REST API => tương ứng với từng format mà data lưu xuống postgre sẽ mang đặc thù riêng
; mà code các thằng D lại giống giống nhau (thậm chí giống đến 70~80% luôn ạ). Do code base của D phục vụ chuyên cho handle crud nên em đã chỉnh cho nó làm nhiệm vụ export data, gọi đến cache, paging và counter theo kiểu fix cứng trong code.- Ông client mới đang rất ưng cái export, họ chỉ muốn chỉnh sửa bizness đôi chút cho hợp với logic bên họ thôi. Vấn đề mới bây giờ là họ cần thêm tính năng import nữa, cũng có bizness đi theo 3 loại format đó luôn.
Team phải viết thêm D+ implement tính năng import, ban đầu viết trước cái format json đã, xem họ ưng không. Mà các bác biết rồi đấy, viết code import big data khá lằng nhằng, mới viết xong 1 cái mà chi phí đã cao, bên em đang đàm phán với họ về giá của cả 3. Code export của team hiện tại đã móc logic cache, paging lung tung với thằng B2 lộn xí ngầu cả lên, trong khi import thì đách cần cache làm gì. Nhưng khổ nỗi chức năng import của client lại.. giống hệt với 3 format của D, nếu giờ tách code ra service mới thì duplicate ác mộng. Nhỡ đâu sau này maintain, client muốn sửa 1 chút bizness thế là phải sửa tất cả các thằng D, chắc cả team bốc cư't quá. Báo giá để sửa 1 nhóm nhỏ bizness không được deal quá cao, nhưng chi phí để sửa tất cả các D và D+ là rất tốn công. Em biết kiến trúc microservices phải chấp nhận duplicated code, không như kiến trúc mono có thể module hóa để re-use thuận tiện. Vừa đòi hỏi micro vừa đèo bòng re-use code là quá tham lam. (Chỗ này em tự gạch vì có vẻ sai sai)
Khái quát vấn đề em gặp phải: code cũ cho 3 loại metadata bị dup ra làm 3 và vẫn na ná nhau, code này gọi đến service handle để thao tác các caching, paging khá lằng nhằng; code mới cũng tương tự code cũ nhưng không gọi đến thằng handle kia. Nên em cần refactor thằng D theo kiểu gộp code base của 3 thằng cũ vào chung 1 source, rồi từ đó triển khai code import mới ở D.
Team em có 1 lợi thế lớn, là bộ code cũ đã bán cho client cũ và bên họ chạy ngon rồi, không thêm bớt gì nữa.
Sau đây là hướng xử lý của em đưa ra. Nếu các bro có cao kiến gì hãy cứ gạch đá thoải mái nhé.
- Team em sẽ tạm "đập đi xây lại" bộ D, gọi vậy cũng hơi quá, chỉ là tinh chỉnh code của các D services sao cho nó chung 1 code base, build ra cả 3 dạng như ý muốn. Config nằm trong mongo các kiểu rồi, giờ bỏ công fix lại nhưng về lâu dài sẽ có lợi.
- Gộp thằng import D+ vào trong D services. Sẵn có mongo, tách phần code ra sao cho code chạy export theo flow riêng, import riêng. 2 flow này vẫn có thể re-use các bizness function vì bây giờ chúng đã nằm ở cùng nơi rồi.
- Trường hợp xấu nhất là bỏ luôn thằng B2 và sẽ paging, caching các kiểu ở trong D. Nhưng như vậy sẽ gây bottle-neck ở D.
Last edited:
. Nếu không dọn dẹp thì như rác còn trong nhà, ngày nào cũng thấy.
Còn lại cứ theo thứ tự 1-2-3 vậy.
Xong phần lớn thì em sẽ thử test theo cách import/export big data cùng lúc xem nó chịu nổi không.
