SERVICEWALL是“疫苗”公司？NO

Servicewall是家什么公司？ 公司成立于2018年5月，并获得了由北极光等著名VC联合投资，公司创始团队由来自美国 Netscreen、American Express 等知名企业的专家组成。Servicewall结合设备指纹，数据加密，大数据，人工智能等技术致力于为中国客户提供专业化的在线反欺诈服务。 解决什么问题？ 从需求角度就是解决这个决策树上的问题，把业务风险识别出来，并提供有效的消除方案。 如何解决？ 方法，工程，和我个人对系统的理解。 方法： 通过有效的设备探针检测用户终端环境，收集非敏感信息，如硬件属性。 利用数据分析，机器学习等技术将人与机器的特征区分开。并在特定业务领域下，分析用户的行为，识别潜在风险。 提供串联，旁路等软硬件方案，实时解决业务过程中的风险 灵活的组合和接入方案，满足业务场景的变化和客户的私有化定制需求。 工程： 想解决好这些问题，在工程上其实有很多的挑战 设备探针如何加密不被破解？ 大数据平台Hadoop / Spark实时性低，如何实时获得结果？ SaaS服务与私有化服务器架构如何保持一致？ 无网络环境如何快速无依赖部署？ 私有化环境数据平台如何无人值守运维？ 如何平衡分析结果的准确率与召回率？ … 等等，虽然是新领域，但所有的问题都不是独特的，我们拥抱新技术，勇于探索，大胆尝试，创造黑科技。 至少有以下特色： 云原生，微服务：真Docker全容器化，包括基础设施组件，甚至数据平台。 Java / Golang技术栈：兼顾开发效率，稳定，性能的新老搭配。 节制的数据平台：追求数据的性价比，不浪费。Spark / Clickhouse。 基于事实的分析理念：不假设，简单有效。“如无必要，勿增实体”(Occam’s Razor)。 我的理解 系统中有一个“防火墙” 和“分析平台”，或者说是一个“数据平面”和一个“控制平面”。 数据平面可以串行部署在用户业务线上，所以要稳定可靠，性能高，功能不能太复杂，是系统的“肌肉”。 控制平面有智能，配置灵活，是系统的“大脑”，与数据平面不强耦合，可以独立升级规则，版本。 两个平面形成一个完整的反馈系统，通过强大的“神经”(控制通道/RPC)和“血管”(数据通道/MQ)链接。 而数据则是打通系统的“养料”，数据分析系统都是长出来的，没有真正遇到过“病毒”怎么可能产生健康的“免疫机能”呢？ 仅用假设是做不好安全，问题总是出现在未知的地方。这里我们在这个方向上积累了2年多，用很多事实问题的抽象了不少模型，算是“疫苗”研制初见成果吧。 有了有效的“疫苗”可以迅速解决客户问题，当然在业务安全方向，“病毒”也随着技术的进步，进步很快，对抗“病毒”升级是业务安全的常态。 所以我们不仅仅是“疫苗”的搬运工，而是给用户提供一套完整的注入已知有效“疫苗”的智能“免疫”系统。 广告时间 目前Servicewall已经在“疫苗”量产的路上，客户数量也在稳步提升，为了更好的支撑客户和改良系统，我们需要更多的伙伴加入。 后端开发工程师 负责产品功能、后端服务接口的设计与实现。 具备 3 年以上服务端开发经验，具备扎实的计算机专业基本功； 精通 Java / Golang，擅长分布式系统设计与开发，熟悉函数式编程，对 JVM 原理有一定的了解； 掌握常见的缓存、消息等机制，熟悉 IO/NIO、多线程、集合等基础框架； 熟悉 Spring Boot、Kafka、Redis、MySQL 等开源服务框架或组件； 熟悉 Docker，熟练使用 Shell、Lua、Python 等一种脚本语言； 熟悉单元测试、功能测试、性能测试；

关于规则引擎的思考(3)

