محمد حسین کرمی محمد حسین کرمی
مطالب
افزایش سرعت کد نویسی با Resharper - قسمت 01 - معرفی و نصب
در این سری قصد آموزش افزونه‌ی Resharper برای Visual studio را دارم که توسط شرکت Jetbrains برای بهبود امکانات Visual Studio و افزایش سرعت کد نویسی، نوشته شده‌است.

این نرم افزار را از لینک زیر می‌توانید دانلود کنید:

لینک مرجع آموزشی آن هم در زیر در دسترس می‌باشد:
info 
نصب نرم افزار
نصب این افزونه، یکی از راحت‌ترین قسمت‌ها می‌باشد. فقط کافی است از لینک داده شده نرم افزار را دانلود کنید تا پس از اجرا، با صفحه‌ی زیر روبرو شوید:

در این قسمت می‌توانید هر کدام از موارد را که نیاز دارید، نصب کنید. هر کدام از عنوان‌ها در آینده آموزش داده خواهند شد و پیشنهاد می‌شود آن‌ها را نصب کنید؛ در غیر این صورت فقط گزینه‌ی اول کافی می‌باشد.

در صورت کلیک بر روی Options، با صفحه‌ی زیر روبرو می‌شوید که در آن با انتخاب گزینه‌ی Administrative، می‌توانید تنظیمات بیشتری را در زمان نصب، انجام دهید و همچنین با انتخاب All users ، نرم افزار برای تمام کاربران سیستم در دسترس خواهد بود.

 بعد از اتمام نصب، فایل‌های نرم افزار در آدرس زیر در دسترس می‌باشند: 

%LOCALAPPDATA%\JetBrains\Installations

اکنون اگر Visual studio را باز کنید، Resharper به قسمت Extensions‌‌ها اضافه شده‌است که در ادامه‌ی آموزش به بررسی آن می‌پردازیم.


زبان‌های پشتیبانی شده

ریشارپر از زبان های C# , VB.NET , TypeScript , JavaScript , C++ , CSS پشتیبانی می‌کند.


افزایش سرعت Reshaper

یکی از مشکلاتی که بیشتر افراد بعد از نصب این افزونه دارند، مخصوصا اگر سیستم آن‌ها خیلی قوی نباشد، کند شدن Visual Studio می‌باشد. برای سریعتر کردن این افزونه راه هایی موجود می‌باشد که به آن‌ها می‌پردازیم.


  • خود ریشارپر پیشنهادهایی را برای بهبود سرعت می‌کند که آن‌ها در مسیر زیر در دسترس می‌باشند:
ReSharper | Options | Environment | Performance Guide
  • یکی از امکانات ریشارپر، نشان دادن تمام خطاهای موجود در برنامه به صورت یک لیست می‌باشد که نام این ویژگی، solution-wide analysis است و البته این امکان باعث سنگینی زیاد Visual studio می‌شود. برای غیر فعال کردن آن می‌توانید به مسیر زیر بروید:
ReSharper | Options | Code Inspection | Settings
  • راه دیگر انجام اینکار از قسمت تنظیمات خود Visual studio است. برای این کار به مسیر زیر بروید و گزینه‌های گفته شده را غیر فعال کنید.
Environment | General
Automatically adjust visual experience based on client performance
Enable rich client visual experience
  • همچنین این گزینه را نیز فعال کنید تا جلوی لگ در UI گرفته شود.
Use hardware graphics acceleration if available
  • اگر پروژه‌ی بزرگی را دارید، می‌توانید گزینه‌ی زیر را نیز غیر فعال کنید. البته با غیر فعال کردن این گزینه در صورت کرش نرم افزار، کدهای ذخیره نشده ازدست می‌روند.
Environment | AutoRecover
Save AutoRecover information
  • اگر با تعداد فایل‌های زیادی کار می‌کنید، امکان Track changes باعث کندی برنامه می‌شود. برای غیر فعال کردن این گزینه، به مسیر زیر بروید. 
Text Editor | General
Track changes
  • خود Visual studio گزینه‌هایی را مانند خطا‌ها در Scroll Bar نشان می‌دهد که این امکانات در ریشارپر هم موجود می‌باشد. برای غیر فعال کردن این امکان در Visual Studio برای جلوگیری از دو بار نشان دادن اطلاعات، به مسیر زیر بروید و گزینه‌ی گفته شده را غیر فعال کنید.
Text Editor | All Languages | Scroll Bars
Show annotations over vertical scroll bar
  • یکی دیگر از امکانات Visual Studio گزینه‌ای به اسم CodeLens می باشد که یکی از کارهای آن، نشان دادن تمام رفرنس‌های توابع یک فایل، در بالای تابع می‌باشد. این امکان نیز باعث کندی بسیار زیاد برنامه می‌شود. برای غیر فعال کردن آن می‌توانید به مسیر زیر بروید. 
Text Editor | All Languages | CodeLens
  • هم Visual Studio و هم Reshaper کدهای شما را Format می‌کنند. پس برای جلوگیری از دوبار انجام شدن این کار، به مسیر زیر بروید و گزینه‌ی گفته شده را غیر فعال کنید.
