移動雲平臺的基礎架構之旅(二)- 雲代碼篇

雲代碼的由來

隨着MBaaS的發展,取代移動企業應用程序平臺的趨勢也愈來愈明顯。MBaaS系統爲了讓企業能方便快捷的開發本身移動應用程序,提供了諸多移動客戶端支持,有最通用的REST API,也有方便移動開發者的軟件開發工具包,還有必定程度的監控和分析服務提供。而對於相對比較複雜的應用程序,開發者有時不想也沒必要在移動設備上運行很複雜或很費時或沒法實現的業務邏輯,這種需求催生了雲代碼的產生。java

MaxLeap-Cloud-Code-1

雲代碼的願景

想象一下,若是你想要少許結果信息,但卻必需要向設備發送大量對象列表,或者調用大量REST API才能完成此項工做時(好比統計彙總操做),這種操做顯然會消耗你大量的帶寬和用戶流量。mysql

想象一下,若是你想要設備週期性定時完成某個任務或者想在後臺一直運行某個任務(好比資源回收垃圾清理),這種操做顯然很不可靠,一方面用戶可能會隨時關閉設備上的應用,另外一方面在後臺一直運行某個任務顯然也會耗費用戶設備電量等資源,得不償失。linux

想象一下,當你須要調用第三方平臺API時須要對方回調時好比完成某個支付操做,服務提供商在支付成功後執行回調,你須要根據回調結果完成後續操做好比同步記錄到數據庫中,這種操做在移動應用在沒有本身的後端服務器時也很難完成。ios

想象一下,你的某個App應用有iOS,Android,JavaScript等多個設備平臺版本,當你新增一項功能,同一套業務邏輯須要在全部平臺作同步開發,當你修改一項功能,一樣須要在全部設備平臺作新版本發佈更新操做,若是產品迭代很迅速那這種頻繁的操做顯然會大大增長移動開發的成本和效率,但效果卻可能不見得很好。git

想象一下,當某個用戶註冊了你的應用,你須要對該用戶增長一些信息來用於統計,或者用戶購買了應用裏的某個商品,你須要收集除訂單外額外的信息,這類在用戶觸發某些特定操做時會自動額外產生的邏輯(Hook操做),這些Hook操做並不適用在移動端編寫。算法

伴隨移動開發,相似上面的狀況多有發生,此時MBaaS系統提供的雲代碼功能就是爲移動應用量身定作的解決相似上面問題的方案,雲代碼的願景就是方便移動開發者完全擺脫服務器,爲所欲爲的開發各類移動應用程序。sql

MaxLeap做爲一款優秀的MBaaS平臺系統,其雲代碼的功能如何,是如何實現的,又有哪些加分項,接下來將爲你們一一揭曉。docker

MaxLeap雲代碼的功能

有了雲代碼的背景願景,那雲代碼須要提供的基礎功能就很顯然了數據庫

  • 首先得提供基礎服務和框架,方便用戶開發雲代碼segmentfault

  • 其次得提供代碼託管,能很方便的讓用戶快速部署代碼到雲端運行

  • 最後提供日誌和相關監控工具,能對線上代碼的錯誤及性能特徵有更多瞭解,以便優化本身的程序

MaxLeap雲代碼的實現

一、讓開發者如何開發雲代碼

如何提供基礎服務和框架來方便用戶開發?因爲用戶的開發環境和擅長的開發語言各類各樣,好比使用Java,使用NodeJs,使用Python,使用JavaScript的等等,咱們提供對應的各個開發語言的基礎雲代碼SDK,豐富用戶的選擇,下降用戶開發門檻和成本,這樣雲代碼在CloudCode SDK基礎上開發就會很是便捷,這些CloudCode SDK和MBaaS對外提供的移動SDK不一樣的地方在於它並不在移動設備上運行,而是在雲端運行。也就是說開發者先要選擇本身喜歡的雲代碼SDK,好比我很擅長JAVA,因此我會選擇cloud-code-java-sdk來開發個人雲代碼,同時雲代碼SDK還要提供本地開發測試框架,總不能讓用戶線上開發調試吧,本地開發本地調試完成後再部署到雲端。固然爲了開發者更快的開始,MaxLeap同時提供了Demo和Quick-Start項目來讓開發者更快接觸雲代碼。

二、雲代碼如何爲用戶提供服務

開發者在使用雲代碼部署到雲端後該如何訪問雲代碼?MaxLeap的雲代碼是經過基礎的REST API來訪問,雲代碼SDK負責提供Http服務對外暴露REST API,由於基於Http能夠很好的兼容不一樣開發語言,實現跨平臺訪問,固然這些API不會直接暴露在用戶面前,用戶只有經過調用MBaaS的雲代碼服務API才能間接訪問。

