许多人都有创作自己理想中的交易平台的冲动，这个一般做交易一段时间就会有。细想起来大概源于以下几点： 1. 操作中的一些想法，或出于便捷，或出于策略，认为自己可以随意更改平台的功能就好了。 2. 把一些交易中的失误归罪于交易平台的问题，或者认为交易平台的功能限制了策略的使用。 那么抛开功能本身的便捷与完善，这里提出的一个问题实际上是交易策略本身与软件功能能否彻底的独立开来。当然从理论上说，平台与在平台上开发运行的策略是应该可以独立分开的，而这么多人希望自己开发平台至少说明这个独立分离的实现并不完善，这么多年一直没有一个很好的解决方案，虽然开源的尝试不少，但是效果并不好，这么多人仍然热衷于开发自己的平台就是个证明。 另一个问题是软件包括计算机技术本身的发展，当然这么多年看到的交易平台主要还是在c＋＋，java，c#，现在多了个python之中，因此至少软件上变化的动力并不大。而散户角度看，对高频的需求也不大，因此技术上的推动力在这个现象里不能算作是主因。 这样看，除了软件本身的稳定性，用户界面优劣以外，在开发策略这个问题的解决上，至今还没有一个比较好的抽象化，因此也就不存在一个彻底使得开发策略独立与平台的可能性存在。这么多人做过交易，对金融股市深入浅出，同时这么多人做过软件，对开发技术才高八斗，却无法像其它行业一样抽象出一个股市上策略交易的高层架构，这是个比较sad的现实，也是一个机会。 更sad的是许多有志之士，把这个机会当做通过出租交易平台的一种商业，不论是潜台词的收集用户的策略，还是单纯的通过平台获得使用上的商业利润，比如Quantopian，C2等与国内无数的A股交易平台，都是走火入魔了。这中间例外的是一些商业平台被交易商买去成为辅助工具，比如TD， tradestation等那是唯一的正途。
坛子里有几个贴已经探讨过这个问题，比如ATSXL那个贴，算是到现在为止看到的最公开的尝试了，但是似乎也太监了。 每个人花时间与精力投入下去都会有自己的目的，那么开源一个交易平台的目的是什么，这是从开发者角度说。 开源一个交易策略大概没有人会认为这个人脑子正常，因为所有人都知道交易策略使用的人多了就会逐渐失效，因为一般认为股市是零和游戏，有效的策略自然是只有自己使用最好。那么开源一个交易平台呢？ 首先开源一个软件一般是推广一个软件的市场操作的一部分。单纯爱好者发烧友很多，但是爱好者开发的比较复杂的开源软件自从Linus那个年代之后就越来越少了，因为软件开发成本与投入的精力要求越来越高，因此开源后来成为商业运作的一种方式而存在。 对于交易平台这种相对比较复杂的软件，显然开发者的投入都是在寻求回报的条件下才有可能开发出比较靠谱的产品，那么回报在哪里呢？ 显然作为交易平台来说最直接的回报就是策略交易下的股市回报，而因为前面说过的原因，通过开源交易平台而获得对别人策略的使用，这个是万万不可能的，因为策略的保密性是策略拥有者的第一关注。 然而，C2，Quantopian等都是建立在策略开源的基础上的，他们的平台反而是闭源的（通过web使用）。这些网站的特点是通过开源一些策略来推广网站，也就是说其真正的目的是网站本身，本质上与脸书没什么区别。这样开源的策略，就好比是游客在广场给鸽子喂食，引来鸟儿再引来更多游客，但是这些策略不可能是真正的股市交易者感兴趣的，其效能与使用也因为平台的缘故受到许多限制。 我想真正希望自己做平台的交易者，其目的都是放在股市本身的，不是在利用股民这个群体去进行软件或互联网创业的，因为目标的冲突决定了其效果与执行必然是打折扣的。
对于回报的探讨引出一个问题，就是当一个复杂的开源软件（这里特指用户电脑上本地运行的交易策略开发软件）需要开发投入大量的精力与时间，而同时这个开源软件的目的本身不带有未来商业化（使用收费或出售），并且也不存在通过开源推广这个软件为未来形成下游支援商业化铺路（比如Apache，Linux那样）的目的，而是单纯为了自己与有共同兴趣的人开发交易策略的方便为目的。 这样的一个目的，我要说是导致迄今为止没有人可以成功的开发出一个开源交易软件的根本原因。因为这个目的导致它带不来回报，而在没有回报为动力的条件下，人可以投入的精力与时间是有限的，当工作量达到一定程度，必然会太监，sourceforge上面那么多的开源交易软件都是这个经历的证明。 因此从一个希望有一个自己可以随意更改的交易软件（有一定编程能力），或者是出于不论任何目的，希望有一个开源的交易策略开发软件的使用者角度去看，你可以为这个平台的开发者提供什么样的回报？是革命的首要问题。 而在一个既不出钱，也不出力（多数使用者没有编程能力），只有鼓励开源社区奉献的道德支持者的环境下，其实唯一所有人都还可以拿出回报的就是每个平台使用者的策略，让平台的开发者，维护者可以通过他们的义举得到回报。 但是这又与前文所说的策略的闭源性相矛盾，是不是这个问题是无解的？
遇到了死胡同，那么我们现把这个问题放一放，回头去看看交易平台与开源软件的问题，也许在其他问题上的探讨可以打开另一个思路。 前面说过开源软件中比较复杂的都是一些早期的发烧友，或者近期的商业化市场操作。这个说法其实不全面，因为还有一些也算比较复杂的软件，早期是被一股强烈的政治倾向推动的，或者是一种价值观。比如Bittorrent，bitcoin这样的，这样的软件的广泛使用对现行制度的冲击，本身就是对开发者的回报，也是其目的。因为其使用者数量越多这个效果越显著。开源虽然也是一个市场操作，却是为了尽快获得大量用户的一个决定因素。换句话说，获得大量用户本身就是目的，没有其他。 而这点与交易平台的策略开发目的也是背道而驰的。策略，或者alpha的寻找，本身是一个创新的过程，而创新似乎是一个独享的事物，多数人都知道的事情就不是创新了。这是一般人的直觉，其实创新的过程不是这样。一个简单的例子是，世界上那个行业最符合创新的定义，无疑是科学家，那些每天做research发paper的人唯一的工作就是创新，同时那个行业一年中花在conference中的时间最多，除了跑销售的就是科学家。为什么会这样？因为创新是一个必须在知识碰撞的条件下才能发生的事物，闭门造军是事倍功半的。反过来，也是不需要创新的行业，行业内的交流越少（销售除外），因为每天都在做例行工作是不需要不断更新思想的。 同理，独占性最强的交易策略的开发者们，股市上的股民们，最广泛的一个行为也是交流，换句话说，股市其实就是一个信息的市场，一个知识的市场，同时更是一个在不断的交流中寻找新思路，制定新的交易策略的创新市场。 绕了这么大一个圈，想说明的就是，交易平台的最大利益化，不论对开发者来说还是对使用者来说，不仅仅是提供一个策略开发的平台，因为那是一个非常机械化的过程，即把想法程序化，更重要的是一个让需要创新的策略制定者可以互相交流思想激发新思路的平台。 因此，平台使用者分享策略其实不是必须的，但是有选择的分享思路才是主题，至于程序化的策略执行甚至都不应该是这个平台的主要功能，而应该是一个价值最低的工具化部件，只要可以稳定的运行就可以了。记住，这个话题的前提是这不是高频操作，而是策略。高频操作是完全不同的一个话题与平台。 如果一个交易平台复合这些特点，那么类似bittorrent，bitcoin，这个交易平台的开源才会最有意义也最容易实现，因为使用者越多这个平台的达到目的的可能就越大，因为其目的就是让使用者交流。
我这几个帖子一直在阐述的一个概念就是把策略的创作与程序的开发分开，程序化的执行与测试是平台的一个可有可无的功能，但是最多的开发者着眼点却都在这上面，比如使用什么程序语言，与那个证券商接口等等，是单纯的工具固件，完全可以单独出去，通过使用者购买使用权的方式的到一个商业化的市场的，是可以与硬件条件，软件性能直接挂钩而成为一个白菜化的商品存在的。 但是目前上一般的交易平台设计，是无法达到这个目的的，因为这些平台要求策略的创造者必须通过写程序来把策略转换成程序才可以执行，这个方法不但局限了大多数不具备编程能力的交易者的创新能力，同时也给商业化交易平台对使用者策略的窃取成为可能，并把转换策略为程序的过程当成了策略交易的本身，进而出现了交易平台从开源－闭源－商业化再到开源－闭源等的恶性循环。 有人可能会问，股市是一个全方位的竞争市场，就是说丛林法则，类似bittorrent那样的更多的人获得创新的能力，推动炒股能力水平提高，这不是与弱肉强食的丛林法则背道而驰么。提高能力的事应该是越少的人具备越符合竞争原则么。股市本来是这样的，但是现在不一样了，因为高频的出现，因为庄家的存在，散户虽然是大多数，但是与几十年前的股市相比，现在的股市其实是拥有先进设备与人才的大资金对散户的提款机，市场已经与社会一样发展向两极分化了，时代已经向广大散户提出了更高的要求，更高的合作与创新的挑战，集中化与去中心化的竞争本来就是社会发展的节奏，现在的问题是散户以什么样的手段与能力去与大资金的高频等竞争，拼速度拼硬体甚至拼数据显然都是以己之短碰彼之长。
^_^ 可能微服务(Microservices)是一个可以考虑的方向。 微服务(Microservices) http://blog.csdn.net/wurenhai/article/details/37659335 说在前面 好久没写博文了，心里痒痒（也许是换工作后，有点时间了吧）。最近好像谈论微服务的人比较多，也开始学习一下，但是都有E文，看起来半懂不懂的。 Martinfowler的《微服务》，也算是入门必读了。有人翻译过，但是只有一半。还是自己练练手吧。 任何组织设计一个系统（广义上的系统）都会产生一种设计，其结构为其组织通信结构的复本。 -- Melvyn Conway, 1967 图2：Conway's Law的实践 微服务更倾向于围绕业务功能对服务结构进行划分、拆解。这样的服务，是针对业务领域有着关完整实现的软件，它包含使用接口、持久存储、以及对旬的交互。因此团队应该是跨职能的，包含完整的开发技术：用户体验、数据库、以及项目管理。 图3：通过团队边界强调服务边界 www.comparethemarket.com就采用这种组织形式。不同职能的团队同时为各自的产品构建和运营负责，同时每个产品又拆分成多个通过消息引擎通信的单独服务。 大型的整体型应用也可以按照业务功能进行模块化的，尽管这种例子不常见。当然，我们敦促一个大型的团队将一个构建成整体型的应用依照业务功能进行拆分。我们能看到主要问题在于，这种组件形式会导致很多的上下文依赖。如果在大量的模块边界上都存在这种大量的调用，对于团队的每个成员来说，短期内是很难记住的。此外，我们发现模块化方式需要大量的规范去强制执行，当然，大量明确的拆分也让服务组件在团队的边界中更加清晰。 Be of the web, not behind the web(善于利用网络，而不是限制使用网络。) ---- Ian Robinson 微服务团队采用这样的原则和规范：基于互联网（广义上，包含Unix系统）构建系统。这样经常使用的资源几乎不用什么的代价就可以被开发者或者运行商缓存。 第二种做法是通过轻量级消息总线来发布消息。这种的通信协议非常的单一（单一到只负责消息路由），像RabbitMQ或者ZeroMQ这样的简单的实现甚至像可靠的异步机制都没提供，以至于需要依赖产生或者消费消息的终端或者服务来处理这类问题。 在整体工风格中，组件在进程内执行，进程间的消息通信通常通过调用方法或者回调函数。从整体式风格到微服务框架最大的问题在于通信方式的变更。从内存内部原始的调用变成远程调用，产生的大量的不可靠通信。因此，你需要把粗粒度的方法成更加细粒度的通信。 Tolearant Reader和Consumer-Driven Contracts这样的设计模式就经常被微服务使用。这些模式解决了独立服务在交互过程中的消耗问题。使用Consumer-Driven Contracts增加了你的信心，并实现了快速的反馈机制。事实上，我们知道澳大利亚的一个团队致力使用Consumer-Drvien Contracts开发新的服务。他们使用简单的工程，帮助他们定义服务的接口。使得在新服务的代码开始编写之前，这些接口就成为自动化构建的一个部分。构建出来的服务，只需要指出这些接口适用的范围，一个优雅的方法避免了新软件中的'YAGNI '困境。这些技术和工具在使用过程中完善，通过减少服务间的耦合，限制了集中式管理的需求。 也许分散治理普及于亚马逊“编译它，运维它”的理念。团队为他们开发的软件负全部责任，也包含7*24小时的运行。全责任的方式并不常见，但是我们确实发现越来越多的公司在他们的团队中所推广。Netfix是另外一个接受这种理念的组件。每天凌晨3点被闹钟吵醒，因为你非常的关注写的代码质量。这在传统的集中式治理中这是一样多么不思议的事情呀。 Bounded Context的领域驱动设计。DDD把复杂的领域拆分成不同上下文边界以及它们之间的关系。这样的过程对于整体架构和微服务框架都很有用，但是服务间存在着明显的关系，帮助我们对上下文边界进行区分，同时也像我们在业务功能中谈到的，强行拆分。 当对概念模式下决心进行分散管理时，微服务也决定着分散数据管理。当整体式的应用使用单一逻辑数据库对数据持久化时，企业通常选择在应用的范围内使用一个数据库，这些决定也受厂商的商业权限模式驱动。微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。这种方法叫Polyglot Persistence。你可以把这种方法用在整体架构中，但是它更常见于微服务架构中。 图4：Polyglot Persistence 微服务音分散数据现任意味着管理数据更新。处理数据更新的常用方法是使用事务来保证不同的资源修改数据库的一致性。这种方法通常在整体架构中使用。 使用事务是因为它能够帮助处理一至性问题，但对时间的消耗是严重的，这给跨服务操作带来难题。分布式事务非常难以实施，因此微服务架构强调服务间事务的协调，并清楚的认识一致性只能是最终一致性以及通过补偿运算处理问题。 选择处理不一致问题对于开发团队来说是新的挑战，但是也是一个常见的业务实践模式。通常业务上允许一定的不一致以满足快速响应的需求，但同时也采用一些恢复的进程来处理这种错误。当业务上处理强一致性消耗比处理错误的消耗少时，这种付出是值的的。 持集部署以及它的前任持续集成的经验。团队使用这种方式构建软件致使更广泛的依赖基础设施自动化技术。下图说明这种构建的流程： 图5：基本的构建流程 尽管这不是介绍自动部署的文章，但我们也打算介绍一下它的主要特征。我们希望我们的软件应该这样方便的工作，因此我们需要更多的自动化测试。流程中工作的软件改进意味着我们能自动的部署到各种新的环境中。 整体风格的应用相当开心的在各种环境中构建、测试、发布。事实证明，一旦你打算投资一条整体架构应用自动化的的生产线，那么你会发现发布更多的应用似乎非不那么的可怕。记住，CD（持续部署）的一个目标在于让发布变得无趣，因此无论是一个还是三个应用，它都一样的无趣。 另一个方面，我们发现使用微服务的团队更加依赖于基础设施的自动化。相比之下，在整体架构也微服务架构中，尽管发布的场景不同，但发布工作的无趣并没有多大的区别。 图6：模块化部署的区别 Simian Army可以为每个应用的服务及数据中心提供日常故障检测和恢复。 这种产品中的自动化测试可以让大部分的运维团队正常的上下班。这并不意味着整体构架的应用没有这么精巧的监控配置，只是在我们的经验中它并不常见。 由于服务可以随时故障，快速故障检测，乃至，自动恢复变更非常重要。微服务应用把实时的监控放在应用的各个阶段中，检测构架元素（每秒数据库的接收的请求数）和业务相关的指标（把分钟接收的定单数）。监控系统可以提供一种早期故障告警系统，让开发团队跟进并调查。 对于微服务框架来说，这相当重要，因为微服务相互的通信可能导致紧急意外行为。许多专家车称赞这种紧急事件的价值，但事实是这种紧急行为有时是灾难。监控是至关重要的，它能快速发现这种紧急不良行为，让我们迅速修复它。 整体架构，跟微服务一样，在构建时是通明的，实情上，它们就是这样子的。它们不同之处在于，你需要清楚的认识到不同进程间运行的服务是不相关的。库对于同一进程是透明的，也因此不那么重要了。 微服务团队期望清楚的监控和记录每个服务的配置，比如使用仪表盘显示上/下线状态、各种运维和业务相关的指标。对断路器（circuit breaker）状态、目前的吞吐量和时延细节，我们也会经常遇到。 版本仅是最后的通告手段。我们需要在设计服务时尽可能的容忍供应商的变更，以避免提供多个版本。 太多不同的东西了，因此通常时候我们谈的所谓“SOA”时，它与我们谈论的风格不一至，因为它通常是指在整体风格应用中的ESB。 此外，我们发现面向服务的风格是这么的拙劣：从试图使用ESB隐藏复杂性， 到使用多年才认识到发费数百美元却没产生任务价值这样的失败，到集中治理模式抑制变更。而且这些问题往往很难发现。 可以肯定的时，微服务社区中使用的许多的技术都开发者是从大型机构的整合服务经验中发展来的。Tolerant Reader模式就是这样的一个例子。由于互联网的发展，利用简单的协议这种方法，让它从这些经验传达的出来。这是从已经很复杂的集中式标准中的一种反模式，坦白的说，真让人惊叹。（无论何时，当你需要用一个服务来管理你的所有的服务，你就知道这很麻烦。） SOA的这种常见行为让微服务的提倡者拒绝打上SOA的标签，尽管有人认为微服务是从SOA中发展而来的，或许面向服务是对的。无论如何，事实上SOA表达这么多的含义，它给一个团队清醒的认识到这种构架风格就已经值的了。 Netflix's的开源工具，但是包含Dropwizard在内的其它工具也被广泛的使用着。 断路器(circuit breaker)出现在《Realease It!》一书中，与Bulkhead和Timeout这样的模式放在一起。实施起来，这些模式用于构建通信应用时相当的重要。Netflix的博客在解释它们的应用时，做了大量的工作。 同步是有害的 任务时候，你在服务间的调用使用同步的方法，都会遇到宕机时间的乘积效应。简单的说，你的系统宕机时间是你系统的单独组件的宕机时间的乘积。你面临的选择使用异步或者管理宕机时间。在www.guardian.co.uk中，它们在新平台中使用一种简单的规则来实现它：在Netflix中每次用户请求的同步调用，他们重新设计的平台API都会把它构建成异步的API来执行。 微服务是未来吗？ 我们写这篇文章的主要目的在于解释微服务的主要思想和原则。但是发时间做这事的时候，我们清醒的认识到微服务构架风格是一个非常重要的想法：一个值得企业应用中认真考虑的东西。我们最近使用这种风格构建了几个系统，认识那些也使用和喜欢这种方法的爱好者。 我们认识的使用这种方式的先行者，包含亚马逊、Netflix、The Guardian、The UK Government Digital Service、realestate.com.au、Forward和comparethemarket.com。2013看的巡回会议充满了向正在想成为微服务一分子的公司，包含Travis CI。此外，大量的组件正在从事我们认为是微服务的事，只是没有使用微服务的名字而已。（通常，它们被打上SOA的标签，尽管，我们认为SOA有许多不同的地方。） 尽管有这些积极的经验，然后，我们也不急于确认微服务是未来软件架构方向。至今为止，我们的经验与整体风格的应该中相比出来的是有优势的，但是我们意识知这样的事实，我们并没有足够的时间来证明我们的论证。 你所使用的架构通常是你开发出来后，使用的几年的实际成果。我们看到这些工程是在一个优秀的团队，带着对模块化的强烈追求，使用在过去几年中已经衰退的整体架构构建出来的。许多人相信，这种衰退不太可能与微服务有关，因为服务边界是清晰的并且很难再完善的。然而，当我们还没看到足够多的系统运行足够长时间时，我们不能肯定微服务构架是成熟的。 当然，还有原因就是，有人期望微服务构架不够成熟。在组件化方面的任何努力，其成功都依赖于软件如何拆分成适合的组件。指出组件化的准确边界应该在那，这是非常困难的。改良设计要承认边界的权益困境和因此带来的易于重构的重要性。但是当你的组件是被远程通信的服务时，重构比进程内的库又要困难的多。服务边界上的代码迁移是困难的，任务接口的变更需要参与者的共同协作，向后兼容的层次需要被增加，测试也变更更加复杂。 另一个问题在于，如果组件并没有清晰的划分，你的工作的复杂性将从组件内部转向组件间的关系。做这事不仅要围绕着复杂，它也要面对着不清晰和更难控制的地方。很容易想到，当你在一个小的、简单的组件内找东西，总比在没有关系的混乱的服务间要容易。 最后，团队技能也是重要的因素。新的技术倾向于被掌握更多的技能的团队使用。但是掌握多技能的团队中使用的技巧在较少技能的团队中并不是必需的。我们发现大量的少技能的团队构建混乱的整合构架，但是它要发时间去证明使用微服务在这种情况下会发生什么。一个糟糕的团队通常开发糟糕的系统：很难说，微服务在这种情况下是否能帮助它们，还是破坏它们。 一个理性的争议在于，我们听说，你不应该从微服务构架开始做。最好从整体构架开发，做模块化开发，然后当整体构架出现问题是再把模块化拆分成服务。（尽管这种建议不是好主意，因为一个好的进程内接口并不是一个好的服务接口。） 因此我们持这种谨慎的乐观。到目前为止，我们还没有足够认识，关于微构架能否被大范围的推广。我们不能肯定的说，我们要终结什么，但是软件开发的挑战在于你只能在不完整的信息中决定你目前要处理的问题。
^_^ 如果有轮子可以直接使用，自动或者半自动起码方便很多，起码睡眠时间多不少。 ^_^ 散户，可能更重要的是怎样活得长。 ^_^ 很多人其实都知道底部股票很便宜，问题是很多人那时候没钱了。 ^_^ 抱歉，跑题了，坏习惯，老毛病了，请见谅。
rizm是通过拖放模块来设计策略，比较接近这个目标。 其实最强的那些策略基本上都是公开的，使用效果主要看使用者的理解程度和实现能力。 需要保密的是策略的具体实现形式，因为信息扩散范围直接影响策略实现形式的生存周期。 程序化平台的主要作用是降低实现能力的瓶颈。开源的意义在于消除对策略具体实现形式失密造成生存期缩短的担心。 我现在就用文华，感觉也不错。以前不喜欢它是因为Bug太多，去年发现这些年它进步不小，稳定多了。