摘要：摘要本文我們就如何使用阿里云這樣的配置管理產品在中替代幫助簡化環境配置管理做一個簡單的示例，幫助你理解基于來簡化微服務環境配置管理的方案，并會簡單比較一下與方案的優劣。

摘要： 本文我們就如何使用阿里云ACM這樣的配置管理產品在Spring Cloud中替代Spring Cloud Config幫助簡化環境配置管理做一個簡單的示例，幫助你理解基于ACM來簡化微服務環境配置管理的方案，并會簡單比較一下ACM與Spring Cloud Config方案的優劣。

點此查看原文：http://click.aliyun.com/m/41595/

配置的環境屬性

毫無疑問，在系統持續交付的過程中，系統最終運行環境的多樣性及復雜性毫無疑問增加了我們在配置管理工作上的負擔，有時候，甚至不夸張的說，配置就是因環境而生.

這在Eugen Paraschiv的博文 Configuration Must Be Environment Specific里有簡單的闡述，在我的博文《現代應用架構中的配置管理面臨的挑戰》 的容器化、調度與配置管理小節也有深入的闡述。

如果要問，是什么導致了我們應用的構建物(artifact)在各個環境不能保持一樣，有時候Docker無法輕易達成“Build Once， Run Anywhere!"的承諾，其答案往往就是環境配置的差異，為幫助你理解，舉一些簡單的例子:

在開發環境中將logLevel設置為DEBUG,在預發環境logLevel設置為INFO,生產環境里logLevel設置為WARNING
在開發環境中使用4核8G的機器跑數據庫，而在生產中用32核96G機器跑數據庫
在日常環境執行線程池的最大線程數應該設置為15，而生產環境上這個值應該大一點，默認設為150
在線上環境中，中心機房，應用數據源需要連接A庫，而深圳機房，應用應該就近連接使用B庫
只有在小淘寶環境，雙向同步開關才應該關閉
這次的改動有點大，新的特性僅在線上的杭州單元把該特性開放出來，其它的單元環境先不要開放出來
本文我們就如何使用阿里云ACM這樣的配置管理產品在Spring Cloud中替代Spring Cloud Config幫助簡化環境配置管理做一個簡單的示例，幫助你理解基于ACM來簡化微服務環境配置管理的方案，并會簡單比較一下ACM與Spring Cloud Config方案的優劣。

場景故事
為了幫助理解需求和場景，在日常工程實踐中，我們一般會用用戶故事（User Story）的方式，預設一個簡單的場景，以此來做闡釋和交流，熟悉微服務歷史的兄弟一定熟悉下面這張早期的布道圖:

本文中我們就以Movie Service為例，假設我們需要從關系數據庫MySQL(RDS)檢索所有電影信息列表，但是在測試環境、預發和生產環境我們需要使用不同的數據庫，因為只有生產庫才需要頂配的機器。這樣我們的應用需要在不同的環境配置不同的數據源配置、連接池配置、數據庫安全配置等等，我們會介紹如何基于阿里云ACM的Namespace映射不同環境的能力，為movie service在不同運行環境設置不同的數據源配置。

如下圖所示:

創建微服務 Movie Service
新建Spring Boot Starter 微服務應用 movie service
movie service的業務邏輯很簡單，從MySQL(RDS)里列出所有的movie列表，如下簡圖所示:

這里我們創建了一個標準的jpa應用（類似Spring官網的樣例工程 Accessing data with MySQL，我們的工程結構如下圖所示:

引入JPA、MySQL、連接池HikariCP以及WEB依賴

    org.springframework.boot
    spring-boot-starter-web



    org.springframework.boot
    spring-boot-starter-data-jpa



    mysql
    mysql-connector-java
    runtime



    com.zaxxer
    HikariCP
    2.7.6

創建 MySQL(RDS) 數據庫及用戶

mysql> create database db_example; -- Create the new database
mysql> create user "springuser"@"localhost" identified by "ThePassword"; -- Creates the user
mysql> grant all on db_example.* to "springuser"@"localhost"; -- Gives all the privileges to the new user on the newly created database

具體可參考 Accessing data with MySQL 中的 "Create the database"小節

創建 WEB Controller

package com.alibaba.demo.microsvc.controller;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.RestController;
import com.alibaba.demo.microsvc.dao.MovieRepository;
import com.alibaba.demo.microsvc.model.Movie;

@RestController
public class MovieController {

  @Autowired
  MovieRepository movieRepository;

  @RequestMapping("/list-movies")
  public @ResponseBody Iterable listMovies() {
        return movieRepository.findAll();
  }    

     }

在ACM中使用Namespace創建隔離的環境配置

注: 在阿里云上使用ACM的前提是開通了該項服務，具體開通流程可以參考文檔ACM 快速入門，開通服務并登陸之后，即可進入 ACM 控制臺 創建命名空間及配置

在ACM中創建3個環境 (dev,stage,prod)

為 dev,stage,prod 不同環境分別創建配置

注意 我們完成了什么?

