爬虫的钳形攻势

爬虫的起源 先科普一下，这里说的“爬虫”是指网络爬虫，起源于互联网早期的搜索引擎。为了自动完成网页信息收集的工作被创造出来。 爬虫诞生后，虽然看起来非主流，却实质上是互联网应用最重要技术之一。除了我们熟知的谷歌，百度爬虫这些老牌，新起之秀今日头条，点评美团，去哪儿，58等等互联网巨头都是以爬虫为基础搭建的信息聚合平台，同时也拥有经验丰富的爬虫团队。 除了狭义以网页内容为线索爬虫外，其他以自动化形式获得信息的程序或脚本都可以称为“爬虫”。 爬虫的规模 爬虫在互联网上有多少流量呢，保守估计平均过半的流量都来自爬虫，有些行业甚至可以达到90%。 因为与人类相比，人类数量增长是缓慢的，反应时间也是有限的，人产生的流量有限。 而爬虫的规模则是随着IT基础设施，算力，带宽，吞吐的增加而正比增加的，其本质就是随着互联网中的信息增加而增加，这个是指数级的。 而且还在不断得高速增长，爬虫不会被消灭，只能被管理。 爬虫的黑白 “爬虫”是“人”为了简化工作而创造出的工具。它是中性的，创造和使用它的人们可以用来简化工作也可以用来做恶。 有时甚至无法定义黑白，不同的人商业目的，在互联网的战场上相互厮杀，爬虫技术自然成了这场战争中的武器。 爬虫的攻防就是规模大小，自动化，智能程度的高低的较量。其本质也是背后人与人的对抗。 最近有幸和头部互联网公司有过交手，略胜一筹，有感分享。 爬虫的钳形攻势 爬虫的技术细节很多，不想聊。回到主题，今天说一说最近这次对抗的爬虫，也许是你未闻的。 一般我们知道爬虫是自动化，想要对抗爬虫，就要找到自动化的规律，破解它。 没错，但这个规律是什么呢？五花八门，是不是可以用机器学习或者深度学习解决呢？有可能。 我们总说“攻防对抗”，对抗是不断升级的，指挥双方都是人，高手对决谁也不比谁差，你能想到的别人也可以，是对等的。 所谓“钳形攻势”就是在对目标发起攻击时，同时派出两个不同的分队，从不同角度进行攻击，甚至更多。 其中一个是大特征爬虫，炮火猛烈，人数众多，看来起就像是主力部队，也会比较容易被你或系统发现，摸清规律后控制。 另外一个时分散特征爬虫，像游击队一样，不断变化特征，频率，让你不容易发现它，悄悄得抢夺重要信息。 这样攻势的目的是通过大特征爬虫可以混淆你的自动规则和机器学习系统，让你的反爬虫系统表面上看起来工作顺利，发现并遏制了大量的爬虫。 但实际上关键信息还在不断流失。这种爬虫攻势不但有武器技术层面的杀伤，还有战术上的经验和灵活的应变能力。 也是爬虫战争终极对抗的关键。高手对决，最终消耗的就是资源（成本）和团队的规模。 广告 互联网巨头们垄断了技术和人才，谁也不想和他们较量。一旦他们的爬虫盯上中小企业或非技术驱动企业时，几个回合这些企业就会被打得落花流水。 我及我们的团队恰好可以在这里可以帮助这样的企业，守护你的每一寸信息。对爬虫技术，反爬虫产品有兴趣的伙伴也欢迎咨询与交流。 dongdong@servicewall.ai

ENVOY VS TRAEFIK

