Техническая карта back-end архитектора

Java задняя часть Архитектура Go PHP

知识共享协议（CC协议） GitHub stars GitHub forks GitHub watchers

Последнее обновление 20180502

(Toc созданsimple-php-github-toc)

структура данных

очередь

собирать

связанный список, массив

Словарь, ассоциативный массив

куча

Дерево

бинарное дерево

Каждый узел имеет не более двух листовых узлов.

полное бинарное дерево

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

Сбалансированное бинарное дерево

Абсолютное значение разницы высот между левым и правым поддеревьями не превышает 1, а левое и правое поддеревья оба являются сбалансированным бинарным деревом.

Двоичное дерево поиска (BST)

Двоичное дерево поиска, также известное как упорядоченное двоичное дерево, отсортированное двоичное дерево.

красно-черное дерево

B-, B+, B* дерево

MySQL основан на таблице организации кластеризованного индекса дерева B+.

LSM-дерево

По сравнению с деревом B+, LSM (логарифмически структурированные деревья слияния) жертвует частью производительности чтения в обмен на производительность записи (посредством пакетной записи) для достижения промежуточного результата между чтением и записью. Hbase, LevelDB, Tair (Long DB) и nessDB используют древовидную структуру LSM. LSM может быстро создавать индексы.

  • «LSM-дерево VS B+ дерево»

    • Дерево B+ имеет хорошую производительность чтения, но из-за необходимости упорядоченной структуры, когда ключи разбросаны, поиск по диску происходит часто, что приводит к производительности записи.
    • LSM состоит в том, чтобы разбить большое дерево на N маленьких деревьев, сначала записать в память (нет проблем с поиском, высокая производительность) и построить в памяти упорядоченное маленькое дерево (упорядоченное дерево).Чем больше размер, тем меньше будет дерево памяти. сброшен на диск. При чтении, поскольку вы не знаете, в каком маленьком дереве находятся данные, вы должны пройти (бинарный поиск) все маленькие деревья, но данные упорядочены внутри каждого маленького дерева.

  • "Механизм хранения LSM-дерева (Log-Structured Merge Tree)"

    • В экстремальных условиях производительность записи HBase на основе LSM-дерева на порядок выше, чем у MySQL, а производительность чтения на порядок ниже.
    • Метод оптимизации: фильтр Блума заменяет бинарный поиск; компактное дерево десятичных разрядов для повышения производительности запросов.
    • В Hbase после того, как память достигает определенного порога, все сбрасывается на диск для формирования файла (номер B+).HDFS не поддерживает операцию обновления, поэтому Hbase выполняет общий сброс вместо обновления слиянием. Маленькие деревья, сброшенные на диск, периодически сливаются в большое дерево.

BitSet

Часто используется для проверки дедупликации крупномасштабных данных.

Общие алгоритмы

Алгоритм сортировки, поиска

сортировка выбором

Пузырьковая сортировка

Сортировка вставками

быстрая сортировка

Сортировка слиянием

Сортировка холмов

TODO

сортировка кучей

  • «Графический алгоритм сортировки (3) сортировка кучей»
    • Процесс сортировки — это процесс построения наибольшей кучи, самой большой кучи: значение каждого узла больше или равно значению его левого и правого дочерних узлов, а верхний элемент кучи является наибольшим значением.

сортировка по подсчету

сортировка ведра

сортировка по основанию

Расположите в порядке единиц, десятков, сотен и так далее.

бинарный поиск

Инструмент сортировки в Java

Фильтр Блума

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

сравнение строк

Алгоритм КМП

KMP: Алгоритм Кнута-Морриса-Пратта (сокращенно KMP) Основной принцип заключается в использовании «таблицы частичного соответствия» для пропуска элементов, которые уже были сопоставлены.

Сначала в глубину, сначала в ширину

как дела

алгоритм поиска с возвратом

Алгоритм обрезки

динамическое программирование

Наивный Байес

Алгоритм рекомендаций

Алгоритм минимального связующего дерева

алгоритм кратчайшего пути

параллелизм

Многопоточность

потокобезопасность

согласованность, транзакция

Свойства ACID транзакции

уровень изоляции транзакций

  • Незафиксированное чтение: транзакция может прочитать другие незафиксированные данные, которые подвержены грязному чтению.

  • Фиксация чтения: одна транзакция ожидает фиксации другой транзакции, прежде чем она сможет прочитать данные, но будут неповторяющиеся операции чтения (несоответствующие данные, считанные несколько раз), и в процессе чтения будет много операций UPDATE. (Уровень по умолчанию для большинства баз данных — RC, таких как SQL Server, Oracle), который нельзя изменить при чтении.

  • Повторяемое чтение: в одной и той же транзакции гарантирует получение одних и тех же данных при каждом чтении, но не гарантирует, что исходные данные будут обновлены другими транзакциями (фантомное чтение).Mysql InnoDB — это уровень.

  • Сериализация: все обрабатывается последовательно (в ущерб эффективности)

  • «Понимание 4 уровней изоляции транзакций»

  • Четыре характеристики транзакций базы данных и уровни изоляции транзакций

  • «Проблема фантомного чтения MySQL InnoDB»

    • Пример фантомного чтения очень нагляден.
    • Решено с помощью ВЫБЕРИТЕ... ДЛЯ ОБНОВЛЕНИЯ.

  • «Статья поможет вам понять MySQL и InnoDB»

    • Проиллюстрированы грязные чтения, неповторяемые чтения и фантомные чтения.

MVCC

  • "[mysql] Некоторое понимание MVCC в innodb"

    • MVCC используется на уровне изоляции Repeatable-Read в innodb.
    • MVCC может вызвать проблемы с фантомным чтением (исключение при обновлении).

  • «Легкое понимание механизма реализации MYSQL MVCC»

    • Управление MVCC реализовано путем скрытия столбца версии, в одном столбце записывается время создания, в другом столбце записывается время удаления, здесь время
    • Работайте только со строками, которые меньше (или равны) текущей версии за раз.

Замок

Блокировки и классы синхронизации в Java

Справедливая блокировка и нечестная блокировка

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

