dbstructsync -mysql表、字段、索引差異解析工具(原創)

最近寫了一個工具(比較兩套測試環境mysql數據庫中表、表字段、索引的差異,基於python)通過文章簡單介紹下工具的相關內容

  1. 工具名稱
  2. 主要功能
  3. 具體使用方法
  4. 部分實現代碼
  5. 後續

一、工具名稱:

dbstructsync (python庫)

二、主要功能:

比較兩套環境中mysql指定庫中表、表字段及索引的差異,返回同步的sql ,裡面包含建表,修改索引,修改字段的sql .

A環境的數據庫db 作為sourcedb, B環境的數據庫db targetdb ,程序邏輯比較的是 sourcedb 與targetdb 的差異,然後返回一個list的數據類型 

list中包含新建表sql,修改、增加字段sql, 刪除、新增索引sql 

現在總共有3個版本,0.0.1 和0.0.2 存在一定的bug, 所以請使用最新的0.0.3版本

 

 

其他說明:由於是剛完成不久的程序,所以暫時不對最終結果sql進行執行,避免對使用過程中產生不好的影響,這個版本大家可以通過python 自行選擇需要執行哪些操作;隨着之後程序的逐步深入修改和演變,會將執行sql這一步也都加進去

同時也會優化使用方式,讓使用這個工具的小夥伴更容易操作

三、具體使用方法:

1、 pip install  -i https://pypi.python.org/pypi  dbstructsync   

在代碼里引入使用,

from DbStructSync import cli 

result=cli.db_sync(sourcedb, targetdb) 
#sourcedb,targetdb是兩個dict的參數,具體參數看下面
# 這裏得到的    result = ['use 庫;', 
#             'CREATE TABLE `test_async` (\n  `test_async` #varchar(30) NOT NULL,\n  `aa` varchar(400) DEFAULT NULL,\n  #PRIMARY KEY (`test_async`)\n) ENGINE=InnoDB DEFAULT #CHARSET=utf8;',
#             'drop index `index_chaxx` on chanxx_auto_puxx_conf;',
#             'create index `index_chaxx` on #chanxx_auto_puxx_conf(`channel_nxx`,`channel_prxx`) USING #BTREE;']
#result 中包含  use 庫;
#              如果有少的表,會有 create table的數據; 如果有不同的索引,會#存在drop index 和create index的sql;
#              如果有不同的字段,會有alter table的sql ;
#只需要對這個結果,再通過pymysql的一些數據庫操作就可以保證 sourcedb #的內容與taragetdb一致。

2、同時還支持命令行操作,代碼寫入到x.py代碼中

result = cli.db_sync_commandline()
python x.py --source  host=10.1.1.x,port=3306,user=root,passwd=root,db=investx --target host=10.1.1.x,port=3306,user=root,passwd=root,db=investx

 

命令行中  –source  key=value;key2=value2;key3=value3  –target key=value;key2=value2;key3=value3

–source, –target 是兩給必輸的參數,後續的值會作為一個dict類型傳入程序。 –source是源庫的信息, –target是目標庫的信息

還包括其他幾個命令參數 –only-index , –only-fields ; –only-index 只比較索引差異, –only-fields 只比較字段差異, 非必填,默認都為False 

四、部分實現代碼:

 

def diff_tables(sourcetable, targettable):
    '''

    :param sourcetable:  源數據庫的表名列表
    :param targettable:  目的數據庫的表名列表
    :return: 返回dict,包含三種結果,源庫多的表,目標庫多的表,相同的表
    '''
    logger.info('開始比較兩個庫中表的差異,源庫表{},目標庫表{}'.format(sourcetable, targettable))
    table_result={}
    if not isinstance(sourcetable, list) or not isinstance(targettable, list):
         raise  TypeError('sourcetable , targettable的類型不是list')
    source_diff = set(sourcetable) - set(targettable)
    target_diff = set(targettable) - set(sourcetable)
    same_tables = set(sourcetable)& set(targettable)
    table_result['source'] = source_diff
    table_result['target'] = target_diff
    table_result['same'] = same_tables
    logger.info('兩個庫中表的差異結果{}'.format(table_result))
    return  table_result
 

def  diff_indexs_fields(sourcesql, targetsql, type=1):
    '''
    :param sourcesql: 源數據庫表的創建sql
    :param targetsql: 目標數據表的創建sql
    :return: 記錄下索引不一致的地方
    '''
    result = {}
    logger.info('解析語句中的索引字段,並進行比較索引')
    sourcesql = parse_str(sourcesql)  # 從括號中提取需要的內容
    #logger.info('從括號中提取出來的信息數據{}'.format(sourcesql))
    sourcesql = lists2str(sourcesql)  #將list轉換為str,並對數據的空格數據進行處理
    logger.info('解析完的數據的信息{}'.format(sourcesql))
    sourcesql = sourcesql.split('\n') #將str按照'\\n'進行分割
    logger.info('解析完數據之後的信息{}'.format(sourcesql))
    targetsql = parse_str(targetsql)
    targetsql = lists2str(targetsql)
    targetsql = targetsql.split('\n')
    if type ==1:
        source_index = parse_fields(sourcesql,type)
        target_index = parse_fields(targetsql,type)

        result= compare_indexs_field(source_index, target_index, type)
    elif type ==2:
        source_field_sql = parse_fields(sourcesql, type)
        target_field_sql = parse_fields(targetsql, type)
        result = compare_indexs_field(source_field_sql, target_field_sql, type)
    return  result

