歡迎光臨
每天分享高質量文章

Spring Boot 自動配置的 “魔法” 是如何實現的?

(點選上方公眾號,可快速關註)


來源:sylvanassun ,

sylvanassun.github.io/2018/01/08/2018-01-08-spring_boot_auto_configure/

Spring Boot是Spring旗下眾多的子專案之一,其理念是約定優於配置,它透過實現了自動配置(大多數使用者平時習慣設定的配置作為預設配置)的功能來為使用者快速構建出標準化的應用。Spring Boot的特點可以概述為如下幾點:

  • 內建了嵌入式的Tomcat、Jetty等Servlet容器,應用可以不用打包成War格式,而是可以直接以Jar格式執行。

  • 提供了多個可選擇的”starter”以簡化Maven的依賴管理(也支援Gradle),讓您可以按需載入需要的功能模組。

  • 盡可能地進行自動配置,減少了使用者需要動手寫的各種冗餘配置項,Spring Boot提倡無XML配置檔案的理念,使用Spring Boot生成的應用完全不會生成任何配置程式碼與XML配置檔案。

  • 提供了一整套的對應用狀態的監控與管理的功能模組(透過引入spring-boot-starter-actuator),包括應用的執行緒資訊、記憶體資訊、應用是否處於健康狀態等,為了滿足更多的資源監控需求,Spring Cloud中的很多模組還對其進行了擴充套件。

有關Spring Boot的使用方法就不做多介紹了,如有興趣請自行閱讀官方檔案Spring Boot或其他文章。

如今微服務的概念愈來愈熱,轉型或嘗試微服務的團隊也在如日漸增,而對於技術選型,Spring Cloud是一個比較好的選擇,它提供了一站式的分散式系統解決方案,包含了許多構建分散式系統與微服務需要用到的元件,例如服務治理、API閘道器、配置中心、訊息匯流排以及容錯管理等模組。可以說,Spring Cloud”全家桶”極其適合剛剛接觸微服務的團隊。似乎有點跑題了,不過說了這麼多,我想要強調的是,Spring Cloud中的每個元件都是基於Spring Boot構建的,而理解了Spring Boot的自動配置的原理,顯然也是有好處的。

Spring Boot的自動配置看起來神奇,其實原理非常簡單,背後全依賴於@Conditional註解來實現的。

本文作者為SylvanasSun(sylvanas.sun@gmail.com),首發於SylvanasSun’s Blog。

原文連結:https://sylvanassun.github.io/2018/01/08/2018-01-08-spring_boot_auto_configure/

什麼是@Conditional?

@Conditional是由Spring 4提供的一個新特性,用於根據特定條件來控制Bean的建立行為。而在我們開發基於Spring的應用的時候,難免會需要根據條件來註冊Bean。

例如,你想要根據不同的執行環境,來讓Spring註冊對應環境的資料源Bean,對於這種簡單的情況,完全可以使用@Profile註解實現,就像下麵程式碼所示:

@Configuration

public class AppConfig {

    @Bean

    @Profile(“DEV”)

    public DataSource devDataSource() {

        …

    }

     

    @Bean

    @Profile(“PROD”)

    public DataSource prodDataSource() {

        …

    }

}

剩下只需要設定對應的Profile屬性即可,設定方法有如下三種:

  • 透過context.getEnvironment().setActiveProfiles(“PROD”)來設定Profile屬性。

  • 透過設定jvm的spring.profiles.active引數來設定環境(Spring Boot中可以直接在application.properties配置檔案中設定該屬性)。

  • 透過在DispatcherServlet的初始引數中設定。

    dispatcher

    org.springframework.web.servlet.DispatcherServlet

   

       spring.profiles.active

       PROD

   

但這種方法只侷限於簡單的情況,而且透過原始碼我們可以發現@Profile自身也使用了@Conditional註解。

package org.springframework.context.annotation;

@Target({ElementType.TYPE, ElementType.METHOD})

@Retention(RetentionPolicy.RUNTIME)

@Documented

@Conditional({ProfileCondition.class}) // 組合了Conditional註解

public @interface Profile {

