技術乾貨：咱們的項目是如何技術選型的

選擇最合適的，而不是最「好」的

  這個論述幾乎已是老生常談了，每個有經驗的工程師都會強調這個。但不少出入職場的工程師，包括一年前的我，都會壓抑不住本身的滿腔熱情，看到有新的技術，而且恰好能夠知足項目的需求，便躍躍欲試。但是坑每每是在上文提到的風險中。新的技術每每可能有bug；也因爲新的技術不成熟，後續版本極可能會推翻舊版本的不少設計，致使向下兼容很不友好，致使已有系統的升級困難重重。可是能夠不升級嗎？新的bug只在新版本中修復，官方不維護舊版本怎麼辦？ 
  固然，舊版本就必定好嗎？新項目還用java 1.4的話，我仍是以爲這樣太做了。冷靜地分析項目的需求和風險，冷靜地分析技術的優勢和缺點，冷靜地把項目的特色和技術的特定匹配起來，這須要經驗的輔助，方法論只能提供一個尋找道路的方法，但至於找到的路如何就真的看各人修爲了。 
  可是保持對新技術的熱情是每一個工程師必需的。所以我很是建議每一個開發人員都在github上發佈本身的代碼。在這裏咱們能夠盡情使用本身喜歡的技術，盡情學習各類各樣的新技術，盡情開展各類各樣的實驗，發泄本身對技術的熱情，也只有這裏能夠不須要考慮各類風險，哪怕代碼錯漏百出也不會有人干涉。

http://blog.csdn.net/phospher/article/details/51546042

