Рекомендация проекта с открытым исходным кодом
Pepper Metricsэто инструмент с открытым исходным кодом, разработанный мной и моими коллегами (GitHub.com/live-actioncool/pep…), который собирает текущую статистику производительности jedis/mybatis/httpservlet/dubbo/motan и предоставляет ее для основных данных, совместимых с базой данных временных рядов, таких как prometheus, и отображает тенденции через grafana. Его подключаемая архитектура также очень удобна для пользователей, позволяющих расширять и интегрировать другие компоненты с открытым исходным кодом.
Пожалуйста, поставьте звезду и пригласите всех стать разработчиками и отправить PR, чтобы вместе улучшить проект.
Начните с простого веб-проекта Spring Boot
Мы знаем, что очень легко написать веб-проект с помощью spring-boot, pom наследует spring-boot-parent, а затем вводит зависимость spring-boot-starter-web, а затем пишет такой основной класс запуска, а затем вы можно написать Controller, очень просто, вот так:
@SpringBootApplication
public class SampleApplication {
public static void main(String[] args) {
SpringApplication.run(SampleApplication.class, args);
}
}
// 然后再写一个Controller声明一个Rest服务
@RestController
@RequestMapping("/perf")
public class PerfController {
@RequestMapping("/trace")
public Object trace() {
Object result = yourLogic();
return result;
}
}
Разговор о SpringApplication.run
Но мы подумали о том, что за это сделал spring-boot, чтобы сделать нашу работу такой простой, и как он интегрирует spring, spring-mvc и tomcat? Далее мы анализируем весь процесс инициализации с точки зрения запуска проекта.
PS: В следующем процессе анализа кода основное внимание уделяется конкатенации процесса. Когда переменная вызывается, автор напрямую дает конкретную реализацию переменной. Читатель может быть сбит с толку, но не останавливайтесь, сначала примите это как должное и следуйте инструкциям автора.После того, как идея будет завершена, процесс инициализации и выбора реализации каждой основной переменной будет объяснен один за другим.
Из SpringApplication.run: Метод определяется следующим образом
public static ConfigurableApplicationContext run(Class<?>[] primarySources, String[] args) {
return new SpringApplication(primarySources).run(args);
}
public ConfigurableApplicationContext run(String... args) {
StopWatch stopWatch = new StopWatch();
stopWatch.start();
ConfigurableApplicationContext context = null;
Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>();
configureHeadlessProperty();
SpringApplicationRunListeners listeners = getRunListeners(args);
listeners.starting();
try {
ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
configureIgnoreBeanInfo(environment);
Banner printedBanner = printBanner(environment);
context = createApplicationContext();//1)
exceptionReporters = getSpringFactoriesInstances(SpringBootExceptionReporter.class,
new Class[] { ConfigurableApplicationContext.class }, context);
prepareContext(context, environment, listeners, applicationArguments, printedBanner);
refreshContext(context);//2)
afterRefresh(context, applicationArguments);
stopWatch.stop();
if (this.logStartupInfo) {
new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);
}
listeners.started(context);
callRunners(context, applicationArguments);
}
catch (Throwable ex) {
handleRunFailure(context, ex, exceptionReporters, listeners);
throw new IllegalStateException(ex);
}
try {
listeners.running(context);
}
catch (Throwable ex) {
handleRunFailure(context, ex, exceptionReporters, null);
throw new IllegalStateException(ex);
}
return context;
}
Давайте разберем этот метод RUN
Первый взгляд 1) context = createApplicationContext()
Отвечает за создание основного контейнера Spring. Этот метод динамически выбирается и реализуется в соответствии с классами, от которых зависит конкретный проект во время выполнения. Если это веб-проект, будет выбран AnnotationConfigServletWebServerApplicationContext. Что касается правил и причин выбора, они будут здесь игнорируются и будут представлены позже (пространство-время).ServletWebServerApplicationContext).
Далее мы сосредоточимся на 2) методе refreshContext (контекст)
Наконец, его метод вызывает метод ((AbstractApplicationContext) applicationContext).refresh(), мы расширяем этот метод
@Override
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
prepareRefresh();
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
prepareBeanFactory(beanFactory);
try {
postProcessBeanFactory(beanFactory);
invokeBeanFactoryPostProcessors(beanFactory);
registerBeanPostProcessors(beanFactory);
initMessageSource();
initApplicationEventMulticaster();
onRefresh();//3)
registerListeners();
finishBeanFactoryInitialization(beanFactory);
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
destroyBeans();
cancelRefresh(ex);
throw ex;
}
finally {
resetCommonCaches();
}
}
}
На самом деле, наш вызов здесь достиг пакета spring-context, который не имеет ничего общего с spring-boot.На самом деле это часть refresh() стандартного процесса запуска стандартного SpringApplicationContext.Мы не разбираем процесс запуска spring Так что мы сосредоточимся только на той части, которая сочетается с tomcat, spring-mvc.
Посмотрите непосредственно на 3) метод onRefresh(), потому что AnnotationConfigServletWebServerApplicationContext является подклассом ServletWebServerApplicationContext, поэтому процесс входит в метод onRefresh() ServletWebServerApplicationContext.
@Override
protected void onRefresh() {
super.onRefresh();
try {
createWebServer();//4)
}
catch (Throwable ex) {
throw new ApplicationContextException("Unable to start web server", ex);
}
}
Вы можете видеть это 4) createWebServer(), который является нашим ключом
private void createWebServer() {
WebServer webServer = this.webServer;
ServletContext servletContext = getServletContext();
if (webServer == null && servletContext == null) {
ServletWebServerFactory factory = getWebServerFactory();//5)
this.webServer = factory.getWebServer(getSelfInitializer());//6)
}
else if (servletContext != null) {
try {
getSelfInitializer().onStartup(servletContext);
}
catch (ServletException ex) {
throw new ApplicationContextException("Cannot initialize servlet context", ex);
}
}
initPropertySources();
}
в:
5)ServletWebServerFactory factory = getWebServerFactory();
Конкретной реализацией, полученной с помощью приведенного выше предложения, является TomcatServletWebServerFactory (ворота пространства-времени:TomcatServletWebServerFactory)
6) this.webServer = factory.getWebServer(getSelfInitializer());
Сначала взгляните на метод getSelfInitializer() в 6):
private org.springframework.boot.web.servlet.ServletContextInitializer getSelfInitializer() {
return this::selfInitialize;
}
private void selfInitialize(ServletContext servletContext) throws ServletException {
prepareWebApplicationContext(servletContext);
registerApplicationScope(servletContext);
WebApplicationContextUtils.registerEnvironmentBeans(getBeanFactory(), servletContext);
for (ServletContextInitializer beans : getServletContextInitializerBeans()) {
beans.onStartup(servletContext);
}
}
Это немного интересно, он возвращает this::selfInitialize, определение метода должно возвращать org.springframework.boot.web.servlet.ServletContextInitializer, давайте посмотрим, что он определен
@FunctionalInterface
public interface ServletContextInitializer {
void onStartup(ServletContext servletContext) throws ServletException;
}
@FunctionalInterface — это функциональный интерфейс selfInitialize, поддерживаемый лямбдой в java 8. Эта логика будет вызываться позже в процессе.
Продолжайте смотреть на this.webServer = factory.getWebServer(...) в 6), давайте посмотрим на реализацию:
@Override
public WebServer getWebServer(ServletContextInitializer... initializers) {
Tomcat tomcat = new Tomcat();
File baseDir = (this.baseDirectory != null) ? this.baseDirectory : createTempDir("tomcat");
tomcat.setBaseDir(baseDir.getAbsolutePath());
Connector connector = new Connector(this.protocol);
tomcat.getService().addConnector(connector);
customizeConnector(connector);
tomcat.setConnector(connector);
tomcat.getHost().setAutoDeploy(false);
configureEngine(tomcat.getEngine());
for (Connector additionalConnector : this.additionalTomcatConnectors) {
tomcat.getService().addConnector(additionalConnector);
}
prepareContext(tomcat.getHost(), initializers);//7)
return getTomcatWebServer(tomcat);
}
Видно, что экземпляр Tomcat создается как внутренняя реализация webServer, а затем коннектор внедряется в контейнер службы Tomcat, а затем устанавливается атрибут AutoDeploy контейнера Host по умолчанию и другие действия по инициализации Tomcat.Самая важная строка это 7)
Давайте взглянем:
protected void prepareContext(Host host, ServletContextInitializer[] initializers) {
File documentRoot = getValidDocumentRoot();
TomcatEmbeddedContext context = new TomcatEmbeddedContext();
if (documentRoot != null) {
context.setResources(new LoaderHidingResourceRoot(context));
}
...//省略我们不关注的部分代码
ServletContextInitializer[] initializersToUse = mergeInitializers(initializers);//8)
host.addChild(context);//将context加入host作为host的子容器
configureContext(context, initializersToUse);//9)
postProcessContext(context);
}
Мы видим, что он вызывает host.addChild(context) для добавления контекста к хосту в качестве подконтейнера хоста, а затем 8) Найдите все реализации ServletContextInitializer и объедините их в массив, затем вызовите 9) метод configureContext, давайте посмотрим:
protected void configureContext(Context context, ServletContextInitializer[] initializers) {
TomcatStarter starter = new TomcatStarter(initializers);//10)
if (context instanceof TomcatEmbeddedContext) {
TomcatEmbeddedContext embeddedContext = (TomcatEmbeddedContext) context;
embeddedContext.setStarter(starter);
embeddedContext.setFailCtxIfServletStartFails(true);
}
context.addServletContainerInitializer(starter, NO_CLASSES);//11)
...//忽略
}
10) Создается объект TomcatStarter, и стартер добавляется в список containerInitializer контекста, см. 11), так что экземпляр TomcatStarter будет вызываться во время процесса запуска контейнера tomcat.
Давайте посмотрим, что делает TomcatStarter
class TomcatStarter implements ServletContainerInitializer {
...
private final ServletContextInitializer[] initializers;
...
TomcatStarter(ServletContextInitializer[] initializers) {
this.initializers = initializers;
}
...
@Override
public void onStartup(Set<Class<?>> classes, ServletContext servletContext) throws ServletException {
try {
for (ServletContextInitializer initializer : this.initializers) {
initializer.onStartup(servletContext);
}
}
catch (Exception ex) {
this.startUpException = ex;
if (logger.isErrorEnabled()) {
logger.error("Error starting Tomcat context. Exception: " + ex.getClass().getName() + ". Message: "
+ ex.getMessage());
}
}
}
...
}
Вы можете увидеть, что Tomcatstarter эквивалентен подключением события запуска контекста, а затем вызова метода onstartup всех введенных инициализаторов. Это кажется знакомым? Это интерфейс функции @FunctionalInterface, упомянутый ранее. Далее мы сделаем более глубокий взгляд на конкретное содержание onstartup инициализатора, упомянутого ранее.
//ServletWebServerApplicationContext类当中
private org.springframework.boot.web.servlet.ServletContextInitializer getSelfInitializer() {
return this::selfInitialize;
}
private void selfInitialize(ServletContext servletContext) throws ServletException {
prepareWebApplicationContext(servletContext);
registerApplicationScope(servletContext);
WebApplicationContextUtils.registerEnvironmentBeans(getBeanFactory(), servletContext);
for (ServletContextInitializer beans : getServletContextInitializerBeans()) {
beans.onStartup(servletContext);
}
}
Вы можете видеть, что он вызывает метод onStartup для каждого ServletContextInitializer из getServletContextInitializerBeans().
protected Collection<ServletContextInitializer> getServletContextInitializerBeans() {
return new ServletContextInitializerBeans(getBeanFactory());
}
Посмотрите, что делает новый ServletContextInitializerBeans(getBeanFactory())
@SafeVarargs
public ServletContextInitializerBeans(ListableBeanFactory beanFactory,
Class<? extends ServletContextInitializer>... initializerTypes) {
this.initializers = new LinkedMultiValueMap<>();
this.initializerTypes = (initializerTypes.length != 0) ? Arrays.asList(initializerTypes)
: Collections.singletonList(ServletContextInitializer.class);
addServletContextInitializerBeans(beanFactory);
addAdaptableBeans(beanFactory);
List<ServletContextInitializer> sortedInitializers = this.initializers.values().stream()
.flatMap((value) -> value.stream().sorted(AnnotationAwareOrderComparator.INSTANCE))
.collect(Collectors.toList());
this.sortedList = Collections.unmodifiableList(sortedInitializers);
logMappings(this.initializers);
}
Вы можете видеть, что он получает все реализации ServletContextInitializer в контейнере spring из beanFactory, Часть интеграции здесь находится в ServletRegistrationBean, а процесс внедрения ServletRegistrationBean относится к:Пространственно-временные ворота: Dispatcherservletregistrationbean
private void addServletContextInitializerBeans(ListableBeanFactory beanFactory) {
for (Class<? extends ServletContextInitializer> initializerType : this.initializerTypes) {
for (Entry<String, ? extends ServletContextInitializer> initializerBean : getOrderedBeansOfType(beanFactory,
initializerType)) {
addServletContextInitializerBean(initializerBean.getKey(), initializerBean.getValue(), beanFactory);
}
}
}
private void addServletContextInitializerBean(String beanName, ServletContextInitializer initializer,
ListableBeanFactory beanFactory) {
if (initializer instanceof ServletRegistrationBean) {
Servlet source = ((ServletRegistrationBean<?>) initializer).getServlet();
addServletContextInitializerBean(Servlet.class, beanName, initializer, beanFactory, source);
}
else if (initializer instanceof FilterRegistrationBean) {
Filter source = ((FilterRegistrationBean<?>) initializer).getFilter();
addServletContextInitializerBean(Filter.class, beanName, initializer, beanFactory, source);
}
else if (initializer instanceof DelegatingFilterProxyRegistrationBean) {
String source = ((DelegatingFilterProxyRegistrationBean) initializer).getTargetBeanName();
addServletContextInitializerBean(Filter.class, beanName, initializer, beanFactory, source);
}
else if (initializer instanceof ServletListenerRegistrationBean) {
EventListener source = ((ServletListenerRegistrationBean<?>) initializer).getListener();
addServletContextInitializerBean(EventListener.class, beanName, initializer, beanFactory, source);
}
else {
addServletContextInitializerBean(ServletContextInitializer.class, beanName, initializer, beanFactory,
initializer);
}
}
Затем процесс пойдет гладко, мы вызовем метод onStartup ServletRegistrationBean и, наконец, вызовем стандарт Servlet3.0 servletContext.addServlet, чтобы внедрить DispatchServlet в контейнер сервлета для перехвата всех запросов.
См. код ниже:
//RegistrationBean
@Override
public final void onStartup(ServletContext servletContext) throws ServletException {
String description = getDescription();
if (!isEnabled()) {
logger.info(StringUtils.capitalize(description) + " was not registered (disabled)");
return;
}
register(description, servletContext);
}
//DynamicRegistrationBean
@Override
protected final void register(String description, ServletContext servletContext) {
D registration = addRegistration(description, servletContext);
if (registration == null) {
logger.info(
StringUtils.capitalize(description) + " was not registered " + "(possibly already registered?)");
return;
}
configure(registration);
}
//ServletRegistrationBean
@Override
protected ServletRegistration.Dynamic addRegistration(String description, ServletContext servletContext) {
String name = getServletName();
return servletContext.addServlet(name, this.servlet);
}
На этом все интеграции завершены, и процесс запуска передается на выполнение tomcat.
Незаконченная история: как инициализируется каждый зависимый компонент
TomcatServletWebServerFactory
В spring-boot-autoconfigure/META-INF/spring.factories есть конфигурация:
...
# Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.web.servlet.ServletWebServerFactoryAutoConfiguration,\
...
Затем давайте взглянем на класс ServletWebServerFactoryAutoConfiguration.
@Configuration
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
@ConditionalOnClass(ServletRequest.class)
@ConditionalOnWebApplication(type = Type.SERVLET)
@EnableConfigurationProperties(ServerProperties.class)
@Import({ ServletWebServerFactoryAutoConfiguration.BeanPostProcessorsRegistrar.class,
ServletWebServerFactoryConfiguration.EmbeddedTomcat.class,
ServletWebServerFactoryConfiguration.EmbeddedJetty.class,
ServletWebServerFactoryConfiguration.EmbeddedUndertow.class })
public class ServletWebServerFactoryAutoConfiguration {
...
}
Часть @Import представляет ServletWebServerFactoryConfiguration.EmbeddedTomcat.class, взгляните поближе
@Configuration
class ServletWebServerFactoryConfiguration {
@Configuration
@ConditionalOnClass({ Servlet.class, Tomcat.class, UpgradeProtocol.class })
@ConditionalOnMissingBean(value = ServletWebServerFactory.class, search = SearchStrategy.CURRENT)
public static class EmbeddedTomcat {
@Bean
public TomcatServletWebServerFactory tomcatServletWebServerFactory() {
return new TomcatServletWebServerFactory();
}
}
...
}
Эта часть Spring Boot оценивает, соответствует ли текущая среда выполнения условиям в соответствии с @ConditionalOnClass, то есть содержит ли jar-пакет tomcat, и если да, то создает экземпляр Bean TomcatServletWebServerFactory для присоединения к управлению контейнером spring, что пригодится позже. .
ServletWebServerApplicationContext
Когда он фактически запускается, запускается его подкласс AnnotationConfigServletWebServerApplicationContext.Давайте посмотрим на класс SpringApplication.Фактически, SpringApplication решает, какой ApplicationContext использовать во время выполнения в зависимости от ситуации.
public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) {
this.resourceLoader = resourceLoader;
Assert.notNull(primarySources, "PrimarySources must not be null");
this.primarySources = new LinkedHashSet<>(Arrays.asList(primarySources));
this.webApplicationType = WebApplicationType.deduceFromClasspath();
setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class));
setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));
this.mainApplicationClass = deduceMainApplicationClass();
}
WebApplicationType.deduceFromClasspath() используется для автоматической идентификации этого значения, см. реализацию:
static WebApplicationType deduceFromClasspath() {
if (ClassUtils.isPresent(WEBFLUX_INDICATOR_CLASS, null) && !ClassUtils.isPresent(WEBMVC_INDICATOR_CLASS, null)
&& !ClassUtils.isPresent(JERSEY_INDICATOR_CLASS, null)) {
return WebApplicationType.REACTIVE;
}
for (String className : SERVLET_INDICATOR_CLASSES) {
if (!ClassUtils.isPresent(className, null)) {
return WebApplicationType.NONE;
}
}
return WebApplicationType.SERVLET;
}
Можно видеть, что он оценивается по тому, есть ли в загрузчике классов класс, связанный с сервлетом, поэтому он оценивается во время выполнения.
DispatcherServletRegistrationBean
DispatcherServletRegistrationBean — это ключ, гарантирующий, что наш DispatcherServlet внедряется в контейнер сервлета и начинает действовать Давайте посмотрим, как он инициализируется.
В spring-boot-autoconfigure/META-INF/spring.factories есть конфигурация:
# Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.web.servlet.DispatcherServletAutoConfiguration,\
посмотреть реализацию
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
@Configuration
@ConditionalOnWebApplication(type = Type.SERVLET)
@ConditionalOnClass(DispatcherServlet.class)
@AutoConfigureAfter(ServletWebServerFactoryAutoConfiguration.class)
public class DispatcherServletAutoConfiguration {
@Configuration
@Conditional(DispatcherServletRegistrationCondition.class)
@ConditionalOnClass(ServletRegistration.class)
@EnableConfigurationProperties(WebMvcProperties.class)
@Import(DispatcherServletConfiguration.class)
protected static class DispatcherServletRegistrationConfiguration {
private final WebMvcProperties webMvcProperties;
private final MultipartConfigElement multipartConfig;
public DispatcherServletRegistrationConfiguration(WebMvcProperties webMvcProperties,
ObjectProvider<MultipartConfigElement> multipartConfigProvider) {
this.webMvcProperties = webMvcProperties;
this.multipartConfig = multipartConfigProvider.getIfAvailable();
}
@Bean(name = DEFAULT_DISPATCHER_SERVLET_REGISTRATION_BEAN_NAME)
@ConditionalOnBean(value = DispatcherServlet.class, name = DEFAULT_DISPATCHER_SERVLET_BEAN_NAME)
public DispatcherServletRegistrationBean dispatcherServletRegistration(DispatcherServlet dispatcherServlet) {
DispatcherServletRegistrationBean registration = new DispatcherServletRegistrationBean(dispatcherServlet,
this.webMvcProperties.getServlet().getPath());
registration.setName(DEFAULT_DISPATCHER_SERVLET_BEAN_NAME);
registration.setLoadOnStartup(this.webMvcProperties.getServlet().getLoadOnStartup());
if (this.multipartConfig != null) {
registration.setMultipartConfig(this.multipartConfig);
}
return registration;
}
}
}
Как видите, это похоже на экземпляр Bean DispatcherServletRegistrationBean, зарегистрированный контейнером Spring, и давайте посмотрим на его отношения наследования:
Его родительский класс ServletRegistrationBean имеет следующие методы:
@Override
protected ServletRegistration.Dynamic addRegistration(String description, ServletContext servletContext) {
String name = getServletName();
return servletContext.addServlet(name, this.servlet);
}
Он вызывает метод ServletContext.addServlet для добавления DispatchServlet в контейнер сервлетов, который является методом регистрации сервлетов в Servlet3.0.
Тогда вы можете спросить, а когда вызывается addRegistration?
В соответствии с отношением наследования посмотрите на родительский класс RegistrationBean его родительского класса, который имеет
@Override
public final void onStartup(ServletContext servletContext) throws ServletException {
String description = getDescription();
if (!isEnabled()) {
logger.info(StringUtils.capitalize(description) + " was not registered (disabled)");
return;
}
register(description, servletContext);
}
Метод register — это шаблонный метод, который вызывает реализацию подкласса DynamicRegistrationBean.
@Override
protected final void register(String description, ServletContext servletContext) {
D registration = addRegistration(description, servletContext);
if (registration == null) {
logger.info(StringUtils.capitalize(description) + " was not registered " + "(possibly already registered?)");
return;
}
configure(registration);
}
Метод addRegistration также является шаблонным методом.Реализация является реализацией addRegistration предыдущего ServletRegistrationBean, а метод onStartup будет вызываться в процессе метода SpringApplication.run().Я уже упоминал его, когда говорил об основном процесс, поэтому я не буду повторяться здесь.
Таким образом DispatchServlet и Tomcat интегрированы.DispatchServlet использует шаблон проектирования метода шаблона для назначения определенных запросов различным обработчикам для обработки.Об этом будет упомянуто позже.Эта статья в основном посвящена принципу интеграции Spring Boot, Spring MVC и Tomcat. часть.