建站
咨詢
售后
建站咨詢
新聞中心
IaaS 本文主要是想聊一下在當(dāng)前云服務(wù)熱度越來(lái)越高的環(huán)境下，我們應(yīng)該如何做開(kāi)發(fā)，行業(yè)應(yīng)該如何發(fā)展。哇，話題好大，看過(guò)之后，你再?zèng)Q定要不要拍磚。
成都創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供洋縣網(wǎng)站建設(shè)、洋縣做網(wǎng)站、洋縣網(wǎng)站設(shè)計(jì)、洋縣網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)與制作、洋縣企業(yè)網(wǎng)站模板建站服務(wù)，十余年洋縣做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
引子
云服務(wù)的熱度越來(lái)越高，IaaS、PaaS、SaaS開(kāi)始逐漸為大家所知，論壇時(shí)期的那些草根站長(zhǎng)也開(kāi)始不自己購(gòu)買服務(wù)器轉(zhuǎn)而使用云主機(jī)了，大環(huán)境在慢慢變好，特別是對(duì)創(chuàng)業(yè)人員來(lái)說(shuō)。
不過(guò)所謂的云服務(wù)三個(gè)層次發(fā)展并不均衡，IaaS是真正做起來(lái)了，特別是aws，早就是一個(gè)很重要的收入源了，國(guó)內(nèi)來(lái)講，比較有名的就是阿里云、 UCloud、青云了，應(yīng)該也開(kāi)始盈利了，可喜可賀。但是PaaS并沒(méi)有做起來(lái)，GAE、SAE、BAE、JAE應(yīng)該沒(méi)有一個(gè)稱得上成功。至于SaaS，在筆者的認(rèn)知里，無(wú)非就是提供給大眾用的一個(gè)網(wǎng)站，有賬號(hào)體系，不同賬號(hào)有自己的數(shù)據(jù)，不做評(píng)價(jià)。
本文主要是想聊一下在當(dāng)前大環(huán)境下，我們應(yīng)該如何做開(kāi)發(fā)，行業(yè)應(yīng)該如何發(fā)展。哇，話題好大，口氣不小，每個(gè)人都有自己的理解，仁者見(jiàn)仁智者見(jiàn)智，筆者也只是碎碎念，可能觀點(diǎn)一無(wú)是處，錯(cuò)得離譜，讀者一笑置之，不要扔磚頭，砸到花花草草也是不好~
IaaS服務(wù)概述
首先，我們回顧一下現(xiàn)在IaaS廠商提供了什么
*云主機(jī)
這是必須的，否則就不是IaaS廠商了，至于用的Xen還是KVM，那咱們不關(guān)心，總之對(duì)用戶來(lái)講，拿到手的是一個(gè)指定CPU核數(shù)、指定內(nèi)存大小、指定磁盤大小和類型、指定網(wǎng)絡(luò)帶寬的機(jī)器。
如此一來(lái)，開(kāi)發(fā)者無(wú)需去花費(fèi)幾千甚至幾萬(wàn)塊購(gòu)買物理服務(wù)器了，初期買個(gè)配置低的云主機(jī)還是比較省錢，而且不用關(guān)心操作系統(tǒng)、yum源、機(jī)架、網(wǎng)絡(luò)、交換機(jī)、網(wǎng)線、機(jī)房租賃費(fèi)用等等問(wèn)題，著實(shí)省心不少。
*周邊服務(wù)
一個(gè)服務(wù)要想跑起來(lái)，光有服務(wù)器和操作系統(tǒng)是不夠的，我們通常還要依賴一些周邊服務(wù)，比如數(shù)據(jù)庫(kù)、Cache、Redis、MQ、存儲(chǔ)、LB等等，如果只有云主機(jī)，那我們需要自己在云主機(jī)上搭建并維護(hù)這些服務(wù)。對(duì)于一些資深棧溢出工程師那肯定是沒(méi)問(wèn)題的，但是大部分人都是各有所長(zhǎng)，一個(gè)好的開(kāi)發(fā)并不一定是個(gè)好的DBA。
這些IaaS廠商也意識(shí)到這個(gè)問(wèn)題，他們會(huì)把這些周邊服務(wù)統(tǒng)一管理、運(yùn)維，然后賣給開(kāi)發(fā)者，其實(shí)這是個(gè)好事，IaaS廠商雇用專業(yè)的人士來(lái)打磨這些服務(wù)，通常都要比我們?cè)谠浦鳈C(jī)上手工搭建的要穩(wěn)定、高效、安全、可用。而IaaS廠商統(tǒng)一處理這些周邊服務(wù)之后很容易形成規(guī)模效應(yīng)，成本可以做得更低，穩(wěn)定性也更好，雙贏。
通常的IaaS廠商就是提供這些服務(wù)了，當(dāng)然，像AWS走在行業(yè)前面的巨頭，會(huì)提供更多其他的服務(wù)，我們姑且不談。
IaaS下的開(kāi)發(fā)
上節(jié)咱們簡(jiǎn)單介紹了IaaS提供的服務(wù)、產(chǎn)品，那么在這樣的環(huán)境下，開(kāi)發(fā)人員是怎么利用IaaS快速實(shí)現(xiàn)他們的產(chǎn)品原型的呢?
通常一個(gè)典型的產(chǎn)品可能包含三個(gè)與用戶交互的部分：web端、iOS手機(jī)端、Android手機(jī)端。而后端通常是有一個(gè)nginx前端，有業(yè)務(wù)邏輯部分，比如tomcat中跑的Java code、php-fpm驅(qū)動(dòng)的php code、gunicorn驅(qū)動(dòng)的Python code，會(huì)用到數(shù)據(jù)庫(kù)來(lái)做持久化，用到Cache來(lái)提高查詢速度，如果后端有些比較重量級(jí)的計(jì)算任務(wù)可能還會(huì)有個(gè)rpc服務(wù)。
哪部分需要自己搞，哪部分需要IaaS廠商來(lái)搞?
- 業(yè)務(wù)邏輯相關(guān)的代碼肯定是dev來(lái)開(kāi)發(fā)的
- nginx前面通常需要有個(gè)四層的負(fù)載均衡，也就是大家熟知的ELB了，這個(gè)是IaaS廠商提供
- nginx、php語(yǔ)言環(huán)境、php-fpm(以PHP程序舉例)肯定是sre來(lái)搭建并運(yùn)維了，當(dāng)然，如果這個(gè)小公司只有一個(gè)技術(shù)人員，說(shuō)不得就要通吃dev、qa、sre、fe、ui、ue的所有工作了
- 數(shù)據(jù)庫(kù)、Cache應(yīng)該由IaaS廠商提供，他們負(fù)責(zé)維護(hù)、備份、擴(kuò)容，只要提供給用戶一個(gè)連接地址即可
嗯，看起來(lái)IaaS廠商還是幫了我們一些忙的，一些系統(tǒng)、網(wǎng)絡(luò)、DBA運(yùn)維相關(guān)的事情用戶是不用操心的。
接下來(lái)這個(gè)創(chuàng)業(yè)公司的唯一的技術(shù)人員開(kāi)始著手碼代碼了。雖然IaaS廠商已經(jīng)幫忙解決一部分問(wèn)題了，接下來(lái)這個(gè)哥們還會(huì)遇到哪些問(wèn)題呢?腦洞打開(kāi)……
#p#
IaaS之后，缺失的云服務(wù)
說(shuō)缺失可能并不準(zhǔn)確，因?yàn)橛行┓?wù)已經(jīng)有些公司在做了，只是目前并沒(méi)有與IaaS很好的結(jié)合起來(lái)
Code托管
代碼放在哪里?這是個(gè)問(wèn)題。使用Github?不太好，因?yàn)檫@是個(gè)創(chuàng)業(yè)項(xiàng)目，原因如下：
- Github是個(gè)用代碼交流的開(kāi)發(fā)者社區(qū)，開(kāi)源代碼很適合放在上面，但這不代表私有項(xiàng)目也適合放在上面，而且Github私有repo是收費(fèi)的，雖然不貴，創(chuàng)業(yè)嘛，能省則省，特別是有替代服務(wù)的情況下
- Github在國(guó)外，網(wǎng)絡(luò)狀況不是很好，經(jīng)常要連vpn才能使用，麻煩
- Github不方便與內(nèi)部其他平臺(tái)(比如編譯平臺(tái))整合，其實(shí)這個(gè)歸根結(jié)底還是網(wǎng)絡(luò)惹的禍，萬(wàn)惡的那個(gè)啥啊
所以，國(guó)內(nèi)出了個(gè)gitcafe、出了個(gè)git.oschina.net、出了個(gè)coding.net，稍大一些的公司直接就自己搭建svn服務(wù)器或者gitlab服務(wù)器
這是一塊蛋糕，親愛(ài)的讀者，如果你是做IaaS的，可以嘗試與這些代碼托管服務(wù)商合作一下，畢竟，代碼是一切的開(kāi)始。
Build平臺(tái)
編譯平臺(tái)、產(chǎn)品庫(kù)，這些名詞對(duì)于devops來(lái)說(shuō)再熟悉不過(guò)了。這一節(jié)我們就來(lái)聊聊這部分話題：
代碼已經(jīng)托管起來(lái)了，那下一步是什么呢?編譯打包!沒(méi)錯(cuò)，如果你使用的解釋型語(yǔ)言，比如PHP、Ruby體會(huì)可能不深，但如果是編譯型的，比如Java、Go、C++，估計(jì)就深有感觸了。code寫好了，要去測(cè)試、上線，首先要做的是編譯并打包。
最終的期望是：打成的包自包含Runtime，部署到線上任何一臺(tái)機(jī)器上都能跑起來(lái)，當(dāng)然了，前提是這些機(jī)器都是相同的操作系統(tǒng)，相同的字長(zhǎng)。為啥說(shuō)要自包含呢?因?yàn)榫€上機(jī)器環(huán)境千差萬(wàn)別，操作系統(tǒng)版本可能不同、Python版本可能不同、可能連wget命令都沒(méi)有，千萬(wàn)不能依賴線上環(huán)境。
做這個(gè)平臺(tái)的關(guān)鍵是指定合理的規(guī)范
最終的發(fā)布包要是什么格式，包內(nèi)的文件是怎么個(gè)組織方式，meta信息應(yīng)該放在哪里，啟動(dòng)腳本應(yīng)該放在哪里，打好的發(fā)布包放在哪里，應(yīng)該是一個(gè)整包還是散文件，平臺(tái)去哪里拉取用戶的打包產(chǎn)物……發(fā)布包最終是拿來(lái)部署的，故而規(guī)范的制定要考慮與部署系統(tǒng)的結(jié)合。
Runtime要提前準(zhǔn)備好以提高編配速度
我們剛才說(shuō)最終的期望是打好的包要做到自包含Runtime，所以Java的項(xiàng)目需要包含JDK、Tomcat(或者Resin、Jetty之類的)，Python的項(xiàng)目要包含Python的語(yǔ)言環(huán)境，還要準(zhǔn)備好Nginx之類的，這些常用軟件不能在編譯的時(shí)候去外網(wǎng)下載，應(yīng)該提前放到內(nèi)網(wǎng)或者編譯機(jī)上。
Docker Image & Docker Registry
Docker最近比較火，我們可以把 Docker Image看做是一種發(fā)布包，Docker Registry看做是一種產(chǎn)品庫(kù)。因?yàn)镈ocker Image就是一個(gè)自包含的可以在任何部署了Docker的機(jī)器上跑起來(lái)。而Dockerfile可以看作是一種打包規(guī)范，類似Heroku和 CloudFoundry中的buildpack
這一塊IaaS廠商并沒(méi)有提供，筆者覺(jué)得這也是一個(gè)可以做的方向，不知道有沒(méi)有創(chuàng)業(yè)公司已經(jīng)看到商機(jī)在這塊發(fā)力了。
Deploy工具
我們說(shuō)Code已經(jīng)托管好了，又有編譯平臺(tái)負(fù)責(zé)打好包了，接下來(lái)就是部署了。作為CI的最后一公里，Deploy工具起到了很重要的作用，往QA環(huán)境部署、往沙盒環(huán)境部署、往小流量環(huán)境部署、線上全量部署都要用到。
說(shuō)到底，部署就是一個(gè)按照某種并發(fā)策略去一批機(jī)器上批量執(zhí)行部署腳本的過(guò)程
嗯，筆者自認(rèn)為這句話總結(jié)得還算精辟，哈哈，只是不知道有多少人會(huì)贊同~
對(duì)于單個(gè)項(xiàng)目只有幾十臺(tái)機(jī)器而言，有針對(duì)性得寫一個(gè)部署腳本，批量ssh到對(duì)應(yīng)機(jī)器上跑一下完成部署是沒(méi)有問(wèn)題的。但是這不夠規(guī)范，個(gè)人搞個(gè)人的，也難以形成業(yè)內(nèi)標(biāo)準(zhǔn)，推進(jìn)軟件開(kāi)發(fā)的步伐，對(duì)于幾百臺(tái)機(jī)器的大項(xiàng)目，ssh就很難完成了，批量建立信任關(guān)系也是一個(gè)比較麻煩的事情。
這個(gè)時(shí)候一個(gè)強(qiáng)悍的Deploy工具就派上用場(chǎng)了，這個(gè)工具要：
- 具備批量去各個(gè)機(jī)器執(zhí)行腳本的能力，而且要保證每個(gè)腳本不能多執(zhí)行了，不能少執(zhí)行了，每個(gè)機(jī)器上可能要部署一個(gè)agent來(lái)支持
- 并發(fā)策略要可調(diào)控，比如一個(gè)一個(gè)來(lái)做?還是每次做2個(gè)?5個(gè)?因?yàn)椴煌姆?wù)可承受的同時(shí)重啟的實(shí)例數(shù)目不一樣，所以這個(gè)并發(fā)策略要可配置
- 有既定規(guī)范流程，這個(gè)流程是指在單機(jī)執(zhí)行的一些步驟，先干什么，再干什么，最后干什么等等，我們要去分析抽象出一個(gè)通用流程，能夠滿足大部分項(xiàng)目部署需求
- 單機(jī)部署流程可定制，雖然我們已經(jīng)抽象了一個(gè)比較好的通用流程，但是總有一些特例是沒(méi)法用默認(rèn)方式滿足的，故而這個(gè)流程要可定制，插入用戶自己的特殊邏輯
最后達(dá)到的效果就是：用戶要發(fā)起部署，只要簡(jiǎn)單的指定一些meta信息即可完成。meta信息可能包括：發(fā)布包地址、機(jī)器列表、進(jìn)程啟動(dòng)賬號(hào)、部署目錄等等
aws有提供一個(gè)叫Deploy的服務(wù)，不知道是否就是干這個(gè)事情的。
Config Center
我們?cè)谧鯞uild平臺(tái)和Deploy工具的時(shí)候，必然要處理配置問(wèn)題，因?yàn)椴煌捻?xiàng)目配置是不一樣的，甚至同一個(gè)項(xiàng)目，部署在不同的機(jī)器上配置都是不同的。但是對(duì)于一個(gè)項(xiàng)目而言，我們期望一次release動(dòng)作用到的發(fā)布包都是相同的，不會(huì)因?yàn)榕渲貌煌龀啥鄠€(gè)發(fā)布包。這個(gè)不知道大家有沒(méi)有感觸，測(cè)試環(huán)境、沙盒環(huán)境、線上環(huán)境通常有自己的配置，所以有些人就為測(cè)試環(huán)境打一個(gè)包、為沙盒環(huán)境打一個(gè)包、為線上環(huán)境打一個(gè)包。這種做法在筆者看來(lái)是很不好的。因?yàn)镼A測(cè)試的那個(gè)包竟然不是線上用的包!那如何保證不出問(wèn)題?!
我們推薦做成一個(gè)包，那就要屏蔽差異，把不同的配置信息抽出來(lái)。外部搭建一個(gè)Config Center就是一個(gè)方案。
配置信息通常不大，好多人可能很容易想到用Zookeeper實(shí)現(xiàn)一個(gè)。不過(guò)這篇文章中我們不談具體實(shí)現(xiàn)，淘寶有個(gè)開(kāi)源項(xiàng)目叫Diamond也是做類似事情的，大家如果有興趣可以參考一下，如果沒(méi)記錯(cuò)的話，Google的Borg系統(tǒng)中也是有一個(gè)配置中心的。
云主機(jī)and服務(wù)監(jiān)控
上面提到的幾點(diǎn)主要是針對(duì)code和deploy的，接下來(lái)咱們聊一下監(jiān)控。提到監(jiān)控這個(gè)詞，你想到了對(duì)什么的監(jiān)控?cpu、內(nèi)存、io、網(wǎng)絡(luò)、磁盤，嗯，沒(méi)錯(cuò)，機(jī)器基礎(chǔ)監(jiān)控必須要有;進(jìn)程存活監(jiān)控、端口監(jiān)控、域名監(jiān)控，嗯，針對(duì)服務(wù)存活性的監(jiān)控，也必須要有。通常提供云監(jiān)控的IaaS廠商都會(huì)提供以上兩類監(jiān)控，夠了么?還有其他需求么?
你是否想過(guò)http 500次數(shù)的監(jiān)控?url響應(yīng)時(shí)間過(guò)長(zhǎng)的監(jiān)控?api調(diào)用次數(shù)過(guò)多的監(jiān)控?log中Error字樣或Exception字樣過(guò)多的監(jiān)控?嗯，這些就屬于是一些業(yè)務(wù)自定義監(jiān)控了。能提供這種監(jiān)控的IaaS就不多見(jiàn)了。而實(shí)際上，這是很有需求的，就像我剛才舉的這幾個(gè)例子，你是dev的話你肯定也想知道吧?
但是這些監(jiān)控每個(gè)服務(wù)都不一樣，作為IaaS平臺(tái)方，應(yīng)該從哪里拉取這些監(jiān)控?cái)?shù)據(jù)呢?顯然，沒(méi)地方!應(yīng)該讓app方告訴平臺(tái)方pull的接口是什么，或者平臺(tái)方直接提供一個(gè)push接口，讓app自己去收集數(shù)據(jù)然后push。不管是哪種方式，平臺(tái)方都要制定數(shù)據(jù)格式規(guī)范，比如什么樣的接口才可以被拉取，拉取到的數(shù)據(jù)應(yīng)該是什么格式，或者什么樣的數(shù)據(jù)才能push，push的方式是什么樣的，諸如此類。
如此一來(lái)，我們開(kāi)發(fā)產(chǎn)品的這些苦逼碼農(nóng)不但可以了解到我們使用的云主機(jī)的運(yùn)行情況，服務(wù)的存活情況，也可以了解到服務(wù)的性能情況，穩(wěn)定情況，是不是不錯(cuò)?
LB接口化
IaaS廠商剛剛起步的時(shí)候，第一個(gè)要做的顯然是云主機(jī);云主機(jī)搞定之后呢?顯然是RDS;RDS搞定之后呢?大部分廠商都會(huì)選擇去做LB，因?yàn)橛蛎竺嬷苯优渲闷邔觭erver還是有很大的問(wèn)題，那就是七層server宕機(jī)之后無(wú)法及時(shí)從域名中摘掉，因?yàn)閐ns是有比較久的生效時(shí)間的嘛~于是 LVS之類的四層負(fù)載均衡設(shè)備就派上用場(chǎng)了，也就是aws中所謂的ELB。
通常IaaS廠商都會(huì)提供LB，但是并不是所有廠商都提供api讓用戶去修改vip對(duì)應(yīng)的rs，而這點(diǎn)在筆者看來(lái)是一個(gè)非常重要的功能，最好盡快提供。它有什么用呢?LB已經(jīng)可以自動(dòng)摘掉宕機(jī)的七層實(shí)例了，還不夠?這個(gè)api主要是用于做自動(dòng)遷移的，即：新擴(kuò)容的rs可以及時(shí)加進(jìn)來(lái)，宕機(jī)的rs可以及時(shí)摘掉。這個(gè)加進(jìn)來(lái)和摘掉的動(dòng)作要自動(dòng)化!故而LB要接口化。
All in Automation
之前我們已經(jīng)提到需要一個(gè)Deploy工具，讓用戶方便得部署他們的服務(wù)，快速迭代，持續(xù)集成。但是在部署的過(guò)程中用戶仍然要指定很多信息，比如要部署的機(jī)器列表，run應(yīng)用的Linux賬號(hào)，部署完成之后還要手工修改ELB的配置，修改vip對(duì)應(yīng)的rs(別怕，通常是不用修改的，只有個(gè)別情況比如擴(kuò)容的時(shí)候才需要)。整個(gè)過(guò)程比較復(fù)雜。特別是分配機(jī)器列表，如果模塊比較多，我們?yōu)榱烁玫馁Y源利用通常會(huì)選擇混部，比如io密集型的與cpu密集型的部署到一臺(tái)機(jī)器上，這樣一來(lái)我們要花心思去分配，能不能讓平臺(tái)自動(dòng)化去調(diào)度完成?
比較好的用戶使用方式可能是這樣的：
用戶提供發(fā)布包，提供所有可用的機(jī)器列表，告訴平臺(tái)要部署的服務(wù)是io密集型的還是cpu密集型的，告訴平臺(tái)這個(gè)服務(wù)要注冊(cè)的ELB vip是什么以及這個(gè)服務(wù)的服務(wù)端口是什么，然后平臺(tái)自動(dòng)去調(diào)度部署。
平臺(tái)可能的做法：
通過(guò)監(jiān)控系統(tǒng)收集到該用戶各個(gè)云主機(jī)的資源利用情況，按照比較好的混部策略，找到比較適合部署這個(gè)服務(wù)的云主機(jī)，部署少量幾個(gè)app實(shí)例，把這幾個(gè)實(shí)例注冊(cè)到對(duì)應(yīng)的vip上去(LB接口化很重要吧，嘿)提供服務(wù)，然后監(jiān)控這些實(shí)例是否掛掉，如果掛掉了自動(dòng)拉起，如果實(shí)例所在的機(jī)器都掛了，自動(dòng)將實(shí)例遷移到其他好的云主機(jī)上去，同時(shí)修改vip對(duì)應(yīng)的rs配置，然后監(jiān)控這個(gè)vip的流量，如果流量太高，自動(dòng)擴(kuò)容，找新的云主機(jī)部署新實(shí)例，將新的rs加到該vip下。
目前先想到這么多，這是筆者腦袋中的一個(gè)不甚成熟的藍(lán)圖，諸位看官有補(bǔ)充的歡迎留言。如果看完之后碰撞出了你腦袋中的思維火花，可以選擇打賞我包煙錢，我不會(huì)介意的，嗯?不知道我的支付寶?哦，就是我的手機(jī)號(hào)，嗯?不知道我的手機(jī)號(hào)?打電話問(wèn)嘛……
原文鏈接：http://www.jianshu.com/p/6f6e48717bc4
網(wǎng)站題目：【深度】IaaS之后，我們?cè)撊绾巫鲩_(kāi)發(fā)？
地址分享：http://fisionsoft.com.cn/article/dhidhoc.html
