В этой статье обобщаются общие концепции, принципы и идеи проектирования архитектуры программного обеспечения.

Архитектура
В этой статье обобщаются общие концепции, принципы и идеи проектирования архитектуры программного обеспечения.

Управляемое чтение

В этой статье обобщаются общие концепции, принципы и идеи проектирования архитектуры программного обеспечения, включая шесть принципов объектно-ориентированного подхода, принцип DID, ACID, CAP, теорию BASE, идею среднего уровня, идею кэширования и т. д.

Шесть принципов объектно-ориентированного проектирования

Принцип единой ответственности (SRP):

Определение состоит в том, что для класса должна быть только одна причина для его изменения. Другими словами, класс должен отвечать только за одно;

Два принципа открыто-закрыто (OCP):

Определение заключается в том, что объекты (классы, модули, функции и т. д.) в программном обеспечении должны быть открыты для расширения, но закрыты для модификации, при изменении требований необходимо модифицировать код. расширять исходный код вместо изменения исходного кода, так как это может вызвать больше проблем;

Три принципа замены Лисков (LSP):

Все ссылки на базовый класс должны иметь возможность прозрачно использовать объекты его подклассов; подкласс может расширять функции родительского класса, но не может изменять исходные функции родительского класса, что включает в себя следующие значения: 1. Подкласс может реализовывать абстрактные методы родительского класса, но не может переопределять неабстрактные методы родительского класса; 2. Подклассы могут добавлять свои уникальные методы; 3. Когда метод подкласса перегружает метод родительского класса, формальные параметры метода более расслаблены, чем входные параметры метода родительского класса; 4. Когда метод подкласса реализует абстрактный метод родительского класса, возвращаемое значение метода является более строгим, чем у родительского класса;

Принцип инверсии четырех зависимостей (DIP):

Модули высокого уровня не должны зависеть от модулей низкого уровня, оба должны зависеть от абстракции; абстракция не должна зависеть от деталей, но детали должны зависеть от абстракции; определение немного сбивает с толку, грубо говоря, это программирование против интерфейс, а не реализация; (абстрактный относится к интерфейсу или абстрактному классу, ни один из которых не может быть создан; а детали - это класс реализации, то есть класс, который реализует интерфейс или наследует абстрактный класс, он может быть создан ; модуль высокого уровня относится к вызывающей стороне, а модуль нижнего уровня — к концу. Для конкретных классов реализации в java принцип инверсии зависимостей означает, что зависимости между модулями возникают посредством абстракции, и между классы реализации и их зависимости реализуются через интерфейсы, что является популярным интерфейсно-ориентированным программированием)

Пять принципов изоляции интерфейса (ISP):

Клиент не должен полагаться на ненужные ему интерфейсы;

Шесть принципов Деметры (LOD):

Объект должен иметь минимальные знания о других объектах;

Роберт С. Мартин определил 5 принципов единой ответственности, принципа открытости-закрытости, замены Лискова, разделения интерфейса и инверсии зависимостей как принципы SOLID в начале 2000-х годов.

принцип DID

Разработать (D) спроектировать в 20 раз больше возможностей; Внедрить (I) реализовать в 3 раза больше возможностей; Развернуть (D) развернуть в 1,5 раза больше возможностей. DID обеспечивает экономичный, эффективный и своевременный метод расширения ассортимента продукции.

мышление среднего уровня

Архитектура программного обеспечения компьютерных систем имеет многоуровневую структуру.Кто-то однажды сказал известную поговорку:

Любая проблема в информатике может быть решена с помощью другого уровня косвенности. (Любая проблема в информатике может быть решена путем добавления непрямого промежуточного слоя.)

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

  • Трехуровневая архитектура MVC
  • Четырехуровневая/семиуровневая сетевая модель
  • Добавьте слой кеша, чтобы повысить производительность системы.
  • ...

кешировать идеи

Мир похож, в деловом мире есть классическая поговорка «наличные деньги правят». В Интернете и даже во всем мире программных технологий есть соответствующая поговорка: «Кэш — король». По всей системе кэши есть везде.

Кэш процессора

Поскольку скорость работы ЦП намного выше, чем скорость чтения и записи в память, ЦП всегда должен ждать данных, а кеш решает противоречие между скоростью работы ЦП и скоростью чтения и записи в память. Когда ЦП вызывает данные, он сначала вызывается из кэша, что ускоряет чтение. Кроме того, ЦП имеет несколько уровней кэша.

кеш браузера

