سیب فارسی

شب و روزنوشته های من | داستان سیبی که هر روز به زمین می خورد!

Microservices vs SOA: What’s the Difference?

30 مارس 19

Microservices Architecture (MSA) and Service-Oriented Architecture (SOA) both rely on services as the main component. But they vary greatly in terms of service characteristics.

SOA defines 4 basic service types as depicted below:

coordination-768x330

Business services are coarse-grained services that define core business operations. They are usually represented through XML, Web Services Definition Language (WSDL) or Business Process Execution Language (BPEL).

Enterprise services implement the functionality defined by business services. They rely on application services and infrastructure services to fulfill business requests.

Application services are fine-grained services that are bound to a specific application context. These services can be invoked directly through a dedicated user interface.

Infrastructure services implement non-functional tasks such as authentication, auditing, security, and logging. They can be invoked from either application services or enterprise services.

MSAs have limited service taxonomy. The architecture consists of 2 service types as depicted below.

Minimal-coordination

 support specific business operations. The services are accessed externally and they are usually not shared with any other service. As in SOA, infrastructure services implement tasks such as auditing, security, and logging. The services are not exposed to the outside world and they are available internally.

Key differences between SOA and MSA

SOA-architecture-vs-microservices

MSA
Built on the idea of “share-as-much-as-possible” architecture approach Built on the idea of “share-as-little-as-possible” architecture approach
More importance on business functionality reuse More importance on the concept of “bounded context”
Common governance and standards Relaxed governance, with more focus on people collaboration and freedom of choice
Uses enterprise service bus (ESB) for communication Uses less elaborate and simple messaging system
Supports multiple message protocols Uses lightweight protocols such as HTTP/REST & AMQP
Common platform for all services deployed to it Application Servers not really used. Platforms such as Node.JS could be used
Multi-threaded with more overheads to handle I/O Single-threaded usually with use of Event Loop features for non-locking I/O handling
Use of containers (Dockers, Linux Containers) less popular Containers work very well in MSA
Maximizes application service reusability More focused on decoupling
Uses traditional relational databases more often Uses modern, non-relational databases
A systematic change requires modifying the monolith A systematic change is to create a new service
DevOps / Continuous Delivery is becoming popular, but not yet mainstream Strong focus on DevOps / Continuous Delivery

Let’s explore the differences in more detail:

  • Coordination: In SOA, you need to coordinate with multiple groups to create business requests. But there is little or no coordination among services in MSA. If coordination is needed among service owners, it is done through small application development teams, and services can be quickly developed, tested and deployed.
  • Service granularity: The prefix “micro” in Microservices refers to the granularity of the internal components. Service components within MSA are generally single purpose services that do one thing really well. Services usually include much more business functionality in SOA, and they are often implemented as complete subsystems.
  • Component sharing: SOA enhances component sharing, whereas MSA tries to minimize on sharing through “bounded context.” A bounded context refers to the coupling of a component and its data as a single unit with minimal dependencies. As SOA relies on multiple services to fulfill a business request, systems built on SOA are likely to be slower than MSA.
  • Middleware vs API layer: The messaging middleware in SOA offers a host of additional capabilities not found in MSA, including mediation and routing, message enhancement, message and protocol transformation. MSA has an API layer between services and service consumers.
  • Remote services: SOA architectures rely on messaging (AMQP, MSMQ) and SOAP as primary remote access protocols. Most MSAs rely on two protocols – REST and simple messaging (JMS, MSMQ), and the protocol found in MSA is usually homogeneous.
  • Heterogeneous interoperability: SOA promotes the propagation of multiple heterogeneous protocols through its messaging middleware component. MSA attempts to simplify the architecture pattern by reducing the number of choices for integration. If you would like to integrate several systems using different protocols in heterogeneous environment, you need to consider SOA. If all your services could be exposed and accessed through the same remote access protocol, then MSA is a better option.
  • Contract decoupling: Contract decoupling is the holy grail of abstraction. It offers the greatest degree of decoupling between services and consumers. It is one of the fundamental capabilities offered within SOA. But MSA doesn’t support contract decoupling.

Microservices are not invented. Enterprises such as Amazon, Netflix, and eBay used the divide and conquer strategy to functionally partition their monolithic applications into smaller units, and resolved many issues. Following the success of these companies, many other companies started adopting this as a common pattern to refactor their applications. Eventually the pattern was termed as Microservices Architecture. Nothing radically new has been introduced in MSA. MSA is the logical evolution of SOA and supports modern business use cases.

SOA is better suited for large and complex business application environments that require integration with many heterogeneous applications. However, workflow based applications that have a well defined processing flow are a bit difficult to implement using SOA patterns. Small applications are also not a good fit for SOA as they don’t need messaging middleware component. The MSA pattern is well suited for smaller and well partitioned web based systems. The lack of messaging middleware is one of the factors that makes it unfit for complex environments.

If you are developing an application, then MSA gives you greater control as a developer. If you are trying to orchestrate a number of business processes, SOA probably provides a better set of tools.

Also in the early stages of your business, you might find that MSA is a good choice. As the business grows, you may need capabilities such as complex request transformation and heterogeneous systems integration. In such situations, you may likely turn to SOA pattern to replace MSA.

