⑴ 如何用Nginx快速搭建一個安全的微服務架構
教你如何用Nginx搭建一個安全的、快速的微服務架構
今天我們要談論微服務以及如何使用Nginx構建一個快速的、安全的網路系統。最後，我們將向您展示一個使用Fabric模式如何非常快速和輕松地構建一個微服務的demo。
在我們探討Fabric模式之前，我想談一談微服務並且從Nginx的角度來看這意味著什麼。
0：56 - 大轉變
微服務已經引起了應用程序架構的重大轉變。
當我第一次開始構建應用程序時，他們都是差不多的。幻燈片中所展示的單體架構也象徵了應用程序的構造方式。
目前存在著某種類型的虛擬機（VM），對我來說，就是通常的Java。在虛擬機中應用的功能組件以對象的形式存在，這些對象是在內存中相互通訊的，它們將來來回回處理並進行方法調用。偶爾，你會採用諸如通知等機制來接觸到其他系統以便獲取數據或傳遞信息。
有了微服務之後，應用程序如何構建的範式是完全不同的了。你的功能組件會從在同一個主機的內存中通過虛擬機相互通訊轉變到部署在容器中，並且使用Restful API調用通過HTTP來相互連接。
這是非常強大的，因為它賦予了你功能隔離。它為您提供了更細粒度的可伸縮性，並且你可以獲得更好地處理故障的彈性。很多情況下這是簡單的事實，你只需要使用HTTP進行跨網路調用。
現在，這種方法也有一些缺點。
一件軼事
我有一個暗黑的秘密，我是一個微軟的員工並且從事.Net開發已經很多年了。當我在那兒的時候，我搭建了一個他們的名為Showcase的視頻發布平台。
Showcase是一個用來將微軟內部發布的所有視頻發布到網上的工具。人們可以觀看這些視頻並進行學習，比如Microsoft Word的使用提示和技巧。這是一個非常受歡迎的平台，我們有很多人使用它，並且其中很多人都會在我們發布的視頻上發表評論。
Showcase從一開始就是一個.Net單體應用，隨著它日益受歡迎，我們決定應該將它更換為SOA架構。轉換是相對容易的。Visual Studio提供了本質上的翻轉開關的能力，也就是將你的DLL調用轉變為Restful API調用。隨著一些小的重構，我們能夠讓我們的代碼運行得相當好。我們也為這些評論和應用內的社區功能使用智能社區服務。
緊密的迴路問題
看起來我們是SOA可行的，在我們的首次測試中，一切都工作正常，直到我們將系統切換到我們的Staging環境並開始使用生產環境數據時，我們就會看到一些嚴重的問題。這些問題在在頁面上有很多評論。
這是一個非常受歡迎的平台，其中的一些頁面已經有多達2000條評論了。當我們深入這些問題時，我們意識到這些頁面需要花費一分鍾進行渲染的原因是因為智能社區服務首先需要填充用戶名，然後對每一個用戶名都需要發起一個對於用戶資料庫的網路調用來獲得用戶詳細信息並且填充在渲染頁面上。這是非常低效的，需要一到兩分鍾來渲染頁面，而在內存中進行通常只需要5到6秒鍾。
緩解
當我們經歷了發現和解決問題的過程後，我們最終通過一些措施來調整優化系統，比如對所有的請求進行分組。我們緩存了一些數據，最終我們優化了網路來真正的提高性能。
所以，這與微服務有什麼關系呢？對的，藉助於微服務，你基本上是採用SOA架構的，並且會將其放入超光速引擎中。在SOA架構中所有的對象都是包含在單個虛擬機中並且在其內部管理，在內存中相互通訊，而現在微服務中是使用HTTP進行數據交換的。
當這樣做沒有問題時，你會獲得很好的性能和線性可伸縮性。
Nginx能夠很好地與微服務工作
Nginx是一個你可以用來過渡到微服務的最佳工具之一。
關於Nginx和微服務的一些歷史。我們從一開始就參與了微服務運動，還是第一個從Docker Hub下載應用的，我們的客戶以及那些擁有一些世界上最大的微服務安裝量的最終用戶廣泛地在他們的基礎設施使用Nginx。
原因是Nginx很小、很快並且很可靠。
Nginx微服務參考架構
我們還致力於在Nginx內部使用微服務工作已經有一段時間了。這是一個我們已經搭建的程式化的Nginx微服務參考架構，目前正在AWS上運行。
我們擁有6個核心的微服務，它們都運行在Docker容器里。我們決定建立一個多語種的應用，所以每個容器都可以運行不同的語言，我們目前使用了Ruby、Python、PHP、Java和Node.js。
我們搭建了這個使用十二要素應用的系統，稍加修改，就會使其更好地為微服務工作從而可以替代Roku平台。稍後，我們將向您展示一個實際上運行在demo里的應用。
MRA的價值
為什麼我們要建立這樣一個參考的微服務架構呢？
我們建立這個參考架構是因為我們需要給我們的客戶提供構建微服務的藍圖，我們也想在微服務上下文中測試Nginx和Nginx Plus的功能，弄清楚如何才能更好地利用它的優勢。最後，我們要確保我們對於微服務生態系統以及其可以給我們提供什麼有一個深入的理解。
網路問題
讓我們回到我們討論的大轉變。
從將運行在內存里並且被虛擬機管理的你的應用的所有功能組件遷移到通過網路進行工作並且相互通訊的方式，你會本質上引入一系列為了應用有效工作需要你解決的問題。
第一你需要服務發現，第二，你需要在架構中為所有不同的實例進行負載均衡，然後還有第三個，你需要操心性能和安全。
無論是好是壞，這些問題密不可分，你必須做權衡，有希望的是我們有一個可以解決所有這些問題的解決方案。
讓我們更深入地看待每一個問題。
服務發現
讓我們來談談服務發現。在單體應用中，APP引擎會管理所有的對象關系，你永遠不必擔心一個對象與另一個對象的相對位置，你只需要簡單的調用一個方法，虛擬機會連接到對象實例，然後在調用完畢後銷毀。
然後有了微服務，你需要考慮那些服務的位置。不幸的是，這不是一個普遍的標准流程。您正在使用的各種服務注冊中心，無論是Zookeeper、Consul、etcd或者其它的，都會以不同的方式進行工作。在這個過程中，你需要注冊你的服務，還需要能夠讀取這些服務在哪裡並且可以被連接。
負載均衡
第二個問題是關於負載均衡的。當您擁有多個服務實例時，您希望能夠輕松地連接到它們，將您的請求在它們中高效地分發，並以最快的方式執行，所以不同實例之間的負載均衡是非常重要的問題。
不幸的是，最簡單形式的負載均衡是非常低效的。當你開始使用不同的更加復雜的方案做負載均衡時，它也變得更加復雜並且不易於管理。理想情況下，您希望您的開發人員能夠基於他們的應用程序的需求決定何種負載均衡方案。例如，如果你連接到一個有狀態的應用程序，你需要擁有持久化，這樣可以確保你的Session信息會被保留。
安全和快速通訊
也許微服務最令人生畏的領域是性能和安全。
當在內存中運行時，一切都很快。現在，運行在網路上就會慢了一個數量級。
被安全地包含在一個系統中的信息，通常是二進制格式的，現在會被用文本格式在網路上傳輸。現在是比較容易在網路上布置嗅探器並能夠監聽你的應用正在被移動的所有數據。
如果要在傳輸層加密數據，那麼會在連接速率和CPU使用率方面引入顯著的開銷。SSL/TLS在其全面實施階段需要九個步驟來初始化一個請求。當你的系統每天需要處理成千上萬、幾萬、數十萬或數百萬的請求時，這就成為性能的一個重要障礙了。
一個解決方案
我們已經在Nginx開發的一些解決方案，我們認為，會解決所有的這些問題，它賦予你健壯的服務發現、非常棒的用戶可配置負載均衡以及安全和快速加密。
網路架構
讓我們來談談你可以安裝和配置你的網路架構的各種方法。
我們提出了三種網路模型，它們本身並不相互排斥，但我們認為它們屬於多種格式的。這三種模式是Proxy模式、Router Mesh模式和Fabric模式——這是最復雜的，並在許多方面在其頭部進行負載均衡。
Proxy模式
Proxy模式完全聚焦於你的微服務應用的入站流量，並且事實上忽略內部通訊。
你會獲得Nginx提供的所有的HTTP流量管理方面的福利。你可以有SSL/TLS終止、流量整形和安全，並且藉助於最新版本的Nginx Plus和ModSecurity，你可以獲得WAF能力。
你也可以緩存，你可以將Nginx提供給你的單體應用的所有東西添加到你的微服務系統里，並且藉助於Nginx Plus，你可以實現服務發現。當你的API實例上下浮動時，Nginx Plus可以在負載均衡工具里動態地添加和減去它們。
Router Mesh模式
Router Mesh模式類似於Proxy模式，在其中我們有一個前端代理服務來管理接入流量，但它也在服務之間添加了集中式的負載均衡。
每個服務連接到集中式的Router Mesh，它管理不同服務之間的連接分發。Router Mesh模式還允許你在熔斷器模式中搭建，以便可以對你的應用添加彈性並允許你採取措施來監控和拉回你的失效的服務實例。
不幸的是，因為該模式增加了一個額外的環節，如果你不得不進行SSL/TLS加密，它事實上加劇了性能問題。這就是引入Fabric模式的原因。
Fabric模式
Fabric模式是將其頭部的所有東西翻轉的模式。
就像之前的另外兩個模式一樣，在前面會有一個代理伺服器來管理流入流量，但與Router Mesh模式不同的地方就是你用運行在每個容器里的Nginx Plus來替代了集中式的Router。
這個Nginx Plus實例對於所有的HTTP流量作為反向和正向代理，使用這個系統，你可以獲得服務發現、健壯的負載均衡和最重要的高性能加密網路。
我們將探討這是如何發生的，以及我們如何處理這項工作。讓我們先來看看一個服務如何連接和分發他們的請求結構的正常流程。
正常的流程
在這個圖中，你可以看到投資管理器需要跟用戶管理器通訊來獲取信息。投資管理器創建了一個HTTP客戶端，該客戶端針對服務注冊中心發起了一個DNS請求並獲得返回的一個IP地址，接著初始化了一個到用戶管理器的SSL/TLS連接，該連接需要通過九階段的協商或者是」握手」過程。一旦數據傳輸完畢，虛擬機會關閉連接並進行HTTP客戶端的垃圾回收。
整個過程就是這樣。這是相當簡單和易於理解的。當你把它分解成這些步驟時，您可以看到該模式是如何真正完成請求和響應過程的。
在Fabric模式中，我們已經改變了這一點。
Fabric模式的細節
你會注意到的第一件事是Nginx Plus是運行在每一個服務里的，並且應用程序代碼是在本地與Nginx Plus通信的。因為這些是本地連接，你不需要擔心加密問題。它們可以是從Java或者PHP代碼到Nginx Plus實例的HTTP請求，並且都是在容器內的本地HTTP請求。
你也注意到Nginx Plus會管理到服務注冊中心的連接，我們有一個解析器，通過非同步查詢注冊中心的DNS實例來獲取所有的用戶管理器實例，並且預先建立連接，這樣當Java服務需要從用戶管理器請求一些數據的時候，可以使用預先建立的連接。
持久的SSL/TLS連接
微服務之間的有狀態的、持久化的並且可以加密的連接是真正的益處。
記得在第一個圖中服務實例是如何通過一些流程的吧，比如創建HTTP客戶端、協商SSL/TLS連接、發起請求並關閉的嗎？在這里，Nginx預先建立了微服務之間的連接，並使用Keepalive特性，保持調用之間的持續連接，這樣你就不必為每一個請求處理SSL/TLS協商了。
本質上，我們創建了一個迷你的從服務到服務的VPN連接。在我們最初的測試中，我們發現連接速度增加了77%。
熔斷器Plus
在Fabric模式以及Router Mesh模式中，你也可以從創建和使用熔斷器模式中獲得好處。
本質上，您定義了一個在服務內部的活躍的健康檢查，並設置緩存，以便在服務不可用的情況下保留數據，從而獲得完整的熔斷器功能。
所以，現在我可以確定你認為Fabirc模式聽起來很酷，並且想在實際環境中躍躍欲試。
⑵ 如何搭建區域網伺服器
⑶ 你好，請問伺服器地址是填什麼
您好，很高興為您解答。
伺服器地址可以指ipv4地址，也可以為ipv6地址。
伺服器是指保存有該網路中所有主機的域名和對應IP地址，並具有將域名轉換為IP地址功能的伺服器。其中域名必須對應一個IP地址，一個域名可以有多個IP地址，而IP地址不一定有域名。
簡單的解釋就是：伺服器地址就是一個IP區，就像一個人有名字一樣，你的伺服器在網路供應商的網路中也要有一個名字，就是這一IP區就是你伺服器的名字。
每個電腦都有個ip地址，伺服器也有。但登錄伺服器大多都是用網址，通過伺服器解析，最後指向的還是是那個ip地址加一個訪問埠。
客戶端IP地址指的是用戶機所使用的IP地址。
伺服器IP地址是指提供各項服務的伺服器的Ip地址，即網路伺服器的IP地址。
客戶端IP地址和伺服器IP地址的分配沒有具體要求，但是在同一個網內IP地址不能重復，否則系統會提示IP地址沖突。
(3)創建微伺服器地址擴展閱讀：
IPv4，是互聯網協議（Internet Protocol，IP）的第四版，也是第一個被廣泛使用，構成現今互聯網技術的基礎的協議。地址長度：32位,4位元組。
IPv4通常用點分十進制記法書寫，例如192.168.0.1，其中的數字都是十進制的數字，中間用實心圓點分隔。
IPv6的優勢就在於它大大地擴展了地址的可用空間，IPv6地址有128位長。如果地球表面（含陸地和水面）都覆蓋著計算機，那麼IPv6允許每平方米擁有7*10^23個IP地址；如果地址分配的速率是每微秒100萬個，那麼需要10^19年才能將所有的地址分配完畢。
IPv6的128位地址通常寫成8組，每組為四個十六進制數的形式。比如：AD80:0000:0000:0000:ABAA:0000:00C2:0002 是一個合法的IPv6地址。
⑷ 微服務入門這一篇就夠了
剛開始進入軟體行業時還是單體應用的時代，前後端分離的概念都還沒普及，開發的時候需要花大量的時間在「強大」的JSP上面，那時候SOA已經算是新技術了。現在，微服務已經大行其道，有哪個互聯網產品不說自己是微服務架構呢？
但是，對於微服務的理解每個人都不太一樣，這篇文章主要是聊一聊我對微服務的理解以及如何搭建經典的微服務架構，目的是梳理一下自己的一些想法，如果存在不同看法的歡迎指正！
首先，什麼是微服務呢？
相對的，要理解什麼是微服務，那麼可以先理解什麼是單體應用，在沒有提出微服務的概念的「遠古」年代，一個軟體應用，往往會將應用所有功能都開發和打包在一起，那時候的一個B/S應用架構往往是這樣的：
但是，當用戶訪問量變大導致一台伺服器無法支撐時怎麼辦呢？加伺服器加負載均衡，架構就變成這樣了：
後面發現把靜態文件獨立出來，通過CDN等手段進行加速，可以提升應用的整體相應，單體應用的架構就變成：
上面3中架構都還是單體應用，只是在部署方面進行了優化，所以避免不了單體應用的根本的缺點：
我認為任何技術的演進都是有跡可循的，任何新技術的出現都是為了解決原有技術無法解決的需求，所以，微服務的出現就是因為原來單體應用架構已經無法滿足當前互聯網產品的技術需求。
在微服務架構之前還有一個概念：SOA（Service-Oriented Architecture）-面向服務的體系架構。我認為的SOA只是一個架構模型的方法論，並不是一個明確而嚴謹的架構標准，只是後面很多人將SOA與The Open Group的SOA參考模型等同了，認為嚴格按照TOG-SOA標準的才算真正的SOA架構。SOA就已經提出的面向服務的架構思想，所以微服務應該算是SOA的一種演進吧。
撇開架構先不說，什麼樣的服務才算微服務呢？
微服務架構，核心是為了解決應用微服務化之後的服務治理問題。
應用微服務化之後，首先遇到的第一個問題就是服務發現問題，一個微服務如何發現其他微服務呢？最簡單的方式就是每個微服務裡面配置其他微服務的地址，但是當微服務數量眾多的時候，這樣做明顯不現實。所以需要使用到微服務架構中的一個最重要的組件： 服務注冊中心 ，所有服務都注冊到服務注冊中心，同時也可以從服務注冊中心獲取當前可用的服務清單：
解決服務發現問題後，接著需要解決微服務分布式部署帶來的第二個問題：服務配置管理的問題。當服務數量超過一定程度之後，如果需要在每個服務裡面分別維護每一個服務的配置文件，運維人員估計要哭了。那麼，就需要用到微服務架構裡面第二個重要的組件： 配置中心 ，微服務架構就變成下面這樣了：
以上應用內部的服務治理，當客戶端或外部應用調用服務的時候怎麼處理呢？服務A可能有多個節點，服務A、服務B和服務C的服務地址都不同，服務授權驗證在哪裡做？這時，就需要使用到服務網關提供統一的服務入口，最終形成典型微服務架構：
上面是一個典型的微服務架構，當然微服務的服務治理還涉及很多內容，比如：
目前國內企業使用的微服務框架主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那兩年的停更嚴重打擊了開發人員對它的信心，Spring Cloud已經逐漸成為主流，比較兩個框架的優劣勢的文章在網上有很多，這里就不重復了，選擇什麼框架還是按業務需求來吧，業務框架決定技術框架。
Spring Cloud全家桶提供了各種各樣的組件，基本可以覆蓋微服務的服務治理的方方面面，以下列出了Spring Cloud一些常用組件：
本章節主要介紹如何基於Spring Cloud相關組件搭建一個典型的微服務架構。
首先，創建一個Maven父項目 spring-cloud-examples ，用於管理項目依賴包版本。由於Spring Cloud組件很多，為保證不同組件之間的兼容性，一般通過 spring-cloud-dependencies 統一管理Spring Cloud組件版本，而非每個組件單獨引入。
pom.xml配置如下：
參考上面業務服務A搭建另外一個業務服務B。
目前網上很多說是下一代微服務架構就是Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大廠加持所以呼聲更高。Service Mesh我接觸還不多，但是個人感覺並不一定能稱為下一代微服務架構，可能認為是服務治理的另外一種解決方案更合適，是否能夠取代當前的微服務架構還需要持續觀察。
⑸ 使用小米路由器3作為伺服器怎麼設置
如今的網路時代,很多人都想擁有自己的伺服器,不想花錢購買各種虛擬空間產品,而小米路由器3正好可以當做微型伺服器使用.使用小米路由器3作為伺服器的設置 方法 其實很簡單，下面由我告訴你!
使用小米路由器3作為伺服器的設置方法
首先,要把小米路由器3當伺服器玩的話,需要先開啟SSH功能!鏈接地址:位於"工具/原料"請按照官方提示開啟SSH功能，注意:開啟SSH功能將會失去保修!!
當按照官方提示步驟開啟SSH成功的時候,就需要使用到putty了(可以自行網路下載)
當下載好軟體解壓後,打開putty.exe按照圖片步驟去操作,IP地址為路由器IP地址,默認為192.168.31.1在這里我把路由器的IP修過成了192.168.31.2,所以我輸入的就是192.168.31.2
輸入完成,點擊"OPEN"之後會彈出類似命令行的窗口,然後就輸入賬號"root"並點擊回車 然後輸入密碼,密碼是你在ssh頁面裡面的那個ROOT密碼!輸入的時候不會顯示,輸入完後點擊回車,如果顯示" Welcome to XiaoQiang!",那麼就登錄成功了,不行的話就是密碼錯了,請重新嘗試!然後我們就可以下一步了!
輸入以下命令並點擊回車
vi /etc/sysapitpd/sysapihpd.conf
然後按著方向鍵下到尾部 編輯文本添加第五步的內容(可以在文本空白處隨便輸入英文字元,然後當左下角顯示"I"的時候便可以編輯,但需要刪除亂輸入的字元!若無意修改了其他文本,可以通過按Ctrl+Z鍵撤銷修過,然後重復上面的步驟)
server {
listen 8080;
server_name _;
access_log off;
location / {
root /extdisks/sda1/WEB;
index index.html index.htm;
}
error_page 404 404.html;
error_page 500 502 503 504 50x.html;
location = 50x.html {
root html;
}
}
這里提示一下:1. listen 後面的數字是端 口號 ,在訪問的時候需要用到!2. "root /extdisks/sda1/WEB"是指路由器後面USB介面接的U盤或者硬碟的路徑,WEB是U盤或者硬碟裡面的文件夾,這里的意思就是我把網頁文件都放在了U盤:/WEB 文件夾中3. index 是首選主頁文件4. error_page 是當伺服器發生錯誤的時候的自定義錯誤頁面，編輯後如圖所示
編輯完成第五步的內容後,按ESC鍵,左下角顯示"-",然後輸入大寫Z兩次(可以點擊大寫鎖定"Caps Lock"後雙擊Z鍵,又可以按住"Shift"然後雙擊Z鍵)然後輸入以下命令並點擊回車重啟配置
/etc/init.d/sysapihpd restart
注意不可以出現"error"字樣,不然就是出現錯誤了,灰常需要注意文本裡面的花括弧位置,看清楚再修改!!如圖為正常情況
當上面的步驟都完成後,相信內網已經可以訪問了 打開瀏覽器,輸入192.168.31.1:8080 (我的是192.168.31.200.1406)只是IP和埠號不同,這些都可以自定義的!需要現在連接路由器的U盤或硬碟中的WEB文件夾放入首頁文件,例如index.html,否則可能會顯示拒絕訪問PS:我一開始在嘗試的時候,改過很多次IP..
接下來需要設置的,便是外網訪問了...首先,要讓外網訪問就必須修過防火牆配置 在putty輸入
vi /etc/config/firewall
按著方向鍵下到最後一行,添加代碼
config rule 'htdwan'
option src 'wan'
option dest_port '8080'
option proto 'tcp'
option target 'ACCEPT'
option name ''\''hpd wan accept tcp port 8080'\'''
(我是以前弄的,所以,已經不是最後一行了"option dest_port "為埠號,可以自定義)然後用上面同樣的方法保存
重啟防火牆配置以使其生效
在putty輸入
/etc/init.d/firewall restart
如圖,然後就可以啦
最後一步,設置域名解析，打開路由器設置頁面,按照圖片提示設置，高級設置-DDNS
最後,通過外網鏈接訪問,成功!
END