Создание микросервиса планирования маршрутов в системе оптимизации логистики
ВВЕДЕНИЕ
Актуальность исследования. Предприятие О-Рейли проложила исследование о внедрении Микросервисы в 2020 г.. В выборочном опросе принимали участие промышленные специалисты и главы. Микросервисами пользуются 77% анкетированных. Приблизительно 28% респондентов заявляют, то что их компании пользуются микросервисами не меньше трех лет; более 3/5 (61%) респондентов используют микросервисы в протяжение года и более. При 54% респондентов с микросервисами всё вышло: они представляют свое умение как «полный либо практически успех», 10% достигли максимального преуспевания и только у 8% — полный крах. Среди положительных сторон введения микросервисов анкетированные выделяют эластичность функций, активное изменение под новые требования и улучшение масштабируемости. Меньше всего фирмы занимают сокращение расходов в разработку и повышение доступности благодаря избыточным функциям. Основная трудность, что препятствует внедрению микросервисов, — коллективная культура. К слову, это ведь препят
Содержание
ВВЕДЕНИЕ 9
1. Теоретическое изучение особенностей монолитного и микросервисного подходов при проектировании масштабируемой веб архитектуры 11
1.1. Определение понятия масштабируемой веб архитектуры и ее основные характеристики 11
1.2. Анализ основных типов архитектур для построения современного программного обеспечения 14
1.3. Обзор и анализ проблемы использования монолитной архитектуры в крупных веб системах. Детальное сравнение микросервисов и монолитной архитектуры 17
2. Исследование проблема маршрутизации транспортных средств (VRP) 25
2.1. Определение и классификация основных видов задачи маршрутизации транспортных средств (VRP) 25
2.2. Определение эвристических алгоритмов и анализ работы принципа “разрушения и воссоздания” в задачах VRP 28
2.3. Анализ подходящих инструментов для планирования маршрутов на базе VRP 31
3. Исследование процесса миграции монолитной архитектуры на микросервисы 33
3.1. Причины и предпосылки перехода от монолитной архитектуры к микросервисам 33
3.2. Инфраструктурные требования для перехода к микросервисной архитектуре 35
3.3. Миграция устаревшего программного обеспечения на микросервисную архитектуру 37
4. Сравнительный анализ технологий и инструментов для построение микросервисной архитектуры 43
4.1. Микросервисные коммуникации c использование очереди сообщений. Сравнение очереди сообщений (MQ) и REST API 43
4.2. Обзор фреймворков передачи данных Apache Kafka и RabbitMQ и их сравнение. Описание принципа работы брокера сообщений RabbitMQ 49
4.3. Определение контейнеризация и преимущества ее использования. Микросервисы и контейнеризация. Контейнеры Docker 54
4.4. Определение оркестрация контейнеров, преимущества и принцип работы. Сравнение и обзор Kubernetes, Docker Swarm и Apache Mesos 61
5. Построение микросервисной архитектуры на базе системы оптимизации логистики 66
ЗАКЛЮЧЕНИЕ 77
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 79
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
[1] R. Chen, S. Li, and Z. Li, “From Monolith to Microservices: A DataflowDriven Approach,” in 2017 24th Asia-Pacific Software Engineering Conference (APSEC), 2017, pp. 466–475.
[2] N. Dragoni et al., “Microservices: yesterday, today, and tomorrow,” ArXiv160604036 Cs, Jun. 2016.
[3] S. Newman, Building microservices: designing fine-grained systems. " O’Reilly Media, Inc.", 2015.
[4] R. Chen, S. Li, and Z. Li, “From monolith to microservices: a dataflow- driven approach,” in 2017 24th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 2017, pp. 466–475.
[5] D. Taibi, V. Lenarduzzi, and C. Pahl, “Processes, motivations, and issues for migrating to microservices architectures: An empirical investigation,” IEEE Cloud Computing, vol. 4, no. 5, pp. 22–32, 2017.
[6] Apter, Michael J. (1970). The Computer Simulation of Behaviour. London: Hutchinson & Co. p. 83.
[7] Introduction to Algorithms (Cormen, Leiserson, Rivest, and Stein) 2001, Chapter 16 "Greedy Algorithms".
[8] Z. Dehghani, “How to break a Monolith into Microservices.” [Online]. Available: https://martinfowler.com/articles/break-monolithintomicroservices.html
[9] A. Bucchiarone, N. Dragoni, S. Dustdar, S. T. Larsen, and M. Mazzara, “From monolithic to microservices: an experience report from the banking domain,” Ieee Software, vol. 35, no. 3, pp. 50–55, 2018.
[10] S. Anees, “How to Migrate to Microservices.” [Online]. Available: https://blog.appdynamics.com/product/how-to-migrate-tomicroservices/
[11] M. Mishra, S. Kunde and M. Nambiar, “Cracking the Monolith: Challenges in Data Transitioning to Cloud Native Architectures.” ECSA '18 Proceedings of the 12th European Conference on Software Architecture: Companion Proceedings, Madrid, 2018, pp. 1–4.
[12] G. Mazlami, J. Cito and P. Leitner, "Extraction of Microservices from Monolithic Software Architectures," 2017 IEEE International Conference on Web Services (ICWS), Honolulu, HI, 2017, pp. 524–531.
[13] I. Azarny, “CI/CD for Containerized Microservices.” [Online]. Available: https://dzone.com/articles/cicd-for-containerised- microservices
[14] A. Balalaie, A. Heydarnoori and P. Jamshidi, "Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture," in IEEE Software, vol. 33, no. 3, pp. 42–52, May-June 2016.
[15] H. Rosendahl, “Containers vs Virtual Machines (virtual security) – A Security Perspective.” [Online]. Available: https://neuvector.com/container- security/containers-vs-virtual-machines-vms/
[16] O. Pozdniakova and D. Mažeika, “Systematic Literature Review of the Cloud-ready Software Architecture.” Baltic J. Modern Computing, vol. 5, pp .124– 135, March 2017
[17] S. Anees, “How to Migrate to Microservices.” [Online]. Available: https://blog.appdynamics.com/product/how-to-migrate-tomicroservices/
[18] A. Levcovitz, R. Terra, M. T. Valente, “Towards a Technique for Extracting Microservices from Monolithic Enterprise Systems.” 3rd Brazilian Workshop on Software Visualization, Evolution and Maintenance (VEM), p. 97– 104, 2015
[19] R. Chen, S. Li and Z. Li, "From Monolith to Microservices: A DataflowDriven Approach," 2017
Задача эвристики состоит в том, чтобы найти решение в течение разумного времени, достаточного для решения поставленной задачи. Это решение может быть не лучшим из всех решений этой проблемы, или оно просто приближается к точному решению. Но это все равно того стоит, потому что осознание этого не займет много времени.
Термин эвристический используется для алгоритмов, которые находят решения из всех возможных, но это не гарантирует, что будет найдено наилучшее, поэтому его можно считать алгоритмом приближения, а не точным алгоритмом. Эти алгоритмы обычно находят решение, близкое к наилучшему, и находят его быстро и легко. Иногда эти алгоритмы могут быть точными, то есть они действительно находят лучшее решение, но метод, используемый в эвристических алгоритмах, это лучшее решение оказывается лучшим, является одним из хорошо известных методов, таких как жадность, но для простоты и скорости алгоритм не является требованием задачи.