360°透視：雲原生架構演進

目前，互聯網企業隨着業務的發展不斷前進。所以，不一樣的階段有不一樣的需求，因此須要使用不一樣的方法來聚焦不一樣的目的。好比初創型的企業須要抓住合適的機遇快速進行原型驗證，證實大的方向沒問題纔有可能進一步發展。所以技術通常是爲了知足業務的發展和驗證而設計，只要保證共用的組件可以複用就能夠。只有隨着業務的進一步發展，組織架構及人員的規模愈來愈大，企業纔有機會發展成中型或獨角獸公司。然而協做人員數量的增加也意味着新的問題，通常而言，只要企業的人員規模超過150人，就會帶來極大的管理成本提高。在這一階段，技術不只須要和產品進行更充分的結合，還須要規範化和工程化操做。當規模再次擴大的時候，若是隻是簡單的人力堆積，協調性問題是沒法解決的，企業須要更高效的架構才能支撐和反哺業務的發展，工具和流程須要更加自動化纔有可能保證業務的持續發展，邊際效應很是明顯，同時挑戰也更大。

總之，在任何階段，技術的演進都是一個很是重要的過程，這一點在以技術爲導向的公司尤其凸顯。技術超前就有可能成爲先行者，技術落後就有可能致使企業發展緩慢，機會丟失。

不管是我的開發者仍是技術公司，若是目的是持續運行和發展，就須要一套良好並固定的制度，一樣，在技術上，團隊的持續前進離不開項目的工程化思惟。開發、測試、發佈的軟件生命週期的高效管理必須依賴工程化，它是研發協做與雲端運維的基礎。這裏麪包括許多問題，須要技術人員去解決，好比：追求技術的先進或業務需求的合理性評估，多是不少公司技術管理須要根據組織架構權衡的問題。通常來說，任何從零起步的公司都會通過不一樣的技術發展階段，包括簡單的初創期、快速增加期及分佈式的服務化架構階段。每一個階段對應不一樣的產品和業務需求，技術承擔不一樣職責，須要技術人員來決策，特別是須要架構師首要思考的問題。

1 初創期架構

一般來講，創業公司在開始新業務的時期，基本處在試錯或原型驗證階段，這個階段更可能是關注業務的自己是否有前景或商業模式，而不會把很是多的精力放在技術的系統架構上，尤爲是對於非技術型或不肯定型的項目立項階段。儘管不少技術人員也預料到前期須要不少時間去好好設計系統，才能保證支撐後續可能的業務快速發展，但每每因爲時間成本或人力等緣由而沒法很好地執行。

通常來說，創業型的項目對時間的要求很是苛刻，基本須要在3到6個月時間內完成系統的上線，不然有可能因爲業務沒法快速上線驗證，致使沒法獲取相關的原始數據進行下一個目標驗證，更嚴重的有可能形成資金鍊的斷裂。羅馬不是一天建成的，所以這個階段會使用相對簡單的架構方式來進行設計，本節先從最主要的幾點進行說明，更詳細內容請參考第3章。

單體架構

對於創業型公司來講，因爲人才、技術、資金等重要因素的影響，同時，技術人員爲了配合產品的需求，會採用最簡單的架構來完成最原始階段開發。根據咱們接觸的很多用戶，有些企業甚至考慮成本因素，只使用一臺服務器或者容器服務。另外，傳統官網、論壇等應用，因爲早期的設計採用了單體架構來實現，只須要一臺服務器或容器來服務便可。對於其餘的應用服務器、數據庫、靜態文件等資源，也是部署到同一臺服務器或容器上來服務。最簡單的架構模型如圖1-11所示。

圖1-11  最簡單的架構模型

對於早期的單體應用模型，應用服務+數據庫服務基本上就組成了最原始的架構模型，技術人更多會考慮技術的選型，包括編程語言、版本管理、數據庫的類型等。好比PHP的開發者選擇PHP+MySQL，Java的開發者採用Tomcat+MySQL等開發方式。

服務器分離

