程序員如何讓本身 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 的另一層意思，正是儘量多的利用雲廠商提供的原生技術能力，來構建一個更安全、優雅、可擴展、高可用的應用架構。

 

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。