程序員如何讓自己 Be Cloud Native - 配置篇

jackwang 發布于2019-06-21 16:54 / 1360人閱讀

摘要：前言這是程序員如何讓自己系列文章的第二篇，從第一篇的反饋來看，有些同學反饋十二要素太形式主義，不建議盲目跟從。第一篇倉庫與依賴。配置的安全無小事，一時圖簡單省事，可能就會造成生產級別的敏感信息甚至的泄露。

前言

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

本文作者：中間件小哥

閱讀原文

本文為云棲社區原創內容，未經允許不得轉載。

云服務器 GPU云服務器如何讓自己深度學習 cloud-native 如何讓云服務器定時跑程序如何自己制作小程序

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11475.html

這大概是今年介紹云原生最清晰明了的文章!

摘要：在本次上，京東云將在大會上為對云原生感興趣的研發和運維人員帶來利用延遲加載快速啟動容器的話題分享。今天聊的主角云原生也是一樣。 showImg(https://segmentfault.com/img/bVbtNqp?w=688&h=113); showImg(https://segmentfault.com/img/bVbtQaR?w=684&h=327); showImg(http...

andycall 2019-07-01 17:41 評論0 收藏0
這大概是今年介紹云原生最清晰明了的文章!

摘要：在本次上，京東云將在大會上為對云原生感興趣的研發和運維人員帶來利用延遲加載快速啟動容器的話題分享。今天聊的主角云原生也是一樣。 showImg(https://segmentfault.com/img/bVbtNqp?w=688&h=113); showImg(https://segmentfault.com/img/bVbtQaR?w=684&h=327); showImg(http...

StonePanda 2019-06-28 11:24 評論0 收藏0
springCloud學習2(服務發現)

摘要：服務消費者可以使用多種模型來發現服務。客戶端將定期與服務發現層進行通信，并刷新服務實例的緩存。為了達成目的，我們將要學習使用個不同的客戶端庫，服務消費者可以使用它們來和進行交互。本篇代碼存放于:github 一、服務發現架構 ??服務發現架構通常具有下面 4 個概念：服務注冊：服務如何使用服務發現代理進行注冊？服務地址的客戶端查找：服務客戶端查找服務信息的方法是什么？信息共享...

史占廣 2019-08-19 11:43 評論0 收藏0
Dubbo Cloud Native 之路的實踐與思考

摘要：可簡單地認為它是的擴展，負載均衡自然成為不可或缺的特性。是基于開發的服務代理組件，在使用場景中，它與和整合，打造具備服務動態更新和負載均衡能力的服務網關。類似的特性在項目也有體現，它是另一種高性能代理的方案，提供服務發現健康和負載均衡。摘要： Cloud Native 應用架構隨著云技術的發展受到業界特別重視和關注，尤其是 CNCF（Cloud Native Computing Fo...

niceforbear 2019-06-24 18:03 評論0 收藏0
【騰訊云峰會 Cloud Native 專場】微票兒的 Cloud Native 實踐之路

摘要：導讀在今年騰訊云峰會上，開源技術同樣是一大亮點。此文是微票時代技術副總裁楊森淼在現場有關微票兒的實踐之路分享的實錄。導讀在今年騰訊云峰會上，開源技術同樣是一大亮點。作為開源技術的集成平臺，Cloud Native 專場給各家提供了針對 OpenStack 應用以及背后填坑之路作深度探討的機會。此文是微票時代技術副總裁楊森淼在現場有關《微票兒的 Cloud Native 實踐之路》分...

mo0n1andin 2019-06-28 10:51 評論0 收藏0