隨著移動網際網路時代的興起，提供高效能、高可用性、高擴充套件性的服務已經不僅僅是大公司的專利，而逐漸成為所有網際網路+公司的標配需求。本文介紹網易如何利用多年的網際網路架構經驗和網易蜂巢的平臺，幫助客戶進行架構改進、微服務化、效能調優。

傳統架構之痛

當前的時代稱為網際網路的時代，網際網路應用的特點往往是，新型的應用迅速出現顛覆舊的商業模式，一旦商業模式稍有起色便會有大量的廠商蜂擁而至，使得藍海變成紅海，經過短時間的殘酷競爭，熱度往往持續較短時間後，大量廠商退出市場，僅僅前二名到三名能夠存活下來，最終這一波浪潮被下一波取代。我們回想視訊網站，團購網站，社交網站，微博，打車，直播等，全都呈現這種模式。

所以網際網路市場只有一招，天下武功，唯快不破。

當一種商業模式出現的時候，為了迅速切入市場，佔領商業獻祭，快速驗證商業模式，往往軟體的設計會採取傳統的單體架構。

傳統的單體架構往往分三層，最下面一層是資料庫，中間是應用程式層，所有的商業邏輯都會在這一層，最上面是頁面。

如果商業模式比較成功，則應用會新增新的功能，一種方式是全部新增到原有的商業邏輯中，另一種方式是開發一個全新的三層結構來支撐新的功能。

由於是單體結構，一方面應用層裡面的功能越來越多，如圖中一個功能變為三個功能，將來可能三十個功能，另一方面很多程式碼和邏輯都不能複用，如圖中功能2，每個應用都有，這種功能常見的有認證模組，訊息的編碼和解碼模組等。

這種單體結構會帶來三方面靈活性比較差。

第一，時間靈活性：應用快速迭代，縮短客戶需求到產品上線的時間。

網際網路應用的需求隨時改變，因而應用開發的迭代速度要求會比較快，傳統的軟體可能半年或者一年釋出一個功能，而網際網路應用則可能每週都發布新的功能。而且網際網路產品會時常搞活動，比如雙十一，每次活動不可能提前很長時間策劃，從而給開發充分的產品週期。

然而單體結構的應用如果有了30個模組，每個模組由兩到三個人負責，則修改的成本會非常的大，從開發人員看來，整個架構牽一髮動全身，每次修改必須要做好良好的前期設計，並且讓整個團隊評審，如果新的需求要改多個模組，則程式碼的管理和合並就成為很大的問題。

而且無論測試，聯調，上線，擴充套件，縮減，升級，回滾都需要重新搭建環境，需要配置軟體，需要進行迴歸測試，運維人員需要反覆的部署環境，而且無法保證環境的一致性，任何一個環境配置的小問題，都有可能導致軟體使用有問題。

第二，空間靈活性：應用彈性伸縮，應對業務量突然增長後較短時間恢復。

網際網路應用往往是針對終端使用者的，終端使用者的行為往往不如企業使用者那樣容易預測，終端使用者可能因為促銷，過節等因素導致訪問量的迅速的增長，當訪問遭遇峰值的時候，我們希望應用可以快速擴充套件。

然而對於單體架構，應用擴充套件的過程如萬丈高樓平地起，一層一層慢慢蓋。

如果部署在物理機上面，則還需要採購新的物理裝置，如果有虛擬化平臺，則需要申請新的虛擬機器，並且配置好網路和儲存。然而僅僅一個空的虛擬機器是沒有用的，上面什麼環境都沒有，接下來需要安裝應用環境，比如Tomcat, Apache等，然後就是將應用，頁面配置到應用環境中，還沒有結束，新啟動的是一個獨立的系統，還需要將這個系統加入到當前的系統中，才能一起承擔訪問量，例如加入到負載均衡器的配置裡面。這樣每部署一套都需要從頭來一遍，實在是運維人員的噩夢。

第三，管理靈活性：易部署，易遷移，服務發現，依賴管理，自動修復，負載均衡。

