建站
咨詢
售后
建站咨詢
新聞中心
總體思考
成都創(chuàng)新互聯(lián)主營六合網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,app軟件定制開發(fā),六合h5微信小程序搭建,六合網(wǎng)站營銷推廣歡迎六合等地區(qū)企業(yè)咨詢
總結(jié)這些年經(jīng)驗，進行構(gòu)架演進的方向選擇時，大致要做到下面的目標(biāo)：
- 可快速開發(fā)部署 （五分鐘寫出來一個經(jīng)過測試的hello world并可訪問/調(diào)用，并可在公網(wǎng)訪問）
- 天然可擴展（業(yè)務(wù)層無狀態(tài)，盡可能全部放到***）
- 自動化（內(nèi)存不足了，除了報警，應(yīng)該自動加點機器進去; 新的項目，基礎(chǔ)代碼應(yīng)該都不用寫，自動生成即可）
- 框架化（公共層面的東西盡可能框架化，一層類似日志、counter、trace，應(yīng)該不需要開發(fā)再寫一行代碼即默認(rèn)打開）
- 量化（所有的調(diào)用都應(yīng)該有percentile與rps，透明反饋服務(wù)質(zhì)量，跟蹤系統(tǒng)更是可以模擬用戶進行系統(tǒng)內(nèi)部）
- 同構(gòu)化（因為搞兩套的成本巨大，整體應(yīng)該越來越趨同于同一種語言）
- 硬件虛擬化（整個平臺應(yīng)該對進程透明下面的硬件情況）
- 版本化、灰度化（所有的軟件都應(yīng)該在線上有明確的版本，且上線過程是一點點灰度上）
上圖純手繪花了些時間，本文以此圖從上到下的順序進行描述。
用戶
在移動互聯(lián)網(wǎng)環(huán)境下，用戶會被分為好網(wǎng)絡(luò)的用戶和壞網(wǎng)絡(luò)的用戶，我們要為壞網(wǎng)絡(luò)的用戶盡一切可能提供合適的鏈路和可靠的DNS。
接入層
在接入層的代碼層面，需要準(zhǔn)備client-server套件，這意味著，需要一個同時了解android\ios..等客戶端和服務(wù)器端開發(fā)的團隊，專門打造網(wǎng)絡(luò)套件。
- 這一層的目標(biāo)是，讓客戶端開發(fā)人員不再關(guān)心網(wǎng)絡(luò)協(xié)議的問題。
業(yè)務(wù)接入層
這一層的目標(biāo)是靈通機動調(diào)配流量，往往大家的方案都是LVS，或者是F5等。更高大上一點，再上一些流量分析設(shè)備，在有突增的時候好用來找問題。
業(yè)務(wù)層
在統(tǒng)一的業(yè)務(wù)框架下，去完成各個靈活組織的BIZ邏輯，這里就涉及到異構(gòu)系統(tǒng)對一個大型公司的影響。
- 如果80％的人都在使用java的活，還是趁早全用java，因為意味著剩下20％用其他語言的同學(xué)，有可能要把這80％的同學(xué)做的基礎(chǔ)全部實現(xiàn)一遍。
- 異構(gòu)必然會導(dǎo)致某些模塊不能***工作，比如后續(xù)的RPC、配置管理、監(jiān)控報警、跟蹤系統(tǒng)等等。
RPC框架與隊列
二者一起完成數(shù)據(jù)在IDC的傳遞，不同在于，一個是同步，一個是異步。
- 統(tǒng)一的RPC框架好處不必言說。
配置管理
zookeeper當(dāng)選***角色，上點規(guī)模的服務(wù)里基本都會有zk的身影。
日志系統(tǒng)
統(tǒng)一的日志系統(tǒng)，對未來發(fā)展中所需要的各種數(shù)據(jù)更加容易得到。日志系統(tǒng)的特點要求：快，容網(wǎng)絡(luò)錯誤，部署簡單，進程穩(wěn)定，可水平擴展。
- scribe與kafka都是不錯的選擇。
- 這里最終的日志，可能會需要放到hdfs或者是hbase里進行hive查詢，否則數(shù)據(jù)量大了之后要想把日志用起來很不容易。
監(jiān)控報警系統(tǒng)
ganglia與nagios仍舊是***用的開源管理軟件。
- 需要考慮的是，要將在業(yè)務(wù)框架里默認(rèn)記錄的公共的perfcounter進行監(jiān)控與報警。
跟蹤系統(tǒng)
當(dāng)系統(tǒng)出現(xiàn)bug的時候，用來快速debug，當(dāng)服務(wù)越來越多的時候，跟蹤系統(tǒng)是個必不可少的工具。
- twitter的zipkin是個不錯的開源的實現(xiàn)，不過要使用到自家的代碼里來，可能要加工一下。
PAAS Agent Daemon
整體統(tǒng)一的運維平臺的客戶端程序，此程序負(fù)責(zé):向監(jiān)控系統(tǒng)匯報硬件及網(wǎng)絡(luò)數(shù)據(jù)，啟動和停止應(yīng)用程序，向監(jiān)控系統(tǒng)和PAAS平臺傳遞應(yīng)用程序的運行狀態(tài)。
存儲平臺
此層包括所有重狀態(tài)的hosting service。
- memcached cluster，使用統(tǒng)一的一致性hash客戶端，所有的緩存服務(wù)器進行統(tǒng)一管理，計算命中率、使用率，實時添加內(nèi)存。
- DBMS cluster，使用統(tǒng)一的數(shù)據(jù)庫分庫分表層，動態(tài)地感知和切換故障。常見的項目如mysqlproxy，變形蟲。
- HBase cluster，獨立的存儲可用性保障，本身也是設(shè)計為高可用性的集群。
PAAS 資源控制層
目標(biāo)是實時反饋整個或多個IDC內(nèi)部的內(nèi)存還有多少、CPU是否夠用、下次采購還需要多少機器。
- 虛擬化是個重點難題。常見開源軟件：docker、warden、LXC。
- 資源控制CPU可用cgroups，磁盤可用aufs等，一般的虛擬化方案中都已經(jīng)包括這幾項解決辦法。
PAAS用戶界面層
這一層主要面向運維和開發(fā)人員，比如用來上線服務(wù)、添加刪除機器。
- 除了web界面，還應(yīng)該有cli模式的支持。
自動部署層
一般都以hudson的CI（持續(xù)構(gòu)建）完成之后進行，但可自動化的部署一定需要測試框架非?？孔V，以及測試代碼靠譜，否則就是個悲劇。
測試框架
借用一些高級框架，讓代碼寫少一點，比如jmockit、spring-test等等。
編譯工具
java的maven為不二選擇。編譯好的包倉庫，推薦nexus。
代碼生成
開發(fā)人員不需要重復(fù)進行操作，只要框架是固定的，所有的代碼應(yīng)該都是可以生成的。只需要花精力去修改核心邏輯。
- 這里比較抽象，可以用的辦法比如做一個maven-plugin，讓全部工程師都會用。
- 不斷地去升級這個工具，使其包括更多的可能的代碼方式。
代碼質(zhì)量
在工程師的代碼完成之后，跑一遍靜態(tài)分析，可以提前發(fā)現(xiàn)一些問題，可以做成定期的模式，與持續(xù)集成放在一起。
- 推薦hudson + maven + sonar三劍合一。
代碼及常規(guī)系統(tǒng)
- 代碼托管：gitlab是一個不錯的類似github（越來越像了）的工具。
- codereview：可直接使用gitlab的merge request，也可以使用開源的reviewboard。
- 知識管理：沒什么好說的，mediawiki。
- 需求與bug：jira。
- 故障管理：這個沒有開源項目，post-mortem system，是一種記錄故障原因的系統(tǒng)，下一次故障來臨的時候，來這個系統(tǒng)里進行問卷式的調(diào)查和反思。
PAAS for DEV & TEST
- 開發(fā)階段需要之前提到的cli可發(fā)布到自己的開發(fā)機（這里還需要PAAS可很容易地開一個新的開發(fā)機）的工具。
- 測試階段需要比開發(fā)階段更加高可用性的環(huán)境，而且要時刻提升基礎(chǔ)工具的可靠性，不應(yīng)該讓開發(fā)環(huán)境在發(fā)展中消失，反而用測試環(huán)境來當(dāng)作開發(fā)環(huán)境，現(xiàn)實中發(fā)生此類事件的原因，都是部署沒有做到***。
網(wǎng)站欄目：中大型移動互聯(lián)網(wǎng)公司技術(shù)架構(gòu)選擇思考
當(dāng)前鏈接：http://www.dlmjj.cn/article/dhhegji.html
