Josh Evans nói về thế giới hỗn loạn và đầy màu sắc của vi dịch vụ Netflix, bắt đầu từ những điều cơ bản nhất - cấu trúc của vi dịch vụ, những thách thức liên quan đến hệ thống phân tán và lợi ích của chúng. Dựa trên nền tảng này, anh khám phá các phương pháp thực hành văn hóa, kiến trúc và vận hành dẫn đến khả năng làm chủ vi dịch vụ.
Không giống như sự trôi dạt trong hoạt động, việc giới thiệu các ngôn ngữ mới để quốc tế hóa dịch vụ và các công nghệ mới như container là những quyết định có ý thức nhằm tăng thêm độ phức tạp mới cho môi trường. Nhóm vận hành của tôi đã chuẩn hóa lộ trình công nghệ tốt nhất cho Netflix, được đưa vào các phương pháp thực hành tốt nhất được xác định trước dựa trên Java và EC2, nhưng khi hoạt động kinh doanh phát triển, các nhà phát triển bắt đầu bổ sung các thành phần mới như Python, Ruby, Node-JS và Docker.
Tôi rất tự hào vì chúng tôi là người đầu tiên ủng hộ việc sản phẩm của mình hoạt động tốt mà không cần chờ đợi khiếu nại của khách hàng. Mọi chuyện bắt đầu khá đơn giản - chúng tôi có các chương trình điều hành bằng Python và một số ứng dụng hỗ trợ văn phòng bằng Ruby, nhưng mọi thứ trở nên thú vị hơn nhiều khi các nhà phát triển web của chúng tôi thông báo rằng họ sẽ loại bỏ JVM và sẽ chuyển web ứng dụng lên nền tảng phần mềm Node.js. Sau khi Docker ra đời, mọi thứ trở nên phức tạp hơn nhiều. Chúng tôi tuân theo logic và những công nghệ mà chúng tôi nghĩ ra đã trở thành hiện thực khi chúng tôi triển khai chúng cho khách hàng vì chúng rất có ý nghĩa. Tôi sẽ cho bạn biết tại sao lại như vậy.
API Gateway thực sự có khả năng tích hợp các tập lệnh tuyệt vời có thể đóng vai trò là điểm cuối cho các nhà phát triển giao diện người dùng. Họ đã chuyển đổi từng tập lệnh này theo cách mà sau khi thực hiện các thay đổi, họ có thể triển khai chúng vào sản xuất và sau đó đến thiết bị người dùng, đồng thời tất cả những thay đổi này đều được đồng bộ hóa với các điểm cuối chạy trong cổng API.
Tuy nhiên, điều này lặp lại vấn đề tạo ra một khối nguyên khối mới trong đó dịch vụ API bị quá tải mã theo cách xảy ra nhiều tình huống lỗi khác nhau. Ví dụ: một số điểm cuối đã bị xóa hoặc các tập lệnh được tạo ngẫu nhiên nhiều phiên bản của một thứ gì đó đến mức các phiên bản đó chiếm hết bộ nhớ khả dụng của dịch vụ API.
Việc lấy các điểm cuối này và kéo chúng ra khỏi dịch vụ API là điều hợp lý. Để làm điều này, chúng tôi đã tạo các thành phần Node.js chạy dưới dạng ứng dụng nhỏ trong vùng chứa Docker. Điều này cho phép chúng tôi tách biệt mọi sự cố và sự cố do các ứng dụng nút này gây ra.
Chi phí của những thay đổi này khá lớn và bao gồm các yếu tố sau:
- Công cụ năng suất. Quản lý công nghệ mới yêu cầu các công cụ mới vì nhóm UI sử dụng các tập lệnh rất tốt để tạo mô hình hiệu quả nên không phải mất nhiều thời gian quản lý cơ sở hạ tầng, họ chỉ phải viết tập lệnh và kiểm tra chức năng của chúng.
Phân loại và hiểu biết sâu sắc về cơ hội - Một ví dụ điển hình là các công cụ mới cần thiết để khám phá thông tin về trình điều khiển hiệu suất. Cần phải biết bộ xử lý đã chiếm bao nhiêu dung lượng, bộ nhớ đang được sử dụng như thế nào và việc thu thập thông tin này đòi hỏi các công cụ khác nhau. - Phân mảnh hình ảnh cơ sở - AMI cơ sở đơn giản đã trở nên phân mảnh và chuyên biệt hơn.
- Quản lý nút. Không có kiến trúc hoặc công nghệ sẵn có nào cho phép bạn quản lý các nút trên đám mây, vì vậy chúng tôi đã xây dựng Titus, một nền tảng quản lý bộ chứa cung cấp khả năng triển khai bộ chứa đáng tin cậy và có thể mở rộng cũng như tích hợp đám mây với Amazon AWS.
- Sao chép thư viện hoặc nền tảng. Việc cung cấp các công nghệ mới có cùng chức năng cốt lõi của nền tảng đòi hỏi phải sao chép nó vào các công cụ dành cho nhà phát triển Node.js dựa trên đám mây.
- Đường cong học tập và kinh nghiệm công nghiệp. Sự ra đời của các công nghệ mới chắc chắn sẽ tạo ra những thách thức mới cần phải vượt qua và rút ra bài học.
Vì vậy, chúng tôi không thể giới hạn mình trong một “con đường trải nhựa” và phải liên tục xây dựng những cách thức mới để cải tiến công nghệ của mình. Để giảm chi phí, chúng tôi đã hạn chế hỗ trợ tập trung và tập trung vào JVM, các nút mới và Docker. Chúng tôi ưu tiên tác động hiệu quả, thông báo cho các nhóm về chi phí mà các quyết định của họ phải trả và khuyến khích họ tìm cách sử dụng lại các giải pháp có tác động cao mà họ đã phát triển. Chúng tôi đã sử dụng phương pháp này khi dịch dịch vụ sang tiếng nước ngoài để cung cấp sản phẩm cho khách hàng quốc tế. Các ví dụ bao gồm các thư viện máy khách tương đối đơn giản có thể được tạo tự động, do đó việc tạo phiên bản Python, phiên bản Ruby, phiên bản Java, v.v. là khá dễ dàng.
Chúng tôi không ngừng tìm kiếm cơ hội sử dụng các công nghệ đã được chứng minh đã được chứng minh ở một nơi và trong các tình huống tương tự khác.
Hãy nói về yếu tố cuối cùng - những thay đổi hoặc biến thể. Hãy xem mức tiêu thụ sản phẩm của chúng tôi thay đổi không đều theo ngày trong tuần và theo giờ trong ngày. Có thể nói, 9 giờ sáng là thời điểm khó khăn nhất đối với Netflix, khi tải trên hệ thống đạt mức tối đa.
Làm thế nào chúng ta có thể đạt được tốc độ cao trong việc triển khai đổi mới phần mềm, tức là liên tục thực hiện các thay đổi mới cho hệ thống mà không gây gián đoạn trong việc cung cấp dịch vụ và không gây bất tiện cho khách hàng? Netflix đạt được điều này thông qua việc sử dụng Spinnaker, một nền tảng quản lý và phân phối liên tục (CD) dựa trên đám mây toàn cầu mới.
Điều quan trọng là Spinnaker được thiết kế để tích hợp các phương pháp thực hành tốt nhất của chúng tôi để khi triển khai các thành phần vào sản xuất, chúng tôi có thể tích hợp đầu ra trực tiếp vào công nghệ phân phối phương tiện của mình.
Chúng tôi đã có thể kết hợp hai công nghệ vào quy trình phân phối mà chúng tôi đánh giá cao: phân tích canary tự động và triển khai theo giai đoạn. Phân tích Canary có nghĩa là chúng tôi hướng một lượng nhỏ lưu lượng truy cập đến phiên bản mã mới và chuyển phần còn lại của lưu lượng truy cập sản xuất sang phiên bản cũ. Sau đó, chúng tôi kiểm tra xem mã mới có thể đáp ứng nhiệm vụ như thế nào - tốt hơn hay kém hơn mã hiện có.
Triển khai theo giai đoạn có nghĩa là nếu quá trình triển khai ở một khu vực gặp vấn đề thì chúng tôi sẽ chuyển sang triển khai ở một khu vực khác. Trong trường hợp này, danh sách kiểm tra nêu trên phải được đưa vào quy trình sản xuất. Tôi sẽ giúp bạn tiết kiệm thời gian và khuyên bạn nên xem bài nói chuyện trước đây của tôi, Kỹ thuật vận hành Netflix toàn cầu trên đám mây, nếu bạn muốn tìm hiểu sâu hơn về chủ đề này. Bạn có thể xem đoạn video ghi lại bài phát biểu bằng cách nhấp vào liên kết ở cuối slide.
Cuối buổi nói chuyện, tôi sẽ nói ngắn gọn về tổ chức và kiến trúc của Netflix. Lúc đầu, chúng tôi có một kế hoạch gọi là Phân phối điện tử, đây là phiên bản đầu tiên của truyền phát đa phương tiện NRDP 1.x. Thuật ngữ "ngược dòng" có thể được sử dụng ở đây vì ban đầu người dùng chỉ có thể tải xuống nội dung để phát lại sau trên thiết bị. Nền tảng phân phối kỹ thuật số đầu tiên của Netflix, vào năm 2009, trông giống như thế này.
Thiết bị người dùng chứa ứng dụng Netflix, bao gồm giao diện UI, mô-đun bảo mật, kích hoạt và phát lại dịch vụ, dựa trên nền tảng NRDP - Nền tảng thiết bị sẵn sàng Netflix.
Vào thời điểm đó, giao diện người dùng rất đơn giản. Nó chứa thứ được gọi là Queque Reader và người dùng sẽ truy cập trang web để thêm nội dung nào đó vào Queque và sau đó xem nội dung đã thêm trên thiết bị của họ. Điểm tích cực là nhóm front end và back end thuộc cùng một tổ chức Electronic Delivery và có mối quan hệ làm việc chặt chẽ. Tải trọng được tạo dựa trên XML. Đồng thời, API Netflix dành cho hoạt động kinh doanh DVD đã được tạo, khuyến khích các ứng dụng của bên thứ ba hướng lưu lượng truy cập đến dịch vụ của chúng tôi.
Tuy nhiên, API Netflix đã được chuẩn bị kỹ lưỡng để giúp chúng tôi có giao diện người dùng sáng tạo, chứa siêu dữ liệu của tất cả nội dung, thông tin về những bộ phim có sẵn, tạo ra khả năng tạo danh sách xem. Nó có API REST chung dựa trên lược đồ JSON, Mã phản hồi HTTP, cùng một mã được sử dụng trong kiến trúc hiện đại và mô hình bảo mật OAuth, vốn là những gì được yêu cầu vào thời điểm đó đối với ứng dụng giao diện người dùng. Điều này giúp có thể chuyển từ mô hình phân phối nội dung phát trực tuyến công khai sang mô hình riêng tư.
Vấn đề với quá trình chuyển đổi là sự phân mảnh, vì hiện tại hệ thống của chúng tôi vận hành hai dịch vụ dựa trên các nguyên tắc hoạt động hoàn toàn khác nhau - một dịch vụ dựa trên Rest, JSON và OAuth, dịch vụ còn lại dựa trên RPC, XML và cơ chế bảo mật người dùng dựa trên hệ thống mã thông báo NTBA. Đây là kiến trúc lai đầu tiên.
Về cơ bản, có một bức tường lửa giữa hai nhóm của chúng tôi vì ban đầu API không mở rộng tốt với NCCP và điều này dẫn đến xích mích giữa các nhóm. Sự khác biệt nằm ở dịch vụ, giao thức, mạch, mô-đun bảo mật và nhà phát triển thường phải chuyển đổi giữa các bối cảnh hoàn toàn khác nhau.
Về vấn đề này, tôi đã có cuộc trò chuyện với một trong những kỹ sư cấp cao của công ty, người mà tôi đã đặt câu hỏi: “Kiến trúc dài hạn phù hợp là gì?” và anh ấy đã hỏi câu hỏi ngược lại: “Có lẽ bạn quan tâm hơn về những hậu quả của tổ chức - điều gì sẽ xảy ra nếu chúng ta tích hợp những thứ này và chúng phá vỡ những gì chúng ta đã học để làm tốt? Cách tiếp cận này rất phù hợp với Định luật Conway: "Các tổ chức thiết kế hệ thống bị hạn chế bởi một thiết kế sao chép cấu trúc truyền thông của tổ chức đó". Đây là một định nghĩa rất trừu tượng, vì vậy tôi thích một định nghĩa cụ thể hơn: “Bất kỳ phần mềm nào cũng phản ánh cơ cấu tổ chức đã tạo ra nó”. Đây là câu nói yêu thích của tôi từ Eric Raymond: "Nếu bạn có bốn nhóm nhà phát triển làm việc trên một trình biên dịch, bạn sẽ có được một trình biên dịch bốn bước." Chà, Netflix có trình biên dịch bốn lượt và đó là cách chúng tôi làm việc.
Chúng ta có thể nói rằng trong trường hợp này cái đuôi đang vẫy con chó. Ưu tiên hàng đầu của chúng tôi không phải là giải pháp mà là tổ chức; chính tổ chức thúc đẩy kiến trúc mà chúng tôi có. Dần dần, từ một hỗn hợp các dịch vụ, chúng tôi đã chuyển sang kiến trúc mà chúng tôi gọi là Blade Runner, vì ở đây chúng tôi đang nói về các dịch vụ biên và khả năng NCCP được tách và tích hợp trực tiếp vào proxy Zuul, cổng API và chức năng tương ứng. “Các mảnh ghép” đã được biến thành các dịch vụ vi mô mới với các tính năng bảo mật, phát lại, sắp xếp dữ liệu, v.v. nâng cao hơn.
Vì vậy, có thể nói rằng cơ cấu phòng ban và sự năng động của công ty đóng vai trò quan trọng trong việc định hình thiết kế hệ thống và là yếu tố thúc đẩy hoặc cản trở sự thay đổi. Kiến trúc microservice rất phức tạp và hữu cơ, đồng thời sức khỏe của nó dựa trên kỷ luật và sự hỗn loạn được đưa vào.
Một chút quảng cáo
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com