現在很多網際網路應用都需要多地，多機房部署，有時候會從一個機房遷移到另一個機房，如果每次變動都如上面一樣從底層到頂層都做一遍，成本比較大，時間比較長。

當一個應用依賴於另一個應用，被依賴的應該宕機之後，修復需要手動進行，從底層到頂層配置一遍，而且修復好的系統往往IP地址也變了，則依賴於此應用的所有應用都需要修改配置。

網易的微服務化之路

要解決上面所述的三個問題，對應的有三個步驟。

第一步，去狀態化，從而實現程式的可擴充套件。

單體架構的程式往往很多資料是儲存在記憶體裡面的，或者是本地檔案系統的，例如使用者訪問的session資料，例如使用者上傳的照片。所謂的去狀態化，就是使得應用程式僅僅執行商業邏輯，而將資料的儲存全部交給外部的儲存服務。記憶體裡面的資料可以放在快取redis裡面，結構化資料放在統一的資料庫服務裡面，檔案存放在物件儲存裡面。這樣應用程式就變成了一個只有商業邏輯的應用，可以隨時擴充套件。

這裡面有一個問題就是應用程式的狀態外接化了，放在統一的快取，資料庫，物件儲存裡面了，可是應用程式宕機了是沒有問題了，再啟動一個就可以，如果快取，資料庫，物件儲存宕機了，資料不也是沒有了麼？

其實主流的開源的快取Redis，資料庫mysql，物件儲存swift等，他們設計的時候就是考慮了高可用和容災的情況的，所以資料儲存的工作就應該讓專業的模組來做這件事情，而應用程式應該關注在商業邏輯的實現，從而加速開發的速度。當然這些儲存模組的維護則是另外的專業人士在做的，這部分人士是快取的專家，資料庫的專家，物件儲存的專家，不需要懂商業邏輯。

第二步，容器化，可編排。

與傳統IaaS架構不同，容器提供的不僅僅是基礎資源，而是將作業系統，應用執行環境以及程式碼打包成一個不可修改的映象進行交付，容器的機制可以保證無論在哪裡，什麼時候執行，都能保持環境的一致性，也就是Docker所宣稱的“Build, Ship, and Run Any App, Anywhere(一次構建，隨處執行)”。

容器特別適合部署無狀態的服務，上一步的無狀態化，給容器化奠定了良好的基礎。

一個服務往往會包含多個元件，因而會封裝成為多個容器，容器之間會有相互的依賴，相互的呼叫，Kubernetes可以實現服務的編排、自發現、自修復，使得複雜服務的部署變成了一次API呼叫。

如圖所示，Kubernetes管理了相互依賴的四個服務，全部部署在容器裡面，分別執行在不同的機器上面。服務之間的呼叫通過服務名稱進行，而非固定IP進行，而服務名稱Kubernetes會管理起來。

當一臺伺服器宕機的時候，服務B和服務C會被自動排程到另外兩臺機器上，由於服務是無狀態的，所以沒有問題。然而服務A和服務D如何再找到服務B和服務C能，這兩個服務的物理主機變了，很可能IP也變了。其實是沒有問題的，Kubernates會自動將服務名和對應的IP地址關聯起來，服務之間只要配置的是服務名，而非IP地址，就依然能夠相互訪問。

有了容器和Kubernates這兩個工具後，解決了管理複雜性的問題，但是需要專門的團隊和技術力量，去玩轉Kubernates.

第三步，DevOps，可迭代。

從前面的一張圖中，Dev和Ops，開發和運維之間隔著長長的流程，導致迭代速度很慢。DevOps就是可以加快迭代速度的一種方法。

然而如何讓開發直接進入到運維流程中呢？容器的映象不可改變性提供了方案。

Docker可以保證容器中的執行環境，業務程式碼無論在哪個環境都是一致的，唯一不同的是不同環境的不同配置，可以通過環境變數注入的方式設定。有了這個模式，開發人員可以從很早就使用容器映象的方式進行開發，並且以容器映象的方式交付給測試，測試使用同樣的映象得到同樣的環境進行測試用例的執行，當決定釋出的時候，也確定真正到了生產環境的時候，同測試環境是一樣的。這樣避免了環境不斷重複的部署過程。