Text Editor | [Language] | Formatting
auto-formatting
  • اگر از تمام امکانات Reshaper نمی‌خواهید استفاده کنید، می‌توانید آن‌ها را از آدرس زیر غیر فعال کنید.
Environment | Products & Features
  • اگر در زمان تایپ کردن، برنامه کند می‌باشد، می‌توانید بعضی از امکانات Resharper را از آدرس زیر غیر فعال کنید.
Environment | IntelliSense
Completion Appearance
ReSharper's IntelliSense for specific languages

در قسمت‌های بعد به معرفی امکانات Reshaper می‌پردازیم.
‫۴ سال و ۵ ماه قبل، پنجشنبه ۲۸ فروردین ۱۳۹۹، ساعت ۰۵:۳۵
یاسر مرادی یاسر مرادی
نظرات مطالب
توسعه برنامه های Cross Platform با Xamarin Forms & Bit Framework - قسمت سوم
زمانی که شما قصد دارید نسخه UWP را به مشتری تحویل دهید، در قسمت تنظیمات UWP، این که Min Version را روی 16299 و Target Version را روی بالاترین عدد ممکن (17763 در لحظه نگارش این نظر) بگذارید، حرکت درستی است. ولی اگر از UWP فقط برای توسعه راحت‌تر نرم افزار استفاده می‌کنید، Min & Target را روی برابر با Build Number ویندوز خود بگذارید. برای مثال اگر ویندوز شما 17134 است، هر دو را روی 17134 بگذارید. (لینک مشاهده نحوه تغییر که ممکن است برای دیدن عکس‌های آن نیاز به ابزارهای دور زدن تحریم داشته باشید)

همچنین در صورتی که در استفاده از Xamarin Live Reload یا Xaml Live دچار مشکل شدید، خاموش کردن Firewall و از نو اجرا کردن Visual Studio و تست مجدد نیز ایده خوبی است.
‫۵ سال و ۸ ماه قبل، دوشنبه ۱ بهمن ۱۳۹۷، ساعت ۱۶:۳۳
علی یگانه مقدم علی یگانه مقدم
مطالب
آشنایی با CLR: قسمت بیست و دوم
در ادامه قسمت قبلی، به خصوصیات و ویژگی‌های اسمبلی قوی می‌پردازیم:

اسمبلی‌های نام قوی در برابر دستکاری مقاوم هستند
از آنجائیکه محتویات اسمبلی، هش شده و مقدار هش آن امضا می‌شود، در نتیجه اگر شخصی به دستکاری اسمبلی اقدام کرده باشد یا اینکه فایل مد نظر آسیب دیده باشد، به راحتی قابل شناسایی است و آن اسمبلی به عنوان اسمبلی صحیح شناسایی نخواهد شد و نمی‌گذارد در GAC ثبت شود.

موقعیکه برنامه نیاز داشته باشد به اسمبلی نام قوی بایند یا متصل شود، از 4 ویژگی گفته شده‌ی در قسمت قبلی استفاده می‌کند تا آن را در GAC بیابد. اگر اسمبلی درخواستی موجود باشد، زیر دایرکتوری آن برگشت داده خواهد شد؛ ولی اگر آن را نیابد، ابتدا در داخل دایرکتوری برنامه و سپس در مسیرهایی که در فایل پیکربندی ذکر شده‌اند، به دنبال آن خواهد گشت و در نهایت اگر برنامه توسط فایل MSI نصب شده باشد، محل‌های توزیع را از طریق آن جویا خواهد شد و اگر باز به نتیجه‌ای نرسد، اتصال ناموفق گزارش شده و خطای زیر را ایجاد خواهد کرد:
System.IO.FileNotFoundException
هر بار که برنامه اسمبلی را از غیر از مسیر GAC بخواند، ابتدا هش آن اعتبارسنجی می‌شود و اگر هش آن غیرقابل شناسایی باشد، خطای زیر را صادر می‌کند:
System.IO.FileLoadExceptio
یک اسمبلی با نام قوی مزایای زیر را به همراه دارد:
  1. جلوگیری از دستکاری و حفظ امنیت آن
  2. این اسمبلی تنها یکبار از حافظه‌ی فیزیکی استفاده میکند؛ برعکس توزیع خصوصی که برای هر برنامه باید یک فضای دیسکی داشته باشد.
  3. توزیع ساده‌تر برای نسخه‌های آینده فراهم می‌شود که بعدا در مورد آن توضیح می‌دهیم.
با این حال GAC، یک سیستم امنیتی است که تنها باید توسط مدیر سیستم کنترل شود و هم اینکه توزیع آن‌ها به راحتی توزیع اسمبلی‌های خصوصی نیست. توصیه می‌شود که از اسمبلی‌های نام قوی، زمانی در GAC استفاده کنید که نیاز است توسط چندین برنامه به طور مشترک استفاده شود؛ در غیر این صورت از همان شیوه‌ی توزیع خصوصی استفاده شود. چون در این حالت هم بهترین حالت ایزوله بودن مهیاست، هم نصب آن ساده‌تر است و از آنجا که محل GAC در شاخه system32 است مرتبا از فضای دیسک آن ناحیه کم می‌شود.

