Введение

1. эпоха web1.0 (около 1996 г.)
2. эпоха web2.0 (около 2006 г.)
3. Эпоха Интернета ---> Эпоха Интернета + ---> Умный город: Didi Taxi, Ele.me (около 2012 г.)
4. Большие данные + облачные вычисления
5. Будущее ИИ со времен эпохи
6. ......

фоновая эволюция

первый период

1. Введение в архитектуру единого приложения

• В самый ранний период развития Интернета все коды, бизнесВсе написано на JSP., также является самой ранней структурой веб-сайта в начале.
• All in one: Все модули и кодсобрать это вместе,не слоистый(около 2000 г.).
• базу данных и код вОдинна сервере

Проблема (обслуживание)

1. Код собранНе надоимеютремонтопригодность(весь код находится на странице JSP)
2. Плохая отказоустойчивость,АномальныйПользовательИнформацию об исключении можно увидеть напрямую, ошибка может привести к тому, что службавремя простоя

2. Введение в многоуровневые этапы

1. Многоуровневая разработкаДля улучшения ремонтопригодности (контроллер, сервис, дао)
2. Архитектура MVC(это шаблон проектирования, основанный на веб-приложении Java)
3. база данных и приложениеРазвертывание разделения серверов

вызывать проблемы (высокий параллелизм)

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

3. Введение в кластерную фазу

• кластер:тот самыйбизнес развернут внесколькона сервере.
• служба поддержкиВысокий параллелизм,Высокая доступность.

Проблемы (Переадресация, Сессия)

• Такмногоизсерверпользователь в конце концовпосетить это?
• Где сохраняется сессия?

4. Nginx, этап Redis

• использоватьОбратный прокси NginxЕдиный адрес запроса пользователя, который использует Niginxбалансировки нагрузкиЗавершите переадресацию запроса пользователя.
• использоватьRedis Cluster(кластер Redis) Реализациясовместное использование сеанса.

создать проблему (базу данных)

• Nginx+TomcatкластерпринесВысокий параллелизмПривести кбаза данныхслишком много давления

5. Этап оптимизации базы данных

репликация master-slave

• используя базу данныхрепликация master-slave,разделение чтения-записиТехнологии
• база данных master-slaveданные междуСинхронизировать: мастер отвечает заДобавления, удаления и модификацииЭксплуатация; подчиненный отвечаетчтение/запросдействовать
• сам mysql поддерживаетmaster-slaveФункция (репликация Master-Slave)

Solr/ElasticSearch

• сама база данныхБольшой объем данныхЭффективность запроса медленная, данечеткий запросПоддержка не очень.
• картинаЭлектронная коммерцияВеб-сайт,поискэто очень важная функция, даже если она выполняетсяразделение чтения-записи, но есть еще много функций, которые не могут быть эффективно решены (сегментация слов)
• Чтобы решить эту проблему, введитеФункция сервера полнотекстового поиска

Кэш Redis

• существуетбольшой параллелизмЧехол дляДанные точки доступа, количество запросов к базе данных равномассивный, однако база данныхне в состоянии справитьсяТакой большой запрос приведет к тому, что база данных не сможет предоставлять внешние услуги (исключение при подключении).
• использоватьRedisкеш, т.горячая точкаДанные хранятся в Redis,нет нуждыБаза данных запрашивается каждый раз.
• и РедисОтличная производительность чтения и записи,имеютБогатыйизтип данныхи поддержкаатомарность

Разделение таблиц базы данных

• Таблица имеет1000 штукзапрос данныхвысокая производительность.
• как в таблице1000000данные, запроснизкая производительность.
• Улучшить производительность одной таблицы, но возможности для улучшения еще естьограниченноеиз.

вертикальное разделение

• Предположим, что пользовательская таблица имеет30Поля: id, имя, возраст, идентификационный номер, рост, вес, пол, номер мобильного телефона, домашний адрес...
• популярные поля: идентификатор, имя, идентификационный номер, возраст, пол, номер мобильного телефона
• непопулярное поле: остальное осталось
• мы можем поставитьпопулярныйполе помещается впользовательская таблицасередина,непопулярныйполе помещается вuserinfoтаблицу, заполнить таблицурасколоть

разделить по горизонтали

• согласно снужносплит (провинция/время)
• мы можем поставитьпользовательская таблицаданные, согласноразные провинцииразбить на разные таблицы

Промежуточное ПО, использующее стороннюю подбазу данных и подтаблицу

• mycat, sharding-jdbc, drds (Али)
• Гарантия дизайнаВысокий параллелизм,Высокая доступность(путем постоянного добавления серверов)

https://blog.csdn.net/jornada_/article/details/82947677

