Tôi làm việc trong lĩnh vực gia công, nơi nguyên tắc chính có thể được mô tả bằng cụm từ “bán nhiều, làm nhanh”. Chúng ta làm điều đó càng nhanh thì chúng ta sẽ kiếm được càng nhiều. Và, điều mong muốn là mọi thứ đều hoạt động không phải bằng nạng và nước mũi mà với mức chất lượng có thể chấp nhận được. Tôi sẽ kể cho bạn nghe về trải nghiệm của tôi khi cần phát triển dịch vụ quảng cáo trong một khoảng thời gian ngắn.
Được: tài khoản root trên AWS, không hạn chế lựa chọn công nghệ, một chương trình phụ trợ và một tháng để phát triển.
Thử thách: triển khai dịch vụ quảng cáo trong đó người dùng tải lên từ một đến bốn video kéo dài từ một đến bốn giây, sau đó được nhúng vào chuỗi video gốc.
phán quyết
Viết dịch vụ xe đạp của riêng bạn trong thời gian ngắn như vậy không phải là một ý tưởng hay. Ngoài ra, để dịch vụ có thể đáp ứng được tải trọng và để mọi người có thể nhận được video mong muốn, cơ sở hạ tầng sẽ được yêu cầu. Và tốt nhất là không có thẻ giá từ máy bay. Do đó, chúng tôi ngay lập tức tập trung vào các giải pháp làm sẵn với khả năng tùy chỉnh tối thiểu.
Giải pháp tiêu chuẩn để làm việc với video là FFmpeg, một tiện ích bảng điều khiển đa nền tảng, thông qua các đối số, cho phép bạn cắt và ghi đè âm thanh. Tất cả những gì còn lại phải làm là viết một trình bao bọc và đưa nó vào cuộc sống. Chúng tôi viết một nguyên mẫu để ghép hai video lại với nhau và... cuộc vui bắt đầu. Thư viện dựa trên .NET Core 2, nó sẽ chạy trên bất kỳ máy ảo nào, vì vậy chúng tôi lấy phiên bản AWS EC2 và mọi thứ sẽ hoạt động
Văn bản bị ẩnkhông, nó sẽ không hoạt động
.
Mặc dù FFmpeg đơn giản hóa tác vụ nhưng để có một giải pháp thực sự hiệu quả, bạn cần tạo một phiên bản EC2 và thiết kế cơ sở hạ tầng mạng cho nó, bao gồm cả Cân bằng tải. Nhiệm vụ đơn giản là triển khai từ đầu trở nên phức tạp hơn “một chút” và cơ sở hạ tầng bắt đầu yêu cầu tiền ngay lập tức - mỗi giờ số tiền cho thời gian chạy sẽ được rút từ tài khoản khách hàng.
Dịch vụ của chúng tôi không liên quan đến các quy trình Chạy dài, không yêu cầu cơ sở dữ liệu quan hệ lớn và phức tạp, đồng thời hoàn toàn phù hợp với kiến trúc dựa trên sự kiện với một chuỗi lệnh gọi vi dịch vụ. Giải pháp tự gợi ý - chúng ta có thể từ bỏ EC2 và triển khai một ứng dụng true-serverless, như Image Resizer tiêu chuẩn dựa trên AWS Lambda.
Nhân tiện, mặc dù các nhà phát triển AWS rõ ràng không thích .NET, nhưng họ vẫn hỗ trợ .NET Core 2.1 dưới dạng thời gian chạy, cung cấp đầy đủ các cơ hội phát triển.
Và điều quan trọng nhất - AWS cung cấp một dịch vụ riêng để làm việc với các tệp video - AWS Elemental MediaConvert.
Bản chất của công việc cực kỳ đơn giản: chúng tôi lấy liên kết S3 tới video gửi đi, viết thông qua AWS Console, .NET SDK hoặc đơn giản là JSON những gì chúng tôi muốn làm với video và gọi dịch vụ. Bản thân nó triển khai các hàng đợi để xử lý các yêu cầu đến, tải kết quả lên chính S3 và quan trọng nhất là tạo Sự kiện CloudWatch cho mỗi thay đổi trạng thái. Điều này cho phép chúng tôi triển khai trình kích hoạt lambda để hoàn tất quá trình xử lý video.
Đây là kiến trúc cuối cùng trông như thế nào:
Toàn bộ phần phụ trợ được đặt trong hai lambdas. Một cách khác là để quay video dọc, vì công việc như vậy không thể thực hiện được trong một lần.
Chúng tôi sẽ đặt mặt trước dưới dạng một ứng dụng SPA được viết bằng JS và được biên dịch qua pug trong nhóm S3 công khai. Để tải xuống video, chúng tôi không cần bất kỳ mã máy chủ nào - chúng tôi chỉ cần mở điểm cuối REST mà S3 cung cấp cho chúng tôi. Điều duy nhất là đừng quên cấu hình các chính sách và CORS.
Cạm bẫy
- AWS MediaConvert, vì một số lý do không xác định, chỉ áp dụng âm thanh cho từng đoạn video riêng biệt, nhưng chúng tôi cần một bài hát vui vẻ từ toàn bộ trình bảo vệ màn hình.
- Video dọc cần được xử lý riêng. AWS không thích các thanh màu đen và đặt các con lăn ở góc 90°.
Sân trượt băng dễ dàng
Bất chấp vẻ đẹp của Stateless, bạn cần theo dõi những gì cần làm với video: dán hoặc thêm âm thanh vào chuỗi video hoàn chỉnh. May mắn thay, MediaConvert hỗ trợ truyền siêu dữ liệu qua Công việc của nó và chúng tôi luôn có thể sử dụng cờ đơn giản có dạng “isMasterSoundJob”, phân tích cú pháp siêu dữ liệu này ở bất kỳ giai đoạn nào.
Serverless hoàn toàn cho phép làm việc với NoOps - một cách tiếp cận giả định rằng không cần thiết phải có một nhóm riêng biệt chịu trách nhiệm về cơ sở hạ tầng dự án. Do đó, đây chỉ là một vấn đề nhỏ - chúng tôi triển khai giải pháp trên AWS mà không có sự tham gia của quản trị viên hệ thống, những người luôn có việc phải làm.
Và để tăng tốc tất cả những điều này, chúng tôi tự động hóa tập lệnh triển khai nhiều nhất có thể trên AWS CloudFormation, cho phép bạn triển khai bằng một nút trực tiếp từ VS. Do đó, một tệp gồm 200 dòng mã cho phép bạn triển khai một giải pháp làm sẵn, mặc dù cú pháp CloudFormation có thể gây sốc nếu bạn không quen với nó.
trong tổng số
Serverless không phải là thuốc chữa bách bệnh. Nhưng nó sẽ làm cho cuộc sống dễ dàng hơn nhiều trong những tình huống có ba giới hạn: “nguồn lực hạn chế – ngắn hạn – ít tiền”.
Đặc điểm của ứng dụng phù hợp với Serverless
- không có quy trình chạy dài. Giới hạn cứng của API Gateway là 29 giây, giới hạn cứng của lambda là 5 phút;
- được mô tả bằng kiến trúc Hướng sự kiện;
- chia thành các thành phần được liên kết lỏng lẻo như SOA;
- không yêu cầu nhiều công việc với tình trạng của bạn;
- được viết bằng .NET Core. Để làm việc với .NET Framework, bạn vẫn cần ít nhất Docker với thời gian chạy thích hợp.
Lợi ích của phương pháp Serverless
- giảm chi phí cơ sở hạ tầng;
- giảm chi phí cung cấp giải pháp;
- khả năng mở rộng tự động;
- phát triển vượt bậc của tiến bộ công nghệ.
Nhược điểm, với một ví dụ cụ thể
- Truy tìm và ghi nhật ký phân tán - được giải quyết một phần thông qua AWS X-Ray và AWS CloudWatch;
- gỡ lỗi bất tiện;
- Khởi động nguội khi không tải;
- Giao diện thù địch với người dùng AWS là một vấn đề phổ biến :)
Nguồn: www.habr.com