سیاست‌های انتخاب اسمبلی توسط GAC
موقعی که GAC می‌خواهد یک اسمبلی را برای برنامه شما بازگرداند، از روی خصوصیاتی چون نام اسمبلی، ورژن، فرهنگ، توکن کلید عمومی و در نهایت بسته به معماری ماشین، یک اسمبلی را برمی‌گرداند. در صورتیکه اسمبلی خاصی را برای ماشین مورد نظر پیدا نکند، از اسمبلی یک ماشین دیگر استفاده خواهد کرد. در واقع این انتخاب، یک سیاست پیش فرض است که می‌تواند از طریق ناشر یا مدیر سیستم تغییر پیدا کند و رونویسی شود.
 

کنترل مدیریت پیشرفته (پیکربندی)
در قسمت بیستم با ساخت فایل پیکریندی و نحوه تنظیم کردن اسکن اسمبلی‌ها در CLR آشنا شدیم. این بار قصد داریم در مورد المان‌های دیگر این فایل پیکریندی صحبت کنیم. فایل پیکربندی زیر را بررسی می‌کنیم:
 
<?xml version="1.0"?>
  <configuration>
     <runtime>
        <assemblyBinding xmlns="urn:schemas­microsoft­com:asm.v1">
           <probing privatePath="AuxFiles;bin\subdir" />
             <dependentAssembly>
                <assemblyIdentity name="SomeClassLibrary"  publicKeyToken="32ab4ba45e0a69a1" culture="neutral"/>
                <bindingRedirect  oldVersion="1.0.0.0" newVersion="2.0.0.0" />
                <codeBase version="2.0.0.0"  href="http://www.Wintellect.com/SomeClassLibrary.dll" />
             </dependentAssembly>
             <dependentAssembly>
                <assemblyIdentity name="TypeLib"  publicKeyToken="1f2e74e897abbcfe" culture="neutral"/>
                <bindingRedirect   oldVersion="3.0.0.0­3.5.0.0" newVersion="4.0.0.0" />
                <publisherPolicy apply="no" />
             </dependentAssembly> 
         </assemblyBinding>
     </runtime> 
 </configuration>
 Probing  در قسمت بیستم گفتیم که در این المان، مکان‌هایی را که CLR برای پیدا کردن اسمبلی‌های با نام ضعیف، باید اسکن کند، وارد می‌کنیم که هر مسیر با , از هم جدا شده‌است. برای اسمبلی‌های با نام قوی CLR باید داخل GAC را نگاه کند و در URL هایی که از طریق المان CodeBase مشخص کرده‌ایم. اگر المان CodeBase مشخص نشود، CLR برای پیدا کردن اسمبلی‌های با نام قوی، داخل دایرکتوری‌های این المان را اسکن خواهد کرد.
 Dependent Assembly اول
 		 در اولین فرزند این المان، Assembly Identity یک اسمبلی با مشخصاتی مثل Culture و توکن عمومی معرفی می‌شود و در BindingRedirect به CLR اطلاع می‌دهد موقعی که به دنبال نسخه یک این اسمبلی است، نسخه‌ی دو آن را برای استفاده جایگزین کند.
 Code Base
 		 این المان می‌گوید که وقتی CLR سعی در پیدا کردن نسخه‌ی 2 اسمبلی را دارد، آن را از طریق آدرس مورد نظر پیدا کند. این المان میتواند برای اسمبلی‌های با نام ضعیف هم کار کند.
  Dependent Assembly دوم  این مورد هم همانند سابق است با این تفاوت که گستره‌ی نسخه 3 تا 3.5 را به نسخه‌ی 4 تغییر میدهد.
Publisher Policy
 		اگر سازمان تولید کننده این اسمبلی فایلی برای تعیین Policy به همراه اسمبلی ارائه کرده باشد، این المان باعث می‌شود این فایل ندیده گرفته شود (در مورد فایل Policy در آینده صحبت می‌کنیم).
اکنون هر موقع CLR ارجاعی از جدول AssemblyDef را برای بارگذاری یک اسمبلی دریافت کند، ابتدا فایل پیکربندی را بررسی میکند و بر اساس آن اسمبلی مورد نظر را بارگذاری خواهد کرد. در این لحظه اسمبلی مورد نظر در GAC وجود دارد و آن را بار می‌کند؛ یا اگر یافت نشد المان CodeBase را بررسی میکند و اگر این المان تعریف نشده باشد، در ادامه سیاست‌های قبلی، پوشه کاری برنامه و دایرکتوری‌های private را اسکن میکند.

با وجود این حالت اگر فرض کنیم مدیر یک سیستم متوجه شود که اسمبلی برنامه دچار مشکل شده است و با ناشر تماس بگیرد و ناشر نسخه‌ی جدیدی از آن اسمبلی را در اختیار او بگذارد، مدیر سیستم می‌تواند به راحتی از طریق فایل پیکربندی، CLR را به استفاده‌ی از اسمبلی جدید به جای اسمبلی قدیمی هدایت کند.

