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

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

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

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

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

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

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

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

服務(wù)平臺(tái)化需要面對(duì)的問題

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

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

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

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

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

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

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

#p#

如何解決上述問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloud，Go!

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