Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <ul><li><a>Proof of Work и Proof of Stake для чайников</a></li>

2 <li><a>4 вида распространённых ошибок в Event-Driven системах</a></li>

3 <li><a>Основные функции Apache Tomcat</a></li>

4 <li><a>Kubernetes на AWS: пошаговое руководство</a></li>

5 <li><a>Архитектурный паттерн для обработки больших данных: Kappa</a></li>

6 <li><a>Как управлять состоянием телеграм-бота</a></li>

7 <li><a>Паттерн Circuit Breaker</a></li>

8 <li><a>Проблемы согласованности данных в микросервисах и их решение</a></li>

9 <li><a>Паттерн Одиночка</a></li>

10 <li><a>На пути к четкой архитектуре: проблема избыточной функциональности</a></li>

11 <li><a>Коротко про платежи через ботов в Telegram</a></li>

12 <li><a>Проектирование fault-tolerant систем на Go</a></li>

13 <li><a>Обзор библиотеки bleve в Golang</a></li>

14 <li><a>Обзор библиотеки Go Kit</a></li>

15 <li><a>Зачем нужен архитектор 1С</a></li>

16 <li><a>Разбираемся с Cloud Landing Zone</a></li>

17 </ul><h2>Proof of Work и Proof of Stake для чайников</h2>

18 <p>На старте блокчейн-технологий стояла задача создания системы, которая могла бы функционировать надежно и без централизованного контроля. Здесь помогают консенсусные алгоритмы. Консенсус в блокчейне - это согласие всех участников сети относительно ее текущего состояния, т.е это механизм, который позволяет децентрализованным сетям достигать общего согласия о том, какие транзакции считаются действительными и добавляются в блокчейн.</p>

19 <p>Для достижения консенсуса в блокчейне существуют механизмы <em>Proof of Work</em> и Proof of Stake. Рассмотрим их в этой статье.</p>

20 <p><a>Читать далее</a></p>

21 <h2>4 вида распространённых ошибок в Event-Driven системах</h2>

22 <p>В последние несколько лет в крупных компаниях наблюдается значительный рост внедрения event-driven (событийно-ориентированных) систем. Каковы основные причины этой тенденции? Это чистой воды хайп или есть веские причины, побуждающие к внедрению этой архитектуры? С нашей точки зрения, основными причинами, по которым многие компании выбирают этот путь, являются:</p>

23 <ul><li>Слабая связанность между компонентами</li>

24 <li>Концепция “Fire and Forget”</li>

25 <li>Отсутствие зависимости во времени</li>

26 <li>Ряд бизнес-моделей очень легко вписывается в event-driven системы</li>

27 </ul><p><a>Читать далее</a></p>

28 <h2>Основные функции Apache Tomcat</h2>

29 <p>Apache Tomcat - это открытое программное обеспечение, реализующее спецификации <em>Java Servlet</em>, <em>JSP</em> и <em>Java WebSocket,</em> предоставляя таким образом платформу для запуска веб-приложений, написанных на языке Java. Разработанный и поддерживаемый Apache Software Foundation, Tomcat служит контейнером сервлетов, который позволяет веб-приложениям использовать Java для создания динамичных веб-страниц.</p>

30 <p>Tomcat может работать как самостоятельный веб-сервер, где он обрабатывает как статические страницы, так и динамические запросы через <em>Servlets</em> и <em>JSP</em>. Однако часто Tomcat используется в сочетании с традиционными веб-серверами, такими как Apache HTTP Server или Nginx, для обработки статического контента, в то время как динамический контент обрабатывается через Tomcat.</p>

31 <p>В этой статье мы рассмотрим основной функционал Tomcat.</p>

32 <p><a>Читать далее</a></p>

33 <h2>Kubernetes на AWS: пошаговое руководство</h2>

34 <p>В этой статье мы рассмотрим несколько распространенных способов создания кластера Kubernetes на AWS:</p>

35 <ul><li><strong>Создание кластера с помощью kops</strong>: kops - это инструмент, предназначенный для промышленной эксплуатации, используемый для установки, обновления и управления Kubernetes на AWS.</li>

36 <li><strong>Создание кластера с помощью Amazon Elastic Kubernetes Service (EKS)</strong>: EKS - это управляемый сервис Kubernetes, предоставляемый компанией Amazon. Кластер Kubernetes с EKS можно создать с помощью AWS Management Console.</li>

