雲伺服器與微服務

① 微服務架構：基於微服務和Docker容器技術的PaaS雲平台架構設計

基於微服務架構和Docker容器技術的PaaS雲平台建設目標是給我們的開發人員提供一套服務快速開發、部署、運維管理、持續開發持續集成的流程。平台提供基礎設施、中間件、數據服務、雲伺服器等資源，開發人員只需要開發業務代碼並提交到平台代碼庫，做一些必要的配置，系統會自動構建、部署，實現應用的敏捷開發、快速迭代。在系統架構上，PaaS雲平台主要分為微服務架構、Docker容器技術、DveOps三部分，這篇文章重點介紹微服務架構的實施。

如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。

實施微服務需要投入大量的技術力量來開發基礎設施，這對很多公司來說顯然是不現實的，別擔心，業界已經有非常優秀的開源框架供我們參考使用。目前業界比較成熟的微服務框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基於Spring Boot的一整套實現微服務的框架，它提供了開發微服務所需的組件，跟Spring Boot一起使用的話開發微服務架構的雲服務會變的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我們的微服務架構設計中，就使用了很多Spring Cloud Netflix框架的組件。Spring Cloud Netflix項目的時間還不長，相關的文檔資料很少，博主當時研究這套框架啃了很多英文文檔，簡直痛苦不堪。對於剛開始接觸這套框架的同學，要搭建一套微服務應用架構，可能會不知道如何下手，接下來介紹我們的微服務架構搭建過程以及 需要那些 框架或組件來支持微服務架構。

為了直接明了的展示微服務架構的組成及原理，畫了一張系統架構圖，如下：

從上圖可以看出，微服務訪問大致路徑為：外部請求 → 負載均衡 → 服務網關（GateWay）→ 微服務 → 數據服務/消息服務。服務網關和微服務都會用到服務注冊和發現來調用依賴的其他服務，各服務集群都能通過配置中心服務來獲得配置信息。

服務網關（GateWay）

網關是外界系統（如：客戶端瀏覽器、移動設備等）和企業內部系統之間的一道門，所有的客戶端請求通過網關訪問後台服務。為了應對高並發訪問，服務網關以集群形式部署，這就意味著需要做負載均衡，我們採用了亞馬遜EC2作為虛擬雲伺服器，採用ELB(Elastic Load Balancing)做負載均衡。EC2具有自動配置容量功能，當用戶流量達到尖峰，EC2可以自動增加更多的容量以維持虛擬主機的性能。ELB彈性負載均衡，在多個實例間自動分配應用的傳入流量。為了保證安全性，客戶端請求需要使用https加密保護，這就需要我們進行SSL卸載,使用Nginx對加密請求進行卸載處理。外部請求經過ELB負載均衡後路由到GateWay集群中的某個GateWay服務，由GateWay服務轉發到微服務。服務網關作為內部系統的邊界，它有以下基本能力：

1、動態路由：動態的將請求路由到所需要的後端服務集群。雖然內部是復雜的分布式微服務網狀結構，但是外部系統從網關看就像是一個整體服務，網關屏蔽了後端服務的復雜性。

2、限流和容錯：為每種類型的請求分配容量，當請求數量超過閥值時拋掉外部請求，限制流量，保護後台服務不被大流量沖垮；黨內部服務出現故障時直接在邊界創建一些響應，集中做容錯處理，而不是將請求轉發到內部集群，保證用戶良好的體驗。

3、身份認證和安全性控制：對每個外部請求進行用戶認證，拒絕沒有通過認證的請求，還能通過訪問模式分析，實現反爬蟲功能。

4、監控：網關可以收集有意義的數據和統計，為後台服務優化提供數據支持。

5、訪問日誌：網關可以收集訪問日誌信息，比如訪問的是哪個服務？處理過程（出現什麼異常）和結果？花費多少時間？通過分析日誌內容，對後台系統做進一步優化。

我們採用Spring Cloud Netflix框架的開源組件Zuul來實現網關服務。Zuul使用一系列不同類型的過濾器（Filter），通過重寫過濾器，使我們能夠靈活的實現網關（GateWay）的各種功能。

如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。

服務注冊與發現