def dict2sql(dict_str):
    '''
    將解析完成的數據轉換為對應的可執行sql
    :param dict_str:
    :return:
    '''
    dict_str = copy.deepcopy(dict_str) # 做一個深度copy,可以放心的進行相關數據處理

    if not isinstance(dict_str, dict):
        raise  TypeError('調用方法{}參數不是dict類型,請確認'.format('dict2sql'))
    #獲取db名字
    for key ,value in dict_str.items():
        dbname = key
        logger.info('數據庫名{}'.format(dbname))
        for table, table_desc  in  value.get('source').items():
               if table =='create_table':
                   #create_table_sql = lists2str(table_desc)
                   dict_str[dbname]['source'][table] = table_desc
                   #其他的都是table的名字
                   logger.info('數據庫的修改語句:{}'.format(table_desc))
               else:
                  logger.info('對於索引和字段的解析原始數據{}'.format(table_desc))
                  if table_desc.get('index'):
                      create_index_sql_lists=[]
                      #create_index_sql_lists.append('use {};'.format(dbname))
                      index_lists= (table_desc.get('index'))
                      result_index= parse_comma_split(str(index_lists)[1:-1])
                      for i in result_index:
                           if i.strip().startswith('\'KEY'):
                               #print(i.strip())
                               index_values = parse_space_split(i.strip())
                               drop_index_sql= 'drop index {} on {}'.format(index_values[1],table )
                               if len(index_values)<=3:
                                  create_index_sql='create index {} on {}{} '.format(index_values[1], table, index_values[2])
                               else:
                                  create_index_sql='create index {} on {}{} {}'.format(index_values[1], table, index_values[2], ' '.join(index_values[3:]))
                               create_index_sql_lists.append(drop_index_sql)
                               create_index_sql_lists.append(create_index_sql)

                           if i.strip().startswith('\'UNIQUE KEY'):
                                 index_values = parse_space_split(i.strip())
                                 drop_index_sql = 'drop index {} on {}'.format(index_values[2], table)
                                 if len(index_values) <= 4:
                                     create_index_sql = 'create unique index {} on {}{} '.format(index_values[2], table,
                                                                                          index_values[3])
                                 else:
                                     create_index_sql = 'create unique index {} on {}{} {}'.format(index_values[2], table,
                                                                                               index_values[3],
                                                                                               ' '.join(index_values[4:]),
                                                                                               )
                                 create_index_sql_lists.append(drop_index_sql)
                                 create_index_sql_lists.append(create_index_sql)
                      logger.info('表{}解析出來的索引的修改sql{}'.format(table, create_index_sql_lists))
                      dict_str[dbname]['source'][table]['index'] = create_index_sql_lists
                  if table_desc.get('fields'):
                      create_fields_sql_lists=[]
                      #create_fields_sql_lists.append('use {};'.format(dbname))
                      modify_field_sqls = table_desc.get('fields').get('modify',None)
                      create_field_sqls=table_desc.get('fields').get('lose',None)

                      if modify_field_sqls:
                           for modify_field_sql in modify_field_sqls:
                               sql_indexs = parse_space_split(str(modify_field_sql)[0:-1])
                               #print(sql_indexs)
                               alter_fields_sql='alter table {} modify column {} {} {}'.format(table, sql_indexs[0],sql_indexs[1],' '.join(sql_indexs[2:]))
                               create_fields_sql_lists.append(alter_fields_sql)
                      if create_field_sqls:
                           for  create_field_sql in create_field_sqls:
                                sql_indexs = parse_space_split(str(create_field_sql)[0:-1])
                                create_fields_sql='alter table {} add column {} {}'.format(table, sql_indexs[0],' '.join(sql_indexs[2:]))
                                create_fields_sql_lists.append(create_fields_sql)
                      logger.info('表{}解析出來的字段的修改sql{}'.format(table,create_fields_sql_lists))
                      dict_str[dbname]['source'][table]['fields'] = create_fields_sql_lists

    return  dict_str  # 返回給一個全部是可執行sql的dict

五、後續:

1、對使用過程中遇到對bug進行修復

2、對代碼進行優化

3、增加其他相關功能,讓工具越來越好用

4、希望使用的小夥伴多提意見,未來成為一個好用的小工具

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

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

SpringBoot 正式環境必不可少的外部化配置

前言

中有讀者反應:

部署后運維很不方便,比較修改一個 IP 配置,需要重新打包。