MaxLeap-cloud-code-2

三、雲代碼能爲用戶提供哪些服務

不一樣開發語言的基礎雲代碼SDK其實都具備相同的功能,最重要的是數據存儲服務,CloudCode SDK經過封裝一系列REST API來讓開發者很便捷的訪問基礎MBaaS服務。除此以外還要提供雲函數、後臺任務、Hook操做、消息推送、日誌、安全訪問、分佈式計數器、分佈式鎖等功能。

MaxLeap-cloud-code-3

  • 數據存儲服務

經過SDK能夠很方便的使用MaxLeap的存儲服務,例如對象的CRUD操做,同時集成了手機行業主流的金幣系統。

  • 雲函數

運行在MaxLeap雲端的函數,定義好雲函數後能夠經過REST API方式來訪問,這個API是同步的。同時雲函數提供白名單功能(經過界面設置),方便被其餘第三方網絡服務調用。

  • 後臺任務

一樣是運行在MaxLeap雲端的函數,對於長期運行的任務而言,後臺任務很是有用,例如與響應時間較長的外部網站集成或分批發送推送通知。若是您在運行雲函數時常常遇到超時錯誤,則能夠考慮使用後臺任務,同時當您部署雲代碼後,可經過後臺界面進行計劃任務,你能夠計劃一次性任務或者週期性任務,這不但能夠方便管理你的後臺任務,同時也能清楚的追蹤你的任務狀態。

  • Hook操做

Hook用於在對 Cloud Data 進行任何操做時(包括新建,刪除及修改)執行特定的操做。例如,咱們在用戶註冊成功以前,能夠經過beforeCreate Hook,來檢查其是否重名。也能夠在其註冊成功以後,經過afterCreate Hook,向其發送一條歡迎信息。Hook能很好地實現與數據操做相關的業務邏輯,它的優點在於,全部的業務在雲端實現,並且被不一樣的應用/平臺共享。

  • 消息推送

在移動應用中,爲每一個客戶端用戶推送系統消息或定製消息必不可少,經過該功能開發者能夠很便捷的將消息推送到全部或指定設備上。

  • 分佈式計數器/鎖

雲代碼在雲端是一個分佈式應用,提供計數器、鎖相關的功能以便多個實例之間能夠共享同一份數據。

  • 日誌

提供Logging功能,以便您能記錄Function,Hook或者Job在運行過程當中出現的信息。

  • 命令行工具

能夠方便用戶雲代碼項目的上傳,部署,中止及版本管理。

四、雲代碼該如何管理

雲代碼做爲在雲端部署的代碼,MaxLeap是如何管理它們的呢?在這項重中之重方面咱們可能會遇到下面這些問題:

  • 每一個開發者的環境不一樣,操做系統也不相同,如何下降搭建各類環境的成本以及下降對操做系統的依賴、下降硬件要求和應用環境之間耦合度同時下降虛擬化消耗?

  • 管理的應用可能成千上萬,可是服務器資源就那麼多,該如何對每一個應用實現虛擬化來整合應用和服務器下降成本?

  • 每一個應用的重要程度也不一樣,有重度用戶須要高可用高性能的服務,有低度用戶可能一天也不會有幾個請求,資源該如何分配?

  • 用戶的代碼部署在雲端,如何保證用戶的應用代碼安全?

  • 用戶代碼服務如何作到高可用,出現故障該如何轉移,如何作到服務不間斷,新發布的代碼出現異常該如何回滾?

基於上面遇到的問題,咱們把用戶的雲代碼做爲一個鬆耦合的單個服務,也就是如今流行的微服務架構,經過docker來實現對微服務容器化,由於docker自己就是源於Paas,在MBaaS系統也很是適用,咱們不用爲每一個雲代碼應用開啓一個虛擬機來下降硬件要求和應用環境之間的耦合度,這能大大下降虛擬化消耗,下降成本,並且docker還能爲應用提供一個從開發到部署上線都一致的環境,很是便於管理代碼的流水線,讓咱們能夠對雲代碼從開發到發佈部署簡單可靠的控制。同時Docker隔離應用的能力很是適用於用戶的雲代碼,能讓咱們比經過虛擬機更好的整合雲代碼應用和服務器,基於docker,咱們能爲每一個不一樣的雲代碼應用建立隔離的環境,併爲他們分配指定的服務端口、內存資源等來隔離應用。

MaxLeap-cloud-code-4

