মিখাইল সালোসিন। গোলং মিটআপ। Look+ অ্যাপ্লিকেশনের ব্যাকএন্ডে Go ব্যবহার করে

মিখাইল সলোসিন (এর পরে – এমএস): - হাই সব! আমার নাম মিশেল. আমি MC2 সফ্টওয়্যারে ব্যাকএন্ড বিকাশকারী হিসাবে কাজ করি এবং আমি Look+ মোবাইল অ্যাপ্লিকেশনের ব্যাকএন্ডে Go ব্যবহার করার বিষয়ে কথা বলব৷

এখানে কেউ কি হকি পছন্দ করে?

তাহলে এই অ্যাপ্লিকেশনটি আপনার জন্য। এটি অ্যান্ড্রয়েড এবং আইওএসের জন্য এবং অনলাইনে বিভিন্ন খেলাধুলার ইভেন্টের সম্প্রচার দেখতে এবং রেকর্ড করার জন্য ব্যবহৃত হয়। অ্যাপ্লিকেশনটিতে বিভিন্ন পরিসংখ্যান, পাঠ্য সম্প্রচার, সম্মেলনের জন্য টেবিল, টুর্নামেন্ট এবং ভক্তদের জন্য দরকারী অন্যান্য তথ্য রয়েছে।

এছাড়াও অ্যাপ্লিকেশনটিতে ভিডিও মুহূর্তগুলির মতো একটি জিনিস রয়েছে, যেমন আপনি ম্যাচের সবচেয়ে গুরুত্বপূর্ণ মুহুর্তগুলি (গোল, মারামারি, শ্যুটআউট ইত্যাদি) দেখতে পারেন। আপনি যদি সম্পূর্ণ সম্প্রচারটি দেখতে না চান তবে আপনি শুধুমাত্র সবচেয়ে আকর্ষণীয়গুলি দেখতে পারেন৷

আপনি উন্নয়নে কি ব্যবহার করেছেন?

মূল অংশটি গো-তে লেখা ছিল। মোবাইল ক্লায়েন্টরা যে APIটির সাথে যোগাযোগ করেছিল সেটি Go-তে লেখা ছিল। মোবাইল ফোনে পুশ বিজ্ঞপ্তি পাঠানোর জন্য একটি পরিষেবাও Go-তে লেখা ছিল। আমাদেরও আমাদের নিজস্ব ORM লিখতে হয়েছিল, যেটা নিয়ে আমরা কোনো দিন কথা বলতে পারি। ঠিক আছে, কিছু ছোট পরিষেবা Go-তে লেখা ছিল: সম্পাদকদের জন্য চিত্রগুলি পুনরায় আকার দেওয়া এবং লোড করা...

আমরা ডাটাবেস হিসাবে PostgreSQL ব্যবহার করেছি। ActiveAdmin রত্ন ব্যবহার করে এডিটর ইন্টারফেসটি Ruby on Rails-এ লেখা হয়েছিল। একটি পরিসংখ্যান প্রদানকারী থেকে পরিসংখ্যান আমদানি করা রুবিতেও লেখা হয়।

সিস্টেম API পরীক্ষার জন্য, আমরা পাইথন ইউনিটটেস্ট ব্যবহার করি। মেমক্যাচেড এপিআই পেমেন্ট কল থ্রোটল করতে ব্যবহৃত হয়, কনফিগারেশন নিয়ন্ত্রণ করতে "শেফ" ব্যবহার করা হয়, জ্যাবিক্স অভ্যন্তরীণ সিস্টেম পরিসংখ্যান সংগ্রহ এবং নিরীক্ষণ করতে ব্যবহৃত হয়। Graylog2 হল লগ সংগ্রহের জন্য, স্লেট হল ক্লায়েন্টদের জন্য API ডকুমেন্টেশন।

প্রোটোকল নির্বাচন

আমরা যে প্রথম সমস্যাটির সম্মুখীন হয়েছিলাম: নিম্নলিখিত পয়েন্টগুলির উপর ভিত্তি করে ব্যাকএন্ড এবং মোবাইল ক্লায়েন্টদের মধ্যে মিথস্ক্রিয়া করার জন্য আমাদের একটি প্রোটোকল বেছে নিতে হবে...