пессимистический замок

Если пессимистическая блокировка используется неправильно (слишком много блокировок), это приведет к тому, что служба будет ждать в большой области. Рекомендуется использовать оптимистическую блокировку + сначала повторить попытку.

Оптимистичная блокировка и CAS

АВА-проблема

Из-за высокого параллелизма в CAS этот A может не совпадать с другим A после обновления. Это можно решить по номеру версии, подобно оптимистической блокировке, упомянутой выше в Mysql.

Контейнер CopyOnWrite

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

RingBuffer

Блокировки с повторным входом и блокировки без повторного входа

  • "Реентерабельные и нереентерабельные блокировки"

    • Проиллюстрируйте повторные и неповторные блокировки на простых примерах кода.
    • Повторно входящая блокировка означает, что тот же поток может снова получить ранее полученную блокировку.
    • Повторно входящие блокировки позволяют пользователям избегать взаимоблокировок.
    • Реентерабельные блокировки в Java: синхронизированные и java.util.concurrent.locks.ReentrantLock

  • Резюме «Реентерабельная блокировка ReenTrantLock (отличие от синхронизированной)»

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

Мьютекс и общий замок

Мьютекс: только один поток может одновременно получить блокировку. Например, ReentrantLock — это мьютекс, а блокировка записи в ReadWriteLock — это мьютекс. Общая блокировка: Блокировка, которая может иметь несколько потоков одновременно или. Например, Semaphore и CountDownLatch являются общими блокировками, а блокировки чтения в ReadWriteLock — общими блокировками.

тупик

Операционная система

компьютерные принципы

CPU

многоуровневый кэш

Типичный ЦП имеет кэш-память L3, и чем ближе он к ядру, тем он быстрее и тем меньше места. L1 обычно составляет 32 КБ, L2 обычно составляет 256 КБ, а L3 обычно составляет 12 МБ. Требуется 200 тактов ЦП для скорости памяти и 1 цикл ЦП для кэша ЦП.

процесс

TODO

нить

сопрограмма

  • «Завершение сопрограмм python — реализация от yield до модели актора»
    • За планирование потоков отвечает операционная система, а за планирование сопрограмм отвечает сама программа.
    • По сравнению с потоками сопрограммы уменьшают ненужное переключение ОС.
    • На самом деле более целесообразно переключаться при обнаружении операции ввода-вывода (поскольку операция ввода-вывода не занимает ЦП), если операция ввода-вывода не обнаружена, переключаться в соответствии с интервалом времени.

Linux

Шаблоны проектирования

Шесть принципов шаблонов проектирования

  • Шесть принципов шаблонов проектирования
    • Принцип открытости-закрытости: открыт для расширения, закрыт для модификации и использует абстрактные классы и интерфейсы.
    • Принцип замещения Лискова: базовые классы могут быть заменены подклассами, используя наследование абстрактного класса вместо наследования конкретного класса.
    • Принцип инверсии зависимостей: полагайтесь на абстракцию, а не на конкретность, программа для интерфейса, а не для реализации.
    • Принцип изоляции интерфейса: лучше использовать несколько изолированных интерфейсов, чем использовать один интерфейс и установить наименьший интерфейс.
    • Закон Деметры: Программная сущность должна как можно меньше взаимодействовать с другими сущностями, устанавливая связи через промежуточные классы.
    • Принцип повторного использования композиции: попробуйте использовать композицию/агрегацию вместо наследования.

23 распространенных шаблона проектирования

Сценарии применения

  • «Подсчет шаблонов проектирования в JDK»

    • Структурные модели:

      • Адаптер: используется для преобразования одного интерфейса в другой, например java.util.Arrays#asList().
      • Режим моста: этот режим разделяет абстракцию и реализацию абстрактной операции, так что абстракцию и реализацию можно изменять независимо друг от друга, например JDBC;
      • Режим композиции: один объект и композиция объектов кажутся клиенту эквивалентными. Другими словами, метод определенного типа также принимает в качестве параметра собственный тип, например Map.putAll, List.addAll, Set.addAll.
      • Шаблон декоратора: динамическое добавление дополнительных функций к объекту, что также является альтернативой созданию подклассов, например java.util.Collections#checkedList|Map|Set|SortedSet|SortedMap.
      • Шаблон легковеса: используйте кеш, чтобы ускорить время доступа к большому количеству небольших объектов, таких как valueOf(int).
      • Режим прокси: режим прокси заключается в замене сложного или трудоемкого объекта простым объектом, например java.lang.reflect.Proxy.

    • Режим создания:

      • Шаблон абстрактной фабрики. Шаблон абстрактной фабрики предоставляет протокол для создания ряда связанных или независимых объектов без указания типа конкретных объектов, например java.util.Calendar#getInstance().
      • Режим построения (Builder): Определен новый класс для создания экземпляра другого класса, чтобы упростить создание сложных объектов, таких как: java.lang.StringBuilder#append().
      • Заводской метод: простовозвращение* Методы, возвращающие определенные объекты, а не несколько, например java.lang.Object#toString(), java.lang.Class#newInstance().
      • Шаблон прототипа: позволяет экземплярам классов создавать копии самих себя, например: java.lang.Object#clone().
      • Режим Singleton: в глобальном масштабе существует только один экземпляр, например java.lang.Runtime#getRuntime().

    • модель поведения:

      • Шаблон цепочки ответственности: разделяйте объекты, передавая запросы от одного объекта к следующему объекту в цепочке, пока запрос не будет обработан. Например, javax.servlet.Filter#doFilter().
      • Командный режим: инкапсулируйте операции в объекты для хранения, доставки и возврата, например: java.lang.Runnable.
      • Режим интерпретатора: определяет грамматику языка, а затем анализирует операторы соответствующей грамматики, такие как java.text.Format, java.text.Normalizer.
      • Шаблон итератора: обеспечивает согласованный способ последовательного доступа к объектам в коллекции, например java.util.Iterator.
      • Шаблон посредника: использование промежуточного объекта для распространения сообщений и уменьшения прямых зависимостей между классами, java.lang.reflect.Method#invoke().
      • Режим пустого объекта: например, java.util.Collections#emptyList().
      • Шаблон наблюдателя: он позволяет объекту гибко отправлять сообщения заинтересованным объектам, таким как java.util.EventListener.
      • Шаблон метода шаблона: позволяет подклассам переопределять часть метода вместо всего метода, например java.util.Collections#sort().

  • «Весеннее резюме задействованных шаблонов проектирования»

  • «Шаблоны проектирования, используемые Mybatis»

