如何來提高云原生數(shù)據(jù)的安全性？

限制訪問

成都網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)公司、微信開發(fā)、微信平臺小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。核心團(tuán)隊均擁有互聯(lián)網(wǎng)行業(yè)多年經(jīng)驗，服務(wù)眾多知名企業(yè)客戶；涵蓋的客戶類型包括：玻璃鋼雕塑等眾多領(lǐng)域，積累了大量豐富的經(jīng)驗，同時也獲得了客戶的一致好評！

那些需要訪問有價值數(shù)據(jù)的人員需要安置在更安全的環(huán)境下，并經(jīng)過適當(dāng)?shù)嘏嘤?xùn)，謹(jǐn)防留下錯誤的入口給系統(tǒng)的入侵者。這些工作人員需要接受專業(yè)的訓(xùn)練一來確保這一事件發(fā)生的可能性降為最低，而且那些需要訪問的數(shù)據(jù)要時刻進(jìn)行監(jiān)測。

高風(fēng)險數(shù)據(jù)

如果有些數(shù)據(jù)是高利的數(shù)據(jù)，如金融或會計數(shù)據(jù)，那么就要額外注意確保它有更高級別的保護(hù)措施。提升加密的水平以及增加數(shù)據(jù)監(jiān)測量可以保護(hù)數(shù)據(jù)達(dá)到期望的水平。

注意設(shè)備的安全性

限制訪問數(shù)據(jù)集的某些部分不應(yīng)該是大范下的，而且還要檢查用于訪問數(shù)據(jù)的平臺。有些移動應(yīng)用可以很容易管理，這意味著仍然要隱藏某些高風(fēng)險的數(shù)據(jù)，從而減少相關(guān)的風(fēng)險。

滿足用戶需求

同樣地，高風(fēng)險數(shù)據(jù)可能已經(jīng)被保護(hù)起來了，但它也可以限制可用的人員，以及可用的地方。這說明安全位置上的保護(hù)可以相對的少些，這樣安全漏洞就會少。現(xiàn)在隨著如金融方面的事情也在去中處理，安全事務(wù)變得越來越重要。完全保護(hù)系統(tǒng)不受所有攻擊是不可能的，采取措施降低這一風(fēng)險才是最先需要做的一步。

如何用Nginx快速搭建一個安全的微服務(wù)架構(gòu)

教你如何用Nginx搭建一個安全的、快速的微服務(wù)架構(gòu)

今天我們要談?wù)撐⒎?wù)以及如何使用Nginx構(gòu)建一個快速的、安全的網(wǎng)絡(luò)系統(tǒng)。最后，我們將向您展示一個使用Fabric模式如何非常快速和輕松地構(gòu)建一個微服務(wù)的demo。

在我們探討Fabric模式之前，我想談一談微服務(wù)并且從Nginx的角度來看這意味著什么。

0：56 - 大轉(zhuǎn)變

微服務(wù)已經(jīng)引起了應(yīng)用程序架構(gòu)的重大轉(zhuǎn)變。

當(dāng)我第一次開始構(gòu)建應(yīng)用程序時，他們都是差不多的?；脽羝兴故镜膯误w架構(gòu)也象征了應(yīng)用程序的構(gòu)造方式。

目前存在著某種類型的虛擬機(jī)（VM），對我來說，就是通常的Java。在虛擬機(jī)中應(yīng)用的功能組件以對象的形式存在，這些對象是在內(nèi)存中相互通訊的，它們將來來回回處理并進(jìn)行方法調(diào)用。偶爾，你會采用諸如通知等機(jī)制來接觸到其他系統(tǒng)以便獲取數(shù)據(jù)或傳遞信息。

有了微服務(wù)之后，應(yīng)用程序如何構(gòu)建的范式是完全不同的了。你的功能組件會從在同一個主機(jī)的內(nèi)存中通過虛擬機(jī)相互通訊轉(zhuǎn)變到部署在容器中，并且使用Restful API調(diào)用通過HTTP來相互連接。