    String[] value();

}

package org.springframework.context.annotation;

class ProfileCondition implements Condition {

    ProfileCondition() {

    }

    // 透過提取出@Profile註解中的value值來與profiles配置資訊進行匹配

    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {

        if(context.getEnvironment() != null) {

            MultiValueMap attrs = metadata.getAllAnnotationAttributes(Profile.class.getName());

            if(attrs != null) {

                Iterator var4 = ((List)attrs.get(“value”)).iterator();

                Object value;

                do {

                    if(!var4.hasNext()) {

                        return false;

                    }

                    value = var4.next();

                } while(!context.getEnvironment().acceptsProfiles((String[])((String[])value)));

                return true;

            }

        }

        return true;

    }

}

在業務複雜的情況下,顯然需要使用到@Conditional註解來提供更加靈活的條件判斷,例如以下幾個判斷條件:

  • 在類路徑中是否存在這樣的一個類。

  • 在Spring容器中是否已經註冊了某種型別的Bean(如未註冊,我們可以讓其自動註冊到容器中,上一條同理)。

  • 一個檔案是否在特定的位置上。

  • 一個特定的系統屬性是否存在。

  • 在Spring的配置檔案中是否設定了某個特定的值。

舉個慄子,假設我們有兩個基於不同資料庫實現的DAO,它們全都實現了UserDao,其中JdbcUserDAO與MySql進行連線,MongoUserDAO與MongoDB進行連線。現在,我們有了一個需求,需要根據命令列傳入的系統引數來註冊對應的UserDao,就像java -jar app.jar -DdbType=MySQL會註冊JdbcUserDao,而java -jar app.jar -DdbType=MongoDB則會註冊MongoUserDao。使用@Conditional可以很輕鬆地實現這個功能,僅僅需要在你自定義的條件類中去實現Condition介面,讓我們來看下麵的程式碼。(以下案例來自:https://dzone.com/articles/how-springboot-autoconfiguration-magic-works)

public interface UserDAO {

    ….

}

public class JdbcUserDAO implements UserDAO {

    ….

}

public class MongoUserDAO implements UserDAO {

    ….

}

public class MySQLDatabaseTypeCondition implements Condition {

    @Override

    public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

        String enabledDBType = System.getProperty(“dbType”); // 獲得系統引數 dbType

        // 如果該值等於MySql,則條件成立

        return (enabledDBType != null && enabledDBType.equalsIgnoreCase(“MySql”));

    }

}

// 與上述邏輯一致

public class MongoDBDatabaseTypeCondition implements Condition {

    @Override

    public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

        String enabledDBType = System.getProperty(“dbType”);

        return (enabledDBType != null && enabledDBType.equalsIgnoreCase(“MongoDB”));

    }

}

// 根據條件來註冊不同的Bean

@Configuration

public class AppConfig {

    @Bean

    @Conditional(MySQLDatabaseTypeCondition.class)

    public UserDAO jdbcUserDAO() {

        return new JdbcUserDAO();

    }

     

    @Bean

    @Conditional(MongoDBDatabaseTypeCondition.class)

    public UserDAO mongoUserDAO() {

        return new MongoUserDAO();

    }

}

現在,我們又有了一個新需求,我們想要根據當前工程的類路徑中是否存在MongoDB的驅動類來確認是否註冊MongoUserDAO。為了實現這個需求,可以建立檢查MongoDB驅動是否存在的兩個條件類。

public class MongoDriverPresentsCondition implements Condition {

    @Override

    public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

        try {

            Class.forName(“com.mongodb.Server”);

            return true;

        } catch (ClassNotFoundException e) {

            return false;

        }

    }

}

public class MongoDriverNotPresentsCondition implements Condition {

    @Override

    public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

        try {

            Class.forName(“com.mongodb.Server”);

            return false;

        } catch (ClassNotFoundException e) {

            return true;

        }

    }

}

假如,你想要在UserDAO沒有被註冊的情況下去註冊一個UserDAOBean,那麼我們可以定義一個條件類來檢查某個類是否在容器中已被註冊。

public class UserDAOBeanNotPresentsCondition implements Condition {

