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