這是非常強(qiáng)大的，因為它賦予了你功能隔離。它為您提供了更細(xì)粒度的可伸縮性，并且你可以獲得更好地處理故障的彈性。很多情況下這是簡單的事實，你只需要使用HTTP進(jìn)行跨網(wǎng)絡(luò)調(diào)用。

現(xiàn)在，這種方法也有一些缺點。

一件軼事

?

我有一個暗黑的秘密，我是一個微軟的員工并且從事.Net開發(fā)已經(jīng)很多年了。當(dāng)我在那兒的時候，我搭建了一個他們的名為Showcase的視頻發(fā)布平臺。

Showcase是一個用來將微軟內(nèi)部發(fā)布的所有視頻發(fā)布到網(wǎng)上的工具。人們可以觀看這些視頻并進(jìn)行學(xué)習(xí)，比如Microsoft Word的使用提示和技巧。這是一個非常受歡迎的平臺，我們有很多人使用它，并且其中很多人都會在我們發(fā)布的視頻上發(fā)表評論。

Showcase從一開始就是一個.Net單體應(yīng)用，隨著它日益受歡迎，我們決定應(yīng)該將它更換為SOA架構(gòu)。轉(zhuǎn)換是相對容易的。Visual Studio提供了本質(zhì)上的翻轉(zhuǎn)開關(guān)的能力，也就是將你的DLL調(diào)用轉(zhuǎn)變?yōu)镽estful API調(diào)用。隨著一些小的重構(gòu)，我們能夠讓我們的代碼運行得相當(dāng)好。我們也為這些評論和應(yīng)用內(nèi)的社區(qū)功能使用智能社區(qū)服務(wù)。

緊密的回路問題

?

看起來我們是SOA可行的，在我們的首次測試中，一切都工作正常，直到我們將系統(tǒng)切換到我們的Staging環(huán)境并開始使用生產(chǎn)環(huán)境數(shù)據(jù)時，我們就會看到一些嚴(yán)重的問題。這些問題在在頁面上有很多評論。

這是一個非常受歡迎的平臺，其中的一些頁面已經(jīng)有多達(dá)2000條評論了。當(dāng)我們深入這些問題時，我們意識到這些頁面需要花費一分鐘進(jìn)行渲染的原因是因為智能社區(qū)服務(wù)首先需要填充用戶名，然后對每一個用戶名都需要發(fā)起一個對于用戶數(shù)據(jù)庫的網(wǎng)絡(luò)調(diào)用來獲得用戶詳細(xì)信息并且填充在渲染頁面上。這是非常低效的，需要一到兩分鐘來渲染頁面，而在內(nèi)存中進(jìn)行通常只需要5到6秒鐘。

緩解

?

當(dāng)我們經(jīng)歷了發(fā)現(xiàn)和解決問題的過程后，我們最終通過一些措施來調(diào)整優(yōu)化系統(tǒng)，比如對所有的請求進(jìn)行分組。我們緩存了一些數(shù)據(jù)，最終我們優(yōu)化了網(wǎng)絡(luò)來真正的提高性能。

所以，這與微服務(wù)有什么關(guān)系呢？對的，借助于微服務(wù)，你基本上是采用SOA架構(gòu)的，并且會將其放入超光速引擎中。在SOA架構(gòu)中所有的對象都是包含在單個虛擬機(jī)中并且在其內(nèi)部管理，在內(nèi)存中相互通訊，而現(xiàn)在微服務(wù)中是使用HTTP進(jìn)行數(shù)據(jù)交換的。

當(dāng)這樣做沒有問題時，你會獲得很好的性能和線性可伸縮性。

Nginx能夠很好地與微服務(wù)工作

?

Nginx是一個你可以用來過渡到微服務(wù)的最佳工具之一。

關(guān)于Nginx和微服務(wù)的一些歷史。我們從一開始就參與了微服務(wù)運動，還是第一個從Docker Hub下載應(yīng)用的，我們的客戶以及那些擁有一些世界上最大的微服務(wù)安裝量的最終用戶廣泛地在他們的基礎(chǔ)設(shè)施使用Nginx。

