資訊專欄INFORMATION COLUMN
摘要：前言這是程序員如何讓自己系列文章的第二篇，從第一篇的反饋來看，有些同學(xué)反饋十二要素太形式主義，不建議盲目跟從。第一篇倉庫與依賴。配置的安全無小事，一時(shí)圖簡單省事，可能就會(huì)造成生產(chǎn)級(jí)別的敏感信息甚至的泄露。
前言
這是《程序員如何讓自己 Be Cloud Native》系列文章的第二篇，從第一篇的反饋來看，有些同學(xué)反饋十二要素太形式主義，不建議盲目跟從。作者認(rèn)為任何理論和技術(shù)都需要有自己的觀點(diǎn)，這些觀點(diǎn)是建立在個(gè)體知識(shí)體系逐漸鍛煉出來的辯別能力之上的。Be Cloud Native這一系列的文章，會(huì)基于十二要素為理論基礎(chǔ)，加上作者在云計(jì)算誕生以來對(duì)于架構(gòu)的演進(jìn)所觀察到的變化去分享自己的一些心得。
第一篇：倉庫與依賴?！競魉烷T」
實(shí)例配置這個(gè)要素的核心思想就是代碼與數(shù)據(jù)隔離，一開始我們的軟件很小很小的時(shí)候，我們會(huì)可能直接把各種配置、甚至生產(chǎn)環(huán)境中的代碼直接寫在代碼中，配置甚至就是代碼的一部分？比如以下的這斷代碼就是這樣：
public boolean serviceConnectable() {
return ping("edas.console.aliyun.com", 3);
}
該方法實(shí)現(xiàn)一個(gè)本地是否可以連接到遠(yuǎn)端 server 的功能。如果按照上面的代碼進(jìn)行編寫，只能保證在公共云的環(huán)境達(dá)到想要的效果。該程序如果部署到了一個(gè)專有云或者 IDC 的環(huán)境中的時(shí)候，就需要改代碼了。
如果改成以下的方式，效果就會(huì)截然不同。那時(shí)如果程序部署到了一套新的環(huán)境中，只需改變edas.server.address?這個(gè)配置。
@Value("edas.server.address")
private String remoteAddress;
public boolean serviceConnectable() {
return ping(remoteAddress, 3);
}
定義與示例
這個(gè)例子應(yīng)該比較貼近大家的日常，我們將上面這個(gè)例子往上提升一層，可以做出一個(gè)如下的初步定義：應(yīng)用的行為(_Behavior_) = 代碼(_Code_) + 輸入(_Data_)。代碼是固定的，需要重新編譯分發(fā)，無法根據(jù)環(huán)境進(jìn)行變化的；而輸入是活的。上面的例子，就是一個(gè)把?Code?中的一部分內(nèi)容抽離，變成?Data?的過程。做完這個(gè)變化之后，應(yīng)用對(duì)變化的適應(yīng)性就更強(qiáng)了。當(dāng)然，這些?Data?有些是用戶輸入的，有些是系統(tǒng)啟動(dòng)時(shí)就已經(jīng)確定的，后者是我們定義的?配置?，也是我們今天討論的主題。從這個(gè)層面(_Data_)說起來，配置其實(shí)可以包含很多種，以 Java 語言為例，至少分為以下幾種：
代碼中的文件配置: *.properties 文件。
機(jī)器上的文件配置 *.properties 文件。
通過 -D 參數(shù)指定的啟動(dòng)參數(shù)。
環(huán)境變量。
配置管理系統(tǒng)，簡單的有 DB；比較流行的領(lǐng)域產(chǎn)品如 Nacos、ZooKeeper、ectd 等。
選擇多了，貌似世界就不那么美妙了，因?yàn)槲覀兛偸菚?huì)陷入到“用什么”和“為什么”中去。作者的觀點(diǎn)是，在用什么之前，先弄清楚需求層面的兩點(diǎn)：
隔離粒度：每個(gè)版本不一樣？每臺(tái)機(jī)器不一樣？每個(gè)進(jìn)程不一樣？
安全性：運(yùn)維人員可見？開發(fā)人員可見？還是都不應(yīng)該可見？
仔細(xì)討論上述兩點(diǎn)之前，我們舉幾個(gè)關(guān)于配置的例子：
程序版本號(hào)：從代碼?Release?(build) 開始，基本上就確定了；這一類配置基本上不存在變化的可能，即這一類配置的隔離粒度等同于?Code?。
某個(gè)前端組件的版本號(hào)：前端版本號(hào)有一個(gè)特點(diǎn)，就是變動(dòng)很頻繁，尤其是在上線的過程中，發(fā)布三四個(gè)版本是很常見的現(xiàn)象；而且在上線的過程中，一般都會(huì)先灰度驗(yàn)證，再進(jìn)行現(xiàn)網(wǎng)發(fā)布。所以這類配置需要具備一個(gè)特點(diǎn)就是，可靈活變動(dòng)與可按照環(huán)境（不同機(jī)器、不同流量）粒度發(fā)布。
服務(wù)器端口號(hào)：服務(wù)器的端口號(hào)是需要和進(jìn)程綁定的，尤其在某些微服務(wù)場景；同一個(gè)服務(wù)，如果部署在同一臺(tái)機(jī)器上，必須準(zhǔn)確的告知其他服務(wù)本服務(wù)的確切的地址和端口。
數(shù)據(jù)庫元信息配置：這種配置，同一套環(huán)境中的相同服務(wù)會(huì)是一樣的，而且其真實(shí)的值隱藏的越深越好，其他還有某些 AK/SK、用戶名密碼之類，每套環(huán)境會(huì)不一樣，同時(shí)不同的產(chǎn)品對(duì)待這類配置的安全性要求也可能不一樣。
歸納通過上面例子簡單的論述，我們大致可以把相關(guān)的配置做如下的歸類：
| 配置項(xiàng)所在位置 | 隔離性 | 安全性 |
|---|---|---|
| 代碼文件 | 控制不同版本的軟件行為，等同于代碼、基本不會(huì)改動(dòng) | 所有有代碼權(quán)限的人員都可見 |
| 機(jī)器上的文件 | 機(jī)器環(huán)境級(jí)別的隔離 | 可根據(jù)文件的系統(tǒng)權(quán)限靈活設(shè)置可見性 |
| 啟動(dòng)參數(shù) | 進(jìn)程級(jí)別隔離 | 能進(jìn)入系統(tǒng)便可見 |
| 環(huán)境變量 | 可根據(jù)容器、系統(tǒng)、用戶、進(jìn)程進(jìn)行非常靈活的搭配 | 可設(shè)置到系統(tǒng)用戶級(jí)別 |
| 配置管理系統(tǒng) | 程序員可自由編程實(shí)現(xiàn)，一般是服務(wù)級(jí)別的隔離性 | 取決于不同產(chǎn)品的實(shí)現(xiàn)，有的方案可以做到安全性最好 |
這里作者想額外強(qiáng)調(diào)的是安全性這一個(gè)點(diǎn)，尤其某些金融場景。原生的配置方式，如果不做代碼的改動(dòng)的話，都無法做到很高的安全性，但是在一些分布式產(chǎn)品中，尤其是一些云產(chǎn)品內(nèi)部，就可以做到很安全，具體可以參考下圖：
以?Nacos?的云上實(shí)現(xiàn)?ACM?為例，對(duì)上圖進(jìn)行一個(gè)簡單的闡述。一般的程序讀取配置方式如左圖，當(dāng)執(zhí)行啟動(dòng)腳本后，應(yīng)用程序從腳本中設(shè)置的環(huán)境變量、文件或啟動(dòng)參數(shù)中獲取配置。這些方式可以滿足大部分的場景，但是如果你的應(yīng)用是一個(gè)分布式的大集群，這個(gè)時(shí)候如果想改一個(gè)配置是不可能在機(jī)器上配置的，然后一臺(tái)臺(tái)的區(qū)修改，此時(shí)我們需要一個(gè)支持大集群的分布式配置服務(wù)來支持。開源的配置中心有很多，如 ZooKeeper、etcd、Nacos 等。
但是有一種場景，一般意義上的配置中心也是滿足不了的，那就是諸如數(shù)據(jù)庫密碼這一類安全性要求很高的配置。這類在云上會(huì)有一些很好的實(shí)現(xiàn)，以上圖右邊為例解釋一下在云上是如何做到的：
當(dāng)用戶往配置服務(wù)中寫入一個(gè)配置時(shí)，會(huì)先使用加密服務(wù)進(jìn)行加密，圖中的 A。
如果有客戶端需要，將相應(yīng)的加密數(shù)據(jù)推往對(duì)應(yīng)的客戶端，圖中的 B。
客戶端收到數(shù)據(jù)，會(huì)根據(jù)機(jī)器上的_云角色_，請(qǐng)求云加密服務(wù)進(jìn)行解密，圖中的 C。
從上面這個(gè)描述，我們就能很感受到整個(gè)過程，利用云生態(tài)的能力，可以做得很優(yōu)雅、很安全，而且也沒有額外的代碼侵入。
總結(jié)寫到這里，我需要點(diǎn)一下題，要做到 “Be Cloud Native” ，配置是必不可少的一個(gè)環(huán)節(jié)。能讓我們的世界變得稍微美好點(diǎn)的方式之一，就是把每個(gè)硬編碼的字符，變成一個(gè)個(gè)可運(yùn)維、安全的配置。
同時(shí)在云上，我們會(huì)看到有不一樣的、更加優(yōu)雅、更安全、成本更低的解決方案。配置的安全無小事，一時(shí)圖簡單省事，可能就會(huì)造成生產(chǎn)級(jí)別的敏感信息、甚至 DB 的泄露。
Be Cloud Native 的另外一層意思，正是盡可能多的利用云廠商提供的原生技術(shù)能力，來構(gòu)建一個(gè)更安全、優(yōu)雅、可擴(kuò)展、高可用的應(yīng)用架構(gòu)。
閱讀原文
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/11475.html
摘要：在本次上，京東云將在大會(huì)上為對(duì)云原生感興趣的研發(fā)和運(yùn)維人員帶來利用延遲加載快速啟動(dòng)容器的話題分享。今天聊的主角云原生也是一樣。 showImg(https://segmentfault.com/img/bVbtNqp?w=688&h=113); showImg(https://segmentfault.com/img/bVbtQaR?w=684&h=327); showImg(http...
摘要：在本次上，京東云將在大會(huì)上為對(duì)云原生感興趣的研發(fā)和運(yùn)維人員帶來利用延遲加載快速啟動(dòng)容器的話題分享。今天聊的主角云原生也是一樣。 showImg(https://segmentfault.com/img/bVbtNqp?w=688&h=113); showImg(https://segmentfault.com/img/bVbtQaR?w=684&h=327); showImg(http...
摘要：服務(wù)消費(fèi)者可以使用多種模型來發(fā)現(xiàn)服務(wù)?？蛻舳藢⒍ㄆ谂c服務(wù)發(fā)現(xiàn)層進(jìn)行通信，并刷新服務(wù)實(shí)例的緩存。為了達(dá)成目的，我們將要學(xué)習(xí)使用個(gè)不同的客戶端庫，服務(wù)消費(fèi)者可以使用它們來和進(jìn)行交互。 本篇代碼存放于:github 一、服務(wù)發(fā)現(xiàn)架構(gòu) ??服務(wù)發(fā)現(xiàn)架構(gòu)通常具有下面 4 個(gè)概念： 服務(wù)注冊(cè)：服務(wù)如何使用服務(wù)發(fā)現(xiàn)代理進(jìn)行注冊(cè)？ 服務(wù)地址的客戶端查找：服務(wù)客戶端查找服務(wù)信息的方法是什么？ 信息共享...
摘要：可簡單地認(rèn)為它是的擴(kuò)展，負(fù)載均衡自然成為不可或缺的特性。是基于開發(fā)的服務(wù)代理組件，在使用場景中，它與和整合，打造具備服務(wù)動(dòng)態(tài)更新和負(fù)載均衡能力的服務(wù)網(wǎng)關(guān)。類似的特性在項(xiàng)目也有體現(xiàn)，它是另一種高性能代理的方案，提供服務(wù)發(fā)現(xiàn)健康和負(fù)載均衡。 摘要： Cloud Native 應(yīng)用架構(gòu)隨著云技術(shù)的發(fā)展受到業(yè)界特別重視和關(guān)注，尤其是 CNCF（Cloud Native Computing Fo...
摘要：導(dǎo)讀在今年騰訊云峰會(huì)上，開源技術(shù)同樣是一大亮點(diǎn)。此文是微票時(shí)代技術(shù)副總裁楊森淼在現(xiàn)場有關(guān)微票兒的實(shí)踐之路分享的實(shí)錄。 導(dǎo)讀 在今年騰訊云峰會(huì)上，開源技術(shù)同樣是一大亮點(diǎn)。作為開源技術(shù)的集成平臺(tái)，Cloud Native 專場給各家提供了針對(duì) OpenStack 應(yīng)用以及背后填坑之路作深度探討的機(jī)會(huì)。此文是微票時(shí)代技術(shù)副總裁楊森淼在現(xiàn)場有關(guān)《微票兒的 Cloud Native 實(shí)踐之路》分...
閱讀 1815·2021-09-03 10:50
閱讀 1341·2019-08-30 15:55
閱讀 3386·2019-08-30 15:52
閱讀 1245·2019-08-30 15:44
閱讀 958·2019-08-30 15:44
閱讀 3329·2019-08-30 14:23
閱讀 3565·2019-08-28 17:51
閱讀 2301·2019-08-26 13:52
