[amarifleur]

Chào mọi người, hẳn mọi người đều đã từng biết hoặc có nghe qua về microservice. Hiểu đơn giản thì là kiểu kiến trúc chia nhỏ các thành phần của hệ thống ra từng service nhỏ hơn, chi tiết hơn thì có thể tìm đọc các bài viết hiện tại về microservice rất là nhiều . (VD: microservices.io)

Bên team mình cũng có triển khai ngay từ lúc đầu làm sản phẩm , đến giờ hơn một năm nhưng cũng chưa có thể dám khẳng định là làm được hoàn toàn.

Team mình sử dụng hầu như các dịch vụ của AWS để build hệ thống, kể cả việc sử dụng mongodb bây giờ cũng rục rịch chuyển qua dynamodb. Vì tiền không thành vấn đề nên để đáp ứng được nhu cầu phát triển của startup nên phụ thuộc hoàn toàn vào AWS Hiện tại đi theo microservice thì gặp phải những vấn đề thường gặp sau .
+ Hiện tại có khoảng 80 service, nhưng cảm giác vẫn chưa chia nhỏ đủ. Theo anh em chia như thế nào sẽ là vừa đủ, hợp lý.
+ Các bài toàn liên quan đến nghiệp vụ sản phẩm, thanh toán. Cứ liên quan đến tiền là dữ liệu rất quan trọng. Anh em sẽ giải quyết vấn đề sharing data. transaction data như thế nào, khi mà dữ liệu phân tán ở nhiều service, không bị ràng buộc .
+ Việc timeout giữa các service, việc một service bị die vẫn đảm bảo cho hệ thống hoạt động bình thường, ví dụ đảm bảo cho khách vẫn có thể mua hàng trong khi mình bảo trì hệ thống thanh toán
+ Quản lý số service như thế nào khi số lượng ngày càng tăng, với nhân sự dưới 30 người và hằng trăm micro service. Với việc sản phẩm bên mình phát triển ra nhiều quốc gia, nhiều đội ngũ làm việc ở các quốc gia khác nhau, đảm bảo để team có thể hoạt động suôn sẻ và phối hợp ăn ý ?
+ Khi một service bị die, làm thế nào để phát hiện được lỗi nhanh nhất
+ Ngôn ngữ nào thì phù hợp khi triển khai microservice ? Hiện tại bên mình đang sử dụng Ruby on Rails, Java, Python, Nodejs cho việc phát triển, React cho frontend , xu hướng săp tới là sử dụng erlang , go
+ Việc test giữa nhiều service, xây dựng luồng test như thế nào là hợp lý

....
Và còn rất nhiều vấn đề nữa, kinh nghiệm của mình thì hạn hẹp rất hy vọng anh em nào có kinh nghiệm hoặc có hứng thú tham gia thảo luận và chia sẻ kinh nghiệm hoặc những vấn đề trong quá trình đi theo kiến trúc này .


---------------------------------
Nhân tiện team mình đang tuyển lập trình viên , có tuyển fulltime, partime, chỉ cần tư duy tốt. Ngôn ngữ nào cũng được không thành vấn đề. Môi trường rất tốt, giờ giấc thoải mải, tự do sáng tạo đúng nghĩa, nhiều gái xinh (Không quảng cáo láo đâu vào là biết) . Anh em có thể làm backend, frontend hoặc nhảy sang nghiên cứu về data nếu đủ khả năng. Kể cả làm thiết kế (Bên mình đội thiết kế hơn 10 người).
Sản phẩm đang mở rộng ra nhiều quốc gia , nên cơ hội làm việc ở nước ngoài môi tháng là rất nhiều, team cũng không quá nhiều người nên anh em sẽ không lo bị thua thiệt Team toàn anh em rất là trẻ nên rất là thoải mải
Anh em nhu cầu inbox nhé, không giới hạn độ tuổi, giới tính, học vấn

[RPG29]

Nghe mô tả thì hình như biết là cty nào rồi

Bên mình cũng chỉ dừng lại ở mức research và thử nghiệm nội bộ thôi chứ cũng chưa dám áp dụng cho production do microservices có quá nhiều vấn đề.

+ Hiện tại có khoảng 80 service, nhưng cảm giác vẫn chưa chia nhỏ đủ. Theo anh em chia như thế nào sẽ là vừa đủ, hợp lý.

>>> Mình nghĩ cái này nó do nghiệp vụ quyết định chứ to hay nhỏ ko quan trọng. Xác định boundary context phải do yêu cầu nghiệp vụ chứ dựa trên "cảm giác" thì vãi quá

+ Các bài toàn liên quan đến nghiệp vụ sản phẩm, thanh toán. Cứ liên quan đến tiền là dữ liệu rất quan trọng. Anh em sẽ giải quyết vấn đề sharing data. transaction data như thế nào, khi mà dữ liệu phân tán ở nhiều service, không bị ràng buộc .

>>> Vụ này theo mình thì cứ cái nào cần strict consistency thì tốt nhất cứ để chung với nhau thay vì tách ra. Để cho DB handle transaction là tốt nhất.
Eventually consistency thì có thể áp dụng 2-phases commit, event sourcing. Thấy gần đây nhờ phong trào microservices thì event sourcing nổi lên nhiều (mặc dù nó dc dùng hơn 30 năm nay rồi).

