1.早期的技术选型，没有准确估计实际业务量，一定不要参考一线公司的技术选型，首先实现起来很复杂，其次技术面铺的太宽。
（够用即可，出生阶段，需要能快速实现产品。从0到1的时候需求上的假设都没有验证，没必要折腾APP。）
2.早期的技术选型要考虑高内聚、低耦合。
（不是不为未来考虑，而是分清主次，高内聚、低耦合的方式能在未来业务扩张的情况下实现业务的拆分，让系统间的依赖性减少）
3.人力成本衡量，最新的技术往往依赖核心的技术人员，以最新的技术做框架，要做到关键岗位有备份人选。
早期的手段可以粗糙，云服务是一个特别好的选择，帮助企业和团队节省大量成本。
4.电商，流量是最大的成本和Keyword，解耦流量这个词：卖给谁以及怎么卖。
（目前线上流量成本很高，其次都是一次性的，再次唤醒用户的成本很高，例：我买完手机以后，再买第二个，很久，很难，并且不一定在你这里买）
5.线上+线下。
提到微信，近场能力线下拉人并配合微信支付进行营销。快速验证，高效拉人。
线下的好处可以最大发挥：通过选择地点，圈定潜在用户。所以初期技术的选型务必考虑微信的元素进去。实现相关营销。
6.购买流程上必须完善，不能有技术短板，其次做好产品为核心的营销数据流。
可以考虑memcache，redis等分布式缓存系统，应用改成与状态无关，方便扩容及增加节点。
片面的追求百分百可靠都是异端，满足80%的高质量用户需求即可。量力而行，做人如是，技术也是如此。
7.一个靠谱的CTO，他的经验决定了未来产品的技术栈。
技术总结：前端、业务层、数据层。
前端下分为：移动端（IOS,Android）PC端。
业务层开发restful接口给前端调用，http协议json传输数据，前后端分离，分开部署，接口文档工具采用阿里的RAP，减少前后端沟通成本。
前端nginx分流，（不一定适用nginx+lua）lua可能会把控不住。静态文件考虑七牛和又拍。
后端业务层采用springmvc+mybatis，应用服务器XXX（待定），搜索业务采用soir，订单业务用队列服务器rabbitmq。数据层，分布式缓存--豌豆荚开源方案codis。
数据库层我了解的不多，基本一些点：减少表的关联查询，为后期的分离、服务、可读性做考虑。