由於微服務架構是由一系列職責單一的細粒度服務構成的網狀結構，服務之間通過輕量機制進行通信，這就引入了服務注冊與發現的問題，服務的提供方要注冊報告服務地址，服務調用放要能發現目標服務。我們的微服務架構中使用了Eureka組件來實現服務的注冊與發現。所有的微服務（通過配置Eureka服務信息）到Eureka伺服器中進行注冊，並定時發送心跳進行 健康 檢查，Eureka默認配置是30秒發送一次心跳，表明服務仍然處於存活狀態，發送心跳的時間間隔可以通過Eureka的配置參數自行配置，Eureka伺服器在接收到服務實例的最後一次心跳後，需要等待90秒（默認配置90秒，可以通過配置參數進行修改）後，才認定服務已經死亡（即連續3次沒有接收到心跳），在Eureka自我保護模式關閉的情況下會清除該服務的注冊信息。所謂的自我保護模式是指，出現網路分區、Eureka在短時間內丟失過多的服務時，會進入自我保護模式，即一個服務長時間沒有發送心跳，Eureka也不會將其刪除。自我保護模式默認為開啟，可以通過配置參數將其設置為關閉狀態。

Eureka服務以集群的方式部署（在博主的另一篇文章中詳細介紹了Eureka集群的部署方式），集群內的所有Eureka節點會定時自動同步微服務的注冊信息，這樣就能保證所有的Eureka服務注冊信息保持一致。那麼在Eureka集群里，Eureka節點是如何發現其他節點的呢？我們通過DNS伺服器來建立所有Eureka節點的關聯，在部署Eureka集群之外還需要搭建DNS伺服器。

當網關服務轉發外部請求或者是後台微服務之間相互調用時，會去Eureka伺服器上查找目標服務的注冊信息，發現目標服務並進行調用，這樣就形成了服務注冊與發現的整個流程。Eureka的配置參數數量很多，多達上百個，博主會在另外的文章里詳細說明。

微服務部署

微服務是一系列職責單一、細粒度的服務，是將我們的業務進行拆分為獨立的服務單元，伸縮性好，耦合度低，不同的微服務可以用不同的語言開發，每一個服務處理的單一的業務。微服務可以劃分為前端服務（也叫邊緣服務）和後端服務（也叫中間服務），前端服務是對後端服務做必要的聚合和剪裁後暴露給外部不同的設備（PC、Phone等），所有的服務啟動時都會到Eureka伺服器進行注冊，服務之間會有錯綜復雜的依賴關系。當網關服務轉發外部請求調用前端服務時，通過查詢服務注冊表就可以發現目標服務進行調用，前端服務調用後端服務時也是同樣的道理，一次請求可能涉及到多個服務之間的相互調用。由於每個微服務都是以集群的形式部署，服務之間相互調用的時候需要做負載均衡，因此每個服務中都有一個LB組件用來實現負載均衡。

微服務以鏡像的形式，運行在Docker容器中。Docker容器技術讓我們的服務部署變得簡單、高效。傳統的部署方式，需要在每台伺服器上安裝運行環境，如果我們的伺服器數量龐大，在每台伺服器上安裝運行環境將是一項無比繁重的工作，一旦運行環境發生改變，就不得不重新安裝，這簡直是災難性的。而使用Docker容器技術，我們只需要將所需的基礎鏡像（jdk等）和微服務生成一個新的鏡像，將這個最終的鏡像部署在Docker容器中運行，這種方式簡單、高效，能夠快速部署服務。每個Docker容器中可以運行多個微服務，Docker容器以集群的方式部署，使用Docker Swarm對這些容器進行管理。我們創建一個鏡像倉庫用來存放所有的基礎鏡像以及生成的最終交付鏡像，在鏡像倉庫中對所有鏡像進行管理。

服務容錯

微服務之間存在錯綜復雜的依賴關系，一次請求可能會依賴多個後端服務，在實際生產中這些服務可能會產生故障或者延遲，在一個高流量的系統中，一旦某個服務產生延遲，可能會在短時間內耗盡系統資源，將整個系統拖垮，因此一個服務如果不能對其故障進行隔離和容錯，這本身就是災難性的。我們的微服務架構中使用了Hystrix組件來進行容錯處理。Hystrix是Netflix的一款開源組件，它通過熔斷模式、隔離模式、回退（fallback）和限流等機制對服務進行彈性容錯保護，保證系統的穩定性。

