移動開發者的後端開發入門體驗

大多數公司移動開發的現狀

目前大多數公司移動開發過程當中都會多多少少遇到下面的這幾種場景：

1. 場景A（格式）

   • 移動端：老哥，要開發了，須要把接口給我。
   • 後端：這個以前有給PC的接口，你直接調Dubbo接口吧，你用那個字段就取哪一個字段好了
   • 移動端：？？？這麼多字段哪一個是我要的，爲何成功的時候這個字段返回的是個json對象、失敗的時候返回了個字符串。

2. 場景B （效率）

   • 移動端：各位大佬，App這邊此次項目中有個功能，須要用到訂單、商品和物流的信息，這個接口我應該找誰要？
   • 訂單大佬：我這邊只能給你訂單的，其餘的業務不應我去處理 商品大佬：我也是跟訂單同樣的。
   • 移動端：這接口沒人接了。。。
   • 產品：。。。我去跟各個TL確認下，這接口歸屬哪邊來開發

3. 場景C （在線問題解決）

   • 客滿同窗：線上App報錯了，彈出了個錯誤提示
   • 若干分鐘後。。。
   • 移動端：通過排查是xxx接口返回了錯誤信息，因此彈出了對應提示，功能不可用，接口責任人在訂單同窗那邊，須要訂單同窗查下。
   • 若干分鐘後。。。
   • 訂單同窗： 這個接口是個聚合接口，不僅有訂單的信息，看了下是調用xxx接口報錯了，須要sss同窗幫忙看下。
   • 若干分鐘後。。。
   • sss同窗：排查完畢，是今天發佈致使的，已經回滾了，目前線上問題已修復 此時已通過去了好幾個若干分鐘。

相信每一個移動端開發的小夥伴都或多或少的遇到過以上幾種場景。

爲何移動端要對後端開發有所瞭解

1. 做爲移動端開發的小夥伴們平時要對接的開發側的小夥伴，大多數時間段內都是後端開發的同窗，瞭解後端開發的相關知識，能夠有利於雙方之間的溝通，大大減小雙方溝經過程中「大眼瞪小眼」的尷尬場景，這也就是上面所說的場景A
2. 雖然如今Android官方推薦使用Kotlin語言做爲Android的開發語言，可是絕大多數Android的開發者都是使用java開發Android入的坑，學習後端開發的時候開發語言上不須要從新學習一遍
3. App端做爲直接面向用戶的端，接口裏的內容每每不是僅僅由一個提供方提供的，例如訂單列表的藉口中既會有訂單相關的信息，也會有購買方的用戶信息，還會有所購買的商品的信息，而在實際場景中，用戶、訂單、商品每每是由不一樣的部門負責的，這樣的話給app端提供的接口的維護歸屬就有了分歧，任何一個改動都須要通知各方協調（場景B），當有線上問題出現時查詢問題緣由也須要你們共同去查，會浪費不少人力（場景C），若是各方只提供本身相關的數據，由app端本身去組合數據提供給app端，那麼責任劃分和查詢問題就會輕鬆得多。
4. 移動端開發也會須要本身的一些基礎設施，如自動化構建的維護、跨平臺內容的下發、熱修復的管理這些都須要有本身的平臺去完成，而開發這些平臺最適合的莫過於咱們這些移動開發人員，由於咱們是使用方，更瞭解這些平臺須要替咱們完成什麼樣的功能

如何入門

首先是選擇學習的方向,選擇一個合適的框架

    對於java後端的開發而言，不管是各類書籍仍是網上的博客，基本都是在SSH和SSM兩種組合開發框架中作選擇。

• SSH：Struts2 作控制器(controller) + Spring 管理組件 + Hibernate 負責數據庫。
• SSM: SpringMVC 作控制器(controller) + Spring 管理組件 + MyBatis 負責數據庫。

    SSH是比較早的項目使用的框架，在各種書籍裏常常會見到，目前大多數公司使用的是SSM，Struts2以前屢次爆出了漏洞並且迭代速度並無SpringMVC 那麼快，對於 Hibernate與Mybatis 的話各有優劣，打個比方的話， Hibernate 更像一個能夠拎包入住的裝修好的房子，功能完善，可是難以進行優化和擴展，MyBatis 像是毛胚房，須要開發人員本身裝修(寫sql和維護映射)，可是得益於此擴展和優化相對自由度較高，建議選擇SSM好了，畢竟用的人多，遇到問題也容易找到解決方案。若是你對Spring繁瑣的配置過程感到很頭疼的話，建議使用SpringBoot來進行開發，由於它集齊了各種經常使用的開發框架，同時下降了 Spring 開發的門檻，更是簡化了各類配置過程。

簡單的後端開發用到了哪些知識

相信每一個最初接觸後端開發的小夥伴都會跟我同樣對後端複雜技術生態一臉懵逼，由於一上來就會接觸到不少陌生的詞彙，像Spring 的IOC和DI、負責數據庫操做的Mybatis、緩存方面的Redis等，甚至連該怎麼建立都不清楚。這些。。。。。都是正常的，畢竟沒什麼人樣樣精通。對於後端項目開發的學習，以我自身的經從來講能夠這樣進行：

1. 首先是搭建後端項目的框架，固然每一個公司都會有本身的模板工程，部署完以後就能夠跑起來，若是沒有模版工程的小夥伴能夠到https://start.spring.io/或者使用idea自動建立一個工程，
   start.spring.io自動生成工程只須要在這個頁面上選擇對應的條件就行了，以後把生成的工程導入Idea就能夠開發了。