    @Override

    public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

        UserDAO userDAO = conditionContext.getBeanFactory().getBean(UserDAO.class);

        return (userDAO == null);

    }

}

如果你想根據配置檔案中的某項屬性來決定是否註冊MongoDAO,例如app.dbType是否等於MongoDB,我們可以實現以下的條件類。

public class MongoDbTypePropertyCondition implements Condition {

    @Override

    public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

        String dbType = conditionContext.getEnvironment().getProperty(“app.dbType”);

        return “MONGO”.equalsIgnoreCase(dbType);

    }

}

我們已經嘗試並實現了各種型別的條件判斷,接下來,我們可以選擇一種更為優雅的方式,就像@Profile一樣,以註解的方式來完成條件判斷。首先,我們需要定義一個註解類。

@Target({ ElementType.TYPE, ElementType.METHOD })

@Retention(RetentionPolicy.RUNTIME)

@Documented

@Conditional(DatabaseTypeCondition.class)

public @interface DatabaseType {

    String value();

}

具體的條件判斷邏輯在DatabaseTypeCondition類中,它會根據系統引數dbType來判斷註冊哪一個Bean。

public class DatabaseTypeCondition implements Condition {

    @Override

    public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata metadata) {

        Map attributes = metadata

                                            .getAnnotationAttributes(DatabaseType.class.getName());

        String type = (String) attributes.get(“value”);

        // 預設值為MySql

        String enabledDBType = System.getProperty(“dbType”, “MySql”);

        return (enabledDBType != null && type != null && enabledDBType.equalsIgnoreCase(type));

    }

}

最後,在配置類應用該註解即可。

@Configuration

@ComponentScan

public class AppConfig {

    @Bean

    @DatabaseType(“MySql”)

    public UserDAO jdbcUserDAO() {

        return new JdbcUserDAO();

    }

    @Bean

    @DatabaseType(“mongoDB”)

    public UserDAO mongoUserDAO() {

        return new MongoUserDAO();

    }

}

AutoConfigure原始碼分析

透過瞭解@Conditional註解的機制其實已經能夠猜到自動配置是如何實現的了,接下來我們透過原始碼來看看它是怎麼做的。本文中講解的原始碼基於Spring Boot 1.5.9版本(最新的正式版本)。

使用過Spring Boot的童鞋應該都很清楚,它會替我們生成一個入口類,其命名規格為ArtifactNameApplication,透過這個入口類,我們可以發現一些資訊。

@SpringBootApplication

public class DemoApplication {

    public static void main(String[] args) {

        SpringApplication.run(DemoApplication.class, args);

    }

}

首先該類被@SpringBootApplication註解修飾,我們可以先從它開始分析,檢視原始碼後可以發現它是一個包含許多註解的組合註解。