1、熔斷模式：熔斷模式原理類似於電路熔斷器，當電路發生短路時，熔斷器熔斷，保護電路避免遭受災難性損失。當服務異常或者大量延時，滿足熔斷條件時服務調用方會主動啟動熔斷，執行fallback邏輯直接返回，不會繼續調用服務進一步拖垮系統。熔斷器默認配置服務調用錯誤率閥值為50%，超過閥值將自動啟動熔斷模式。服務隔離一段時間以後，熔斷器會進入半熔斷狀態，即允許少量請求進行嘗試，如果仍然調用失敗，則回到熔斷狀態，如果調用成功，則關閉熔斷模式。

2、隔離模式：Hystrix默認採用線程隔離，不同的服務使用不同的線程池，彼此之間不受影響，當一個服務出現故障耗盡它的線程池資源，其他的服務正常運行不受影響，達到隔離的效果。例如我們通過andThreadPoolKey配置某個服務使用命名為TestThreadPool的線程池，實現與其他命名的線程池隔離。

3、回退（fallback）：fallback機制其實是一種服務故障時的容錯方式，原理類似Java中的異常處理。只需要繼承HystixCommand並重寫getFallBack()方法，在此方法中編寫處理邏輯，比如可以直接拋異常（快速失敗），可以返回空值或預設值，也可以返回備份數據等。當服務調用出現異常時，會轉向執行getFallBack()。有以下幾種情況會觸發fallback：

1）程序拋出非HystrixBadRequestExcepption異常，當拋出HystrixBadRequestExcepption異常時，調用程序可以捕獲異常，沒有觸發fallback，當拋出其他異常時，會觸發fallback；

2）程序運行超時；

3）熔斷啟動；

4）線程池已滿。

4、限流： 限流是指對服務的並發訪問量進行限制，設置單位時間內的並發數，超出限制的請求拒絕並fallback，防止後台服務被沖垮。

Hystix使用命令模式HystrixCommand包裝依賴調用邏輯，這樣相關的調用就自動處於Hystrix的彈性容錯保護之下。調用程序需要繼承HystrixCommand並將調用邏輯寫在run()中，使用execute()（同步阻塞）或queue()（非同步非阻塞）來觸發執行run()。

動態配置中心

微服務有很多依賴配置，某些配置參數在服務運行期間可能還要動態修改，比如：根據訪問流量動態調整熔斷閥值。傳統的實現信息配置的方法，比如放在xml、yml等配置文件中，和應用一起打包，每次修改都要重新提交代碼、打包構建、生成新的鏡像、重新啟動服務，效率太低，這樣顯然是不合理的，因此我們需要搭建一個動態配置中心服務支持微服務動態配置。我們使用Spring Cloud的configserver服務幫我們實現動態配置中心的搭建。我們開發的微服務代碼都存放在git伺服器私有倉庫裡面，所有需要動態配置的配置文件存放在git伺服器下的configserver（配置中心，也是一個微服務）服務中，部署到Docker容器中的微服務從git伺服器動態讀取配置文件的信息。當本地git倉庫修改代碼後push到git伺服器倉庫，git服務端hooks(post-receive，在服務端完成代碼更新後會自動調用)自動檢測是否有配置文件更新，如果有，git服務端通過消息隊列給配置中心（configserver，一個部署在容器中的微服務）發消息，通知配置中心刷新對應的配置文件。這樣微服務就能獲取到最新的配置文件信息，實現動態配置。

以上這些框架或組件是支撐實施微服務架構的核心，在實際生產中，我們還會用到很多其他的組件，比如日誌服務組件、消息服務組件等等，根據業務需要自行選擇使用。在我們的微服務架構實施案例中，參考使用了很多Spring Cloud Netflix框架的開源組件，主要包括Zuul（服務網關）、Eureka（服務注冊與發現）、Hystrix（服務容錯）、Ribbon（客戶端負載均衡）等。這些優秀的開源組件，為我們實施微服務架構提供了捷徑。