نکته : اگر مدیر بخواهد تمام برنامه‌های موجود از این اسمبلی جدید استفاده کنند باید فایل machine.config را ویرایش کند.

‫۸ سال و ۵ ماه قبل، شنبه ۲۵ اردیبهشت ۱۳۹۵، ساعت ۰۶:۳۵
محمد پهلوان محمد پهلوان
مطالب
معماری پایگاه داده چند مستاجری (Multi-Tenant Data Architecture)
 اعتماد و یا فقدان آن، عامل شماره یک مسدود کردن استفاده از نرم افزار به عنوان خدمات است. معماری پایگاه داده چند مستاجری برای رسیدگی به مشکل نرم افزار به عنوان سرویس (SaaS) که می‌تواند خدمات به تعدادی کلاینت ارائه کند استفاده می‌شود . معماری دیتابیس چند مستاجری وقتی مفید است که یک نمونه از دیتابیس به تعدادی کلاینت خدمات دهد. وقتی که نرم افزار‌های محلی نصب می‌کنید نرم افزارهای به عنوان یک سرویس با مشتریان متمرکز، دسترسی به داده‌ها مبتنی بر شبکه با سربار کمتر را فراهم می‌کنند. اما به منظور برخورداری بیشتر از مزیت‌های یک نرم افزار سرویس، یک سازمان باید از سطحی از کنترل روی داده صرفنظر کند و به فروشنده نرم افزار جهت نگهداری و امنیت به دور از چشم آنها اعتماد کند.

برای به درست آوردن این اعتماد، یکی از بالاترین الویت ها، آینده نگری معماری نرم افزار و ساخت یک معماری داده است که باید هر دو قوی و به اندازه کافی ایمن باشد، این دو برای راضی کردن مستاجران و کلاینت هایی که علاقمند هستند کنترل داده‌های حیاتی تجارت خود را به شخص سومی واگذار نمایند،  موثر است  در حالی که برای اداره کردن و نگهداری مقرون به صرفه است. 

  سه روش مدیریت چند مستاجری داده
  1. دیتابیس‌های جداگانه برای هر مستاجر
  2. دیتابیس مشترک و schema جداگانه برای هر مستاجر
  3. دیتابیس مشترک و schema مشترک 

  انتخاب روش مناسب برای برنامه شما به عوامل زیر بستگی دارد :
  • سایز دیتابیس هر مستاجر
  • تعداد مستاجران
  • تعداد کاربران هر مستاجر
  • نرخ رشد مستاجر
  • نرخ رشد دیتابیس مستاجر
  • امنیت  
  • هزینه

1) دیتابیس‌های جداگانه برای هر مستاجر :
ذخیره سازی داده‌های مستاجران در دیتابیس‌های جداگانه ساده‌ترین روش است. در این روش هر مستاجر یک دیتابیس دارد. منابع و کدهای برنامه معمولا در سرور بین همه مستاجران مشترک است اما هر مستاجر مجموعه ای از داده دارد که بطور منطقی از سایر مستاجران جدا شده است.

  مزایا :
  • امنیت بیشتر
  • سهولت سفارشی سازی برای هر مستاجر
  • سهولت نگهداری ( Backup و Restore ) برای هر مستاجر

معایب:
  • برای نگهداری سخت افزار قوی مورد نیاز است
  • این روش هزینه بیشتری برای تجهیزات ( Backup و Restore ) برای هر مستاجر دارد

  2)   دیتابیس مشترک و schema جداگانه برای هر مستاجر :
خدمات دهی به چندین مستاجر در یک دیتابیس مشترک اما هر مستاجر یک مجموعه از جداول گروهبندی شده دارد که با Schema جدا شده است که برای هر مستاجر الزامی است.

مزایا :
  • برای دیتابیس برنامه‌های کوچک مناسب است. وقتی تعداد جداول برای هر مشتری کم است
  • هزینه کمتری نسبت به روش اول دارد
  • برای مشتریانی که نگران امنیت هستند، سطح منطقی مناسبی برای جداسازی داده ه وجود دارد

معایب:
  • اطلاعات مستاجران در صورت بروز خطا به سختی restore می‌شود
  • مدیریت آن برای دیتابیس‌های بزرگ مشکل است

  3)   دیتابیس مشترک و schema مشترک :

این روش شمامل یک دیتابیس و یک مجموعه از جداول برای چندین مستاجر است. داده‌های جدول می‌تواند شامل رکورد‌های هر مستاجر باشد

مزایا :
  • در مقایسه با روش قبلی، کمترین هزینه سخت افزاری را دارد
  • می‌تواند مستاجران بیشتری رادر هر سرور پشتیبانی کند
  • قابلیت بروز رسانی آسان در یک جا برای همه مستاجران
  • مدیریت آسان دیتابیس و خطا و Backup و Restore