在咱們看來用戶每次的代碼發佈都是一個構建鏡像並推送鏡像到私服上的過程,每次代碼部署都是從私服上獲取鏡像並啓動一個容器的過程,每次中止部署都是一個容器卸載的過程,每次升級代碼都是一個從新生成不一樣標籤的應用鏡像的過程。用戶每次上傳發布雲代碼都須要爲它指定一個版本,不一樣的版本會生成不一樣的鏡像標籤,能夠同時部署多個版本,但咱們作了限制,最多隻能同時發佈2個版本,咱們稱之爲灰度發佈,這是爲了能讓你的代碼能平滑過渡升級,在灰度發佈過程當中用戶須要設置版本負載均衡比重,以作到服務不間斷,基於版本控制你能夠回滾你的代碼,你能夠選擇你發佈過的任意版本進行部署,這真的很是方便。

MaxLeap-cloud-code-5

對於用戶的雲代碼鏡像、啓動的容器、部署的策略以及容器所在的宿主機咱們會有一個專門的CloudCode-Manager服務來進行管理,咱們稱這個服務爲hydra(海德拉)。它希臘神話中的九頭蛇,傳說它擁有九顆頭,其中一顆頭要是被斬斷,馬上又會生出兩顆頭來,在這裏咱們寓意用戶的雲代碼能夠達到高可用,若是用戶部署的任何一個雲代碼實例出現故障達到服務不用,系統會自動在其餘宿主機上從新啓動一個相同實例。爲了達到高可用、故障轉移,雲代碼SDK須要提供心跳接口,在用戶部署雲代碼後每隔一段時間hydra都會作心跳檢查,檢查失敗重試必定次數後便認爲該服務已經失效,咱們會在另外一臺宿主機上從新部署一個和故障實例如出一轍的實例,而後再卸載故障實例,若是卸載故障實例失敗,好比故障實例所在的宿主機發生宕機,那麼該故障實例會永久成爲一個孤島實例等待被強制回收。若是應用的雲代碼被重度使用超過負荷能夠隨時擴容,或者經過縮容來較少成本,經過任意擴容和縮容也就是經過部署容器任意實例數量來真正達到高可用,最經常使用的使用場景是商家在作活動時有訪問高峯能夠快速增長實例資源來減小壓力,平常時則減小實例以低成本運行。

經過docker來整合應用和服務器,一臺宿主機上可能部署了上百個容器應用,那應用是如何分發的呢,在雲代碼SDK中咱們提供了REST服務,好比雲函數、後臺任務、心跳等API,全部應用的這些REST服務在啓動後都是監聽在容器的8080端口,容器須要容許外部訪問就必需要映射容器端口到宿主機,因此在應用分發過程當中,宿主機的端口管理很是必要,咱們使用mysql來存儲全部宿主機的信息,包括全部提供給雲代碼容器使用的可用端口,經過樂觀鎖來保證端口的併發分配,啓動任意雲代碼容器時都會分配一個映射端口給容器,同時在zookeeper中同步應用的雲代碼服務地址提供給MBaaS雲代碼服務使用。這個過程使用事務來保證容器啓動和數據庫信息的一致性,同時使用zookeeper分佈式鎖來防止同一個應用被同時操做。雲代碼服務的REST層實時監控zookeeper中雲容器訪問地址信息變動,經過hosting形式提供路由功能,經過負載均衡算法選擇可用地址來訪問宿主機上的雲代碼達到分流效果,這樣就能作到簡單有效的應用分發。

上面咱們說到雲代碼容器經過端口映射來容許外部訪問,但考慮到用戶的代碼安全,並非任何機器均可以訪問雲代碼容器,這就須要一個網絡安全體系來對用戶的訪問和網絡進行限制。在網絡隔離安全方面,咱們在Docker的標準網絡橋接接口docker0上啓用內核防火牆iptables規則來限制Docker容器的源IP地址範圍與外界通信,全部的雲代碼宿主機只能由maxleap和hydra服務所在的機器訪問,而云代碼訪問maxleap內部服務須要經過反向代理實現。

MaxLeap-cloud-code-6

在宿主機和容器之間安全隔離方面,經過訪問控制的安全策略,使用selinux配置Linux內核安全模塊,從而實現強制性的訪問控制(MAC)用以將進程約束在一套有限的系統資源或權限中。在容器與容器之間經過cgroups防止經過耗盡系統資源引起拒絕服務(DoS)攻擊,好比限制容器的CPU使用、內存使用、存儲使用。

五、雲代碼該如何監控

使用微服務容器化雲代碼能爲應用開發者省去部署和維護方面的負擔,但代價是必定程度上減弱了線上環境的透明性,爲了能對線上代碼的錯誤和性能特徵有更多瞭解以便優化本身的代碼或者擴容、縮容來達到水平擴展,咱們須要給很好的監控雲代碼。