原因是Nginx很小、很快并且很可靠。

Nginx微服務(wù)參考架構(gòu)

?

我們還致力于在Nginx內(nèi)部使用微服務(wù)工作已經(jīng)有一段時間了。這是一個我們已經(jīng)搭建的程式化的Nginx微服務(wù)參考架構(gòu)，目前正在AWS上運行。

我們擁有6個核心的微服務(wù)，它們都運行在Docker容器里。我們決定建立一個多語種的應(yīng)用，所以每個容器都可以運行不同的語言，我們目前使用了Ruby、Python、PHP、Java和Node.js。

我們搭建了這個使用十二要素應(yīng)用的系統(tǒng)，稍加修改，就會使其更好地為微服務(wù)工作從而可以替代Roku平臺。稍后，我們將向您展示一個實際上運行在demo里的應(yīng)用。

MRA的價值

?

為什么我們要建立這樣一個參考的微服務(wù)架構(gòu)呢？

我們建立這個參考架構(gòu)是因為我們需要給我們的客戶提供構(gòu)建微服務(wù)的藍(lán)圖，我們也想在微服務(wù)上下文中測試Nginx和Nginx Plus的功能，弄清楚如何才能更好地利用它的優(yōu)勢。最后，我們要確保我們對于微服務(wù)生態(tài)系統(tǒng)以及其可以給我們提供什么有一個深入的理解。

網(wǎng)絡(luò)問題

?

讓我們回到我們討論的大轉(zhuǎn)變。

從將運行在內(nèi)存里并且被虛擬機(jī)管理的你的應(yīng)用的所有功能組件遷移到通過網(wǎng)絡(luò)進(jìn)行工作并且相互通訊的方式，你會本質(zhì)上引入一系列為了應(yīng)用有效工作需要你解決的問題。

第一你需要服務(wù)發(fā)現(xiàn)，第二，你需要在架構(gòu)中為所有不同的實例進(jìn)行負(fù)載均衡，然后還有第三個，你需要操心性能和安全。

無論是好是壞，這些問題密不可分，你必須做權(quán)衡，有希望的是我們有一個可以解決所有這些問題的解決方案。

讓我們更深入地看待每一個問題。

服務(wù)發(fā)現(xiàn)

讓我們來談?wù)劮?wù)發(fā)現(xiàn)。在單體應(yīng)用中，APP引擎會管理所有的對象關(guān)系，你永遠(yuǎn)不必?fù)?dān)心一個對象與另一個對象的相對位置，你只需要簡單的調(diào)用一個方法，虛擬機(jī)會連接到對象實例，然后在調(diào)用完畢后銷毀。

然后有了微服務(wù)，你需要考慮那些服務(wù)的位置。不幸的是，這不是一個普遍的標(biāo)準(zhǔn)流程。您正在使用的各種服務(wù)注冊中心，無論是Zookeeper、Consul、etcd或者其它的，都會以不同的方式進(jìn)行工作。在這個過程中，你需要注冊你的服務(wù)，還需要能夠讀取這些服務(wù)在哪里并且可以被連接。

負(fù)載均衡

?

第二個問題是關(guān)于負(fù)載均衡的。當(dāng)您擁有多個服務(wù)實例時，您希望能夠輕松地連接到它們，將您的請求在它們中高效地分發(fā)，并以最快的方式執(zhí)行，所以不同實例之間的負(fù)載均衡是非常重要的問題。

不幸的是，最簡單形式的負(fù)載均衡是非常低效的。當(dāng)你開始使用不同的更加復(fù)雜的方案做負(fù)載均衡時，它也變得更加復(fù)雜并且不易于管理。理想情況下，您希望您的開發(fā)人員能夠基于他們的應(yīng)用程序的需求決定何種負(fù)載均衡方案。例如，如果你連接到一個有狀態(tài)的應(yīng)用程序，你需要擁有持久化，這樣可以確保你的Session信息會被保留。