+ Việc timeout giữa các service, việc một service bị die vẫn đảm bảo cho hệ thống hoạt động bình thường, ví dụ đảm bảo cho khách vẫn có thể mua hàng trong khi mình bảo trì hệ thống thanh toán

>>> Chết bất thình lình khác với bảo trì chứ nhỉ? Thường với bảo trì bên mình sẽ dựng 1 instance mới làm trên đó ok rồi mới route request về instance mới bỏ instance cũ chứ k shutdown instance cũ ngay để đảm bảo uptime. Còn việc chọn hàng và thanh toán mình thấy nó khác nhau mà nhỉ. Khách vẫn có thể bỏ hàng vào giỏ, chỉ có bước checkout cuối do payment service nó chết rồi nên stuck ở đó chứ các bước trước vẫn bình thường?

+ Quản lý số service như thế nào khi số lượng ngày càng tăng, với nhân sự dưới 30 người và hằng trăm micro service. Với việc sản phẩm bên mình phát triển ra nhiều quốc gia, nhiều đội ngũ làm việc ở các quốc gia khác nhau, đảm bảo để team có thể hoạt động suôn sẻ và phối hợp ăn ý ?

>>> Vụ này thì mình chịu, chưa scale đến mức đó nên k biết

+ Khi một service bị die, làm thế nào để phát hiện được lỗi nhanh nhất

>>> Server nào cũng phải cài agent để giám sát chứ nhỉ? Agent nó có thể chủ động ping hoặc watch process nếu chết thì nó sẽ bắn alert về monitoring system?

+ Ngôn ngữ nào thì phù hợp khi triển khai microservice ? Hiện tại bên mình đang sử dụng Ruby on Rails, Java, Python, Nodejs cho việc phát triển, React cho frontend , xu hướng săp tới là sử dụng erlang , go

>>> Giờ xu hướng bọn nó containerize hết rồi nên thực ra cái nào cũng same same nhau nhưng mà mình prefer JVM, Go... hơn do mấy cái IPC protocol nó support có vẻ tốt hơn như Apache Thrift, gRPC (Protocol Buffers), performance cũng tốt và nhất là self-containing đóng thành một cục dễ deliever hơn

+ Việc test giữa nhiều service, xây dựng luồng test như thế nào là hợp lý

>>> Cái này nó phụ thuộc vào việc tách services ntn, dependency ra sao. Mình cho rằng tốt nhất nên phụ thuộc trực tiếp A -> B sẽ dễ hơn, còn transition dependency A -> B -> C nó cực kỳ khó test và quản lý. Còn tối ưu nhất vẫn là độc lập nhau hết (cái này thì có lẽ khó)

[momotico]

bác RPG nói hết rồi, chả biết nói thêm gì nữa =)

bác amarifleur là bên cty nào nhỉ? tuyển làm ngôn ngữ gì vậy?

[vinhomn]

Công ty cũ có dùng microservice, cũng có tech talk rồi tranning cơ mà chưa được động vào nên ko dám chém nhiều, với cả bác RPG cũng nói hết rồi

Việc timeout giữa các service, việc một service bị die vẫn đảm bảo cho hệ thống hoạt động bình thường, ví dụ đảm bảo cho khách vẫn có thể mua hàng trong khi mình bảo trì hệ thống thanh toán

Bình thướng thì có service load balancer, service discovery rồi thì cứ ngắt từng instance ra để bảo trì thôi, em hiểu là vậy.
Còn nếu nó chết trong lúc hoạt động thì các cụ bảo là thiết kế fail-fast system, dùng circuit breaker pattern để đảm bảo instance hay service nào đang hấp hối thì tự ngắt ra, tránh ảnh hưởng đến data và các thằng service khác. Còn nếu mà chúng nó lăn ra chết hết thì chịu.

[amarifleur]

Vì đặc thù công ty nên nghiệp vụ rất dễ thay đổi, thường thay đổi trong ngày, chưa thể đưa ra được một chuẩn chung nên thường theo "cảm giác", giữa vào thiết kế ban đầu để xác định nên chia service như thế nào . Lâu lâu sẽ gặp một số vấn đề phát sinh do "cảm giác" ban đầu nó chưa được tổng quát

[amarifleur]

Originally Posted by momotico

bác RPG nói hết rồi, chả biết nói thêm gì nữa =)

bác amarifleur là bên cty nào nhỉ? tuyển làm ngôn ngữ gì vậy?

Hiện tại đang chủ yếu code ruby, nhưng sắp tới sẽ đẩy mạnh sử dụng erlang, go cho một số project . Ngoài ra một số ae dùng Python, Java, nói chung là tùy ý thích

[RPG29]

Originally Posted by amarifleur

Vì đặc thù công ty nên nghiệp vụ rất dễ thay đổi, thường thay đổi trong ngày, chưa thể đưa ra được một chuẩn chung nên thường theo "cảm giác", giữa vào thiết kế ban đầu để xác định nên chia service như thế nào . Lâu lâu sẽ gặp một số vấn đề phát sinh do "cảm giác" ban đầu nó chưa được tổng quát