одноэлементный шаблон

Модель цепочки ответственности

TODO

MVC

IOC

  • «Понимание МОК»
  • Понимание и интерпретация МОК
    • Форвардное управление: Традиционный способ прохождения нового. Реверсивный контроль, ввод объектов через контейнер.
    • Роль: используется для развязки модуля.
    • DI: Dependency Injection, то есть внедрение зависимостей, заботится только об использовании ресурсов, а не об их источнике.

AOP

UML

Микросервисное мышление

Закон Конвея

  • «Теоретические основы микросервисной архитектуры — закон Конвея»

    • Закон 1. Способ организационной коммуникации будет выражаться в системном дизайне, то есть схема архитектуры будет аналогична организационной структуре.
    • Закон 2: Сколько бы ни было времени, невозможно сделать что-то одно идеально, но всегда есть время, чтобы закончить одно дело. Если вы не можете съесть жир за один раз, вы можете сделать это первым.
    • Закон 3. Линейные системы и линейные организационные структуры потенциально неоднородны и гомоморфны. Посадка дынь пожинает дыни, создавая независимые и автономные подсистемы для снижения затрат на связь.
    • Закон 4. Крупные системные организации всегда более склонны к декомпозиции, чем небольшие системы. Когда они вместе долгое время, их надо разделить.Разделяй и властвуй.

  • «20 лекций о ядре микросервисной архитектуры»

Эксплуатация, статистика и техническая поддержка

рутинный мониторинг

средство мониторинга командной строки

APM

APM — управление производительностью приложений

Статистический анализ

Непрерывная интеграция (CI/CD)

Jenkins

разделение окружающей среды

Разделение сред разработки, тестирования и производства.

Автоматизированная эксплуатация и техническое обслуживание

Ansible

puppet

chef

контрольная работа

Теория TDD

  • «Глубокая интерпретация — TDD (разработка через тестирование)»
    • Кодирование функционального кода на основе тестовых случаев, основной практики XP (экстремального программирования).
    • Преимущества: Сосредоточьтесь на одном моменте, уменьшая нагрузку на размышления, адаптируясь к изменениям в требованиях или улучшая структуру кода, заранее уточняя требования, быстрая обратная связь и т. д.

модульный тест

испытание давлением

Стресс-тест полной ссылки

A/B, оттенки серого, сине-зеленый тест

Виртуализация

KVM

Xen

OpenVZ

контейнерная технология

Docker

Облачные технологии

OpenStack

DevOps

управление документами

промежуточное ПО

Web Server

Nginx

  • «Основы изучения Nginx — сравнение многопроцессорности и Apache»

    • Nginx обеспечивает высокий уровень параллелизма благодаря асинхронному неблокирующему механизму обработки событий. Apache занимает один поток на запрос, что очень сильно потребляет системные ресурсы.
    • Управление событиями подходит для служб с интенсивным вводом-выводом (Nginx), а несколько процессов или потоков подходят для служб с интенсивным использованием ЦП (Apache), поэтому Nginx подходит для обратного проксирования, а не для использования веб-сервера.

  • «Сравнение nginx и Apache, их преимущества и недостатки»

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

OpenResty

Apache Httpd

Tomcat

Принципы архитектуры

План настройки

  • "Схема настройки Tomcat"

    • Запустите режим NIO (или APR), настройте пул потоков, отключите коннектор AJP (архитектура Nginx+tomcat, AJP не требуется);

  • "протокол http tomcat и протокол ajp"

  • «Сравнение и анализ AJP и HTTP»

    • Протокол AJP (порт 8009) используется для уменьшения количества соединений (внешних) с внешним сервером (например, Apache и должен поддерживать протокол AJP) и повышения производительности за счет длинных соединений.
    • Когда параллелизм высок, протокол AJP лучше, чем протокол HTTP.

Jetty

  • Как работает Jetty и чем он отличается от Tomcat
  • «Сравнение преимуществ причала и кота»
    • Сравнение архитектуры: архитектура Jetty проще, чем у Tomcat.
    • Сравнение производительности: у Jetty и Tomcat небольшая разница в производительности. Jetty по умолчанию использует NIO для обработки запросов ввода-вывода, а Tomcat по умолчанию использует BIO для обработки запросов ввода-вывода. Tomcat подходит для обработки нескольких очень загруженных каналов и обработки статических данных. ресурсы, производительность низкая.
    • Другие аспекты: приложение Jetty работает быстрее, его модификация проста, а поддержка новой спецификации сервлетов лучше; Tomcat имеет более полную поддержку JEE и Servlet.

тайник

локальный кеш

Кэш клиента

кеш сервера

Memcached

Redis

  • «Учебник по Redis»

  • «Основополагающий принцип Redis»

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

  • «Метод сохранения Redis»

    • Режим RDB: регулярные моментальные снимки резервных копий, часто используемые для аварийного восстановления. Преимущества: резервное копирование в процессе разветвления не влияет на основной процесс, а RDB быстрее, чем AOF, при восстановлении больших наборов данных. Недостаток: данные будут потеряны.
    • Режим AOF: режим сохранения журнала операций. Преимущества: Меньшая потеря данных при восстановлении. Недостатки: Большие файлы, медленное восстановление.
    • Также возможно использовать комбинацию этих двух способов.

  • «Распределенный кэш — последовательность 3 — атомарная операция и оптимистическая блокировка CAS»

Архитектура

стратегия утилизации

