分布式系統(tǒng) 并不是我想象中的那樣！

作者：Turbo Zhang 2014-07-16 09:53:57

前言

過去兩個(gè)月深入的參與了一個(gè)分布式系統(tǒng)的開發(fā)，記得之前有人說過“想成為架構(gòu)師之前，都是從微觀架構(gòu)開始的”。盡管我從沒想過將來的某一天要成為一個(gè)架構(gòu)師，或者領(lǐng)域?qū)＜遥抑皇窍朊让葒}的編碼，寫著自己喜歡的Code，和一群志同道合的朋友做出大家喜歡的商品和產(chǎn)品。但是工作久了慢慢的搭架子的事情還是會(huì)來到你的面前，因?yàn)闀r(shí)間總會(huì)把一部分人慢慢推向海邊，使得他們成為最早見到陽光的人。

不扯淡了，為什么要說陽光呢，還是因?yàn)檫^去的兩（三）個(gè)月可能過的太充實(shí)也太痛苦了，完成之后，曙光來臨的時(shí)候整個(gè)人是會(huì)發(fā)光的哦。“深度”參與是因?yàn)槲医K于有機(jī)會(huì)在搭架子的過程中有了話語權(quán)和選擇權(quán)，同時(shí)也會(huì)承擔(dān)70%以上的編碼工作。

之前我的自我認(rèn)知是我可能在軟件方面的積累還可以，比如設(shè)計(jì)模式，架構(gòu)分層，程序解耦，API入手等方面，但是總覺得我在硬件網(wǎng)絡(luò)方面積累的太少，太薄了。

比如：

不同操縱系統(tǒng)之間的特點(diǎn)；
網(wǎng)絡(luò)端口管理與分發(fā)；
哪些網(wǎng)絡(luò)協(xié)議可以幫助我們更好的完成工作，監(jiān)控虛擬機(jī)的時(shí)候是在虛機(jī)上加代div理好還是用協(xié)議去控制；
硬件是否支持分布式，在擴(kuò)展過程中對(duì)于.net C#的兼容怎么樣；
什么時(shí)候使用多線程，在把線程交給程序調(diào)度的時(shí)候我們?cè)趺纯刂坪筒蹲骄€程的異常；
日志系統(tǒng)對(duì)于整個(gè)分散的系統(tǒng)是多么的重要；
何時(shí)使用關(guān)系數(shù)據(jù)庫(kù)，什么時(shí)候使用Nosql；
消息隊(duì)列用擅長(zhǎng)的MSMQ還是RabbitMQ.
怎樣有效的和其他部門的同事溝通；
用什么樣的方式去有效調(diào)度不同語言開發(fā)的系統(tǒng)；
測(cè)試用例對(duì)于大系統(tǒng)從零散到完整是多么的重要；
系統(tǒng)標(biāo)準(zhǔn)，代碼原則對(duì)于后期的維護(hù)余擴(kuò)展是多么的重要；
等；

項(xiàng)目簡(jiǎn)介

首先項(xiàng)目詳細(xì)內(nèi)容不便多說，簡(jiǎn)答的說，就是為國(guó)內(nèi)某大型廠商建立一套協(xié)調(diào)其自身搭建的私有云以及其購(gòu)買的公有云的一套系統(tǒng)。說牛X一點(diǎn)就是：一套混合云系統(tǒng)。

使用Restful

這是在構(gòu)建完整個(gè)系統(tǒng)***的收獲，之前使用web api的經(jīng)驗(yàn)只是為電商系統(tǒng)的移動(dòng)終端提供數(shù)據(jù)交互的接口，但是在這次項(xiàng)目之后發(fā)現(xiàn)Rest接口的不僅作為我們系統(tǒng)向外部系統(tǒng)提供交互的方式，同時(shí)在一些開源工具其暴露出來的接口也是基于rest的，可見全世界的程序員對(duì)于json對(duì)于rest有多么的喜愛；

為什么裝上軟件配置完成之后使用不了

之前的開發(fā)經(jīng)驗(yàn)由于使用的都是微軟的技術(shù)包括組建，工具。但是在項(xiàng)目中使用一些開源工具之后，配置成功之后卻總也跑不起來，同時(shí)由于開源工具已將Exception封裝起來，我們很難知道具體是什么樣的問題，有的時(shí)候調(diào)試好久還是跑不起來，很沮喪也很懊惱，結(jié)果***發(fā)現(xiàn)是由于公司IT只是將常用的端口打開，其他的都干掉了，如果申請(qǐng)開放端口的話還要走流程，于是對(duì)于開發(fā)人員有時(shí)候有一臺(tái)外網(wǎng)的開發(fā)虛擬機(jī)也是相當(dāng)?shù)挠斜匾摹?/p>