Đặ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

[nice.boobs]

bác ở sì gòn hay hà lội thế

[4nh7i3m]

Không có kinh nghiệm nhưng vì thớt cho chém gió nên cứ chém nhiệt tình thôi. .

Hiện tại có khoảng 80 service, nhưng cảm giác vẫn chưa chia nhỏ đủ. Theo anh em chia như thế nào sẽ là vừa đủ, hợp lý.

Theo "cảm giác" thì nếu là mình là mình chia theo resource. Mỗi resource là nằm ở một service. Ví dụ Order, Customer, Payment, Product, Transaction,... nhưng mà chia càng nhỏ thì dữ liệu redundant càng nhiều mà hệ thống phải scale tốt thì mới giữ vững được performance. Như Customer có thông tin địa chỉ và creditcard, nếu mà băm ra thì customerservice, addressservice và cvvservice.

Các bài toàn liên quan đến nghiệp vụ sản phẩm, thanh toán. Cứ liên quan đến tiền là dữ liệu rất quan trọng. Anh em sẽ giải quyết vấn đề sharing data. transaction data như thế nào, khi mà dữ liệu phân tán ở nhiều service, không bị ràng buộc .

Hệ thống phân tán thì theo tiêu chí https://en.wikipedia.org/wiki/CAP_theorem thì căng rồi. Cái này tự biết kém nên không chém, nhưng phân tán đâu có nghĩa là không ràng buộc nhỉ. Các mối liên hệ vẫn được lưu trữ redundant ở mỗi service mà ta?

Việc timeout giữa các service, việc một service bị die vẫn đảm bảo cho hệ thống hoạt động bình thường, ví dụ đảm bảo cho khách vẫn có thể mua hàng trong khi mình bảo trì hệ thống thanh toán

Đây là tính năng của micro-service mà để đảm bảo các hệ thống hoạt động độc lập với nhau. OrderService nằm riêng với PaymentService thì thằng PaymentService lỡ chết thì OrderService vẫn chạy bình thường mà. Hay í là catch Exception TimeOut nhỉ?

Quản lý số service như thế nào khi số lượng ngày càng tăng, với nhân sự dưới 30 người và hằng trăm micro service. Với việc sản phẩm bên mình phát triển ra nhiều quốc gia, nhiều đội ngũ làm việc ở các quốc gia khác nhau, đảm bảo để team có thể hoạt động suôn sẻ và phối hợp ăn ý ?

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ỉ.

Khi một service bị die, làm thế nào để phát hiện được lỗi nhanh nhất

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. =)).

Ngôn ngữ nào thì phù hợp khi triển khai microservice ? Hiện tại bên mình đang sử dụng Ruby on Rails, Java, Python, Nodejs cho việc phát triển, React cho frontend , xu hướng săp tới là sử dụng erlang , go

Giỏi quá. Em biết mỗi tiếng Việt. .

+ Việc test giữa nhiều service, xây dựng luồng test như thế nào là hợp lý

Ủa cái này là bên integration test rồi. Thì kết hợp với QA và BA (Business Analyst) để tạo test case chạy tự động thôi chứ nhỉ? Hay là sao nhỉ?

[_sharp_]

Originally Posted by amarifleur

+ Hiện tại có khoảng 80 service, nhưng cảm giác vẫn chưa chia nhỏ đủ. Theo anh em chia như thế nào sẽ là vừa đủ, hợp lý.

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.

Originally Posted by amarifleur

+ Các bài toàn liên quan đến nghiệp vụ sản phẩm, thanh toán. Cứ liên quan đến tiền là dữ liệu rất quan trọng. Anh em sẽ giải quyết vấn đề sharing data. transaction data như thế nào, khi mà dữ liệu phân tán ở nhiều service, không bị ràng buộc .

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 ???

Originally Posted by amarifleur

+ Việc timeout giữa các service, việc một service bị die vẫn đảm bảo cho hệ thống hoạt động bình thường, ví dụ đảm bảo cho khách vẫn có thể mua hàng trong khi mình bảo trì hệ thống thanh toán
+ Khi một service bị die, làm thế nào để phát hiện được lỗi nhanh nhất
+ Việc test giữa nhiều service, xây dựng luồng test như thế nào là hợp lý

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.

Originally Posted by amarifleur

+ Ngôn ngữ nào thì phù hợp khi triển khai microservice ? Hiện tại bên mình đang sử dụng Ruby on Rails, Java, Python, Nodejs cho việc phát triển, React cho frontend , xu hướng săp tới là sử dụng erlang , go

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ỳ.

Originally Posted by amarifleur

Việc timeout giữa các service, việc một service bị die vẫn đảm bảo cho hệ thống hoạt động bình thường, ví dụ đảm bảo cho khách vẫn có thể mua hàng trong khi mình bảo trì hệ thống thanh toán

Queue

Originally Posted by amarifleur

nhiều gái xinh (Không quảng cáo láo đâu vào là biết)

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)