前言

這是《程序員如何讓自己 Be Cloud Native》系列文章的第二篇，從第一篇的反饋來看，有些同學反饋十二要素太形式主義，不建議盲目跟從。作者認為任何理論和技術(shù)都需要有自己的觀點，這些觀點是建立在個體知識體系逐漸鍛煉出來的辯別能力之上的。Be Cloud Native這一系列的文章，會基于十二要素為理論基礎，加上作者在云計算誕生以來對于架構(gòu)的演進所觀察到的變化去分享自己的一些心得。

第一篇：倉庫與依賴。「傳送門」

實例

配置這個要素的核心思想就是代碼與數(shù)據(jù)隔離，一開始我們的軟件很小很小的時候，我們會可能直接把各種配置、甚至生產(chǎn)環(huán)境中的代碼直接寫在代碼中，配置甚至就是代碼的一部分？比如以下的這斷代碼就是這樣：

public boolean serviceConnectable() {return ping("edas.console.aliyun.com", 3);}

該方法實現(xiàn)一個本地是否可以連接到遠端 server 的功能。如果按照上面的代碼進行編寫，只能保證在公共云的環(huán)境達到想要的效果。該程序如果部署到了一個專有云或者 IDC 的環(huán)境中的時候，就需要改代碼了。

如果改成以下的方式，效果就會截然不同。那時如果程序部署到了一套新的環(huán)境中，只需改變edas.server.address?這個配置。

@Value("edas.server.address") private String remoteAddress;public boolean serviceConnectable() { return ping(remoteAddress, 3);}

定義與示例

這個例子應該比較貼近大家的日常，我們將上面這個例子往上提升一層，可以做出一個如下的初步定義：應用的行為(_Behavior_) = 代碼(_Code_) + 輸入(_Data_)。代碼是固定的，需要重新編譯分發(fā)，無法根據(jù)環(huán)境進行變化的；而輸入是活的。上面的例子，就是一個把?Code?中的一部分內(nèi)容抽離，變成?Data?的過程。做完這個變化之后，應用對變化的適應性就更強了。當然，這些?Data?有些是用戶輸入的，有些是系統(tǒng)啟動時就已經(jīng)確定的，后者是我們定義的?配置?，也是我們今天討論的主題。從這個層面(_Data_)說起來，配置其實可以包含很多種，以 Java 語言為例，至少分為以下幾種：

• 代碼中的文件配置: *.properties 文件。
• 機器上的文件配置 *.properties 文件。
• 通過 -D 參數(shù)指定的啟動參數(shù)。
• 環(huán)境變量。
• 配置管理系統(tǒng)，簡單的有 DB；比較流行的領域產(chǎn)品如 Nacos、ZooKeeper、ectd 等。

選擇多了，貌似世界就不那么美妙了，因為我們總是會陷入到“用什么”和“為什么”中去。作者的觀點是，在用什么之前，先弄清楚需求層面的兩點：

• 隔離粒度：每個版本不一樣？每臺機器不一樣？每個進程不一樣？
• 安全性：運維人員可見？開發(fā)人員可見？還是都不應該可見？

仔細討論上述兩點之前，我們舉幾個關(guān)于配置的例子：

• 程序版本號：從代碼?Release?(build) 開始，基本上就確定了；這一類配置基本上不存在變化的可能，即這一類配置的隔離粒度等同于?Code?。
• 某個前端組件的版本號：前端版本號有一個特點，就是變動很頻繁，尤其是在上線的過程中，發(fā)布三四個版本是很常見的現(xiàn)象；而且在上線的過程中，一般都會先灰度驗證，再進行現(xiàn)網(wǎng)發(fā)布。所以這類配置需要具備一個特點就是，可靈活變動與可按照環(huán)境（不同機器、不同流量）粒度發(fā)布。
• 服務器端口號：服務器的端口號是需要和進程綁定的，尤其在某些微服務場景；同一個服務，如果部署在同一臺機器上，必須準確的告知其他服務本服務的確切的地址和端口。
• 數(shù)據(jù)庫元信息配置：這種配置，同一套環(huán)境中的相同服務會是一樣的，而且其真實的值隱藏的越深越好，其他還有某些 AK/SK、用戶名密碼之類，每套環(huán)境會不一樣，同時不同的產(chǎn)品對待這類配置的安全性要求也可能不一樣。