在上一步中，我們為相同配置項針對不同環境的設置了不同的值，例如 "spring.datasource.url"這個配置項，我們通過設置不同的url來為各環境連接不同的數據庫，并且僅在生產環境開啟SSL (useSSL=true)

  dev:
        spring.datasource.url=jdbc:mysql://localhost:3306/db_example?useSSL=false
>        
    prod:
        spring.datasource.url=jdbc:mysql://30.5.101.169:3306/db_example?useSSL=true
>    

同時，我們也為生產環境(prod)設置了更大的數據庫連接池和更小的連接超時時間

  dev:
        spring.datasource.hikari.connection-timeout=60000
        spring.datasource.hikari.maximum-pool-size=10
>        
    prod:
        spring.datasource.hikari.connection-timeout=15000
        spring.datasource.hikari.maximum-pool-size=200
>    

而為了方便開發調試，我們僅在開發環境打開了SQL Trace

    dev:
        spring.jpa.show-sql=true

Movie Service與配置中心ACM集成
現在我們將集成Movie Service與ACM以便從ACM中獲取對應環境的配置. 關于如何在Spring Cloud中使用ACM，具體可以參考ACM官方文檔 開發指南 > SDK 參考 > Spring Cloud ACM

為movie service引入ACM依賴

 
    com.alibaba.cloud
    spring-cloud-starter-acm
    1.0.1
 

在application.properties配置ACM連接信息、namespace、accessKey、secretKey等信息

spring.application.name=movie-service
spring.application.group=com.alibaba.cloud.acm
  
alibaba.acm.endpoint=acm.aliyun.com
alibaba.acm.namespace=
alibaba.acm.accessKey=        
alibaba.acm.secretKey=

注意: 你可以在ACM的"命名空間詳情"或者"配置的示例代碼"里找到你的namespace_id，accessKey，secretKey等信息，如下圖所示:

在瀏覽器里訪問Movie Service

查看ACM配置推送刷新信息

如果在movie service引入了spring-boot-starter-actuator依賴并且在application.properties設置了management.security.enabled=false,可以通過端點 http://<>/acm 看到應用的配置消費及刷新情況，如下圖:

也可以在ACM控制臺上查看配置的推送軌跡、配置版本等信息，具體使用方法可參考ACM官方文檔，在此不再贅述。

ACM與Spring Cloud Config簡單對比

擴展思考 - 為什么不把配置放到應用自身的jar包里？
在我的博文《現代應用架構中的配置管理面臨的挑戰》 里有長篇幅的側面論述。
如果測試、生產因為配置打出來的包不一樣，如何保證你的測試是有效的？
關注微服務的開發者一定拜讀過下面這本微服務圣經

在上書中的第6.7及6.8小節對于環境和配置有非常精彩的闡述，這里將原文引用在此

6.8 服務配置

服務需要一些配置。理想情況下，這些配置的工作量應該很小，而且僅僅局限于環境間配置的差異。如果你的配置修改了很多服務的基本行為，或者不同環境之間的配置差異很大，那么你可能就只能在一套環境中發現某個特定的問題，這是極其痛苦的事情。
所以，如果存在不同環境之間的配置差異，應該如何在部署流程中對其進行處理呢？一種方法是對每個環境創建不同的構建物，并把配置內建在該構建物中。剛開始看這種方法好像挺有道理。配置已經被內建了，只需要簡單的部署，它應該就能夠正常工作了，對吧？其實這是有問題的。還記得持續交付的概念嗎？我們想要創建一個構建物作為候選發布版本，并使其沿著流水線向前移動，最終確認它能夠被發布到生產環境。想象一下，我構建了一個Customer-Service-Test構建物和Customer-Service-Prod構建物。如果Customer-Service-Test構建物通過了測試，但我真正要部署的構建物卻是Customer-Service-Prod，又要如何驗證這個軟件最終會真正運行在生產環境中呢？
還有一些其他的挑戰。首先，創建這些構建物比較耗時。其次，你需要在構建的時候知道存在哪些環境。你要如何處理敏感的配置數據？我可不想把生產環境的數據庫密碼提交到源代碼中，但是如果在創建這些構建物時需要的話，通常這也是難以避免的。
一個更好的方法是只創建一個構建物，并將其配置多帶帶管理。從形式上來說，這針對的可能是每個環境一個屬性文件，或者是傳入到安裝過程中的一些參數。還有一個在應對大量微服務時比較流行的方法是，使用專用系統來提供配置，第11章會詳細討論這個話題。

配置漂移
當應用部署之后運行過程中，尤其是部署在多臺服務器上之后，如果使用開發人員或者運維人員手工維護配置文件的方式，日積月累之后，會產生我們所謂的"配置飄移"問題，即由于應用以及依賴的組件的版本變更帶來的配置差異，以及不同的團隊或者人的多次不同時間點做的不同的修改會導致數據中心中每臺機器上的相同的應用的配置在各臺機器上或多或少都有細微的差別，而這往往是bug和重大故障隱藏之所。

總結
在本文中，我們以一個測試和生產連接不同的數據庫，配置不同的數據源(包括連接池)參數為例，介紹了如何將阿里云配置中心ACM與Spring Cloud一起使用，幫助你在微服務架構中簡化你的環境配置管理。