用雲開發快速製作客戶業務需求收集小程序丨實戰

一、導語

​ 如何省去企業上門(現場)搜集客戶需求的環節,節約企業人力和時間成本,將客戶的業務定製需求直接上傳至雲數據庫?雲開發為我們提供了這個便利!

二、需求背景

​ 作為一名XX公司IT萌萌新,這段時間對小程序開發一直有非常濃厚的興趣,並且感慨於“雲開發·不止於快”的境界。近期工作中,剛好碰見業務部門的一個需求,目的是節約上門跟客戶收集業務定製資料的時間,以往是每變更一次,就需要上門一次,碰見地域較遠的,費時費力,且往往要求幾天內完成上線,時間非常緊迫。因此,結合一直以來對雲開發的各種優勢的了解,我說服公司領導通過小程序·雲開發來實現。

下面是其中一項業務定製界面的展示:
(1)業務對業務流程有簡單說明;
(2)相關業務介紹;
(3)不同客戶輸入個性化需求;
(4)雲存儲後台實現需求表單的收集。

​ 得力於雲開發提供的API和WeUI庫的便利,本項目在我在極短的時間內就實現了比較理想的效果 。接下來,我就從本項目入手,講講我是如何依靠小程序·雲開發將想法快速實現的,其實我也是剛入門沒多久,只是想分享一下自身在學習小程序開發項目中的一些知識點和體會,代碼可能略為粗糙,邏輯也有待優化,歡迎大家在評論區多多交流。

三、開發過程

1、組件

主要使用了官方WeUI擴展能力的一些組件庫來實現主要功能。

核心的WeUI庫主要有 Msg、Picker、圖片的Upload等(以快為目的,節省自己寫CSS樣式的時間,也方便0基礎的同學上手,這裏又體會到了小程序開發的便捷)。

2、實現代碼

本次雲開發包括雲數據庫雲存儲兩大功能:

(1)雲數據庫

雲數據庫的主要就是搜集客戶提交上來的表單信息,包括客戶的聯繫方式和選擇的業務類型等,並存儲在雲數據庫中,方便業務經理搜集需求。

我們來看簡單的實現過程:

首先是表單,用到了 form 表單組件以及它的 bindsubmit 方法,在 wxml 中放置 form 表單:

<form bindsubmit="formSubmit">
    <view class="form">
      <view class="section">
        <picker bindchange="bindPickerGsd" mode="selector" value="{{indexGsd}}" range="{{arrayGsd}}">
          <view class="picker">歸屬縣市</view>
          <view class="picker-content" >{{arrayGsd[indexGsd]?arrayGsd[indexGsd]:"(必填項) 請下拉選擇歸屬地"}}</view> 
        </picker>
      </view>    
      <!---中間部分詳見代碼--->
    </view>

    <view class="footer">
      <button class="dz-btn" formType="submit" loading="{{formStatus.submitting}}" disabled="{{formStatus.submitting}}" bindtap="openSuccess">提交</button>
    </view>
  </form>

表單中除了普通的文本輸入,增加有下拉列表的實現(畢竟客戶有時候是比較懶的)。

來看一下具體代碼:

bindPickerGsd: function (e) {    
  console.log('歸屬地已選擇,攜帶值為', e.detail.value)
  console.log('歸屬地選擇:', this.data.arrayGsd[e.detail.value])    
  this.setData({
     indexGsd: e.detail.value     
   })   
   this.data.formData.home_county = this.data.arrayGsd[e.detail.value]
},

最後表單上傳到雲數據庫:

  // 表單提交
  formSubmit: function (e) {
    var minlength = '';
    var maxlength = '';
    console.log("表單內容",e)
    var that = this;
    var formData = e.detail.value;
    var result = this.wxValidate.formCheckAll(formData);
    
    console.log("表單提交formData", formData);
    console.log("表單提交result", result)
    wx.showLoading({
      title: '發布中...',
    })
    const db = wx.cloud.database()
    db.collection('groupdata').add({
      data: {
        time: getApp().getNowFormatDate(),
        home_county: this.data.formData.home_county,
        group_name: formData.group_name,
        contact_name: formData.contact_name,
        msisdn: formData.msisdn,
        product_name: this.data.formData.product_name,
        word: formData.word,
      },
      success: res => {
        wx.hideLoading()
        console.log('發布成功', res)

      },
      fail: err => {
        wx.hideLoading()
        wx.showToast({
          icon: 'none',
          title: '網絡不給力....'
        })
        console.error('發布失敗', err)
      }
    })
  },
(2)雲存儲

​ 因為業務的定製需要填單客戶所在單位的授權證明材料,因此需要提單人(使用人)上傳證明文件,因此增加了使用雲存儲的功能。

核心代碼:

    promiseArr.push(new Promise((reslove,reject)=>{
        wx.cloud.uploadFile({
            cloudPath: "groupdata/" + group_name + "/" + app.getNowFormatDate() +suffix,
            filePath:filePath
        }).then(res=>{
            console.log("授權文件上傳成功")          
            })
            reslove()
            }).catch(err=>{
            console.log("授權文件上傳失敗",err)
    })

    因為涉及到不同頁面的數據傳遞,即將表單頁面的group_name作為雲存儲的文件夾用於存儲該客戶在表單中上傳的圖片,因此還需要用到getCurrentPages()來進行頁面間的數據傳遞 

    var pages = getCurrentPages();
    var prePage = pages[pages.length - 2];//pages.length就是該集合長度 -2就是上一個活動的頁面,也即是跳過來的頁面
    var group_name = prePage.data.formData.group_name.value//取上頁data里的group_name數據用於標識授權文件所存儲文件夾的名稱

3、待進一步優化

​ 基於時間關係,本次版本僅對需求進行了簡單實現,作為公司一個可靠的項目,還需要關注”客戶隱私”、“數據安全”,以及更人性化的服務。比如:

(1)提單人確認和認證過程

可靠性:增加驗證碼驗證(防止他人冒名登記),以及公司受理業務有個客戶本人提交憑證。

(2)訂閱消息

受理成功后,可以給客戶進行處理結果的反饋,增強感知。

(3)人工客服

進行在線諮詢等。

四、總結

​ 在本次項目開發中,我深刻體會到了雲開發的“快”,特別是雲數據庫的增刪查改功能非常方便。雲開發提供的種種便利,讓我在有新創意的時候,可以迅速採用小程序雲開發快速實現,省時省力,還能免費使用騰訊雲服務器,推薦大家嘗試!

源碼地址

如果你想要了解更多關於雲開發CloudBase相關的技術故事/技術實戰經驗,請掃碼關注【騰訊云云開發】公眾號~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※試算大陸海運運費!

SpringBoot 源碼解析 (六)—– Spring Boot的核心能力 – 內置Servlet容器源碼分析(Tomcat)

Spring Boot默認使用Tomcat作為嵌入式的Servlet容器,只要引入了spring-boot-start-web依賴,則默認是用Tomcat作為Servlet容器:

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Servlet容器的使用

默認servlet容器

我們看看spring-boot-starter-web這個starter中有什麼

核心就是引入了tomcat和SpringMvc,我們先來看tomcat

Spring Boot默認支持Tomcat,Jetty,和Undertow作為底層容器。如圖:

而Spring Boot默認使用Tomcat,一旦引入spring-boot-starter-web模塊,就默認使用Tomcat容器。

切換servlet容器

那如果我么想切換其他Servlet容器呢,只需如下兩步:

  • 將tomcat依賴移除掉
  • 引入其他Servlet容器依賴

引入jetty:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <!--移除spring-boot-starter-web中的tomcat-->
            <artifactId>spring-boot-starter-tomcat</artifactId>
            <groupId>org.springframework.boot</groupId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <!--引入jetty-->
    <artifactId>spring-boot-starter-jetty</artifactId>
</dependency>

Servlet容器自動配置原理

EmbeddedServletContainerAutoConfiguration

其中
EmbeddedServletContainerAutoConfiguration是嵌入式Servlet容器的自動配置類,該類在
spring-boot-autoconfigure.jar中的web模塊可以找到。

我們可以看到EmbeddedServletContainerAutoConfiguration被配置在spring.factories中,看過我前面文章的朋友應該知道SpringBoot自動配置的原理,這裏將EmbeddedServletContainerAutoConfiguration配置類加入到IOC容器中,接着我們來具體看看這個配置類:

@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
@Configuration
@ConditionalOnWebApplication// 在Web環境下才會起作用
@Import(BeanPostProcessorsRegistrar.class)// 會Import一個內部類BeanPostProcessorsRegistrar
public class EmbeddedServletContainerAutoConfiguration {

    @Configuration
    // Tomcat類和Servlet類必須在classloader中存在 // 文章開頭我們已經導入了web的starter,其中包含tomcat和SpringMvc // 那麼classPath下會存在Tomcat.class和Servlet.class
    @ConditionalOnClass({ Servlet.class, Tomcat.class }) // 當前Spring容器中不存在EmbeddedServletContainerFactory類型的實例
    @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT) public static class EmbeddedTomcat {

        @Bean
        public TomcatEmbeddedServletContainerFactory tomcatEmbeddedServletContainerFactory() {
            // 上述條件註解成立的話就會構造TomcatEmbeddedServletContainerFactory這個EmbeddedServletContainerFactory
            return new TomcatEmbeddedServletContainerFactory();
        }
    }
    
    @Configuration
    @ConditionalOnClass({ Servlet.class, Server.class, Loader.class,
            WebAppContext.class })
    @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT)
    public static class EmbeddedJetty {

        @Bean
        public JettyEmbeddedServletContainerFactory jettyEmbeddedServletContainerFactory() {
            return new JettyEmbeddedServletContainerFactory();
        }

    }
    
    @Configuration
    @ConditionalOnClass({ Servlet.class, Undertow.class, SslClientAuthMode.class })
    @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT)
    public static class EmbeddedUndertow {

        @Bean
        public UndertowEmbeddedServletContainerFactory undertowEmbeddedServletContainerFactory() {
            return new UndertowEmbeddedServletContainerFactory();
        }

    }
    
    //other code...
}

在這個自動配置類中配置了三個容器工廠的Bean,分別是:

  • TomcatEmbeddedServletContainerFactory

  • JettyEmbeddedServletContainerFactory

  • UndertowEmbeddedServletContainerFactory

這裏以大家熟悉的Tomcat為例,首先Spring Boot會判斷當前環境中是否引入了Servlet和Tomcat依賴,並且當前容器中沒有自定義的
EmbeddedServletContainerFactory的情況下,則創建Tomcat容器工廠。其他Servlet容器工廠也是同樣的道理。

EmbeddedServletContainerFactory

  • 嵌入式Servlet容器工廠
public interface EmbeddedServletContainerFactory {

    EmbeddedServletContainer getEmbeddedServletContainer( ServletContextInitializer... initializers);
}

內部只有一個方法,用於獲取嵌入式的Servlet容器。

該工廠接口主要有三個實現類,分別對應三種嵌入式Servlet容器的工廠類,如圖所示:

TomcatEmbeddedServletContainerFactory

以Tomcat容器工廠TomcatEmbeddedServletContainerFactory類為例:

public class TomcatEmbeddedServletContainerFactory extends AbstractEmbeddedServletContainerFactory implements ResourceLoaderAware {
    
    //other code...
    
    @Override
    public EmbeddedServletContainer getEmbeddedServletContainer( ServletContextInitializer... initializers) {
        //創建一個Tomcat
        Tomcat tomcat = new Tomcat(); //配置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);
        
        //包裝tomcat對象,返回一個嵌入式Tomcat容器,內部會啟動該tomcat容器
        return getTomcatEmbeddedServletContainer(tomcat);
    }
}

首先會創建一個Tomcat的對象,並設置一些屬性配置,最後調用getTomcatEmbeddedServletContainer(tomcat)方法,內部會啟動tomcat,我們來看看:

protected TomcatEmbeddedServletContainer getTomcatEmbeddedServletContainer(
    Tomcat tomcat) {
    return new TomcatEmbeddedServletContainer(tomcat, getPort() >= 0);
}

該函數很簡單,就是來創建Tomcat容器並返回。看看TomcatEmbeddedServletContainer類:

public class TomcatEmbeddedServletContainer implements EmbeddedServletContainer {

    public TomcatEmbeddedServletContainer(Tomcat tomcat, boolean autoStart) {
        Assert.notNull(tomcat, "Tomcat Server must not be null");
        this.tomcat = tomcat;
        this.autoStart = autoStart;
        
        //初始化嵌入式Tomcat容器,並啟動Tomcat
 initialize();
    }
    
    private void initialize() throws EmbeddedServletContainerException {
        TomcatEmbeddedServletContainer.logger
                .info("Tomcat initialized with port(s): " + getPortsDescription(false));
        synchronized (this.monitor) {
            try {
                addInstanceIdToEngineName();
                try {
                    final Context context = findContext();
                    context.addLifecycleListener(new LifecycleListener() {

                        @Override
                        public void lifecycleEvent(LifecycleEvent event) {
                            if (context.equals(event.getSource())
                                    && Lifecycle.START_EVENT.equals(event.getType())) {
                                // Remove service connectors so that protocol
                                // binding doesn't happen when the service is
                                // started.
                                removeServiceConnectors();
                            }
                        }

                    });

                    // Start the server to trigger initialization listeners
                    //啟動tomcat
                    this.tomcat.start(); // We can re-throw failure exception directly in the main thread
                    rethrowDeferredStartupExceptions();

                    try {
                        ContextBindings.bindClassLoader(context, getNamingToken(context),
                                getClass().getClassLoader());
                    }
                    catch (NamingException ex) {
                        // Naming is not enabled. Continue
                    }

                    // Unlike Jetty, all Tomcat threads are daemon threads. We create a
                    // blocking non-daemon to stop immediate shutdown
                    startDaemonAwaitThread();
                }
                catch (Exception ex) {
                    containerCounter.decrementAndGet();
                    throw ex;
                }
            }
            catch (Exception ex) {
                stopSilently();
                throw new EmbeddedServletContainerException(
                        "Unable to start embedded Tomcat", ex);
            }
        }
    }
}

到這裏就啟動了嵌入式的Servlet容器,其他容器類似。

Servlet容器啟動原理

SpringBoot啟動過程

我們回顧一下前面講解的SpringBoot啟動過程,也就是run方法:

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);

        // 第二步:根據SpringApplicationRunListeners以及參數來準備環境
        ConfigurableEnvironment environment = prepareEnvironment(listeners,applicationArguments);
        configureIgnoreBeanInfo(environment);

        // 準備Banner打印器 - 就是啟動Spring Boot的時候打印在console上的ASCII藝術字體
        Banner printedBanner = printBanner(environment);

        // 第三步:創建Spring容器
        context = createApplicationContext();

        exceptionReporters = getSpringFactoriesInstances(
                SpringBootExceptionReporter.class,
                new Class[] { ConfigurableApplicationContext.class }, context);

        // 第四步:Spring容器前置處理
        prepareContext(context, environment, listeners, applicationArguments,printedBanner);

        // 第五步:刷新容器
 refreshContext(context);

     // 第六步:Spring容器後置處理
        afterRefresh(context, applicationArguments);

      // 第七步:發出結束執行的事件
        listeners.started(context);
        // 第八步:執行Runners
        this.callRunners(context, applicationArguments);
        stopWatch.stop();
        // 返回容器
        return context;
    }
    catch (Throwable ex) {
        handleRunFailure(context, listeners, exceptionReporters, ex);
        throw new IllegalStateException(ex);
    }
}

我們回顧一下第三步:創建Spring容器

public static final String DEFAULT_CONTEXT_CLASS = "org.springframework.context."
            + "annotation.AnnotationConfigApplicationContext";

public static final String DEFAULT_WEB_CONTEXT_CLASS = "org.springframework."
            + "boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext";

protected ConfigurableApplicationContext createApplicationContext() {
    Class<?> contextClass = this.applicationContextClass;
    if (contextClass == null) {
        try {
            //根據應用環境,創建不同的IOC容器
            contextClass = Class.forName(this.webEnvironment ? DEFAULT_WEB_CONTEXT_CLASS : DEFAULT_CONTEXT_CLASS);
        }
    }
    return (ConfigurableApplicationContext) BeanUtils.instantiate(contextClass);
}

創建IOC容器,如果是web應用,則創建
AnnotationConfigEmbeddedWebApplicationContext的IOC容器;如果不是,則創建AnnotationConfigApplicationContext的IOC容器;很明顯我們創建的容器是AnnotationConfigEmbeddedWebApplicationContext
接着我們來看看
第五步,刷新容器
refreshContext(context);

private void refreshContext(ConfigurableApplicationContext context) {
    refresh(context);
}

protected void refresh(ApplicationContext applicationContext) {
    Assert.isInstanceOf(AbstractApplicationContext.class, applicationContext);
    //調用容器的refresh()方法刷新容器
 ((AbstractApplicationContext) applicationContext).refresh();
}

容器刷新過程

調用抽象父類AbstractApplicationContext的refresh()方法;

