alireza
alireza
خواندن ۱۸ دقیقه·۱ سال پیش

آشنایی با برخی مفاهیم به عنوان پیش نیاز در معماری نرم افزار

v
v

در این نوشته سعی خواهیم نمود پیرامون برخی موضوعات زیر آشنایی نسبی به خواننده ارائه نمائیم. این موضوعات مقدمه ای برای ورود به دنیای زیبای معماری نرم افزار خواهد بود.

  1. Modular Monolithic
  2. AWS
  3. API-first Approach
  4. NoSQL Databases
  5. Serverless Architecture
  6. Domain Driven Design
  7. Hexagonal architecture
  8. Event Sourcing
  9. Low code platforms
  10. Business Process Management Systems (BPMS)
  11. Message Queue (such as Kafka and RabbitMQ)
  12. Container orchestration (such as Kubernetes)
  13. Log Management Tools (such as ELK)
  14. Monitoring tools (such as Prometheus)
  15. Static Code Analysis (such as SonarQube)

1. یکپارچه ماژولار Modular Monolithic :

اگر جز برنامه نویسان دهه هشتاد شمسی باشید حتما معماری و برنامه نویسی 3 لایه موسوم به Three-Tier را به خاطر می آورید. در این معماری لایه ها شامل موارد زیر بودند :

· لایه بالایی به نام لایه ارائه یا Presentation یا UI

· لایه میانی به نام لایه تجاری یا Business یا Application و یا Logical

· لایه پایینی به نام لایه داده یا Data یا Database

به مرور زمان این معماری براثر افزایش مهارت و درک بهتر برنامه نویسان به سمت N-Tier یا چند لایه حرکت نمود و افزایش و تقسیم لایه‌ها بیشتر در لایه میانی اتفاق می افتاد و این موضوع باعث شده بود که مفهوم همان سه لایه اصلی در معماری چند لایه نیز پابرجا باشد.

تجربیاتی از این دست باعث ایجاد رویکردی به نام یکپارچه ماژولار گردید با این تفاوت که کل پروژه بر مبنای لایه میانی تقسیم بندی و لایه بندی گردید و هر لایه همچنان که مفهوم لایه میانی (Business) را حفظ می‌نماید شامل لایه های UI و Data منحصر بفرد خود باشد به عبارتی دیگر یک پروژه تجاری به یک سری پروژه کوچک تجاری تقسیم می‌گردید و هر پروژه اجزای اصلی و منحصربفرد خود را دارد. برای مثال یک پروژه حسابداری شامل چند پروژه کوچک می‌شود که هر پروژه یک بخش کار حسابداری را انجام می‌دهد مثلا یک بخش مربوط به چک، یک بخش مربوط به صندوق، یک بخش مربوط به سند حسابداری و ... .

اما اگر توجه کرده باشید تا اینجای کار در واقع ما مفهوم ماژول بندی را در این دست پروژه‌ها ایجاد کرده ایم و لازم است مفهوم یکپارچگی و کارکردن این ماژول‌ها با یکدیگر را نیز بین ماژول‌ها ایجاد نمائیم تا این ماژول‌ها بتوانند در قالب یک مفهوم کل به نام برنامه حسابداری و تحت یک فایل اجرایی (باینری) عمل نمایند. برای ایجاد چنین Monolithic ای از دو رویکرد اتصال مولفه‌ها می‌توان استفاده نمود. رویکرد همگام سازی از طریق سرویس‌های اتصال دهنده و یا رویکرد کارگزار پیام.

در نهایت در کنار ماژول‌ها و بخش اتصال دهنده (برای مثال کارگزار پیام)، یک سری مولفه مشترک هم به صورت Crosscut و قابل استفاده مجدد ماژول‌ها نیز در این معماری وجود خواهند داشت.

معماری یکپارچه ماژولار
معماری یکپارچه ماژولار


2. سرویس AWS :

Amazon Web Services (AWS)
Amazon Web Services (AWS)