Both SOA and MSA are the same set of standards used at different layers of an enterprise. The existence of MSA comes down to the success of SOA pattern. Hence, MSA pattern is a subset of SOA. Here the main focus is on the runtime autonomy of each service.

enterprise service bus

30 مارس 19

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It implements a software architecture as depicted in the picture. As it implements a distributed computing architecture, it implements a special variant of the more general client-server model, wherein, in general, any application using ESB can behave as server or client in turns. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. The primary goal of the high-level protocol communication is enterprise application integration (EAI) of heterogeneous and complex service or application landscapes (a view from the network level).

The concept is analogous to the bus concept found in computer hardware architecturecombined with the modular and concurrent design of high-performance computer operating systems. The motivation for the development of ESB was to find a standard, structured, and general purpose concept for describing implementation of loosely coupled software components (called services) that are expected to be independently deployed, running, heterogeneous, and disparate within a network. ESB is also a common implementation pattern for service-oriented architecture.

Working

An ESB applies the design concept of modern operating systems to independent services running within networks of disparate and independent computers. Like concurrent operating systems, an ESB provides commodity services in addition to adoption, translation and routing of client requests to appropriate answering services.

The primary duties of an ESB are:

  • Route messages between services
  • Monitor and control routing of message exchange between services
  • Resolve contention between communicating service components
  • Control deployment and versioning of services
  • Marshal use of redundant services
  • Provide commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication servic

Key benefits

  • Scales from point-solutions to enterprise-wide deployment (distributed bus)
  • More configuration rather than integration coding
  • No central rules-engine, no central broker
  • Easy plug-in and plug-out and loosely coupling system

Key disadvantages

  • Slower communication speed, especially for those already compatible services
  • Single point of failure, can bring down all communications in the Enterprise
  • High configuration and maintenance complexity

میکروسرویس (Microservice) چیست؟

30 مارس 19

پیش نوشت: این مطلب مقدمه ای است برای مطلب: اصول طراحی: مقدمه ای بر microservics و enterprise service bus (مقدمه یک)

میکروسرویس (Microservice) چیست؟

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

معماری Monolithic چیست؟
برای درک ماهیت میکروسرویس‌ها، ابتدا باید ببینیم که معماری Monolithic چگونه کار می‌کند. به طور کلی، در این نوع معماری ما سه لایه داریم تحت عناوین:

– Model (منطق اپلیکیشن)
– View (خروجی اپلیکیشن)
– Controller (رابط مابین خروجی و منطق اپلیکیشن)

برای روشن‌تر شدن این مسئله، مثالی می‌زنیم. در حال حاضر که مشغول مطالعهٔ این مقاله هستید، به محض اینکه وارد این صفحه شدید، یک ریکوئست (درخواست) برای سرور وردپرس سیب فارسی ارسال گردیده است که لایهٔ مرتبط با Controller این درخواست را گرفته و برای لایهٔ Model ارسال می‌کند و این لایه هم با دیتابیس ارتباط برقرار ساخته و دیتای مرتبط با این مقاله را از دیتابیس فراخوانی کرده و در صورت نیاز یکسری کارها برای تر و تمیز کردن داده‌ها انجام داده و در نهایت مجدد دیتا در اختیار Controller قرار می‌دهد و این لایه هم دیتای موجود را در اختیار View می‌گذارد و این لایه هم خروجی این صفحه از وبلاگ سیب فارسی را داخل مرورگر شما نشان می‌دهد.

مشکلات مرتبط با معماری Monolithic
این نوع معماری که تحت عنوان معماری MVC هم شناخته می‌شود دارای یکسری نواقصی است. به عبارت دیگر، تمامی لایه‌ها (مدل، ویو و کنترلر) زیر پرچم یک پلتفرم واحد مدیریت می‌شوند و ارتباط بسیار تنگاتنگی با یکدیگر دارند و مثلاً به سادگی نمی‌توان Model یک اپلیکیشنی که تحت معماری MVC نوشته شده را برداشته و در پروژهٔ دیگری استفاده کرد.

from-the-monolith-to-microservices-craftconf-2015-6-638

همان‌طور که در تصویر فوق مشخص است، در معماری Monolithic یک هستهٔ مرکزی داریم که کاربران و حتی دیگر سرویس‌ها از طُرق مختلف می‌توانند با آن ارتباط برقرار سازند و می‌بینیم گرچه خودِ این هستهٔ مرکزی ماژولار (بخش‌بندی) است، اما همگی تحت یک پلتفرم واحد کنار یکدیگر قرار گرفته‌اند و امکان مجزاسازی این ماژول‌ها وجود ندارد و یا اگر هم چنین امکانی وجود داشته باشد، بسیار دشوار خواهد بود.
اگرچه که در معماری MVC کدها ماژولار هستند و نسبت به گذشته که تمامی فایل‌ها در یک پوشه گذاشته می‌شدند و اصلاً مفهومی تحت عنوان ماژول در کار نبود شرایط به مراتب بهتر است، اما همان‌طور که گفته شد، هر ماژول برای کارکرد صحیح و اصولی خود نیاز به سایر ماژول‌ها دارد. به طور کلی، مشکلات مرتبط با معماری Monolithic را می‌توان به دسته‌های زیر تقسیم‌بندی کرد:

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

