程序員如何讓自己 Be Cloud Native - 配置篇
前言
這是《程序員如何讓自己 Be Cloud Native》系列文章的第二篇，從第一篇的反饋來看，有些同學反饋十二要素太形式主義，不建議盲目跟從。作者認為任何理論和技術都需要有自己的觀點，這些觀點是建立在個體知識體系逐漸鍛煉出來的辯別能力之上的。Be Cloud Native這一系列的文章，會基於十二要素為理論基礎，加上作者在雲計算誕生以來對於架構的演進所觀察到的變化去分享自己的一些心得。
第一篇：倉庫與依賴。「傳送門」
實例
配置這個要素的核心思想就是代碼與數據隔離，一開始我們的軟件很小很小的時候，我們會可能直接把各種配置、甚至生產環境中的代碼直接寫在代碼中，配置甚至就是代碼的一部分？比如以下的這斷代碼就是這樣：
public boolean serviceConnectable() {
return ping("edas.console.aliyun.com", 3);
}
該方法實現一個本地是否可以連接到遠端 server 的功能。如果按照上面的代碼進行編寫，只能保證在公共雲的環境達到想要的效果。該程序如果部署到了一個專有雲或者 IDC 的環境中的時候，就需要改代碼了。
如果改成以下的方式，效果就會截然不同。那時如果程序部署到了一套新的環境中，只需改變edas.server.address 這個配置。
@Value("edas.server.address")
private String remoteAddress;
public boolean serviceConnectable() {
return ping(remoteAddress, 3);
}
定義與示例
這個例子應該比較貼近大家的日常，我們將上面這個例子往上提升一層，可以做出一個如下的初步定義：應用的行為(_Behavior_) = 代碼(_Code_) + 輸入(_Data_)。代碼是固定的，需要重新編譯分發，無法根據環境進行變化的；而輸入是活的。上面的例子，就是一個把 Code 中的一部分內容抽離，變成 Data 的過程。做完這個變化之後，應用對變化的適應性就更強了。當然，這些 Data 有些是用戶輸入的，有些是系統啟動時就已經確定的，後者是我們定義的 配置 ，也是我們今天討論的主題。從這個層面(_Data_)說起來，配置其實可以包含很多種，以 Java 語言為例，至少分為以下幾種：
- 代碼中的文件配置: *.properties 文件。
- 機器上的文件配置 *.properties 文件。
- 通過 -D 參數指定的啟動參數。
- 環境變量。
- 配置管理系統，簡單的有 DB；比較流行的領域產品如 Nacos、ZooKeeper、ectd 等。
選擇多了，貌似世界就不那麽美妙了，因為我們總是會陷入到“用什麽”和“為什麽”中去。作者的觀點是，在用什麽之前，先弄清楚需求層面的兩點：
- 隔離粒度：每個版本不一樣？每臺機器不一樣？每個進程不一樣？
- 安全性：運維人員可見？開發人員可見？還是都不應該可見？
仔細討論上述兩點之前，我們舉幾個關於配置的例子：
- 程序版本號：從代碼 Release (build) 開始，基本上就確定了；這一類配置基本上不存在變化的可能，即這一類配置的隔離粒度等同於 Code 。
- 某個前端組件的版本號：前端版本號有一個特點，就是變動很頻繁，尤其是在上線的過程中，發布三四個版本是很常見的現象；而且在上線的過程中，一般都會先灰度驗證，再進行現網發布。所以這類配置需要具備一個特點就是，可靈活變動與可按照環境（不同機器、不同流量）粒度發布。
- 服務器端口號：服務器的端口號是需要和進程綁定的，尤其在某些微服務場景；同一個服務，如果部署在同一臺機器上，必須準確的告知其他服務本服務的確切的地址和端口。
- 數據庫元信息配置：這種配置，同一套環境中的相同服務會是一樣的，而且其真實的值隱藏的越深越好，其他還有某些 AK/SK、用戶名密碼之類，每套環境會不一樣，同時不同的產品對待這類配置的安全性要求也可能不一樣。
歸納
通過上面例子簡單的論述，我們大致可以把相關的配置做如下的歸類：
| 配置項所在位置 | 隔離性 | 安全性 |
|---|---|---|
| 代碼文件 | 控制不同版本的軟件行為，等同於代碼、基本不會改動 | 所有有代碼權限的人員都可見 |
| 機器上的文件 | 機器環境級別的隔離 | 可根據文件的系統權限靈活設置可見性 |
| 啟動參數 | 進程級別隔離 | 能進入系統便可見 |
| 環境變量 | 可根據容器、系統、用戶、進程進行非常靈活的搭配 | 可設置到系統用戶級別 |
| 配置管理系統 | 程序員可自由編程實現，一般是服務級別的隔離性 | 取決於不同產品的實現，有的方案可以做到安全性最好 |
這裏作者想額外強調的是安全性這一個點，尤其某些金融場景。原生的配置方式，如果不做代碼的改動的話，都無法做到很高的安全性，但是在一些分布式產品中，尤其是一些雲產品內部，就可以做到很安全，具體可以參考下圖：
以 Nacos 的雲上實現 ACM 為例，對上圖進行一個簡單的闡述。一般的程序讀取配置方式如左圖，當執行啟動腳本後，應用程序從腳本中設置的環境變量、文件或啟動參數中獲取配置。這些方式可以滿足大部分的場景，但是如果你的應用是一個分布式的大集群，這個時候如果想改一個配置是不可能在機器上配置的，然後一臺臺的區修改，此時我們需要一個支持大集群的分布式配置服務來支持。開源的配置中心有很多，如 ZooKeeper、etcd、Nacos 等。
但是有一種場景，一般意義上的配置中心也是滿足不了的，那就是諸如數據庫密碼這一類安全性要求很高的配置。這類在雲上會有一些很好的實現，以上圖右邊為例解釋一下在雲上是如何做到的：
- 當用戶往配置服務中寫入一個配置時，會先使用加密服務進行加密，圖中的 A。
- 如果有客戶端需要，將相應的加密數據推往對應的客戶端，圖中的 B。
- 客戶端收到數據，會根據機器上的_雲角色_，請求雲加密服務進行解密，圖中的 C。
從上面這個描述，我們就能很感受到整個過程，利用雲生態的能力，可以做得很優雅、很安全，而且也沒有額外的代碼侵入。
總結
寫到這裏，我需要點一下題，要做到 “Be Cloud Native” ，配置是必不可少的一個環節。能讓我們的世界變得稍微美好點的方式之一，就是把每個硬編碼的字符，變成一個個可運維、安全的配置。
同時在雲上，我們會看到有不一樣的、更加優雅、更安全、成本更低的解決方案。配置的安全無小事，一時圖簡單省事，可能就會造成生產級別的敏感信息、甚至 DB 的泄露。
Be Cloud Native 的另外一層意思，正是盡可能多的利用雲廠商提供的原生技術能力，來構建一個更安全、優雅、可擴展、高可用的應用架構。
程序員如何讓自己 Be Cloud Native - 配置篇