如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。

② 微雲可能取代AWS、Azure和Google Cloud公共雲

雲計算市場的許多小規模提供商的雲計算服務和產品在速度、成本、靈活性，甚至在本地部署和混合雲選項方面都會對全球雲計算行業巨頭構成挑戰。

雲計算平台的規模一定很大，對吧?如果雲計算的最佳功能是用戶只需點擊幾秒鍾並啟動一台機器，那麼必然需要建設和運營部署大量伺服器的大量數據中心。

不過，「大」這個詞明迅念是相對的。規模最大的雲計算行業巨頭AWS、Microsoft Azure、谷歌雲可能會占據大部分市場份額，但它們並不能阻礙雲計算市場其他提供商的發展。一些規模較小的雲計算提供商正在開發利基市場，並採用其他的競爭方式，然而與雲計算行業巨頭相比，他們的伺服器數量確實微不足道。

人們普遍發現，這些「微不足道」的雲計算提供商也在全球范圍內運營著數十個數據中心，而這些數據中心也擁有足夠數量的伺服器，只是沒有雲計算巨頭那麼多。

事實證明，對於開發激困人員來說，規模並不總是最具吸引力的選擇。機器實例幾乎是運行在普通操作系統的普通硬體，軟體可以遷移以尋找更好的選擇。雲計算公司在用戶界面、復雜功能、速度等方面展開了競爭，有時甚至在規模、價格等看似明顯的優勢方面的雲計算巨頭也面臨一些競爭。

微服務架構的發展正在孕育更廣泛的雲計算市場。將工作負載分成N個不同部分的開發人員不需要將自己限制在一個雲平台中。當連續的數據包流正在傳輸時，保持軟體在同一數據中心運行是有意義的，但通常可能會將應用程序分解為許多鬆散鏈接的代碼塊，偶爾交換消息，並且不需要最快的響應速度。如果有充分的理由，後台處理和分析功能很容易轉移到不同的雲平台。如果企業在為系統創建體系結構時非常謹慎，甚至可以將每個微服務放在不同的雲平台上。

所有這一切都意味著雲計算之戰並不局限於規模最大化。以下是十幾個規模較小的雲計算提供商，他們的雲計算產品和服務也有自己獨特的優勢，它們都很吸引人，但並不是客戶唯一的選擇。當他們超越規模最大的競爭對手時，人們發現雲計算市場是一個令人驚訝的巨大和多樣化的市場。

1.Wasabi公司

2.Vultr公司

雲計算提供商Vultr公司通過以每小時2.50美元的價格提供最低價格的實例，按小時計費。這台機器只配備512KB的內存，適用於靜態Web伺服器，但用戶可以花費更多的費用購買更大的機器實例。

該公司已經擴展了其產品線，其中包括裸機伺服器，這些伺服器沒有虛擬化層的阻礙。還有專門的伺服器，可以減少與攻擊者共享同一個伺服器的威脅。Vultr公司在全球運營16個數據中心。其雲平台的界面很靈活，但是提供的服務有限並且比較基礎，可能提供的僅僅是命令行。如果用戶希望伺服器在引導時運行腳本，則可以使用一個很好的輸入欄位來鍵入腳本。但以每月2.50美元的價格計算，要求過高將是錯誤的。

3.UpCloud公司

UpCloud公司的亮點是提供持久硬碟存儲服務，該公司稱，它提供比SSD硬碟更快的性能。在啟動和持續性能方面甚至可能快50%。用戶必須測試其應用程序才能確定，因為速度將根據計算和數據獲取的混合而變化。

UpCloud的許多其他部分也令人熟悉。UpCloud在全球運行API、一昌乎系列標准模板和數據中心，其中兩個位於赫爾辛基的UpCloud公司總部附近。UpCloud提供公共雲託管、私有選項和一些軟體層來創建組合。軟體定義的網路很快就會到來。

其基本實例提供1GB內存和25GB硬碟存儲空間，起價為5美元，並以與競爭對手大致相同的方式向上擴展。UpCloud並不一定能提供更低的價格，但提供更快的磁碟訪問。

4.Packet公司

