RPG29
Đã tốn tiền
Ô phen gì mà căng vậy, mình có căng đâu nhề. Sao lại yc mình bỏ đi vậy phen.
Anw, quay lại chủ đề thớt. Đã phen nào dùng consul chưa nhỉ?
Bên mình production cũng được 2 năm rồi
Ô phen gì mà căng vậy, mình có căng đâu nhề. Sao lại yc mình bỏ đi vậy phen.
Anw, quay lại chủ đề thớt. Đã phen nào dùng consul chưa nhỉ?
Bắt đầu nghiên cứu microservice thì coi sách hay nguồn nào mấy cái thím
Cái kiểu cười như khiêu khích người khác ấy, mình ko thích. Mà thôi, mình cũng không muốn làm loãng topic. Thím ko bỏ thì mình xin phép ignore.Ô phen gì mà căng vậy, mình có căng đâu nhề. Sao lại yc mình bỏ đi vậy phen.
Anw, quay lại chủ đề thớt. Đã phen nào dùng consul chưa nhỉ?
Giải pháp hiện tại bên bạn là như thế nào? Mình không rành bên microservices, nhưng thường Monitoring/Alerting dùng Prometheus/Alertmanager, Logging thì ELK Stack, còn Sentry cho Tracing. Tiền to, muốn giảm Ops thì Datadog, New Relic, nhỏ thì được chứ infras bự lên thì như đang đốt tiền.Có 1 khía cạnh cực kì quan trọng trong microservices hình như chưa bác nào đề cập là logging, tracing và monitoring. Hiện tại đang làm vs đủ thứ lẩu thập cẩm tool toy.
Đúng như bạn nói là tùy trường hợpBình thường các bác làm microservices thì database hay chia ra theo từng service con hay có sử dụng shared database tùy trường hợp ạ. Em mới đụng đến phần này lần đầu nên k có kinh nghiệm
Stack bên mình khá là tả pí lù do dùng multi data center ( GCP , on-prem)Giải pháp hiện tại bên bạn là như thế nào? Mình không rành bên microservices, nhưng thường Monitoring/Alerting dùng Prometheus/Alertmanager, Logging thì ELK Stack, còn Sentry cho Tracing. Tiền to, muốn giảm Ops thì Datadog, New Relic, nhỏ thì được chứ infras bự lên thì như đang đốt tiền.
Giải pháp hiện tại bên bạn là như thế nào? Mình không rành bên microservices, nhưng thường Monitoring/Alerting dùng Prometheus/Alertmanager, Logging thì ELK Stack, còn Sentry cho Tracing. Tiền to, muốn giảm Ops thì Datadog, New Relic, nhỏ thì được chứ infras bự lên thì như đang đốt tiền.
Việc giao tiếp từ service này qua service kia để get thì người ta sẽ ko dùng service bus mà sẽ giao tiếp qua API vì nó có độ trễ khá cao, mục đích của services bus là để đảm bảo eventually consistency giữa các micro services. Thường sẽ dùng cho những post và put query và thực hiện những long running transaction.Cho mình hỏi ngu, mà mình cũng hỏi chơi thôi chứ cũng ko đang làm về MicroService:
- Trước mình luôn nghĩ là các service giao tiếp bằng API Rest/SOAP, vậy mà mấy hôm nay đọc được khái niệm "Service Bus", vậy cái này là gì vậy.
- Load Balancer là cái gì vậy. Mình đọc thì hiểu là "router làm nhiệm vụ route các request đến các server khác nhau", mà k biết đúng k.
Mình cũng đang dùng consul, hiện tại vẫn đang hài lòng.Ô phen gì mà căng vậy, mình có căng đâu nhề. Sao lại yc mình bỏ đi vậy phen.
Anw, quay lại chủ đề thớt. Đã phen nào dùng consul chưa nhỉ?
Ở đây có bác nào kinh nghiệm deploy Serverless không? Bên em đang chuyển sang Quarkus và GraalVM để deploy Serverless đây. Ngoài GraalVM ra còn ông nào hỗ trợ AOT compiler cho Java mạnh không nhỉ các bác.
Sent from Xiaomi Mi MIX 2 using vozFApp
Stack bên mình khá là tả pí lù do dùng multi data center ( GCP , on-prem)
Logging: Stack driver, ELK
Monitoring/Alert: Stack driver, Prometheus, Grafana, Splunk, New relic
Tracing: Stack driver trace, Opentracing, Istio, Elastic Apm. Trước có dùng sentry mà giờ bỏ rồi.
Mấy cái mất tiền thì chả có gì để nói vì dùng nhiều thì charge nhiều, mấy cái tự cài mới mệt. Ví dụ 1 ngày ELK tầm 100tr records, muốn search tầm 3 tháng thì phải làm ntn Ngoài ra bài toán về tracing trên multi cluster
Vì cty to, mỗi project lại ngang vs 1 cty con, SA k có vai trò quyết định mà chỉ recommend nên mỗi bên chạy 1 kiểu. Như gateway vừa dùng Kong, vừa Gcp load balancer, bên trong thêm ingress k8s. Vậy nên latency hay network issue cực khó debug thậm chí nhiều lúc buông xuôiBên thím stack chạy tả pí lù nhiều thứ thế này maintenance mệt chết, bên em đang cố gắng gom lại vài thằng cho khỏe
SA bên thím ở mức nào mà lại chỉ recommend nhỉ, hay do đặc thù công ty nó thếVì cty to, mỗi project lại ngang vs 1 cty con, SA k có vai trò quyết định mà chỉ recommend nên mỗi bên chạy 1 kiểu. Như gateway vừa dùng Kong, vừa Gcp load balancer, bên trong thêm ingress k8s. Vậy nên latency hay network issue cực khó debug thậm chí nhiều lúc buông xuôi
Cái này mình k rõ, có thể mình thiếu thông tin hoặc vấn đề mang tính lịch sử, chỉ biết tóm lại giờ đang có một mở tả pí lù tool. Cái lợi là ae devops tha hồ nghịchSA bên thím ở mức nào mà lại chỉ recommend nhỉ, hay do đặc thù công ty nó thế
Vì cty to, mỗi project lại ngang vs 1 cty con, SA k có vai trò quyết định mà chỉ recommend nên mỗi bên chạy 1 kiểu. Như gateway vừa dùng Kong, vừa Gcp load balancer, bên trong thêm ingress k8s. Vậy nên latency hay network issue cực khó debug thậm chí nhiều lúc buông xuôi
Hiện bên cty mình thì chưa thấy issue gì, cơ mà stack nào cũng mất công vận hành chứ fen, nhiều hay ít thôi. Vd Kong nó cần redis và Cassandra( Postgres) làm datasource. Nếu bên fen dùng GCP thì còn đỡ chứ on-prem để auto scale đc vs Kong cũng là vấn đề.Con hàng Kong này ngon không thím? Thấy based-on Nginx, biết lâu rồi mà chưa rờ vô bao giờ, đang muốn thay dàn Nginx hiện tại bằng thằng khác cho đỡ công vận hành.