@Target({ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

@Documented

@Inherited

@SpringBootConfiguration

@EnableAutoConfiguration

@ComponentScan(

    excludeFilters = {@Filter(

    type = FilterType.CUSTOM,

    classes = {TypeExcludeFilter.class}

), @Filter(

    type = FilterType.CUSTOM,

    classes = {AutoConfigurationExcludeFilter.class}

)}

)

public @interface SpringBootApplication {

    @AliasFor(

        annotation = EnableAutoConfiguration.class,

        attribute = “exclude”

    )

    Class >[] exclude() default {};

    @AliasFor(

        annotation = EnableAutoConfiguration.class,

        attribute = “excludeName”

    )

    String[] excludeName() default {};

    @AliasFor(

        annotation = ComponentScan.class,

        attribute = “basePackages”

    )

    String[] scanBasePackages() default {};

    @AliasFor(

        annotation = ComponentScan.class,

        attribute = “basePackageClasses”

    )

    Class >[] scanBasePackageClasses() default {};

}

該註解相當於同時宣告了@Configuration、@EnableAutoConfiguration與@ComponentScan三個註解(如果我們想定製自定義的自動配置實現,宣告這三個註解就足夠了),而@EnableAutoConfiguration是我們的關註點,從它的名字可以看出來,它是用來開啟自動配置的,原始碼如下:

@Target({ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

@Documented

@Inherited

@AutoConfigurationPackage

@Import({EnableAutoConfigurationImportSelector.class})

public @interface EnableAutoConfiguration {

    String ENABLED_OVERRIDE_PROPERTY = “spring.boot.enableautoconfiguration”;

    Class >[] exclude() default {};

    String[] excludeName() default {};

}

我們發現@Import(Spring 提供的一個註解,可以匯入配置類或者Bean到當前類中)匯入了EnableAutoConfigurationImportSelector類,根據名字來看,它應該就是我們要找到的標的了。不過檢視它的原始碼發現它已經被Deprecated了,而官方API中告知我們去檢視它的父類AutoConfigurationImportSelector。

/** @deprecated */

@Deprecated

public class EnableAutoConfigurationImportSelector extends AutoConfigurationImportSelector {

    public EnableAutoConfigurationImportSelector() {

    }

    protected boolean isEnabled(AnnotationMetadata metadata) {

        return this.getClass().equals(EnableAutoConfigurationImportSelector.class)?((Boolean)this.getEnvironment().getProperty(“spring.boot.enableautoconfiguration”, Boolean.class, Boolean.valueOf(true))).booleanValue():true;

    }

}

由於AutoConfigurationImportSelector的原始碼太長了,這裡我只截出關鍵的地方,顯然方法selectImports是選擇自動配置的主入口,它呼叫了其他的幾個方法來載入元資料等資訊,最後傳回一個包含許多自動配置類資訊的字串陣列。

public String[] selectImports(AnnotationMetadata annotationMetadata) {

    if(!this.isEnabled(annotationMetadata)) {

        return NO_IMPORTS;

    } else {

        try {

            AutoConfigurationMetadata ex = AutoConfigurationMetadataLoader.loadMetadata(this.beanClassLoader);

            AnnotationAttributes attributes = this.getAttributes(annotationMetadata);

            List configurations = this.getCandidateConfigurations(annotationMetadata, attributes);

            configurations = this.removeDuplicates(configurations);

            configurations = this.sort(configurations, ex);

            Set exclusions = this.getExclusions(annotationMetadata, attributes);

            this.checkExcludedClasses(configurations, exclusions);

            configurations.removeAll(exclusions);

            configurations = this.filter(configurations, ex);

            this.fireAutoConfigurationImportEvents(configurations, exclusions);

            return (String[])configurations.toArray(new String[configurations.size()]);

        } catch (IOException var6) {

            throw new IllegalStateException(var6);

        }

    }

}

重點在於方法getCandidateConfigurations()傳回了自動配置類的資訊串列,而它透過呼叫SpringFactoriesLoader.loadFactoryNames()來掃描載入含有META-INF/spring.factories檔案的jar包,該檔案記錄了具有哪些自動配置類。(建議還是用IDE去看原始碼吧,這些原始碼單行實在太長了,估計文章中的觀看效果很差)

protected List getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {

    List configurations = SpringFactoriesLoader

                                        .loadFactoryNames(this.getSpringFactoriesLoaderFactoryClass(), this.getBeanClassLoader());

    Assert.notEmpty(configurations, “No auto configuration classes 

    found in META-INF spring.factories. 

    If you are using a custom packaging, make sure that file is correct.”);

    return configurations;

}

     

public static List loadFactoryNames(Class > factoryClass, ClassLoader classLoader) {

    String factoryClassName = factoryClass.getName();

    try {

        Enumeration ex = classLoader != null?classLoader.getResources(“META-INF/spring.factories”):ClassLoader.getSystemResources(“META-INF/spring.factories”);

        ArrayList result = new ArrayList();

        while(ex.hasMoreElements()) {

            URL url = (URL)ex.nextElement();

            Properties properties = PropertiesLoaderUtils.loadProperties(new UrlResource(url));

            String factoryClassNames = properties.getProperty(factoryClassName);

            result.addAll(Arrays.asList(StringUtils.commaDelimitedListToStringArray(factoryClassNames)));

        }

        return result;

    } catch (IOException var8) {

        throw new IllegalArgumentException(“Unable to load [” + factoryClass.getName() + “] factories from location [” + “META-INF/spring.factories” + “]”, var8);

    }

}

自動配置類中的條件註解

接下來,我們在spring.factories檔案中隨便找一個自動配置類,來看看是怎樣實現的。我查看了MongoDataAutoConfiguration的原始碼,發現它宣告了@ConditionalOnClass註解,透過看該註解的原始碼後可以發現,這是一個組合了@Conditional的組合註解,它的條件類是OnClassCondition。

@Configuration

@ConditionalOnClass({Mongo.class, MongoTemplate.class})

@EnableConfigurationProperties({MongoProperties.class})

@AutoConfigureAfter({MongoAutoConfiguration.class})

public class MongoDataAutoConfiguration {

    ….

}

@Target({ElementType.TYPE, ElementType.METHOD})

@Retention(RetentionPolicy.RUNTIME)

@Documented

@Conditional({OnClassCondition.class})

public @interface ConditionalOnClass {

    Class >[] value() default {};

    String[] name() default {};

}

然後,我們開始看OnClassCondition的原始碼,發現它並沒有直接實現Condition介面,只好往上找,發現它的父類SpringBootCondition實現了Condition介面。

class OnClassCondition extends SpringBootCondition implements AutoConfigurationImportFilter, BeanFactoryAware, BeanClassLoaderAware {

    …..

}

public abstract class SpringBootCondition implements Condition {

    private final Log logger = LogFactory.getLog(this.getClass());

    public SpringBootCondition() {

    }

    public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {

        String classOrMethodName = getClassOrMethodName(metadata);

        try {

            ConditionOutcome ex = this.getMatchOutcome(context, metadata);

            this.logOutcome(classOrMethodName, ex);

            this.recordEvaluation(context, classOrMethodName, ex);

            return ex.isMatch();

        } catch (NoClassDefFoundError var5) {

            throw new IllegalStateException(“Could not evaluate condition on ” + classOrMethodName + ” due to ” + var5.getMessage() + ” not found. Make sure your own configuration does not rely on that class. This can also happen if you are @ComponentScanning a springframework package (e.g. if you put a @ComponentScan in the default package by mistake)”, var5);

        } catch (RuntimeException var6) {

            throw new IllegalStateException(“Error processing condition on ” + this.getName(metadata), var6);

        }

    }

    public abstract ConditionOutcome getMatchOutcome(ConditionContext var1, AnnotatedTypeMetadata var2);

}

SpringBootCondition實現的matches方法依賴於一個抽象方法this.getMatchOutcome(context, metadata),我們在它的子類OnClassCondition中可以找到這個方法的具體實現。

public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {

    ClassLoader classLoader = context.getClassLoader();

    ConditionMessage matchMessage = ConditionMessage.empty();

    // 找出所有ConditionalOnClass註解的屬性

    List onClasses = this.getCandidates(metadata, ConditionalOnClass.class);

    List onMissingClasses;

    if(onClasses != null) {

        // 找出不在類路徑中的類

        onMissingClasses = this.getMatches(onClasses, OnClassCondition.MatchType.MISSING, classLoader);

        // 如果存在不在類路徑中的類,匹配失敗

        if(!onMissingClasses.isEmpty()) {

            return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnClass.class, new Object[0]).didNotFind(“required class”, “required classes”).items(Style.QUOTE, onMissingClasses));

        }

        matchMessage = matchMessage.andCondition(ConditionalOnClass.class, new Object[0]).found(“required class”, “required classes”).items(Style.QUOTE, this.getMatches(onClasses, OnClassCondition.MatchType.PRESENT, classLoader));

    }

    // 接著找出所有ConditionalOnMissingClass註解的屬性

    // 它與ConditionalOnClass註解的含義正好相反,所以以下邏輯也與上面相反

    onMissingClasses = this.getCandidates(metadata, ConditionalOnMissingClass.class);

    if(onMissingClasses != null) {

        List present = this.getMatches(onMissingClasses, OnClassCondition.MatchType.PRESENT, classLoader);

        if(!present.isEmpty()) {

            return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnMissingClass.class, new Object[0]).found(“unwanted class”, “unwanted classes”).items(Style.QUOTE, present));

        }

        matchMessage = matchMessage.andCondition(ConditionalOnMissingClass.class, new Object[0]).didNotFind(“unwanted class”, “unwanted classes”).items(Style.QUOTE, this.getMatches(onMissingClasses, OnClassCondition.MatchType.MISSING, classLoader));

    }

    return ConditionOutcome.match(matchMessage);

}

