Распределенные системы (Бизнес-информатика), презентации к курсу

1. 1 / 102
Распределённые системы
Старолетов СМ serg_soft@mail.ru
Курс для Бизнес Информатики
ФИТ АлтГТУ

2. 2 / 102
Распределенная система
●
В современном мире людьми используются
приложения, которые уже не работают только на
локальном компьютере пользователя, а
взаимодействуют друг с другом через сети
передачи данных.
●
Распределенная система – это программно-
аппаратный комплекс, позволяющий запускать
многокомпонентное приложение, части
(компоненты) которого работают на разных
узлах.

3. 3 / 102
Узел (node, нод)
●
Узел распределенной системы – устройство, на
котором работает один из компонентов
распределенной системы.
●
Узлы низкосвязаны. Обмен через сообщения.

4. 4 / 102
Тема 1. Параллельные
системы и алгоритмы
●
Параллельное программирование – способ
решения задач, при котором задачи разделяются
на параллельно выполняющиеся подзадачи.
●
Распределенное программирование – это
случай параллельного программирования, когда
эти подзадачи выполняются на разных узлах.
●
В параллельном программировании узлом
является процессор или ядро

5. 5 / 102
Максимальное ускорение в
параллельной обработке
●
Параллельное программирование позволяет решать
задачи параллельной обработки больших данных со
снижением времени решения в задачи до P раз
(идеальный случай), где P- количество параллельно
работающих узлов с использованием параллельных
алгоритмов.
●
То есть Р процессоров/ядер ускоряют в P раз в идеале
●
Закон Амдала определяет оценку параллелизма при
наличии последовательных частей в алгоритме, любой
последовательный код значительно снижает скорость и
масштабируемость

6. 6 / 102
Многоядерный процессор
●
Современные процессоры масштабируются не по
частоте, а по числу ядер и оптимизации внутренней
архитектуры
●
Ядро процессора может
независимо выполнять
свой поток команд
●
Ядра могут быть
виртуальными, они делят неисользуемые регистры
процессора и эффективны при небольшом объеме
вычислений в потоках
●
Современные процессоры содержат уже >= 32 ядра
(Intel i9, AMD ThreadRipper)

7. 7 / 102
Поток, нить (thread)
●
Процесс (process) – это образ запущенного
приложения в памяти.
●
Поток (thread – англ. нить) - это абстракция,
созданная для выполнения параллельных задач
в рамках одного процесса. Это
последовательность операций процессора,
выполняющаяся во времени независимо
(асинхронно) от других потоков.

8. 8 / 102
Информация о загрузке по каждому ядру и
количество потоков у процессов в системе

9. 9 / 102
Целесообразность
●
Время на создание потоков большое
●
Переключение большого числа потоков или
тяжелых потоков приносит проблемы
●
Если задача мала, нет смысла ее решать
параллельно
●
Параллельно следует решать задачи,
обрабатывающие большие данные
●
Время работы от нескольких секунд
●
Тогда можно наблюдать ускорение

10. 10 / 102
Параллельное
программирование в C#
●
Можно параллелить алгоритм по задачам (каждый поток
решают свою задачу) и по данным (каждый поток решает
задачу на части исходных данных)
●
Если не запрограммировать, возможности распределения по
ядрам/процессорам не включаются сами
●
Это одна из задач современной программной инженерии – как
автоматически распареллелить программы
●
Потоки создаются явно или неявно(пример – таймеры,
асинхронные вызовы)
●
Мы будем использовать явное создание: поток выполняет
заданную функцию в фоне

11. 11 / 102
●
Задача делится на части (обычно по данным)
●
Запускаются потоки, каждый поток решает
подзадачу (обрабатывает свою часть данных) и
сохраняет результат
●
После ожидания всех потоков главная функция
проводит финальную редукцию результатов
Решение с распределением
подзадач по потокам

12. 12 / 102
Создание потоков в C#
●
Создаем P потоков и передаем каждому потоку
его номер
●
Здесь threadFunc – это функция (статический
метод), которая будет работать в потоке
параллельно

13. 13 / 102
Функция потока

14. 14 / 102
Пример: поиск минимума в
большом массиве
●
Нужно найти минимальное значение
●
Идем по всем элементам и сравниваем с
текущим минимумом
●
Долго!! Проход по всему массиву+операции