AbstractApplicationContext

 1 public void refresh() throws BeansException, IllegalStateException {
 2     synchronized (this.startupShutdownMonitor) {
 3         /**
 4          * 刷新上下文環境
 5          */
 6         prepareRefresh();
 7 
 8         /**
 9          * 初始化BeanFactory,解析XML,相當於之前的XmlBeanFactory的操作,
10          */
11         ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
12 
13         /**
14          * 為上下文準備BeanFactory,即對BeanFactory的各種功能進行填充,如常用的註解@Autowired @Qualifier等
15          * 添加ApplicationContextAwareProcessor處理器
16          * 在依賴注入忽略實現*Aware的接口,如EnvironmentAware、ApplicationEventPublisherAware等
17          * 註冊依賴,如一個bean的屬性中含有ApplicationEventPublisher(beanFactory),則會將beanFactory的實例注入進去
18          */
19         prepareBeanFactory(beanFactory);
20 
21         try {
22             /**
23              * 提供子類覆蓋的額外處理,即子類處理自定義的BeanFactoryPostProcess
24              */
25             postProcessBeanFactory(beanFactory);
26 
27             /**
28              * 激活各種BeanFactory處理器,包括BeanDefinitionRegistryBeanFactoryPostProcessor和普通的BeanFactoryPostProcessor
29              * 執行對應的postProcessBeanDefinitionRegistry方法 和  postProcessBeanFactory方法
30              */
31             invokeBeanFactoryPostProcessors(beanFactory);
32 
33             /**
34              * 註冊攔截Bean創建的Bean處理器,即註冊BeanPostProcessor,不是BeanFactoryPostProcessor,注意兩者的區別
35              * 注意,這裏僅僅是註冊,並不會執行對應的方法,將在bean的實例化時執行對應的方法
36              */
37             registerBeanPostProcessors(beanFactory);
38 
39             /**
40              * 初始化上下文中的資源文件,如國際化文件的處理等
41              */
42             initMessageSource();
43 
44             /**
45              * 初始化上下文事件廣播器,並放入applicatioEventMulticaster,如ApplicationEventPublisher
46              */
47             initApplicationEventMulticaster();
48 
49             /**
50  * 給子類擴展初始化其他Bean 51              */
52  onRefresh(); 53 
54             /**
55              * 在所有bean中查找listener bean,然後註冊到廣播器中
56              */
57             registerListeners();
58 
59             /**
60              * 設置轉換器
61              * 註冊一個默認的屬性值解析器
62              * 凍結所有的bean定義,說明註冊的bean定義將不能被修改或進一步的處理
63              * 初始化剩餘的非惰性的bean,即初始化非延遲加載的bean
64              */
65             finishBeanFactoryInitialization(beanFactory);
66 
67             /**
68              * 通過spring的事件發布機制發布ContextRefreshedEvent事件,以保證對應的監聽器做進一步的處理
69              * 即對那種在spring啟動后需要處理的一些類,這些類實現了ApplicationListener<ContextRefreshedEvent>,
70              * 這裏就是要觸發這些類的執行(執行onApplicationEvent方法)
71              * spring的內置Event有ContextClosedEvent、ContextRefreshedEvent、ContextStartedEvent、ContextStoppedEvent、RequestHandleEvent
72              * 完成初始化,通知生命周期處理器lifeCycleProcessor刷新過程,同時發出ContextRefreshEvent通知其他人
73              */
74             finishRefresh();
75         }
76 
77         finally {
78     
79             resetCommonCaches();
80         }
81     }
82 }

我們看第52行的方法:

protected void onRefresh() throws BeansException {

}

很明顯抽象父類AbstractApplicationContext中的onRefresh是一個空方法,並且使用protected修飾,也就是其子類可以重寫onRefresh方法,那我們看看其子類AnnotationConfigEmbeddedWebApplicationContext中的onRefresh方法是如何重寫的,AnnotationConfigEmbeddedWebApplicationContext又繼承EmbeddedWebApplicationContext,如下:

public class AnnotationConfigEmbeddedWebApplicationContext extends EmbeddedWebApplicationContext {

那我們看看其父類EmbeddedWebApplicationContext 是如何重寫onRefresh方法的:

EmbeddedWebApplicationContext

@Override
protected void onRefresh() {
    super.onRefresh();
    try {
        //核心方法:會獲取嵌入式的Servlet容器工廠,並通過工廠來獲取Servlet容器
 createEmbeddedServletContainer();
    }
    catch (Throwable ex) {
        throw new ApplicationContextException("Unable to start embedded container", ex);
    }
}

在createEmbeddedServletContainer方法中會獲取嵌入式的Servlet容器工廠,並通過工廠來獲取Servlet容器:

 1 private void createEmbeddedServletContainer() {
 2     EmbeddedServletContainer localContainer = this.embeddedServletContainer;
 3     ServletContext localServletContext = getServletContext();
 4     if (localContainer == null && localServletContext == null) {
 5         //先獲取嵌入式Servlet容器工廠
 6         EmbeddedServletContainerFactory containerFactory = getEmbeddedServletContainerFactory();  7         //根據容器工廠來獲取對應的嵌入式Servlet容器
 8         this.embeddedServletContainer = containerFactory.getEmbeddedServletContainer(getSelfInitializer());  9     }
10     else if (localServletContext != null) {
11         try {
12             getSelfInitializer().onStartup(localServletContext);
13         }
14         catch (ServletException ex) {
15             throw new ApplicationContextException("Cannot initialize servlet context",ex);
16         }
17     }
18     initPropertySources();
19 }

關鍵代碼在第6和第8行,先獲取Servlet容器工廠,然後根據容器工廠來獲取對應的嵌入式Servlet容器

獲取Servlet容器工廠

protected EmbeddedServletContainerFactory getEmbeddedServletContainerFactory() {
    //從Spring的IOC容器中獲取EmbeddedServletContainerFactory.class類型的Bean
    String[] beanNames = getBeanFactory().getBeanNamesForType(EmbeddedServletContainerFactory.class); //調用getBean實例化EmbeddedServletContainerFactory.class
    return getBeanFactory().getBean(beanNames[0], EmbeddedServletContainerFactory.class);
}

我們看到先從Spring的IOC容器中獲取EmbeddedServletContainerFactory.class類型的Bean,然後調用getBean實例化EmbeddedServletContainerFactory.class,大家還記得我們第一節Servlet容器自動配置類EmbeddedServletContainerAutoConfiguration中注入Spring容器的對象是什麼嗎?當我們引入spring-boot-starter-web這個啟動器后,會注入TomcatEmbeddedServletContainerFactory這個對象到Spring容器中,所以這裏獲取到的Servlet容器工廠是TomcatEmbeddedServletContainerFactory,然後調用

TomcatEmbeddedServletContainerFactory的getEmbeddedServletContainer方法獲取Servlet容器,並且啟動Tomcat,大家可以看看文章開頭的getEmbeddedServletContainer方法。

大家看一下第8行代碼獲取Servlet容器方法的參數getSelfInitializer(),這是個啥?我們點進去看看

private ServletContextInitializer getSelfInitializer() {
    //創建一個ServletContextInitializer對象,並重寫onStartup方法,很明顯是一個回調方法
    return new ServletContextInitializer() { public void onStartup(ServletContext servletContext) throws ServletException { EmbeddedWebApplicationContext.this.selfInitialize(servletContext); } };
}

創建一個ServletContextInitializer對象,並重寫onStartup方法,很明顯是一個回調方法,這裏給大家留一點疑問:

  • ServletContextInitializer對象創建過程是怎樣的?
  • onStartup是何時調用的?
  • onStartup方法的作用是什麼?

ServletContextInitializer是 Servlet 容器初始化的時候,提供的初始化接口。這裏涉及到Servlet、Filter實例的註冊,我們留在下一篇具體講

 

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

※專營大陸快遞台灣服務

台灣快遞大陸的貨運公司有哪些呢?

技術人如何利用 github+Jekyll ,搭建一個獨立免費的技術博客

上次有人留言說,技術博客是程序員的標配,但據我所知絕大部分技術同學到現在仍然沒有自己的技術博客。原因有很多,有的是懶的寫,有的是怕寫不好,還有的是一直想憋個大招,幻想做到完美再發出來,結果一直胎死腹中。但其實更多程序員是不知道如何去搭建一個博客,其實如今搭建一個個人技術博客非常簡單,其中最簡單搭建方式莫屬使用 GitHub Pages + Jekyll 了,我的博客就是使用這種技術。

GitHub Pages

Github Pages 是面向用戶、組織和項目開放的公共靜態頁面搭建託管服務,站點可以被免費託管在 Github 上,你可以選擇使用 Github Pages 默認提供的域名 github.io 或者自定義域名來發布站點。Github Pages 支持 自動利用 Jekyll 生成站點,也同樣支持純 HTML 文檔,將你的 Jekyll 站點託管在 Github Pages 上是一個不錯的選擇。

使用 Github Pages 搭建博客有以下幾個優點:

  • 完全免費,其中服務器、流量、域名什麼的都管,完全零費用搭建一個技術博客
  • 寫博客就是提交代碼,讓寫作和編程的體驗保持一致
  • 支持綁定自己的域名
  • 提供流行的網頁主題模板

缺點也是有的:

  • 不支持動態內容,博客必須都是靜態網頁,一般會使用 Jekyll 來構建內容。
  • 博客不能被百度索引,因 Github 和百度有過節,所以 Github 就把百度給屏蔽了。
  • 倉庫空間不大於1G
  • 每個月的流量不超過100G
  • 每小時更新不超過 10 次

Github Pages 使用 Jekyll 來構建內容,那麼 Jekyll 是什麼呢?

Jekyll 介紹

Jekyll 是一個簡單的博客形態的靜態站點生產機器。它有一個模版目錄,其中包含原始文本格式的文檔,通過一個轉換器(如 Markdown)和我們的 Liquid 渲染器轉化成一個完整的可發布的靜態網站,你可以發布在任何你喜愛的服務器上。Jekyll 也可以運行在 GitHub Page 上,也就是說,你可以使用 GitHub 的服務來搭建你的項目頁面、博客或者網站,而且是完全免費的。

但如果我們只是在 GitHub 上面使用的話,到不需要知道 Jekyll 的語法,一般 Github 會自動將我們寫的 Markdown 文件轉換成靜態頁面。使用 Jekyll 需要使用 Markdown 語法來寫你的文章,不過 Markdown 語法非常簡單,做為程序員來講基本上兩三天就掌握了,大家也可以參考這篇文章:。

給大家分享一些 Jekyll 主題,這個網站下有很多 主題,大家可以根據自己的愛好去選擇博客主題。

我的個人博客

我的博客經過了三個階段,第一個階段,完全依託於使用 GitHub Pages 來構建;第二個階段,將博客託管於國外的一個服務商;第三個階段,服務器遷移回到國內、域名備案。之前也寫過幾篇關於技術博客的文章,如下:

使用 Github Pages + Jekyll 構建一個技術博客很簡單,基本上步驟就是網上找一個自己喜歡的主題,直接 Fork 到自己的 Github ,然後在刪掉原博客中的內容,在上傳自己的文章即可,以我自己的博客為例。

我的博客最初使用的是,但這個主題已經盡兩年多都沒有更新了。因此後期我在這個主題的基礎上做了一些改動,其中有依賴組件的更新,結合個人情況對個別頁面進行了改版,就成為了現在的樣子:

使用這個主題的原因是,我比較喜歡簡潔大氣的風格,並且此博客主題對代碼展示支持良好。

快速構建一個博客

以我的博客為例,介紹如何最快搭建一個博客。這也是我博客經歷的第一個階段。

1、首先打開地址,點擊 Fork 按鈕將代碼複製一份到自己的倉庫。

過上一分鐘,你的 github 倉庫發現一個 ityouknow.github.io 項目。

2、刪除 CNAME 文件

刪除項目中的 CNAME 文件,CNAME 是定製域名的時候使用的內容,如果不使用定製域名會存在衝突。

3、設置 GitHub Pages

點擊 Settings 按鈕打開設置頁面,頁面往下拉到 GitHub Pages 相關設置,在 Source 下面的複選框中選擇 master branch ,然後點擊旁邊的 Save 按鈕保存設置。

4、重命名項目

點擊 Settings 按鈕打開設置頁面,重命名項目名稱為:github_username.github.io。

github_username 是你的 github 登錄用戶名

5、重命名之後,再次回到 Settings > GitHub Pages 頁面

會發現存在這樣一個地址:

這個時候,你訪問此地址已經可以看到博客的首頁,但是點擊文章的時鏈接跳轉地址不對,這是因為少配置了一個文件。

6、配置 _config.yml

打開項目目錄下的 _config.yml 文件,修改以下配置:

repository: github_username/github_username.github.io
github_url: https://github.com/github_username
url: https://github_username.github.io

這時候在訪問地址: https://github_username.github.io,就會發現博客就已經構建完成了。剩下的事情就是去項目的 _posts 目錄下刪除掉我的文章,然後按照 Jekyll 的語法就寫自己的文章就好了。

github_username 為你的 github id。

自定義域名

雖然通過地址https://github_username.github.io可以正常訪問博客,但是技術小夥伴們肯定有人想使用自己的域名訪問博客,這樣的需求 GitHub Pages 也是支持的。

首先需要設置域名解析,將域名的地址指向自己的 github 博客地址。這裏以萬網的域名配置為例,選擇需要設置的域名點擊解析,在域名解析頁面添加以下兩條記錄

紅框內,需要填寫自己github_username值。

然後重新打開項目的 Settings > GitHub Pages 頁面,Custom domain 下的輸入框輸入剛才設置的域名:xxx.com,點擊保存即可。

重新配置 _config.yml

打開項目目錄下的 _config.yml 文件,修改以下配置:

url: http://www.xxx.com

等待一分鐘之後,瀏覽器訪問地址:www.xxx.com 即可訪問博客。

自定義 DIY 博客

一般同學到上面這一步也就完成了,基本滿足了 80% 技術同學的需求。但還是有一些同學們有更高的追求,比如說使用 Github Pages 雖然簡單方便,但是不能被百度檢索白白流失了大量的流量,還有一個原因有些時候,博客網絡訪問穩定性不是很高。

當時我在國外有幾個虛擬機,本來用作它用,後來在上面安裝了一個 Nginx 作為靜態頁面的服務器。首先我在本機(win10)安裝了 Jekyll 環境,將 Github 上的博客代碼下載下來之後,在本機編譯成靜態的 Html ,然後手動上傳到服務的 Nginx 目錄下;然後將域名指向虛擬機。

非常不建議大家實踐以上這段內容,win10 上面安裝 Jekyll 環境是一段慘痛的經歷。

就這樣很麻煩的步驟我用了幾個月後,實在是受不了了,一方面因為服務器在國外,有時候仍然不穩定(可能因為服務器安裝了代理),另一方面我需要使用一些功能,使用這些功能的前提是網站需要備案,那段時間騰訊雲在做活動,就把博客又從國外搬了回來,順便重新優化了一下流程。

仍然把博客託管在 Github 上面,每次提交完代碼后,在騰訊雲上面執行一個腳本,這個腳本會自動從 Github 拉取最新更新的文件,並自動生產靜態的 Html 文件推送到 Nginx 目錄,域名重新指向這台服務器。可以在 Github 上面設置一些鈎子,當提交代碼的時候自動觸髮腳本,也可以定時觸髮腳本來發布文章。

腳本內容如下:

cd /usr/local/ityouknow.github.io
git pull http://github.com/ityouknow/ityouknow.github.io.git
jekyll build --destination=/usr/share/nginx/html

執行此腳本的前提是安裝好 git\jekyll 環境,這個網上有很多案例,這裏就不再多描述了。
關於 Jekyll 環境搭建和使用可以參考這裏:

自動化部署

這两天看到,我也按照他的步驟實踐了一番,很好用,所以把自動化部署這段寫補上。

配置 Webhook

在開發過程中的 Webhook,是一種通過通常的 callback,去增加或者改變 Web page或者 Web app 行為的方法。這些 Callback 可以由第三方用戶和開發者維持當前,修改,管理,而這些使用者與網站或者應用的原始開發沒有關聯。Webhook 這個詞是由 Jeff Lindsay 在 2007 年在計算機科學 hook 項目第一次提出的。

用大白話講就是,代碼倉庫在收到代碼提交的時候,會自動觸發一個 url 類型的通知,你可以根據這個通知去做一些事情,比如提交了代碼就自動去部署項目。

我們的自動部署博客也是利用了這個機制,Github 自帶了 Webhook 功能,我們直接配置即可使用。

在 Github 倉庫的項目界面,比如本博客項目 https://github.com/ityouknow/ityouknow.github.io,點擊 Setting->Webhooks->Add Webhook,在添加 Webhooks 的配置信息,我的配置信息如下:

Payload URL: http://www.ityouknow.com/deploy
Content type: application/json
Secret: 123456

如下圖:

服務器接受推送

我們需要在博客的服務器上面建立一個服務,來接收 Github 提交代碼后的推送,從而來觸發部署的腳本。 Github 上有一個開源項目可以做這個事情 。

這個開源項目目的很單純,就是負責接收 Github 推送過來的通知,然後執行部署腳本,不過他是使用 NodeJs 來開發的,所以我們先需要在 Centos 上面按照 Node 環境。

centos7 安裝 Node 環境

首先添加源

sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-7-11.noarch.rpm

//yum安裝node.js
yum install -y nodejs

然後在安裝 github-webhook-handler

npm install -g github-webhook-handler     #安裝 github-webhook-handler
#如果沒有安裝成功,可以選擇法2來安裝
npm install -g cnpm --registry=http://r.cnpmjs.org
cnpm install -g github-webhook-handler

安裝成功之後,我們需要添加一個腳本。進入到安裝目錄下:

cd  /usr/lib/node_modules/github-webhook-handler

新建 deploy.js

vi deploy.js

腳本內容如下:

var http = require('http')
var createHandler = require('github-webhook-handler')
var handler = createHandler({ path: '/deploy', secret: 'ityouknow' }) //監聽請求路徑,和Github 配置的密碼
 
function run_cmd(cmd, args, callback) {
  var spawn = require('child_process').spawn;
  var child = spawn(cmd, args);
  var resp = "";
 
  child.stdout.on('data', function(buffer) { resp += buffer.toString(); });
  child.stdout.on('end', function() { callback (resp) });
}
 
http.createServer(function (req, res) {
  handler(req, res, function (err) {
    res.statusCode = 404
    res.end('no such location')
  })
}).listen(3006)//監聽的端口
 
handler.on('error', function (err) {
  console.error('Error:', err.message)
})
 
handler.on('push', function (event) {
  console.log('Received a push event for %s to %s',
    event.payload.repository.name,
    event.payload.ref);
  run_cmd('sh', ['/usr/local/depoly.sh'], function(text){ console.log(text) });//成功后,執行的腳本。
})

腳本的作業就是啟動一個監聽端口來接收請求,接收到請求后執行部署腳本,腳本內容的關鍵點已經標註上註釋。

部署博客的腳本如下:depoly.sh

echo `date`
cd /usr/local/ityouknow.github.io
echo start pull from github 
git pull http://github.com/ityouknow/ityouknow.github.io.git
echo start build..
jekyll build --destination=/usr/share/nginx/html

就是拉取代碼,進行部署而已。

這個腳本的啟動需要藉助 Node 中的一個管理 forever 。forever 可以看做是一個 nodejs 的守護進程,能夠啟動,停止,重啟我們的 app 應用。

不過我們的先安裝 forever,然後需要使用 forever 來啟動 deploy.js 的服務,執行命令如下:

npm install forever -g   #安裝
$ forever start deploy.js          #啟動
$ forever stop deploy.js           #關閉
$ forever start -l forever.log -o out.log -e err.log deploy.js   #輸出日誌和錯誤
/root/node-v8.12.0-linux-x64/lib/node_modules/forever/bin/forever start -l forever.log -o out.log -e err.log deploy.js

如果報錯:
/root/node-v8.12.0-linux-x64/lib/node_modules/forever/bin/forever start -a -l forever.log -o out.log -e err.log deploy.js

同時一般情況下,我們不會對外保留很多端口,所以需要通過博客的地址來轉發,需要在 Nginx 上面添加一個轉發配置,用來監聽的 /deploy 請求轉發到 nodejs 服務上,配置代碼如下:

location = /deploy {
     proxy_pass http://127.0.0.1:3006/deploy;
}

這樣我們整個自動化部署就完了,每次提交代碼時,Github 會發送 Webhook 給地址http://www.ityouknow.com/deploy,Nginx 將 /deploy 地址轉發給 Nodejs 端口為 3306 的服務,最後通過 github-webhook-handler 來執行部署腳本,已到達自動部署的目的。

以後只需要我們提交代碼到 Github ,就會自動觸發博客的自動化部署。

可能會出現的問題

有一些小夥伴反饋在克隆博客的時候出現了一些問題,在這裏集中回復一下。

1、克隆博客后格式丟失

這是很多讀者反饋的第一個問題,因為我的博客 css 和 圖片是放到另外一個域名下的:www.itmind.net ,因此這塊大家克隆過去需要改成本地的。

主要涉及的文件 ityouknow.github.io\_includes 目錄下 head.html 和 footer.html 兩個文件夾,將文件中的 http://www.ityouknow.com/xxx/xxx 改為相對路徑/xxx/xxx即可。

2、留言功能丟失

這裏就需要大家修改一下 _config.yml 中 gitalk 的配置信息。具體如何操作大家可以參考這篇文章 。註冊完之後,需要在 _config.yml 配置以下信息:

gitalk:
    owner: ityouknow
    repo: blog-comments
    clientID: 61bfc53d957e74e78f8f
    clientSecret: 31c61e66cdcc9ada8db2267ee779d0bdafac434c

將這裏改成你註冊好的信息

3、博客

博客現在還缺檢索功能,下一頁和上一頁功能、系列文章優化查看的功能,大家克隆後有完善功能的,也請幫忙留意,共同把這個博客完善的更好。

最後,大家可以在這篇文章下留下你的個人博客地址,方便同行們觀賞、交流、學習。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

台灣海運大陸貨務運送流程

兩岸物流進出口一站式服務

021.掌握Pod-Pod調度策略

一 Pod生命周期管理

1.1 Pod生命周期

Pod在整個生命周期過程中被系統定義了如下各種狀態。

狀態值 描述
Pending API Server已經創建該Pod,且Pod內還有一個或多個容器的鏡像沒有創建,包括正在下載鏡像的過程。
Running Pod內所有容器均已創建,且至少有一個容器處於運行狀態、正在啟動狀態或正在重啟狀態。
Succeeded Pod內所有容器均成功執行退出,且不會重啟。
Failed Pod內所有容器均已退出,但至少有一個容器退出為失敗狀態。
Unknown 由於某種原因無法獲取該Pod狀態,可能由於網絡通信不暢導致。

1.2 Pod重啟策略

Pod重啟策略(RestartPolicy)應用於Pod內的所有容器,並且僅在Pod所處的Node上由kubelet進行判斷和重啟操作。當某個容器異常退出或者健康檢查失敗時,kubelet將根據RestartPolicy的設置來進行相應操作。
Pod的重啟策略包括Always、OnFailure和Never,默認值為Always。