معایب:
  • امنیت بیشتری مورد نیاز است تا مطمئن شوید هیچکس به اطلاعات سایر مستاجران دسترسی ندارد.
  • می‌تواند روی کارایی کوئری‌ها تاثیر بگذارد چون تعداد رکورد‌ها زیاد است.
  • بروزرسانی و سفارشی کردن فقط برای یک مستاجر سخت است
 
منابع :
http://msdn.microsoft.com/en-us/library/aa479086.aspx
http://www.codeproject.com/Articles/51334/Multi-Tenants-Database-Architecture   
‫۱۰ سال و ۱۱ ماه قبل، دوشنبه ۱۱ آذر ۱۳۹۲، ساعت ۱۳:۱۰
مهمان مهمان
نظرات مطالب
YVD
این نرم افزار رو تست کردم.همانطور که گفتم عالی بود.

تجربه من در استفاده از این نرم افزار در هنگامی که به اینترنت متصل نبودم:

آدرس پیش فرض رو آخرش رو مقداری تغییر دادم تا بتونم چند مورد رو در صف داشته باشم.گرچه عملیات دانلود انجام نمیشه.این کار رو فقط برای دیدن ظاهر برنامه انجام دادم.در این حین متوجه شدم در هنگامی که چند مورد اضافه میشه وقتی میخوام اونا رو Remove کنم در بعضی موارد برنامه با اشکال مواجه میشه و عملیات Remove رو انجام نمدیده (در مورد مواردی که اصلا Url نیستند.برای مثال چند حرف رو به جای Url به برنامه داده بودم !!!).گاهی اوقات هم پس از چندین بار سعی در Remove کردن نهایتا این کار رو انجام میده!!!

بعلاوه فکر می کنم اگه عبارت Download Queue در وسط نمایش داده بشه برنامه زیباتر به نظر میرسه.
‫۱۴ سال و ۸ ماه قبل، شنبه ۱۴ فروردین ۱۳۸۹، ساعت ۱۲:۱۸
رضابیات رضابیات
نظرات مطالب
اطلاع از بروز رسانی نرم افزار ساخته شده
با تشکر از توجه و راهنمایی شما. نرم افزارهای زیادی برای این کار وجود داره ولی من خیلی وقته از Snagit و Snagit Editor استفاده میکنم. این نرم افزار بیشتر برای فیلم و عکس گرفتن از دسکتاب استفاده میشه ولی امکانات فراوانی دیگری هم در این نرم افزار وجود داره. من خودم نسخه Snagit 11.2.1 را از سایت http://www.softgozar.com  دانلود کردم.
‫۱۱ سال و ۳ ماه قبل، پنجشنبه ۱۷ مرداد ۱۳۹۲، ساعت ۰۵:۰۴
محمد اسماعیل آزاد محمد اسماعیل آزاد
مطالب
مایکرو سرویس‌ها - قسمت 1 - معرفی
در نرم افزار‌های Enterprise، توسعه محصول، چالش اصلی تیم نمی‌باشد. اصلی‌ترین چالش، بعد از استقرار نرم افزار و زیر بار رفتن آن به‌وجود می‌آید؛ مسائلی نظیر مدیریت تغییرات و scaling و چنانچه نرم افزار بصورت صحیحی توسعه نیافته باشد، می‌توان گفت که انجام موارد ذکر شده بسیار سخت یا شاید غیر ممکن شوند و باید نرم افزار، بازنویسی شود.
برای روشن شدن موضوع یک مثال میزنم.
فرض کنید یک نرم افزار جامع بیمه (Core Insurance) داریم که بصورت یک نرم افزار یکپارچه (Monolithic) ارائه شده است. بعد از چند سال قرار است در زیر سیستم‌های مختلف تغییراتی انجام شود؛ مثلا زیر سیستم‌های بیمه عمر، بیمه مسافرتی و بیمه درمان، نیاز به تغییر دارند. فرض کنید تغییرات در بیمه درمان سریعتر انجام شده و آماده استفاده برای مشتری می‌باشد؛ اما به دلیل یکپارچه بودن سیستم، این انتشار نسخه باید تا اتمام کار زیر سیستم‌های دیگر، به تعویق بیفتد. یا اینکه به دلیل بالا رفتن تعداد کاربران می‌خواهیم سیستم را  scale out کنیم. برای این منظور باید چند نسخه از کل سیستم را در پروسه‌های مجزایی قرار دهیم.
با توجه به توضیحات بالا متوجه این منظور میشویم که مدیریت تغییرات، بخاطر وابستگی‌های بیش از حد سیستم، با کندی روبه رو می‌شود و همچنین هزینه Scale سیستم با توجه به اینکه باید کل سیستم را  در پروسه‌های مختلفی نصب کرد، بالا می‌باشد.
اگر این سیستم یکپارچه به زیر سیستم‌های مجزایی شکسته می‌شد، هزینه تغییرات و Scale آن به مراتب کمتر می‌شد. حتی از این جلوتر بریم و هر کدام از این زیر سیستم‌ها قابلیت‌های کسب و کار (Business Capabilities) خودشان را به‌صورت سرویس‌های مجزایی ارائه دهند، هزینه تغییرات و نگهداری آن‌ها چگونه خواهد بود؟!
برای مثال اگر زیر سیستم بیمه عمر را تصور و آن‌را به سه قسمت درخواست بیمه نامه ، صدور بیمه نامه و بخش خسارت تقسیم کنیم که هر کدام از این قسمت‌ها به تنهایی قابل ارائه به مشتری باشند.
برای مثال درخواست بیمه نامه شامل پر کردن فرم پیشنهاد، بررسی اطلاعات وارد شده توسط پزشکان بیمه و اعلام نظر کار شناسان بیمه برای افزایش نرخ بیمه نامه بر اساس ریسک‌های پزشکی و شغلی بیمه شده می‌باشد که در نهایت بعد از چند روز، یک فرم پیشنهاد به تایید کارشناسا ن رسیده و تازه به بیمه نامه تبدیل می‌شود. همانطور که می‌بینید این بخش به تنهایی می‌تواند در اختیار نمایندگی‌های شرکت بیمه قرار گرفته و قسمت اولیه فروش بیمه نامه را پشتیبانی کند. حالا اگر نیاز به تغییرات یا scaling سیستم وجود داشته باشد، انجام دادن آن‌ها به مراتب راحت‌تر و کم هزینه‌تر می‌باشد.