使用RabbitMq

個(gè)人是非常的喜歡使用Mq的，之前做電商總喜歡在Application層下面放入一層Service，你可以不用但是總會(huì)強(qiáng)迫癥似的不去不寫。為什么不用Msmq呢，原因是有很多了，簡(jiǎn)單點(diǎn)就是rabbit要比Msmq的協(xié)議更加高級(jí)，支持的處理功能也更加豐富，最重要的原因是Rabbit在開源語言使用上是占領(lǐng)先地位的，而且我們的系統(tǒng)又要嫁接太多的開源語言系統(tǒng)，***只能適配他們嘍。

之前知道Mq在企業(yè)系統(tǒng)間數(shù)據(jù)交互使用頻繁，不但能有效的劃分層次，解耦依賴，同時(shí)數(shù)據(jù)交互方式上也相當(dāng)?shù)谋憬荨？倳?huì)有消息沒有被消費(fèi)者使用，那我們就需要程序異步的去處理這個(gè)消息隊(duì)列了。

Redis

系統(tǒng)中使用了三種數(shù)據(jù)存儲(chǔ)，MySql，SqlServer，Redis，當(dāng)然前兩種適用于開源和C#，而Redis的使用則是為了那些總是難以找到有效關(guān)系和依賴的數(shù)據(jù)，比如之前只是知道Reids可以作為數(shù)據(jù)的存儲(chǔ)，可以分布式，可以主從復(fù)制，但是在這次開發(fā)之后更真真的發(fā)現(xiàn)Reids或者Nosql對(duì)于一個(gè)數(shù)據(jù)規(guī)則難以掌握，數(shù)據(jù)量大的系統(tǒng)是多么的重要，因?yàn)橛械臅r(shí)候一批的Json串過來之后，難以有效的挖出里面的關(guān)系與邏輯，索性就一次性將他們放入Redis中吧，使用時(shí)再反序列吧。同時(shí)建立讀寫分離的原則，我們主要將讀放在了Redis里面，寫到了Mysql，并通過Mysql的觸發(fā)器實(shí)現(xiàn)服務(wù)器段數(shù)據(jù)的主從復(fù)制同步。

日志系統(tǒng)

之前我們的單一系統(tǒng)的時(shí)候，比如只是簡(jiǎn)單的3層架構(gòu)的話，我們通過Debug可以從頭debug到數(shù)據(jù)庫(kù)，每一步都是掌握在手底下，每一步都盡收眼底。可是對(duì)于這一個(gè)層次太深，組建調(diào)用較多，同時(shí)又是多線程的系統(tǒng)來說，挖到雷的機(jī)會(huì)，時(shí)間，成本都是要考慮的。于是有效的使用日志組件，有效的在代碼中埋雷就顯的尤為迫切和必要，能夠更好的幫助我們找到問題所在。

#p#

組件式開發(fā)

之前的簡(jiǎn)單分層系統(tǒng)我們通過Svn或其他的代碼管理工具，每次提交都可以Merge看的到，但是當(dāng)系統(tǒng)龐雜同時(shí)系統(tǒng)獨(dú)立性很強(qiáng)的時(shí)候，分組建，分模塊開發(fā)就顯得很重要。因?yàn)椴幌肜速M(fèi)大家一起Merge的時(shí)間，我們習(xí)慣性每個(gè)人有自己的Branch每周2的時(shí)候提交代碼，大家一起參與，這樣減少了好多因?yàn)榇a管理浪費(fèi)的時(shí)間。

測(cè)試用例

之前小的系統(tǒng)使用測(cè)試用例基本就是裝B用的，本來小小的系統(tǒng)整套流程腦子一想就可以知道怎么做啦，為什么還要浪費(fèi)時(shí)間。可是在這次開發(fā)中充分理解了測(cè)試用例的重要性。比如我需要你給我提供多臺(tái)服務(wù)器的監(jiān)控?cái)?shù)據(jù)包括CPU信息，IO信息，NEt信息等等，但是你還沒有想到怎么樣去抓取虛擬信息，不能因?yàn)槟愕膯栴}去影響其他人的進(jìn)度的，***的方式從使用者角度獲知他希望使用什么樣的數(shù)據(jù)，為其建立API，同時(shí)為API建立測(cè)試用例并保證測(cè)試穩(wěn)定。而后期我有了監(jiān)控虛機(jī)的方式之后我在建立對(duì)應(yīng)的適配方法適配到對(duì)應(yīng)的API上。