15. 15 / 102
Параллельный алгоритм
●
1. Разделим задачу по данным: пусть каждый поток ищет минимум в своей
части массива
●
2. Передадим потоку его номер, а он по номеру вычислит начало своей
части ( номер потока * число элементов / число потоков), а также размер
своего куска данных (число элементов/ число потоков). Здесь мы не
учитываем случай, что потоков больше, чем элементов или что число
элементов не делится на цело на число потоков. Поскольку потокам
доступны глобальные данные, то сам массив, его размер, количество
потоков не передается через параметры.
●
3. Каждый поток находит свой минимум и сохраняет в массив
промежуточных минимумов (индекс в массиве – номер потока). В главном
процессе этот массив создается перед запуском потоков.
●
4. Потоки синхронизуются (барьерная синхронизация).
●
5. Главный процесс ищет минимум среди минимумов и получает
результирующий минимум.

16. 16 / 102
Реализация – главная функция

17. 17 / 102
Реализация – функция потока

18. 18 / 102
Диаграмма состояний
Создание
Функция потока
Редукция

19. 19 / 102
Возможные ошибки (нельзя!)
●
Доступ к общим данным на запись из разных
потоков (обратить внимание: в примере каждый
из потоков пишет в свою ячейку mins[number], а
не в одну глобальную переменную, что решает
это!)
●
Деление задач на подзадачи с
пересекающимися данными
●
Зависимость подзадач друг от друга
●
Ожидание потоков через Sleep
●
Запуск слишком большого числа потоков (много
больше числа физических ядер)

20. 20 / 102
Отладка многопоточных
приложений
●
Отладка затруднена, так как ОС каждый раз будет
запускать потоки по разному
●
Вывод на экран может изменить поведение
программы (так как меняет время работы потоков)
●
Для отладки поставить точку останова, в меню
отладка вызвать окно Потоки (threads), будет видно
в окне потоки и их стек вызовов для
каждого(последовательность вызова
функций/методов), можно остановить ненужные
потоки и пошагово смотреть поведение своего.

21. 21 / 102
Тема 2. Моделирование
распределенных систем
●
Проектирование особенно необходимо для
программ, работающих параллельно или
распределенно, поскольку человеческий мозг в
каждый момент времени решает только одну
задачу и не может сразу правильно
спроектировать и реализовать рабочую систему
с взаимодействующими частями.
●
Различные виды диаграмм применяются, чтобы
не упустить всех моментов в системе

22. 22 / 102
Диаграммы
●
Структурные схемы параллельных процессов
(идея взята из языка Ada)
●
UML диаграммы (стандарт для моделирования
разных аспектов системы)
●
Схемы бизнес-процессов, BPMN (набирает
популярность)
●
Различные прототипизаторы пользовательского
интерфейса

23. 23 / 102
Структурная схема процессов
●
Процесс имеет пронумерованные относительно
только его входы и выходы
●
Процесс ничего не знает о всей системе
●
Он только может ждать, обрабатывать и
передавать данные (активируя при этом один из
входов-выходов)
●
Возможны ожидания типа “и” или “или” от
нескольких процессов
●
Возможны условные и переходы тайм-аутом

24. 24 / 102
Структурная схема

25. 25 / 102
Резюме по структурной схеме
●
Отметим, что структурная схема показывает
работу всей системы в целом, включая все
возможные условия.
●
Она удобна на первоначальном этапе
проектирования несложных взаимодействующих
систем с 5-10 объектами при небольшом
количестве взаимодействий.
●
По ней можно рисовать другие схемы и
писать/генерировать программы

26. 26 / 102
UML
●
Unified Modeling Language (унифицированный
язык моделирования)
●
Это графический язык
●
Текущая версия 2.0 (В полной мере
поддерживается средством Visual Paradigm)
●
Содержит 2 типа диаграмм – статические и
динамические

27. 27 / 102
Статические диаграмы UML
●
Статические UML диаграммы описывают архитектурно
разрабатываемую систему. Это прежде всего:
●
UML диаграмма классов (class diagram), показывающая
взаимосвязи между классами в системе;
●
диаграмма вариантов использования (use case diagram),
показывающая режимы работы с точки зрения пользователей;
●
диаграмма компонентов (component diagram), показывающая
основные связи между компонентами системы;
●
диаграмма развертывания (deployment diagram), показывающая
связи в распределенной системе включая протоколы и порты.