نیاز به سرور و ماشین مجازی برای ارائه خدمات بر بستر اینترنت همواره یک چالش بزرگ برای مالکین این خدمات بوده است و در این میان شرکت های بزرگ فناوری همواره راهکارهایی را برای پاسخ به این چالش ارائه نموده اند. یکی از این راهکارها که توسط شرکت آمازون ارائه شده است راهکار AWS یا Amazon Web Services می باشد. این راهکار پلتفرم‌های بر پایه پردازش ابری بسته به تقاضا یا On-Demand فراهم می‌آورد. اما این دقیقا چیست ؟ در واقع فرض کنید شما برای ارائه یک خدمت به مشتریان خود بر بستر اینترنت، نیازمند یک Host و یا سرور یا یک محیط پردازشی هستید در اینجا شما باید از طریق یک Provider نسبت به تهیه هاست یا سرور اقدام کنید و شرکت‌های فراهم آورنده یا اصلاحأ Provider این نوع از خدمات زیرساختی به دلیل محدودیت‌های سخت افزاری – پردازشی ، پهنای باندی و مسائل زیرساختی خدمات خود را در قالب Plan های خاصی ارائه می‌نمایند که این موضوع همواره مشکلاتی را برای شما بوجود می آورد برای مثال مجبور هستید برای یک مدت معین مثلا ماهیانه یا سالیانه سفارش ثبت کنید یا در مواردی هنوز شما مشتری ندارید و تهیه این زیرساخت بیشتر با هدف تولید و توسعه خدمت صورت می‌گیرد و این موضوع برای Provider مورد توجه نیست یا در مورد دیگری پهنای باند اختصاصی به شما در یک محدوده بازه ای ارائه می‌گردد که با مصرف شما متناسب نیست. در مقابل این نوع ارائه خدمت نیز برای Provider مشکلات و سربار هزینه هایی را در پی دارد برای مثال منابع توسط مشتریانی به خوبی استفاده نمی‌گردد و این موضوع به نحوی باعث اشغال بدون استفاده منابع می‌گردد تا جایی که هزینه های نگهداری و استهلاک تجهیزات باعث ضرر دهی Provider می‌گردد این مشکلات و مواردی دیگر از این دست با ظهور فناوری پردازش ابری (Cloud Computing) قابل رفع گردید اما بکارگیری این فناوری، نیازمند تجهیزات زیرساختی و دانش و سرمایه‌گذاری خاصی می‌باشد که طبیعتأ هر Provider ای توانایی انجام آن را ندارد. در این میان شرکت آمریکایی آمازون به این موضوع ورود کرد و یک زیرمجموعه تحت عنوان AWS تاسیس نمود. در AWS تجهیزات زیرساختی و خدمات نرم افزاری پایه‌ای حوزه اینترنت با بهره گیری از فناوری پردازش ابری ارائه می‌گردند به این نحو که شما برای هاست یا سرور خود می‌توانید بر حسب نیاز پردازشی و بازه زمانی و یا بودجه این که در نظر دارید به صورت کاملا مقیاس پذیر سرویس دریافت کنید. برای مثال شما برای دموی نرم افزار خود نیاز به 1 هسته CPU با 1 گیگ RAM و یک پهنای باند 1 گیگ و 200 مگابایت فضای ذخیره‌سازی آن هم فقط در یک بازه 1 هفته و تنها در ساعات اداری دارید و در ضمن قصد دارید اگر همین میزان از توان پردازشی هم مصرف نشد شما برحسب مصرف پرداخت انجام دهید و پرداخت شما هم به سه صورت پرداخت بر حسب استفاده، اجاره ای یا اقساطی و رزرو از قبل امکان پذیر است و همین طور میزان پردازشی در صورت عدم استفاده برای شما قابل Save شدن است و در زمانی دیگر از آن می‌توانید استفاده نمائید و یا حتی اگر میزان استفاده شما از میزان سفارش شما تجاوز نمود بر حسب نوع توافق قبلی، مقیاس منابع پردازشی شما بیشتر یا محدودتر می‌گردد همه اینها در حالی جالب‌تر می‌گردد که آمازون بر حسب منطقه شما و یا منطقه‌ای که قصد ارائه خدمات خود را دارید قیمت گذاری خدمات ابری را انجام می‌دهد. در اینجا سرویس AWS به صورت کاملا خودکار منابع را برحسب مصرف شما کنترل کرده و در مقابل همین توان پردازشی شما را در صورت عدم استفاده به صورت کاملا خودکار در اختیار سایر مشتریان قرار می‌دهد و با این کار از منابع خود بیشترین استفاده ممکن را می‌نماید.