這一點我是深有體會,17 年自學,並很大膽的直接在生產環境用的時候,我都是讓產品經理(此時他充當我們的運維,嘿嘿)用壓縮軟件打開 jar,然後複製出配置,修改完之後再替換回去。為什麼我這麼大膽,因為當時才入行一年,而且覺得有架構師兜底,我就奔放了。你是不知道,當時負責這個項目的開發(c#開發)一開始不想用 SpringBoot 的。

不過如今看到這個問題,我有點震驚,都 9102 年了,竟然還擔心這樣的問題。我想說,哥們,這真的不是事兒。SpringBoot 早就提供了方法來解決這個問題。

SpringBoot 生產特性

SpringBoot 有很多生產特性,可以在生產環境中使用時更加方便。其中外部化配置基本都會用到。

Spring Boot 允許外部化配置,以便相同的應用在不同的環境中工作。
屬性值可以在 Spring 環境中使用 @Value 或 @ConfigurationProperties 使用。

此次參考的版本是 SpringBoot-2.2.0.RELEASE

優先級

外部化配置的優先級順序如下:

  1. Devtools 全局配置:當 devtools 啟用時,$HOME/.config/spring-boot
  2. 測試類中的 @TestPropertySource
  3. 測試中的 properties 屬性:在 @SpringBootTest 和 用來測試特定片段的測試註解
  4. 命令行參數
  5. SPRING_APPLICATION_JSON 中的屬性:內嵌在環境變量或系統屬性中的 JSON
  6. ServletConfig 初始化參數
  7. ServletContext 初始化參數
  8. java:comp/env 中的 JNDI 屬性
  9. Java 系統屬性:System.getProperties()
  10. 操作系統環境變量
  11. 隨機值(RandomValuePropertySource):random.*屬性
  12. jar 包的指定 profile 配置文件:application-{profile}.properties
  13. jar 包的指定 profile 配置文件:application-{profile}.properties
  14. jar 包的默認配置文件:application.properties
  15. jar 包的默認配置文件:application.properties
  16. 代碼內的 @PropertySource註解:用於 @Configuration 類上
  17. 默認屬性:通過設置 SpringApplication.setDefaultProperties 指定

注意:以上用 properties 文件的地方也可用 yml文件

配置隨機值

my.uuid=${random.uuid}

命令行屬性

java -jar -Ddemo=vm demo.jar --demo=arg
  • -Dxxx 為 vm 參數,在代碼中通過 System#getProperty 獲取
  • –xxx 為 spring 命令行參數,通過 Environment#getProperty 獲取,若通過此方法獲取不到,會獲取 vm 同名參數
  • xxx.jar 之後的參數都是 arg 參數,都會在 main 方法中的 arg 數組中獲取到

示例

public static void main(String[] args) {
    ConfigurableApplicationContext context = SpringApplication.run(ArgApplication.class, args);
    LOGGER.info("----------------");
    /* 打印 arg 參數 */
    Arrays.stream(args)
        .forEach(
            arg -> {
              LOGGER.info("arg:{}", arg);
            });
    /* 命令行傳參 demo */
    LOGGER.info("System#getProperty:{}", System.getProperty("demo"));
    LOGGER.info("Environment#getProperty:{}", context.getEnvironment().getProperty("demo"));
}

輸入命令

java -jar -Ddemo=vm arg-0.0.1-SNAPSHOT.jar aaa bbb ccc --demo=arg

效果如下:

----------------
arg:aaa
arg:bbb
arg:ccc
arg:--demo=arg
System#getProperty:vm
Environment#getProperty:arg

而如果執行命令是:

java -jar -Ddemo=vm arg-0.0.1-SNAPSHOT.jar aaa bbb ccc

結果如下:

arg:aaa
arg:bbb
arg:ccc
System#getProperty:vm
Environment#getProperty:vm

如果執行命令是:

java -jar arg-0.0.1-SNAPSHOT.jar aaa bbb ccc --demo=arg

結果如下:

arg:aaa
arg:bbb
arg:ccc
arg:--demo=arg
System#getProperty:null
Environment#getProperty:arg

屬性文件

優先級:

  1. file:./config/
  2. file:./
  3. classpath:/config/
  4. classpath:/

如果定義了 spring.config.location,如:classpath:/custom-config/,file:./customr-config/,優先級如下:

  1. file:./custom-config/
  2. classpath:custom-config/

如果指定了 spring.config.additional-location,會先加載 additional 配置 如:spring.config.additional-location=classpath:/custom-config/,file:./customr-config/,優先級如下:

  1. file:./custom-config/
  2. classpath:/custom-config/
  3. file:./config/
  4. file:./
  5. classpath:/config/
  6. classpath:/

指定 profile 的屬性

默認的 profile 是 default,當沒有指定spring.profiles.active 屬性時,默認會加載application-default.properties 文件。指定 profiles 文件的加載順序與上述不指定 profiles 文件的加載一致。指定 profile 文件的屬性始終覆蓋未指定文件的屬性。如:spring.profiles.active=dev,則 application-dev.properties文件內的屬性會覆蓋 application.properties 內的同名屬性。

注意:如果在 spring.config.location 屬性中指定了 文件,則此文件對應的特定 profiles 類文件不起作用。如果想要起作用,在 spring.config.location 中使用 文件夾

佔位符

配置文件中可以引用之前定義的值,如下:

app.name=MyApp
app.description=${app.name} is a Spring Boot application.

可以用此特性創建一些已存在的 Spring Boot 配置的較短、易於使用的變量。如下:

# nacos 配置示例
spring:
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848
        namespace: d9a39d78-xxxxxxxx-ea4f282e9d99
      discovery:
        server-addr: 127.0.0.1:8848
        namespace: d9a39d78-xxxxxxxx-ea4f282e9d99
# Discovery 配置示例        
nacos:
  plugin:
    namespace: d9a39d78-xxxxxxxx-ea4f282e9d99

可改為如下配置

spring:
  cloud:
    nacos:
      config:
        server-addr: ${app.server-addr}
        namespace: ${app.namespace}
      discovery:
        server-addr: ${app.server-addr}
        namespace: ${app.namespace}
# Discovery 配置示例        
nacos:
  plugin:
    namespace: ${app.namespace}

app:
  server-addr: 127.0.0.1:8848
  namespace: d9a39d78-xxxxxxxx-ea4f282e9d99

然後在命令行可以直接通過 -Dapp.namespace--app.namespace 來傳參,會方便很多。特別是在多個地方用到同一個屬性的時候。

屬性加密

Spring Boot 不支持屬性加密,但提供鈎子節點修改配置屬性。EnvironmentPostProcessor 接口允許在應用啟動前操作 Environment

yaml

yaml 文件使用的時候非常直觀、方便。而且在 Spring Boot 中做了處理,獲取 yaml 和 properties 文件中的屬性基本是一樣的操作。

一個文件指定多 pfofile

通過 spring.profiles 指示何時使用對應的配置,使用 ---進行配置分隔

# application.yml
server:
  address: 192.168.1.100
---
spring:
  profiles: development
server:
  address: 127.0.0.1
---
spring:
  profiles: production & eu-central
server:
  address: 192.168.1.120

yaml 缺點

@PropertySource 不能加載 yaml 文件,這種情況下只能使用 properties 文件。

在特定 profile 的 yaml 文件中使用多 profile 配置,會有意料之外的情況:

# application-dev.yml
server:
  port: 8000
---
spring:
  profiles: "!test"
  security:
    user:
      password: "secret"

當運行時指定 --spring.profiles.active=dev ,啟用 dev profile,其它的 profile 會忽略。也就是此例中 spring.security.user.password 屬性會失效。

因此,不要在指定 profile 的 yaml 文件中使用多種 profile 配置。

類型安全的屬性配置

JavaBean 屬性綁定

通過 @ConfigurationProperties 註解將屬性(properties、yml 文件、環境變量等)綁定到類對象中。與自動配置類類似。

@ConfigurationProperties("acme")
public class AcmeProperties{
    private boolean enabled;
    private InetAddress remoteAddress;
    private final Security security = new Security();
    // getter and setter
    public static class Security{
        private String username;
        private String password;
        private List<String> roles = new ArrayList<>(Collections.singleton("USER"));
         // getter and setter
    }
}

這種安排依賴於默認的無參構造器,getter 和 setter 通常是必需的,因為綁定就像 Spring MVC 一樣是通過標準的 Java Beans 屬性描述符進行的。在下列情況下,可省略 setter:

  • Maps:只要被初始化后,getter 必須而 setter 不必須,binder 可以對它們進行修改
  • Collections 和 數組:可以通過索引或逗號分隔的值來設定屬性。後者必須有 setter 方法。建議對於這種情況一直加上 setter。如果初始化了一個 Collection,確保它不是不可變類型。
  • 如果初始化了嵌套的 POJO 屬性(如上例中的 Security),setter 不是必須的。如果需要 binder 通過其默認構造器動態創建實例,則需要 setter

注意:如果使用 Lombok 生成 getter 和 setter,確保不會生成任何特定的構造器,不然容器會自動使用它來實例化對象。
最後,只有標準 Java Bean 屬性可以這樣綁定屬性,靜態屬性不支持。

構造器綁定

上述示例可以改成如下:

@ConstructorBinding
@ConfigurationProperties("acme")
public class AcmeProperties{
  private final boolean enabled;
  private final InetAddress remoteAddress;
  private final Security security;
  
  public AcmeProperties(boolean enabled, InetAddress remoteAddress, Security security){
      this.enabled = enabled;
      this.remoteAddress = remoteAddress;
      this.security = security;
  }
  // getter and setter
  
  public static class Security{
      private final String username;
      private final String password;
      private final List<String> roles;
      public Security(String username, String password, @DefaultValue("USER") List<String> roles){
          this.username = username;
          this.password = password;
          this.roles = roles;
      }
      // getter and setter
  }
}

@ConstructorBinding 註解表示使用構造函數綁定屬性值。這意味着 binder 將期望找到一個包含待綁定參數的構造器。
@ConstructorBinding 類的嵌套成員也將通過構造函數綁定屬性值。

可以使用 @DefaultValue 指定默認值,轉換服務將字符串值強轉為缺少屬性的目標類型。

要使用構造綁定,類必須允許使用 @EnableConfigurationProperties 或 配置屬性掃描方式。不能對由常規 Spring 機制創建的 bean 使用構造函數綁定。如:@Component Bean、通過@Bean 方法創建的 Bean 或使用@Import 加載的 Bean

如果類中有多個構造器,可以直接將 @ConstructorBinding 註解使用在要綁定的構造器上。

啟用 @ConfigurationProperties 註解類型

Spring Boot 提供了一個基礎設施來綁定這些類型並將它們自動註冊為 bean。
如果應用程序中使用 @SpringBootsApplication,用 @ConfigurationProperties 註解的類將被自動掃描並註冊為 bean。默認情況下,將從聲明此註解的類的包中進行掃描。如果要掃描特定的包,可以對 ·@SpringBootsApplication 註解的類顯式使用 @ConfigurationPropertiescan 註解,如下例所示:

@SpringBootApplication
@ConfigurationPropertiesScan({ "com.example.app", "org.acme.another" })
public class MyApplication {
}

有時,用 @ConfigurationProperties 註釋的類可能不適合掃描,例如,如果正在開發自己的自動配置,在這些情況下,可以在任何@Configuration 類上指定要處理的類型列表,如下例所示:

@Configuration(proxyBeanMethods = false) @EnableConfigurationProperties(AcmeProperties.class)
public class MyConfiguration { }

注意:當使用配置屬性掃描或通過@EnableConfigurationProperties 註冊@ConfigurationProperties bean 時,bean 有一個常規名稱:<prefix>-<fqn>,其中 <prefix>@ConfigurationProperties 註解中指定的環境 key 前綴,<fqn> 是 bean 的完全限定名。如果註解沒有提供任何前綴,則只使用 bean 的完全限定名。
上例中 bean name 是 acme-com.example.AcmeProperties

使用@ConfigurationProperties 註解類型

這種類型的配置在 SpringApplication 外部 YAML 配置中特別適用,如下例所示:

# application.yml

acme:
  remote-address: 192.168.1.1
  security:
    username: admin
    roles:
      - USER
      - ADMIN

@ConfigurationProperties bean 可以像其它 bean 一樣注入使用。如下:

@Service
public class MyService{
    private final AcmeProperties properties;
    
    @Autowired
    public MyService(AcmeProperties properties){
        this.properties = properties;
    }
    
    // ...
}

使用 @ConfigurationProperties 還可以生成元數據文件,IDE 可以使用這些文件提供代碼自動完成功能。

第三方配置

除了可以在 上使用 @ConfigurationProperties 註解,還可以在 public @Bean 方法上使用它。如果要將屬性綁定到不在控制範圍內的第三方組件,那麼這樣做特別有用。

要從 Environment 屬性配置 bean,將 @ConfigurationProperties 添加到其 bean 註冊中,如下例所示:

@ConfigurationProperties(prefix = "another")
@Bean
public AnotherComponent anotherComponent() {
    //... 
}

another 前綴定義的任何 JavaBean 屬性都映射到 AnotherComponent bean 上,映射方式類似於前面的 AcmeProperties 示例。

鬆綁定

Spring Boot 使用一些寬鬆的規則將 Environment 屬性綁定到@ConfigurationProperties bean,因此環境屬性名和 bean 屬性名之間不需要完全匹配。常見的包括短劃線分隔的環境屬性(例如,context-path 綁定到 contextPath)和大寫的環境屬性(例如,PORT 綁定到 port)。

@ConfigurationProperties(prefix="acme.my-project.person")
public class OwnerProperties {
    private String firstName;
    public String getFirstName() {
        return this.firstName;
    }
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
}

對於以上 Java Bean,可以使用以下屬性

注意:註解的前綴值必須是短橫線 (小寫,用-分隔,如:acme.my-project.person)。

放寬每個屬性源的綁定規則

建議:如果可能的話,將屬性存儲為小寫的短橫線格式,例如:my.property-name=acme。

在綁定到 Map 屬性時,如果 key 包含除小寫字母-数字字符或 - 之外的任何內容,則需要使用括號符號,以便保留原始值。如果 key 沒有被[]包圍,則刪除任何不是字母数字或 -的字符。

acme:
  map:
    "[/key1]": value1
    "[/key2]": value2
    /key3: value3

上面的屬性將綁定到 Map 的這些 key 中:/key1/key2key3

合併複雜類型

List

當在多個位置配置 list 時,通過替換(而非添加)整個 list 來覆蓋。

@ConfigurationProperties("acme")
public class AcmeProperties {
    private final List<MyPojo> list = new ArrayList<>();
    public List<MyPojo> getList() { return this.list;
    }
}
acme:
  list:
    - name: my name
      description: my description
---
spring:
  profiles: dev
acme:
  list:
    - name: my another name

當啟用 dev 配置時,AcmeProperties.list 中值包含一個 MyPojo 對象(name 為my another name),不是添加操作,而是覆蓋操作。

當一個 List 在多個 profiles 中定義時,最高優先級的被使用。

Map

對於 Map 屬性,可以使用從多個屬性源獲取屬性值進行綁定。但是,對於多個源中的同一屬性,將使用優先級最高的屬性。

@ConfigurationProperties("acme")
public class AcmeProperties {
    private final Map<String, MyPojo> map = new HashMap<>();
    public Map<String, MyPojo> getMap() {
    return this.map;
    }
}
acme:
  map:
    key1:
      name: my name 1
      description: my description 1
---
spring:
  profiles: dev
acme:
  map:
    key1:
      name: dev name 1
    key2:
      name: dev name 2
      description: dev description 2

當 dev 配置啟用時,AcmeProperties.map 中包含兩個鍵值對。key1 中 pojo name 為 dev name 1,description 為 my description 1;key2 中 pojo name 為 dev name 2,description 為 dev description 2。

不同屬性源的配置進行了合併

以上合併規則適用於所有的屬性源

屬性轉換

Spring Boot 試圖在綁定到 @ConfigurationProperties bean 時將外部應用程序屬性強轉為正確的類型。如果需要自定義類型轉換,可以提供 ConversionService bean(帶有名為 ConversionService 的 bean)或自定義屬性編輯器(通過 CustomEditorConfigurer bean)或自定義 Converters (使用 bean 定義註解 @ConfigurationPropertiesBinding )。

注意:由於此 bean 在應用程序生命周期的早期被請求,請確保限制 ConversionService 正在使用的依賴項。通常,需要的任何依賴項在創建時都可能未完全初始化。如果自定義的 ConversionService 不需要配置 keys 強轉,並且僅依賴於使用 @ConfigurationPropertiesBinding 限定的自定義轉換器,則可能需要將它重命名。

時間區間轉換

SpringBoot 對錶示持續時間有專門的支持。如果暴露 java.time.Duration 屬性,則可以用以下格式:

  • 常規的 long 表示(除非指定了 @DurationUnit,否則使用毫秒作為默認單位)
  • java.time.Duration 使用的標準 ISO-8601 格式
  • 一種更可讀的格式,其中值和單位是耦合的(例如,10s 表示 10 秒)
@ConfigurationProperties("app.system")
public class AppSystemProperties {

    @DurationUnit(ChronoUnit.SECONDS)
    private Duration sessionTimeout = Duration.ofSeconds(30);

    private Duration readTimeout = Duration.ofMillis(1000);

    public Duration getSessionTimeout() {
        return this.sessionTimeout;
    }

    public void setSessionTimeout(Duration sessionTimeout) {
        this.sessionTimeout = sessionTimeout;
    }

    public Duration getReadTimeout() {
        return this.readTimeout;
    }

    public void setReadTimeout(Duration readTimeout) {
        this.readTimeout = readTimeout;
    }

}

要指定 30 秒的 sessionTimeout,30、PT30S 和 30s 都是等效的。500ms 的 readTimeout 可以用以下任何形式指定:500、PT0.5S 和 500ms。
也可以使用以下任何支持的單位:

  • ns:納秒
  • us:微妙
  • ms:毫秒
  • s:秒
  • m:分
  • h:時
  • d:天

默認的單位是毫秒,可以使用 @DurationUnit 指定

數據 size 轉換

Spring 框架有一個 DataSize 類型,以字節表示大小。如果暴露一個 DataSize 屬性,則可以用以下格式:

  • 常規的 long 表示(除非指定了 @DataSizeUnit,否則使用字節作為默認單位)
  • java.time.Duration 使用的標準 ISO-8601 格式
  • 一種更可讀的格式,其中值和單位是耦合的(例如,10MB 表示 10 兆字節)。
@ConfigurationProperties("app.io")
public class AppIoProperties {

    @DataSizeUnit(DataUnit.MEGABYTES)
    private DataSize bufferSize = DataSize.ofMegabytes(2);

    private DataSize sizeThreshold = DataSize.ofBytes(512);

    public DataSize getBufferSize() {
        return this.bufferSize;
    }

    public void setBufferSize(DataSize bufferSize) {
        this.bufferSize = bufferSize;
    }

    public DataSize getSizeThreshold() {
        return this.sizeThreshold;
    }

    public void setSizeThreshold(DataSize sizeThreshold) {
        this.sizeThreshold = sizeThreshold;
    }

}

要指定 10 兆字節的 bufferSize1010MB 是等效的。256 字節的 sizeThreshold 可以指定為 256256B
也可以使用以下任何支持的單位:
B:字節
KB:千字節
MB:兆字節
GB:千兆字節
TB:兆兆字節

默認的單位是字節,可以使用 @DataSizeUnit 指定

@ConfigurationProperties 校驗

每當對 @ConfigurationProperties 類使用 Spring 的@Validated 註解時,Spring Boot 就會驗證它們。可以直接在配置類上使用 JSR-303 javax.validation 約束註解。必須確保類路徑上有一個兼容的 JSR-303 實現(如:hibernate-validator),然後將約束註解添加到字段中。

@ConfigurationProperties(prefix="acme")
@Validated
public class AcmeProperties {
    @NotNull
    private InetAddress remoteAddress;
    
    // ... getters and setters
}

注意:還可以通過註解@Bean 方法來觸發驗證,該方法使用@Validated 創建配置屬性。

儘管嵌套屬性在綁定時也將被驗證,但最好對關聯字段使用 @Valid。這確保即使找不到嵌套屬性,也會觸發驗證。

@ConfigurationProperties(prefix="acme")
@Validated
public class AcmeProperties {

    @NotNull
    private InetAddress remoteAddress;

    @Valid
    private final Security security = new Security();

    // ... getters and setters

    public static class Security {

        @NotEmpty
        public String username;

        // ... getters and setters

    }

}

還可以通過創建ConfigurationPropertiesValidator bean 來添加自定義 Spring Validator@Bean 方法應該聲明為 static 。配置屬性驗證器是在應用程序生命周期的早期創建的,將@Bean 方法聲明為 static 可以創建 Bean,而無需實例化@configuration 類。這樣做可以避免任何可能由早期實例化引起的問題。

注意:spring-boot-actuator 模塊包含一個端點,該端點暴露所有 @ConfigurationProperties bean。訪問 /actuator/configprops 可獲得相關信息。

@ConfigurationProperties vs. @Value

@Value 註解是一個核心容器特性,它不提供與 @ConfigurationProperties 相同的特性。

如果需要為組件定義了一組配置鍵,建議將它們配置到一個 @ConfigurationProperties 註解的 POJO 中。由於 @Value 不支持鬆綁定,如果需要使用環境變量提供值,則它不是一個好的選項。
雖然可以在 @Value 中編寫 SpEL 表達式,但此類表達式不會從 properties 文件中處理。

使用配置中心

如果項目比較大的話,分成了好幾個 SpringBoot 工程,可以使用某些 SpringCloud 組件,比如:配置中心。配置中心支持一個地方管理所有的配置,有些還可以支持修改配置實時生效而不用重啟應用,真的是很棒棒呢。推薦使用 nacos。如果項目比較小,你用 git 或者指定文件夾來作為配置存放的地方也可以。

怎麼樣?有了這些用法的支持,你還會覺得 Springboot 打成一個 jar 會在部署的時候很不方便嗎?

參考資料

公眾號:逸飛兮(專註於 Java 領域知識的深入學習,從源碼到原理,系統有序的學習)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

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

特斯拉需求大!住友金屬追加擴產電池材料、增至2.5倍

 

日本住友金屬礦山(Sumitomo Metal Mining)28日發布新聞稿宣布,該公司雖已於去年10月27日表示將砸下180億日圓於2018年1月將鋰離子電池正極材料「鎳酸鋰(見附圖)」月產能擴增至3,550噸,不過因電動車(EV)用鋰離子電池需求擴大,因此決議對「鎳酸鋰」進行追加增產措施,計畫投入40億日圓於磯浦工廠進行增產工程,目標在2018年6月將整體「鎳酸鋰」月產能擴增至4,550噸、將達現行的2.5倍。

住友金屬礦山指出,該公司正持續擴大與Panasonic攜手研發的高性能鎳酸鋰產能,此次為了因應Panasonic擴大鋰離子電池產能、故決定對鎳酸鋰進行追加增產投資。

據日經新聞指出,住友金屬礦山追加增產「鎳酸鋰」主要是因應美國EV廠特斯拉(Tesla)增產所需。據報導,住友金屬礦山目前透過Panasonic供應特斯拉電動車所需的大部分車用電池正極材料。

根據嘉實XQ全球贏家系統報價,截至台北時間31日上午8點50分為止,住友金屬礦山上揚1.34%至1,660.5日圓,稍早最高漲至1,664.5日圓創約5個月來(2月16日以來)新高水準。

特斯拉平價電動車「Model 3」於7月28日正式交車。Business Insider、The Motley Fool、Electrek等外電報導,Model 3售價35,000美元,特斯拉原本計畫要在2020年底前,將Model 3年產量提升至50萬台,但去(2016)年該公司把目標提前兩年、移至2018年。不過,Model 3目前的生產年率還只有10萬台,特斯拉想要達標、產速勢必得快速拉升。

富士經濟6月22日公布調查報告指出,預估2030年時EV年銷售量將增至407萬台、超越HV(油電混合車、2030年銷售量預估為391萬台),且之後雙方的差距將持續擴大。富士經濟預估,在中國需求增加加持下,2035年EV全球銷售量將擴大至630萬台、將達2016年的13.4倍(較2016年增加12.4倍)。

(本文內容由授權使用。圖片出處:MoneyDJ)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

燃料電池車緩不濟急,豐田擬2019年量產電動車

中國擅長以政策引導經濟發展,據日經新聞報導,豐田為符合中國新能源車規定,可能於2019年開始在中國量產電動車。

報導指出,有鑒於美國、中國與其它地區汽車排放規定轉嚴,豐田已要求同集團的汽車零件廠Denso、愛信精機(Aisin Seiki)合力成立子公司,務求加速電動車的開發作業。

就新能源車而言,以氫氣驅動的「燃料電池車」才是豐田首選,然而「燃料電池車」需要廣建加氫站曠日廢時,而中國新能源車最快於2018年上路,迫使豐田退而求其次。

豐年2012年就曾推出RAV4 EV電動休旅車,採用特斯拉製鋰電池,但市場反應不佳,僅賣出2500輛,豐田隨後也宣布停產。在中國政策引導下,豐田第二次做電動車是否會產生不一樣的結果,有待觀察。

吉利汽車旗下的Volvo日前已宣布從2019年起,旗下所有新車都會是純電動或油電混合驅動,象徵純汽油車將走入歷史。

(本文內容由授權使用。圖片出處:豐田)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

EV商機夯!Toray電池材料傳大增產、擬在美國建新廠

日經新聞、日刊工業新聞1日報導,Toray計畫在2020年結束前總計砸下約1,200億日圓擴增車用鋰離子電池關鍵材料「分隔膜(separator、見附圖)」產能,目標將分隔膜年產能擴增至19.5億平方公尺、將達現行(約4億平方公尺)的約5倍。Toray目前在日本及南韓生產分隔膜,且已在南韓工廠進行增產工程,計畫在2017年度末(2018年3月底)將分隔膜年產能提高至約6.5億平方公尺。

報導指出,因法國、英國紛紛表明計畫在2040年停售汽柴油車,提振電動車(EV)有望急速普及,故Toray計畫在2019年於歐洲興建一座年產能達8,000萬平方公尺的新工廠,且除了歐洲之外,Toray也計畫在特斯拉(Tesla)等EV廠抬頭的美國興建新工廠。

特斯拉平價電動車「Model 3」於7月28日正式交車。而為了因應特斯拉增產所需,住友金屬礦山(Sumitomo Metal Mining)於7月28日宣布,將追加增產鋰離子電池正極材料「鎳酸鋰」,目標將其月產能擴增至現行的2.5倍。

鋰離子電池4大關鍵材料分別為正極材、負極材、分隔膜和電解液,而這些電池材料皆由日系廠商握有高市佔率,其中,在全球分隔膜市場上,Toray為第2大廠、僅次於旭化成(Asahi Kasei)。

日刊工業新聞6月23日報導,因車廠加快電動車(EV)的研發腳步、帶動電池材料市場成長速度超乎預期,故旭化成計畫上修鋰離子電池關鍵材料「分隔膜」的增產計畫,目標在2020年結束前將分隔膜年產能最高擴增至15億平方公尺(m2)、將達現行的2.5倍,且將遠高於原先規劃的11億m2目標,期望藉由積極投資、鞏固全球龍頭位置。預估追加擴產所需的投資額約300億日圓。

旭化成於3月30日宣布,因電動車(EV)、油電混合車(HV)等車用鋰離子電池需求預估將呈現急速增長,故決議擴增鋰離子電池關鍵材料「分隔膜」產能,計畫投下約150億日圓,在守山製造所(滋賀縣守山市)增設年產能約2億平方公尺(m2)的分隔膜產線,並預計於2019年度上半年商轉。旭化成指出,待上述增產工程完工後,該公司整體分隔膜年產能將從現行的約6.6億m2提高3成至約8.6億m2。

根據日本市調機構富士經濟(Fuji Keizai)預估,2020年全球分隔膜市場規模將增至3,000億日圓、將達2015年的2倍水準,而EV、HV等車用用途是推動分隔膜需求急增的最大功臣,預估2020年車用分隔膜佔整體市場比重將達約45%。

富士經濟6月22日公布調查報告指出,預估2030年時EV年銷售量將增至407萬台、超越HV(2030年銷售量預估為391萬台),且之後雙方的差距將持續擴大。富士經濟預估,在中國需求增加加持下,2035年EV全球銷售量將擴大至630萬台、將達2016年的13.4倍(較2016年增加12.4倍)。

(本文內容由授權使用。圖片出處:)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

松下預計提高美國電池廠年產能以供特斯拉需求

日經亞洲評論28日報導,松下(Panasonic)汽車零件部門執行副總伊藤好生(Yoshio Ito)在受訪時表示,車用電池能量密度越來越高、處理的難度也跟著升高,松下不能將電池賣給沒有能力肩負起產品安全控管能力的電動車製造商。他說,從需求的角度來看、電動車電池銷售額要倍增不是件難事,但在考量合格工程師人數、土地、廠房以及主管機關許可執照等因素後松下決定不去追求不切實際的目標。

伊藤指出,松下已經決定將美國電池廠年產能提升至35 GWh、現階段並無進一步擴產的明確規劃。作為特斯拉(Tesla)的獨家電池供應商,松下的任務就是供應足夠的數量給客戶。他還提到,松下計畫開發雷達和聲納技術、聚焦自駕車市場中現有車商忽視的利基需求。

官網資料顯示,2020年特斯拉超級電池工廠(Gigafactory)的年產能將超過2013年全球鋰電池產能的總和。

華爾街日報7月15日報導,加州下議院已通過規模達30億美元的電動車購車退稅折扣法案,後續還得過上議院與州長Jerry Brown這兩關。

負責起草這項法案的舊金山民主黨籍議員Phil Ting表示,加州若想落實氣候變遷目標(2025年讓150萬輛零排放車輛上路)、勢必得想辦法給電動車產業打強心針才行。根據加州空氣資源局的統計,加州已有超過25萬輛零排放汽車(包括電動車)上路、佔美國約半數的比重。

特斯拉平價電動車「Model 3」售價為35,000美元起(不含獎勵計畫)、電池續航力為345公里。特斯拉在6月23日創下歷史收盤新高紀錄(383.45美元)、7月28日以335.07美元坐收。

(本文內容由授權使用。圖片出處:Tesla)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

特斯拉掀21700圓柱形電池風潮,中國電池企業加速佈局

上證報報導,7月29日,特斯拉首批量產Model 3完成交付;220英里至310英里(約合354公里至499公里)的續航能力、3.5萬美元起的銷售價格,讓Model 3成為特斯拉至今為止價格最親民的車型;而能讓特斯拉推出如此平民級電動車的關鍵,在於其使用升級版電池。業內人士預測,21700型號電池可望在未來成為市場主流方案。

今年初,特斯拉宣佈與松下在超級工廠量產用於Model 3中的21700型號電池(其中的「21」指電池直徑為21mm,「70」指長度為70mm,「0」代表圓柱體型的電池)。據瞭解,特斯拉使用的21700型電池系統的能量密度在300Wh/kg左右,比原來Model S使用的18650電池能量密度提升20%以上,單體容量提升35%,系統成本降低10%左右。

業內分析人士指出,相較其他型號,除了保持了18650型電池所具有的高可靠性和穩定性,21700型還兼具了經濟性。物理尺寸的增加不僅可以提升能量密度,同時也會影響到循環壽命等性能。根據有關測算,容量每提升10%,循環壽命約會降低20%,不斷加大尺寸,安全性上也存在風險;而21700型可能是目前可量產電池中能量密度最高且成本最低的電池。

因此,自特斯拉宣佈Model 3車型上使用21700型號電池後,三星SDI也宣佈將推出21700型電池,並表示該電池將在2021年進入規模化生產階段。在國際巨頭的帶動下,中國電池企業也加速了對21700型電池的佈局。

億緯鋰能7月底舉行了湖北金泉二區投產啟動儀式,是中國目前自動化程度最高的動力圓柱鋰離子電池生產線,亦是中國投產的首條21700型號電池生產線;公司預計,今年第三季末將達到共計3.5GWh的圓柱電池產能規模。此外,鋰電巨頭力神電池近日舉行了21700型鋰離子動力電池新品發佈會;按照戰略規劃,華東產業基地是力神電池在十三五期間的投資重點,主要產品為新能源汽車用鋰離子動力電池。

業內人士認為,Model 3作為特斯拉主打的平民級電動車,其量產所具備的意義可比肩iPhone 4當時在手機行業引領的趨勢;隨著特斯拉對21700型電池的率先啟用,21700型電池可望在未來成為市場主流方案,而億緯鋰能、力神電池等一批率先佈局的企業,將不斷加大其在行業競爭中的話語權,市場份額有望不斷擴大。

(本文內容由授權使用。圖片出處:Tesla)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

車拚鋰電池!鹼性電池新突破 可重複充電、以鋁代鋅

 

鹼性電池售價便宜、也比鋰電池更不容易起火燃燒,唯一缺點是無法重複充電使用。不過,新創公司Ionic Materials即將在本週四(8月3日)發表一項突破性的新發現,讓固態的鹼性電池成為鋰電池等高儲電科技的替代品,直接應用到PC、智慧型手機或電動車。

紐約時報1日報導(),Ionic發明的新技術,可讓鹼性電池重複充電,其推出的原型,最多已能充電400次。Ionic創辦人兼材料科學家Mike Zimmerman說,該公司開發的鹼性電池,目前雖比市面上的鋰電池還要重,但其成本優勢和更優秀的儲電能力,將彌補這項缺點。

不只如此,鋰電池的關鍵材料是鈷,不但毒害環境,非洲還有不少礦場違法使用童工採鈷,令人憂心。相較之下,鹼性電池使用的是蘊藏量相對豐富的鋅和錳。

另外,Ionic還修正鹼性電池的設計,以價格更為親民的鋁取代鋅。在過去,鋁因為容易被腐蝕的問題,並未被採納,若鹼性電池真的能以鋁為材料,那麼重量有機會比鋰電池還要輕,也會比當前市面上的鹼性電池還要便宜。

報導稱,Ionic計畫在週四於永續能源研究機構Rocky Mountain Institute舉行的35週年大會上,宣布研究成果。

鹼性電池若能重複充電、將有諸多好處,但鋰電池之父John Goodenough也不是省油的燈。Goodenough雖已高齡94歲,卻寶刀未老,他今(2017)年3月已經帶領德州大學(University of Texas)奧斯汀分校團隊,打造出「全固態」(all-solid-state)鋰電池,不但更加安全,容量還是三倍大,而且只要數分鐘就可充電完畢,不必再像從前那樣等待數小時。

Apple Insider、CNET、CleanTechnica等多家外電3月6日報導,Goodenough採用全新技術打造的鋰電池可適用幾乎所有裝置,包括iPhone、MacBook Pro、車用電池或是類似特斯拉「Powerwall」家用電力儲存系統等,都可使用這種電池。

Goodenough團隊開發的最新技術,使用了玻璃製的電解質(不是以往的液體 ),可解決電池充電過快時激發「金屬鬚晶」(metal whiskers),導致正負兩極相互接觸、繼而起火爆炸的問題。

玻璃電解質是以鋰、鈉或鉀製成,可大幅增加電池的能量密度,據研究人員估算,即使充放電超過1,200次,電池續航力也幾乎不受影響。不僅如此,即使環境急凍到零下20度C,新款電池依舊能正常運作。

研發團隊指出,玻璃電解質可簡化電池製造流程,採用的材料也都對環境友善,能輕鬆回收再利用,另外更能降低稀土金屬的使用量。不過,德州大學科技商業化辦公室目前還在跟多家電池大廠洽談授權事宜,因此短期內恐怕還無法上市。

(本文內容由授權使用。圖片出處:Ionic Materials)  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

為了Model 3 的「生產地獄」,特斯拉可能將再次發債籌資

隨著Model 3 車款開始正式交車,特斯拉(Tesla)的「生產地獄」也即將來臨,這意味著特斯拉將開始以非常低的現金流維持運行,為了提高能使用的現金量,馬斯克正在考慮發債籌資。

華爾街日報報導,在日前公布的第二季財報中,特斯拉的虧損幅度小於外界預期,但馬斯克(Elon Musk)也同時承認,相較起以往的車款,生產Model 3 的挑戰還會再高出許多。

根據了解,特斯拉的目標是在2018 年底前,達到每周生產1 萬台Model 3 的目標,但做為比較,去年其他車款的周產量還不到2,000 台。

「當我用『生產地獄』來形容Model 3 的生產時,我是認真的。」

儘管如此,特斯拉對於「生產地獄」的情況似乎並不陌生,它們正為了雄心勃勃的產能時間表投入大筆資金,在加州和內華達州增設工廠,並大量投入研究和開發。

第二季的財報顯示,特斯拉目前手上有約30 億美元的現金,但為了因應Model 3 的生產,特斯拉預估下半年將再花費20 億美元,這將讓特斯拉的現金部位降至10 億美元。

儘管特斯拉表示,下半年持有的現金和增加的收入應該足以涵蓋所有支出項目,但摩根史丹利分析師Ryan Brinkman 對此仍抱持懷疑。

(Source:Tesla Club Belgium via Flickr CC2.0)

對於現金部位是否足夠的疑問,馬斯克表示,為了更快速的生產Model 3,特斯拉已經和供應商談判了更好的付款條件,可以在繳交零組件的帳單之前先賣車,但馬斯克也同意,在現金部位上保有緩衝空間總是更明智的選擇。

馬斯克強調,特斯拉正有在考慮發債籌資,但是並沒有考慮增加股權。財務長Deepak Ahuja 指出,特斯拉還有8 億美元的信貸額度空間,而且從新收購的太陽能業務中,也還能獲得近7 億美元的稅收股權基金(tax equity funds)和債務。

但根據S&P 全球市調機構統計,在2017 年第一季時,包含長期票據和資本租貸(Capital Leases)在內,特斯拉已有約有96.7 億美元的未還債務,年初發售的股票和優先債更讓債務再次往上提升。

對於有著支出需求的特斯拉前景,摩根士丹利分析師Adam Jonas 如此評估:「額外的資本支出會讓投資者的眼中充滿淚水,而時間會告訴他們這是不是喜悅的眼淚。」

晨星研究(Morningstar)的分析師David Whiston 則表示,不論是特斯拉今年再次發債,或是明年再度公開籌資,都不會是需要驚訝的事情,「人們需要習慣特斯拉的『習慣』──極度仰賴資本籌集來實現野心勃勃的成長目標。」

根據了解,Model 3 在去年原本有約51.8 萬張訂單,由於交車時間持續延後,有6.3 萬筆訂單取消,目前訂單約有45.5 萬張。

對於這些取消的訂單,馬斯克表示,其實只需要再多一些努力,特斯拉可以保留下更多Model 3 的訂單,但他認為這些需求的減少並不是什麼大問題。

「這就像是經營一家餐廳,你正在賣漢堡,但目前的等待時間大約需要1.5 小時,這樣你還會鼓勵更多的人來買漢堡嗎?」

(合作媒體:。首圖來源:Tesla)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

EV續航距離倍增、媲美汽油車!GS傳量產新電池

 

日經新聞8日報導,GS Yuasa將在2020年開始量產可讓電動車(EV)充飽一次電所能行駛的距離擴增至現行2倍的新型鋰離子電池。現行部分EV充飽電所能行駛的距離僅有汽油車的一半左右水準,而搭載GS新型電池將讓EV續航距離增加至可媲美汽油車的水準。GS為全球第4大車用鋰離子電池廠。

報導指出,上述新型電池由GS、三菱商事(Mitsubishi)、三菱汽車(Mitsubishi Motors)合資設立的電池製造公司「Lithium Energy Japan(簡稱LEJ)」所研發,將在2020年透過LEJ工廠進行量產,將供應給日系、歐系車廠使用,價格目標是壓低至同於現行產品的水準。GS、三菱商事、三菱汽車對LEJ的出資比重分別為51%、46%、3%。

根據GS公布的財報資料顯示,上季(2017年4-6月)GS車用鋰離子電池事業營收較去年同期成長4.2%至87.24億日圓、營損額自去年同期的2.17億日圓縮小至1.64億日圓。

法國、英國已紛紛表明計畫在2040年停售汽柴油車,提振EV後續需求料將急速擴大。

富士經濟6月22日公布調查報告指出,預估2030年時EV年銷售量將增至407萬台、超越HV(油電混合車、2030年銷售量預估為391萬台),且之後雙方的差距將持續擴大。富士經濟預估,在中國需求增加加持下,2035年EV全球銷售量將擴大至630萬台、將達2016年的13.4倍(較2016年增加12.4倍)。

(本文內容由授權使用。圖片出處:GS Yuasa)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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