возникающие проблемы

1. серверочень дорого,существуетНеравномерная занятостьпроблема (количество посещений во время Double 11 было большим), серверподдерживатьТребует больших трудозатрат (инженер по эксплуатации и обслуживанию)
2. плохая ремонтопригодность: требуется изменение бизнеса на каждом серверепередислоцировать
3. Плохая масштабируемость: (имеется в виду сервер)добавить большеСервер, которому необходимо перенастроить среду
4. Совместная разработкаНеудобно: всем приходится изменять один и тот же бизнес-код, возникают конфликты/ошибки кода.
5. Монолитная архитектура: с постоянным ростом бизнес-требований код приложения также будет становиться все больше и больше, что приведет к тому, что при развертывании на сервере будет занимать слишком много места на жестком диске.

второй период

Обзор вертикальной архитектуры приложений

По мере того, как количество посещений будет постепенно увеличиваться,одно приложениеувеличено на машинеускорениеСтановясь все меньше и меньше, приложение разбивается наНесколько не связанных между собой приложений, для повышения эффективности. На данный момент используется для ускорения разработки страниц интерфейса.веб-фреймворк(MVC) является ключевым.

Horizontal Split (разделить по горизонтали)

Требования к сценарию

Теперь сайт разделен настойка регистрации(для использования пользователем),За кулисами(для админов), нужно ли его разбирать на2 проекта развернуты независимо? Если его нужно разобрать, есть несколько передних и заднихобщественныйкод, что насчет этих кодов?

метод разделения

• по разнымуровеньрасколоть
• будетбольшойразделение приложенийнесколько маленькихзаявление

parent pom    #父工程（放所有的pom.xml)
common.jar    #公共库 相关工具类
pojo.jar      #java bean
mapper.jar    #数据持久层
service.jar   #业务逻辑层
web.war       #web访问层
manager.war   #后台管理

преимущество

1. независимый jпакет ar, модульмультиплекс
2. уменьшатьохватыватьразвертыватьсервер временидискЗанято:Пользовательпосетилweb.waг пакет можетмногоразвернуть несколько серверов,За кулисамиудалосьmanager.waпакет r развернут1сервер

Вертикальное разделение (вертикальное разделение)

метод разделения

• по разнымФункциирасколоть
• положитьБольшойприкладная прессаФункцииразделить на нескольконесвязанные апплеты, и каждое приложениеНезависимостьвеб-приложение (в направлении распределенной разработки)

преимущество

1. ремонтопригодность:еслинужнопроисходитьизменять,нужно тольконастроитьзаявлениемодульТолько что
2. Функциональное расширение:Увеличиватьдля различных потребностей бизнеса,УвеличиватьСоответствующий веб-сайтмодуль
3. Совместная разработка — это удобно: Разные команды отвечают за разные модули.
4. Настройка производительности развертывания: к какому модулю обращаетсяБольшой,Сразунесколько развертыванийНесколько серверов, отвечающих за модуль

возникающие проблемы

1. пара клиентовстраницаизТребоватьвсе больше и большевысокий,необходимостьЧасто меняйте страницы, но в это времяПередний и задний концы не разделены(Каждыйзаявлениеот начала и до концавсе), каждый разпередислоцироватьФоновое приложение.
2. вместе сбизнеспостоянный спросУвеличивать, несколькоразныеизмодульможет произойти междуделовое взаимодействие,(разные модули развернуты на разных серверах) как решить?

третий период

• когдавертикальное применениевсе больше и большемного, между приложениямивзаимодействоватьнеизбежно,основнойбизнесизвлекатьвне, какНезависимостьуслуги, постепенно формируя устойчивыйСервисный центр,Сделатьвнешний интерфейсПрикладная энергияБыстреебыстрооткликизменениеРыночный спрос. В этом случае для улучшенияповторное использование в бизнесеа такжеИнтегрированная структура распределенных служб(RPC) является ключевым.
• RPC: (Удаленный вызов процедуры) являетсяпротокол связи с компьютером, протокол позволяет работать наодинкомпьютерпрограмма вызывает другуюкомпьютерподпрограмма, а программистнет нуждыдополнительно за это взаимодействиепрограммирование. РПЦ – этоРаспределенных вычисленийизCSрежим, всегда поClientОтправить сервер для выполнения ряда процессовпросить,Serverпринять запрос, использоватьклиенткоторый предоставилпараметр, после завершения расчета результат будетвернутьклиенту. Существует множество протоколов RPC, таких как самый ранний CORBA, Java RMI, RPC-стиль веб-службы, Hessian, Thrift и даже Rest API.

Обзор распределенной архитектуры

