Developer Advocate
Kanalga Telegram’da o‘tish
1 035
Obunachilar
Ma'lumot yo'q24 soatlar
Ma'lumot yo'q7 kun
-130 kun
Postlar arxiv
1 035
یکی از الهامبخشترین مثالهای استفاده از SignalR در ASP.NET Core، پیادهسازی live collaboration feature شبیه Google Docs است. فرض کنید چند کاربر همزمان روی یک صفحه «یادداشتبرداری تیمی» کار میکنند. هر تغییری که توسط کاربری ایجاد میشود (چه تایپ یک حرف باشد یا حذف یک پاراگراف)، تقریباً بلافاصله برای سایرین قابل مشاهده است—بدون هیچ ریفریش یا polling!
در اینجا اسکلت سادهی SignalR Hub را میبینید که تغییرات متن را real-time برای تمام شرکتکنندگان ارسال میکند:
public class DocumentHub : Hub
{
// ارسال بروزرسانی متن به همه کلاینتها به جز ارسالکننده
public async Task UpdateContent(string documentId, string content)
{
await Clients.OthersInGroup(documentId)
.SendAsync("ReceiveContentUpdate", content);
}
// گروهبندی کاربران براساس DocumentId برای تفکیک اسناد
public override async Task OnConnectedAsync()
{
var documentId = Context.GetHttpContext().Request.Query["docId"];
await Groups.AddToGroupAsync(Context.ConnectionId, documentId);
await base.OnConnectedAsync();
}
}
ReceiveContentUpdate را گوش دهد تا ویرایش دیگران را real-time دریافت نماید.
📌 آنچه این Pattern را متمایز میکند:
- Isolation: استفاده از گروهها به تفکیک context کاری چندین سند یا session کمک میکند.
- Zero Latency UX: تجربه کاربری کاملاً بیدرنگ—مناسب هر جایی که مشارکت تیمی و شفافیت نیاز است.
- پیادهسازی تمیز و مقیاسپذیر: SignalR به سادگی روی کانفیگ Redis Scale-Out اجرا میشود و در محیطهای cloud-native (مثل Azure SignalR Service) نیز عالی جواب میدهد.
برای سناریوهای پیشرفتهتر میتوانید conflict resolution و OT/CQRS نیز به معماری بیفزایید. این سبک معماری، نسل بعدی collaboration applications را ممکن و پایدار میکند! 🚀
@DeveloperAdvocate 🥑1 035
🔹 مدیریت Concerns مقطعی (Cross-Cutting Concerns) با Middleware و Decorator در .NET
در معماری مدرن، پیادهسازی concernهایی مثل Logging یا Authorization بدون آلودگی منطق اصلی، یکی از کلیدهای ساخت سیستمهای تمیز و قابل نگهداری است. دو رویکرد محبوب:
1️⃣ Middleware در ASP.NET Core
Middlewareها مناسبترین انتخاب برای concerns سراسری در سطح HTTP Pipeline هستند—logging، authentication، exception handling و غیره. مثال ساده لاگگیری:
public class LoggingMiddleware
{
private readonly RequestDelegate _next;
private readonly ILogger<LoggingMiddleware> _logger;
public LoggingMiddleware(RequestDelegate next, ILogger<LoggingMiddleware> logger)
{
_next = next;
_logger = logger;
}
public async Task InvokeAsync(HttpContext context)
{
_logger.LogInformation("Request: {Method} {Path}", context.Request.Method, context.Request.Path);
await _next(context);
_logger.LogInformation("Response: {StatusCode}", context.Response.StatusCode);
}
}
// ثبت در Pipeline
app.UseMiddleware<LoggingMiddleware>();
public class LoggingBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
private readonly ILogger<LoggingBehavior<TRequest, TResponse>> _logger;
public LoggingBehavior(ILogger<LoggingBehavior<TRequest, TResponse>> logger)
{
_logger = logger;
}
public async Task<TResponse> Handle(TRequest request, RequestHandlerDelegate<TResponse> next, CancellationToken cancellationToken)
{
_logger.LogInformation("Handling {RequestName}", typeof(TRequest).Name);
var response = await next();
_logger.LogInformation("Handled {RequestName}", typeof(TRequest).Name);
return response;
}
}
// ثبت Behavior در DI
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(LoggingBehavior<,>));
1 035
✅ اهمیت Canary Deployment در استقرار سرویسهای .NET و Microservices غیرقابل انکار است. سرویس مشهایی مانند Istio و Linkerd امکان مدیریت ترافیک در سطح لایه شبکه را فراهم میکنند و قابلیتهایی مانند میزبانی همزمان چند نسخه (Stable/Canary) از یک سرویس و تغییر تدریجی ترافیک میان نسخهها را فراهم میسازند؛ بدون نیاز به تغییر حتی یک خط کد از اپلیکیشن!
بیایید فرآیند پیادهسازی یک Canary Deployment روی Kubernetes با Istio را قدمبهقدم مرور کنیم (مخصوص سرویسهای .NET Core):
1️⃣ استقرار دو نسخه از سرویس
مثال: نسخه
v1 (Stable) و نسخه v2 (Canary) از یک سرویس API تحت عنوان myapi را دارید.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapi-v1
spec:
template:
metadata:
labels:
app: myapi
version: v1
...
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapi-v2
spec:
template:
metadata:
labels:
app: myapi
version: v2
...
apiVersion: v1
kind: Service
metadata:
name: myapi
spec:
selector:
app: myapi
ports:
- name: http
port: 80
targetPort: 5000
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: myapi
spec:
host: myapi
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapi
spec:
hosts:
- myapi
http:
- route:
- destination:
host: myapi
subset: v1
weight: 90 # ۹۰٪ ترافیک به نسخه پایدار
- destination:
host: myapi
subset: v2
weight: 10 # ۱۰٪ به نسخه canary
1 035
در معماریهای event-driven، مکانیزم Change Data Capture (CDC) راهحل ایدهآلی برای استخراج تغییرات دیتابیس و پخش آنها به سایر سیستمهاست. اینجا نحوه راهاندازی یک pipeline با Debezium برای stream کردن تغییرات PostgreSQL به Kafka را مرور میکنیم:
۱. فعالسازی logical replication
ابتدا باید logical replication را در PostgreSQL فعال کنید (در
postgresql.conf):
wal_level = logical max_replication_slots = 4 max_wal_senders = 4و دسترسی لازم در
pg_hba.conf تعریف شود:
host replication debezium 0.0.0.0/0 md5۲. ایجاد replication slot و publication بعد از راهاندازی دوباره، در دیتابیس هدف:
CREATE PUBLICATION debezium_pub FOR ALL TABLES;
docker run -it --rm \
--name debezium-connect \
-p 8083:8083 \
-e GROUP_ID=1 \
-e CONFIG_STORAGE_TOPIC=my_connect_configs \
-e OFFSET_STORAGE_TOPIC=my_connect_offsets \
-e STATUS_STORAGE_TOPIC=my_connect_statuses \
--link kafka:kafka \
debezium/connect:2.5
{
"name": "pg-source",
"config": {
"connector.class": "io.debezium.connector.postgresql.PostgresConnector",
"database.hostname": "postgres",
"database.port": "5432",
"database.user": "debezium",
"database.password": "password",
"database.dbname": "mydb",
"database.server.name": "mydb-server",
"publication.name": "debezium_pub",
"slot.name": "debezium_slot",
"plugin.name": "pgoutput"
}
}
mydb-server.public.<table>) ارسال خواهد شد. در Consumer، پیامها معمولاً به این شکل خواهند بود:
using Confluent.Kafka;
using System.Text.Json;
var config = new ConsumerConfig
{
BootstrapServers = "localhost:9092",
GroupId = "cdc-consumer",
AutoOffsetReset = AutoOffsetReset.Earliest
};
using var consumer = new ConsumerBuilder<Ignore, string>(config).Build();
consumer.Subscribe("mydb-server.public.user");
while (true)
{
var cr = consumer.Consume();
var message = JsonSerializer.Deserialize<DebeziumMessage>(cr.Message.Value);
// پردازش تغییرات مثلاً Insert/Update/Delete
}
public class DebeziumMessage
{
public Payload payload { get; set; }
}
public class Payload
{
public Change before { get; set; }
public Change after { get; set; }
public string op { get; set; } // c=insert, u=update, d=delete
}
public class Change
{
public int id { get; set; }
public string username { get; set; }
// سایر فیلدهای جدول
}
op و مقایسه before/after حالتهای مختلف Data Mutation را مدیریت کنید تا Event sourcing واقعی را تجربه کنید.
@DeveloperAdvocate 🥑1 035
🎯 معماری — Valet Key Pattern برای دسترسی موقت و ایمن به Azure Blob Storage
الگوی Valet Key راهکاری معماری برای واگذاری دسترسی محدود و کنترلشده به منابع است، بدون اینکه کلید اصلی سرویس را در اختیار کاربر قرار دهید. در اکوسیستم Azure، پیادهسازی کلاسیک آن با ایجاد SAS Token (Shared Access Signature) صورت میگیرد که یک کلید دسترسی کوتاهعمر و scoped به کاربر میدهد.
در اینجا یک نمونه عملی از پیادهسازی این الگو را میبینید: فرض کنید میخواهید به client اجازه بارگذاری فایل در یک Blob Container را بدهید، بدون آنکه به Storage Key اصلی یا ارتباط مستقیم با Azure Storage نیاز باشد. API شما این توکن موقت را ایجاد و ارائه میکند:
using Azure.Storage.Blobs;
using Azure.Storage.Sas;
// فرض بر این است که این متد در یک backend API endpoint صدا زده میشود:
public string GenerateUploadSasToken(string blobName, TimeSpan validity)
{
var blobServiceClient = new BlobServiceClient("<StorageAccountConnectionString>");
var containerClient = blobServiceClient.GetBlobContainerClient("<ContainerName>");
var blobClient = containerClient.GetBlobClient(blobName);
// اطمینان حاصل کنید که کلید دسترسی کافی برای تولید SAS دارید
BlobSasBuilder sasBuilder = new BlobSasBuilder
{
BlobContainerName = containerClient.Name,
BlobName = blobClient.Name,
Resource = "b", // blob-level
ExpiresOn = DateTimeOffset.UtcNow.Add(validity)
};
// تنظیم دسترسی موردنیاز – مثلاً فقط برای write (آپلود)
sasBuilder.SetPermissions(BlobSasPermissions.Write);
// تولید SAS Token با استفاده از کلید اکانت
var sasToken = sasBuilder.ToSasQueryParameters(
new Azure.Storage.StorageSharedKeyCredential(
"<StorageAccountName>", "<StorageAccountKey>"))
.ToString();
// آدرس کامل جهت ارسال توسط کلاینت:
return $"{blobClient.Uri}?{sasToken}";
}
1 035
در برنامهنویسی ناهمگام داتنت، استفاده از
async/await تقریباً تبدیل به استاندارد شده؛ اما برای معماریهای پیچیدهتر، دو مفهوم بسیار قوی و کمتر استفادهشده وجود دارد: IAsyncEnumerable<T> و ValueTask<T>.
🔹 IAsyncEnumerable<T>: پردازش دادههای استریم بهصورت ناهمگام
وقتی با حجم زیادی از دادهها یا جریانهای بلندمدت (مثل خواندن از دیتابیس، API یا فایلهای بزرگ) سر و کار داریم، کنترل کردن «بازگشت تدریجی» دادهها اهمیت زیادی پیدا میکند. اینجاست که IAsyncEnumerable<T> وارد میشود. با این اینترفیس میتوانید همزمان هم بهینه مصرف حافظه داشته باشید (چون همه را یکجا بارگذاری نمیکنید) و هم هر مقدار داده که رسید را بلافاصله مصرف کنید.
public async IAsyncEnumerable<int> GetLargeDataAsync()
{
for (int i = 0; i < 1000000; i++)
{
await Task.Delay(1); // فرضا یک عملیات I/O
yield return i;
}
}
// مصرفکننده:
await foreach(var item in GetLargeDataAsync())
{
Console.WriteLine(item);
}
await foreach (... in ... .WithCancellation(token))).
🔹 ValueTask<T>: بهینهسازی هزینههای ناهمگامی
Task همیشه با هزینه heap allocation همراه است؛ اما اگر میدانید که گاهی عملیات شما بلافاصله تکمیل میشود (مثلاً دیتا در کش است)، میتوانید از ValueTask<T> استفاده کنید تا این هزینهها را حذف کنید. این موضوع در کدهای low-latency (مثل کَشها یا سیستمهای با پاسخ سریع) تفاوت بزرگی ایجاد میکند.
public ValueTask<string> GetCachedValueAsync(string key)
{
if (_memoryCache.TryGetValue(key, out var value))
return new ValueTask<string>(value); // بلافاصله پاسخ میدهد
return new ValueTask<string>(GetValueFromStoreAsync(key)); // عملیات ناهمگام واقعی
}
.Result یا await روی یک ValueTask غیرمجاز است؛ همیشه یا یک بار await کنید، یا آن را تبدیل به Task کنید.
---
استفاده هوشمندانه از این ابزارها، به معماری شما انعطاف و بهینگی میدهد، مخصوصاً وقتی با حجم زیاد داده و حساسیت روی منابع سر و کار دارید!
@DeveloperAdvocate 🥑1 035
🔎 در اعماق Reflection: عملکرد و جایگزینهای سریعتر در .NET
اگر اهل معماری نرمافزار در .NET باشید، حتماً با Reflection سروکار داشتهاید: ابزاری قدرتمند اما ذاتاً کند برای متادیتا و کار با ساختارهای پویا. علت اصلی کندی Reflection، وابستگی آن به جداول متادیتای CLR و کسر هزینهٔ کشف و اجرای Memberها در زمان اجراست—گاهی تا صدها برابر کندتر از دسترسی مستقیم.
یک مثال کلاسیک:
var pi = typeof(MyClass).GetProperty("Value");
for (int i = 0; i < 1_000_000; i++)
{
var value = pi.GetValue(obj);
}
GetValue در هر بار اجرا باید از مسیر Reflection عبور کند، که برای حجم بالا بسیار پرهزینه است.
راهکارهای سریعتر چیست؟
۱. Delegate / Expression Trees
با تولید Delegateها به صورت داینامیک و ذخیرهٔ آنها (Caching)، Reflection را عملاً فقط یکبار اجرا میکنید؛ بارهای بعدی، فراخوانی به سرعت کد دستنویس است:
using System.Linq.Expressions;
var param = Expression.Parameter(typeof(MyClass));
var member = Expression.Property(param, "Value");
var lambda = Expression.Lambda<Func<MyClass, int>>(member, param).Compile();
// حالا دسترسی سریع!
int v = lambda(obj);
DynamicMethod و تولید IL خام امکانپذیر است؛ خیلی سریع، اما فقط برای سناریوهای وضعیتمحور ارزش دارد.
جمعبندی کاربردی:
- Reflection را مستقیماً در مسیرهای پرتکرار اجرا نکنید
- دسترسی به Property/Field/Method را از طریق Delegate یا Code Generation سریع کنید
- کش کردن نتیجهی Reflection (مخصوصاً MemberInfo و Delegateها) را حتماً اعمال کنید
🔗 نکته: اگر IL2CPP یا AOT دارید، پیش از انتخاب راهکار سریعتر، محدودیتهای محیط اجرایی را بسنجید.
#AdvancedDotNet #Performance #Reflection #SourceGenerators
@DeveloperAdvocate 🥑1 035
Rate Limiting (محدودسازی نرخ درخواست) از ملزومات معماری سیستمهای قابل اتکاست. پیادهسازی یک middleware Rate Limiter سفارشی در ASP.NET Core نهتنها کنترل بار را آسانتر میکند، بلکه میتواند به سادگی با سایر قطعات pipeline ادغام شود.
اینجا یک نمونه middleware مبتنی بر in-memory dictionary و الگوریتم Token Bucket خواهید دید که براساس کلید IP درخواستها را محدود میکند:
using Microsoft.AspNetCore.Http;
using System.Collections.Concurrent;
using System.Threading.Tasks;
public class RateLimitingMiddleware
{
private readonly RequestDelegate _next;
private readonly int _capacity;
private readonly TimeSpan _refillInterval;
private readonly int _refillAmount;
private static readonly ConcurrentDictionary<string, TokenBucket> _buckets = new();
public RateLimitingMiddleware(RequestDelegate next, int capacity = 20, int refillAmount = 20, int seconds = 60)
{
_next = next;
_capacity = capacity;
_refillAmount = refillAmount;
_refillInterval = TimeSpan.FromSeconds(seconds);
}
public async Task InvokeAsync(HttpContext context)
{
var ip = context.Connection.RemoteIpAddress?.ToString() ?? "unknown";
var bucket = _buckets.GetOrAdd(ip, _ => new TokenBucket(_capacity, _refillAmount, _refillInterval));
if (!bucket.GrantAccess())
{
context.Response.StatusCode = StatusCodes.Status429TooManyRequests;
await context.Response.WriteAsync("Too many requests.");
return;
}
await _next(context);
}
private class TokenBucket
{
private int _tokens;
private readonly int _capacity;
private readonly int _refillAmount;
private readonly TimeSpan _refillInterval;
private DateTime _lastRefill;
public TokenBucket(int capacity, int refillAmount, TimeSpan refillInterval)
{
_capacity = capacity;
_refillAmount = refillAmount;
_refillInterval = refillInterval;
_tokens = capacity;
_lastRefill = DateTime.UtcNow;
}
public bool GrantAccess()
{
lock (this)
{
var now = DateTime.UtcNow;
if (now - _lastRefill > _refillInterval)
{
var periods = (int)((now - _lastRefill).TotalMilliseconds / _refillInterval.TotalMilliseconds);
_tokens = Math.Min(_capacity, _tokens + periods * _refillAmount);
_lastRefill = now;
}
if (_tokens > 0)
{
_tokens--;
return true;
}
return false;
}
}
}
}
app.UseMiddleware<RateLimitingMiddleware>();
1 035
دیتابیسهای گراف: وقتی روابط مهمتر از اطلاعات خام هستند
گاهی ساختار دادههای شما جوری است که هیچ دیتابیس رابطهای یا NoSQL سندمحور نمیتواند بهینه مدیریتشان کند: وقتی که دادهها به شکل یک گراف پیچیده با یالهای متنوع متصلاند. دیتابیسهایی مثل Neo4j دقیقا برای همین موقعیتها ساخته شدهاند؛ جایی که میخواهید به سؤالات پیچیده روی گرافها به سرعت پاسخ دهید.
مثال واقعی: فرض کنید باید یک ماژول "توصیهگر محصول" برای یک فروشگاه آنلاین بسازید و الگوریتم باید بداند چه کاربری چه محصولی را خریده، چه کسانی نظرات مشابهی دادهاند و چه آیتمهایی اغلب با هم خریداری میشوند. یافتن تمام محصولاتی که در سه سطح ارتباط (دوسان دوستان و دوستان آنها) خریداری شدهاند، با SQL عملا کابوس است!
در حالی که در Neo4j، مدل دادههایتان را به شکل نودها (کاربر، محصول) و یالها (خریداری، لایک، مشاهده) ذخیره میکنید و کوئرییابی رابطهای فوقالعاده سریع و ساده میشود.
نمونه کوئری Cypher (زبان Neo4j) برای یافتن محصولات توصیهشده به کاربر مشخصی بر اساس خریدهای دوستانش:
MATCH (u:User {id: $userId})-[:FRIEND]->(friend:User)-[:BOUGHT]->(p:Product)
WHERE NOT (u)-[:BOUGHT]->(p)
RETURN DISTINCT p
LIMIT 10
var client = new GraphClient(new Uri("http://localhost:7474/db/data"), "neo4j", "password");
await client.ConnectAsync();
var query = client.Cypher
.Match("(u:User {id: $userId})-[:FRIEND]->(f:User)-[:BOUGHT]->(p:Product)")
.Where("NOT (u)-[:BOUGHT]->(p)")
.WithParam("userId", inputUserId)
.ReturnDistinct(p => p.As<Product>())
.Limit(10);
var recommendations = await query.ResultsAsync;
1 035
🔒 امنیت CI/CD: آشنایی با SAST (Static Application Security Testing) در لوله CI
در معماریهای مدرن DevOps، امنیت باید بخشی جداییناپذیر از چرخه توسعه باشد، نه تنها مرحلهای پس از اتمام کدنویسی. یکی از رویکردهای کلیدی برای شناسایی آسیبپذیریهای امنیتی در ابتدای فرآیند توسعه، SAST یا تست امنیتی ایستای برنامههاست.
SAST معمولاً به عنوان یک گام مستقل در لوله CI پیادهسازی میشود تا کد منبع را، بدون اجرای برنامه، برای الگوهای آسیبپذیری (مثل SQL Injection، XSS یا استفادهی ناایمن از توابع reflection) تحلیل کند. این تستها، معمولاً روی Pull Requestها یا commitهای جدید اجرا میشوند و در صورت کشف ضعفهای بحرانی، میتوانند به صورت خودکار build را fail کنند.
در داتنت، ابزارهایی مثل Microsoft Security Code Analysis، SonarQube یا Roslyn Analyzers بسیار محبوب هستند. فرض کنید قصد داریم SonarQube را به Azure Pipelines اضافه کنیم:
# azure-pipelines.yml
trigger:
- main
pool:
vmImage: 'windows-latest'
steps:
- task: UseDotNet@2
inputs:
packageType: 'sdk'
version: '7.x'
- script: dotnet build YourSolution.sln --configuration Release
- task: SonarQubePrepare@5
inputs:
SonarQube: 'SonarQubeServiceConnection'
scannerMode: 'MSBuild'
projectKey: 'YourProject'
projectName: 'YourProject'
- script: dotnet build YourSolution.sln
- task: SonarQubeAnalyze@5
- task: SonarQubePublish@5
inputs:
pollingTimeoutSec: '300'
1 035
انتقال از نقش Senior Developer به Tech Lead چیزی بیشتر از یادگیری تکنولوژیهای جدید یا تسلط روی معماری است؛ یک «تغییر نگرش بنیادی» نیاز دارد: از تکنوازی به هارمونی تیمی. اگر قبلاً موفقیت شخصی خود را با حل پیچیدهترین مسائل و نوشتن بهترین کد میسنجیدید، اکنون باید به موفقیت جمعی تیم فکر کنید.
🔸 Ownership تیمی را جایگزین ownership فردی کنید: به جای اینکه فقط به «کدی که خودتان مینویسید» افتخار کنید، باید فضا را طوری آماده کنید که همه اعضا رشد کنند و بتوانند بهترین خروجی خود را ارائه دهند—حتی اگر quality کد پایینی ببینید، مهم است که اول حمایت و راهنمایی کنید، نه آنی دخالت فنی!
🔸 تصمیمات تکنیکی را از «بهترین جواب» به «مناسبترین جواب» توسعه دهید؛ یعنی گاهی باید قید معماری ایدهآل را برای simplicity یا time-to-market بزنید. همیشه یادتان باشد بهترین راهحل آن چیزی است که کل تیم میتواند آن را بفهمد و نگهداری کند:
// به جای این رویکرد، که فقط خودتان میتوانید تست، refactor و debugش کنید:
public sealed class SingletonWithReflectionBlock
{
private static readonly SingletonWithReflectionBlock instance = new SingletonWithReflectionBlock();
private SingletonWithReflectionBlock() {}
public static SingletonWithReflectionBlock Instance => instance;
}
// چنین پیادهسازی سادهای برای تیم قابل لمستر است:
public class SimpleSingleton
{
private static SimpleSingleton _instance;
private SimpleSingleton() {}
public static SimpleSingleton Instance => _instance ??= new SimpleSingleton();
}
1 035
اگر روی پروژههای فولاستک مبتنی بر .NET و JavaScript/TypeScript کار میکنید (مثلاً Next.js یا ASP.NET Core + React)، مدیریت Monorepo چالشهای خاص خود را دارد: کشکردن بیلدها، وابستگیهای بینماژولها، اجرای تست موازی و یکپارچهسازی ابزارهای CI/CD. ابزارهایی مثل Nx یا Turborepo نقطهی تحول این فضا هستند و اینجا به چند قابلیت کلیدی اشاره میکنم که برای تیمهای حرفهای حیاتیاند:
1️⃣ اثربخشی کش هوشمند
این ابزارها بیلد و تست هر پکیج را کَش میکنند؛ یعنی اگر فقط منطق بکاند تغییر کرد، فرانتاند مجدد بیلـد نمیشود. نتیجه: صرفهجویی قابل توجه در زمان و منابع.
2️⃣ وابستگی متقابل ماژولها (Dependency Graph)
ایجاد گراف استاتیک بین لایههای پروژه — مثلاً وقتی DLL لایهی Domain تغییر کرد، فقط همان قسمتهایی که وابستهاند ریبیلد و ریتست میشوند. تصور کنید در معماری DDD چقدر این موضوع حیاتی میشود.
3️⃣ نمایش و اجرای تسکها به صورت موازی
فرض کنید ۱۰ میکروسرویس و ۵ وباپ فرانتاند دارید؛ Nx و Turborepo بهسادگی تست/بیلد همه را روی چند هسته اجرا میکنند:
// مثال: اجرای موازی تست پروژههای .NET
dotnet test MySolution.sln --parallel
1 035
الگوی Bulkhead: جداسازی شکستها بین سرویسها
اغلب در معماری میکروسرویس، شکست یک سرویس میتواند به سرعت روی کل سیستم تأثیر بگذارد. الگوی Bulkhead با الهام از کشتیها (محفظهبندی)، قسمتهای بحرانی سیستم را از هم جدا میکند. به این ترتیب، خرابی یک بخش نمیتواند منابع سایر بخشها را مصرف یا کل سیستم را فلج کند.
### پیادهسازی عملی Bulkhead در .NET
فرض کنید یک API داریم که به سه سرویس خارجی مجزا وابسته است و هرکدام پتانسیل تأخیر یا شکست دارند. Bulkhead را میتوان در سطح لایه ارتباطی پیادهسازی کرد تا هر سرویس سهمیه مجزای خودش از تردها/اتصالات را داشته باشد.
استفاده از Polly (کتابخانه open source resiliency در .NET) یک رویکرد ساده اما قدرتمند است:
using Polly;
using Polly.Bulkhead;
var service1Bulkhead = Policy.BulkheadAsync<HttpResponseMessage>(maxParallelization: 5, maxQueuingActions: 10);
var service2Bulkhead = Policy.BulkheadAsync<HttpResponseMessage>(3, 5);
var service3Bulkhead = Policy.BulkheadAsync<HttpResponseMessage>(2, 2);
// سرویس اول - تنها ۵ درخواست همزمان و تا ۱۰ درخواست صفشده مجاز است
async Task<HttpResponseMessage> CallService1Async(HttpRequestMessage req)
{
return await service1Bulkhead.ExecuteAsync(() => httpClient.SendAsync(req));
}
// سرویس دوم و سوم مشابه، با مقادیر bulkhead جداگانه
1 035
پیادهسازی Canary Deployment با Service Meshهایی مثل Istio یا Linkerd، به شما این امکان را میدهد که نسخه جدید سرویس را به درصد مشخصی از ترافیک هدایت کنید و رفتار واقعی کاربران را قبل از انتشار کامل بسنجید.
در Istio، این کار عموماً با تعریف دو آبجکت اصلی انجام میشود:
VirtualService و DestinationRule. فرض کنید دو نسخه از سرویس myservice دارید (v1 و v2) و میخواهید ۹۰٪ ترافیک روی v1 و ۱۰٪ روی v2 باشد. کافیست در YAML مربوط به Istio به شکل زیر رفتار کنید:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: myservice
spec:
hosts:
- myservice
http:
- route:
- destination:
host: myservice
subset: v1
weight: 90
- destination:
host: myservice
subset: v2
weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: myservice
spec:
host: myservice
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
name: myservice-split
spec:
service: myservice
backends:
- service: myservice-v1
weight: 90
- service: myservice-v2
weight: 10
1 035
پترن Outbox در معماری مایکروسرویسها راهکاری قدرتمند برای حل معضل ارسال پیامهای قابلاعتماد (reliable messaging) و جلوگیری از از دست رفتن رویدادهاست. تصور کنید سرویس A باید تراکنشی را در دیتابیس ذخیره و همزمان یک پیام (مثلاً رویداد domain یا نوتیفیکیشن) به صف یا پیامرسان (مثل Kafka, RabbitMQ) ارسال کند. اگر بین این دو، مشکلی در ارسال پیام رخ دهد (مثلاً بعد از commit تراکنش Database نتواند پیام را Publish کند)، وضعیت ناهماهنگی بین سرویسها ایجاد میشود (inconsistent state).
اینجا Outbox Pattern وارد میشود:
1️⃣ ذخیره atomic پیامها: بهجای ارسال مستقیم پیام، ابتدا محتوای پیام را همراه با تغییرات domain، به جدول Outbox در دیتابیس همان سرویس ذخیره میکنیم—در همان تراکنش دیتا.
2️⃣ پردازش Asynchronous Outbox: یک background worker (مثلاً HostedService در ASP.NET Core) بهصورت دورهای جدول Outbox را اسکن کرده، پیامهای جدید را Publish و پس از ارسال موفق، آنها را از جدول پاک یا آرشیو میکند.
مثال بسیار ساده از مدل Outbox در Entity Framework:
public class OutboxMessage
{
public Guid Id { get; set; }
public DateTime OccurredOn { get; set; }
public string Type { get; set; } // نوع رویداد/پیام
public string Content { get; set; } // JSON یا ...
public bool IsProcessed { get; set; }
}
// هنگام save دیتا:
using var tx = db.Database.BeginTransaction();
db.Orders.Add(order);
db.OutboxMessages.Add(new OutboxMessage {
Id = Guid.NewGuid(),
OccurredOn = DateTime.UtcNow,
Type = "OrderCreated",
Content = JsonConvert.SerializeObject(order),
IsProcessed = false
});
db.SaveChanges();
tx.Commit();
public class OutboxPublisher : BackgroundService
{
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
while (!stoppingToken.IsCancellationRequested)
{
var messages = await db.OutboxMessages
.Where(x => !x.IsProcessed)
.Take(100)
.ToListAsync();
foreach (var m in messages)
{
// ارسال به Message Broker
await messageBus.PublishAsync(m.Type, m.Content);
m.IsProcessed = true;
}
await db.SaveChangesAsync();
await Task.Delay(TimeSpan.FromSeconds(5));
}
}
}
1 035
یکی از سناریوهای پیشرفته و کاملاً موجه برای استفاده از unsafe code و pointerها در #CSharp، پردازش پرفورمنسمحور دادههای بلاکی (مثلاً تصاویر، سیگنال یا دادههای عددی حجیم) است. مثلا فرض کنید میخواهید ماتریسی بزرگ از اعداد اعشاری را طی یک حلقه با سرعت بسیار بالا پردازش کنید. استفاده از pointerها، باعث حذف پویایی (bounds checking) و افزایش کارایی میشود.
در مثال زیر، برای بهروزرسانی مقادیر در یک آرایه double، از pointer و keywordی به نام
fixed استفاده شده است تا آرایه، در حافظه جابجا نشود و بتوان روی آن pointer داد:
unsafe
{
double[] data = new double[1000000];
// مقادیر آرایه را مقداردهی کنید
fixed (double* ptr = data)
{
double* current = ptr;
for (int i = 0; i < data.Length; i++)
{
// پردازش سریع با استفاده از pointer
*current *= 1.1;
current++;
}
}
}
1 035
🗃️ #ADR — نمونه تصمیم معماری: انتخاب الگوی Dependency Injection
یکی از تصمیمات رایج معماری در پروژههای .NET انتخاب مکانیزم و چارچوب دیپندنسی اینجکشن است. در این ADR، یک سناریوی واقعی و فنی را مستند میکنیم:
---
عنوان: انتخاب Microsoft.Extensions.DependencyInjection به عنوان DI Container پیشفرض
زمینه:
در طول طراحی سامانه سرویسمحور (Microservices) مبتنی بر ASP.NET Core، نیازمند مکانیزمی کارآمد برای مدیریت وابستگیها و چرخهعمر آبجکتها بودیم. یکی از پیشنیازها: پشتیبانی از Lifetimes (Transient, Scoped, Singleton)، سازگاری با منابع reflection-based، و سادگی استفاده.
تصمیم:
استفاده از Microsoft.Extensions.DependencyInjection به عنوان DI Container پیشفرض پروژه.
گزینههای بررسیشده:
- Autofac
- SimpleInjector
- StructureMap
- Microsoft.Extensions.DependencyInjection
دلیل انتخاب:
- همگرایی با زیرساخت رسمی ASP.NET Core و تحویل out-of-the-box
- پشتیبانی بومی از Lifetimes مختلف و رفلکشن مینیمال
- اکستنشنپذیری بالا با رجیستری و فکتوریهای سفارشی
- سادگی تست و Mock کردن وابستگیها به کمک Microsoft.Extensions.DependencyInjection.Abstractions
نمونه کد رجیستری:
public void ConfigureServices(IServiceCollection services)
{
services.AddScoped<IOrderRepository, SqlOrderRepository>();
services.AddTransient<IPaymentGateway, StripePaymentGateway>();
services.AddSingleton<IClock, SystemClock>();
}
1 035
🔷 افزایش چشمگیر سرعت با SIMD و
Vector<T> در C#
در پردازش دادههای عددی، حتی حلقههای ساده هم میتوانند گلوگاه کارایی شوند. با استفاده از SIMD (Single Instruction, Multiple Data)، میتوانید چندین عملیات عددی را همزمان روی چند داده انجام دهید. در #NetCore و بعدتر، کلاس System.Numerics.Vector<T> این امکان را بهسادگی فراهم کرده است.
بیایید جمع دو آرایه بزرگ را با استفاده از SIMD مقایسه کنیم:
using System;
using System.Diagnostics;
using System.Numerics;
public class SimdDemo
{
public static void Main()
{
int N = 10_000_000;
float[] a = new float[N];
float[] b = new float[N];
float[] result1 = new float[N];
float[] result2 = new float[N];
// مقداردهی تصادفی
Random rnd = new Random();
for (int i = 0; i < N; i++)
{
a[i] = (float)rnd.NextDouble();
b[i] = (float)rnd.NextDouble();
}
// جمع ساده (اسکالر)
var sw = Stopwatch.StartNew();
for (int i = 0; i < N; i++)
result1[i] = a[i] + b[i];
sw.Stop();
Console.WriteLine($"جمع اسکالر: {sw.ElapsedMilliseconds} ms");
// جمع برداری با SIMD
int simdLength = Vector<float>.Count;
sw.Restart();
int iSimd = 0;
for (; iSimd <= N - simdLength; iSimd += simdLength)
{
var va = new Vector<float>(a, iSimd);
var vb = new Vector<float>(b, iSimd);
(va + vb).CopyTo(result2, iSimd);
}
// باقیماندهها
for (; iSimd < N; iSimd++)
result2[iSimd] = a[iSimd] + b[iSimd];
sw.Stop();
Console.WriteLine($"جمع SIMD: {sw.ElapsedMilliseconds} ms");
}
}
Vector<T> نه تنها برای افزایش سرعت، بلکه برای بالا بردن کیفیت کد و استفاده کامل از سختافزار مدرن لذت ببرید!
#ExpertCSharp #SIMD #Vector #PerformanceTuning
@DeveloperAdvocate 🥑1 035
👃🏻 Code Smell: Long Method
متدهای طولانی (Long Method) یکی از رایجترین نشانههای code smell هستند. وقتی یک متد مسئولیتهای زیادی دارد خوانایی، نگهداری و قابلیت تست آن کاهش پیدا میکند.
نمونهی مشکلدار:
public void ProcessOrder(Order order)
{
// Validate order
if (order == null || order.Items.Count == 0)
throw new ArgumentException("Invalid order");
// Calculate total
decimal total = 0;
foreach (var item in order.Items)
{
total += item.Quantity * item.Price;
if (item.Quantity > 100)
total -= 10; // Promotion
}
// Save to database
using (var db = new OrderContext())
{
db.Orders.Add(order);
db.SaveChanges();
}
// Send confirmation email
var smtp = new SmtpClient("mail")
{
Credentials = new NetworkCredential("user", "pass")
};
smtp.Send(new MailMessage("shop@example.com", order.CustomerEmail, "Your order", "Thanks!"));
}
public void ProcessOrder(Order order)
{
ValidateOrder(order);
CalculateTotal(order);
SaveOrder(order);
SendConfirmationEmail(order);
}
private void ValidateOrder(Order order)
{
if (order == null || order.Items.Count == 0)
throw new ArgumentException("Invalid order");
}
private void CalculateTotal(Order order)
{
decimal total = 0;
foreach (var item in order.Items)
{
total += item.Quantity * item.Price;
if (item.Quantity > 100)
total -= 10; // Promotion
}
order.Total = total;
}
private void SaveOrder(Order order)
{
using var db = new OrderContext();
db.Orders.Add(order);
db.SaveChanges();
}
private void SendConfirmationEmail(Order order)
{
using var smtp = new SmtpClient("mail")
{
Credentials = new NetworkCredential("user", "pass")
};
smtp.Send(new MailMessage("shop@example.com", order.CustomerEmail, "Your order", "Thanks!"));
}
1 035
ردگیری توزیعشده (Distributed Tracing) با OpenTelemetry در سناریوهای چندسرویسی، امکان مشاهدهی کامل درخواست از ابتدای ورود تا سرویس آخر را فراهم میکند. بیایید نحوه پیادهسازی و دیدن این ردگیری را در یک معماری .NET چندسرویسی مرور کنیم.
فرض کنید دو سرویس داریم: ServiceA و ServiceB، که ServiceA برای پردازش، به ServiceB فراخوانی HTTP میزند. هر دو سرویس باید به OpenTelemetry تجهیز شوند.
✅ وابستگیها (مثال برای سرویس A):
// برنامه .NET 7 یا 8
dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Instrumentation.AspNetCore
dotnet add package OpenTelemetry.Instrumentation.Http
dotnet add package OpenTelemetry.Exporter.Jaeger
using OpenTelemetry;
using OpenTelemetry.Trace;
builder.Services.AddOpenTelemetry()
.WithTracing(tracerProviderBuilder =>
{
tracerProviderBuilder
.AddAspNetCoreInstrumentation()
.AddHttpClientInstrumentation()
.AddJaegerExporter(jaeger =>
{
jaeger.AgentHost = "localhost";
jaeger.AgentPort = 6831;
});
});
AddAspNetCoreInstrumentation: ردگیری کل درخواستهای ورودی.
- AddHttpClientInstrumentation: ردگیری تمام فراخوانیهای خروجی HTTP (از جمله ارتباط ServiceA به ServiceB).
- AddJaegerExporter: ارسال دادهها به Jaeger.
✅ نمونه کد فراخوانی سرویس در ServiceA:
using System.Net.Http;
[ApiController]
[Route("[controller]")]
public class TestController : ControllerBase
{
private readonly IHttpClientFactory _clientFactory;
public TestController(IHttpClientFactory clientFactory)
{
_clientFactory = clientFactory;
}
[HttpGet]
public async Task<IActionResult> Get()
{
var client = _clientFactory.CreateClient();
var response = await client.GetAsync("http://service-b/api/process");
var content = await response.Content.ReadAsStringAsync();
return Ok(content);
}
}
docker run -d --name jaeger \
-e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
-p 6831:6831/udp \
-p 16686:16686 \
jaegertracing/all-in-one:latest
using var span = tracer.StartActiveSpan("CustomBlock");