根據線上運行經驗，通常的業務的類型，若是每日的用戶訪問量在百萬以內PV級別，只要進行簡單的Web應用性能參數調優、數據庫索引優化等，基本上就能保證服務的穩定運行。固然，若是隨着訪問量的不斷增長，部署在同一臺服務器上的應用及數據庫等服務應用，會和服務器的CPU/內存/磁盤/帶寬等系統資源競爭，從而相互影響。顯然很容易出現性能瓶頸，若是這臺服務器出現了宕機或沒法恢復的狀況，就有可能會致使全站不可訪問或者數據丟失等狀況，形成的後果很是嚴重，所以大部分產品會將Web應用服務器和數據庫服務器進行物理分離，獨立部署，相互熱備提供服務，只須要增長不多的成本，就能解決對應性能和數據的可靠性等問題。

初期因爲各類條件存在，不能很好地進行新項目前景的預見，技術人員若是能在最小成本的狀況下保證架構的合理性，還能很好地服務產品功能需求，甚至只要在部署架構上稍作調整，就能夠防止出現災難性的問題，這其中也包括不少技術架構上的考慮。

業務模型

通常而言，現階段的業務比較簡單，產品也比較單一，業務會隨時根據其運營數據進行調整，所以，這時須要技術人可以較好地把不一樣的模塊分離出來，對於偏業務相關的功能，須要有較好的心態接收隨時變化的不肯定性，對於後續可能複用或大量依賴的工程，須要進行較好的設計，不然可能在業務爆發時致使業務開發的進度愈來愈慢，甚至阻礙業務的發展，形成業務時常中斷。即便有人力或時間來對系統進行從新設計，也會令技術人員產生抵觸心理，同時也會引入較高的風險。所以，基於雲原生應用的設計模式在最基礎的階段對架構也有很大的做用，包括考慮如何使用雲的彈性，將不可變優點融合到系統的設計中。合理的業務模型分界也是確保後續能發展的重要步驟之一。

總而言之，在早期項目原型驗證或者快速試錯階段，採用單體架構具備很大的技術優點，產品的想法也在項目的初始階段就能進行比較好的迭代開發，發佈和部署也比較靈活。然而，隨着業務的增加，若是架構仍是一成不變的話，帶來的技術風險就愈來愈高，好比，代碼行數的增長影響技術人員的學習成本、業務的變動速度、業務的可靠性、安全性及工程變大後的發佈效率等，每次修改都必須反覆測試，不然全站隨時可能不可用，致使業務中斷或者丟失市場的機會。所以，這部分的技術債務必須在業務快速發展的同時，進行技術架構的改造，使其能保證後期業務的支撐。因此，除了業務的發展判斷外，對開發人員的技術能力儲備和架構遠見判斷也將成爲考慮的事情之一。

2 快速成長期架構

接下來，初創公司隨着業務的進一步發展，好比當訪問人數到達十萬日活（UV）的時候，一般也是最關鍵的時刻，既要保證業務的穩定運行，又要進行產品的快速迭代。到了這個階段，因爲業務模式獲得了必定的驗證和反饋，有可能會出現不少競品或友商。一方面，隨着風險資本的注入，會依賴更有質量的數據進行發展運營，另外一方面，競品的出現又致使了市場的加速前進。所以，如何在調整期保證業務與技術的和諧發展是考驗架構是否足夠靈活的指標之一，一樣，本節主要說明幾點，更詳細內容請參考第4章。

前端加速優化

首先基於瀏覽器端應用或者移動端應用，隨着請求的不斷增長，偶爾會看到Web服務出現性能瓶頸致使請求變慢或者失敗。除去服務器自己的配置低外，更有可能因爲架構設計或分離的緣由，大量的Web併發請求被堵塞或者變慢，緣由無非是服務器的CPU、磁盤I/O、帶寬競爭激烈，致使相互影響。這時候咱們就須要對架構進行先後端分解，合理配置或轉發請求，若是是前端的服務請求來不及處理或者有瓶頸，能夠將圖片、JS、CSS、HTML及應用服務相關的靜態資源文件存儲經過Nginx本地代理或者對象存儲服務來進行物理加速，使用不一樣的域名來轉發請求，並經過CDN將靜態資源分佈式緩存在各個節點實現「就近訪問」，主動或被動刷新CDN的緩存來加速前端服務。若是是後端的動態請求壓力過大或者有熱點服務，能夠把無狀態的後端的服務再進一步水平擴展知足業務分擔，有狀態須要判斷是否能經過垂直擴容來服務，不然只能進行代碼、架構設計或者業務規劃的調整來優化。通常而言，經過將動態請求、靜態請求的訪問分離（「動靜分離」），能有效解決服務器在CPU、磁盤I/O、帶寬方面的訪問壓力，固然，這須要在架構設計時採用一些方法來進行調整。

