Microservices بالعربي

الكورس يناقش مفهوم الميكرو سيرفس ومشاكلها.

الميكرو سيرفس هي طريقة لبناء الأنظمة وليس تقنية جاهزة.

المزايا تشمل قابلية التوسع والتطوير بشكل مستقل لكل خدمة.

المشاكل تشمل التعامل مع البيانات المشتركة وضمان التزامن.

النقاش يتطرق إلى كيفية إدارة التران잭شن بين الخدمات المختلفة.

تم ذكر أدوات مثل Kafka و Graphana لتحليل الأداء ومراقبة النظام.

أحد الحلول هو استخدام الكاش Redis لتقليل الحمل على قاعدة البيانات.

التحكم في الـ API rate limit يتم عبر أدوات مثل Redis.

النقاش يشمل كيفية نقل البيانات بين قواعد بيانات مختلفة دون وقت تعطل.

تم تقديم عرض عملي (Demo) لكيفية عمل النظام باستخدام Docker و Kubernetes.

Introduction to Kafka and its use cases.

Kafka is designed for high-throughput data processing, not just reading books.

Kafka's architecture includes brokers, topics, partitions, and offsets.

Data replication in Kafka ensures durability but requires significant storage.

Kafka uses Zookeeper for managing metadata and leader elections.

Kafka supports real-time data streaming and microservices communication.

Key concepts include producers, consumers, topics, and partitioning.

Producers write data to topics, while consumers read from them.

Kafka guarantees message ordering within a partition.

Consumer groups allow parallel processing of data across partitions.

Rebalancing occurs when consumers join or leave a consumer group.

Kafka stores data on disk in segments for efficient retrieval.

Configuration options affect performance, such as batch size and linger time.

Kafka handles failures through replication and leader re-election.

Common issues include data duplication and rebalancing delays.

Use cases discussed include order tracking, metrics aggregation, and event sourcing.

Kafka is suitable for complex, large-scale applications requiring reliable data delivery.

Introduction to the podcast discussing Kafka and its applications.

Discussion on Kafka's transaction concept and its implementation in distributed systems.

Explanation of the problem with message duplication in distributed transactions.

The scenario where a producer sends messages and faces issues like network failure or broker crash.

How Kafka handles message delivery assurance and the idempotent producer feature.

Detailed breakdown of Kafka's transaction mechanism, including transaction markers and offsets.

Challenges with reading uncommitted data and how Kafka consumers handle this using isolation levels.

Illustration of potential problems when mixing transactional and non-transactional producers.

Importance of understanding Kafka’s transaction feature before implementation.

Closing remarks encouraging questions from listeners for future discussions.

Introduction of the podcast host, Ahmed Imam, and guest, Eng. Mohamed Yehia.

Discussion on the importance of contributing to Arabic content in software engineering.

Eng. Mohamed Yehia shares his experience starting in software engineering in 2004 with Microsoft technologies.

The main topic is about separating read and write operations in a system for better data management.

Explanation of challenges faced when scaling applications and handling complex data operations.

Introduction to using different patterns like CQRS (Command Query Responsibility Segregation) to solve these issues.

Detailed discussion on implementing CQRS and its benefits in complex systems.

Importance of understanding business logic and validation before designing system architecture.

Challenges of maintaining data consistency across different databases and microservices.

Use of event sourcing as a solution to track changes and maintain data history.

Audience questions addressed, including the use of transactions with message brokers and examples of read model usage.

Closing remarks emphasizing the value of learning and sharing knowledge within the tech community.

Introduction of Moustafa Mansour, a respected software engineer working at Microsoft Copenhagen.

Discussion on distributed transactions and their importance in software engineering.

Explanation of the difference between queries and transactions in databases.

Importance of Atomicity, Consistency, Isolation, and Durability (ACID) properties in database transactions.

Detailed explanation of isolation levels and problems like Dirty Reads, Non-Repeatable Reads, and Phantom Reads.

Concurrency Control methods including Optimistic and Pessimistic approaches.

Real-life incident about GitLab data loss due to incorrect transaction handling and backup issues.

Explanation of locking mechanisms in transactions and how they affect performance.

Comparison between Orchestration and Choreography design patterns for microservices.

Advantages and disadvantages of using Orchestration vs. Choreography in distributed systems.

The role of Correlation IDs in tracking events across services in Choreography-based systems.

Closing remarks appreciating Moustafa for sharing his knowledge and insights.

The discussion is about the challenges and considerations of transitioning from a monolithic architecture to microservices.

The speaker emphasizes that microservices should not be adopted just for the sake of it but when there is a clear problem they can solve.

One major issue with monolithic systems is the difficulty in managing large teams and complex codebases, leading to slow release cycles.

Microservices introduce their own set of challenges, such as increased complexity in deployment, network communication, and data consistency.

The speaker discusses the importance of understanding domain boundaries before splitting services and ensuring that teams are aligned with these domains.