Tair

  • Официальный сайт
  • «Сравнение Таира и Редиса»
  • Возможности: количество резервных узлов можно настроить и синхронизировать с резервным узлом посредством асинхронной синхронизации.
  • Последовательный алгоритм хеширования.
  • Архитектура: Подобно идее дизайна Hadoop, есть Configserver, DataServer, Configserver определяется пульсом, а Configserver также имеет отношение активный/резервный.

Несколько механизмов хранения:

  • MDB, полностью в памяти, может использоваться для хранения данных, таких как сеанс.
  • Rdb (похож на Redis), легкий, удаляет такие операции, как aof, поддерживает операции Restfull.
  • LDB (механизм хранения LevelDB), постоянное хранилище, LDB как постоянство rdb, реализованное Google, более эффективное, теоретической основой является алгоритм LSM (Log-Structured-Merge Tree), теперь измените данные в памяти, когда они достигают определенное количество (и старые данные, суммированные в памяти, записываются на диск вместе), а затем записываются на диск, и хранилище более эффективно.Счет аналогичен алгоритму хеширования.
  • Таир использует разделяемую память для хранения данных, если сервис зависает (не сервер), то после перезапуска сервиса данные остаются.

очередь сообщений

шина сообщений

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

порядок сообщений

RabbitMQ

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

RocketMQ

Реализация Java, поддерживается режим push-pull, а пропускная способность уступает Kafka. Порядок сообщений гарантирован.

ActiveMQ

Чистая реализация Java, совместимая с JMS, может быть встроена в приложения Java.

Kafka

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

Push-сообщение Redis

Режимы производителя и потребителя полностью выполняются на стороне клиента.Реализованы режимы списка и извлечения, а инструкции blpop используются для блокировки и ожидания.

ZeroMQ

TODO

по расписанию

Автономное планирование времени

Распределенное планирование времени

RPC

Dubbo

** SPI ** TODO

Thrift

gRPC

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

Промежуточное ПО базы данных

Sharding Jdbc

лог-система

сбор журналов

Центр конфигурации

Асинхронные функции сервлета 3.0 доступны для клиентов центра конфигурации

Шлюз API

Основные обязанности: переадресация запросов, аутентификация безопасности, преобразование протоколов и аварийное восстановление.

Интернет

протокол

Семиуровневый протокол OSI

TCP/IP

HTTP

HTTP2.0

HTTPS

сетевая модель

  • «Пять моделей ввода-вывода и три режима работы сети, которые необходимо понимать при веб-оптимизации»

    • Пять моделей ввода-вывода: блокирующий ввод-вывод, неблокирующий ввод-вывод, мультиплексирование ввода-вывода, ввод-вывод, управляемый событиями (сигналами), асинхронный ввод-вывод, первые четыре ввода-вывода являются синхронными операциями, ввод-вывод Первый этап O отличается, второй этап такой же, а последний является асинхронной операцией.
    • Существует три режима работы веб-сервера: Prefork (многопроцессный), рабочий режим (режим потоков) и режим событий.

  • «Краткий обзор различий между select, poll и epoll»

    • select, poll и epoll по сути являются синхронным вводом-выводом, потому что все они должны отвечать за чтение и запись после того, как событие чтения-записи будет готово, что означает, что процесс чтения-записи заблокирован.
    • select имеет ограничение на количество дескрипторов открытых файлов, по умолчанию 1024 (2048 для x64), 1 миллион одновременных процессов требует 1000 процессов, а затраты на переключение велики; опрос использует структуру связанного списка, и нет ограничений на номер.
    • Когда select и poll «бодрствуют», им нужно просмотреть всю коллекцию fd, в то время как epoll нужно только определить, пуст ли список готовых файлов, когда они «бодрствуют», что экономит много времени процессора благодаря механизму обратного вызова; набор fd необходимо один раз скопировать из пользовательского режима в режим ядра, а epoll нужно скопировать только один раз.
    • Poll будет постепенно снижать свою производительность по мере увеличения параллелизма.Epoll использует красно-черную древовидную структуру со стабильной производительностью и не будет снижаться по мере увеличения количества подключений.

  • "выбрать, опрос, сравнение epoll"

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

  • "Углубленное понимание Java NIO"

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

  • «Разница между BIO, NIO и AIO»

  • «Две модели проектирования эффективных серверов: модели Reactor и Proactor»

Epoll

Java NIO

kqueue

Соединения и короткие соединения

Рамка

нулевая копия

  • «Понимание нулевой копии Netty ByteBuf»
    • Несколько физически разделенных буферов логически объединяются в один, что позволяет избежать копирования данных между блоками памяти.

Сериализация (бинарный протокол)

Hessian

Protobuf

база данных

основная теория

Три парадигмы проектирования баз данных

  • «Три парадигмы баз данных и пять ограничений»
    • Первая нормальная форма: каждый столбец (каждое поле) в таблице данных должен быть наименьшей единицей, которая не может быть разделена, то есть для обеспечения атомарности каждого столбца;
    • Вторая нормальная форма (2NF): после удовлетворения 1NF все столбцы в таблице должны зависеть от первичного ключа, и ни один столбец не может быть не связан с первичным ключом, то есть таблица описывает только одну вещь;
    • Третья нормальная форма: сначала должна быть удовлетворена вторая нормальная форма (2NF), требующая: каждый столбец в таблице связан только напрямую с первичным ключом, а не косвенно (каждый столбец в таблице может зависеть только от первичного ключа) ;

MySQL

принцип

InnoDB

оптимизация

показатель

кластеризованный индекс, некластеризованный индекс

MyISAM не агрегирован, InnoDB агрегирован

составной индекс

Адаптивный хэш-индекс (AHI)

explain

NoSQL

MongoDB

  • Учебник по MongoDB
  • «Преимущества и недостатки MongoDB по сравнению с реляционными базами данных»
    • Преимущества: слабая согласованность (согласованность в конечном счете), которая может лучше обеспечить скорость доступа пользователей; встроенная GridFS, поддерживающая хранилище большой емкости; база данных без схемы, нет необходимости заранее определять структуру; встроенный шардинг; по сравнению с другими NoSQL, сторонняя поддержка богата, превосходная производительность;
    • Недостатки: mongodb не поддерживает транзакционные операции, mongodb занимает слишком много места, у MongoDB нет таких зрелых инструментов обслуживания, как у MySQL, что является достойным внимания местом для разработки и ИТ-операций;

