Эволюция разделения фронтенда и бэкенда: если нельзя микросервисы, то изоляция BFF — Phodal

задняя часть Микросервисы Архитектура внешний интерфейс

Большинство существующих программных систем в какой-то момент в будущем станут устаревшими системами, но сроки будут другими. Хорошая система имеет хороший дизайн и развивается в течение своего жизненного цикла. Но ни один дизайн не может противостоять времени и изменениям, которые приносит бизнес.

Технологическое видение

Может быть, вы уже знаете, что такое BFF в моей предыдущей статье, а может быть, вы узнали об этом из других источников. Если нет, то позвольте мне кратко представить:Что такое лучший друг?

BFF

BFF, то есть бэкенды для фронтов, который используется в API проектирования серверов, а логика сервиса выполняется непосредственно на сервере.

![BFF)(http://architecture.phodal.com//images/bff.jpg)

Как я в "История развития интерфейса》 Как упоминалось в статье, когда мы проектировали системный API в первые дни, мы просто предоставляли JSON-сериализацию модели (Model) для внешнего интерфейса (Web, Android, iOS и т. д.) и специально не рассматривали потребности фронтенда. Ниже приведен обычный RESTful API, который по своей конструкции соответствует требованиям RESTful API, но не подходит для использования во внешнем интерфейсе.

В этом случае нам нужно сделать некоторую обработку, такую ​​как усечение текста и так далее. Использование BFF означает, что у него будет дополнительный уровень бизнес-обработки и пересылки.

Применимая сцена

Как упоминалось выше, эта архитектура особенно подходит для миграции системы с использованием модели удушителя.

План миграции

Давайте вернемся в эпоху Web 1.0 и посмотрим на архитектуру веб-сайтов того времени:

1.0 早期的网站

Система выглядит такой простой, потому что не так много компаний пытаются работать в Интернете. Затем, более десяти лет назад, мы начали работать с мобильными устройствами и адаптировали слой API:

2.0 新的移动趋势

API, адаптированный из этого уровня, плохо спроектирован. Это может быть просто схема базы данных одна за другой:

CREATE TABLE contents (
  `id` int(11) DEFAULT NULL auto_increment PRIMARY KEY,
  `type` varchar(255),
  `title` varchar(255),
  `author` varchar(255),
  `body` text,
  http://architecture.phodal.com/.
) TYPE=MyISAM;

Эти объекты преобразуются в JSON в коде, а затем передаются во внешний интерфейс. И по мере того, как взаимодействие веб-приложений становилось все более и более сложным, сторона ПК также начала активно использовать API вместо фонового рендеринга:

2.5 创建 API 层

Раньше серверная часть напрямую возвращала значение из базы данных во внешний интерфейс, и каждый раз, когда значение менялось, приходилось изменять Android, iOS и Интернет. В то же время, когда нам нужно обработать строку, например ограничение в 140 символов, нам нужно реализовать это на каждом клиенте (Android, iOS, Web) отдельно, что, очевидно, довольно дорого. Итак, нам нужен BFF в качестве промежуточного программного обеспечения. В этом промежуточном программном обеспечении мы выполним некоторую обработку бизнес-логики:

2.75 BFF 层

И когда у нас есть этот уровень BFF, нам не нужно рассматривать миграцию серверной части системы. Изменения в бэкенде могут быть сделаны на слое BFF с некоторыми соответствующими модификациями:

后端微服务化

Пока, мы реконструируем фронтенд и бэкэнд системы под новую архитектуру, а фронтенд и бэкенд вряд ли.

стратегия тестирования

Учитывая совместимость системы,

Возвращаясь снова к пирамиде тестирования, с новой системой, новым языком, старые модульные тесты обязательно недоступны. Тестирование услуг и тестирование пользовательского интерфейса совместимы, в зависимости от конструкции системы.

сервисный тест

Для серверной части мы по-прежнему читаем базу данных из системы, и результаты, отображаемые в конце, должны быть согласованными — это может быть просто другая база данных или метод чтения изменился с ODBC на JDBC. Для фронтенд-разработчиков в фоне ничего не изменилось — конечно, при отсутствии слоя изоляции BFF несколько запросов могут стать одним запросом.

Как мы столкнулись в приведенной выше системе, сгенерированный URL-адрес и заголовок страницы должны быть неизменными, поэтому нам нужно написать тесты для проверки соответствующего URL-адреса и заголовка:

title,url
Phodal's Idea实战指南,https://github.com/phodal/ideabook
一步步搭建物联网系统,https://github.com/phodal/designiot
GitHub 漫游指南,https://github.com/phodal/github-roam
RePractise,https://github.com/phodal/repractise
Growth: 全栈增长工程师指南,https://github.com/phodal/growth-ebook
Growth: 全栈增长工程师实战,https://github.com/phodal/growth-in-action
我的职业是前端工程师,https://github.com/phodal/fe
写给软件工程师看的硬件编程指南,https://github.com/phodal/make

Сначала напишите тест URL-адреса старой системы, а затем поочередно проверяйте согласованность содержимого.

поведенческий тест

Чтобы обеспечить совместимость старой и новой систем, нам необходимо провести автоматизированные тесты пользовательского интерфейса, чтобы обеспечить нормальную работу новой системы.

И если наши предыдущие UI-тесты были написаны с использованием архитектуры BDD, то мы можем продолжать использовать предыдущее поведение. При этом нам нужно только изменить реализацию тестового скрипта:

BDD

Возьмите огурец в качестве примера:

# language: zh-CN
功能: 失败的登录

  场景大纲: 失败的登录
    假设 当我在网站的首页
    当 输入用户名 <用户名>
    当 输入密码 <密码>
    当 提交登录信息
    那么 页面应该返回 "Error Page"

    例子:
      |用户名     |密码      |
      |'Jan1'    |'password'|
      |'Jan2'    |'password'|

Когда бизнес остается неизменным, это поведение также остается неизменным, потому что меняется базовая реализация. Как и раньше, идентификатор кнопки входаlogin, теперь идентификатор кнопки может статьnew_login.new_loginОпределенно плохо сделанное имя, вероятно, все еще на следующем рефакторинге.new_login.

Или Датчик от ThoughtWorks:

失败的登录
===

     |用户名   |密码     |
     |--------|--------|
     |Jan1    |password|
     |Jan2    |password|

失败的登录
-----------
* 当我在网站的首页
* 输入用户名 <用户名>
* 输入密码 <密码>
* 提交登录信息
* 页面应该返回 "Error Page"

кейс

Два года назад я работал над сайтом по поиску недвижимости. Это настолько старая система, что мы можем видеть комментарии 10-летней давности, когда исправляем ошибки. В то время мы приняли модель душителя, чтобы переписать систему, т.Добавляйте новые функции вне устаревшей системы, чтобы создавать микросервисы..

Поскольку это система, которая уже находится в сети, все равно необходимо убедиться, что старая функциональность не будет нарушена в процессе перезаписи. В старой системе есть необслуживаемая поисковая система.Чтобы заменить эту поисковую систему, мы создали слой сервисного уровня API - в слое API мы адаптировали старую поисковую систему и разработали новую поисковую систему. двигатель. В сегодняшнем представлении это своего рода реализация BFF, и метод миграции достаточно надежен.

в заключении

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

Категории