مایکرو سرویس چیست ؟

در یک تعریف کوتاه، در معماری مایکرو سرویس، توسعه یک نرم افزار به‌صورت مجموعه‌ای از سرویسهای کوچک می‌باشد که این سرویسها به‌صورت کاملا مستقلی قابلیت استقرار دارند و هر کدام از این سرویسها می‌توانند توسط تیم‌های جداگانه‌ای با پلتفرم توسعه و زبان برنامه نویسی و بانک اطلاعاتی جداگانه‌ای توسعه داده شوند  و با یک مکانیزم سبک  وزن مانند Http با یکدیگر در ارتباط باشند.

این روش پیاده سازی قابلیت مقیاس پذیری و تست پذیری را بالا میبرد و توسعه و نگهداری سیستم را آسان می‌کند. دلیل آن هم کاملا مشخص است؛ هر سرویس یک وظیفه مشخص دارد و تیم توسعه‌ی آن کاملا بر آن مسلط می‌باشد و با توجه به اینکه این سرویسها خیلی بزرگ نیستند، تغییرات و تست و نگهداری آن آسان میشود .

چرا معماری مایکرو سرویس؟

مایکرو سرویس‌ها به شما قابلیت چابکی بیشتری می‌دهند و شما را قادر میسازند تا به‌صورت بهتری بتوانید یک سیستم بزرگ، پیچیده و در مقیاس بزرگ را نگهداری کنید.
این سرویس‌ها به تنهایی قابلیت scaling دارند و برخلاف یک سیستم یکپارچه که برای scaling باید تمام سیستم را به عنوان یک واحد scale out کرد، در مایکرو سرویس‌ها شما می‌توانید سرویس‌هایی را که بیشتر مورد استفاده قرار می‌گیرند، بصورت کاملا مستقلی scale out کنید و به این صورت چابکی شما در مواجه با تغییرات که از خصوصیات اصلی یک سیستم نرم افزاری می‌باشد، بالا می‌رود. 
با توجه به توضیحات بالا تصویر زیر گویای همه‌ی این موارد هست:

مقایسه سیستم یکپارچه با مایکروسرویسدر مطالب بعدی در موردی مشخصه‌های مایکرو سرویس‌ها صحبت خواهیم کرد.

‫۷ سال و ۴ ماه قبل، شنبه ۲۷ خرداد ۱۳۹۶، ساعت ۱۷:۴۵
وحید نصیری وحید نصیری
مطالب
NoSQL و مایکروسافت
روشی را که مایکروسافت برای پرداختن به مقوله NoSQL تاکنون انتخاب کرده است، قرار دادن ویژگی‌هایی خاصی از دنیای NoSQL مانند امکان تعریف اسکیمای متغیر، داخل مهم‌ترین بانک اطلاعاتی رابطه‌ای آن، یعنی SQL Server است، که در ادامه به آن خواهیم پرداخت. همچنین در سمت محصولات پردازش ابری آن نیز امکان دسترسی به محصولات NoSQL کاملی وجود دارد.

1) Azure table storage
Azure table storage در حقیقت یک Key-value store ابری است و برای کار با آن از اینترفیس پروتکل استاندارد OData استفاده می‌شود. علت استفاده و طراحی یک سیستم Key-value store در اینجا، مناسب بودن اینگونه سیستم‌ها جهت مقاصد عمومی است و به این ترتیب می‌توان به بازه بیشتری از مصرف کنندگان، خدمات ارائه داد.
پیش از ارائه Azure table storage، مایکروسافت سرویس خاصی را به نام SQL Server Data Services که به آن SQL Azure نیز گفته می‌شود، معرفی کرد. این سرویس نیز یک Key-Value store است؛ هرچند از SQL Server به عنوان مخزن نگهداری اطلاعات آن استفاده می‌کند.


