最近一年的工作，有很大的比重在做云平臺的事情，簡單來說，就是為公司內(nèi)用戶提供一個PaaS，用戶可以在我們的云平臺上方便的將單機(jī)服務(wù)程序擴(kuò)展為多實(shí)例程序，以平臺服務(wù)化的方式對外提供。在這里簡單分享一下。

首先簡單說一下我們解決了用戶的什么需求，或者說痛點(diǎn)。

基礎(chǔ)算法直接以庫的形式提供給應(yīng)用方?

用戶提供了一個基礎(chǔ)算法，這個算法可能以一個動態(tài)庫的形式提供，那么使應(yīng)用方需要關(guān)注編譯依賴，需要關(guān)注詞典等模型文件，開發(fā)成本比較高。尤其是如果這個基礎(chǔ)算法需要升級，或者模型文件需要升級的時候，還需要通知應(yīng)用方進(jìn)行修改。而且，如果基礎(chǔ)算法不穩(wěn)定，有出core的行為，那么勢必影響了應(yīng)用方的服務(wù)質(zhì)量。還有就是，如果基礎(chǔ)算法非常耗資源，比如CPU，內(nèi)存占得太多，可能會影響應(yīng)用方程序?qū)τ谫Y源的使用。

基礎(chǔ)算法的服務(wù)化

為了避免基礎(chǔ)算法以動態(tài)庫提供給應(yīng)用方的種種弊端，基礎(chǔ)算法可以以網(wǎng)絡(luò)服務(wù)的形式提供，這就是基礎(chǔ)算法的服務(wù)化。就是說，基礎(chǔ)算法是一個網(wǎng)絡(luò)服務(wù)，用戶直接訪問這個網(wǎng)絡(luò)服務(wù)即可。這樣，基礎(chǔ)算法的服務(wù)接口只要不變，不論它如何升級，都不需要應(yīng)用方做任何修改。開源的Thrift，等等RPC的方案，都很好的滿足了基礎(chǔ)算法服務(wù)化的需求。

服務(wù)化的質(zhì)量如何衡量

那么一個服務(wù)化的基礎(chǔ)算法，如何保證上面所說的服務(wù)質(zhì)量和延時上的要求呢。尤其是服務(wù)質(zhì)量，或者說可靠性。如果我們假設(shè)機(jī)器永遠(yuǎn)無故障，網(wǎng)絡(luò)設(shè)備也永遠(yuǎn)運(yùn)行正常，服務(wù)也足夠穩(wěn)定，不會有core，也不會升級等等，那么直接找一些機(jī)器拉起來就萬事大吉了。但是，現(xiàn)實(shí)卻是殘酷了，首先服務(wù)可能會有故障，它應(yīng)該會不斷升級(如果有一個不用升級的程序，要么是太完美了，要么就是沒有人用了，大家寫程序都知道，完美的程序你永遠(yuǎn)寫不出來，少寫點(diǎn)爛代碼才是正常追求)，升級的過程不能影響服務(wù)質(zhì)量，還有服務(wù)不可能獨(dú)占機(jī)器的，很有可能會和其他服務(wù)混布，那么如何選擇合適的機(jī)器部署，也是一個問題。還有，很多時候一個服務(wù)實(shí)例是滿足不了需求的，可能要部署多個服務(wù)實(shí)例，這里邊的問題就更多了，請求發(fā)給哪個實(shí)例，負(fù)載均衡，等等等。

服務(wù)平臺化需要面對的問題

我們下面將服務(wù)化的基礎(chǔ)算法，以承諾的服務(wù)質(zhì)量對外提供的過程，稱為服務(wù)的平臺化。就是說，服務(wù)化的基礎(chǔ)算法，經(jīng)過一個平臺對外提供，就能獲得相應(yīng)的服務(wù)質(zhì)量。那么平臺化的挑戰(zhàn)有哪些呢?

如果一個基礎(chǔ)算法自己想實(shí)現(xiàn)平臺化，閉門造車，需要做很多工作。這也是PaaS存在的意義，將大家服務(wù)化的工作都通用化，讓策略開發(fā)者解放出來。那么，平臺化要解決的哪些問題，或者基礎(chǔ)算法服務(wù)化的痛點(diǎn)在哪里呢?