یک نمونه از Plan خدمات AWS
یک نمونه از Plan خدمات AWS

اما خدمات AWS تنها به چنین مواردی محدود نمی‌گردد و خدمات نرم‌افزاری در قالب بسته‌های نرم افزاری برای اهدافی مانند Storage، Migration، DevOps و ... را نیز به همین نحو ارائه می‌نماید. با این نحو از ارائه خدمات، یک محدوده بزرگ از مشتریان، از دانشجو تا متخصص، از استارت آپ تا سازمان‌های بزرگ، مشتریانی با اهدافی مانند تست و دمو تا فروشگاه بزرگ اینترنتی، مشتریانی با اهداف بهره‌گیری از بسته‌های نرم افزاری ابری در کسب و کار خود را پوشش می‌دهد.

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


3. رویکرد API-first :

این رویکرد در واقع تاکید بر این موضوع دارد که محصول نهایی که به عنوان خروجی مراحل ساخت و تولید نرم‌افزار خواهد بود را API ها ببینید و هنگام معماری نرم‌افزار API ها را در بالاترین رده در معماری پیشنهادی خود لحاظ کنید. اما این یعنی چی ؟ فرض کنید قرار است شما یک نرم افزار برای یک سازمان یا ارگان تولید نمائید در ابتدا معمولا اولین کاری که اتفاق می‌افتد این است که سازمان مربوطه یک حجم بزرگی از داده‌ها را در اختیار شما قرار می‌دهد تا شما برحسب و متناسب این داده‌ها نرم افزار تولید کنید اما این رویکرد کار تولید را بسیار کند و پیچیده خواهد کرد کاری که در گذشته بسیار مرسوم بود. حال اگر شما با عینک مبتنی بر سرویس به داده‌ها نگاه کنید و در ابتدا سعی نمائید ساز و کاری را فراهم آورید که این داده ها از طریق API به عنوان ورودی به نرم افزار شما وارد شوند و اجزا و بخش های مختلف نرم افزار خود را مبتنی بر تنوع خدماتی که نرم افزار قرار است ارائه نماید تقسیم بندی نمائید تولید داده های جدید و حتی خروجی های نرم افزار شما نیز مبتنی بر API خواهند بود و این چیزی است که به آن رویکرد API-First می‌گویند.


4. پایگاه داده های NoSQL :

