نظام انترنتي متعدد الطبقات

ان المزج بين رفع مستوى خدمة الزبون والحاجة للحفاظ على نظم الشركة من الضغط الذي قد ينجم عن اقبال كثيف من المستخدمين, وحمايتها من القرصنة, يستدعي ان تقدم الخدمة عبر عدة طبقات. طبقة 1, طبقة 2, الشبكة المحلية.

ما هي الطبقات ؟

هنالك عدة تعريفات للطبقات في هذا الخصوص, طبقات في البرنامج layers, وطبقات التوزيع الشبكي للخدم (servers tier) , ان الفصل بين مكونات التطبيق يمكًن من اضافة عناصر اخرى للحماية من الاخطار, وكذلك يضاعف من جاهزية الشركة لأضافة servers ان استدعت الحاجة لذلك.

الفصل الذي اتكلم عنه هنا هو الفصل الشبكي.

الطبقة الاولى (1):

هي الطبقة التي يكون فيها الخادم الذي يتصل به المستخدم مباشرة, عادة ما تدعى presintation (طبقة العرض)

الطبقة الثانية (2):

هي الطبقة التي تربط بين النظم الداخلية والخادم الامامي في طبقه 1. (middle tier), وتدعى في كثير من الأحيان البنية التحتية.

الشبكة الداخلية :

فيها تتواجد انظمة الشركة الاساسية (CRM, Billing, ERP, BI) واخرى.

الفاصل بين الطبقات :

ان وضع firewall يهدف لحماية الخادم والنظم من تعرضها للقرصنة بشكل اساسي. فيمكن التحكم عن طريقه بقناة اللاتصال والثغرات المفتوحة (firewall) بين الخادم وبين المسنخدم, وهو عبارة عن برنامج يمكن التحكم بمعاييره حسب الحاجه كأن يفتح port 80 فقط, لمنع الاتصال باي جهاز غير الخادم.

جهاز توزيع الضغط Load Balance والذي من وظيفته ان يستقبل الطلبات وان يوزعها على الخدم الخلفية وحسب معايير تضمن توزيع الضغط ليضمن تواصل الخدمة لكل المستخدمين, هناك عدة خوارزميات لتوزيع الضغط مثل :

1- The round-robin algorithm: واساسه ان كل خادم يتلقى الطلب القادم حسب الدور بشكل دوري فكل خادم يقدم

نفس عدد الخدمات.
2- Persistent IP : وهو توزيع الخدمة بين الخدم حسب IP المستخدم. فان ذلك يوزع الضغط بشكل عشوائي نوعا ما,

لكنه يضمن ان كل مستخدم يرجع في العمل امام نفس الخادم.

قاعدة بيانات المستخدمين:

من المفضل ان تتواجد هذه الوحدة في الطبقة الثانية حتى يقلل من امكانة تعرضها للقرصنة مباشرة عبر الانترنت وان يتركز

الاتصال بها عبر الخادم الأمامي والخلفي من خلال التطبيقات.

طرق الاتصال بين الطبقات :

هناك بروتوكولات كثيرة لربط الطبقات والإتصال بينها, من اسهلها واكثرها انتشارا webservice, rmi,com وأحدثها wcf.

طبعا هذه البروتوكولات تسهل من القدرة على توسعة التطبيقات واستغلال البنيه التحتية في عدة تطبيقات مستقبلية.

كيف يمكن منع تعرض الموقع للتجمد !!

هنالك بعض المواقع المعدة لاعطاء الخدمة الذاتية للزبائن. ومثل هذه المواقع عليها ان تكون متصلة في كثير من الاحيان مع النظم الداخلية للشركة, وهذا الاتصال عادة ما يكون عن طريق webservice, قد يتعرض الموقع للتجمد اذا حصل التالي في ذات الوقت :

1. اذا كان اقبال كبير على الموقع في ساعات الضغط.
2. اذا كانت نظم الشركة تعاني الضغط في ذات الوقت بسبب إما الصيانة او تشغيل معالجة معطيات (تجهيز حساب فواتير مثلا).