– یک تغییر کوچک در یکی از ماژول‌ها، ممکن است عملکرد دیگر ماژول‌ها را تحت‌تأثیر خود قرار دهد.

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

– کامپوننت‌ها را به سادگی نمی‌توان با یک معماری جدیدتر و بهینه‌تر جایگزین کرد چرا که کل معماری نرم‌افزار باید دستخوش تغییر گردد.

– تنوع تکنولوژی من‌جمله زبان‌های برنامه‌نویسی، دیتابیس‌های مختلف، لایبرری‌ها و فریمورک‌های مختلف وجود نخواهد داشت و اگر هم این‌گونه باشد، ارتباط برقرار کردن مابین آن‌ها بسیار دشوار خواهد بود.

– و یک باگ در یکی از ماژول‌ها، به احتمال زیاد کل پروژه را تحت‌الشعاع خود قرار خواهد داد.

اینجا است که پای میکروسرویس‌ها به میان می‌آید و مزایایش منجر بدین گشته تا کمپانی‌های بزرگی همچون آمازون یا نتفلیکس به استفاده از میکروسرویس‌ها ترغیب شوند.

معماری Microservice چیست؟
میکروسرویس‌ روشی به منظور تقسیم‌بندی کردن یک اپلیکیشن (نرم‌افزار) به بخش‌ها یا سرویس‌های کوچک، سبُک، مستقل از یکدیگر و قابل‌مدیریت است. به عبارت دیگر، میکروسرویس یک معماری توسعهٔ‌ نرم‌افزار به اصطلاح Distributed است.

همان‌طور که در تصویر فوق مشاهده می‌شود، این نوع سرویس‌ها صرفاً به منظور هندل کردن یک تَسک خاص طراحی می‌شوند. به طور مثال، یک سرویس صرفاً وظیفهٔ مدیریت کاربران را دارا است و سرویس دیگر فقط و فقط برای بخش جستجوی سایت کاربرد دارد و با توجه به اینکه میکروسرویس‌ها مجزا و مستقل از یکدیگر هستند، به راحتی قادر خواهیم بود تا آن‌ها را با زبان‌های برنامه‌نویسی مختلفی نوشته و برای ذخیره‌سازی داده‌های مرتبط با آن‌ها نیز از سیستم‌های مدیریت دیتابیس مختلفی استفاده کنیم (به عبارت دیگر، جاهایی که نیاز به ذخیره‌سازی سنتی داده‌ها داریم می‌توانیم از MySQL استفاده کنیم و جاهایی دیگر هم به خاطر ساختار غیرقابل پیش‌بینی دیتای خود می‌توانیم به استفاده از دیتابیس‌های به اصطلاح NoSQL بپردازیم.)

حال ممکن است این پرسش مطرح شود که سرویس‌های مختلف یک اپلیکیشن با معماری میکروسرویس چگونه با یکدیگر ارتباط برقرار می‌کنند؟ در پاسخ به این سؤال باید گفت، همان‌طور که در تصویر فوق مشخص است، با استفاده از ریکوئست‌هایی از جنس HTTP و یکسری API به اصطلاح RESTful این ارتباط برقرار خواهد شد.

آشنایی با معماری Service Oriented Architecture
اینجا سؤال دیگری به ذهن می‌رسد و آن هم اینکه با این تفاسیر تفاوت چندانی مابین Service Oriented Architecture یا به اختصار SOA با Microservice وجود ندارد که در پاسخ به این سؤال هم می‌توان گفت که Microservice نوعی SOA (معماری مبتنی بر سرویس) است که طی ده‌های گذشته خیلی مطرح بوده است اما در عین حال میکروسرویس نسبت به معماری مبتنی بر سرویس انعطاف‌پذیرتر است چرا که به سادگی می‌توان یک سرویس یا ماژول را از پروژه‌ای برداشت و بدون پیکره‌بندی خاصی آن را در پروژه‌ٔ دیگری استفاده کرد اما این در حالی است که معماری SOA داخل یک معماری اصطلاحاً Monolithic پیاده‌سازی می‌شود.

به عبارت دیگر، در معماری SOA ما کامپوننت‌ها یا ماژول‌هایی داریم که سرویس‌هایی را در اختیار دیگر کامپوننت‌های قرار می‌دهند و این در حالی است که این کامپوننت‌ها می‌توانند منحصر به یک اپلیکیشن خاص باشند اما در مقابل در معماری یک Microservice این کامپوننت‌ها به عنوان سرویس‌های کاملاً مستقلی هستند که به صورت تکی هم می‌توان آن‌ها را دیپلوی کرد. نکتهٔ دیگری که در ارتباط با تفاوت‌های این دو معماری نرم‌افزار باید مد نظر داشت، سایز ماژول‌ها است. به عبارت دیگر، میکروسرویس‌ها به مراتب کوچک‌ترند و همین مسئله مدیریت آن‌ها را به مراتب ساده‌تر می‌سازد.

آشنایی با تفاوت‌های معماری‌های Microservice ،Monolithic و SOA
برای درک بهتر تفاوت‌های مابین معماری‌های Microservice ،Monolithic و SOA می‌توان اولین تصویری که در این مقاله استفاده شده را مد نظر قرار داد. در واقع از چپ به راست، معماری‌های SOA ،Monolithic و Microservice در قالب خوراکی به تصویر کشیده‌ شده‌اند.