Packet可能規模相對較小，但它提供功能齊全的專門伺服器，它們以「裸機」運行客戶的應用程序。這意味著客戶的I/O和存儲操作不會因無限的虛擬化層而陷入困境(至少在客戶通過過度的容器化添加自己的虛擬化層之前，這是客戶的責任)。

客戶需要為採用Packet的機器支付更多費用，但其獲得回報更多。c1.large.arm機器配備128GB的內存和32個核心處理器，其價格是每小時1美元，在一個月內累計超過672小時。Packet還採用一些配置較低的伺服器，配備8 GB內存和4個核心處理器，每小時只需7美分。

其具備的一個很好的特性是現貨定價市場，客戶可以在那裡出價購買硬體。一些需求放緩時的價格似乎比清單上的價格便宜50%以上。Packet在全球運營18個數據中心，還提供RESTful API，以及使用企業的配置、安全和管理軟體的本地版本構建混合雲的大量選項。

5.Linode公司

另一家提供小型靈活的Linux機器root訪問許可權的雲計算提供商是Linode公司，其價格每月低至5美元。Linode公司支持全球9個數據中心的10個主要Linux發行版，其運營的第10個數據中心在印度孟買。

如果客戶需要安裝特定服務，Linode公司的用戶社區將共享大量啟動腳本，這些腳本將安裝正確的軟體並自定義配置。這些腳本涵蓋了大多數主要應用程序，如WordPress、Plesk、代理伺服器、OpenVPN和LAMP堆棧。客戶還可以創建自己構建的腳本。

6.Hidora公司

如果客戶使用一些標准模型(NoDE.JS、PHP、Java)部署Web應用程序，Hidora公司提供一個PaaS(平台即服務)來適應。該公司認為，其靈活的擴展以更好的價格提供了更好的性能。可以將負載平衡、備份和空閑出站帶寬等服務整合到捆綁包中。

Hidora是如何擴展和更新舊的共享託管模型以支持現代微服務架構的一個很好的例子。如果客戶想要獲得root訪問許可權，Hidora公司會提供虛擬專用伺服器，但客戶也可以將Docker容器部署到其Kubernetes集群。

Hidora將其伺服器部署在瑞士，並確保它們受到瑞士數據保護法的保護。

7.DigitalOcean公司

DigitalOcean之所以受到開發人員的歡迎，是因為它簡化了虛擬機的啟動、大小調整和拆除虛擬機的過程，DigitalOcean稱之為「Droplets」。在取得一些成功之後，該公司最近擴展了PostgreSQL資料庫的更多託管服務、數據桶和Kubernetes集群。Droplet按小時計費，但當月計費的小時數上限為672小時，即四周的小時數，因此每個月的價格都相同。該公司將其價格設置為5美元的倍數，使賬單計算更加簡單。DigitalOcean公司在全球8個城市擁有並運營12個數據中心。

8.Shared hosting公司

Shared hosting的雲服務由共享Web伺服器提供。客戶在LAMP伺服器上租借了一個帳戶，上傳了其HTML、JavaScript/HP，並按月支付費用，雖然不會給客戶提供root許可權，但有時會讓客戶使用Telnet。

許多專門提供這些服務的公司(IONOS、A2、BlueHost、HostGator、InMotion)已經逐漸擴展到雲伺服器業務，提供虛擬專用伺服器和專用伺服器。其計費通常按月計算，時間長達三年。

Shared hosting公司似乎對每隔幾個小時啟動和拆除機器以滿足需求飆升的客戶感興趣。盡管如此，它們仍然是一個靈活的選項，可用於小型專用項目。

9.Antsle公司

Antsle公司可能是規模最小的雲計算提供商。Antsle公司提供了一款無風扇伺服器，可以放在桌面上，通過客戶自己的「雲託管」儀錶板創建Gentoo Linux實例。這個伺服器小而安靜，提供雲計算的大部分靈活性和功能。其CPU功率取決於客戶購買的產品，客戶可以通過控制物理安全性和保持一切可見性來運行工作負載，從而獲得更大的工作量。

Antsle公司還正在為其支持其他硬體的軟體版本進行封閉測試。或者客戶也可以在裸機伺服器Antsle主機中使用相同的界面和軟體。