في مثل هذه الحالة ما سيحصل هو عبارة عن ازدحام كما في السير الى درجة التجمد في الموقع على الweb. اذا حاولت دخوله في هذه اللحظة فانك لن تلقى اي رد من الخادم لفترة طويلة والتي قد تصل الى عدة دقائق في بعض الاحيان ان صح الحال.

لماذا يحدث هذا؟

ان الخادم قادر على ان يعطي الخدمة لحد معين من الاتصالات به requests في ذات الوقت, في حال ان قام الطلب الاول "request" والذي من خلاله على الخادم ان يشغل معالجة داخل نظم الشركة والتي تعاني الضغط عبر ال webservice فان على ال webservice الانتظار حتى ينتهي تنفيذ دوره, لكن العالم ليس ملكك وحدك, ففي ذات الوقت بينما انت في الانتظار سياتي زبزن اخر ويطلب ذات الخدمة وعليه الانتظار ايضا. والزبون الاخر سيأتي ايضا بعد ثوان او اقل, وكلما زاد الوقت زاد المنتظرون وزادوا وزادوا....... حتى ان لا يتمكن الخادم من استيعاب الطب الاخير والذي زاد الحد الذي يقدر عليه.

عندها فان الزبائن الاخرين لن يتمنكوا من عرض حتى صفحة HTML عادية خالية من اي معالجة معطيات, فما ذنبهم !! ولماذا هم ايضا ينتظرون. ولم لا نحل لهم المشكلة !!

فما الحل ؟

هناك كثير من الحلول التي يمكن ان تساعد في حل هذا الحال, ولكن يجب ان تدرس ملائمة الحل مع امكانيات الشركة المادية, الوقت المتاح لتجهيزه, وملائمته للنطم في الشركة, واذا كان من الممكن الدمج بينها فان ذلك افضل كثيرا .

الحل الاول :

قد يدور في البال اضافة خادم انترنت امامي, لكن هذا لن يساعد كثيرا ومن المرجح انه اذا وصل الحال ان تجمد الموقع من الضغط عليه فان خادم اضافي قد يخدم بعض الزبائن الاضافيين ويتجمد ايضا. فاذا دخل المستخدم الاضافي وطلب صفحة فيها معالجة معطيات تعتمد على النطم الداخلية فان عليه الانتظار طويلا (دقائق) ليضاف الى قائمة المنتظرين لنرجع لنفس الحال, هذا والاهم من ذلك فانه لن يتلقى الخدمة من الخادم فهو عادة غير مستعد للانتظار لدقائق حتى تتم معالجة معطياته.

الحل الثاني:

مما يتبين فان المشكلة ليست كامنة في خادم الانترنت بل في النظم الداخلية, فهي مصدر التعويق (عنق الزجاجة), اذا يمكن نظريا تحسين وظيفة النظم الداخلية بالبحث عن معالجات تعيق السير (مثل, SQL غير مفحوص من قبل, مشكلة في شبكة الاتصال الداخلية, مشكلة مساحات تخزين, تشغيل نظم تخزين اضافي (backup) في توقيت غير مناسب, تشغيل antivirus في توقيت غير مناسب, او معالجة بيانات ضخمة في ذات الوقت بدل ان تقسم الى مراحل مثل تجهيزحسابات وانتاج تقارير طويلة اخرى).

الحل الثالث:

اضافة خادم للنظم الداخلية حتى يتم تحسين اداءها, طبعا هذا الحل ليس سهلا ولا رخيصا دائما, وقد تكون تكوينة النظم الداخلية لا تسمح بمثل هذا الحل.

الحل الرابع :

عليك ان تدخل بعض التغييرات في تصميم التطبيق على النت ليعمل بالشكل التالي,

1.تقسيم الخدمات في الموقع الى قسمين اساسيين, عرض بيانات GET, ومعالجة طلبات (Process).