• সবচেয়ে গুরুত্বপূর্ণ প্রয়োজন: ক্লায়েন্টদের ডেটা রিয়েল টাইমে আপডেট করতে হবে। অর্থাৎ, যারা বর্তমানে সম্প্রচার দেখছেন তাদের প্রায় সঙ্গে সঙ্গে আপডেট পাওয়া উচিত।
• জিনিসগুলি সহজ করার জন্য, আমরা ধরে নিয়েছি যে ক্লায়েন্টদের সাথে সিঙ্ক্রোনাইজ করা ডেটা মুছে ফেলা হয় না, তবে বিশেষ পতাকা ব্যবহার করে লুকানো হয়।
• সমস্ত ধরণের বিরল অনুরোধ (যেমন পরিসংখ্যান, দল গঠন, দলের পরিসংখ্যান) সাধারণ GET অনুরোধ দ্বারা প্রাপ্ত হয়।
• এছাড়াও, সিস্টেমটিকে একই সময়ে 100 হাজার ব্যবহারকারীকে সহজেই সমর্থন করতে হয়েছিল।

এর উপর ভিত্তি করে, আমাদের দুটি প্রোটোকল বিকল্প ছিল:

1. ওয়েবসকেট। কিন্তু আমাদের ক্লায়েন্ট থেকে সার্ভারে চ্যানেলের প্রয়োজন ছিল না। আমাদের শুধুমাত্র সার্ভার থেকে ক্লায়েন্টে আপডেট পাঠাতে হবে, তাই একটি ওয়েবসকেট একটি অপ্রয়োজনীয় বিকল্প।
2. সার্ভার-প্রেরিত ইভেন্টস (SSE) ঠিক ঠিক এসেছে! এটি বেশ সহজ এবং মূলত আমাদের প্রয়োজনীয় সবকিছু সন্তুষ্ট করে।

সার্ভার-প্রেরিত ইভেন্ট

এই জিনিসটি কিভাবে কাজ করে সে সম্পর্কে কয়েকটি শব্দ...

এটি একটি http সংযোগের উপরে চলে। ক্লায়েন্ট একটি অনুরোধ পাঠায়, সার্ভার কন্টেন্ট-টাইপ: টেক্সট/ইভেন্ট-স্ট্রিম দিয়ে সাড়া দেয় এবং ক্লায়েন্টের সাথে সংযোগ বন্ধ করে না, তবে সংযোগে ডেটা লিখতে থাকে:

ক্লায়েন্টদের সাথে সম্মত একটি বিন্যাসে ডেটা পাঠানো যেতে পারে। আমাদের ক্ষেত্রে, আমরা এটি এই ফর্মটিতে পাঠিয়েছি: পরিবর্তিত কাঠামোর নাম (ব্যক্তি, খেলোয়াড়) ইভেন্ট ক্ষেত্রে পাঠানো হয়েছিল, এবং প্লেয়ারের জন্য নতুন, পরিবর্তিত ক্ষেত্রগুলির সাথে JSON ডেটা ক্ষেত্রে পাঠানো হয়েছিল।

এখন কথা বলা যাক কিভাবে মিথস্ক্রিয়া নিজেই কাজ করে।

• ক্লায়েন্ট প্রথম যে কাজটি করে তা হল পরিষেবাটির সাথে শেষবার সিঙ্ক্রোনাইজেশন করা হয়েছে তা নির্ধারণ করে: এটি তার স্থানীয় ডাটাবেস দেখে এবং এটির দ্বারা রেকর্ড করা শেষ পরিবর্তনের তারিখ নির্ধারণ করে।
• এটি এই তারিখের সাথে একটি অনুরোধ পাঠায়।
• জবাবে, আমরা তাকে সেই তারিখ থেকে ঘটে যাওয়া সমস্ত আপডেট পাঠাই।
• এর পরে, এটি লাইভ চ্যানেলের সাথে একটি সংযোগ তৈরি করে এবং এই আপডেটগুলির প্রয়োজন না হওয়া পর্যন্ত এটি বন্ধ হয় না:

আমরা তাকে পরিবর্তনের একটি তালিকা পাঠাই: যদি কেউ গোল করে, আমরা ম্যাচের স্কোর পরিবর্তন করি, যদি সে ইনজুরিতে পড়ে, এটিও রিয়েল টাইমে পাঠানো হয়। এইভাবে, ক্লায়েন্টরা তাৎক্ষণিকভাবে ম্যাচ ইভেন্ট ফিডে আপ-টু-ডেট ডেটা গ্রহণ করে। পর্যায়ক্রমে, যাতে ক্লায়েন্ট বুঝতে পারে যে সার্ভারটি মারা যায়নি, এতে কিছুই হয়নি, আমরা প্রতি 15 সেকেন্ডে একটি টাইমস্ট্যাম্প পাঠাই - যাতে এটি জানে যে সবকিছু ঠিক আছে এবং পুনরায় সংযোগ করার প্রয়োজন নেই।