2) SQL Azure XML Columns
فیلدهای XML از سال 2005 به امکانات توکار SQL Server اضافه شدند و این نوع فیلدها، بسیاری از مزایای دنیای NoSQL را درون SQL Server رابطه‌ای مهیا می‌سازند. برای مثال با تعریف یک فیلد به صورت XML، می‌توان از هر ردیف به ردیفی دیگر، اطلاعات متفاوتی را ذخیره کرد؛ به این ترتیب امکان کار با یک فیلد که می‌تواند اطلاعات یک شیء را قبول کند و در حقیقت امکان تعریف اسکیمای پویا و متغیر را در کنار امکانات یک بانک اطلاعاتی رابطه‌ای که از اسکیمای ثابت پشتیبانی می‌کند، میسر می‌شود. در این حالت در هر ردیف می‌توان تعدادی ستون ثابت را با یک ستون XML با اسکیمای کاملا پویا ترکیب کرد.
همچنین SQL Server در این حالت قابلیتی را ارائه می‌دهد که در بسیاری از بانک‌های اطلاعاتی NoSQL میسر نیست. در اینجا در صورت نیاز و لزوم می‌توان اسکیمای کاملا مشخصی را به یک فیلد XML نیز انتساب داد؛ هر چند این مورد اختیاری است و می‌توان یک un typed XML را نیز بکار برد. به علاوه امکانات کوئری گرفتن توکار از این اطلاعات را به کمک XPath ترکیب شده با T-SQL، نیز فراموش نکنید.
بنابراین اگر یکی از اهداف اصلی گرایش شما به سمت دنیای NoSQL، استفاده از امکان تعریف اطلاعاتی با اسکیمای متغیر و پویا است، فیلدهای نوع XML اس کیوال سرور را مدنظر داشته باشید.
یک مثال عملی: فناوری Azure Dev Fabric's Table Storage (نسخه Developer ویندوز Azure که روی ویندوزهای معمولی اجرا می‌شود؛ یک شبیه ساز خانگی) به کمک SQL Server و فیلدهای XML آن طراحی شده است.


3) SQL Azure Federations
در اینجا منظور از Federations در حقیقت همان پیاده سازی قابلیت Sharding بانک‌های اطلاعاتی NoSQL توسط SQL Azure است که برای توزیع اطلاعات بر روی سرورهای مختلف طراحی شده است. به این ترتیب دو قابلیت Partitioning و همچنین Replication به صورت خودکار در دسترس خواهند بود. هر Partition در اینجا، یک SQL Azure کامل است. بنابراین چندین بانک اطلاعاتی فیزیکی، یک بانک اطلاعاتی کلی را تشکیل خواهند داد.
هرچند در اینجا Sharding  (که به آن Federation member گفته می‌شود) و در پی آن مفهوم «عاقبت یک دست شدن اطلاعات» وجود دارد، اما درون یک Shard یا یک Federation member، مفهوم ACID پیاده سازی شده است. از این جهت که هر Shard واقعا یک بانک اطلاعاتی رابطه‌ای است. اینجا است که مفهوم برنامه‌های  Multi-tenancy را برای درک آن باید درنظر داشت. برای نمونه یک برنامه وب را درنظر بگیرید که قسمت اصلی اطلاعات کاربران آن بر روی یک Shard قرار دارد و سایر اطلاعات بر روی سایر Shards پراکنده شده‌اند. در این حالت است که یک برنامه وب با وجود مفهوم ACID در یک Shard می‌تواند سریع پاسخ دهد که آیا کاربری پیشتر در سایت ثبت نام کرده است یا خیر و از ثبت نام‌های غیرمجاز جلوگیری به عمل آورد.
در اینجا تنها موردی که پشتیبانی نشده‌است، کوئری‌های Fan-out می‌باشد که پیشتر در مورد آن بحث شد. از این جهت که با نحوه خاصی که Sharding آن طراحی شده است، نیازی به تهیه کوئری‌هایی که به صورت موازی بر روی کلیه Shards برای جمع آوری اطلاعات اجرا می‌شوند، نیست. هر چند از هر shard با استفاده از برنامه‌های دات نت، می‌توان به صورت جداگانه نیز کوئری گرفت.


4) OData
اگر به CouchDB و امکان دسترسی به امکانات آن از طریق وب دقت کنید، در محصولات مایکروسافت نیز این دسترسی REST API پیاده سازی شده‌اند.
OData یک RESTful API است برای دسترسی به اطلاعاتی که به شکل XML یا JSON بازگشت داده می‌شوند. انواع و اقسام کلاینت‌هایی برای کار با آن از جاوا اسکریپت گرفته تا سیستم‌های موبایل، دات نت و جاوا، وجود دارند. از این API نه فقط برای خواندن اطلاعات، بلکه برای ثبت و به روز رسانی داده‌ها نیز استفاده می‌شود. در سیستم‌های جاری مایکروسافت، بسیاری از فناوری‌ها، اطلاعات خود را به صورت OData دراختیار مصرف کنندگان قرار می‌دهند مانند Azure table storage، کار با SQL Azure از طریق WCF Data Services (جایی که OData از آن نشات گرفته شده)، Azure Data Market (برای ارائه فیدهایی از اطلاعات خصوصا رایگان)، ابزارهای گزارشگیری مانند SQL Server reporting services، لیست‌های شیرپوینت و غیره.
به این ترتیب به بسیاری از قابلیت‌های دنیای NoSQL مانند کار با اطلاعات JSON بدون ترک دنیای رابطه‌ای می‌توان دسترسی داشت.