  • Always:當容器失效時,由kubelet自動重啟該容器;
  • OnFailure:當容器終止運行且退出碼不為0時,由kubelet自動重啟該容器;
  • Never:不論容器運行狀態如何,kubelet都不會重啟該容器。

       kubelet重啟失效容器的時間間隔以sync-frequency乘以2n來計算,例如1/2/4/8倍等,最長延時5min,並且在成功重啟后的10min后重置該時間。

Pod的重啟策略與控制方式關聯,當前可用於管理Pod的控制器包括ReplicationController、Job、DaemonSet及直接管理kubelet管理(靜態Pod)。
不同控制器的重啟策略限制如下:

  • RC和DaemonSet:必須設置為Always,需要保證該容器持續運行;
  • Job:OnFailure或Never,確保容器執行完成后不再重啟;
  • kubelet:在Pod失效時重啟,不論將RestartPolicy設置為何值,也不會對Pod進行健康檢查。








Pod包含的容器數 Pod當前的狀態 發生事件 Pod的結果狀態
RestartPolicy=Always RestartPolicy=OnFailure RestartPolicy=Never
包含1個容器 Running 容器成功退出 Running Succeeded Succeeded
包含1個容器 Running 容器失敗退出 Running Running Failed
包括兩個容器 Running 1個容器失敗退出 Running Running Running
包括兩個容器 Running 容器被OOM殺掉 Running Running Failed

1.3 Pod健康檢查

對Pod的健康檢查可以通過兩類探針來檢查:LivenessProbe和ReadinessProbe。
LivenessProbe探針:用於判斷容器是否存活(running狀態),如果LivenessProbe探針探測到容器不健康,則kubelet將殺掉該容器,並根據容器的重啟策略做相應處理。若一個容器不包含LivenessProbe探針,kubelet認為該容器的LivenessProbe探針返回值用於是“Success”。
ReadineeProbe探針:用於判斷容器是否啟動完成(ready狀態)。如果ReadinessProbe探針探測到失敗,則Pod的狀態將被修改。Endpoint Controller將從Service的Endpoint中刪除包含該容器所在Pod的Eenpoint。
kubelet定期執行LivenessProbe探針來診斷容器的健康狀態,通常有以下三種方式:

  • ExecAction:在容器內執行一個命令,若返回碼為0,則表明容器健康。

示例:通過執行”cat /tmp/health”命令判斷一個容器運行是否正常。容器初始化並創建該文件,10s后刪除該文件,15s秒通過命令判斷,由於該文件已被刪除,因此判斷該容器Fail,導致kubelet殺掉該容器並重啟。

  1 [root@uk8s-m-01 study]# vi dapi-liveness.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-liveness-pod
  6   labels:
  7     test: liveness-exec
  8 spec:
  9   containers:
 10     - name: dapi-liveness
 11       image: busybox
 12       args:
 13       - /bin/sh
 14       - -c
 15       - echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600
 16       livenessProbe:
 17         exec:
 18           command:
 19           - cat
 20           - /tmp/health
 21 
 22 [root@uk8s-m-01 study]# kubectl describe pod dapi-liveness-pod

  • TCPSocketAction:通過容器的IP地址和端口號執行TCP檢查,若能建立TCP連接,則表明容器健康。

示例:

  1 [root@uk8s-m-01 study]# vi dapi-tcpsocket.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-healthcheck-tcp
  6 spec:
  7   containers:
  8     - name: nginx
  9       image: nginx
 10       ports:
 11       - containerPort: 80
 12       livenessProbe:
 13         tcpSocket:
 14           port: 80
 15         initialDelaySeconds: 30
 16         timeoutSeconds: 1
 17 
 18 [root@uk8s-m-01 study]# kubectl create -f dapi-tcpsocket.yaml


提示:對於每種探測方式,都需要設置如下兩個參數,其包含的含義如下:

initialDelaySeconds:啟動容器後進行首次健康檢查的等待時間,單位為s;

timeoutSeconds:健康檢查發送請求后等待響應的超時時間,單位為s,當超時發生時,kubelet會認為容器已經無法提供服務,將會重啟該容器。

二 Pod調度

Kubernetes中,Pod通常是容器的載體,一般需要通過Deployment、DaemonSet、RC、Job等對象來完成一組Pod的調度與自動控制功能。

2.1 Depolyment/RC自動調度

Deployment或RC的主要功能之一就是自動部署一個容器應用的多份副本,以及持續監控副本的數量,在集群內始終維持用戶指定的副本數量。
示例:

  1 [root@uk8s-m-01 study]# vi nginx-deployment.yaml
  2 apiVersion: apps/v1beta1
  3 kind: Deployment
  4 metadata:
  5   name: nginx-deployment-01
  6 spec:
  7   replicas: 3
  8   template:
  9     metadata:
 10       labels:
 11         app: nginx
 12     spec:
 13       containers:
 14       - name: nginx
 15         image: nginx:1.7.9
 16         ports:
 17         - containerPort: 80
 18 
 19 [root@uk8s-m-01 study]# kubectl get deployments
 20 NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
 21 nginx-deployment-01   3/3     3            3           30s
 22 [root@uk8s-m-01 study]# kubectl get rs
 23 NAME                             DESIRED   CURRENT   READY   AGE
 24 nginx-deployment-01-5754944d6c   3         3         3       75s
 25 [root@uk8s-m-01 study]# kubectl get pod | grep nginx
 26 nginx-deployment-01-5754944d6c-hmcpg   1/1     Running     0          84s
 27 nginx-deployment-01-5754944d6c-mcj8q   1/1     Running     0          84s
 28 nginx-deployment-01-5754944d6c-p42mh   1/1     Running     0          84s

2.2 NodeSelector定向調度

當需要手動指定將Pod調度到特定Node上,可以通過Node的標籤(Label)和Pod的nodeSelector屬性相匹配。
# kubectl label nodes <node-name> <label-key>=<label-value>
node節點創建對應的label后,可通過在定義Pod的時候加上nodeSelector的設置實現指定的調度。
示例:

  1 [root@uk8s-m-01 study]# kubectl label nodes 172.24.9.14 speed=io
  2 node/172.24.9.14 labeled
  3 [root@uk8s-m-01 study]# vi nginx-master-controller.yaml
  4 kind: ReplicationController
  5 metadata:
  6   name: nginx-master
  7   labels:
  8     name: nginx-master
  9 spec:
 10   replicas: 1
 11   selector:
 12     name: nginx-master
 13   template:
 14     metadata:
 15       labels:
 16         name: nginx-master
 17     spec:
 18       containers:
 19       - name: master
 20         image: nginx:1.7.9
 21         ports:
 22         - containerPort: 80
 23       nodeSelector:
 24         speed: io
 25 
 26 [root@uk8s-m-01 study]# kubectl create -f nginx-master-controller.yaml
 27 [root@uk8s-m-01 study]# kubectl get pods -o wide
 28 NAME                READY   STATUS    RESTARTS    AGE    IP            NODE
 29 nginx-master-7fjgj  1/1     Running   0           82s    172.24.9.71   172.24.9.14


提示:可以將集群中具有不同特點的Node貼上不同的標籤,實現在部署時就可以根據應用的需求設置NodeSelector來進行指定Node範圍的調度。

注意:若在定義Pod中指定了NodeSelector條件,但集群中不存在符合該標籤的Node,即使集群有其他可供使用的Node,Pod也無法被成功調度。

2.3 NodeAffinity親和性調度

親和性調度機制極大的擴展了Pod的調度能力,主要增強功能如下:

  1. 更具表達力,即更精細的力度控制;
  2. 可以使用軟限制、優先採用等限制方式,即調度器在無法滿足優先需求的情況下,會使用其他次條件進行滿足;
  3. 可以依據節點上正在運行的其他Pod的標籤來進行限制,而非節點本身的標籤,從而實現Pod之間的親和或互斥關係。

目前有兩種節點親和力表達:
requiredDuringSchedulingIgnoredDuringExecution:硬規則,必須滿足指定的規則,調度器才可以調度Pod至Node上(類似nodeSelector,語法不同)。
preferredDuringSchedulingIgnoredDuringExecution:軟規則,優先調度至滿足的Node的節點,但不強求,多個優先級規則還可以設置權重值。
IgnoredDuringExecution指:如果一個Pod所在的節點在Pod運行期間標籤發生了變化,不再符合該Pod的節點親和性需求,則系統將忽略Node上Label的變化,該Pod能繼續在該節點運行。
示例:
條件1:只運行在amd64的節點上;盡量運行在ssd節點上。

  1 [root@uk8s-m-01 study]# vi nodeaffinity-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: with-node-affinity
  6 spec:
  7   affinity:
  8     nodeAffinity:
  9       requiredDuringSchedulingIgnoredDuringExecution:
 10         nodeSelectorTerms:
 11         - matchExpressions:
 12           - key: kubernetes.io/arch
 13             operator: In
 14             values:
 15             - amd64
 16       preferredDuringSchedulingIgnoredDuringExecution:
 17       - weight: 1
 18         preference:
 19           matchExpressions:
 20           - key: disk-type
 21             operator: In
 22             values:
 23             - ssd
 24   containers:
 25   - name: with-node-affinity
 26     image: gcr.azk8s.cn/google_containers/pause:2.0


NodeAffinity操作語法;In、NotIn、Exists、DoesNotExist、Gt、Lt。NotIn和DoesNotExist可以實現互斥功能。
NodeAffinity規則設置注意事項:

  • 若同時定義nodeSelector和nodeAffinity,則必須兩個條件都滿足,Pod才能最終運行指定在Node上;;
  • 若nodeAffinity指定多個nodeSelectorTerms,則只需要其中一個能夠匹配成功即可;
  • 若nodeSelectorTerms中有多個matchExpressions,則一個節點必須滿足所有matchExpressions才能運行該Pod。

2.4 PodAffinity親和性調度

PodAffinity根據節點上正在運行的Pod標籤而不是Node標籤來判斷和調度,要求對節點和Pod兩個條件進行匹配。
規則描述為:若在具有標籤X的Node上運行了一個或多個符合條件Y的Pod,則Pod應該(或者不應該)運行在這個Node上。
X通常為Node節點的機架、區域等概念,Pod是屬於某個命名空間,所以條件Y表達的是一個或全部命名空間中的一個Label Selector。
Pod親和性定義與PodSpec的affinity字段下的podAffinity字段里,互斥性定義於同一層次的podAntiAffinity子字段中。
舉例:

  1 [root@uk8s-m-01 study]# vi nginx-flag.yaml	#創建名為pod-flag,帶有兩個標籤的Pod
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: pod-affinity
  6 spec:
  7   affinity:
  8     podAffinity:
  9       requiredDuringSchedulingIgnoredDuringExecution:
 10       - labelSelector:
 11           matchExpressions:
 12           - key: security
 13             operator: In
 14             values:
 15             - S1
 16         topologyKey: kubernetes.io/hostname
 17   containers:
 18   - name: with-pod-affinity
 19     image: gcr.azk8s.cn/google_containers/pause:2.0

  1 [root@uk8s-m-01 study]# vi nginx-affinity-in.yaml	#創建定義標籤security=S1,對應如上Pod “Pod-flag”。
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: pod-affinity
  6 spec:
  7   affinity:
  8     podAffinity:
  9       requiredDuringSchedulingIgnoredDuringExecution:
 10       - labelSelector:
 11           matchExpressions:
 12           - key: security
 13             operator: In
 14             values:
 15             - S1
 16         topologyKey: kubernetes.io/hostname
 17   containers:
 18   - name: with-pod-affinity
 19     image: gcr.azk8s.cn/google_containers/pause:2.0
 20 
 21 [root@uk8s-m-01 study]# kubectl create -f nginx-affinity-in.yaml
 22 [root@uk8s-m-01 study]# kubectl get pods -o wide


提示:由上Pod親和力可知,兩個Pod處於同一個Node上。

