浅谈创业早期技术实现思路

对于早期的技术而言，不要大而全，不用高精尖，先按需求实现，活下来再说。我们需要考虑的是哪些可以用第三方云服务，哪些可以直接用现成的开源方案或技术，哪些需要自己开发实现。我们可以粗旷一些，要的是快速出活，让产品活下来。

前期那么几杆枪，就技术而行，要用团队成员最熟悉的。要有人能全盘掌控所有的技术栈。虽然我们用的是最熟悉的东西，但是在整个技术选型和开发过程中，需要有以下几个基本的思路：

1. 原则和规范

• 注意解耦，分层，动静分离、轻重分离的原则。

• 开发的规范，代码及代码分支管理规范、发布流程。

• 在开发过程中，对于公共的操作要抽象成组件。即我们常说的职责单一，如缓存操作，数据库操作等等都封装成组件，一边开发一边封装。

2. 保留水平扩展的能力

• 业务服务端无状态，会话通过 memcache 等来管理。

• 数据库设计考虑到一定时间内的容量，做好必要的分库分表，如1到2年的容量规划。

• 热点数据缓存起来，将大量请求打到缓存而不是数据库。

3. 业务隔离

• 隔离关键业务和非关键业务。

• 隔离主业务系统与旁路上报、日志上报等周边系统。如果是 HTTP 服务，至少要在域名级别保证其隔离。

• 不同端业务的隔离。如 PC 侧的业务和 H5 的页面可以是同一套代码，但是域名不同，接入点不同，后端机器相同。

4. 用好开源的轮子

• 在满足现有业务需求的情况下，对业界开源的轮子做技术选型。在能驾驭的前提下尽量使用已有的，成熟的，经过了大量公司实践的开源组件，如nginx，redis，和elk等等。

5. 必要的安全策略

• 安全是互联网应用无法回避的问题，我们需要在框架或基础组件层面引入常见的 XSS 、CSRF、 和 SQL注入等安全问题的过滤。

• 对于静态的能放到CDN的内容尽量放到CDN。这样做的好处：一是就近接入，提高访问速度，二是减少后台的服务压力。

• 保留快速切到云服务防 DDoS 的能力。

• 在业务层面实现一定的规则以及联合 WEB 容器实现一定程度上的防 CC 攻击能力。

6. 备份、备份、备份，重要的事情说三遍

• 宕机、不同城市的机房同时起火、光缆被挖断、数据错乱等等各种神奇的事情都有可能出现。此时备份就显示出其价值。我们不仅仅是要备份业务数据库，还要备份代码，和备份部署脚本等等。

• 当所有的不幸都发生的时候，我们所有的东西都不见的时候，我们能够很快地将应用恢复到上一个可预见的备份版本。即我们必须有灾备方案，最好是能够提前演练过。

7. 监控可能出现的异常

• 使用第三方的监控服务监控网站的访问可用性，服务的可用性等。

• 对业务的数据和关键的节点进行监控，比如做金融的需要确认每个用户的进出钱要对得上账，在这里至少要有一个监控。

8. 灰度发布

前期按机器做灰度发布，一个简单的脚本就可以搞定。后期可以实现按用户灰度等，以此提高业务的连续性，保证业务的可用性。

从 0 到 1，不管是技术还是业务都是不成熟的，大家都是摸着石头过河。因此，我们需要快速的试错，需要快速的反馈。

在技术层面，在保证以上一些原则的同时，快速迭代，实现产品需求。对于一些出错统计类的东西直接交给第三方来实现。在业务层面，如果是网站，一些流量分析直接也是直接交给第三方。比如百度统计，Google Analytics等。对于具体的业务，一个脚本每天早上跑出报表以邮件的形式发到指定邮件组。将相关人加入邮件组列表，以确保相关人等能接收到报表邮件。

以上是最开始需要注意的原则和必须要实现的东西。

在此之外，还有很重要的内容需要持续搭建和实现，包括但不限于以下这些：

1．降级服务能力：在遇到正常或不正常的大流量时，可以在一定范围内将业务降级。业务降级可以前期提供手动降级能力，后续实现自动降级。

2．第三方服务可替换：花钱能解决问题，但花钱一般不能真正的解决问题。因为花钱买来的可能是一个坑，还是一个需要自己填的坑。在使用第三方服务时，需要多家备用可替换，如短信服务，多接两家。平时两家均衡分发，或者按业务分发。当某一家出问题时，直接切到正常的那家。

3．日志中心：日志是定位问题的必备工具。当后台服务有多台机器时，就不能一台一台的用 grep 搜索了，需要有一个集中存储的地方，直接上一个 elk 也许能解决大部分的问题。

创业要的是能存活下来，技术要的是能产生价值。架构会随着业务的发展而不断的演化。然而，在创业早期上面的原则是必须要守住的。