Hbase

поисковый движок

Принципы поисковой системы

Lucene

Elasticsearch

Solr

sphinx

представление

Методология оптимизации производительности

Оценка потенциала

Сеть CDN

пул соединений

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

Большие данные

Потоковые вычисления

Storm

Flink

Kafka Stream

Сценарии применения

Например:

  • Реклама связанная в режиме реального времени статистика;
  • Метка портрета пользователя рекомендательной системы обновляется в режиме реального времени;
  • Мониторинг состояния онлайн-сервиса в режиме реального времени;
  • список в реальном времени;
  • Статистика данных в реальном времени.

Hadoop

HDFS

MapReduce

Yarn

Spark

Безопасность

веб-безопасность

XSS

CSRF

SQL-инъекция

Hash Dos

внедрение скрипта

Средство сканирования уязвимостей

код верификации

Предотвращение DDoS-атак

Защита конфиденциальной информации пользователя

  1. Пароли пользователей хранятся в виде неясного текста, и добавляется динамическая планка.
  2. Если вы хотите отобразить идентификационный номер и номер мобильного телефона, замените некоторые символы на «*».
  3. Отображается ли контактная информация или нет, контролируется пользователем.
  4. TODO

Уязвимость сериализации

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

Симметричное шифрование

  • «Общие алгоритмы симметричного шифрования»
    • DES, 3DES, Иглобрюх, AES
    • DES использует 56-битные ключи, Blowfish использует ключи переменной длины от 1 до 448 бит, AES 128, 192 и 256-битные ключи.
    • Ключ DES слишком короткий (всего 56 бит), алгоритм заменен на AES, а у AES есть аппаратное ускорение, производительность очень хорошая.

хеш-алгоритм

Асимметричное шифрование

безопасность сервера

Безопасность данных

резервное копирование данных

TODO

сетевая изоляция

Разделение внутренних и внешних сетей

TODO

Войти в спрингборд

Вход на онлайн-хост через трамплин во внутренней и внешней среде.

Авторизация, Аутентификация

RBAC

OAuth2.0

Двухфакторная аутентификация (2FA)

2FA — двухфакторная аутентификация для расширенной проверки входа

Обычная практика: пароль для входа + код подтверждения мобильного телефона (или токен-ключ, аналогичный USB-ключу с онлайн-банкингом).

Единый вход (SSO)

Распространенные фреймворки с открытым исходным кодом

протокол с открытым исходным кодом

структура регистрации

Лог4дж, Лог4дж2

Logback

ORM

Мой Батис:

  • "Подробное объяснение механизма кэширования mybatis"

    • Кэш первого уровня — это кеш уровня SqlSession, а кэшированные данные действительны только в пределах SqlSession.
    • Кэш второго уровня — это кеш уровня сопоставителя, и одно и то же пространство имен использует этот кеш, поэтому он используется совместно с SqlSession; используйте механизм LRU, чтобы очистить кеш и включить его с помощью параметра cacheEnabled.

  • «Генератор обучающего кода MyBatis»

веб-фреймворк

TODO

веб-фреймворк

Весенняя семья

Spring

Spring Boot

Spring Cloud

инструментальная рама

распределенный дизайн

Расширяемый дизайн

Стабильность и высокая доступность

  • «Проектирование системы: некоторые технические решения для систем высокой доступности»

    • Расширяемость: горизонтальное расширение, вертикальное расширение. Избегайте единых точек отказа с помощью избыточных развертываний.
    • Изоляция. Предотвратите использование одной службой всех ресурсов. Избегайте взаимного влияния между службами 2. Изоляция в компьютерном зале, чтобы избежать единой точки отказа.
    • Разъединение: снижение затрат на техническое обслуживание и снижение риска сцепления. Уменьшите зависимости и уменьшите взаимное влияние.
    • Текущее ограничение: метод подсчета скользящего окна, алгоритм дырявого ведра, алгоритм ведра с токеном и другие алгоритмы. При возникновении всплесков трафика обеспечьте стабильность системы.
    • Переход на более раннюю версию: высвобождение ресурсов для неосновных функций в экстренной ситуации. Пожертвуйте непрофильным бизнесом, чтобы обеспечить высокую доступность основного бизнеса.
    • Предохранитель: ненормальное состояние превышает пороговое значение и переходит в состояние плавкого предохранителя, которое быстро выходит из строя. Уменьшите влияние нестабильных внешних зависимостей на основные службы.
    • Автоматизированное тестирование: уменьшите количество сбоев, вызванных релизом, с помощью сложного тестирования.
    • Публикация в градациях серого. Публикация в градациях серого — это компромисс между скоростью и безопасностью, который может эффективно снизить количество сбоев при публикации.

  • «О системах высокой доступности»

    • Принципы проектирования: данные не теряются (постоянство); служба обладает высокой доступностью (копия службы); абсолютная 100%-я высокая доступность затруднена, и цель состоит в том, чтобы достичь как можно большего количества девяток, например 99,999% (всего всего 5 минут). в течение года).

аппаратная балансировка нагрузки

Балансировка нагрузки программного обеспечения

Ограничение

  • «Говоря о текущем ограничении систем с высокой степенью параллелизма»
    • Счетчик: Контролируйте количество запросов в единицу времени с помощью счетчика скользящего окна, который прост и груб.
    • Алгоритм дырявого ведра: дырявое ведро с фиксированной емкостью, запрос отбрасывается, когда дырявое ведро заполнено, что используется чаще.
    • Алгоритм корзины токенов: корзина токенов фиксированной емкости. Токены добавляются с определенной скоростью. Вам необходимо получить токен перед обработкой запроса. Если вы не можете получить токен, отклоните запрос или войдите в очередь сброса. Вы можете управлять скоростью, с которой добавляются токены. , чтобы контролировать общую скорость. RateLimiter в Guava — это реализация ведра токенов.
    • Дросселирование Nginx: пройтиlimit_reqи другие модули ограничивают количество одновременных подключений.