// 獲得所有annotationType註解的屬性

private List getCandidates(AnnotatedTypeMetadata metadata, Class > annotationType) {

    MultiValueMap attributes = metadata.getAllAnnotationAttributes(annotationType.getName(), true);

    ArrayList candidates = new ArrayList();

    if(attributes == null) {

        return Collections.emptyList();

    } else {

        this.addAll(candidates, (List)attributes.get(“value”));

        this.addAll(candidates, (List)attributes.get(“name”));

        return candidates;

    }

}

private void addAll(List list, ListitemsToAdd) {

    if(itemsToAdd != null) {

        Iterator var3 = itemsToAdd.iterator();

        while(var3.hasNext()) {

            Object item = var3.next();

            Collections.addAll(list, (String[])((String[])item));

        }

    }

}    

// 根據matchType.matches方法來進行匹配

private List getMatches(Collection candidates, OnClassCondition.MatchType matchType, ClassLoader classLoader) {

    ArrayList matches = new ArrayList(candidates.size());

    Iterator var5 = candidates.iterator();

    while(var5.hasNext()) {

        String candidate = (String)var5.next();

        if(matchType.matches(candidate, classLoader)) {

            matches.add(candidate);

        }

    }

    return matches;

}

關於match的具體實現在MatchType中,它是一個列舉類,提供了PRESENT和MISSING兩種實現,前者傳回類路徑中是否存在該類,後者相反。