服務(wù)的平臺化，并不是簡單的在幾臺機(jī)器上把一個服務(wù)部署起來，對外提供服務(wù)，尤其是對應(yīng)用方承諾了服務(wù)質(zhì)量的時候。而且，為了提升機(jī)器的資源利用率，一般幾個服務(wù)會混布在一起，因此如何合理部署服務(wù)也是一個問題。除此之外，服務(wù)的平臺化還需要關(guān)注很多事情，用戶一般需要關(guān)注以下幾點(diǎn)：

1. 如何定義服務(wù)接口，使得用戶根據(jù)這個服務(wù)接口就可以自助完成服務(wù)訪問
2. 服務(wù)尋址：應(yīng)用方通過何種方式訪問訪問后臺的策略服務(wù)，如何做請求的負(fù)載均衡，后臺服務(wù)地址變更時，如何通知應(yīng)用方
3. 服務(wù)上線：既要保證上線新的服務(wù)不能影響老的服務(wù)，又要滿足當(dāng)前服務(wù)的資源需求
4. 服務(wù)擴(kuò)容：隨著請求的增加，如何擴(kuò)展實(shí)例數(shù)來滿足應(yīng)用方需要
5. 機(jī)器故障：機(jī)器出現(xiàn)故障時，如何保證服務(wù)質(zhì)量不受影響，如何將故障機(jī)器上的服務(wù)遷移到其他的節(jié)點(diǎn)
6.  服務(wù)升級：如何實(shí)現(xiàn)在不影響服務(wù)質(zhì)量的前提下完成服務(wù)的升級
7. 訪問統(tǒng)計：如何統(tǒng)計訪問量，服務(wù)延時，能夠區(qū)分不同用戶訪問的不同服務(wù)等，類似于Hadoop Counter，實(shí)現(xiàn)一個比較簡單通用的Counter
8. 監(jiān)控與報警：服務(wù)出現(xiàn)問題時，如何實(shí)現(xiàn)報警機(jī)制，以便第一時間發(fā)現(xiàn)并解決問題
9. 訪問權(quán)限與流控：服務(wù)屬于保密性質(zhì)，只能讓指定用戶使用;應(yīng)用方的訪問頻度需要按照約定來進(jìn)行限制
10. 服務(wù)實(shí)例的動態(tài)擴(kuò)容與縮容：為了節(jié)省資源，增加資源利用率，需要有動態(tài)擴(kuò)容與縮容的機(jī)制：即服務(wù)實(shí)例負(fù)載高的時候，能夠擴(kuò)容以滿足計算需求，而在負(fù)載低的時候，縮減服務(wù)實(shí)例以將機(jī)器資源給其他服務(wù)使用。

架構(gòu)當(dāng)然要去解決基礎(chǔ)算法平臺化的時候遇到的上述問題。但是除了這些問題之外，還需要關(guān)注以下問題：

1. 資源管理和調(diào)度：服務(wù)要分配哪些機(jī)器
2. 服務(wù)的部署：分配了機(jī)器后，服務(wù)實(shí)例的程序包如何下載，下載后如何拉起服務(wù)
3. 服務(wù)地址的匯報和更新：服務(wù)實(shí)例拉起后，如何匯報服務(wù)地址，讓應(yīng)用方使用這些地址，還有地址更新后，如何通知到應(yīng)用方
4. 資源隔離：只能給服務(wù)以承諾的配額，比如多少CPU，多少內(nèi)存;避免有問題的服務(wù)影響其他的服務(wù)
5. 不能影響服務(wù)的性能：這就要求不能用有性能損耗的虛擬化技術(shù)來做隔離等，我們要實(shí)現(xiàn)用戶直接使用物理機(jī)相同的性能效果
6. 計費(fèi)系統(tǒng)，按照不同的資源使用情況來計費(fèi)。對于公司內(nèi)部平臺來說，如果機(jī)器是平臺的，用戶只是使用，那么可以沒有這個系統(tǒng);但是如果需要服務(wù)的提供方提供機(jī)器，來換取相應(yīng)的計算資源，那么還是需要的。