做一个安全风控的引擎，用规则配置，需要能够自反馈。所以也不是一个简单的规则引擎。 也就是实时引擎 + 离线引擎两个部分。或者说是 数据平面 + 控制平面也行。 实时引擎在业务流量上处理，离线引擎给实时引擎提供弹药。 实时引擎： 逻辑匹配70%：if else 有状态的计算30%：虽然比重小，但实现麻烦。 state管理的流式数据计算。原理参考Spark，Flink，但又不是通用系统。不能用Spark，Flink是需要同步做决策，Spark，Flink显然不合适。 https://spark.apache.org/docs/1.6.2/api/java/org/apache/spark/streaming/State.html 有需求边界夹持，可以做的更快，更小。 举个例子：状态防火墙中的session table，以IP五元祖为key，其中一种状态是tcp状态。 我们使用数据流式处理如何实现呢 key: ip 5-tuple state: 就是tcp状态顺序，在一定生命周期下统计，有明确开始(create)，和退出时机(remove)。 def sequnceFunction(ip, tcp_action, state) := { if (state.exists) { if (tcp_ack == FIN_ACK) { state.remove() } else { state.update(transState(tcp_action)); } } else { state.update(initStatinitState(tcp_action)); } 这个例子的状态比较具体，如果抽象一些，这个状态大概分为这些 https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/state/state.html 状态 场景 需求 ValueState 单值统计 需要 ListState 序列统计 需要 ReducingState 单值 不是简单累加，比如求唯一数量，可以用近似算法HyperHyperLog，这样就变成单值 AggregatingState 复杂统计 Reducing 和 ListState更复杂的表达，目前不需要 MapState 二维矩阵 目前不需要，场景上可以用预测接口PMML替代 实时引擎要有嵌入机器学习模型的能力，使用PMML。

关于规则引擎的思考(2)

规则 & 引擎 规则引擎字面隐含的需求： 规则：简单人能读懂的条件 引擎：快速执行规则背后的机器指令 所以人们想用简单的表达来指导复杂的工作，这种化繁为简的银弹是真实需求。 但规则到指令不是等量的，所以一定有细节的损失，也就是规则不能表达的逻辑。 UI —- 配置 —- DSL — * — 脚本 —- 静态语言 —— 汇编/机器指令 所以规则引擎的过程是一个语义表达从简单到复杂的过程。 中间有一个人到机器的分界。（程序员是人，也是机器） 回到之前举的例子，我也正好比较熟悉。 ACL或eBPF：保过滤规则引擎 配置层面（人读）： router#show access-list Extended IP access list test permit ip host 2.2.2.2 host 3.3.3.3 permit tcp host 1.1.1.1 host 5.5.5.5 eq www permit icmp any any permit udp host 6.6.6.6 10.10.10.0 0.0.0.255 eq domain host 192.168.0.1 and not host 10.1.1.1 and (port 138 or port 139 or port 445) UI界面，配置文件，DSL都认为是人读的。

关于规则引擎的思考(1)

规则引擎是什么？ 先看一类文章，为什么要用规则引擎 https://www.cnblogs.com/rjzheng/p/10996186.html https://www.jianshu.com/p/9b67ab434795 先看一类文章，为什么不需要规则引擎 https://www.yinwang.org/blog-cn/2017/05/25/dsl https://www.jianshu.com/p/d136a76e1c0d 第一类的文章使用规则引擎相当于把 if else 数据化，复杂程度没有降低，只是转移了，为了规则引擎而规则引擎。 由静态语言转向数据，可以热加载热更新，这才是真正的需求。 而第二类文章所说复杂规则引擎，必然引入DSL，相当于一个冷门的语言，不但复杂度没降低，熟悉它的成本反而升高，得不偿失。仅为了热加载或解耦不如用脚本。 规则引擎的功能是什么？ 假设一下： 如果没有需求的限制，需要灵活的功能大而全的规则引擎，那么最后这个规则引擎就会变成Drools，甚至脚本语言。 一种靠解析器执行的以决策树为主的东西。如果说因为Hard Code复杂，换成Drools的话，非程序员也无法使用Drools，所以规则引擎可以降低逻辑复杂度是一个悖论。 那么，通常情况下，我们只需要一个脚本语言，Lua或者Python，这个语言可以完成热加载，有逻辑表达即可。 再进一步说一下语言表达和规则表达的区别，规则主要是匹配逻辑，if else，即语言中的 “逻辑”（控制） 部分，程序语言中还有 “累加”（计算），“变量” （数据），看看是不是用得到。 考虑完以上问题后：几个著名规则引擎 or DSL。 ACL只用于包过滤：输入是网络包文，输出是一个动作 SQL只用于数据操作和分析：输入是表达式，输出表达式结果 eBPF: 算是引擎，DSL都算不上，汇编代码啊。 TOML/YAML：连规则都算不上，DSL配置吧。 我们回到在特定问题域，特定需求范围下探讨规则引擎 / DSL / 配置文件来驱动逻辑。 规则引擎 is Nothing 所以“规则引擎”没有狭义的概念和实现，还是需要从需求考虑： 是注重人机交互，提供交互UI，降低用户使用难度？ 还是为了数据驱动逻辑，分离数据与执行？ 还是为了热更新，热加载？ 还是只想碰“词” 结论：“规则引擎”是抽象的功能需求，并不是一个具体的技术方案，更不是指导开发实现的特定方法。

