我對服務端開發的一些認識

這篇博客主要是承接上篇的博客，繼續談一談自己對服務端開發的一些認識。當然，在這篇博客里面我不想只是鋪陳一些技術框架或者某個技術難點，一是服務端的技術框架太多了，我自己的技術有限；二是大家這樣看起來也會覺得很枯燥；

說到自己跟服務端技術的結緣，主要還是由于公司最近一年的HTML5項目。讓我自己能夠有機會從移動端轉到服務端，就像我自己之前一直說的，我一直很希望能夠接觸到更多地服務端技術。所以這次公司有個HTML5的項目，后端主要是基于java web去開發的，我就自己主動請纓的意思。因為主要的開發IDE還是eclipse，開發語言也還是java，所以在上手開發這塊根本就沒有什么難度了。最主要欠缺的就是要從移動端的開發思路轉變過來，就像上篇博客里面講的，我一直認為移動端的技術還是非常有限的，做來做去就是那些東西，一個一個項目無非就是重復造輪子了。但是服務端的技術就很有挑戰性了，最開始上手的時候，你也許還會對一些服務端的同事經常說到的前置系統、內管系統、高并發、數據庫controller層，服務層等相關名詞感到非常陌生吧！但是沒關系的，這是從事服務端開發的必經過程。這樣吧，我們先跟上篇博客一樣從一個簡單地登錄為例說說，服務端開發的流程吧（基于java）！你像現在一個正統的項目系統一般都會包括至少兩個展示渠道吧，一個是app，另一個就是web網站。比如剛剛說到的登錄功能，在web網站里面會有用戶登錄，在移動app里面會有用戶登錄。這兩種登錄方式除了頁面的展示不同之外，其他的方面屬性都應該是一致的。不管是用戶賬戶信息、用戶權限信息、以及與之相關聯的其他信息，都應該是同一套數據。這個時候，你可能就有疑問了。在服務端系統里面他是怎么同時支持兩種渠道呢？你一定回答道：這還不簡單嗎？直接開發同一套項目的接口不就可以了嗎？的確是這樣的，但是我又要問了：這套接口系統里面，他又是怎樣同時支持不同的請求方式（get/post）的呢？在這段系統里面又是怎樣保證接口處理流程的完備性呢？最后又是怎樣根據不同情況輸入不同響應報文給客戶端的呢？如果是涉及架構層面的話，可能還有一個值得考慮的事情，就是web網站建設的過程中到底要不要將UI和后臺的接口系統進行一定的拆分呢？針對這個問題也許你會覺得比較抽象是不是，你可以這樣想象一下：就是一個外面直接穿了一件牛仔外套，這個時候，他肯定會覺得很硬、硌得慌。這個時候如果我在牛仔外套和身體之間在加上一件軟軟的襯衫呢？是不是就感覺整個人舒服多了？沒錯，這個例子里面你可以將后面加上去的襯衫想象成接口系統，牛仔外套就是UI，你自己的身體就是服務端最核心的一些東西。通過一件外套我們可以將兩個渠道不同情況處理局限在一個系統層面里面。所以不管怎么說一個可以橫向模塊化的系統，它的生命長度都是非常高的。好了，讓我們繼續回到剛剛說到的登錄功能，我們先通過一個簡單地servlet去接受發送過來的渠道請求，我們可以在相關的配置文件里面申明接口的地址信息。比如我們可以將該登錄接口申明成login.do，當前名字是可以隨便取得。這個時候如果我們在本地環境里面進行相關的測試的話，我們就可以通過輸入：http://localhost:8080/項目名/login.do,完成這個接口的請求了。當然，如果我們直接將上面的地址在瀏覽器里面輸入的話，我們最多完成的就是一個get請求是不是？那么在這個servlet里面又是怎么區分get/post請求呢？說到這個問題，將是初學者最不用擔心的問題了，為什么呢？因為本來一個servlet里面就已經繼承了httpservlet了，通過這種方式，它就已經提供了兩個實現的doget,dopost方法了。通過這兩個方法，當不同的請求到來的時候，sdk里面的一套機制就可以區分不同的請求方式了，然后進行相關的分配了。好了，到這里我們基本處理好了接口請求的任務了。接下來，我們應該做些什么呢？是不是需要針對請求的報文信息做一定的驗證處理呀？答案是一定，比如字段是不是為空？傳輸過程中，我們可能為了安全性，對密碼加密。這個時候，我們也需要在服務端使用項目的加密機制，進行密碼的相關對比驗證了。當校驗通過之后，還有什么呢？沒錯還有最重要的一塊就是連庫對比該賬號是不是已經注冊，能夠登錄我們的系統了。哈哈，這個最頭痛的事情來了，數據庫操作。難道我們應該將數據庫操作也放在接口系統里面呢？如果數據庫操作發生錯誤我們又應該怎么辦呢？你可以想象如果是銀行系統里面，如果數據庫操作也發生錯了，那么影響將是非常嚴重的。好吧，因為到現在為止我們還沒有介紹到其他相關的服務端開發框架技術，所以我們暫且將數據操作也放在接口系統里面了。當我們連庫查找之后，根據用戶存在與否，回應code,msg報文就可以了。到這一步的話，我們整個登錄操作的流程才算真正的完成了。從移動的請求發送，到服務端的接口應答，整個系統的流程都完成的串起來了。是不是有一種頓時打通了任督二脈的感覺呢？別急，這還只是非常初步的知識呢？下面讓我們來看看現在java服務端開發現在使用比較多、比較穩定，然后針對不同的項目需求，我們可以選取不同框架比較輕松的完成項目的開發任務。

現在java服務端平臺比較主流無非就兩種框架了，一個是ssh,當然后來也出現了變形框架ssm;另外一種就是springmvc;這兩款框架都是比較成熟、穩定了。可以適用于比較大型的商用項目。下面讓我們細細講一下，這兩款框架到底包括哪些東西呢？兩者之間又哪些區別呢？首先讓我們來說一說ssh，ssh其實是三款框架的縮寫，分別是:spring/struts/hibernate。首先是struts框架主要是負責拆分mvc模式，而hibernate是用來做什么的呢？主要是為了用來進行數據庫操作的，負責持久化這一層。spring則主要是為了管理整個項目架構的。那么后面出現的變形ssm又是指的什么呢？其實ss還是原來的那兩個ss，但是h已經變成了現在的m,m主要指的是mybatis框架，就為了代替hibernate進行持久化操作的。另一礦springmvc呢？看這個名字就知道已經在原來的spring框架的基礎之上實現了mvc框架了，所以在這個框架里面就不再需要struts了，當然持久化的工具還是需要的。如果你想知道這兩款框架到底是怎么配置工作的呢？好吧，其實配置起來還是非常麻煩的，具體就不細講了。

當然如果我們進行開發的項目不是商業上面的那種大項目，對數據的安全性、高并發行要求都不那么高的話。那我還可以推薦一款比較好的國產框架Jfinal，這款框架的主要優勢是什么呢？配置非常簡單，一兩天即可上手開發。比如，現在如果我們有一個針對微信平臺的html5項目，這個時候我們完全就可以采用這款框架進行急速開發，再加上web前段一些比較好的框架，我們可以很好地完成開發任務了。

好了，今天先這樣吧，后面我會整理一些demo，還有web前段的一些技術，see you!