易于扩展的架构实战——概述

这段时间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、微信、轻应用的对接。

最后，会探讨一下微信方面的开发，这个其实笔者在之前也贡献了相关的源码。