در تصویر سمت چپ می‌بینیم که معماری Monolithic به گونه‌ای است که ارتباط تنگاتنگی مابین ماژول‌های مختلف اپلیکیشن وجود دارد که اصطلاحاً گفته می‌شود Tightly Coupled است و در صورتی که بخواهیم تغییری در یکی از بخش‌ها دهیم با مشکل مواجه خواهیم شد و همین مسئله Continous Deployment یا به اختصار CD را دشوار می‌سازد. در تصویر وسط که نشانگر معماری SOA است، می‌بینیم که اوضاع نسبت به معماری Monolithic به مراتب بهتر بوده به طوری می‌توانیم اپلیکیشن را به بخش‌های مجزا از یکدیگر تقسیم‌بندی کنیم اما در عین حال، هر بخش زیر چتر پلتفرم اصلی قرار دارد و در تصویر سمت راست هم که معماری Microservice در آن به تصویر کشیده شده است،‌ بر خلاف دو معماری دیگر می‌بینیم که هر ماژول کاملاً مستقل از دیگر ماژول‌ها است که اصطلاحاً گفته می‌شود Loosely Coupled است و همچون یک پیراشکی، می‌توان آن را به تنهایی میل کرد!

monolithic-vs-microservices

مزایای استفاده از میکروسرویس‌ها
امروزه ماژولار بودن به یک مزیت رقابتی در هر صنعتی مبدل شده‌اند؛ از مبلمان IKEA گرفته تا گوشی‌های موبایل ماژولار و حتی اسباب‌بازی‌های LEGO و این در حالی است که ایدهٔ پشت میکروسرویس‌ها این است تا این امکان به دولوپرها داده شود تا اپلیکیشن‌های خود را بر مبنای اجزا یا سرویس‌هایی که مستقل از یکدیگر هستند و به سادگی قابل‌تغییر، حذف و به‌روزرسانی می‌باشند توسعه دهند بدون اینکه کل اپلیکیشن تحت‌الشعاع قرار گیرد. روی هم رفته، مهم‌ترین مزایای استفاده از معماری میکروسرویس‌ عبارتند از:

– بر خلاف معماری مونولیتیک، در یک اپلیکیشنی که در آن از معماری میکروسرویس استفاده شده باشد سرویس‌ها هرگز بر اساس معماری MVC تقسیم‌بندی نمی‌شوند بلکه بر اساس کاری که انجام می‌دهند به بخش‌های مختلف تقسیم می‌شوند. به عبارت دیگر، یک سرویس همچون آپلود فایل شامل بخش‌هایی همچون رابط کاربری، مدل‌های مرتبط با دیتابیس، کنترلر، سیستم لاگینگ و … خواهد بود (در چنین شرایطی، فرض کنیم دولوپر سرویسی تحت عنوان File Uploader می‌سازد و از آن پس به سادگی قادر خواهد بود سرویس مد نظر را در دیگر پروژه‌ها که کاربرد یکسانی دارند نیز استفاده کند.)

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

– علاوه بر موارد فوق، میکروسرویس‌ها اصطلاحاً Scalable (قابل‌توسعه) هستند. ماهیت مستقل ماژول‌های مختلف یک میکروسرویس این امکان را برای‌مان فراهم می‌آورند تا با استفاده از زبانی خاص، دیتابیسی خاص و همچنین سروری خاص به توسعهٔ اپلکیکشن مد نظر خود بپردازیم و در صورت نیاز صرفاً منابع همان پلتفرم را ارتقاء دهیم.

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

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

– با توجه به اینکه سرویس‌ها برای برطرف کردن نیازهای خود دیگر سرویس‌ها را کال (فراخوانی) می‌کنند، رصد کردن آن‌ها و بالتبع فرایند دیباگینگ بسیار دشوار خواهد شد.

– هر سرویس لاگ‌گیری اختصاصی خود را دارا است و از همین روی هیچ سیستم مانیتورینگ مرکزی برای بررسی لاگ‌ها وجود ندارد و در چنین شرایطی نیاز به یک سیستم مدیریت لاگ مرکزی وجود خواهد داشت.

– با توجه به اینکه ارتباط سرویس‌ها با یکدیگر از طریق API است، تعداد رکوئست‌ها نسبت به یک معماری مونولیتیک به مراتب بیشتر خواهد بود.

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

– ورژن‌بندی میکروسرویس‌ها باید به صورت مجزا از یکدیگر صورت گیرد و اینجا است که نیاز داریم تا مشخص کنیم به طور مثال کدام ورژن سرویس A با کدام ورژن سرویس Z باید دیپلوی شود.

– مستندات‌سازی چنین اپلیکیشن‌هایی مشکل‌تر است چرا که با توجه به ماهیت مستقل هر ماژول، سرویس‌ها باید به صورت کامل مستندسازی شوند.

– با توجه به اینکه ممکن است از چندین زبان‌ برنامه‌نویسی و تکنولوژی مختلف در چنین اپلیکیشن‌هایی استفاده شود، هزینهٔ نگهداری چنین سیستم‌ها گاهی‌ اوقات زیاد می‌شود به طوری که مثلاً نیاز به استخدام دولوپر زبان‌های مختلف خواهیم داشت.

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