37 <li><strong>Создание кластера с помощью Rancher</strong>: Rancher - это платформа управления Kubernetes, которая упрощает развертывание Kubernetes и контейнеров.</li>

38 </ul><p><a>Читать далее</a></p>

39 <h2>Архитектурный паттерн для обработки больших данных: Kappa</h2>

40 <p>Когда речь идет о обработке больших данных, архитектурные паттерны играют самую важную роль. Ранее мы обсудили Lambda, который предлагает подход, сочетающий в себе потоковую и батч-обработку данных. Однако, Kappa предоставляет нам несколько другой взгляд на эту проблему. Он упрощает архитектуру, фокусируясь исключительно на потоковой обработке.</p>

41 <p><a>Читать далее</a></p>

42 <h2>Как управлять состоянием телеграм-бота</h2>

43 <p>Управление состоянием - это фундаментальный аспект создания телеграм-ботов, позволяющий нам эффективно управлять взаимодействием с пользователями и предоставлять более персонализированный опыт.</p>

44 <p>Управление состоянием - это концепция, которая делает весь процесс взаимодействия с пользователем систематическим и удобным. Без этого механизма, ваш бот будет действовать как человек, страдающий амнезией, забывая предыдущие действия пользователя и не способный предоставить согласованный опыт.</p>

45 <p><a>Читать далее</a></p>

46 <h2>Паттерн Circuit Breaker</h2>

47 <p>Каждая секунда простоя может стоить компании целое состояние, важно иметь надежные механизмы защиты от сбоев. Здесь и приходит на помощь паттерн Circuit Breaker.</p>

48 <p>Представьте себе обычный автоматический выключатель в вашем доме. Когда происходит перегрузка, он "выбивается", предотвращая возможные повреждения. Точно так же работает и Circuit Breaker в микросервисах. Он мониторит вызовы к внешнему сервису и при обнаружении слишком большого количества неудачных попыток временно "отключает" вызов, предотвращая тем самым падение всей системы.</p>

49 <p>Этот паттерн основывается на трех основных состояниях: <em>закрытое</em>, <em>открытое</em> и <em>полуоткрытое</em>.</p>

50 <p><a>Читать далее</a></p>

51 <h2>Проблемы согласованности данных в микросервисах и их решение</h2>

52 <p>Микросервисы стали выбором многих благодаря их гибкости, масштабируемости и способности поддерживать сложные приложения в динамично меняющемся мире.</p>

53 <p>Но не всё так просто. Одной из ключевых проблем, с которыми сталкиваются при переходе от монолитных архитектур к микросервисным, является обеспечение согласованности данных.</p>

54 <p>Каждый сервис работает автономно, управляя своим собственным набором данных. Как гарантировать, что данные, распределенные по разным сервисам, будут консистентными? Как избежать потери данных и обеспечить их актуальность в реальном времени?</p>

55 <p><a>Читать далее</a></p>

56 <h2>Паттерн Одиночка</h2>

57 <p>Паттерн "Одиночка" (Singleton) является одним из паттернов проектирования, который используется для создания класса, имеющего только один экземпляр в системе, и предоставляющего глобальную точку доступа к этому экземпляру. Это означает, что в рамках приложения может существовать только один объект данного класса, и любой запрос на создание нового экземпляра будет возвращать ссылку на существующий.</p>

58 <p>Паттерн обеспечивает механизм глобального доступа к единственному экземпляру класса, что упрощает взаимодействие с этим объектом из любой части приложения.</p>

59 <p>Паттерн может быть реализован разными способами, включая ленивую инициализацию (создание экземпляра при первом запросе), мгновенную инициализацию (создание экземпляра при загрузке класса), и использование синхронизации для обеспечения потокобезопасности.</p>

60 <p><a>Читать далее</a></p>

61 <h2>На пути к четкой архитектуре: проблема избыточной функциональности</h2>

62 <p>Несколько лет назад, будучи еще новичком, я столкнулся с задачей, которая казалась на первый взгляд простой, но оказалась настоящим ужасом. Мое слепое стремление добавить как можно больше функций привело к тому, что интерфейс стал чрезмерно перегруженным и сложным для пользователя.</p>

63 <p>Мы в небольшой команде разрабатывали модуль отчетности, который должен был предоставлять пользователю возможности для анализа данных проекта. Мы решили интегрировать множество функций: от базового отображения статистики до сложных инструментов предиктивного анализа. В результате пользовательский интерфейс превратился в лабиринт из кнопок, меню и форм, мало того, что это не просто лабиринт, а лабиринт с минотавром, ведь после некоторой комбинации кнопок юзеры получали неизвестную нам ошибку.</p>