• будетОдинбизнесрасколотьстатьнесколько суббизнес, развернутый вразныена сервере
• использоватьПереднее и заднее разделениеРазработка/развертывание (страница + бизнес-код)

• использоватьRPC,Http,HttpClient и другие базовые технологииРазрешение вызовов между разными модулями

возникающие проблемы

1. Распределенная транзакция: двухэтапная фиксация
2. Распределенная блокировка: Значение ключа Setnx в Redis
3. Распределенная сессия: Кластер Redis
4. Распределенный журнал: ELK (Elasticsearch, Logstash и Kibana)

• когдаСлужитьвсе больше и большемного, между сервисами и сервисамиперечислитьочень запутанно (я даже не знаю тебяЧтосервис) (RPC)
• ресурсизнапрасно тратитьПроблема (плата за управление трафикоммаленький,норазвернутый100сервер, логистика, управление трафикомБольшой,ноТолькоразвернутый50сервер)

Четвертый период

Обзор архитектуры мобильных вычислений

• когдаСлужитьвсе больше и большемного,емкостьизоценивать,небольшой сервисРесурсынапрасно тратитьПри постепенном появлении проблемы необходимо добавитьдиспетчерский центрна основе давления доступаУправляйте емкостью кластера в режиме реального времени, увеличение кластераИспользование. На данном этапе центр планирования ресурсов и управления (SOA) для повышения эффективности использования машин является ключевым.
• SOA: Сервисно-Ориентированная Архитектура,"Сервисно-Ориентированная Архитектура": ОнМетод проектирования, который содержитнесколькоуслуги, между услугами черезвзаимозависимостьв конечном итоге предоставить рядФункции.Служба обычно начинается сНезависимостьформасуществуетВоперационная системав ходе выполнения. между службамиИнтернетперечислить.

решение

• Распределенное управление услугамипромежуточное ПО: (Дуббо/СпрингКлауд)
• Пример:

以一个公司为例：有基层员工， 有管理层， 有老板。
最初大家都听老板指挥，谁干什么谁干什么，根据需要，你可能今天干A事情，明天干B事情，后来人越来越多了，事情也越来越多了，做事情的效率越来越多，管理也很混乱，
就开始做部门划分（服务化），专门部门做专门事情的，IT部门只做研发，人事部门只做招聘； 这个时候就无法避免的发生跨部门协作（服务器调用）， 但是你怎么知道有这样一个部门可以做这个事情呢，就要依赖行政部门（注册中心），新成立的部门要在行政哪里做一个备案（服务注册），然后公布一下，让其他部门知道了（服务发布），大家就可以在新的工作秩序里面嗨皮的上班了，这个时候依然是在公司的组织架构中运转

• DubboНижний слойRPCПротокол (Dubbo — это RPC-фреймворк).
• SpringCloudНижний слойHTTPпротокол.

Микросервисы и SpringBoot

Микросервисы

• Монолитное приложение разделено на несколько не связанныхапплет, каждое маленькое приложение называетсяМикросервисы.

• потому чтоSOA(Сервис-ориентированная архитектура) также основана наапплет, мы также можем назвать этоМикросервисная архитектура

преимущество

1. Микросервисыдля деловых функцийрасколотьболеедотошный(возможность повторного использованиясильнее), что улучшает развитиеэффективный
2. Сильная масштабируемость: Вы можете выбрать использование в соответствии с вашими потребностяминовейшая технология
3. применять кИнтернетПроект: Итеративный циклкороткая, эффективность разработкибыстро

недостаток

1. Микросервисы тожемного,Услугиуправление/управлениевысокая стоимость
2. неблагоприятный для обслуживанияразвертывать: Доступны Docker/K8S
3. ТехнологиитрудностьВ росте: распределеноТранзакция, Блокировка, Сеанс, Журнал
4. для программистовТребоватьПостоянно улучшаем:Dubbo/SpringCloud

возникающие проблемы

• мономерАрхитектура приложений, которую мы используемSSM-фреймворкТолько что
• когда мы ставиммономерАрхитектура приложения разделена нанесколько апплетов, каждый апплетНезависимостьвеб-программы, каждая из которых должна выполнятьсяКонфигурация SSM(Включатьмного повторенийjar и файл конфигурации)

Springboot

используется дляупрощатькодразвиватьи упрощенный кодРамкаизПостроить.

---

PS:

1. Почти все ониручной тип,дляфокусЧастичносмелыйоперация, легко читаемая, соригинальныйсодержание
2. Некоторые ресурсы организованы онлайн, если есть какие-либо нарушения, просьба сообщить об удалении.
3. Пожалуйста, указывайте источник при перепечатке этой статьи