কিভাবে লাইভ সংযোগ পরিসেবা করা হয়?

• প্রথমত, আমরা একটি চ্যানেল তৈরি করি যেখানে বাফার করা আপডেটগুলি পাওয়া যাবে।
• এর পরে, আপডেট পেতে আমরা এই চ্যানেলটি সাবস্ক্রাইব করি।
• আমরা সঠিক হেডার সেট করি যাতে ক্লায়েন্ট জানে যে সবকিছু ঠিক আছে।
• প্রথম পিং পাঠান। আমরা কেবল বর্তমান সংযোগ টাইমস্ট্যাম্প রেকর্ড করি।
• এর পরে, আপডেট চ্যানেল বন্ধ না হওয়া পর্যন্ত আমরা একটি লুপে চ্যানেল থেকে পড়ি। চ্যানেলটি পর্যায়ক্রমে বর্তমান টাইমস্ট্যাম্প বা পরিবর্তনগুলি গ্রহণ করে যা আমরা ইতিমধ্যে সংযোগগুলি খুলতে লিখছি৷

আমরা প্রথম যে সমস্যার সম্মুখীন হয়েছিলাম তা হল: ক্লায়েন্টের সাথে খোলা প্রতিটি সংযোগের জন্য, আমরা একটি টাইমার তৈরি করেছি যা প্রতি 15 সেকেন্ডে একবার টিক দেয় - দেখা যাচ্ছে যে যদি আমাদের একটি মেশিনের সাথে (একটি API সার্ভারের সাথে) 6 হাজার সংযোগ খোলা থাকে তবে 6 হাজার টাইমার তৈরি করা হয়েছে। এর ফলে মেশিনটি প্রয়োজনীয় লোড ধরে রাখে না। সমস্যাটি আমাদের কাছে এতটা স্পষ্ট ছিল না, কিন্তু আমরা একটু সাহায্য পেয়েছি এবং এটি ঠিক করেছি।

ফলে এখন যে চ্যানেল থেকে আপডেট আসে সেই চ্যানেল থেকেই আমাদের পিং আসে।

তদনুসারে, শুধুমাত্র একটি টাইমার রয়েছে যা প্রতি 15 সেকেন্ডে একবার টিক করে।

এখানে বেশ কিছু অক্জিলিয়ারী ফাংশন আছে - হেডার, পিং এবং স্ট্রাকচার নিজেই পাঠানো। অর্থাৎ, টেবিলের নাম (ব্যক্তি, ম্যাচ, ঋতু) এবং এই এন্ট্রি সম্পর্কে তথ্য এখানে প্রেরণ করা হয়:

আপডেট পাঠানোর ব্যবস্থা

এখন পরিবর্তনগুলি কোথা থেকে আসে সে সম্পর্কে একটু। আমাদের অনেক লোক, সম্পাদক আছে, যারা রিয়েল টাইমে সম্প্রচার দেখেন। তারা সমস্ত ইভেন্ট তৈরি করে: কাউকে বিদায় করা হয়েছিল, কেউ আহত হয়েছিল, কোনও ধরণের প্রতিস্থাপন ...

একটি CMS ব্যবহার করে, ডেটা ডাটাবেসে প্রবেশ করে। এর পরে, ডাটাবেস লিসেন/নোটিফাই মেকানিজম ব্যবহার করে এ সম্পর্কে API সার্ভারকে অবহিত করে। API সার্ভার ইতিমধ্যে ক্লায়েন্টদের কাছে এই তথ্য পাঠায়। এইভাবে, আমাদের কাছে মূলত ডাটাবেসের সাথে সংযুক্ত কয়েকটি সার্ভার রয়েছে এবং ডাটাবেসের উপর কোন বিশেষ লোড নেই, কারণ ক্লায়েন্ট সরাসরি ডাটাবেসের সাথে কোনোভাবেই যোগাযোগ করে না:

PostgreSQL: শুনুন/বিজ্ঞাপন করুন