由于以上問題，RD不能專注于核心策略的實(shí)現(xiàn)，不得不做很多平臺化的事情。當(dāng)然了，部分問題可以通過人工運(yùn)維的來完成的，但是這又會造成服務(wù)的維護(hù)成本過高。而且，人工運(yùn)維總有一定的滯后性，可能在某些場景下會出現(xiàn)服務(wù)質(zhì)量下降的問題。還有機(jī)器的資源利用率的問題，也是一個復(fù)雜問題。

#p#

如何解決上述問題

那么如何解決上述問題，這里我們給出一些可能的解決方案：

1. 如何定義服務(wù)接口：使用一些通用的RPC解決方案，比如Thrift。像我們使用的是sofa-pbrpc，https://github.com/baidu/sofa-pbrpc。這個是百度內(nèi)部應(yīng)用比較廣泛的一個RPC，有針對于公司內(nèi)部應(yīng)用場景的豐富組件。

2. 服務(wù)尋址：簡單來說定義一個接口通知應(yīng)用方后臺服務(wù)的地址。當(dāng)然sofa-pbrpc有實(shí)現(xiàn)的一個尋址組件，應(yīng)用方只需要指定一個名字就可以完成尋址，這個組件也完成了負(fù)載均衡的策略，能夠?qū)⒄埱蟠蛏⑵骄l(fā)送到后臺的服務(wù)商。當(dāng)然可以以ZK來實(shí)現(xiàn)尋址。比如服務(wù)實(shí)例拉起后將自己的地址添加到ZK的一個節(jié)點(diǎn)下，退出時由于與ZK的連接斷開而自動刪除自己。這樣應(yīng)用方只要監(jiān)控這個節(jié)點(diǎn)的數(shù)據(jù)變化即可。負(fù)載均衡的話最簡單的就是將請求按照順序發(fā)送到后臺。但是有一個問題就是機(jī)器可能處理能力是不相同的，就是集群的機(jī)器都是異構(gòu)的，因此可以記錄一下每個節(jié)點(diǎn)的處理能力，當(dāng)一個服務(wù)節(jié)點(diǎn)pending的請求比較多時，那么就優(yōu)先發(fā)給處理請求比較快的節(jié)點(diǎn)上。

3. 服務(wù)上線：這個實(shí)際上需要集群資源管理與調(diào)度的功能，就是用戶提交了服務(wù)上線的請求時，按照用戶的資源請求，比如每個服務(wù)實(shí)例需要多少CPU Core， Memory以及網(wǎng)絡(luò)等的情況，還有實(shí)例的個數(shù)，為這個服務(wù)分配計算資源。集群會選擇符合這個服務(wù)的機(jī)器節(jié)點(diǎn)，分配給服務(wù)。這個分配算法業(yè)界也有很多研究，核心就是提供資源利用率，而又要保證服務(wù)的質(zhì)量。對這個有興趣的可以看一下dominant resource fairness算法。

分配了計算資源后，就需要在節(jié)點(diǎn)上把這個服務(wù)部署好，部署完成后把服務(wù)拉起。

4. 服務(wù)擴(kuò)容：當(dāng)服務(wù)的負(fù)載變高時，需要擴(kuò)容服務(wù)實(shí)例數(shù)。這個其實(shí)和服務(wù)上線差不多，需要分配計算資源，部署，服務(wù)拉起等。

5. 機(jī)器故障：任何云平臺都要考慮這個情況，尤其是機(jī)器數(shù)量多的時候，機(jī)器故障幾乎成為一個必然會發(fā)生的事情。這個需要下線這個機(jī)器，即資源調(diào)度模塊標(biāo)記該機(jī)器未不可用。其次還需要將該機(jī)器上運(yùn)行的服務(wù)實(shí)例遷移到其他節(jié)點(diǎn)。

6. 服務(wù)升級：這個過程可以不需要資源調(diào)度模塊的參與：在各自的服務(wù)實(shí)例所在的節(jié)點(diǎn)上就地升級，比如直接下載程序包，下載完成準(zhǔn)備好環(huán)境后直接停止原來的進(jìn)程，啟動新部署的即可。當(dāng)然這個進(jìn)程重啟勢必會影響服務(wù)質(zhì)量。如果服務(wù)要求不需要是100%的，那么可能這個最簡單的方法也是可以接受的。當(dāng)然也可以在客戶端加重試的邏輯，如果延時能夠忍受的話。

