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
thảo luận Microservices and Cloud Native Group
- Thread starter RPG29
- Start date
Bên mình production cũng được 2 năm rồi
RPG29
Đã tốn tiền
Microservices thì có rất nhiều nguồn tài liệu. Tiêu biểu thì có của mấy tay to như Chris Richardson, Sam Newman.
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ỉ?
Darkness.apache
Senior Member
Bì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
nikola_testla
Senior Member
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.
Đúng như bạn nói là tùy trường hợp
Như mình thường dùng là database-per-services
noneedname
Senior Member
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
gâu_
Đã tốn tiền
Hoặc có một cách gọn lẹ hơn là chơi nguyên stack Elastic luôn, Elastic APM + EK, có cả logging này nọ luôn. Thích nhất là nó có operator cho k8s nên nhẹ được phần quản lý cho nó.
freedom.9
Senior Member
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.
Microservices ko phải là kiến trúc khó về architect mà là nó khó về việc phân chia và tách ra những business domain nào để triển khai, xác định bounded context cho từng services.
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ỉ?
TIEU PH0NG
Member
Ở đâ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
Sent from Xiaomi Mi MIX 2 using vozFApp
RPG29
Đã tốn tiền
Hiện tại chỉ có GraalVM thôi mà cũng chưa tối ưu. GraalVM AOT chạy cloud native container cluster, serverless thì phù hợp do startup nhanh, memory footprint thấp, resource usage thấp nhưng performance vẫn chưa ăn đc Hotspot JIT.
Đang dùng Spring quen chuyển sang Quarkus thấy thọt đầu thọt đuôi hơi chán, chờ Spring nó hỗ trợ đầy đủ GraalVM rồi quất luôn một thể, mới ra cái Spring Graal Native 0.6 xài qua thấy cũng ổn ổn.
RPG29
Đã tốn tiền
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
Bê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
noneedname
Senior Member
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
CloneCanhac
Junior Member
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
noneedname
Senior Member
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ịch
VietNamVoDichAFF
Senior Member
Ôi nghe toàn keyword lạ lần đầu nghe 
RPG29
Đã tốn tiền
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
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.
noneedname
Senior Member
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 đề.
Bên Infra đang tính dùng Kong serverless plugin, deploy golang code lên VM chạy Kong instance, dạng như aws lamda hoặc Gcp cloud function.
Similar threads
