背景

精准营销从被提出到广泛运用，伴随着互联网技术飞速发展，尤其是大数据和人工智能技术的日趋成熟。精准营销也成为每一家互联网企业必然绕不开的课题，围绕它展开的业务不胜枚举。通常营销过程包含如下三部分：
① 营销活动前：确定营销的目标，
② 营销活动中：效果监控和跟踪，
③ 营销活动后：效果评估和优化。
本文主要分享笔者在精准营销工程化方面做的一些尝试和实践，侧重点在营销目标的确定。

现状

营销目标就是我们传统意义的圈人，筛选出一批跟营销计划匹配的人。最初圈人逻辑是通过标签圈人，后续又加入了算法圈人，这两种模式的数据核心都基于离线数仓，按天更新。这两种方式在初期能够满足业务需求，但是随着业务发展及精细化运营的需求，该模式短板越来越明显，例如转化率的提升越来越难、实时性不高、灵活度不够等。希望有一套既能兼容现有离线链路，同时又能引入实时特征的方案。

挑战

离线链路侧，每个签约品牌每天会基于MaxCompute，通过协同过滤的方式从经济体的数亿用户中召回和品牌群像具有相似度的人，粗召回人数大品牌数亿中小品牌数千万。通过粗召回的数据量乘以签约品牌数，就可以很轻易的预估出离线召回的数据量在百亿级别，并且随着签约品牌的新增该数据量还会增加。实时链路侧，用户的实时特征，例如交易特征、LBS特征、商品加购特征、店铺点击特征等，每天特征总量也维持在几十亿级别，并且特征会随着业务的发展越来越多。
面对如此庞大的数据量，每条数据多耗时一毫秒，那么在百亿量级下就会放大到数千小时；一条数据多1bit，百亿就会放大到1G。所以特征数据如何传递、处理、存储都需要精心设计，否则带来的不但是程序性能上的急剧下降，而且还会导致计算和存储成本的飞速飙升，这便是我们在整个系统建设过程中遇到最大挑战。

背景

最近工作中大量使用到Elasticsearch，需要通过Bulk操作将大量数据推到Elasticsearch中，但是发现有个别推数据的分布式任务一直不能结束，通过Thread Dump发现SchedulerX-ConsumerThread处于休眠状态，Thread Dump信息见下图：

最近利用业余时间写了一个简单的分布式对象存储yfs，分布式一致性构建在atomix之上。atomix实现了raft，并且提供了更高层次的抽象，例如Map、Set、DistributedLock等。为了详细的阐述遇到问题的来龙去脉，有必要简单阐述下yfs的架构，架构图如下：

上下文

假如我们项目中引入的三方包出现了一个小的bug，我们通常会fixed它，然后创建一个pull request，但是通常我们等不到pull request被merge之后的release版本。
这种现象非常普遍，对于这种情况，我们通过有如下三种方案：

1. 使用merge了pull request的snapshot版本。
2. 自己fork一个分支，发布内部版本。
3. Class Overriding，重写之后的代码就放到自己的项目中。

方案一会引入了很多不稳定的因素到项目之中，方案二自己维护一个临时的稳定分支成本太高，所以它们都不是非常好的方案。方案三则避免了前两种方案的不足，并且等官方release版本发布之后，可以零成本的切换到官方版本。

问题

Class Overriding之后，在Classpath中会存在两个同名的该类，一个是位于自己项目中另一个是三方库中的原有的。那么问题就来，Classloader究竟会加载谁呢？
Classloader Hierarchy大家都比较熟悉，网上也有大量的文章来阐述。我们不但要清楚parent delegation model，而且需要明白相同的Class被不同的Classloader加载，在JVM中它们也是不同的Class。显然此处这并不是我们想要分析的重点，除非我们bug刚好出现在Custemclassloader，也就是说我们要分析的是同一个Classloader对Classpath下名称相同但位置不同的Class资源的加载顺序。

API Gateway/Backend for Front-End作为一种目前非常流行并且经过验证的Pattern，不论是在Netflix/Amazon还是BAT都得到了广泛的应用。在Microservice architecture pattern大行其道的当下，API Gateway的建设显得尤为重要，本文主要是分享笔者在API Gateway研发中的一些心得体会，同时这篇文章也发布在了公众号聊聊架构，可以移步此处查看讨论。

Context

为了阐述API Gateway建设带来的收益是值得我们投入大成本来研发的，我们假设需要建设一个online store。为了支撑整个电子商务逻辑的运转，可以简单抽象成如下的微服务：