另外一個方法就是重新分配一些節(jié)點(diǎn)，然后啟動新的服務(wù)實(shí)例后，將老的機(jī)器先從應(yīng)用方的尋址中刪除，保證不會再有新請求達(dá)到老的服務(wù)實(shí)例。在服務(wù)實(shí)例的負(fù)載都為0時，老的服務(wù)實(shí)例下線。這樣做稍微復(fù)雜，但是不會影響服務(wù)質(zhì)量。但是如果服務(wù)實(shí)例數(shù)百上千，那么這個代價會比較高，甚至沒有足夠的節(jié)點(diǎn)來完成這個升級。當(dāng)然可以分批次升級，這樣無疑有復(fù)雜了些。

第一個方法有一個優(yōu)點(diǎn)，由于都是就地升級的，因此可以快速回滾的老的版本，因?yàn)椴恍枰掳?，回滾的時間開銷就是進(jìn)程重啟的時間。

7. 訪問統(tǒng)計：互聯(lián)網(wǎng)公司都會有這個模塊，就是分布式日志的收集，匯聚和展現(xiàn)。以便展示服務(wù)的調(diào)用量，延時，等等的報表。這個開源社區(qū)也有很多的實(shí)現(xiàn)。一般來說就是每個服務(wù)實(shí)例打印訪問統(tǒng)計的日志，這些目標(biāo)日志會被部署到每個節(jié)點(diǎn)的agent收集，發(fā)送到比如一個MQ里，然后由一些工作線程去處理這些日志。

8. 監(jiān)控與報警：平臺資源的整體使用量，集群節(jié)點(diǎn)的資源使用情況，比如CPU IDLE，Memory的監(jiān)控，服務(wù)實(shí)例狀態(tài)的監(jiān)控等。在檢測到異常觸發(fā)閾值時報警給用戶，或者集群管理員等。

9. 訪問權(quán)限與流控：這個可以和公司的賬號體系打通，這樣就可以追蹤到非常細(xì)粒度的訪問權(quán)限控制，當(dāng)然簡單的做法也可以直接使用訪問者IP來做限制，實(shí)行IP白名單的制度。流控對于離線服務(wù)比較重要，離線服務(wù)注重吞吐，但是有時候一個Hadoop任務(wù)起來，可能發(fā)到后臺的壓力非常大，因此流控可以保證后臺服務(wù)不被壓垮，或者保證每個Task不會與其他的Task有資源的競爭。對于在線服務(wù)，流控有的時候也會有，比如拒絕一部分請求，總比大家都一起慢下來，但是誰都用不了好。說道這里，又想起一個集群的慢節(jié)點(diǎn)的問題，就是一個集群有dead的節(jié)點(diǎn)不害怕，就怕有比較挫的節(jié)點(diǎn)，運(yùn)行超慢但是半死不活，特殊情況下可能會拖累整個平臺?？梢钥匆幌逻@個文章：http://danluu.com/limplock/

10. 服務(wù)實(shí)例的動態(tài)擴(kuò)容與縮容：有的同學(xué)會問服務(wù)實(shí)例如果沒有計算，就空跑在那里唄，但是至少它會占用內(nèi)存，而且，一般集群為一個服務(wù)分配計算資源時，一般會以CPU，內(nèi)存為度量單位，因此如果一個服務(wù)占用了CPU，內(nèi)存，那么就會保證它至少能用到這些，對于在線服務(wù)來說，“虛擬”一些資源出來在某些場景下會影響服務(wù)質(zhì)量的。

上面這個問題，任何一個問題都可以衍生出好多問題。因此，本文是我想給大家分享的自己構(gòu)建一個云平臺的時候，需要注意的事情和需要關(guān)注的點(diǎn)。完全是拋磚引玉。

我們在過去的一年中，使用Go實(shí)現(xiàn)了這么一個云平臺。在這里也推薦一下Go。標(biāo)題中的Go，實(shí)際上就是Go的意思。Go，云時代的系統(tǒng)編程語言，就像過去十年服務(wù)器的編程語言是C一樣，學(xué)了你就知道這句話什么含義了。

Cloud，Go!

博文出處：http://blog.csdn.net/anzhsoft/article/details/49029129