Tìm kiếm
40 kết quả cho “Service tier”. Tìm không phân biệt dấu.
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Implementation of a monitoring strategy for products based on microservices Bài tóm tắt · Salesforce · 2019
…ntation-of-a-monitoring-strategy-for-products-based-on-microservices-24ad24c4c3e5) Bối cảnh - Một sản phẩm Salesforce sắp GA, ghép từ nhiều microservice do nhiều team sở hữu. Câu h…
- How Intelligent Load Shedding Prevents Cascading Failures in Tier-0 Systems Bài tóm tắt · Salesforce · 2026
…iều region. - Xác thực nằm ở "cửa trước": identity chậm thì service phụ thuộc chờ, request xếp hàng, upstream retry, retry lại thêm tải. Quá tải cục bộ thành lỗi dây chuyền . - Wor…
- グローバル展開を支える基盤の裏側 (Behind the Infrastructure Powering Global Expansion) Bài tóm tắt · Mercari · 2025
…viết. Bối cảnh chiến lược ở . Bối cảnh - Hệ sinh thái microservices của Mercari đã trưởng thành: template service, SDK Go, module Terraform "starter kit", SDK trừu tượng hoá cấu h…
- GitHub's Engineering Fundamentals program Bài tóm tắt · GitHub · 2024
…bility, Security, Availability. Thay đổi chính - Thuộc tính service nằm trong repo: mỗi service có một file YAML giữ tầng (tier 0–3 theo mức quan trọng), QoS (critical, best effort…
- A Brief History of Scaling LinkedIn Bài tóm tắt · LinkedIn · 2015
…let cho mọi trang, business logic, kết nối vài database). - Service đầu tiên là member graph ("Cloud"): đồ thị kết nối cần duyệt trong bộ nhớ, có profile tải khác hẳn Leo nên tách…
- How we deploy to production over 100 times a day Bài tóm tắt · Monzo · 2022
…i deploy gần như không đổi. Hơn 100 deploy/ngày , hơn 2.000 service . Thay đổi chính - Quy trình thay đổi ít điểm chạm người: tối thiểu một review từ engineer của team sở hữu là đư…
- From One Horizontal Scaling Controller to Many: Evolving Uber's Compute Platform Bài tóm tắt · Uber · 2026
…mpute ở data center và cloud (Oracle, Google), khoảng 4.000 service trên 3 triệu core, 1,5 triệu lần khởi động pod mỗi ngày. Up là lớp federation: service owner deploy, khai báo mi…
- Argo Rollouts at scale: Bringing Automated Rollbacks to 2,100+ services at Monzo Bài tóm tắt · Monzo · 2022
…scale) Bối cảnh - Monzo (ngân hàng số ở Anh) theo đuổi microservices: hơn 2.100 service, hơn 100 lượt deploy/ngày, hơn 27.000 lượt deploy trong năm 2021 . - Deploy bằng một lệnh CL…
- Unlocking Horizontal Scalability in Our Web Serving Tier Bài tóm tắt · Airbnb · 2016
…nolith Rails chạy trên nhiều web server, nói chuyện với vài service Java; dữ liệu lõi trong MySQL trên RDS, đã tách database theo chức năng năm 2015. - MySQL community dùng mô hình…
- Incident Report: July 2, 2026 — US East Services Outage Bài tóm tắt · Railway · 2026
…ps://blog.railway.com/p/incident-report-july-2-2026-us-east-services-outage) Bối cảnh - Railway tự vận hành datacenter ("Metal"); mỗi site nối với ít nhất ba nhà mạng Tier 1 để mất…
- Search Federation Architecture at LinkedIn Bài tóm tắt · LinkedIn · 2018
…heo hai kiểu, nên thêm một tính năng là sửa và deploy nhiều service; - thiết kế dựa trên kế thừa làm các vertical dính nhau, đầy if-else; - test coverage thấp, không service nào de…
- Adopting Arm at Scale: Transitioning to a Multi-Architecture Environment Bài tóm tắt · Uber · 2025
…ment/) Phần 2/2. Phần 1: . Bối cảnh - Sau khi chạy được vài service trên Arm, cần mở rộng cho 5.000+ service . Phân bổ CPU theo monorepo: 60% Go, 20% Java, 10% Web , phần còn lại r…
- Uber's Rate Limiting System Bài tóm tắt · Uber · 2026
…s/en/blog/ubers-rate-limiting-system/) Bối cảnh - Kiến trúc service của Uber xử lý hàng trăm triệu RPC mỗi giây qua hàng nghìn service. Thời đầu mỗi team tự throttle (trong logic n…
- How Netflix Scales its API with GraphQL Federation (Part 1) Bài tóm tắt · Netflix · 2020
…trăm ứng dụng; dữ liệu và quan hệ nằm rải trong vô số microservice. - Hai cách các đội tự xoay xở: lớp gộp dùng một lần (BFF hoặc mid-tier) lặp lại code lấy dữ liệu; và materializ…
- Running a Software Factory Efficiently at Uber Scale Bài tóm tắt · Uber · 2026
…ph : 24 triệu node, 80 triệu cạnh, gom từ hơn 30 hệ nội bộ (service, team, sự cố, PR, design doc, deploy, dataset, lịch sử query), agent hỏi bằng ngôn ngữ tự nhiên. - Hiển thị thay…
- How Uber Conquered Database Overload: From Static Rate-Limiting to Intelligent Load Management Bài tóm tắt · Uber · 2026
…) tới t5; không có ưu tiên tường minh thì gán mặc định theo service gọi; shed từ thấp lên. Bỏ hàng đợi "chậm", còn đọc và ghi, việc dài chỉ đánh ưu tiên thấp. Timeout hàng đợi tự c…
- A deeper dive into our May 2019 security incident Bài tóm tắt · Stack Overflow · 2021
…eloper. - Trong site settings của dev có credential của một service account TeamCity: chức năng dùng nó đã bỏ từ lâu nhưng credential vẫn còn hiệu lực. TeamCity mở ra Internet, và…
- Running Kafka At Scale Bài tóm tắt · LinkedIn · 2015
…Kafka Audit kiểm độ đầy đủ: header message mang timestamp, service và host gốc. Producer đếm số message gửi mỗi khoảng thời gian và gửi con số vào một topic audit; mỗi cụm có cons…
- Running Cost-Efficient Export Workloads at Uber Bài tóm tắt · Uber · 2026
…au khi đã sắp xếp, thống kê cột đủ và nhẹ hơn. - Hudi Table Service lo backfill sắp xếp, dựng index, sắp xếp tăng dần. Hướng tiếp: Z-order cho bảng có nhiều cột predicate khác nhau…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Mô hình tổ chức SRE Chủ đề
Lúc nhỏ, một team ops hay SRE tập trung trực và vận hành mọi thứ. Khi chuyển sang microservice và "you build it, you run it", team sản phẩm phải tự sở hữu service trên production, nhưng nhiều team chưa có kỹ năng, còn…
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- Uber Công ty Thành viên
Một vòng đủ: monolith → microservices → tổ chức lại microservices. Năm 2012–2013 Uber có hai monolith; khi lên hàng trăm kỹ sư thì tách. Lý do chủ yếu là tổ chức. Năm 2015 họ có 500+ service và phải chuẩn hoá contract…
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…