  1 [root@uk8s-m-01 study]# vi nginx-affinity-out.yaml	#創建不能與參照目標Pod運行在同一個Node上的調度策略
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: anti-affinity
  6 spec:
  7   affinity:
  8     podAffinity:
  9       requiredDuringSchedulingIgnoredDuringExecution:
 10       - labelSelector:
 11           matchExpressions:
 12           - key: security
 13             operator: In
 14             values:
 15             - S1
 16         topologyKey: failure-domain.beta.kubernetes.io/zone
 17     podAntiAffinity:
 18       requiredDuringSchedulingIgnoredDuringExecution:
 19       - labelSelector:
 20           matchExpressions:
 21           - key: security
 22             operator: In
 23             values:
 24             - nginx
 25         topologyKey: kubernetes.io/hostname
 26   containers:
 27   - name: anti-affinity
 28     image: gcr.azk8s.cn/google_containers/pause:2.0
 29 
 30 [root@uk8s-m-01 study]# kubectl get pods -o wide	#驗證

2.5 Taints和Tolerations(污點和容忍)

Taint:使Node拒絕特定Pod運行;
Toleration:為Pod的屬性,表示Pod能容忍(運行)標註了Taint的Node。
Taint語法:$ kubectl taint node node1 key=value:NoSchedule
解釋:為node1加上一個Taint,該Taint的鍵為key,值為value,Taint的效果為NoSchedule。即除非特定聲明可以容忍此Taint,否則不會調度至node1上。
Toleration示例:

  1 tolerations:
  2 - key: "key"
  3   operator: "Equal"
  4   value: "value"
  5   effect: "NoSchedule"

  1 tolerations:
  2 - key: "key"
  3   operator: "Exists"
  4   effect: "NoSchedule"

注意:Pod的Toleration聲明中的key和effect需要與Taint的設置保持一致,並且滿足以下條件:

  • operator的值是Exists(無須指定value);
  • operator的值是Equal並且value相等;
  • 空的key配合Exists操作符能夠匹配所有的鍵和值;
  • 空的effect匹配所有的effect。


若不指定operator,則默認值為Equal。
taint說明:系統允許在同一個Node上設置多個taint,也可以在Pod上設置多個toleration。Kubernetes調度器處理多個taint和toleration的邏輯順序:首先列出節點中所有的taint,然後忽略pod的toleration能夠匹配的部分,剩下的沒有忽略掉的taint就是對pod的效果。以下是幾種特殊情況:
若剩餘的taint中存在effect=NoSchedule,則調度器不會把該Pod調度到這一節點上;
若剩餘的taint中沒有NoSchedule效果,但有PreferNoSchedule效果,則調度器會嘗試不把這個Pod指派到此節點;
若剩餘taint的效果有NoSchedule,並且這個Pod已經在該節點上運行,則會被驅逐,若沒有在該節點上運行,也不會再被調度到該節點上。
示例:

  1 $ kubectl taint node node1 key=value1:NoSchedule
  2 $ kubectl taint node node1 key=value1:NoExecute
  3 $ kubectl taint node node1 key=value2:NoSchedule
  4 tolerations:
  5 - key: "key1"
  6   operator: "Equal"
  7   value: "value"
  8   effect: "NoSchedule"
  9 tolerations:
 10 - key: "key1"
 11   operator: "Equal"
 12   value: "value1"
 13   effect: "NoExecute"


釋義:此Pod聲明了兩個容忍,且能匹配Node1的taint,但是由於沒有能匹配第三個taint的toleration,因此此Pod依舊不能調度至此Node。若該Pod已經在node1上運行了,那麼在運行時設置了第3個taint,它還能繼續在node1上運行,這是因為Pod可以容忍前兩個taint。
通常,若node加上effect=NoExecute的taint,那麼該Node上正在運行的所有無對應toleration的Pod都會被立刻驅逐,而具有相應toleration的Pod則永遠不會被驅逐。同時,系統可以給具有NoExecute效果的toleration加入一個可選的tolerationSeconds字段,表明Pod可以在taint添加到Node之後還能在此Node運行多久。

  1 tolerations:
  2 - key: "key1"
  3   operator: "Equal"
  4   value: "value"
  5   effect: "NoSchedule"
  6   tolerationSeconds: 3600

釋義:若Pod正在運行,所在節點被加入一個匹配的taint,則這個pod會持續在該節點運行3600s后被驅逐。若在此期限內,taint被移除,則不會觸發驅逐事件。
Taints和Tolerations常用場景:

  • 獨佔節點:

給特定的節點運行特定應用。
$ kubectl taint nodes 【nodename】 dedicated=groupName:NoSchedule
同時在Pod中設置對應的toleration配合,帶有合適toleration的Pod允許同時使用其他節點一樣使用有taint的節點。

  • 具有特殊硬件設備的節點

集群中部分特殊硬件(如安裝了GPU),則可以把不需要佔用GPU的Pod禁止在此Node上調度。

  1 $ kubectl taint nodes 【nodename】 special=true:NoSchedule
  2 $ kubectl taint nodes 【nodename】 special=true:PreferNoSchedule

  • 定義Pod驅逐行為

NoExecute的taint對節點上正在運行的Pod有以下影響:

    1. 沒有設置toleration的pod會被立刻驅逐;
    2. 配置了對應toleration的pod,若沒有為tolerationSeconds賦值,則會一直保留在此節點中;
    3. 配置了對應toleration的pod,且為tolerationSeconds賦值,則在指定時間后驅逐。

2.6 DaemonSet

DaemonSet是在每個Node上調度一個Pod的資源對象,用於管理集群中每個Node僅運行一份Pod的副本實例。
常見場景:
在每個Node上運行一個GlusterFS存儲的Daemon進程;
在每個Node上運行一個日誌採集程序,例如Fluentd;
在每個Node上運行一個性能監控程序,採集該Node的運行性能數據,例如Prometheus。
示例:

  1 [root@uk8s-m-01 study]# vi fluentd-ds.yaml
  2 apiVersion: extensions/v1beta1
  3 kind: DaemonSet
  4 metadata:
  5   name: fluentd-cloud-logging
  6   namespace: kube-system
  7   labels:
  8     k8s-app: fluentd-cloud-logging
  9 spec:
 10   template:
 11     metadata:
 12       namespace: kube-system
 13       labels:
 14         k8s-app: fluentd-cloud-logging
 15     spec:
 16       containers:
 17       - name: fluentd-cloud-logging
 18         image: gcr.azk8s.cn/google_containers/fluentd-elasticsearch:1.17
 19         resources:
 20           limits:
 21             cpu: 100m
 22             memory: 200Mi
 23         env:
 24         - name: FLUENTD_ARGS
 25           value: -q
 26         volumeMounts:
 27         - name: varlog
 28           mountPath: /var/log
 29           readOnly: false
 30         - name: containers
 31           mountPath: /var/lib/docker/containers
 32           readOnly: false
 33       volumes:
 34       - name: containers
 35         hostPath:
 36           path: /var/lib/docker/containers
 37       - name: varlog
 38         hostPath:
 39           path: /var/log

2.7 Job批處理調度

通過Kubernetes Job資源對象可以定義並啟動一個批處理任務,批處理任務通過并行(或者串行)啟動多個計算進程去處理一批工作項。根據批處理方式不同,批處理任務可以分為如下幾種模式:
Job Template Expansion模式:一個Job對象對應一個待處理的Work item,有幾個work item就產生幾個獨立的Job。通常適合Work item數量少、每個Work item要處理的數據量比較大的場景。
Queue with Pod Per Work Item模式:採用一個任務隊列存放Work item,一個Job對象作為消費者去完成這些Work item。此模式下,Job會啟動N個Pod,每個Pod都對應一個Work item。
Queue with Variable Pod Count模式:採用一個任務隊列存放Work item,一個Job對象作為消費者去完成這些Work item,但此模式下Job啟動的數量是可變的。
Kubernetes將Job氛圍以下三類:

  • Non-parallel Jobs

通常一個Job只啟動一個Pod,除非Pod異常,才會重啟該Pod,一旦此Pod正常結束,Job將結束。

  • Parallel Jobs with a fixed completion count

并行Job會啟動多個Pod,此時需要設定Job的.spec.completions參數為一個正數,當正常結束的Pod數量達至此參數設定的值后,Job結束。同時.spec.parallelism參數用來控制并行度,即同時啟動幾個Job來處理Work Item。

  • Parallel Jobs with a work queue

任務隊列方式的并行Job需要一個獨立的Queue,Work Item都在一個Queue中存放,不能設置Job的.spec.completions參數,此時Job具有以下特性:

    1. 每個Pod都能獨立判斷和決定是否還有任務項需要處理;
    2. 如果某個Pod正常結束,則Job不會再啟動新的Pod;
    3. 如果一個Pod成功結束,則此時應該不存在其他Pod還在工作的情況。它們應該都處於即將結束、退出的狀態;
    4. 如果所有Pod都結束了,且至少有一個Pod成功結束,則整個Jod成功結束。

2.8 Cronjob定時任務

表達式:Minutes Hours DayofMonth Month DayofWeek Year
Minutes:可出現”,”、”_”、”*”、”/”,有效範圍為0~59的整數;
Hours:出現”,”、”_”、”*”、”/”,有效範圍為0~23的整數;
DayofMonth:出現”,”、”_”、”*”、”/”、”L”、”W”、”C”,有效範圍為0~31的整數;
Month:可出現”,”、”_”、”*”、”/”,有效範圍為1~12的整數或JAN~DEC;
DayofWeek:出現”,”、”_”、”*”、”/”、”L”、”W”、”C”、”#”,有效範圍為1~7的整數或SUN~SAT;
*: 表示匹配該域的任意值, 假如在Minutes域使用“*”, 則表示每分鐘都會觸發事件。
/: 表示從起始時間開始觸發, 然後每隔固定時間觸發一次,例如在Minutes域設置為5/20, 則意味着第1次觸發在第5min時, 接下來每20min觸發一次, 將在第25min、 第45min等時刻分別觸發。
示例:*/1 * * * * #每隔1min執行一次任務

  1 [root@uk8s-m-01 study]# vi cron.yaml
  2 apiVersion: batch/v2alpha1
  3 kind: CronJob
  4 metadata:
  5   name: hello
  6 spec:
  7   schedule: "*/1 * * * *"
  8   jobTemplate:
  9     spec:
 10       template:
 11         spec:
 12           containers:
 13           - name: hello
 14             image: busybox
 15             args:
 16             - /bin/sh
 17             - -c
 18             - date; echo Hello from the Kubernetes cluster
 19           restartPolicy: OnFailure

  1 [root@master study]# kubectl create -f cron.yaml
  2 [root@master study]# kubectl get cronjob hello
  3 NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
  4 hello   */1 * * * *   False     0        <none>          29s
  5 [root@master study]# kubectl get pods
  6 NAME                     READY   STATUS      RESTARTS   AGE
  7 hello-1573378080-zvvm5   0/1     Completed   0          68s
  8 hello-1573378140-9pmwz   0/1     Completed   0          8s
  9 [root@node1 ~]# docker logs c7					#node節點查看日誌
 10 Sun Nov 10 09:31:13 UTC 2019
 11 Hello from the Kubernetes cluster
 12 [root@master study]# kubectl get jobs				#查看任務
 13 NAME               COMPLETIONS   DURATION   AGE
 14 hello-1573378500   1/1           8s         3m7s
 15 hello-1573378560   1/1           4s         2m7s
 16 hello-1573378620   1/1           6s         67s
 17 hello-1573378680   1/1           4s         7s
 18 [root@master study]# kubectl get pods -o wide | grep hello-1573378680	#以job任務查看對應的pod
 19 [root@master study]# kubectl delete cj hello			#刪除cronjob

2.9 初始化容器

在很多應用場景中, 應用在啟動之前都需要進行如下初始化操作。

  • 等待其他關聯組件正確運行( 例如數據庫或某個後台服務) 。
  • 基於環境變量或配置模板生成配置文件。
  • 從遠程數據庫獲取本地所需配置, 或者將自身註冊到某个中央數據庫中。
  • 下載相關依賴包, 或者對系統進行一些預配置操作。

示例:以Nginx應用為例, 在啟動Nginx之前, 通過初始化容器busybox為Nginx創建一個index.html主頁文件。同時init container和Nginx設置了一個共享的Volume, 以供Nginx訪問init container設置的index.html文件。

  1 [root@uk8s-m-01 study]# vi nginx-init-containers.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: nginx
  6   annotations:
  7 spec:
  8   initContainers:
  9   - name: install
 10     image: busybox
 11     command:
 12     - wget
 13     - "-O"
 14     - "/work-dir/index.html"
 15     - http://kubernetes.io
 16     volumeMounts:
 17     - name: workdir
 18       mountPath: "/work-dir"
 19   containers:
 20   - name: nginx
 21     image: nginx:1.7.9
 22     ports:
 23     - containerPort: 80
 24     volumeMounts:
 25     - name: workdir
 26       mountPath: /usr/share/nginx/html
 27   dnsPolicy: Default
 28   volumes:
 29   - name: workdir
 30     emptyDir: {}

  1 [root@uk8s-m-01 study]# kubectl get pods
  2 NAME    READY   STATUS     RESTARTS   AGE
  3 nginx   0/1     Init:0/1   0          2s
  4 [root@uk8s-m-01 study]# kubectl get pods
  5 NAME    READY   STATUS    RESTARTS   AGE
  6 nginx   1/1     Running   0          13s
  7 [root@uk8s-m-01 study]# kubectl describe pod nginx		#查看事件可知會先創建init容器,名為install


init容器與應用容器的區別如下。
(1) init container的運行方式與應用容器不同, 它們必須先於應用容器執行完成, 當設置了多個init container時, 將按順序逐個運行, 並且只有前一個init container運行成功后才能運行后一個init container。 當所有init container都成功運行后, Kubernetes才會初始化Pod的各種信息, 並開始創建和運行應用容器。
(2) 在init container的定義中也可以設置資源限制、 Volume的使用和安全策略, 等等。 但資源限制的設置與應用容器略有不同。

  • 如果多個init container都定義了資源請求/資源限制, 則取最大的值作為所有init container的資源請求值/資源限制值。
  • Pod的有效(effective) 資源請求值/資源限制值取以下二者中的較大值。
    • 所有應用容器的資源請求值/資源限制值之和。
    • init container的有效資源請求值/資源限制值。
  • 調度算法將基於Pod的有效資源請求值/資源限制值進行計算,即init container可以為初始化操作預留系統資源, 即使後續應用容器無須使用這些資源。
  • Pod的有效QoS等級適用於init container和應用容器。
  • 資源配額和限制將根據Pod的有效資源請求值/資源限制值計算生效。
  • Pod級別的cgroup將基於Pod的有效資源請求/限制, 與調度機制

一致。
(3) init container不能設置readinessProbe探針, 因為必須在它們成功運行后才能繼續運行在Pod中定義的普通容器。在Pod重新啟動時, init container將會重新運行, 常見的Pod重啟場景如下。

  • init container的鏡像被更新時, init container將會重新運行, 導致Pod重啟。 僅更新應用容器的鏡像只會使得應用容器被重啟。
  • Pod的infrastructure容器更新時, Pod將會重啟。
  • 若Pod中的所有應用容器都終止了, 並且RestartPolicy=Always, 則Pod會重啟。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

小三通海運與一般國際貿易有何不同?

小三通快遞通關作業有哪些?

Spring Boot2 系列教程(二十四)Spring Boot 整合 Jpa

Spring Boot 中的數據持久化方案前面給大夥介紹了兩種了,一個是 JdbcTemplate,還有一個 MyBatis,JdbcTemplate 配置簡單,使用也簡單,但是功能也非常有限,MyBatis 則比較靈活,功能也很強大,據我所知,公司採用 MyBatis 做數據持久化的相當多,但是 MyBatis 並不是唯一的解決方案,除了 MyBatis 之外,還有另外一個東西,那就是 Jpa,松哥也有一些朋友在公司里使用 Jpa 來做數據持久化,本文就和大夥來說說 Jpa 如何實現數據持久化。

Jpa 介紹

首先需要向大夥介紹一下 Jpa,Jpa(Java Persistence API)Java 持久化 API,它是一套 ORM 規範,而不是具體的實現,Jpa 的江湖地位類似於 JDBC,只提供規範,所有的數據庫廠商提供實現(即具體的數據庫驅動),Java 領域,小夥伴們熟知的 ORM 框架可能主要是 Hibernate,實際上,除了 Hibernate 之外,還有很多其他的 ORM 框架,例如:

