我終于深入?yún)⑴c了一個分布式系統(tǒng)了，好多想法不一樣了！原文出處：TurboZhang的博客前言過去兩個月深入的參與了一個分布式系統(tǒng)的開發(fā)，記得之前有人說過“想成為架構(gòu)師之前，都是從微觀架構(gòu)開始的”。盡管我從沒想過將來的某一天要成為一個架構(gòu)師，或者領(lǐng)域?qū)＜遥抑皇窍朊让葒}的編碼，寫著自己喜歡的Code，和一群志同道合的朋友做出大家喜歡的商品和產(chǎn)品。但是工作久了慢慢的搭架子的事情還是會來到你的面前，因為時間總會把一部分人慢慢推向海邊，使得他們成為最早見到陽光的人不扯淡了，為什么要說陽光呢，還是因為過去的兩（三）個月可能過的太充實也太痛苦了，完成之后，曙光來臨的時候整個人是會發(fā)光的哦?！吧疃取眳⑴c是因為我終于有機會在搭架子的過程中有了話語權(quán)和選擇權(quán)，同時也會承擔70%以上的編碼工作。之前我的自我認知是我可能在軟件方面的積累還可以，比如設計模式，架構(gòu)分層，程序解耦，API入手等方面，但是總覺得我在硬件網(wǎng)絡方面積累的太少，太薄了。比如：不同操縱系統(tǒng)之間的特點；網(wǎng)絡端口管理與分發(fā)；哪些網(wǎng)絡協(xié)議可以幫助我們更好的完成工作，監(jiān)控虛擬機的時候是在虛機上加代理好還是用協(xié)議去控制；硬件是否支持分布式，在擴展過程中對于.netC#的兼容怎么樣；什么時候使用多線程，在把線程交給程序調(diào)度的時候我們怎么控制和捕捉線程的異常；日志系統(tǒng)對于整個分散的系統(tǒng)是多么的重要；何時使用關(guān)系數(shù)據(jù)庫，什么時候使用Nosql；消息隊列用擅長的MSMQ還是RabbitMQ.怎樣有效的和其他部門的同事溝通；用什么樣的方式去有效調(diào)度不同語言開發(fā)的系統(tǒng)；測試用例對于大系統(tǒng)從零散到完整是多么的重要；系統(tǒng)標準，代碼原則對于后期的維護余擴展是多么的重要；項目簡介首先項目詳細內(nèi)容不便多說，簡答的說，就是為國內(nèi)某大型廠商建立一套協(xié)調(diào)其自身搭建的私有云以及其購買的公有云的一套系統(tǒng)。說牛X一點就是：一套混合云系統(tǒng)。使用Restful這是在構(gòu)建完整個系統(tǒng)最大的收獲，之前使用webapi的經(jīng)驗只是為電商系統(tǒng)的移動終端提供數(shù)據(jù)交互的接口，但是在這次項目之后發(fā)現(xiàn)Rest接口的不僅作為我們系統(tǒng)向外部系統(tǒng)提供交互的方式，同時在一些開源工具其暴露出來的接口也是基于rest的，可見全世界的程序員對于json對于rest有多么的喜愛；為什么裝上軟件配置完成之后使用不了之前的開發(fā)經(jīng)驗由于使用的都是微軟的技術(shù)包括組建，工具但是在項目中使用一些開源工具之后，配置成功之后卻總也跑不起來，同時由于開源工具已將Exception封裝起來，我們很難知道具體是什么樣的問題，有的時候調(diào)試好久還是跑不起來，很沮喪也很懊惱，結(jié)果最后發(fā)現(xiàn)是由于公司IT只是將常用的端口打開，其他的都干掉了，如果申請開放端口的話還要走流程，于是對于開發(fā)人員有時候有一臺外網(wǎng)的開發(fā)虛擬機也是相當?shù)挠斜匾?。使用RabbitMq個人是非常的喜歡使用Mq的，之前做電商總喜歡在Application層下面放入一層Service，你可以不用但是總會強迫癥似的不去不寫。為什么不用Msmq呢，原因是有很多了，簡單點就是rabbit要比Msmq的協(xié)議更加高級，支持的處理功能也更加豐富，最重要的原因是Rabbit在開源語言使用上是占領(lǐng)先地位的，而且我們的系統(tǒng)又要嫁接太多的開源語言系統(tǒng)，最后只能適配他們嘍。之前知道Mq在企業(yè)系統(tǒng)間數(shù)據(jù)交互使用頻繁，不但能有效的劃分層次，解耦依賴，同時數(shù)據(jù)交互方式上也相當?shù)谋憬??？倳邢]有被消費者使用，那我們就需要程序異步的去處理這個消息隊列了。Redis系統(tǒng)中使用了三種數(shù)據(jù)存儲，MySql,SqIServer,Redis,當然前兩種適用于開源和C#，而Redis的使用則是為了那些總是難以找到有效關(guān)系和依賴的數(shù)據(jù)，比如之前只是知道Reids可以作為數(shù)據(jù)的存儲，可以分布式，可以主從復制，但是在這次開發(fā)之后更真真的發(fā)現(xiàn)Reids或者Nosql對于一個數(shù)據(jù)規(guī)則難以掌握，數(shù)據(jù)量大的系統(tǒng)是多么的重要，因為有的時候一批的Json串過來之后，難以有效的挖出里面的關(guān)系與邏輯，索性就一次性將他們放入Redis中吧，使用時再反序列吧。同時建立讀寫分離的原則，我們主要將讀放在了Redis里面，寫到了Mysql，并通過Mysql的觸發(fā)器實現(xiàn)服務器段數(shù)據(jù)的主從復制同步。日志系統(tǒng)之前我們的單一系統(tǒng)的時候，比如只是簡單的3層架構(gòu)的話，我們通過Debug可以從頭debug到數(shù)據(jù)庫，每一步都是掌握在手底下，每一步都盡收眼底?？墒菍τ谶@一個層次太深，組建調(diào)用較多，同時又是多線程的系統(tǒng)來說，挖到雷的機會，時間，成本都是要考慮的。于是有效的使用日志組件，有效的在代碼中埋雷就顯的尤為迫切和必要，能夠更好的幫助我們找到問題所在。組件式開發(fā)之前的簡單分層系統(tǒng)我們通過Svn或其他的代碼管理工具，每次提交都可以Merge看的到，但是當系統(tǒng)龐雜同時系統(tǒng)獨立性很強的時候，分組建，分模塊開發(fā)就顯得很重要。因為不想浪費大家一起Merge的時間，我們習慣性每個人有自己的Branch每周2的時候提交代碼，大家一起參與，這樣減少了好多因為代碼管理浪費的時間。測試用例之前小的系統(tǒng)使用測試用例基本就是裝B用的，本來小小的系統(tǒng)整套流程腦子一想就可以知道怎么做啦，為什么還要浪費時間?？墒窃谶@次開發(fā)中充分理解了測試用例的重要性。比如我需要你給我提供多臺服務器的監(jiān)控數(shù)據(jù)包括CPU信息，10信息，NEt信息等等，但是你還沒有想到怎么樣去抓取虛擬信息，不能因為你的問題去影響其他人的進度的，最好的方式從使用者角度獲知他希望使用什么樣的數(shù)據(jù)，為其建立API，同時為API建立測試用例并保證測試穩(wěn)定。而后期我有了監(jiān)控虛機的方式之后我在建立對應的適配方法適配到對應的API上。所以首先肯定要保證API的穩(wěn)定，因為他之上的東西已經(jīng)穩(wěn)定了嗎，你只好辛苦啦，有效的測試用例可以幫助我們更好的剝離項目邏輯與協(xié)調(diào)組件系統(tǒng)。編碼原則這個主要是每周有時間大家一起參與CodeReview,由于開發(fā)人員的能力不同資歷不同，所以總會在代碼的編寫上和建立出現(xiàn)太多的不統(tǒng)一。比如命名啦，變量聲明啦，有的時候會發(fā)現(xiàn)剛畢業(yè)的小朋友會將好多的私有變量放在類的頂部，同時一個類里寫太多的方法，而且有的方法好長，還沒有注釋。于是有的時候你想了解一個方法的真正含義，要鼠標各種滾動，到變量聲明去了解真正用途，好煩的。有的時候代碼的職責不明確，總是瀑布的思想方式去寫代碼，比如我們兩個功能：一個是發(fā)送API請求建立虛擬機，另一個是在虛擬機建立成功時候?qū)⒉僮鱈og寫入db。他們習慣性的將寫DB的邏輯放在了發(fā)送HTTPRequst的方法里面，這完全是兩個邏輯。另一個問題是由于創(chuàng)建虛擬機是需要時間的，同時盡管虛擬機操作成功有可能你寫DB的時候網(wǎng)絡原因DB失敗了。我認為這應該是個原子的操作，兩者的狀態(tài)必須統(tǒng)一，就像是你在手機充值的時候顯示銀行卡扣金額成功，可是手機充值是出現(xiàn)問題，錢不是白花了嗎。所以在這些有特殊邏輯的地方要建立特殊的統(tǒng)一的機制，不能每個人有各自的實現(xiàn)。之后就是溝通了由于項目涉及到多個項目組，我們并不是同一個部門，相互也不熟悉，所以溝通上就會有一些需要注意的。首先要了解“對手”，主要是因為如果對方是個技術(shù)高手，你不能像個白癡小孩，要有所準備，最起碼知道他們用什么開發(fā)語言，他們需要關(guān)注的業(yè)務邏輯，等等，不能讓他們得到你是個菜鳥的結(jié)論。由于口頭的好多東西可能是沒有經(jīng)過檢驗的東西，所以前幾次達成的協(xié)議我們只是做個參考，需要多次溝通之后才能確定結(jié)果上匕如我們的項目中我們需要和Python組Java組協(xié)調(diào)消息接口，消息格式的時候。你要知道協(xié)調(diào)RabbitMQ時候我們需要定義下交互的Exchange，queuename或者RoteKey等等，同時由于消息格式比較大，需要定義一些關(guān)鍵字或者預設字段的話，需要發(fā)郵件進行確認與溝通，避免開發(fā)過程中產(chǎn)生誤會影響完成的功能返工?？傊@次搭架子的過程收獲很多，一時半會也不能想的全面，以后慢慢聊，由于是第一次資歷尚淺，好多的技術(shù)選型，問題考慮可能不成熟，也希望大家知道更多的能夠