পোস্টগ্রেসে লিসেন/নোটিফাই মেকানিজম আপনাকে ইভেন্ট সাবস্ক্রাইবারদের জানাতে দেয় যে কিছু ইভেন্ট পরিবর্তিত হয়েছে - ডাটাবেসে কিছু রেকর্ড তৈরি করা হয়েছে। এটি করার জন্য, আমরা একটি সাধারণ ট্রিগার এবং ফাংশন লিখেছি:

একটি রেকর্ড সন্নিবেশ বা পরিবর্তন করার সময়, আমরা data_updates চ্যানেলে বিজ্ঞপ্তি ফাংশনকে কল করি, সেখানে টেবিলের নাম এবং পরিবর্তিত বা ঢোকানো রেকর্ডের শনাক্তকারীকে পাস করি।

ক্লায়েন্টের সাথে সিঙ্ক্রোনাইজ করা আবশ্যক সমস্ত টেবিলের জন্য, আমরা একটি ট্রিগার সংজ্ঞায়িত করি, যা একটি রেকর্ড পরিবর্তন/আপডেট করার পরে, নীচের স্লাইডে নির্দেশিত ফাংশনটিকে কল করে।
কিভাবে API এই পরিবর্তন সাবস্ক্রাইব করে?

একটি ফ্যানআউট প্রক্রিয়া তৈরি করা হয় - এটি ক্লায়েন্টকে বার্তা পাঠায়। এটি সমস্ত গ্রাহক চ্যানেল সংগ্রহ করে এবং এই চ্যানেলগুলির মাধ্যমে প্রাপ্ত আপডেটগুলি পাঠায়:

এখানে স্ট্যান্ডার্ড pq লাইব্রেরি, যা ডাটাবেসের সাথে সংযোগ করে এবং বলে যে এটি চ্যানেলটি শুনতে চায় (data_updates), চেক করে যে সংযোগটি খোলা আছে এবং সবকিছু ঠিক আছে। আমি স্থান বাঁচাতে ত্রুটি পরীক্ষা বাদ দিচ্ছি (চেক করা বিপজ্জনক নয়)।

এর পরে, আমরা অ্যাসিঙ্ক্রোনাসভাবে টিকার সেট করি, যা প্রতি 15 সেকেন্ডে একটি পিং পাঠাবে এবং আমাদের সাবস্ক্রাইব করা চ্যানেলটি শুনতে শুরু করবে। যদি আমরা একটি পিং পাই, আমরা এই পিং প্রকাশ করি। যদি আমরা কোনো ধরনের এন্ট্রি পাই, তাহলে আমরা এই ফ্যানআউটের সকল গ্রাহকদের কাছে এই এন্ট্রিটি প্রকাশ করি।

ফ্যান-আউট কিভাবে কাজ করে?

রাশিয়ান ভাষায় এটি "বিভাজনকারী" হিসাবে অনুবাদ করে। আমাদের কাছে একটি বস্তু রয়েছে যা গ্রাহকদের নিবন্ধন করে যারা কিছু আপডেট পেতে চায়। এবং এই অবজেক্টে একটি আপডেট আসার সাথে সাথে এটি তার সমস্ত গ্রাহকদের কাছে এই আপডেটটি বিতরণ করে। যথেষ্ট সহজ:

এটি Go এ কীভাবে প্রয়োগ করা হয়েছে:

একটি কাঠামো আছে, এটি Mutexes ব্যবহার করে সিঙ্ক্রোনাইজ করা হয়। এটির একটি ক্ষেত্র রয়েছে যা ডাটাবেসের সাথে ফ্যানআউটের সংযোগের অবস্থা সংরক্ষণ করে, অর্থাত্ এটি বর্তমানে শুনছে এবং আপডেটগুলি পাবে, সেইসাথে সমস্ত উপলব্ধ চ্যানেলগুলির একটি তালিকা - মানচিত্র, যার মূলটি হল চ্যানেল এবং কাঠামোর আকারে মান (মূলত এটি কোন উপায়ে ব্যবহৃত হয় না)।

দুটি পদ্ধতি - সংযুক্ত এবং সংযোগ বিচ্ছিন্ন - আমাদের ফ্যানআউটকে বলার অনুমতি দেয় যে আমাদের বেসের সাথে একটি সংযোগ রয়েছে, এটি উপস্থিত হয়েছে এবং বেসের সাথে সংযোগটি ভেঙে গেছে। দ্বিতীয় ক্ষেত্রে, আপনাকে সমস্ত ক্লায়েন্টকে সংযোগ বিচ্ছিন্ন করতে হবে এবং তাদের বলতে হবে যে তারা আর কিছু শুনতে পারবে না এবং তারা পুনরায় সংযোগ করবে কারণ তাদের সাথে সংযোগ বন্ধ হয়ে গেছে।

