لا علاقة لهندسة MACH المعمارية برقم ماخ (وهو مقياس للسرعة) أو بنواة ماخ الموجودة تحت نظام GNU Hurd؛ إنه اختصار لبناء برمجيات المؤسسات من أجزاء قابلة للاستبدال. يرمز MACH إلى الخدمات المصغرة (Microservices)، والواجهة البرمجية أولاً (API-first)، والسحابية الأصل (Cloud-native)، وعديمة الرأس (Headless)، ويتم الترويج له من قبل تحالف MACH، وهو هيئة صناعية غير ربحية تأسست في عام 2020. يحدد هذا الدليل كل ركيزة بلغة واضحة، ويقارن MACH بنهجي الكتلة المتجانسة (monolith) وSOA اللذين يحل محلهما، ويوضح مكانه، بما في ذلك نظرة على منصة الواجهات البرمجية (API platform) التي ستستخدمها لبيئة الخدمات المصغرة.
ماذا يعني MACH حقًا
MACH هي مجموعة من مبادئ التصميم، وليست منتجًا يمكنك شراؤه. كل حرف يمثل مبدأ واحدًا، ولا يعتبر النظام متوافقًا مع MACH إلا إذا اتبع جميع المبادئ الأربعة. تحالف MACH صارم في هذا الشأن: إظهار سمة أو اثنتين لا يؤهله لذلك.
إليك الاختصار بلمحة سريعة.
| الحرف | المبدأ | ماذا يعني |
|---|---|---|
| M | الخدمات المصغرة (Microservices) | كل قدرة عمل هي خدمة مستقلة قابلة للنشر |
| A | الواجهة البرمجية أولاً (API-first) | كل وظيفة مكشوفة عبر واجهة برمجية، ومصممة قبل كتابة الكود |
| C | السحابية الأصل (Cloud-native) | مبنية للعمل كـ SaaS على البنية التحتية السحابية، مرنة ومدارة |
| H | بلا واجهة (Headless) | الواجهة الأمامية مفصولة عن الواجهة الخلفية وتتواصل عبر الواجهات البرمجية |
الفكرة هي قابلية التركيب (composability). فبدلاً من منتج واحد كبير يقوم بكل شيء، تقوم بتجميع أفضل الخدمات المتخصصة التي تقوم كل منها بشيء واحد، ويمكنك استبدال أي منها دون إعادة بناء الباقي. وهذا هو نفس الهدف وراء حركة "المؤسسات القابلة للتركيب" الأوسع؛ MACH هي الوصفة التقنية التي تجعل قابلية التركيب ممكنة.
الخدمات المصغرة (Microservices)
تجمع الكتلة المتجانسة كل ميزة في قاعدة بيانات واحدة ونشر واحد. تفصل الخدمات المصغرة ذلك. يصبح كتالوجك وعربة التسوق والبحث ومنطق الدفع كل منها خدمة منفصلة ببياناتها الخاصة ودورة إصدارها الخاصة. يمكن لفريق واحد شحن خدمة البحث يوم الثلاثاء دون المساس بخدمة سلة التسوق على الإطلاق.
المقايضة هي التعقيد التشغيلي. أنت الآن تدير العديد من الخدمات، والعديد من قواعد البيانات، والكثير من استدعاءات الشبكة بينها. إذا كنت تريد النسخة الطويلة، فراجع تطبيق الكتلة المتجانسة مقابل الخدمات المصغرة.
الواجهة البرمجية أولاً (API-first)
تعني الواجهة البرمجية أولاً أن الواجهة البرمجية هي نقطة البداية، وليست مجرد فكرة لاحقة. تقوم بتصميم العقد ونقاط النهاية وأشكال الطلبات والاستجابات، قبل أن يكتب أي شخص التنفيذ. تصل كل قدرة في نظام MACH إلى العالم الخارجي من خلال تلك الواجهة البرمجية، لذا يصبح العقد هو السطح الفعلي للمنتج.
هذه هي الركيزة التي تؤثر بشكل أكبر على كيفية عمل الفرق يوميًا، وهي المكان الذي تهم فيه الأدوات أكثر من غيره. سنعود إليها أدناه. للمبادئ، يغطي تطوير الواجهة البرمجية أولاً الأساس.
السحابية الأصل (Cloud-native)
تتجه السحابية الأصل (Cloud-native) بمعنى MACH بقوة نحو SaaS. يتم بناء المكونات لتشغيلها على البنية التحتية السحابية وعادة ما يتم استهلاكها كخدمات مدارة. لا تقوم بتصحيح الخوادم أو تخطيط السعة لارتفاع حركة المرور؛ فالخدمة تتوسع بمرونة ويتعامل البائع مع التحديثات. وهذا يختلف عن "لقد نقلنا تطبيقنا القديم إلى جهاز افتراضي في السحابة". تعني السحابية الأصل أن البرنامج قد صُمم لتلك البيئة منذ البداية.
بلا واجهة (Headless)
تقسم "بلا واجهة" (Headless) طبقة العرض عن منطق الأعمال. لا تحتوي الواجهة الخلفية على واجهة أمامية مدمجة؛ بل تقدم البيانات والعمليات فقط عبر واجهات برمجية. يستفيد موقعك الإلكتروني، تطبيقك المحمول، ساعتك الذكية، كشكك، أو مساعدك الصوتي من نفس الواجهات البرمجية ويقدم كل منها تجربته الخاصة.
المكافأة هي الوصول. يمكن لجهة خلفية واحدة أن تغذي العديد من الواجهات الأمامية، ويمكنك إعادة تصميم واجهة المتجر دون ترحيل محرك التجارة الأساسي. تصبح الواجهة البرمجية عديمة الرأس هي المنتج لأنها الطريقة الوحيدة للوصول.
MACH مقابل الكتلة المتجانسة (monolith) مقابل SOA
من المفيد معرفة موقع MACH مقارنة بالأنماط التي سبقته.
| الكتلة المتجانسة (Monolith) | SOA | MACH | |
|---|---|---|---|
| وحدة النشر | تطبيق واحد | خدمات خشنة على ناقل | خدمات مصغرة دقيقة الحبيبات |
| التكامل | استدعاءات داخل العملية | ناقل خدمة المؤسسة (Enterprise service bus)، غالبًا SOAP | واجهات برمجية خفيفة الوزن REST/GraphQL |
| الواجهة الأمامية | مقترنة، تُعرض من الخادم | غالبًا مقترنة | بلا واجهة، مفصولة تمامًا |
| الاستضافة | خوادم تديرها بنفسك | محلية أو مستضافة | SaaS سحابية الأصل |
| استبدال مكون | إعادة بناء وإعادة نشر | صعبة، مقترنة بالناقل | استبدال خدمة واحدة |
الكتلة المتجانسة سريعة في البدء وسهلة الفهم، وهذا هو السبب في أنها لا تزال الخيار الصحيح للعديد من الفرق الصغيرة. حاولت SOA تفكيك الأنظمة قبل عقد من الزمان ولكنها غالبًا ما كانت مركزية كل شيء على ناقل خدمة ثقيل، والذي أصبح بدوره نقطة اختناق. تحافظ MACH على فكرة التفكيك وتتخلى عن الناقل، وتربط الخدمات بواجهات برمجية عادية وتدفع الاستضافة إلى السحابة.
MACH هو في الأساس الإجابة الحديثة لعصر السحابة على السؤال الذي طرحته SOA. إذا كنت تريد الخريطة الأوسع للأنماط، فإن أنماط هندسة الواجهات البرمجية توضحها.
متى تتبنى MACH (ومتى لا تتبناها)
يحل MACH مشاكل حقيقية، لكنه ليس مجانيًا. تبناه عندما تتوافق القيود.
مناسب تمامًا عندما:
- وصلت إلى أقصى حدود منصة متجانسة، ودورات الإصدار بطيئة لأن كل شيء يُشحن معًا.
- تحتاج فرق متعددة للعمل بالتوازي دون أن يتدخل أحدها في عمل الآخر.
- تقدم محتوى أو تجارة لقنوات متعددة (الويب، الجوال، داخل المتجر) وترغب في واجهة خلفية واحدة خلف كل منها.
- ترغب في تبديل البائعين لقدرة معينة دون إعادة بناء المنصة بالكامل.
فكر مرتين عندما:
- تكون فريقًا صغيرًا بمنتج بسيط. فالعبء التشغيلي للعديد من الخدمات وخطوط الأنابيب والعقود سيبطئك أكثر مما تفعله الكتلة المتجانسة.
- لا تملك مهارات المنصة بعد. يفترض MACH الإلمام بالبنية التحتية السحابية، وCI/CD، وتصميم الواجهة البرمجية.
- حركة المرور وفريقك مستقران ومتواضعان. قد لا تُستخدم المرونة التي تدفع ثمنها أبدًا.
المسار الصادق الشائع هو البدء بكتلة متجانسة منظمة جيدًا، ثم فصل الخدمات مع ظهور نقاط ضعف محددة. ليس عليك أن تتبنى MACH بالكامل في اليوم الأول.
النظام البيئي للأدوات
صُممت MACH لتكون محايدة للبائعين، لكن المنشأة النموذجية تستمد من بضع فئات:
- أنظمة إدارة المحتوى بلا واجهة (Headless CMS) للمحتوى، مثل Contentstack أو Contentful.
- محركات التجارة بلا واجهة أو القابلة للتركيب مثل commercetools.
- البحث والتخصيص كخدمات واجهة برمجية منفصلة.
- شبكات توصيل المحتوى (CDN) والحافة (edge) للتوصيل السحابي الأصلي، وغالبًا ما تقترن بواجهة أمامية على غرار Jamstack. وثائق Jamstack من Netlify مرجع مفيد لجانب الواجهة الأمامية المفصولة.
- بوابات الواجهات البرمجية والهوية لتوجيه وتأمين ومصادقة حركة المرور عبر الخدمات.
الخيط الذي يربط كل ذلك معًا هو الواجهة البرمجية (API). كل مربع في تلك القائمة يتحدث مع الآخرين عبر عقد، لذا فإن جودة تلك العقود تحدد ما إذا كان النظام بأكمله سيصمد.
حيث يصبح عقد الواجهة البرمجية هو المنتج
هذا هو حرف "A" في MACH، وهو الجزء الذي تتحكم فيه بشكل مباشر. في نظام عديم الرأس يعتمد على الخدمات المصغرة، لا يتفاعل أحد مع خدمتك من خلال واجهة المستخدم التي قمت ببنائها. بل يتفاعلون مع الواجهة البرمجية (API). لذلك، العقد هو المنتج، ويحتاج إلى نفس العناية التي يتلقاها أي منتج: التصميم، النماذج الوهمية (mocks)، الاختبارات، والوثائق.
Apidog هي طبقة جودة الواجهة البرمجية لهذا العمل. إنه ليس نظام إدارة محتوى (CMS)، أو محرك تجارة، أو بوابة، ولا "ينفذ" MACH أو الخدمات عديمة الرأس لك. إنه المكان الذي تتعامل فيه مع العقد نفسه:
- تصميم OpenAPI أولاً. تحدد عقد كل خدمة مصغرة في Apidog قبل التنفيذ، بحيث تتفق الفرق المستهلكة على الشكل مسبقًا.
- خوادم وهمية (Mock servers). ينشئ Apidog نماذج وهمية من المواصفات، بحيث يمكن لفريق الواجهة الأمامية البناء مقابل واجهة برمجة تطبيقات سلة التسوق قبل وجود خدمة سلة التسوق. تتوقف الفرق المفصولة عن عرقلة بعضها البعض.
- تنفيذ الاختبارات عديمة الرأس. يقوم واجهة سطر الأوامر (CLI) لـ Apidog بتشغيل اختبارات الواجهة البرمجية الخاصة بك بدون واجهة رسومية، مباشرة في CI، وهو يتناسب مع نظام عديم الرأس: يتم التحقق من العقد بواسطة الآلات، وليس بالنقر يدويًا.
- MCP للوكلاء. من خلال MCP، يمكنك إدارة والاستعلام عن الواجهة البرمجية من وكيل الذكاء الاصطناعي الخاص بك أو بيئة التطوير المتكاملة (IDE)، بحيث يظل العقد متاحًا من الأدوات التي يستخدمها فريقك بالفعل.
هذا يجعل Apidog أمينًا لدوره. فهو يمتلك ركيزة "الواجهة البرمجية أولاً"، لذلك تظل خدماتك موصوفة جيدًا وقابلة للاختبار والنمذجة عبر المنشأة. يظهر نفس التفكير في الواجهة البرمجية كمنتج، وهو بالضبط العقلية التي يفرضها عليك MACH. هل تريد تجربتها؟ قم بتنزيل Apidog ووجهه إلى مواصفات خدمة واحدة.
أسئلة مكررة
هل MACH هو نفسه الهندسة المعمارية القابلة للتركيب؟
هما مرتبطان ارتباطًا وثيقًا ولكنهما ليسا متطابقين. الهندسة المعمارية القابلة للتركيب هي فكرة العمل الأوسع: بناء نظامك من أجزاء قابلة للتبديل يمكنك إعادة تجميعها. MACH هو النمط التقني المحدد (الخدمات المصغرة، الواجهة البرمجية أولاً، السحابية الأصل، بلا واجهة) الذي يجعل قابلية التركيب قابلة للتحقيق. يمكنك اعتبار MACH هو المخطط الهندسي لمؤسسة قابلة للتركيب.
هل أحتاج إلى أن أكون عضوًا في تحالف MACH لاستخدام MACH؟
لا. تحالف MACH هو منظمة غير ربحية تصادق على البائعين وفقًا للمبادئ الأربعة، مما يساعد المشترين على تحديد المنتجات القابلة للتركيب حقًا. يمكنك بناء نظام MACH بالكامل من أدوات غير أعضاء، أو حتى خدماتك الخاصة. المبادئ مفتوحة؛ العضوية هي شهادة بائع، وليست ترخيصًا لاستخدام النمط.
ما الفرق بين MACH وإعداد الخدمات المصغرة العادي؟
الخدمات المصغرة هي إحدى ركائز MACH الأربع، وليست كل شيء. الواجهة الخلفية للخدمات المصغرة مع واجهة أمامية مرتبطة بإحكام واستضافة محلية ليست MACH. يضيف MACH انضباط الواجهة البرمجية أولاً، ونموذج SaaS السحابي الأصلي، والفصل عديم الرأس. إذا كنت تختار البنية التحتية للخدمات، فإن كيفية اختيار منصة واجهة برمجية للخدمات المصغرة يشرح ما يجب مراعاته.
هل MACH مخصص للتجارة الإلكترونية فقط؟
بدأت في التجارة، حيث يكون استبدال بائع لعملية دفع أو بحث دون إعادة بناء المنصة ذا قيمة واضحة، لكن النمط ينطبق في أي مكان تقدم فيه قنوات متعددة من منطق خلفي مشترك. تستخدم منتجات الإعلام والبنوك والسفر والـ SaaS جميعها الفصل بأسلوب MACH.
تجميع الكل معاً
MACH هي طريقة لبناء البرمجيات من أجزاء قابلة للاستبدال: خدمات مصغرة للنشر المستقل، واجهة برمجية أولاً بحيث يكون لكل قدرة عقد نظيف، سحابية الأصل بحيث تتوسع كـ SaaS، وبلا واجهة بحيث تغذي واجهة خلفية واحدة العديد من الواجهات الأمامية. إنها قوية عندما يكون لديك النطاق والفرق لاستخدامها، ومبالغ فيها عندما لا يكون لديك.
مهما كان توجهك، فإن عقد الواجهة البرمجية هو الجزء الذي يتحمل الحمل. عندما يكون العقد هو المنتج، صممه جيدًا، وقم بعمل نماذج وهمية مبكرًا، واختبره في CI. يمنحك Apidog طبقة جودة الواجهة البرمجية هذه بحيث تظل بيئة MACH الخاصة بك موصوفة جيدًا من الخدمة الأولى إلى الأخيرة.