28. 28 / 102
Динамические UML диаграммы
●
Динамические UML диаграммы моделируют поведение компонентов
системы или всей системы в целом. Следует отметить, что такие
диаграммы могут быть построены автоматизированными средствами по
работающей системе.
●
Диаграмма состояний (state machine diagram) моделирует работу для
каждого компонента системы (либо процесса);
●
диаграмма последовательностей (sequence diagram) или линий жизни
показывает один из вариантов работы компонентов в течении времени
плюс взаимодействие между ними при помощи сообщений;
●
диаграмма коопераций, коммуникаций (communication diagram) – вариант
диаграммы последовательностей, но не во времени, а с использованием
нумерации для взаимодействий;
●
диаграмма активностей (activity diagram), или “плавательные дорожки”
показывает работу многопоточной или распределенной системы, когда на
каждой дорожке строится диаграмма состояний для каждого процесса или
компонента, а связи между дорожками моделируют взаимодействия.

29. 29 / 102
Use case
●
Данная диаграмма предназначена для утверждения
заказчиком первоначальных требований к системе, таких
как содержание окон, меню, режимы работы программы,
взаимодействующие компоненты распределенной
системы.
●
Диаграмма состоит из акторов, вариантов
использования, точек расширения, ассоциаций,
пояснений.
●
Содержит все функции, показывает, как они связаны.
Следовательно, может быть использована для оценки
трудоемкости

30. 30 / 102
Use Case
●
Процесс это актор
●
Все действия в диаграмме для
взаимодействующих процессов – парные!

31. 31 / 102
Use Case
●
Точки расширения группируют логически
однородные действия (в точке расширения –
общий ключ, к нему ведут конкретные
частности). Моделирует ожидание от нескольких
процессов типа “и” или “или”

32. 32 / 102
Communication
●
UML диаграмма коопераций (или коммуникаций,
communication diagram) показывает один из
вариантов работы системы.
●
Диаграмма коопераций показывает вариант
развития событий согласно одному из путей,
когда срабатывает одно из условий. Для другого
варианта следует рисовать уже другую
диаграмму коммуникаций.

33. 33 / 102
Communication

34. 34 / 102
Sequence/time-line
●
Линия жизни моделирует объект (процесс) в его
динамике взаимодействия с другими объектами.Линия
жизни включает в себя промежутки активности и
неактивности объекта, они обозначаются отрезками
прямой линии.
●
Сообщение показывает взаимодействие между двумя
объектами. Сообщения упорядочены по удалению от
начала линии жизни объекта (больше удаление – позже
сообщение), если время идет снизу вверх, то чем ниже
сообщение, тем оно передано позднее (если время идет
слева направо, то чем правее сообщение, тем оно
передано позднее).

35. 35 / 102
Sequence

36. 36 / 102
State machine
●
Диаграмма состояний (state machine diagram)
предназначена для моделирования каждого
компонента системы на самом низком уровне,
на уровне алгоритма работы. Такой
диаграммной моделируются пошаговые
алгоритмы и протоколы. Диаграмма состояний
рисуется своя для каждого объекта (процесса).
Возможно совместить все диаграммы на одной,
при этом требуется указать при помощи UML
комментария, какой из объектов моделируется.

37. 37 / 102
State machine
●
Для перевода структурных схем в диаграммы
состояний следует придерживаться следующего
подхода: для всех входов и выходов каждого
объекта в соответствии с их порядком отметим
состояния либо как ”ожидание” от объекта,
который обращается к нашему объекту (для
входа) или как “оповещение” или “передача” к
объекту, к которому обращается наш объект.

38. 38 / 102
State machine

39. 39 / 102
Моделирование параллельных программ с
помощью State machine
●
Создание потоков (Fork)
●
Работа потока (Последовательность состояний)
●
Ожидание завершения потоков, барьер (Join)

40. 40 / 102
Activity
●
Диаграмма деятельности (activity) позволяет
промоделировать всю логику работы системы, включая
взаимодействия.
●
Для этого рабочая область диаграммы, как чаша
бассейна, разбивается на части по количеству объектов
(процессов) в системе. Каждая часть называется
“плавательной дорожкой”.
●
В каждой такой дорожке рисуется диаграмма состояний
(как описано в предыдущем пункте) для
соответствующего объекта. Соответствующие состояния
разных компонентов соединяются между дорожками.

