文章來源：圖解源碼
換公司已經(jīng)有幾個月的時間，現(xiàn)在更多的時間是在思考公司的PAAS平臺的設(shè)計，這里將最近的一些思考整理出來，分享下自己的一些胡思亂想, 歡迎各位大佬指正其中的不足，也算是對這一段時間的總結(jié)吧
在公司的PAAS平臺建設(shè)中通常會提供到一個基礎(chǔ)的平臺ARP(Applications Running Platform)即應(yīng)用運行平臺，通過該平臺支持公司的業(yè)務(wù)應(yīng)用的運行，同時也是與公有云PAAS差異最大的地方，在這一層我們可以落地更多的公司的標(biāo)準(zhǔn)與規(guī)范，同時根據(jù)公司的需要進行數(shù)據(jù)的整合，這才是私有PAAS最大的意義
看上去很簡單的運行時個人理解才是paas平臺中最負(fù)責(zé)的設(shè)計之一，在PAAS里面有承上啟下的意義，對下運行時的設(shè)計將底層的操作系統(tǒng)和服務(wù)器完全屏蔽掉，同時將各種基礎(chǔ)設(shè)施平臺細(xì)節(jié)進行隱藏，對上提供面向應(yīng)用的環(huán)境，提供一鍵式的無感的運行環(huán)境支持
中間件泛指的就是各種基礎(chǔ)服務(wù)，比如mysql、redis、mq、kafka、hbase等等，還包括公司自研的各種基礎(chǔ)服務(wù)，通過這些服務(wù)應(yīng)用研發(fā)可以更關(guān)注業(yè)務(wù)代碼編寫本身，而不需要對底層的各種依賴進行相應(yīng)的調(diào)研測試，只需要使用PAAS平臺提供的功能即可
接下來我們聊另外的一個跟運維相關(guān)的東西-Devops
Devops也是現(xiàn)在做運維大家老生常談的一個東西了，我一直比較喜歡一個老師的觀點，Devops本質(zhì)上其實就做三件事：1.解耦 2.研發(fā)效能提升3.管理，不過我們今天只聊兩個：全鏈路與數(shù)據(jù)流動
平臺目前只完成了基礎(chǔ)的功能設(shè)計，
在進行第一版Paas設(shè)計的時候，其實并沒有想設(shè)計成后來的樣子，更多的只是想做一個應(yīng)用管理PAAS， 結(jié)合上面的Devops思想，去構(gòu)建公司的CICD流水線，實現(xiàn)研發(fā)從應(yīng)用創(chuàng)建、環(huán)境部署、資源申請、中間件申請、持續(xù)集成、持續(xù)交付、持續(xù)部署的Devops的半個流程，然后通過oam進行應(yīng)用元數(shù)據(jù)的管理
現(xiàn)在的很多運維產(chǎn)品都很成熟，比如像藍鯨、優(yōu)維這兩款產(chǎn)品一直陪伴著我做運維開發(fā)的日子，不過我一直都明白一件事這兩個產(chǎn)品就只能拿過來用借鑒里面的思想，但是如果是要仿一個，老大鐵定會先開掉我。
而且這兩款產(chǎn)品其實已經(jīng)是Saas了，根據(jù)公司的現(xiàn)狀已經(jīng)有了部分系統(tǒng)，雖然沒有商業(yè)產(chǎn)品的成熟，但是如果想引進一個外部的商業(yè)產(chǎn)品，則會直接顛覆現(xiàn)狀的運維體系和生態(tài)，我也一定會被開掉。
思考這件事本身是一個嘗試尋找結(jié)果的過程，思考PAAS本質(zhì)也是如此，之前一直是基于K8s的Paas來思考，可是慢慢發(fā)現(xiàn)這是一個極大的誤區(qū)，K8s抹掉了太多在Paas平臺的東西(k8s底層設(shè)計)，在這個基礎(chǔ)上如果再去思考PAAS其實就好比井底之蛙，其實看到的只是上層基于k8s的應(yīng)用，而不是PAAS平臺本身，我舉個例子，如果我們把K8s定位成一個Paas基座(其實也有Saas功能)，那我們所有的ci、cd、Deployment、日志、監(jiān)控等等其實都可以理解為其上的一個應(yīng)用，我們將這些應(yīng)用進行整合，構(gòu)建我們的應(yīng)用托管環(huán)境，那Paas平臺提供的彈性、按需使用、故障自愈等基礎(chǔ)功能，你還知道嘛？
在藍鯨里面用戶可以基于平臺完成上層Saas應(yīng)用的開發(fā)，同時托管到藍鯨，藍鯨提供Paas的能力，而在優(yōu)維里面也有對標(biāo)的微應(yīng)用，從這個角度來看其實我們所有的運維操作都可以分為平臺和應(yīng)用兩部分
在進行服務(wù)整合集中化存儲的時候，很大的一個問題就是數(shù)據(jù)一致性問題，因為會涉及到多個系統(tǒng)多份數(shù)據(jù)，那如何解決這個問題呢？借住分布式的思想，這個問題其實很好解決，就找個集中存儲哇，就跟你用zk/etcd進行分布式協(xié)調(diào)一樣，然后將私有的狀態(tài)數(shù)據(jù)由各個服務(wù)自己進行存儲
Devops服務(wù)：就是我們上面提到的第一個版本應(yīng)用PAAS，同時我們也只做這一部分，只有當(dāng)這部分達到穩(wěn)態(tài)的時候，才會進行后續(xù)部分建設(shè)；
基礎(chǔ)服務(wù)：建設(shè)是提供Paas偏Saas的相關(guān)功能，即提供數(shù)據(jù)相關(guān)的功能，這樣后續(xù)就只需要進行應(yīng)用開發(fā)即可，平臺提供基礎(chǔ)的數(shù)據(jù)能力
運維服務(wù)：將運維能力服務(wù)化，同時對外提供平臺層和應(yīng)用層的功能，主要是為了滿足公司運維的各種日常操作和運維場景，通過標(biāo)準(zhǔn)化運維將各種操作進行統(tǒng)一標(biāo)準(zhǔn)，減少誤操的概率，同時將運維專家經(jīng)驗進行落地，并提供數(shù)據(jù)分析的功能，為運維數(shù)字化轉(zhuǎn)型提供基礎(chǔ)的數(shù)據(jù)
在現(xiàn)在的設(shè)計中打亂了正常的Devops平臺的建設(shè)，進行一些細(xì)粒度的拆分，希望能夠讓老板們短時間看到對應(yīng)的產(chǎn)出，看到運維數(shù)據(jù)化帶來的收益，希望未來能有效果，同時將對應(yīng)的規(guī)范和標(biāo)準(zhǔn)化落地到新的流程和系統(tǒng)中，將運維的經(jīng)驗進行平臺化產(chǎn)出，推動公司的運維數(shù)字化轉(zhuǎn)型
運維數(shù)字化轉(zhuǎn)型最大的問題就是思維的轉(zhuǎn)變，很多運維平臺建設(shè)都是煙囪式的，修修補補。數(shù)字化建設(shè)除了要解決這些眼前的問題還要思考未來，就像Devops中的不確定性與確定性一樣，為什么要快速交付，因為不確定是否是市場要的，為什么要提高確定性，因為要盡可能保證安全、穩(wěn)定的產(chǎn)品，Paas平臺建設(shè)本質(zhì)也是這樣，快速向領(lǐng)導(dǎo)交付可用產(chǎn)品確定是不是領(lǐng)導(dǎo)要的產(chǎn)品
運維數(shù)字化的結(jié)果是共贏，運維開發(fā)團隊提供基礎(chǔ)的平臺功能，運維將自己的運維經(jīng)驗進行場景化應(yīng)用落地，這樣就會有更多的數(shù)據(jù)，更多的場景應(yīng)用，然后結(jié)合行業(yè)運維經(jīng)驗，就可以構(gòu)建獨一無二的行業(yè)數(shù)字化平臺，通過行業(yè)場景+數(shù)據(jù)，才是私有Paas平臺真正的競爭力，所以在運維PAAS平臺建設(shè)中，運維可能才是最重要的推動者，而不是研發(fā)
平臺建設(shè)的思考就先寫這一篇，后面還是會繼續(xù)分享一些云原生系統(tǒng)設(shè)計方面的東西，好好在思考下一些技術(shù)設(shè)計的實現(xiàn)與設(shè)計，畢竟一切設(shè)計都得落地
聯(lián)系客服