سیستم های مدیریت پایگاه های داده موسوم به DBMS ها برای کار و مواجهه با داده ها به دو دسته کلی رابطه ای و غیر رابطه ای تقسیم می‌شوند. پایگاه های داده ای غیر رابطه ای را NoSQL DBs می‌نامند. اما این یعنی چی ؟ اگر تجربه کار با پایگاه داده هایی مانند SQL Server یا MySQL را داشته باشید حتما مشاهده کرده‌اید که ساختار یک بانک اطلاعاتی به این صورت است که داده‌ها را در خود در قالب جدول‌هایی که دارای سطر و ستون می‌باشند ذخیره می‌نمایند و برای ارتباط داده‌ها با یکدیگر چه در داخل هر جدول و یا بین جدول‌ها، از مفاهیم کلید بهره می‌برند که تعیین این کلیدها از قواعدی پیروی می‌نماید و این بدین معنی است که داده‌ای که قرار است به این نحو ذخیره و بازیابی گردد باید ساختاری متناسب با قواعد پایگاه‌های داده‌ای رابطه‌ای داشته باشد اما همواره هر نوع داده‌ای را نمی‌توان متناسب با چنین ساختارهایی شکل داد برای مثال در یک موتور جستجو که مبتنی بر کلمه مورد نظر کاربر قرار است یک سری محتوا در قالب‌های متن و عکس و فیلم و ... را ارائه نماید بین محتواهایی که شامل چنین کلمه‌ای است ممکن است ارتباطات زیادی وجود داشته باشد که چند جدول رابطه‌ای حتما نمی توانند چنین حجمی از اطلاعات را درخود ذخیره نمایند و نه می‌توانند برای حالت های مختلف جدوال مرتبط و روابط مختلف را در حالت اجرا ایجاد و سپس حذف نمایند در اینجا پایگاه های داده ای غیر رابطه‌ای به کمک آمده و از طریق مکانیزهای خاص مانند مفهوم Document با داده‌ها برخورد می‌نمایند. انواع پایگاه داده های غیررابطه ای شامل، مبتنی بر اسناد، مبتنی بر گراف، مبتنی بر چندستونه و مبتنی بر کلید و مقدار یا مبتنی بر چند مدله می‌باشند.

انواع پایگاه داده‌های غیررابطه‌ای
انواع پایگاه داده‌های غیررابطه‌ای

برخی از این پایگاه های داده مانند MongoDB، Redis، neo4J را می توان نام برد.


5. معماری Serverless :

مفهوم بدون سرور یا Serverless در واقع به این معنی است که شما از طریق مکانیزی بدون نیاز به سرور نرم افزار یا برنامه کاربردی خود را اجرا نمائید در این حالت شما درگیر مسائل مربوط به مدیریت سرور و زیرساخت نخواهید داشت و کنترلی هم روی آنها نخواهید داشت. مکانیزم مورد استفاده در واقع نوع خاصی از پردازش ابری است که شرکت هایی مانند آمازون هم تحت نام AWS Lambda آن را ارئه می‌نمایند.


6. طراحی DDD (Domain Driven Design) :

طراحی دامنه محور نوعی تفکر و نگاه برای تولید و توسعه نرم افزار است. تاکید این تفکر بر توجه به دامنه های مختلف کسب و کار است که قرار است در نرم افزار پیاده سازی گردند و برای این منظور ارتباط مستقیم توسعه دهندگان و برنامه نویسان با خبرگان بخش های مختلف کسب و کار را لازم و ضروری دانسته و برای ایجاد یک درک و ارتباط موثر بین این دو گروه (توسعه دهندگان و خبرگان کسب و کار) یک زبان مشترک Ubiquitous Language را پیشنهاد داده است. در این رویکرد همه چیز تحت دامنه ها دسته بندی می‌گردند و بسیار اتفاق می افتد که لازم است یک دامنه به تعدادی دامنه کوچکتر شکسته شود. این دامنه ها تحت سناریوهایی تعریف شده و سپس به کد تبدیل می‌گردند.


7. معماری Hexagonal :

معماری شش ضلعی که معماری جدیدی هم نیست، رویکردی است که به اجزای سازنده یک نرم افزار به چشم اجزای اصلی و اجزای فرعی نگاه می‌کند به این صورت که اجزای اصلی همان بخش کسب و کار نرم افزار است که برای مدت طولانی بدون تغییر باقی می‌ماند و با گذشت زمان این بخش کمتر دستخوش تغییر می‌گردد و اجزای فرعی بخش‌هایی مانند پایگاه داده، رابط کاربری، سرویس پیامک و پست الکترونیک و غیره نرم افزار می‌گردند که در زمان های کوتاه به دلایلی مانند تغییر فناوری‌ها، درخواست کاربران، نیازمندی‌های جدید دستخوش تغییر می‌گردند اما این نگاه چطوری باید در قالب یک معماری ارائه گردد ؟

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

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