所以首先肯定要保證API的穩(wěn)定，因?yàn)樗系臇|西已經(jīng)穩(wěn)定了嗎，你只好辛苦啦，有效的測(cè)試用例可以幫助我們更好的剝離項(xiàng)目邏輯與協(xié)調(diào)組件系統(tǒng)。

編碼原則

這個(gè)主要是每周有時(shí)間大家一起參與Code Review，由于開發(fā)人員的能力不同資歷不同，所以總會(huì)在代碼的編寫上和建立出現(xiàn)太多的不統(tǒng)一。比如命名啦，變量聲明啦，有的時(shí)候會(huì)發(fā)現(xiàn)剛畢業(yè)的小朋友會(huì)將好多的私有變量放在類的頂部，同時(shí)一個(gè)類里寫太多的方法，而且有的方法好長(zhǎng)，還沒有注釋。于是有的時(shí)候你想了解一個(gè)方法的真正含義，要鼠標(biāo)各種滾動(dòng)，到變量聲明去了解真正用途，好煩的。

有的時(shí)候代碼的職責(zé)不明確，總是瀑布的思想方式去寫代碼，比如我們兩個(gè)功能：一個(gè)是發(fā)送API請(qǐng)求建立虛擬機(jī)，另一個(gè)是在虛擬機(jī)建立成功時(shí)候?qū)⒉僮鱈og寫入db。他們習(xí)慣性的將寫DB的邏輯放在了發(fā)送HTTPRequst的方法里面，這完全是兩個(gè)邏輯。另一個(gè)問題是由于創(chuàng)建虛擬機(jī)是需要時(shí)間的，同時(shí)盡管虛擬機(jī)操作成功有可能你寫DB的時(shí)候網(wǎng)絡(luò)原因DB失敗了。我認(rèn)為這應(yīng)該是個(gè)原子的操作，兩者的狀態(tài)必須統(tǒng)一，就像是你在手機(jī)充值的時(shí)候顯示銀行卡扣金額成功，可是手機(jī)充值是出現(xiàn)問題，錢不是白花了嗎。所以在這些有特殊邏輯的地方要建立特殊的統(tǒng)一的機(jī)制，不能每個(gè)人有各自的實(shí)現(xiàn)。

之后就是溝通了

由于項(xiàng)目涉及到多個(gè)項(xiàng)目組，我們并不是同一個(gè)部門，相互也不熟悉，所以溝通上就會(huì)有一些需要注意的。首先要了解“對(duì)手”，主要是因?yàn)槿绻麑?duì)方是個(gè)技術(shù)高手，你不能像個(gè)白癡小孩，要有所準(zhǔn)備，最起碼知道他們用什么開發(fā)語言，他們需要關(guān)注的業(yè)務(wù)邏輯，等等，不能讓他們得到你是個(gè)菜鳥的結(jié)論。

由于口頭的好多東西可能是沒有經(jīng)過檢驗(yàn)的東西，所以前幾次達(dá)成的協(xié)議我們只是做個(gè)參考，需要多次溝通之后才能確定結(jié)果，比如我們的項(xiàng)目中我們需要和Python組Java組協(xié)調(diào)消息接口，消息格式的時(shí)候。你要知道協(xié)調(diào)RabbitMQ時(shí)候我們需要定義下交互的Exchange，queue name 或者RoteKey等等，同時(shí)由于消息格式比較大，需要定義一些關(guān)鍵字或者預(yù)設(shè)字段的話，需要發(fā)郵件進(jìn)行確認(rèn)與溝通，避免開發(fā)過程中產(chǎn)生誤會(huì)影響完成的功能返工。

總之這次搭架子的過程收獲很多，一時(shí)半會(huì)也不能想的全面，以后慢慢聊，由于是***次資歷尚淺，好多的技術(shù)選型，問題考慮可能不成熟，也希望大家知道更多的能夠糾錯(cuò)指導(dǎo)。