MaxLeap-cloud-code-7

一、首先是日誌信息的收集,雲代碼的系統日誌、用戶的日誌這些都須要收集起來提供給用戶查看,MaxLeap的雲代碼使用主流的Logstash+elasticsearch來完成日誌收集工做,咱們會在每臺宿主機上啓動一個logstash-forwarder服務做爲shipper來收集指定的雲代碼日誌,Logstash匯聚日誌後轉發到ES存儲。

二、其次是對容器資源的監控,Docker容器經過namespace作資源隔離,經過cgroup來作資源限制,咱們有個專門的docker-monitor服務來監控全部宿主機上雲代碼容器的指標,它會週期性獲取已註冊的宿主機上全部雲代碼容器的cgroup stats,收集指標包括CPU MEM IO等,而後將數據PUSH到ES裏。

三、最後是展現給用戶,MaxLeap經過後臺界面的方式展現出全部容器實例的性能和狀態,還有部署的雲代碼版本全部的日誌信息,用戶能夠很直觀的瞭解到本身的雲代碼有什麼錯誤的信息,在什麼地方有瓶頸,該在哪方面優化代碼。而咱們內部會經過Kibana來展現,並經過Nagios來報警。

MaxLeap雲代碼的衍生-雲容器

有客戶看到這裏說:你說了那麼多,我就是不想用你的雲代碼SDK來寫,熟悉你的SDK都要花費好長時間,用看官方文檔頭都大了,我就想用關係型數據庫,我就是想用我本身寫的後端服務或者以前公司已經寫好的程序,咋辦?嘿,MBaaS系統的願景是讓用戶徹底擺脫服務器,但遇到這種已經有本身服務器和數據庫並大量線上使用的客戶讓他們選擇MBaaS系統便得仔細考量是否值得了。考量到這類需求,MaxLeap在雲代碼的基礎上衍生出了雲容器的概念,它是能夠幫助用戶部署及運維其後端應用程序的代碼託管服務,用戶只須要提供服務端的業務邏輯,包括靜態網站或者動態應用程序,而服務端的高可用、多實例、負載均衡、不中斷服務的平滑升級等都由雲容器提供支持。沒錯,雲代碼有的功能它均可以有,雲代碼沒有的功能它也有,一個是數據源功能,不少企業客戶內部使用的數據庫都是mysql這種關係型數據庫,讓他們一下切換到MBaaS上的NoSql數據庫會很不放心,特別對事務要求很嚴格的業務邏輯,人家可能一看到你的數據庫是使用Nosql就放棄了,能很方便的遷移也不行,就是這麼直接,雲容器的數據源功能則會幫讓他們放下很大一部分顧慮,它可讓用戶使用並管理本身的關係型數據庫,而另外一個二級域名功能可讓用戶在部署雲容器後能夠直接訪問他的雲服務。做爲雲代碼的升級版,雲容器的底層架構都是基於雲代碼的實現,這徹底下降了用戶Dev&Ops上的難度。因爲篇幅緣由,更多雲容器相關的信息本篇文章再也不贅述了。

MaxLeap雲代碼的展望

看到這咱們發現MaxLeap的雲代碼、雲容器的架構基本都是圍繞docker容器這個生態圈來實現的,那麼如何更好的維護和優化這個生態圈將是咱們未來的重中之重,在這裏咱們給出一些咱們將來一段時間將要實現和優化的關鍵信息:

MaxLeap-cloud-code-8

  • 全部容器資源經過Mesos申請

  • 全部容器生命週期經過Marathon管理

  • 更智能的資源分配機制,更智能的壓力監控實現自動擴容/縮容

  • 用戶雲代碼託管方式支持git等第三方倉庫

  • 用戶上傳雲代碼、雲容器支持增量上傳來減小等待時間

  • 更多容器安全方面的優化

  • 更多雲代碼/容器操做的Dev&Ops自動化

  • 更多基建架構方面的調整優化

MaxLeap更強大更優秀的雲代碼/雲容器服務敬請你們期待。


相關閱讀:
移動雲平臺的基礎架構之旅-雲應用篇

做者系力譜宿雲 LeapCloud 團隊_雲服務研發成員:David Young【原創】
力譜宿雲首發地址:https://blog.maxleap.cn/archi...

歡迎關注微信訂閱號:從移動到雲端
歡迎加入咱們的MaxLeap活動QQ羣:555973817,咱們將不按期作技術分享活動。

如有轉載須要,請轉發時注意自帶做者信息一欄並本自媒體公號:力譜宿雲 LeapCloud,尊重原創做者的勞動成果~ 謝謝配合~

相關文章
相關標籤/搜索