根据业务场景，将业务抽离成独立模块，对外通过接口提供服务，减少系统复杂度和耦合度，实现可复用，易维护，易拓展
项目中实践例子：
Before：
在返还购APP里有个【我的红包】的功能，用户的红包数据来自多个业务，如：邀请新用户注册领取100元红包，大促活动双倍红包，等各种活动红包，多个活动业务都实现了一套不同规则的红包领取和红包奖励发放的机制，导致红包不可管理，不能复用，难维护难拓展
After：
设计概要
Before VS After
产品有时提出的业务需求没有往这方面去考虑，结合场景和未来拓展需要，在需求讨论的时候提出模块化设计方案，并可以协助产品进行设计
在项目开发中经常会遇到些类似的功能，但是不同的开发人员都各自实现，或者因为不能复用又重新开发一个，导致了类似功能的重复开发，所以我们需要对能够抽离独立服务的功能进行抽离，达到复用的效果，并且可以不断拓展完善，节约了后续开发成本，提高开发效率，易于维护和拓展
项目中实践例子：
Before
在业务中经常需要对用户进行信息通知，如：短信定时通知，APP消息推送，微信通知，等
开发人员在接到需求中有通知功能的时候没有考虑后续拓展，就接入第三方信息通知平台，然后简单封装个信息通知方法，后续也有类似信息通知需求的时候，另一个开发人员发现当前这个通知方法无法满足自己的需求，然后又自己去了解第三方平台重新封装了通知方法，或者后续需求加了定时通知的功能，开发人员针对业务去实现了个定时通知功能，但是只能自己业务上使用，其他业务无法接入，没有人去做这块功能的抽离，久而久之就演变成功能重复开发，且不易于维护和拓展
After
接触到这种可以抽离通用服务需求的时候，就会与产品确认这种需求是否后续会存在类似的需要，然后建议这把块需求抽离成通用服务，方便后续维护和拓展
设计概要
Before VS After
项目开发过程中有些需求是与所在项目业务无关，如：收集用户行为习惯，收集商品曝光点击，数据收集提供给BI进行统计报表输出，公用拉新促活业务（柚子街和返还公用），类似这种需求，我们结合应用场景，考虑服务的独立性，以及未来的拓展需要，架构独立项目进行维护，在服务器上独立分布式部署不影响现有主业务服务器资源
项目中实践例子：
架构用户行为跟踪独立服务，在开发前预估了下这个服务的请求量，并会有相对大量的并发请求
架构方案：
用户行为跟踪服务的服务架构图
高并发除了需要对服务器进行垂直扩展和水平扩展之外，作为后端开发可以通过高并发优化，保证业务在高并发的时候能够稳定的运行，避免业务停滞带来的损失，给用户带来不好的体验
服务端缓存架构图
异步编程
业务异步处理
【业务异步处理】架构图
【业务异步处理】除了可以在高并发业务中使用，在上面通用服务的设计里也是用这种架构方式
在类秒杀的活动中通过限制请求量，可以避免超卖，超领等问题
高并发的活动业务，通过前端控流，分散请求，减少并发量
当服务器资源消耗已经达到一定的级别的时候，为了保证核心业务正常运行，需要丢卒保车，弃车保帅，服务降级是最后的手段，避免服务器宕机导致业务停滞带来的损失，以及给用户带来不好的体验
高并发优化概要图
大多数公司的产品设计和程序猿对于推广活动业务的防刷意识不强，在活动业务设计和开发的过程中没有把防刷的功能加入业务中，给那些喜欢刷活动的人创造了很多的空子
等到你发现自己被刷的时候，已经产生了不小的损失，少则几百几千，多则几万
随着利益的诱惑，现在已经浮现了一个新的职业“刷客”，专业刷互联网活动为生，养了N台手机+N个手机号码+N个微信账号，刷到的奖励金进行提现，刷到活动商品进行低价转手处理，开辟了一条新的灰色产业链
我们要拿起武器(代码)进行自我的防御，风控，加高门槛，通过校验和限制减少风险发生的各种可能性，减少风险发生时造成的损失
这里列出常用套路（具体应用结合业务场景）：
校验请求合法性
业务风控
应对角色
防刷/防羊毛党套路概要图
附加
多操作
当==同用户==多次触发点击，或者通过模拟并发请求，就会出现多操作的问题，比如：签到功能，一天只能签到一次，可以获得1积分，但是并发的情况下会出现用户可以获得多积分的问题
简化签到逻辑一般是这样的：
查询是否有签到记录 --> 否 --> 添加今日签到记录 --> 累加用户积分 --> 签到成功
查询是否有签到记录 --> 是 --> 今日已经签到过
假设这个时候用户A并发两个签到请求，这时会同时进入到 【查询是否有签到记录】，然后同时返回否，就会添加两条的签到记录，并且多累加积分
最理想简单的方案，只需要在签到记录表添加【签到日期】+【用户ID】的组合唯一索引，当并发的时候只有会一条可以添加成功，其他添加操作会因为唯一约束而失败
库存负数
当==多用户==并发点击参与活动，如：抽奖活动，这个时候奖品只有一个库存了，理论上只有一个用户可以获得，但是并发的时候往往会出现他们都成功获得奖品，导致奖品多支出，加大了活动成本
有问题的逻辑流程一般是这样的：
中奖 --> 查询奖品库存 --> 有 --> 更新奖品库存 --> 添加中奖纪录 --> 告知中奖
中奖 --> 查询奖品库存 --> 无 --> 告知无中奖
假设抽奖活动，当前奖品A只有最后一个库存，然后用户A、B、C，同时参与活动同时中奖奖品都是A，这个时候查询商品库存是存在1个，就会进行更新库存，添加中奖纪录，然后就同时中奖了
最理想根本就不需要用多做一个库存的SELECT奖品库存操作，只需要UPDATE 奖品库存-1 WHERE 奖品库存>=1，UPDATE成功后就说明是有库存的，然后再做后续操作，并发的时候只会有一个用户UPDATE成功
总结：
在开发业务接口的时候需要把==同用户==和==多用户==并发的场景考虑进去，这样就可以避免在并发的时候产生数据异常问题，导致成本多支出
可以使用下面的工具进行模拟并发测试：
普遍方案
使用selenium+Headless自动化测试框架
反反爬虫
在做数据采集的过程中，有些平台会对重要数据的请求设置反爬虫策略，避免数据被竞品挖掘和利用，以及消耗大量资源拖垮服务器，
反爬虫和反反爬虫是技术之间的较量，这场没有硝烟的战争永不停息。（程序员何必为难程序员）
反爬虫可以分为以下两种
作为后端开发者，不仅是完成需求功能开发，要结合业务场景进行合理设计，架构未来，对核心业务进行压测优化，以保证业务在并发下能够正常运行，同时要考虑安全问题以及防刷，防羊毛党，在编码上避免坏代码味道，面相抽象开发，适当使用设计模式，避免技术债
开发应该铭记于心的精句：
原文地址：http://blog.51cto.com/sflyq/2120345