41. 41 / 102
Activity
●
Было (состояния объекта на дорожках)

42. 42 / 102
Activity
●
Стало (добавлена синхронизация)

43. 43 / 102
Объекты синхронизации
●
Семафор применяется, когда один объект ждет другого и
продолжает действия после ожидания. Например, Менеджер
ждет запроса от Клиента. Семафор моделируется двумя
операциями, как это введено Дейкстрой, автором семафора –
P (ждать взаимодействия) и V (осуществить взаимодействие).
●
Канал применяется, когда один объект ждет какие-то данные
от другого. Канал гарантирует, что переданные в него данные
не будут затерты новыми до завершения их передачи (на
стороне отправителя он блокируется после передачи и
разблокируется после приема получателем). Получатель
также блокируется на операции ожидания данных. Канал
моделируется двумя операциями – Put (отправить, положить
данные в канал) и Get (ожидать, взять данные из канала).

44. 44 / 102
BPMN
●
Это расширение диаграммы Activity, которая
представляет систему в более расширенном
виде бизнес-процесса, ориентированного на
сообщения между компонентами системы.

45. 45 / 102
Тема 3. Проблемы синхронизации в
параллельных и распределенных
системах
●
Распределенные системы слабосвязаны и
нуждаютя в синхронизации
●
Проблемы возникают из-за
недетерминированности (случайного характера)
работы параллельных процессов, которые
обращаются к общим ресурсам
●
Возможны потери данных и зависания

46. 46 / 102
Основные проблемы
●
Data race, гонка данных (неопределённость
общих данных параллелизма).
●
Deadlock, дедлок (взаимная блокировка)
●
Производные: starvation(голодание), livelock

47. 47 / 102
Гонка данных
●
Пример: один поток увеличивает переменную,
другой ее уменьшает. Результат непредсказуем.
●
Другой пример: потоки ищут минимум в своей
части и сразу меняют общий минимум. Результат
разный.
●
Два пользователя одновременно бронируют
билет на тоже место. Кто же получит место?

48. 48 / 102
Гонка данных - природа
●
Поскольку операция не представляет собой
полноценную транкзакцию (пример – sum++ =>
sum= sum+1, это три операции: чтение,
суммирование, запись), то при параллельной
работе в любой момет другой процесс может
параллельно изменить данные, а наш процесс
об этом не будет знать и будет думать, что
обрабатывает еще старые данные

49. 49 / 102
Гонка данных - решение
●
Разделение по данным – каждый поток/процесс
работает со своими данными (если задача
позволяет), делает локальное решение, а потом
все эти решения редуцируются
●
Защита данных путем блокировки
●
Неблокирующие алгоритмы – запиши и проверь
●
Атомарные структуры данных

50. 50 / 102
Взаимная блокировка
●
Возникает, когда объект A
ожидает объект B, который
ожидает объект А.
●
Блокировку можно обнаружить, как цикл в графе
ожидания ресурсов объектами
●
Решение – управление доступом к ресурсам

51. 51 / 102
Проблема обедающих
философов

52. 52 / 102
Решение
●
Добавления официанта возле стола (процесса-
менеджера ресурсов).
●
Философы должны дожидаться разрешения
официанта перед тем, как взять вилку.
●
Поскольку официант знает, сколько вилок
используется в данный момент, он может
принимать решения относительно
распределения вилок и тем самым
предотвратить взаимную блокировку
философов.

53. 53 / 102
Необходимость синхронизации
●
Таким образом, часто системе требуется
дополнительный объект, с помощью которого
процессы будут работать корректно
●
Ученый Дейкстра предложил использовать
“семафор”.

54. 54 / 102
Семафор
●
Это общий объект для параллельных
процессов, который имеет внутреннее
состояние (открыт/закрыт) и две операции:
●
P() - Если семафор закрыт, зависнуть и ждать,
пока его не откроют, иначе закрыть его
●
V() - открыть, дать сигнал зависшему на
семфоре процессу продолжать работу

55. 55 / 102
Семафор
●
В общем виде, семафор может иметь N состояний и
ожидать до N процессов.
●
Семафор с открыт/закрыт также называется
мьютексом
●
Семафор является объектом ядра ОС, то есть
работа с ним производится на уровне системного
кода
●
Процессы, которые висят на семафорах, не
добавлются в планирщик процессов, что экономит
процессорное время (все-равно ОС знает, когда
семфор освободиться, тогда и данные процессы
получат свое время)