Аварийное восстановление прикладного уровня

  • "Лавинное оружие: принцип действия и применение взрывателя Hystrix"

    • Причины лавинного эффекта: аппаратный сбой, аппаратный сбой, программная ошибка, повторные попытки увеличить трафик и большое количество пользовательских запросов.
    • Лавинные контрмеры: текущий лимит, улучшенный режим кеша (предварительная загрузка кеша, синхронный вызов асинхронного), автоматическое расширение, даунгрейд.
    • Принципы дизайна Hystrix:
      • Изоляция ресурсов: Hystrix избегает лавин сервисов, назначая независимые пулы потоков для каждой зависимой службы для изоляции ресурсов.
      • Прерыватель цепи: работоспособность службы = количество неудачных запросов / общее количество запросов Переключатель управляется настройкой порога и скользящим окном.
      • Командный режим: обертка логики вызова службы путем наследования HystrixCommand.

  • "Проникновение в кеш, разбивка кеша, анализ лавинного решения кеша"

  • "Сбой кеша, инвалидация и проблемы с горячими клавишами"

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

Аварийное восстановление в компьютерных залах

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

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

  • «Несколько жизней в разных местах (несколько жизней в разных местах) Практический опыт»

    • Обратите внимание на проблему задержки: многократные вызовы через компьютерный зал увеличивают задержку в несколько раз.
    • Велика вероятность, что будут проблемы с выделенной линией для построения помещения, поэтому хорошо поработайте над отказоустойчивостью на эксплуатационно-техническом и программном уровнях.
    • Нельзя рассчитывать на двойную запись данных на стороне программы, и должна быть схема автоматической синхронизации.
    • Данные никогда не имеют больших задержек и плохого качества сети, учитывая проблемы с качеством синхронизации.
    • Основной бизнес и второстепенный бизнес разделяются и завоевываются, или даже рассматривается только основной бизнес.
    • Развертывание и тестирование удаленного мультиактивного мониторинга также должны идти в ногу со временем.
    • Рассмотрите возможность создания пользовательских разделов, когда это позволяет бизнес, особенно для игр и почтовых ящиков.
    • Контролируйте размер тела сообщения в компьютерном зале, чем меньше, тем лучше.
    • Рассмотрите возможность использования технологии виртуализации контейнеров Docker для улучшения возможностей динамического планирования.

  • Введение в технологию аварийного восстановления и опыт строительства

Процесс отработки аварийного восстановления

плавный пуск

Расширение базы данных

Режим разделения чтения-записи

Режим разделения

  • «Проблемы и решения, которые необходимо рассмотреть в подбазе данных и подтаблице»

    • Промежуточное ПО: легкое: sharding-jdbc, TSharding, тяжелое: Atlas, MyCAT, Vitess и т. д.
    • Проблемы: транзакции, соединения, миграции, масштабирование, идентификаторы, пейджинг и т. д.
    • Компенсация транзакций: сверка данных, сравнение на основе журналов, регулярная синхронизация со стандартными источниками данных и т. д.
    • Стратегия подбиблиотеки: диапазон значений, модуль, дата и т. д.
    • Количество подбаз данных: как правило, 50 миллионов записей в одной базе данных для MySQL и 100 миллионов записей для одной базы данных в Oracle требуют подбаз данных.

  • "Подробное объяснение таблицы MySql и раздела таблицы"

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

Служба управления

Регистрация и обнаружение службы

Управление маршрутизацией услуг

  • «Примечания к исследованию платформы распределенных услуг 4. Маршрутизация услуг»
    • Принцип: прозрачная маршрутизация
    • Стратегии балансировки нагрузки: случайный, циклический, задержка вызова службы, согласованное хеширование, фиксированные соединения.
    • Ограниченная стратегия локальной маршрутизации: injvm (приоритет вызова сервисов внутри jvm), native (приоритет использования сервисов той же физической машины), в принципе найти ближайший сервис.
    • Способ настройки: единый реестр, локальная конфигурация, динамическое распространение.

Распределенная согласованность

CAP и BASE теория

  • «От распределенной согласованности к теории CAP, теории BASE»
    • Классификация непротиворечивости: сильная непротиворечивость (немедленная непротиворечивость); слабая непротиворечивость (непротиворечивость может быть достигнута за единицу времени, например секунд); окончательная непротиворечивость (тип слабой непротиворечивости, в конечном счете непротиворечивый в течение определенного периода времени).
    • CAP: непротиворечивость, доступность, устойчивость к разделам (вызванная сбоями в сети)
    • БАЗОВЫЙ: в основном доступный, мягкое состояние и в конечном итоге согласованный
    • Основная идея теории BASE заключается в том, что даже если невозможно достичь строгой согласованности, каждое приложение может принять соответствующий метод для достижения окончательной согласованности в соответствии со своими бизнес-характеристиками.

Распределенная блокировка

  • «Несколько реализаций распределенных блокировок»

    • Распределенные блокировки на основе базы данных: Преимущества: Простота в эксплуатации и понятность. Недостатки: есть проблема с одной точкой, производительность базы данных может быть высокой, и она не реентерабельна;
    • Распределенные блокировки на основе кеша: Преимущества: неблокирующий, хорошая производительность. Недостатки: Плохая эксплуатация легко может привести к тому, что замок не будет снят.
    • Распределенная блокировка Zookeeper: механизм блокировки реализован через упорядоченные временные узлы.Если соответствующему узлу требуется наименьшая сумма, считается, что он получил блокировку. Преимущества: Кластер может прозрачно решать одноточечные проблемы, избегать проблем с не снятием блокировок, а блокировки могут быть повторно введены. Недостатки: производительность не так хороша, как у метода кэширования, и пропускная способность будет уменьшаться по мере увеличения размера кластера zk.

  • "Распределенная блокировка на основе Zookeeper"

    • Понятное описание принципа + пример кода на Java.

  • "реализация распределенной блокировки jedisLock-redis"

    • На основе setnx (установите, если он не существует), верните false, если есть, в противном случае верните true. И время истечения срока действия поддержки.

  • «Схема распределенной блокировки Memcached и Redis»

    • Используйте операцию добавления memcached (отличную от установки), чтобы вернуть false, когда ключ существует.

