隨著移動互聯網時代的興起，提供高性能、高可用性、高擴展性的服務已經不僅僅是大公司的專利，而逐漸成為所有互聯網+公司的標配需求。本文介紹網易如何利用多年的互聯網架構經驗和網易蜂巢的平臺，幫助客戶進行架構改進、微服務化、性能調優。
傳統架構之痛
當前的時代稱為互聯網的時代，互聯網應用的特點往往是，新型的應用迅速出現顛覆舊的商業模式，一旦商業模式稍有起色便會有大量的廠商蜂擁而至，使得藍海變成紅海，經過短時間的殘酷競爭，熱度往往持續較短時間后，大量廠商退出市場，僅僅前二名到三名能夠存活下來，最終這一波浪潮被下一波取代。我們回想視頻網站，團購網站，社交網站，微博，打車，直播等，全都呈現這種模式。
所以互聯網市場只有一招，天下武功，唯快不破。
當一種商業模式出現的時候，為了迅速切入市場，占領商業獻祭，快速驗證商業模式，往往軟件的設計會采取傳統的單體架構。
微服務架構和分布式架構的區別，傳統的單體架構往往分三層，最下面一層是數據庫，中間是應用程序層，所有的商業邏輯都會在這一層，最上面是頁面。
如果商業模式比較成功，則應用會添加新的功能，一種方式是全部添加到原有的商業邏輯中，另一種方式是開發一個全新的三層結構來支撐新的功能。
由于是單體結構，一方面應用層里面的功能越來越多，如圖中一個功能變為三個功能，將來可能三十個功能，另一方面很多代碼和邏輯都不能復用，如圖中功能2，每個應用都有，這種功能常見的有認證模塊，消息的編碼和解碼模塊等。
這種單體結構會帶來三方面靈活性比較差。
第一，時間靈活性：應用快速迭代，縮短客戶需求到產品上線的時間。
微服務架構。互聯網應用的需求隨時改變，因而應用開發的迭代速度要求會比較快，傳統的軟件可能半年或者一年發布一個功能，而互聯網應用則可能每周都發布新的功能。而且互聯網產品會時常搞活動，比如雙十一，每次活動不可能提前很長時間策劃，從而給開發充分的產品周期。
然而單體結構的應用如果有了30個模塊，每個模塊由兩到三個人負責，則修改的成本會非常的大，從開發人員看來，整個架構牽一發動全身，每次修改必須要做好良好的前期設計，并且讓整個團隊評審，如果新的需求要改多個模塊，則代碼的管理和合并就成為很大的問題。
而且無論測試，聯調，上線，擴展，縮減，升級，回滾都需要重新搭建環境，需要配置軟件，需要進行回歸測試，運維人員需要反復的部署環境，而且無法保證環境的一致性，任何一個環境配置的小問題，都有可能導致軟件使用有問題。
第二，空間靈活性：應用彈性伸縮，應對業務量突然增長后較短時間恢復。
互聯網應用往往是針對終端用戶的，終端用戶的行為往往不如企業用戶那樣容易預測，終端用戶可能因為促銷，過節等因素導致訪問量的迅速的增長，當訪問遭遇峰值的時候，我們希望應用可以快速擴展。
中臺架構與微服務的關系、
然而對于單體架構，應用擴展的過程如萬丈高樓平地起，一層一層慢慢蓋。
如果部署在物理機上面，則還需要采購新的物理設備，如果有虛擬化平臺，則需要申請新的虛擬機，并且配置好網絡和存儲。然而僅僅一個空的虛擬機是沒有用的，上面什么環境都沒有，接下來需要安裝應用環境，比如Tomcat, Apache等，然后就是將應用，頁面配置到應用環境中，還沒有結束，新啟動的是一個獨立的系統，還需要將這個系統加入到當前的系統中，才能一起承擔訪問量，例如加入到負載均衡器的配置里面。這樣每部署一套都需要從頭來一遍，實在是運維人員的噩夢。
第三，管理靈活性：易部署，易遷移，服務發現，依賴管理，自動修復，負載均衡。
現在很多互聯網應用都需要多地，多機房部署，有時候會從一個機房遷移到另一個機房，如果每次變動都如上面一樣從底層到頂層都做一遍，成本比較大，時間比較長。
arm架構性能排行。
當一個應用依賴于另一個應用，被依賴的應該宕機之后，修復需要手動進行，從底層到頂層配置一遍，而且修復好的系統往往IP地址也變了，則依賴于此應用的所有應用都需要修改配置。
網易的微服務化之路
要解決上面所述的三個問題，對應的有三個步驟。
第一步，去狀態化，從而實現程序的可擴展。
單體架構的程序往往很多數據是保存在內存里面的，或者是本地文件系統的，例如用戶訪問的session數據，例如用戶上傳的照片。所謂的去狀態化，就是使得應用程序僅僅運行商業邏輯，而將數據的保存全部交給外部的存儲服務。內存里面的數據可以放在緩存redis里面，結構化數據放在統一的數據庫服務里面，文件存放在對象存儲里面。這樣應用程序就變成了一個只有商業邏輯的應用，可以隨時擴展。
微服務架構應該具備的功能、這里面有一個問題就是應用程序的狀態外置化了，放在統一的緩存，數據庫，對象存儲里面了，可是應用程序宕機了是沒有問題了，再啟動一個就可以，如果緩存，數據庫，對象存儲宕機了，數據不也是沒有了么？
其實主流的開源的緩存Redis，數據庫mysql，對象存儲swift等，他們設計的時候就是考慮了高可用和容災的情況的，所以數據存儲的工作就應該讓專業的模塊來做這件事情，而應用程序應該關注在商業邏輯的實現，從而加速開發的速度。當然這些存儲模塊的維護則是另外的專業人士在做的，這部分人士是緩存的專家，數據庫的專家，對象存儲的專家，不需要懂商業邏輯。
第二步，容器化，可編排。
與傳統IaaS架構不同，容器提供的不僅僅是基礎資源，而是將操作系統，應用運行環境以及代碼打包成一個不可修改的鏡像進行交付，容器的機制可以保證無論在哪里，什么時候運行，都能保持環境的一致性，也就是Docker所宣稱的“Build, Ship, and Run Any App, Anywhere(一次構建，隨處運行)”。
容器特別適合部署無狀態的服務，上一步的無狀態化，給容器化奠定了良好的基礎。
一個服務往往會包含多個組件，因而會封裝成為多個容器，容器之間會有相互的依賴，相互的調用，Kubernetes可以實現服務的編排、自發現、自修復，使得復雜服務的部署變成了一次API調用。
cpu架構排行、
如圖所示，Kubernetes管理了相互依賴的四個服務，全部部署在容器里面，分別運行在不同的機器上面。服務之間的調用通過服務名稱進行，而非固定IP進行，而服務名稱Kubernetes會管理起來。
當一臺服務器宕機的時候，服務B和服務C會被自動調度到另外兩臺機器上，由于服務是無狀態的，所以沒有問題。然而服務A和服務D如何再找到服務B和服務C能，這兩個服務的物理主機變了，很可能IP也變了。其實是沒有問題的，Kubernates會自動將服務名和對應的IP地址關聯起來，服務之間只要配置的是服務名，而非IP地址，就依然能夠相互訪問。
有了容器和Kubernates這兩個工具后，解決了管理復雜性的問題，但是需要專門的團隊和技術力量，去玩轉Kubernates.
第三步，DevOps，可迭代。
9種高性能高可用高并發的技術架構？從前面的一張圖中，Dev和Ops，開發和運維之間隔著長長的流程，導致迭代速度很慢。DevOps就是可以加快迭代速度的一種方法。
然而如何讓開發直接進入到運維流程中呢？容器的鏡像不可改變性提供了方案。
Docker可以保證容器中的運行環境，業務代碼無論在哪個環境都是一致的，唯一不同的是不同環境的不同配置，可以通過環境變量注入的方式設置。有了這個模式，開發人員可以從很早就使用容器鏡像的方式進行開發，并且以容器鏡像的方式交付給測試，測試使用同樣的鏡像得到同樣的環境進行測試用例的執行，當決定發布的時候，也確定真正到了生產環境的時候，同測試環境是一樣的。這樣避免了環境不斷重復的部署過程。
容器鏡像可以手動維護和交付，但是也可以借助CICD持續集成的工具，來監控代碼庫的更改，當有程序員提交代碼的時候，會觸發一個hook，這個hook會調用CI工具，告知他代碼已經有更新了，可以根據最新的代碼打成最新的鏡像，CI工具根據配置好的Dockerfile，將代碼打包成鏡像，上傳到鏡像庫，每次打鏡像都應該有新的版本，而不應該總使用latest。
鏡像打好了以后，接下來CD的工具會將鏡像部署到測試環境，測試人員可以就這個新的測試環境進行一輪測試，如果測試成功，則可以告知線上管理人員，可以更新新的版本。
hpc高性能解決方案，線上管理人員在恰當的時間，使用編排工具，將容器鏡像的版本改為最新的版本，從而生產環境也就更新了。如果發現生產環境有問題，新的版本有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來處理這個事情。
intel cpu 架構代號？第三，容器的優化。
在容器使用的過程中，容器的網絡問題，尤其是跨主機互訪問的問題是比較大的問題，Docker雖然本身提供了Overlay的網絡，但是在性能方面表現一般。在能夠實現互訪問的基礎上，還需要能夠和租戶管理結合起來，保證不同的租戶的網絡之間是完全隔離的。另外，容器的網絡除了互聯的問題，還需虛擬防火墻，虛擬VPN，虛擬負載均衡器。最后，很多已經使用網易云IaaS的業務，也需要IaaS層和容器層互通。在這些方面，其他的容器網絡解決方案例如Flannel，Calico都不能滿足要求。
既然IaaS層使用Neutron和Openvswitch的方案，并且經過性能調優和安全增強，自然容器的網絡也可以使用Openvswitch的方案，滿足上述的要求。
除了網絡問題，容器的存儲也是一個問題。容器是比較適合部署無狀態的服務的，對于有狀態的服務，我們還是希望將用戶數據放置在外置的遠程云盤中，這樣容器宕機和跨主機遷移，都不影響外部的數據，而且數據盤還可以打快照，做備份和恢復。
第四，編排層Kubernetes的優化。
之所以選擇Kubernetes作為服務編排的框架，主要考慮到以下幾點。
- Kubernetes功能完善，產品理念成熟。資源調度、服務發現、運行監控、擴容縮容、負載均衡、灰度升級、失敗冗余、容災恢復、DevOps都有對應的方案。
- 定義了構建分布式業務系統的標準化架構層，即Cluster、Node、Pod、Label等一系列的抽象都是定義好的，為服務編排提供了一個簡單、輕量級的方式。
- 社區活躍度高，被大量的云計算技術提供商和用戶采用。在容器的編排領域有廣泛的群眾基礎
當然Kubernetes作為一個開源軟件，也不會是完美的。
首先遇到的問題是Kubernetes支持多租戶的問題，默認情況下NameSpace 只隔離 replication controller、pod 等資源，node 與存儲、網絡等是共享狀態，實現真正的多租戶隔離需要將所有資源隔離。不同租戶不共享 node，每個租戶的認證與授權獨立。這樣就避免了在公有云場景下，用戶使用容器的安全性問題。
第二個問題，就是當集群規模擴大到一定的規模，任務的調度就遭遇了瓶頸，默認情況下，任務隊列中所有操作都是串行執行，通過改進為多優先級隊列、deadline機制，可有效解決這一問題。
還有一個問題，當集群規模大了之后，一個etcd集群不能滿足要求，根據Pod/Node/RC等資源到拆分不同的etcd集群。現在1.3已經支持將不同資源分布在不同的etcd集群，而我們其實在1.0的版本上就已經做了相應的實踐。
從上面的敘述可以看出，要構建高性能的微服務架構，既需要基礎架構層面的性能調優，也需要服務編排層面的調度優化，也不能缺少應用層面的微服務化，是一個端到端的工作。
如圖所示，綠色的部分是網易蜂巢基于多年的互聯網經驗，在各個層面進行了優化后，推出的組件，作為一個創業公司，不需要招聘一個IaaS平臺管理的團隊，數據庫DBA的團隊，分布式存儲的團隊，容器和服務編排的團隊，網絡調優的團隊，而僅僅只需要聚焦企業核心的業務層面就可以了，如圖中紅色的部分。這樣才能將主要的力量集中在產品快速上線，搶占新一輪互聯網+風口。
企業只需要逐步做到以下三步，就可以實現微服務和快速交付。
- 去狀態化：將內存數據寫入緩存，將持久化數據寫入數據庫，將文件寫入對象存儲。
- 容器化：可彈性伸縮，自我修復，動態遷移。
- 微服務化：可快速迭代，持續集成。
網易在所有組件的選型的時候，都是采取了業界最主流的開源平臺和方案，并且完全兼容開源軟件的API，使得平臺做到足夠的開放、標準、穩定和不綁定。
作者簡介
劉超，網易云計算解決方案總架構師。10年云計算領域研發及架構經驗，Open DC/OS貢獻者。長期專注于Kubernetes、OpenStack、Hadoop、Docker、Lucene、Mesos等開源軟件的企業級應用及產品化。曾出版《Lucene應用開發揭秘》。