چه زمانی به میکروسرویس مهاجرت کنیم؟
آنچه در ادامه خواهیم آورد، شرایطی است که اگر در مورد اپلیکیشن شما صدق می‌کند، زمان آن فرا رسیده که میکروسرویس هم جزو یکی از گزینه‌های پیش‌ روی شما باشد:

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

– صرفاً برخی بخش‌های اپلیکیشن نیاز به توسعه دارند و این در حالی است که در معماری مونولیتیک شما باید به یک باره کل منابع سیستمی خود را ارتقاء دهید و این در صورتی است که ممکن است اصلاً نیاز به ارتقاء به این شکل نباشد.

– چنانچه دولوپرها در کنار یکدیگر نیستند و نمی‌توانند به صورت مستقل از یکدیگر روی پروژه کار کنند.

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

 

این مطلب منتشر شده در سیب فارسی از وبلاگ سکان آکادمی

اصول طراحی: مقدمه ای بر microservics و enterprise service bus (مقدمه یک)

27 مارس 19

استفاده از design principle ها هم حدودی داره که باید رعایت بشه و نباید در استفاده از آن افراط و تفریط بشه. سه تا از اونها DRY , YAGNI , KISS هست. یه تعریف کلی از هرکدوم پایین تر اورده شده. توی پست های بعدی چند تا از مصداق های افراط و تفریط توی هرکدوم رو خصوصا در بحث esb ها و دیدگاه سرویس گرایی خواهم نوشت‌.

KISS
“Keep It Simple, Stupid”
The simpler your code is, the simpler it will be to maintain it in the future.

YAGNI
“You Aren’t Gonna Need It” – Sometimes, as developers, we try to think way ahead, into the future of the project, coding some extra features “just in case we need them” or thinking“we will eventually need them”. Just one word: Wrong! You didn’t need it, you don’t need it and in most of the cases… “You Aren’t Gonna Need It”.

DRY
“Don’t Repeat Yourself” – How many times do you see that there are similar codes in different parts of a system? The DRY principle, formulated by Andrew Hunt and David Thomas in their book The Pragmatic Programmer, states that “every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” In other words, you must try to maintain the behavior of a functionality of the system in a single piece of code.

#esb #designprinciples #soa #microservices

به کارگیری ابزار بیت کوین در مراکز پولی و مالی ممنوع است

23 آوریل 18

به کارگیری ابزار بیت کوین(Bit Coin) و سایر ارزهای مجازی در تمام مراکز پولی و مالی کشور ممنوع است.

به گزارش روابط عمومی بانک مرکزی در جلسه سی ام شورای عالی مبارزه با پولشویی در تاریخ 9 دی ماه 1396، به کارگیری ابزار بیت کوین(Bit Coin) و سایر ارزهای مجازی در تمام مراکز پولی و مالی کشور ممنوع اعلام شد. از آنجایی که انواع ارزهای مجازی از این قابلیت برخوردار هستند که به ابزاری برای پولشویی و تامین مالی تروریسم و به طور کل، جابه‌جایی منابع پولی مجرمان بدل شوند، حوزه نظارت بانک مرکزی برای پیشگیری از وقوع جرائم از طریق ارزهای مجازی، موضوع ممنوعیت به کارگیری ارزهای مجازی را به بانک ها ابلاغ کرده است.

از این رو، با توجه به اهمیت موضوع، تمام شعب و واحدهای تابعه بانک ها و موسسات اعتباری و صرافي ها باید از انجام هر گونه خرید و فروش ارزهای مذکور و یا انجام هر گونه اقدامی که به تسهیل و یا ترویج ارزهای یاد شده بینجامد، به طور جد اجتناب کنند. همچنین لازم به ذکر است با متخلفین، برابر قوانین و مقررات مربوط برخورد خواهد شد.‏
نظر:

البته استفاده از این نوع ارز رواج نداشت و ممنوعیت برای آینده است. در حال حاضر بیشتر از کسب درآمد و حفظ سرمایه برای مهاجرت از خرید بیت کوین استفاده می شد و تبدیل دلار به ارز های دیجیتال و تبدیل در خارج از کشور مجددا به دلار و یورو وغیره.

آیا این قانون مهاجرت را برای شما سخت می کند؟ شما برای انتقال سرمایه از این روش استفاده می کنید؟

ما را به رندی افسانه کردند

7 جولای 17

شعر جاودانه ی استاد غزل حافظ عزیز رو می خوندم گفتم توی این حال خوب شما رو هم شریک کنم.

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

توی فکر ایجاد یه ابزاری ام که توش مردم از حال خوبشون بگن و این حال خوب رو بین هم تقسیم کنن.. حالا یه اپ یه گروه تلگرام یا یک وبسایت، اگه ایده ای دارید بگید باهم اجراش کنیم.

سایت های فروش اینترنتی از سراب تا موفقیت: اپیزود دوم شکست بامیلو

2 آوریل 17

راجع به شرکت بامیلو نقد های فراوانی شده است و پیش از این نیز بارها صحبت شده است و ضعف های این شرکت برای اهل فن آشکار شده است…