8. پلتفرم‌های Low Code :

در کنار روش های تولید نرم افزار مرسوم، ایده تولید از طریق روش‌هایی مانند بدون کد یا روش کم‌کد نیز مطرح و برای این ایده پلتفرم‌هایی ارائه شده است. در روش کم‌کد برنامه نویس بیشتر نقش طراح داشته و از طریق پلتفرمی که ابزارهای ویژوال در اختیار کاربر قرار می‌دهد به برنامه نویس امکان ساخت فرم‌ها با کمترین کدنویسی ممکن را می‌دهد.


9. سیستم های مدیریت فرایندهای کسب و کار :

نرم افزاری که از طریق آن کار مدیریت فرایندهای کسب و کار انجام می‌گیرد. در هر شرکتی تمامی کارها در قالب فرایندهای کاری تعریف می‌گردند و چارچوبی مانند BPM برای این منظور بکار می‌رود در این چارچوب، فرایندها در یک چرخه طراحی، مدلسازی، اجرا، نظارت، بهینه سازی و طراحی مجدد قرار می‌گیرند. زبانی مانند BPMN برای طراحی فرایندها مورد استفاده قرار می‌گیرد. در این میان سیستم مدیریت فرایندهای کسب و کار موسوم به BPMS چارچوب BPM را در سازمان‌ها کاربردی می‌نمایند.

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


10. راهکار Message Queue و ابزارهایی مانند Kafka و RabbitMQ :

در معماری میکروسرویس و معماری Serverless برای ایجاد ارتباط و گفتگو بین سرویس‌ها (Service-to-Service) به صورت آسنکرون از راهکار MQ استفاده می‌گردد. همانطور که از اسم این راهکار مشخص است پیام ها به صورت مکانیزمی که به آن کارگزار پیام گفته می‌شود در صف برای پاسخگویی قرار می‌گیرند.

اما کاربرد ملموس آن چیست ؟ فرض کنید درخواست‌های زیادی در مدت زمان خیلی کم به سمت یک API روانه شوند در این حالت بدلیل آنکه پاسخ به هر درخواست نیاز به پردازش دارد سیستم قادر نخواهد بود به درخواست‌های تقریبا همزمان بعدی پاسخ دهد و این درخواست‌ها از دست خواهند رفت در این حالت به کمک مکانیزم MQ که به عنوان واسط عمل می‌نماید درخواست‌های وارده دریافت و الویت بندی و در صف قرار می‌گیرند و مطابق صف ایجاد شده به سمت API مربوطه ارسال می‌گردند در این حالت به تمامی درخواست‌ها با اطمینان بالایی پاسخ داده خواهد شد و درخواستی از دست نمی‌رود. این واسط با این روش حتی به صورت تاثیر جانبی باعث سرعت بخشیدن به پاسخ‌ها نیز می‌گردد زیرا دیگر درخواست‌های مکرر مزاحم سرویس نمی‌شوند.

راهکار صف پیام
راهکار صف پیام

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

یکی از ابزارهای رایگان، بسیار محبوب، Open Source و قابل توسعه در این زمینه RabbitMQ است.

از ابزارهای دیگر می‌توان به ابزار غیررایگان AWS SQS شرکت آمازون اشاره نمود که به عنوان یکی از سرویس‌های قابل ارائه در AWS شناخته می‌شود.


11. راهکار Container Orchestration و ابزاری مانند Kubernetes :