Фронтальное кэширование страниц имеет два значения: во-первых, сама страница кэширует некоторые или все элементы страницы, а во-вторых, сервер кэширует элементы статической или динамической страницы, а затем использует их для клиента. Кэш страницы здесь относится к кешу самой страницы или кешу автономного приложения. HTML5 поддерживает автономное кэширование и локальное хранилище, и с помощью этой функции можно легко создавать страничные приложения.

кэш в сети

  • Кэширование CDN
  • кеш обратного прокси

кеш сервера

  • кэш уровня памяти
  • Распределенный кеш

кеш базы данных

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

КИСЛОТА (кислота)

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

A: атомарность

Атомарность означает, что транзакция является неделимой единицей работы, и операции в транзакции выполняются либо все, либо ни одна из них.

С: Консистенция

Целостность данных до и после транзакции должна оставаться неизменной.

Я: Изоляция

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

Д: долговечность

Долговечность означает, что после того, как транзакция зафиксирована, ее изменения в данных в базе данных являются постоянными, и даже если база данных выходит из строя, это не должно оказывать на нее никакого влияния.

CAP (принцип ограничения)

Принцип CAP, также известный как теорема CAP, относится к тому факту, что в распределенной системе три элемента CAP могут достигать не более двух одновременно, и невозможно учесть все три. CAP относится к

С: Консистенция

Данные всех узлов одновременно полностью непротиворечивы, под непротиворечивостью здесь понимается сильная согласованность

А: Доступность

В доступной распределенной системе каждый исправный узел должен отвечать на каждый запрос. Обычно мы используем几个9Для описания доступности, например, доступность 5 девяток означает, что уровень доступности составляет 99,999%, то есть годовое время простоя не превышает (1-0,99999)36524*60 = 5,256 мин.

P: Допуск перегородки

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

БАЗА (база)

Дэн Притчетт, архитектор eBay, исходил из практического обзора крупномасштабных распределенных систем и опубликовал статью о ACM, чтобы предложить теорию BASE. Теория BASE является расширением теории CAP. Основная идея заключается в том, что даже если не может быть достигнута строгая согласованность (строгая согласованность, согласованность CAP — это строгая согласованность), но приложение может достичь согласованности в конечном счете (согласованность в конечном счете) подходящим способом.

BA: в основном доступно

Базовая доступность означает, что при сбое распределенной системы часть доступности может быть потеряна, то есть ядро ​​гарантированно будет доступно. Чтобы справиться с всплеском трафика во время продвижения электронной коммерции, некоторые пользователи могут быть перенаправлены на страницу понижения версии, а сервисный уровень может предоставлять только услуги понижения версии. Это воплощение потери частичной доступности.

S: Мягкое состояние

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

E: в конечном счете последовательный

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

теория кислотно-щелочного баланса

ACID является широко используемой концепцией проектирования для традиционных баз данных и использует модель строгой согласованности. BASE поддерживает крупномасштабные распределенные системы и предлагает достичь высокой доступности, пожертвовав строгой согласованностью. ACID и BASE представляют две диаметрально противоположные философии дизайна, основанные на酸碱平衡理论, то есть в разных сценариях используйте ACID и BASE соответственно для решения проблемы распределенной согласованности.

Спасибо за прочтение, если что-то получится, пожалуйста点赞,очень прошу关注Пусть больше людей увидят эту статью, эта статья была впервые опубликована в технической публичной учетной записи, которая не ограничивается технологиями.Nauyus, добро пожаловать, чтобы определить QR-код ниже, чтобы получить больше контента, в основном делиться оригинальными техническими продуктами, такими как JAVA, микросервисы, языки программирования, архитектурный дизайн, мышление и познание, и запускать режим еженедельного обновления с декабря 2019 года. Добро пожаловать, чтобы обратить внимание и присоединяйтесь к Науюс ЖЖ.

Преимущество 1: Видеоруководство по бэкенд-разработке

Десятки наборов видеоруководств по разработке серверной части JAVA, собранных за годы, включая микросервисы, распределенные, Spring Boot, Spring Cloud, шаблоны проектирования, кэширование, настройку JVM, MYSQL, крупномасштабные распределенные боевые проекты электронной коммерции и другой контент, Follow Nauyus и немедленно ответьте на [Видеоучебник] Нет никакой процедуры, чтобы получить его.

Welfare 2: Пакет и загрузка вопросов для интервью

Сводка ресурсов с вопросами для собеседований, собранных за прошедшие годы, включая руководства по поиску работы, навыки прохождения собеседований и сводку вопросов для собеседований от Microsoft, Huawei, Ali, Baidu и других компаний. В этой части еще разбираются, можете продолжать обращать внимание. Немедленно следуйте за Наюсом, чтобы ответить на [Вопросы интервью]. Нет никакой процедуры, чтобы получить это.