Алексей Черемисин

Стандартная практика обработки ошибок или освобождения ресурсов в Си. Обычно в таких случаях goto более удобен и читаем чем альтернативные решения.
Однако в данном конкретном примере функция очень короткая и в ней нет множества ветвлений, поэтому конечно проще написать без goto, но видимо сила привычки или задел на будущее.

Вот напиример функция из питона с более уместным использованием goto

static int
ast_type_init(PyObject *self, PyObject *args, PyObject *kw)
{
    Py_ssize_t i, numfields = 0;
    int res = -1;
    PyObject *key, *value, *fields;
    fields = _PyObject_GetAttrId((PyObject*)Py_TYPE(self), &PyId__fields);
    if (!fields)
        PyErr_Clear();
    if (fields) {
        numfields = PySequence_Size(fields);
        if (numfields == -1)
            goto cleanup;
    }

    res = 0; /* if no error occurs, this stays 0 to the end */
    if (numfields < PyTuple_GET_SIZE(args)) {
        PyErr_Format(PyExc_TypeError, "%.400s constructor takes at most "
                     "%zd positional argument%s",
                     Py_TYPE(self)->tp_name,
                     numfields, numfields == 1 ? "" : "s");
        res = -1;
        goto cleanup;
    }
    for (i = 0; i < PyTuple_GET_SIZE(args); i++) {
        /* cannot be reached when fields is NULL */
        PyObject *name = PySequence_GetItem(fields, i);
        if (!name) {
            res = -1;
            goto cleanup;
        }
        res = PyObject_SetAttr(self, name, PyTuple_GET_ITEM(args, i));
        Py_DECREF(name);
        if (res < 0)
            goto cleanup;
    }
    if (kw) {
        i = 0;  /* needed by PyDict_Next */
        while (PyDict_Next(kw, &i, &key, &value)) {
            res = PyObject_SetAttr(self, key, value);
            if (res < 0)
                goto cleanup;
        }
    }
  cleanup:
    Py_XDECREF(fields);
    return res;
}

Возможно. Обычно роутер - это мини-сервер, специализированная железка, заточенная под задачи роутинга-файрволла-NAT и еще что-нибудь. Плюсы - маленький, нет механики (а значит нет износа), не сдохнет при внезапном выключении питания (сервер тоже не сдохнет, но fsck и возможно пропадание файлов никто не отменял). Минусы - если на сервере планируется не только прокси, но и сервисы, доступные извне - DNS, веб - придется пробрасывать порты и все такое.

Решение с сервером в качестве роутера подойдет тем, кто сам сможет его админить. Решение с роутером в качестве роутера :) подойдет виндовозникам - тогда в качестве прокси можно поставить винду :)

Обычно в таких сценариях всё лежит в поисковом движке. Всё это поля для поиска и id самого товара. Больше этого не надо.
Идет запрос к ES обычно страничный, находятся Id's идет запрос к SQL и вытаскиваются все нужные поля, часто между ES и SQL есть кэш.

Как упаковать в Yii2, это отдельный вопрос (коим не владею), скорее всего вам понадобится позже фасетированние и автокомплит.

Краткий ликбез в то как работает виртуализация, чтобы чуть чуть продвинуть вас в вопросе про решение.
Начнём с простого, как работает x86 система?
Очень укрупнённо и упрощённо, она работает тактами. Каждый такт, процессор выполняет какие либо действия, что-то считает, что-то читает, что-то записывает.
Каждый такт, на процессор поступает набор инструкций и они выполняются.
В каждом такте у нас есть кусочек памяти, с которой мы можем работать - регистры. Какие-то мы можем читать и записывать, какие-то можем только читать, какие-то показывают нам текущее состояние. Регистров много и они разные.
У нас есть таблица прерываний - она показывает нам состояние системы, состояние оборудования и устройств ввода и вывода.
И много всего ещё. Всё это называет Контекст исполнения.
Помимо прочего, у процессора (опять же если упростить) есть система безопастности основанная на уровнях привилегий процесса. Для Windows (и многих других систем), например, это два уровня: ядро (нулевой уровень, уровень ядра) и пользовательский (User-mode). Процесс (а в данном приближении - инструкции) запущенные на разных уровнях имеют различные привилегии, различный доступ к регистрам и прочим ресурсам и имеют различный Контекст исполнения