  • Batoo JPA
  • DataNucleus (formerly JPOX)
  • EclipseLink (formerly Oracle TopLink)
  • IBM, for WebSphere Application Server
  • JBoss with Hibernate
  • Kundera
  • ObjectDB
  • OpenJPA
  • OrientDB from Orient Technologies
  • Versant Corporation JPA (not relational, object database)

Hibernate 只是 ORM 框架的一種,上面列出來的 ORM 框架都是支持 JPA2.0 規範的 ORM 框架。既然它是一個規範,不是具體的實現,那麼必然就不能直接使用(類似於 JDBC 不能直接使用,必須要加了驅動才能用),我們使用的是具體的實現,在這裏我們採用的實現實際上還是 Hibernate。

Spring Boot 中使用的 Jpa 實際上是 Spring Data Jpa,Spring Data 是 Spring 家族的一個子項目,用於簡化 SQL、NoSQL 的訪問,在 Spring Data 中,只要你的方法名稱符合規範,它就知道你想幹嘛,不需要自己再去寫 SQL。

關於 Spring Data Jpa 的具體情況,大家可以參考

工程創建

創建 Spring Boot 工程,添加 Web、Jpa 以及 MySQL 驅動依賴,如下:

工程創建好之後,添加 Druid 依賴,完整的依賴如下:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>druid-spring-boot-starter</artifactId>
    <version>1.1.10</version>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.28</version>
    <scope>runtime</scope>
</dependency>

如此,工程就算創建成功了。

基本配置

工程創建完成后,只需要在 application.properties 中進行數據庫基本信息配置以及 Jpa 基本配置,如下:

# 數據庫的基本配置
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.url=jdbc:mysql:///test01?useUnicode=true&characterEncoding=UTF-8
spring.datasource.type=com.alibaba.druid.pool.DruidDataSource

# JPA配置
spring.jpa.database=mysql
# 在控制台打印SQL
spring.jpa.show-sql=true
# 數據庫平台
spring.jpa.database-platform=mysql
# 每次啟動項目時,數據庫初始化策略
spring.jpa.hibernate.ddl-auto=update
# 指定默認的存儲引擎為InnoDB
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL57Dialect

注意這裏和 JdbcTemplate 以及 MyBatis 比起來,多了 Jpa 配置,Jpa 配置含義我都註釋在代碼中了,這裏不再贅述,需要強調的是,最後一行配置,默認情況下,自動創建表的時候會使用 MyISAM 做表的引擎,如果配置了數據庫方言為 MySQL57Dialect,則使用 InnoDB 做表的引擎。

好了,配置完成后,我們的 Jpa 差不多就可以開始用了。

基本用法

ORM(Object Relational Mapping) 框架表示對象關係映射,使用 ORM 框架我們不必再去創建表,框架會自動根據當前項目中的實體類創建相應的數據表。因此,我這裏首先創建一個 User 對象,如下:

@Entity(name = "t_user")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;
    @Column(name = "name")
    private String username;
    private String address;
    //省略getter/setter
}

首先 @Entity 註解表示這是一個實體類,那麼在項目啟動時會自動針對該類生成一張表,默認的表名為類名,@Entity 註解的 name 屬性表示自定義生成的表名。@Id 註解表示這個字段是一個 id,@GeneratedValue 註解表示主鍵的自增長策略,對於類中的其他屬性,默認都會根據屬性名在表中生成相應的字段,字段名和屬性名相同,如果開發者想要對字段進行定製,可以使用 @Column 註解,去配置字段的名稱,長度,是否為空等等。

做完這一切之後,啟動 Spring Boot 項目,就會發現數據庫中多了一個名為 t_user 的表了。

針對該表的操作,則需要我們提供一個 Repository,如下:

public interface UserDao extends JpaRepository<User,Integer> {
    List<User> getUserByAddressEqualsAndIdLessThanEqual(String address, Integer id);
    @Query(value = "select * from t_user where id=(select max(id) from t_user)",nativeQuery = true)
    User maxIdUser();
}

這裏,自定義 UserDao 接口繼承自 JpaRepository,JpaRepository 提供了一些基本的數據操作方法,例如保存,更新,刪除,分頁查詢等,開發者也可以在接口中自己聲明相關的方法,只需要方法名稱符合規範即可,在 Spring Data 中,只要按照既定的規範命名方法,Spring Data Jpa 就知道你想幹嘛,這樣就不用寫 SQL 了,那麼規範是什麼呢?參考下圖:

當然,這種方法命名主要是針對查詢,但是一些特殊需求,可能並不能通過這種方式解決,例如想要查詢 id 最大的用戶,這時就需要開發者自定義查詢 SQL 了。

如上代碼所示,自定義查詢 SQL,使用 @Query 註解,在註解中寫自己的 SQL,默認使用的查詢語言不是 SQL,而是 JPQL,這是一種數據庫平台無關的面向對象的查詢語言,有點定位類似於 Hibernate 中的 HQL,在 @Query 註解中設置 nativeQuery 屬性為 true 則表示使用原生查詢,即大夥所熟悉的 SQL。上面代碼中的只是一個很簡單的例子,還有其他一些點,例如如果這個方法中的 SQL 涉及到數據操作,則需要使用 @Modifying 註解。

好了,定義完 Dao 之後,接下來就可以將 UserDao 注入到 Controller 中進行測試了(這裏為了省事,就沒有提供 Service 了,直接將 UserDao 注入到 Controller 中)。

@RestController
public class UserController {
    @Autowired
    UserDao userDao;
    @PostMapping("/")
    public void addUser() {
        User user = new User();
        user.setId(1);
        user.setUsername("張三");
        user.setAddress("深圳");
        userDao.save(user);
    }
    @DeleteMapping("/")
    public void deleteById() {
        userDao.deleteById(1);
    }
    @PutMapping("/")
    public void updateUser() {
        User user = userDao.getOne(1);
        user.setUsername("李四");
        userDao.flush();
    }
    @GetMapping("/test1")
    public void test1() {
        List<User> all = userDao.findAll();
        System.out.println(all);
    }
    @GetMapping("/test2")
    public void test2() {
        List<User> list = userDao.getUserByAddressEqualsAndIdLessThanEqual("廣州", 2);
        System.out.println(list);
    }
    @GetMapping("/test3")
    public void test3() {
        User user = userDao.maxIdUser();
        System.out.println(user);
    }
}

如此之後,即可查詢到需要的數據。

好了,本文的重點是 Spring Boot 和 Jpa 的整合,這個話題就先說到這裏。

多說兩句

在和 Spring 框架整合時,如果用到 ORM 框架,大部分人可能都是首選 Hibernate,實際上,在和 Spring+SpringMVC 整合時,也可以選擇 Spring Data Jpa 做數據持久化方案,用法和本文所述基本是一樣的,Spring Boot 只是將 Spring Data Jpa 的配置簡化了,因此,很多初學者對 Spring Data Jpa 覺得很神奇,但是又覺得無從下手,其實,此時可以回到 Spring 框架,先去學習 Jpa,再去學習 Spring Data Jpa,這是給初學者的一點建議。

相關案例已經上傳到 GitHub,歡迎小夥伴們們下載:

掃碼關注松哥,公眾號後台回復 2TB,獲取松哥獨家 超2TB 學習資源

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享

小三通物流營運型態?

※快速運回,大陸空運推薦?

webpack優化之玩轉代碼分割和公共代碼提取

前言

開發多頁應用的時候,如果不對webpack打包進行優化,當某個模塊被多個入口模塊引用時,它就會被打包多次(在最終打包出來的某幾個文件里,它們都會有一份相同的代碼)。當項目業務越來越複雜,打包出來的代碼會非常冗餘,文件體積會非常龐大。大體積文件會增加編譯時間,影響開發效率;如果直接上線,還會拉長請求和加載時長,影響網站體驗。作為一個追求極致體驗的攻城獅,是不能忍的。所以在多頁應用中優化打包尤為必要。那麼如何優化webpack打包呢?

一、概念

在一切開始前,有必要先理清一下這三個概念:

  • module: 模塊,在webpack眼裡,任何可以被導入導出的文件都是一個模塊。
  • chunk: chunk是webpack拆分出來的:
    • 每個入口文件都是一個chunk
    • 通過 import、require 引入的代碼也是
    • 通過 splitChunks 拆分出來的代碼也是
  • bundle: webpack打包出來的文件,也可以理解為就是對chunk編譯壓縮打包等處理后的產出。

二、問題分析

首先,簡單分析下,我們剛才提到的打包問題:

  • 核心問題就是:多頁應用打包後代碼冗餘,文件體積大。
  • 究其原因就是:相同模塊在不同入口之間沒有得到復用,bundle之間比較獨立。

弄明白了問題的原因,那麼大致的解決思路也就出來了:

  • 我們在打包的時候,應該把不同入口之間,共同引用的模塊,抽離出來,放到一個公共模塊中。這樣不管這個模塊被多少個入口引用,都只會在最終打包結果中出現一次。——解決代碼冗餘。
  • 另外,當我們把這些共同引用的模塊都堆在一個模塊中,這個文件可能異常巨大,也是不利於網絡請求和頁面加載的。所以我們需要把這個公共模塊再按照一定規則進一步拆分成幾個模塊文件。——減小文件體積。
  • 至於如何拆分,方式因人而異,因項目而異。我個人的拆分原則是:
    • 業務代碼和第三方庫分離打包,實現代碼分割;
    • 業務代碼中的公共業務模塊提取打包到一個模塊;
    • 第三方庫最好也不要全部打包到一個文件中,因為第三方庫加起來通常會很大,我會把一些特別大的庫分別獨立打包,剩下的加起來如果還很大,就把它按照一定大小切割成若干模塊。

optimization.splitChunks

webpack提供了一個非常好的內置插件幫我們實現這一需求:CommonsChunkPlugin。不過在 webpack4 中CommonsChunkPlugin被刪除,取而代之的是optimization.splitChunks, 所幸的是optimization.splitChunks更強大!

三、 實現

通過一個多頁應用的小demo,我們一步一步來實現上述思路的配置。

demo目錄結構:

|--public/
|   |--a.html
|   |--index.html
|--src/
|   |--a.js
|   |--b.js
|   |--c.js
|   |--index.js
|--package.json
|--webpack.config.js

代碼邏輯很簡單,index模塊中引用了 ab 2個模塊,a 模塊中引用了 c 模塊和 jquery庫,b 模塊中也引用了 c 模塊和 jquery 庫,c 是一個獨立的模塊沒有其他依賴。

index.js代碼如下:

//index.js
import a from './a.js';
import b from './b.js';
function fn() {
    console.log('index-------');
}
fn();

a.js代碼如下:

//a.js
require('./c.js');
const $ = require('jquery')
function fn() {
    console.log('a-------');
}
module.exports = fn();

b.js代碼如下:

//b.js
require('./c.js');
const $ = require('jquery')
function fn() {
    console.log('b-------');
}
module.exports = fn();

c.js代碼如下:

//c.js
function fn() {
    console.log('c-------');
}
module.exports = fn();

1. 基本配置

webpack先不做優化,只做基本配置,看看效果。項目配置了2個入口,搭配html-webpack-plugin實現多頁打包:

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
    entry: {
        index: './src/index.js',
        a: './src/a.js'
    },
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: '[name].js'
    },
    plugins: [
        new HtmlWebpackPlugin({
            template: './public/index.html',
            filename: 'index.html'
        }),
        new HtmlWebpackPlugin({
            template: './public/a.html',
            filename: 'a.html'
        })
    ]
}

在開發模式下運行webpack:

可以看到,打包出兩個html和兩個體積很大的(300多K)的文件a.js,index.js

進入dist目錄檢查js文件:

  • a.js里包含c模塊代碼和jquery代碼
  • index.js里包含a模塊、b模塊、c模塊和jquery代碼

看,同樣的代碼cjquery被打包了2遍。

2. 初步添加splitChunks優化配置

首先解決相同代碼打包2次的問題,我們需要讓webpack把cjquery提取出來打包為公共模塊。

在webpack配置文件添加splitChunks:

//webpack.config.js

optimization: {
    splitChunks: {
        cacheGroups: {
            default: {
                name: 'common',
                chunks: 'initial'
            }
        }
    }
}

– cacheGroups

  • cacheGroupssplitChunks配置的核心,對代碼的拆分規則全在cacheGroups緩存組裡配置。
  • 緩存組的每一個屬性都是一個配置規則,我這裏給他的default屬性進行了配置,屬性名可以不叫default可以自己定。
  • 屬性的值是一個對象,裏面放的我們對一個代碼拆分規則的描述。

– name

  • name:提取出來的公共模塊將會以這個來命名,可以不配置,如果不配置,就會生成默認的文件名,大致格式是index~a.js這樣的。

– chunks

  • chunks:指定哪些類型的chunk參与拆分,值可以是string可以是函數。如果是string,可以是這個三個值之一:all, async, initialall 代表所有模塊,async代表只管異步加載的, initial代表初始化時就能獲取的模塊。如果是函數,則可以根據chunk參數的name等屬性進行更細緻的篩選。

再次打包:

可以看到a.js,index.js從300多K減少到6點幾K。同時增加了一個common.js文件,並且兩個打包入口都自動添加了common.js這個公共模塊:

進入dist目錄,依次查看這3個js文件:

  • a.js里不包含任何模塊的代碼了,只有webpack生成的默認代碼。
  • index.js里同樣不包含任何模塊的代碼了,只有webpack生成的默認代碼。
  • common.js里有a,b,c,index,jquery代碼。

發現,提是提取了,但是似乎跟我們預料的不太一樣,所有的模塊都跑到common.js里去了。

這是因為我們沒有告訴webpack(splitChunks)什麼樣的代碼為公共代碼,splitChunks默認任何模塊都會被提取。

– minChunks

splitChunks是自帶默認配置的,而緩存組默認會繼承這些配置,其中有個minChunks屬性:

  • 它控制的是每個模塊什麼時候被抽離出去:當模塊被不同entry引用的次數大於等於這個配置值時,才會被抽離出去。
  • 它的默認值是1。也就是任何模塊都會被抽離出去(入口模塊其實也會被webpack引入一次)。

我們上面沒有配置minChunks,只配置了namechunk兩個屬性,所以minChunks的默認值 1 生效。也難怪所有的模塊都被抽離到common.js中了。

優化一下,在緩存組裡配置minChunks覆蓋默認值:

//webpack.config.js

optimization: {
    splitChunks: {
        cacheGroups: {
            default: {
                name: 'common',
                chunks: 'initial',
                minChunks: 2  //模塊被引用2次以上的才抽離
            }
        }
    }
}

然後運行webpack

可以看到有2個文件的大小發生了變化:common.js由314K減小到311K,index.js由6.22K增大到7.56K。

進入dist目錄查看:

  • a.js里依然不包含任何模塊的代碼(正常,因為a作為模塊被index引入了一次,又作為入口被webpack引入了一次,所以a是有2次引用的)。
  • index.js里出現了bindex模塊的代碼了。
  • common.js里只剩a,c,和jquery模塊的代碼。

現在我們把共同引用的模塊a, c, jquery,從aindex這兩個入口模塊里抽取到common.js里了。有點符合我們的預期了。

3. 配置多個拆分規則

3.1 實現代碼分離,拆分第三方庫

接下來,我希望公共模塊common.js中,業務代碼和第三方模塊jquery能夠剝離開來。

我們需要再添加一個拆分規則。

//webpack.config.js

optimization: {
    splitChunks: {
        minSize: 30,  //提取出的chunk的最小大小
        cacheGroups: {
            default: {
                name: 'common',
                chunks: 'initial',
                minChunks: 2,  //模塊被引用2次以上的才抽離
                priority: -20
            },
            vendors: {  //拆分第三方庫(通過npm|yarn安裝的庫)
                test: /[\\/]node_modules[\\/]/,
                name: 'vendor',
                chunks: 'initial',
                priority: -10
            }
        }
    }
}

我給cacheGroups添加了一個vendors屬性(屬性名可以自己取,只要不跟緩存組下其他定義過的屬性同名就行,否則後面的拆分規則會把前面的配置覆蓋掉)。

– minSize

minSize設置的是生成文件的最小大小,單位是字節。如果一個模塊符合之前所說的拆分規則,但是如果提取出來最後生成文件大小比minSize要小,那它仍然不會被提取出來。這個屬性可以在每個緩存組屬性中設置,也可以在splitChunks屬性中設置,這樣在每個緩存組都會繼承這個配置。這裏由於我的demo中文件非常小,為了演示效果,我把minSize設置為30字節,好讓公共模塊可以被提取出來,正常項目中不用設這麼小。

– priority

priority屬性的值為数字,可以為負數。作用是當緩存組中設置有多個拆分規則,而某個模塊同時符合好幾個規則的時候,則需要通過優先級屬性priority來決定使用哪個拆分規則。優先級高者執行。我這裏給業務代碼組設置的優先級為-20,給第三方庫組設置的優先級為-10,這樣當一個第三方庫被引用超過2次的時候,就不會打包到業務模塊里了。

– test

test屬性用於進一步控制緩存組選擇的模塊,與chunks屬性的作用有一點像,但是維度不一樣。test的值可以是一個正則表達式,也可以是一個函數。它可以匹配模塊的絕對資源路徑或chunk名稱,匹配chunk名稱時,將選擇chunk中的所有模塊。我這裏用了一個正則/[\\/]node_modules[\\/]/來匹配第三方模塊的絕對路徑,因為通過npm或者yarn安裝的模塊,都會存放在node_modules目錄下。

運行一下webpack:

可以看到新產生了一個叫vendor.js的文件(name屬性的值),同時common.js文件體積由原來的311k減少到了861bytes!

進入dist目錄,檢查js文件:

  • a.js里不包含任何模塊代碼。
  • common.js只包含ac模塊的代碼。
  • index.js只包含bindex模塊的代碼。
  • vendor.js只包含jquery模塊的代碼。

現在,我們在上一步的基礎上,成功從common.js里把第三方庫jquery抽離出來放到了vendor.js里。

3.2 拆分指定文件