2. 工程能夠跑起來以後就能夠寫提供給客戶端的接口了，在這部分你須要學習建立Controller、Service、log日誌的輸出以及maven的依賴管理，學習這些看官方文檔應該是最快的方案，https://docs.spring.io/spring-boot/docs/2.1.5.RELEASE/reference/htmlsingle/官方文檔寫的很詳細，因此不必單獨爲spring買一本書去學習，由於書確定不如官網的文檔更新的快，若是以爲英文不太方便的話，國內也是有中文翻譯的文檔版本的，能夠參照https://love2.io/@funkkiid/doc/Spring-Boot-Reference-Guide/README.md來學習。
3. 相信通過上面的兩部份你已經知道如何給客戶端提供接口了，可是光是這些是不夠的，由於給客戶端須要的數據每每來自各個服務提供方，例如上面舉的訂單的例子。這裏就須要咱們從其餘後端應用的服務獲取數據，目前國內大多數公司使用阿里開源的Dubbo框架來對外提供服務，因此在這裏咱們還須要學習Dubbo的使用，因爲Dubbo框架是中國公司開源的，因此[文檔]https://dubbo.apache.org/zh-cn/有中文版，學習起來會比較方便
4. 若是單純是調用別人的服務來整合數據的話，上面三部分學習知識已經能夠知足你的要求了。若是有涉及到App獨立的數據須要持久化存儲的話，還須要學習Mysql相關的知識以及Mybatis的使用。
5. 隨着後端工程業務逐漸複雜，你可能還須要學習更多的內容來完成本身的需求：
6. 緩存方面：redis
7. 權限方面：shiro、spring security
8. 代理服務：Nginx
9. 消息：ActiveMQ
10. 數據庫鏈接池：druid
11. 定時任務：Quartz
12. 爬蟲：WebMagic

其實這些都是可選的，用到的時候再去學習就ok了

有贊移動後端基礎設施所作的工做

對於有贊移動端的基礎設施的工做咱們主要作了如下的內容：

1. App網關，雖然項目名稱是網關，可是跟後端一般所指的網關不相同，這是一個專門給App這邊提供接口的應用，開始所說的三種場景的問題，這裏都可以很好的解決，由於後端同窗大多說是不瞭解app開發的，更多的小夥伴給App提供接口的時候會按照給前端網頁提供接口的方法給接口，這種場景下App這邊調用起來就會比較麻煩，在App網關中App端的小夥伴本身給app端提供接口，由App端自行維護這個應用，這樣的話中臺的小夥伴只須要提供本身那部分基礎服務就行了，徹底不須要考慮提供出去接口的格式和接口歸屬的劃分，同時出現線上問題App端的小夥伴也能夠直接定位到是哪一個服務出現了問題，能夠減小線上故障的時間。App網關結構以下圖所示：。在服務化的過程當中前段同窗也使用node作過相似的處理，感興趣的同窗能夠移步Node 在有讚的實踐，只不過不一樣點在於：App網關裏有一部分app端自有的業務邏，沒有頁面渲染的功能。
2. MBD，因爲業務線比較多，你們都在本身機器上打包的話比較耗時間，也沒辦法對安裝包的構建過程作統一的管理，因此開發了MBD來進行正式包、測試包和熱修復以及二方庫構建的管理。
   Apub，用於app應用新版本和熱修復的下發和灰度，同時與MBD打通，能夠實現從構建到發佈、熱修復、交付一系列流程的打通。
3. Weex構建平臺 ，相似於MBD的功能，對應的場景非原生髮版，而是weex發版，使得開發人員能夠更關注於業務自己，便捷的在不一樣環境全量、灰度發佈weex頁面。
4. 配置中心，隨着App功能的迭代，App端的配置日益增多：各類功能的開關、參數的配置、網頁url的地址……
   對配置動態化的指望值也愈來愈高：配置修改後實時生效，灰度發佈，分環境，同時對於運營人員而言，也不但願每次修改信息都由開發人員幫忙修改代碼發佈。
   在這樣的場景，傳統的經過移動端或者後端代碼中hardcode發版、修改數據庫等方式已經愈來愈沒法知足開發人員和運營人員對配置管理的需求。因而咱們開發了移動配置中心來知足這些需求。
   配置中心中能夠對不一樣的功能劃分不一樣的組件，給運營人員和開發人員發佈新配置的功能，新的配置能夠經過有贊IM的長鏈接和App先後臺切換去主動拉取配置，達到實時生效,通過數個版本的迭代，還接入了移動基礎保障發佈權限的審批、Apub的灰度發佈功能。
5. 移動基礎保障平臺，用於移動端管理平臺上的權限管理和審批、app端應用日誌的撈取和用戶設備信息的查詢、以及app內應用反饋的處理，配置中心基礎功能見下圖：

感覺&收穫

1. 客戶端的開發更加註重的是用戶的體驗，是用戶操做時的具體感覺，面向的是單個用戶，而服務端開發更注重的是功能和數據，是線上功能的可用性及數據的準確性。
2. 雖然客戶端和後端都會考慮應用的性能，可是二者側重點不一樣，客戶端更看重用戶使用的感知，如動畫效果及滑動流暢性，然後端更看重的是運行效率和併發能力。
3. 客戶端在開發的過程當中併發的場景比較少，切換線程一類的操做比較多，而服務端恰好相反，服務端場景下用戶併發的場景會不少，線程切換類的操做卻是不如客戶端那麼頻繁了，這與系統的限制及面對的場景相關，客戶端只面對一個用戶和服務端，而服務端須要面對多個用戶。

講座【特別推薦】

Spring Boot 系列文章如若不解，能夠經過講座進行進一步學習。

手把手的跟大家一塊兒Coding，你快來。

1. Spring Boot 1.5 快速入門教程
2. Spring Boot 1.5 進階
3. Spring Boot 系列教程（入門+進階） 【SF編輯推薦】