HUGO 分割线

Hugo <- Hexo3 <- Hexo2 <- WordPress <- Micolog GAE

简易BITCOIN自动交易框架 - XIAOSHAOZI

这个简单的程序是我去年初写的，那时Bitcoin刚开始流行，Golang也刚刚开始流行。一方面为了学习一下量化交易是否真的可以赚钱，另外也练习一下用Golang写点能运行的东西。 那为什么现在拿出来？这周五去车库咖啡参加了一个量化交易平台Startup举办的讲座，当然是半广告性质的。创始人最初的想法也是来自于Bitcoin，当然做的东西嘛，我也没觉得太好(当然至少比我的强)。另外最近Bitcoin涨势也不错，估计也有人感兴趣。当然还有就是去年因为硬盘意外，这些没来得及保存的代码今天才从我的生产机上弄下来，也不是最新版本了。 如果想运行成功，适配如今最新的交易所的API，还需要改一改，吸收教训，我先传到GitHub上。欢迎大家修改并提意见，当然代码写的很糟糕，想骂请先request commit。 项目的介绍: http://www.donge.org/project/ GitHub: https://github.com/donge/xiaoshaozi

恢复了博客

自从去年因为安装黑苹果导致全硬盘格式化，整个人都不好了。很久没coding，也没有写博客。 因为很多数据没有了，也恢复不了，一度放弃。最近鼓起勇气用html2markdown恢复了所有的文章，也趁机更新到Hexo 3.0。 这段时间发生的很多事情也没有记录下来，希望再次开始能继续过去的热情，不断提升，加油。

程序员复仇记