如果我們還想把項目中的某一些文件單獨拎出來打包(比如工程本地開發的組件庫),可以繼續添加拆分規則。比如我的src下有個locallib.js文件要單獨打包,假設a.js中引入了它。

//a.js
require('./c.js');
require('./locallib.js');  //引入自己本地的庫
const $ = require('jquery')
function fn() {
    console.log('a-------');
}
module.exports = fn();

可以這麼配置:

//webpack.config.js

optimization: {
    splitChunks: {
        minSize: 30,  //提取出的chunk的最小大小
        cacheGroups: {
            default: {
                name: 'common',
                chunks: 'initial',
                minChunks: 2,  //模塊被引用2次以上的才抽離
                priority: -20
            },
            vendors: {  //拆分第三方庫(通過npm|yarn安裝的庫)
                test: /[\\/]node_modules[\\/]/,
                name: 'vendor',
                chunks: 'initial',
                priority: -10
            },
            locallib: {  //拆分指定文件
                test: /(src\/locallib\.js)$/,
                name: 'locallib',
                chunks: 'initial',
                priority: -9
            }
        }
    }
}

我在緩存組下又新增了一個拆分規則,通過test正則指定我就要單獨打包src/locallib.js文件,並且把優先級設置為-9,這樣當它被多次引用時,不會進入其他拆分規則組,因為另外兩個規則的優先級都比它要低。

運行webpack打包后:

可以看到新產生了一個locallib.js文件。進入dist目錄查看:

  • a.js里不包含任何模塊代碼。
  • common.js只包含ac模塊的代碼。
  • index.js只包含bindex模塊的代碼。
  • vendor.js只包含jquery模塊的代碼。
  • locallib.js里只包含locallib模塊的代碼。

現在我們又在上一步的基礎上獨立打包了一個指定的模塊locallib.js

至此,我們就成功實現了抽離公共模塊、業務代碼和第三方代碼剝離、獨立打包指定模塊。

對比一下,優化前,打包出來js一共有633KB:

優化后,打包出來js一共不到330KB:

優化打包后的文件分類清晰,體積比優化前縮小了幾乎50%,有點小完美是不是!擊掌!這還只是我舉的一個簡單例子,在實際多頁應用中,優化力度說不定還不止這麼多。

小結

webpack很強大,以上只是冰山一角,但是只要掌握了上述optimization.splitChunks的核心配置,我們就可以幾乎隨心所欲地按照自己的想法來拆分優化代碼控制打包文件了,是不是很酷?玩轉代碼拆分,你也可以!

如果覺得這些依然不能滿足你的需求,還想更精(bian)細(tai)地定製打包規則,可以到查看optimization.splitChunks的更多配置。

歡迎交流~

本文的完整webpack配置和demo源碼可以在這裏獲取:

歡迎轉載,轉載請註明出處:

本文同步發表於:

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

台灣寄大陸海運貨物規則及重量限制?

大陸寄台灣海運費用試算一覽表

QQ是怎樣創造出來的?——解密好友系統的設計

本篇介紹筆者接觸的第一個後台系統,從自身見聞出發,因此涉及的內容相對比較基礎,後台大牛請自覺略過。

什麼是好友系統?

簡單的說,好友系統是維護用戶好友關係的系統。我們最熟悉的好友系統案例當屬QQ,實際上QQ是一款即時通訊工具,憑着好友系統沉澱了海量的好友關係鏈,從而鑄就了一個堅不可摧的商業帝國。好友系統的重要性可見一斑。

熟悉互聯網產品的人都知道,當產品有了一定的用戶量,往往會開發一個好友系統。其主要目的是增加用戶粘性(有了好友就會常來)或者增加社區活躍度(有了好友就會多交流)。

而我的後台開發生涯就是從這樣一個系統開始的。

那時候,好友系統對於我們團隊大部分人來說,都是一個全新的事物,因為我們大部分人都是應屆生。整個系統的架構自然不是我們一群黃毛小孩所能創造。當年的架構圖已經找不到了,但是憑着一點記憶和多年來的經驗積累,還是可以把當年的架構勾勒出來。

 

如圖,好友系統的架構是常見的3層結構,包括接入層、邏輯層和數據層。

我們先從數據層講起。

因為我們對QQ太熟悉了,我們可以很容易地列出好友系統的數據主要包括用戶資料、好友關係鏈、消息(聊天消息和系統消息)、在線狀態等。

互聯網產品往往要面對海量的請求併發,傳統的關係型數據庫比較難滿足讀寫需求。在存儲中,一般是讀多寫少的數據才會使用MySQL等關係型數據庫,而且往往還需要增加緩存來保證性能;NoSQL(Not Only SQL)應該是目前的主流。

對於好友系統,用戶資料和好友關係鏈都使用了kv存儲,而消息使用公司自研的tlist(可以用redis的list替代),在線狀態下面再介紹。

接着是邏輯層

在這個系統中複雜度最高的應該是消息服務(而這個服務我並沒有參与開發[捂臉])。

消息服務中,消息按類型分為聊天消息和系統消息(系統消息包括加好友消息、全局tips推送等),按狀態分為在線消息和離線消息。在實現中,維護3種list:聊天消息、系統消息和離線消息。聊天消息是兩個用戶共享的,系統消息和離線消息每個用戶獨佔。當用戶在線時,聊天消息和系統消息是直接發送的;如果用戶離線,就把消息往離線消息list存入一份,等用戶再次登錄時拉取。

這樣看來,消息服務並不複雜?其實不然,系統設計中常規的流程設計往往是比較簡單的,但是對於互聯網產品,異常情況才是常態,當把各種異常情況都考慮進來時,系統就會非常複雜。

這個例子中,消息發送丟包是一種異常情況,怎麼保證在丟包情況下,還能正常運行就是一個不小的問題。

常見的解決方法是收包方回復確認包,發送方如果沒收到確認包就重發。但是確認包又可能丟包,那又可以給確認包增加一個確認包,這是一個永無止境的確認。

解決方法可以參考TCP的重傳機制。那問題來了,我們為什麼不用TCP呢?因為TCP還是比較慢的,聊天消息的可靠性沒有交易數據要求那麼高,丟幾條消息並不會造成嚴重後果,但是如果用戶每次發送消息后都要等很久才能被收到,那體驗是很差的。

一個比較折中的方案是,收包方回復確認包,如果發送方在一定時間內沒有收到確認就重發;如果收包方收到兩個相同的包(自定義seq一樣),去重即可。

一個面試題引發的討論:

面試時我常常會問候選人一個問題:在分佈式系統中怎樣實現一個用戶同時只能有一個終端在線(用戶在兩個地方先後登錄賬號,后一次登錄可以把前一次登錄踢下線)?這是互聯網產品中非常基礎的一個功能,考察的是候選人基本的架構設計能力。

設計要先從接入服務器(下稱接口機)說起。接口機是好友系統對外的窗口,主要功能是維護用戶連接、登錄鑒權、加解密數據和向後端服務透傳數據等。用戶連接好友系統,首先是連接到接口機,鑒權成功后,接口機會在內存中維護用戶session,後續的操作都是基於session進行。

如圖所示,用戶如果嘗試登錄兩次,接口機通過session就可以將第一次的登錄踢下線,從而保證只有一個終端在線。

問題解決了嗎?

沒有。因為實際系統肯定不會只有一台接口機,在多台接口的情況下,上面的方法就不可行了。因為每個接口機只能維護部分用戶的session,所以如果用戶先後連接到不同的接口機,就會造成用戶多處登錄的問題。

 

自然可以想到,解決的方法就是要維護一個用戶狀態的全局視圖。在我們的好友系統中,稱為在線狀態服務。

在線狀態服務,顧名思義就是維護用戶的在線狀態(登錄時間、接口機IP等)的服務。用戶登錄和退出會通過接口機觸發這裏的狀態變更。因為登錄包和退出包都可能丟包,所以心跳包也用作在線狀態維護(收到一次心跳標記為在線,收不到n次心跳標記為離線)。

一種常用的方法是,採用bitmap存儲在線狀態,具體是指在內存中分配一塊空間,32位機器上的自然數一共有4294967296個,如果用一個bit來表示一個用戶ID(例如QQ號),1代表在線,0代表離線,那麼把全部自然數存儲在內存只要4294967296 / (8 * 1024 * 1024) = 512MB(8bit = 1Byte)。當然,實現中也可以根據需要給每個用戶分配更多的bit。

於是,踢下線功能如圖所示。

 

用戶登錄的時候,接口機首先查找本機上是否有session,如果有則更新session,接着給在線狀態服務發送登錄包,在線狀態服務檢查用戶是否已經在線,如果在線則更新狀態信息,並向上次登錄的接口機IP發送踢下線包;接口機在收到踢下線包時會檢查包中的用戶ID是否存在session,如果存在則給客戶端發送踢下線包並刪除session。

在實際中,踢下線功能還有很多細節問題需要注意。

又回到用戶先後登錄同一台接口機的情況:

 

圖中踢下線流程是正確的,但是如果步驟10和13調換了順序(在UDP傳輸中是常見的)會發生什麼?大家可以自己推演一下,後到的踢下線包會把第二次登錄的A’踢下線了。這不是我們期望的。怎麼辦呢?

解決方法分幾個細節,①接口機在收到13號登錄成功包時,先將session A替換成session A’,然後給客戶端A發生踢下線包(避免多處存活導致互相踢下線);②踢下線包中必須包含除用戶ID外的其他標識信息,session的唯一標識應該是ID+XXX的形式(我最開始採用的是ID+LoginTime),XXX是為了區分某次的登錄;③接口機在收到踢下線包的時候只要判斷ID+XXX是否吻合來決定是否給客戶端發踢下線包。

現實情況,問題總是千奇百怪的,好在辦法總比問題多。

比如我在項目中遇到過接口機和在線狀態服務時間漂移(差幾秒)的情況。這樣踢下線的唯一標識就不能是用戶ID+LoginTime的形式了。可以為每次的登錄生成一個唯一的UUID解決。類似的問題還有很多,不再贅述。

總結一下,本篇主要介紹了好友系統的整體架構和部分模塊的實現方式。分佈式系統中各個模塊的實現其實並不難,難點主要在於應對複雜網絡環境帶來的問題(如丟包、時延等)和服務器異常帶來的問題(如為了應對服務器宕機會增加服務器冗餘度,進而又會引發其它問題)。

好友系統雖然簡單,但麻雀雖小五臟俱全,架構設計的各種技術基本都有涉及。例如分層結構、負載均衡、平行擴展、容災、服務發現、服務器開發框架等方面,後面我會在各個不同的項目中介紹這些技術,敬請期待。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

大陸寄台灣空運注意事項

大陸海運台灣交貨時間多久?

[ch01-03]神經網絡基本原理

系列博客,原文在筆者所維護的github上:,
點擊star加星不要吝嗇,星越多筆者越努力。

前言

For things I don’t know how to build, I don’t understand.

如果我不能親手搭建起來一個東西,那麼我就不能理解它。 — 美國物理學家理查德·費曼

在互聯網發達的今天,很多知識都可以從網絡上找到,但是網絡上的博客、文章的質量參差不齊,或者重點不明確,或者直接把別人的博客抄襲過來。這種狀況使得廣大的初學者們學習起來很困難,甚至誤入歧途,增加了學習曲線的陡峭程度。當然也有很多博主非常非常負責任,文章質量很高,只是連續度不夠,正看得過癮的時候,沒有後續章節了,無法形成知識體系。

初學者也可以選擇看一些教材或者理論書籍,但是,一個雞生蛋蛋生雞的問題出現了:如果你不懂,那麼看完了理論你還是不會懂;如果你懂了,那麼你就沒必要看理論。這也是很多教材或者理論書籍的缺憾。

筆者也看過吳恩達老師的課,理論知識講得由淺入深,還是非常清楚的,雖然代碼示例基本沒有,但仍然強烈建議大家去看。筆者的心得是:視頻可以事先緩存在手機中,利用一些時間片段就可以學習了。

社會上還有一些網課,在線講解深度學習的知識,筆者也參加了幾個團購,老師和助教一般都很負責任,最後可以回看錄像,下載PPT課件。這些課程一般偏重於工程項目,講解深度學習框架和工具的使用,即教大家如何使用工具建模、訓練等等,也是很有幫助的。但對於初學者來說,理解一個新概念可能需要前面很多個已有知識點的支撐,門檻過高,一下子就變得很沮喪。或者是知其然而不知其所以然,最後淪為調參工程師,職業發展受到了限制。

還是應了那句古話:授人以魚不如授人以漁。經歷了以上那些學習經歷,程序員出身的筆者迫切感覺到應該有一種新的學習體驗,在“做中學”,用寫代碼的方式把一些基礎的理論復現一遍,可以深刻理解其內涵,並能擴充其外延,使讀者得到舉一反三的泛化能力。

筆者總結了自身的學習經歷后,把深度學習的入門知識歸納成了9個步驟,簡稱為9步學習法:

  1. 基本概念
  2. 線性回歸
  3. 線性分類
  4. 非線性回歸
  5. 非線性分類
  6. 模型的推理與部署
  7. 深度神經網絡
  8. 卷積神經網絡
  9. 循環神經網絡

筆者看到過的很多書籍是直接從第7步起步的,其基本假設是讀者已經掌握了前面的知識。但是對於從零開始的初學者們,這種假設並不正確。

在後面的講解中,我們一般會使用如下方式進行:

  1. 提出問題:先提出一個與現實相關的假想問題,為了由淺入深,這些問題並不複雜,是實際的工程問題的簡化版本。
  2. 解決方案:用神經網絡的知識解決這些問題,從最簡單的模型開始,一步步到複雜的模型。
  3. 原理分析:使用基本的物理學概念或者數學工具,理解神經網絡的工作方式。
  4. 可視化理解:可視化是學習新知識的重要手段,由於我們使用了簡單案例,因此可以很方便地可視化。

原理分析和可視化理解也是本書的一個特點,試圖讓神經網絡是可以解釋的,而不是盲目地使用。

還有一個非常重要的地方,我們還有配套的Python代碼,除了一些必要的科學計算庫和繪圖庫,如NumPy和Matplotlib等,我們沒有使用任何已有的深度學習框架,而是帶領大家從零開始搭建自己的知識體系,從簡單到複雜,一步步理解深度學習中的眾多知識點。

對於沒有Python經驗的朋友來說,通過閱讀示例代碼,也可以起到幫助大家學習Python的作用,一舉兩得。隨着問題的難度加深,代碼也會增多,但是前後都有繼承關係的,最後的代碼會形成一個小的框架,筆者稱之為Mini-Framework,可以用搭積木的方式調用其中的函數來搭建深度學習的組件。

這些代碼都是由筆者親自編寫調試的,每章節都可以獨立運行,得到相關章節內所描述的結果,包括打印輸出和圖形輸出。

另外,為了便於理解,筆者繪製了大量的示意圖,數量是同類書籍的10倍以上。一圖頂萬字,相信大家會通過這些示意圖快速而深刻地理解筆者想要分享的知識點,使大家能夠從真正的“零”開始,對神經網絡、深度學習有基本的了解,並能動手實踐。

對於讀者的要求:

  1. 學過高等數學中的線性代數與微分
  2. 有編程基礎,可以不會Python語言,因為可以從示例代碼中學得
  3. 思考 + 動手的學習模式

可以幫助讀者達到的水平:

  1. 可以判斷哪些任務是機器學習可以實現的,哪些是科學幻想,不說外行話
  2. 深刻了解神經網絡和深度學習的基本理論
  3. 培養舉一反三的解決實際問題的能力
  4. 得到自學更複雜模型和更高級內容的能力
  5. 對於天資好的讀者,可以培養研發新模型的能力

符號約定

符號 含義
\(x\) 訓練用樣本值
\(x_1\) 第一個樣本或樣本的第一個特徵值,在上下文中會有說明
\(x_{12},x_{1,2}\) 第1個樣本的第2個特徵值
\(X\) 訓練用多樣本矩陣
\(y\) 訓練用樣本標籤值
\(y_1\) 第一個樣本的標籤值
\(Y\) 訓練用多樣本標籤矩陣
\(z\) 線性運算的結果值
\(Z\) 線性運算的結果矩陣
\(Z1\) 第一層網絡的線性運算結果矩陣
\(\sigma\) 激活函數
\(a\) 激活函數結果值
\(A\) 激活函數結果矩陣
\(A1\) 第一層網絡的激活函數結果矩陣
\(w\) 權重參數值
\(w_{12},w_{1,2}\) 權重參數矩陣中的第1行第2列的權重值
\(w1_{12},w1_{1,2}\) 第一層網絡的權重參數矩陣中的第1行第2列的權重值
\(W\) 權重參數矩陣
\(W1\) 第一層網絡的權重參數矩陣
\(b\) 偏移參數值
\(b_1\) 偏移參數矩陣中的第1個偏移值
\(b2_1\) 第二層網絡的偏移參數矩陣中的第1個偏移值
\(B\) 偏移參數矩陣(向量)
\(B1\) 第一層網絡的偏移參數矩陣(向量)
\(X^T\) X的轉置矩陣
\(X^{-1}\) X的逆矩陣
\(loss,loss(w,b)\) 單樣本誤差函數
\(J, J(w,b)\) 多樣本損失函數

1.3 神經網絡的基本工作原理簡介

