程式設計師如何讓自己 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_)說起來，配置其實可以包含很多種，以 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 的另外一層意思，正是儘可能多的利用雲廠商提供的原生技術能力，來構建一個更安全、優雅、可擴充套件、高可用的應用架構。