最近一年的工作，有很大的比重在做雲平臺的事情，簡單來說，就是爲公司內用戶提供一個PaaS，用戶可以在我們的雲平臺上方便的將單機服務程序擴展爲多實例程序，以平臺服務化的方式對外提供。在這裏簡單分享一下。
首先簡單說一下我們解決了用戶的什麼需求，或者說痛點。
基礎算法直接以庫的形式提供給應用方？
用戶提供了一個基礎算法，這個算法可能以一個動態庫的形式提供，那麼使應用方需要關注編譯依賴，需要關注詞典等模型文件，開發成本比較高。尤其是如果這個基礎算法需要升級，或者模型文件需要升級的時候，還需要通知應用方進行修改。而且，如果基礎算法不穩定，有出core的行爲，那麼勢必影響了應用方的服務質量。還有就是，如果基礎算法非常耗資源，比如CPU，內存佔得太多，可能會影響應用方程序對於資源的使用。
基礎算法的服務化
爲了避免基礎算法以動態庫提供給應用方的種種弊端，基礎算法可以以網絡服務的形式提供，這就是基礎算法的服務化。就是說，基礎算法是一個網絡服務，用戶直接訪問這個網絡服務即可。這樣，基礎算法的服務接口只要不變，不論它如何升級，都不需要應用方做任何修改。開源的Thrift，等等RPC的方案，都很好的滿足了基礎算法服務化的需求。
服務化的質量如何衡量
那麼一個服務化的基礎算法，如何保證上面所說的服務質量和延時上的要求呢。尤其是服務質量，或者說可靠性。如果我們假設機器永遠無故障，網絡設備也永遠運行正常，服務也足夠穩定，不會有core，也不會升級等等，那麼直接找一些機器拉起來就萬事大吉了。但是，現實卻是殘酷了，首先服務可能會有故障，它應該會不斷升級（如果有一個不用升級的程序，要麼是太完美了，要麼就是沒有人用了，大家寫程序都知道，完美的程序你永遠寫不出來，少寫點爛代碼纔是正常追求），升級的過程不能影響服務質量，還有服務不可能獨佔機器的，很有可能會和其他服務混布，那麼如何選擇合適的機器部署，也是一個問題。還有，很多時候一個服務實例是滿足不了需求的，可能要部署多個服務實例，這裏邊的問題就更多了，請求發給哪個實例，負載均衡，等等等。
服務平臺化需要面對的問題
我們下面將服務化的基礎算法，以承諾的服務質量對外提供的過程，稱爲服務的平臺化。就是說，服務化的基礎算法，經過一個平臺對外提供，就能獲得相應的服務質量。那麼平臺化的挑戰有哪些呢？
如果一個基礎算法自己想實現平臺化，閉門造車，需要做很多工作。這也是PaaS存在的意義，將大家服務化的工作都通用化，讓策略開發者解放出來。那麼，平臺化要解決的哪些問題，或者基礎算法服務化的痛點在哪裏呢？
服務的平臺化，並不是簡單的在幾臺機器上把一個服務部署起來，對外提供服務，尤其是對應用方承諾了服務質量的時候。而且，爲了提升機器的資源利用率，一般幾個服務會混布在一起，因此如何合理部署服務也是一個問題。除此之外，服務的平臺化還需要關注很多事情，用戶一般需要關注以下幾點：
1. 如何定義服務接口，使得用戶根據這個服務接口就可以自助完成服務訪問
2. 服務尋址：應用方通過何種方式訪問訪問後臺的策略服務，如何做請求的負載均衡，後臺服務地址變更時，如何通知應用方
3. 服務上線：既要保證上線新的服務不能影響老的服務，又要滿足當前服務的資源需求
4. 服務擴容：隨着請求的增加，如何擴展實例數來滿足應用方需要
5. 機器故障：機器出現故障時，如何保證服務質量不受影響，如何將故障機器上的服務遷移到其他的節點
6. 服務升級：如何實現在不影響服務質量的前提下完成服務的升級
7. 訪問統計：如何統計訪問量，服務延時，能夠區分不同用戶訪問的不同服務等，類似於Hadoop Counter，實現一個比較簡單通用的Counter
8. 監控與報警：服務出現問題時，如何實現報警機制，以便第一時間發現並解決問題
9. 訪問權限與流控：服務屬於保密性質，只能讓指定用戶使用；應用方的訪問頻度需要按照約定來進行限制
10. 服務實例的動態擴容與縮容：爲了節省資源，增加資源利用率，需要有動態擴容與縮容的機制：即服務實例負載高的時候，能夠擴容以滿足計算需求，而在負載低的時候，縮減服務實例以將機器資源給其他服務使用。
架構當然要去解決基礎算法平臺化的時候遇到的上述問題。但是除了這些問題之外，還需要關注以下問題：
1. 資源管理和調度：服務要分配哪些機器
2. 服務的部署：分配了機器後，服務實例的程序包如何下載，下載後如何拉起服務
3. 服務地址的彙報和更新：服務實例拉起後，如何彙報服務地址，讓應用方使用這些地址，還有地址更新後，如何通知到應用方
4. 資源隔離：只能給服務以承諾的配額，比如多少CPU，多少內存；避免有問題的服務影響其他的服務
5. 不能影響服務的性能：這就要求不能用有性能損耗的虛擬化技術來做隔離等，我們要實現用戶直接使用物理機相同的性能效果
6. 計費系統，按照不同的資源使用情況來計費。對於公司內部平臺來說，如果機器是平臺的，用戶只是使用，那麼可以沒有這個系統；但是如果需要服務的提供方提供機器，來換取相應的計算資源，那麼還是需要的。
由於以上問題，RD不能專注於核心策略的實現，不得不做很多平臺化的事情。當然了，部分問題可以通過人工運維的來完成的，但是這又會造成服務的維護成本過高。而且，人工運維總有一定的滯後性，可能在某些場景下會出現服務質量下降的問題。還有機器的資源利用率的問題，也是一個複雜問題。
如何解決上述問題
那麼如何解決上述問題，這裏我們給出一些可能的解決方案：
1. 如何定義服務接口：使用一些通用的RPC解決方案，比如Thrift。像我們使用的是sofa-pbrpc，https://github.com/baidu/sofa-pbrpc。這個是百度內部應用比較廣泛的一個RPC，有針對於公司內部應用場景的豐富組件。
2. 服務尋址：簡單來說定義一個接口通知應用方後臺服務的地址。當然sofa-pbrpc有實現的一個尋址組件，應用方只需要指定一個名字就可以完成尋址，這個組件也完成了負載均衡的策略，能夠將請求打散平均發送到後臺的服務商。當然可以以ZK來實現尋址。比如服務實例拉起後將自己的地址添加到ZK的一個節點下，退出時由於與ZK的連接斷開而自動刪除自己。這樣應用方只要監控這個節點的數據變化即可。負載均衡的話最簡單的就是將請求按照順序發送到後臺。但是有一個問題就是機器可能處理能力是不相同的，就是集羣的機器都是異構的，因此可以記錄一下每個節點的處理能力，當一個服務節點pending的請求比較多時，那麼就優先發給處理請求比較快的節點上。
3. 服務上線：這個實際上需要集羣資源管理與調度的功能，就是用戶提交了服務上線的請求時，按照用戶的資源請求，比如每個服務實例需要多少CPU Core， Memory以及網絡等的情況，還有實例的個數，爲這個服務分配計算資源。集羣會選擇符合這個服務的機器節點，分配給服務。這個分配算法業界也有很多研究，核心就是提供資源利用率，而又要保證服務的質量。對這個有興趣的可以看一下dominant resource fairness算法。
分配了計算資源後，就需要在節點上把這個服務部署好，部署完成後把服務拉起。
4. 服務擴容：當服務的負載變高時，需要擴容服務實例數。這個其實和服務上線差不多，需要分配計算資源，部署，服務拉起等。
5. 機器故障：任何雲平臺都要考慮這個情況，尤其是機器數量多的時候，機器故障幾乎成爲一個必然會發生的事情。這個需要下線這個機器，即資源調度模塊標記該機器未不可用。其次還需要將該機器上運行的服務實例遷移到其他節點。
6. 服務升級：這個過程可以不需要資源調度模塊的參與：在各自的服務實例所在的節點上就地升級，比如直接下載程序包，下載完成準備好環境後直接停止原來的進程，啓動新部署的即可。當然這個進程重啓勢必會影響服務質量。如果服務要求不需要是100%的，那麼可能這個最簡單的方法也是可以接受的。當然也可以在客戶端加重試的邏輯，如果延時能夠忍受的話。
另外一個方法就是重新分配一些節點，然後啓動新的服務實例後，將老的機器先從應用方的尋址中刪除，保證不會再有新請求達到老的服務實例。在服務實例的負載都爲0時，老的服務實例下線。這樣做稍微複雜，但是不會影響服務質量。但是如果服務實例數百上千，那麼這個代價會比較高，甚至沒有足夠的節點來完成這個升級。當然可以分批次升級，這樣無疑有複雜了些。
第一個方法有一個優點，由於都是就地升級的，因此可以快速回滾的老的版本，因爲不需要下包了，回滾的時間開銷就是進程重啓的時間。
7. 訪問統計：互聯網公司都會有這個模塊，就是分佈式日誌的收集，匯聚和展現。以便展示服務的調用量，延時，等等的報表。這個開源社區也有很多的實現。一般來說就是每個服務實例打印訪問統計的日誌，這些目標日誌會被部署到每個節點的agent收集，發送到比如一個MQ裏，然後由一些工作線程去處理這些日誌。
8. 監控與報警：平臺資源的整體使用量，集羣節點的資源使用情況，比如CPU IDLE，Memory的監控，服務實例狀態的監控等。在檢測到異常觸發閾值時報警給用戶，或者集羣管理員等。
9. 訪問權限與流控：這個可以和公司的賬號體系打通，這樣就可以追蹤到非常細粒度的訪問權限控制，當然簡單的做法也可以直接使用訪問者IP來做限制，實行IP白名單的制度。流控對於離線服務比較重要，離線服務注重吞吐，但是有時候一個Hadoop任務起來，可能發到後臺的壓力非常大，因此流控可以保證後臺服務不被壓垮，或者保證每個Task不會與其他的Task有資源的競爭。對於在線服務，流控有的時候也會有，比如拒絕一部分請求，總比大家都一起慢下來，但是誰都用不了好。說道這裏，又想起一個集羣的慢節點的問題，就是一個集羣有dead的節點不害怕，就怕有比較挫的節點，運行超慢但是半死不活，特殊情況下可能會拖累整個平臺。可以看一下這個文章：http://danluu.com/limplock/
10. 服務實例的動態擴容與縮容：有的同學會問服務實例如果沒有計算，就空跑在那裏唄，但是至少它會佔用內存，而且，一般集羣爲一個服務分配計算資源時，一般會以CPU，內存爲度量單位，因此如果一個服務佔用了CPU，內存，那麼就會保證它至少能用到這些，對於在線服務來說，“虛擬”一些資源出來在某些場景下會影響服務質量的。
上面這個問題，任何一個問題都可以衍生出好多問題。因此，本文是我想給大家分享的自己構建一個雲平臺的時候，需要注意的事情和需要關注的點。完全是拋磚引玉。
我們在過去的一年中，使用Go實現了這麼一個雲平臺。在這裏也推薦一下Go。標題中的Go，實際上就是Go的意思。Go，雲時代的系統編程語言，就像過去十年服務器的編程語言是C一樣，學了你就知道這句話什麼含義了。
最後做一個廣告吧，百度的同學如果看到這篇文章，可以搜索內網搜索SofaCloud，一個徹底解決策略開發者的平臺化之痛的雲平臺。除此之外，我們通過架構優化，還可以節省85%的業務方機器！！我們當前日均數百億的計算量，數千個計算實例，服務數十個產品線！！！想什麼呢，還不趕緊遷移到我們這上邊來！！！
用了SofaCloud後，明明的頭髮都長出來了有沒有！！！氣色變好了，有沒有！！！
Cloud，Go!