容器映象可以手動維護和交付，但是也可以藉助CICD持續整合的工具，來監控程式碼庫的更改，當有程式設計師提交程式碼的時候，會觸發一個hook，這個hook會呼叫CI工具，告知他程式碼已經有更新了，可以根據最新的程式碼打成最新的映象，CI工具根據配置好的Dockerfile，將程式碼打包成映象，上傳到映象庫，每次打映象都應該有新的版本，而不應該總使用latest。

映象打好了以後，接下來CD的工具會將映象部署到測試環境，測試人員可以就這個新的測試環境進行一輪測試，如果測試成功，則可以告知線上管理人員，可以更新新的版本。

線上管理人員在恰當的時間，使用編排工具，將容器映象的版本改為最新的版本，從而生產環境也就更新了。如果發現生產環境有問題，新的版本有Bug，沒有問題，只要將映象改為上個版本的映象即可，可以保證原來那個能用的版本，所有的配置和原來一樣，從而功能也一樣，實現了升級和回滾功能。

當然這套持續整合的工具和流程，需要開發人員和開發流程進行改進，才可以順利使用。

網易蜂巢幫助企業構建高效能微服務架構

前面的三板斧，去狀態化，容器化，持續整合，分別解決了空間靈活性，管理靈活性，時間靈活性。但是需要招聘一個DBA，Redis的專家，持續整合的專家，容器的專家，Kubernetes的專家，對於一個創業公司來講，這些專家往往比較難招聘到，而且與核心的業務邏輯沒有關係。

下面就介紹一下網易蜂巢幫助企業構建高效能微服務架構背後的黑科技。

第一，高效能的IaaS平臺。

蜂巢的容器是基於IaaS平臺的，IaaS平臺是基礎設施，基礎設施如果搭建不好，會對上層的PaaS和CaaS有效能方面的影響。所謂IaaS層，主要就是計算，網路，儲存，如果IaaS層不能提供高可靠的，高效能的基礎設施，則容器裡面的網路和儲存效能也會受影響。

蜂巢做的計算方面的改進主要是針對KVM的，如果我們自己搭建一套OpenStack平臺，建立虛擬機器的時候，會發現虛擬機器的建立時間是分鐘級別的，有時候會幾分鐘甚至十幾分鍾。然而容器是秒級啟動的，毫無疑問，KVM的啟動速度會大大拖累容器的啟動。經過分析KVM的啟動時間，發現cloud-init的配置時間最長，而且預設的KVM映象會啟動大量不需要的服務，當然首先做的事情就是對KVM映象進行裁剪，並且不使用DHCP的方式分配IP，而是採取靜態IP注入的方式進行，這樣KVM的啟動也降到了秒級。

對於網路方面，基於Neutron的虛擬網路管理，最底層的技術是基於Openvswitch的，通過vxlan給每一個租戶分配一個vxlan id，從而可以實現租戶之間的隔離。為了保證每個租戶的網路頻寬，需要通過Linux TC和流表對Openvswitch虛擬出來的網絡卡進行QoS。並且對於大量的網路小包進行了優化。

對於儲存方面，所有的本地盤和雲盤都是基於SSD盤的，保證了虛擬機器的IO效能。對於遠端訪問雲盤，支撐iscsi方式和ceph方式，對於ceph叢集，尤其是OSD的部分進行的優化。

第二，MySQL核心開發能力和獨立分支，保證主從切換時資料零丟失。

如果一個MySQL資料可以滿足需求的情況下，主從同步複製的方式，可以保證主從之間資料的一致性，在使用開源MySQL進行主從複製的時候，雖然主從切換可以配置，但是無法保證資料完全不丟失。這對需要強事務性的業務來講，是個很大的問題。

如果一個MySQL資料庫不足以滿足需求的情況下，就需要分庫分表了，這個蜂巢也是有分散式資料庫NDDB來處理這個事情。

第三，容器的優化。

