1. Предпосылки
1.1 История архитектуры прикладной системы
1.2 Что такое микросервисы?
Происхождение: Концепция микросервисов возникла из статьи «Микросервисы», написанной Мартином Фаулером в марте 2014 года. В содержании статьи упоминается: Микросервисная архитектура — это архитектурный шаблон, который выступает за разделение одного приложения на набор небольших сервисов, а сервисы координируют и взаимодействуют друг с другом, чтобы предоставить пользователям максимальную ценность.
Метод связи. Каждая служба работает в своем собственном процессе, и службы взаимодействуют друг с другом с помощью упрощенного механизма связи (обычно API RESTful на основе HTTP).
Общее определение микросервисов. Микросервисы — это архитектурный стиль, в котором большое сложное программное приложение состоит из одного или нескольких микросервисов. Каждая микрослужба в системе может быть развернута независимо, и каждая микрослужба слабо связана. Каждый микросервис ориентирован на выполнение только одной задачи.
Исходная полная служба обработки разделена на две или более службы обработки, и между ними существует взаимосвязь вызова По сравнению с исходной службой с одним процессом это «микрослужба». (Микросервис — это сравнительное понятие, а не отдельное понятие)
1.3 Преимущества микросервисной архитектуры
- Масштабируемость: при добавлении бизнес-функций в архитектуре отдельного приложения необходимо вносить относительно большие корректировки на основе кода исходной архитектуры, в то время как в архитектуре микросервисов нужно только добавить новые узлы микросервисов и настроить связанные узлы микросервисов. При повышении скорости реагирования бизнеса одну архитектуру необходимо масштабировать как единое целое, в то время как архитектуре микросервисов необходимо масштабировать только узлы микросервисов с недостаточной реакцией.
- Отказоустойчивость: когда система выходит из строя, архитектура одного приложения должна восстанавливать всю систему, включая изменения кода, а также запуск и останов приложения, в то время как архитектуре микросервиса нужно только изменить код и запустить и остановить службы для рассматриваемой службы. Другие сервисы могут обеспечить отказоустойчивость на уровне приложения с помощью таких механизмов, как повторная попытка и автоматический выключатель.
- Гибкий выбор технологий: в микросервисной архитектуре каждый микросервисный узел может свободно выбирать наиболее подходящий технологический стек в соответствии с различными требуемыми функциями.Даже при реконструкции одного микросервисного узла стоимость очень низкая.
- Более эффективная DevOps: каждый узел микрослужбы представляет собой единый процесс, все сосредоточены на одной функции и четко выражают границы службы через четко определенные интерфейсы. Благодаря своему небольшому размеру и низкой сложности каждый микросервис может полностью контролироваться небольшой командой или отдельным лицом, что упрощает поддержание высокой ремонтопригодности и эффективности разработки.
Как самая популярная среда разработки микросервисов в настоящее время, Spring Cloud реализует архитектуру микросервисов без использования среды Spring Cloud и обладает преимуществами архитектуры микросервисов. Правильное понимание — использовать фреймворк Spring Cloud для разработки системы микросервисной архитектуры, чтобы система обладала преимуществами микросервисной архитектуры (Spring Cloud — это как инструмент, и для него тоже нужен процесс «делания»).
1.4 Что такое Spring Boot? Что такое весеннее облако?
Фреймворк Spring Boot — это новый фреймворк, предоставленный командой Pivotal, который предназначен для упрощения начального процесса создания и разработки приложений на основе Spring. Фреймворк SpringBoot использует особый способ настройки системы приложений, поэтому разработчикам больше не нужно тратить много энергии на определение шаблонных файлов конфигурации.
Spring Cloud — это инструмент разработки облачных приложений на основе Spring Boot, который обеспечивает управление конфигурацией, регистрацию и обнаружение сервисов, автоматические выключатели, интеллектуальную маршрутизацию, микроагенты, шины управления, глобальные блокировки и кампании по принятию решений в облаке на основе JVM. такие операции, как , распределенные сеансы и управление состоянием кластера, обеспечивают простой способ разработки.
1.5 Связь между микросервисами, Spring Boot и Spring Cloud
- Мысль: микросервис — это концепция архитектуры, которая предлагает принципы проектирования микросервисов и обеспечивает руководящую идеологию для реализации конкретных технологий из теории.
- Формирование шаблонов: Spring Boot — это набор шаблонов быстрой конфигурации, с помощью которых можно быстро разработать один микросервис на основе Spring Boot.
- Набор из нескольких компонентов: Spring Cloud — это набор инструментов для управления службами, основанный на Spring Boot; Spring Boot фокусируется на отдельной микрослужбе, которую можно быстро и легко интегрировать; Spring Cloud фокусируется на глобальной структуре управления службами.
2. Технический анализ
2.1 Everything is jar, Everything is http
Spring Boot идентифицируется как приложение Spring Boot с помощью аннотации @SpringBootApplication. Все приложения компилируются, развертываются и запускаются через пакеты jar.
@SpringBootApplication
public class Application {
private static final Logger LOGGER = LoggerFactory.getLogger(Application.class);
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
LOGGER.info(”启动成功！");
}
}
Каждое приложение Spring Boot может предоставлять http-сервисы с помощью встроенных веб-контейнеров. Ему нужно полагаться только на spring-boot-start-web в файле pom. В принципе, микросервисная архитектура предполагает, что каждый независимый узел будет предоставлять http-сервисы.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
2.2 Запуск задачи Spring boot Task и задача синхронизации
Когда Spring Boot нужно запустить задачу, ему нужно только наследовать интерфейс CommandLineRunner и реализовать его метод запуска.
@SpringBootApplication
public class ClientDataListener implements CommandLineRunner
public void run(String... strings) throws Exception {
clientInfoListenerHandler();
}
}
Когда Spring Boot необходимо выполнять запланированные задачи, вам нужно всего лишь добавить аннотацию @Scheduled(cron = "0 15 0 * *?") к методу запланированной задачи (поддерживает стандартные выражения cron) и добавить @EnableScheduling к запуску службы. класс Просто аннотировать.
@SpringBootApplication
@EnableScheduling
public class Application {
private static final Logger LOGGER = LoggerFactory.getLogger(Application.class);
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
LOGGER.info(”启动成功！");
}
}
// some class
@Scheduled(cron = "0 15 0 * * ?")
public void someTimeTask() {
***
}
2.3 Мониторинг привода Spring Boot
Актуатор — это компонент, предоставляемый spring boot для мониторинга самой системы приложения.Достаточно ввести spring-boot-starter-actuator на основе внедрения spring-boot-start-web.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
2.4 Центр конфигурации Spring Cloud Config
Когда мы реализуем микросервисную архитектуру, каждому узлу микросервиса нужны свои собственные связанные элементы данных конфигурации.Когда узлов много, обслуживание становится очень сложным, поэтому необходимо установить центральную службу конфигурации.
Spring Cloud Config разделен на две части. Сервер Spring Cloud Config — это служебный процесс, а файл конфигурации Spring Cloud — место хранения файлов конфигурации.
2.5 Реестр сервисов Spring Cloud Eureka
Концепция регистрации службы появилась задолго до появления микросервисной архитектуры, которая разделяет исходный отдельный узел приложения на множество узлов микрослужбы. Отношения вызова между собой будут очень сложными, Spring Cloud Eureka выступает в роли реестра, и все микросервисы могут зарегистрироваться в Spring Cloud Eureka для унифицированного управления и доступа (Eureka отличается от Zookeeper, и OP выбран по принципу AOP, Больше упора на эффективность сервиса)
2.6 Интеллектуальная маршрутизация на стороне сервера Spring Cloud Zuul
Когда мы регистрируем все службы в Eureka (реестр служб), возникает вопрос, как их вызывать. Spring Cloud Zuul — это прокси-компонент на стороне сервера, предоставляемый Spring Cloud. Его можно рассматривать как шлюз. Zuul получает доступные службы через Eureka. Через конфигурацию сопоставления клиент получает доступ к Zuul для доступа к службам, к которым действительно необходимо получить доступ. Все сервисы идентифицируются по spring.application.name,
Разные IP-адреса, одно и то же spring.application.name — сервисный кластер. Когда мы добавляем узел с тем же именем spring.application.name, Zuul получает информацию о новом узле, связываясь с Eureka, чтобы обеспечить интеллектуальную маршрутизацию и повысить скорость отклика этого типа службы.
2.7 Интеллектуальная маршрутизация клиента Spring Cloud Ribbon
В соответствии с прокси-сервером Spring Cloud Zuul, Spring Cloud Ribbon предоставляет прокси-сервер на стороне клиента. В прокси-сервере клиенту не нужно знать, какой узел микросервиса в конечном итоге предоставляет услугу, а прокси-сервер на стороне клиента получает узел, который фактически предоставляет услугу, и выбирает один из них для вызова службы. Подобно Zuul, Ribbon также реализует интеллектуальную маршрутизацию на стороне клиента, взаимодействуя с Eureka (реестр служб).
2.8 Распределенная трассировка Spring cloud Sleuth
2.9 Цепочка вызовов Spring cloud Zipkin
2.10 HTTP-клиент Spring Cloud Feign
Spring Cloud Feign — это декларативный шаблонный http-клиент. При использовании Spring Cloud Feign для запроса удаленной службы это может быть похоже на вызов локального метода, чтобы разработчики не чувствовали, что это удаленный метод (Feign интегрирует Ribbon для балансировки нагрузки).
Сопоставление удаленных служб и локальных служб
@FeignClient(name = "rabbitmq-http", url = "${SKYTRAIN_RABBITMQ_HTTP}")
public interface TaskService {
@RequestMapping(value = "/api/queues", method = RequestMethod.GET)
public String query(@RequestHeader("Authorization") String token);
}
Вызовите удаленную службу так же, как локальную службу
@Autowired
private TaskService taskService;
private String queryRabbitmqStringInfo() {
byte[] credentials = Base64 .encodeBase64((rabbitmqHttpUserName + ":" + rabbitmqHttpPassword).getBytes(StandardCharsets.UTF_8));
String token = "Basic " + new String(credentials, StandardCharsets.UTF_8);
return taskService.query(token);
}
2.11 Автоматический выключатель Spring Cloud Hystrix
3. Практика микросервисов
3.1 Несколько разработанных нами микросервисных компонентов — Центр управления приложениями
Центр управления приложениями может выполнять полные онлайн-операции по остановке, компиляции, упаковке, развертыванию и запуску каждого зарегистрированного микросервисного узла.
3.2 Несколько компонентов микросервиса, которые мы разработали — центр запросов данных zookeeper
Центр запроса данных зоопарка получает информацию о данных зоопарка в соответствии с адресом зоопарка, портом и командой.
3.3 Несколько разработанных нами компонентов микросервисов — Центр обнаружения работоспособности микросервисов
Центр обнаружения работоспособности периодически проверяет состояние каждой микрослужбы и инициирует сигнал тревоги, когда обнаруживается, что состояние микрослужбы ОТКЛЮЧЕНО или время ожидания соединения истекло.
3.4 Несколько микросервисных компонентов, разработанных нами - центр запросов по времени
// 在BeanPostProcessor子类中拦截
@Component
public class SkytrainBeanPostProcessor implements BeanPostProcessor, Ordered {
***
/**
* Bean 实例化之后进行的处理
*/
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
beanPostProcessor.postProcessAfter(bean, beanName);
return bean;
}
***
}
// 拦截后获取定时任务注解
***
public Object postProcessAfter(Object bean, String beanName) {
Class targetClass = AopUtils.getTargetClass(bean);
Map annotatedMethods = MethodIntrospector.selectMethods(targetClass,
new MethodIntrospector.MetadataLookup() {
public Set inspect(Method method) {
Set scheduledMethods = AnnotatedElementUtils.getMergedRepeatableAnnotations(method,
Scheduled.class, Schedules.class);
return (!scheduledMethods.isEmpty() ? scheduledMethods : null);
}
});
if (!annotatedMethods.isEmpty()) {
String className = targetClass.getName();
for (Map.Entry entry : annotatedMethods.entrySet()) {
Method method = entry.getKey();
for (Scheduled scheduled : entry.getValue()) {
String key = className + ":" + method.getName();
String value = scheduled.toString();
taskInfos.put(key, value);
}
}
}
return null;
}
***
// 获取定时任务后注册
***
public void taskRegister() {
String nodeInfo = ipAddress + ":" + serverPort + ":";
try {
/**
* 定时任务
*/
Map infos = taskInfos;
for (Entry item : infos.entrySet()) {
String taskId = nodeInfo + item.getKey();
String taskParameter = item.getValue();
JSONObject info = new JSONObject();
info.put("taskId", taskId);
info.put("taskParameter", taskParameter);
info.put("applicationName", applicationName);
info.put("taskType", "schedule");
LOGGER.info(info.toString());
zooKeeperExecutor.createZKNode(SKYTRAIN_TASK_ZKNODE_PREFIX + taskId, info.toString());
}
}
catch (Exception ex) {
LOGGER.error("", ex);
}
}
***
3.5 Классификация микросервисов
- Компоненты микросервисной платформы
- компоненты государственной службы
- Базовый сервисный компонент/Бизнес-сервисный компонент
3.6 Общая схема микросервисной архитектуры
Автор: Лян Синь
Источник: Технологический институт CreditEase.