پیش از مطلبی راجع به این موضوع نوشته بودم که می توانید آن را از طریق لینک زیر مشاهد فرمایید:

سایت های فروش اینترنتی از سراب تا موفقیت

طی جستجو های اخیر دیدم شکایت ها درباره این شرکت از طرف مشتریان روز به روز بیشتر شده است در زیر برخی از این شکایات که مشاهده کردم در زیر آورده ام لینک و نام و نشان دوستان محفوظ است و در زیر پست رفرنس شده است:

#کمپین_ما_از_بامیلو_خرید_نمیکنیم_درش_را_ببندید #شکایت_از_بامیلو  #نارضایتی_بامیلو

احسان گفته:

من ناچارا چند ماه پیش از بامیلو خرید کردم با اینکه میدانستم خیلی گران فروش است و قیمتهاش از بازار و فروشگاه های دیگر بالاتر است ولی چون کالا در بازار و فروشگاه های دیگر موجود نبود به ناچار با 140 هزار تومان گرانتر خریداری شد.
کالا ارسال شد…
کالا یک عدد لنز کنون بود
تاریخ خرید 24/5/94 بود و برگه گارانتی که همراه کالا بود تاریخ ثبت را 92/10/7 زده بود
لنز را روی دوربین وصل کردم متوجه لکه های داخل عدسی شدم لنز را باز کردم دیدم داخل لنز یک تار مو و چند لکه هست محل اتصال را با دقت نگاه کردم که متوجه سایدگی دور محل اتصال شدم
که نشان میدهد لنز استفاده شده
با بامیلو تماس گرفتم و موارد را بیان کردم
با کمال تعجب گفتند ما از تامین کننده این کالا را گرفیتم و باید با ایشان بررسی شود
گفتم به من چه ربطی دارد؟ من از شما گرفتم که در و دیوار را از تبلیغ پر کردید و قیمت هایتان نیز بالاتر است…من در این تاریخ سفارش دادم کارت گارانتی برای دو سال پیش است…
بالاخره گقت پس بفرستید تا بررسی کینم
پس فرستادم تماس گرفتن که بررسی شد و چون کالا در انبار تامیین کننده بود این موارد پیش امده
گفتم خانم این لنز استفاده شده و اگر هم اکبند بوده ، در انبار با لگد اینور انورش کردن که پر از لک است
خلاصه کالا را برای من فرستاند و من 3 ماه درگیر شکایت هستم و کارم بجایی نرسیده هنوز
اینماد هم یک مترسک است برای خالی نبودن عریضه در اصل فقط همان چیز نمادین است و هیچ اعتبار و اطمینانی ندارد.

 

راجع به نظر احسان گفته شده است:

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

 

خانم یا آقای موسوی گفته:

سلام
روزتون بخیر
دوستان من یک گوشی Galaxy Ace 4 از توی سایت بامیلو سفارش دادم که توی سایت مشخصاتش رو 2 هسته ای و با دوربین 5 نوشته بود(G313HU) وقتی گوشی رو دریافت کردم و دیدم روش نوشته Galaxy ace 4 جعبه رو باز کردم شروع کردم به تست کردن که دیدم گوشی خیلی کنده و کیفیت دوربینش خیلی پایین به خاطر همین شک کردم که شاید همون گوشی نباشه باری همین با جستجو متوجه شدم که این گوشی دو مدل G313HU و G313H داره که مدلی که برای من فرستادن تک هسته ای هست و دوربین 3.2
حالا با بامیلو هرچی تماس میگیرم میگن چون باز کردی پس نمیگیریم خوب شما خودتون رو بزارید جای من ، من از کجا باید میدونستم که Galaxy ace 4 دو مدل داره و از کجا باید میدونستم باید از کجای رو جعبه تشخیص بدم چیه اصلا من نمیدونستم که اونی که سفارش دادم G313HU هست و فکر میکردم همین اسم ace 4 کفایت میکنه من خبره بازار موبایل نیستم که از همه این چیزها سر در بیارم و از رو جعبه گوشی که تا حالا ندیدم تشخیص بدم اون گوشی که سفارش دادم نیست
دوستان میخواستم نظر شما رو بدونم ایا حق با من هست یا بامیلو که نمیخواد گوشی رو پس بگیره
از فاکتور و گوشی عکس گرفتم ضمیمه کردم
چیزی که من متوجه شدم این هست که بامیلو جنس هایی رو که تامین کننده هاش میفرستن رو اگر مشتری برگشت بزنه با کمال میل قبول میکنه ولی اگر تامین کننده جنس خودش باشه
حاضره خریدار ضرر کنه و لی خودش ضرر نبینه

