移動開發的未來——微服務

標籤：移動開發   響應式設計   行動裝置 App   開發人員   移動平台   

如果對於移動開發，你的知識還僅僅限制於響應式設計，那麼這是遠遠不夠的。

作為一個開發人員不得不去處理一些老舊的架構，同時添加一些新功能。為了不僅僅是更好的適應需求，有時也是為了方便更好的擴充。分享一下，今年來玩的兩個不同網站的移動擴充之路，一個是自己的網站，一個則是與女友建設中的一個尋找有趣的人、事、物的網站——尋ta驛站。

一次傳統網站的移動開發

對於一個傳統的網站來說，僅僅是Responsive是遠遠不夠的，對於使用手機、平台的使用者來說，重新整理是一種不好的體驗。這裡以自己網站(Phodal——Geek‘s life)的架構作一個樣本，而自己重構時的思路是來自於某大型網站的架構。

如所示，

部落格使用的是基於Django的CMS-Mezzanine，資料庫用的是MySQL，而在後面的某個時期已經換成了SQLite3，受限於伺服器的效能。簡單地來說，這就類似於一個傳統網站的架構，有簡單的後台和前台，可以方便地擴充，添加新的功能。

對於一般的使用者來說，他們可以習慣於在自己的電腦上的重新整理，甚至於如果沒有重新整理的話，他們可能覺得他們什麼也沒做。而對於移動端來說，重新整理是一種不好的體驗，不僅會帶來額外的流量，當然還有漫長的等待。這可以很好的解釋為Responsive什麼在今天Angularjs、Mustache等等的JS庫這麼流行，因為AJAX帶來的優點實現是太多了。對於移動端採用JS來說

• Javascript的程式員很容易找到(似乎對於一個背景程式員來說，JS也是要掌握的)。
• 需要的只是構建RESTful API
• 不用重新整理是多麼美妙

雖然他的缺點也相當的多，其他的有如

• 調試上的不便
• 學習曲線
• 有時候你沒有辦法處理一些與作業系統相關的事件(如select)。

在這裡對於我們構建我們的API來說，我們所要做的便是產生一個RESTful介面，對於我們用的是怎樣的構架已經無所謂了。Nodejs與RESTify的作用便是相當於一個微服務，具有與之相關的特性，如:

• 服務本身是非常簡單的，每個服務側重於做好一件事;
• 可在這個位置使用最佳和最合適的工具來構建每個服務;
• 建在這樣的系統本質上是松耦合;
• 多個開發人員和團隊可以彼此相對獨立的提供這種模式下;
• 他們是一支偉大推動者連續輸送，讓頻繁的發布，同時保持系統的其餘部分可用的和穩定的。

我們可以選用不同的架構來做這些事情，而不需要去考慮其他因素，所要做的是便是獨立開發。而在這時，負責移動UI的程式員也可以很愉快地開發了他們的開發之旅，而不是等待。

移動開發與

在構建尋ta驛站的時候，一開始我想要的只是一個部落格，可以方便地寫部落格，同時可以擴充，除了Wordpress沒有想到其他的部落格系統。於是，很愉快地先選了個WP Super Cache以加快網站的開啟速度，作為緩衝來說效能還是相當優異的。

因為要開發一個公眾的查詢功能，於是用上了WP-API，以及一個公眾平台——weChat-backend。而weChat-backend則是基於Ruby上的Sinatra架構開發的，當我們發起一次查詢的時候:

如所示，當我們搜尋的是極客愛情，會將請求發給後台，而後台去請求WP-API，從資料庫查詢完後再返回。

接著我們便可以在手機用戶端上看到我們所要查詢的內容。對於一個查詢不到的結果時，返回的便是部落格的RSS的解析結果，返回最新的URL。可以用在公眾上搜尋:hongzhishushe，或者可以直接用二維碼掃描。

然而，這會帶來很多問題，其中之一便是Wordpress與MySQL的效能問題。然而相比於自己動手構建一個平台來說，利用現有的架構最佳化也是一個不錯的選擇。

後記

對於由傳統的網站、應用開發來說，行動裝置 App的開發是一種挑戰，我們需要去考慮更多的東西，而對於移動平台來說，Javascript是一種更好的選擇。需要去綜合考慮不同的因素，與傳統開發不同的是前後台分離的趨勢越來越明顯，後台對於前台來說僅僅是一種服務的存在。

無論是網站的手機版，還是對應於平台，後台對於前台只是一種服務的存在。而這種服務不再僅僅是傳統的宏服務，更多的是微服務。由一個個微小的服務來構成整個系統，為整個系統提供更強力的支援，當然他還有很多問題——《微服務架構——不是免費的午餐 》。