在容器使用的過程中，容器的網路問題，尤其是跨主機互訪問的問題是比較大的問題，Docker雖然本身提供了Overlay的網路，但是在效能方面表現一般。在能夠實現互訪問的基礎上，還需要能夠和租戶管理結合起來，保證不同的租戶的網路之間是完全隔離的。另外，容器的網路除了互聯的問題，還需虛擬防火牆，虛擬VPN，虛擬負載均衡器。最後，很多已經使用網易雲IaaS的業務，也需要IaaS層和容器層互通。在這些方面，其他的容器網路解決方案例如Flannel，Calico都不能滿足要求。

既然IaaS層使用Neutron和Openvswitch的方案，並且經過效能調優和安全增強，自然容器的網路也可以使用Openvswitch的方案，滿足上述的要求。

除了網路問題，容器的儲存也是一個問題。容器是比較適合部署無狀態的服務的，對於有狀態的服務，我們還是希望將使用者資料放置在外接的遠端雲盤中，這樣容器宕機和跨主機遷移，都不影響外部的資料，而且資料盤還可以打快照，做備份和恢復。

第四，編排層Kubernetes的優化。

之所以選擇Kubernetes作為服務編排的框架，主要考慮到以下幾點。

1. Kubernetes功能完善，產品理念成熟。資源排程、服務發現、執行監控、擴容縮容、負載均衡、灰度升級、失敗冗餘、容災恢復、DevOps都有對應的方案。

2. 定義了構建分散式業務系統的標準化架構層，即Cluster、Node、Pod、Label等一系列的抽象都是定義好的，為服務編排提供了一個簡單、輕量級的方式。

3. 社群活躍度高，被大量的雲端計算技術提供商和使用者採用。在容器的編排領域有廣泛的群眾基礎

當然Kubernetes作為一個開源軟體，也不會是完美的。

首先遇到的問題是Kubernetes支援多租戶的問題，預設情況下NameSpace 只隔離 replication controller、pod 等資源，node 與儲存、網路等是共享狀態，實現真正的多租戶隔離需要將所有資源隔離。不同租戶不共享 node，每個租戶的認證與授權獨立。這樣就避免了在公有云場景下，使用者使用容器的安全性問題。

第二個問題，就是當叢集規模擴大到一定的規模，任務的排程就遭遇了瓶頸，預設情況下，任務佇列中所有操作都是序列執行，通過改進為多優先順序佇列、deadline機制，可有效解決這一問題。

還有一個問題，當叢集規模大了之後，一個etcd叢集不能滿足要求，根據Pod/Node/RC等資源到拆分不同的etcd叢集。現在1.3已經支援將不同資源分佈在不同的etcd叢集，而我們其實在1.0的版本上就已經做了相應的實踐。

從上面的敘述可以看出，要構建高效能的微服務架構，既需要基礎架構層面的效能調優，也需要服務編排層面的排程優化，也不能缺少應用層面的微服務化，是一個端到端的工作。

如圖所示，綠色的部分是網易蜂巢基於多年的網際網路經驗，在各個層面進行了優化後，推出的元件，作為一個創業公司，不需要招聘一個IaaS平臺管理的團隊，資料庫DBA的團隊，分散式儲存的團隊，容器和服務編排的團隊，網路調優的團隊，而僅僅只需要聚焦企業核心的業務層面就可以了，如圖中紅色的部分。這樣才能將主要的力量集中在產品快速上線，搶佔新一輪網際網路+風口。

企業只需要逐步做到以下三步，就可以實現微服務和快速交付。

1. 去狀態化：將記憶體資料寫入快取，將持久化資料寫入資料庫，將檔案寫入物件儲存。
2. 容器化：可彈性伸縮，自我修復，動態遷移。
3. 微服務化：可快速迭代，持續整合。

網易在所有元件的選型的時候，都是採取了業界最主流的開源平臺和方案，並且完全相容開源軟體的API，使得平臺做到足夠的開放、標準、穩定和不繫結。

轉自：http://www.infoq.com/cn/articles/building-a-high-performance-micro-service-architecture?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage