Контрольний список архітектури програмного забезпечення: як створити продукт з нуля

Ви прокидаєтесь одного ранку, щоб випити чашку кави і вуаля, момент Еврики вже тут. Ви нарешті зрозуміли свою бізнес-модель, і все стає на свої місця. Ви знаєте, що інвесторам сподобається, і вам просто не терпиться почати будувати продукт. Перша перевага для вашої подорожі - ваша.

Ці моменти трапляються рідко, але коли вони трапляються, вам потрібно почати в потрібний момент. Все, що вам потрібно, - це правильний посібник, який допоможе вам зрозуміти, що ви повинні, а що не повинні робити. Це не час для експериментів, це час для виконання. Зараз ВАШ час!

ПРИМІТКА - Далі наведено питання створення архітектури програмного забезпечення з нуля. Тож, якщо вам цікаво знати дрібницю задіяних технологій, тоді продовжуйте. В іншому випадку, будь ласка, поділіться з тими, кому це точно сподобається: P

Звідки взявся цей путівник

Я сам працював над кількістю продуктів на ранніх стадіях, і, чесно кажучи, я робив помилки. Я завжди хотів, щоб був контрольний список, якого слід дотримуватися під час створення продукту з нуля.

У побудові архітектури з нуля є стільки речей, що ви повністю забудете певні фрагменти. І вони повернуться, щоб вкусити вас на пізніх стадіях товарного циклу.

Нарешті я вирішив створити цей контрольний список речей, які слід врахувати, перш ніж натискати цю кнопку розгортання вперше.

Отже, без подальшого нарощування, ось контрольний список, який ви повинні пройти, будуючи архітектуру бекенда для продукту з нуля.

Виберіть ПРАВИЛЬНУ мову та основи (для вашого проекту)

Вибрати правильну мову та структуру для вашого продукту складно, і для цього немає особливої ​​срібної кулі. Моя порада - вибрати мову, яка вам найбільше сподобалась, і знати тонкощі входу та виходу.

Сказавши це, це рідко, тому що є дуже мало людей, які є ніндзями Javascript, або Python Panthers, або якими б там не було забавними іменами.

Тож виберіть мову, яка має справжню хорошу підтримку в галузі, наприклад Javascript, Python, Java або Перейдіть, щоб назвати декілька. Ви можете вибрати будь-яку мову, просто виберіть, яка з них вам найбільш зручна.

І пам’ятайте - ви створюєте MVP (Мінімальний життєздатний продукт) і будете в процесі створення POC (Доказ концепції). Тож дістаньте свій товар якомога швидше. Вам не потрібно застрявати в питаннях, які можуть походити з нової мови в місті. Щоб уникнути цих проблем, оберіть більш широко використовувану, добре задокументовану мову.

Нарешті, ви можете масштабувати пізніше. Якщо ви перебуваєте у фазі створення POC, просто створіть і виконайте це. Але якщо ви створюєте щось дійсно конкретне, і для цього є спеціально побудована мова та фреймворк, тоді вам точно слід обрати саме цю технологію.

Але здебільшого проблеми, які ми намагаємось вирішити, можна легко усунути за допомогою будь-якої із згаданих мов та їх відповідних систем. Тож просто виберіть його та запустіть свій продукт.

Хороший ресурс, який допоможе вам прийняти рішення -

//content.techgig.com/top-5-programming-languages-for-backend-web-development/articleshow/67337449.cms

Впровадити мікросервіси аутентифікації та авторизації

Існує багато способів автентифікації та авторизації користувача. Ви можете спробувати жетони сеансу, JWT (веб-маркери JSON) або OAuth, щоб назвати декілька. Кожен варіант має свої плюси і мінуси. Тож давайте розглянемо деякі з них уважніше.

Веб-токени JSON

JWT швидко і легко впровадити. Це тому, що маркери ніколи не зберігаються ніде у вашій системі. Вони просто закодовані, зашифровані та відправлені користувачеві. Отже, перевірка JWT швидша, ніж будь-який інший метод.

Але тоді, оскільки вони не зберігаються в системі, ви фактично не можете зробити термін дії маркера закінченим до його фактичного часу закінчення, і це може бути проблемою в певних випадках.

Тож з’ясуйте плюси і мінуси кожної системи автентифікації та виберіть ту, яка найкраще відповідає вашим вимогам. Я особисто віддаю перевагу JWT (але це мій власний вибір).

Авторизація

Ніколи не забувайте застосовувати авторизацію користувачів. Ви не хочете, щоб авторизований користувач1 міняв деталі користувача2. Це може спричинити хаос у вашій системі.

Визначте кінцеві точки, які потребують авторизації, та негайно впровадьте їх. Ви не хочете, щоб стан вашої бази даних був таким пошкодженим. Запам’ятайте різницю між 401 і 403.

Нижче наведено певні кінцеві точки, які ви обов’язково повинні врахувати під час створення вашої системи автентифікації (я створив її в Django за допомогою JWT). Для вашого випадку використання можуть бути певні доповнення / видалення, але саме ці ви повинні розглянути.

Багато фреймворків надають їх нестандартно, але розгляньте їх, перш ніж створювати їх самостійно. Перевірте аутентифікаційні_класи та дозвольні_класи в Django Rest Framework для подальшого посилання.

Погляньте на цей ресурс Django REST Framework -

//www.django-rest-framework.org/tutorial/4-authentication-and-permissions/

Створіть абстрактну базову модель, яка успадковується кожною іншою моделлю у вашій базі даних

Пам’ятайте принцип СУХОГО - не повторюватися? Її слід дотримуватися до основи в розробці програмного забезпечення.

Спираючись на вищеописаний процес обдумування, у вашій базі даних будуть певні стовпці, які будуть присутні у кожній таблиці. Тому краще створити для них абстрактний клас, щоб інші Класи Моделей могли успадковувати від них.

Давайте розглянемо цей код і що він означає:

  • id - Хоча це не написано тут, воно автоматично створюється фреймворком Django. Але якщо його немає у вас, запишіть це в цьому класі. Це просто поле з автоматичним збільшенням, яке можна використовувати як первинний ключ у відношенні бази даних.
  • created_at - Це означає, коли поле / рядок було вставлено у вашу таблицю, і воно заповнене самим фреймворком. Вам не потрібно встановлювати це явно.
  • updated_at - Це означає, коли поле / рядок було востаннє змінено / оновлено у вашій таблиці, і знову воно заповнене самим фреймворком.
  • delete_at + is_deleted - Отже, це спірне поле. Я не маю точної відповіді щодо того, чи має він бути там чи ні - адже, чесно кажучи, нічого в Інтернеті ніколи не видаляється. Це поле, якщо воно заповнене, відображає, що рядок видаляється з системи (хоча дані залишаються в системі для подальших посилань і можуть бути вилучені з бази даних і збережені в резервних копіях)
  • uuid - Це залежить від того, хочете ви помістити це у свою таблицю чи ні. Якщо вам потрібно виставити Первинний ключ таблиці зовнішній системі, краще виставити цей, а не автоматично збільшене ціле число. Ви можете запитати, чому ...? Ну, чому ви хочете сказати зовнішній системі, що у вашій таблиці 10378 замовлень? Але знову ж таки це особистий вибір.

Налаштуйте мікросервіс сповіщень

Кожен продукт повинен надсилати нагадування та сповіщення користувачеві для залучення та транзакцій. Тож кожному товару це знадобиться.

Ви обов’язково повинні розглянути можливість створення мікросервісу, який надаватиме послуги сповіщення (наприклад, push-повідомлення, електронні листи та SMS) для ваших кінцевих користувачів.

Це взагалі має бути окрема мікрослужба. Не будуйте цього всередині мікросервісу автентифікації або служби додатків (фактична бізнес-логіка).

Існує безліч сторонніх бібліотек / служб, які можна використовувати для його створення для вашого додатка. Використовуйте їх і будуйте це на вершині цього.

Не забудьте побудувати всі 3 функціональні можливості:

  • Push-сповіщення (APNS + FCM),
  • Електронні листи (для початку просто інтегруйте клієнт SMTP)
  • та SMS

ПРИМІТКА - Майте два канали для надсилання SMS, транзакційний та рекламний. Ніколи не надсилайте рекламне SMS на транзакційному каналі, оскільки існує ймовірність того, що на вас подадуть позов добре обізнаний та мотивований користувач.

Найпростіший спосіб налаштувати ваш SMTP-клієнт у вашому додатку, використовуючи це у ваших налаштуваннях:

Я зробив це в Django, але ви можете зробити те саме вибраною мовою та структурою.

Налаштування журналювання помилок

Використовуйте проміжне програмне забезпечення для реєстрації помилок, які виникають у вашій виробничій системі. Люди, які сидять там, не бачитимуть вашу виробничу систему, щоб бачити журнали програм цілодобово та без вихідних. Тож вам знадобиться система, яка реєструватиме ці внутрішні помилки сервера у центральному місці. Тоді ви можете щодня перевіряти їх або створювати веб-хук, щоб ви могли отримувати попередження в потрібний час і піклуватися про них.

