總體思考

成都創(chuàng)新互聯(lián)主營六合網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,app軟件定制開發(fā),六合h5微信小程序搭建,六合網(wǎng)站營銷推廣歡迎六合等地區(qū)企業(yè)咨詢

總結這些年經(jīng)驗，進行構架演進的方向選擇時，大致要做到下面的目標：

• 可快速開發(fā)部署 （五分鐘寫出來一個經(jīng)過測試的hello world并可訪問/調用，并可在公網(wǎng)訪問）
• 天然可擴展（業(yè)務層無狀態(tài)，盡可能全部放到***）
• 自動化（內存不足了，除了報警，應該自動加點機器進去; 新的項目，基礎代碼應該都不用寫，自動生成即可）
• 框架化（公共層面的東西盡可能框架化，一層類似日志、counter、trace，應該不需要開發(fā)再寫一行代碼即默認打開）
• 量化（所有的調用都應該有percentile與rps，透明反饋服務質量，跟蹤系統(tǒng)更是可以模擬用戶進行系統(tǒng)內部）
• 同構化（因為搞兩套的成本巨大，整體應該越來越趨同于同一種語言）
• 硬件虛擬化（整個平臺應該對進程透明下面的硬件情況）
• 版本化、灰度化（所有的軟件都應該在線上有明確的版本，且上線過程是一點點灰度上）

上圖純手繪花了些時間，本文以此圖從上到下的順序進行描述。

用戶

在移動互聯(lián)網(wǎng)環(huán)境下，用戶會被分為好網(wǎng)絡的用戶和壞網(wǎng)絡的用戶，我們要為壞網(wǎng)絡的用戶盡一切可能提供合適的鏈路和可靠的DNS。

接入層

在接入層的代碼層面，需要準備client-server套件，這意味著，需要一個同時了解android\ios..等客戶端和服務器端開發(fā)的團隊，專門打造網(wǎng)絡套件。

• 這一層的目標是，讓客戶端開發(fā)人員不再關心網(wǎng)絡協(xié)議的問題。

業(yè)務接入層

這一層的目標是靈通機動調配流量，往往大家的方案都是LVS，或者是F5等。更高大上一點，再上一些流量分析設備，在有突增的時候好用來找問題。

業(yè)務層

在統(tǒng)一的業(yè)務框架下，去完成各個靈活組織的BIZ邏輯，這里就涉及到異構系統(tǒng)對一個大型公司的影響。

• 如果80％的人都在使用java的活，還是趁早全用java，因為意味著剩下20％用其他語言的同學，有可能要把這80％的同學做的基礎全部實現(xiàn)一遍。
• 異構必然會導致某些模塊不能***工作，比如后續(xù)的RPC、配置管理、監(jiān)控報警、跟蹤系統(tǒng)等等。

RPC框架與隊列

二者一起完成數(shù)據(jù)在IDC的傳遞，不同在于，一個是同步，一個是異步。

• 統(tǒng)一的RPC框架好處不必言說。

配置管理

zookeeper當選***角色，上點規(guī)模的服務里基本都會有zk的身影。

日志系統(tǒng)

統(tǒng)一的日志系統(tǒng)，對未來發(fā)展中所需要的各種數(shù)據(jù)更加容易得到。日志系統(tǒng)的特點要求：快，容網(wǎng)絡錯誤，部署簡單，進程穩(wěn)定，可水平擴展。

• scribe與kafka都是不錯的選擇。
• 這里最終的日志，可能會需要放到hdfs或者是hbase里進行hive查詢，否則數(shù)據(jù)量大了之后要想把日志用起來很不容易。

監(jiān)控報警系統(tǒng)

ganglia與nagios仍舊是***用的開源管理軟件。

• 需要考慮的是，要將在業(yè)務框架里默認記錄的公共的perfcounter進行監(jiān)控與報警。

跟蹤系統(tǒng)

當系統(tǒng)出現(xiàn)bug的時候，用來快速debug，當服務越來越多的時候，跟蹤系統(tǒng)是個必不可少的工具。

• twitter的zipkin是個不錯的開源的實現(xiàn)，不過要使用到自家的代碼里來，可能要加工一下。

PAAS Agent Daemon

整體統(tǒng)一的運維平臺的客戶端程序，此程序負責:向監(jiān)控系統(tǒng)匯報硬件及網(wǎng)絡數(shù)據(jù)，啟動和停止應用程序，向監(jiān)控系統(tǒng)和PAAS平臺傳遞應用程序的運行狀態(tài)。

存儲平臺

此層包括所有重狀態(tài)的hosting service。

• memcached cluster，使用統(tǒng)一的一致性hash客戶端，所有的緩存服務器進行統(tǒng)一管理，計算命中率、使用率，實時添加內存。
• DBMS cluster，使用統(tǒng)一的數(shù)據(jù)庫分庫分表層，動態(tài)地感知和切換故障。常見的項目如mysqlproxy，變形蟲。
• HBase cluster，獨立的存儲可用性保障，本身也是設計為高可用性的集群。

PAAS 資源控制層

目標是實時反饋整個或多個IDC內部的內存還有多少、CPU是否夠用、下次采購還需要多少機器。

• 虛擬化是個重點難題。常見開源軟件：docker、warden、LXC。
• 資源控制CPU可用cgroups，磁盤可用aufs等，一般的虛擬化方案中都已經(jīng)包括這幾項解決辦法。

PAAS用戶界面層

這一層主要面向運維和開發(fā)人員，比如用來上線服務、添加刪除機器。

• 除了web界面，還應該有cli模式的支持。

自動部署層

一般都以hudson的CI（持續(xù)構建）完成之后進行，但可自動化的部署一定需要測試框架非?？孔V，以及測試代碼靠譜，否則就是個悲劇。

測試框架

借用一些高級框架，讓代碼寫少一點，比如jmockit、spring-test等等。

編譯工具

java的maven為不二選擇。編譯好的包倉庫，推薦nexus。

代碼生成

開發(fā)人員不需要重復進行操作，只要框架是固定的，所有的代碼應該都是可以生成的。只需要花精力去修改核心邏輯。

• 這里比較抽象，可以用的辦法比如做一個maven-plugin，讓全部工程師都會用。
• 不斷地去升級這個工具，使其包括更多的可能的代碼方式。

代碼質量

在工程師的代碼完成之后，跑一遍靜態(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)里進行問卷式的調查和反思。

PAAS for DEV & TEST

• 開發(fā)階段需要之前提到的cli可發(fā)布到自己的開發(fā)機（這里還需要PAAS可很容易地開一個新的開發(fā)機）的工具。
• 測試階段需要比開發(fā)階段更加高可用性的環(huán)境，而且要時刻提升基礎工具的可靠性，不應該讓開發(fā)環(huán)境在發(fā)展中消失，反而用測試環(huán)境來當作開發(fā)環(huán)境，現(xiàn)實中發(fā)生此類事件的原因，都是部署沒有做到***。

分享題目：中大型移動互聯(lián)網(wǎng)公司技術架構選擇思考
轉載來于：http://uogjgqi.cn/article/dhhegji.html