這段時間IT業界也是風起雲涌， 各種收購、併購、融資的消息不斷。跟我們技術相關的討論，從以前對IOS陣營和Android陣營的PK，轉向微信公衆賬號還是APP的PK， 甚至還包括了各類瀏覽器的輕應用之間的較量。未來，爲了覆蓋多個渠道【IOS平臺，Android平臺， 以及可能的社交平臺(微信、line，facebook等)】， 真需要好好考慮一下服務端和這些應用之間，該如何交互，才能讓我們的框架，適應未來的各種變化。
爲此，我們設計了一個容易擴展的架構， 後臺採用Java Servlet + Mysql(mybitis) + Log4j + Json這一套簡單的程序包， 它對外僅僅提供Json組裝的API接口。 作爲服務提供方, 並且，該服務爲私有服務。
在前端上，我們採用，我們完全分離出來:
1. PC 、手機Web頁面 ——採用的方式是: 純H5 + JS + Ajax的方式
2. 微信公衆賬號—— 按照微信的協議，並且嵌入手機Web頁面的方式（微信提供了相關接口）
3. 各類APP(Android、IOS、WP) —— Hybrid App， 方便擴展
在未來的章節中，會逐步將前端和後端的源碼提供出來，供大家學習和參考。 我們這樣考慮的初衷是:
1. 減少技能要求， 讓技術成本最小化
2. 維護代價最小化。 降低後期投入風險。 比如，用戶對UI不滿意，即使全部更新。至少後臺的東西能保留，有所積累。
3. 方便拆分任務，前端和後端徹底分離得概念， 讓各自能聚焦自己的任務。
這裏再補充一些題外話，還記得三年前，筆者一直是App的死忠。 覺得App憑藉優良的用戶體驗，必將Web App開發打敗。 除此之外，因爲人們感興趣的站點，不會多過於7個（摘自《金字塔原理》）， 這一切似乎都是對的。 但App的門檻高，對於初創的企業、對於他們的用戶而言，都不是一個很好的選擇。
從初創公司來看:
1. 開發成本高。比如需要覆蓋多個平臺。 這個不是普通公司能承擔的
2. 推廣成本高。 一個App推廣的成本，大概在RMB2~ 5元。 通過刷榜的方式實現，這個成本和代價，過於高昂。
3. 用戶容易刪除，如果沒有足夠的新穎， 用戶遲早會產生審美疲勞， 很容易導致前功盡棄。
從用戶角度來看:
1. 用戶難以接受一個新的產品，尤其是需要下載，註冊繁瑣的產品
2. 用戶瞭解產品的渠道有限，App Store獨步天下，用戶難以看到真正需要的內容。
3. 不信任產品， 大部分的移動產品，有一些竊聽隱私的功能，導致用戶壓力太大，不敢下載。
4. 用戶很難關注某個單一功能的產品。 但大而全的產品， 又不是小公司能承受之重。
今天我理解的產品， 已經不僅僅包含研發，還包含市場推廣和營銷的因素。初創產品做好營銷渠道過於艱辛， 用戶也面臨接受一個未知產品的壓力， 個人看來，產品的思路應該如此:
1. 佈局移動渠道， 將各方流量匯聚到自己的產品上來。
這裏，我覺得需要仰仗微信——原因是用戶基數非常大。 當然更需要將其他的移動平臺覆蓋到位，比如Whatsapp，line. 最好的放肆，就是做一個手機web頁面，實現核心功能，或者是核心功能的80%。
同時，以線下爲核心，做好推廣工作， 因爲線下的流量是最優質的流量。
2. 通過流量迅速轉化爲現金流
3. 在足夠有錢、用戶對產品{這裏可能僅僅只是微信的公號}認知度度很高的條件下， 發展App用戶，進一步提升體驗，不願意安裝的用戶，依然可以留在原來的公衆賬號平臺。
類似於某些論壇可以通過QQ登陸，今天通過微信的公衆賬號，作爲訪問切入點，其實是一個很好的方案。 並且這樣的方案，非常容易和線下結合。
上述思路，也正好印證筆者現在談到的技術框架——後臺足夠輕巧，適應力夠強，方便前端營銷方案和推廣計劃的變動。下一步，我們將一步步的實現這個架構，首先從Servlet + Log4j 開始，逐步過渡到數據庫{mybatis + mysql}, 然後過度到Json接口. 你可以看到，筆者的架構對第三方組件的依賴非常少。 不像普通的J2EE,動輒上十幾百個包。 （補充一下， 上一家公司採用的OSGi的框架，這個讓筆者非常糾結， 實際上，插件的架構對我們的幫助不是很大。並且技術實現上，鮮有文檔可依，讓我們做得很艱辛）
接下來，我們會過度到前端技術， 設計一個移動Web應用，使用上述輕後臺方案提供的API接口，並通過H5+ Ajax實現. 這個方便和Line、微信、輕應用的對接。
最後，會探討一下微信方面的開發，這個其實筆者在之前也貢獻了相關的源碼。