private static enum MatchType {

    PRESENT {

        public boolean matches(String className, ClassLoader classLoader) {

            return OnClassCondition.MatchType.isPresent(className, classLoader);

        }

    },

    MISSING {

        public boolean matches(String className, ClassLoader classLoader) {

            return !OnClassCondition.MatchType.isPresent(className, classLoader);

        }

    };

    private MatchType() {

    }

    // 跟我們之前看過的案例一樣,都利用了類載入功能來進行判斷

    private static boolean isPresent(String className, ClassLoader classLoader) {

        if(classLoader == null) {

            classLoader = ClassUtils.getDefaultClassLoader();

        }

        try {

            forName(className, classLoader);

            return true;

        } catch (Throwable var3) {

            return false;

        }

    }

    private static Class > forName(String className, ClassLoader classLoader) throws ClassNotFoundException {

        return classLoader != null?classLoader.loadClass(className):Class.forName(className);

    }

    public abstract boolean matches(String var1, ClassLoader var2);

}

現在終於真相大白,@ConditionalOnClass的含義是指定的類必須存在於類路徑下,MongoDataAutoConfiguration類中宣告了類路徑下必須含有Mongo.class, MongoTemplate.class這兩個類,否則該自動配置類不會被載入。

在Spring Boot中到處都有類似的註解,像@ConditionalOnBean(容器中是否有指定的Bean),@ConditionalOnWebApplication(當前工程是否為一個Web工程)等等,它們都只是@Conditional註解的擴充套件。當你揭開神秘的面紗,去探索本質時,發現其實Spring Boot自動配置的原理就是如此簡單,在瞭解這些知識後,你完全可以自己去實現自定義的自動配置類,然後編寫出自定義的starter。

【關於投稿】


如果大家有原創好文投稿,請直接給公號傳送留言。


① 留言格式:
【投稿】+《 文章標題》+ 文章連結

② 示例:
【投稿】《不要自稱是程式員,我十多年的 IT 職場總結》:http://blog.jobbole.com/94148/

③ 最後請附上您的個人簡介哈~



看完本文有收穫?請轉發分享給更多人

關註「ImportNew」,提升Java技能

贊(0)

分享創造快樂