中大型移動互聯網公司技術架構選擇(轉載)

原文地址：http://2014.54chen.com/blog/2014/03/05/ihaveadream/

 

整體思考

總結這些年經驗，進行構架演進的方向選擇時，大體要作到下面的目標：

• 可快速開發部署 （五分鐘寫出來一個通過測試的hello world並可訪問/調用，並可在公網訪問）
• 自然可擴展（業務層無狀態，儘量所有放到最後）
• 自動化（內存不足了，除了報警，應該自動加點機器進去; 新的項目，基礎代碼應該都不用寫，自動生成便可）
• 框架化（公共層面的東西儘量框架化，一層相似日誌、counter、trace，應該不須要開發再寫一行代碼即默認打開）
• 量化（全部的調用都應該有percentile與rps，透明反饋服務質量，跟蹤系統更是能夠模擬用戶進行系統內部）
• 同構化（由於搞兩套的成本巨大，總體應該愈來愈趨同於同一種語言）
• 硬件虛擬化（整個平臺應該對進程透明下面的硬件狀況）
• 版本化、灰度化（全部的軟件都應該在線上有明確的版本，且上線過程是一點點灰度上）

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

用戶

在移動互聯網環境下，用戶會被分爲好網絡的用戶和壞網絡的用戶，咱們要爲壞網絡的用戶盡一切可能提供合適的鏈路和可靠的DNS。

接入層

在接入層的代碼層面，須要準備client-server套件，這意味着，須要一個同時瞭解android\ios..等客戶端和服務器端開發的團隊，專門打造網絡套件。

• 這一層的目標是，讓客戶端開發人員再也不關心網絡協議的問題。

業務接入層

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

業務層

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

• 若是80％的人都在使用java的活，仍是趁早全用java，由於意味着剩下20％用其餘語言的同窗，有可能要把這80％的同窗作的基礎所有實現一遍。
• 異構必然會致使某些模塊不能完美工做，好比後續的RPC、配置管理、監控報警、跟蹤系統等等。

RPC框架與隊列

兩者一塊兒完成數據在IDC的傳遞，不一樣在於，一個是同步，一個是異步。

• 統一的RPC框架好處沒必要言說。

配置管理

zookeeper當選最佳角色，上點規模的服務裏基本都會有zk的身影。

日誌系統

統一的日誌系統，對將來發展中所須要的各類數據更加容易獲得。日誌系統的特色要求：快，容網絡錯誤，部署簡單，進程穩定，可水平擴展。

• scribe與kafka都是不錯的選擇。
• 這裏最終的日誌，可能會須要放到hdfs或者是hbase裏進行hive查詢，不然數據量大了以後要想把日誌用起來很不容易。

監控報警系統

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

• 須要考慮的是，要將在業務框架裏默認記錄的公共的perfcounter進行監控與報警。

跟蹤系統

當系統出現bug的時候，用來快速debug，當服務愈來愈多的時候，跟蹤系統是個必不可少的工具。

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

PAAS Agent Daemon

總體統一的運維平臺的客戶端程序，此程序負責:向監控系統彙報硬件及網絡數據，啓動和中止應用程序，向監控系統和PAAS平臺傳遞應用程序的運行狀態。

存儲平臺

此層包括全部重狀態的hosting service。

• memcached cluster，使用統一的一致性hash客戶端，全部的緩存服務器進行統一管理，計算命中率、使用率，實時添加內存。
• DBMS cluster，使用統一的數據庫分庫分表層，動態地感知和切換故障。常見的項目如mysqlproxy，變形蟲。
• HBase cluster，獨立的存儲可用性保障，自己也是設計爲高可用性的集羣。

PAAS 資源控制層

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

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

PAAS用戶界面層

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

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

自動部署層

通常都以hudson的CI（持續構建）完成以後進行，但可自動化的部署必定須要測試框架很是靠譜，以及測試代碼靠譜，不然就是個悲劇。

測試框架

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

編譯工具

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

代碼生成

開發人員不須要重複進行操做，只要框架是固定的，全部的代碼應該都是能夠生成的。只須要花精力去修改核心邏輯。

• 這裏比較抽象，能夠用的辦法好比作一個maven-plugin，讓所有工程師都會用。
• 不斷地去升級這個工具，使其包括更多的可能的代碼方式。

代碼質量

在工程師的代碼完成以後，跑一遍靜態分析，能夠提早發現一些問題，能夠作成按期的模式，與持續集成放在一塊兒。

• 推薦hudson + maven + sonar三劍合一。

代碼及常規系統

• 代碼託管：gitlab是一個不錯的相似github（愈來愈像了）的工具。
• codereview：可直接使用gitlab的merge request，也可使用開源的reviewboard。
• 知識管理：沒什麼好說的，mediawiki。
• 需求與bug：jira。
• 故障管理：這個沒有開源項目，post-mortem system，是一種記錄故障緣由的系統，下一次故障來臨的時候，來這個系統裏進行問卷式的調查和反思。

PAAS for DEV & TEST

• 開發階段須要以前提到的cli可發佈到本身的開發機（這裏還須要PAAS可很容易地開一個新的開發機）的工具。
• 測試階段須要比開發階段更加高可用性的環境，並且要時刻提高基礎工具的可靠性，不該該讓開發環境在發展中消失，反而用測試環境來看成開發環境，現實中發生此類事件的緣由，都是部署沒有作到完美。