<td id="artContent">
<div style="width: 656px; margin: 0; padding: 0; height: 0;"></div>
<p><img src="http://image96.360doc.com/DownloadImg/2016/04/2608/70530311_1" img_width="1280" img_height="1226" alt="技術乾貨：咱們的項目是如何技術選型的" data-index="0"></p><p><strong>本文做者：上海駐雲開發總監 陳昂</strong></p><p><strong>如下正文：</strong></p><p><img src="http://image96.360doc.com/DownloadImg/2016/04/2608/70530311_2" img_width="900" img_height="500" alt="技術乾貨：咱們的項目是如何技術選型的" data-index="1"></p><p>公司逐漸壯大，團隊日趨穩定。做爲一名陪着公司一塊成長的一分子，我深感欣慰。驀然回首，發現咱們居然有了諸多產出與成果。有平臺，有工具，有產品，有項目。有些項目進行中，有些產品已夭折。但無論怎樣，看着這麼多已有成果，仍是小小的驕傲了一下。然而驕傲之餘，精心沉思，咱們積累的太少，沉澱的不夠。之前，咱們就像是在打仗，爲了生存，你死我活，兵貴神速，分秒必爭。如今，咱們多少能夠喘一口氣的時候，有必要回顧下，總結下，沉澱下了。</p><p>那麼，今天就先回顧下咱們以前這些項目的技術選型過程吧。</p><p>時間回到2013年，當時剛剛換了一份餬口的工做。一家廣告公司，美女如雲，帥哥成堆，有充足的時間和資源讓你定位本身的性取向。然而胖子的一通電話讓我沒有時間再去思考性取向的問題了。他電話中對雲計算一陣雲裏霧裏的吹噓，讓個人當心髒頓時撲通撲通的久久不能平靜啊。立馬決定加入他的新公司，擁抱雲計算，迎接新挑戰。</p><p>一個月後，到了新公司，哦不，應該說到了兄弟公司，借位辦公（新公司還沒徹底成立，辦公地點也還沒選好，這些都不重要了，重要的是新產品已經開始規劃了）。挖了兩個前同事立馬開幹，作一個可視化雲設計平臺，主要面向阿里雲（國內雲計算老大嘛，抱大腿嘛，固然要抱老大的大腿嘍）。通俗的講呢，經過這個產品，用戶能夠方便直觀的設計出雲資源架構。</p><p><strong>產品有幾個基本需求：</strong></p><p><strong>1.免安裝</strong></p><p><strong>2.兼容iPad</strong></p><p><strong>3.拖拽操做</strong></p><p><strong>4.呈現的架構夠直觀</strong></p><p><strong>5.可以同步基礎雲資源（阿里雲）</strong></p><p>基本需求很少，但各個切中雲計算痛點。發揮的餘地仍是比較大的。對於第一點，免安裝，那麼基本只考慮WEB方式了。</p><p>既然是WEB應用，就要先考慮五花八門的瀏覽器的兼容性。因爲這個產品的客戶比較面向技術，IE也就暫時不考慮兼容（不解釋）。最後選了兩款瀏覽器做爲主要兼容目標：Chrome、Safari。</p><p>選好瀏覽器就是開發語言的選型了。JS確定是必須的，另外，那麼後端語言，零零總總一堆：<strong>PHP、NodeJS、Python、JAVA、ROR...</strong></p><p><strong>· PHP是WEB霸主，有不少成熟的WEB框架</strong></p><p><strong>· NodeJS是新貴，自己就是JS語言，先後端基本不存在兼容問題</strong></p><p><strong>· Python語法夠優雅</strong></p><p><strong>· JAVA夠厚重穩定，可是開發慢</strong></p><p><strong>· ROR夠快，可是比較適合MES系統</strong></p><p><strong>· ...</strong></p><p><strong>咱們這個產品有什麼特色呢：</strong></p><p><strong>· 面向雲計算的設計和同步平臺</strong></p><p><strong>· 前端有大量複雜的邏輯和計算</strong></p><p><strong>· 後端不須要太負責的邏輯支持</strong></p><p><strong>· 可以快速開發和產出，由於當時若是不及時產出，公司可能就死掉了<strong>（QAQ）</strong></strong></p><p>既然這樣，咱們直接先排除了JAVA、Python、ROR。後來在PHP和NodeJS之間猶豫了很久。最後考慮到PHP噁心的語法，考慮到NodeJS完美支持JSON，最後考慮到咱們須要實時同步而NodeJS領域有個Socket.io能夠完美支持，就選擇NodeJS了（其實那些都是爲了說服本身的理由，PHP畢竟仍是很成熟的）。</p><p><strong>接下來的事情就是選幾個已經有不少輪子的框架或工具，幫咱們造車。</strong></p><p><strong>· 因爲前端須要Canvas，最後找了一個很不錯的Canvas框架KineticJS（其實咱們是先看到了KineticJS，再定了Canvas），KineticJS封裝了豐富的Canvas組件，讓咱們能夠以組件的方式操做畫布，方便開發。</strong></p><p><strong>· 模板層咱們選了輕量的Handlebars。</strong></p><p><strong>· 後端NodeJS層面選用Express</strong></p><p><strong>· MongoDB層面選用Moogoose來操做數據</strong></p><p><strong>· 因爲先後都是JS，爲了提升開發效率，強制你們都用Coffeescript（js的轉義語言）來編寫代碼（幾乎全部項目沿襲至今）</strong></p><p><strong>· CSS用Less，就像Coffeescript同樣</strong></p><p><strong>· 項目構建採用Grunt</strong></p><p>其實這些技術選型仍是很盲目的，然而技術永遠不可能有最好的，只有最適合的。雖然是盲目的選型，可是選型和推廣的過程的確是痛苦的，無論團隊是人多仍是人少。世界上最可貴的事情莫過於說服別人改變本身的習慣。好比推廣coffeescript，有一個開發很排斥，一開始死活不肯用coffee寫js，感受這樣不夠正宗，他的一句話還讓我快吐血了，是男人就不應戴套。不過私下裏他仍是嘗試了coffee，也很發現了coffee帶來的快感。</p><p>後來的事實也證實咱們的技術選型帶來了很大的優點。三我的，兩個月就出了初版，並參加了阿里雲開發者大會，收穫也不一樣凡響。後來又通過幾個月雕琢，出了好幾個版本。奈何當時阿里雲API尚缺穩定，也不夠豐富（固然咱們也是對API深度使用了），咱們只發布了一個設計版。</p><p>這裏有必要發一下咱們這個產品的簡單部署架構。</p><p><img src="http://image96.360doc.com/DownloadImg/2016/04/2608/70530311_3" img_width="2550" img_height="1460" alt="技術乾貨：咱們的項目是如何技術選型的" data-index="2"></p><p>架構很簡單，同時，這個架構也是我用咱們這個產品畫出來的。其實這個產品仍是有不少bug的，以及體驗上的缺陷。</p><p>然而，這些都不重要了。咱們度過了生存期，並且還帶來了個意外的項目，爲阿里雲作一個VPC的可視化平臺（這個平臺如今你已經看不到了，放個圖吧）</p><p><img src="http://image96.360doc.com/DownloadImg/2016/04/2608/70530311_4" img_width="1902" img_height="1292" alt="技術乾貨：咱們的項目是如何技術選型的" data-index="3"></p><p>有時候事情的發展就是這樣，作好了本身的本職工做，幸運就會降臨，就像國足此次進入12強，贏得了牽動亞洲的計算題同樣。</p><p>這個項目的技術選型和上面那個產品差很少，就不贅述了。須要提一下的是這個項目在部署階段遇到攔路虎了。由於是阿里雲的項目，部署環境理應是用阿里雲資源，一開始的架構是這樣的：</p><p><img src="http://image96.360doc.com/DownloadImg/2016/04/2608/70530311_5" img_width="1368" img_height="1044" alt="技術乾貨：咱們的項目是如何技術選型的" data-index="4"></p><p>前面仍是負載均衡，掛載兩臺機器，緩存服務採用阿里雲的OCS，數據庫咱們嘗試用OTS。</p><p>在部署的過程當中，發現SLB沒法透傳Websockets，也就沒法支持Socket.io工做，而Socket.io在這個項目中起了很大的做用。咱們嘗試着SLB從HTTP換成TCP模式（畢竟SLB對TCP模式是直接轉發的IP），但也不行，當時沒搞清楚是阿里雲產品的問題仍是咱們配置問題（固然如今的阿里雲SLB已經很完美了）。後來通過屢次嘗試，終於曲線救國，socket.io 改用polling的方式，不用websockets。另外爲了充分發揮多核的性能，NodeJS也開啓多個進程。可是爲了知足Socket.io，要保證Session在同一進程，Nodejs每一個進程就開啓了不一樣的端口，前面經過Nginx 配置 IP Hash並反向代理到不一樣的NodeJS端口。以下圖所示</p><p><img src="http://image96.360doc.com/DownloadImg/2016/04/2608/70530311_6" img_width="1324" img_height="642" alt="技術乾貨：咱們的項目是如何技術選型的" data-index="5"></p><p>再後來，發現OCS的Node SDK不穩定，就啓用了OCS，直接換成了ECS搭建Memcached。</p><p><img src="http://image96.360doc.com/DownloadImg/2016/04/2608/70530311_4" img_width="1902" img_height="1292" alt="技術乾貨：咱們的項目是如何技術選型的" data-index="6"></p><p>通過幾個月的奮戰，這個項目成功上線，來不及喘息，新項目又來了。</p><p>此次要作一個雲管理平臺，典型的MES系統。項目開始，技術選型這塊就出現了矛盾。基本明確的是基礎語言不變，後端仍是NodeJS，數據庫換成RDS。</p><p>可是前端的框架起了爭執。以前的那些框架或工具明顯不適用了，得選一個可以快速開發而且方便維護管理的前端框架作支撐，這時候AngularJS和EmberJS進入了咱們的選擇。一個是Google出品，上手快，但深刻難。一個是社區項目，更面向生產，但不夠輕盈。我堅持選擇EmberJS，由於更加面向生產，也更加面向團隊協做，不像AngularJS引入了不少新概念，學習成本更低。一個同事堅持Angular，他以前就用過，並且Angular更火一點。最後我作了妥協，畢竟無論哪一個，對我來講都是新的。而若是團隊裏有一個有經驗的人在，會更加可靠一點。</p><p>後來的狀況是這樣的，Angular配合着NodeJS帶來了極速開發，項目一個多月就上線了（你沒看錯，是一個多月）。這個框架在公司也就火起來了（雖然開發仍是很少）。這期間，我我的也對Angular上手了，感受框架自己的理念仍是很超前的，開發很是快，特別適合MES系統，若是你的系統是管理系統，BOSS系統，或是信息系統，用它，絕對沒錯。</p><p>公司這時候也逐漸壯大了起來，產品和項目也多了起來。一個產品或項目不再是隻有一個兩我的奮戰的狀況了。團隊成員之間的協做也變得日趨重要和緊密，程序須要解耦，團隊協做一樣也須要「解耦」。敏捷開發時代，前端程序是不可能等後端API都調試好了再進行開發的。這個時候就有人提出了「先後分離」這個詞。這個詞當下很火，阿里也在作這樣的事情，只不過業務不一樣罷了。幾我的坐下來一合計，感受這事靠譜，作吧。接口規範定義清除，數據格式定義清除。後端無需關心前端的業務邏輯，只要保證好什麼樣的接口應該具備什麼樣的權限，應該如何傳參，返回什麼樣的數據就行。校驗不經過，按照既定的數據格式返回給前端。前端業務只須要根據後端的API返回數據作進一步的邏輯處理就行。先後端同步進行，沒有完成的接口，前端經過Mockup調試，完成了就聯調。直到如今，咱們的前端妹子，還在說，「先後分離」大法好啊。</p><p><strong><strong>·</strong>永遠沒有一招鮮的技術</strong></p><p>永遠沒有一招鮮吃遍天的技術，也沒有一招鮮的選型。由於業務的需求，咱們接了一個外包。對方公司要求作一個CMS系統 + 開發者平臺。若是不考慮其餘因素，CMS系統咱們可能就直接上Drupal啦，開發者平臺就經過Angular +NodeJS實現。但是對方還有一個需求就是開發完成3個月內可以接手代碼，而對方公司技術人員大多數是JAVA背景。爲了可以讓對方快速接手，咱們作了以下的技術選型。</p><p><img src="http://image96.360doc.com/DownloadImg/2016/04/2608/70530311_7" img_width="1510" img_height="776" alt="技術乾貨：咱們的項目是如何技術選型的" data-index="7"></p><p>在這個模型中JAVA層只負責和客戶的TOP數據接口打交道，而後經過提供RESTful風格接口爲前端系統提供接口服務。其中CMS和開發者平臺都是基於Angular打造。因爲網站直接面向公衆，更多也是靜態頁面，須要有更好的加載性能和SEO友好，因此經過NodeJS進行渲染，而NodeJS又和JAVA進行數據交換。</p><p>開發的過程，其實並非太順利。一方面由於對於CMS系統（業務複雜性很高）的不瞭解，咱們等於說是從0打造，沒用太多的輪子可用。另外一方面，項目存在三方協做的問題，協調效率並非過高。但無論怎樣，項目仍是順利完成了。</p><p><strong>· 新的挑戰</strong></p><p>隨着業務的發展，公司想要對最先的架構雲從新打造，讓其上升到一個更高的高度。若是要用數字1表示一個產品是完整的，那麼以前的架構雲只能說是0.8。畢竟是公司初期的產品，也有不少產品外的壓力因素致使咱們沒有作到1。不過公司今非昔比了，有充分的時間讓咱們靜靜思考下產品，咱們有了更高的目標和要求，那就是把產品從0.8作到1，再作到5。基於這個目標，通過團隊人員的討論和商量，老產品維護成本過高，基礎選型也不夠成熟，咱們打算對其進行重構。重構的第一關就是技術選型啦。結合以前的經驗，咱們認爲，輕量級的框架會給咱們帶來更高的掌控性和穩定性。後端選了NodeJS，數據庫採用Mysql。更多的工做是在前端。通過Demo嘗試，SVG性能更好，開發起來也更加舒服。基於SVG選了Snap.svg（比較輕量的SVG工具）。在渲染層面，選了鼎鼎大名的ReactJS。ReactJS的VirtualDOM對於畫布的渲染有着很是高的性能和可維護性，也能方便的作到組件化和模塊化，進一步下降開發成本。如下就是咱們新的架構雲技術選型</p><p><img src="http://image96.360doc.com/DownloadImg/2016/04/2608/70530311_8" img_width="1268" img_height="656" alt="技術乾貨：咱們的項目是如何技術選型的" data-index="8"></p><p>新的架構雲已經如火如荼的進行中了，幾個月後，你們將會看到漂亮的初版。敬請期待~~~</p><p><strong>好啦~本文到這裏就結束了，同時，若是喜歡咱們的話就趕忙訂閱咱們吧~~~天天定時推送新鮮乾貨~~~也能夠關注咱們的微信公衆號：架構雲專家頻道 天天同步更新喲~~~</strong></p>
</td>

 

 

http://www.360doc.com/content/16/0426/08/32626470_553847410.shtml