На ринку існує безліч сторонніх інструментів реєстрації помилок. Просто виберіть будь-який, який відповідає вашим вимогам. Я в основному використовую Sentry / Airbrake.

Розгляньте можливість налаштування веб-хуків, як я вже згадував вище. Вони повідомлять ваших користувачів про помилки, і, наприклад, ви можете розміщувати ці помилки, коли і коли вони трапляються на певних слабких каналах. Тоді ви зможете регулярно перевіряти ці канали та виправляти їх залежно від їх суворості.

Офіційна домашня сторінка Airbrake - //airbrake.io/

Офіційна домашня сторінка Sentry - //sentry.io/welcome/

Запит на реалізацію - відповідь та реєстрація програми

Сценарій - користувач звертається за вашою підтримкою та повідомляє, що він не отримав квитанцію про транзакцію за покупку, яку зробив на вашому веб-сайті. Що ти робитимеш?

Якщо ви ввели систему реєстрації програм у свою систему, то не хвилюйтеся. Тепер, що я маю на увазі під цим? Завжди краще показати приклад, ніж намагатися пояснити словами. Ось воно:

Я повідомив, що збираюся надіслати електронне повідомлення на згаданий email_id. Я можу перевірити журнали програми, чи справді електронне повідомлення було надіслано клієнту, перевіривши, чи існує такий журнал у системі. Переконайтеся, що у вашій системі є повні журнали, щоб ви могли простежити шлях прохання.

Крім того, непогано встановити асинхронну систему, яка буде вибирати такі журнали відповідей на запити та програми з вашої системи та скидати їх у центральне місце. Там їх можна обробити для легшої інтерпретації.

Для цього хорошим варіантом є стек ELK: ElasticSearch - Logstash - Kibana.

Докладніше про стек ELK - //www.elastic.co/what-is/elk-stack

ПРИМІТКА. Під час реєстрації запитів та відповідей подбайте про наступне:

  • Не реєструйте паролі.
  • Не реєструвати маркери (маркери доступу, які використовуються для автентифікації)
  • Не реєструйте OTP

Введіть дроселювання в своїх API та обмеження швидкості на серверах додатків

Сценарій - Ви щойно запустили свою послугу і продали продукт на платформах соціальних мереж. Це дізнався хакер чорного капелюха, який просто хотів пограти з вашою системою. Тож вони запланували атаку DOS (відмова в обслуговуванні) на вашу систему.

Для боротьби з цим, ви можете встановити обмеження швидкості на основі різних факторів поверх ваших балансирів навантаження для ваших серверів додатків. Це подбає про атаки DOS і запобіжить нападу зловмисного користувача на ваші сервери.

Сценарій - Кінцева точка API / otp / validate, яка приймає 4-значні OTP для автентифікації користувача та повертає маркери, які будуть використовуватися для автентифікованих API. Зловмисний користувач отримує mobile_number для одного з ваших клієнтів і починає вражати кінцеву точку API грубою силою, змінюючи IP-адреси, атакою DDOS (розподілена відмова в обслуговуванні). Обмежувач швидкості не може зупинити користувача, оскільки ІР постійно змінюється з кожним зробленим запитом.

Щоб зупинити це, ви можете встановити регулювання на API, залежно від користувача. Ви можете налаштувати, скільки запитів може зробити конкретний користувач до кінцевої точки API. Для перевірки OTP хороша кількість - 5 запитів на 10 хвилин. Це зупинить зловмисного користувача від здійснення грубої сили DDOS-атаки на вищевказаний API.

Регулювання в REST Framework Django -

//www.django-rest-framework.org/api-guide/throttling/

Встановіть і налаштуйте асинхронний зв’язок з першого дня

Сценарій - Вам потрібно надіслати вітальний електронний лист користувачеві, коли він зареєструється у вашій заявці. Фронтальний клієнт потрапляє в API реєстрації, ви створюєте користувача у серверній системі після перевірок, і це запускає процес надсилання вітального електронного листа.

Надсилання цього вітального електронного листа займе час, можливо, кілька секунд. Але чому ви хочете, щоб мобільний клієнт застряг у такому процесі? Це може відбуватися у фоновому режимі, без того, щоб користувач застряг без особливих причин на сторінці Реєстрації. Кожна секунда дорогоцінна, і ви не хочете, щоб користувач втратив ці дорогоцінні секунди.

Тож просто надішліть електронне повідомлення через асинхронне завдання. Для цього скористайтеся працівниками, завданнями, посередниками повідомлень та результатами.

