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

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

基礎算法直接以庫的形式提供給應用方?

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

基礎算法的服務化

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

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

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

服務平臺化需要面對的問題

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

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

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

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

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

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

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

#p#

如何解決上述問題

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

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

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

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

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

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

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

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

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

第一個方法有一個優(yōu)點，由于都是就地升級的，因此可以快速回滾的老的版本，因為不需要下包了，回滾的時間開銷就是進程重啟的時間。

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

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

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

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

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

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

Cloud，Go!

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