从0到1，用架构套路节省创业公司的机会成本
By 龙寅@玩多多
前言
有很多人在互联网大公司积累了不少经验后，投身创业，企图将自己的才华和经验更完美的释放。这其中，技术背景的创业者不乏少数。技术出身的人都有几个共同的特点：逻辑条理清晰、对细节把握仔细、追求事情的完美。而创业公司活下来的基础是快速抢占市场的一部分份额，马云所说的“唯快不破”一直以来是被大家公认的创业真谛。作为创业公司的技术人员，如何使技术快速跟上业务，甚至略微超前业务是非常有必要的，因为业务思考上突然的灵光一现最需要的就是线上系统能最短时间的实现，甚至是需要架构已经“天然”支持业务的变化。
最近两年来，我也经历了几次不算成功的创业项目。同样是创业项目，在团队实践过程中，一些曾经使用过技术方案被彻底的否定和放弃，而另一些优秀的技术成果被原封不动得保留下来，这大大节约了思考和设计的过程，缩短了项目研发时间，使得团队能够在前期很快进行业务的扩张。
在此过程中，我发现创业的技术不用求新、求完美，反而熟练掌握一些技术“套路”，并灵活使用能够为企业节约大量宝贵的时间。
套路1——微信“拉新”，APP“留存”
互联网创业公司为了线上接触用户，到底是开发微信公众号还是APP呢？或者两个都开发，但谁的优先级高一些？很多创业公司在初期都面临了这样的选择。
有个很有意思的现象，3-4年前，我们看见很多创业公司一上来就是搞APP开发。当时的APP程序员真是难招，任何一个项目如果要安全点至少得配齐4个人（2个Android、2个IOS），如果一个程序员又懂IOS、又能开发Android，那无疑是各类初创公司的宠儿。而最近两年，前端H5开发工程师逐步火了起来，很多企业招聘都互相哭诉前端人才在市场上非常难求。前不久有一篇文章传遍了整个朋友圈——《别开发App了，做个公众号就可以》，更是把低频APP直接“判了死刑”。
那么从0起步的公司究竟应该如何选择呢？
微信公众号有很多得天独厚的优势：
免安装——关注即可，这是微信公众号最大的优势！在前期推广，特别是线下推广，只需要一个二维码，用户扫码关注即可享受商家的线上服务。相比之前我们看见很多地推团队拿着各种礼物在街边要求路人下载APP就送礼物、还免费提供手机WIFI热点 要轻便得多、高效得多，用户的接受程度也高很多。
宜传播——利用关系。无论是朋友圈还是微信群，用户的分享和订阅关注都是在一个平台内发生的，所以传播的路劲变短、传播有效率容易提升。
成本低——相对APP。这里的成本主要是指开发成本。由于微信本身对网页浏览有一定的封装，所以跨平台的兼容性天然提升了很多。开发人员一般情况下一次开发就能适用于各种终端。大大减少了各种调试、适配的过程。而且平台的更新可以不需要用户主动触发，服务端升级就行了。
开发微信公众号是一个初创企业非常不错的选择，可以帮助企业一定程度上提升“拉新”的效率、减少一小部分获客成本。
APP相对来说，也有一些它无法替代的优势：
不依赖平台。随着微信公众号数量的增加，微信也在逐步出台一些标准。比如“不允许引导用户分享”，此标准直接干掉了一部分以诱导传播为主要功能的微信号。很多互联网企业的微信号也感到受到危险，经常能够看见一些企业的站点被微信“封杀”，搞得所有公司内部上下全员危机、动用所有力量一边找关系、一边解决触犯微信准则的问题。APP的独立使得企业的线上流量不完全绑定与微信平台，在功能一些功能开发商能够更容易接入一些第三方平台，比如支付宝、芝麻信用……而不用担心有一天这些功能会被微信屏蔽。
更好的体验。进入微信公众号后，微信的任何消息就不能及时查看，一但从公众号返回，用户所有的浏览路径都会丢失掉，一些访问路径较深功能就不容易再次使用。这使得设计微信公众号的页面结构不能太复杂——太复杂也很难有较高的使用率。
更直接的入口。相比进入微信再找到公众号，再进入应用，APP提供了更直接的用户入口。如果内容够丰富，粘性较高的用户更容易形成“逛”APP的需求。
所以，“拉新用微信、留存用为APP”。对于初创企业，是否采用APP应该考虑是否有足够丰富的内容能够提升忠诚用户的粘性，结合自身企业提供的用户服务以及开发资源的实际情况做出正确的选择。
技术上，初创企业开发微信公众号一般采用H5，react这样的框架能很好结构化移动开发。合理的模块化设计能让H5通过Hybrid APP的结构方式嵌入WebView中，既可以方便地调用设备本地功能，又兼具跨平台、设备兼容性、维护方便等特性。对于交互体验要求不是很高的、创业初始的应用来说这是一项非常节省时间的方案。
在Hybrid APP的架构设计中，要着重注意以下两个方面：
· 通讯方式：统一封装H5调用Native、Native调用H5的通讯方式。后期大量的逻辑都是基于通讯接口展开的。
· 资源的加载方式：将资源（css、js、html）打包在app中或运行时动态加载资源包。这两种方案的优劣也是一目了然的，前者减少了网络请求，后者则更加动态化、不依赖于版本更新。设计完善一个完善的H5容器有助于更好的体验，网络环境差的情况下读取本地资源缓存，在环境可许的情况下再读取线上资源进行更新。这样的方式能够方便开发人员更加便捷地抓取网络请求，进行问题查询。
套路2——三层足以
初期以验证商业模式为主，技术的复杂度不是创业者应该主动追求的。
我经历过的一个初创电商项目，技术团队的能力的确很牛、执行力也很强，1个月内从0到1实现了18个微服务，绝大部分业务逻辑都独立到每个子系统去了，包括：用户、订单、中央仓储、支付、促销优惠……。系统的结构的复杂、内部高度容错，上线后，经历了双11、黑色星期五、双12等多次线上流量、交易高峰，系统从一而终地稳定。但是我们在实践中也意识到有几点这样做大幅增加了成本：
系统成本。每一个微服务独立部署就是一个单独的进程资源，18个多负载的微服务加上高可用的ZooKepper，即便是采用公用云，也是一笔不小开支。
开发成本。一旦采用这样的模式，一个工程师要想在自己的本地环境搭建一套用于开发的环境是几乎不可能。而搭建一整套开发环境，前期根本不可能有时间让开发人员或者运维人员去及时更新各个服务的版本或者修复问题。所有的问题都只能先mock、然后放到测试环境做集成测试。如果遇到疑难的问题，很难进行现场调试和跟踪。
升级成本。初创企业的业务基本上是不可能定型的，再牛的设计也无法避免接口的升级和改造，而多服务的系统结构必定使得系统在开发时需要调用方与被依赖方分别修改。更麻烦的是增加了线上部署平滑过渡的难度，比如A依赖B，B修改了其中一个接口的逻辑，如果A先上线则会出现调用这个接口的业务逻辑无法正常运行；如果B先上线则会出现调用这个接口的业务逻辑异常或者产生脏数据。为了解决类似的问题，在开发过程中必须得引入版本控制，这又带来了一定开发效率的牺牲。
服务的多层次、拆分通常是针对系统复杂度、系统管理的角度来考虑的，有时也是为了解决一部分性能问题而单独增加层次。但，随着计算机硬件和开源技术的发展，如今这个时代的计算能力已经大幅超越以往，再加上各种缓存技术：内存、分布式缓存、URL缓存……初创企业的系统的前期性能优化已经不是太大的瓶颈。10年前做个10w用户的站点就让一个工程师费劲心思，而如今一个服务做到上亿访问也是轻轻松松的事情。
近几年，很多互联网公司的架构师出来讲系统架构的发展，都会提到从原始的三层到后来的多层、多服务。从0开始的企业，应该保持稳重踏实的步伐，不要觉得既然今后要拆分，前期就干脆一步到位——因为能否活到那一步都是未知数。技术的重心应放在业务模块的垂直划分，做好模块之间的独立于松耦合，尽量杜绝模块之间的依赖过多，做好今后模块拆分独立的准备即可。
记住软件架构的原则：Keep It Simple，Stupid！
套路3——构建能复用的组件
能够复用的组件从功能性上来说可以分为两种，一种是与业务无关的，我们称之为基础组件，一种是与业务有关的，我们成为项目组件。
基础组件
包括你的部署环境、代码仓库、异常日志处理方案、搜索引擎等等，这些组件能够加快项目开发、测试、发布各个环节的效率。
Docker 是一个开源的应用容器引擎，可以打包一个应用以及依赖包到一个可移植的容器中，然后发布到任何的机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口，几乎没有性能开销，可以很容易地在机器和数据中心中运行。最重要的是，它不依赖于任何语言、框架包括系统。构建属于自己团队的Docker镜像仓库，为不同类型的应用配置和创建不同的镜像能够在团队内部的项目在大环境上是一致的，能够加速后期新的应用的部署效率、节省部署时间。
持续集成、发布。持续集成能够减少团队开发风险：一天中多次进行系统集成，并做相应的单元测试，更早地发现开发过程引入的系统问题。持续集成能大幅提升团队开发效率：大幅减少了项目中各个部分的开发编译时间、集成测试时间、部署时间。而持续发布能够让团队在上线过程中更加自信、更加便捷，减少了人为控制过程中引入的操作风险。
日志中心。通常，服务器日志分散存储在每台不同的设备上，如果有多台服务器，仍旧采用登录每一台服务器查询日志的方案效率十分低下、而且操作起来非常繁琐。日志的集中管理在现代软件架构中显得重要。日志集成后，一个友好、高效的日志查询界面也是相当有必要的。目前开源的集成化日志管理系统有很多方案，没必要每个团队都去创建重复的轮子，但一定要定义自己的日志记录、收集规范，并用做好镜像备份。ELK平台是一个非常不错的选择，它由ElasticSearch、LogStash、Kibana三个部分组成。
Elasticsearch是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
Logstash是一个完全开源的工具，他可以对你的日志进行收集、过滤，并将其存储供以后使用。
Kibana 也是一个开源和免费的工具，它Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助您汇总、分析和搜索重要数据日志。
项目组件
项目组件高度提炼了通用的业务特性，创业公司开展多个项目的情况下能节省大量的研发时间。根据每个项目的特性有一些区别，但是一般来说都会包含以下几种功能性的组件：
基于微信的用户组件。任何的应用都离不开用户。一个较为完善的用户组件有：用户注册（包括手机短信接收、二维码、微信绑定）、用户登录、用户信息展示与修改。这些功能几乎存在于市面上90%的应用。GITHUB上有很多微信的开源SDK，即便如此，我也强烈建议初创企业不惜花几天时间自己造个轮子，一方面可以更加灵活地应对接口的变化，另一方面在后期能够针对第三方资源的访问进行统一的封装和
支付组件。如果存在线上交易过程，那么一定要独立封装一次支付接口，最起码需要支持微信支付和支付宝支付。支付的封装有一定的难点，主要在于与第三方系统交互还必须保证每一笔交易要么正常、要么失败。
后台管理系统。掌控和管理数据、流程。我曾经利用了一点闲暇时间带领一支小团队搭建了一套后台系统的框架。框架以下主要核心内容：
员工\/部门信息管理：登录后台系统的每个账号应该是能够代表他（她）的个人行为，系统记录的日志信息也应该能够真实反应这个人在系统中进行的任何操作。所以强烈建议在项目一开始就规范员工使用系统的规范。所以，一套员工的基本系统管理、登录是后台系统最基本的要求。部门管理的目的在于便于今后在一些数据的展示和查询上做数据权限分层控制。比如订单数据，属于A部门的领导只能看见A部门的数据，不能看见B部门的数据。A部门的员工只能看见属于自己的数据。项目初始就规范部门管理能够让后期的扩展变得容易和简单。
权限\/角色控制：不同对应角色应该有不同的权限，一是有效避免一些关键信息的流出；更重要的是让不同的角色在后台工作的时候更加专注于自己所用的主要功能。比如客服就只需要看见用户、订单等相关信息，不需要去关心商品的配置、促销的配置。
复杂查询列表页的基础SearchModel。几乎所有的管理后台都有很多复杂条件组合起来的查询列表页。
复杂查询列表页的开发有几个麻烦的地方：
查询条件的数量非常多，输入和不输入查询项则对SQL拼写有很大的影响。
要注意前端页面输入项的SQL注入可能。
对于不控件的查询表达式不一样得单独处理，比如有的是用Like，有的是用Equal……
团队在6年前就创建过一套基于.Net EF的页面条件构建工具，两年前我们把这个经验移植到Java环境上，针对Mybatis和Hibernate都构建了一套查询工具。其基本思路是1：
构建一个请求的拦截器，处理和整理浏览器传回服务端的请求中带有复查查询条件标示的参数。
构建一个复杂查询对象SearchModel，可以保存所有的查询域、查询值、表达式符号、and\/or等SQL组装所需要的信息。
将复杂查询对象SearchModel通过ORM框架（Mybatis\/Hibernate）转化为SQL查询条件，并执行查询语句。
在页面处理查询语句返回的结果，将其绑定到页面上的Grid中。
通过构建这套复杂查询机制，后端的列表页如果是对单个资源的查询基本上都能在10-20分钟完成，对多个资源的复合组合查询也仅需要1个多小时的开发时间。这个工具大大提高团队的开发效率，为企业赢取了宝贵的时间。
总结
软件架构发展至今，新技术层出不穷，作为创业公司的软件开发者一方面得实时更新自己的技术和知识，另一方面还是应该结合公司实际业务选择最恰当的技术方案。在此之余，一定要多总结多记录，形成适合自己公司的技术套路，在今后各种场景中融会贯通、灵活使用。保持架构的简洁、灵活是创业公司应该时刻关注的目标。
1. 可以参考我的好朋友邹建先生的博客——《ASP.NET MVC & EF 构建智能查询》 http:\/\/www.cnblogs.com\/chsword\/archive\/2010\/12\/27\/searchmodel_1.html ↩