1. shopping cart
2. shipping
3. inventory
4. recommendation
5. order
6. review
7. product catalog

架构如下图所示：

笔者之前为了研究HttpProxy，自己用Java造了一个轮子WAF，随着研究的深入，该项目也逐步成为公司的API Gateway之一，在研发过程中收获很多。

HTTP协议

既然初衷是HttpProxy，那么HTTP(RFC7230-7235/7216)协议是必然需要了解，这是每个开发人员都或多或少了解的协议。我之前自认为对HTTP还是有足够的了解的，但是经过此次实际运用才发现还有很多细节理解的不够。

1. Header头不区分大小写，而我之前所有的获取header都是一律大写，导致在不同的浏览器表现不一致，有些头拿不到。
2. Http Method了解不够，我们跨域方案采用的是CORS，所以会有OPTIONS请求去询问后端是否支持跨域。用户登录成功之后会返回一个Token，后续的访问都需要在HEAD中带上该标识，由于发起OPTIONS请求是浏览器的自带行为不是XHR请求，所以没有Token。Gateway对所有的请求都会进行拦截，自然这个OPTIONS就不幸命中，解决方法就是本地Cookie也写一份或者OPTIONS请求直接放行。
3. X-Forwarded-For，X-Real-IP使用场景和限制没有充分弄清楚。

最近一直在研究应用安全相关的技术和产品，因为随着产品不断推广放量，安全体系的建设已经刻不容缓。谈到应用安全大家想到最多就是各种商业级的WAF防火墙，但是这个不是我想谈的重点，这次我们主要谈谈软件WAF。说到软件WAF，大家最熟悉的就是ModSecurity、esapi-java-legacy、lua-resty-waf、ngx_lua_waf等众多解决方案。虽然笔者所在公司使用了以上方案中的一种，但是为了研究和学习，笔者用Java重新造了一个轮子，本篇文章主要是阐述笔者设计和研发的思路，供大家参考。项目地址为：https://github.com/chengdedeng/waf。

这篇文章最早发布在聊聊架构微信公众号，结果引发了大家的众多评论，有对红星所做事情的疑惑也有对技术合理性的质疑。不论哪种情况，很高兴抛出了一个让大家还有兴趣聊两句的话题，还是那句话不求共鸣，只求博君一笑，不论是嘲笑还是微笑！

互联网和移动互联网的飞速崛起，对传统行业造成了破坏性的冲击和几乎窒息的压迫，迫使他们必须做出改变和应对。在这个都想拿到船票的时刻，技术的重要性已经可以媲美商业模式，因为再好的商业模式都离不开技术来落地，所以谁的技术领先，谁就有可能最快抵达终点。但是众所周知，传统行业的IT部都是支撑部门，在信息化建设的研发能力上是先天不足的。红星美凯龙是一家超过30年的老牌传统企业，虽然过去几年在信息化的建设和互联网的探索上投入了大量的资本，但是在技术方面的积淀收效甚微。随着红星的港股上市，再次开启互联网战略，成立红星悦家互联网集团，我们在吸收了过去经验教训的基础上，重新架构红星的技术体系。

随着SOA、微服务等诸多概念的炒作，再加上Dubbo、Spring Cloud、Netflix OSS等诸多开源软件的支撑，要构建一套大型的分布式系统的技术门槛已经变得非常之低。但是这并不意味着构建一套大型分布式系统就是很容易的，因为任何系统都是领域知识的体现。所以笔者将这些年系统研发过程中的一点感悟记录下来，仅供参考。

统一内部通用语言

Question:

1. SPU=SKU

   1 2	A:把类目X下的SPU给我。 B:把类目X下的SKU给了A。

2. ID=CODE

   1 2	A:我给你商场ID，你给我商场信息。 B:A给我商场CODE，我用商场CODE去查询。

为了解决这个问题，所有的团队成员都应该意识到需要创建一种通用的语言，并且时常提醒大家对基本的内容保持专注，在任何需要的时候都使用这种语言。我们应该尽量少地在这些场合使用我们自己的行话，应该使用通用语言，因为它能帮助我们更清晰、更精确地交流。

受MSUP TOP100组委会的邀请，12月12号在国际会议中心分享了《传统互联网转型的架构之道》，会后也和一些业界的朋友做了更深层的探讨，收货很多。下面是我分享内容的PPT，供感兴趣的朋友参考。由于图片经过压缩之后不是很清晰，如果阅读清晰版，可以下载PDF查看。