Алгоритм распределенной согласованности

PAXOS

Zab

Raft

Gossip

Двухэтапная фиксация, многофазная фиксация

идемпотент

  • «Распределенные системы — идемпотентный дизайн»
    • Роль функции идемпотента: Ресурс является идемпотентным, и запрашивающей стороне не нужно беспокоиться об ошибках, вызванных повторными вызовами.
    • Общие средства обеспечения идемпотентности: MVCC (аналог оптимистической блокировки), таблица дедупликации (уникальный индекс), пессимистическая блокировка, одноразовый токен, метод серийного номера.

Распределенная согласованная схема

Выборы узла распределенного лидера

TCC (попробовать/подтвердить/отменить) гибкая транзакция

  • «Традиционные дела и гибкие дела»
    • На основе теории BASE: в основном доступное, гибкое состояние, в конечном счете непротиворечивое.
    • Решение: Ведение журнала + компенсация (прямое пополнение или откат), повторная попытка сообщения (требуется, чтобы программа была идемпотентной); «дизайн без блокировки», с использованием оптимистического механизма блокировки.

Распределенная файловая система

Генерация уникального идентификатора

Глобально уникальный идентификатор

  • «Создание сводки глобального уникального идентификатора в распределенной системе с высокой степенью параллелизма»

    • Схема Twitter (алгоритм Snowflake): 41-битная метка времени + 10-битный идентификатор машины (например, IP-адрес, имя сервера и т. д.) + 12-битный серийный номер (локальный счетчик)
    • Схема мерцания: идентификатор автоинкремента MySQL + "REPLACE INTO XXX:SELECT 1316656;"
    • UUID: Недостаток, беспорядок, строка слишком длинная, занимает место и влияет на производительность поиска.
    • Решение MongoDB: используйте ObjectId. Недостаток: нельзя автоматически увеличивать.

  • «Принцип ПОСЛЕДОВАТЕЛЬНОСТИ TDDL в распределенных системах»

    • Создайте таблицу последовательности в базе данных для записи максимального значения занятого в данный момент id.
    • Каждый клиентский хост берет раздел идентификатора (например, 1000 ~ 2000) локально и обновляет запись максимального идентификатора в таблице последовательности.
    • Между клиентскими хостами берутся разные диапазоны идентификаторов, и они берутся снова, когда они израсходованы, а механизм оптимистичной блокировки используется для управления параллелизмом.

Последовательный алгоритм хеширования

Дизайн-мышление и режим разработки

DDD (Дизайн, управляемый доменом — Дизайн, управляемый доменом)

  • «Насколько я понимаю дизайн, основанный на домене DDD»

    • Концепция: DDD в первую очередь предлагается для устранения проблем в обычном процессе разработки программного обеспечения (анализ - проектирование - кодирование), избегая программного обеспечения, которое не может быть доставлено (и востребовано) из-за неизвестного анализа или единогласного анализа информации при разработке программного обеспечения. Представьте себе несоответствие) . DDD подчеркивает все в этой области, подчеркивая роль эксперта в предметной области, и подчеркивает развитие модели предметной области после того, как модель предметной области определена, и модель предметной области может направлять разработку (так называемый драйвер).
    • Процесс: понять домен, разделить домен, уточнить домен, точность модели зависит от глубины понимания модели.
    • Дизайн: инструменты моделирования, такие как агрегаты, сущности, объекты-значения, фабрики, репозитории, службы предметной области и события предметной области, предлагаются в DDD для помощи в моделировании предметной области.

  • «Краткий обзор основ доменно-ориентированного проектирования»

    • Домен — это по сути проблемный домен, такой как система электронной коммерции, система форумов и т. д.
    • Ограниченный контекст: описывает отношения между поддоменами, которые можно просто понимать как подсистему или компонентный модуль.
    • Модель предметной области: ядром DDD является создание правильной модели предметной области (с использованием общего языка описания, общего языка инструментальной области); она отражает характер бизнес-требований, включая объекты и процессы; она проходит через весь процесс анализа программного обеспечения. , дизайн и разработка Процесс, общий способ выражения модели предметной области: диаграмма, код или текст;
    • Язык предметной области: язык или инструмент, который эксперты предметной области, разработчики и дизайнеры могут использовать немедленно.
    • Классическая многоуровневая архитектура: уровень пользовательского интерфейса/отображения, уровень приложений, уровень предметной области, уровень инфраструктуры, который представляет собой четырехуровневый шаблон архитектуры.
    • Используемый режим:
      • Ассоциаций должно быть как можно меньше, как можно больше одного элемента, а общая сложность должна быть максимально снижена.
      • Сущность: Уникальный идентификатор в поле, атрибутов сущности как можно меньше, а понятно меньше всего.
      • Объект значения: простой объект без уникального идентификатора и неизменяемых значений свойств, таких как Дата.
      • Служба домена: координирует несколько объектов домена, только методы не имеют состояния (данные не хранятся); их можно разделить на службы прикладного уровня, службы уровня предметной области и службы базового уровня.
      • Aggregate and Aggregate Root (Агрегат, Aggregate Root): Aggregate определяет набор связанных объектов со связной связью; Корень агрегата — единственный элемент, на который ссылается агрегат; При изменении агрегата он должен находиться на уровне транзакции; Большинство полей В модели, 70% агрегатов обычно имеют только один объект, а 30% имеют только 2-3 объекта; если агрегат имеет только один объект, то этот объект является корнем агрегата; если существует несколько объектов, то мы можем думать о том, какой объект в совокупности имеет самостоятельное значение и может непосредственно взаимодействовать с окружающим миром;
      • Завод (Factory): Аналогичен шаблону factory в шаблоне проектирования.
      • Репозиторий: сохраняйте базу данных, управляйте объектами и проектируйте репозитории только для агрегатов.

  • «Путь реализации доменно-ориентированного проектирования (DDD)»

    • Агрегация: Например, автомобиль (Car) содержит такие компоненты, как двигатель (Engine), колеса (Wheel) и топливный бак (Tank), все из которых незаменимы.

  • «Серия «Дизайн, ориентированный на предметную область» (2) Анализ концепций, различий и использования VO, DTO, DO и PO»

