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

创业最开始的时候，是最难的时候，此时，从0到1，从无到有，做的是自己不曾做过的事情，所以，我们称之为创业。

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

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

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 也许能解决大部分的问题；

创业要的是活下来，技术要的是产生价值。 架构会随着业务的发展而不断的演化。

除了眼前的苟且,还有架构与远方。

介绍创业路上的技术选型和架构、大型网站架构、高性能高可用可扩展架构实现，技术管理等相关话题，紧跟业界主流步伐。

数据集合类系统如何架构

以下内容来源于QCon某高可用架构群聊天记录整理

如果携程网想把旅游信息展示到另一平台上 平台和他们的系统数据对接，pull好一些还是post好一些？或者说一个系统只是把好多其他商家的数据集合展示到统一的系统上，这样的系统一般如何架构？

先回答第一个问题：数据对接是pull好一些还是post好一些，这里需要根据实际业务做权衡，如果平台系统很大部分是通过聚合第三方数据再展示，那么比较推荐让第三方post数据，自己设计统一数据规则接口。这种情况，需要考虑自身服务的稳定性了，预防第三方误调用，击垮自身系统。如果只有小部分内容聚合第三方，那就pull，比较好保证自己系统稳定性，不过最终还得把所有的数据转换成自己格式，需要自己开发团队做这块工作。

相比较而言，post时效性高，数据交互少，如果系统会需要各个源的信息，最终也不会只是展示那么简单。如果使用post方案，则需要在接入，数据，读取等方面做隔离，在接入使用mq可以提高吞吐，在读的时候用Cache抗。并且在前期需要考虑好数据存储和数据的量级，因为是第三方的数据，在存储的扩展性方面要有比较好的方案。

最终落地的方案可能是：

按业务隔离，不同的业务相互不影响，拆分子系统；
使用redis和kafka保障高性能，kafka主要一方面用到日志上 一方面用到缓解数据库并发上；
使用nginx和lvs保障高可用；
在后期所有数据进hbase然后用storm做数据流处理和分析

以上这些并不需要一次性做到位，不要过早优化，只需要有一些大的原则，比如隔离，扩展等。小系统会随着业务慢慢演变，最终会变成大系统。在演变的过程中，可能会需要读写分离、业务分布式，分服务，架构就是在这样演变的路上成长起来的。

微信红包实现原理

以下内容来源于QCon某高可用架构群聊天记录整理 背景：有某个朋友咨询微信红包的架构，在官方或非官方同学的解释和讨论中得出以下讨论内容，在此期间有多个同学发红包做现网算法测试。

抢红包过程

当有人在群里发了一个N人的红包，总金额M元，后台大概发生的事情如下：

一、发红包后台操作：

1. 在数据库中增加一条红包记录，存储到CKV，设置过期时间；
2. 在Cache（可能是腾讯内部kv数据库，基于内存，有落地，有内核态网络处理模块，以内核模块形式提供服务））中增加一条记录，存储抢红包的人数N

二、抢红包后台操作：

1. 抢红包分为抢和拆，抢操作在Cache层完成，通过原子减操作进行红包数递减，到0就说明抢光了，最终实际进入后台拆操作的量不大，通过操作的分离将无效请求直接挡在Cache层外面。这里的原子减操作并不是真正意义上的原子减操作，是其Cache层提供的CAS，通过比较版本号不断尝试，存在一定程度上的冲突，冲突的用户会放行，让其进入下一步拆的操作，这也解释了为啥有用户抢到了拆开发现领完了的情况。
2. 拆红包在数据库完成，通过数据库的事务操作累加已经领取的个数和金额，插入一条领取流水，入账为异步操作，这也解释了为啥在春节期间红包领取后在余额中看不到。拆的时候会实时计算金额，其金额为1分到剩余平均值2倍之间随机数，一个总金额为M元的红包，最大的红包为 M * 2 /N（且不会超过M），当拆了红包后会更新剩余金额和个数。财付通按20万笔每秒入账准备，实际只到8万每秒。

FAQ

1. 既然在抢的时候有原子减了就不应该出现抢到了拆开没有的情况？
   这里的原子减并不是真正意义上的原子操作，是Cache层提供的CAS，通过比较版本号不断尝试。
2. cache和db挂了怎么办？
   主备 +对账
3. 有没有红包个数没了，但余额还有情况？
   没有，程序最后会有一个take all操作以及一个异步对账保障。
4. 为什么要分离抢和拆？
   总思路是设置多层过滤网，层层筛选，层层减少流量和压力。这个设计最初是因为抢操作是业务层，拆是入账操作，一个操作太重了，而且中断率高。 从接口层面看，第一个接口纯缓存操作，搞压能力强，一个简单查询Cache挡住了绝大部分用户，做了第一道筛选，所以大部分人会看到已经抢完了的提示。
5. 抢到红包后再发红包或者提现，这里有什么策略吗？
   大额优先入账策略
6. 有没有从数据上证明每个红包的概率是不是均等？
   不是绝对均等，就是一个简单的拍脑袋算法。
7. 拍脑袋算法，会不会出现两个最佳？
   会出现金额一样的，但是手气最佳只有一个，先抢到的那个最佳。
8. 发红包人的钱会不会冻结？
   是直接实时扣掉，不是冻结。
9. 采用实时算出金额是出于什么考虑？
   实时效率更高，预算才效率低下。预算还要占额外存储。因为红包只占一条记录而且有效期就几天，所以不需要多大空间。就算压力大时，水平扩展机器是。