وحید درباره نظر موسوی گفته:

  • اگر چیزی که نوشته بوده اینی نیست که براتون فرستاده معامله قابل فسخ است
    یک قائده مشهور فقهی و قانونی هست .
    «العقود تابعة للقصود» معامله تابع قصد است . وقتی چیزی که واقع شده اون چیزی نباشه که قصد شده معامله قابل قسخ است (ما قصد لم یقع و ما وقع لم یقصد)

    یکی از شرایط قصد اشتباه در موضوع معامله است
    مواد 199، 200، و 201 قانون مدنی حکم کلی اشتباه را بیان داشته است; ماده 199 بطور عام از اشتباه و انواع آن صحبت کرده است. ماده 200 در مورداشتباه در موضوع عقد و ماده 201 اشتباه در شخص طرف معامله و تعدادی دیگر ازمواد قانون مدنی بطور پراکنده، درباره اشتباه در موضوع عقد است ; از جمله ماده 353 که در رابطه با اشتباه در جنس موضوع عقد و موادی از قانون مدنی است که احکام خیارات، تدلیس، عیب و… را بیان می دارد. اشتباه در انواع موضوع قرارداد

    البته چون چیزی که شما خریده اید کلی فی الذمه است (مالی که مثل های فراوانی دارد ) فروشکاه باید انچه کهتعهد کرده به شما بدهد

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

 

امیری گفته:

از باميلو يه surface سفارش دادم.
قبل از سفارش زنگ زدم گفتم کيبورد داره يا نه گفتن سفارش رو ثبت کنيد بعد زنگ بزنيد روی سفارش يادداشت بزاريم.
سفارش رو ثبت کردم.
بعد زنگ زدم گفتم بنويسيد اگر کيبورد نداره نميخوام.
فرداش زنگ زدن گفتن کيبورد داره.
گفتم کيبوردش چه رنگی هست.
گفتن بهت زنگ ميزنيم.
ظهرش زنگ زدن گفتن کيبوردش رنگ بدنه هست دکمه هاش هم مشکی هست.
گفتم بفرستيد
فرداش صبح surface رو اوردن دم در
دادم بچه ها چک کنن و تو همون زمان خودم کارت رو کشيدم (اين يک اشتباه از من بود) چون نخواستم پيک معطل بشه
تا کارت رو کشيدم بچه ها گفتن کيبورد نداره
پيک زنگ زد به انبار گفت اينا کيبورد نداره
گفتم اونهمه يادداشت رو سفارش هست شما بخون ببين من گفتم بدون کيبورد نميخوام
خلاصه همون موقع دادم پيک برگردوند
3 روز بعدش هم پول رو پس دادن

وقتی زنگ زدم پشتيبانيشون برای پيگيری پول خودش تعجب کرد گفت اينجا اينهمه ياداشت هست که کيبورد داشته باشه کيبورد اين رنگی هست و اينا آخرش بدون کيبورد فرستادن برای شما.
يک نکته جالب هم اين بود که سفارش رو با کوپن تخفيف 200 هزار تومانی ثبت کرده بودم.
بعد ازينکه بدون کيبورد اوردن و سفارش کنسل شد کوپن من هم سوخت شد.
چون حرصم گرفته بود پشت تلفن بهشون گفتم شما هيچ وقت نميتونيد جای ديجی کالا در ايران رو بگيريد. گفت ما از شما دلجویی ميکنيم.
بعد از چند روز زنگ زدن گفتن ميخوايم از شما دلجویی کنيم. گفتم دمشون گرم الان يک کوپن 500 هزار تومنی بهم ميدن
گفت يک کوپن 40 هزار تومانی براتون در نظر گرفتيم. بهم برخورد گفتم نميخوام. گفتم من کلا ديگه از سايت شما چيزی سفارش نميدم.
شماره سفارش هم 300781692 هست.

#کمپین_ما_از_بامیلو_خرید_نمیکنیم_درش_را_ببندید #شکایت_از_بامیلو  #نارضایتی_بامیلو

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

#کمپین_ما_از_بامیلو_خرید_نمیکنیم_درش_را_ببندید #شکایت_از_بامیلو  #نارضایتی_بامیلو

فهرست شیندلر Schindler’s List

2 آوریل 17

فهرست شیندلر Schindler’s List
مطلبی که در لینکداین درباره این فیلم مشاهده کردم:
حالا که تعطیلیه ممکنه برای خیلیها فراغتی ایجاد کرده باشه .فیلم بی نظیری رو به اهل دانش و دانشگاه و تجارت و کسب وکار پیشنهاد میدم ببینن! مطمئنم اونایی که دیدن همین الان هوس کردن یک بار دیگه ببین! اگر فردی باشه ساعاتی از زندگیشو صرف تماشای فیلم یا خوندن داستان کرده و این فیلم رو ندیده باشه راحت اون مثل “نصف عمرت بر فناست” رو درموردش میشه بکار برد :)).
ذکر این نکته مهمه فیلم رو فارغ از اما و اگرهای صحت و مستند بودن تاریخی و مذهبی ماجرا ببنید .چون هنوز دعوا های زیادی در صحت تاریخی بعضی از بخشهای داستان هست و واقعا برای یادگرفتن خیلی چیزا نیازی نیست ذهن درگیرش بشه مگه علاقه خاصی به تاریخ نگاری داشته باشه! اما از منظر داستان پردازی حقیقت گرا یا به قول اهل فن رئالیسم مجموعه ای بی نظیر از حقایق جاری در دنیای کسب و کار و فرهیختگی و نظامی گریه. تضمین میکنم اگه بار اول باشه این فیلم رو میبینید، وقتی پا شدید انگار از صدتا کارگاه موفقیت،فن بیان،جامعه شناسی و روانشناسی و…برگشتید. لطفا کسانی که این فیلم رو دیدن و با من هم نظرند بی توجه رد نشن! درج نظر کنند یا تو پست خودشون این فیلم رو معرفی کنند یا لفظی به دوستان پیشنهاد بدن تا دیگران به تماشای یک فیلم و داستان درجه یک ترقیب شن!