با بوجود آمدن مفهوم Container سازی که به عنوان قابلیت جدید در زیرساخت نرم افزاری بروز نموده است هر بخش و واحد نرم افزاری را می‌توان در قالب یک Container از یک زیرساخت به زیرساخت دیگری انتقال و مهاجرت داد همچنین اجرا و راه اندازی آن بسیار سبک‌تر خواهد بود. دقیقا مانند صادرات محصولات از طریق کشتیرانی و استفاده از الگوی حمل کالا به صورت کانیتری. اما تاکنون به این فکر کرده‌اید که نحوه سازماندهی و چیدمان کانتینرها در کشتی یک موضوع بسیار مهم می‌باشد. در دنیای نرم افزاری هم ساماندهی Container ها بسیار مهم است و این ساماندهی بهتر است به روش رهبر ارکستر که به آن Orchestration می‌گویند انجام گیرد.

یکی از ابزارهایی که به روش Orchestration به ساماندهی Container ها می پردازد و البته رایگان و Open Source می‌باشد Kubernetes به معنی ناخدا است. در کوبرنتیز با مفاهیمی از بالاترین سطح تا پایین‌ترین سطح روبرو هستیم. از سطح بالا با مفهوم خوشه یا Cluster که به مجموعه ماشین های حاوی Containerها گفته می‌شود روبرو هستیم سپس با مفهوم گره یا Node که به هریک از ماشین‌های موجود در یک خوشه گفته می‌شود و در سطح بعد با مفهوم پاد یا Pods که نمونه یک برنامه یا فرایندی از کوبرنتیز است که می تواند شامل چند Container باشد روبرو می شویم.

12. ابزارهای مدیریت لاگ مانند ELK :

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

با بروز و ظهور فناوری‌های جدید مانند پردازش ابری و بحث Container ها و یا متدولوژی‌های توسعه نرم افزار مانند DevOps تنوع کاربرد ابزارهای مدیریت لاگ بیش از پیش افزایش یافته است.

برخی ابزارهای فوق حرفه ای مانند Splunk در این عرصه بسیار سرآمد هستند و البته گران و مناسب سازمان‌های بزرگ. در این میان ابزارهای رایگان و Open Source ای مانند ELK نیز وجود دارند که از طرف شرکت‌های کوچک و استارت آپ‌ها مورد استقبال قرار گرفته است. اسم ELK که از 3 حرف اول سه ابزار مجتمع شده با یکدیگر یعنی Elasticsearch، Logstash و Kibana تشکیل شده بخش‌های این ابزار را معرفی می‌نماید. در واقع لاگ‌ها توسط Logstash جمع آوری شده، توسط Elasticsearch بروی لاگ‌ها امکان ذخیره سازی، جستجو و پرس و جو فراهم می‌گردد و در آخر لاگ‌ها توسط Kibana قابلیت تجسم و نمایش به کاربران را پیدا می‌نمایند. در این میان درصورتیکه تعداد زیادی لاگ به سمت Elk در مدت کوتاهی سرازیر گردد می‌توان به کمک ابزارهای MQ مانند RabbitMQ و تلفیق آنها با ELK این ابزار را انعطاف‌پذیر نمود.


13. ابزارهای مانیتورینگ مانند Prometheus :

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

یکی از این ابزارهای رایگان و OpenSource ابزار Prometheus می‌باشد.

Prometheus
Prometheus

این ابزار از بخش‌های جمع آوری کننده داده، ذخیره ساز، هشدار دهنده و تجسم ساز و داشبوردساز تشکیل شده است.


14. تحلیل کد استاتیک و ابزاری مانند SonarQube :

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

خروجی تجزیه و تحلیل کد توسط SonarQube
خروجی تجزیه و تحلیل کد توسط SonarQube

این ابزار، ابزارهای تحلیلی مانند PMD، FindBugs و ... را در دل خود دارا می‌باشد و همچنین این ابزار سرور، دیتابیس و رابط کاربری مجزای خود را داشته و می‌تواند به ابزارهای اتوماسیون DevOps مانند Jenkins متصل شده و در طول چرخه یا خط لوله‌های DevOps با ارائه گزارشات متنوع، به برنامه نویسان در یافتن خطای کدی که نوشته‌اند کمک نماید.

awsarchitecturesoftwareeventdesign
شاید از این پست‌ها خوشتان بیاید