本文主要是介绍【交易架构day8】洋码头交易系统的演进之路——先生存后发展，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
按：我们谈系统演化，本质上是一个动态进化的过程，谁先做、谁后做，第一枪打在哪、这是关键。先保生存、再发展是比较好的策略。本文来自洋码头架构师张志强、涂文杰两位的分享。
1. 交易1.0
和许多业务优先、快速起步的创业型公司一样，洋码头的核心业务最初都在一个主站系统中。该系统很快发展成一个小型巨无霸，服务拆分势在必行。从主站系统剥离出所有订单相关功能，快速封装出一套独立部署的Restful风格的服务就形成了交易系统1.0。
在1.0版本，数据库读/写分离，订单操作服务和订单查询服务分离，买家订单查询服务和买手订单查询服务分离。
2. 交易2.0
随着业务发展，订单在线实时查询/聚合的场景/条件越来越复杂。为保证足够的性能，查询服务引入了越来越多，越来越复杂（譬如大量的SQL Join操作等）的查询存储过程，系统的可读性，可维护性下降；同时，为应对不断增加的查询条件及其组合，在核心的订单表上添加了越来越多的索引，严重影响了系统的下单峰值处理能力。因此，交易2.0的关键目标是：
-
查询服务去存储过程
-
订单表去索引
为此，我们将操作类数据源与查询类数据源彻底分离。操作类数据源为支持事务的SQL数据库，专注在写的高效，不提供查询服务。查询类数据源为文档型（Document）NoSQL数据库（Mongodb/ElasticSearch），专门用于各类订单查询，专注在读的高效与便捷。每完成一次订单操作场景（譬如订单支付成功），SQL数据库中被变更且需要被查询到的数据会被即时同步到Mongodb/ElasticSearch中。一个订单的所有能被查询的信息结构化在一个Document中，拿到订单ID，就能按需从Document中取数据构造查询结果，再无在1.0版本中大量多SQL表复杂JOIN操作的痛苦。同时，因为SQL数据库只负责写，各主要SQL业务表上订单ID之外的索引基本被清除，下单TPS可达原来的2～3倍。以下是版本2.0的总体架构图：
这篇关于【交易架构day8】洋码头交易系统的演进之路——先生存后发展的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