56. 56 / 102
Использование в коде на C#
← V()
← P()

57. 57 / 102
Применение семафора
●
Для ожидания объектами друг друга
один ждет (вызывает sem.P()), другой приходит
(вызывает V())
●
Для блокировки общих данных – при использовании
данного кода только один процесс будет менять
переменную, другие будут ждать в это время:
sem.p();
data++;
sem.v();

58. 58 / 102
Семафоры и каналы –
реализуем взаимодействия

59. 59 / 102
Семафоры и каналы –
реализуем взаимодействия
Каналы – по схеме Activity
Код полностью по схеме
(печать и синхронизация)
И так все объекты, каждый в своем потоке

60. 60 / 102
Тема 4. Распределенные
микросервисы
●
Сервисо-ориентированная архитектура – это
методология использования услуг, которые выполняются
удаленными организациями
●
То есть, компании предоставляют сервисы другим
компаниям во всех аспектах деятельности
●
Аутсорс или фриланс – это частные случаи

61. 61 / 102
Все есть сервис

62. 62 / 102
Сервис
●
Сервис с точки зрения программирования – это
набор удаленных процедур + описания модели
данных
●
Удаленная процедура (RPC) позволяет вызвать
какую-то функцию, которая будет работать на
удаленном узле, а мы получим ее результат у
себя

63. 63 / 102
Сервис. Интерфейсы
●
Сервис имеет программные интерфейсы (список
функций, параметров), которые видны наружу и по
ним клиент сервиса может сгенерировать классы
для работы с этим сервисом
●
Код для доступа к сервису можно написать
практически на любом языке

64. 64 / 102
Микросервисы. АОП
●
АОП (агентно-ориентированное программирование)
преполагает реализацию программ в виде
взаимодействующих через сообщения агентов,
которые никак не связану, кроме как через
сообщения
●
Микросервисы – новый подход, когда программа
практически ничего не делает сама по себе, для
всех действий вызывает функции с сервисов, те в
свою очередь с других сервисов и т.д. Код сервиса и
его ответственность минимальны.

65. 65 / 102
Микросервисы
●
Соответственно, наши спроектированные
системы являются микросервисами: все
действия выполняются по цепочке разными
сервисами.

66. 66 / 102
Сервисы Госуслуг
●
Портал госуслуг программно реализован как
набор взаимодействующих сервисов + средства
представления данных на сайте

67. 67 / 102
WCF
●
WCF = Windows Communication Foundation,
средство для создания своих сервисов и доступа
к ним из C#.
●
С WCF создать сервис просто – делаем класс,
добавляем методы, добавляем специальные
аннотации на класс и методы (и данные)
●
Вызвать сервис тоже просто – делаем ссылку на
сервис, получаем прокси класс, работаем с ним
как с обычным классом (но вызовы будут
проходить удаленно)

68. 68 / 102
Создание сервиса
●
Написание интерфейса
●
Реализация интерфейса
●
Написание Main для запуска сервиса

69. 69 / 102
Интерфейс сервиса
●
Согласно разработанной структурной схеме
определяем методы, которые являются
входными стрелками для данного объекта:
сервис их предоставляет другим

70. 70 / 102
Реализация сервиса
●
Пишем ее позднее, поскольку остальные
сервисы еще не готовы, а нам нужно вызывать
их методы.
●
В реализации сервиса будет так – согласно
схеме получаем от предыдущего сервиса
данные, и вызываем другой сервис для их
обработке согласно структурной схеме
●
Для начала нужны заглушки

71. 71 / 102
Реализация Main для сервиса

72. 72 / 102
Вызов сервиса
●
Для начала нужно запустить сервис и создать
ссылку на него в другом проекте (в меню
проектва есть пункт ссылка на сервис)

73. 73 / 102
Вызов сервиса
●
После того, как создан прокси-класс для
сервиса, его можно инстансцировать и вызывать
методы (удаленные процедуры):

74. 74 / 102
Реализация распределенной
системы на сервисах
●
Согласно схеме, для каждого объекта ссылки на
другие сервисы и интерфейс, который он
предоставляет другим
●
Вызов удаленных процедур(методов) с других
сервисов по цепочке
●
Логика (ожидание двух, условия)
●
Синхронизация (голодный человек перед тем,
как сделать другой заказ, висит на семафоре,
пока не принесут готовый предыдущий)