故事开始前，先声明一下，此文不是技术文，前端猿勿鄙视之。 故事是这样开始的… 一. 激怒 今天无聊得刷着朋友圈，发现好多人在玩【打企鹅】这个弱智游戏。虽然东哥从来都是摆出鄙视一切低弱智游戏的姿态，但也忍不住好奇不住去捅了一把。 “哈哈，19604.8米，我果然是个神~~”，立马分享给朋友们，以炫耀东哥那出众的能力。 …10秒钟后…“美慧: 没看见我尾灯[偷笑]”。(美慧是朋友的媳妇，非IT工作者，微信串子，爱晒家里可爱的宝宝照。) “我擦！！！”，怎么可能，去瞅了一眼。她…27731.9米…刚刚分享的，和我的消息紧紧挨着。造物弄人啊…真是颜面全失，还咋在朋友圈里混啊。于是一向不服输的我断定，“我们玩的不是相同的版本”。为了寻回尊严，我进了她分享的链接，不停得挥舞着残害小动物的大棒…一次又一次… 好吧，必须承认，事实又再一次证明了程序员虽然有高智商，但无法在低智商游戏中胜出，那多余的智力是白白浪费了。为了挽回程序员的颜面，和正要出门赶飞机的媳妇放出大话，“我自己搞一个版本，看谁还能超了我”。 勺子媳妇立刻对东哥抛来了崇拜的小眼神，“这几天你可有事情做的”，于是我飘飘然到，“用不了几天，你下飞机前就搞定”。 二. 怂了 媳妇出门后，回复了朋友圈，这次她去的可不是新疆，是广州，三个小时的距离，再加上候机也不到5小时，虽然没有正面打击我，但估计也不相信我的大话。 再想想东哥那可怜的前端知识，突然有了一种秋风从脑后吹过的悲凉情景…硬着头皮来吧… 首先第一步先找到大家分析链接的地址，[复制URL]，然后在电脑上打开。还好，不出所料，都是静态的页面，HTML5和Javascript做的，乱糟糟的。 第二步就是想到如何改这个游戏，重要的是找到这个游戏的主要逻辑在哪里，于是就一个JS一个JS的翻，有些像jquery，各种库可以一眼看出来是和游戏逻辑无关的。还好这个页面的JS引用的不多，很快找到最重要的线索，flyline.js。 Main.flyLine = <span class="keyword">function</span>(angle){ <span class="keyword">var</span> speedRate = <span class="number">7</span>;<span class="comment">//速度倍率</span> <span class="keyword">var</span> gRate = <span class="number">100</span>;<span class="comment">//重力倍率</span> <span class="keyword">var</span> flyBird; 哈哈，真相只有一个，开启Chrome的调试器，走你…29557米… 第三步是把这个页面扒下来，对于山寨成性的东哥来说，这活不陌生，但烦恼的是不论是用Chrome，Safari还是狗屁IE，直接保存全部的页面资源都无法直接再打开这个页面。 如果用Safari的WebArchive或者IE的mht格式，是可以打开的，但这种格式又无法编辑。于是去Google了各种能把WebArchive还原成页面和资源的工具和方法，一一尝试过都失败了。 这样一度让我陷入沮丧，此时1个小时过去了… 于是我只能分享了一个朋友圈，在认怂的同时，也要挽回一点点小面子… 三. 坚持 有时候，看起来距离最短的路不一定能最快到目的地，路上总有意外发生。 镇定下来后，我想干脆从头来过，先保存纯页面，用绝对路径将页面在本地打开。 当然，又失败了，页面出现FILE_LOAD_ERROR的提示，打开调试器发现，是页面用了一个叫CreateJs的库，用来预加载游戏图片资源，而游戏图片在JS文件中用了相对路径。由于引用数量很多，这里我没有一一修改，是将图片资源下载到本地，用http server来启动页面，保证相对路径。 Bingo，页面可以打开了。 最后一步就是上传到我的服务器，我没有国内的服务器，所以资源最好用绝对路径链接到国内的原网站，说不定还有CDN加速的效果。所以我就只本地化了flyline.js和必要的图片资源，将企鹅飞行的速度参数改为了10，其余保持不变。 最后经过一些测试，调试，修改，它已经可以完美工作了。 四. 后记 “piu…46132.4米，哼哼，愚蠢的人类，啊哈哈…啊哈哈…”，正在得意这次完美的复仇时。美慧已经用我的【复仇版】分享了46917.1米…好吧，我表示再次怂了。不过她表示…“程序员…真可怕…”，这让东哥没有再次丢脸。 时间过了两个小时，媳妇刚刚登机，得知我完成了自己吹的流比，向我发来了亲切而友好的慰问…我表示要继续努力，不辜负祖国的培养。 程序员是一群不错的家伙，当他们被激怒时会释放出强大的力量，虽然这个小复仇非常容易，但它还远远没有结束… 我突然有了一种想法，需要量化一下它的能量，于是将两个好友的微信公众号作为广告登了上去，并做了申请了页面流量统计。 不得不承认最近从【神经猫】，【测试你有多色】到【打企鹅】，这种在微信上的简单游戏，通过晾晒成绩到朋友圈来激发的攀比心态，已经形成了一种病毒式的营销模式。每款游戏的定位简单，声明短暂，但一波波得也形成了巨大的影响力。 虽然这里我不鼓励山寨，但这也许是一个好想法的开始。 (END) 打企鹅 - 勺子复仇版，请用微信扫一扫，或者点击 这里 关注T神的微信公众帐号【程序人生】。 PS: 如有版权问题，请与donge @ donge.org联系，谢谢。

周年记

两个多月没码字了，在写作这个事情上，我算得上是个懒人。或者是没有灵感的人，感觉灵感是一种冲动，我每每想写点什么的时候，都是看到了或想到了不好的东西。嘴里骂不出来，想给丫写上一笔，说白了还是愤青型，对事的，对人的。但等我有时间写的时候，想想这样多不好，胸襟狭小，不符合我的气质，还是算了吧。不过我回看我的微博评论，感觉也还不那么阳光。 不过估计人的个性如此，也许很难改了（又找借口了）。这周是我在J工作一年整的日子，我想说说这一年的变化，为自己总结，也为宣泄一点情感。 老东家的变化 为什么离开华为，我之前也说过了，其实每个公司都有自己的好，也有自己的坏。当你的三观与公司的文化差异太大时，自认也就离开了，说小点就是个人气质和部门气氛不合。 部门的HR在我离开一年的时候给我打了个电话，希望我能客观得再反应一下自己对部门的看法，其实这也多余，糊弄了两句大道理，因为我也知道他们是在完成任务，而不是真正要干些什么。也许就是这样的事情看得太多了，所以热情也消退了。最近和过去的同事聊到，得知部门也发生了一些变化，走了一些人，多是骨干，老员工。原因其实也很简单，没有精力每天十二小时地，为那些做做而已的事情而加班了。 新公司的变化 当初选择外企，就自己告诫了自己“一入外企深似海，从此奋斗是路人”。如果自己没有方向和目标，很可能就在这样的地方浑浑噩噩地厮混下去了。因为种种原因，大部分的外企中国机构都有一些政治原因而设立的，所以也难有自己的话语权。经过一年的时间，我看到了踌躇满志开疆扩土的大老板被保守派挤走，一些文化，语言，时间的差异也影响着做事的效率和主动性。随着一波调整和裁员，士气也不如往昔。 如果说华为是给你一个远大的目标，但实际骗你做一些无聊的事。那J就是看不到远大的目标，但做的事还算踏实。 我的变化 好像气氛又被我写得沉重了，其实我是想把好的事情都写到我身上，让我看起来更加闪亮：） 老朋友： 和朋友厮混的时间变多了，过去的同事，同学，朋友，没事吃吃喝喝，聊聊八卦，无脑得开心。小白的儿子淡定得和他爹一样，从此你的爱好又多一项；PYM和猪终于修成正果，日子过得那是相当舍得；亮亮媳妇做的饭，蹭了好几顿，我媳妇说一定要谢她；还有留守部门的XXX(隐去你们姓名)，一起抱怨着部门里的奇葩也是一种快乐；还有远在大连的靠谱的小伙伴们，不定期得串联。 新同事： 克里夫是个幽默实干的经理，没有一点架子，是我认同的类型，对我也很赏识；程序君T神，用一句话评价的话，是个让你觉得每月薪水少2000元也值得共事的人（以后单独点评）；Ben和Yafang都是专业领域的强人，并伴着文艺气息的同类屌丝青年；伶俐的Lily总是在与各种各样的bug和ce周旋；老练的Tony给我们讲着各式过去的八卦；剑，锋利而温和的一位优秀的女性工程师；善谈的Hao，稳重的Dan，平易的Sunyong，热爱旅游的Leo，深藏不露的Bean…..各式能人不能逐举了，还有很多很多各式才能和奇葩爱好的人，让我觉得有些小惊艳。 新爱好： 有了更多假期，旅游成为了可能，这是即能放松又能增长见识的收费活动，乐此不疲，只叹荷包不鼓；Bitcoin，虽然最近赔得腰斩，但也是见证我投资成熟的一个里程碑，我也是能承受50%损失的人；动，比起过去，锻炼时间增多了，身体状态也好了些了，我决定以后和小伙伴们少搞一些吃吃喝喝活动，多搞一些体育运动；在T神影响下，学习了一些互联网的东西，偶尔捣鼓几个自己的小程序；看书和写作，算了，真不好意思写出来，但对比过长年文盲的我，也算进步了。 总得来说，好的变化多于坏的变化，我很满意。其实最大的变化也就是一点是，自己的时间多了，自己的时间多了就有更多可能。更多的可能就有更多的变化。 追逐改变的好奇心，我想，就是一种，理想吧。 P.S.自己又读了一遍，相当不通顺，没写多少，错别字多，病句多，及格无望了…

量化交易初感悟

量化交易，也称算法交易或自动交易等等，就是利用数值分析，概率统计，通过计算机建模，自动完成交易。Wiki 我是一个程序员，又是一个投资爱好者，当遇到Bitcoin时，我意识它给我提供了一个了解和实践量化交易的机会。 自己摸索了一段时间，有一些不成熟的感悟，希望如果有大牛看到，务必提点一下。 友情提示: 投资有风险，量化也有风险，Bitcoin风险更大，本文不形成任何投资建议 绝对不会暴富，赔钱也很平常 刚刚接触量化交易时，觉得这个东西希望很高级，趋势明显，很容易盈利。 后来又有一段时间认为量化交易是骗局，算法总是矛盾的，赚钱快的模型赔钱也快。 现在的感觉是这个大标题，这个有很多因素构成： 心理 粗读了一本叫《海龟交易法则》的书，讲华尔街的期货交易者如何通过既定模型进行交易的书。感觉最想传达的就是克制自己的心理，当交易按照既定规则进行时，过程中人们往往无法忍住去怀疑这个模型是不是好，或受到其他外界因素的影响，最终无法按照既定规则交易。 这个因素往往是最难的把握的，赚钱总是喜悦的，赔钱总是苦恼的，也许有用别人的钱可以一定程度降低心理风险。 理性的投资心态是做任何投资的基础，也与风险承受能力有关。 模型 模型是量化交易的根本，你的系统如果没有靠谱的模型，再好的UI，再完美的架构也无法盈利。我的干货： 模型不是越复杂越好，这点我从多篇文章和书中看到，自己也有同感。 简单模型如果在一段时间获得10%的收益，你想改进他获得11%的收益，从算法和程序复杂度上是成指数级别增长的，这个是我自己的猜想，待证实。 模型是针对市场的，没有通吃的模型。 模型不是想出来的，是实践出来的。不run不知道，一run吓一跳。(p.s. 又赔了…) 今天盈利的模型，未来可能一直赔钱。因为是市场的有生命的，博弈的。 预测模型: 号称在最高点卖出，在最低点买入的模型都是bullshit，这个绝对不可能，价格没到，谁也不知道下一步如何。 套利模型: 俗称搬砖，套利模型的风险在于物品交易时的时间差内，价格发生变化，这个风险是套利模型的风险。我也写了一个跟踪程序来尝试证明站内的套利模型是否存在，目前结果是否定的。一般站内存在套利模型的交易所，都是有手续费的，真是买的没有卖的精啊。 回溯机制: 市场有时反应没那么快，必定没那么多聪明人，所以用过去一段时间的回溯来验证模型应该是可行的，待证实。 市场 不是所有的交易都适合量化交易，量化交易我理解适用于具有以下特征的市场。 7*24小时开放，如外汇市场，Bitcoin市场 参与者多，大户均衡，没有人可以瞬间将市价提高10倍或降低10倍 与2有所矛盾，就是不能过度平稳，必须有一定幅度的涨幅，并且可以捕捉趋势。 交易手续费低廉，或者没有 参与公平：运营机构没有老鼠仓，提供真实的价格给交易者 个人如果可以参与，需要市场提供API给个人，而不会是只有机构有。当然也有别的办法。 未来 喊喊口号撒~~ 量化交易走下神坛，未来不是华尔街的，而是程序员的！ 真正的市场经济，必定是自由的，无中心。金融交易也会越来越透明，利润摊到人民。 电子货币系统不会灭亡，学习一下不要钱。卖篇关于Bitcoin的介绍[Bitcoin Briefly]。 互联网金融来到，金融市场人人参与，快快建立自己的量化模型。 最后附图这张模型step恰好match市场的成功的部分交易记录给不明真相的群众… 如果你很心动，读一下图片下面的标题…