A common mistake is over-separation of services, which can lead to unnecessary coupling or dependencies between them.

The conversation highlights the need for strong communication and coordination between teams when working with microservices.

Technical decisions, like choosing programming languages or databases, should be based on team expertise and project requirements rather than trends.

The speaker shares practical advice on handling database migrations, versioning APIs, and managing backward compatibility during transitions.

The importance of security checks, automated testing, and enforcing best practices across teams is emphasized to avoid technical debt.

Martin Fowler’s concept of 'If you're not prepared for big bang, don't break things apart' is mentioned as a guiding principle.

The talk concludes by stressing the need for organizational alignment and a shift in mindset to successfully adopt microservices.

الكومونكيشن بين السيرفيسز في المايكرو سيرفيسز مهم جداً ويجب أن يكون واضحًا للجميع.

استخدام الكومونكيشن السنكروني يسبب مشاكل مثل توقف النظام عند حدوث فشل في أحد السيرفيسز.

يجب علينا استخدام أساليب غير سنكرونية لتحسين الأداء وتقليل التبعيات بين السيرفيسز.

الاعتماد على الـ REST API ليس دائمًا الحل الأمثل بسبب التكلفة العالية من حيث الأداء والموارد.

يمكن استخدام بروتوكولات أخرى مثل gRPC لتحل محل REST API وتحسن الأداء بشكل كبير.

الـ Event-Driven Architecture تساعد في حل مشكلة التبعية بين السيرفيسز باستخدام الكيو (Queues).

من المهم التعامل مع الإصدارات المختلفة للبيانات (Versioning) لضمان توافق الإصدارات القديمة والجديدة.

الـ Backward Compatibility وForward Compatibility ضروريان لتجنب تعطل النظام عند تحديث البيانات أو الهياكل.

وجود ميكانيزم Retry مهم جدًا لمعالجة الفشل المؤقت في استقبال الرسائل أو تنفيذ العمليات.

يجب التعامل مع مشكلة فقدان البيانات أو تكرارها باستخدام Dead Letter Queue (DLQ) لتخزين الرسائل التي لم يتم معالجتها بنجاح.

الـ Idempotency مهمة جدًا لضمان عدم تنفيذ العملية أكثر من مرة إذا تم إرسال نفس الطلب عدة مرات.

تقسيم الرسائل باستخدام Topics يساعد في تحسين الأداء ومنع ازدحام النظام.

الـ Protobuf يعتبر أفضل من JSON من حيث الحجم والأداء لأنه يوفر طريقة أكثر كفاءة لتسلسل البيانات.

الـ Schema Definition في gRPC يساعد في تحديد شكل البيانات بدقة مما يقلل من أخطاء الاتصال بين السيرفيسز.

التعامل مع الـ Streams في gRPC يسمح بإرسال واستقبال بيانات بشكل مستمر دون الحاجة إلى انتظار رد لكل طلب.

السلام عليكم، هذا بودكاست عن المايكرو سيرفيسز يركز على موضوع الـ Communication Patterns.

المشكلة الرئيسية التي ناقشناها هي كيفية تحسين التواصل بين الخدمات باستخدام أنماط اتصال مختلفة.

تحدثنا عن مشكلة الـ Synchronous Communication حيث يؤدي تعطل خدمة واحدة إلى توقف النظام بالكامل.

تم تقديم حلول مثل استخدام الـ Message Queue لتقليل التبعيات المباشرة وتحسين الأداء.

أوضحنا أهمية الـ Event-Driven Architecture لتفادي المشاكل المرتبطة بالتواصل المتزامن.

ذكرنا أمثلة عملية حول كيفية عمل الـ API Gateway مع الخدمات المختلفة باستخدام REST أو gRPC.

شرحنا مفهوم Backward Compatibility وForward Compatibility في التعامل مع الإصدارات المختلفة للبيانات.

تم التركيز على أهمية استخدام البروتوكولات الفعالة مثل Protocol Buffers بدلاً من JSON لتقليل حجم البيانات.

ناقشنا مشكلة فقدان الرسائل أو استلامها بشكل متكرر عند استخدام Queues وكيفية التعامل معها.

تم شرح كيفية تنظيم Topics وأهميتها في تصنيف الأحداث داخل النظام.

أظهرنا مثالاً عمليًا لكيفية بناء نظام Microservices باستخدام gRPC و Protocol Buffers.

أكدنا على أهمية وضع آليات Retry ومعالجة الأخطاء لضمان استقرار النظام.

تحدثنا عن تقسيم النظام إلى وحدات صغيرة وإعادة استخدام الكود لتحقيق كفاءة أعلى.

أوضحنا كيف يمكن إدارة الإصدارات القديمة والجديدة للبيانات دون إيقاف النظام.

ختمنا الحلقة بتوضيح أهمية تصميم جيد للنظام لتجنب المشاكل المستقبلية.