1. فيما يتعلق بمعالجة طلبات فالعمل بصورة asynchronic (طلب المعالجة لا ينتظر الرد), فان الزبون عندما يطب مثلا ان يسجل لخدمة معينة فسيتم تنفيذها لاحقا,
وتعرض له اجابة من نوع "تلقينا طلبك وسيتم تنفيذها لاحقا". وهناك طرق كثيرة لتحقيق ان ينفذ الطلب.

2.فيما يتعلق بعرض بيانات, فالهدف واضح, فان المستخدم عادة لا يقبل الانتظار طويلا امام الشاشة, فالحل الامثل هو ان تعطي في تصميم تطبيقق امكانية توقيت حد اقصى (timeout), والذي يتلائم مع نوع الخدمة.

ان ذلك يقلل من انتظار المستخدم حتى وان تلقى ردا من نوع "نأسف , هذا الخدمة غير متوفرة حاليا", وبالمقابل فان يقلل دور المنتظرين, فتحديد وقت للخدمة يعطي نتائج مضاعفة عن اضافة خادم. ان ذلك يعطيك القدرة على التحكم بالردود على الطلبات المتواردة على التطبيق, ويعطي انطباعا افضل لدى المستخدم.

كيف تحافظ على نظم الشركة من الهاكرز مع ادخال خدماتك عن طريق الانترنت

ان الشركات اليوم تعمل جاهدة على تحسين الخدمة للزبائن وفي ذات الوقت ان تزيد من ارباحها.

وتجد هذه الشركات الحلول في استعمال الانترنت للتواصل مع الزبائن بصورة اسرع ومقللة من الحاجة الى توظيف موظفين في هذا المجال.

ما يجب ان يؤخذ بعين الاعتبار هو المحافظة على نظم الشركة من التعرض للقرصنة من قبل الهاكرز, لذلك يجب التقيد بالضوابط المبدأية التالية :

1. يجب ان تحمي حظيرة الانتاج باستعمال firewall ونظام Proxy الذين يقللان بدورهما من طلب خدمات من الخادم غير متطابقه مع تصميم الموقع واهدافه
2. ان يتم الفصل بين الخادم للانترنت والنظم الداخلية باستعمال Firewall
3. ان يقوم الاتصال بين خادم الانترنت والنظم الداخلية عن طريق بروتوكولات اتصال معروفة ك SOAP او RMI او ,Web Services ومن خلال وحدة اتصال مركزية حتى تتم مراقبتها بصورة افضل.
4. ان تقوم البرامج من الطرفين بتحديد نوع البيانات التي تتوقع استقبالها (رقمية تاريخ احرف خاصة او لا وطول البيانات)
5. استخدام وسائل امنية للتاكد من خلو البيانات المتداولة بين الطرفين من جمل قرصنة (SQL Injection) مثلا او Javascript , ومحتويات خطرة اخرى.
6. تشفير الاتصال بشيفرات SSL المعروفة (Https) والتي تمنع من سرقة (او الاطلاع على محتوى الاتصال بين الطرفين).

طبعا هذا قليل من كثير وللمزيد ساعرض التركيب المثالي لاحقا ان شاء الله بالصور.

كيف يمكن زيادة الاعلان من دون تكلفة

استكمالا لما بدأته من قبل فهذه مركيات لنظام بعث رسائل ميل للزبائن مع اضافة دعاية مخصصة حسب مواصفات الزبون.

لنفرض ان لديك قائمة من الزبائن من فئات مختلفة : أصحاب ورش, أصاحب مطاعم, معلمين وكذا. وبودك نشر اعلانات تتلائم وكل فئة من خلال الميل الشهري او اي ميل يصدر منك اليهم.

عليك اولا ان تتجهز بالتالي:

1- جمع بيانات عن الزبائن حسب احتياجات التقسيم الذي تنويه

2- التزود بنظام رسائل الكترونية متطور ليتحمل الكميات التي يتم بعثها

3- نظام لصق اعلانات لمحتوى الرسالة