এছাড়াও একটি সাবস্ক্রাইব পদ্ধতি রয়েছে যা চ্যানেলটিকে "শ্রোতাদের" সাথে যুক্ত করে:

একটি আনসাবস্ক্রাইব পদ্ধতি রয়েছে, যা ক্লায়েন্ট সংযোগ বিচ্ছিন্ন হলে শ্রোতাদের থেকে চ্যানেলটি সরিয়ে দেয়, পাশাপাশি একটি প্রকাশ পদ্ধতি, যা আপনাকে সমস্ত গ্রাহকদের কাছে একটি বার্তা পাঠাতে দেয়৷

প্রশ্ন: - এই চ্যানেলের মাধ্যমে কি প্রেরণ করা হয়?

মাইক্রোসফট: - যে মডেলটি পরিবর্তিত হয়েছে বা পিং প্রেরণ করা হয়েছে (মূলত শুধুমাত্র একটি সংখ্যা, পূর্ণসংখ্যা)।

মাইক্রোসফট: – আপনি যেকোন কিছু পাঠাতে পারেন, যেকোন কাঠামো পাঠাতে পারেন, প্রকাশ করতে পারেন – এটি শুধু JSON-এ পরিণত হয় এবং এটাই।

মাইক্রোসফট: - আমরা পোস্টগ্রেস থেকে একটি বিজ্ঞপ্তি পাই - এতে টেবিলের নাম এবং শনাক্তকারী রয়েছে। টেবিলের নাম এবং শনাক্তকারীর উপর ভিত্তি করে, আমরা আমাদের প্রয়োজনীয় রেকর্ডটি পাই এবং তারপরে আমরা এই কাঠামোটি প্রকাশের জন্য পাঠাই।

পরিকাঠামো

এটি একটি অবকাঠামো দৃষ্টিকোণ থেকে দেখতে কেমন? আমাদের 7টি হার্ডওয়্যার সার্ভার রয়েছে: তাদের মধ্যে একটি সম্পূর্ণরূপে ডেটাবেসের জন্য উত্সর্গীকৃত, অন্য ছয়টি ভার্চুয়াল মেশিন চালায়। API এর 6 টি কপি রয়েছে: API সহ প্রতিটি ভার্চুয়াল মেশিন একটি পৃথক হার্ডওয়্যার সার্ভারে চলে - এটি নির্ভরযোগ্যতার জন্য।

অ্যাক্সেসিবিলিটি উন্নত করার জন্য আমাদের কাছে Keepalived ইনস্টল করা দুটি ফ্রন্টএন্ড রয়েছে, যাতে কিছু ঘটলে, একটি ফ্রন্টএন্ড অন্যটিকে প্রতিস্থাপন করতে পারে। এছাড়াও - CMS এর দুটি কপি।

একটি পরিসংখ্যান আমদানিকারকও রয়েছে। একটি ডিবি স্লেভ আছে যেখান থেকে পর্যায়ক্রমে ব্যাকআপ করা হয়। আছে Pigeon Pusher, একটি অ্যাপ্লিকেশন যা ক্লায়েন্টদের কাছে পুশ বিজ্ঞপ্তি পাঠায়, সেইসাথে অবকাঠামোগত জিনিসগুলি: Zabbix, Graylog2 এবং Chef.

প্রকৃতপক্ষে, এই অবকাঠামোটি অপ্রয়োজনীয়, কারণ কম সার্ভারের সাথে 100 হাজার পরিবেশন করা যেতে পারে। কিন্তু লোহা ছিল - আমরা এটি ব্যবহার করেছি (আমাদের বলা হয়েছিল যে এটি সম্ভব ছিল - কেন নয়)।

Go এর সুবিধা

আমরা এই অ্যাপ্লিকেশনটিতে কাজ করার পরে, Go এর সুস্পষ্ট সুবিধাগুলি আবির্ভূত হয়েছিল।