Одним з хороших прикладів цього зі світу Пітона є працівник Селери. Просто поставте завдання, яке потрібно виконати, у посереднику повідомлень (Rabbit MQ / SQS тощо). Селера послухає це і надішле завдання призначеному працівникові. Потім цей працівник обробить запит і помістить результат у серверну інформацію, яка може бути системою кешування / системою баз даних. (Redis / PostgreSQL, наприклад).

Ви можете відстежувати ці завдання та черги за допомогою безлічі сторонніх бібліотек. Хорошим прикладом цього є квітка селери, яка стежить за всім цим.

Ви можете прочитати більше про RabbitMQ тут - //www.rabbitmq.com/

І селера - //docs.celeryproject.org/en/stable/django/first-steps-with-django.html

І, нарешті, Квітка селери - //flower.readthedocs.io/uk/latest/

Налаштування завдань cron

Сценарій - Ви щойно запустили свій продукт, і вам потрібно надіслати рекомендації своїм користувачам щодо нових продуктів на вашій платформі. Ви будете надсилати їх на основі їх історії покупок кожні вихідні.

Вищевказане завдання можна легко виконати, використовуючи завдання cron. Він легко налаштовується в будь-якій структурі. Важливо пам’ятати, що ви не повинні розміщувати завдання cron безпосередньо у файлі crontab вашого сервера. Ви повинні дозволити фреймворку це обробляти.

Це тому, що інженер з розгортання / інженер Devops повинен бути єдиною особою, яка має доступ до такої системи з міркувань безпеки. Хоча вам не потрібно реалізовувати це таким чином, добре мати щось з самого початку.

У світі Джанго ви можете за допомогою celerybeat налаштувати свої крони за допомогою працівників селери.

Дізнайтеся більше про Celery Beat тут - // docs.celeryproject.org/en/latest/userguide/periodic-tasks.html

Правильно керуйте своїми секретами (файл параметрів)