水平擴展

在上節中提到垂直擴容能解決部分的問題，但因爲業務和流量的快速增加及垂直資源有限，不一樣的應用場景須要依賴不一樣的策略分流，好比長鏈接的應用會依賴於4層的網絡鏈接，互聯網應用一般採用7層的模式來完成，甚至在遊戲場景中，依賴UDP進行通訊。爲了更多地分擔服務器的壓力和保證業務的高可用，負載均衡技術一般是這個階段解決問題的一個方法，經過增長多臺後端服務器就能夠實現分流的功能，分流設計也面臨不少原則與技巧，好比分流的路徑、權重等，負載均衡承擔的角色也決定了後端的應用架構，好比無狀態化設計才能實現水平擴展，另外還要考慮業務是否有親緣性，同時在後端服務出現異常的狀況下，自動進行健康檢查，異常的服務能及時進行下線操做，快速失敗。

數據庫及緩存優化

數據庫和緩存配合使用是解決後端結構化數據與非結構化問題的有效手段，根據不一樣的場景，要明白哪一種數據使用結構化數據合適，哪一種數據使用非結構化數據更合適，以及哪一種方式在保證性能較好的狀況下成本又能夠接受。同時，如何在數據庫和緩存之間進行過渡也是須要考慮的，好比數據在更新的時候，如何保證緩存的一致性，如何保證熱點數據一直被訪問，提升緩存的命中率等。另外，當大量用戶訪問不存在的數據時，也有可能致使後端的壓力很是大，甚至有可能形成雪崩效應。

每種服務獨立承擔對應的功能，各司其職，而且根據應用的特性區別提供不一樣的服務能力，好比應用服務器提供用戶的接入服務，數據庫服務專門承擔結構化數據的存儲，緩存承擔或非結構化數據（KV值對）的存儲等，若是要提供搜索的功能，還需將數據進行分詞、索引、檢索等，不一樣服務器根據業務的功用需求來提供對應的服務，如圖 1-12所示。

在這個階段，除了必須保證知足業務的功能型需求，還要更多考慮非功能性需求，好比，經過前端負載均衡提供業務分流的能力，根據用戶的特徵進行不一樣的流量轉發；數據庫提供主備的能力，二者之間經過數據同步進行數據備份，當主數據庫發生故障後，應用能夠自動切換到備份的服務器來爲用戶提供服務；在用戶體驗方面，可能會引入緩存、CDN等基礎服務來提供性能加速。

圖1-12  數據庫及緩存優化

3 分佈式服務架構

通常而言，企業通過前面兩個階段的發展，就基本肯定了業務的發展方向，接下來只要面對競爭對手的跟隨和大量用戶訪問請求的問題。這些企業也會提供各類不一樣的子產品模塊功能來知足業務的多樣性發展，好比產品會設計不一樣的產品功能體系，運營人員會設計不一樣的運營活動，客服人員會接到不一樣的用戶反饋等。這些需求疊加在一塊兒，會致使整個業務愈來愈複雜，有些系統變得再也不具備維護性，沒法知足可用性的需求，只要一出現流量高峯，系統一定宕機，因此不少公司面臨重構架構設計，甚至推翻重來，好比京東大部分的用戶業務從.NET轉到Java語言的重構，淘寶從PHP轉到Java，升級2.0，再到3.0的架構轉變，能夠看到，這個時間點的轉型或重構可能不會到生死攸關的地步，但其成本是很是高的。所以，如何在一開始就能作好這種轉變的預見性，對技術的要求有至關大的挑戰，本節先給出幾點供讀者來參考，更詳細內容請參考第5章。

業務需求