安全和快速通訊

?

也許微服務(wù)最令人生畏的領(lǐng)域是性能和安全。

當(dāng)在內(nèi)存中運行時，一切都很快?，F(xiàn)在，運行在網(wǎng)絡(luò)上就會慢了一個數(shù)量級。

被安全地包含在一個系統(tǒng)中的信息，通常是二進(jìn)制格式的，現(xiàn)在會被用文本格式在網(wǎng)絡(luò)上傳輸?，F(xiàn)在是比較容易在網(wǎng)絡(luò)上布置嗅探器并能夠監(jiān)聽你的應(yīng)用正在被移動的所有數(shù)據(jù)。

如果要在傳輸層加密數(shù)據(jù)，那么會在連接速率和CPU使用率方面引入顯著的開銷。SSL/TLS在其全面實施階段需要九個步驟來初始化一個請求。當(dāng)你的系統(tǒng)每天需要處理成千上萬、幾萬、數(shù)十萬或數(shù)百萬的請求時，這就成為性能的一個重要障礙了。

一個解決方案

?

我們已經(jīng)在Nginx開發(fā)的一些解決方案，我們認(rèn)為，會解決所有的這些問題，它賦予你健壯的服務(wù)發(fā)現(xiàn)、非常棒的用戶可配置負(fù)載均衡以及安全和快速加密。

網(wǎng)絡(luò)架構(gòu)

?

讓我們來談?wù)勀憧梢园惭b和配置你的網(wǎng)絡(luò)架構(gòu)的各種方法。

我們提出了三種網(wǎng)絡(luò)模型，它們本身并不相互排斥，但我們認(rèn)為它們屬于多種格式的。這三種模式是Proxy模式、Router Mesh模式和Fabric模式——這是最復(fù)雜的，并在許多方面在其頭部進(jìn)行負(fù)載均衡。

Proxy模式

?

Proxy模式完全聚焦于你的微服務(wù)應(yīng)用的入站流量，并且事實上忽略內(nèi)部通訊。

你會獲得Nginx提供的所有的HTTP流量管理方面的福利。你可以有SSL/TLS終止、流量整形和安全，并且借助于最新版本的Nginx Plus和ModSecurity，你可以獲得WAF能力。

你也可以緩存，你可以將Nginx提供給你的單體應(yīng)用的所有東西添加到你的微服務(wù)系統(tǒng)里，并且借助于Nginx Plus，你可以實現(xiàn)服務(wù)發(fā)現(xiàn)。當(dāng)你的API實例上下浮動時，Nginx Plus可以在負(fù)載均衡工具里動態(tài)地添加和減去它們。

Router Mesh模式

?

Router Mesh模式類似于Proxy模式，在其中我們有一個前端代理服務(wù)來管理接入流量，但它也在服務(wù)之間添加了集中式的負(fù)載均衡。

每個服務(wù)連接到集中式的Router Mesh，它管理不同服務(wù)之間的連接分發(fā)。Router Mesh模式還允許你在熔斷器模式中搭建，以便可以對你的應(yīng)用添加彈性并允許你采取措施來監(jiān)控和拉回你的失效的服務(wù)實例。

不幸的是，因為該模式增加了一個額外的環(huán)節(jié)，如果你不得不進(jìn)行SSL/TLS加密，它事實上加劇了性能問題。這就是引入Fabric模式的原因。

Fabric模式

?

Fabric模式是將其頭部的所有東西翻轉(zhuǎn)的模式。

就像之前的另外兩個模式一樣，在前面會有一個代理服務(wù)器來管理流入流量，但與Router Mesh模式不同的地方就是你用運行在每個容器里的Nginx Plus來替代了集中式的Router。

這個Nginx Plus實例對于所有的HTTP流量作為反向和正向代理，使用這個系統(tǒng)，你可以獲得服務(wù)發(fā)現(xiàn)、健壯的負(fù)載均衡和最重要的高性能加密網(wǎng)絡(luò)。

