Я давно работаю с платформой Java и прекрасно знаю ее сильные и слабые стороны.
В этой статье я хочу рассказать вам, как могла бы сложиться история, если бы не она.
В конце концов, мы могли бы использовать машину Java вместо систем Docker. А сама Java-машина могла бы полностью заменить ОС.
Это обзорная статья, я лишь изложу несколько мыслей.
Их полный анализ занял бы много места.
Итак, Java-машина — это ОС.
Местами даже круче ОС.
На самом деле, это не такое уж и необычное заявление.
Ведь всем хорошо известен пример полноценной ОС, существенно основанной (изначально) на Java — Андроид .
Кроме того, существуют операционные системы в классическом понимании, полностью основанные на JVM. Итак, какие характеристики ОС у нас есть в JVM? Управление памятью - несомненно.
Управление потоками — да, но обычно на основе существующих локальных потоков базовой ОС.
Однако потоки являются важной неотъемлемой и высокоразвитой подсистемой машины, предоставляющей гораздо больше услуг, чем базовые потоки ОС.
Ввод-вывод также очень развит, если принять во внимание всю инфраструктуру Java со всеми серверами и библиотеками.
В этом смысле ввод-вывод базовой ОС примерно подобен старому BIOS для последней, он осуществляет низкоуровневые операции.
У Java есть философия.
Если в Unix все является файлом, то в Java все (почти) является объектом.
Есть важная часть системы, о которой многие либо не знают, либо забывают. Java — это среда с мощными инструментами контроля доступа.
Именно поэтому он широко используется в банковском секторе.
Наличие этих инструментов вкупе с полной многопоточностью на уровне языка создает предпосылки для создания многозадачной И многопользовательской среды исполнения.
Многие знают о многопоточности.
Что касается контроля доступа, давайте разберемся подробнее.
Во-первых, JVM — это управляемая среда.
Это означает не только безопасность выполнения кода.
Это тоже модель демаркации, аналогичная разделению ядра в большинстве ОС на отдельный привилегированный контекст выполнения.
Т.
Н.
Собственный контекст исполнения, в котором работает сама машина, является прямым аналогом реального (или подобного) режима исполнения ядра ОС процессором.
Сама машина имеет полный контроль над всеми процессами внутри нее.
Байт-код уже имеет очень ограниченную, защищенную среду.
Степень свободы загруженного байт-кода определяется Java-машиной и ее библиотекой времени выполнения.
Иерархия загрузки в эталонной реализации сервера приложений Более того, механизм загрузки байт-кода (классов в первую очередь) иерархичен и предполагает разделение прав и обязанностей — ветвление прав.
Такое ветвление достигается за счет использования отдельных загрузчиков классов.
Это создает иерархию областей действия; код, загруженный в одном контексте, не имеет доступа к другому независимому контексту.
В этом случае невозможно получить указатель на произвольную область памяти, нет доступа к произвольным полям объектов, даже через механизм отражения, даже к целым отдельным объектам.
Этот механизм встроен в язык (ключевые слова приватный, защищенный и т.п.
) и в платформу — уже упомянутые загрузчики и, конечно же, менеджеры безопасности, о которых мы тоже не забудем.
Такие механизмы обеспечивают разделение контекстов выполнения аналогично классическим процессам ОС.
Я бы даже сказал более строгое и надежное разделение.
Загрузчики классов вместе с менеджерами безопасности (SecurityManager) обеспечивают полный контроль над тем, что может попасть внутрь среды выполнения Java, а что нет. Этот механизм чрезвычайно гибок.
При этом, в отличие от нативного кода, загружаемый байт-код проходит полную проверку на валидность (он не может тогда вызвать непредсказуемый сбой) и безопасность — поскольку возможные варианты поведения ограничиваются тем же загрузчиком + менеджером безопасности.
Вы когда-нибудь слышали о вирусах в Java? Для больших систем описанный выше механизм хорошо сочетается с модульностью и плагинным подходом.
При этом, как я уже говорил, эта система плагинов гораздо более безопасна, чем ее аналоги, поскольку плагины могут вести себя как отдельные приложения.
Яркий пример — OSGi. Здесь стоит отметить, что все вышеперечисленные возможности существуют в рамках всего одного процесса.
Это устраняет необходимость в сложных, рискованных и дорогостоящих механизмах межпроцессного взаимодействия.
С другой стороны, есть один из главных недостатков Java-машины, которая до недавнего времени изрядно портила бочку меда — большая общая куча со сборкой мусора.
Но новое поколение ассемблеров практически полностью устранило этот недостаток, позволив запускать Java-машины с кучей десятков гигабайт.
Круче, чем кубер
Почему Java-машина круче кубера? Потому что, как я уже говорил, он позволяет создавать множество независимых изолированных контекстов — пространств имен чтения — на основе общего ядра Java-машины и библиотеки времени выполнения.И эти пространства можно настраивать более гибко, обеспечивая разные уровни изоляции (доступа).
Их можно дополнительно настроить.
Отличным примером этого являются мощные серверы приложений.
Они предлагают все, что обещают нам Docker и его оркестраторы — отказоустойчивость, балансировку нагрузки, отличную модульность (суть микросервисов), сервисы и веб-сервисы и даже самые микро- и наномодули — лямбды в виде сверхлегких ejbs, решение проблем совместимости версий библиотек, удаленный вызов процедур как альтернатива protoBuf & gRPC — RMI и его разработка Corba & RMI-IIOP. И это все в виде стандартов и множества реализаций.
Не хватает только красивых картинок и графиков (хотя это зависит от реализации) и развертывания инфраструктуры из нарисованной схемы.
Но последнее бесплатно в коробку с Кубером никто не положит. И для иллюстрации давайте посмотрим на стандартную модульность сервера приложений.
Существует иерархия загрузки: система -> сервер -> приложение -> модуль приложения.
Итак, это все на данный момент. Давайте порадуемся выходу очередной версии Jakarta EE 9 и пожелаем им успехов.
Теги: #облачные сервисы #Kubernetes #docker #java #Распределенные системы #jvm #модульность #javaee #операционные системы
-
Пкanywhere
19 Oct, 24 -
Генерация Локальных Обратных Ссылок
19 Oct, 24 -
Потебня Александр Афанасевич.
19 Oct, 24 -
Как Я Пришел В Ux
19 Oct, 24 -
Темная Сторона Визуальной Студии
19 Oct, 24
