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

ان المزج بين رفع مستوى خدمة الزبون والحاجة للحفاظ على نظم الشركة من الضغط الذي قد ينجم عن اقبال كثيف من المستخدمين, وحمايتها من القرصنة, يستدعي ان تقدم الخدمة عبر عدة طبقات. طبقة 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.

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

كيف تربط بين عدة تطبيقات WEB تعمل بتكنولوجيا مختلفة (weblogic and .NET)

مشاركة Session بين تطبيقات web

اذا كان عندك عدة تطبيقات كل تحت خادم مختلف لنفرض IIS والاخر weblogic وتريد ان تشارك الاولى ذات ال Session مع الاخرى, هذه الحاجة كثيرا ما تحصل في شركات التي لا تقوم ببناء التطبيقات في مبنى الشركة, وتدخل تطبيقات من تقنيات مختلفه وجاهزه (تطبيقات من الرف) لسداد احتياجاتها.

من اجل التبسيط :

لنفرض ان لديك موقع اول وفيه تعرض منتوجات للبيع (منتوج,صورة,سعر) ومن خلاله يختار الزبون المنتوجات والكمية التي يود شراءها لنفرض http://catalog4me_bmawasy.com.

وفي موقع اخر (تحت خادم اخر) لديك تطبيق معد لان يجري عملية المحاسبة والدفع,لنفرض https://pay4me_bmawasy.com

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

فكيف يمكن ذلك ؟

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

يمكنك ان تقوم بالتالي :

1- الموقع الاول وعند الضغط على زر الدفع وفي جهة الخادم (server side) وقبل الانتفال الى موقع الدفع يقوم ب :

a. بناء XML يحتوي على المتغيرات المحفوظة في الSESSION والمنتوجات التي جمعها الزبون.

مثال :

<userdata>
<attribute name="username" value="bombalia"></attribute>
<attribute name="firstName" value="عواد"></attribute>
<attribute name="lastname" value="عواودة"></attribute>
<basketitems>
<item id="1212" name="حليب" count="12" price="10" unit="علبة لتر"></item>
<item id="2351" name="بندورة" count="2" price="3" unit="كغم"></item>
</basketitems>
</userdata>

b. بناء ما يدعى token والذي هو عبارة عن رقم او جملة عشوائية طويلة يصعب توقعها, مثال

token=AsC32AVvcgbb692-dfdf5fb5w43r

c. تخزين ال token و ال userdata في قاعدة بيانات مشتركة (يمكن للتطبيقين ان يتصلا بها)

d. يوجه المتصفح عند الزبون الى عنوان الموقع الثاني (موقع الدفع) ويضم العنوان قيمة الtoken التي تم انتاجها للتو, مثال :

https://pay4me_bmawasy.com?token=AsC32AVvcgbb692-dfdf5fb5w43r&source=http://catalog4me_bmawasy.com

2- على الموقع الثاني ان يتعرف على محتويات السلة وتفاصيل الزبون التي جمعت من قبل, فعليه استعمال المتغير token

فيتوجه الى قاعدة البيانات ويطلب الXML التابع لtoken.

3- يجب محو سطر الtoken من قاعدة البيانات حتى نحفظ ان لا يتم استعماله من قبل هاكرز.

4- تعرض الفاتورة حسب ما رجع من ال XML ليدفعها الزبون ويكمل مشواره فرحا بما اشتراه :)

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

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

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

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

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

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

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

فما الحل ؟

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

الحل الاول :

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

الحل الثاني:

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

الحل الثالث:

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

الحل الرابع :

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

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

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

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

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