經過雲服務一般能夠解決不少架構層面的問題，好比對象存儲系統解決了文件分佈式存儲的問題，CDN解決了靜態資源訪問的性能問題，但實際上隨着業務的不斷髮展，系統訪問壓力增大，還可能有不少的請求變慢或者超時，應用服務器或數據庫服務的壓力波動較大，只要不停地上線新業務，技術債就會愈來愈明顯，業務的迭代也愈來愈跟不上產品需求。爲了解決這些問題，企業每每須要進行各類業務的拆分，把不一樣的功能模塊拆分到不一樣的服務器上進行獨立部署。好比用戶模塊、商品模塊、購物車模塊、訂單模塊和支付模塊等，這些模塊拆分並獨立部署出來後，能夠再進一步根據系統的瓶頸進行細分。可是進行服務拆分以後，各模塊之間的依賴又變得明顯起來，好比數據庫的鏈接數、數據的分佈式事務、數據庫的性能開銷等都是急切須要解決的問題。

同時，隨着業務模塊的拆分，除了上述的技術問題要解決外，還面臨着工程實踐的問題，好比在業務的不一樣分支中，須要保證開發人員、測試人員、運維人員快速地開發環境、測試環境、預發佈環境的搭建和發佈。在高速發展的企業中，迭代的頻率很是高，以網易考拉平臺爲例，全部系統的日發佈總次數到達數千次，因此技術人員對效率的要求極高。當擴大到一個公司多個產品線，總體的運行就要求像現代化工廠同樣來運做，須要自動化的能力平臺去解決，純手工根本沒法知足企業的高效運轉。

彈性擴容

隨着需求和用戶的不斷增加，系統會出現波峯和波谷，爲了更好地利用資源和成本預算，彈性擴容成了必要需求，在峯值的時候可以根據業務的壓力自動擴容，分擔流量，在壓力低的時候自動縮容，減小成本或提升資源的利用率，把縮容的資源作離線業務計算。也許在過去是簡單地經過垂直擴大規模能力來處理更多的需求，或者是購買更強的服務器，這在必定程度上是可行的，但過程很慢而且代價龐大，經過提早準備過多的資源，會致使只根據峯值使用量預測來規劃能力值，好比根據服務器的最高計算能力購買硬件予以知足，這是不得已的作法。例如國外的黑色星期5、國內的雙11等活動，當天請求很是高，須要足夠的資源來知足業務請求，而平時這些服務器的使用率很低，因此，只有依賴雲的彈性才能知足這種業務場景的需求。

服務化

無論是互聯網仍是傳統行業轉型的企業，基本都是在原有基礎業務上發展而來的，不可能把業務中止從零開始，所以，直接對原有系統進行微服務改造比較困難，風險也較大。這時基本上處於一種混合架構期，即新的業務會從頭開發，逐步接入到老系統中，一步步替換老系統不知足的地方，經過不斷地快速迭代來保證業務的可持續性，同時又保證新業務的快速需求。著名的架構大師Martin Fowler從2013年正式提出微服務架構的綜述文章至今，都沒有提供統一的最佳實踐方案。如今微服務的架構實現方式也各類各樣，一般根據應用的類型拆分紅不一樣的微服務來實現，每一個服務根據業務的特徵採用不一樣的技術棧進行組合，把每一個服務劃分紅能夠獨立部署的隔離進程來運行。目前，微服務的基本框架都相似，好比包括服務發現、降級、治理等方面。業務實現微服務的技術細節各不相同，沒有統一的實現方案，好比服務發現有自建服務基礎設施的，也有依賴第三方開源的，技術人員須要根據本身的場景來作選擇。簡化的架構模型如圖1-13所示。

圖1-13  服務化架構模型

顯然，這個架構模型只是整個業務服務架構的一部分，實際的系統可能要複雜幾十倍。若是業務的迭代速度很是快，同時每一個業務之間的依賴從設計、開發、測試、上線到運維都是一個很是龐大的複雜工程，所以，如何高效管理所依賴的服務和系統依賴，診斷並及時對業務反饋響應是對服務架構的考驗。

 

本文節選自《雲原生應用架構實踐》，網易雲基礎服務架構團隊著，全程詳解單體到分佈式服務化架構的演進。更多精彩內容，敬請期待下期分享。對雲原生感興趣的讀者，歡迎掃碼閱讀全書。

相關閱讀：

360°透視：雲原生架構及設計原則

人工智能的全面科普

人工智能是如何識別一張黃圖的？

 

相關活動：

2017網易中國創業家大賽

2017雲創大會