• দুর্দান্ত http লাইব্রেরি। এটি দিয়ে আপনি বাক্সের বাইরে অনেক কিছু তৈরি করতে পারেন।
• এছাড়াও, চ্যানেলগুলি যা আমাদেরকে খুব সহজেই ক্লায়েন্টদের কাছে বিজ্ঞপ্তি পাঠানোর জন্য একটি প্রক্রিয়া বাস্তবায়ন করতে দেয়।
• বিস্ময়কর জিনিস রেস ডিটেক্টর আমাদের বেশ কিছু জটিল বাগ (স্টেজিং অবকাঠামো) দূর করতে দেয়। স্টেজিং-এ কাজ করে এমন সবকিছু রেস কী দিয়ে কম্পাইল করা হয়। এবং আমরা, সেই অনুযায়ী, আমাদের কী সম্ভাব্য সমস্যা রয়েছে তা দেখতে স্টেজিং অবকাঠামো দেখতে পারি।
• ন্যূনতমতা এবং ভাষার সরলতা।

আমরা ডেভেলপার খুঁজছি! কেউ চাইলে দয়া করে।

প্রশ্ন

শ্রোতাদের কাছ থেকে প্রশ্ন (এর পরে – B): – আমার কাছে মনে হচ্ছে আপনি ফ্যান-আউট সংক্রান্ত একটি গুরুত্বপূর্ণ পয়েন্ট মিস করেছেন। আমি কি বুঝতে পেরেছি যে আপনি যখন কোনও ক্লায়েন্টকে প্রতিক্রিয়া পাঠান, ক্লায়েন্ট পড়তে না চাইলে আপনি ব্লক করেন?

মাইক্রোসফট: - না, আমরা বাধা দিচ্ছি না। প্রথমত, আমাদের nginx এর পিছনে এই সব আছে, অর্থাৎ, ধীর ক্লায়েন্টদের সাথে কোন সমস্যা নেই। দ্বিতীয়ত, ক্লায়েন্টের একটি বাফার সহ একটি চ্যানেল আছে - আসলে, আমরা সেখানে একশত আপডেট দিতে পারি... যদি আমরা চ্যানেলে লিখতে না পারি, তাহলে এটি মুছে দেয়। যদি আমরা দেখি যে চ্যানেলটি ব্লক করা হয়েছে, তাহলে আমরা কেবল চ্যানেলটি বন্ধ করে দেব, এবং এটিই - কোনো সমস্যা দেখা দিলে ক্লায়েন্ট পুনরায় সংযোগ করবে। অতএব, নীতিগতভাবে, এখানে কোন অবরোধ নেই।

ভিতরে: - এটি কি অবিলম্বে লিসেন/নোটিফাইতে একটি রেকর্ড পাঠানো সম্ভব নয়, এবং একটি শনাক্তকারী টেবিল নয়?

মাইক্রোসফট: - লিসেন/নোটিফাই যে প্রিলোড পাঠায় তাতে 8 হাজার বাইটের সীমা রয়েছে। নীতিগতভাবে, আমরা যদি অল্প পরিমাণ ডেটা নিয়ে কাজ করি তবে এটি পাঠানো সম্ভব হবে, তবে আমার কাছে মনে হচ্ছে এইভাবে [আমরা যেভাবে এটি করি] কেবল আরও নির্ভরযোগ্য। সীমাবদ্ধতা পোস্টগ্রেসেই রয়েছে।

ভিতরে: - ক্লায়েন্টরা কি এমন ম্যাচের আপডেট পায় যা তারা আগ্রহী নয়?

মাইক্রোসফট: - সাধারণভাবে, হ্যাঁ। একটি নিয়ম হিসাবে, সমান্তরালভাবে 2-3টি ম্যাচ চলছে, এবং তারপরেও খুব কমই। যদি একজন ক্লায়েন্ট কিছু দেখছেন, তবে সাধারণত তিনি যে ম্যাচটি চলছে তা দেখছেন। তারপরে, ক্লায়েন্টের একটি স্থানীয় ডাটাবেস রয়েছে যেখানে এই সমস্ত আপডেটগুলি যোগ করা হয়েছে এবং এমনকি ইন্টারনেট সংযোগ ছাড়াই, ক্লায়েন্ট অতীতের সমস্ত ম্যাচ দেখতে পারে যার জন্য তার আপডেট রয়েছে। মূলত, আমরা ক্লায়েন্টের স্থানীয় ডাটাবেসের সাথে সার্ভারে আমাদের ডাটাবেস সিঙ্ক্রোনাইজ করি যাতে সে অফলাইনে কাজ করতে পারে।

ভিতরে: - কেন আপনি আপনার নিজের ORM তৈরি করেছেন?