64 <p><a>Читать далее</a></p>

65 <h2>Коротко про платежи через ботов в Telegram</h2>

66 <p>Больше не нужно переключаться между различными приложениями или веб-сайтами, чтобы совершить покупку. Теперь всё это возможно прямо в телеге, платформе, которая уже является частью повседневной жизни миллионов людей.</p>

67 <p>Платежи через ботов позволяют пользователям совершать покупки напрямую в интерфейсе чата. А непосредственно разработчикам, можно интегрировать функции электронной коммерции в бота, позволяя пользователям покупать товары или услуги без выхода из телеги.</p>

68 <p>Платежи обрабатываются через проверенных и надежных платежных провайдеров, что обеспечивает безопасность транзакций. Пользователям не нужно беспокоиться о сохранности своих финансовых данных, так как Telegram не хранит информацию о картах. Всё, что им нужно - это выбрать товар, нажать на кнопку покупки, и они будут направлены на безопасную страницу платежной системы для завершения транзакции.</p>

69 <p><a>Читать далее</a></p>

70 <h2>Проектирование fault-tolerant систем на Go</h2>

71 <p>Fault-tolerant системы - это те, которые способны продолжать функционировать даже в условиях частичных сбоев или неисправностей. Основная фича таких систем заключается в том, чтобы обеспечить непрерывность работы приложения и безопасность данных даже при возникновении ошибок или непредвиденных ситуаций. Это достигается за счет ряда архитектурных и программных решений, направленных на предотвращение полного отказа системы при возникновении отдельных сбоев.</p>

72 <p>Go благодаря своей простоте, производительности и, что наиболее важно, поддержке конкурентности на уровне языка, становится идеальным выбором для создания fault-tolerant систем.</p>

73 <p><a>Читать далее</a></p>

74 <h2>Обзор библиотеки bleve в Golang</h2>

75 <p>Bleve предоставляет индексации любых структур данных Go, он поддерживает различные типы полей: <em>текст</em>, <em>числа</em>, <em>даты</em> и <em>логические</em> <em>значения</em>, а также разнообразие запросов: от простых терминов до фраз и сложных булевых запросов.</p>

76 <p>Чтобы начать работу с Bleve, нужно установить саму библиотеку в рабочее пространство Go. Процесс установки выполняется с помощью команды go get:</p>

77 go get -u github.com/blevesearch/bleve<p><a>Читать далее</a></p>

78 <h2>Обзор библиотеки Go Kit</h2>

79 <p>Go Kit предоставляет стандартизированный способ создания сервисов, с ее помощью можно легко реализовать совместимость сервисов. С его помощью можно легко интегрировать различные транспортные протоколы, такие как HTTP, RPC, gRPC, и многое другое, а также реализовывать общие паттерны: логирование, метрики, трассировка. В общем, Go Kit хорошо подходит для разработки микросервисов на go.</p>

80 <p><a>Читать далее</a></p>

81 <h2>Зачем нужен архитектор 1С</h2>

82 <p>Есть такие, кто считает, что нет оснований для использования отдельного понятия архитектор 1С. Дескать, архитекторы это, например, Растрелли или Гауди, а мы тут немного другим занимаемся. Разработка программного обеспечения и проектирование зданий может и являются родственниками, но уж очень дальними. И, в конце концов, есть уже один достаточно широко используемый термин: разработчик. Зачем плодить лишние сущности и ссылаться при этом на что-то постороннее? Некоторое время назад автор и сам был одним из тех, кто так считал. Но все-таки различать разработчиков ПО и архитекторов ПО имеет смысл. И я попробую раскрыть его.</p>

83 <p><a>Читать далее</a></p>

84 <h2>Разбираемся с Cloud Landing Zone</h2>

85 <p>Облачные сервисы в последние годы пользуются большой популярностью. Преимущества всем хорошо известны - это экономия на закупке и сопровождении оборудования, лицензиях, персонале и т.д. Если у нас разворачивается инфраструктура с нуля, то ситуация несколько проще. Мы можем сразу развернуть наши сервисы в облаках и дальше уже тестировать их работу. Конечно, здесь тоже можно столкнуться с различными трудностями, но по крайней мере при создании инфраструктуры с нуля нам не требуется выполнять миграцию.</p>

86 <p><a>Читать далее</a></p>