Існує багато способів керувати секретами параметрів на робочих серверах. Деякі з них:

  • Створення секретного файлу та збереження його в приватному сегменті s3 та витягування його під час розгортання вашої програми.
  • Встановлення параметрів у змінних середовища під час розгортання вашої програми (зберігання їх у s3 знову)
  • Розміщення секретів у службі управління секретами (наприклад, //aws.amazon.com/secrets-manager/) та використання їх для отримання секретів у вашому додатку.

Ви можете вибрати будь-який із цих методів відповідно до вашого комфорту та випадку використання. (Ви також можете зберігати різні секретні файли для локального, проміжного та виробничого середовищ.)

Оновіть свої API з першого дня

Це те, що вам обов’язково слід розглянути з 1-го дня. Ви ніколи не дізнаєтесь, як часто можуть змінюватися ваші бізнес-моделі, і вам потрібно мати сумісність із програмою вперед-назад. Тож ви повинні версиювати свої API, щоб забезпечити безперебійну роботу всіх.

Ви можете мати різні програми для різних версій, і нехай nginx обробляє це для вашого додатка. Або ви можете встановити версію для самої програми, і нехай маршрути на сервері додатків обробляють це. Ви можете вибрати будь-який метод для його реалізації - головне, щоб увімкнути версію з самого початку.

Визначтесь із твердими та програмними перевірками версій оновлення для своїх клієнтів

То яка різниця між жорстким та м’яким оновленнями?

Жорсткі оновлення стосуються випадків, коли користувач змушений оновлювати версію клієнта на номер версії вищий, ніж той, що встановлений на мобільному телефоні.

М'які оновлення стосуються випадків, коли користувачеві відображається запит про доступність нової версії, і він може оновити свою програму до нової версії, якщо захоче.

Жорсткі оновлення не заохочуються, але бувають випадки, коли вам потрібно їх застосувати. У будь-якому випадку, ви обов’язково повинні подумати, як ви збираєтесь застосувати це для своїх додатків.

Ви можете зробити це, впровадивши або налаштувавши це в Play Store або App Store. Інший спосіб - створити API у вашому сервісному додатку, який буде вражатись кожного разу, коли мобільний додаток запускається. Це надішле два ключі: hard_update -> true / false та soft_update -> true / false, залежно від версії користувача та версій жорсткого та програмного оновлення, встановлених у вашій серверній системі.

Хороше місце для зберігання цих версій - у вашому кеші (Redis / Memcache), який ви можете змінювати на льоту, не потребуючи розгортання програми.

Впроваджуйте безперервну інтеграцію з першого дня

Сценарій - один із стажерів, що працює у вашому проекті, недостатньо досвідчений для написання коду виробничого рівня. Можливо, вони щось змінили, що може порушити якийсь важливий компонент у вашому проекті. Як ви можете переконатися, що в таких випадках все нормально?

Запровадити безперервну інтеграцію. Він буде запускати лінтери та тестові кейси при кожному коміті, і буде порушуватись, якщо будуть порушені будь-які правила. Це, в свою чергу, заблокує запит на витягування з об’єднання, доки не пройдуть усі правила підключення та тестові кейси. Приємно мати щось, і насправді це допомагає і в довгостроковій перспективі, тому майте це на увазі.

На ринку доступно багато опцій. Ви можете вибрати, щоб реалізувати його самостійно (Jenkins CI / CD), або ви можете використовувати TravisCI, CircleCI тощо для того самого.

Прочитайте про TravisCI тут - //travis-ci.org/

І CircleCI - //circleci.com/

Увімкнути підтримку Docker (особисті уподобання)

Створіть Dockerfile та docker-compose.yml для своєї програми, щоб усі запускали програму за допомогою Docker з самого початку. Однією з головних причин використання такого підходу є узгодженість у вашому локальному / проміжному / виробничому середовищі, щоб жоден розробник ніколи не міг повторити це:

Але це працювало на моїй машині.

З 1-го дня використовувати його не складно. На початку просто використовуйте Docker для вашого місцевого середовища, щоб налаштування вашої програми могло бути справді плавним. Але майте на увазі, як ви можете запускати його як з Docker, так і без нього.

Ось додаткова інформація про Docker Hub - //hub.docker.com/

Використовуйте інструмент APM

Інструмент моніторингу додатків повинен бути необхідним, якщо ви хочете контролювати API вашого додатка, транзакції, підключення до бази даних тощо.

Сценарій - жорсткий диск вашого сервера cron майже заповнений, і він не може виконувати завдання cron. Оскільки він не може знайти місця на диску, ваші крони не працюють. То як ви можете отримувати сповіщення, коли це трапляється?

Існує багато інструментів APM, за допомогою яких ви можете відстежувати це. Ви можете налаштувати їх відповідно до того, коли вам потрібно повідомити. Ви отримуватимете сповіщення на вибраний вами носій, коли такий хаос трапляється у вашій системі - і повірте, це відбувається постійно. Тож краще будьте до цього готові. New Relic - хороший варіант.

Детальніше про Нову Реліквію читайте тут - //newrelic.com/

Використовуйте ElasticSearch для забезпечення пошуку у всіх програмах у ваших клієнтських програмах

За даними wikipedia,

Elasticsearch - це пошукова машина, заснована на бібліотеці Lucene. Він забезпечує розподілену повнотекстову пошукову систему з можливістю використання декількох одиниць, веб-інтерфейсом HTTP та документами JSON без схем. Elasticsearch розроблений на Java.

На початку у вас виникне спокуса використовувати традиційні запити до бази даних, щоб отримати результати в цьому рядку пошуку для клієнтської програми. Чому? Бо це просто.

Але традиційні бази даних не призначені для таких продуктивних запитів. Визначте сприятливий час для перенесення пошуку на ElasticSearch та введення конвеєру даних у вашу систему. Він подає еластичний пошук даними, а потім підключає пошук від ElasticSearch до сервера додатків.

Ось хороший огляд Elasticsearch для початку.

І документи ElasticSearch - //www.elastic.co/guide/index.html

Вставте брандмауер на робочий сервер

Ви обов’язково повинні це зробити - це обов’язково. Вставте брандмауер на робочий сервер і закрийте всі порти, крім тих, які будуть використовуватися для API (з'єднання https). Маршрутизуйте кінцеві точки API, використовуючи веб-сервер зворотного проксі-сервера, такий як NGiNX або Apache. Жоден порт не повинен бути доступним для зовнішнього світу, крім дозволених NGiNX.

Чому слід використовувати NGiNX:

  • //www.nginx.com/resources/wiki/community/why_use_it/
  • //blog.serverdensity.com/why-we-use-nginx/
  • //www.freecodecamp.org/news/an-introduction-to-nginx-for-developers-62179b6a458f/

Підведенню

Вищезазначені моменти ґрунтуються на моїх власних уподобаннях, і я розвивав їх протягом багатьох років. Тут і там будуть незначні відмінності, але концепції залишаються незмінними.

І врешті-решт ми робимо все це для того, щоб гладка система, побудована з нуля, працювала у виробництві якомога швидше після того, як ви придумали ідею.

Я намагався загін вниз всі свої знання , які я придбав за ці роки, і я міг би бути неправильно протягом декількох місцях .Я ж вам здається , ви можете запропонувати краще інформацію , будь ласка , чи не соромтеся коментувати. І як завжди, будь ласка, поділіться, якщо вважаєте, що це корисно.