4- نظام بناء محتوى الرسالة وتصنيف الزبون كجزء من فحوى الرسالة

كيف يعمل ذلك

هناك شركات تستعمل البريد الالكتروني بشكل اساسي للتواصل مع زبائنها, كارسال الفاتورة مثلا, او تقارير شهرية, او حتى بريد في اطار خدمة الزبون.

كما مبين في الشكل فان العملية تمر بالمراحل التالية :

1. جمع بيانات الزبائن

هذه العملية عادة ما تكون الاصعب, اذ انها مرتبطة بمدى اهتمام الشركة في هذا الامر, مدى جاهزيتها وجاهزية نظمها لجمع المعطيات من

الزبائن , واكثر صعوبة هو جاهزية الزبون للتفاعل مع الموضوع. فتفاصيله الشخصية وطبيعة العمل الذي يعمل به ليست مما يرغب الزبون ان يعطيها عادة.

جمع المعطيات يتم من خلال استغلال فرص التماس مع الزبون في مراحل مختلفة على سبيل المثال :

مرحلة عرض الشراء والبيع, عند تواجد الزبون في المتجر مثلا.

• مرحلة الخدمة, اذا رجع الزبون لتلقى خدمة اضافية, فهذه ايضا فرصة مثالية.
• عند التسجيل للموقع اذا كانت الشركة تعرض خدماتها عبر الانترنت.

من المهم ان تجمع هذه البيانات في قاعدة معطيات محوسبة (قاعدة بيانات نظام CRM- نظام ادارة العلاقات مع الزبائن).

2. اعداد الدعايات

على الدعاية ان تكون من نوع html, والذي يمكن اضافته كDIV في نهاية الرسالة الاصلية. دعايات من نوع HTML يمكنها ان تكون

الامثل لعدة اسباب :

• يمكن ان تتضمن عدة انواع (نص, فلاش, صور, رابط الى موقع الشركة للتفاصيل...)
• يمكن ان تتضمن javascript الذي يعطي تقارير عن من يضغط على الروابط ويمكن من اعداد احصائيات عن كيفية التفاعل من قبل الزبائن.
• ارفاق الدعاية لا يثقل فحوى الرسالة من ناحية الحجم لما في ذلك من مشاكل في خادم الميل (الرسائل)

على الدعايات ان تكون متلائمة مع تصنيف الزبائن طبعا حسب الحاجة. لكل دعاية يرفق التصنيف المعدة له.

اعداد الرسائل يمكن ان يتم عن طريق محرر HTML عادي وليس بالشيئ الخاص.

3. إرسال الرسائل - المرحله الأولى :

ان الشركات اليوم تسعى للحفاظ على البيئة :) والتقليل من نفقاتها, وفي هذا السبيل انها تعتمد المراسلة عبر الميل.

نأخذ على سبيل المثال الفاتورة الشهرية :

بعد ان جمعت بيانات الزبون يمكن تصنيفه بالتصنيف المناسب, وهذا التصنيف يدخل كجزء من موضوع الرسالة,

مثال واحد من الاتي :

*** أعمال حرة *** فاتورة حساب

*** ممرضين *** فاتورة حساب

*** فنادق *** فاتورة حساب

واترك المجال للخيال......

ابعث الرسالة عبر SMTP "خاص" الذي يعمل على اضافة الدعاية المناسبة للرسالة حسب التصنيف (هناك نظم خاصة في السوق التي تعطي هذه الخدمة.

4. إرسال الرسائل - المرحله الثانية :

يقوم ال SMTP بالتعرف على نوع الدعاية التي يجب الصاقها من خلال قراءة موضوع الرسالة:

*** تصنيف *** فاتورة حساب , فيقوم بإضافة الدعاية في نهاية الرسالة. ومن ثم يغير موضوع الرسالة فيحذف التصنيف ليبقى الموضوع "فاتورة حساب".

للمزيد من المعلومات والتفاصيل اتصل بي على العنوان الخاص او اكتب تعليقك