Как работает ОС в штатном режиме?
Операционная система запускает приложения, передаёт им управление на определённое время, делит процессор между приложениями согласно их приоритетам, их потребностям, наличию фокуса на окне, прерыванием от оборудования или драйверов, забирает процессор, если есть процесс важнее или если есть ожидание чего-либо (чтение, запись диска, сеть и тыды).
Сама ОС и её драйвера, процессы, службы и прочее - работают в определённом Контексте исполнения, он частично меняется для каждого приложения, но не значительно.
ОС (её ядро), часть процессов и часть драйверов - работают на нулевом уровне, с максимальными привилегиями, могут писать\читать куски памяти, писать в любое место, могут читать большинство регистров и так далее.

С точки зрения ОС, что такое виртуальная машина?
Ничего. Ну то есть прям вот так, для ОС нет никакого процесса или представления, для ОС (хостовой ОС) виртуальной машины не существует.

А что есть? Ало?
Есть процесс - гипервизард (если чуть точнее - мониторинг виртуальной машины - VMM). В его задачи входит следить за контекстом исполнения, за прерываниями, забирать управление у гостевой или хостовой ОС. Менять контекст исполнения и возвращать всё назад.

И как это работает?
Такт первый, в комнате двое ОС и VMM.
ОС, вздыхая, присаживаясь на кушетку:
- Кажется я немного устала и дел на сегодня больше нет
VMM:
- Тогда пожалуй мне пора.
Выходит из комнаты с чайником
Такт второй, улица, фонарь, двое в тени.
VMM:
- Псс, слышь, процессор интересует?
Некто:
- О! И маска процессора мне нравится и вообще круто, только регистры что-то не вижу, где, позвольте VT-D?
VMM:
- Чё сказал? Брать будешь нет?
Некто:
- Да ладно, ладно, я ж только спросил, буду конечно, быть виртуалкой меня ещё поучи
Так третий. Заключительный
В комнате накуренно, разбросаны бутылки, пахнет жжёными тряпками. Где-то смеются.
Мужчина в трусах и с пультом от PS4 уставился в монитор. Дверь срывается с петель и падает на пол.
VMM врываясь:
- Всем выйти из сумрака! Это ночной дозор!

*переводя на компьютерные термины.
Для ОС VMM это процесс. ОС передаёт ему управление, как обычному процессу. Тот, меняет контекст исполнения (меняет все все регистры. Или почти все все регистры) и передаёт управление гостевой ОС, та выполняет какую-то свою работу (заведомо зная что она виртуализирована). Дальше гипервизард ставит гостевую ОС на паузу и возвращает всё назад. ПОсле этого хостовая ОС получает свой контекст исполнения и делает свою работу.
И так такт за тактом.
Поступило прерывание? Проверили кому оно, сменили контекст исполнения, доставили прерывание, почистили таблицы, вернули назад.
**на самом деле всё чуть сложнее. И с прерываниями, и с уровнями доступа, и с регистрами, и с оборудованием, и тыды, но это выходит за пределы вопроса (и мне лень).
***речь идёт про аппаратную виртуализацию.

Возвращаясь к вашему вопросу. Как вы хотите из хостовой системы увидеть, что творится в ОС гостя без "особого вмешательства"?

Смените тему диплома. ПОкопайте как работает виртуализация. Сама по себе это очень годная тема для изучения.

Работая с JDBC, вы непосредственно работаете с базой данных, ORM же представляет "обертку" для того же JDBC, которая (ORM) реализует паттерны, обеспечивающее большее удобство, помогает ускорить разработку, очевидно что лучше предпочитать второе, но первое проще для простых задач, более гибко, а также помогает освоить второе.