Schindler's List (فهرست شیندلر)

و نظر بنده راجع به فیلم:
خطر لو رفتن داستان!
اول راجع به نظرات دوستان: به نظر بنده شاهکار اصلی فیلم داستان اونه که اسپیلبرگ بزرگ با تواضع روایتتش کرده اساسا از منظر فیلمسازی اسپیلبرگ متعهد به داستان بوده و سعی نکرده توانایی هاشو به رخ بکشه. این نکته هم جالبه که تنوع داستان هایی که اسپیلبرگ روایت کرده بینظره. این فیلم داستان قدیمی رو روایت میکنه ولی فیلم خیلی قدیمی هم محسوب نمیشه و کاملا روایت مدرنی رو داره و در دهه ۱۹۹۰ تا ۲۰۰۰ سرشار از فیبم هاییه با داستانهای بی نظیر و روایت بدون اشکال. داستان از موسیقی هم بالاتر رفته و فیلم و همه چیزو تحت الشعاع قرار داده. فیلم سرشار از نکات آموزنده و جذابه ولی بولد ترینشون برای من تماشای سیر تحول اسکار شیندلر بود که با نیت اقتصادی و ماهی گرفتن از اب گل آلود وارد شد (نشون اش هم ماجرای عصبانی شدن از کینگزلی بخاطر استخدام مرد یک دست) و رفته رفته تبدیل به قدیسی میشه که هدفش فقط نجات جون انسانها و مقابله با فاشیسته. از اون فیلم بلندهاست که اخرش میگی چه زود تموم شد و زمان حس نکردی.

ویکی پدیا
imdb
دانلود
نقد مفصل فیلم

سازمان های فناوری اطلاعات و حلقه ی مفقود ارزیابی و نظارت

19 مارس 17

عموما ارزیابی نیروهای فنی به طور صحیح انجام نمیشه‌. تنها مدیر مستقیم شناخت کافی داره مگر اینکه خود نیرو خیلی خیلی برونگرا! باشه یا مدیر خیلی خیلی با عزت نفسی داشته باشه که بدون ترس از دست دادن موقعیت خودش فیدبک صحیحی رو به مدیران لایه بالاتر برسونه. حالا مهمتر از ارزیابی نیروهای فنی ارزیابی مدیران اجرایی لایه میانیه چون اونا هستن که سرعت موفقیت یک سازمان رو تعیین می کنن حالا موضوع اینجاست که برخلاف شرکت های معتبر خارجی، در ایران ارزیابی این لایه از مدیران غالبا انجام نمیشه یعنی حداقل من ندیدم که بیان از کارشناسا راجع به مدیرشون فیدبک بگیرن.
کلا در شرکت های بزرگ سازوکار نظارت خیلی خوب پیاده نمیشه. راه حل این موضوع اینه که موقع ای که یک ceo داره کارش را آغاز می کند enviorment management plan که من اسمشو گذاشتم emp را به طور کامل بچینه. لزومی نداره همه role ها از روز اول جایگذاری بشه اما در big picture آن plan تهیه شده آورده بشه و به تدریج جایگذاری شود.
این emp شامل موارد زیادی میشه که در یک مقاله مستخرج از کتابچه راهنمای emp که در حال تدوین آن هستم آورده شده است. مثل روش های مختلف ارزیابی سلسله مراتبی و گرافی، ایجاد حلقه ناظرین ارزیاب و جانشین ceo که به این گروه نظارت میکند و بسیاری موارد دیگر که به حث ارزیابی مرتبط نیست.

سیمرغ، سیاست زدگی، مرگ واره! نگاهی به جشنواره فیلم فجر ۳۵

11 فوریه 17

اول از همه نگاهی بندازیم به نحوه تقسیم سیمرغ های جشنواره ۳۵

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

دعوا از جایی شروع شد که برنامه سینمایی ۷ شروع به زدن جشنواره و انتقادهای صریح نسبت به فیلم ها و نحوه برگزاری آن داشت.

فشارها برای اعمال سلیقه به هیئت داوران به این نحو بود که فیلم ماجرای نیمروز بهتر از سایر فیلم هاست.

و از انتخاب نامزدها بر می آمد که داوران فیلم تابستان داغ را بیشتر پسندیدند.

نتیجه جالب بود همان فیلم ماجرای نیمروز بیشترین جوایز رو برد و نشان داد که نظر داوران نیز به نظر برنامه ۷ نزدیک است.

نکته ای که برای من مهم بود جدا از دعوای افخمی و ایوبی یا نظرات سیاست زده و غیر استاندارد فراستی و سایرین و شاید ماجرای محیرالعقولی که افخمی راجع به کشورهای خارجی و کانادا میگفت و… این بود که حتی با اینکه بیشترین جوایز به ماجرای نیمروز داده شد باز هم محل اصلی انتقاد با داوری ها که همین فیلم بود تغییر نکرد و باز هم انتقادها ادامه داشت.

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