Разделение обязанностей запроса команды (CQRS)

CQRS — разделение ответственности за запросы команд

Анемия, модель гиперемии

  • «Анемия, интерпретация модели перегрузки и некоторые опыты»
    • Модель потери крови: Лао-Цзы и Сон определены отдельно и не знают друг друга.В определении этих двух сущностей нет абсолютно никакой бизнес-логики, и они связаны через внешнюю службу.
    • Модель анемии: Лао-цзы знает своего сына, а его сын знает Лао-цзы; часть бизнес-логики размещена в сущности; Преимущества: Единые зависимости каждого слоя, четкая структура, простота обслуживания; Недостатки: Не соответствует ООП, а сервисный слой толще, чем модель перегрузки.
    • Модель перегрузки. Подобно модели анемии, разница заключается в том, как разделить бизнес-логику. Преимущества: сервисный слой относительно тонкий и играет только роль фасада, он не имеет отношения к DAO и сочетает в себе ООП-идеи Недостатки: неоднородная зависимость, двунаправленная зависимость между DO и DAO, а также логическое разделение сервисного слоя может легко вызвать путаницу.
    • Режим набухания: это крайний случай, отмена уровня службы и помещение всей бизнес-логики в DO; преимущества: соответствует идее объектно-ориентированного программирования и упрощает наслоение; недостатки: открывается слишком много информации, и многие логики, не относящиеся к DO, будут скрыты. принудительно включен в ДО. Этого шаблона следует избегать.
    • Авторы выступают за использование модели анемии.

Актерский режим

TODO

реактивное программирование

Reactor

TODO

RxJava

TODO

Vert.x

TODO

DODAF2.0

Serverless

TODO

Service Mesh

TODO

управление проектом

Обзор архитектуры

рефакторинг

спецификация кода

TODO

Обзор кода

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

RUP

Канбан-менеджмент

SCRUM

СКРАМ - Схватка

Гибкая разработка

TODO

Экстремальное программирование (XP)

XP - eXtreme Programming

  • Основная методология Agile-разработки: Extreme Programming XP

    • Это методология для разработчиков.

    • 4 большие ценности:

      • Коммуникация: поощряйте устное общение и повышайте эффективность.
      • Просто: хватит.
      • Обратная связь: своевременная обратная связь и информирование соответствующих людей.
      • Мужество: пропаганда перемен и смелость реконструкции.

    • 5 принципов: быстрая обратная связь, простые допущения, постепенные изменения, поддержка изменений (небольшие шаги), качественная работа (небольшие шаги с обеспечением качества).

    • 5 задач: поэтапные спринты, совещание по планированию спринта, ежедневное стендап-совещание, обзор после спринта, ретроспективное совещание.

парное программирование

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

Режим управления FMEA

TODO

Общие деловые термины

TODO

Технологические тенденции

TODO

политики и правила

TODO

закон

Строго соблюдать статью 253 Уголовного кодекса

Статья 253-1 Уголовного кодекса моей страны гласит:

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

Дополнительные положения (4) Верховного народного суда и Верховной народной прокуратуры об исполнении уголовного закона Китайской Народной Республики для определения обвинений: нарушение статьи 253-1 Уголовного закона представляет собой преступление «продажи или незаконного предоставления персональные данные граждан»; нарушение положений статьи 253-2 Уголовного кодекса составляет преступление «незаконное получение персональных данных граждан».

Качество архитектора

  • «Портрет архитектора».

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

  • «Что архитекторы должны знать об оптимизации архитектуры и проектировании»

    • Детали, которые необходимо учитывать: модульность, легкое связывание и архитектура без общего доступа; уменьшите лень перед каждым компонентом, обратите внимание на сбой цепочки и влияние, вызванное ленью между службами, и т. д.
    • Всестороннее рассмотрение инфраструктуры, конфигурации, тестирования, разработки, эксплуатации и обслуживания.
    • Учитывайте влияние людей, команд и организаций.

  • «Как я могу действительно улучшить себя и стать отличным архитектором? 》

  • «Основные качества архитектора и пути роста»

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

  • Архитектор - На каком этаже вы находитесь? 》

    • Архитекторы первого уровня видят только сам продукт
    • Архитекторы второго этажа видят не только собственные продукты, но и общее решение
    • Архитекторы уровня 3 видят ценность для бизнеса

Управление командой

TODO

Набор персонала

Информация

Информация об отрасли

Список публичных аккаунтов

TODO

блог

Блог команды

личный блог

Интегрированный портал, сообщество

одомашненный:

иностранный:

Сообщество вопросов и ответов

Анализ отраслевых данных

Специальный сайт

другие

Рекомендуемые справочники

Онлайн электронная книга

бумажная книга

разработка

Архитектурные аспекты

технический менеджмент

основная теория

Инструменты

TODO

большие данные

технические ресурсы

ресурсы с открытым исходным кодом

Инструкции, Документация, Учебники

одомашненный:

  • W3Cschool

  • Runoob.com

    • Вводные руководства по HTML, CSS, XML, Java, Python, PHP, шаблонам проектирования и многому другому.

  • Love2.io

    • Многие, многие китайские онлайн-книги являются совершенно новой платформой для обмена техническими документами с открытым исходным кодом.

  • gitbook.cn

    • Платные электронные книги.

  • ApacheCN

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

иностранный:

  • Quick Code
    • Бесплатные технические онлайн-уроки.
  • gitbook.com
    • Есть китайские электронные книги.
  • Cheatography
    • Полный сборник Cheat Sheets, одностраничный сайт с документацией.

онлайн-класс

конференция

Платформа публикации событий:

Общее приложение

искать работу

инструмент

хостинг кода

файловая служба

  • семь коров
  • Снова выстрелить в облако

Интегрированный поставщик облачных услуг

VPS

Категории