1.3.1 神經元細胞的數學模型

神經網絡由基本的神經元組成,圖1-13就是一個神經元的數學/計算模型,便於我們用程序來實現。

圖1-13 神經元計算模型

輸入 input

(x1,x2,x3) 是外界輸入信號,一般是一個訓練數據樣本的多個屬性,比如,我們要預測一套房子的價格,那麼在房屋價格數據樣本中,x1可能代表了面積,x2可能代表地理位置,x3可能朝向。另外一個例子是,假設(x1,x2,x3)分別代表了(紅,綠,藍)三種顏色,而此神經元用於識別輸入的信號是暖色還是冷色。

權重 weights

(w1,w2,w3) 是每個輸入信號的權重值,以上面的 (x1,x2,x3) 的例子來說,x1的權重可能是0.92,x2的權重可能是0.2,x3的權重可能是0.03。當然權重值相加之後可以不是1。

偏移 bias

還有個b是怎麼來的?一般的書或者博客上會告訴你那是因為\(y=wx+b\),b是偏移值,使得直線能夠沿Y軸上下移動。這是用結果來解釋原因,並非b存在的真實原因。從生物學上解釋,在腦神經細胞中,一定是輸入信號的電平/電流大於某個臨界值時,神經元細胞才會處於興奮狀態,這個b實際就是那個臨界值。亦即當:

\[w_1 \cdot x_1 + w_2 \cdot x_2 + w_3 \cdot x_3 >= t\]

時,該神經元細胞才會興奮。我們把t挪到等式左側來,變成\((-t)\),然後把它寫成b,變成了:

\[w_1 \cdot x_1 + w_2 \cdot x_2 + w_3 \cdot x_3 + b >= 0\]

於是b誕生了!

求和計算 sum

\[ \begin{aligned} Z &= w_1 \cdot x_1 + w_2 \cdot x_2 + w_3 \cdot x_3 + b \\ &= \sum_{i=1}^m(w_i \cdot x_i) + b \end{aligned} \]

在上面的例子中m=3。我們把\(w_i \cdot x_i\)變成矩陣運算的話,就變成了:

\[Z = W \cdot X + b\]

激活函數 activation

求和之後,神經細胞已經處於興奮狀態了,已經決定要向下一個神經元傳遞信號了,但是要傳遞多強烈的信號,要由激活函數來確定:

\[A=\sigma{(Z)}\]

如果激活函數是一個階躍信號的話,會像繼電器開合一樣咔咔的開啟和閉合,在生物體中是不可能有這種裝置的,而是一個漸漸變化的過程。所以一般激活函數都是有一個漸變的過程,也就是說是個曲線,如圖1-14所示。

圖1-14 激活函數圖像

至此,一個神經元的工作過程就在電光火石般的一瞬間結束了。

小結

  • 一個神經元可以有多個輸入。
  • 一個神經元只能有一個輸出,這個輸出可以同時輸入給多個神經元。
  • 一個神經元的w的數量和輸入的數量一致。
  • 一個神經元只有一個b。
  • w和b有人為的初始值,在訓練過程中被不斷修改。
  • 激活函數不是必須有的,亦即A可以等於Z。
  • 一層神經網絡中的所有神經元的激活函數必須一致。

1.3.2 神經網絡的訓練過程

單層神經網絡模型

這是一個單層的神經網絡,有m個輸入 (這裏m=3),有n個輸出 (這裏n=2)。在神經網絡中,\(b\) 到每個神經元的權值來表示實際的偏移值,亦即\((b_1,b_2)\),這樣便於矩陣運算。也有些人把 \(b\) 寫成\(x_0\),其實是同一個效果,即把偏移值看做是神經元的一個輸入。

  • \((x_1,x_2,x_3)\)是一個樣本數據的三個特徵值
  • \((w_{11},w_{21},w_{31})\)\((x_1,x_2,x_3)\)\(n1\)的權重
  • \((w_{12},w_{22},w_{32})\)\((x_1,x_2,x_3)\)\(n2\)的權重
  • \(b_1\)\(n1\)的偏移
  • \(b_2\)\(n2\)的偏移

圖1-15 單層神經網絡模型

從圖1-15大家可以看到,同一個特徵 \(x_1\),對於\(n1、n2\)來說,權重是不相同的,因為\(n1、n2\)是兩個神經元,它們完成不同的任務(特徵識別)。我們假設\(x_1,x_2,x_3\)分別代表紅綠藍三種顏色,而 \(n1,n2\) 分別用於識別暖色和冷色,那麼 \(x_1\)\(n1\) 的權重,肯定要大於 \(x_1\)\(n2\) 的權重,因為\(x_1\)代表紅色,是暖色。

而對於\(n1\)來說,\(x_1,x_2,x_3\)輸入的權重也是不相同的,因為它要對不同特徵有選擇地接納。如同上面的例子,\(n1\) 對於代表紅色的 \(x_1\),肯定是特別重視,權重值較高;而對於代表藍色的 \(x_3\),盡量把權重值降低,才能有正確的輸出。

訓練流程

從真正的“零”開始學習神經網絡時,我沒有看到過任何一個流程圖來講述訓練過程,大神們寫書或者博客時都忽略了這一點,圖1-16是一個簡單的流程圖。

圖1-16 神經網絡訓練流程圖

前提條件

  1. 首先是我們已經有了訓練數據;
  2. 我們已經根據數據的規模、領域,建立了神經網絡的基本結構,比如有幾層,每一層有幾個神經元;
  3. 定義好損失函數來合理地計算誤差。

步驟

假設我們有表1-1所示的訓練數據樣本。

表1-1 訓練樣本示例

Id x1 x2 x3 Y
1 0.5 1.4 2.7 3
2 0.4 1.3 2.5 5
3 0.1 1.5 2.3 9
4 0.5 1.7 2.9 1

其中,x1,x2,x3是每一個樣本數據的三個特徵值,Y是樣本的真實結果值:

  1. 隨機初始化權重矩陣,可以根據高斯分佈或者正態分佈等來初始化。這一步可以叫做“猜”,但不是瞎猜;
  2. 拿一個或一批數據作為輸入,帶入權重矩陣中計算,再通過激活函數傳入下一層,最終得到預測值。在本例中,我們先用Id-1的數據輸入到矩陣中,得到一個A值,假設A=5;
  3. 拿到Id-1樣本的真實值Y=3;
  4. 計算損失,假設用均方差函數 \(Loss = (A-Y)^2=(5-3)^2=4\)
  5. 根據一些神奇的數學公式(反向微分),把Loss=4這個值用大喇叭喊話,告訴在前面計算的步驟中,影響A=5這個值的每一個權重矩陣,然後對這些權重矩陣中的值做一個微小的修改(當然是向著好的方向修改,這一點可以用數學家的名譽來保證);
  6. 用Id-2樣本作為輸入再次訓練(goto 2);
  7. 這樣不斷地迭代下去,直到以下一個或幾個條件滿足就停止訓練:損失函數值非常小;準確度滿足了要求;迭代到了指定的次數。

訓練完成后,我們會把這個神經網絡中的結構和權重矩陣的值導出來,形成一個計算圖(就是矩陣運算加上激活函數)模型,然後嵌入到任何可以識別/調用這個模型的應用程序中,根據輸入的值進行運算,輸出預測值。

1.3.3 神經網絡中的矩陣運算

圖1-17是一個兩層的神經網絡,包含隱藏層和輸出層,輸入層不算做一層。

圖1-17 神經網絡中的各種符號約定

\[ z1_1 = x_1 \cdot w1_{1,1}+ x_2 \cdot w1_{2,1}+b1_1 \]
\[ z1_2 = x_1 \cdot w1_{1,2}+ x_2 \cdot w1_{2,2}+b1_2 \]
\[ z1_3 = x_1 \cdot w1_{1,3}+ x_2 \cdot w1_{2,3}+b1_3 \]

變成矩陣運算:

\[ z1_1= \begin{pmatrix} x_1 & x_2 \end{pmatrix} \begin{pmatrix} w1_{1,1} \\ w1_{2,1} \end{pmatrix} +b1_1 \]

\[ z1_2= \begin{pmatrix} x_1 & x_2 \end{pmatrix} \begin{pmatrix} w1_{1,2} \\ w1_{2,2} \end{pmatrix} +b1_2 \]

\[ z1_3= \begin{pmatrix} x_1 & x_2 \end{pmatrix} \begin{pmatrix} w1_{1,3} \\ w1_{2,3} \end{pmatrix} +b1_3 \]

再變成大矩陣:

\[ Z1 = \begin{pmatrix} x_1 & x_2 \end{pmatrix} \begin{pmatrix} w1_{1,1}&w1_{1,2}&w1_{1,3} \\ w1_{2,1}&w1_{2,2}&w1_{2,3} \\ \end{pmatrix} +\begin{pmatrix} b1_1 & b1_2 & b1_3 \end{pmatrix} \]

最後變成矩陣符號:

\[Z1 = X \cdot W1 + B1\]

然後是激活函數運算:

\[A1=a(Z1)\]

同理可得:

\[Z2 = A1 \cdot W2 + B2\]

注意:損失函數不是前向計算的一部分。

1.3.4 神經網絡的主要功能

回歸(Regression)或者叫做擬合(Fitting)

單層的神經網絡能夠模擬一條二維平面上的直線,從而可以完成線性分割任務。而理論證明,兩層神經網絡可以無限逼近任意連續函數。圖1-18所示就是一個兩層神經網絡擬合複雜曲線的實例。

圖1-18 回歸/擬合示意圖

所謂回歸或者擬合,其實就是給出x值輸出y值的過程,並且讓y值與樣本數據形成的曲線的距離盡量小,可以理解為是對樣本數據的一種骨架式的抽象。

以圖1-18為例,藍色的點是樣本點,從中可以大致地看出一個輪廓或骨架,而紅色的點所連成的線就是神經網絡的學習結果,它可以“穿過”樣本點群形成中心線,盡量讓所有的樣本點到中心線的距離的和最近。

分類(Classification)

如圖1-19,二維平面中有兩類點,紅色的和藍色的,用一條直線肯定不能把兩者分開了。

圖1-19 分類示意圖

我們使用一個兩層的神經網絡可以得到一個非常近似的結果,使得分類誤差在滿意的範圍之內。圖1-19中那條淡藍色的曲線,本來並不存在,是通過神經網絡訓練出來的分界線,可以比較完美地把兩類樣本分開,所以分類可以理解為是對兩類或多類樣本數據的邊界的抽象。

圖1-18和圖1-19的曲線形態實際上是一個真實的函數在[0,1]區間內的形狀,其原型是:

\[y=0.4x^2 + 0.3xsin(15x) + 0.01cos(50x)-0.3\]

這麼複雜的函數,一個兩層的神經網絡是如何做到的呢?其實從輸入層到隱藏層的矩陣計算,就是對輸入數據進行了空間變換,使其可以被線性可分,然後在輸出層畫出一個分界線。而訓練的過程,就是確定那個空間變換矩陣的過程。因此,多層神經網絡的本質就是對複雜函數的擬合。我們可以在後面的試驗中來學習如何擬合上述的複雜函數的。

神經網絡的訓練結果,是一大堆的權重組成的數組(近似解),並不能得到上面那種精確的數學表達式(數學解析解)。

1.3.5 為什麼需要激活函數

生理學上的例子

人體骨關節是動物界里最複雜的生理結構,一共有8個重要的大關節:肩關節、
肘關節、腕關節、髖關節、膝關節、踝關節、頸關節、腰關節。

人的臂骨,腿骨等,都是一根直線,人體直立時,也是一根直線。但是人在骨關節和肌肉組織的配合下,可以做很多複雜的動作,原因就是關節本身不是線性結構,而是一個在有限範圍內可以任意活動的結構,有一定的柔韌性。

比如肘關節,可以完成小臂在一個二維平面上的活動。加上肩關節,就可以完成胳膊在三維空間的活動。再加上其它關節,就可以擴展胳膊活動的三維空間的範圍。

用表1-2來對比人體運動組織和神經網絡組織。

表1-2 人體運動組織和神經網絡組織的對比

人體運動組織 神經網絡組織
支撐骨骼 網絡層次
關節 激活函數
肌肉韌帶 權重參數
學習各種運動的動作 前向+反向訓練過程

激活函數就相當於關節。

激活函數的作用

看以下的例子:

\[Z1=X \cdot W1 + B1\]

\[Z2 = Z1 \cdot W2 + B2\]

\[Z3 = Z2 \cdot W3 + B3\]

展開:

\[ \begin{aligned} Z3&=Z2 \cdot W3 + B3 \\ &=(Z1 \cdot W2 + B2) \cdot W3 + B3 \\ &=((X \cdot W1 + B1) \cdot W2 + B2) \cdot W3 + B3 \\ &=X \cdot (W1\cdot W2 \cdot W3) + (B1 \cdot W2 \cdot W3+B2 \cdot W2+B3) \\ &=X \cdot W+B \end{aligned} \]

\(Z1,Z2,Z3\)分別代表三層神經網絡的計算結果。最後可以看到,不管有多少層,總可以歸結到\(XW+B\)的形式,這和單層神經網絡沒有區別。

如果我們不運用激活函數的話,則輸出信號將僅僅是一個簡單的線性函數。線性函數一個一級多項式。線性方程是很容易解決的,但是它們的複雜性有限,並且從數據中學習複雜函數映射的能力更小。一個沒有激活函數的神經網絡將只不過是一個線性回歸模型罷了,不能解決現實世界中的大多數非線性問題。

沒有激活函數,我們的神經網絡將無法學習和模擬其他複雜類型的數據,例如圖像、視頻、音頻、語音等。這就是為什麼我們要使用人工神經網絡技術,諸如深度學習,來理解一些複雜的事情,一些相互之間具有很多隱藏層的非線性問題。

圖1-20 從簡單到複雜的擬合

圖1-20展示了幾種擬合方式,最左側的是線性擬合,中間的是分段線性擬合,右側的是曲線擬合,只有當使用激活函數時,才能做到完美的曲線擬合。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※專營大陸空運台灣貨物推薦

台灣空運大陸一條龍服務

Cesium坐標系及坐標轉換詳解

前言

Cesium項目中經常涉及到模型加載、瀏覽以及不同數據之間的坐標轉換,弄明白Cesium中採用的坐標系以及各個坐標系之間的轉換,是我們邁向三維GIS大門的前提,本文詳細的介紹了Cesium中採用的兩大坐標系以及之間轉換的各種方法。

Cesium中的坐標系

Cesium中常用的坐標有兩種WGS84地理坐標系和笛卡爾空間坐標系,我們平時常用的以經緯度來指明一個地點就是用的WGS84坐標,笛卡爾空間坐標系常用來做一些空間位置變換如平移旋轉縮放等等。二者的聯繫如下圖。

其中,WGS84地理坐標系包括 WGS84經緯度坐標系(沒有實際的對象)和 WGS84弧度坐標系(Cartographic);

         笛卡爾空間坐標系包括 笛卡爾空間直角坐標系(Cartesian3)、平面坐標系(Cartesian2),4D笛卡爾坐標系(Cartesian4)。

WGS84坐標系

World Geodetic System 1984,是為GPS全球定位系統使用而建立的坐標系統,坐標原點為地球質心,其地心空間直角坐標系的Z軸指向BIH (國際時間服務機構)1984.O定義的協議地球極(CTP)方向,X軸指向BIH 1984.0的零子午面和CTP赤道的交點,Y軸與Z軸、X軸垂直構成右手坐標系。我們平常手機上的指南針显示的經緯度就是這個坐標系下當前的坐標,進度範圍[-180,180],緯度範圍[-90,90]。

WGS84坐標系

Cesium目前支持兩種坐標系WGS84和WebMercator,但是在Cesium中沒有實際的對象來描述WGS84坐標,都是以弧度的方式來進行運用的也就是Cartographic類:

new Cesium.Cartographic(longitude, latitude, height),這裏的參數也叫longitude、latitude,就是經度和緯度,計算方法:弧度= π/180×經緯度角度。

 笛卡爾空間直角坐標系(Cartesian3)

笛卡爾空間坐標的原點就是橢球的中心,我們在計算機上進行繪圖時,不方便使用經緯度直接進行繪圖,一般會將坐標系轉換為笛卡爾坐標系,使用計算機圖形學中的知識進行繪圖。這裏的Cartesian3,有點類似於三維繫統中的Point3D對象,new Cesium.Cartesian3(x, y, z),裏面三個分量x、y、z。

笛卡爾空間直角坐標系

平面坐標系(Cartesian2)

平面坐標系也就是平面直角坐標系,是一個二維笛卡爾坐標系,與Cartesian3相比少了一個z的分量,new Cesium.Cartesian2(x, y)。Cartesian2經常用來描述屏幕坐標系,比如鼠標在電腦屏幕上的點擊位置,返回的就是Cartesian2,返回了鼠標點擊位置的xy像素點分量。

平面坐標系

坐標轉換

經緯度和弧度的轉換

var radians=Cesium.Math.toRadians(degrees);//經緯度轉弧度
var degrees=Cesium.Math.toDegrees(radians);//弧度轉經緯度

WGS84經緯度坐標和WGS84弧度坐標系(Cartographic)的轉換

//方法一:
var longitude = Cesium.Math.toRadians(longitude1); //其中 longitude1為角度

var latitude= Cesium.Math.toRadians(latitude1); //其中 latitude1為角度