我們將探討這是如何發(fā)生的，以及我們?nèi)绾翁幚磉@項工作。讓我們先來看看一個服務(wù)如何連接和分發(fā)他們的請求結(jié)構(gòu)的正常流程。

正常的流程

?

在這個圖中，你可以看到投資管理器需要跟用戶管理器通訊來獲取信息。投資管理器創(chuàng)建了一個HTTP客戶端，該客戶端針對服務(wù)注冊中心發(fā)起了一個DNS請求并獲得返回的一個IP地址，接著初始化了一個到用戶管理器的SSL/TLS連接，該連接需要通過九階段的協(xié)商或者是”握手”過程。一旦數(shù)據(jù)傳輸完畢，虛擬機(jī)會關(guān)閉連接并進(jìn)行HTTP客戶端的垃圾回收。

整個過程就是這樣。這是相當(dāng)簡單和易于理解的。當(dāng)你把它分解成這些步驟時，您可以看到該模式是如何真正完成請求和響應(yīng)過程的。

在Fabric模式中，我們已經(jīng)改變了這一點。

Fabric模式的細(xì)節(jié)

?

你會注意到的第一件事是Nginx Plus是運行在每一個服務(wù)里的，并且應(yīng)用程序代碼是在本地與Nginx Plus通信的。因為這些是本地連接，你不需要擔(dān)心加密問題。它們可以是從Java或者PHP代碼到Nginx Plus實例的HTTP請求，并且都是在容器內(nèi)的本地HTTP請求。

你也注意到Nginx Plus會管理到服務(wù)注冊中心的連接，我們有一個解析器，通過異步查詢注冊中心的DNS實例來獲取所有的用戶管理器實例，并且預(yù)先建立連接，這樣當(dāng)Java服務(wù)需要從用戶管理器請求一些數(shù)據(jù)的時候，可以使用預(yù)先建立的連接。

持久的SSL/TLS連接

?

微服務(wù)之間的有狀態(tài)的、持久化的并且可以加密的連接是真正的益處。

記得在第一個圖中服務(wù)實例是如何通過一些流程的吧，比如創(chuàng)建HTTP客戶端、協(xié)商SSL/TLS連接、發(fā)起請求并關(guān)閉的嗎？在這里，Nginx預(yù)先建立了微服務(wù)之間的連接，并使用Keepalive特性，保持調(diào)用之間的持續(xù)連接，這樣你就不必為每一個請求處理SSL/TLS協(xié)商了。

本質(zhì)上，我們創(chuàng)建了一個迷你的從服務(wù)到服務(wù)的VPN連接。在我們最初的測試中，我們發(fā)現(xiàn)連接速度增加了77%。

熔斷器Plus

?

在Fabric模式以及Router Mesh模式中，你也可以從創(chuàng)建和使用熔斷器模式中獲得好處。

本質(zhì)上，您定義了一個在服務(wù)內(nèi)部的活躍的健康檢查，并設(shè)置緩存，以便在服務(wù)不可用的情況下保留數(shù)據(jù)，從而獲得完整的熔斷器功能。

所以，現(xiàn)在我可以確定你認(rèn)為Fabirc模式聽起來很酷，并且想在實際環(huán)境中躍躍欲試。

如何保證微服務(wù)接口的安全

上一篇 Nginx與網(wǎng)關(guān)的區(qū)別

下一篇 Gateway網(wǎng)關(guān)轉(zhuǎn)發(fā)demo

推薦閱讀：

網(wǎng)關(guān)背景分類及常用框架

微服務(wù)網(wǎng)關(guān)與過濾器的區(qū)別

Nginx與Zuul的區(qū)別

Zuul與Gateway有哪些區(qū)別

Nginx與網(wǎng)關(guān)的區(qū)別

Gateway網(wǎng)關(guān)轉(zhuǎn)發(fā)demo

Zuul的反向代理、過濾及動態(tài)網(wǎng)關(guān)配置實例

Gateway高可用集群與動態(tài)網(wǎng)關(guān)

Gateway的謂詞配置實例

Gateway配置及流程分析