আলেক্সি (লুক+ এর বিকাশকারীদের একজন): - সেই সময়ে (এটি এক বছর আগে) এখনকার তুলনায় কম ওআরএম ছিল, যখন সেগুলি অনেক বেশি। বেশিরভাগ ORM সম্পর্কে আমার প্রিয় জিনিস হল যে তাদের বেশিরভাগই খালি ইন্টারফেসে চলে। অর্থাৎ, এই ওআরএম-এর পদ্ধতিগুলি যে কোনও কিছু গ্রহণ করতে প্রস্তুত: একটি কাঠামো, একটি কাঠামো নির্দেশক, একটি সংখ্যা, সম্পূর্ণ অপ্রাসঙ্গিক কিছু...

আমাদের ORM ডেটা মডেলের উপর ভিত্তি করে কাঠামো তৈরি করে। আমি নিজেই। এবং তাই সমস্ত পদ্ধতিই কংক্রিট, প্রতিফলন ইত্যাদি ব্যবহার করবেন না।

ভিতরে: - কতজন অংশ নিয়েছিল?

মাইক্রোসফট: -প্রাথমিক পর্যায়ে দুইজন অংশগ্রহণ করে। আমরা জুনে কোথাও শুরু করেছি এবং আগস্টে মূল অংশটি প্রস্তুত ছিল (প্রথম সংস্করণ)। সেপ্টেম্বরে মুক্তি পেয়েছিল।

ভিতরে: - যেখানে আপনি SSE বর্ণনা করেন, আপনি টাইমআউট ব্যবহার করেন না। কেন এমন হল?

মাইক্রোসফট: – সত্যি কথা বলতে, SSE এখনও একটি html5 প্রোটোকল: SSE স্ট্যান্ডার্ডটি ব্রাউজারগুলির সাথে যোগাযোগ করার জন্য ডিজাইন করা হয়েছে, যতদূর আমি বুঝি। এটিতে অতিরিক্ত বৈশিষ্ট্য রয়েছে যাতে ব্রাউজারগুলি পুনরায় সংযোগ করতে পারে (এবং আরও), কিন্তু আমাদের সেগুলির প্রয়োজন নেই, কারণ আমাদের কাছে এমন ক্লায়েন্ট ছিল যা সংযোগ এবং তথ্য গ্রহণের জন্য যে কোনও যুক্তি প্রয়োগ করতে পারে৷ আমরা SSE তৈরি করিনি, বরং SSE-এর অনুরূপ কিছু। এটি নিজেই প্রোটোকল নয়।
কোন প্রয়োজন ছিল না। যতদূর আমি বুঝতে পারি, ক্লায়েন্টরা প্রায় স্ক্র্যাচ থেকে সংযোগ প্রক্রিয়াটি প্রয়োগ করেছে। তারা সত্যিই পাত্তা দেয়নি.

ভিতরে: - আপনি কোন অতিরিক্ত ইউটিলিটি ব্যবহার করেছেন?

মাইক্রোসফট: - শৈলীকে একীভূত করার জন্য, সেইসাথে gofmt করার জন্য আমরা সর্বাধিক সক্রিয়ভাবে govet এবং golint ব্যবহার করেছি। আর কিছুই ব্যবহার করা হয়নি।

ভিতরে: - আপনি ডিবাগ করতে কি ব্যবহার করেছেন?

মাইক্রোসফট: - ডিবাগিং মূলত পরীক্ষা ব্যবহার করে বাহিত হয়েছিল। আমরা কোনো ডিবাগার বা GOP ব্যবহার করিনি।

ভিতরে: – আপনি কি সেই স্লাইডটি ফেরত দিতে পারবেন যেখানে পাবলিশ ফাংশন প্রয়োগ করা হয়েছে? একক-অক্ষরের পরিবর্তনশীল নাম কি আপনাকে বিভ্রান্ত করে?

মাইক্রোসফট: - না। তাদের দৃশ্যমানতার মোটামুটি "সংকীর্ণ" সুযোগ রয়েছে। এগুলি এখানে ছাড়া অন্য কোথাও ব্যবহার করা হয় না (এই শ্রেণীর অভ্যন্তরীণগুলি ব্যতীত), এবং এটি খুব কমপ্যাক্ট - এটি কেবল 7 টি লাইন নেয়।

ভিতরে: - একরকম এটি এখনও স্বজ্ঞাত নয় ...