var cartographic = new Cesium.Cartographic(longitude, latitude, height);

//方法二:
var cartographic= Cesium.Cartographic.fromDegrees(longitude, latitude, height);//其中,longitude和latitude為角度

//方法三:
var cartographic= Cesium.Cartographic.fromRadians(longitude, latitude, height);//其中,longitude和latitude為弧度

WGS84坐標系和笛卡爾空間直角坐標系(Cartesian3)的轉換

通過經緯度或弧度進行轉換
var position = Cesium.Cartesian3.fromDegrees(longitude, latitude, height);//其中,高度默認值為0,可以不用填寫;longitude和latitude為角度

var positions = Cesium.Cartesian3.fromDegreesArray(coordinates);//其中,coordinates格式為不帶高度的數組。例如:[-115.0, 37.0, -107.0, 33.0]

var positions = Cesium.Cartesian3.fromDegreesArrayHeights(coordinates);//coordinates格式為帶有高度的數組。例如:[-115.0, 37.0, 100000.0, -107.0, 33.0, 150000.0]

//同理,通過弧度轉換,用法相同,具體有Cesium.Cartesian3.fromRadians,Cesium.Cartesian3.fromRadiansArray,Cesium.Cartesian3.fromRadiansArrayHeights等方法

注意:上述轉換函數中最後均有一個默認參數ellipsoid(默認值為Ellipsoid.WGS84)。

通過過度進行轉換

具體過度原理可以參考上邊的注意事項。

var position = Cesium.Cartographic.fromDegrees(longitude, latitude, height);
var positions = Cesium.Ellipsoid.WGS84.cartographicToCartesian(position);
var positions = Cesium.Ellipsoid.WGS84.cartographicArrayToCartesianArray([position1,position2,position3]);

笛卡爾空間直角坐標系轉換為WGS84

直接轉換
var cartographic= Cesium.Cartographic.fromCartesian(cartesian3);

轉換得到WGS84弧度坐標系后再使用經緯度和弧度的轉換,進行轉換到目標值

間接轉換
var cartographic = Cesium.Ellipsoid.WGS84.cartesianToCartographic(cartesian3);
var cartographics = Cesium.Ellipsoid.WGS84.cartesianArrayToCartographicArray([cartesian1,cartesian2,cartesian3]);

平面坐標系(Cartesian2)和笛卡爾空間直角坐標系(Cartesian3)的轉換

平面坐標系轉笛卡爾空間直角坐標系

這裏注意的是當前的點(Cartesian2)必須在三維球上,否則返回的是undefined;通過ScreenSpaceEventHandler回調會取到的坐標都是Cartesian2。

屏幕坐標轉場景坐標-獲取傾斜攝影或模型點擊處的坐標

這裏的場景坐標是包含了地形、傾斜攝影表面、模型的坐標。

通過viewer.scene.pickPosition(movement.position)獲取,根據窗口坐標,從場景的深度緩衝區中拾取相應的位置,返回笛卡爾坐標。

var handler = new Cesium.ScreenSpaceEventHandler(viewer.scene.canvas);
handler.setInputAction(function (movement) {
     var position = viewer.scene.pickPosition(movement.position);
     console.log(position);
}, Cesium.ScreenSpaceEventType.LEFT_CLICK);

注:若屏幕坐標處沒有傾斜攝影表面、模型時,獲取的笛卡爾坐標不準,此時要開啟地形深度檢測(viewer.scene.globe.depthTestAgainstTerrain = true; //默認為false)。

屏幕坐標轉地表坐標-獲取加載地形后對應的經緯度和高程

這裡是地球表面的世界坐標,包含地形,不包括模型、傾斜攝影表面。

通過viewer.scene.globe.pick(ray, scene)獲取,其中ray=viewer.camera.getPickRay(movement.position)。

var handler = new Cesium.ScreenSpaceEventHandler(viewer.scene.canvas);
handler.setInputAction(function (movement) {
     var ray = viewer.camera.getPickRay(movement.position);
     var position = viewer.scene.globe.pick(ray, viewer.scene);
     console.log(position);
}, Cesium.ScreenSpaceEventType.LEFT_CLICK);

注:通過測試,此處得到的坐標通過轉換成wgs84后,height的為該點的地形高程值。

屏幕坐標轉橢球面坐標-獲取鼠標點的對應橢球面位置

這裏的橢球面坐標是參考橢球的WGS84坐標(Ellipsoid.WGS84),不包含地形、模型、傾斜攝影表面。

通過 viewer.scene.camera.pickEllipsoid(movement.position, ellipsoid)獲取,可以獲取當前點擊視線與橢球面相交處的坐標,其中ellipsoid是當前地球使用的橢球對象:viewer.scene.globe.ellipsoid,默認為Ellipsoid.WGS84

var handler = new Cesium.ScreenSpaceEventHandler(viewer.scene.canvas);
handler.setInputAction(function (movement) {
     var position = viewer.scene.camera.pickEllipsoid(movement.position, viewer.scene.globe.ellipsoid);
     console.log(position);
}, Cesium.ScreenSpaceEventType.LEFT_CLICK);

注:通過測試,此處得到的坐標通過轉換成wgs84后,height的為0(此值應該為地表坐標減去地形的高程)。

笛卡爾空間直角坐標系轉平面坐標系

var cartesian2= Cesium.SceneTransforms.wgs84ToWindowCoordinates(viewer.scene,cartesian3)

空間位置變換

經緯度轉換到笛卡爾坐標系后就能運用計算機圖形學中的仿射變換知識進行空間位置變換如平移旋轉縮放。

Cesium為我們提供了很有用的變換工具類:Cesium.Cartesian3(相當於Point3D)Cesium.Matrix3(3×3矩陣,用於描述旋轉變換)Cesium.Matrix4(4×4矩陣,用於描述旋轉加平移變換),Cesium.Quaternion(四元數,用於描述圍繞某個向量旋轉一定角度的變換)。

下面舉個例子:

      一個局部坐標為p1(x,y,z)的點,將它的局部坐標原點放置到loc(lng,lat,alt)上,局部坐標的z軸垂直於地表,局部坐標的y軸指向正北,並圍繞這個z軸旋轉d度,求此時p1(x,y,z)變換成全局坐標笛卡爾坐p2(x1,y1,z1)是多少?

var rotate = Cesium.Math.toRadians(d);//轉成弧度
var quat = Cesium.Quaternion.fromAxisAngle(Cesium.Cartesian3.UNIT_Z, rotate); //quat為圍繞這個z軸旋轉d度的四元數
var rot_mat3 = Cesium.Matrix3.fromQuaternion(quat);//rot_mat3為根據四元數求得的旋轉矩陣
var v = new Cesium.Cartesian3(x, y, z);//p1的局部坐標
var m = Cesium.Matrix4.fromRotationTranslation(rot_mat3, Cesium.Cartesian3.ZERO);//m為旋轉加平移的4x4變換矩陣,這裏平移為(0,0,0),故填個Cesium.Cartesian3.ZERO
m = Cesium.Matrix4.multiplyByTranslation(m, v);//m = m X v
var cart3 = ellipsoid.cartographicToCartesian(Cesium.Cartographic.fromDegrees(lng, lat, alt)); //得到局部坐標原點的全局坐標
var m1 = Cesium.Transforms.eastNorthUpToFixedFrame(cart3);//m1為局部坐標的z軸垂直於地表,局部坐標的y軸指向正北的4x4變換矩陣
m = Cesium.Matrix4.multiplyTransformation(m, m1);//m = m X m1
var p2 = Cesium.Matrix4.getTranslation(m);//根據最終變換矩陣m得到p2
console.log('x=' + p2.x + ',y=' + p2.y + ',z=' + p2.z );

總結

通過本文,介紹了各個坐標系間的轉換問題,在具體項目中,可結合實際需求,靈活組合解決具體的實際問題。注意,博文是參照網上相關博客及結合自己的實踐總結得來,希望本文對你有所幫助,後續會更新更多內容,感興趣的朋友可以加關注,歡迎留言交流!

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※試算大陸海運運費!

詳解JavaScript錯誤捕獲和上報流程

 

 

 

 

怎麼捕獲錯誤並且處理,是一門語言必備的知識。在JavaScript中也是如此。

那怎麼捕獲錯誤呢?初看好像很簡單,try-catch就可以了嘛!但是有的時候我們發現情況卻繁多複雜。

  • Q1: 同步可以try-catch,但一個異步回調,比如setTimeOut里的函數還可以try-catch嗎?

  • Q2: Promise的錯誤捕獲怎麼做?

  • Q3: async/await怎麼捕獲錯誤?

  • Q4: 我能夠在全局環境下捕獲錯誤並且處理嗎?

  • Q5: React16有什麼新的錯誤捕獲方式嗎?

  • Q6: 捕獲之後怎麼上報和處理?

 

問題有點多,我們一個一個來。

 

Q1. 同步代碼里的錯誤捕獲方式

在同步代碼里,我們是最簡單的,只要try-catch就完了 

function test1 () {
  try {
    throw Error ('callback err');
  } catch (error) {
    console.log ('test1:catch err successfully');
  }
}
test1();

輸出結果如下,顯然是正常的

Q2. 普通的異步回調里的錯誤捕獲方式(Promise時代以前)

上面的問題來了,我們還能通過直接的try-catch在異步回調外部捕獲錯誤嗎?我們試一試 

// 嘗試在異步回調外部捕獲錯誤的結果
function test2 () {
  try {
    setTimeout (function () {
      throw Error ('callback err');
    });
  } catch (error) {
    console.log ('test2:catch err successfully');
  }
}
test2(); 

輸出

注意這裏的Uncaught Error的文本,它告訴我們錯誤沒有被成功捕捉。

為什麼呢? 因為try-catch的是屬於同步代碼,它執行的時候,setTimeOut內部的的匿名函數還沒有執行呢。而內部的那個匿名函數執行的時候,try-catch早就執行完了。( error的內心想法:哈哈,只要我跑的夠慢,try-catch還是追不上我!)

但是我們簡單想一想,誒我們把try-catch寫到函數裏面不就完事了嘛!

 

 

function test2_1 () {
  setTimeout (function () {
    try {
      throw Error ('callback err');
    } catch (error) {
      console.log ('test2_1:catch err successfully');
    }
  });
}
test2_1();

輸出結果如下,告訴我們這方法可行

 

總結下Promise時代以前,異步回調中捕獲和處理錯誤的方法

  • 在異步回調內部編寫try-catch去捕獲和處理,不要在外部哦

  • 很多異步操作會開放error事件,我們根據事件去操作就可以了

Q3. Promise里的錯誤捕獲方式

可通過Promise.catch方法捕獲

function test3 () {
  new Promise ((resolve, reject) => {
    throw Error ('promise error');
  }).catch (err => {
    console.log ('promise error');
  });
}

輸出結果

>> reject方法調用和throw Error都可以通過Promise.catch方法捕獲

function test4 () {
  new Promise ((resolve, reject) => {
    reject ('promise reject error');
  }).catch (err => {
    console.log (err);
  });
} 

輸出結果

 

>> then方法中的失敗回調和Promise.catch的關係

  • 如果前面的then方法沒寫失敗回調,失敗時後面的catch是會被調用的

  • 如果前面的then方法寫了失敗回調,又沒拋出,那麼後面的catch就不會被調用了

// then方法沒寫失敗回調
function test5 () {
  new Promise ((resolve, reject) => {
    throw Error ('promise error');
  })
    .then (success => {})
    .catch (err => {
      console.log ('the error has not been swallowed up');
    });
}
// then方法寫了失敗回調
function test5 () {
  new Promise ((resolve, reject) => {
    throw Error ('promise error');
  })
    .then (success => {},err => {})
    .catch (err => {
      console.log ('the error has not been swallowed up');
    });
}

輸出分別為

1.the error has not been swallowed up
2.無輸出

Q4.async/await里的錯誤捕獲方式

對於async/await這種類型的異步,我們可以通過try-catch去解決

async function test6 () {
  try {
    await getErrorP ();
  } catch (error) {
    console.log ('async/await error with throw error');
  }
}
 
function getErrorP () {
  return new Promise ((resolve, reject) => {
    throw Error ('promise error');
  });
}
test6();

輸出結果如下

 

>> 如果被await修飾的Promise因為reject調用而變化,它也是能被try-catch的

(我已經證明了這一點,但是這裏位置不夠,我寫不下了)

Q5.在全局環境下如何監聽錯誤

window.onerror可以監聽全局錯誤,但是很顯然錯誤還是會拋出

window.onerror = function (err) {
  console.log ('global error');
};
throw Error ('global error');

 

輸出如下

 

Q6.在React16以上如何監聽錯誤

>> componentDidCatch和getDerivedStateFromError鈎子函數

class Bar extends React.Component {
  // 監聽組件錯誤
  componentDidCatch(error, info) {
    this.setState({ error, info });
  }
  // 更新 state 使下一次渲染能夠显示降級后的 UI
  static getDerivedStateFromError(error) {
    return { hasError: true };
  }
  render() {
  }
}

 

 

有錯誤,那肯定要上報啊!不上報就發現不了Bug這個樣子。Sentry這位老哥就是個人才,日誌記錄又好看,每次見面就像回家一樣

 

 

Sentry簡單介紹

Sentry provides open-source and hosted error monitoring that helps all software
teams discover, triage, and prioritize errors in real-time.
One million developers at over fifty thousand companies already ship
better software faster with Sentry. Won’t you join them?
—— Sentry官網

 

Sentry是一個日誌上報系統,Sentry 是一個實時的日誌記錄和匯總處理的平台。專註於錯誤監控,發現和數據處理,可以讓我們不再依賴於用戶反饋才能發現和解決線上bug。讓我們簡單看一下Sentry支持哪些語言和平台吧

 

在JavaScript領域,Sentry的支持也可以說是面面俱到

 

參考鏈接
https://docs.sentry.io/platforms/ 

Sentry的功能簡單說就是,你在代碼中catch錯誤,然後調用Sentry的方法,然後Sentry就會自動幫你分析和整理錯誤日誌,例如下面這張圖截取自Sentry的網站中

 

在JavaScript中使用Sentry 

1.首先呢,你當然要註冊Sentry的賬號

這個時候Sentry會自動給你分配一個唯一標示,這個標示在Sentry里叫做 dsn

2. 安卓模塊並使用基礎功能

安裝@sentry/browser 

npm install @sentry/browser

 

在項目中初始化並使用

import * as Sentry from '@sentry/browser';
 
Sentry.init ({
  dsn: 'xxxx',
});
 
try {
  throw Error ('我是一個error');
} catch (err) {
    // 捕捉錯誤
  Sentry.captureException (err);
}

3.上傳sourceMap以方便在線上平台閱讀出錯的源碼

 

// 安裝
$ npm install --save-dev @sentry/webpack-plugin
$ yarn add --dev @sentry/webpack-plugin
 
// 配置webpack
const SentryWebpackPlugin = require('@sentry/webpack-plugin');
module.exports = {
  // other configuration
  plugins: [
    new SentryWebpackPlugin({
      include: '.',
      ignoreFile: '.sentrycliignore',
      ignore: ['node_modules', 'webpack.config.js'],
      configFile: 'sentry.properties'
    })
  ]
}; 

4. 為什麼不是raven.js?

 

// 已經廢棄,雖然你還是可以用
var Raven = require('raven-js');
Raven
  .config('xxxxxxxxxxx_dsn')
  .install();

 

Sentry的核心功能總結

捕獲錯誤

try { aFunctionThatMightFail(); } catch (err) { Sentry.captureException(err); }

 

設置該錯誤發生的用戶信息

下面每個選項都是可選的,但必須 存在一個選項 才能使Sentry SDK捕獲用戶: id 

Sentry.setUser({
    id:"penghuwan12314"
  email: "penghuwan@example.com",
  username:"penghuwan",
  ip_addressZ:'xxx.xxx.xxx.xxx'
  });

 

設置額外數據

Sentry.setExtra("character_name", "Mighty Fighter");
設置作用域 
Sentry.withScope(function(scope) {
    // 下面的set的效果只存在於函數的作用域內
  scope.setFingerprint(['Database Connection Error']);
  scope.setUser(someUser);
  Sentry.captureException(err);
});
// 在這裏,上面的setUser的設置效果會消失

 

設置錯誤的分組

整理日誌信息,避免過度冗餘 

Sentry.configureScope(function(scope) {
  scope.setFingerprint(['my-view-function']);
});

 

設置錯誤的級別

在閱讀日誌時可以確定各個bug的緊急度,確定排查的優先書序

Sentry.captureMessage('this is a debug message', 'debug');
//fatal,error,warning,info,debug五個值
// fatal最嚴重,debug最輕

 

自動記錄某些事件

例如下面的方法,會在每次屏幕調整時完成上報 

window.addEventListener('resize', function(event){
  Sentry.addBreadcrumb({
    category: 'ui',
    message: 'New window size:' + window.innerWidth + 'x' + window.innerHeight,
    level: 'info'
  });
})

Sentry實踐的運用

根據環境設置不同的dsn

let dsn;
  if (env === 'test') {
    dsn = '測試環境的dsn';
  } else {
    dsn =
      '正式環境的dsn';
  }
 
Sentry.init ({
  dsn
});

 

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

※專營大陸快遞台灣服務

台灣快遞大陸的貨運公司有哪些呢?