云原生场景，产生了很多的Edge Router，Load balance，API Gate Way，Proxy等组件。 最近研究了一下，分享几个喜欢的项目，它们大致分为两类： Gateway为主：Kong，Krakend Proxy为主：Envoy，Traefik 但两类没有实际功能的边界，Proxy为主，一般要支持在L4，Gateway为主，支持在L7即可。 Proxy主要位置是中间，可以做sidecar，Gateway在服务endpoint前面。 再比如传统的HAProxy就是Proxy，Nginx就偏Gateway。 这个概念和数据通信网络的Core Router和Edge/Service Router是差不多的，Edge Router是感知服务的，理论上功能更多，Data Plane基本一样，Control Plane功能更丰富而已。 所以Gateway一般是一个Control Plane + Data Plane，比如Kong的Data Plane就是OpenResty。 使用Envoy作为Data Plane的Control Plane有Solo.io（Istio族下）。 从需求角度，我有几个偏好： 高性能：C++，Rust，Golang还可以，其他语言就别Data Plane了 高扩展：必须支持插件，动态(如LuaJIT)或者静态(链接库)。 独立：Serverless，无依赖，无状态，单daemon，最好自带UI。 小而美：其实和上面几个也是一个意思，最好带简单Control Plane，但要节制。 功能性能上，需要看场景。我关注在差异上，也就是高扩展与独立。 Envoy：C++原生性能没得说，线程模型比Nginx还先进，水平扩展，所有配置均支持动态接口。最吸引我的是WASM的插件机制，逻辑上WASM可以编译到原生水平，还有很好的容器属性。只要push/pull就能增加插件进行使用。 Traefik在今年上半年选型时，我很看好，独立，2.0开始支持L4，与Swarm，K8S结合都很好，性能也与Nginx不相上下，但配置动态还自带UI，可惜当时不支持插件，惜败。没想到从2.3开始支持golang的动态链接库和golang代码解析执行两种（Dev Mode），实验阶段。 Kong/OpenResty：Nginx性能没的说，Lua动态没得说，Kong增加了控制平面的动态能力，差就差在Kong是几个东西组合的，大而全，但不小也不美，配置部署都麻烦。 Krakend：这个是个欧洲公司，小众，golang，插件支持Lua与Golang，性能说是比Kong高，有很技术后发优势，小而美，自带UI。但生态上还是和几个大哥差太多了，怕半路夭折了，长期观望。 Envoy VS Traefik C++ VS Golang WASM插件 VS Golang插件 小而聚(无控制) VS 小而全(自带UI） Envoy WASM插件： https://github.com/envoyproxy/envoy/tree/master/examples/wasm-cc BodyRewrite的流程，弄了一遍，总体不算太痛苦，哭在写C++上比较烦，当前还支持Rust，所以不算缺点。 本身插件是WASM文件，如果支持容器，还需要一些繁琐的步骤。据说性能目前还不行。可以先用Lua。 这里是Hub的生态，还比较冷清 https://docs.solo.io/web-assembly-hub/latest Traefik插件： https://github.com/traefik/plugindemo Golang的开发成本更低，写起来比较快，动态性上差点。 Plugins的生态更冷清。 https://pilot.traefik.io/plugins 虽然在插件概念上，大家都各用奇招。但插件需求还是比较高级的开发者需求，普通用户不一定用到。 我关注的其他功能 gRPC：都支持。 状态：虽说Proxy无状态的，但状态是我的特殊需求，比如RateLimit如何实现，分布式下如何存储状态，效率如何。两者实现默认都是无状态的，不能集群全局RateLimit。Envoy给了一种gRPC实现有状态的实现的例子。 数据收集：Traefik比较弱，主要是文本输出Access，Envoy更加灵活可以将日志通过gPRC protobuf输出。 总结

软件的生死

软件是有生命的，最终走向EOL。 那如何定义软件的“衰老”呢？ 是功能不够用，满足不了需求？还是功能太多，架构太复杂，无法维护呢？ 显然是“后者”，如果一个软件因为功能不够用，满足不了需求，那么它连“成长”的机会都没有。 所以我这里指的软件都是在市场成功后，快速下滑的。 这种经过“年富力强”，最后走向“衰老”，而且几乎是必然的。 软件产品经理的诞生是业界挽救“衰老”的已经验证的成功经验。 并不是产品经理有能耐，不然也不会说“人人都是产品经理”。 产品经理的角色设定，真正改变了软件需求的供需关系。 产品经理折射的玄学 没有产品经理的时候，程序员会根据自己的喜好开发软件系统，产生了大量“假设需求”，“万一需求”和“将来需求“，这些会使软件系统“衰老”加速。 为什么有独立产品经理时不同呢，因为产品经理要间接麻烦程序员开发需求，所以产品经理的大量“假设需求”，“万一需求”，“将来需求“没法都给到软件开发人员，只能低三下四次给几个，就在筛选这几个需求的过程中，“需求控制”的意义达到了。 没有哪个程序员愿意在高强度工作下，还能把产品经理的“假设需求”照单全收，都是推三阻四，提三个留一个，并不会都收下还连夜加班多送两个。 当然要达到这种控制的平衡，产品经理和程序员地位一定是一致的，虽然有“经理”二字，但一定是平级，否则悲剧还是会重演。 如果没有产品就没办法了么，有！ 那就是程序员的“克制”，自己克制对技术完美，架构完美的追求，克制对假设需求，万一需求，将来需求的恐惧。敏捷理论的“拥抱变化“并不是鼓励“需求变更”，而是说“将来”真的到来时再考虑这个需求。 程序员的克制 除了产品经理，玄学，还有几个方法： 让程序员自己实现自己提出的需求 让程序员自己测试自己开发的系统 让程序员自己维护自己开发的系统 DevPM，DevOps，DevTest 这不容易实现，其实就是独立开发者。 所以也不难理解独立开发者的软件水平要高与团队系统一个等级，独立开发者的时间开销和收入也必然要求他做最有价值的需求。 比如张小龙当年的Foxmail，最后变成了PM头子还能把微信需求把持得这么好。 现实情况下一个大系统一般不可能一个人开发，除非克服人性，极度“克制”。 当然一个没有产品经理的团队也要学会“克制”，“克制”软件系统在当下的需求。 预言 最后预言一下Hadoop全家桶快走向“死亡”了。 不是因为它不支持什么功能，而是支持的功能太多，引入组件太多，架构复杂，依赖复杂，维护困难，性价比低。 一个刚过“年富力强”的软件系统，过于贪婪，膨胀太快，“死亡”只会来得更快，拭目以待。

下下下一代防火墙关键技术漫谈

防火墙到底几代了？ Siri：“抱歉，很难回答你的问题”。 防火墙虽然是个网络设备，但其功能不需要与其他防火墙之间互联互通，所以没有“互联”标准化的诞生。 防火墙是在一个L2/L3网络设备基础上叠加不同的功能的软件系统，“功能”的标准化最后只停留在了“营销话术”，“第三方认证评级”，“市场调查机构”，“等保国标”的手上。 但有一点不可否认，相对上一代，下一代防火墙其实是“下一层”防火墙，将对网络流量的认知深入一层。 如果说ACL，五元祖的防火墙规则是第一代，那么相当于3层，网络层。 其下一代，状态防火墙可以认知TCP三次握手，位于4-5层，传输和会话层。 再下一代，UTM防病毒等认知到了应用数据，位于6-7层，应用层。 那下下下一代呢，已经超出网络的层次了，那么合理的推论就是在，在以上几代都检查不出来的情况下，认知对用户业务的威胁。 所以下下下一代算是目前看到防火墙的终极形态了。 如何理解针对业务的威胁？ 这个看起来是个玄学，因为这个层面上已经没有了协议的约束，所以是道“主观题”，还是文科的。 “主观题”在市场营销上可谓随意发挥，各种危机案例，骇人场景，人工智能，深度学习都上了。 但真正的工程角度，还是要把文科“主观题”转化给理科的“证明题”。 如何证明这道题目呢？既然我们知道主观因素很多，那么人的因素增加大，理解业务的深度和广度增大了。我们需要 更加深入灵活的规则 更深更广的数据支撑 更全面及时的情报 更智能的分析逻辑 所以最终这题关键考点“数据分析”。翻译成“人话”就是“找规律，找不同”。 比如：张三总是半夜访问，和正常人不同。李四像个机器人，每天都是固定模式读图。 工程与技术如何选择？ 大数据分析，机器学习，深度学习技术在过去10年有了一次越迁，技术层出不穷，但落地到安全场景是否合适？ 抛开市场营销不说，只谈干货。安全领域需求是主要分类“正常”与“不正常”的问题。 深度学习：基于神经网络技术，用于自然语言理解，图形图像视频识别，语音识别场景，其都是人的感官模拟。 看过一些论文将网络流特征弄成图片，然后做图像学习，感觉明显画蛇添足。虽然用了深度学习，其效果比传统机器学习还差。 目前我才疏学浅，还没认知到基于流量的安全领域使用深度学习的必要场景，而且人因素最大，算力资源要求也最大。 (补充: NPL可用于URL参数注入分析场景) 机器学习/大数据分析：相比统计规则，机器学习相当于在一定公式下进行最优解查找，找到最合适的参数。方法也很多。 但也都需要“训练”过程，这个过程在防火墙设备中进行目前还不是很适合，因为需要人指导，但训练后的模型进行“预测”完全可以在防火墙中进行。 目前我觉得决策树及其衍生模型，包括随机森林，GBDT均适用于实时预测，可以使用的工程框架如 XGBoost 的 C++ 版本。 其可行性论文网上已经有很多。 关键技术指标在哪里？ 首先防火墙都是以性能指标为参照，实现相同功能下以硬件代价小（成本）性能高为竞争力。 除了算法的领先，需要在架构上领先。无论使用机器学习，还是统计规则，都要在比过去大几个数量级的数据下提取特征为基础的。 也就是“数据量”与“计算速度”还有“灵活性”的能力要超过上一代。而这三者关系却是互斥的，需要做减法。 既然是“数据分析”是关键，我们看看现在有的技术Hadoop生态，显然可以处理大数据量，但是速度慢，成本高。 后起之秀 Spark / Flink 解决速度问题，但还是基于Hadoop生态，是一个通用框架，灵活性上更好，性能还是太慢。 而下下下一代防火墙被限定在一个固定输入的“数据分析”系统下，显然灵活性可以牺牲一些，数据量也可以牺牲一些，但速度绝对不能妥协，因为防火墙是嵌入在关键路径上的。 首先需要一个通用的深度解析引擎，能灵活将业务字段从流量中提取，显然当代防火墙都已经具备。 然后需要一个通用的计算分析引擎，能够缓存大量的关键数据，然后根据规则进行计算。 基于状态管理的流计算分析 首先这个不是新东西，做过状态防火墙的都知道，流表(Flow Session Table)就是基于流或会话关系的状态管理。 从会话产生，状态变迁到结束的过程，需要符合一定规律，这个规律是网络协议定义的，所有的检查都是基于这个状态进行叠加的。 对应到业务风险就是对业务状态的管理，一般来说正常人在线完成一个业务的平均值为30分钟以内。所以通常这个数据量只需要1个小时即可解决90%的场景，数据量的问题被减掉了。 然后是会话的key，在业务安全层面上，可以使用传统的IP，FlowId，但更需要使用的是AppId，UserId，DeviceId，SessionId这种业务维度的key，这是一个开放字段，但不会超过10种，需要通用支持，也就是从报文任意位置解析出来的字段，都可以作为这个状态的key。 业务中也可以同时有很多key的状态，需要进行聚合（AGG）关联（JOIN）或合并（UNION）。 第二个不确定就是规律，这个业务规律是无法事先定义的，没有协议，只能事后分析产生，所以机器学习和人工分析在这里需要能指导这个规律，具体不展开讲。 这个状态管理的计算也就是速度与灵活性的取舍，比如还是流表状态管理，这个显然是针对3层流量定制的状态管理，所以速度快。 但业务层面没法牺牲字段和计算表达的灵活性了，所以这里的功能和一个Flink CEP系统相似。（已经不少安全公司在云安全上使用了） https://ci.apache.org/projects/flink/flink-docs-stable/dev/libs/cep.html 其底层就是一个通用的状态计算决定的，这个通用状态可以抽象定义为 <key, state, ttl> 摘抄 Spark 中的一段代码，看起来就是这么回事，Flink中也是类似的的，所有大数据流计算都相似，但速度一定不会快了，

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