5) امکان اجرای MongoDB و امثال آن روی سکوی کاری Azure
امکان توزیع MongoDB بر روی یک Worker role سکوی کاری Azure وجود دارد. در این حالت بانک‌های اطلاعاتی این سیستم‌ها بر روی Azure Blob Storage قرار می‌گیرند که به آن‌ها Azure drive نیز گفته می‌شود. همین روش برای سایر بانک‌های اطلاعاتی NoSQL نیز قابل اجرا است.
به علاوه امکان اجرای Hadoop نیز بر روی Azure وجود دارد. مایکروسافت به کمک شرکتی به نام HortonWorks نسخه ویندوزی Hadoop را توسعه داده‌اند. HortonWorks را افرادی تشکیل داده‌اند که پیشتر در شرکت یاهو بر روی پروژه Hadoop کار می‌کرده‌اند.


6) قابلیت‌های فرا رابطه‌ای SQL Server
الف) فیلدهای XML (که در ابتدای این مطلب به آن پرداخته شد). به این ترتیب می‌توان به یک اسکیمای انعطاف پذیر، بدون از دست دادن ضمانت ACID رسید.
ب) فیلد HierarchyId برای ذخیره سازی اطلاعات چند سطحی. برای مثال در بانک‌های اطلاعاتی NoSQL سندگرا، یک سند می‌تواند سند دیگری را در خود ذخیره کند و الی آخر.
ج) Sparse columns؛ ستون‌های اسپارس تقریبا شبیه به Key-value stores عمل می‌کنند و یا حتی Wide column stores نیز با آن قابل مقایسه است. در اینجا هنوز اسکیما وجود دارد، اما برای نمونه علت استفاده از Wide column stores این نیست که واقعا نمی‌دانید ساختار داده‌های مورد استفاده چیست، بلکه در این حالت می‌دانیم که در هر ردیف تنها از تعداد معدودی از فیلدها استفاده خواهیم کرد. به همین جهت در هر ردیف تمام فیلدها قرار نمی‌گیرند، چون در اینصورت تعدادی از آن‌ها همواره خالی باقی می‌ماندند. مایکروسافت این مشکل را با ستون‌های اسپارس حل کرده است؛ در اینجا هر چند ساختار کلی مشخص است، اما مواردی که هر بار استفاده می‌شوند، تعداد محدودی می‌باشند. به این صورت SQL Server تنها برای ستون‌های دارای مقدار، فضایی را اختصاص می‌دهد. به این ترتیب از لحاظ فیزیکی و ذخیره سازی نهایی، به همان مزیت Wide column stores خواهیم رسید.
د) FileStreams در اس کیوال سرور بسیار شبیه به پیوست‌های سندهای بانک‌های اطلاعاتی NoSQL سندگرا هستند. در اینجا نیز اطلاعات در فایل سیستم ذخیره می‌شوند اما ارجاعی به آن‌ها در جداول مرتبط وجود خواهند داشت.


7) SQL Server Parallel Data Warehouse Edition
SQL PDW، نگارش خاصی از SQL Server است که در آن یک شبکه از SQL Serverها به صورت یک وهله منطقی SQL Server در اختیار برنامه نویس‌ها قرار می‌گیرد.
این نگارش، از فناوری خاصی به نام MPP یا massively parallel processing برای پردازش کوئری‌ها استفاده می‌کند. در اینجا همانند بانک‌های اطلاعاتی NoSQL، یک کوئری به نود اصلی ارسال شده و به صورت موازی بر روی تمام نودها پردازش گردیده (همان مفهوم Map Reduce که پیشتر در مورد آن بحث شد) و نتیجه در اختیار مصرف کننده قرار خواهد گرفت. نکته مهم آن نیز در عدم نیاز به نوشتن کدی جهت رخ دادن این عملیات از طرف برنامه نویس‌ها است و موتور پردازشی آن جزئی از سیستم اصلی است. تنها کافی است یک کوئری SQL صادر گردد تا نتیجه نهایی از تمام سرورها جمع آوری و بازگردانده شود.
این نگارش ویژه تنها به صورت یک Appliance به فروش می‌رسد (به صورت سخت افزار و نرم افزار باهم) که در آن CPU‌ها، فضاهای ذخیره سازی اطلاعات و جزئیات شبکه به دقت از پیش تنظیم شده‌اند.
‫۱۱ سال و ۲ ماه قبل، جمعه ۸ شهریور ۱۳۹۲، ساعت ۲۰:۱۰