
معرفی
به وبلاگ عالی دیگری که شخصاً توسط کارشناسان DEV IT ما گردآوری شده است، خوش آمدید. وبلاگ قبلی، راهنمای سریع ویژگی های Azure، به شرح ویژگی های Azure می پردازد و موضوعاتی از جمله:
- ویژگی Azure چیست؟
- بدون سرور چیست؟
- نمونه ای از تابع Azure
وبلاگ دیگری در این سایت موضوعاتی را در مورد “استفاده از Injector Builder برای استقرار DI در Microsoft Azure” پوشش می دهد. این یکی دیگر از وبلاگ های مهم در مورد پروژه های عملکرد Azure است و برای اطمینان از یکپارچگی کد شما در حین کار بر روی پروژه عملکرد Azure ضروری است. این پست جدید اکنون به موضوعات تزریق وابستگی برای ویژگیهای Azure V2 و V3 میپردازد. ما در حال حاضر به دنبال V1 نخواهیم بود، اما اگر می خواهید یک وبلاگ در مورد آن داشته باشید، لطفاً یک نظر در زیر بنویسید و من به زودی یکی را ارسال خواهم کرد.
بنابراین، بیایید بلافاصله به آن بپردازیم. این وبلاگ محرک های مختلفی را برای اجرای ویژگی های Azure پوشش می دهد.
تریگر آزور چیست؟
ماشه تابع لاجوردی مکانیزمی است که توسط آن می توان تابع را (به صورت دستی یا خودکار) فراخوانی کرد. به محرک به عنوان یک رویداد فکر کنید. هنگامی که رویداد رخ می دهد، تابع را با داده های مناسب فراخوانی می کند تا تابع Azure زمینه کافی برای تصمیم گیری را پیدا کند.
انواع مختلفی از محرک ها وجود دارد که ویژگی Azure در خارج از جعبه از آنها پشتیبانی می کند که در این پست وبلاگ به آنها خواهیم پرداخت. و اگر متوجه شدید که نیاز شما هیچ یک از محرک های موجود پشتیبانی شده توسط جعبه را برآورده نمی کند، نگران نباشید. نمونه ای از یک تریگر سفارشی را خواهیم دید و خواهیم دید که چگونه یک تریگر سفارشی می تواند پیاده سازی شود.
محرک های پشتیبانی شده برای ویژگی Azure
معمولاً در هر پروژه از محرک های زیر استفاده می شود:
- HTTP و قلاب های وب
- تایمر
- ذخیره سازی وبلاگ
- ذخیره سازی میز
- ذخیره سازی دم
- اتوبوس خدماتی
- شبکه ای از رویدادها
- مرکز رویداد
Http و قلاب های وب
راهانداز HTTP & webhooks برای فراخوانی یک تابع لاجوردی با برقراری تماس HTTP است. یعنی می توانید یک API بدون سرور ایجاد کنید یا با API های خود به عنوان یک قلاب یکپارچه سازی شخص ثالث رفتار کنید.
که در قسمت 1، نمونه ای از تابع لاجوردی HTTPTrigger را با استفاده از مثال HelloWorld دیدیم. پس از پیاده سازی، دیدیم که تابع می تواند در http: // localhost: 7071: // api / helloworldfunction فراخوانی شود.
در اینجا مواردی وجود دارد که هنگام اجرای ویژگی HTTP Trigger باید در نظر داشته باشید:
اتصال HTTP تمام شد
اگر HTTP API را با استفاده از HTTPClient در تابع HTTPTriger خود فراخوانی کنید، ممکن است با مشکل تخلیه پورت مواجه شوید که می توانید با به اشتراک گذاری اشیاء HTTPClient در چندین پیاده سازی عملکرد آن را حل کنید. راه های دیگری نیز وجود دارد که در اینجا با جزئیات بیشتر توضیح داده شده است – مدیریت اتصال HTTP در توابع Azure.
محافظت از ویژگی HTTP Trigger
به طور پیش فرض، ویژگی فعال کردن HTTP به اتصالات ناشناس اجازه می دهد. یعنی هر کسی با URL می تواند ویژگی ما را درخواست کند. این را می توان به چند روش حل کرد:
1. از کلیدهای تابع استفاده کنید – با استفاده از این کلید، فقط می توانید عملکرد Azure مربوطه را فراخوانی کنید.
2. از کلیدهای میزبان استفاده کنید – با استفاده از این کلید، می توانید تمام عملکردهای یک سرویس برنامه را فراخوانی کنید.
3. از کلیدهای اصلی استفاده کنید – با استفاده از این کلید می توانید به تمامی ویژگی ها و همچنین به API مدیریت ویژگی های Azure و سرویس اپلیکیشن دسترسی داشته باشید.
4. از مکانیزم احراز هویت سرویس برنامه استفاده کنید – Azure Application Service (ویژگی یا برنامه وب) دارای پشتیبانی داخلی برای احراز هویت و نقاط پایانی مجوز است. میتوان از ASP.NET Identity تحت تابع لاجوردی برای مدیریت هویتها و تولید توکنها استفاده کرد و به میانافزار اجازه داد تا به سرویس برنامه اجازه دهد تا بخش مجوز را پردازش کند.
5. از سایر خدمات Azure مانند APIM استفاده کنید
6. مشابه با استفاده از مکانیسم احراز هویت، از قابلیت های مدیریت API می توان برای ایمن سازی API ها استفاده کرد.
از گزینه های پشتیبانی شده در بالا، اگر قصد دارید API را از طریق اینترنت در حال تولید در معرض دید قرار دهید، 4 و 5 روش پیشنهادی برای پیاده سازی هستند.
برای اطلاعات بیشتر در مورد «ارائه توابع محرک HTTP» اینجا را بخوانید.
یادداشت مهم: اگر تابع ماشه لاجوردی از کار بیفتد، زمان اجرای لاجورد تابع را دوباره امتحان نمی کند، یعنی. مکانیسم Retry در تابع TimerTrigger تعبیه نشده است.
تایمر
همانطور که از نام آن پیداست، ماشه تایمر اجازه می دهد تا یک تابع بر اساس زمان از پیش تعیین شده فراخوانی شود. عملکردی که با تایمر راهاندازی میشود بهعنوان یک تابع زمانبندی شده در نظر بگیرید که میتواند هر روز در ساعت ۱۲ ظهر، هر دوشنبه در ساعت ۳:۰۰ صبح، یا هر ۳۰ دقیقه در روزهای دوشنبه، چهارشنبه، یعنی بسته به نموداری که تعریف میکنیم، عملکرد تایمر انجام شود. با اجرای تابع Azure اجرا می شود.
تریگر تایمر بر اساس عبارت NCRONTab اجرا می شود. به عنوان مثال، “0 * / 5 * * * *” یک عبارت کرون برای “هر 5 دقیقه یک بار” و “0 30 9 * Jan Mon” یک عبارت کرون برای “9:30 صبح هر دوشنبه در ژانویه است”.
توجه: بیان و زمانهای CRON در ویژگی Azure (یا همه سرویسهای لاجوردی) فقط بر اساس UTC هستند.
بیایید یک مثال را ببینیم:
[FunctionName("ScheduledImport")] public static void Run([TimerTrigger("0 */5 * * * *")]TimerInfo timerRequest, ILogger logger) { log.LogInformation($"Timer is running at {DateTime.UtcNow}!"); }
از مثال بالا می بینیم که TimerTrigger یک عبارت NCRON را به عنوان ورودی می گیرد و تصمیم می گیرد که چه زمانی تابع را اجرا کند. همچنین می توانید این عبارت را از فایل local.development.json دریافت کنید. TimerInfo را به عنوان یک پرس و جو ارسال می کند که به عنوان ویژگی هایی مانند:
- ScheduleStatus.Last – آخرین بار برای انجام عملکرد لاجوردی
- ScheduleStatus.Next – دفعه بعد برای اجرای تابع azure
- IsPastDue – آیا این ویژگی دیرتر از زمان برنامه ریزی شده فعال می شود یا خیر.
یادداشت مهم: اگر تابع ماشه لاجوردی از کار بیفتد، زمان اجرای لاجورد تابع را دوباره امتحان نمی کند، یعنی. مکانیسم Retry در تابع TimerTrigger تعبیه نشده است.
ذخیره سازی Blob
عملکرد راهاندازی شده توسط Blog Storage زمانی اجرا میشود که زمان اجرای Azure یک لکه جدید/بهروزرسانی شده را در یک ظرف پیکربندی شده شناسایی کند. از آنجایی که کشف نقاط جدید/بهروزرسانیشده میتواند یک چالش عملکرد باشد، زمان اجرا Azure میتواند برخی از رویدادهایی را که میتوانند باعث رفتار غیرمنتظره شوند نادیده بگیرد. یعنی تابع azure ممکن است برای رویدادهای blob اجرا نشود زیرا ممکن است از آنها صرفنظر شود.
بیایید یک مثال را ببینیم:
[FunctionName("ProfilePictureModify")] public static void Run([BlobTrigger("profile-pictures/{name}")] Stream blobRequest, string name, ILogger logger) { log.LogInformation($"Function is executing for blob name:{name} and Size: {myBlob.Length} Bytes"); }
یادداشت های مهم:
- هنگامی که عملکرد ماشه حباب از کار می افتد، به طور خودکار تا 5 بار امتحان می کند. اگر هر پنج تلاش مجدد ناموفق باشد، مرجع اجرای blob به عنوان یک حباب سم به فروشگاه صف اضافه می شود. (یعنی لکه همانطور که در حساب ذخیره سازی هست باقی می ماند)
- MaxDequeueCount تنظیمی است که می توان از آن برای امتحان مجدد استفاده کرد و به طور پیش فرض روی 5 تنظیم شده است.
- بهطور پیشفرض، 24 تابع blob را میتوان بهدلیل محدودیت پیشفرض به طور همزمان فعال کرد که میتوان آن را در فایل host.json تغییر داد.
برای اطلاعات بیشتر در مورد نکات فوق اینجا را بخوانید – “استفاده از موازی سازی و حافظه”.
ذخیره سازی میز
ما به ذخیره سازی جداول با جزئیات بیشتری نگاه نمی کنیم، زیرا طرح ها شبیه به ذخیره سازی حباب ها با تفاوت های کوچک است که می توانید در اینجا بخوانید – Table Storage Trigger.
ذخیره سازی دم
صف فعالشده یکی از پرکاربردترین محرکهای توابع لاجوردی است که کاملاً مشابه «ServiceBus»، «EventHub» و «EventGrid» هستند. بنابراین، نمونههایی از نحوه اجرای Queue Trigger و سپس پوشش تفاوتهای کلیدی بین سایرین را خواهیم دید.
توابع فعال شده توسط صف زمانی فراخوانی می شوند که پیام در فروشگاه صف موجود باشد.
بیایید مثالی بزنیم:
[FunctionName("SendNotificationForGroupCreation")] public static void Run( [QueueTrigger("group creation notification queue", Connection = "StorageConnectionSetting")] string groupCreationRequest, ILogger log) { log.LogInformation($"Function is executing request for {groupCreationRequest}"); }
از مثال بالا، می بینید که هر بار که پیامی در صفی به نام “صف اعلان گروه” در حساب ذخیره سازی “StorageConnectionSetting” یافت می شود، تابع فراخوانی / اجرا می شود.
پرس و جوی ورودی می تواند یک رشته (کوئری ایجاد گروه) یا یک شی باشد (در این مورد زمان اجرا لاجوردی رشته را به نوع ارائه شده از حالت سریال خارج می کند).
یادداشت های مهم:
- اگر یک تابع ناموفق باشد، azure runtime پنج تلاش را امتحان میکند و اگر همه تلاشها با شکست مواجه شوند، زمان اجرای azure پیام را به صف Poison منتقل میکند، یعنی. {Original-Queue-Name} -poison.
- اندازه دسته پیش فرض صف 16 است، یعنی. زمان اجرای Azure 16 پیام را از صف دریافت کرده و به صورت موازی اجرا می کند. این تنظیمات را می توان در فایل host.json تغییر داد.
تفاوت اصلی بین ماشه ذخیره سازی دم و ماشه باس سرویس:
- در حالی که تابع راهانداز صف میتواند پیامهای صف را بخواند، تابع راهانداز گذرگاه خدمات میتواند پیامها و رشتههای صف را بخواند.
- تعداد دفعات تکرار برای ذخیره صف توسط تابع تعریف و پردازش می شود، در حالی که برای گذرگاه سرویس بر اساس تعداد تحویل پیام (و همچنین در سطح تابع) تعریف می شود.
جدول زیر را می توان به عنوان مرجعی برای انواع ماشه های پشتیبانی شده با توجه به نسخه Azure مشاهده کرد.
تایپ کنید | 1.x | 2.x و بالاتر | ماشه | ورود | خروج |
---|---|---|---|---|---|
ذخیره سازی Blob | ![]() | ![]() | ![]() | ![]() | ![]() |
Azure Cosmos DB | ![]() | ![]() | ![]() | ![]() | ![]() |
داپر3 | ![]() | ![]() | ![]() | ![]() | |
شبکه ای از رویدادها | ![]() | ![]() | ![]() | ![]() | |
مراکز رویداد | ![]() | ![]() | ![]() | ![]() | |
HTTP و قلاب های وب | ![]() | ![]() | ![]() | ![]() | |
مرکز اینترنت اشیا | ![]() | ![]() | ![]() | ![]() | |
کافکا 2 | ![]() | ![]() | ![]() | ||
برنامه های موبایل | ![]() | ![]() | ![]() | ||
مراکز اطلاع رسانی | ![]() | ![]() | |||
ذخیره سازی دم | ![]() | ![]() | ![]() | ![]() | |
RabbitMQ2 | ![]() | ![]() | ![]() | ||
SendGrid | ![]() | ![]() | ![]() | ||
اتوبوس خدماتی | ![]() | ![]() | ![]() | ![]() | |
SignalR | ![]() | ![]() | ![]() | ||
ذخیره سازی میز | ![]() | ![]() | ![]() | ![]() | |
تایمر | ![]() | ![]() | ![]() | ||
تویلیو | ![]() | ![]() | ![]() |
ماشه سفارشی برای عملکرد Azure
در قسمت قبل انواع مختلفی از تریگرها را دیدیم که ویژگی Azure از آنها پشتیبانی می کند. اگر هیچ یک از آنها نیازهای شما را برآورده نکرد، می توانید یک ماشه سفارشی ذخیره کنید.
اساساً نوشتن یک پسوند سفارشی شامل دو بخش است:
- نوشتن ماشه – مسئول تماس است
- نوشتن صحافی – مسئول ارائه داده های لازم است.
بیایید یک اسکریپت برای نوشتن یک تابع لاجوردی در نظر بگیریم که بر اساس ایمیل دریافت شده در جعبه ایمیل شخصی انجام می شود. (پذیرش صرافی یا دفتر 365 در اینجا)
بیایید ابتدا Trigger را بنویسیم
[AttributeUsage(AttributeTargets.Parameter)] [Binding] public class OutlookTriggerAttribute: Attribute { public string GraphConnectionString { get; set; } public string EmailId { get; set; } public string Password { get; set; } internal string GetOfficeGraphUri() { return Environment.GetEnvironmentVariable(GraphConnectionString ); } } Now let’s implement a Listener responsible for reading messages: public class OutlookListener: IListener { private readonly ITriggeredFunctionExecutor _executor; private readonly OutlookTriggerContext _context; public OutlookListener(ITriggeredFunctionExecutor executor, OutlookTriggerContext context) { _executor = executor; _context = context; } public void cancel() { if (_context == null || _context.Client == null) return; _context.Client.Disconnect(); } public void Dispose() { _context.Client.Dispose(); } public Task StartAsync(CancellationToken cancellationToken) { return Task.Factory.StartNew(() => { while (true) { wtoken.Token.ThrowIfCancellationRequested(); //_context.Client.GetMessages(); // … Get message from graph API an var triggerData = new TriggeredFunctionData { TriggerValue = outlookMessagePayload }; var task = _executor.TryExecuteAsync(triggerData, CancellationToken.None); task.Wait(); Task.Wait(10000); } }, wtoken, TaskCreationOptions.LongRunning); } public Task StopAsync(CancellationToken cancellationToken) { return Task.Run(() =>{ _context.Client.Disconnect(); }); } } }
بیایید زمینه Outlook Trigger را اعمال کنیم.
public class OutlookTriggerContext { public OutlookTriggerAttribute TriggerAttribute; public GraphApiClient Client; public OutlookTriggerContext(OutlookTriggerAttribute attribute, GraphApiClient client) { this.TriggerAttribute = attribute; this.Client = client; } }
اکنون Binding را برای ماشه Outlook خود پیاده سازی می کنیم
[assembly: WebJobsStartup(typeof(OutlookBinding.Startup))] namespace WebJobs.Extension.Outlook { public class OutlookBinding { public class Outlookup : IWebJobsStartup { public void Configure(IWebJobsBuilder builder) { builder.AddOutlookExtension(); } } } }
برای تکمیل باید متد AddOutlookExtension را اضافه کنیم
public static class OutlookWebJobsBuilderExtensions { public static IWebJobsBuilder AddNatsExtension(this IWebJobsBuilder builder) { if (builder == null) { throw new ArgumentNullException(nameof(builder)); } builder.AddExtension<OutlookExtensionConfigProvider>(); builder.Services.AddSingleton<IOutlookServiceFactory, OutlookServiceFactory>(); return builder; } }
اکنون میتوانیم یک ویژگی لاجوردی را ذخیره کنیم که میتواند بر اساس ایمیلی که در جعبه ایمیل دریافت میکنید فعال شود:
public static class OutlookTriggerFunction { [FunctionName("OutlookTriggerFunction")] public static void Run( [OutlookTrigger(GraphConnectionString = "mail.outlook.com", EmailId = "[email protected]", Password = "Password")] string outlookMessage, ILogger log) { log.LogInformation($"Message Received From outlook mailbox is {outlookMessage}"); } }
نتیجه
امیدوارم این وبلاگ به شما کمک کرده باشد تا در مورد محرک های V2 و V3 برای ویژگی های Azure بیاموزید. مجدداً، اگر شما نیز میخواهید یک وبلاگ V1 داشته باشید، لطفاً آن را در نظرات زیر ذکر کنید. همچنین، اگر شک دیگری دارید، لطفاً در زیر نظر دهید و مهندسان DEV IT ما با شما تماس خواهند گرفت.
نشریه قسمت -2: راهنمای تخصصی برای آموزش عملکرد Azure اولین بار در مجله DEV IT ظاهر شد.