75. 75 / 102
Распределенные системы и
ERP системы
●
Так как доступ к сервисам стандартизирован, их можно вызывать из
разных языков примерно одинаково
●
В том числе и можно создать клиент к нашей распределенной
системе на 1с (голодный человек это форма с таблицей)
●
Так можно производить выгрузку и загрузку данных с разных систем

76. 76 / 102
Распределенные системы и
ERP системы
●
Делаем обработчик ожидания (по сути отдельный поток)
●
Обращаемся к Менеджеру (вызываем GetClient())
●
Нужна модификация Менеджера, чтобы клиент мог проверять и
забирать результат, если не готов – возвращаем пустой
●
В цикле проверяем результат, пока он пустой.

77. 77 / 102
Тема 5. Распределенные
алгоритмы (кратко)
●
Распределенный алгоритм решает вопросы
корректной синхронизации распределенных
узлов
●
Алгоритм должен работать корректно, если узлы
отсоединяются, шлют некорректные сообщения
и т.д.
●
Все протоколы сети Интернет – это
распределенные алгоритмы (пример:
рукопожатие TCP/IP, множественный доступ к
WIFI)

78. 78 / 102
Распределенные алгоритмы
●
Обычно моделирются в виде диаграмм линий
жизни
●
Современные уязвимости компьютерной
безопастности – это часто атаки на реализации
распределенных алгоритмов
●
Примеры: синхронизация часов в сети; алгоритм
выбора лидера с голосованием; алгоритм Raft
для репликации и тд

79. 79 / 102
Децентрализованные
алгоритмы и системы
●
Децентрализованные системы отличаются отсутствием
единого центра. Пример – Интернет
●
Децентрализованные системы хранят данные на
клиентах и обмениваются ими между собой. Клиент
может быть и клиентом и сервером одновременно и
брать на себя ответственность за сеть и реплицировать
(согласовывать) данные при потере/появлении
соединения
●
Могут храниться порции данных.
●
Примеры – BitTorrent
●
Блокчейн решения – это децентрализованные системы

80. 80 / 102
Тема 6. Распределенные БД
(кратко)
●
Клиент серверные Базы Данных (с
использованием SQL) изначально представляют
собой распределенную арзитектуру
●
Однако, требуется осуществить надежность
доступа и резервирование данных
●
Вывод: в промышленных прорамнных системах
используются кластера для серверов баз
данных.

81. 81 / 102
Кластер
●
Кластер представляет несколько серверов баз
данных, которые связаны между собой и
переодически синзронизируются. Отказ в
обслуживании одного из узлов кластера не
приводит к неработоспособности всей базы

82. 82 / 102
MS SQL Server
●
При установке SQL Server можно выбрать,
установить новый экземпляр или добавить
сервер в кластер
●
Кластер должен работать на MS Windows Server
и там должны быть настроены средства
репикации
●
Для пользователя использование кластера
прозрачно – мы соединяемся к master узлу, а он
далее прокидывает соединение до одного из
worker узлов

83. 83 / 102
Будущее БД
●
Постепенный отказ от SQL баз. Все больше
проектов используют документо-
ориентированные базы (например MongoDB),
так называемые Key-Value хранилища, пример:
customers[id].Card
●
Внедрение распределенных хранилищ, которые
работают полностью в памяти. Отключение
узлов проблем не составит, ведь данные
синхронизируются. Доступ намного быстрее.
Пример: GridGain (Сбербанк)

84. 84 / 102
Тема 7. Распределенные
системы контроля версий
●
Контроль версий – средство хранения всех
версий файла, также это отслеживание
изменений, откат к нужной версии,
множественный доступ к файлам пользователей
●
Во всех современных компаниях проектом
занимается много людей и он располагается на
общем (открытом, закрытом) репозитории

85. 85 / 102
GIT
●
Git создан Линусом Товальдсом (автором Linix)
●
Для работы с контролем версий распределенно
●
Каждый пользователь хранит свой локальный
репозиторий, он делает фиксацию изменений
(коммит). В любое время он может
синхронизироваться с репозиторием на сервере

