لقد أمضيت أشهرًا في إعادة تصميم وحدتك المتجانسة وتحويلها إلى خدمات صغيرة، وأخيرًا اجتمع الجميع معًا لقلب المفتاح. تذهب إلى صفحة الويب الأولى... ولا يحدث شيء. قمت بإعادة تحميله - ومرة أخرى لا شيء جيد، الموقع بطيء جدًا لدرجة أنه لا يستجيب لعدة دقائق. ماذا حدث؟
في حديثه، سيقوم جيمي بوجارد بإجراء "تشريح" لكارثة الخدمات الصغيرة الواقعية. سيعرض مشاكل النمذجة والتطوير والإنتاج التي اكتشفها، وكيف قام فريقه بتحويل الكتلة الموزعة الجديدة ببطء إلى الصورة النهائية للعقل. على الرغم من أنه من المستحيل منع أخطاء التصميم بشكل كامل، إلا أنه يمكنك على الأقل تحديد المشكلات في وقت مبكر من عملية التصميم لضمان أن المنتج النهائي يصبح نظامًا موزعًا موثوقًا به.
مرحبًا بالجميع، أنا جيمي واليوم ستسمعون كيف يمكنك تجنب الكوارث الكبرى عند إنشاء الخدمات الصغيرة. هذه قصة شركة عملت بها لمدة عام ونصف تقريبًا للمساعدة في منع سفينتهم من الاصطدام بجبل جليدي. لسرد هذه القصة بشكل صحيح، سيتعين علينا العودة بالزمن والتحدث عن المكان الذي بدأت فيه هذه الشركة وكيف تطورت البنية التحتية لتكنولوجيا المعلومات الخاصة بها بمرور الوقت. ولحماية أسماء الأبرياء في هذه الكارثة، قمت بتغيير اسم هذه الشركة إلى Bell Computers. توضح الشريحة التالية كيف كانت تبدو البنية التحتية لتكنولوجيا المعلومات لهذه الشركات في منتصف التسعينيات. هذه بنية نموذجية لخادم HP Tandem Mainframe كبير عالمي متسامح مع الأخطاء لتشغيل متجر أجهزة الكمبيوتر.
لقد احتاجوا إلى إنشاء نظام لإدارة جميع الطلبات والمبيعات والمرتجعات وكتالوجات المنتجات وقاعدة العملاء، لذلك اختاروا حل الحواسيب المركزية الأكثر شيوعًا في ذلك الوقت. يحتوي هذا النظام العملاق على كل جزء من المعلومات حول الشركة، وكل شيء ممكن، ويتم تنفيذ كل معاملة من خلال هذا الكمبيوتر الرئيسي. لقد احتفظوا بكل بيضهم في سلة واحدة واعتقدوا أن هذا أمر طبيعي. الشيء الوحيد الذي لم يتم تضمينه هنا هو كتالوجات الطلبات عبر البريد وتقديم الطلبات عبر الهاتف.
بمرور الوقت، أصبح النظام أكبر وأكبر، وتراكمت فيه كمية هائلة من القمامة. كما أن لغة COBOL ليست اللغة الأكثر تعبيرًا في العالم، لذلك انتهى الأمر بالنظام إلى أن أصبح قطعة كبيرة متجانسة من الخردة. بحلول عام 2000، رأوا أن العديد من الشركات لديها مواقع ويب يمكن من خلالها إجراء جميع أعمالهم، وقرروا إنشاء أول موقع ويب تجاري لهم على شبكة الإنترنت.
بدا التصميم الأولي جميلًا للغاية ويتكون من موقع bell.com عالي المستوى وعدد من النطاقات الفرعية للتطبيقات الفردية: catalog.bell.com، وحسابات.bell.com، وorders.bell.com، وبحث المنتج search.bell. com. استخدم كل نطاق فرعي إطار عمل ASP.Net 1.0 وقواعد البيانات الخاصة به، وتحدثوا جميعًا إلى الواجهة الخلفية للنظام. ومع ذلك، استمرت معالجة جميع الطلبات وتنفيذها داخل حاسوب مركزي ضخم واحد، حيث بقيت كل القمامة، ولكن الواجهة الأمامية كانت عبارة عن مواقع ويب منفصلة مع تطبيقات فردية وقواعد بيانات منفصلة.
لذلك بدا تصميم النظام منظمًا ومنطقيًا، لكن النظام الفعلي كان كما هو موضح في الشريحة التالية.
جميع العناصر موجهة إلى بعضها البعض، وواجهات برمجة التطبيقات التي تم الوصول إليها، وملفات dll المضمنة التابعة لجهات خارجية، وما شابه ذلك. لقد حدث غالبًا أن أنظمة التحكم في الإصدار ستلتقط كود شخص آخر، وتدفعه داخل المشروع، وبعد ذلك يتعطل كل شيء. استخدم MS SQL Server 2005 مفهوم خوادم الارتباط، وعلى الرغم من أنني لم أظهر الأسهم على الشريحة، إلا أن كل قاعدة من قواعد البيانات تحدثت أيضًا مع بعضها البعض، لأنه لا حرج في بناء الجداول بناءً على البيانات التي تم الحصول عليها من عدة قواعد بيانات.
وبما أن لديهم الآن بعض الفصل بين المناطق المنطقية المختلفة للنظام، فقد أصبح هذا عبارة عن نقاط من الأوساخ الموزعة، مع بقاء أكبر قطعة من القمامة في الواجهة الخلفية للحاسب المركزي.
والشيء المضحك هو أن هذا الكمبيوتر الرئيسي تم بناؤه بواسطة منافسين لشركة Bell Computers وما زال مستشاروهم الفنيون يقومون بصيانته. واقتناعا منها بالأداء غير المرضي لتطبيقاتها، قررت الشركة التخلص منها وإعادة تصميم النظام.
كان التطبيق الحالي قيد الإنتاج لمدة 15 عامًا، وهو رقم قياسي للتطبيقات المستندة إلى ASP.Net. تقبل الخدمة الطلبات من جميع أنحاء العالم، وقد وصلت الإيرادات السنوية من هذا التطبيق الواحد إلى مليار دولار. تم تحقيق جزء كبير من الأرباح من خلال موقع bell.com. وفي أيام الجمعة السوداء، وصل عدد الطلبات المقدمة عبر الموقع إلى عدة ملايين. ومع ذلك، فإن البنية الحالية لم تسمح بأي تطوير، لأن الترابط الصارم لعناصر النظام لم يسمح عمليا بإجراء أي تغييرات على الخدمة.
كانت المشكلة الأكثر خطورة هي عدم القدرة على تقديم طلب من دولة ما، ودفع ثمنه في دولة أخرى وإرساله إلى دولة ثالثة، على الرغم من أن مخطط التداول هذا شائع جدًا في الشركات العالمية. لم يسمح موقع الويب الحالي بأي شيء من هذا القبيل، لذلك كان عليهم قبول هذه الطلبات وتقديمها عبر الهاتف. وأدى ذلك إلى تفكير الشركة بشكل متزايد في تغيير البنية، ولا سيما فيما يتعلق بالتحول إلى الخدمات الصغيرة.
لقد فعلوا الشيء الذكي من خلال النظر إلى الشركات الأخرى لمعرفة كيف قاموا بحل مشكلة مماثلة. وكان أحد هذه الحلول هو بنية خدمة Netflix، والتي تتكون من خدمات صغيرة متصلة عبر واجهة برمجة التطبيقات (API) وقاعدة بيانات خارجية.
قررت إدارة شركة Bell Computers إنشاء مثل هذه البنية مع الالتزام بمبادئ أساسية معينة. أولاً، قاموا بإزالة ازدواجية البيانات باستخدام نهج قاعدة البيانات المشتركة. ولم يتم إرسال أية بيانات، بل على العكس من ذلك، كان على كل من يحتاجها أن يتوجه إلى مصدر مركزي. وأعقب ذلك العزلة والاستقلالية - حيث كانت كل خدمة مستقلة عن الأخرى. لقد قرروا استخدام Web API في كل شيء على الإطلاق - إذا كنت تريد الحصول على البيانات أو إجراء تغييرات على نظام آخر، فقد تم كل ذلك من خلال Web API. كان آخر شيء كبير هو حاسب مركزي جديد يسمى "Bell on Bell" بدلاً من حاسب "Bell" المركزي المعتمد على أجهزة المنافسين.
لذلك، على مدار 18 شهرًا، قاموا ببناء النظام حول هذه المبادئ الأساسية ووضعوه في مرحلة ما قبل الإنتاج. بالعودة إلى العمل بعد عطلة نهاية الأسبوع، اجتمع المطورون وقاموا بتشغيل جميع الخوادم التي كان النظام الجديد متصلاً بها. 18 شهرًا من العمل، ومئات المطورين، وأحدث أجهزة Bell - ولا توجد نتيجة إيجابية! لقد خيب هذا آمال الكثير من الأشخاص لأنهم قاموا بتشغيل هذا النظام على أجهزة الكمبيوتر المحمولة الخاصة بهم عدة مرات وكان كل شيء على ما يرام.
لقد كانوا أذكياء في إنفاق كل أموالهم على حل هذه المشكلة. لقد قاموا بتثبيت أحدث رفوف الخادم مع المفاتيح، واستخدموا ألياف جيجابت الضوئية، وأقوى أجهزة الخادم مع كمية هائلة من ذاكرة الوصول العشوائي، وقاموا بتوصيلها كلها، وتكوينها - ومرة أخرى، لا شيء! ثم بدأوا في الشك في أن السبب قد يكون انتهاء المهلة، لذلك قاموا بالدخول إلى جميع إعدادات الويب، وجميع إعدادات واجهة برمجة التطبيقات (API) وقاموا بتحديث تكوين المهلة بالكامل إلى الحد الأقصى للقيم، بحيث كل ما يمكنهم فعله هو الجلوس وانتظار حدوث شيء ما إلى الموقع. لقد انتظروا وانتظروا وانتظروا لمدة 9 دقائق ونصف حتى تم تحميل الموقع أخيرًا.
بعد ذلك، اتضح لهم أن الوضع الحالي يحتاج إلى تحليل شامل، فدعونا. أول شيء اكتشفناه هو أنه خلال 18 شهرًا من التطوير، لم يتم إنشاء "ميكرو" حقيقي واحد - كل شيء أصبح أكبر. بعد ذلك، بدأنا في كتابة تقرير ما بعد الوفاة، المعروف أيضًا باسم "الأثر الاسترجاعي"، أو "الأثر الاسترجاعي الحزين"، والمعروف أيضًا باسم "عاصفة اللوم"، على غرار "العصف الذهني"، لفهم سبب الكارثة.
كان لدينا العديد من الأدلة، أحدها كان التشبع الكامل لحركة المرور في وقت استدعاء واجهة برمجة التطبيقات. عند استخدام بنية خدمة متجانسة، يمكنك فهم الخطأ الذي حدث على الفور لأن لديك تتبع مكدس واحد يُبلغ عن كل ما يمكن أن يكون سببًا في الفشل. في حالة وصول مجموعة من الخدمات في نفس الوقت إلى نفس واجهة برمجة التطبيقات، فلا توجد طريقة لتتبع التتبع باستثناء استخدام أدوات مراقبة الشبكة الإضافية مثل WireShark، والتي بفضلها يمكنك فحص طلب واحد ومعرفة ما حدث أثناء تنفيذه. لذلك أخذنا صفحة ويب واحدة وأمضينا ما يقرب من أسبوعين في تجميع قطع اللغز معًا وإجراء مجموعة متنوعة من الاستدعاءات لها وتحليل ما أدى إليه كل منها.
أنظر لهذه الصورة. يوضح أن طلبًا خارجيًا واحدًا يطالب الخدمة بإجراء العديد من المكالمات الداخلية التي تعود مرة أخرى. اتضح أن كل مكالمة داخلية تقوم بقفزات إضافية حتى تتمكن من خدمة هذا الطلب بشكل مستقل، لأنه لا يمكن أن تتحول إلى أي مكان آخر للحصول على المعلومات اللازمة. تبدو هذه الصورة وكأنها سلسلة من المكالمات لا معنى لها، حيث يستدعي الطلب الخارجي خدمات إضافية، والتي تستدعي خدمات إضافية أخرى، وهكذا، إلى ما لا نهاية تقريبًا.
يُظهر اللون الأخضر في هذا الرسم البياني نصف دائرة تتصل فيه الخدمات ببعضها البعض - الخدمة "أ" تستدعي الخدمة "ب"، والخدمة "ب" تستدعي الخدمة "ج"، وتستدعي الخدمة "أ" مرة أخرى. ونتيجة لذلك، نحصل على "حالة توقف تام موزعة". أدى طلب واحد إلى إنشاء ألف استدعاء لواجهة برمجة التطبيقات (API) للشبكة، وبما أن النظام لم يكن مزودًا بميزة التسامح مع الأخطاء وحماية الحلقة المضمنة، فسيفشل الطلب حتى في حالة فشل إحدى استدعاءات واجهة برمجة التطبيقات (API) هذه.
لقد قمنا ببعض الرياضيات. كان لكل استدعاء لواجهة برمجة التطبيقات (API) اتفاقية مستوى الخدمة (SLA) لا تزيد عن 150 مللي ثانية ووقت تشغيل بنسبة 99,9%. تسبب طلب واحد في 200 مكالمة مختلفة، وفي أفضل الأحوال، يمكن عرض الصفحة في 200 × 150 مللي ثانية = 30 ثانية. وبطبيعة الحال، لم يكن هذا جيدا. بضرب 99,9% من وقت التشغيل في 200، حصلنا على 0% من التوفر. اتضح أن هذه الهندسة المعمارية كانت محكوم عليها بالفشل منذ البداية.
لقد سألنا المطورين كيف فشلوا في التعرف على هذه المشكلة بعد 18 شهرًا من العمل؟ اتضح أنهم قاموا فقط باحتساب اتفاقية مستوى الخدمة (SLA) للرمز الذي قاموا بتشغيله، ولكن إذا كانت خدمتهم تستدعي خدمة أخرى، فلن يحسبوا ذلك الوقت في اتفاقية مستوى الخدمة (SLA) الخاصة بهم. كل ما تم إطلاقه ضمن عملية واحدة التزم بقيمة 150 مللي ثانية، لكن الوصول إلى عمليات الخدمة الأخرى أدى إلى زيادة إجمالي التأخير عدة مرات. كان الدرس الأول المستفاد هو: "هل أنت مسيطر على اتفاقية مستوى الخدمة (SLA) الخاصة بك، أم أن اتفاقية مستوى الخدمة (SLA) هي المسيطرة عليك؟" وفي حالتنا، كان الأخير.
والشيء التالي الذي اكتشفناه هو أنهم كانوا على علم بمفهوم المفاهيم الخاطئة المتعلقة بالحوسبة الموزعة، والذي صاغه بيتر ديتش وجيمس جوسلينج، لكنهم تجاهلوا الجزء الأول منه. وتنص على أن العبارات "الشبكة موثوقة" و"زمن الوصول صفر" و"الإنتاجية اللانهائية" هي مفاهيم خاطئة. تتضمن المفاهيم الخاطئة الأخرى عبارات مثل "الشبكة آمنة"، و"الهيكل لا يتغير أبدًا"، و"هناك دائمًا مسؤول واحد فقط"، و"تكلفة نقل البيانات صفر"، و"الشبكة متجانسة".
لقد ارتكبوا خطأً لأنهم اختبروا خدمتهم على الأجهزة المحلية ولم يتصلوا مطلقًا بخدمات خارجية. عند التطوير محليًا واستخدام ذاكرة التخزين المؤقت المحلية، لم يواجهوا أبدًا قفزات الشبكة. طوال 18 شهرًا من التطوير، لم يتساءلوا أبدًا عما يمكن أن يحدث إذا تأثرت الخدمات الخارجية.
إذا نظرت إلى حدود الخدمة في الصورة السابقة، يمكنك أن ترى أنها كلها غير صحيحة. هناك الكثير من المصادر التي تقدم النصائح حول كيفية تحديد حدود الخدمة، ومعظمها يخطئ في ذلك، مثل Microsoft في الشريحة التالية.
هذه الصورة مأخوذة من مدونة MS حول موضوع "كيفية بناء الخدمات المصغرة". يُظهر هذا تطبيق ويب بسيطًا وكتلة من منطق الأعمال وقاعدة بيانات. يأتي الطلب مباشرة، ربما يكون هناك خادم واحد للويب، وخادم واحد للأعمال وواحد لقاعدة البيانات. إذا قمت بزيادة حركة المرور، سوف تتغير الصورة قليلا.
هنا يأتي موازن التحميل لتوزيع حركة المرور بين خادمي ويب، وذاكرة تخزين مؤقت موجودة بين خدمة الويب ومنطق الأعمال، وذاكرة تخزين مؤقت أخرى بين منطق الأعمال وقاعدة البيانات. هذه هي بالضبط الهندسة المعمارية التي استخدمتها شركة Bell لموازنة التحميل وتطبيق النشر الأزرق/الأخضر في منتصف العقد الأول من القرن الحادي والعشرين. حتى وقت ما، كان كل شيء يعمل بشكل جيد، لأن هذا المخطط كان مخصصًا لهيكل متجانس.
توضح الصورة التالية كيف توصي MS بالانتقال من وحدة متراصة إلى خدمات صغيرة - ببساطة تقسيم كل خدمة من الخدمات الرئيسية إلى خدمات صغيرة منفصلة. أثناء تنفيذ هذا المخطط ارتكب بيل خطأً.
لقد قسموا جميع خدماتهم إلى مستويات مختلفة، كل منها يتألف من العديد من الخدمات الفردية. على سبيل المثال، تضمنت خدمة الويب خدمات صغيرة لعرض المحتوى والمصادقة، وتتكون خدمة منطق الأعمال من خدمات صغيرة لمعالجة الطلبات ومعلومات الحساب، وتم تقسيم قاعدة البيانات إلى مجموعة من الخدمات الصغيرة ذات البيانات المتخصصة. كان كل من الويب ومنطق الأعمال وقاعدة البيانات بمثابة خدمات عديمة الحالة.
ومع ذلك، كانت هذه الصورة خاطئة تمامًا لأنها لم تحدد أي وحدات عمل خارج مجموعة تكنولوجيا المعلومات بالشركة. ولم يأخذ هذا المخطط في الاعتبار أي اتصال بالعالم الخارجي، لذلك لم يكن من الواضح كيفية الحصول، على سبيل المثال، على تحليلات أعمال الطرف الثالث. وألاحظ أنه كان لديهم أيضًا العديد من الخدمات التي تم اختراعها ببساطة لتطوير الحياة المهنية للموظفين الأفراد الذين سعوا إلى إدارة أكبر عدد ممكن من الأشخاص من أجل الحصول على المزيد من المال مقابل ذلك.
لقد اعتقدوا أن الانتقال إلى الخدمات الصغيرة كان سهلاً مثل أخذ البنية التحتية الداخلية للطبقة المادية من الطبقة N ولصق Docker عليها. دعونا نلقي نظرة على الشكل الذي تبدو عليه الهندسة المعمارية التقليدية من الطبقة N.
ويتكون من 4 مستويات: مستوى واجهة المستخدم UI، ومستوى منطق الأعمال، ومستوى الوصول إلى البيانات وقاعدة البيانات. الأكثر تقدمًا هو DDD (التصميم المبني على المجال)، أو البنية الموجهة نحو البرمجيات، حيث يكون المستويان الأوسطان عبارة عن كائنات المجال والمستودع.
حاولت أن أنظر إلى مجالات التغيير المختلفة، ومجالات المسؤولية المختلفة في هذه البنية. في تطبيق نموذجي من المستوى N، يتم تصنيف مجالات التغيير المختلفة التي تتخلل الهيكل عموديًا من الأعلى إلى الأسفل. هذه هي الكتالوج، وإعدادات التكوين التي يتم إجراؤها على أجهزة الكمبيوتر الفردية، وعمليات التحقق من الخروج، والتي تم التعامل معها بواسطة فريقي.
تكمن خصوصية هذا المخطط في أن حدود مجالات التغيير هذه لا تؤثر فقط على مستوى منطق الأعمال، بل تمتد أيضًا إلى قاعدة البيانات.
دعونا نلقي نظرة على ما يعنيه أن تكون خدمة. هناك 6 خصائص مميزة لتعريف الخدمة - وهي عبارة عن برنامج:
- تم إنشاؤها واستخدامها من قبل منظمة معينة؛
- مسؤول عن محتوى ومعالجة و/أو توفير نوع معين من المعلومات داخل النظام؛
- يمكن بناؤها ونشرها وتشغيلها بشكل مستقل لتلبية الاحتياجات التشغيلية المحددة؛
- يتواصل مع المستهلكين والخدمات الأخرى، ويقدم المعلومات بناءً على الاتفاقيات أو الضمانات التعاقدية؛
- تحمي نفسها من الوصول غير المصرح به، ومعلوماتها من الضياع؛
- يتعامل مع حالات الفشل بطريقة لا تؤدي إلى تلف المعلومات.
كل هذه الخصائص يمكن التعبير عنها بكلمة واحدة "الاستقلالية". تعمل الخدمات بشكل مستقل عن بعضها البعض، وتستوفي قيودًا معينة، وتحدد العقود التي يمكن للأشخاص على أساسها الحصول على المعلومات التي يحتاجون إليها. ولم أذكر تقنيات محددة، واستخدامها أمر بديهي.
الآن دعونا نلقي نظرة على تعريف الخدمات المصغرة:
- الخدمة الصغيرة صغيرة الحجم ومصممة لحل مشكلة واحدة محددة؛
- الخدمة الصغيرة مستقلة؛
- عند إنشاء بنية خدمات صغيرة، يتم استخدام استعارة تخطيط المدن. هذا هو التعريف من كتاب سام نيومان، بناء الخدمات المصغرة.
تعريف السياق المحدود مأخوذ من كتاب إيريك إيفانز "التصميم القائم على المجال". هذا هو النمط الأساسي في DDD، وهو مركز تصميم معماري يعمل مع النماذج المعمارية الحجمية، ويقسمها إلى سياقات محددة مختلفة ويحدد بوضوح التفاعلات بينها.
ببساطة، يشير السياق المحدود إلى النطاق الذي يمكن استخدام وحدة معينة فيه. وفي هذا السياق يوجد نموذج موحد منطقيًا يمكن رؤيته، على سبيل المثال، في مجال عملك. إذا سألت "من هو العميل" للموظفين المشاركين في الطلبات، فستحصل على تعريف واحد، وإذا سألت المشاركين في المبيعات، فستحصل على تعريف آخر، وسيعطيك فناني الأداء تعريفًا ثالثًا.
لذا، يقول السياق المحدود أنه إذا لم نتمكن من إعطاء تعريف واضح لما هو مستهلك خدماتنا، فلنحدد الحدود التي يمكننا من خلالها التحدث عن معنى هذا المصطلح، ثم نحدد نقاط الانتقال بين هذه التعريفات المختلفة. أي أننا إذا كنا نتحدث عن عميل من وجهة نظر تقديم الطلبات فهذا يعني هذا وذاك، وإذا كنا من وجهة نظر المبيعات فهذا يعني هذا وذاك.
التعريف التالي للخدمة الصغيرة هو تغليف أي نوع من العمليات الداخلية، مما يمنع "تسرب" مكونات عملية العمل إلى البيئة. ويأتي بعد ذلك «تعريف العقود الصريحة للتفاعلات الخارجية، أو الاتصالات الخارجية»، والتي تتمثل في فكرة العقود العائدة من اتفاقيات مستوى الخدمة. التعريف الأخير هو كناية عن الخلية، أو الخلية، ويعني التغليف الكامل لمجموعة من العمليات داخل الخدمة المصغرة ووجود مستقبلات للاتصال مع العالم الخارجي.
لذلك قلنا للعاملين في شركة Bell Computers، "لا يمكننا إصلاح أي من الفوضى التي خلقتها لأنك لا تملك المال للقيام بذلك، ولكننا سنصلح خدمة واحدة فقط لجعل كل شيء على ما يرام" حاسة." في هذه المرحلة، سأبدأ بإخبارك كيف قمنا بإصلاح خدمتنا الوحيدة بحيث استجابت للطلبات بشكل أسرع من 9 دقائق ونصف.
22:30 دقيقة
على أن تستمر قريبا جدا ...
بعض الاعلانات
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com