মাইক্রোসফট: - না, না, এটি একটি বাস্তব কোড! এটা শৈলী সম্পর্কে না. এটি এমন একটি উপযোগী, খুব ছোট শ্রেণী - ক্লাসের ভিতরে মাত্র 3টি ক্ষেত্র...

মাইক্রোসফট: - মোটামুটিভাবে, ক্লায়েন্টদের সাথে সিঙ্ক্রোনাইজ করা সমস্ত ডেটা (সিজন ম্যাচ, প্লেয়ার) পরিবর্তন হয় না। মোটামুটিভাবে বলতে গেলে, আমরা যদি অন্য কোনো খেলা তৈরি করি যেখানে আমাদের ম্যাচ পরিবর্তন করতে হবে, তাহলে আমরা কেবল ক্লায়েন্টের নতুন সংস্করণে সবকিছু বিবেচনা করব এবং ক্লায়েন্টের পুরানো সংস্করণগুলি নিষিদ্ধ করা হবে।

ভিতরে: - কোন তৃতীয় পক্ষের নির্ভরতা ব্যবস্থাপনা প্যাকেজ আছে?

মাইক্রোসফট: - আমরা গো ডিপ ব্যবহার করি।

ভিতরে: - প্রতিবেদনের বিষয়ে ভিডিও সম্পর্কে কিছু ছিল, কিন্তু ভিডিও সম্পর্কে প্রতিবেদনে কিছুই ছিল না।

মাইক্রোসফট: - না, ভিডিওটির বিষয়ে আমার কাছে কিছু নেই। এটিকে "লুক+" বলা হয় - এটি অ্যাপ্লিকেশনটির নাম।

ভিতরে: - আপনি বলেছেন যে এটি ক্লায়েন্টদের কাছে প্রবাহিত হয়? ..

মাইক্রোসফট: - আমরা ভিডিও স্ট্রিমিংয়ের সাথে জড়িত ছিলাম না। এটি সম্পূর্ণরূপে মেগাফোন দ্বারা করা হয়েছিল। হ্যাঁ, আমি বলিনি যে অ্যাপ্লিকেশনটি মেগাফোন।

মাইক্রোসফট: – যান – সমস্ত ডেটা পাঠানোর জন্য – স্কোরে, ম্যাচের ইভেন্টে, পরিসংখ্যানে... গো হল অ্যাপ্লিকেশনটির সম্পূর্ণ ব্যাকএন্ড। ক্লায়েন্টকে অবশ্যই কোথাও থেকে জানতে হবে যে প্লেয়ারের জন্য কোন লিঙ্কটি ব্যবহার করতে হবে যাতে ব্যবহারকারী ম্যাচটি দেখতে পারেন। আমরা প্রস্তুত করা হয়েছে যে ভিডিও এবং স্ট্রীম লিঙ্ক আছে.

কিছু বিজ্ঞাপন 🙂

আমাদের সাথে থাকার জন্য আপনাকে ধন্যবাদ. আপনি আমাদের নিবন্ধ পছন্দ করেন? আরো আকর্ষণীয় বিষয়বস্তু দেখতে চান? অর্ডার দিয়ে বা বন্ধুদের সুপারিশ করে আমাদের সমর্থন করুন, $4.99 থেকে বিকাশকারীদের জন্য ক্লাউড ভিপিএস, এন্ট্রি-লেভেল সার্ভারগুলির একটি অনন্য অ্যানালগ, যা আমাদের দ্বারা আপনার জন্য উদ্ভাবিত হয়েছে: VPS (KVM) E5-2697 v3 (6 কোর) 10GB DDR4 480GB SSD 1Gbps থেকে $19 বা কিভাবে একটি সার্ভার শেয়ার করবেন সম্পর্কে সম্পূর্ণ সত্য? (RAID1 এবং RAID10 এর সাথে উপলব্ধ, 24 কোর পর্যন্ত এবং 40GB DDR4 পর্যন্ত)।

আমস্টারডামের ইকুইনিক্স টায়ার IV ডেটা সেন্টারে ডেল R730xd 2x সস্তা? শুধু এখানে 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 টিভি $199 থেকে নেদারল্যান্ডে! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 থেকে! সম্পর্কে পড়ুন কিভাবে ইনফ্রাস্ট্রাকচার কর্পোরেশন তৈরি করা যায়। এক পয়সার জন্য 730 ইউরো মূল্যের Dell R5xd E2650-4 v9000 সার্ভার ব্যবহার করে ক্লাস?

উত্স: www.habr.com