86. 86 / 102
●
ГитХаб – это социальная сеть, хостинг для
проектов (бесплатный для открытых)
●
На GitHub можно заливать файлы через
синхронизацию с Git
●
Можно оставлять комменты к коду, смотреть
изменения, писать записи о багах и многое
другое
●
Удобный клиент – GitHub Desktop

87. 87 / 102
GitHub - репозитории
●
Можно создать свой репозиторий или
форкнуть(fork-вилка) чужой (потом можно
предложить туда свои изменения)

88. 88 / 102
GitHub
●
Коммиты – это изменения. Разработчики делают
изменения и фиксируют логически цельное
изменение. Коммит сопровождается описанием.

89. 89 / 102
GitHub – изменения коммита
●
Для каждого коммита можно посмотреть, какие
файлы изменены и что именно было добавлено/
удалено:

90. 90 / 102
Git резюме
●
Таким образом, можно отслеживать всю
последовательность работы разработчика, его
эффективность, вклад, качество
●
Существуют системы для помощи менеджерам в
оценке разработчиков по коммитам
●
Когда код под версионным контролем, мы его не
потеряем и обеспечим совместную работу

91. 91 / 102
Тема 8. Блокчейны и
криптовалюты
●
Блокчейн (цепочка блоков) – это
последовательность подписанных блоков
●
Каждый блок это обычно транкзакция –
движение средств от отправителя получателю
●
Блоки хранятся распределенно у узлов сети
●
Используются распределенные алгоритмы
синхронизации и валидации

92. 92 / 102
Криптовалюты
●
Криптовалюта – это генерируемые некоторым
алгоритмом блоки о зачислении/списании
средств у пользователей.
●
Изначально был придуман Биткоин на основе
технологии Блокчейн
●
Далее пошли форки (копии с изменением) его
кода
●
Сейчас любой может создать свою валюту,
однако нужно ли это?

93. 93 / 102
Основа
●
Хеш функции (необратимые функции, которые
переводят любую последовательность байт в
последовательность заданной длины)
●
Задача о Византийских генералах (конценцус в
распределенной системе)

94. 94 / 102
Криптовалюты
●
В Америке все то, что имеет спрос, может быть продано
или куплено.
●
Очередной пузырь, на этот раз криптовалютный

95. 95 / 102
Защищенность криптовалют
●
Блоки в цепочки блокчейн подписаны, то есть
поменять блок без следов невозможно.
●
Блоки генерируются в некоторый момент
времени, туда попадают ожидающие
транкзакции и блок подписывается.
●
Майнеры с помощью вычисления хеш функций
подписывают блок.
●
Блоки содержат ссылки на предыдущие,
следовательно для вставки “левого” или
измененного блока придется пересчитать все
хеши, что очень долго

96. 96 / 102
Пример: валюта DogeCoin
●
Скачиваем клиент MultiDoge и создаем кошелек.

97. 97 / 102
Адрес кошелька
●
DAVBdYHzAX6LM511vCegVEsmevNiHeK3nn
например, это адрес кошелька.
●
Любой может скинуть сюда со своего какую-
нибудь сумму (Doge ничего не стоят, это
практически как выразить благодарность за
помощь, сделать лайк)
●
Для анонимности можно создать принимающий
адрес на каждый новый перевод – тогда
отправитель не сможет узнать транкзакции по
другим нашим адресам

98. 98 / 102
Blockchain explorer
●
Любой может увидеть транкзакции по данному
адресу

99. 99 / 102
Транкзакции в блоке

100. 100 / 102
Майнинг
●
Майдинг (mining, горное дело, термин был взят
из Англии) - “добыча” электронных денег
●
За подпись блока создатели валюты платят
криптоденьги
●
Их получает тот, кто первый подпишет блок
●
Соответственно, чем больше пользователей
пытаются заработать, тем меньше вероятность
получить прибыль

101. 101 / 102
Майнинг
●
Для получения суммы согласно вкладу
пользователи объединяются в пулы
●
Необходимо получать с сервера задачи и
вычислять хеш-функции
●
Необходимо использовать видеокарты (они
содержат большое число процессоров) или
специальные устройства (ASIC), зависит от
валюты

102. 102 / 102
Ethereum
●
Это криптовалюта и платформа для создания
своих сервисов
●
Вместо того, чтобы создавать свои валюты и
сервисы на основе их, можно использовать
Etherium
●
Он предоставляет “умные контракты”, на
которых можно реализовывать доверенные
распределенные приложения.