歸納

通過上面例子簡單的論述，我們大致可以把相關(guān)的配置做如下的歸類：

配置項所在位置隔離性安全性

代碼文件	控制不同版本的軟件行為，等同于代碼、基本不會改動	所有有代碼權(quán)限的人員都可見
機器上的文件	機器環(huán)境級別的隔離	可根據(jù)文件的系統(tǒng)權(quán)限靈活設置可見性
啟動參數(shù)	進程級別隔離	能進入系統(tǒng)便可見
環(huán)境變量	可根據(jù)容器、系統(tǒng)、用戶、進程進行非常靈活的搭配	可設置到系統(tǒng)用戶級別
配置管理系統(tǒng)	程序員可自由編程實現(xiàn)，一般是服務級別的隔離性	取決于不同產(chǎn)品的實現(xiàn)，有的方案可以做到安全性最好

這里作者想額外強調(diào)的是安全性這一個點，尤其某些金融場景。原生的配置方式，如果不做代碼的改動的話，都無法做到很高的安全性，但是在一些分布式產(chǎn)品中，尤其是一些云產(chǎn)品內(nèi)部，就可以做到很安全，具體可以參考下圖：

以?Nacos?的云上實現(xiàn)?ACM?為例，對上圖進行一個簡單的闡述。一般的程序讀取配置方式如左圖，當執(zhí)行啟動腳本后，應用程序從腳本中設置的環(huán)境變量、文件或啟動參數(shù)中獲取配置。這些方式可以滿足大部分的場景，但是如果你的應用是一個分布式的大集群，這個時候如果想改一個配置是不可能在機器上配置的，然后一臺臺的區(qū)修改，此時我們需要一個支持大集群的分布式配置服務來支持。開源的配置中心有很多，如 ZooKeeper、etcd、Nacos 等。

但是有一種場景，一般意義上的配置中心也是滿足不了的，那就是諸如數(shù)據(jù)庫密碼這一類安全性要求很高的配置。這類在云上會有一些很好的實現(xiàn)，以上圖右邊為例解釋一下在云上是如何做到的：

• 當用戶往配置服務中寫入一個配置時，會先使用加密服務進行加密，圖中的 A。
• 如果有客戶端需要，將相應的加密數(shù)據(jù)推往對應的客戶端，圖中的 B。
• 客戶端收到數(shù)據(jù)，會根據(jù)機器上的_云角色_，請求云加密服務進行解密，圖中的 C。

從上面這個描述，我們就能很感受到整個過程，利用云生態(tài)的能力，可以做得很優(yōu)雅、很安全，而且也沒有額外的代碼侵入。

總結(jié)

寫到這里，我需要點一下題，要做到 “Be Cloud Native” ，配置是必不可少的一個環(huán)節(jié)。能讓我們的世界變得稍微美好點的方式之一，就是把每個硬編碼的字符，變成一個個可運維、安全的配置。

同時在云上，我們會看到有不一樣的、更加優(yōu)雅、更安全、成本更低的解決方案。配置的安全無小事，一時圖簡單省事，可能就會造成生產(chǎn)級別的敏感信息、甚至 DB 的泄露。

Be Cloud Native 的另外一層意思，正是盡可能多的利用云廠商提供的原生技術(shù)能力，來構(gòu)建一個更安全、優(yōu)雅、可擴展、高可用的應用架構(gòu)。

#阿里云開年Hi購季#幸運抽好禮！
點此抽獎：https://www.aliyun.com/acts/product-section-2019/yq-lottery?utm_content=g_1000042901

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的程序员如何让自己 Be Cloud Native - 配置篇的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。