摘要：作為一款優秀的平臺系統，其云代碼的功能如何，是如何實現的，又有哪些加分項，接下來將為大家一一揭曉。當然為了開發者更快的開始，同時提供了和項目來讓開發者更快接觸云代碼。

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

想象一下，如果你想要少量結果信息，但卻必須要向設備發送大量對象列表，或者調用大量REST API才能完成此項工作時（比如統計匯總操作），這種操作顯然會消耗你大量的帶寬和用戶流量。

想象一下，如果你想要設備周期性定時完成某個任務或者想在后臺一直運行某個任務（比如資源回收垃圾清理），這種操作顯然很不可靠，一方面用戶可能會隨時關閉設備上的應用，另一方面在后臺一直運行某個任務顯然也會耗費用戶設備電量等資源，得不償失。

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

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

想象一下，當某個用戶注冊了你的應用，你需要對該用戶增加一些信息來用于統計，或者用戶購買了應用里的某個商品，你需要收集除訂單外額外的信息，這類在用戶觸發某些特定操作時會自動額外產生的邏輯（Hook操作），這些Hook操作并不適用在移動端編寫。

伴隨移動開發，類似上面的情況多有發生，此時MBaaS系統提供的云代碼功能就是為移動應用量身定做的解決類似上面問題的方案，云代碼的愿景就是方便移動開發者徹底擺脫服務器，隨心所欲的開發各種移動應用程序。

MaxLeap作為一款優秀的MBaaS平臺系統，其云代碼的功能如何，是如何實現的，又有哪些加分項，接下來將為大家一一揭曉。

有了云代碼的背景愿景，那云代碼需要提供的基礎功能就很顯然了

首先得提供基礎服務和框架，方便用戶開發云代碼

其次得提供代碼托管，能很方便的讓用戶快速部署代碼到云端運行

最后提供日志和相關監控工具，能對線上代碼的錯誤及性能特征有更多了解，以便優化自己的程序

如何提供基礎服務和框架來方便用戶開發？由于用戶的開發環境和擅長的開發語言各種各樣，比如使用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才能間接訪問。

不同開發語言的基礎云代碼SDK其實都具有相同的功能，最重要的是數據存儲服務，CloudCode SDK通過封裝一系列REST API來讓開發者很便捷的訪問基礎MBaaS服務。除此之外還要提供云函數、后臺任務、Hook操作、消息推送、日志、安全訪問、分布式計數器、分布式鎖等功能。

數據存儲服務

通過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，我們能為每個不同的云代碼應用創建隔離的環境，并為他們分配指定的服務端口、內存資源等來隔離應用。

在我們看來用戶每次的代碼發布都是一個構建鏡像并推送鏡像到私服上的過程，每次代碼部署都是從私服上獲取鏡像并啟動一個容器的過程，每次停止部署都是一個容器卸載的過程，每次升級代碼都是一個重新生成不同標簽的應用鏡像的過程。用戶每次上傳發布云代碼都需要為它指定一個版本，不同的版本會生成不同的鏡像標簽，可以同時部署多個版本，但我們做了限制，最多只能同時發布2個版本，我們稱之為灰度發布，這是為了能讓你的代碼能平滑過渡升級，在灰度發布過程中用戶需要設置版本負載均衡比重，以做到服務不間斷，基于版本控制你可以回滾你的代碼，你可以選擇你發布過的任意版本進行部署，這真的非常方便。

對于用戶的云代碼鏡像、啟動的容器、部署的策略以及容器所在的宿主機我們會有一個專門的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內部服務需要通過反向代理實現。

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

使用微服務容器化云代碼能為應用開發者省去部署和維護方面的負擔，但代價是一定程度上減弱了線上環境的透明性，為了能對線上代碼的錯誤和性能特征有更多了解以便優化自己的代碼或者擴容、縮容來達到水平擴展，我們需要給很好的監控云代碼。

1、首先是日志信息的收集，云代碼的系統日志、用戶的日志這些都需要收集起來提供給用戶查看，MaxLeap的云代碼使用主流的Logstash+elasticsearch來完成日志收集工作，我們會在每臺宿主機上啟動一個logstash-forwarder服務作為shipper來收集指定的云代碼日志，Logstash匯聚日志后轉發到ES存儲。

2、其次是對容器資源的監控，Docker容器通過namespace做資源隔離，通過cgroup來做資源限制，我們有個專門的docker-monitor服務來監控所有宿主機上云代碼容器的指標，它會周期性獲取已注冊的宿主機上所有云代碼容器的cgroup stats，收集指標包括CPU MEM IO等，然后將數據PUSH到ES里。

3、最后是展示給用戶，MaxLeap通過后臺界面的方式展示出所有容器實例的性能和狀態，還有部署的云代碼版本所有的日志信息，用戶可以很直觀的了解到自己的云代碼有什么錯誤的信息，在什么地方有瓶頸，該在哪方面優化代碼。而我們內部會通過Kibana來展示，并通過Nagios來報警。

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

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

所有容器資源通過Mesos申請

所有容器生命周期通過Marathon管理

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

用戶云代碼托管方式支持git等第三方倉庫

用戶上傳云代碼、云容器支持增量上傳來減少等待時間

更多容器安全方面的優化

更多云代碼/容器操作的Dev&Ops自動化

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

MaxLeap更強大更優秀的云代碼/云容器服務敬請大家期待。

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

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

歡迎關注微信訂閱號：從移動到云端
歡迎加入我們的MaxLeap活動QQ群：555973817，我們將不定期做技術分享活動。

若有轉載需要，請轉發時注意自帶作者信息一欄并本自媒體公號：力譜宿云 LeapCloud，尊重原創作者的勞動成果~ 謝謝配合~